Dear maintainer,

I suggest removing guix from Debian for the following reasons:
 * It accumulated 3 RC-bugs:
   + #1096790: guix: ftbfs with GCC-15
     Last modified: 1 year, 14 days

   + #1108318: guix: CVE-2025-46415 CVE-2025-46416 CVE-2025-52991 CVE-2025-52992 CVE-2025-52993
     Last modified: 1 year, 28 days

   + #1112143: security updates impractical due to rolling release model
     Last modified: 1 year, 22 days

 * It is not part of trixie or forky and is not a key package.

This bug serves as a pre-removal warning. After one month, the bug will be
reassigned to ftp.debian.org to actually request removal of the package.

In case the package should be kept in unstable, please evaluate each of the
RC-bugs listed above.
 * If the bug is meant to permanently prevent the package from entering testing
   or a stable release, but this package should stay part of unstable, please
   add a usertag:

       user helmutg@debian.org
       usertags NNN + sidremove-ignore

 * If the bug no longer applies, please close it. If it is closed, check
   whether the fixed version is correct and adjust if necessary.

 * Is the bug really release-critical? If not, please downgrade.

 * If the bug still applies, please send a status update at least once a year.

Once all of the mentioned RC bugs have been acted upon in one way or another,
please close this bug.

In case the package should be removed from unstable, you may reassign this
bug report:

    Control: severity -1 normal
    Control: retitle -1 RM: guix -- RoM; rc-buggy
    Control: reassign -1 ftp.debian.org
    Control: affects -1 + src:guix

Alternatively, you may wait a month and have it reassigned.

In case you disagree with the above, please add a wontfix tag to this bug.

    Control: tags -1 + wontfix

Doing so will also prevent automatic reassignment.

Kind regards

A tool for automatically removing packages from unstable

This bug report has been automatically filed with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne <helmut@subdivi.de> for assistance.

Hi,

I've written the previous mail several days ago but it didn't reach
debbugs so I've re-sent it as-is.

Since that time several things happened:

- I managed to backport patches on top of Guix 1.5.0.

They are in the guix-1.5.0-backports branch in
https://git.sr.ht/~gnutoo/guix.

- The process to make the new Guix 1.6.0 release has started. In one
  way it's good news but I also need Guix to accept my backported
  patches so I hope that this doesn't interfer with that.

I've also prepared patches for the Guix manual in the
guix-1.5.0-backports-docs branch but I've not yet sent them yet either
as I'm waiting for Tanguy to contact people.

Denis.

Hi,

I am very biased here:

* I am part of a Guix team (similar to a Debian Developer for Guix).
  Also note that Guix is very big and that I'm not that well connected
  yet in it.

* I contributed to the Trisquel (a downstream of Debian) guix package,
  helping backport security fixes.

* I also maintain the Parabola (a downstream of Arch Linux) guix
  package.

And I do have very strong interest in keeping Guix packaged somewhere
because I co-maintain GNU Boot and we badly need Guix to be packaged in
more than 1 100% free GNU/Linux distribution.

So I need guix to be kept in Trisquel. I heard that some people need
guix to be kept in Ubuntu, but we also need to contact them.

But I also do understand that things aren't magic, and that Debian has
strong requirements for extremely good reasons and that the problem
here is in Guix not in Debian: Guix should backport security fixes and
at the time of the package removal in Debian, I could not get people to
commit to do that in Guix.

And given what happened at that time in Guix, I'm realist and I don't
think it is feasible to have Guix backport security fixes in older
releases (like Guix 1.4.0 when Guix 1.5.0 is the latest release), and
that doesn't work with Debian because Debian isn't a rolling release
distribution.

So I made a new plan for rolling release distributions and other
distributions (below) and I'm still gathering support right now, but I
would need an upstream for the "Debian" package (see below why).

Why is Debian even relevant here?
---------------------------------

I've managed to confirm that it's possible to technically make Trisquel
pull the guix package from Debian unstable.

And since I want to keep Guix in Trisquel, and I need an upstream
for the Debian package. And it would also be good to be able to
collaborate with people that want guix in Ubuntu on that.

So instead of simply deleting the package, would it be possible to
instead move it to some other repository like the fasttrack
repository[2] or somewhere that can be pulled by Trisquel and ideally
Ubuntu as well?

Also note that I've no idea if it's possible to pull from fasttrack in
Trisquel as this has different keyrings (I'd need to look into it).

While I previously collaborated with the Trisquel maintainer to fix
guix CVEs, I also need to get him on board with this plan, and so far I
didn't contact him yet.

My new plan for Guix for rolling release distributions.
-------------------------------------------------------

Since mid September I've started to work on all that again and I
instead of just backporting the security fix(es) like last time[3] and
doing a bad job at convincing people, I instead spent more time to make
a better plan than the last and started trying to convince people to get
onboard with that plan.

The idea would be that:

- Guix would create a team that manages the backporting of patches
  and potentially other critical fixes (like if guix packages are 100%
  broken due to substitute server URL changes or similar).

- The members of this new team would not commit to backport any
  patches. Instead they would commit to review patches sent
  to this team.

  And anybody (including members of that team) would be welcome to
  backport patches and send them to that team for review.

  And people like me who maintain a guix package (in Parabola) would
  then be able to get proper reviews, to get the code merged in a new
  branch (like 1.5.1) and to get the release team do a proper release
  with the security fix applied.

- I would also write text that makes it clear that we we are looking
  for volunteers to backport CVEs to make this become sustainable. This
  text could go in release notes, in the team description, etc.

- Have Guix commit to keep Guix working on the latest Guile release.
  This means that any Guix revision more recent than the latest release
  is supposed to not break on top of the latest release of Guile.

Since Guix was removed from Debian, Guix also committed to make more
regular releases as per GCD 005[1], so here I hope that releases will
be more regular than before, and that there would be less to
backport and to review, even if Guix is late as per the schedule in [1].

Timeline
--------

In practice it means the following:

* First I would backport the fix on top of 1.5.0. Nothing would be set
  in motion before that, as I personally think that having a patch to
  review makes everything easier.

* Then Tanguy who is the treasurer of Guix told me he could manage to
  convince people that do releases to do a 1.5.1.

* In Guix we try to implement this process described above: create a
  team, etc along the way.

Note that here I'm writing that mail as we also need to get involved
with Debian in some way and that Vagrant Cascadian pointed me to this
bug report (he also pointed me to the fasttrack repository).

Also note that I am a complete beginner with Debian packaging: I managed
to create (Debian) packages from scratch for my personal use and for the
GNU Boot manual.

But for instance I've no idea how, as an external contributor, how to
make https://salsa.debian.org/debian/guix.git have the guix 1.5.0
revision (there is probably a process for that as the source
probably needs to be authenticated somehow).

This is also a good reason to offset as much work as possible in
Guix, but for good reasons Guix cannot have a debian/ directory in
Guix[4], so we still need some upstream for the Debian package (for
Trisquel, Ubuntu, etc).

And we also need the package to be built in a repository (like
fasttrack or unstable) to be able to get it from Trisquel.

References:
-----------
[1]https://codeberg.org/guix/guix-consensus-documents/raw/branch/main/005-regular-releases.md
[2]https://fasttrack.debian.net/
[3]A bit before Debian removed Guix, I managed to backport all the
   security fixes on top of 1.4.0 in a quick and dirty way. The tests
   didn't pass anymore. Since we need both the proper structure AND the
   fixes, I'm trying another approach.
[4]https://wiki.debian.org/action/show/UpstreamGuide#Do_not_include_a_.2Fdebian_directory

Denis.

Hi Denis,

I contacted the release team working on the next release. Actually, I **joined** the team! 😅

I’ll be pushing the idea of having a 1.5.1 and keep you posted…

At this point, getting a 1.5.1 would be nice, but it might also be worth
aiming for some git snapshots as 1.6.0 is targeted for december, if
there is any chance of getting Guix back into Debian Testing (and
eventually Debian Stable?)... while keeping in mind for post 1.6.0 what
would be needed to make 1.6.1 possible (at least from the perspective of
keeping Guix in Debian, although I think it would also make snse for
Guix's own upstream releases).

Or we can work on 1.5.x in unstable, and 1.6.x snapshots in experimental
for the time being...

I think the problem I had getting 1.5.0 ready was maybe issues with
apparmor profiles blocking guix-daemon from starting...

live well,
  vagrant

On Sun, 04 Oct 2026 21:44:00 +0200 "Tanguy Le Carrour" <tanguy@bioneland.org> wrote:
Thanks a lot.

The problem I have here is that 1.6.0 will not ship with security
vulnerabilities (which is obviously a good thing), so if we wait for
1.6.0, then there will probably be much less interest in having a
process to backport security fixes in Guix, and we would
have nothing real to test the process with, so communication would be
harder in Guix (how can people commit to something they can't see), we
won't be able to tune the process along the way, and finally
distributions will not be able to see it working for real to draw
conclusions (how to know what you can really rely on if you can not
observe it).

I fixed that in the Parabola and Trisquel packages. The most
interesting one is Trisquel, as it is based on Ubuntu, which made
Apparmor stricter on some areas.

The patches for that are in the ecne branch in
https://gitlab.trisquel.org/trisquel/package-helpers.git/ in
helpers/DATA/guix/apparmor.

A valid question here would be if these are fit for backporting. I
personally think they would because the Guix daemon doesn't even start
without these, but if I sent these, I would not be the one making that
judgment (it would be the reviewers and/or people who can push and make
releases).

I think we should also test that if we manage to make a 1.5.1.

Denis.

Hi Denis,

Not so fast here. There are several distinct requirements at play an I
don't think you stitched them together in a good way.

Packages meant for stable releases should have security patches
backported. This does not imply that all packages in Debian unstable
must have security patches backported. It can be ok, to flag a package
as not having such backports (via an RC bug) and then it'll be excluded
from stable releases but can still be part of unstable.

If guix is not meant for stable, it also cannot be part of testing.

The reason for me to have filed a removal suggestion was RC bugs being
unanswered. This can happen legitimately (e.g. for excluing a package
from stable for lack of patch backporting). Indeed, #1112143 is such a
bug and I think it is fair to mark it in such a way that it does not
cause removal of guix.

Now what makes me think guix should be removed is that nobody cared to
fix #1108318 for over a year! Even unstable users deserve security
updates and if we cannot provide them, the package should not be part of
unstable. No backporting needed here. Just go to the next development
release.

I don't think backporting is a requirement for keeping guix in Debian.
Updating the package however is.

So this sounds like a way forward to me.

That also is an option, but having it in any kind of repository
without being updated is a disservice to any user base. Unless the
package is maintained (and the present one evidently is not), there is
no point in figuring out where to host it.

I don't think this is necessary for keeping the package in Debian. You
can still do this for other reasons.

It is not completely removed yet. It is removed from stable and testing
and this bug report attempts to do the last removal (from unstable).

Exactly this is what would be necessary. I agree this is a non-trivial
amount of work, but it is this work that is needed for keeping the
package in any place. Just dumping vulnerable versions somewhere looks
nice but is a disservice to anyone who consumes them.

Helmut

I tried applying those patches, but could not get the test suites to
pass, or even when ignoring the test suites, failed to actually get
guix-daemon 1.5.0 to work correctly... lots of issues with corrupt
substitutes.

For now, I've uploaded guix 1.5.0-1 to Debian without those patches, at
least fixing the other long-outstanding security vulnerabilities and
other issues... the patches from guix-1.5.0-backports branch apply
pretty easily if someone else wants to try to shake out the remaining
problems.

Yeah, I get that.


live well,
  vagrant

user helmutg@debian.org
usertags 1112143 + sidremove-ignore
thanks
...

That was the point of 1112143, hopefully I tagged it correctly!

Guix has picked up a couple more RC bugs (new security issues, FTBFS
with nocheck build profile) since the filing of this bug, but with some
more people taking an interest in it, I have at least some hope we can
get those fixed...


live well,
  vagrant

Hi,

On Wed, 07 Oct 2026 15:29:43 -0700 Vagrant Cascadian <vagrant@debian.org> wrote:

That's exactly my point. Here I need help and I can't do everything. So
my goal is to get help from people from the future backports Guix team
during the review.

And the Linux documentation that explains how to learn to backport
patches also says that involving people that made these patches in the
review would be a good thing, but this can only happen in Guix because
these people are not expected to be Debian contributors.

Another issue is that in my backports there were conflicts and I've
tried to resolve them as best as I could, but I learned later on (in
that documentation) that it was a good idea to investigate more deeply
merge conflicts, by finding and reading the patches that got in
the way, instead of just trying to resolve them like I'm used to.

I've started posting patches
(https://codeberg.org/guix/guix/pulls/11832) for the Guix documentation
on creating a team for backports and I'll try to see if tomorrow I can
gather more help at Guix @ Paris, a monthly Guix meeting.

Since "test that don't pass" seem to be a real concern for downstream
distributions, I've also modified slightly my plan to make sure this is
in scope for backporting patches.

Denis.

close 1148812
thanks

Hi Vagrant,

I confirm. The sidremove-ignore tag is meant for bugs that do not make
the package unusable for unstable users but shall prevent inclusion into
testing. Being unsupportable by the security team generally is a good
example for this tag.

To me, this is actually good news. It shows that people care about the
package. Also new RC bugs is not something the autoremover reacts to. It
takes a year of not interacting with a bug for my tooling to trigger a
process. The goal of my removals is to get rid of packages that nobody
cares about. It seems like we are very far from that now.

Given the activity, I am closing the removal suggestion.

Keep up the good work

Helmut