[gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

2016-04-19 Thread Leno Hou
Authored-by: Linda Jiang 
---
 eclass/toolchain-binutils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/toolchain-binutils.eclass b/eclass/toolchain-binutils.eclass
index a23300f..6d2dde8 100644
--- a/eclass/toolchain-binutils.eclass
+++ b/eclass/toolchain-binutils.eclass
@@ -271,6 +271,7 @@ toolchain-binutils_src_configure() {
# We used to do it for everyone, but it's slow on 32bit arches. #438522
case $(tc-arch) in
ppc|sparc|x86) myconf+=( --enable-64-bit-bfd ) ;;
+   ppc64) myconf+=( --enable-targets="powerpc-linux-gnu" ) ;;
esac
 
use multitarget && myconf+=( --enable-targets=all --enable-64-bit-bfd )
-- 
1.9.1




Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

2016-04-19 Thread Sam Jorna
On Wed, Apr 20, 2016 at 02:52:24PM +1000, Sam Jorna wrote:
> On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote:
> > On Mon, 18 Apr 2016 08:13:34 + (UTC)
> > "Patrice Clement"  wrote:
> > 
> > > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050
> > > Author: Patrice Clement  gentoo  org>
> > > AuthorDate: Mon Apr 18 06:35:31 2016 +
> > > Commit: Patrice Clement  gentoo  org>
> > > CommitDate: Mon Apr 18 07:58:13 2016 +
> > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca
> 
> ...
> 
> > > - CC on bugs
> > 
> > You're discarding important information here. This also has been
> > covered in the GLEP. The suggested solution is to copy the person into
> > downstream maintainers with appropriate explanatory description (like
> > 'upstream developer wishing to be CC-ed on bugs').
> 
> Just an FYI:
> Members of the Proxy Maintainers project decided that the inclusion of the
>  element was superfluous and that the ordering of  />
> elements was sufficient for determining bug assignment/CC'ing based on the
> bug-wranglers policy[0] (which does not explicitly mention ).

Forgot the reference (which I probably don't need anyway) but:

0: https://wiki.gentoo.org/wiki/Project:Bug-wranglers#Assigning_bug_reports

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

2016-04-19 Thread Sam Jorna
On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote:
> On Mon, 18 Apr 2016 08:13:34 + (UTC)
> "Patrice Clement"  wrote:
> 
> > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050
> > Author: Patrice Clement  gentoo  org>
> > AuthorDate: Mon Apr 18 06:35:31 2016 +
> > Commit: Patrice Clement  gentoo  org>
> > CommitDate: Mon Apr 18 07:58:13 2016 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca

...

> > -   CC on bugs
> 
> You're discarding important information here. This also has been
> covered in the GLEP. The suggested solution is to copy the person into
> downstream maintainers with appropriate explanatory description (like
> 'upstream developer wishing to be CC-ed on bugs').

Just an FYI:
Members of the Proxy Maintainers project decided that the inclusion of the
 element was superfluous and that the ordering of 
elements was sufficient for determining bug assignment/CC'ing based on the
bug-wranglers policy[0] (which does not explicitly mention ).

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Mike Frysinger
On 19 Apr 2016 22:12, Leno Hou wrote:
> --- /dev/null
> +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> @@ -0,0 +1,26 @@
> +--- configure.orig   2016-04-09 16:24:17.507053635 +
>  configure2016-04-09 16:25:41.851918142 +
> +@@ -4947,6 +4947,9 @@
> + ppc64-*linux*|powerpc64-*linux*)
> +   LD="${LD-ld} -m elf32ppclinux"
> +   ;;
> ++ppc64le-*linux*|powerpc64le-*linux*)
> ++  LD="${LD-ld} -m elf32lppclinux"
> ++  ;;

you appear to be patching libtool code.  this should be in libtool
itself. if it's a common issue, we'll want to leverage elibtoolize
here.  make a patch and stick it in eclass/ELT-patches/ppc64le/,
and then update the libtool.eclass file to apply those.  then update
opensp to call the elibtoolize function in src_prepare.
-mike


signature.asc
Description: Digital signature


[gentoo-portage-dev] [PATCH v4] Colorize packages in user sets (bug 577720)

2016-04-19 Thread Adam Mills
Three new settings were added to /etc/portage/color.map:
PKG_MERGE_USER_SET, PKG_BINARY_MERGE_USER_SET, and
PKG_NOMERGE_USER_SET. These colors are applied when the package is
selected from a set in /etc/portage/sets/

X-Gentoo-bug: 577720
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=577720
---

[PATCH v4] Created one InternalPackageSet for each root
[PATCH v3] Updates based on feedback from IRC meeting
[PATCH v2] Simplification of check_sets ref Alexander Berntsen's feedback_

 cnf/sets/portage.conf  |  1 +
 doc/config/sets.docbook|  4 +++-
 man/color.map.5| 11 ++
 man/portage.5  |  1 +
 pym/_emerge/resolver/output.py | 25 +++---
 pym/_emerge/resolver/output_helpers.py | 17 ---
 pym/portage/_sets/__init__.py  |  8 +++
 pym/portage/_sets/base.py  |  1 +
 pym/portage/output.py  | 39 ++
 9 files changed, 77 insertions(+), 30 deletions(-)

diff --git a/cnf/sets/portage.conf b/cnf/sets/portage.conf
index ac282d9..e990620 100644
--- a/cnf/sets/portage.conf
+++ b/cnf/sets/portage.conf
@@ -49,6 +49,7 @@ class = portage.sets.files.StaticFileSet
 multiset = true
 directory =  %(PORTAGE_CONFIGROOT)setc/portage/sets
 world-candidate = True
+user-set = True
 
 # Set to rebuild all packages that need a preserved lib that only remains due
 # to FEATURES=preserve-libs
diff --git a/doc/config/sets.docbook b/doc/config/sets.docbook
index 749b775..02135d6 100644
--- a/doc/config/sets.docbook
+++ b/doc/config/sets.docbook
@@ -57,6 +57,8 @@
is missing)
world-candidate, 
which determines if
given package should be added to the 
world set
+   user-set, which 
determines if
+   given package should be colorized as a user 
set


Some handler classes might require additional options 
for their configuration,
@@ -93,7 +95,7 @@
but to indicate that the section should generate 
multiple sets it's
also necessary to set the multiset 
option to 
true. The 
world-candidate
-   option also supported like with 
+   and user-set options are also 
supported like with
single sets (they'll apply to all sets generated by the 
section).


diff --git a/man/color.map.5 b/man/color.map.5
index 5543628..39f23f7 100644
--- a/man/color.map.5
+++ b/man/color.map.5
@@ -46,6 +46,9 @@ Defines color used for satisfied blockers.
 \fBPKG_MERGE\fR = \fI"darkgreen"\fR
 Defines color used for packages planned to be merged.
 .TP
+\fBPKG_MERGE_USER_SET\fR = \fI"darkgreen"\fR
+Defines color used for packages planned to be merged from a user defined set.
+.TP
 \fBPKG_MERGE_SYSTEM\fR = \fI"darkgreen"\fR
 Defines color used for system packages planned to be merged.
 .TP
@@ -55,6 +58,10 @@ Defines color used for world packages planned to be merged.
 \fBPKG_BINARY_MERGE\fR = \fI"purple"\fR
 Defines color used for packages planned to be merged using a binary package.
 .TP
+\fBPKG_BINARY_MERGE_USER_SET\fR = \fI"purple"\fR
+Defines color used for packages planned to be merged using a binary package
+from a user defined set.
+.TP
 \fBPKG_BINARY_MERGE_SYSTEM\fR = \fI"purple"\fR
 Defines color used for system packages planned to be merged using a binary
 package.
@@ -66,6 +73,10 @@ package.
 \fBPKG_NOMERGE\fR = \fI"darkblue"\fR
 Defines color used for packages not planned to be merged.
 .TP
+\fBPKG_NOMERGE_USER_SET\fR = \fI"darkblue"\fR
+Defines color used for packages not planned to be merged from a user defined
+set.
+.TP
 \fBPKG_NOMERGE_SYSTEM\fR = \fI"darkblue"\fR
 Defines color used for system packages not planned to be merged.
 .TP
diff --git a/man/portage.5 b/man/portage.5
index 7c2a8f7..3cc1f07 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -1114,6 +1114,7 @@ class = portage.sets.files.StaticFileSet
 multiset = true
 directory =  %(PORTAGE_CONFIGROOT)setc/portage/sets
 world-candidate = True
+user-set = True
 
 [module-rebuild]
 class = portage.sets.dbapi.OwnerSet
diff --git a/pym/_emerge/resolver/output.py b/pym/_emerge/resolver/output.py
index 400617d..7c70a3e 100644
--- a/pym/_emerge/resolver/output.py
+++ b/pym/_emerge/resolver/output.py
@@ -271,6 +271,8 @@ class Display(object):
return 
colorize("PKG_BINARY_MERGE_SYSTEM", pkg_str)
elif pkg_info.world:
return 
colorize("PKG_BINARY_MERGE_WORLD", pkg_str)
+   elif pkg_info.user_set:
+   return 
colorize("PKG_BINARY_MERGE_USER_SET", pkg_str)

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Mike Frysinger
On 19 Apr 2016 04:02, Anthony G. Basile wrote:
> On 4/19/16 1:41 AM, Mike Frysinger wrote:
> > i waited until the known bugs died down.  i don't have access to a
> > tinderbox system myself.
> 
> you didn't notice that coreutils and systemd/udev/eudev broke?

i had pushed the coreutils issue upstream, but i thought it was fixed
already (via configure checks).  i don't run those other packages.

> but a heads up would have been useful

certainly.  i usually do it based on how much on an impat a change
will have.  i didn't think this would spawn as many bugs as it had
(since the incoming rate had slowed/stopped), but i misjudged.

> > not today, but as i said, we want to move multiple libraries (at least
> > glibc, uClibc, musl, and bionic) in that direction.  the current behavior
> > violates the POSIX standard.
> 
> i took a look at opengroup.org and it seems posix is silent on the
> matter.

POSIX does not permit sys/types.h inclusion to export things it doesn't
define.  since it doesn't define major/minor/makedev, including them in
the export is a standards violation.
-mike


signature.asc
Description: Digital signature


[gentoo-dev] l10n.eclass: update l10n_find_plocales_changes()

2016-04-19 Thread rindeal
​
Hello everybody,

I've updated `l10n_find_plocales_changes()` from l10n.eclass. Please review
the change.

GitHub PR: https://github.com/gentoo/gentoo/pull/1308


Regards

Jan


Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Dirkjan Ochtman
On Apr 19, 2016 6:28 PM, "Anthony G. Basile"  wrote:
> yeah we need to buy him a drink or something really.  i'd say make him a
> dev but i'm not sure i'd inflict that punishment on anyone :P

+1 make him a dev.

Cheers,

Dirkjan


Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Anthony G. Basile
On 4/19/16 8:07 AM, Alexis Ballier wrote:
> On Tue, 19 Apr 2016 01:41:06 -0400
> Mike Frysinger  wrote:
> 
>> On 19 Apr 2016 04:21, Mart Raudsepp wrote:
>>> Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike
>>> Frysinger:  
 On 16 Apr 2016 09:23, Patrick Lauer wrote:  
> So why on earth are we applying a random patch that upstream is
> not using  

 not everyone uses glibc, and glibc *is* moving in this
 direction.  Gentoo
 is simply accelerating the change ... otherwise glibc will take
 longer to do the actual migration.  
>>>
>>> You don't need to break everyone's ~arch for dubious glibc benefits,
>>> which could be done by a p.masked version and a tinderbox run.
>>> I am not your tinderbox dummy having to waste time on this to
>>> maintain my own ~arch stuff.  
>>
>> i waited until the known bugs died down.  i don't have access to a
>> tinderbox system myself.
> 
> just for the record: I dont have access to a tinderbox system myself
> either but I usually ask Toralf by ccing him on bugs where I need it
> and he is pretty diligent on providing data. kudos to him.
> 

+1

yeah we need to buy him a drink or something really.  i'd say make him a
dev but i'm not sure i'd inflict that punishment on anyone :P

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
On Tue, Apr 19, 2016 at 10:51 PM, Leno Hou  wrote:

> On Tue, Apr 19, 2016 at 10:36 PM, Michał Górny  wrote:
>
>> On Tue, 19 Apr 2016 22:32:51 +0800
>> Leno Hou  wrote:
>>
>> > On Tue, Apr 19, 2016 at 10:20 PM, Michał Górny 
>> wrote:
>> >
>> > > On Tue, 19 Apr 2016 22:12:59 +0800
>> > > Leno Hou  wrote:
>> > >
>> > > > ---
>> > > >  .../opensp-1.5.2-configure-with-ppc64le.patch  | 26
>> > > ++
>> > > >  app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
>> > > >  app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
>> > > >  3 files changed, 29 insertions(+), 1 deletion(-)
>> > > >  create mode 100644
>> > > app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
>> > > >
>> > > > diff --git
>> > > a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
>> > > b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
>> > > > new file mode 100644
>> > > > index 000..e1c8bef
>> > > > --- /dev/null
>> > > > +++
>> b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
>> > > > @@ -0,0 +1,26 @@
>> > > > +--- configure.orig   2016-04-09 16:24:17.507053635 +
>> > > >  configure2016-04-09 16:25:41.851918142 +
>> > > > +@@ -4947,6 +4947,9 @@
>> > > > + ppc64-*linux*|powerpc64-*linux*)
>> > > > +   LD="${LD-ld} -m elf32ppclinux"
>> > > > +   ;;
>> > > > ++ppc64le-*linux*|powerpc64le-*linux*)
>> > > > ++  LD="${LD-ld} -m elf32lppclinux"
>> > > > ++  ;;
>> > > > + s390x-*linux*)
>> > > > +   LD="${LD-ld} -m elf_s390"
>> > > > +   ;;
>> > > > +@@ -4960,9 +4963,12 @@
>> > > > + x86_64-*linux*)
>> > > > +   LD="${LD-ld} -m elf_x86_64"
>> > > > +   ;;
>> > > > +-ppc*-*linux*|powerpc*-*linux*)
>> > > > ++ppc64-*linux*|powerpc64-*linux*)
>> > > > +   LD="${LD-ld} -m elf64ppc"
>> > > > +   ;;
>> > > > ++ppc64le-*linux*|powerpc64le-*linux*)
>> > > > ++  LD="${LD-ld} -m elf64lppc"
>> > > > ++  ;;
>> > > > + s390*-*linux*)
>> > > > +   LD="${LD-ld} -m elf64_s390"
>> > > > +   ;;
>> > >
>> > > Isn't that the generic kind of problem usually fixed via elibtoolize?
>> > >
>> >
>> >  How to fix it via elibtoolize ? Thanks if you give me in detail ;-)
>>
>> I don't know the details, I just know it does some random common
>> patching to configure files. Take a look at libtool.eclass and
>> ELT-patches.
>
>
> Seems can't  fix this in libtool.eclass and ELT-patches.
>
>

How goes today ? I've got strict on some metadata.xml stuffs with github PRs
QA check
 ..

-Leno Hou


Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
On Tue, Apr 19, 2016 at 10:36 PM, Michał Górny  wrote:

> On Tue, 19 Apr 2016 22:32:51 +0800
> Leno Hou  wrote:
>
> > On Tue, Apr 19, 2016 at 10:20 PM, Michał Górny 
> wrote:
> >
> > > On Tue, 19 Apr 2016 22:12:59 +0800
> > > Leno Hou  wrote:
> > >
> > > > ---
> > > >  .../opensp-1.5.2-configure-with-ppc64le.patch  | 26
> > > ++
> > > >  app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
> > > >  app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
> > > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > >  create mode 100644
> > > app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > > >
> > > > diff --git
> > > a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > > b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > > > new file mode 100644
> > > > index 000..e1c8bef
> > > > --- /dev/null
> > > > +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > > > @@ -0,0 +1,26 @@
> > > > +--- configure.orig   2016-04-09 16:24:17.507053635 +
> > > >  configure2016-04-09 16:25:41.851918142 +
> > > > +@@ -4947,6 +4947,9 @@
> > > > + ppc64-*linux*|powerpc64-*linux*)
> > > > +   LD="${LD-ld} -m elf32ppclinux"
> > > > +   ;;
> > > > ++ppc64le-*linux*|powerpc64le-*linux*)
> > > > ++  LD="${LD-ld} -m elf32lppclinux"
> > > > ++  ;;
> > > > + s390x-*linux*)
> > > > +   LD="${LD-ld} -m elf_s390"
> > > > +   ;;
> > > > +@@ -4960,9 +4963,12 @@
> > > > + x86_64-*linux*)
> > > > +   LD="${LD-ld} -m elf_x86_64"
> > > > +   ;;
> > > > +-ppc*-*linux*|powerpc*-*linux*)
> > > > ++ppc64-*linux*|powerpc64-*linux*)
> > > > +   LD="${LD-ld} -m elf64ppc"
> > > > +   ;;
> > > > ++ppc64le-*linux*|powerpc64le-*linux*)
> > > > ++  LD="${LD-ld} -m elf64lppc"
> > > > ++  ;;
> > > > + s390*-*linux*)
> > > > +   LD="${LD-ld} -m elf64_s390"
> > > > +   ;;
> > >
> > > Isn't that the generic kind of problem usually fixed via elibtoolize?
> > >
> >
> >  How to fix it via elibtoolize ? Thanks if you give me in detail ;-)
>
> I don't know the details, I just know it does some random common
> patching to configure files. Take a look at libtool.eclass and
> ELT-patches.


Seems can't  fix this in libtool.eclass and ELT-patches.

-Leno Hou


Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Michał Górny
On Tue, 19 Apr 2016 22:32:51 +0800
Leno Hou  wrote:

> On Tue, Apr 19, 2016 at 10:20 PM, Michał Górny  wrote:
> 
> > On Tue, 19 Apr 2016 22:12:59 +0800
> > Leno Hou  wrote:
> >  
> > > ---
> > >  .../opensp-1.5.2-configure-with-ppc64le.patch  | 26  
> > ++  
> > >  app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
> > >  app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
> > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > >  create mode 100644  
> > app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch  
> > >
> > > diff --git  
> > a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch  
> > > new file mode 100644
> > > index 000..e1c8bef
> > > --- /dev/null
> > > +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > > @@ -0,0 +1,26 @@
> > > +--- configure.orig   2016-04-09 16:24:17.507053635 +
> > >  configure2016-04-09 16:25:41.851918142 +
> > > +@@ -4947,6 +4947,9 @@
> > > + ppc64-*linux*|powerpc64-*linux*)
> > > +   LD="${LD-ld} -m elf32ppclinux"
> > > +   ;;
> > > ++ppc64le-*linux*|powerpc64le-*linux*)
> > > ++  LD="${LD-ld} -m elf32lppclinux"
> > > ++  ;;
> > > + s390x-*linux*)
> > > +   LD="${LD-ld} -m elf_s390"
> > > +   ;;
> > > +@@ -4960,9 +4963,12 @@
> > > + x86_64-*linux*)
> > > +   LD="${LD-ld} -m elf_x86_64"
> > > +   ;;
> > > +-ppc*-*linux*|powerpc*-*linux*)
> > > ++ppc64-*linux*|powerpc64-*linux*)
> > > +   LD="${LD-ld} -m elf64ppc"
> > > +   ;;
> > > ++ppc64le-*linux*|powerpc64le-*linux*)
> > > ++  LD="${LD-ld} -m elf64lppc"
> > > ++  ;;
> > > + s390*-*linux*)
> > > +   LD="${LD-ld} -m elf64_s390"
> > > +   ;;  
> >
> > Isn't that the generic kind of problem usually fixed via elibtoolize?
> >  
> 
>  How to fix it via elibtoolize ? Thanks if you give me in detail ;-)

I don't know the details, I just know it does some random common
patching to configure files. Take a look at libtool.eclass and
ELT-patches.

-- 
Best regards,
Michał Górny



pgpaNjAkkTqzW.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
On Tue, Apr 19, 2016 at 10:20 PM, Michał Górny  wrote:

> On Tue, 19 Apr 2016 22:12:59 +0800
> Leno Hou  wrote:
>
> > ---
> >  .../opensp-1.5.2-configure-with-ppc64le.patch  | 26
> ++
> >  app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
> >  app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
> >  3 files changed, 29 insertions(+), 1 deletion(-)
> >  create mode 100644
> app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> >
> > diff --git
> a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > new file mode 100644
> > index 000..e1c8bef
> > --- /dev/null
> > +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> > @@ -0,0 +1,26 @@
> > +--- configure.orig   2016-04-09 16:24:17.507053635 +
> >  configure2016-04-09 16:25:41.851918142 +
> > +@@ -4947,6 +4947,9 @@
> > + ppc64-*linux*|powerpc64-*linux*)
> > +   LD="${LD-ld} -m elf32ppclinux"
> > +   ;;
> > ++ppc64le-*linux*|powerpc64le-*linux*)
> > ++  LD="${LD-ld} -m elf32lppclinux"
> > ++  ;;
> > + s390x-*linux*)
> > +   LD="${LD-ld} -m elf_s390"
> > +   ;;
> > +@@ -4960,9 +4963,12 @@
> > + x86_64-*linux*)
> > +   LD="${LD-ld} -m elf_x86_64"
> > +   ;;
> > +-ppc*-*linux*|powerpc*-*linux*)
> > ++ppc64-*linux*|powerpc64-*linux*)
> > +   LD="${LD-ld} -m elf64ppc"
> > +   ;;
> > ++ppc64le-*linux*|powerpc64le-*linux*)
> > ++  LD="${LD-ld} -m elf64lppc"
> > ++  ;;
> > + s390*-*linux*)
> > +   LD="${LD-ld} -m elf64_s390"
> > +   ;;
>
> Isn't that the generic kind of problem usually fixed via elibtoolize?
>

 How to fix it via elibtoolize ? Thanks if you give me in detail ;-)

--
> Best regards,
> Michał Górny
> 
>


Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Michał Górny
On Tue, 19 Apr 2016 22:12:59 +0800
Leno Hou  wrote:

> ---
>  .../opensp-1.5.2-configure-with-ppc64le.patch  | 26 
> ++
>  app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
>  app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
>  3 files changed, 29 insertions(+), 1 deletion(-)
>  create mode 100644 
> app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> 
> diff --git a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch 
> b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> new file mode 100644
> index 000..e1c8bef
> --- /dev/null
> +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> @@ -0,0 +1,26 @@
> +--- configure.orig   2016-04-09 16:24:17.507053635 +
>  configure2016-04-09 16:25:41.851918142 +
> +@@ -4947,6 +4947,9 @@
> + ppc64-*linux*|powerpc64-*linux*)
> +   LD="${LD-ld} -m elf32ppclinux"
> +   ;;
> ++ppc64le-*linux*|powerpc64le-*linux*)
> ++  LD="${LD-ld} -m elf32lppclinux"
> ++  ;;
> + s390x-*linux*)
> +   LD="${LD-ld} -m elf_s390"
> +   ;;
> +@@ -4960,9 +4963,12 @@
> + x86_64-*linux*)
> +   LD="${LD-ld} -m elf_x86_64"
> +   ;;
> +-ppc*-*linux*|powerpc*-*linux*)
> ++ppc64-*linux*|powerpc64-*linux*)
> +   LD="${LD-ld} -m elf64ppc"
> +   ;;
> ++ppc64le-*linux*|powerpc64le-*linux*)
> ++  LD="${LD-ld} -m elf64lppc"
> ++  ;;
> + s390*-*linux*)
> +   LD="${LD-ld} -m elf64_s390"
> +   ;;

Isn't that the generic kind of problem usually fixed via elibtoolize?

-- 
Best regards,
Michał Górny



pgpIP0F9BPS8i.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH v1][ 7/8] sys-libs/gdbm: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 .../files/gdbm-1.11-configure-with-ppc64le.patch   | 26 ++
 sys-libs/gdbm/gdbm-1.11.ebuild |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 sys-libs/gdbm/files/gdbm-1.11-configure-with-ppc64le.patch

diff --git a/sys-libs/gdbm/files/gdbm-1.11-configure-with-ppc64le.patch 
b/sys-libs/gdbm/files/gdbm-1.11-configure-with-ppc64le.patch
new file mode 100644
index 000..2bdba70
--- /dev/null
+++ b/sys-libs/gdbm/files/gdbm-1.11-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-09 17:02:36.818123640 +
 configure  2016-04-09 17:04:09.407071685 +
+@@ -6898,6 +6898,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -6914,9 +6917,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
diff --git a/sys-libs/gdbm/gdbm-1.11.ebuild b/sys-libs/gdbm/gdbm-1.11.ebuild
index 06ebd03..aa9d6cf 100644
--- a/sys-libs/gdbm/gdbm-1.11.ebuild
+++ b/sys-libs/gdbm/gdbm-1.11.ebuild
@@ -26,6 +26,7 @@ RDEPEND="
 EX_S="${WORKDIR}"/${EX_P}
 
 src_prepare() {
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
elibtoolize
 }
 
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 8/8] sys-process/procps: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 .../procps-3.3.10-configure-with-ppc64le.patch | 26 ++
 sys-process/procps/procps-3.3.10-r1.ebuild |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 
sys-process/procps/files/procps-3.3.10-configure-with-ppc64le.patch

diff --git 
a/sys-process/procps/files/procps-3.3.10-configure-with-ppc64le.patch 
b/sys-process/procps/files/procps-3.3.10-configure-with-ppc64le.patch
new file mode 100644
index 000..9251a09
--- /dev/null
+++ b/sys-process/procps/files/procps-3.3.10-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-09 00:44:30.728256474 +
 configure  2016-04-09 00:47:52.098589452 +
+@@ -9367,6 +9367,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -9383,9 +9386,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
diff --git a/sys-process/procps/procps-3.3.10-r1.ebuild 
b/sys-process/procps/procps-3.3.10-r1.ebuild
index f254f34..237ebda 100644
--- a/sys-process/procps/procps-3.3.10-r1.ebuild
+++ b/sys-process/procps/procps-3.3.10-r1.ebuild
@@ -34,6 +34,7 @@ src_prepare() {
epatch "${FILESDIR}"/${PN}-3.3.8-kill-neg-pid.patch # 
http://crbug.com/255209
epatch "${FILESDIR}"/${P}-pmap-unreadable.patch #404389
epatch "${FILESDIR}"/${P}-tests-no-tty.patch #461302
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
sed -i -e 's:systemd-login:systemd:' configure || die #501306
 }
 
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 5/8] sys-apps/acl: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 sys-apps/acl/acl-2.2.52-r1.ebuild  |  2 ++
 .../files/acl-2.2.52-configure-with-ppc64le.patch  | 26 ++
 2 files changed, 28 insertions(+)
 create mode 100644 sys-apps/acl/files/acl-2.2.52-configure-with-ppc64le.patch

diff --git a/sys-apps/acl/acl-2.2.52-r1.ebuild 
b/sys-apps/acl/acl-2.2.52-r1.ebuild
index d1d2169..e2112b3 100644
--- a/sys-apps/acl/acl-2.2.52-r1.ebuild
+++ b/sys-apps/acl/acl-2.2.52-r1.ebuild
@@ -31,6 +31,8 @@ src_prepare() {
|| die
strip-linguas po
 
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
+
# same as https://savannah.nongnu.org/bugs/index.php?39736
multilib_copy_sources
 }
diff --git a/sys-apps/acl/files/acl-2.2.52-configure-with-ppc64le.patch 
b/sys-apps/acl/files/acl-2.2.52-configure-with-ppc64le.patch
new file mode 100644
index 000..52fc63c
--- /dev/null
+++ b/sys-apps/acl/files/acl-2.2.52-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-09 08:34:52.432446384 +
 configure  2016-04-09 08:36:45.785578064 +
+@@ -5487,6 +5487,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -5503,9 +5506,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 6/8] sys-apps/attr: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 sys-apps/attr/attr-2.4.47-r2.ebuild|  1 +
 .../files/attr-2.4.47-configure-with-ppc64le.patch | 26 ++
 2 files changed, 27 insertions(+)
 create mode 100644 sys-apps/attr/files/attr-2.4.47-configure-with-ppc64le.patch

diff --git a/sys-apps/attr/attr-2.4.47-r2.ebuild 
b/sys-apps/attr/attr-2.4.47-r2.ebuild
index 11a6bda..2803514 100644
--- a/sys-apps/attr/attr-2.4.47-r2.ebuild
+++ b/sys-apps/attr/attr-2.4.47-r2.ebuild
@@ -29,6 +29,7 @@ src_prepare() {
include/builddefs.in \
|| die
strip-linguas -u po
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
multilib_copy_sources # https://savannah.nongnu.org/bugs/index.php?39736
 }
 
diff --git a/sys-apps/attr/files/attr-2.4.47-configure-with-ppc64le.patch 
b/sys-apps/attr/files/attr-2.4.47-configure-with-ppc64le.patch
new file mode 100644
index 000..13e8dfc
--- /dev/null
+++ b/sys-apps/attr/files/attr-2.4.47-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-09 01:41:18.087752381 +
 configure  2016-04-09 01:43:29.129086786 +
+@@ -5454,6 +5454,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -5470,9 +5473,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 4/8] net-libs/libmnl: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 .../libmnl-1.0.3-configure-with-ppc64le.patch  | 26 ++
 net-libs/libmnl/libmnl-1.0.3-r1.ebuild |  4 
 2 files changed, 30 insertions(+)
 create mode 100644 
net-libs/libmnl/files/libmnl-1.0.3-configure-with-ppc64le.patch

diff --git a/net-libs/libmnl/files/libmnl-1.0.3-configure-with-ppc64le.patch 
b/net-libs/libmnl/files/libmnl-1.0.3-configure-with-ppc64le.patch
new file mode 100644
index 000..d46bcc9
--- /dev/null
+++ b/net-libs/libmnl/files/libmnl-1.0.3-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-08 16:30:09.521850897 +
 configure  2016-04-08 16:34:25.932337241 +
+@@ -6309,6 +6309,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -6325,9 +6328,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
diff --git a/net-libs/libmnl/libmnl-1.0.3-r1.ebuild 
b/net-libs/libmnl/libmnl-1.0.3-r1.ebuild
index 4b0bbc2..aa57068 100644
--- a/net-libs/libmnl/libmnl-1.0.3-r1.ebuild
+++ b/net-libs/libmnl/libmnl-1.0.3-r1.ebuild
@@ -15,6 +15,10 @@ SLOT="0"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~amd64-linux"
 IUSE="examples static-libs"
 
+src_prepare() {
+epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
+}
+
 src_configure() {
econf $(use_enable static-libs static)
 }
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 3/8] net-firewall/iptables: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 .../iptables-1.4.21-configure-with-ppc64le.patch   | 26 ++
 net-firewall/iptables/iptables-1.4.21-r1.ebuild|  3 +++
 net-firewall/iptables/iptables-1.4.21-r2.ebuild|  2 ++
 net-firewall/iptables/iptables-1.4.21-r3.ebuild|  2 ++
 net-firewall/iptables/iptables-1.4.21-r4.ebuild|  1 +
 5 files changed, 34 insertions(+)
 create mode 100644 
net-firewall/iptables/files/iptables-1.4.21-configure-with-ppc64le.patch

diff --git 
a/net-firewall/iptables/files/iptables-1.4.21-configure-with-ppc64le.patch 
b/net-firewall/iptables/files/iptables-1.4.21-configure-with-ppc64le.patch
new file mode 100644
index 000..58ebb6a
--- /dev/null
+++ b/net-firewall/iptables/files/iptables-1.4.21-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-08 14:03:11.035208027 -0400
 configure  2016-04-08 14:05:22.270056952 -0400
+@@ -6707,6 +6707,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -6723,9 +6726,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
diff --git a/net-firewall/iptables/iptables-1.4.21-r1.ebuild 
b/net-firewall/iptables/iptables-1.4.21-r1.ebuild
index 056b1b4..288f2da 100644
--- a/net-firewall/iptables/iptables-1.4.21-r1.ebuild
+++ b/net-firewall/iptables/iptables-1.4.21-r1.ebuild
@@ -31,6 +31,9 @@ src_prepare() {
# use the saner headers from the kernel
rm -f include/linux/{kernel,types}.h
 
+   # fix the configure problem for ppc64le
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
+
# Only run autotools if user patched something
epatch_user && eautoreconf || elibtoolize
 }
diff --git a/net-firewall/iptables/iptables-1.4.21-r2.ebuild 
b/net-firewall/iptables/iptables-1.4.21-r2.ebuild
index e87e4ed..1baaf2d 100644
--- a/net-firewall/iptables/iptables-1.4.21-r2.ebuild
+++ b/net-firewall/iptables/iptables-1.4.21-r2.ebuild
@@ -35,6 +35,8 @@ src_prepare() {
rm -f include/linux/{kernel,types}.h
 
epatch "${FILESDIR}"/${P}-configure.patch #557586
+   # fix the configure problem for ppc64le
+epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
 
# Only run autotools if user patched something
epatch_user && eautoreconf || elibtoolize
diff --git a/net-firewall/iptables/iptables-1.4.21-r3.ebuild 
b/net-firewall/iptables/iptables-1.4.21-r3.ebuild
index ef4eb78..7eb801f 100644
--- a/net-firewall/iptables/iptables-1.4.21-r3.ebuild
+++ b/net-firewall/iptables/iptables-1.4.21-r3.ebuild
@@ -36,6 +36,8 @@ src_prepare() {
 
epatch "${FILESDIR}"/${P}-configure.patch #557586
epatch "${FILESDIR}"/${P}-static-connlabel-config.patch #558234
+epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
+
 
# Only run autotools if user patched something
epatch_user && eautoreconf || elibtoolize
diff --git a/net-firewall/iptables/iptables-1.4.21-r4.ebuild 
b/net-firewall/iptables/iptables-1.4.21-r4.ebuild
index 49b9bd8..27c89fe 100644
--- a/net-firewall/iptables/iptables-1.4.21-r4.ebuild
+++ b/net-firewall/iptables/iptables-1.4.21-r4.ebuild
@@ -36,6 +36,7 @@ src_prepare() {
 
epatch "${FILESDIR}"/${P}-configure.patch #557586
epatch "${FILESDIR}"/${P}-static-connlabel-config.patch #558234
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
 
# Only run autotools if user patched something
epatch_user && eautoreconf || elibtoolize
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 .../opensp-1.5.2-configure-with-ppc64le.patch  | 26 ++
 app-text/opensp/opensp-1.5.2-r3.ebuild |  3 ++-
 app-text/opensp/opensp-1.5.2-r4.ebuild |  1 +
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 
app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch

diff --git a/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch 
b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
new file mode 100644
index 000..e1c8bef
--- /dev/null
+++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
@@ -0,0 +1,26 @@
+--- configure.orig 2016-04-09 16:24:17.507053635 +
 configure  2016-04-09 16:25:41.851918142 +
+@@ -4947,6 +4947,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -4960,9 +4963,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
diff --git a/app-text/opensp/opensp-1.5.2-r3.ebuild 
b/app-text/opensp/opensp-1.5.2-r3.ebuild
index 9f97607..28c32fc 100644
--- a/app-text/opensp/opensp-1.5.2-r3.ebuild
+++ b/app-text/opensp/opensp-1.5.2-r3.ebuild
@@ -33,7 +33,8 @@ S=${WORKDIR}/${MY_P}
 src_prepare() {
epatch \
"${FILESDIR}"/${PN}-1.5-gcc34.patch \
-   "${FILESDIR}"/${P}-fix-segfault.patch
+   "${FILESDIR}"/${P}-fix-segfault.patch \
+   "${FILESDIR}"/${P}-configure-with-ppc64le.patch
 }
 
 src_configure() {
diff --git a/app-text/opensp/opensp-1.5.2-r4.ebuild 
b/app-text/opensp/opensp-1.5.2-r4.ebuild
index 2abcab3..0851155 100644
--- a/app-text/opensp/opensp-1.5.2-r4.ebuild
+++ b/app-text/opensp/opensp-1.5.2-r4.ebuild
@@ -33,6 +33,7 @@ S=${WORKDIR}/${MY_P}
 
 src_prepare() {
epatch "${FILESDIR}"/${P}-fix-segfault.patch
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
use prefix && eautoreconf
 }
 
-- 
1.9.1




[gentoo-dev] [PATCH v1][ 2/8] dev-libs/expat: Fix ppc64le configure problem

2016-04-19 Thread Leno Hou
---
 dev-libs/expat/expat-2.1.0-r5.ebuild   |  1 +
 .../files/expat-2.1.0-configure-with-ppc64le.patch | 78 ++
 2 files changed, 79 insertions(+)
 create mode 100644 
dev-libs/expat/files/expat-2.1.0-configure-with-ppc64le.patch

diff --git a/dev-libs/expat/expat-2.1.0-r5.ebuild 
b/dev-libs/expat/expat-2.1.0-r5.ebuild
index c0aca16..bb3d559 100644
--- a/dev-libs/expat/expat-2.1.0-r5.ebuild
+++ b/dev-libs/expat/expat-2.1.0-r5.ebuild
@@ -19,6 +19,7 @@ RDEPEND="abi_x86_32? ( 
!<=app-emulation/emul-linux-x86-baselibs-20130224-r6
 src_prepare() {
epatch "${FILESDIR}"/${P}-xmlwfargs.patch
epatch "${FILESDIR}"/${P}-mozilla-sanity-check-size.patch #555642
+   epatch "${FILESDIR}"/${P}-configure-with-ppc64le.patch
elibtoolize
 }
 
diff --git a/dev-libs/expat/files/expat-2.1.0-configure-with-ppc64le.patch 
b/dev-libs/expat/files/expat-2.1.0-configure-with-ppc64le.patch
new file mode 100644
index 000..2d7f01e
--- /dev/null
+++ b/dev-libs/expat/files/expat-2.1.0-configure-with-ppc64le.patch
@@ -0,0 +1,78 @@
+--- configure.orig 2016-04-13 16:49:24.906810546 +
 configure  2016-04-13 16:52:37.792699936 +
+@@ -5932,6 +5932,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -5948,9 +5951,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
+--- aclocal.m4.orig2016-04-13 16:53:39.097309462 +
 aclocal.m4 2016-04-13 16:55:33.502456982 +
+@@ -1292,6 +1292,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -1308,9 +1311,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
+--- m4/libtool.m4.org  2016-04-13 16:58:32.884276527 +
 m4/libtool.m4  2016-04-13 16:59:47.713041421 +
+@@ -1285,6 +1285,9 @@
+ ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf32ppclinux"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf32lppclinux"
++  ;;
+ s390x-*linux*)
+   LD="${LD-ld} -m elf_s390"
+   ;;
+@@ -1301,9 +1304,12 @@
+ x86_64-*linux*)
+   LD="${LD-ld} -m elf_x86_64"
+   ;;
+-ppc*-*linux*|powerpc*-*linux*)
++ppc64-*linux*|powerpc64-*linux*)
+   LD="${LD-ld} -m elf64ppc"
+   ;;
++ppc64le-*linux*|powerpc64le-*linux*)
++  LD="${LD-ld} -m elf64lppc"
++  ;;
+ s390*-*linux*|s390*-*tpf*)
+   LD="${LD-ld} -m elf64_s390"
+   ;;
-- 
1.9.1




Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Alexis Ballier
On Tue, 19 Apr 2016 01:41:06 -0400
Mike Frysinger  wrote:

> On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike
> > Frysinger:  
> > > On 16 Apr 2016 09:23, Patrick Lauer wrote:  
> > > > So why on earth are we applying a random patch that upstream is
> > > > not using  
> > > 
> > > not everyone uses glibc, and glibc *is* moving in this
> > > direction.  Gentoo
> > > is simply accelerating the change ... otherwise glibc will take
> > > longer to do the actual migration.  
> > 
> > You don't need to break everyone's ~arch for dubious glibc benefits,
> > which could be done by a p.masked version and a tinderbox run.
> > I am not your tinderbox dummy having to waste time on this to
> > maintain my own ~arch stuff.  
> 
> i waited until the known bugs died down.  i don't have access to a
> tinderbox system myself.

just for the record: I dont have access to a tinderbox system myself
either but I usually ask Toralf by ccing him on bugs where I need it
and he is pretty diligent on providing data. kudos to him.



Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Anthony G. Basile
On 4/19/16 1:41 AM, Mike Frysinger wrote:
> 
> i waited until the known bugs died down.  i don't have access to a
> tinderbox system myself.

you didn't notice that coreutils and systemd/udev/eudev broke?  anyhow,
i don't think this whole affair is as bad as i first did, its an easy
fix to pkgs.  but a heads up would have been useful.  you don't need a
full tinderbox run for glibc upgrades, just a complete rebuild of
@system in a stage3 chroot on amd64 is probably enough.

> 
> not today, but as i said, we want to move multiple libraries (at least
> glibc, uClibc, musl, and bionic) in that direction.  the current behavior
> violates the POSIX standard.
> 

i took a look at opengroup.org and it seems posix is silent on the
matter.  i might have missed something though.  musl which is sticks
pretty close to standards includes major/minor/makedev in sys/types. but
guards it behind _GNU_SOURCE or _BSD_SOURE.  i don't know what
glibc-2.23 did with types.h and sysmacros.h (did they just drop it
hard?), but proceeding as musl did doesn't seem unreasonable to me.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Mike Frysinger
On 19 Apr 2016 08:15, Michał Górny wrote:
> On Tue, 19 Apr 2016 01:41:06 -0400 Mike Frysinger wrote:
> > On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> > > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:  
> > > > On 16 Apr 2016 09:23, Patrick Lauer wrote:  
> > > > > So why on earth are we applying a random patch that upstream is not
> > > > > using  
> > > > 
> > > > not everyone uses glibc, and glibc *is* moving in this
> > > > direction.  Gentoo
> > > > is simply accelerating the change ... otherwise glibc will take
> > > > longer to do the actual migration.  
> > > 
> > > You don't need to break everyone's ~arch for dubious glibc benefits,
> > > which could be done by a p.masked version and a tinderbox run.
> > > I am not your tinderbox dummy having to waste time on this to maintain
> > > my own ~arch stuff.  
> > 
> > i waited until the known bugs died down.  i don't have access to a
> > tinderbox system myself.
> 
> Cut the nonsense. You clearly didn't even test that glibc version
> on a single system. If you did, you'd notice the core system packages
> failing to build.

i know it's asking a lot of you, but you should refrain from making claims
that not only do you obviously have no idea about but can also be trivially
refuted.  i run glibc versions starting before i commit them to the tree
and build/test packages against it constantly.  this box has built hundreds
of packages and if you look at the git tree, i fixed a number of packages
before anyone even saw the breakage.
-mike


signature.asc
Description: Digital signature


Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

2016-04-19 Thread Michał Górny
On Tue, 19 Apr 2016 01:41:06 -0400
Mike Frysinger  wrote:

> On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:  
> > > On 16 Apr 2016 09:23, Patrick Lauer wrote:  
> > > > So why on earth are we applying a random patch that upstream is not
> > > > using  
> > > 
> > > not everyone uses glibc, and glibc *is* moving in this
> > > direction.  Gentoo
> > > is simply accelerating the change ... otherwise glibc will take
> > > longer to do the actual migration.  
> > 
> > You don't need to break everyone's ~arch for dubious glibc benefits,
> > which could be done by a p.masked version and a tinderbox run.
> > I am not your tinderbox dummy having to waste time on this to maintain
> > my own ~arch stuff.  
> 
> i waited until the known bugs died down.  i don't have access to a
> tinderbox system myself.

Cut the nonsense. You clearly didn't even test that glibc version
on a single system. If you did, you'd notice the core system packages
failing to build.

-- 
Best regards,
Michał Górny



pgpChCrHybOhZ.pgp
Description: OpenPGP digital signature