Hi,
I built a custom kernel from the src.rpm for 4.17.0.0. When I tried to install it, it failed with errors like the following:
Error: Transaction check error: file /usr/share/licenses/kernel-core/COPYING from install of kernel-core-4.17.0-0.rc0.git4.1.20180407.fc28.x86_64 conflicts with file from package kernel-core-4.16.0-0.rc6.git3.1.20180325.fc28.x86_64
But this is just the GPL v2 license. Did the kernel change its license? And, if it did, how do I make the transition, other than force installing the new version?
Thanks.
Am Samstag, den 07.04.2018, 13:52 -0700 schrieb stan:
Hi,
I built a custom kernel from the src.rpm for 4.17.0.0. When I tried to install it, it failed with errors like the following:
Error: Transaction check error: file /usr/share/licenses/kernel-core/COPYING from install of kernel-core-4.17.0-0.rc0.git4.1.20180407.fc28.x86_64 conflicts with file from package kernel-core-4.16.0-0.rc6.git3.1.20180325.fc28.x86_64
But this is just the GPL v2 license. Did the kernel change its license? And, if it did, how do I make the transition, other than force installing the new version?
Thanks.
Same file conflict happens with regular build of `kernel-core-4.17.0- 0.rc0.git4.1.fc29` from/in recent Rawhide.
Cheers, Björn
On Sun, 08 Apr 2018 14:35:35 +0200 Björn 'besser82' Esser besser82@fedoraproject.org wrote:
Same file conflict happens with regular build of `kernel-core-4.17.0- 0.rc0.git4.1.fc29` from/in recent Rawhide.
That makes it sound like there is an issue with the spec file for git 4.1. I'm not familiar enough with packaging to know why this happens, but I see this file conflict error fairly regularly with other packages. I don't know what the fix is, though I've seen it repaired.
Should I open a ticket against the kernel, or is this thread in the kernel mailing list enough?
On Sun, Apr 8, 2018 at 7:49 PM, stan stanl-fedorauser@vfemail.net wrote:
On Sun, 08 Apr 2018 14:35:35 +0200 Björn 'besser82' Esser besser82@fedoraproject.org wrote:
Same file conflict happens with regular build of `kernel-core-4.17.0- 0.rc0.git4.1.fc29` from/in recent Rawhide.
The conflict existed before: # rpm -qf /usr/share/licenses/kernel-core/COPYING kernel-core-4.15.13-300.fc27.x86_64 kernel-core-4.15.15-300.fc27.x86_64 AFAICT the files were identical, but the content changed between f27: d7810fab7487fb0aad327b76f1be7cd7 /usr/share/licenses/kernel-core/COPYING and f29: bbea815ee2795b2f4230826c0c6b8814 ./usr/share/licenses/kernel-core/COPYING (in fact the file is completely different).
This can be traced to upstream's commit "COPYING: use the new text with points to the license files" from 2018-03-23: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/CO...
That makes it sound like there is an issue with the spec file for git 4.1. I'm not familiar enough with packaging to know why this happens, but I see this file conflict error fairly regularly with other packages. I don't know what the fix is, though I've seen it repaired.
Should I open a ticket against the kernel, or is this thread in the kernel mailing list enough?
Please file a bug with the above information.
On Sun, 8 Apr 2018 21:16:52 +0200 François Cami fcami@fedoraproject.org wrote:
On Sun, 08 Apr 2018 14:35:35 +0200 Björn 'besser82' Esser besser82@fedoraproject.org wrote:
Same file conflict happens with regular build of `kernel-core-4.17.0- 0.rc0.git4.1.fc29` from/in recent Rawhide.
The conflict existed before: # rpm -qf /usr/share/licenses/kernel-core/COPYING kernel-core-4.15.13-300.fc27.x86_64 kernel-core-4.15.15-300.fc27.x86_64 AFAICT the files were identical, but the content changed between f27: d7810fab7487fb0aad327b76f1be7cd7 /usr/share/licenses/kernel-core/COPYING and f29: bbea815ee2795b2f4230826c0c6b8814 ./usr/share/licenses/kernel-core/COPYING (in fact the file is completely different).
This can be traced to upstream's commit "COPYING: use the new text with points to the license files" from 2018-03-23: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/CO...
Please file a bug with the above information.
I found an existing bug, and added the information there.
On Sun, Apr 08, 2018 at 13:10:43 -0700, stan stanl-fedorauser@vfemail.net wrote:
I found an existing bug, and added the information there.
I had filed a bug (1564745) for this a day earlier. This is an issue because the license file is in kernel-core without a name that varies by version. So whenever this file changes there is going to be a file conflict between kernel versions, which will be a pain to work around.
One option would be to change the name to match the kernel version. Another option would be put it in kernel instead of kernel-core. Another option would be to have a versioned name in kernel-core and a symlink to it with the normal name in kernel.
I wanted to wait a bit before forcing an update so that I can easily test the solution provided. But it is a pain dealing with the file conflict, because it isn't detected early enough by dnf to be excluded and causes updates to fail unless I manually say not to use kernel-core. And even that has some bad interactions with distro-sync when I need that.
On Mon, 9 Apr 2018 10:55:39 -0500 Bruno Wolff III bruno@wolff.to wrote:
I had filed a bug (1564745) for this a day earlier.
Sorry about that. I did a search, and when the top result was the issue, I didn't look further.
One option would be to change the name to match the kernel version. Another option would be put it in kernel instead of kernel-core. Another option would be to have a versioned name in kernel-core and a symlink to it with the normal name in kernel.
I vote for one. There's a file for each installed kernel, and upon kernel removal, it just disappears without any checks to see if there are other kernels needing the file.
On Mon, Apr 9, 2018 at 2:19 PM, stan stanl-fedorauser@vfemail.net wrote:
On Mon, 9 Apr 2018 10:55:39 -0500 Bruno Wolff III bruno@wolff.to wrote:
I had filed a bug (1564745) for this a day earlier.
Sorry about that. I did a search, and when the top result was the issue, I didn't look further.
One option would be to change the name to match the kernel version. Another option would be put it in kernel instead of kernel-core. Another option would be to have a versioned name in kernel-core and a symlink to it with the normal name in kernel.
I vote for one. There's a file for each installed kernel, and upon kernel removal, it just disappears without any checks to see if there are other kernels needing the file.
I would be happy to hear more feedback on this from people. I am trying to decide on the best course to take (this file changes rarely and last changed in 2005). I plan to put something in place by rc1 next Monday.
Justin
On Mon, Apr 9, 2018 at 11:19 PM, Justin Forbes jforbes@redhat.com wrote:
On Mon, Apr 9, 2018 at 2:19 PM, stan stanl-fedorauser@vfemail.net wrote:
On Mon, 9 Apr 2018 10:55:39 -0500 Bruno Wolff III bruno@wolff.to wrote:
I had filed a bug (1564745) for this a day earlier.
Sorry about that. I did a search, and when the top result was the issue, I didn't look further.
One option would be to change the name to match the kernel version. Another option would be put it in kernel instead of kernel-core. Another option would be to have a versioned name in kernel-core and a symlink to it with the normal name in kernel.
I vote for one. There's a file for each installed kernel, and upon kernel removal, it just disappears without any checks to see if there are other kernels needing the file.
I would be happy to hear more feedback on this from people. I am trying to decide on the best course to take (this file changes rarely and last changed in 2005). I plan to put something in place by rc1 next Monday.
I'd lean towards having COPYING in the kernel subpackage and installing it in a versioned directory - trading a very small amount of disk space for upgrade safety and simplicity.
On Tue, Apr 10, 2018 at 2:36 AM, François Cami fcami@fedoraproject.org wrote:
On Mon, Apr 9, 2018 at 11:19 PM, Justin Forbes jforbes@redhat.com wrote:
On Mon, Apr 9, 2018 at 2:19 PM, stan stanl-fedorauser@vfemail.net wrote:
On Mon, 9 Apr 2018 10:55:39 -0500 Bruno Wolff III bruno@wolff.to wrote:
I had filed a bug (1564745) for this a day earlier.
Sorry about that. I did a search, and when the top result was the issue, I didn't look further.
One option would be to change the name to match the kernel version. Another option would be put it in kernel instead of kernel-core. Another option would be to have a versioned name in kernel-core and a symlink to it with the normal name in kernel.
I vote for one. There's a file for each installed kernel, and upon kernel removal, it just disappears without any checks to see if there are other kernels needing the file.
I would be happy to hear more feedback on this from people. I am trying to decide on the best course to take (this file changes rarely and last changed in 2005). I plan to put something in place by rc1 next Monday.
I'd lean towards having COPYING in the kernel subpackage and installing it in a versioned directory - trading a very small amount of disk space for upgrade safety and simplicity.
I think the idea of naming the file COPYING-$kver might be better than putting it in the versioned kernel directory. Simply because users know that '/usr/share/licenses/<pkg>' contains licensing information.
Lo! On 10.04.2018 14:50, Justin Forbes wrote:
I think the idea of naming the file COPYING-$kver might be better than putting it in the versioned kernel directory. Simply because users know that '/usr/share/licenses/<pkg>' contains licensing information.
FWIW: Is shipping the new COPYING file (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPY... ) really enough to comply with the Fedora packaging/licensing guidelines? I tend to think we at least need to ship the first two files that are mentioned in it (and maybe a file that explains the "and Redistributable, no modification permitted" part in the license field of the specfile). Then maybe /usr/share/licenses/kernel/$kver/ directory might make sense; maybe other files from the LICENSES directory (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICE... ) should be included there as well. Or they should go to the docs subpackage (btw: isn't it time to have one again regularly now that Documentation/ and the tools to process it got revamped?)
CU, knurd
Is there an easy work-around for this issue with 4.17.0-0.rc0.git4.1 on Rawhide?
Mike
On Wed, Apr 11, 2018 at 20:41:03 -0400, Michael Hill mdhillca@gmail.com wrote:
Is there an easy work-around for this issue with 4.17.0-0.rc0.git4.1 on Rawhide?
The problem is fixed with kernel-core-4.17.0-0.rc0.git7.1.fc29. That won't be in the compose running right now, but should be in future ones. You can grab a copy now using: koji download-build --arch=noarch --arch=x86_64 kernel-4.17.0-0.rc0.git7.1.fc29 (Change x86_64 to what makes sense for you.)
On Thu, Apr 12, 2018 at 12:28 AM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Apr 11, 2018 at 20:41:03 -0400, Michael Hill mdhillca@gmail.com wrote:
Is there an easy work-around for this issue with 4.17.0-0.rc0.git4.1 on Rawhide?
The problem is fixed with kernel-core-4.17.0-0.rc0.git7.1.fc29. That won't be in the compose running right now, but should be in future ones. You can grab a copy now using: koji download-build --arch=noarch --arch=x86_64 kernel-4.17.0-0.rc0.git7.1.fc29 (Change x86_64 to what makes sense for you.)
Thanks, Bruno.
Mike
On Mon, Apr 09, 2018 at 16:19:57 -0500, Justin Forbes jforbes@redhat.com wrote:
I would be happy to hear more feedback on this from people. I am trying to decide on the best course to take (this file changes rarely and last changed in 2005). I plan to put something in place by rc1 next Monday.
I think the main thing is that people be able to upgrade kernels without having to do anything special. I doubt many people actually look at that file, so we just need something that covers our legal obligations. Doing something complicated to make sure the original name still works probably isn't going to add any value and will make things more fragile.
kernel@lists.fedoraproject.org
-
Björn 'besser82' Esser -
Bruno Wolff III -
François Cami -
Justin Forbes -
Michael Hill -
stan -
Thorsten Leemhuis