From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#14851: linux-libre-3.3.8-gnu disappeared Date: Fri, 19 Jul 2013 14:09:37 +0200 Message-ID: <8761w6hhtq.fsf@gnu.org> References: <201307121302.05303.andreas@enge.fr> <87zjtrfm39.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V09Vg-0006no-LW for bug-guix@gnu.org; Fri, 19 Jul 2013 08:10:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V09Vb-0000il-KO for bug-guix@gnu.org; Fri, 19 Jul 2013 08:10:08 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:42653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V09Vb-0000hq-HQ for bug-guix@gnu.org; Fri, 19 Jul 2013 08:10:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V09Va-0001ke-Mq for bug-guix@gnu.org; Fri, 19 Jul 2013 08:10:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Alexandre Oliva's message of "Fri, 19 Jul 2013 08:08:43 -0300") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Alexandre Oliva Cc: 14851@debbugs.gnu.org Alexandre Oliva skribis: > On Jul 12, 2013, ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > >> Since we=E2=80=99re about to release a new version of Guix, I=E2=80=99d = 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-li= bre-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=E2=80=99s 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=E2=80=99ll 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=E2=80=99t want to bother, provided the FTP admins allow it. WDY= T? > > 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=E2=80=99s usually not= a blocking problem. Yet, it=E2=80=99s preferable to have them elsewhere, bec= ause 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 =E2=80=9Ccop= y=E2=80=9D, 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 =E2=80=9Cmultiple GBs of builds per week=E2=80=9D? Lin= ux{,-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=E2=80=99s something to discuss with the GNU sysadmins. Thanks for your feedback! Ludo=E2=80=99.