[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14851: linux-libre-3.3.8-gnu disappeared
From: |
Ludovic Courtès |
Subject: |
bug#14851: linux-libre-3.3.8-gnu disappeared |
Date: |
Fri, 19 Jul 2013 14:09:37 +0200 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
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’.