Kernel download site structure

[Antonio Grassi]

I hadn't thought of the approach you mention: downloading always the vanilla
Kernel sources, and deblobing as appropriate. I'll take a look at it.

Thanks Nick

2010/7/4 Nick <linux-libre-list at njw.me.uk>

> Hi Antonio,
>
> Quoth Antonio Grassi:
> > Hello list. I'm working on the LibreWRT project [1] whish is based on
> > OpenWRT [2]
> >
> > The idea is to create an OpenWRT variant that would use only libre
> software.
> > OpenWRT is composed of a bunch of scripts that download the kernel and
> the
> > base system sources and compiles everything, producing a disk image.
> > Different kernel versions are used for different target architectures.
>
> Brilliant! I have a WRT54GS router myself, running OpenWRT, and
> love to see more fun and freedom-oriented work done on it. (though
> I'm not sure if the free B43 firmware works yet - do provide
> instructions for this if it's possible sometime ;-))
>
> > As part of this work, we added a build option. When set, the kernel to
> > download and compile should be Linux-Libre instead of the blobbed one. I
> > made a POC which worked ok, and now I'm working on a clean patch to
> submit
> > upstream to OpenWRT.
> >
> > The patch should ideally just change the URL used to download the kernel,
> > but this seems a bit hard, 'cause the directory structure & naming
> differs
> > between kernel.org and Libre Linux. Even worse, I see that some releases
> end
> > in -libre, others in libre-1, libre-2, etc
>
> Yes, this was tricky in the case of us at Gentoo, too. I ended up
> using
>
> http://www.fsfla.org/svnwiki/selibre/linux-libre/download/releases/LATEST-${DEBLOB_PV}.N/
> (where DEBLOB_PV is eg 2.6.30). This always points to the latest
> libre version. One slight issue with this, though, is that if that
> symlink changes because there's a different libre version (doesn't
> happen too often), the checksums which are automatically cached by
> Gentoo will change so integrity checks might change. Looking at it
> again, though, if you're getting the kernel sources rather than the
> deblob scripts, you'll still have to keep track of the libre
> version.
>
> The directory structure being slightly different was annoying for us
> too, but not difficult. Though as we now just apply the deblob
> script to a vanilla kernel, it's no longer an issue for us.
>
> I don't know how the OpenWRT build system works, but if you could do
> as we do, so that one can choose to automatically run the deblob
> scripts against any available kernel by choosing an option, that'd
> be nicer as whatever kernel patches people want, deblobbing will be
> available. Also, using the script handily steps around the naming
> and directory structure issues.
>
> > So I'm writing to the list to know if there's a logic behind the naming
> > scheme of Linux Libre, so that I can determine which is the folder and
> the
> > name of the tarball that should be used for a given version. E.g. if
> kernel
> > version is 2.6.32.14 how to know I should
> > download 2.6.32.14-libre1/linux-2.6.32.14-libre1.tar.bz2 ?
>
> I believe the appended number to libre in the filename is to mark
> where there have been major changes to the deblob rules. There is
> mention of it somewhere in the archives (or just wait for a response
> from Alexandre).
>
> > I'm also curious about the reasons for not mirroring the
> > kernel.orgdirectory & naming conventions, could someone illustrate me
> > about this?
>
> Yes, for the record, this would have been useful for us too, before
> we switched to using the script directly. I suggest the project
> considers switching to a directory structure as kernel.org's, and
> ideally stable and predictable tarball URLs, so it's easier for
> people to write interesting scripts to automatically get your deblob
> goodness :-)
>
> Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20100704/48588d23/attachment.htm>