[gentoo-dev] Changes for php-ext-source-r3 wrt bug 650324

[Brian Evans]

Bug 650324 noticed some inconsistencies with how user patches are applied.

Previously, it attempted to call default_src_prepare per target.
This, of course, would not reapply user patches for each target.

These patches bring this back into alignment and adjust packages which
would be negatively affected by this change.

Brian
From c0693eeafe8004ab698d2b46fa8a8c66aa1851a7 Mon Sep 17 00:00:00 2001
From: Brian Evans 
Date: Mon, 12 Mar 2018 20:19:36 -0400
Subject: [PATCH 1/7] eclass: php-ext-sources-r3 - Apply user patches to all
 targets

The original eclass copied sources as part of the exported src_unpack
and then attempted to apply default_src_prepare to every PHP_TARGET.

As the bug shows, this fails on eapply_user because that function will
only ever apply once.

Instead, eliminate the php-ext-sources-r3_src_unpack. Move the copy
function to src_prepare phase after patches were applied,
optionally disabled by PHP_EXT_SKIP_PATCHES=yes.

This eclass will only apply patches to PHP_EXT_S.

Fixes: https://bugs.gentoo.org/650324
---
 eclass/php-ext-source-r3.eclass | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index dfcec487685..22f07f8827b 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -11,7 +11,7 @@
 
 inherit autotools
 
-EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install src_test
+EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
 
 case ${EAPI} in
 	6) ;;
@@ -141,23 +141,16 @@ DEPEND="${DEPEND}
 # @ECLASS-VARIABLE: PHP_EXT_SKIP_PHPIZE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
-# By default, we run "phpize" in php-ext-source-r3_src_unpack(). Set
+# By default, we run "phpize" in php-ext-source-r3_src_prepare(). Set
 # PHP_EXT_SKIP_PHPIZE="yes" in your ebuild if you do not want to run
 # phpize (and the autoreconf that becomes necessary afterwards).
 
-# @FUNCTION: php-ext-source-r3_src_unpack
+# @ECLASS-VARIABLE: PHP_EXT_SKIP_PATCHES
+# @DEFAULT_UNSET
 # @DESCRIPTION:
-# Runs the default src_unpack and then makes a copy for each PHP slot.
-php-ext-source-r3_src_unpack() {
-	default
-
-	local slot orig_s="${PHP_EXT_S}"
-	for slot in $(php_get_slots); do
-		cp --recursive --preserve "${orig_s}" "${WORKDIR}/${slot}" || \
-			die "failed to copy sources from ${orig_s} to ${WORKDIR}/${slot}"
-	done
-}
-
+# By default, we run default_src_prepare to PHP_EXT_S.
+# Set PHP_EXT_SKIP_PATCHES="yes" in your ebuild if you
+# want to apply patches yourself.
 
 # @FUNCTION: php-ext-source-r3_src_prepare
 # @DESCRIPTION:
@@ -165,9 +158,16 @@ php-ext-source-r3_src_unpack() {
 # src_prepare() for PATCHES/eapply_user support, and then call
 # php-ext-source-r3_phpize.
 php-ext-source-r3_src_prepare() {
+	local slot orig_s="${PHP_EXT_S}"
+	if [[ "${PHP_EXT_SKIP_PATCHES}" != 'yes' ]] ; then
+		pushd "${orig_s}" > /dev/null || die
+		default
+		popd > /dev/null || die
+	fi
 	for slot in $(php_get_slots); do
+		cp --recursive --preserve "${orig_s}" "${WORKDIR}/${slot}" || \
+			die "failed to copy sources from ${orig_s} to ${WORKDIR}/${slot}"
 		php_init_slot_env "${slot}"
-		default
 		php-ext-source-r3_phpize
 	done
 }
-- 
2.16.1

From 5f6b52cdbfa4458a7ea4940b01d115c4dc2bae4c Mon Sep 17 00:00:00 2001
From: Brian Evans 
Date: Mon, 12 Mar 2018 20:29:26 -0400
Subject: [PATCH 2/7] sci-geosciences/mapserver: Apply php-ext-source-r3
 changes to src_unpack

---
 sci-geosciences/mapserver/mapserver-7.0.5.ebuild | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sci-geosciences/mapserver/mapserver-7.0.5.ebuild b/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
index 69fae655f2c..a412b4ed85e 100644
--- a/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
+++ b/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
@@ -83,12 +83,10 @@ pkg_setup() {
 }
 
 src_unpack() {
-	# unpack A and then copy the php thingies into workdir/php-slot
-	php-ext-source-r3_src_unpack
-	# HACK: and then remove it and replace by symlink
+	default
+	# HACK: Make symlinks for php targets
 	local slot
 	for slot in $(php_get_slots); do
-		rm -rf "${WORKDIR}/${slot}" || die
 		ln -s "${PHP_EXT_S}" "${WORKDIR}/${slot}" || die
 	done
 }
-- 
2.16.1

From 22aff5b20453f792966b8a3a6372bb7c3c39426e Mon Sep 17 00:00:00 2001
From: Brian Evans 
Date: Mon, 12 Mar 2018 20:31:23 -0400
Subject: [PATCH 3/7] dev-php/twig: Remove src_unpack as changes to eclass make
 it obsolete

---
 dev-php/twig/twig-1.31.0.ebuild | 9 -
 1 file changed, 9 deletions(-)

diff --git a/dev-php/twig/twig-1.31.0.ebuild b/dev-php/twig/twig-1.31.0.ebuild
index e62d3486a73..7e678f068e6 100644
--- a/dev-php/twig/twig-1.31.0.ebuild
+++ b/dev-php/twig/twig-1.31.0.ebuild
@@ -27,15 +27,6 @@ DEPEND="test? ( dev-php/phpunit )"
 # requires *specific* versions.
 RDEPEND="dev-lang/php"
 
-src_unpack() {
-	# Don't make copies 

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[Zac Medico]

On 03/11/2018 09:58 PM, M. J. Everitt wrote:
> On 12/03/18 04:53, Duncan wrote:
>> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:
>>
>>> I really don't want to spend a lot of time making revisions, and I think
>>> "unstable" communicates well enough in this case.
>> Very well then.  With robbat2's already accepted first paragraph changes 
>> it's acceptable as-is.
>>
>> Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
>> the only one who's thankful there's a steady hand at the portage wheel, 
>> even if it doesn't always come thru.  Your efforts certainly make the 
>> gentoo experience a better one! =:^)
>>
> +1 to that .. particularly through choppy waters lately .. keep up the
> good work!

You're very welcome. Thanks for your praise!
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[James Le Cuirot]

On Mon, 12 Mar 2018 13:53:34 +
Andrey Utkin  wrote:

> On Thu, Mar 08, 2018 at 05:57:35PM +0100, Jeroen Roovers wrote:
> > On Thu, 08 Mar 2018 16:40:44 +0100
> > Michał Górny  wrote:
> >   
> > > As part of that we also shouldn't deliver static libraries  
> > 
> > OK, so you want to absolutely kill dead the only current sane way
> > for developers who use Gentoo to ship static binaries to their
> > users' target systems? Drive them away to another Linux distro that
> > does support being the build platform that they need? Or force
> > everyone to use EXTRA_ECONF"--enable-static" and hope for them that
> > it works for all packages? All just because static linking
> > *between* ebuilds is bad?  
> 
> This is close to my current case. Trying (in my own time) to build a
> (hopefully elegant) demo setup of Gentoo & crossdev with static libs
> enabled, to present as an alternative to CentOS which is currently the
> build env at my job (and static linkage is the way the product is
> built now). I run into cross-compilation problems when I enable
> USE=static-libs to any extent, despite the comment in Gentoo's fake
> /usr/lib64/*.so files saying "And yes, this works in the cross-
> compiling scenario as the sysroot-ed linker will prepend the real
> path". But it's what I'd rather have resolved than have no
> USE=static-libs at all.

libtool often screws up relinking unless --with-sysroot is passed to
configure, which is something we're adding for EAPI 7. I need to take a
closer look at those fake .so files to see whether anything more needs
to be done.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Andrey Utkin]

On Thu, Mar 08, 2018 at 05:57:35PM +0100, Jeroen Roovers wrote:
> On Thu, 08 Mar 2018 16:40:44 +0100
> Michał Górny  wrote:
> 
> > As part of that we also shouldn't deliver static libraries
> 
> OK, so you want to absolutely kill dead the only current sane way for
> developers who use Gentoo to ship static binaries to their users'
> target systems? Drive them away to another Linux distro that does
> support being the build platform that they need? Or force everyone to
> use EXTRA_ECONF"--enable-static" and hope for them that it works for
> all packages? All just because static linking *between* ebuilds is bad?

This is close to my current case. Trying (in my own time) to build a
(hopefully elegant) demo setup of Gentoo & crossdev with static libs
enabled, to present as an alternative to CentOS which is currently the
build env at my job (and static linkage is the way the product is built
now). I run into cross-compilation problems when I enable
USE=static-libs to any extent, despite the comment in Gentoo's fake
/usr/lib64/*.so files saying "And yes, this works in the cross-
compiling scenario as the sysroot-ed linker will prepend the real path".
But it's what I'd rather have resolved than have no USE=static-libs at
all.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrey Utkin]

> sys-power/acpid

Taking this one.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: How to deal with git sources?

[Michael Orlitzky]

On 03/12/2018 04:29 AM, Martin Vaeth wrote:
> Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> If I'm recalling correctly a warning posted on this list, repeated calls
>> to the github tarballing API for the same commit will result in delivery
>> of tarballs with differing checksums.
> 
> This was so many many years ago in the beginning of github.
> This has long been fixed since then.

Every once in a while they still change. This is from a few weeks ago:

https://marc.info/?l=openbsd-ports=151973450514279=2

[gentoo-dev] Re: How to deal with git sources?

[Martin Vaeth]

Duncan <1i5t5.dun...@cox.net> wrote:
>
> If I'm recalling correctly a warning posted on this list, repeated calls
> to the github tarballing API for the same commit will result in delivery
> of tarballs with differing checksums.

This was so many many years ago in the beginning of github.
This has long been fixed since then.
Actually, github is just using "git archive" which produces
always the same tarball.
Only possible exception is if you use .zip instead of .tar.gz
because the former (due to FAT compatibility in the format)
has to store the timezone. So if the timezone of the github
server ever changes, the .zip "tar"ball might also change.