On Fri, Feb 06, 2026 at 10:20:57AM +0100, Simon Josefsson wrote: > Steve George <[email protected]> writes: > > > The big thing is having a 'Team' that's going to be able to commit to > > working on this consistently. There were a lot of different installer > > options that we published in the 1.4.0 time-frame, but when I looked > > at 1.5.0 most of them hadn't been maintained. That's not much of a > > problem for a one-off installer image for a dev motherboard, but it > > will cause issues for containers. > > > > I think you need a new team, or an existing team takes responsibility, > > and there has to be at least one committer in the team. > > Do the release team want to take this on? I'm happy to contribute to a > "Guix Container/Cloud Images Team" if one was started. (...)
I would say the release team is responsible for testing the artefacts that go with a particular release. They're not a permanent team, as we're supposed to rotate devs so that the load is spread. Since the images need a base config, and they're being published all the time there should be a team responsible all the time. I don't know whether that's a "container images" team or a "cloud team". Up to the people who'd be involved - a change is just a PR away :-) > >> 2) I'm not that familiar with the Guix project build system, but I > >> suppose the images should be built by centralized by it? Is this > >> feasible? What would be involved in making that happen? > >> > >> 3) Agreement that images should be generated by 'guix pack -f docker'. > >> Any alternative? > > > > There's been a strong desire for automation in the project so > > yes. Also, most users will want the 'latest' version of a 'container' > > since they'll re-roll the base-container quite often. > > Yes, having daily/weekly/monthly rebuilds of containers seems to be the > norm. > > >> 6) It would be useful to publish images for a recent 'master' commit but > >> also for the Guix v1.5.0 release commit -- which ought to be forever > >> bit-by-bit identical once prepared (or?) -- and for future releases. > >> > > > > I expect you'll want both. > > > > Given that guix pull takes a really long time I would expect that > > users that deploy to 'production' would use the latest commit on > > master. It's good to have the release commit as a separate one. > > What I found in my Guix images jobs is that if I 'guix pull --commit=' > to a commit that is ca one week old, things are much faster since the > substitution servers have cought up. Maybe some people really need > latest master to mean really latest master, but I expect most usages > will just need a "reasonable fresh image" that can be a couple of weeks > old without problem, and even a month or two isn't a problem, but two > years is definitely a concern. > Yes, good point, it doesn't have to track master, it can be a "recent" commit. > >> 7) How are they distributed? I suppose the images could be published on > >> gnu.org/gnu/guix/ but the container-way is via some public container > >> registry. Docker Hub is well-known, but there are many other. I'm not > >> sure if Codeberg offers one. What are the concerns here? > >> > >> What do you think? Other concerns? > > (...) > > > > According to the Codeberg documentation OCI containers can be published: > > > > https://forgejo.org/docs/latest/user/packages/ > > > > I can see the 'package' link on the Guix organisation - it's pretty > > hidden, so I wouldn't expect many users to know about it. We could > > link from the Guix download page as well. > > Yay! Then getting the packages pushed to codeberg/guix's container > registry seems useful. > > Is Guix using any Forgejo runners, or are everything built on ci.guix? > I wonder how to automate the Codeberg container image uploads. > > > The main concern for me about Docker Hub is I don't know what their > > policies are these days. As long as there's no charge for > > distribution? > > I expect it is a horrible mess, but I started pushing my images there to > gain experience how that site actually plays out in practice. (...) Probably a good "learning experience" ;-))) Steve / Futurile
signature.asc
Description: PGP signature
