if the netrcFile setting has been changed tell curl that the file is required, so
fetching fails if the file does not exist
if the caFile setting has been specified, check if the file exists and throw an
error if is it non-existent
Refs: #1106
Change-Id: Icb9330a7a715175d35b9ed894ed945f0fd4d7061
So apparently we can still use the repl if the input file fails, as long
as we have the debugger enabled.
This Commit removes the "only one output block for should_fails"
requirement to allow this behavior
Change-Id: I02568c8d7e4305ab6414953306650bbe13c6f4bc
curl does not support this configuration. we can't easily change the
config setup to mirror how curl works, but we *can* print a warning.
fixes#1223
Change-Id: Iaa1583275d9cc9e5eed5552210db183a8e0628c8
the case-sensitiveness of the "accept all options" prompt (and the fact
it silently defaults to no) was confusing a few users, so by rewording
it slightly we can avoid that case-sensitiveness and make the prompt
clearer. for consistency, i also rewrote the individual accept prompt to
make it case-insensitive.
at reviewers' requests, i also reworked the code so it re-prompts the
user on invalid answers.
Change-Id: Ie786c0f26a0aa752b22d5a5e8af1b2c7ca2846b5
lix.pc currently lists several optional libraries (such as libcpuid and
libseccomp) as required dependencies. Update the pkg-config generation
step to only list optional dependencies which are used by the Lix build.
Change-Id: Iceea7ecc9421b5b10fc08edbe95a063a4e39cea1
what the actual fuck. swallowing all errors *except* EXDEV is not okay.
renames do not do this, so moves should not do it either. luckily we do
not use moveFile anywhere except the store path registration code. this
may or may not have caused problems in the past. probably nobody knows.
Change-Id: I2b0255a5703983cbd129abc3219c11ac7171fd12
catch and rewrap std::fs errors in some meaningful way, otherwise lix
can crash with foreign exception aborts if filesystem failures happen
that aren't already being caught. renames in particular can fail with
incomprehensible errors in even pretty normal circumstances elsewise.
fixes#1219, fixes#995
Change-Id: I0b1e5696d300aac3422e43cffc17a2426803d64e
I'm not sure why this wasn't an issue before, but the generation of
jobset constituents in Hydra trips over this. The Hydra-convention is to
have the `system`-attribute last anyways, not in-between.
Since this is a single attribute, get rid of it for the sake of
simplicity.
Change-Id: I80ef1b92ed158c8712ee899534ce82130614f338
This is a Hydra jobset definition to be used to warm up a cache with Lix
versions built against several nixpkgs versions. This is only happening
after a bunch of tests have passed.
Change-Id: Id0b0e50c08581f3f377c7c793d2fd83a6007999d
If e.g. i686-linux is not in the list of systems and thus no attribute in `nixpkgsFor`
exists (e.g. on hydra.afnix.fr), don't try to instantiate it.
Change-Id: I118e2af5289ad7bd95ce7f1e6b0728afb6f0321f
...expect for the dev-shell: while it doesn't seem reasonable to me to
even build dev-shells in post-merge CI, this should still remain part of
the pre-merge checks.
Change-Id: I5cb9b4cf53484f884d694770ed94d0dc0862117e
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
Noticed on my quest to make Lix buildable against multiple nixpkgs' to
provide pre-warmed caches for the flake on AFNix's Hydra.
`pkgs.systemd` has a new patch policy[1] that only allows patches for
hotfixes and fundamental incompatibilities. As such, the patch that
allows nspawn workloads to start without a `/usr/bin` was removed with the
recommendation to create that stub yourself.
[1] https://github.com/NixOS/nixpkgs/pull/488508
Change-Id: Iaa35ae3b8971867f12daeac5f94958c20a7d9233
The option has been broken since Nix 2.4. The flag was accepted, but not
used. This change plumbs it through to computeFSClosure.
Change-Id: Id6adee8ea8a6a4f457b24b650660f319e3daa2b2
This makes it easier to build lix on a different file system from the
source repo, e.g. symlinking ./build to a directory in /tmp.
The ./outputs directory is included for completeness as another
significant source of generated artifacts.
Change-Id: I1bb4c21c700beacb4882a1be473dd31353edd177
this logs unpackTarfile calls as an `actUnknown` activity, which
unfortunately doesn't report any progress for now. for the reasoning
behind this choice, see the previous iterations of this CL (cl/5590)
as well as the attached comments (the crux of the conversion is in DMs,
unfortunately). in short:
- i could't make a new ActivityType because that would be a breaking
change to the daemon protocol, including with previous lix versions
- i can't use actFileTransfer because that would show up as a download,
which would be confusing for both users and tools
- i can't use actCopyPath /or/ actCopyPaths because that would break
NAR/substitution accounting when doing remote builds
also, ArchiveDecompressionSource, which is apparently used for
decompressing logs etc, does its own custom decompression without using
unpackTarfile, so it is not affected by this. from what i can tell,
unpackTarfile is only used for:
- fetchtarball fetcher
- git fetcher
- channel unpacking
- nix-prefetch-url
Fixes#1213
Change-Id: I68f3be520681d8889292353dd41ab19a60c5eeea
rootile