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 <[email protected]> > 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 >
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
