bug#14851: linux-libre-3.3.8-gnu disappeared

[Ludovic Courtès]

Alexandre Oliva <address@hidden> skribis:

> On Jul 12, 2013, address@hidden (Ludovic Courtès) wrote:
>
>> Since we’re about to release a new version of Guix, I’d rather keep
>> using 3.3.8.
>
>> Alexandre: could you reinstate the original
>> http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu/linux-libre-3.3.8-gnu.tar.xz?
>
> I suppose you don't want to prevent users of guix from using ath9k wifi
> cards, so I strongly suggest switching to 3.3.8-gnu1.

Of course not, but again, this one is used to get headers against which
to build glibc, so that’s not a problem.

> Indeed, I think you'd be better off with some LTS version of GNU
> Linux-libre, rather than the dead 3.3 branch.  But that's your call.

When we have a stand-alone, bootable distro, we’ll certainly want to
synchronize with you for the choice of the default kernel version.

>> It would be ideal if the tarballs were on ftp.gnu.org.  I could do it if
>> you don’t want to bother, provided the FTP admins allow it.  WDYT?
>
> I'd be glad with such an arrangement.

Great.

> Now, another possibility that I think would make more sense for guix is
> to have its sources consolidated in a single place, rather than
> scattered all over and at risk of having them pulled from under you.

Actually, our continuous integration server at http://hydra.gnu.org does
that transparently: it caches all the source tarballs, along with build
byproducts.

So when a tarball vanishes from its upstream site, it’s usually not a
blocking problem.  Yet, it’s preferable to have them elsewhere, because
they will eventually be garbage-collected from hydra.gnu.org.

[...]

> When we get GNU Linux-libre at ftp.gnu.org, it could then be hard links,
> so that if we remove some tarball it won't go away from your “copy”, but
> until then, you might be better off holding your own copy rather than
> assuming our primary repository has infinite space.  Unfortunately it
> doesn't, and I have to clean things up quite often.  For sources, I at
> least keep enough bits around that the tarballs can be reconstructed in
> a bit-exact fashion, but for binaries, when they're gone, they're gone
> forever.  However, considering we put out multiple GBs of builds per
> week, I don't think it's realistic to keep them all forever.  Not in our
> own server, not at ftp.gnu.org.

What do you mean by “multiple GBs of builds per week”?  Linux{,-Libre}
releases are not that frequent, are they?

The policy at ftp.gnu.org has always been to keep everything forever,
AFAIK.

If size turns out to be a problem, we could choose to keep only LTS
releases on ftp.gnu.org, for instance.  That’s something to discuss
with the GNU sysadmins.

Thanks for your feedback!

Ludo’.