7 ms·

Removing Guix from Debian

138 points by 6581 1y ago

yjftsjthsd-h 1y ago
> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release. It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
- pxc 1y ago
  It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790 Maybe such changes are more substantial than the typical differences between GCC releases?
  - yjftsjthsd-h 1y ago
    Surely if that's all they would just build with an explicit -std=whatever setting?
    - opello 1y ago
      Looking at the build log in the linked Debian issue, there is an argument setting -std=c++11. It seems as though an implicit inclusion of <cstdint> had been provided by libstdc++ in the past and was removed as of GCC 15. https://github.com/bpftrace/bpftrace/pull/3407 https://github.com/bpftrace/bpftrace/pull/3407 https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176.html https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176... Looks like they did in fact add the header detail to the porting guide: https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-changes https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-change...
      - opello 1y ago
        Just closing some tabs and followed this trail a bit further, it looks like guix fixed the issue too: https://codeberg.org/guix/guix/commit/7b66b41ce5cee48b14eb6cce3bb4b26f5b058652 https://codeberg.org/guix/guix/commit/7b66b41ce5cee48b14eb6c...
      - cozzyd 1y ago
        it would be nice if g++ had an --implicit-includes=[foo,bar] option that would make it easier for a distro to shotgun fix such incompatibilities with CXXFLAGS rather than doing real work.
        yjftsjthsd-h 1y ago
        That seems like kicking the can down the road in a way that's worse in the long run IMHO
        Ashymad 1y ago
        Isn't the --include option basically that?
        cozzyd 1y ago
        Ah, you learn something new everyday, thanks!
        ForOldHack 1y ago
        Isn't that what AI/Vibe coding is for? ( I am kidding a lot)(Ducking thrown paper balls)
  - vincent-manis 1y ago
    I recently custom-built Guile for my Arch system, and found that it won't build with GCC 15, but will with 14, which is the only other version in the Arch repository. I think that the Guile maintainers will need to get busy fixing the incompatibilities in question, before GCC 16 appears.
tucnak 1y ago
It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I say this as a long-term guix user.
- giancarlostoro 1y ago
  > I say this as a long-term guix user. Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
  - zelphirkalt 1y ago
    Not the GP, but: For Guix in general? That's easy to answer: (1) Making things reproducible. That is one of the main reasons. And not only installed system packages. You can also use it to build reproducible projects you develop, if the dependencies are available on Guix. (2) The other one is installing software, that your distribution doesn't have in standard repos.
    - giancarlostoro 1y ago
      So its similar to Nix? I've heard similar of Nix.
      - mikepurvis 1y ago
        Nix and guix ("geeks") are close cousins, and both can be an entire OS or be used just to manage a single workspace/project on another OS. There was a solid piece on here a few weeks ago comparing the two, written by someone with in-depth knowledge of Nix: https://news.ycombinator.com/item?id=44569032 https://news.ycombinator.com/item?id=44569032
  - trelane 1y ago
kwk1 1y ago
I've been meaning to share these results in a more appropriate place, but for what it's worth, the proof-of-concept script for the recent Guix CVEs bisects to a Jan 2023 commit, so it's not clear that released versions are affected. 4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca
Arcuru 1y ago
> According to Debian's popularity contest (popcon) statistics, there are not quite 230 systems with Guix installed.
- JohnFen 1y ago
  But most people using Debian turn popcon off. I don't at all doubt that Guix is not used by most people, but I'm quite certain the number of users is well above 230.
  - cestith 1y ago
    The locales package has over 265k installs in the same recent report that lists 231 copies of guix. That’s less than 0.09% or so.
    - yjftsjthsd-h 1y ago
      By the same virtue, https://qa.debian.org/popcon.php?package=firefox https://qa.debian.org/popcon.php?package=firefox only lists 5749 installs of firefox. I'd take it with a grain of salt.
      - Ologn 1y ago
        It lists 118698 installs of firefox-esr. https://qa.debian.org/popcon.php?package=firefox-esr https://qa.debian.org/popcon.php?package=firefox-esr
        omniglottal 1y ago
        Yes, and these numbers have been established as what we in the industry call "invalid".
      - _ea1k 1y ago
        Firefox-esr seems to be much more common (~118k): https://qa.debian.org/popcon.php?package=firefox-esr https://qa.debian.org/popcon.php?package=firefox-esr
Eduard 1y ago
why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?
- kwk1 1y ago
  It could have been possible to upload something like a 1.4.0+git2025mmdd package, if not for the timing of the CVE announcement with regards to Debian's release freeze.

138 points by 6581 1y ago

> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release. It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.

pxc 1y ago
It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790 Maybe such changes are more substantial than the typical differences between GCC releases?
- yjftsjthsd-h 1y ago
  Surely if that's all they would just build with an explicit -std=whatever setting?
  - opello 1y ago
    Looking at the build log in the linked Debian issue, there is an argument setting -std=c++11. It seems as though an implicit inclusion of <cstdint> had been provided by libstdc++ in the past and was removed as of GCC 15. https://github.com/bpftrace/bpftrace/pull/3407 https://github.com/bpftrace/bpftrace/pull/3407 https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176.html https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176... Looks like they did in fact add the header detail to the porting guide: https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-changes https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-change...
    - opello 1y ago
      Just closing some tabs and followed this trail a bit further, it looks like guix fixed the issue too: https://codeberg.org/guix/guix/commit/7b66b41ce5cee48b14eb6cce3bb4b26f5b058652 https://codeberg.org/guix/guix/commit/7b66b41ce5cee48b14eb6c...
    - cozzyd 1y ago
      it would be nice if g++ had an --implicit-includes=[foo,bar] option that would make it easier for a distro to shotgun fix such incompatibilities with CXXFLAGS rather than doing real work.
      - yjftsjthsd-h 1y ago
        That seems like kicking the can down the road in a way that's worse in the long run IMHO
      - Ashymad 1y ago
        Isn't the --include option basically that?
        cozzyd 1y ago
        Ah, you learn something new everyday, thanks!
      - ForOldHack 1y ago
        Isn't that what AI/Vibe coding is for? ( I am kidding a lot)(Ducking thrown paper balls)
- vincent-manis 1y ago
  I recently custom-built Guile for my Arch system, and found that it won't build with GCC 15, but will with 14, which is the only other version in the Arch repository. I think that the Guile maintainers will need to get busy fixing the incompatibilities in question, before GCC 16 appears.

tucnak 1y ago

It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I say this as a long-term guix user.

giancarlostoro 1y ago
> I say this as a long-term guix user. Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
- zelphirkalt 1y ago
  Not the GP, but: For Guix in general? That's easy to answer: (1) Making things reproducible. That is one of the main reasons. And not only installed system packages. You can also use it to build reproducible projects you develop, if the dependencies are available on Guix. (2) The other one is installing software, that your distribution doesn't have in standard repos.
  - giancarlostoro 1y ago
    So its similar to Nix? I've heard similar of Nix.
    - mikepurvis 1y ago
      Nix and guix ("geeks") are close cousins, and both can be an entire OS or be used just to manage a single workspace/project on another OS. There was a solid piece on here a few weeks ago comparing the two, written by someone with in-depth knowledge of Nix: https://news.ycombinator.com/item?id=44569032 https://news.ycombinator.com/item?id=44569032
- trelane 1y ago

kwk1 1y ago

I've been meaning to share these results in a more appropriate place, but for what it's worth, the proof-of-concept script for the recent Guix CVEs bisects to a Jan 2023 commit, so it's not clear that released versions are affected. 4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca

Arcuru 1y ago

> According to Debian's popularity contest (popcon) statistics, there are not quite 230 systems with Guix installed.

JohnFen 1y ago
But most people using Debian turn popcon off. I don't at all doubt that Guix is not used by most people, but I'm quite certain the number of users is well above 230.
- cestith 1y ago
  The locales package has over 265k installs in the same recent report that lists 231 copies of guix. That’s less than 0.09% or so.
  - yjftsjthsd-h 1y ago
    By the same virtue, https://qa.debian.org/popcon.php?package=firefox https://qa.debian.org/popcon.php?package=firefox only lists 5749 installs of firefox. I'd take it with a grain of salt.
    - Ologn 1y ago
      It lists 118698 installs of firefox-esr. https://qa.debian.org/popcon.php?package=firefox-esr https://qa.debian.org/popcon.php?package=firefox-esr
      - omniglottal 1y ago
        Yes, and these numbers have been established as what we in the industry call "invalid".
    - _ea1k 1y ago
      Firefox-esr seems to be much more common (~118k): https://qa.debian.org/popcon.php?package=firefox-esr https://qa.debian.org/popcon.php?package=firefox-esr

Eduard 1y ago

why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?

kwk1 1y ago
It could have been possible to upload something like a 1.4.0+git2025mmdd package, if not for the timing of the CVE announcement with regards to Debian's release freeze.