Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 573920 - sys-apps/portage: eapply_user fails if no *.{patch,diff} files in directory /etc/portage/patches/<cat>/<pkg> but directory exists
Summary: sys-apps/portage: eapply_user fails if no *.{patch,diff} files in directory /...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 579358 (view as bug list)
Depends on:
Blocks: portage-2.3.0
  Show dependency tree
 
Reported: 2016-02-05 12:44 UTC by Thomas Deutschmann
Modified: 2016-04-08 17:13 UTC (History)
1 user (show)

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


Attachments
Test ebuild demonstrating the problem (testpkg-0.0.1.ebuild,465 bytes, text/plain)
2016-02-05 16:12 UTC, Thomas Deutschmann
Details
Jason's patch from comment 5 in git format (proposed_patch_573920c5.patch,1.30 KB, patch)
2016-03-07 20:52 UTC, Thomas Deutschmann
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann gentoo-dev Security 2016-02-05 12:44:22 UTC
>>> Emerging (3 of 3) net-libs/gnutls-3.3.21::gentoo
 * gnutls-3.3.21.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...             [ ok ]
>>> Unpacking source...
>>> Unpacking gnutls-3.3.21.tar.xz to /var/tmp/portage/net-libs/gnutls-3.3.21/work
>>> Source unpacked in /var/tmp/portage/net-libs/gnutls-3.3.21/work
>>> Preparing source in /var/tmp/portage/net-libs/gnutls-3.3.21/work/gnutls-3.3.21 ...
 * Applying gnutls-3.3.19-build-allow-installing-man-1-even-with-disable-doc.patch ...                           [ ok ]
 * ERROR: net-libs/gnutls-3.3.21::gentoo failed (prepare phase):
 *   No *.{patch,diff} files in directory /etc/portage/patches/net-libs/gnutls
 *
 * Call stack:
 *            ebuild.sh, line  133:  Called src_prepare
 *          environment, line 3381:  Called default
 *   phase-functions.sh, line  805:  Called default_src_prepare
 *   phase-functions.sh, line  870:  Called __eapi6_src_prepare
 *          environment, line  337:  Called eapply_user
 *          environment, line  902:  Called eapply '/etc/portage/patches/net-libs/gnutls'
 *          environment, line  876:  Called die
 * The specific snippet of code:
 *               [[ -z ${files[@]} ]] && die "No *.{patch,diff} files in directory ${f}";



# ls -lv /etc/portage/patches/net-libs/gnutls
total 0

(The folder exists but is empty)
Comment 1 Lars Wendler (Polynomial-C) gentoo-dev 2016-02-05 15:23:38 UTC
Most likely an EAPI-6 bug.
Comment 2 Thomas Deutschmann gentoo-dev Security 2016-02-05 16:12:39 UTC
Created attachment 424686 [details]
Test ebuild demonstrating the problem

See the simple test ebuild.

It works until you run

# mkdir -p /etc/portage/patches/app-misc/testpkg"

If you have a patch dir without any patch or diff files, emerge will fail.


Portage 2.2.27 (python 3.4.3-final-0, default/linux/amd64/13.0, gcc-5.3.0, glibc-2.22-r1, 4.4.1-gentoo x86_64)
=================================================================
System uname: Linux-4.4.1-gentoo-x86_64-Intel-R-_Core-TM-_i7-3770K_CPU_@_3.50GHz-with-gentoo-2.2
KiB Mem:     4023096 total,   1299376 free
KiB Swap:    1048572 total,   1048572 free
Timestamp of repository gentoo: Fri, 05 Feb 2016 15:15:01 +0000
sh bash 4.3_p42-r2
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p42-r2::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.22.1::gentoo
dev-lang/python:          2.7.11-r2::gentoo, 3.4.3-r7::gentoo, 3.5.1-r2::gentoo
dev-util/cmake:           3.4.3::gentoo
dev-util/pkgconfig:       0.29::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.20.4::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.69-r1::gentoo
sys-devel/automake:       1.13.4-r1::gentoo, 1.14.1-r1::gentoo, 1.15-r1::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            5.3.0::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r1::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22-r1::gentoo
Comment 3 Jason A. Donenfeld archtester Gentoo Infrastructure gentoo-dev Security 2016-03-06 22:41:12 UTC
I can confirm the existence of this bug.
Comment 4 Jason A. Donenfeld archtester Gentoo Infrastructure gentoo-dev Security 2016-03-06 22:51:23 UTC
It's because of this line in phase-helpers.sh:

    [[ -z ${files[@]} ]] && die "No *.{patch,diff} files in directory ${f}"

This is probably the right behavior for eapply, but not for eapply_user.
Comment 5 Jason A. Donenfeld archtester Gentoo Infrastructure gentoo-dev Security 2016-03-06 22:57:32 UTC
Here you go.

--- a/phase-helpers.sh	2015-12-29 22:53:50.000000000 +0100
+++ b/phase-helpers.sh	2016-03-06 23:57:02.639848608 +0100
@@ -1089,6 +1089,10 @@
 		local basedir=${PORTAGE_CONFIGROOT%/}/etc/portage/patches
 
 		local d applied
+		local LC_ALL=POSIX
+		local prev_shopt=$(shopt -p nullglob)
+		shopt -s nullglob
+
 		# possibilities:
 		# 1. ${CATEGORY}/${P}-${PR} (note: -r0 desired to avoid applying
 		#    ${P} twice)
@@ -1096,12 +1100,14 @@
 		# 3. ${CATEGORY}/${PN}
 		# all of the above may be optionally followed by a slot
 		for d in "${basedir}"/${CATEGORY}/{${P}-${PR},${P},${PN}}{,:${SLOT%/*}}; do
-			if [[ -d ${d} ]]; then
+			if [[ -n $(echo ${d}/*.diff) || -n $(echo ${d}/*.patch) ]]; then
 				eapply "${d}"
 				applied=1
 			fi
 		done
 
+		${prev_shopt}
+
 		[[ -n ${applied} ]] && ewarn "User patches applied."
 	}
 fi
Comment 6 Thomas Deutschmann gentoo-dev Security 2016-03-07 20:52:30 UTC
Created attachment 427696 [details, diff]
Jason's patch from comment 5 in git format

Ulrich (ulm) requested the patch in git format. Here it is.
Comment 8 Zac Medico gentoo-dev 2016-03-14 03:41:17 UTC
Fixed in 2.2.28.
Comment 9 Lars Wendler (Polynomial-C) gentoo-dev 2016-04-08 17:13:24 UTC
*** Bug 579358 has been marked as a duplicate of this bug. ***