* bug#14851: linux-libre-3.3.8-gnu disappeared @ 2013-07-12 11:02 Andreas Enge 2013-07-12 22:30 ` Ludovic Courtès 2017-04-03 10:53 ` bug#14851: #14851 - " ng0 0 siblings, 2 replies; 13+ messages in thread From: Andreas Enge @ 2013-07-12 11:02 UTC (permalink / raw) To: 14851 The build of linux-libre-headers-3.3.8 currently fails because the tarball cannot be downloaded any more from http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu/ Instead, there is a new version in http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu1/ Should we switch to this one? Or update to the newest version? In all cases, I am afraid a complete rebuild will be triggered, so we might as well advance in the version numbers. Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-12 11:02 bug#14851: linux-libre-3.3.8-gnu disappeared Andreas Enge @ 2013-07-12 22:30 ` Ludovic Courtès 2013-07-14 4:28 ` Jason Self 2013-07-19 11:08 ` Alexandre Oliva 2017-04-03 10:53 ` bug#14851: #14851 - " ng0 1 sibling, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2013-07-12 22:30 UTC (permalink / raw) To: Andreas Enge, Alexandre Oliva; +Cc: 14851 Hello, (Cc: Alexandre Oliva of Linux-Libre.) Andreas Enge <andreas@enge.fr> skribis: > The build of linux-libre-headers-3.3.8 currently fails because the tarball > cannot be downloaded any more from > http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu/ > Instead, there is a new version in > http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu1/ I just checked and the latter has a different SHA256 (1860as3dwh7f3im1sq3x06awmil9vppl6igg2gnva5w9mbkw2fc8). > Should we switch to this one? Or update to the newest version? In all > cases, I am afraid a complete rebuild will be triggered, so we might as > well advance in the version numbers. Indeed. 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? 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? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-12 22:30 ` Ludovic Courtès @ 2013-07-14 4:28 ` Jason Self 2013-07-14 13:55 ` Ludovic Courtès 2013-07-17 13:31 ` Ludovic Courtès 2013-07-19 11:08 ` Alexandre Oliva 1 sibling, 2 replies; 13+ messages in thread From: Jason Self @ 2013-07-14 4:28 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 14851, Alexandre Oliva [-- Attachment #1: Type: text/plain, Size: 351 bytes --] My understanding is that the change from gnu to gnu1 is the result of changes that were needed to the deblobbing. Specifically to allow the loading of the firmware used by ath9k-htc, now that it's free [0]... i.e. 3.3.8-gnu and 3.3.8-gnu1 aren't the same source code. [0] https://www.fsf.org/news/ryf-certification-thinkpenguin-usb-with-atheros-chip ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-14 4:28 ` Jason Self @ 2013-07-14 13:55 ` Ludovic Courtès 2013-07-17 13:31 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2013-07-14 13:55 UTC (permalink / raw) To: Jason Self; +Cc: 14851, Alexandre Oliva "Jason Self" <jason@bluehome.net> skribis: > My understanding is that the change from gnu to gnu1 is the result of > changes that were needed to the deblobbing. Specifically to allow the > loading of the firmware used by ath9k-htc, now that it's free [0]... > i.e. 3.3.8-gnu and 3.3.8-gnu1 aren't the same source code. OK, thanks for the info. It’s hard for us to deal with disappearing software. In this case, we’re currently using this tarball just to install the Linux-Libre headers to build libc, and our ‘linux-libre’ package can use a different upstream version than ‘linux-libre-headers’ anyway. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-14 4:28 ` Jason Self 2013-07-14 13:55 ` Ludovic Courtès @ 2013-07-17 13:31 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2013-07-17 13:31 UTC (permalink / raw) To: 14851; +Cc: Alexandre Oliva I’ve asked ftp-upload@ if they could allow me to upload linux-libre tarballs to ftp.gnu.org. In the meantime, I’ve uploaded this tarball to ftp://alpha.gnu.org/gnu/guix/mirror and changed linux.scm to refer to it. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-12 22:30 ` Ludovic Courtès 2013-07-14 4:28 ` Jason Self @ 2013-07-19 11:08 ` Alexandre Oliva 2013-07-19 12:09 ` Ludovic Courtès 2013-07-19 16:51 ` Andreas Enge 1 sibling, 2 replies; 13+ messages in thread From: Alexandre Oliva @ 2013-07-19 11:08 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 14851 On Jul 12, 2013, ludo@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. 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. > 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. I keep on failing to figure out how to fit the weekly publishing of multiple releases into a workflow that includes collecting information and sending it to ftp.gnu.org without keeping another local copy of stuff that was published before. That's one of the hold-up factors for me. As for the tarballs, they're all signed, so figuring out a way to upload just the bits created since the last push, and pushing them to live, is what's missing. 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. At the very least, you ought to keep a copy of sources you use to build binaries you publish, so that you can satisfy your obligation to offer the corresponding source, be it a legal (copyleft) or moral (software in gnu ought to be free) obligation. 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. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-19 11:08 ` Alexandre Oliva @ 2013-07-19 12:09 ` Ludovic Courtès 2013-07-19 19:50 ` Alexandre Oliva 2013-07-19 16:51 ` Andreas Enge 1 sibling, 1 reply; 13+ messages in thread From: Ludovic Courtès @ 2013-07-19 12:09 UTC (permalink / raw) To: Alexandre Oliva; +Cc: 14851 Alexandre Oliva <lxoliva@fsfla.org> skribis: > On Jul 12, 2013, ludo@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’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-19 12:09 ` Ludovic Courtès @ 2013-07-19 19:50 ` Alexandre Oliva 2013-07-19 20:30 ` Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Alexandre Oliva @ 2013-07-19 19:50 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 14851 On Jul 19, 2013, ludo@gnu.org (Ludovic Courtès) wrote: > What do you mean by “multiple GBs of builds per week”? Linux{,-Libre} > releases are not that frequent, are they? They are. ATM there are 4 active stable releases that each get one new release per week. There are 3 other LTS stable branches that get releases less often. And then, there are the weekly development -rcs for the next release, that I seldom start tracking long before the release is out. This is just for sources, and it adds up to almost 1GB per week. Adding binaries to the picture grows the entire size by a little bit when it comes to the freesh and planet .debs, and to a larger extent when it comes to gnewsense/yeeloong (that gets one build per source release we put out, with a total deb+tar size about the same size of the source release subdir), and the freed-ora builds (that involve 1-4 rpm builds per active Fedora release per week, each one weighting some 2GB total; for most of the time there are 2 or 3 active releases; sometimes there are 4, depending on whether or not I've already cleaned up the -rc series for the upcoming release that gets built for the rawhide tree). > If size turns out to be a problem, we could choose to keep only LTS > releases on ftp.gnu.org, for instance. Keeping only LTS wouldn't help guix, though, since you're not using an LTS release. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-19 19:50 ` Alexandre Oliva @ 2013-07-19 20:30 ` Ludovic Courtès 0 siblings, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2013-07-19 20:30 UTC (permalink / raw) To: Alexandre Oliva; +Cc: 14851 Alexandre Oliva <lxoliva@fsfla.org> skribis: > On Jul 19, 2013, ludo@gnu.org (Ludovic Courtès) wrote: > >> What do you mean by “multiple GBs of builds per week”? Linux{,-Libre} >> releases are not that frequent, are they? > > They are. ATM there are 4 active stable releases that each get one new > release per week. There are 3 other LTS stable branches that get > releases less often. And then, there are the weekly development -rcs > for the next release, that I seldom start tracking long before the > release is out. This is just for sources, and it adds up to almost 1GB > per week. Ah OK, I wasn’t aware of that. > Adding binaries to the picture grows the entire size by a little bit Yes, but binaries is not what we’re interested in here. :-) >> If size turns out to be a problem, we could choose to keep only LTS >> releases on ftp.gnu.org, for instance. > > Keeping only LTS wouldn't help guix, though, since you're not using an > LTS release. Heh but that’s not set in stone, and we don’t use Linux-Libre for anything beyond building libc. That’ll change in the near future though. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-19 11:08 ` Alexandre Oliva 2013-07-19 12:09 ` Ludovic Courtès @ 2013-07-19 16:51 ` Andreas Enge 2013-07-19 19:40 ` Alexandre Oliva 1 sibling, 1 reply; 13+ messages in thread From: Andreas Enge @ 2013-07-19 16:51 UTC (permalink / raw) To: Alexandre Oliva; +Cc: 14851 Am Freitag, 19. Juli 2013 schrieb Alexandre Oliva: > 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. As far as I know, ftp.gnu.org would only be concerned with the source, that is, the content of http://linux-libre.fsfla.org/pub/linux-libre/releases/ and not with binary packages in upper level directories, and these source tarballs are usually kept indefinitely. One also need not add the patch and diff files, so that the amount of storage would be quite manageable. Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: linux-libre-3.3.8-gnu disappeared 2013-07-19 16:51 ` Andreas Enge @ 2013-07-19 19:40 ` Alexandre Oliva 0 siblings, 0 replies; 13+ messages in thread From: Alexandre Oliva @ 2013-07-19 19:40 UTC (permalink / raw) To: Andreas Enge; +Cc: 14851 On Jul 19, 2013, Andreas Enge <andreas@enge.fr> wrote: > Am Freitag, 19. Juli 2013 schrieb Alexandre Oliva: >> 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. > As far as I know, ftp.gnu.org would only be concerned with the source, I don't know about that. I've seen binaries in ftp.gnu.org in the past. This should indeed reduce significantly the space requirements to a bit less than 1GB per week, considering 4 releases per week in 3 different compression formats. OTOH, if we're to be strict, we should publish only the deblob scripts, for those are the ultimate sources produced by the GNU Linux-libre project. The tarballs and diffs and deltas are just the result of running those scripts on tarballs produced by third parties. The scripts would be trivial to retain indefinitely; even more so because they seldom change for stable releases. > and these source tarballs are usually kept indefinitely. > One also need not add the patch and diff files, so that the amount of > storage would be quite manageable. The diff files are probably no big deal (10% increase, not an order of magnitude like the build tarballs and debuginfo rpms). Excluding them would probably make for more work in the upload script, though. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: #14851 - linux-libre-3.3.8-gnu disappeared 2013-07-12 11:02 bug#14851: linux-libre-3.3.8-gnu disappeared Andreas Enge 2013-07-12 22:30 ` Ludovic Courtès @ 2017-04-03 10:53 ` ng0 2017-05-05 18:56 ` Ludovic Courtès 1 sibling, 1 reply; 13+ messages in thread From: ng0 @ 2017-04-03 10:53 UTC (permalink / raw) To: 14851 Andreas, Ludovic, and others: This bug report was last modified 3 years and 258 days ago. It is my understanding that this bug could be closed. I see no more current problems and it makes no sense to keep the bug open just in case the problem appears again. Would you agree? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14851: #14851 - linux-libre-3.3.8-gnu disappeared 2017-04-03 10:53 ` bug#14851: #14851 - " ng0 @ 2017-05-05 18:56 ` Ludovic Courtès 0 siblings, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2017-05-05 18:56 UTC (permalink / raw) To: 14851-done ng0 <contact.ng0@cryptolab.net> skribis: > Andreas, Ludovic, and others: > > This bug report was last modified 3 years and 258 days ago. > > It is my understanding that this bug could be closed. I see no more > current problems and it makes no sense to keep the bug open just in case > the problem appears again. > > Would you agree? I do! Especially with the content-addressed mirror we’ve been hosting with ‘guix publish’. Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-05-05 18:57 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-12 11:02 bug#14851: linux-libre-3.3.8-gnu disappeared Andreas Enge 2013-07-12 22:30 ` Ludovic Courtès 2013-07-14 4:28 ` Jason Self 2013-07-14 13:55 ` Ludovic Courtès 2013-07-17 13:31 ` Ludovic Courtès 2013-07-19 11:08 ` Alexandre Oliva 2013-07-19 12:09 ` Ludovic Courtès 2013-07-19 19:50 ` Alexandre Oliva 2013-07-19 20:30 ` Ludovic Courtès 2013-07-19 16:51 ` Andreas Enge 2013-07-19 19:40 ` Alexandre Oliva 2017-04-03 10:53 ` bug#14851: #14851 - " ng0 2017-05-05 18:56 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).