aboutsummaryrefslogtreecommitdiff
path: root/meson.build
AgeCommit message (Collapse)Author
2024-10-09testsuite: add a functional2 test suite based on pytestJade Lovelace
I am tired of bad shell scripts, let me write bad python quickly instead. It's definitely, $100%, better. This is not planned as an immediate replacement of the old test suite, but we::jade would not oppose tests getting ported. What is here is a mere starting point and there is a lot more functionality that we need. Fixes: https://git.lix.systems/lix-project/lix/issues/488 Change-Id: If762efce69030bb667491b263b874c36024bf7b6
2024-10-08Set c++ version to c++23Lulu
I followed @pennae's advice and moved the constructor definition of `AttrName` from the header file `nixexpr.hh` to `nixexpr.cc`. Change-Id: I733f56c25635b366b11ba332ccec38dd7444e793
2024-10-08Fix gcc warning -Wmissing-field-initializersLulu
The approach that was taken here was to add default values to the type definitions rather than specify them whenever they are missing. Now the only remaining warning is '-Wunused-parameter' which @jade said is usually counterproductive and that we can just disable it: https://git.lix.systems/lix-project/lix/issues/456#issuecomment-6617 So this change adds the flags '-Wall', '-Wextra' and '-Wno-unused-parameter', so that all warnings are enabled except for '-Wunused-parameter'. Change-Id: Ic223a964d67ab429e8da804c0721ba5e25d53012
2024-10-08Fix gcc warning -Wsign-compareLulu
Add the compile flag '-Wsign-compare' and adapt the code to fix all cases of this warning. Change-Id: I26b08fa5a03e4ac294daf697d32cf9140d84350d
2024-09-27build: let meson add compiler flags for libstdc++ assertionsOlivia Crain
We have manually enabled libstdc++ assertions since cl/797. Meson 1.4.0 (the minimum version we mandate) enables this by default, so we can remove the enabling compiler flag from the list of project arguments. With this patch, `-D_GLIBCXX_ASSERTIONS=1` is still present in the compile command logs when building with both gccStdenv and clangStdenv. See: https://gerrit.lix.systems/c/lix/+/797 See: https://mesonbuild.com/Release-notes-for-1-4-0.html#ndebug-setting-now-controls-c-stdlib-assertions Change-Id: I53483fadfe5cbd11ba35544b437d3a9ee8031631
2024-09-27build: require meson 1.4.0 or newerOlivia Crain
This was already the de facto requirement, we use the method `full_path` on a file object (introduced in Meson 1.4.0) in the functional test suite's build. This version of Meson is in NixOS 24.05, so there should be no compatibility issues should this make it into a backported release of Lix. CC: https://git.lix.systems/lix-project/lix/issues/247 Change-Id: I5c640824807353b6eb4287e7ed09c4e89a4bdde2
2024-09-27build: fix deprecated uses of configure_fileOlivia Crain
Using `configure_file` to copy files has been deprecated since Meson 0.64.0. The intended replacement is the `fs.copyfile` method. This removes the following deprecation warning that arises when a minimum Meson version is specified: `` Project [...] uses feature deprecated since '0.64.0': copy arg in configure_file. Use fs.copyfile instead `` Change-Id: I09ffc92e96311ef9ed594343a0a16d51e74b114a
2024-09-09forbid gcc for compilation, only allow clangeldritch horrors
while gcc 12 and older miscompile our generators, gcc 13 and older outright crash on kj coroutines. (newer gcc versions may fix this) Change-Id: I19f12c8c147239680eb0fa5a84ef5c7de38c9263
2024-09-08libstore: turn Worker in a kj event loop usereldritch horrors
using a proper event loop basis we no longer have to worry about most of the intricacies of poll(), or platform-dependent replacements for it. we may even be able to use the event loop and its promise system for all of our scheduling in the future. we don't do any real async processing yet, this is just preparation to separate the first such change from the huge api design difference with the async framework we chose (kj from capnp): kj::Promise, unlike std::future, doesn't return exceptions unmangled. it instead wraps any non-kj exception into a kj exception, erasing all type information and preserving mostly the what() string in the process. this makes sense in the capnp rpc use case where unrestricted exception types can't be transferred, and since it moves error handling styles closer to a world we'd actually like there's no harm in doing it only here for now Change-Id: I20f888de74d525fb2db36ca30ebba4bcfe9cc838
2024-08-23build: remove approximately 400 seconds of CPU time (30%)Jade Lovelace
This took parsing time from 1421s or so to 1060s or so. The reason is entirely nlohmann. All of the stuff below is just Obliterated because it's built in the PCH instead: **** Templates that took longest to instantiate: 219051 ms: nlohmann::basic_json<>::parse<const char *> (276 times, avg 793 ms) 169675 ms: nlohmann::basic_json<>::basic_json (1127 times, avg 150 ms) 129416 ms: nlohmann::detail::parser<nlohmann::basic_json<>, nlohmann::detail::i... (276 times, avg 468 ms) 98155 ms: nlohmann::detail::parser<nlohmann::basic_json<>, nlohmann::detail::i... (276 times, avg 355 ms) 81322 ms: nlohmann::basic_json<>::json_value::json_value (1405 times, avg 57 ms) 53531 ms: nlohmann::detail::json_sax_dom_callback_parser<nlohmann::basic_json<... (276 times, avg 193 ms) clang-only. This brings the clang build time to not far from *half* of the gcc build time. Also, clang does not enjoy so much to miscompile coroutines. Maybe we should just be clang-only. Change-Id: Id3135db0094e4560830674090e32e6da2c22fcc6
2024-08-21fix: build with meson 1.5 alsoJade Lovelace
nixpkgs delivered us the untimely gift of a meson 1.5 upgrade, which *does* make our lives easier by allowing us to delete wrap generation code, but it does so at the cost of renaming all rust crates in such a way that the wrap logic cannot tolerate the new names on the old meson version 😭. It also means that support burden for this is going to be atrocious until we either give in and vendor meson 1.5 or we make a CI target for it. Neither seems appealing, though the latter is not super absurd for ensuring we don't break nixpkgs unstable. This commit causes meson 1.5 to ignore the .wrap files in subprojects/ entirely (since they have the wrong names lol) and instead use Cargo.lock, so it now hard-depends on our workspace reshuffling improvement. It also deletes the hack that we were using to get the sources of Cargo deps into meson by using a feature that went unnoticed when this code was originally written: MESON_PACKAGE_CACHE_DIR: https://github.com/mesonbuild/meson/blob/8a202de6ec763284cbb7160b9d43d5e7e0703f19/mesonbuild/wrap/wrap.py#L490-L502 Change-Id: I7a28f12fc2812c6ed7537b60bc3025c141a05874
2024-08-21build: move to a Cargo workspaceJade Lovelace
This is purely to let Cargo's dependency resolver do stuff for us, we do not actually intend to build this stuff with Cargo to begin with. Change-Id: I4c08d55595c7c27b7096375022581e1e34308a87
2024-08-20lix-doc: move under src/Jade Lovelace
This is required to make more meson stuff easier/possible, and honestly it *is* now Lix sources anyhow. Change-Id: Ia6c38fabce9aa5c53768745ee38c5cf344f5c226
2024-08-20build: build lix-doc with Meson! 🎉Qyriad
lix-doc is now built with Meson, with lix-doc's dependencies built as Meson subprojects, either fetched on demand with .wrap files, or fetched in advance by Nix with importCargoLock. It even builds statically. Fixes #256. Co-authored-by: Lunaphied <lunaphied@lunaphied.me> Co-authored-by: Jade Lovelace <lix@jade.fyi> Change-Id: I3a4731ff13278e7117e0316bc0d7169e85f5eb0c
2024-08-16meson: Don't use `target_machine`Artemis Tosini
The target_machine variable is meant for the target of cross compilers. We are not a cross compiler, so instead reuse our host_machine based checks. Fixes Linux→FreeBSD cross, since Meson can't figure out `target_machine.kernel()` in that case. Fixes: https://git.lix.systems/lix-project/lix/issues/469 Change-Id: Ia46a64c8d507c3b08987a1de1eda171ff5e50df4
2024-08-10libutil: deal with Linux systems that do not implement close_rangeJade Lovelace
Seems a little bit Rich that musl does not implement close_range because they suspect that the system call itself is a bad idea, so they uhhhh are considering not implementing a wrapper. Let's just fix the problem at hand by writing our own wrapper. Change-Id: I1f8e5858e4561d58a5450503d9c4585aded2b216
2024-08-07build: declare all the deps as -isystemJade Lovelace
I don't know why but I was getting a spurious -Werror=switch-enum inside toml11. It does not make sense why it did not occur before, but it should be stopped. This was not done at an earlier stage to better match the legacy make build system, but we don't use it anyway. Change-Id: I636f8a71e8a0ba5e0feb80b435ae24c3af995c5d
2024-08-04build: implement clang-tidy using our pluginJade Lovelace
The principle of this is that you can either externally build it with Nix (actual implementation will be in a future commit), or it can be built with meson if the Nix one is not passed in. The idea I have is that dev shells don't receive the one from Nix to avoid having to build it, but CI can use the one from Nix and save some gratuitous rebuilds. The design of this is that you can run `ninja -C build clang-tidy` and it will simply correctly clang-tidy the codebase in spite of PCH bullshit caused by the cc-wrapper. This is a truly horrendous number of hacks in a ball, caused by bugs in several pieces of software, and I am not even getting started. I don't consider this to fix the clang-tidy issue filing, since we still have a fair number of issues to fix even on the existing minimal configuration, and I have not yet implemented it in CI. Realistically we will need to do something like https://github.com/Ericsson/codechecker to be able to silence warnings without physically touching the code, or at least *diff* reports between versions. Also, the run-clang-tidy output design is rather atrocious and must not be inflicted upon anyone I have respect for, since it buries the diagnostics in a pile of invocation logs. We would do really well to integrate with the Gerrit SARIF stuff so we can dump the reports on people in a user-friendly manner. Related: https://git.lix.systems/lix-project/lix/issues/147 Change-Id: Ifefe533f3b56874795de231667046b2da6ff2461
2024-07-31tree-wide: add support for asan!Jade Lovelace
What if you could find memory bugs in Lix without really trying very hard? I've had variously scuffed patches to do this, but this is blocked on boost coroutines removal at this point tbh. Change-Id: Id762af076aa06ad51e77a6c17ed10275929ed578
2024-07-23libstore: Add FreeBSD findPlatformRootsArtemis Tosini
Use libprocstat to find garbage collector roots on FreeBSD. Tested working on a FreeBSD machine, although there is no CI yet Change-Id: Id36bac8c3de6cc4de94e2d76e9663dd4b76068a9
2024-07-22enable -Werror=suggest-overrideeldritch horrors
*accidentally* overriding a function is almost guaranteed to be an error. overriding a function without labeling it as such is merely bad style, but bad style that makes the code harder to understand. Change-Id: Ic0594f3d1604ab6b3c1a75cb5facc246effe45f0
2024-07-16remove boost coroutine referenceseldritch horrors
we no longer need these since sinkToSource and sourceToSink are gone. Change-Id: Ibbf440e2cf71bf3e9f3b833af2d78a21fb1b3193
2024-07-03libutil: generator type with on-yield value mappingeldritch horrors
this will be the basis of non-boost coroutines in lix. anything that is a boost coroutine *should* be representable with a Generator coroutine, and many things that are not currently boost coroutines but behave much like one (such as, notably, serializers) should be as well. this allows us to greatly simplify many things that look like iteration but aren't. Change-Id: I2cebcefa0148b631fb30df4c8cfa92167a407e34
2024-06-30enable -Werror=unused-resulteldritch horrors
we do not have any of these warnings appearing at the moment, but it seems like a good idea to enable [[nodiscard]] checking anyway. once we start introducing more functions with must-use conditions we will need such checking, and the rust stdlib has proven them very useful. Change-Id: Ibb6b042ae1ec5f527f8dc2809a7816a4c1548ae2
2024-06-25libexpr: rewrite the parser with pegtl instead of flex/bisoneldritch horrors
this gives about 20% performance improvements on pure parsing. obviously it will be less on full eval, but depending on how much parsing is to be done (e.g. including hackage-packages.nix or not) it's more like 4%-10%. this has been tested (with thousands of core hours of fuzzing) to ensure that the ASTs produced by the new parser are exactly the same as the old one would have produced. error messages will change (sometimes by a lot) and are not yet perfect, but we would rather leave this as is for later. test results for running only the parser (excluding the variable binding code) in a tight loop with inputs and parameters as given are promising: - 40% faster on lix's package.nix at 10000 iterations - 1.3% faster on nixpkgs all-packages.nix at 1000 iterations - equivalent on all of nixpkgs concatenated at 100 iterations (excluding invalid files, each file surrounded with parens) more realistic benchmarks are somewhere in between the extremes, parsing once again getting the largest uplift. other realistic workloads improve by a few percentage points as well, notably system builds are 4% faster. Benchmarks summary (from ./bench/summarize.jq bench/bench-*.json) old/bin/nix --extra-experimental-features 'nix-command flakes' eval -f bench/nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix mean: 0.408s ± 0.025s user: 0.355s | system: 0.033s median: 0.389s range: 0.388s ... 0.442s relative: 1 new/bin/nix --extra-experimental-features 'nix-command flakes' eval -f bench/nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix mean: 0.332s ± 0.024s user: 0.279s | system: 0.033s median: 0.314s range: 0.313s ... 0.361s relative: 0.814 --- old/bin/nix --extra-experimental-features 'nix-command flakes' eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system' mean: 6.133s ± 0.022s user: 5.395s | system: 0.437s median: 6.128s range: 6.099s ... 6.183s relative: 1 new/bin/nix --extra-experimental-features 'nix-command flakes' eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system' mean: 5.925s ± 0.025s user: 5.176s | system: 0.456s median: 5.934s range: 5.861s ... 5.943s relative: 0.966 --- GC_INITIAL_HEAP_SIZE=10g old/bin/nix eval --extra-experimental-features 'nix-command flakes' --raw --impure --expr 'with import <nixpkgs/nixos> {}; system' mean: 4.503s ± 0.027s user: 3.731s | system: 0.547s median: 4.499s range: 4.478s ... 4.541s relative: 1 GC_INITIAL_HEAP_SIZE=10g new/bin/nix eval --extra-experimental-features 'nix-command flakes' --raw --impure --expr 'with import <nixpkgs/nixos> {}; system' mean: 4.285s ± 0.031s user: 3.504s | system: 0.571s median: 4.281s range: 4.221s ... 4.328s relative: 0.951 --- old/bin/nix --extra-experimental-features 'nix-command flakes' search --no-eval-cache github:nixos/nixpkgs/e1fa12d4f6c6fe19ccb59cac54b5b3f25e160870 hello mean: 16.475s ± 0.07s user: 14.088s | system: 1.572s median: 16.495s range: 16.351s ... 16.536s relative: 1 new/bin/nix --extra-experimental-features 'nix-command flakes' search --no-eval-cache github:nixos/nixpkgs/e1fa12d4f6c6fe19ccb59cac54b5b3f25e160870 hello mean: 15.973s ± 0.013s user: 13.558s | system: 1.615s median: 15.973s range: 15.946s ... 15.99s relative: 0.97 --- Change-Id: Ie66ec2d045dec964632c6541e25f8f0797319ee2
2024-06-18build: make UBSan work :)Jade Lovelace
This is really just a question of turning off the production sanitizer configuration so we get nice diagnostics. Not much else to say. Change-Id: I76bd6d225320056ed95bd89955f00beff2db0d2f
2024-06-18s3: delete obsolete ifdefsJade Lovelace
The versions checked for are so old that we can just drop support. Change-Id: Ib9cf136d1cb9a4a91a6613102c4fd15e1190363b
2024-06-16meson.build: Allow undefined symbols on FreeBSDArtemis Tosini
The linker cannot find environ while linking libutil. Fix build by allowing undefined symbols Change-Id: Iba319126284d48454b50db40d3aadf37e0339668
2024-06-12[resubmit] flake: update nixpkgs pin 23.11->24.05 (+ boehmgc compat changes)Pierre Bourdon
-- message from cl/1418 -- The boehmgc changes are bundled into this commit because doing otherwise would require an annoying dance of "adding compatibility for < 8.2.6 and >= 8.2.6" then updating the pin then removing the (now unneeded) compatibility. It doesn't seem worth the trouble to me given the low complexity of said changes. Rebased coroutine-sp-fallback.diff patch taken from https://github.com/NixOS/nixpkgs/pull/317227 -- jade resubmit changes -- This is a resubmission of https://gerrit.lix.systems/c/lix/+/1418, which was reverted in https://gerrit.lix.systems/c/lix/+/1432 for breaking CI evaluation without being detected. I have run `nix flake check -Lv` on this one before submission and it passes on my machine and crucially without eval errors, so the CI result should be accurate. It seems like someone renamed forbiddenDependenciesRegex to forbiddenDependenciesRegexes in nixpkgs and also changed the type incompatibly. That's pretty silly, but at least it's just an eval error. Also, `xonsh` regressed the availability of `xonsh-unwrapped`, but it was fixed by us in https://github.com/NixOS/nixpkgs/pull/317636, which is now in our channel, so we update nixpkgs compared to the original iteration of this to simply get that. We originally had a regression related to some reorganization of the nixpkgs lib test suite in which there was broken parameter passing. This, too, we got quickfixed in nixpkgs, so we don't need any changes for it: https://github.com/NixOS/nixpkgs/pull/317772 Related: https://gerrit.lix.systems/c/lix/+/1428 Fixes: https://git.lix.systems/lix-project/lix/issues/385 Change-Id: I26d41ea826fec900ebcad0f82a727feb6bcd28f3
2024-06-12build: remove unused 'deps' variableQyriad
This never actually got used Change-Id: I8f3f1d413124b27913d59a75cff42319cbaac385
2024-06-10Revert "flake: update nixpkgs pin 23.11->24.05 (+ boehmgc compat changes)"jade
This reverts commit 28a079f841834ac11105ce5762115904d1e40ce1. Reason for revert: This caused a pile of regressions in CI, and does not pass nix flake check. Some number of them are fixed in CL: https://gerrit.lix.systems/c/lix/+/1429 but there's more to be fixed. We should defer this after 2.90. Change-Id: Ib839d0fcb08eb52094af2b521145e3c1b4e0556f
2024-06-09flake: update nixpkgs pin 23.11->24.05 (+ boehmgc compat changes)Pierre Bourdon
The boehmgc changes are bundled into this commit because doing otherwise would require an annoying dance of "adding compatibility for < 8.2.6 and >= 8.2.6" then updating the pin then removing the (now unneeded) compatibility. It doesn't seem worth the trouble to me given the low complexity of said changes. Rebased coroutine-sp-fallback.diff patch taken from https://github.com/NixOS/nixpkgs/pull/317227 Change-Id: I8c590e9fe25c0f566d0cfeacb96d8cf50abf12e8
2024-06-07Merge changes from topic "releng" into mainjade
* changes: Add meson release note Move version to a JSON file so we can have release names Remove rl-next-dev
2024-06-06Move version to a JSON file so we can have release namesJade Lovelace
Change-Id: I5ff3396a302565ee5ee6c2db97e048e403779076
2024-06-06build: expose option to enable or disable precompiled std headersQyriad
They are enabled by default, and Meson will also prints whether or not they're enabled at the bottom at the end of configuration. Change-Id: I48db238510bf9e74340b86f243f4bbe360794281
2024-05-31build: fix static linking with a hackQyriad
This causes libstore, libexpr, libfetchers, and libutil to be linked with -Wl,--whole-archive to executables, when building statically. libstore for the store backends, libexpr for the primops, libfetchers for the fetcher backends I assume(?), and libutil for the nix::logger initializer (which notably shows in pre-main constructors when HOME is not owned by the user. cursed.). This workaround should be removed when #359 is fixed. Fixes #306. Change-Id: Ie9ef0154e09a6ed97920ee8ab23810ca5e2de84c
2024-05-30build: fix static aws-cpp-sdkQyriad
Change-Id: I310830951106f194f6960a6b2d52b5081a7f6156
2024-05-24libstore/build: always enable seccomp filtering and no-new-privilegesAlois Wohlschlager
Seccomp filtering and the no-new-privileges functionality improve the security of the sandbox, and have been enabled by default for a long time. In https://git.lix.systems/lix-project/lix/issues/265 it was decided that they should be enabled unconditionally. Accordingly, remove the allow-new-privileges (which had weird behavior anyway) and filter-syscall settings, and force the security features on. Syscall filtering can still be enabled at build time to support building on architectures libseccomp doesn't support. Change-Id: Iedbfa18d720ae557dee07a24f69b2520f30119cb
2024-05-23packaging: rename nixexpr -> lixexpr and so onJade Lovelace
This breaks downstreams linking to us on purpose to make sure that if someone is linking to Lix they're doing it on purpose and crucially not mixing up Nix and Lix versions in compatibility code. We still need to fix the internal includes to follow the same schema so we can drop the single-level include system entirely. However, this requires a little more effort. This adds pkg-config for libfetchers and config.h. Migration path: expr.hh -> lix/libexpr/expr.hh nix/config.h -> lix/config.h To apply this migration automatically, remove all `<nix/>` from includes, so: `#include <nix/expr.hh>` -> `#include <expr.hh>`. Then, the correct paths will be resolved from the tangled mess, and the clang-tidy automated fix will work. Then run the following for out of tree projects: ``` lix_root=$HOME/lix (cd $lix_root/clang-tidy && nix develop -c 'meson setup build && ninja -C build') run-clang-tidy -checks='-*,lix-fixincludes' -load=$lix_root/clang-tidy/build/liblix-clang-tidy.so -p build/ -fix src ``` Related: https://git.lix.systems/lix-project/nix-eval-jobs/pulls/5 Fixes: https://git.lix.systems/lix-project/lix/issues/279 Change-Id: I7498e903afa6850a731ef8ce77a70da6b2b46966
2024-05-09add and fix -Wignored-qualifiersQyriad
Change-Id: I4bffa766ae04dd80355f9b8c10e59700e4b406da
2024-05-09add and fix -Wdeprecated-copyQyriad
*so* many warnings, from only two definitions Change-Id: If2561cd500c05a1e33cce984faf9f3e42a8a95ac
2024-05-05meson: install org.nixos.nix-daemon.plist on macOSQyriad
Change-Id: I70079a553ec355be944f9940258f9abf861759fc
2024-05-03libstore/local-derivation-goal: prohibit creating setuid/setgid binariesMaximilian Bosch
With Linux kernel >=6.6 & glibc 2.39 a `fchmodat2(2)` is available that isn't filtered away by the libseccomp sandbox. Being able to use this to bypass that restriction has surprising results for some builds such as lxc[1]: > With kernel ≥6.6 and glibc 2.39, lxc's install phase uses fchmodat2, > which slips through https://github.com/NixOS/nix/blob/9b88e5284608116b7db0dbd3d5dd7a33b90d52d7/src/libstore/build/local-derivation-goal.cc#L1650-L1663. > The fixupPhase then uses fchmodat, which fails. > With older kernel or glibc, setting the suid bit fails in the > install phase, which is not treated as fatal, and then the > fixup phase does not try to set it again. Please note that there are still ways to bypass this sandbox[2] and this is mostly a fix for the breaking builds. This change works by creating a syscall filter for the `fchmodat2` syscall (number 452 on most systems). The problem is that glibc 2.39 is needed to have the correct syscall number available via `__NR_fchmodat2` / `__SNR_fchmodat2`, but this flake is still on nixpkgs 23.11. To have this change everywhere and not dependent on the glibc this package is built against, I added a header "fchmodat2-compat.hh" that sets the syscall number based on the architecture. On most platforms its 452 according to glibc with a few exceptions: $ rg --pcre2 'define __NR_fchmodat2 (?!452)' sysdeps/unix/sysv/linux/x86_64/x32/arch-syscall.h 58:#define __NR_fchmodat2 1073742276 sysdeps/unix/sysv/linux/mips/mips64/n32/arch-syscall.h 67:#define __NR_fchmodat2 6452 sysdeps/unix/sysv/linux/mips/mips64/n64/arch-syscall.h 62:#define __NR_fchmodat2 5452 sysdeps/unix/sysv/linux/mips/mips32/arch-syscall.h 70:#define __NR_fchmodat2 4452 sysdeps/unix/sysv/linux/alpha/arch-syscall.h 59:#define __NR_fchmodat2 562 I added a small regression-test to the setuid integration-test that attempts to set the suid bit on a file using the fchmodat2 syscall. I confirmed that the test fails without the change in local-derivation-goal. Additionally, we require libseccomp 2.5.5 or greater now: as it turns out, libseccomp maintains an internal syscall table and validates each rule against it. This means that when using libseccomp 2.5.4 or older, one may pass `452` as syscall number against it, but since it doesn't exist in the internal structure, `libseccomp` will refuse to create a filter for that. This happens with nixpkgs-23.11, i.e. on stable NixOS and when building Lix against the project's flake. To work around that * a backport of libseccomp 2.5.5 on upstream nixpkgs has been scheduled[3]. * the package now uses libseccomp 2.5.5 on its own already. This is to provide a quick fix since the correct fix for 23.11 is still a staging cycle away. We still need the compat header though since `SCMP_SYS(fchmodat2)` internally transforms this into `__SNR_fchmodat2` which points to `__NR_fchmodat2` from glibc 2.39, so it wouldn't build on glibc 2.38. The updated syscall table from libseccomp 2.5.5 is NOT used for that step, but used later, so we need both, our compat header and their syscall table 🤷 Relevant PRs in CppNix: * https://github.com/NixOS/nix/pull/10591 * https://github.com/NixOS/nix/pull/10501 [1] https://github.com/NixOS/nixpkgs/issues/300635#issuecomment-2031073804 [2] https://github.com/NixOS/nixpkgs/issues/300635#issuecomment-2030844251 [3] https://github.com/NixOS/nixpkgs/pull/306070 (cherry picked from commit ba6804518772e6afb403dd55478365d4b863c854) Change-Id: I6921ab5a363188c6bff617750d00bb517276b7fe
2024-04-22meson: fix cross compilationQyriad
This should fix cross compilation in the base case, but this is difficult to test as cross compilation is broken in many different places right now. This should bring Meson back up to cross parity with the Make buildsystem though. Change-Id: If09be8142d1fc975a82b994143ff35be1297dad8
2024-04-18meson: correctly embed sandbox shell when askedQyriad
Change-Id: I2f6c0d42245204a516d2e424eea26a6391e975ad
2024-04-18meson: embed source paths as relative to the source root and avoid ../srcQyriad
Change-Id: Ifab83cb7a3bfde717a4d6032ede8be75dc61f2b1
2024-04-17Merge "build internal API docs with Meson" into mainQyriad
2024-04-15build internal API docs with MesonQyriad
This commit adds the capability for building the Doxygen internal API docs in the Meson buildsystem, and also makes doing so the default for the internal-api-docs hydra job. Aside from the /nix-support directory, which differed only by the hash part of a store path, the outputs of hydraJobs.internal-api-docs before and after this commit were bit-for-bit identical on my machine. Change-Id: I98f0017891c25b06866c15f7652fe74f706ec8e1
2024-04-11docs: redo content generation for mdbook and manualeldritch horrors
manpages can be rendered using the markdown output of mdbook, the rest of the manual can generated out of the main doc/manual source tree. we still use lowdown to actually render manpages instead of eg mdbook-man because lowdown does generate reasonably good manpages (though that is also somewhat debatable, but they're a lot better than mdbook-man). doing this not only lets us drastically simplify the lowdown pipeline, but also remove all custom {{#include}} handling since now mdbook does all of it, even for the manpage builds. even the lowdown wrapper isn't entirely necessary because lowdown can take all wrapper arguments with command line flags rather than bits of input file content. This also implements running mdbook in Meson, in order to generate the manpages. The mdbook outputs are also installed in the usual location. Co-authored-by: Qyriad <qyriad@qyriad.me> Change-Id: I60193f9fd0f15d48872f071af35855cda2a0f40b
2024-04-09meson: correctly differentiate $profiledir and $sysconfdir/profile.dQyriad
The configured sysconfdir is used to look for nix.conf, so it needs to be /etc, and not $out/etc, so we separate out the place where shell profile files are installed, which is the only other place sysconfdir is at all used. See https://git.lix.systems/lix-project/lix/issues/231#issuecomment-1989 for more info. Change-Id: Idbed8ba82e711b8a9d6b6127904befa27d58e279