Created attachment 324160 [details] "strace patch -p0 < test.patch" output log The new sys-devel/patch-2.7 is having problems applying patches when the running kernel has CONFIG_SECURITY_SELINUX enabled. I have only tested & reproduced this on a vanilla non-selinux setup (that just happens to have SECURITY_SELINUX enabled in the kernel, because it's on by default). I don't know anything about selinux, if I'm honest. ANYWAY-- Applying a patch fails like so: # patch -p0 < test.patch patching file bar patch: setting attributes for ./bar.o84LKu5: Operation not supported # I have tested on a few filesystems, it fails on ext2, ext4, and reiserfs. It succeeds on tmpfs. I did some research and it is this commit that causes the breakage: http://git.savannah.gnu.org/cgit/patch.git/commit/?id=76d0e43140e83602ecca0073f2ee5515c3a9613b This issue can be worked around by passing EXTRA_ECONF="--disable-xattr" when emerging patch-2.7. I have attached the strace output that shows the failure when setting the selinux-related attributes. My testing here was just with plain patch from CLI, but this also affects any use of patch via portage. Many users are finding portage nearly completely broken until they downgrade patch back to 2.6.1.
do you have xattr support enabled in your kernel for those filesystems ? please attach your kernel .config.
Commit message: Add USE=xattr flag http://sources.gentoo.org/sys-devel/patch/patch-2.7.ebuild?r1=1.1&r2=1.2
It only fails when extended attributes are disabled on the FS driver. I have actually only tested that bit on ext2 so far but I assume it's the same on others.
Created attachment 324300 [details] "emerge =portage-2.2.0_alpha128" failure This xattr USE flag helps, but just to be clear-- if USE=xattr is still enabled but the FS on /var/tmp/portage (or wherever patch is writing its result) does not support xattr, it is fatal. Patch errors out and emerge errors out. If doing a basic patch test from CLI, the patch result is never written to the filesystem.
can you try this snapshot: ftp://alpha.gnu.org/gnu/patch/patch-2.7.0.21-89e5.tar.gz it should have this bug fixed
Yes this snapshot works perfectly
should be all set now in the tree; thanks for the report! Commit message: Version bump http://sources.gentoo.org/sys-devel/patch/patch-2.7.1.ebuild?rev=1.1