hydra.nixos.org serves broken binaries because of our favorite non-deterministic
package IDs in GHC bug. :-( Re-building everything from scratch seems like the
easiest way to recover.
We disabled this to prevent users from accidentally running nix-build on
an 'env' attribute, but in fact the ability to use those in combination
with "nix-shell -p" is quite useful, so the restriction is lifted.
This is essentially what's been done for the official NixOS build slaves
and I'm using it as well for a few of my machines and my own Hydra
slaves.
Here's the same implementation from the Delft server configurations:
f47c2fc7f8/delft/common.nix (L91-L101)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This not the latest, but the greatest version (by number of models still
supported).
A big bump. Everything seems to work fine. Tested with a Samsung CLP-325.
Also fixed some strange things. Did this ever even work? On x86_64?
This reverts commit 7719f7f23b, again!
It prevents systems from booting, for two reasons:
* The initrd size is going to explode, but I think this is not the
REAL issue. We had that in 666cf99 already, which reverted this
update already.
* Another reason I don't yet know, which is the REAL issue. We need to
investigate and fix that before attempting another update.
Because of that I've also added a small comment before the src attribute
to prevent further updates like this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Many bus clients get hopelessly confused when dbus-daemon is
restarted. So let's not do that.
Of course, this is not ideal either, because we end up stuck with a
possibly outdated dbus-daemon. But that issue will become irrelevant
in the glorious kdbus-based future.
Hopefully this also gets rid of systemd getting stuck after
dbus-daemon is restarted:
Apr 01 15:37:50 mandark systemd[1]: Failed to register match for Disconnected message: Connection timed out
Apr 01 15:37:50 mandark systemd[1]: Looping too fast. Throttling execution a little.
Apr 01 15:37:51 mandark systemd[1]: Looping too fast. Throttling execution a little.
...
It has been removed by 71a197bc6e.
I'm reintroducing the test mainly because it actually *is* useful,
because right now, machines with mdraid will not boot. In order to
prevent such things from happening in the future, we should *not* remove
this VM test again.
If it really goes back to failing randomly, we should really try to fix
it instead of removing it again.
Of course it fails right now because of the mdraid bump in 7719f7f.
Also, if you want to have additional info about the reasons, have a look
at the commit message of 666cf992f0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm increasing it to 100MB to make sure, any bootloader will fit with
all its stages. Of course, right now the reason why GRUB doesn't fit
into the partition is because of mdadm 3.3.2 and thus the initrd taking
all the space, but in order to avoid confusion on why the *boot* loader
fails in the VM tests, I've increased the size.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
