lix_2_92: init at 2.92.0 #375030
lix_2_92: init at 2.92.0 #375030
Conversation
RaitoBezarius
force-pushed
the
lix_2_92
branch
from
cdd325c to
cf9b451
Compare
There was a problem hiding this comment.
With Clang being the default/requirement now, it'd probably be a good idea to implement this suggestion from #353576
I think something like the following should work and not affect previous versions. Everything built and tests ran just fine on my end
- (lib.mesonBool "b_lto" (!stdenv.hostPlatform.isStatic && stdenv.cc.isGNU))
+ (lib.mesonBool "b_lto" (!stdenv.hostPlatform.isStatic && (lib.versionAtLeast version "2.92.0" && !stdenv.hostPlatform.isDarwin || stdenv.cc.isGNU)))pkgsLLVM.lix should also be fixed after https://gerrit.lix.systems/c/lix/+/2286 (though I still wasn't able to build it since lix-doc is passing -lgcc_s to the compiler now for some reason, but applying the patch to previous versions worked)
Edit: Seems I have stumbled into a landmine here. The pkgsLLVM failures are apparently caused by an upstream Rust bug that we're currently tracking solutions for in #311930; it's nothing to do with Lix. LTO with only Clang should still be good to go, though
Edit 2: Opened #375267 to flag this in rustc itself. Hopefully no one else will need to come across this unintentionally
Last edit: pkgsLLVM.pkgsMusl.lix works after fixing another include snuck in through glibc. All of LLVM should be fine on Linux
There was a problem hiding this comment.
Awesome work @getchoo!
There was a problem hiding this comment.
Wait, @getchoo — I was definitely able to build with LTO on Darwin, what is happening?
There was a problem hiding this comment.
Ah no, I'm tired, let me check again.
There was a problem hiding this comment.
I was definitely able to build with LTO on Darwin, what is happening?
LTO is currently disabled broadly on Clang due to #337036, which was theorized in #353576 to be the result of potential UB in Darwin or LLVM generally -- and since I've built Lix 2.91 against Clang + libcxx on Linux before, we know it can only be the former
I'm not sure if this still an in issue in 2.92 though, as I haven't built it. In the case it does build (against x86_64-darwin specifically) I'd imagine we're probably in the clear and this condition could be changed to a nicer !stdenv.hostPlatform.isStatic && (lib.versionAtLeast version "2.92.0" || stdenv.cc.isGNU)
|
please hold for a lix 2.92.1, we found a critical bug that somehow we didn't manage to hit until after release |
Is there anywhere we can get more information? |
|
the first bug actually turned out to not affect 2.92.0 but we fixed it. currently blocked on https://git.lix.systems/lix-project/lix/issues/662 |
wegank
added
the
2.status: merge conflict
This is required in the upcoming release of Lix and will benefit the whole ecosystem of editline dependents. It's already merged upstream and pending a final release. Change-Id: I85fcf283494891c28bb05973bacb83030d942a9a Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
This gives a richer editline for dependents in exchange of a ncurses dependency. This effectively makes editline not a replacement _without_ ncurses. This can be re-obtained at the cost of a conditional or a feature flag matrix like the kernel has. Change-Id: Ic28c815171745e0e1fce2ffb6399f70490b7c359 Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
The Lix team will take maintainership on this one as we are critically dependent on the Cap'n'Proto runtime. Change-Id: Iee99f88fa73540ea91a2ba2825fba1e0b8969a07 Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
RaitoBezarius
force-pushed
the
lix_2_92
branch
from
cf9b451 to
857a346
Compare
github-actions
bot
added
the
6.topic: nixos
RaitoBezarius
force-pushed
the
lix_2_92
branch
from
aab3ab2 to
33f0294
Compare
This introduces https://lix.systems/blog/2025-01-18-lix-2.92-release/ in nixpkgs. This new release introduces a bunch of changes at the packaging level, reliant on new features of Meson, new features of some of our dependencies which are done in previous commits (editline & capnproto). The approach taken here is that it's OK to add more dependencies than required for older versions but not OK to break them. Moreover, Lix is now load-bearing dependent on the Clang stdenv, it cannot be compiled with GCC anymore. An escape hatch is included but if this escape hatch is used, the user is on its own and should probably work with GCC upstream to fix miscompilations. Change-Id: I4d51831c10e5d56723240b80fcafc9d951aff279 Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
An installer tests exacerbates the distribution packaging but in the case of NixOS: the Nix package manager implementation. As part of our classical release management process, the Lix team tests whether a NixOS system installs just fine with Lix or not. To avoid bloating the CI needlessly and keeping it simple, we only introduce it on the simple variant and give a general way to pipe a Nix implementation inside of an installer test. Change-Id: I781da14475867dc2d946b740bad10af5de79ec5a Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
RaitoBezarius
force-pushed
the
lix_2_92
branch
from
33f0294 to
f09aabf
Compare
ofborg
bot
removed
the
2.status: merge conflict
This brings the required stuff to package Lix 2.92 in Nixpkgs.
https://lix.systems/blog/2025-01-18-lix-2.92-release/
If you want to review this PR, to make it easier on authors, please get involved in Lix release management and do not mindlessly nixpkgs-review or comment on things you do not necessarily understand.
Lix release management QA list