Hi, Vagrant Cascadian <vagr...@debian.org> wrote: > Thanks for updating linux-libre to 5.7!
Yes, many thanks to Leo Famulari for taking care of that (large) job. > I saw the 5.8 was out, and gave a quick shot at updating it, but it hung > python indefinitely during the deblobbing process. I also tried > switching to python 3 instead of python 2, but it had the same > issue. Apparently this is a known issue: > > https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00001.html Thanks for bringing this to our attention. Until the deblobbing issue is resolved, in the definition of 'linux-libre-5.8-pristine-source', we could simply replace the call to 'make-linux-libre-source' with an ordinary 'origin' form that fetches the deblobbed source tarball from the linux-libre project, using (linux-libre-urls linux-libre-5.8-version) as the URI. The bigger issue is that the default configurations will need to be updated again before 5.7.x reaches end-of-life, which will be quite soon. Otherwise we'll need to revert back to 5.4.x in order to get upstream security updates. > So I asked a bit in #linux-libre on freenode and they wondered why we > don't use the git repository instead of running the deblob scripts again > in guix. > > One of the issues might be that linux-libre may occasionally remove > releases that accidentally contained non-free code breaking guix's > ability to build old versions. Last I checked, the linux-libre project periodically deletes most of its older tarballs, even if there are no accidents. This problem came to my attention while trying to help someone determine which version of linux-libre introduced a bug on their system. I was about to suggest bisecting point versions before realizing that the relevant linux-libre tarballs had all been deleted. Moreover, if we had succeeded in finding the first buggy release, the next step would have been to do a 'git bisect' to determine the precise commit that introduced the bug. Other reasons to run the deblob scripts ourselves include: * It may be useful for users with newer hardware devices, which are not yet well supported by the latest stable release, to use an arbitrary commit from either Linus' mainline git repository or some other subsystem tree. * It allows us to update to a new point version (which usually includes security fixes) more quickly, before the linux-libre project reacts. * It allows us to avoid trusting the integrity of the systems used by the linux-libre project to produce their deblobbed tarballs. Regards, Mark
