On Mon, May 12, 2025 at 01:11:15PM -0400, Greg Hogan wrote: > On Mon, May 12, 2025 at 12:23 PM Rutherther <ruthert...@ditigal.xyz> wrote: > > > > Hi Greg, > > > > Greg Hogan <c...@greghogan.com> writes: > > > > > On Fri, May 9, 2025 at 5:55 PM Steve George <st...@futurile.net> wrote: > > >> > > >> I hope the initial user experience wouldn't be to "break on the user's > > >> first pull", since with annual releases we wouldn't have release > > >> artefacts that are 2.5 years out of date. And, we'd also degraft > > >> regularly which would be beneficial for all users. > > >> > > >> As you can tell I would _love_ us to be able to have a slower moving > > >> branch, but purposefully have kept the GCD more limited. For now > > >> focusing on the step forward of regular releases. > > > > > > I have not updated a 2.5+ year old Guix system, but what is the issue > > > here? How is this any different from updating a week old system? If > > > the archive contains broken packages then the user upgrade experience > > > will fail just the same. And clearing the archive of broken packages > > > also breaks user manifests! > > > > There isn't an issue as long as you use substitutes. But if you decided > > you won't, then there is an issue currently. Specifically there is a > > misbehaving mirror crysys.hu that returns 200, but returns page not > > found html page. That means packages like gnutls aren't building. For > > people that are installing Guix from their system's package manager, > > they will get hit by this unless they actively activate the substitutes. > > > > This points to a more general problem that can be happening in the > > future, it can be misbehaving mirrors or pages that aren't handled well > > by Guix and lead to non-buildable software. As long as pages behave as > > they should, everything should be fine, ie. SWH gets triggered on > > missing repositories, subsequent mirror urls are used, etc. But > > misbehaving pages are always going to cause issues. > > So for the (small?) subset of users (myself included) who do not > enable substitutes, then for the small set of packages provided > pre-built with the installation ... > > >> guix depends on gnutls > guix@1.4.0-36.0772d36 > guile-gnutls@4.0.0 > gnutls@3.8.3 > > Can we not retry mirrors on checksum mismatch? And differentiate > between binary substitutes and sources? The latter are strongly hashed > and therefore no different from patches or the package code itself. > Does use of SWH require substitutes to be enabled?
SWH doesn't require substitutes to be enabled, they only serve source files. > > Apart from that there has been a mistake made in generation of the 1.4.0 > > iso, the iso has used a local channel url, /home/ludo/..., so now if you > > install from the iso, your system will have this path in the > > channels.scm provenance file. Then if you do not pull at all, but > > reconfigure right away, you will get an error that /home/ludo/... is not > > found. That is because of the forward update check that is going to try > > to check if your current commit is descendant of the previous one. > > (I think that the check should have a way to abort early if no > > commits have changed btw) > > Mistakes like that will probably be happening with new releases > > as well. Though this one should be impossible already - the url is going > > to be replaced in the operating-system from install.scm. > > > > The more releases the faster issues like this can get resolved, and not > > confuse the users. > > I think we should release more often (multiple times per year) and > also add checks like building release artifacts and bootstrapping > systems with clocks set into the future to detect another major > annoyance: timebombs. Anything which can be automated. These are still things that we can do. I hope that any manual parts of the release process we can identify and automate going forward, including making sure any package or service we offer from the installer actually builds. > > Regards > > Rutherther > -- Efraim Flashner <efr...@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
