Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 537132 - sys-kernel/gentoo-sources without USE=deblob has a different license because of binary blobs
Summary: sys-kernel/gentoo-sources without USE=deblob has a different license because ...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-20 13:37 UTC by Dylan
Modified: 2021-07-10 18:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
kernel-2.eclass patch to fix verify fail with deblob (kernel-2.eclass.patch,716 bytes, patch)
2015-01-27 13:36 UTC, Dylan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dylan 2015-01-20 13:37:50 UTC
Removal of deblob option from sys-kernel/gentoo-sources breaks ACCEPT_LICENCE="-* @FREE"
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2015-01-20 16:03:53 UTC
Please explain.
Comment 2 gentoo-bugs-old 2015-01-20 19:12:16 UTC
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.
Comment 3 douteiful 2015-01-21 02:22:06 UTC
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.
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2015-01-21 07:33:13 UTC
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.
Comment 5 douteiful 2015-01-21 11:47:24 UTC
Please mark it as WONTFIX if you don't actually plan to fix this.
Comment 6 Dylan 2015-01-27 13:36:25 UTC
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.
Comment 7 Mike Pagano gentoo-dev 2015-01-27 15:14:36 UTC
(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
Comment 8 Dylan 2015-01-28 23:37:12 UTC
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.
Comment 9 Mike Pagano gentoo-dev 2015-01-28 23:41:19 UTC
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
Comment 10 Dylan 2015-01-29 00:20:05 UTC
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/
Comment 11 Mike Pagano gentoo-dev 2015-01-29 00:44:01 UTC
Are you saying checkout via tags? I have not looked at that svn repo.
Comment 12 Dylan 2015-01-29 11:07:29 UTC
Yes. They are available: http://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/
Comment 13 Pablo Cholaky 2015-02-05 02:54:43 UTC
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?
Comment 14 Mike Pagano gentoo-dev 2015-02-06 13:25:32 UTC
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.
Comment 15 Andrey Aleksandrovich 2018-01-28 07:52:52 UTC
(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.