compilation failure against latest lix release-2.91 #12
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Compiling against the latest lix release-2.91 branch currently fails, reproducible using:
Where:
Full build logs here (IPv6 only): https://hydra.shell.bsocat.net/build/22463/nixlog/2
relevant parts
I'm not sure if this is a Lix thing or a hydra thing (and I'm not a C++ person), but I'll see what I can figure out as soon as I find some spoons.
With the 24.11 release being around the corner I understand if this isn't the highest prio, but since this might be an (unintentional) BC breaking change on the Lix side I figured I could at least open an issue.
Ah, it looks like
7c7078cccf
, while making hydra build against lix' main branch, caused build failures against the current stable.I somehow assumed this repo would follow the upstream release model of always building/testing against an already released version of Nix (or in this case Lix).
If keeping the hydra main in sync with the Lix main (which sounds like a good idea since it'd make for a ready-to-use release as soon as Lix releases) is the future, could we have a stable or even release-x.y branches too?
I get that it's more maintenance overhead, but being able to run
nix flake update
without having to manually exclude or pin the hydra repo would be nice as a user.What we'll probably want to do is to branch off for each Lix version as upstream does it. Perhaps even tags?
Thoughts @delroth @raito @yu-re-ka?
Ideally, this should be included in the release engineering of Lix, but there's too much pressure over there in the Lix team, so any help is welcome on what is the cheapest thing we can do that makes end users happy.
@ma27 you have full authority to decide on something reasonable here that doesn't suck up your soul, IMHO. :)
First of all apologies that I didn't respond earlier, there was too much other stuff ongoing. That said, I'd like to assure your that if it'll end up with me taking responsibility here, this will obviously get a higher priority in my personal schedule!
I'm well-aware of that and it was not my intention to push the work onto them.
My suggestion is relatively simple: since Hydra doesn't have a release process and I don't think it's wise to establish one now, we should
release-X.Y
whereX.Y
is the Lix minor this Hydra compiles with.I'd offer to take care of that, two notes:
I intend to only use my write access for maintenance tasks and to push things that are discussed with other stake-holders[2]. I.e. I don't intend to push for e.g. #11 if people are not OK with that. If you ever get the impression that this isn't the case, reach out to me, please!
I am interested in switching to Lix+this Hydra because I'm convinced of Lix being the better option, but I'm not in the position to make that call (and I must say it's kinda hard to tell what we'll end up with in a few months), so it's unclear if that'll happen. I do intend to upstream my changes here as well, however that'll be an effort in my free time.
[1] @raito what's the current lifetime policy of Lix? I.e. is 2.90 dead because 24.05 already has 2.91? If so, I wouldn't bother supporting 2.90 at all and start with 2.91 right away.
[2] I guess @raito, @delroth and @leo60228 can be considered stake-holders. Anyone else?
Oh! Wait you didn't have access to that? I think I am allowed to simply unilaterally give you write access to the secondary Lix projects, so I am going to do so (Raito and co please also do this if you notice similarly responsible people who should simply be given commit access under
trusted-contributors/secondary-committers
in keycloak).AFAIK Lix 2.90 is dead realistically. We do not generally backport very hard unless it is a bug that affects a lot of users or a security bug; though I think 2.90 didn't even get the last trivial security backport. There is not currently a formal release maintenance policy; my current stance is that even old NixOS versions can just have their Lix upgraded to the latest release because they don't break stuff.
Thanks a lot for your trust, that's greatly appreciated!
I prepared a branch locally that I'll push tomorrow (CET) and document it on main in the readme. That should sufficiently cover this issue's scope.
Yes indeed. I guess I'll keep an eye on the latest Lix release only for now then.
EDIT: I forgot to logout and login again, sorry for the ping.
@jade am I holding it wrong?I wanted to push a branch
lix-2.91
now to this repo and I get@ma27 try logging out of forgejo and back in again, that's how to resync your groups from keycloak