Removal of deblob option from sys-kernel/gentoo-sources breaks ACCEPT_LICENCE="-* @FREE"
Please explain.
emerge of gentoo-sources gives: "The following license changes are necessary to proceed: (see "package.license" in the portage(5) man page for more details) # required by gentoo-sources (argument) >=sys-kernel/gentoo-sources-3.17.7:3.17.7 freedist" When deblob was still there, the freedist license, which allows binary blobs, was not required.
See bug 533532. It seems the linux-libre script (deblob-check) that deblobs the kernel was causing problems too often, so they removed the USE flag completely. As you say, this will force you to unmask the freedist license if you're trying to run a fully libre system, even if you plan to run the deblob script later. It seems it was caused due the eclass downloading the latest bleeding edge script (thus causing checksum issues periodically) instead of a stable one (I assume they're located in the 3.x.x folders instead of LATEST-*). If we want to request it again we need to provide a patch to fix the issue first.
And how do you suppose this can be fixed without reinstating USE=deblob? I guess you'll have to accept the new license and then maybe not use the blobs.
Please mark it as WONTFIX if you don't actually plan to fix this.
Created attachment 395002 [details, diff] kernel-2.eclass patch to fix verify fail with deblob This is my first patch, which is dierect output from svn diff. Changes the lookup directory for the deblob script on the fsfla webiste to match the currently selected kernel instead of just the most recently released. To fully funtion it still needs K_DEBLOB_AVAILABLE to be set to 1 and a new manifest for each of the gentoo-sources ebuilds.
(In reply to Dylan from comment #6) > Created attachment 395002 [details, diff] [details, diff] > kernel-2.eclass patch to fix verify fail with deblob > > This is my first patch, which is dierect output from svn diff. Changes the > lookup directory for the deblob script on the fsfla webiste to match the > currently selected kernel instead of just the most recently released. To > fully funtion it still needs K_DEBLOB_AVAILABLE to be set to 1 and a new > manifest for each of the gentoo-sources ebuilds. Aren't these all the same deblob-<ver> files? 3.17.1-gnu/deblob-3.17 2014-09-28 03:49 124K 3.17.2-gnu/deblob-3.17 2014-09-28 03:49 124K 3.17.3-gnu/deblob-3.17 2014-09-28 03:49 124K
You're right. I've come to the conclusion that my patch is not a solution to the cause of the issues that have been occurring with deblob. I've further investigated and looking purely at 3.18 bugs 533488 and 536482 What caused these issues can be seen in the history of the MANIFEST file. 53488 was caused by revision 1.1656 where the correct hashes for deblob-3.18 are overwritten http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1655&r2=1.1656 in revision 1.1664 of the MANIFEST file all of the deblob hashes are overwritten with the hash for deblob-check-3.* are overwritten with the hashes for deblob-check-3.14 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1663&r2=1.1664 Both of the above are corrected in revision 1.1666 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1665&r2=1.1666 and 1.1667 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1666&r2=1.1667 536482 was a direct result of 1.1673 which overwrote the hases for several deblob-3.* and deblob-check-3.* hashes http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1672&r2=1.1673 Looking at the hash for deblob-3.18 1.1673 instroduces the same incorrect has that was introduced in 1.1656 all of the deblob-3.* and deblob-check-3.* hashes were removed in 1.1674 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/Manifest?r1=1.1673&r2=1.1674 So to find a solution to the issue with deblob we need to work out what caused theses changes to the deblob hashes. The timestamp for deblob-3.18 on fsfla.org is 2014-12-08 which is before any of the above changes occurred.
Yeah, I had gone down the same path as you when trying to solve this. What we really need is some versioning from upstream similar to what the BFQ patches have: http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
Maybe then we could modify kernel-2.eclass to get the deblob scripts straight from their svn repository: http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/
Are you saying checkout via tags? I have not looked at that svn repo.
Yes. They are available: http://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/
I don't know if is related, but since the removal of deblob, I had to modify the ebuild to "enable" deblob and worked without problems, I don't see currently the idea to ignore deblob since 3.12. By the way, I'm using vanilla-sources and deblob have no problems, shouldn't be ignored. IDK about gentoo-sources, but shouldn't be vanilla with gentoo patches only?
Sometimes it works, but when they change the file while keeping the same name it will break. Until that issue is solved by us doing some svn checking, or them by adding a version number when they update the script, then the deblob support for vanilla or gentoo-sources stays removed.
(In reply to Mike Pagano from comment #14) > Until that issue is solved by us doing some svn checking, or them by adding > a version number when they update the script, then the deblob support for > vanilla or gentoo-sources stays removed. Mike, I have asked at linux-libre@fsfla.org mailing list about it, that's the answer: 2018-01-27 23:44 GMT+02:00, Jason Self <j@jxself.org>: > It seems that they're getting the scripts from the wrong place if > they're having problems like this. If they want to get from them from > subversion they should at least be going with releases, not from trunk. > > So http://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/ > and not http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/ > > (The trunk URL at > http://www.fsfla.org/svn/fsfla/software/linux-libre/releases/trunk > shows points to scripts.) > > A new tag is added to /releases/tags when changes are made. For > example: 4.9.2-gnu, 4.9.36-gnu, 4.9.41-gnu, 4.9.59-gnu. These match up > with kernel versions for when changes are needed. > > Another option is to check this out: > http://linux-libre.fsfla.org/pub/linux-libre/releases/ > > For whatever version is being deblobbed you will find the deblob > script that was used to make that version of the kernel in the > appropriate directory. > > Ignore the "LATEST" directories or it will likely cause them similar > grief. And the one more: 2018-01-27 23:59 GMT+02:00, Jason Self <j@jxself.org>: > It sounds like they may not have the correct mental model for how it's > setup: They should use script version that matches the kernel version > being compiled. Anything else will cause problems. > > Continuing the example of the 4.9 kernel series where the following > tags exist in subversion: > > 4.9-gnu > 4.9.2-gnu > 4.9.36-gnu > 4.9.41-gnu > 4.9.59-gnu > > 4.9-gnu should be only be used to deblob 4.9.0 and 4.9.1. > 4.9.2-gnu should only be used to deblob 4.9.2 through 4.9.35. > 4.9.36-gnu should only be used to deblob 4.9.36 through 4.9.40. > 4.9.41-gnu should only be used to deblob 4.9.41 through 4.9.58. > 4.9.59-gnu should only be used to deblob 4.9.59 to current (4.9.78), > although deblobbing changes may be needed at any time and so a new tag > for post-4.9.59 may appear at any time. Each new kernel release is > examined and a determination as to if deblobbing changes are needed > are made at that point. This is usually done within a few days of the > release at kernel.org. > > So the key part is that they need to find the deblob script that > matches with the kernel version that is being compiled, not that > "4.9.59-gnu is the latest version of the 4.9 series and should be used > on all of the 4.9 series." > > If it's too difficult to calculate which tag to get from subversion > based on which kernel version is being compiled, that's why I also > pointed to http://linux-libre.fsfla.org/pub/linux-libre/releases/ > > That location has a directory for every kernel version and so no > computing of version numbers is needed: Go into the directory for any > version and you will find the deblob scripts needed for that version. > > Ignore the "LATEST" directories or it will cause them similar grief to > what they were experiencing. > > Hopefully this helps and the information from my previous email and > this one can get back to them somehow. I very much hope that this information will help to solve our issue. If you can, please, move back deblobbing. Thanks.
