This is necessary to cleanly and unambiguously transition to using
forgejo issues, since we now control our own destiny.
If we ban unprefixed numbers for a couple of releases, we ensure there
are no releases in active support with the wrong unprefixed number
semantics that could receive backports.
Change-Id: I1c94541dcb3f071399f439870b48cd76557b70d2
* Point `meta.homepage` to the correct location
* Remove `meta.maintainers` field: the folks listed in there maintain
the upstream package. I decided to remove it since we don't use
`meta.maintainers` in this repository to indicate maintainership of a
component.
Change-Id: Iec7b0eb463bc8f41907909e87ec9280c19dc86f5
Under chroot or diverted store setups, the filtering logic of
`builtins.filterSource` and `builtins.path` (which shares the same filtering
logic as `filterSource`) would incorrectly pass physical paths to the
filter function instead of logical store paths.
This caused actual breakage in nixpkgs when the `lib.fileset` library was
introduced. Due to this unresolved bug in Nix, the library was forbidden
from use: <https://github.com/NixOS/nixpkgs/pull/369694>.
To the best of our knowledge, this bug has existed since CppNix 2.3.
The existing tests were strengthened to cover these cases, but
additional testing may be required, particularly regarding symlink
handling.
References: https://github.com/NixOS/nix/pull/12512 (CppNix fix to the
problem using "union" abstractions).
Co-authored-by: Raito Bezarius <raito@lix.systems>
Co-authored-by: Alois Wohlschlager <alois1@gmx-topmail.de>
Co-authored-by: eldritch horrors <pennae@lix.systems>
Signed-off-by: Raito Bezarius <raito@lix.systems>
Change-Id: Iaf6ca8c506eeca145393ce100c64db12178daa62
deletePath checks for interruption, and when interrupted simply exits
without doing anything of note. this may be useful in some instances,
but in the case of a user interrupting a build running on a daemon it
leaves temporary directories sitting around until they are deleted by
the user or by some automated mechanism. we simply shouldn't do this.
note the this means that large build directories now cause the daemon
(and single-user processes) to not be interruptible during cleanup of
cancelled builds. we plan to address this by getting rid of this very
haphazard mechanism once asyncification is completed (hopefully soon)
fixes#678 (again)
Change-Id: Ifff3769620bc9ef7684bc84354aed6c7f932bd87
generators are nice, but they can't be made async. narFromPath will
eventually have to be made async. we just can't win with this stuff
Change-Id: Ia24727893be0001491e232ea27a09cc921b1c935
only RemoteStore and the daemon loop ever call this method, and the
remote store call site isn't even particularly well done. we do not
have to create a bitstream, check whether our remote understands it
at all, only to parse it again if the remote doesn't understand it.
we can instead just use data we already have and avoid many copies.
Change-Id: Ib20740df16555269cbb19c7b12937280a00fc1f0
Let's use similar terminology and formatting to the other entries,
and make it a bit clearer.
The information here is based on the changelog entry from when this
feature was added.
Change-Id: Ia859c710588180ca827c665a70650eb4db5a1c45
This is because C++ exceptions are very tricky, and most notably,
because a catch is run *after* things have been cleaned up, and we don't
*want* them cleaned up if we want usable stack traces.
$ nix nar
Lix crashed. This is a bug. We would appreciate if you report it along with what caused it at https://git.lix.systems/lix-project/lix/issues with the following information included:
Exception: std::runtime_error: lol
Stack trace:
0# nix::getStackTrace[abi:cxx11]() in /home/jade/lix/lix4/outputs/out/lib/liblixutil.so
1# 0x00007D58FC909292 in /home/jade/lix/lix4/outputs/out/lib/liblixmain.so
2# 0x00007D58FC49220A in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
3# 0x00007D58FC492275 in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
4# 0x00007D58FC4924C7 in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
5# 0x00005B9799B45036 in nix
6# 0x00005B9799B3697F in nix
7# 0x00005B9799B3924D in nix
8# nix::handleExceptions(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<void ()>) in /home/jade/lix/lix4/outputs/out/lib/liblixmain.so
9# 0x00005B9799B38D2B in nix
10# 0x00007D58FC1E227E in /nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libc.so.6
11# __libc_start_main in /nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libc.so.6
12# 0x00005B9799A7CF05 in nix
zsh: IOT instruction (core dumped) nix nar
Sadly our symbolizer sucks. But that's, well, improvable. The core dump
is at least much more useful now.
Obviously with async things being full of catch-alls, we have the same
problem. I think we might want to change those in another commit to only
catch nix::BaseError subclasses and let the rest fall into a noexcept
function so it will crash hard.
The daemon also could use this treatment, but I would like to be able to
send the client the crash message in phase 1 unwind. No idea how to
achieve that; all the ways I have seen are heinous.
Fixes: https://git.lix.systems/lix-project/lix/issues/698
Change-Id: I0b61f2e7a7003b92c39b1a0e90756979e5e59cb4
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>
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 is kind of a painful change, because a lot of code grew around the
bad abstraction, but the goal here is to abstract formals in a way that
allows adding other means of pattern matching / argument destructuring
in the future.
Change-Id: If4e681a4be3d1f42ceea81a8e07297f0d08acc80
I'm sorry but checking the name of the function arguments to be "final"
and "prev" is just absurd. That's like worst of
type-checking-meets-static-analysis. And the error message of the second
`throw` was not even good, as it mixed all three failure cases together.
Change-Id: Id4244171123dd8a228be71ce9f04d8e9f647c111
while not copy-assignable it was still copy-constructible, which can
lead to some very unfortunate interactions with closure captures. we
will also need to move current-activity handles in upcoming changes.
Change-Id: I63cede83b9790820c6bd8784fb5d47e5246b7c4a
Jade Lovelace