IRC channel logs

<fossy>stikonas[m]: i might give that a go in a little bit... i'm not sure if that should be global, i have a suspicion that if gcc is compiled with -O0 it'd overall slow it down

<fossy>but that is a good idea for python at least

<fossy>gccs i'll test but i think it might be slower overall

<fossy>guile is mainly guild invocations so i don't think there's an -O0 for that

<mihi>A question that occurred to me, for my fellow Guix like janneke: When next Guix version is released and I install it on a foreign distro, then install a package written in C without using substitutes, will it bootstrap gcc all the way from M2-Planet or will it use the gcc of my host distro? And if the former, will it download the guile seed or will it use my host guile?

<mihi>maybe I should better ask this in #guix...

<janneke>mihi: the former, it will bootstrap everything

<janneke>guix is completely isolated from your foreign distro

<mihi>wow, that was fast, thank you :)

<janneke>hehe ;)

<mihi>so guix itself when run the first time will use my host Guile to download the bootstrap tarball, and then use the Guile inside it to continue?

<mihi>as e.g. https://packages.debian.org/bullseye/guix depends on guile on the host system.

<janneke>it depends on how you install it

<oriansj>mihi: well assuming the behavior is no different than guix with no substitutes now; then it would use the bootstrap guile and run all of the steps

<mihi>janneke, from debian package :)

<oriansj>which for Rust packages takes about a week on an x200

<janneke>mihi: ah right, sure it's built with debian dependencies

<janneke>guess that's a feature :)

<mihi>yeah. I wouldn't mind if it also used host Guile as a driver instead of that binary blob. But I guess when it gets the binary blob with stage0 and guile in it, it will probably use both

<mihi>oriansj, Thinkpad L530 here, plus VirtualBox overhead, which is the reason why I don't want to test it myself :)

<janneke>mihi: note that you'll (most probably) have to run "guix pull" first to get the new full source bootstrap

<mihi>that's why I wrote "when next Guix version is released" (and I meant "and packaged for debian unstable")

<janneke>right...but you don't have to wait for that of course

<janneke>running "guix pull" now is almost just as good

<oriansj>mihi: fair enough. The worst bit is finding the guix packages that no longer build and people using substitutes completely miss that detail.

<mihi>oriansj, I have the impression that even with subsitutes, when living on the Guix bleeding edge, you will encounter packages that won't build (and hence have no substitutes availablilty) for months...

<mihi>in Debian, when a package FTBFS and is not fixed, it gets dropped from the next release...

<janneke>oriansj: a guix package that doesn't build anymore...that's _very_ unlikely to happen

<janneke>if it has substitutes

<mihi>janneke, it happens all the time, search for "time bomb" on the guix-devel mailing list

<janneke>(of course, packages may fail to build when dependencies are upgraded or something)

<mihi>janneke, unfortunately, there are packages that only build with an internet connection. And modern internet is brittle (timestamps, certificates, etc.)

<mihi>even openssl / libressl tests sometimes fail if your system clock is too far "in the future".

<janneke>mihi: guix packages are built in a container without internet

<mihi>janneke, yet OpenSSL still can fail tests (e.g. https://lists.gnu.org/archive/html/guix-devel/2023-04/msg00061.html)

<janneke>mihi: right, but that's not a "happens all the time" imho, that is an exception with a terribly written test

<mihi>also, when I experimented with a childhurd some years ago, I had the impression that building did connect to the Internet. But perhaps that was only on Hurd.

<janneke>kernel or hardware incompatibilities, yeah that could happen

<janneke>but source could should always be available for some time now

<janneke>mihi: that's true

<janneke>the childhurd does not build in a container yet

<janneke>that's a known bug :-(

<janneke>*source code

<oriansj>and one that does need to be fixed (probably by falling back to virtual machines)

<mihi>yeah, I appreciate the work that Guix puts into SWH and Disarchive.

<janneke>oriansj: sure, that needs to be fixed!

<mihi>still, from the scores in the last Disarchive report I read, I would not say "always" available (even 90% is not always)

<oriansj>and unfortunately there are packages which are updated and not tested prior to merging into master and that results in broken package versions that never worked in the first place

<janneke>sure, that's terrible and happens all the time

<oriansj>and can break a system deploy on new systems >.<

<janneke>sure, but there's always roll-back right? ;)

<mihi>janneke, oriansj, for initial install on a new system I'd probably use a released version and not bleeding edge. Yet I'm not sure if that only contains 100% good packages, either.

<oriansj>janneke: not on brand new systems

<mihi>there is a reason that for "other" distros, release freeze is several months.

<oriansj>and guix has no stable branch nor tags that are fully tested.

<janneke>oriansj: right, but nothing was lost then; a first install can always fail?

<janneke>yeah

<mihi>janneke, lost time, lost confidence. When first install of a distro fails for me, I'll use a different distro on that machine.

<oriansj>janneke: welll, it is a serious problem if your computer died and you are trying to get back into an operational state

<mihi>janneke, maybe that is your point. nothing lost yet, better move now than later when it is more painful :)

<janneke>hehe

<oriansj>which is a bit of a concern on x200 systems as they are getting quite old and there are not many respect your freedom certified laptops available.

IRC channel logs

2023-05-06.log