Step II to move the code out of flake.nix. Done in a second intermediate
commit to make it easier to review.
Change-Id: I13fb386f2e9b87b1d28c366e9b7f0d2dbe03315c
That way we can use it in non-flake contexts down the chain.
We don't override the `nixpkgs` anyways since this is a test artifact
that needs an old nixpkgs input, so this isn't a concern here anyways.
Change-Id: If2aa8f7171a445e8321ef449026e206cc5a0fe3c
The upcoming change factors out a lot of code to make it reusable for a
"legacy" Hydra project that we use to build a matrix of (Lix x nixpkgs)
to have a warm cache for everyone.
The Hydra project will not use flakes to have some inputs overridable,
so the change is needed. In non-flake mode we don't have a notion of
"self", so rename it to `lixSrc` such that the next commit is purely
about moving stuff without changing any aspect.
Current stock Hydra doesn't expose `lastModified` though, so right now
that is a cache-miss. There's a pending Hydra PR fixing that[1].
[1] https://git.lix.systems/lix-project/hydra/pulls/82
Change-Id: I59d70b8b874f576c782217e7bca099eda4c7add9
The reference to the flake is used in a single place only to get the
`doc` output of Lix. Remove it so that we can also instantiate the tests
in a legacy Hydra jobset (happening further down the chain).
Change-Id: Ie3eccf42d67c81fcf991342097783e5067d512bc
That way we can automatically push the static build (compressed as
tarball) into the AFNix S3 bucket and have it updated on each update to
main.
Change-Id: I1002727ab12c0ab6b95c8d37ae4620996607d7b7
Admittedly, I do not understand what the comment means:
> As soon as Nixpkgs updates to >= 3.0.0, change to lowdown_2_0!
But this should work fine for nixpkgs versions providing lowdown 2.x or
3.x, and not cause rebuilds of the nixpkgs Lix/Nix derivations.
Change-Id: I6fb9e775335b4dbc23add76b98106970956e19fb
We would've had `build-lowdown_2_0.aarch64-linux.aarch64-linux`
otherwise. This is a bit of a problem because my way of generating a
list of constituents for Hydra's per-architecture[1] release job stops
recursing once it encounters a system.
The alternative would be to switch `hydraJobs` to `<system>.x.y` or
switching Hydra to "legacy" jobsets. For the latter I'd prefer to do the
same for Buildkite such that we don't have diverging things to build
depending on pre/post-merge CI.
[1] per-architecute because the trusted AFNix builders don't support all
the architectures we support in Lix and with Flakes there's no way
of parameterizing the list of supported systems.
Change-Id: I33f31260caf86ed5bb0f728770ca3cf1c00adf31
This job is used to indicate that all relevant Hydra jobs of an
architecture have built. The idea is to build some CD mechanism on
AFNix's Hydra to e.g. auto-update the nightly manual.
See https://hydra.afnix.fr/jobset/lix/demo for the current setup.
Change-Id: I41724c5884a068bbe41407ab30f8edf8e4914001
lowdown 3.0.0 merged some flags into one to save on bits and did not add
any aliases for backward compatibility.
As with the changes for lowdown >= 1.4, we define a preprocessor flag to
gate the changes on and add a job to CI to ensure that lowdown < 3.0
keeps working (which is used by NixOS 25.11).
Unfortunately, we need to jump through some hoops to prevent nix and lix
from upstream Nixpkgs from being rebuilt due to a changed lowdown. Since
both implementation's packaging in Nixpkgs has their own package set /
fix point now, we can't simply inherit them from `prev` since they will
always be (re-)computed from the `final` fix point. As a consequence,
we need to expose our changed lowdown version at a non-default attribute
or break the builds of Nixpkgs derivations we test against.
Change-Id: I20a3e2fdaa05906f032ff66911c42867557fdd11
the devshell no longer worked for us due to the recent deprecations :D
let's update pre-commit too because while it doesn't fail it does warn
Change-Id: Ic2060c82e4e97bb7a96cebd29097abefabdfe733
This adds a way to control the deprecated features that need to be
enable while evaluating the specific nixpkgs version
Change-Id: Ia2b9a29f1966d4d5f32239a36ba8270330007da9
This avoids rebuilding Lix each time we need to modify the lib tests
(as flake.nix stays unchanged), and adds a way to control the deprecated
features that need to be enable while evaluating the nixpkgs lib
testsuite
Change-Id: I2baa1cf90effcaf9d53337c6a7a5b24d6297178c
This bump nixpkgs input to 25.11 and fix the two warnings that were
coming with the update:
1. `pkgs.system` => `pkgs.stdenv.hostPlatform.system`
2. `runCommandNoCC` => `runCommand`
also:
1. remove cppnix 2.3 compat tests (cppnix 2.3 is officially dead now)
2. remove lowdown 1.3 compat tests (nixpkgs no longer carries it)
Co-authored-by: Tom Hubrecht <github@mail.hubrecht.ovh>
Change-Id: I78526b5d8992a6c63ecd7f0c7c1fa6346a6a6964
GCC still ICEs on coroutines, while Clang works properly. Use the latter, just
like for Lix itself.
Change-Id: I802d6df7279550a5f5355e6c1ea0533c6a6a6964
This partially reverts commit f68233ec43.
while more modern capnp in *does* have the build system changes, it
does *not* have the patches. and those patches are rather important
to us; the clock patch because our CI machiens don't behave the way
capnp expect and the nodiscard patch because it *is* a bugsquasher.
Change-Id: Ic273777f09fd8e5e7001f815db8998dae2dd7b88
Currenlty `lix` and `nixos-module` have slightly diverging version
numbering. This commit fixes the lix side of things, in accordance to
the format proposed in
https://git.lix.systems/lix-project/lix/issues/585#issuecomment-7336
which allows for better use of `builtins.compareVersions`
fixes#585
Change-Id: I2072b701f9fadf780e7aab67b62fbcd2ec5df76d
Without https://github.com/NixOS/nixpkgs/pull/434761 evaluation of the
`nixpkgsLibTests` will fail in CI with recent enough Lix, due to reliance on
the TOML integer saturation bug.
Reported-by: Sergei Zimmerman <sergei@zimmerman.foo>
Change-Id: I6a6a6964838009d2c525f67035f84072fdfad988
We need capnproto-lix to be provided by callPackage, otherwise it won't
be spliced and the same (built for the cross host platform) for both
buildInputs (correct) and nativeBuildInputs (incorrect). We thus move it
into the overlay.
A similar problem exists for the lowdown build. We thus use callPackage
to override it as well. This is horrible (especially because it means we
need to pass the enableDarwinSandbox package argument through
ourselves), but at least it builds...
Fixes: https://git.lix.systems/lix-project/lix/issues/939
Change-Id: I802152072d852903401ef701f526195aa99475f2
postInstall needs to know the name of the (versioned) .so file since it
needs to be renamed for Darwin platforms. Unfortunately, the .so version
is not properly overrideable, so we need to use string replacement.
Change-Id: Idf9671f84fac955a52d82a20ec0f381d05fdc762
We upgrade to 25.05 release, which contains the curl commit
https://github.com/curl/curl/commit/5fbd78eb2dc4afbd8884e8eed27147fc3d4318f6
done in
https://github.com/NixOS/nixpkgs/pull/396200#issuecomment-2795944006.
This fixes HTTP transfers generating arbitrary errors and possibly
failing unusually.
Users who are already depending on 25.05-small or a recent unstable
already had the fix.
Special mention to the Linux kernel who gave me the opportunity to get
on a 24 hours bisection side quest to fix the local release engineering
test.
Special thanks to everyone who had to endure me ranting.
Change-Id: I866caf65d5ea103f1fa5eccd57df8031c9eacda0
Co-authored-by: eldritch horrors <pennae@lix.systems>
Co-authored-by: helle <helle@h3l.li>
Signed-off-by: Raito Bezarius <raito@lix.systems>
This takes the first baby steps towards resolving #765. This first
test/workflow isn't the most useful thing ever, because it doesn't
test the code path for building the manual. Still, it does a decent job
at testing the basic git workflow, and the upload functionality.
Change-Id: I16dd3a39addd6308ad3eb37c2e3dc3466584a4e3
Closes#703
The problem boils down to:
* A testcase with a segfaulting worker due to a stack overflow from the
evaluation.
* When the controller encounters that the pipes are down, the worker's
state is checked and a potential infrec is reported if it stopped with
SIGSEGV.
* However, in a few cases, the worker didn't exit yet, but only had closed
pipes (which is how the error is detected). In that case, a different
error message is printed breaking the test.
This bug handling only affects error cases, so this race doesn't happen
on normal shutdown. To mitigate the problem a bit, the controller will
wait for a second and re-check the state of the worker process then.
While this should make the error reporting for end-users a little more
reliable, it's still no guarantee for a non-racy test. Hence, the test
asserts against both cases now and it passes if either the infrec error
or the "worker still running, but pipes are closed" error is returned.
Change-Id: Ifdc7a05bc86b6aecd5d03118d3e3ffc9affe1c5e
Now that we're using nixpkgs 24.11 it's possible to build cross
for FreeBSD from linux, both in a derivation and a devShell.
Change-Id: I06fa257023397a97cdc72af51170e8523e9f1bfb
This exposes the `pytest` suite as a Nix build. Previously, this didn't
exist and upstream just runs this in GHA. As a result, the test was
actually broken since the assumptions about the directory structure have
changed.
To not require network access, the nixpkgs used by the Lix flake is
injected into the test. The evaluation will be done in a chroot store
since the `openStore` call would otherwise need write access to
/nix/store.
Change-Id: Ib4ff5f0319ce3aabb3b7243a076ea169e27e3533
We don't want any of this github integration stuff since it won't do
anything, flakes don't support subdirs properly and maintaining a second
flake is pointless and annoying, and then the rest is lix formatting
standards hitting n-e-j.
Yeet!
Change-Id: Ibcd3b0182d90f727562a92c215b6061c16502554
nixpkgs 24.11 changes how we access xonsh yet again
and updates clang.
Unfortunately, clang 18 produces significantly more
warnings on existing code that is challenging to fix.
Make sure that doesn't error when we're running
`-Werror` builds.
n.b. I had to change the "SSL certificate problem: self-signed
certificate" to the old error prior to the improved libcurl errors,
since what is presumably a difference in which TLS library is used has
cropped up between releases? Either way the curl error buffer is empty.
Seems like we aggressively cannot do anything about this.
Change-Id: If0141a46a8b445a0e7d6f86f939e8c8e03569bf5
The devShell relied on several packages directly from `pkgs`
or used with a non-splice-aware functions.
These would be built for the host system, making them useless
in a devShell for the build system.
Make sure that all packages are for the build system when needed.
Some other minor changes also required:
* Make devShells use `clangStdenv` because GCC is currently broken
* Disable rr when making a cross stdenv
Change-Id: Iee5f8a1a0c594139a50f2261b203491bd1644866
Maximilian Bosch