GNU bug report logs - #14851
linux-libre-3.3.8-gnu disappeared

Previous Next

Full log

Message #20 received at 14851 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alexandre Oliva <lxoliva <at> fsfla.org>
Cc: 14851 <at> debbugs.gnu.org, Andreas Enge <andreas <at> enge.fr>
Subject: Re: bug#14851: linux-libre-3.3.8-gnu disappeared
Date: Fri, 19 Jul 2013 14:09:37 +0200

Alexandre Oliva <lxoliva <at> fsfla.org> skribis:

> On Jul 12, 2013, ludo <at> gnu.org (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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.