[gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

[gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

All,

It looks like that sometime around Linux 3.15, some kind of a quirk was
introduced where a patch that contains the removal of a symlink followed by the
addition of a file with the same name as the symlink causes patch's --dry-run
phase to fail, which kills 'epatch'.  See Bug #507656.

A workaround was added to kernel-2.eclass, around line 1093, that hardcodes a
check for sys-kernel/git-sources, to avoid this issue.  Well,
sys-kernel/mips-sources is also affected by the same issue.  I'm close to
releasing a newer mips-sources, having spent the last few months
re-writing/refactoring chunks of old SGI IP27/BRIDGE code, and rather than add
another hardcode to kernel-2, I instead created a new variable, K_FROM_GIT,
that will replace the hardcode.

When set to a value, it triggers the workaround, which still affects current
kernels.  This results in a cleaner implementation instead of a hardcoded
ebuild, should future kernel packages sourced from a git repo get added.

Patch is attached for review.

Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[-- Attachment #2: kernel-2_eclass-from-git.diff --]
[-- Type: text/x-patch, Size: 1258 bytes --]

--- /usr/portage/eclass/kernel-2.eclass.orig	2016-08-19 07:44:46.149376480 -0400
+++ /usr/portage/eclass/kernel-2.eclass	2016-08-19 08:29:50.729377972 -0400
@@ -49,6 +49,9 @@
 # 						  as a result the user cannot choose to apply those patches.
 # K_EXP_GENPATCHES_LIST	- A list of patches to pick from "experimental" to apply when
 # 						  the USE flag is unset and K_EXP_GENPATCHES_PULL is set.
+# K_FROM_GIT - If set, this variable signals that the kernel sources derives from a git tree and special
+#	    handling will be applied so that any patches that are applied will actually apply.
+#
 # K_GENPATCHES_VER		- The version of the genpatches tarball(s) to apply.
 #						  A value of "5" would apply genpatches-2.6.12-5 to
 #						  my-sources-2.6.12.ebuild
@@ -1090,7 +1093,7 @@ unipatch() {
 			#                                                                  #
 			# https://bugs.gentoo.org/show_bug.cgi?id=507656                   #
 			####################################################################
-			if [[ ${PN} == "git-sources" ]] ; then
+			if [[ -n ${K_FROM_GIT} ]] ; then
 				if [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) &&
 					${RELEASETYPE} == -rc ]] ; then
 					ebegin "Applying ${i/*\//} (-p1)"

Re: [gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1541 bytes --]

On 08/20/2016 05:13 AM, Joshua Kinard wrote:
> All,
> 
> It looks like that sometime around Linux 3.15, some kind of a quirk was
> introduced where a patch that contains the removal of a symlink followed by the
> addition of a file with the same name as the symlink causes patch's --dry-run
> phase to fail, which kills 'epatch'.  See Bug #507656.
> 
> A workaround was added to kernel-2.eclass, around line 1093, that hardcodes a
> check for sys-kernel/git-sources, to avoid this issue.  Well,
> sys-kernel/mips-sources is also affected by the same issue.  I'm close to
> releasing a newer mips-sources, having spent the last few months
> re-writing/refactoring chunks of old SGI IP27/BRIDGE code, and rather than add
> another hardcode to kernel-2, I instead created a new variable, K_FROM_GIT,
> that will replace the hardcode.
> 
> When set to a value, it triggers the workaround, which still affects current
> kernels.  This results in a cleaner implementation instead of a hardcoded
> ebuild, should future kernel packages sourced from a git repo get added.
> 
> Patch is attached for review.
> 
> Thanks!
> 

lgtm, but I'm curious over the targeting of -rc releases. Are the only
releases after 15 in the 3.x series -rc? If not, you're going to run
into problems where a kernel is >=3.15 but not an rc.

Otherwise it seems better than hardcoding it imo.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] [PATCH] kernel-2.eclass: introduce K_FROM_GIT for sources that derive from git repos

[Joshua Kinard]

On 08/20/2016 20:22, Daniel Campbell wrote:
> On 08/20/2016 05:13 AM, Joshua Kinard wrote:
>> All,
>>
>> It looks like that sometime around Linux 3.15, some kind of a quirk was
>> introduced where a patch that contains the removal of a symlink followed by the
>> addition of a file with the same name as the symlink causes patch's --dry-run
>> phase to fail, which kills 'epatch'.  See Bug #507656.
>>
>> A workaround was added to kernel-2.eclass, around line 1093, that hardcodes a
>> check for sys-kernel/git-sources, to avoid this issue.  Well,
>> sys-kernel/mips-sources is also affected by the same issue.  I'm close to
>> releasing a newer mips-sources, having spent the last few months
>> re-writing/refactoring chunks of old SGI IP27/BRIDGE code, and rather than add
>> another hardcode to kernel-2, I instead created a new variable, K_FROM_GIT,
>> that will replace the hardcode.
>>
>> When set to a value, it triggers the workaround, which still affects current
>> kernels.  This results in a cleaner implementation instead of a hardcoded
>> ebuild, should future kernel packages sourced from a git repo get added.
>>
>> Patch is attached for review.
>>
>> Thanks!
>>
> 
> lgtm, but I'm curious over the targeting of -rc releases. Are the only
> releases after 15 in the 3.x series -rc? If not, you're going to run
> into problems where a kernel is >=3.15 but not an rc.
> 
> Otherwise it seems better than hardcoding it imo.

This bug smells more like a corner-case problem with patch itself, but I am not
certain yet if it's been reported upstream to the GNU folks.  Seems to affect
sources built on top of, or pulled from, git repos.  mips-sources is derived
from periodic checkouts I do from the linux-mips.org git repo (ralf/linux.git),
with custom patches stacked on top.  Without this workaround, applying the base
patches (either patch-x.y from kernel.org or the mipsgit-x.y.z-yyyymmdd* patch
I diff myself) will fail, on both -rc or stable releases.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic