IRC channel logs

<rekado>hello there, the bootstrappable.org domain lease is expiring soon and I don't know if I should renew it myself. Would someone like to take over the domain name from me?

<jackdk>It should absolutely be renewed

<fossy>stikonas: gentoo rust has got a fairly significant update (virtual/rust got removed, rust is now slotted) that significantly breaks gentoo rust bootstrap. looks very painful to fix unfortunately :(

<fossy>just fyi

<fossy>i'm sure you have better/more fun things to do than fix that

<sam_>note that it will also make life significantly easier

<sam_>(in particular, but not only, making it very easy for us to have a proper bootstrap chain in ::gentoo)

<fossy>oh i'd agree, just means most of the old ebuilds need to be redone

<fossy>the virtual/rust thing was a pain lol

<sam_>yes definitely

<sam_>we also did agonise over a way to do it incrementally and decided we couldn't in this instance :(

<sam_>one very interesting thing is

<sam_>we also split the binary fetching out of dev-lang/rust, so all binaries are now always in dev-lang/rust-bin

<fossy>oooh okay

<fossy>that is very good

<sam_>this is a good thing for various reasons, but it's also made people aware that the binaries *are* being used, and it's led to a lot of people realising rust is written in rust and not being so happy about it :)

<fossy>:D

<lanodan>I guess a similar *-bin split for dev-lang/ghc could be nice, at least part of me wishes non *-bin packages wouldn't fetch binaries.

<sam_>agreed

<sam_>I would like to see it for ghc too but: a) I'm not involved with haskell (just give armchair advice); b) other priorities once Rust is all sorted (Go next)

<sam_>that said, I did suggest it the other day, and will nudge in that direction

<sam_>there's other nice arguments which help too, as it e.g. means you can simplify the ebuild a lot

<jackdk>nobody knows how to bootstrap ghc, unfortunately

<Googulator>jackdk: bootstrapping is one thing, but we can't even jump the gap from 7.4 to 7.6...

<jackdk>As in building 7.6 from 7.4?

<Googulator>yes - technically 7.4 can build 7.6, but the resulting binary can't recompile itself

<Googulator>7.6 built with 7.4 segfaults when building 7.6

<Googulator>same for 7.8 built with 7.4

<Googulator>or 7.6 built with 7.2

<Googulator>which is why Guix "bootstraps" 4.x from C "sources", propagates the chain up to 7.0 (trivially extendable to 7.4) - and then throws it all away and downloads a binary of 7.8 for building 7.10

<lanodan>Heh beautiful, but well even without bootstrapping having a split it probably worth it

<sam_>yes, it makes the distinction clearer, makes the problem obvious too

<matrix_bridge><Andrius Štikonas> fossy: yeah, I saw it

<matrix_bridge><Andrius Štikonas> Perhaps I can fix it when mrustc switched to 1.74...

<matrix_bridge><Andrius Štikonas> But yes, it should work better afterwards

<lanodan>Also just pure curiosity as I don't use it, but doesn't guix have some kind of policy against binaries?

<Googulator>It has an absolute ban on closed-source binaries, but unbootstrappable open-source binaries are used when there is no alternative

<Googulator>and unfortunately, Haskell is required these days for building a basic desktop environment

<Googulator>because of pandoc mainly

<sam_>i'm not sure i agree with that conclusion

<sam_>none of my very full-featured gentoo desktop systems have it

<sam_>it's also pretty rare for our users to have it installed, anecdotally

<Googulator>It's not part of the final system, but it's required for building tools required for building tools required for ... required for building the final system.

<sam_>certainly isn't here, though

<sam_>it is definitely avoidable and is not some sort of fundamental DE requirement

<lanodan>Well it is pulled by quite a lot of things: https://packages.gentoo.org/packages/virtual/pandoc/reverse-dependencies

<sam_>that list is really not that big

<matrix_bridge><Andrius Štikonas> Yeah, I don't have either GHC or Ruby

<matrix_bridge><Andrius Štikonas> Must be some USE flags that you selected

<sam_>in fact it is so uncommon on our users systems that whenever someone introduces a dep on pandoc, you end up with riots and it ends up fixed quickly ;)

<sam_>now, i am sure you have something which does need it, but it is in no way unavoidable

<matrix_bridge><Andrius Štikonas> Though shellcheck also needs GHC :(

<sam_>:(

<matrix_bridge><Andrius Štikonas> But this is devtool, so normal users can live without it

<lanodan>Well I don't have pandoc, after all I guess I'm part of the anti-pandoc rioters :)

<rekado>Googulator: we don't "throw it all away". I started the build chain from 4.x up to 6 or 7 well after the GHC binaries had been added.

<rekado>I stopped working on it for various reasons and nobody else has continued the work.

<rekado>there is no causal link between stopping the work on building up the chain and using a binary GHC.

<Googulator>I'm referring to my experiments extending the chain - I got 7.2 and 7.4 to build, but anything beyond that segfaults when not built with its own binary.

<Googulator>We have the full development history in Git repository form from that era, but I'm not proficient enough in Scheme to figure out how to build intermediate versions from Git revisions

<Googulator>(hopefully there is a sequence of intermediates that can bridge the gap from 7.4 to 7.6, as opposed to some big-bang commit that depends on its own code)

<jackdk>The one that really makes me sad is that I can't use guix at all if I turn off substituters because openssl 1.1.1l fails in checkPhase due to all the certs having expired and I can't seem to get anyone to care.

<unmush>if you're not using substitutes you could just apply a package transformation that replaces every package with its replacement if it exists ("un-grafting") or modify the check phase to use faketime, it's all going to have to be built from scratch anyway

<stikonas>unmush: yeah, but if some package is known to fail check phase after a certain time, shouldn't it just be officially built without tests

<unmush>my understanding is that there's disagreement on the subject between packagers and upstream

<unmush>on the one hand you have the idea that running the tests is a good way to know that it basically has the proper dependencies, so a dumb time bomb is something to be worked around, and on the other hand if upstream isn't going to bother to make good tests there isn't much point in running them or basing anything on their results

<unmush>IMO upstream should either conditionally disable the date-based tests based on the current time or set the certificate expiration dates at build-time

<stikonas>perhaps, but the thing is that most distros don't fail package if tests fail, it's just a warning

<stikonas>but on Guix it is a hard failure

<stikonas>so it's harder to convince upstream to do something when it is just a one distro

<unmush>yeah, the proper solution for a "reproducibility-first" distro like guix is probably to use faketime, and it's just painful until we identify everywhere that needs to happen

<unmush>I've personally modified quite a few packages in my local repository to use faketime

<jackdk>I agree that these are things that I could do, but it makes me very sad that the package manager/system distribution that has a full source bootstrap makes that bootstrap functionally unusable in general

<fossy_>are tests really unskippable on guix?

<unmush>tests are skippable, the issue is that them being unskippable is a property of the package build, and changing the package build means now that package and everything that depends on it needs to be rebuilt

IRC channel logs

2024-11-18.log