From: Josh Boyer <jwboyer@fedoraproject.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
twaugh@redhat.com, Git Mailing List <git@vger.kernel.org>
Subject: Re: patch-2.7.3 no longer applies relative symbolic link patches
Date: Mon, 26 Jan 2015 16:07:22 -0500 [thread overview]
Message-ID: <CA+5PVA5RdtLyRiYerG=u--bRZQ87qU0EGf7kGPMiQs9_KB3hRw@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxbY21vBbPs5qCFPT1HSBbaeS+Z2Fr9So1r3rXrMWe_ZQ@mail.gmail.com>
On Mon, Jan 26, 2015 at 3:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>
>> I went to do the Fedora 3.19-rc6 build this morning and it failed in
>> our buildsystem with:
>>
>> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
>> + case "$patch" in
>> + unxz
>> + patch -p1 -F1 -s
>> symbolic link target '../../../../../include/dt-bindings' is invalid
>> error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep)
>
> Ugh. I don't see anything we can do about this on the git side, and I
> do kind of understand why 'patch' would be worried about '..' files.
> In a perfect world, patch would parse the filename and see that it
> stays within the directory structure of the project, but that is a
> rather harder thing to do than just say "no dot-dot files".
>
> The short-term fix is likely to just use "git apply" instead of "patch".
Well, that's one fix anyway. I just removed the hunk from the local
copy of patch-3.19-rc6.xz and added the symlink manually. See why
below.
> The long-term fix? I dunno. I don't see us not using symlinks, and a
> quick check says that every *single* symlink we have in the kernel
> source tree is one that points to a different directory using ".."
> format. And while I could imagine that "patch" ends up counting the
> dot-dot entries and checking that it's all inside the same tree it is
> patching, I could also easily see patch *not* doing that. So using
> "git apply" _might_ end up being the long-term fix too.
It could, but from a distro perspective that requires either doing
'untar linux-3.N.tar.xz; cd linux-3.N; git add .; git apply
patch-3.N+1-rcX' , or just using a git tree to begin with, which then
makes all of this unnecessary anyway. Creating a git repo from a
tarball for each build is kind of silly. Some might say not just
using a git tree to build from to begin with in 2015 is also kind of
silly.
Or did I miss a way that git-apply can take a git patch and apply it
to a tree that isn't a git repo?
> I suspect that if "patch" cannot apply even old-style kernel patches
> due to the symlinks we have in the tree, and people end up having to
> use "git apply" for them, I might end up starting to just use
> rename-patches (ie using "git diff -M") for the kernel.
I'm kind of wondering why we'd generate patches at all if you have to
apply them to a git repo, but maybe people like doing things the
old-fashioned way just for the hell of it.
> I've considered that for a while already, because "patch" _does_ kind
> of understand them these days, although I think it gets the
> cross-rename case wrong because it fundamentally works on a
> file-by-file basis. But if "patch" just ends up not working at all,
> the argument for trying to maintain backwards compatibility gets
> really weak.
Yeah. I mostly wanted to give people a heads up on the issue. I'm
sure it's going to impact more than just the kernel. I think for us
it's mostly limited to the -rcX patches, because once the tarball for
the final release is out the symlink should be created by tar just
fine.
josh
next prev parent reply other threads:[~2015-01-26 21:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 16:29 patch-2.7.3 no longer applies relative symbolic link patches Josh Boyer
2015-01-26 16:32 ` Josh Boyer
2015-01-26 20:44 ` Linus Torvalds
2015-01-26 21:01 ` David Kastrup
2015-01-26 21:07 ` Josh Boyer [this message]
2015-01-26 21:30 ` Linus Torvalds
2015-01-26 21:35 ` Junio C Hamano
2015-01-26 21:50 ` Linus Torvalds
2015-01-27 15:47 ` Andreas Gruenbacher
2015-01-31 21:27 ` Andreas Gruenbacher
2015-01-26 22:15 ` Josh Boyer
2015-01-27 3:27 ` Junio C Hamano
2015-01-27 20:39 ` Junio C Hamano
2015-01-29 6:05 ` Junio C Hamano
2015-01-29 6:34 ` Junio C Hamano
2015-01-29 20:45 ` [PATCH] apply: refuse touching a file beyond symlink Junio C Hamano
2015-01-29 22:15 ` Stefan Beller
2015-01-29 23:48 ` [PATCH 2/1] apply: reject input that touches outside $cwd Junio C Hamano
2015-01-30 18:24 ` Jeff King
2015-01-30 19:07 ` Junio C Hamano
2015-01-30 19:16 ` Jeff King
2015-01-30 9:04 ` [PATCH] apply: refuse touching a file beyond symlink Christian Couder
2015-01-30 18:11 ` Jeff King
2015-01-30 19:42 ` Junio C Hamano
2015-01-30 19:46 ` Jeff King
2015-01-30 19:48 ` Junio C Hamano
2015-01-30 20:07 ` Jeff King
2015-01-30 20:32 ` Junio C Hamano
2015-01-30 20:11 ` Junio C Hamano
2015-01-30 20:16 ` Jeff King
2015-01-30 20:20 ` Junio C Hamano
2015-01-30 20:48 ` Jeff King
2015-01-30 21:10 ` Junio C Hamano
2015-01-30 21:50 ` Junio C Hamano
2015-01-27 15:26 ` patch-2.7.3 no longer applies relative symbolic link patches Andreas Gruenbacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+5PVA5RdtLyRiYerG=u--bRZQ87qU0EGf7kGPMiQs9_KB3hRw@mail.gmail.com' \
--to=jwboyer@fedoraproject.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=twaugh@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).