| 21 Feb 2025 |
|  alexandi joined the room. | 06:52:57 |
|  @normalcea:matrix.org joined the room. | 16:37:46 |
| 22 Feb 2025 |
|  @selachimorpha:matrix.org changed their display name from selachimorpha to cogitoblood. | 01:36:18 |
| @selachimorpha:matrix.org left the room. | 01:39:48 |
| 24 Feb 2025 |
|  ubalot left the room. | 07:40:55 |
|  Zm94ZGV2 changed their profile picture. | 13:15:52 |
 emily | is it known/expected that pkgsStatic.nixVersions.nix_2_26, pkgsCross.*.nixVersions.nix_2_26, etc., all cause a throw? this seems like another regression of importing the flake packaging into Nixpkgs | 17:44:12 |
 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:
# boost is a public dependency, but not a pkg-config dependency unfortunately, so we
# put in `deps_other`.
why? Boost has .pc files (in Nixpkgs at least), and this breaks e.g. Rust pkg_config parsing the dependencies out of the .pc files
| 18:32:40 |
| emily | * another question:
# boost is a public dependency, but not a pkg-config dependency unfortunately, so we
# put in `deps_other`.
why? Boost has .pc files (in Nixpkgs at least), and this breaks e.g. Rust pkg_config parsing the dependencies out of the Nix .pc files
| 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 |
