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>
If state records are not destroyed at destroy time, this might confuse a
new build that thinks there's a remnant of a cgroup when actually it was
destroyed.
This fixes a bunch of inoffensive and noisy warnings about cgroups being
deleted by someone else.
Reported-by: Ramses <@rvdp:infosec.exchange>
Change-Id: Ib3d33f4ecd6143f33e032c5107b288b4ecabaee1
Signed-off-by: Raito Bezarius <raito@lix.systems>
User locks are taken to avoid another build grabbing the same UID.
Under build user contention, it is possible to recycle the same UID from
another build which did not run the Goal destructor yet.
Prior to this change, cgroups were destroyed at Goal destruction time,
but user locks were released at `buildDone()` time.
Therefore, it was possible to have 2 builds fights for the same cgroup
and mess with it, resulting in confusion.
To avoid this, we override `cleanupHookFinally` in charge to release the
user locks and we destroy the cgroup before releasing the locks.
Statistics are kept in the `cgroup` object a bit longer and can be
obtained at `killSandbox(true)` time.
`AutoDestroyCgroup::kill` now ignore if the cgroup path has already been
destroyed, as kill is idempotent.
Reported-by: Ramses <@rvdp:infosec.exchange>
Reported-by: Frederico Schonborn <@fredericoschonborn:matrix.org>
Change-Id: Idfbf9aaf010c5f718f2c1c38548383d912d8ee95
Signed-off-by: Raito Bezarius <raito@lix.systems>
Such a RAII structure should NEVER be copyable or movable, otherwise:
```
AutoDelete x;
x = AutoDelete(p, false);
```
will trigger the immediate deletion of `p`!
This fixes an annoying bug where the state record for cgroups was
deleted immediately as soon as it was created.
Change-Id: I2bfbc0815706700a0a75b79d1059cc552119b2c9
Signed-off-by: Raito Bezarius <raito@lix.systems>
It's `delegated` and not `delgated`, also it's `DelegateSubgroup` and
not `DelegateSubtree` which I clearly hallucinated because of subtree
vs. sub(c)group.
Change-Id: Icfaa6116fa83416c431820978ef35aa8aa943feb
Signed-off-by: Raito Bezarius <raito@lix.systems>
We offer full cgroup delegation to our sandbox now, required for running
containers inside the sandbox.
To run systemd-nspawn or containers managers inside the sandbox, there
is a need for one extra ingredient now: control over your own cgroup
subtree inside the sandbox.
If, in addition, you need multiple UIDs, for e.g. rootless usecases, you
need to run with the `uid-range` system feature.
Therefore, when the daemon or Nix runs under the right condition, e.g.
systemd-style delegation of the cgroup subtree while placing the
nix-daemon in a supervisor sub-cgroup, we create a new sub-cgroup for
each build based on the build UID and delegate that sub-cgroup to the
builder's process.
Additionally, `uid-range` always request the `cgroups` feature now, as
`uid-range` builds would probably always benefit from having cgroups
delegated, but the converse is not true.
Inspired from https://github.com/NixOS/nix/pull/11412 with a different
design that does not use function-local statics to derive the root
cgroup.
Co-authored-by: Linus Heckemann <git@sphalerite.org>
Co-authored-by: Parker Hoyes <contact@parkerhoyes.com>
Change-Id: Ic8947c5adaf4b5bbd153386e05fad65a935274fa
Signed-off-by: Raito Bezarius <raito@lix.systems>
We drop it to re-introduce it via the concept of build context which
will control in which cgroup a certain build should be spawned.
Change-Id: I4b4705d768129a6d7c0f061dc2163ba116088b18
Signed-off-by: Raito Bezarius <raito@lix.systems>
Some source trees might not be representable inside of the NAR listing
format v1 as file paths (on Linux) are not guaranteed to be valid UTF-8.
When something like this happens on a large-scale build farm, a
mysterious "queued" but impossible to process job appears, this is
because we cannot write the NAR listing and serialization always fails.
Why did this work before? nlohmann was introduced _after_ such paths
were ingested, see: 09f00dd4d0.
What happened for such previously mis-serialized NAR listings?
```
curl -v 'https://cache.nixos.org/nz8p9hn00r6z7s57581c1hiv39pa1ia6.ls' |
brotli -d | jq .
```
This fixes the build of `sub-batch`
(https://github.com/kl/sub-batch/tree/master/tests/rename_invalid_utf8)
on ForkOS infrastructure.
Many thanks to Puck for the assistance on holding `rr` right on this one
and finding the history of these changes.
Change-Id: I2c2fbac70818e02810f9fd236c3a248187bf5fe7
Signed-off-by: Raito Bezarius <raito@lix.systems>
Instead of allocating a new Value and copy the symbol string
representation inside of it, we can pass along the underlying Value,
which avoids (garbage collected) allocations.
This results in:
* a ~8 % reduction for `gc.totalBytes` over
`nixos.ec2.closures.x86_64-linux` for NixOS 24.11. (920MiB → 842MiB)
* a slight reduction in CPU time due to less allocations being performed
at all
Change-Id: I097f586dbc98f889fbc62d0a5f80c9d76ddedfd2
Signed-off-by: Raito Bezarius <raito@lix.systems>
The backing storage for symbols becomes a class storing a Value and a
string.
The Value is itself a string which contents points to the owned string.
Recovering a `SymbolStr` is still possible.
Change-Id: I171151abc3c0a513f2150c4b54edd61dea256cce
Signed-off-by: Raito Bezarius <raito@lix.systems>
The symbol table will contain types that encloses a Value, thus, it
needs to depend upon the Value header, whereas the Value header depends
on `Symbol` for typedefs.
We move the typedefs in the place where they are used.
Change-Id: Ic533e5aad927b9bc4a9d1723430e90e86a4b5466
Signed-off-by: Raito Bezarius <raito@lix.systems>
This simplifies many call-sites where construction can take place
automatically.
Change-Id: I87f697d55375676345b388024eb8df900bf808de
Co-authored-by: Tom Hubrecht <github@mail.hubrecht.ovh>
Signed-off-by: Raito Bezarius <raito@lix.systems>
Lix has a style guide:
https://wiki.lix.systems/books/lix-contributors/page/code but
contributors like me have been unable to enforce it, which is sad.
To avoid further violations of that style guide, we enable a pre-commit
hook for clang formatting of the changed lines.
Change-Id: I217452efa3ac8bd66b4d3a08a6fe9a241207790b
Signed-off-by: Raito Bezarius <raito@lix.systems>
This is useful to reformat only changed hunks of a file via
`clang-format`.
Change-Id: I9aa8526d75fd2301113ee57f3a2e595f3b03504f
Signed-off-by: Raito Bezarius <raito@lix.systems>
The coerce integer feature was not rebased before merge and we do not
have a merge queue, hence, after merge, the HEAD was in a broken state.
We take a commitment to invest into a merge queue now and do a fixup
here.
Change-Id: Ied9410690b542359859ab5f597f22ebceb857305
Signed-off-by: Raito Bezarius <raito@lix.systems>
This introduces a new (demanded?) feature for coercing integers in
interpolation arguments under the experimental feature
`coerce-integers`.
This feature is being introduced behind an *experimental feature flag*
due to the cautious approach we're taking. The codebase has a track
record of revealing unexpected behaviors, often in subtle ways, so we
want to give this sufficient time and exposure before making it stable.
To remove the experimental flag, we want to see **at least two releases
or six months of real-world usage -- whichever is longer** -- that
demonstrate strong confidence the feature doesn't introduce regressions
or unintended side effects. If that level of confidence is reached,
we'll proceed to stabilize it.
Change-Id: I825904719eeba8f0e2a93cd6b93cfe6cebd7d827
Signed-off-by: Raito Bezarius <raito@lix.systems>
`ExprConcatStrings` tracks whether the expression is an interpolation or
not via an obscure boolean called `forceString`.
Instead, we rename it to `isInterpolation`.
This is a breaking change for the JSON AST representation.
Change-Id: I9f89337449b56f6e99a961e21169761f554c9896
Signed-off-by: Raito Bezarius <raito@lix.systems>
Inspired by cl/3191 and
https://git.lix.systems/delroth/lix/commit/ae0247cbb4fc739ab013dc87d02e5f3191cf25ab.
`coerceToString` takes now an enumeration that lives in `value.hh`, this
enumeration is meant to represent increasing subsets of behaviors, e.g.
any level above Strict should do what the previous levels do and extra
behavior until `ToString`, which transforms many Nix values into an
arbitrary string representation, e.g. `null` to `""`.
Change-Id: Ief7a4756e8c0660e197623efebeaf07710746ec7
Signed-off-by: Raito Bezarius <raito@lix.systems>
Co-authored-by: Pierre Bourdon <delroth@gmail.com>
The pre-flight `echo started` check over SSH was originally added in
577ebeaefb. As it is usual with these old
commits, understanding why is there a need for something is difficult.
The closest thing would be
> Fix a race starting the SSH master. We now wait synchronously for
> the SSH master to finish starting. This prevents the SSH clients
> from starting their own connections.
But, we removed SSH connection sharing, so this does not apply anymore.
Nonetheless, we believed this check was meant as a way to catch obvious
misconfigurations or SSH failures early, before handing off to
`nix-store`. However, this approach was not fruitful: it assumes the
remote has a `bash`-compatible shell, `echo` behaves in a standard way,
and no `ForceCommand` interferes—all of which are unreliable assumptions
in practice.
While the intent was to provide slightly better diagnostics (e.g. in
case of SSH hanging or returning an interactive shell), in practice it
does not meaningfully catch or improve real failure cases. The
underlying protocol or engine can and should handle those errors more
robustly anyway.
In contrast, this check *does* break several legitimate workflows,
including:
* remote builders using `ForceCommand` wrappers (e.g.
`nix-remote-build`-style setups), see
<https://discourse.nixos.org/t/wrapper-to-restrict-builder-access-through-ssh-worth-upstreaming/25834/15>,
* SSHing into minimal environments lacking `bash` (e.g. initrd,
busybox-based systems),
* configurations that don’t default to POSIX-like shells, e.g., nushell
enthusiasts.
As such, we’re removing this code. Protocol mismatch errors and SSH
failures can be rethought and handled more structurally elsewhere in the
engine.
Change-Id: I187f6881375d42ef83987a13a350c97964bbdb30
Signed-off-by: Raito Bezarius <raito@lix.systems>
If the profile inode is invalid, e.g. invalid symlink, the current
generation cannot be discovered.
Nonetheless, this should not be a reason for an assert failure, instead
of crashing, just raise an error.
Fixes fj#801.
Change-Id: I63937672173bc3bf37196de98307800adc5757e1
Signed-off-by: Raito Bezarius <raito@lix.systems>
Co-authored-by: Qyriad <qyriad@qyriad.me>
From time to time, our KVM's CI machine clock goes in a weird direction
during NixOS tests, this is known on certain hardware, e.g. macOS, where
the check is disabled. Cap'n'Proto removed the check everywhere now.
Fixes fj#754.
We can remove the patch once it hits a stable version of Cap'n'Proto.
Change-Id: I4c9be5061c3b244f601486a8ac4521dff44ceb92
Signed-off-by: Raito Bezarius <raito@lix.systems>
This was discussed as part of https://git.lix.systems/lix-project/lix/issues/767
with a one month long comment period.
This commit removes the recursive-nix feature from Lix. It has seen
limited usage and is difficult to stabilize, especially on non-Linux
systems where its behavior is underspecified.
Maintaining this feature complicates core work on the store, as we must
account for the potential presence of the daemon in the sandbox, adding
unnecessary complexity. Additionally, its inclusion in the
platform-independent local store creates risks for non-Linux platforms.
For more details on this removal, refer to the release note entry or the
issue entry.
Change-Id: I9137202f563c0a317f9c5da79cd9fd07d801427a
Signed-off-by: Raito Bezarius <raito@lix.systems>
When external subcommand support landed, the `lix` binary gave
accidental access to nix3 CLI as well.
This was not the intended effect of this feature, we want to keep `lix`
as a namespace for a new redesign of the CLI (that has not started yet),
while giving that namespace for external subcommands.
To this end, we sever the nix3 CLI connection for the `lix` binary.
Fixes fj#508.
Change-Id: I13a0748bcbf87343c8e0e89439bd4af3a0ac3118
Signed-off-by: Raito Bezarius <raito@lix.systems>
There's no reason to make it dependent upon `Xp::Cgroups`, this
increases the purity of the builders' views.
Change-Id: I3d934428177e6bb78cd700d1cce1ded8a88e9da0
Signed-off-by: Raito Bezarius <raito@lix.systems>
This feature allows calling external binaries starting with `lix-` as
subcommands directly within the `lix` CLI, similar to how Git handles
external commands.
For example, a binary named `lix-example` can now be invoked using `lix
example`.
This change opens up the possibility for broader community-driven
extensions of the Lix CLI, offering flexibility that Flakes has somewhat
restricted by centralizing certain features around its own model of
dependency management.
By enabling users to introduce custom subcommands, we encourage
experimentation and diverse workflows, addressing the needs of those who
seek more modular, feature-rich approaches to package management and
system configuration beyond what Flakes currently offers [1] [2] [3].
This adds `lix` as a new binary to be able to use this feature.
[1]: https://github.com/nmattia/niv
[2]: https://github.com/andir/npins
[3]: https://github.com/nikstur/lon
Change-Id: Ic6344424a6a46fc9fb30432f00e21c3509659f8a
Signed-off-by: Raito Bezarius <raito@lix.systems>
Original-Author: picnoir <picnoir@alternativebit.fr>
Inspired from
https://github.com/NixOS/nix/pull/11922/commits/ced8d311a593fcf9c3823e4e118474ac132d8e60
and adapted for Lix needs.
TL;DR: The topological sort should ensure that it is possible to delete
the path iterated upon. Nonetheless, in some cases,
`invalidatePathChecked` can still throw `PathInUse`, the exception
bubbles up and cancel the garbage collection procedure, leaving the rest
of the paths untouched. This change ensure that the error is logged for
further investigation but doesn't prevent the GC to continue when it
can.
After code review, we decided to make it a `printInfo` to inform the
user about sudden "in use" dependencies during garbage collection and
let them re-run garbage collection if they care about this.
References: https://github.com/NixOS/nix/issues/11923
References: https://git.lix.systems/lix-project/lix/issues/621
Change-Id: I5606c9afd16b5faa747b713fde2dc24016990ba3
Signed-off-by: Raito Bezarius <raito@lix.systems>
This reverts commit 02c35ea9df.
Reason for revert: this code path is also used for `Input::getRev()`, i.e. flakes VCS revision validation, which, in the case of Git, are using SHA1.
As a result, this cause too much noise due to SHA1 revisions in Flakes.
Change-Id: I8064c1ebc26e4e83b627f0803a7a9ba56cfe1f37
Revert submission 1946
Reason for revert: regression in building (found via bisection)
Reported by users:
> error: path '/nix/store/04ca5xwvasz6s3jg0k7njz6rzi0d225w-jq-1.7.1-dev' does not exist in the store
Reverted changes: /q/submissionid:1946
Change-Id: I6f1a4b2f7d7ef5ca430e477fc32bca62fd97036b
Fate has something different in store for the release process,
backporting process and the general maintainer documentation.
See https://git.lix.systems/lix-project/lix/issues/260.
Change-Id: I626686ff4059aee22a3ab1664b52581b2dbf6ed7
Signed-off-by: Raito Bezarius <raito@lix.systems>
Now, we can credit folks for their work.
The credit generator is very basic, we probably want a database of
profiles and link to their preferred page or something.
Change-Id: Ida81905750371e5e125d0ce7e554d0526265cf8e
Co-Authored-By: Jade Lovelace <lix@jade.fyi>
Signed-off-by: Raito Bezarius <raito@lix.systems>
In case of failure to connect as can be seen in
https://buildbot.lix.systems/#/builders/39/builds/1386/steps/1/logs/stdio
It is difficult to understand what happened, if we enabled the talkative
verbose level, we could learn about the first line SSH sent us.
In practice, this is not workable, we can just make it warn all the
time.
Change-Id: Iaaf56894060a58f2dfc78254bb60b1c43482f9bb
Signed-off-by: Raito Bezarius <raito@lix.systems>
As per our bootstrap governance discussions, here's a very simple
proposal which links as much as possible to our wiki.
Change-Id: I88b1c43f933ff7e529151b1e933fad40283383c4
Signed-off-by: Raito Bezarius <raito@lix.systems>
Once this commit lands, we are even more visible in analytics FWIW.
Change-Id: Id7e0c162315d0f191edbea9cb5fb82ce363704b9
Signed-off-by: Raito Bezarius <raito@lix.systems>
If the state SQLite database is configured to use a write-ahead-log, it
creates WAL files in the state directory.
When the state SQLite database is closed by the `nix-daemon` after
builds, those files are removed.
When an unprivileged user would like to open _in read only_ that
database, they cannot do so because they would need to create those WAL
files and they do not have the permission to do so.
For this, SQLite offers a "persistent WAL" feature [1] to leave the WAL
files around, even after closing the database.
This CL enable the persistent WAL mode.
Fixes: https://github.com/NixOS/nix/issues/10300
[1]: https://www.sqlite.org/wal.html
Change-Id: Id8ae534d7d2290457af28782e5215222ae051fe5
Signed-off-by: Raito Bezarius <raito@lix.systems>
