Re: linux-libre source tarballs

[Leo Famulari <leo@famulari.name>]

On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascadian wrote:
> Pragmatically speaking, on slower platforms this is a huge resource
> overhead. So much so that ci.guix.gnu.org *usually* times out when
> generating the linux-libre aarch64 tarballs:
> 
>   https://ci.guix.gnu.org/search?query=system%3Aaarch64-linux+linux-libre-arm64-generic

Thanks for letting me know. I didn't know this was happening.

The immediate solution is for me to make sure the tarballs have built
before committing the updates. I already do this for x86_64 and I can
start doing it for aarch64 too.

> * Using linux-libre's git repository.

We could do this. The decision is up to the maintainers, ultimately. I'd
rather we did not because linux-libre is not the "upstream" of the
kernel in a meaningful way (they do not develop or fix bugs), and it's
not "source code" in the GNU sense, which is the "preferred form of the
work for making changes in it":

http://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoftware

Not to mention that cloning a 1 GB Git repo is rather expensive compared
to downloading a tarball, and thus also suboptimal for the ARM boards
that can't easily deblob. Although if people are building the
linux-libre tarballs, they are also compiling, which is of course way
more expensive.
  
> * Using the linux-libre tarballs. May have some issues with long-term
>   availability, but fast to download and the deblobbing scripts have
>   effectively already been run, saving a lot of local work. There is
>   basically support for this in guix already, and was the method used in
>   guix before july 2019 1ad9c105c208caa9059924cbfbe4759c8101f6c9.

As you say, these tarballs are not available for very long.  I think
this option is not practical for that reason.

> * Bump the timeouts on ci.guix.gnu.org for linux-libre so that the
>   deblob scripts actually get a chance to finish. Doesn't require much
>   change in the guix infrastructure to significantly improve the status
>   quo for slower architectures. Might take some tweaking over time to
>   find the right timeouts.

Will do.