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.
pgponkyL_1iaB.pgp
Description: OpenPGP digital signature
