 | Nix Hackers | 912 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Nix Hackers | 912 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Feb 2025 | ||
 John Ericson | CC Robert Hensing (roberth) ^ | 18:23:07 |
| John Ericson | I don't think so? | 18:23:10 |
| John Ericson | thanks for pointing out | 18:23:16 |
 emily | another question: why? Boost has | 18:32:40 |
| emily | * another question: why? Boost has | 18:32:44 |
| emily | (fwiw, nixVersions.latest is also not 2.26, although I had been assuming that was intentional while the packaging bakes) | 18:34:59 |
| John Ericson | @emilazy:matrix.org: oh awesome! | 18:35:35 |
| John Ericson | Maybe the PC file was new? | 18:35:50 |
| emily | Nixpkgs bumped its Boost a couple times recently, so that may have been a factor | 18:36:05 |
| emily | (in particular, it breaks it for pkgsStatic, because the resulting .pc file has e.g. Libs: -L${libdir} -lnixstore -pthread /nix/store/2hbky50x3hzky0drn4ay87xj77frq27c-boost-static-x86_64-unknown-linux-musl-1.81.0/lib/libboost_container.a and the pkg_config crate just discards the absolute path, seemingly) | 18:36:34 |
| emily | (that's probably a ~bug-ish on the Rust end, but I think parsing useful semantic information out of .pc files is really hard in general, so it would work better if it's -lboost_container with a Requires/Requires.private) | 18:37:00 |
| John Ericson | Also, if we could make progress on breaking up boost then there are some hacks we can remove | 18:37:07 |
| emily | (which I think Meson would arrange automatically if Boost was consumed via .pc) | 18:37:07 |
| John Ericson | I am very pro pc-file-or-best, don't mind there being a Rust bug ;) | 18:37:24 |
| John Ericson | * I am very pro pc-file-or-best, don't mind there being a Rust bug :) | 18:37:26 |
| emily | I'm happy to review Nixpkgs changes to break up Boost. it should probably just be a bunch of boost-* packages in pkgs/by-name, with a buildBoostComponent builder for each, and a shared src. | 18:37:48 |
| emily | I believe the libraries can basically be built independently and other distros do this. | 18:38:02 |
| emily | we do have multiple Boost versions that complicate things currently, but I've killed off a few of them and I think it would be okay to treat the non-latest ones as legacy versions we don't split up | 18:38:37 |
| John Ericson | oh wow if other derivations do it, then yes it is especially embarrassing! | 18:54:40 |
| emily | this seems to be downstream of the use of generateSplicesForMkScope… as with the rest of the packaging I have no idea what it's being used for or why it's so complicated | 19:37:20 |
| emily | I guess it expects that pkgsFooBar.nixComponents will exist, which it doesn't (despite the # This becomes the pkgs.nixComponents attribute set comment elsewhere) | 19:42:28 |
| emily | I assume that this is another case of the flake packaging making assumptions about / having infrastructure for things that don't apply to nixpkgs | 19:42:44 |
| 25 Feb 2025 | ||
 tobim | building compiled boost libraries independently is easy, but we'd have to fix all the consumers that don't use *.pc files for the compiler args. At least the autoconf macros for boost can't deal with separate prefixes, and I suspect the *.cmake setup installed by boost will also cause quite some trouble. We should get https://github.com/NixOS/nixpkgs/pull/370251 finished (I need to rebase...) which is a step in the right direction. | 10:23:21 |
| emily | yes, I was thinking of your Python PR when you wrote that :) I think we can still maintain compatibility for projects that can't handle a split boost: we can keep an umbrella boost library that just symlinks everything | 13:23:55 |
| emily | that said – given how many other distros split up their Boost packages, are there really that many things that can't handle multiple prefixes? if nothing else I suppose we'll be able to pick patches from other distros? | 13:24:22 |
| tobim | Other distros dodge that problem by using a single global prefix. | 14:05:34 |
| tobim | The PR above already adds a symlink-joined view on a combined boost and boost-python I supposed that pattern can just be extended for the other compiled boost libs as well. We can even assign the boost top-level attribute name to that derivation so client code keeps working. Then we can gradually improve packages that can handle the more fine-grained attributes. | 14:09:58 |
 ElvishJerricco | Gauging interest: https://github.com/ElvishJerricco/nix/commit/46709106ab0dd1898858c236e6078676e1776db3 I think this is the best way to get fsverity enabled for secure boot style stuff: https://github.com/NixOS/nixpkgs/compare/master...ElvishJerricco:nixpkgs:push-pvsmvszsxvkq Wondering if the Nix change would be accepted upstream and what else needs to be done in it. | 16:53:27 |
| 26 Feb 2025 | ||
 ubalot joined the room. | 08:58:34 | |
 p14 | Weird footgun where remote builders silently do not work as expected. https://github.com/NixOS/nix/issues/10451 | 14:22:54 |