Re: [gentoo-dev] [PATCH] multilib.eclass: Include /$(get_libdir) in PKG_CONFIG_SYSTEM_LIBRARY_PATH.

2020-11-23 Thread Sergei Trofimovich
On Mon, 23 Nov 2020 21:55:35 -0500
Mike Gilbert  wrote:

> From: Arfrever Frehtes Taifersar Arahesis 
> 
> Set also PKG_CONFIG_SYSTEM_INCLUDE_PATH for consistency.
> 
> Bug: https://bugs.gentoo.org/756238
> Signed-off-by: Arfrever Frehtes Taifersar Arahesis 
> ---
>  eclass/multilib.eclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 9c7042fcd29..33ca9726131 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -498,6 +498,7 @@ multilib_toolchain_setup() {
>   STRIP
>   PKG_CONFIG_LIBDIR
>   PKG_CONFIG_PATH
> + PKG_CONFIG_SYSTEM_INCLUDE_PATH
>   PKG_CONFIG_SYSTEM_LIBRARY_PATH
>   )
>  
> @@ -547,7 +548,8 @@ multilib_toolchain_setup() {
>   export CHOST=$(get_abi_CHOST $1)
>   export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
>   export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
> - export 
> PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/usr/$(get_libdir)
> + export PKG_CONFIG_SYSTEM_INCLUDE_PATH=${EPREFIX}/usr/include
> + export 
> PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/$(get_libdir):${EPREFIX}/usr/$(get_libdir)
>   fi
>  }

The patch looks good. Feel free to push.

-- 

  Sergei



Re: [gentoo-dev] Incoming >=sys-libs/timezone-data-2020d[zic-slim] breakage

2020-10-29 Thread Sergei Trofimovich
On Thu, 29 Oct 2020 19:10:00 +0100
Toralf Förster  wrote:

> On 10/29/20 10:14 AM, Sergei Trofimovich wrote:
> >You can enable new default explicitly with USE=zic-slim switch.  
> 
> will do it here at the tinderbox

Thank you! That will be very useful!

-- 

  Sergei



[gentoo-dev] Incoming >=sys-libs/timezone-data-2020d[zic-slim] breakage

2020-10-29 Thread Sergei Trofimovich
Tl;DR:

  Upstream timezone-data-2020b changed the way /usr/share/zoneinfo
  files are generated by default. Gentoo does NOT enable this new
  default to keep existing software running (so far).

  You can enable new default explicitly with USE=zic-slim switch.

  Libraries and tools that parse /usr/share/zoneinfo will break in trivial
  (crashes) or very obscure ways (DST time switch will not happen and
  will report wrong time).

What can you do:

  If you are feeling brave then enable USE=zic-slim to identify and
  fix affected packages. Sometimes bugs are specific to a timezone
  you are in. Running a testsuite is probably the best way to find
  problems.

  If you found a bug check that USE=-zic-slim makes it go away and
  report (and/or fix) it upstream and add it to the gentoo's tracker
  bug:
https://bugs.gentoo.org/749591.

What actually changed:

  From https://data.iana.org/time-zones/tzdb/NEWS:

  ```
  Release 2020b - 2020-10-06 18:35:04 -0700
  ...
  zic now defaults to '-b slim' instead of to '-b fat'.
  ```

  Mechanically both 'fat' and 'slim' are the same VER=2 (or 3 for some
  timezones) file format from 'man 5 tzfile'. But 'fat'/'slim' contents
  is different. From 'man 8 zic':

  ```
   -b bloat
  If bloat is fat, generate additional data entries that work
  around potential bugs or incompatibilities in older software,
  such as software that mishandles the 64-bit generated data.
  If bloat is slim, keep the output files small; this can help check
  for the bugs and incompatibilities.

  Although the default is currently fat, this is intended to
  change in future zic versions, as software that mishandles the
  64-bit data typically mishandles timestamps  after the year 2038
  anyway.
  ```

  Thus ideally libraries should already handle both flavours. But due
  to bugs some libraries will break.

File format spec is an RFC8536:

  https://www.rfc-editor.org/rfc/rfc8536.txt

Good luck!

-- 

  Sergei



Re: [gentoo-dev] Trying to use Python3.9 as default for my laptop

2020-10-14 Thread Sergei Trofimovich
On Thu, 15 Oct 2020 00:01:58 +0300
Alexey 'Alexxy' Shvetsov  wrote:

...
> sys-devel/gdb
> 
> So i wanna ask maintainers of this packages add python3_9 to pytargets (they 
> builds and works fine for me) or if they dont mind give me a right to do so =)

Sure. Go ahead.

-- 

  Sergei



Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280

2020-08-28 Thread Sergei Trofimovich
On Fri, 28 Aug 2020 10:10:02 +0200
Fabian Groffen  wrote:

> On 28-08-2020 08:52:09 +0100, Sergei Trofimovich wrote:
> > On Fri, 28 Aug 2020 07:37:54 +0100
> > Sergei Trofimovich  wrote:
> >   
> > > On Fri, 28 Aug 2020 08:15:47 +0200
> > > Jaco Kroon  wrote:
> > >   
> > > > Hi All,
> > > > 
> > > > https://bugs.gentoo.org/731280
> > > > 
> > > > Summary:
> > > > 
> > > > This machine uses a clang/LLVM toolchain.
> > > > Asterisk fails to compile, ./configure fails with:
> > > > 
> > > > checking for RAII support... checking for clang -fblocks...
> > > > configure: error: BlocksRuntime is required for clang, please install
> > > > libblocksruntime
> > > > 
> > > > I suspect this explains the issue:
> > > > 
> > > > https://github.com/mackyle/blocksruntime
> > > > 
> > > > I have no idea how to actually solve this.
> > > 
> > > honggfuzz also needs it as it happens to use -fblocks on clang:
> > > https://bugs.gentoo.org/729256
> > > 
> > > We need to package the library. I can give it a try.  
> > 
> > Packaged library as sys-libs/blocksruntime:
> > 
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae376c73ef197d6c7aa619e821c436ccab0cd77e
> > 
> > Usage example for app-forensics/honggfuzz:
> > 
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd841336dfdefbc14907e2d9b1eb1a1a3f5f8b8e
> >   
> 
> This is cool, but shouldn't it be something like openmp?  (e.g. blocks)

You mean when -fopenmp is present in LDFLAGS compiler itself pulls in runtime?
That would be ideal. But currently clang does not install blocks runtime.

> There is no reason blocks have to be used if not on macOS (where system
> headers use blocks features).

Sure. As with most extensions it can be avoided. Alas some projects use it
is for convenience. At least honggfuzz uses blocks with __attribute__(cleanup)
to emulate lexical scope destructors:

https://github.com/google/honggfuzz/blob/03bbc2de983f13cfcd880f72e3a56582c4f82f24/libhfcommon/util.h#L57

-- 

  Sergei



Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280

2020-08-28 Thread Sergei Trofimovich
On Fri, 28 Aug 2020 07:37:54 +0100
Sergei Trofimovich  wrote:

> On Fri, 28 Aug 2020 08:15:47 +0200
> Jaco Kroon  wrote:
> 
> > Hi All,
> > 
> > https://bugs.gentoo.org/731280
> > 
> > Summary:
> > 
> > This machine uses a clang/LLVM toolchain.
> > Asterisk fails to compile, ./configure fails with:
> > 
> > checking for RAII support... checking for clang -fblocks...
> > configure: error: BlocksRuntime is required for clang, please install
> > libblocksruntime
> > 
> > I suspect this explains the issue:
> > 
> > https://github.com/mackyle/blocksruntime
> > 
> > I have no idea how to actually solve this.  
> 
> honggfuzz also needs it as it happens to use -fblocks on clang:
> https://bugs.gentoo.org/729256
> 
> We need to package the library. I can give it a try.

Packaged library as sys-libs/blocksruntime:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae376c73ef197d6c7aa619e821c436ccab0cd77e

Usage example for app-forensics/honggfuzz:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd841336dfdefbc14907e2d9b1eb1a1a3f5f8b8e

-- 

  Sergei



Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280

2020-08-28 Thread Sergei Trofimovich
On Fri, 28 Aug 2020 08:15:47 +0200
Jaco Kroon  wrote:

> Hi All,
> 
> https://bugs.gentoo.org/731280
> 
> Summary:
> 
> This machine uses a clang/LLVM toolchain.
> Asterisk fails to compile, ./configure fails with:
> 
> checking for RAII support... checking for clang -fblocks...
> configure: error: BlocksRuntime is required for clang, please install
> libblocksruntime
> 
> I suspect this explains the issue:
> 
> https://github.com/mackyle/blocksruntime
> 
> I have no idea how to actually solve this.

honggfuzz also needs it as it happens to use -fblocks on clang:
https://bugs.gentoo.org/729256

We need to package the library. I can give it a try.

-- 

  Sergei



Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Sergei Trofimovich
On Fri, 07 Aug 2020 21:45:48 +0200
Michał Górny  wrote:

> But I suppose being sarcastic is the new norm and should be documented as 
> such.

I am not sarcastic if it was your implication.

-- 

  Sergei



Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Sergei Trofimovich
On Fri, 7 Aug 2020 14:25:04 -0400
Michael Orlitzky  wrote:

> When you ignore the devmanual and the pkgcheck warning and the 10+
> threads I've started about the issue, and make changes like...
> 
>   --- a/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
>   +++ b/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
>   @@ -1,4 +1,4 @@
>   -# Copyright 1999-2018 Gentoo Foundation
>   +# Copyright 1999-2019 Gentoo Authors
># Distributed under the terms of the GNU General Public License v2
> 
>EAPI=6
>   @@ -21,8 +21,7 @@ RDEPEND="${RDEPEND}
>   x11-apps/bitmap
>   x11-apps/iceauth
>   x11-apps/luit
>   -   x11-apps/mkfontdir
>   -   x11-apps/mkfontscale
>   +   >=x11-apps/mkfontscale-1.2.0
>   x11-apps/sessreg
> 
> 
> This is what portage does:
> 
>   $ sudo emerge -uDN @world
>   Password:
>   Calculating dependencies... done!
> 
>   emerge: there are no ebuilds to satisfy "x11-apps/mkfontdir".
>   (dependency required by "x11-base/xorg-x11-7.4-r3::gentoo"
>   [installed])
>   (dependency required by "@selected" [set])
>   (dependency required by "@world" [argument])

After PAM virtual removal and a bunch of similar large-scale
changes done by QA members I assume it's a new norm and
should be documented as such.

I ended up enabling --changed-deps by default on my systems
to make them upgradeable.

-- 

  Sergei



Re: [gentoo-dev] [PATCH 2/4] dev-haskell/cryptonite: Change USE to cpu_flags_x86_rdrand

2020-07-13 Thread Sergei Trofimovich
On Mon, 13 Jul 2020 19:11:52 +0200
"Francisco Blas Izquierdo Riera (klondike)"  wrote:

> Package-Manager: Portage-2.3.99, Repoman-2.3.23
> Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
> ---
>  dev-haskell/cryptonite/cryptonite-0.21.ebuild    | 4 ++--
>  dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild | 2 +-
>  dev-haskell/cryptonite/metadata.xml  | 1 -
>  3 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/dev-haskell/cryptonite/cryptonite-0.21.ebuild 
> b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> index 531dfe8cfb7..c3497dae415 100644
> --- a/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> +++ b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2019 Gentoo Authors
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  EAPI=7
> @@ -16,7 +16,7 @@ 
> SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
>  LICENSE="BSD"
>  SLOT="0/${PV}"
>  KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux"
> -IUSE="cpu-flags-x86-rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
> cpu_flags_x86_sse4_1 +integer-gmp"
> +IUSE="cpu_flags_x86_rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
> cpu_flags_x86_sse4_1 +integer-gmp"
>  
>  RDEPEND=">=dev-haskell/memory-0.8:=[profile?]  
>  >=dev-lang/ghc-7.4.1:=
> diff --git a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild 
> b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> index 8d097bb5cfa..3cdbcf44b91 100644
> --- a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> +++ b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> @@ -16,7 +16,7 @@ 
> SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
>  LICENSE="BSD"
>  SLOT="0/${PV}"
>  KEYWORDS="~amd64 ~x86"
> -IUSE="+cpu-flags-x86-rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
> cpu_flags_x86_sse4_1 +integer-gmp"
> +IUSE="+cpu_flags_x86_rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
> cpu_flags_x86_sse4_1 +integer-gmp"
>  
>  RDEPEND=">=dev-haskell/basement-0.0.6:=[profile?]  
>  >=dev-haskell/memory-0.14.18:=[profile?]
> diff --git a/dev-haskell/cryptonite/metadata.xml 
> b/dev-haskell/cryptonite/metadata.xml
> index c845b334ecd..8e02ebe625c 100644
> --- a/dev-haskell/cryptonite/metadata.xml
> +++ b/dev-haskell/cryptonite/metadata.xml
> @@ -29,7 +29,6 @@
>      Evaluate the security related to your requirements before using.
>  
>  
> -        allow compilation with RDRAND on 
> system and architecture that supports it
>      Whether or not to use GMP for some 
> functions
>  
>  
> -- 
> 2.26.2
> 

Looks good!

-- 

  Sergei



[gentoo-dev] dev-libs/cloog is up for grabs

2020-07-12 Thread Sergei Trofimovich
dev-libs/cloog used to be maintaned by toolchain@.

It's not used by nowadays' gcc and thus dropped to maintainer-needed.

Two open bugs:
- https://bugs.gentoo.org/595132
- https://bugs.gentoo.org/650304

Feel free to grab!

-- 

  Sergei



Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Sergei Trofimovich
On Fri, 26 Jun 2020 13:41:13 -0400
Aaron Bauman  wrote:

> On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich  
> wrote:
> >On Fri, 26 Jun 2020 11:38:58 +0200
> >Michał Górny  wrote:
> >  
> >> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote:  
> >> > On Fri, 26 Jun 2020 07:29:45 +
> >> > Michał Górny  wrote:
> >> > 
> >> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich  
> > napisał(a):
> >> > > > On Sat, 20 Jun 2020 16:29:53 +0100
> >> > > > Sergei Trofimovich  wrote:
> >> > > >  
> >> > > > > On Sat, 20 Jun 2020 16:05:38 +0200
> >> > > > > Michał Górny  wrote:
> >> > > > >   
> >> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich  
> >wrote:
> >> > > > > > > Give maintainers the chance to act and flag packages that  
> >pull in  
> >> > > > python:2.7.  
> >> > > > > > > Signed-off-by: Sergei Trofimovich 
> >> > > > > > > ---
> >> > > > > > >  profiles/package.deprecated | 4 
> >> > > > > > >  1 file changed, 4 insertions(+)
> >> > > > > > > 
> >> > > > > > > diff --git a/profiles/package.deprecated  
> >> > > > b/profiles/package.deprecated  
> >> > > > > > > index a756e845f47..bb661571962 100644
> >> > > > > > > --- a/profiles/package.deprecated
> >> > > > > > > +++ b/profiles/package.deprecated
> >> > > > > > > @@ -17,6 +17,10 @@
> >> > > > > > >  
> >> > > > > > >  #--- END OF EXAMPLES ---
> >> > > > > > >  
> >> > > > > > > +# Sergei Trofimovich  (2020-06-20)
> >> > > > > > > +# Deprecated. Consider poring to python 3 and drop  
> >support for  
> >> > > > python2.  
> >> > > > > > > +dev-lang/python:2.7
> >> > > > > > > +
> >> > > > > > >  # Sergei Trofimovich  (2020-02-22)
> >> > > > > > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3  
> >provider.  
> >> > > > > > >  # Use that instead. Or even better use none of them.  
> >It's a  
> >> > > > > > 
> >> > > > >   
> >> > > > > > It will trigger the same for packages that support *only*
> >> > > > > > Python 2.7, as well as these that support 2.7 in addition  
> >to 3  
> >> > > > because  
> >> > > > > > they have 2.7 deps.
> >> > > > > 
> >> > > > > If we expect actions by developers on both cases I don't see  
> >a  
> >> > > > problem with that.
> >> > > > 
> >> > > > Pushed as:
> >> > > >  
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> >  
> >> > > > with full text being:
> >> > > > 
> >> > > > +# Sergei Trofimovich  (2020-06-26)
> >> > > > +# Deprecated.
> >> > > > +# - optional python:2.7 dependency should be dropped if no  
> >reverse  
> >> > > > +#   dependencies are using it.
> >> > > > +# - mandatory python:2.7 depepndency will require package  
> >porting  
> >> > > > +#   or package removal if no reverse dependencies are using  
> >it.  
> >> > > > +dev-lang/python:2.7  
> >> > > 
> >> > > You've just introduced 829 CI warnings
> >> > 
> >> > That's the intention.
> >> > 
> >> > > effectively disabling the ability to distinguish *new* problems  
> >in these packages.
> >> > 
> >> > Correct. Citing above:
> >> > 
> >> > "If we expect actions by developers on both cases I don't see a   
> >problem with that."  
> >> > 
> >> > I assume we still do.
> >> 
> >> Not exactly.  You've pinpointed the wrong target.
> >> 
> >> First of all, we want people to support Python 3.  Removing support  
> >for  

Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Sergei Trofimovich
On Fri, 26 Jun 2020 19:17:50 +0200
Michał Górny  wrote:

> On Fri, 2020-06-26 at 17:47 +0100, Sergei Trofimovich wrote:
> > On Fri, 26 Jun 2020 11:38:58 +0200
> > Michał Górny  wrote:
> >   
> > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote:  
> > > > On Fri, 26 Jun 2020 07:29:45 +
> > > > Michał Górny  wrote:
> > > >     
> > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich 
> > > > >  napisał(a):
> > > > > > On Sat, 20 Jun 2020 16:29:53 +0100
> > > > > > Sergei Trofimovich  wrote:
> > > > > >  
> > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200
> > > > > > > Michał Górny  wrote:
> > > > > > >   
> > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote:
> > > > > > > > 
> > > > > > > > > Give maintainers the chance to act and flag packages that 
> > > > > > > > > pull in  
> > > > > > python:2.7.  
> > > > > > > > > Signed-off-by: Sergei Trofimovich 
> > > > > > > > > ---
> > > > > > > > >  profiles/package.deprecated | 4 
> > > > > > > > >  1 file changed, 4 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/profiles/package.deprecated  
> > > > > > b/profiles/package.deprecated  
> > > > > > > > > index a756e845f47..bb661571962 100644
> > > > > > > > > --- a/profiles/package.deprecated
> > > > > > > > > +++ b/profiles/package.deprecated
> > > > > > > > > @@ -17,6 +17,10 @@
> > > > > > > > >  
> > > > > > > > >  #--- END OF EXAMPLES ---
> > > > > > > > >  
> > > > > > > > > +# Sergei Trofimovich  (2020-06-20)
> > > > > > > > > +# Deprecated. Consider poring to python 3 and drop support 
> > > > > > > > > for  
> > > > > > python2.  
> > > > > > > > > +dev-lang/python:2.7
> > > > > > > > > +
> > > > > > > > >  # Sergei Trofimovich  (2020-02-22)
> > > > > > > > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3 
> > > > > > > > > provider.
> > > > > > > > >  # Use that instead. Or even better use none of them. It's a  
> > > > > > > > > 
> > > > > > > > 
> > > > > > >   
> > > > > > > > It will trigger the same for packages that support *only*
> > > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3  
> > > > > > > > 
> > > > > > because  
> > > > > > > > they have 2.7 deps.
> > > > > > > 
> > > > > > > If we expect actions by developers on both cases I don't see a
> > > > > > >   
> > > > > > problem with that.
> > > > > > 
> > > > > > Pushed as:
> > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> > > > > > with full text being:
> > > > > > 
> > > > > > +# Sergei Trofimovich  (2020-06-26)
> > > > > > +# Deprecated.
> > > > > > +# - optional python:2.7 dependency should be dropped if no reverse
> > > > > > +#   dependencies are using it.
> > > > > > +# - mandatory python:2.7 depepndency will require package porting
> > > > > > +#   or package removal if no reverse dependencies are using it.
> > > > > > +dev-lang/python:2.7  
> > > > > 
> > > > > You've just introduced 829 CI warnings
> > > > 
> > > > That's the intention.
> > > > 
> > > > > effectively disabling the ability to distinguish *new* problems in 
> > > > > these packages.
> > > > 
> > > > Correct. Citing above:
> > > > 
> > > > "If we expect actions by developers on both cases I don't see a  
> > > > problem with that.&q

Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Sergei Trofimovich
On Fri, 26 Jun 2020 11:38:58 +0200
Michał Górny  wrote:

> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote:
> > On Fri, 26 Jun 2020 07:29:45 +
> > Michał Górny  wrote:
> >   
> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich  
> > > napisał(a):  
> > > > On Sat, 20 Jun 2020 16:29:53 +0100
> > > > Sergei Trofimovich  wrote:
> > > >
> > > > > On Sat, 20 Jun 2020 16:05:38 +0200
> > > > > Michał Górny  wrote:
> > > > > 
> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote:  
> > > > > > > Give maintainers the chance to act and flag packages that pull in 
> > > > > > >
> > > > python:2.7.
> > > > > > > Signed-off-by: Sergei Trofimovich 
> > > > > > > ---
> > > > > > >  profiles/package.deprecated | 4 
> > > > > > >  1 file changed, 4 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/profiles/package.deprecated
> > > > b/profiles/package.deprecated
> > > > > > > index a756e845f47..bb661571962 100644
> > > > > > > --- a/profiles/package.deprecated
> > > > > > > +++ b/profiles/package.deprecated
> > > > > > > @@ -17,6 +17,10 @@
> > > > > > >  
> > > > > > >  #--- END OF EXAMPLES ---
> > > > > > >  
> > > > > > > +# Sergei Trofimovich  (2020-06-20)
> > > > > > > +# Deprecated. Consider poring to python 3 and drop support for   
> > > > > > >  
> > > > python2.
> > > > > > > +dev-lang/python:2.7
> > > > > > > +
> > > > > > >  # Sergei Trofimovich  (2020-02-22)
> > > > > > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider.
> > > > > > >  # Use that instead. Or even better use none of them. It's a  
> > > > > > >   
> > > > > >   
> > > > > 
> > > > > > It will trigger the same for packages that support *only*
> > > > > > Python 2.7, as well as these that support 2.7 in addition to 3
> > > > because
> > > > > > they have 2.7 deps.  
> > > > > 
> > > > > If we expect actions by developers on both cases I don't see a
> > > > problem with that.
> > > > 
> > > > Pushed as:
> > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> > > > with full text being:
> > > > 
> > > > +# Sergei Trofimovich  (2020-06-26)
> > > > +# Deprecated.
> > > > +# - optional python:2.7 dependency should be dropped if no reverse
> > > > +#   dependencies are using it.
> > > > +# - mandatory python:2.7 depepndency will require package porting
> > > > +#   or package removal if no reverse dependencies are using it.
> > > > +dev-lang/python:2.7
> > > 
> > > You've just introduced 829 CI warnings  
> > 
> > That's the intention.
> >   
> > > effectively disabling the ability to distinguish *new* problems in these 
> > > packages.  
> > 
> > Correct. Citing above:
> > 
> > "If we expect actions by developers on both cases I don't see a  problem 
> > with that."
> > 
> > I assume we still do.  
> 
> Not exactly.  You've pinpointed the wrong target.
> 
> First of all, we want people to support Python 3.  Removing support for
> Python 2 is a secondary goal.

What is the desired end state here? All packages that depend on
python should support python3?

> Flagging packages that support Python 2 in addition to Python 3
> and cause no trouble in py2 cleanup is doubtful.

What is "py2 cleanup"? I still struggle to understand what packages
require change and which do not. Is there one pager doc that explains
a few things for me:
- How packages are picked for masking? Maybe we can deprecate them
  instead? Or we (I) can write a bit of code that flags packages requiring
  maintainers' attention.
- What is the expected end state for the "py2 cleanup"? 

The doc would also be a good link to add to recently added "# Py2 only"
masks as well.

> Flagging packages that support 2+3 because of their revdeps is not
> helpful at all.  It's just noise to the maintainer who can't remove py2
> because of revdeps.

I agree it can be spammy if we expect to have many packages with
python2 support for an extended period of time (3+ months). If it's
seen by others as too noisy I can revert the commit now.

> Flagging dev-python/pypy* which needs py2 but is entirely outside
> the eclass system is not helpful at all.

To pick a concrete example: from what I read above I don't see why
app-misc/golly was masked for removal.

-- 

  Sergei



Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Sergei Trofimovich
On Fri, 26 Jun 2020 07:29:45 +
Michał Górny  wrote:

> Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich  
> napisał(a):
> >On Sat, 20 Jun 2020 16:29:53 +0100
> >Sergei Trofimovich  wrote:
> >  
> >> On Sat, 20 Jun 2020 16:05:38 +0200
> >> Michał Górny  wrote:
> >>   
> >> > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote:
> >> > > Give maintainers the chance to act and flag packages that pull in  
> >python:2.7.  
> >> > > 
> >> > > Signed-off-by: Sergei Trofimovich 
> >> > > ---
> >> > >  profiles/package.deprecated | 4 
> >> > >  1 file changed, 4 insertions(+)
> >> > > 
> >> > > diff --git a/profiles/package.deprecated  
> >b/profiles/package.deprecated  
> >> > > index a756e845f47..bb661571962 100644
> >> > > --- a/profiles/package.deprecated
> >> > > +++ b/profiles/package.deprecated
> >> > > @@ -17,6 +17,10 @@
> >> > >  
> >> > >  #--- END OF EXAMPLES ---
> >> > >  
> >> > > +# Sergei Trofimovich  (2020-06-20)
> >> > > +# Deprecated. Consider poring to python 3 and drop support for  
> >python2.  
> >> > > +dev-lang/python:2.7
> >> > > +
> >> > >  # Sergei Trofimovich  (2020-02-22)
> >> > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider.
> >> > >  # Use that instead. Or even better use none of them. It's a  
> >> > 
> >>   
> >> > It will trigger the same for packages that support *only*
> >> > Python 2.7, as well as these that support 2.7 in addition to 3  
> >because  
> >> > they have 2.7 deps.
> >> 
> >> If we expect actions by developers on both cases I don't see a  
> >problem with that.
> >
> >Pushed as:
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> >with full text being:
> >
> >+# Sergei Trofimovich  (2020-06-26)
> >+# Deprecated.
> >+# - optional python:2.7 dependency should be dropped if no reverse
> >+#   dependencies are using it.
> >+# - mandatory python:2.7 depepndency will require package porting
> >+#   or package removal if no reverse dependencies are using it.
> >+dev-lang/python:2.7  
> 
> You've just introduced 829 CI warnings

That's the intention.

> effectively disabling the ability to distinguish *new* problems in these 
> packages.

Correct. Citing above:

"If we expect actions by developers on both cases I don't see a  problem with 
that."

I assume we still do.

-- 

  Sergei



Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Sergei Trofimovich
On Sat, 20 Jun 2020 16:29:53 +0100
Sergei Trofimovich  wrote:

> On Sat, 20 Jun 2020 16:05:38 +0200
> Michał Górny  wrote:
> 
> > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote:  
> > > Give maintainers the chance to act and flag packages that pull in 
> > > python:2.7.
> > > 
> > > Signed-off-by: Sergei Trofimovich 
> > > ---
> > >  profiles/package.deprecated | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/profiles/package.deprecated b/profiles/package.deprecated
> > > index a756e845f47..bb661571962 100644
> > > --- a/profiles/package.deprecated
> > > +++ b/profiles/package.deprecated
> > > @@ -17,6 +17,10 @@
> > >  
> > >  #--- END OF EXAMPLES ---
> > >  
> > > +# Sergei Trofimovich  (2020-06-20)
> > > +# Deprecated. Consider poring to python 3 and drop support for python2.
> > > +dev-lang/python:2.7
> > > +
> > >  # Sergei Trofimovich  (2020-02-22)
> > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider.
> > >  # Use that instead. Or even better use none of them. It's a
> >   
> 
> > It will trigger the same for packages that support *only*
> > Python 2.7, as well as these that support 2.7 in addition to 3 because
> > they have 2.7 deps.  
> 
> If we expect actions by developers on both cases I don't see a problem with 
> that.

Pushed as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
with full text being:

+# Sergei Trofimovich  (2020-06-26)
+# Deprecated.
+# - optional python:2.7 dependency should be dropped if no reverse
+#   dependencies are using it.
+# - mandatory python:2.7 depepndency will require package porting
+#   or package removal if no reverse dependencies are using it.
+dev-lang/python:2.7

-- 

  Sergei



Re: [gentoo-dev] [PATCH] unpacker.eclass: call BUILD_AR when unpacking deb files

2020-06-22 Thread Sergei Trofimovich
On Mon, 22 Jun 2020 11:10:55 -0400
Mike Gilbert  wrote:

> Closes: https://bugs.gentoo.org/722054
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/unpacker.eclass | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> index 865e2e1a1a58..63aedee4480e 100644
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -17,6 +17,8 @@
>  if [[ -z ${_UNPACKER_ECLASS} ]]; then
>  _UNPACKER_ECLASS=1
>  
> +inherit toolchain-funcs
> +
>  # @ECLASS-VARIABLE: UNPACKER_BZ2
>  # @DEFAULT_UNSET
>  # @DESCRIPTION:
> @@ -279,8 +281,7 @@ unpack_deb() {
>   done
>   } < "${deb}"
>   else
> - local AR=${AR-ar}
> - ${AR} x "${deb}" || die
> + $(tc-getBUILD_AR) x "${deb}" || die
>   fi
>  
>   unpacker ./data.tar*
> -- 
> 2.27.0

Looks good!

-- 

  Sergei



Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-20 Thread Sergei Trofimovich
On Sat, 20 Jun 2020 16:05:38 +0200
Michał Górny  wrote:

> On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote:
> > Give maintainers the chance to act and flag packages that pull in 
> > python:2.7.
> > 
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  profiles/package.deprecated | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/profiles/package.deprecated b/profiles/package.deprecated
> > index a756e845f47..bb661571962 100644
> > --- a/profiles/package.deprecated
> > +++ b/profiles/package.deprecated
> > @@ -17,6 +17,10 @@
> >  
> >  #--- END OF EXAMPLES ---
> >  
> > +# Sergei Trofimovich  (2020-06-20)
> > +# Deprecated. Consider poring to python 3 and drop support for python2.
> > +dev-lang/python:2.7
> > +
> >  # Sergei Trofimovich  (2020-02-22)
> >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider.
> >  # Use that instead. Or even better use none of them. It's a  
> 

> It will trigger the same for packages that support *only*
> Python 2.7, as well as these that support 2.7 in addition to 3 because
> they have 2.7 deps.

If we expect actions by developers on both cases I don't see a problem with 
that.

-- 

  Sergei


pgp9G4XWt3F8Y.pgp
Description: Цифровая подпись OpenPGP


[gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-20 Thread Sergei Trofimovich
Give maintainers the chance to act and flag packages that pull in python:2.7.

Signed-off-by: Sergei Trofimovich 
---
 profiles/package.deprecated | 4 
 1 file changed, 4 insertions(+)

diff --git a/profiles/package.deprecated b/profiles/package.deprecated
index a756e845f47..bb661571962 100644
--- a/profiles/package.deprecated
+++ b/profiles/package.deprecated
@@ -17,6 +17,10 @@
 
 #--- END OF EXAMPLES ---
 
+# Sergei Trofimovich  (2020-06-20)
+# Deprecated. Consider poring to python 3 and drop support for python2.
+dev-lang/python:2.7
+
 # Sergei Trofimovich  (2020-02-22)
 # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider.
 # Use that instead. Or even better use none of them. It's a
-- 
2.27.0




[gentoo-dev] Re: [gentoo-dev-announce] */*: Mask Py2 only packages

2020-06-20 Thread Sergei Trofimovich
On Sat, 20 Jun 2020 00:43:03 -0400
Aaron Bauman  wrote:

> # Aaron Bauman  (2020-06-20)
> # Py2 only
> # Removal in 14 days
...
> app-misc/golly

If you decided to delete a maintained package you should file a bug against
the maintainer. Otherwise they won't see the effect until mask hits the users.

-- 

  Sergei



[gentoo-dev] Re: [PATCH 2/2] multilib.eclass: drop amd64 from maintainers

2020-06-14 Thread Sergei Trofimovich
On Sun, 14 Jun 2020 11:57:06 -0400
Mike Gilbert  wrote:

> Acked-by: Agostino Sarubbo 
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/multilib.eclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 29d44768adec..4d1be867f14d 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -3,7 +3,6 @@
>  
>  # @ECLASS: multilib.eclass
>  # @MAINTAINER:
> -# am...@gentoo.org
>  # toolch...@gentoo.org
>  # @BLURB: This eclass is for all functions pertaining to handling multilib 
> configurations.
>  # @DESCRIPTION:
> -- 
> 2.27.0
> 

Looks good!

-- 

  Sergei



[gentoo-dev] Re: [PATCH 1/2] multilib.eclass: use tc-export to simplify multilib_toolchain_setup

2020-06-14 Thread Sergei Trofimovich
On Sun, 14 Jun 2020 11:57:05 -0400
Mike Gilbert  wrote:

> This also gives a tiny performance boost by reducing the number of
> subshells that are forked.
> 
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/multilib.eclass | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 342d21a2e1c3..29d44768adec 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -506,19 +506,15 @@ multilib_toolchain_setup() {
>   # Make sure ${save_restore_variables[@]} list matches below.
>   export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
>  
> - export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
> + # Append ABI flags to CHOST-prefixed tools
>   export CC="$(tc-getCC) $(get_abi_CFLAGS)"
>   export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
>   export F77="$(tc-getF77) $(get_abi_CFLAGS)"
>   export FC="$(tc-getFC) $(get_abi_CFLAGS)"
>   export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
> - export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
> - export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use 
> '${CHOST}-objdump'
> - export PKG_CONFIG="$(tc-getPKG_CONFIG)"
> - export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use 
> '${CHOST}-ranlib'
> - export READELF="$(tc-getREADELF)" # Avoid 'readelf', use 
> '${CHOST}-readelf'
> - export STRINGS="$(tc-getSTRINGS)" # Avoid 'strings', use 
> '${CHOST}-strings'
> - export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use 
> '${CHOST}-strip'
> +
> + # Use CHOST-prefixed tools
> + tc-export AR NM OBJDUMP PKG_CONFIG RANLIB READELF STRINGS STRIP
>  
>   export CHOST=$(get_abi_CHOST $1)
>   export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
> -- 
> 2.27.0
> 



-- 

  Sergei



[gentoo-dev] [PATCH 2/2] multilib.eclass: populate STRINGS

2020-06-14 Thread Sergei Trofimovich
For both multilib and non-multilib profiles binutils provides
tools with native CHOST prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-strings' and 'strings'.

autoconf usually uses AC_CHECK_TOOL(STRINGS, strings) autodetection
to discover either of these.

The change overrides STRINGS and friends to 'x86_64-pc-linux-gnu-strings'
for multilib setup similar to other environment variables.

Tested on media-libs/x264 and x11-libs/cairo packages.

Signed-off-by: Sergei Trofimovich 
---
 eclass/multilib.eclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 54ff1509ead..342d21a2e1c 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -470,6 +470,7 @@ multilib_toolchain_setup() {
PKG_CONFIG
RANLIB
READELF
+   STRINGS
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
@@ -504,6 +505,7 @@ multilib_toolchain_setup() {
#
# Make sure ${save_restore_variables[@]} list matches below.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
+
export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
@@ -515,7 +517,9 @@ multilib_toolchain_setup() {
export PKG_CONFIG="$(tc-getPKG_CONFIG)"
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use 
'${CHOST}-ranlib'
export READELF="$(tc-getREADELF)" # Avoid 'readelf', use 
'${CHOST}-readelf'
+   export STRINGS="$(tc-getSTRINGS)" # Avoid 'strings', use 
'${CHOST}-strings'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use 
'${CHOST}-strip'
+
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
-- 
2.27.0




[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*STRINGS helpers

2020-06-14 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 eclass/toolchain-funcs.eclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index a88d9a114ff..ec7b920bcfa 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -73,6 +73,10 @@ tc-getCXX() { tc-getPROG CXX g++ "$@"; }
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the linker
 tc-getLD() { tc-getPROG LD ld "$@"; }
+# @FUNCTION: tc-getSTRINGS
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the strings program
+tc-getSTRINGS() { tc-getPROG STRINGS strings "$@"; }
 # @FUNCTION: tc-getSTRIP
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the strip program
@@ -150,6 +154,10 @@ tc-getBUILD_CXX() { tc-getBUILD_PROG CXX g++ "$@"; }
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the linker for building binaries to run on the build machine
 tc-getBUILD_LD() { tc-getBUILD_PROG LD ld "$@"; }
+# @FUNCTION: tc-getBUILD_STRINGS
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the strings program for building binaries to run on the 
build machine
+tc-getBUILD_STRINGS() { tc-getBUILD_PROG STRINGS strings "$@"; }
 # @FUNCTION: tc-getBUILD_STRIP
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the strip program for building binaries to run on the build 
machine
-- 
2.27.0




[gentoo-dev] Re: [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one

2020-06-12 Thread Sergei Trofimovich
On Fri, 12 Jun 2020 17:43:10 -0400
Mike Gilbert  wrote:

> On Fri, Jun 12, 2020 at 5:25 PM Sergei Trofimovich  wrote:
> >
> > x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> > tool on sys-devel/binutils-config[-native-symlinks] system as:
> > `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
> >
> > It's caused by the code that locates the tool as:
> > `prog_nm = find_program('nm')`.
> >
> > The change adds 'nm' tool along with other binutils tools.
> >
> > CC: William Hubbs 
> > CC: Mike Gilbert 
> > Closes: https://bugs.gentoo.org/720886
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  eclass/meson.eclass | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index e79faa1beea..1590c1f14cf 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> > cpp = $(_meson_env_array "$(tc-getCXX)")
> > fortran = $(_meson_env_array "$(tc-getFC)")
> > llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> > +   nm = $(_meson_env_array "$(tc-getNM)")
> > objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> > pkgconfig = '$(tc-getPKG_CONFIG)'
> > @@ -228,6 +229,7 @@ _meson_create_native_file() {
> > cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> > fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> > llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> > +   nm = $(_meson_env_array "$(tc-getBUILD_NM)")
> > objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> > pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
> > --
> > 2.27.0
> >  
> 
> Looks good.

Thank you! Pushed as:
  
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da03d40f146a646c38e75fd0a6fc299b5aeba505

-- 

  Sergei



[gentoo-dev] [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one

2020-06-12 Thread Sergei Trofimovich
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`

It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.

The change adds 'nm' tool along with other binutils tools.

CC: William Hubbs 
CC: Mike Gilbert 
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich 
---
 eclass/meson.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..1590c1f14cf 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+   nm = $(_meson_env_array "$(tc-getNM)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+   nm = $(_meson_env_array "$(tc-getBUILD_NM)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
-- 
2.27.0




[gentoo-dev] [PATCH] meson.eclass: override 'nm' tool with tuple-prefixed one

2020-06-12 Thread Sergei Trofimovich
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`

It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.

The change adds 'nm' tool along with other binutils tools.

CC: William Hubbs 
CC: Mike Gilbert 
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich 
---
 eclass/meson.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..20f74a29b83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+   nm = $(_meson_env_array "$(tc-getNM nm)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+   nm = $(_meson_env_array "$(tc-getBUILD_NM nm)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
-- 
2.27.0




Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice

2020-06-08 Thread Sergei Trofimovich
On Mon, 8 Jun 2020 03:02:49 -0700
Georgy Yakovlev  wrote:

> opened a PR to add it to repoman:
> 
> https://github.com/gentoo/portage/pull/554

Thank you!

-- 

  Sergei



Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice

2020-06-08 Thread Sergei Trofimovich
On Mon, 08 Jun 2020 10:13:24 +0200
Andreas Sturmlechner  wrote:

> This eclass no longer receives any changes.
> Everyone must port to cmake.eclass.

We have quite a few ebuilds that still use it:
$ git grep -E 'inherit.*cmake-utils' | wc -l
1338

I don't see any warnings reported by repoman to suggest users
to migrate away. Should we have one?

-- 

  Sergei



Re: [gentoo-dev] [PATCH 0/2] multilib.eclass: improve multilib handling of pkg-config

2020-06-06 Thread Sergei Trofimovich
On Sat,  6 Jun 2020 15:24:03 -0400
Mike Gilbert  wrote:

> These patches are part of a larger change to eliminate MULTILIB_USEDEP
> from virtual/pkgconfig dependencies in BDEPEND.
> 
> See https://bugs.gentoo.org/723112 and
> https://github.com/gentoo/gentoo/pull/16025.
> 
> Mike Gilbert (2):
>   multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in
> multilib_toolchain_setup
>   multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup
> 
>  eclass/multilib.eclass | 4 
>  1 file changed, 4 insertions(+)
> 

Looks good!

-- 

  Sergei



Re: [gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878

2020-06-03 Thread Sergei Trofimovich
On Sat, 30 May 2020 09:59:16 -0700
Manoj Gupta  wrote:

> Also see https://bugs.chromium.org/p/chromium/issues/detail?id=1088210 on
> Chrome OS.
> 
> Verified that this fixes the linux-headers build issue when gcc links are
> not installed.
> 
> Thanks,
> Manoj
> 
> On Sat, May 30, 2020 at 5:24 AM Sergei Trofimovich 
> wrote:
> 
> > Before the change HOSTCC always used gcc. This was
> > detected by Agostino on linux-headers package.
> >
> > After the change HOSTCC uses user-specified CC
> > (or BUILD_CC). Tested on native linux-headers
> > and on cross-*/linux-headers.
> >
> > CC: ker...@gentoo.org
> > Reported-by: Agostino Sarubbo
> > https://bugs.gentoo.org/725878
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  eclass/kernel-2.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 930bcf22e29..04edee33930 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -712,6 +712,7 @@ env_setup_xmakeopts() {
> > elif type -p ${CHOST}-ar > /dev/null ; then
> > xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> > fi
> > +   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> > export xmakeopts
> >  }
> >
> > --
> > 2.26.2

Pushed as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3dd41142d73f41e2528eefa32e760fc3083001ee

-- 

  Sergei



[gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878

2020-05-30 Thread Sergei Trofimovich
Before the change HOSTCC always used gcc. This was
detected by Agostino on linux-headers package.

After the change HOSTCC uses user-specified CC
(or BUILD_CC). Tested on native linux-headers
and on cross-*/linux-headers.

CC: ker...@gentoo.org
Reported-by: Agostino Sarubbo
https://bugs.gentoo.org/725878
Signed-off-by: Sergei Trofimovich 
---
 eclass/kernel-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 930bcf22e29..04edee33930 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -712,6 +712,7 @@ env_setup_xmakeopts() {
elif type -p ${CHOST}-ar > /dev/null ; then
xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
fi
+   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
export xmakeopts
 }
 
-- 
2.26.2




Re: [gentoo-dev] Add more toolchain variables to emerge --info

2020-05-28 Thread Sergei Trofimovich
On Thu, 28 May 2020 14:23:46 +0200
Agostino Sarubbo  wrote:

> https://bugs.gentoo.org/show_bug.cgi?id=722456
> 
> What is your opinion?

Adding more build-related variables sounds great.

-- 

  Sergei



[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.

2020-05-26 Thread Sergei Trofimovich
On Tue, 26 May 2020 15:13:47 -0700
Manoj Gupta  wrote:

> I noticed that gcc-config recently gained --enable-native-links /
> --disable-native-links knobs that are . Will this patch with a renamed
> option name
> e.g. --disable-default-cc-vars and support for a USE flag work?

That can work. Let's try and see how the end result looks like.

> Thanks,
> Manoj
> 
> On Wed, Mar 11, 2020 at 9:07 AM Manoj Gupta  wrote:
> 
> >
> >
> > On Wed, Mar 11, 2020 at 12:49 AM Sergei Trofimovich 
> > wrote:
> >  
> >> On Tue, 10 Mar 2020 20:54:12 -0700
> >> Manoj Gupta  wrote:
> >>  
> >> > On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich   
> >> wrote:  
> >> >  
> >> > > On Mon, 2 Mar 2020 19:03:48 -0800
> >> > > Manoj Gupta  wrote:
> >> > >  
> >> > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <  
> >> sly...@gmail.com>  
> >> > > > wrote:
> >> > > >  
> >> > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta   
> >>  
> >> > > wrote:  
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <  
> >> manojgu...@google.com>  
> >> > >  
> >> > > > > wrote:  
> >> > > > > >>
> >> > > > > >> gcc-config installs cc/f77 by default. This may be undesired on
> >> > > > > >> systems that want to set their own versions of cc/f77.
> >> > > > > >>
> >> > > > > >> Add option "-n"/"--no-default-vars" to not install the cc/f77
> >> > > > > >> wrappers.
> >> > > > > >>
> >> > > > > >> Signed-off-by: Manoj Gupta 
> >> > > > > >> ---
> >> > > > > >>  gcc-config | 6 +-
> >> > > > > >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >> > > > > >>
> >> > > > > >> diff --git a/gcc-config b/gcc-config
> >> > > > > >> index f03a46a..6f306db 100755
> >> > > > > >> --- a/gcc-config
> >> > > > > >> +++ b/gcc-config
> >> > > > > >> @@ -262,7 +262,7 @@ update_wrappers() {
> >> > > > > >> # For all toolchains, we want to create the fully  
> >> qualified  
> >> > > > > >> # `tuple-foo`.  Only native ones do we want the  
> >> simple  
> >> > > `foo`.  
> >> > > > > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} )
> >> > > > > >> -   if ! is_cross_compiler ; then
> >> > > > > >> +   if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" ==  
> >> "yes"  
> >> > > ]];  
> >> > > > > then  
> >> > > > > >> all_wrappers+=( "${new_wrappers[@]}" )
> >> > > > > >> # There are a few fun extra progs which we  
> >> have to  
> >> > > > > handle #412319  
> >> > > > > >> all_wrappers+=( cc:gcc f77:g77 )
> >> > > > > >> @@ -951,6 +951,7 @@ FORCE="no"
> >> > > > > >>  CC_COMP=
> >> > > > > >>  ENV_D="${EROOT}etc/env.d"
> >> > > > > >>  GCC_ENV_D="${ENV_D}/gcc"
> >> > > > > >> +DEFAULT_PROGS="yes"
> >> > > > > >>
> >> > > > > >>  for x in "$@" ; do
> >> > > > > >> case "${x}" in
> >> > > > > >> @@ -972,6 +973,9 @@ for x in "$@" ; do
> >> > > > > >> -l|--list-profiles)
> >> > > > > >> set_doit list_profiles
> >> > > > > >> ;;
> >> > > > > >> +   -n|--no-default-vars)
> >> > > > > >> +   DEFAULT_PROGS="no"
> >> > > > > >> +   ;;
> >> > > > > >> 

[gentoo-dev] [PATCH v2] kernel-2.eclass: avoid lexicographical compare on versions, bug #705246

2020-05-26 Thread Sergei Trofimovich
Originally found in bug #705240 as:

```
if [[ ... || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
```

'>' are string comparisons. They are benign so far, but
will start failing on linux-10 :)

Let's be consistent and use version comparison.

Closes: https://bugs.gentoo.org/705246
Signed-off-by: Sergei Trofimovich 
---
Change since v1:
- fixed syntax around compound conditionals:
  '[[ foo || ver_test bar ]]' -> '[[ foo ]] || ver_test bar'

 eclass/kernel-2.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 07af8d8ab2c..930bcf22e29 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1015,7 +1015,7 @@ postinst_sources() {
#   K_SECURITY_UNSUPPORTED=deblob
 
# if we are to forcably symlink, delete it if it already exists first.
-   if [[ ${K_SYMLINK} > 0 ]]; then
+   if [[ ${K_SYMLINK} -gt 0 ]]; then
[[ -h ${EROOT}usr/src/linux ]] && { rm "${EROOT}"usr/src/linux 
|| die; }
MAKELINK=1
fi
@@ -1078,7 +1078,7 @@ postinst_sources() {
KV_PATCH=$(ver_cut 3 ${OKV})
if [[ "$(tc-arch)" = "sparc" ]]; then
if [[ $(gcc-major-version) -lt 4 && $(gcc-minor-version) -lt 4 
]]; then
-   if [[ ${KV_MAJOR} -ge 3 || 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
+   if [[ ${KV_MAJOR} -ge 3 ]] || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.24 ; then
echo
elog "NOTE: Since 2.6.25 the kernel Makefile 
has changed in a way that"
elog "you now need to do"
@@ -1272,7 +1272,7 @@ unipatch() {
# do not apply fbcondecor patch to sparc/sparc64 as it breaks boot
# bug #272676
if [[ "$(tc-arch)" = "sparc" || "$(tc-arch)" = "sparc64" ]]; then
-   if [[ ${KV_MAJOR} -ge 3 || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
> 2.6.28 ]]; then
+   if [[ ${KV_MAJOR} -ge 3 ]] || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.28 ; then
if [[ ! -z ${K_WANT_GENPATCHES} ]] ; then
UNIPATCH_DROP="${UNIPATCH_DROP} 
*_fbcondecor*.patch"
echo
@@ -1521,7 +1521,7 @@ kernel-2_src_unpack() {
# fix a problem on ppc where TOUT writes to /usr/src/linux breaking 
sandbox
# only do this for kernel < 2.6.27 since this file does not exist in 
later
# kernels
-   if [[ -n ${KV_MINOR} &&  ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 
]] ; then
+   if [[ -n ${KV_MINOR} ]] && ver_test ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
-lt 2.6.27 ; then
sed -i \
-e 's|TOUT  := .tmp_gas_check|TOUT  := 
$(T).tmp_gas_check|' \
"${S}"/arch/ppc/Makefile
-- 
2.26.2




Re: [gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304

2020-05-25 Thread Sergei Trofimovich
On Mon, 25 May 2020 11:30:29 -0400
Mike Gilbert  wrote:

> On Mon, May 25, 2020 at 9:06 AM Sergei Trofimovich  wrote:
> >
> > Bug: https://bugs.gentoo.org/725304
> > Signed-off-by: Sergei Trofimovich   
> 
> Both patches look good to me.
> 
> However, I think you should remove the bug number from the summary
> line; it makes the summary too long and the Bug tag later in the
> commit message is sufficient.

Sounds good! Dropped bug number and pushed as:
  
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ccdea417c4a259a03a745e3a977ac56827be5ae4
  
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7bd13f6d55a51f2a1f4da69a41df7973fa7503cc

-- 

  Sergei



[gentoo-dev] [PATCH 2/2] multilib.eclass: populate READELF, bug #725304

2020-05-25 Thread Sergei Trofimovich
For both multilib and non-multilib profiles binutils provides
tools with native CHOST prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-readelf' and 'readelf'.

meson build system uses 'readelf' or $READELF binaries
and relies on meson.eclass to populate READELF.

The change overrides READELF and friends to 'x86_64-pc-linux-gnu-readelf'
for multilib setup similar to other environment variables.

Tested on net-libs/gssdp package.

Closes: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich 
---
 eclass/multilib.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index b79718bb193..ed54568aa2d 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -468,6 +468,7 @@ multilib_toolchain_setup() {
NM
OBJDUMP
RANLIB
+   READELF
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
@@ -510,6 +511,7 @@ multilib_toolchain_setup() {
export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use 
'${CHOST}-objdump'
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use 
'${CHOST}-ranlib'
+   export READELF="$(tc-getREADELF)" # Avoid 'readelf', use 
'${CHOST}-readelf'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use 
'${CHOST}-strip'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
-- 
2.26.2




[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304

2020-05-25 Thread Sergei Trofimovich
Bug: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich 
---
 eclass/toolchain-funcs.eclass | 9 +
 1 file changed, 9 insertions(+)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 1bc6cbbc108..709c3baca53 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -85,6 +85,10 @@ tc-getNM() { tc-getPROG NM nm "$@"; }
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the archiver indexer
 tc-getRANLIB() { tc-getPROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getREADELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector
+tc-getREADELF() { tc-getPROG READELF readelf "$@"; }
 # @FUNCTION: tc-getOBJCOPY
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the object copier
@@ -158,6 +162,10 @@ tc-getBUILD_NM() { tc-getBUILD_PROG NM nm "$@"; }
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the archiver indexer for building binaries to run on the 
build machine
 tc-getBUILD_RANLIB() { tc-getBUILD_PROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getBUILD_READELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector for building binaries to run on the build 
machine
+tc-getBUILD_READELF() { tc-getBUILD_PROG READELF readelf "$@"; }
 # @FUNCTION: tc-getBUILD_OBJCOPY
 # @USAGE: [toolchain prefix]
 # @RETURN: name of the object copier for building binaries to run on the build 
machine
@@ -376,6 +384,7 @@ tc-env_build() {
NM=$(tc-getBUILD_NM) \
PKG_CONFIG=$(tc-getBUILD_PKG_CONFIG) \
RANLIB=$(tc-getBUILD_RANLIB) \
+   READELF=$(tc-getBUILD_READELF) \
"$@"
 }
 
-- 
2.26.2




Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Sergei Trofimovich
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu"  wrote:

> > USE=-native-symlinks removes a bunch of links that most packages use by 
> > default
> > until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> > 
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix it will 
> > probably
> > disappear with USE=-native-symlinks.
> > 
> > (At least eventually) 'emerge' should still be able to build most of 
> > packages
> > in such environment. I expect initial breakage will be huge though.
> > 
> > Using './configure && make && make install' style workflow will be more 
> > tedious.
> > One workaround at least for gcc is to use something like:
> > $ PATH="$(gcc-config -B):$PATH"
> > It's not perfect. We'll see if toolchain can provide nicer environment.
> >   
> 
> Do we currently have (or is there a plan for) a mechanism to manage the 
> symbolic links and/or create them after merging the package when necessary?  
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.

There currently is no nice way to get stable path with up-to-date
symlinks for current gcc/binutils. I think of adding a gentoo-specific
directory to manage symlinks similar to what 'gcc-config -B' provides
in a stable path that you can write once into user's PATH.

No concrete implementation yet. Filed https://bugs.gentoo.org/724980
to track it.

-- 

  Sergei



Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Sergei Trofimovich
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert  wrote:

> On Fri, May 22, 2020 at 5:36 PM Sergei Trofimovich  wrote:
> >
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> >
> > I added new USE=-native-symlinks mode for gcc-config and
> > binutils-config to ease detection of such packages.
> >
> > Native symlinks are still installed by default. Nothing should
> > break for users who use default USE flags.
> >
> > USE=-native-symlinks removes a bunch of links that most packages
> > use by default until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> > it will probably disappear with USE=-native-symlinks.
> >
> > (At least eventually) 'emerge' should still be able to build most
> > of packages in such environment. I expect initial breakage will be
> > huge though.  
> 
> Could you please add this flag to package.use.force?

Added as 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136

> I don't think we
> want to give people the impression that this is a well-supported
> configuration. I would only expect people to disable this if they want
> to break their system intentionally.

Yeah, today it's certainly a way to get your system in a miserable state.
My hope is that USE=-native-symlinks can get you a working Gentoo in a
near future by only fixing real package problems and limitations of their
build systems.

-- 

  Sergei



Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Sergei Trofimovich
On Sat, 23 May 2020 23:40:22 -0700
Matt Turner  wrote:

> On Sat, May 23, 2020 at 10:21 PM Joonas Niilola  wrote:
> >
> >
> > On 5/24/20 5:41 AM, Mike Gilbert wrote:  
> > > Also, people are likely to disable this accidentally via USE="-*".  
> >
> > Counts as
> >  
> > > if they want to break their system intentionally.  
> 
> Yes, but unfortunately catalyst's stage1 build does exactly this.
> 
> Suggestions how to avoid doing this would be appreciated, but until
> that's resolved we don't have carte blanche to break USE="-*".

Ah, I keep forgetting about catalyst. Use-forced flags as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136

While at it added a page that explains how to turn it back by enthusiasts:
https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks
and will collect more details on typical fixes and "this is fine to ignore" 
pitfalls.

-- 

  Sergei



Re: [gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248

2020-05-23 Thread Sergei Trofimovich
On Sat, 23 May 2020 14:56:06 -0400
Mike  wrote:

> On 5/22/20 2:57 PM, Sergei Trofimovich wrote:
> > Originally found in bug #705240 as:
> > 
> > ```
> >   error=0
> >   ...
> >   if [[ ${error} > 0 ]]; then
> >   ...
> > ```
> >   
> > '>' are string comparisons. They are benign in this case, but let's  
> > be consistent and use integer comparison.
> > 
> > CC: ker...@gentoo.org
> > Closes: https://bugs.gentoo.org/705248
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  eclass/linux-info.eclass | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > index 44eebcf52a9..405ef5571e1 100644
> > --- a/eclass/linux-info.eclass
> > +++ b/eclass/linux-info.eclass
> > @@ -813,7 +813,7 @@ check_extra_config() {
> > linux_chkconfig_present ${config} || error=1
> > fi
> >  
> > -   if [[ ${error} > 0 ]]; then
> > +   if [[ ${error} -gt 0 ]]; then
> > local report_func="eerror" local_error
> > local_error="ERROR_${config}"
> > local_error="${!local_error}"
> > @@ -848,14 +848,14 @@ check_extra_config() {
> > fi
> > done
> >  
> > -   if [[ ${hard_errors_count} > 0 ]]; then
> > +   if [[ ${hard_errors_count} -gt 0 ]]; then
> > eerror "Please check to make sure these options are set 
> > correctly."
> > eerror "Failure to do so may cause unexpected problems."
> > eerror "Once you have satisfied these options, please try 
> > merging"
> > eerror "this package again."
> > export 
> > LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
> > die "Incorrect kernel configuration options"
> > -   elif [[ ${soft_errors_count} > 0 ]]; then
> > +   elif [[ ${soft_errors_count} -gt 0 ]]; then
> > ewarn "Please check to make sure these options are set 
> > correctly."
> > ewarn "Failure to do so may cause unexpected problems."
> > else
> >   
> 
> Thanks. LGTM

Pushed as:
  
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa1d259decdfd73a49e0c49e88a8ec5675453266

-- 

  Sergei



[gentoo-dev] Re: [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558

2020-05-23 Thread Sergei Trofimovich
On Fri, 22 May 2020 23:42:48 +0100
Sergei Trofimovich  wrote:

> For both multilib and non-multilib profiles binutils provides
> tools with native ABI prefix only. For example on amd64 there
> is only 'x86_64-pc-linux-gnu-nm' and 'nm'.
> 
> On abi_x86_32 tools are usually configured with --host=i686-pc-linux-gnu.
> Configure tries i686-pc-linux-gnu-nm, then falls back to 'nm'.
> 
> The change overrides NM to 'x86_64-pc-linux-gnu-nm' for
> multilib setup similar to other environment variables.
> 
> Reported-by: Kent Fredric
> Closes: https://bugs.gentoo.org/724558
> Signed-off-by: Sergei Trofimovich 
> ---
>  eclass/multilib.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index bbaab709b4f..25e90dea44c 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -484,11 +484,13 @@ multilib_toolchain_setup() {
>   # Set the CHOST native first so that we pick up the native
>   # toolchain and not a cross-compiler by accident #202811.
>   export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
> + export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
>   export CC="$(tc-getCC) $(get_abi_CFLAGS)"
>   export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
>   export F77="$(tc-getF77) $(get_abi_CFLAGS)"
>   export FC="$(tc-getFC) $(get_abi_CFLAGS)"
>   export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
> + export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
>   export CHOST=$(get_abi_CHOST $1)
>   export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
>   export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig

Also added OBJDUMP, RANLIB and STRIP as they are used in most
libraries used by autotools. Pushed as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd35b529194fdcadf324fd4f0a466a61aa1dfadb

-- 

  Sergei



Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-23 Thread Sergei Trofimovich
On Sat, 23 May 2020 08:05:46 +0200
Michał Górny  wrote:

> On Fri, 2020-05-22 at 22:36 +0100, Sergei Trofimovich wrote:
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> > 
> > I added new USE=-native-symlinks mode for gcc-config and
> > binutils-config to ease detection of such packages.
> > 
> > Native symlinks are still installed by default. Nothing should
> > break for users who use default USE flags.
> > 
> > USE=-native-symlinks removes a bunch of links that most packages
> > use by default until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> > 
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> > it will probably disappear with USE=-native-symlinks.  
> 
> Does this list include 'ar' or not?  Asking because there's been
> a number of false positives reported for 'ar' being used as an archiver
> (e.g. to work on .deb packages).

USE=-native-symlinks does remove /usr/bin/ar. Full(er) list for binutils is:

addr2line
ar
as
c++filt
coffdump
dlltool
dllwrap
dwp
elfedit
gprof
ld
ld.bfd
ld.gold
nm
objcopy
objdump
ranlib
readelf
size
srconv
strings
strip
sysdump
windmc
windres

-- 

  Sergei



[gentoo-dev] [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558

2020-05-22 Thread Sergei Trofimovich
For both multilib and non-multilib profiles binutils provides
tools with native ABI prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-nm' and 'nm'.

On abi_x86_32 tools are usually configured with --host=i686-pc-linux-gnu.
Configure tries i686-pc-linux-gnu-nm, then falls back to 'nm'.

The change overrides NM to 'x86_64-pc-linux-gnu-nm' for
multilib setup similar to other environment variables.

Reported-by: Kent Fredric
Closes: https://bugs.gentoo.org/724558
Signed-off-by: Sergei Trofimovich 
---
 eclass/multilib.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index bbaab709b4f..25e90dea44c 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -484,11 +484,13 @@ multilib_toolchain_setup() {
# Set the CHOST native first so that we pick up the native
# toolchain and not a cross-compiler by accident #202811.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
+   export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
export F77="$(tc-getF77) $(get_abi_CFLAGS)"
export FC="$(tc-getFC) $(get_abi_CFLAGS)"
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
+   export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
-- 
2.26.2




[gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-22 Thread Sergei Trofimovich
'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
packages that don't respect users' CC/AR/LD flags.

I added new USE=-native-symlinks mode for gcc-config and
binutils-config to ease detection of such packages.

Native symlinks are still installed by default. Nothing should
break for users who use default USE flags.

USE=-native-symlinks removes a bunch of links that most packages
use by default until are overridden explicitly. Incomplete list is:
- /lib/cpp
- /usr/bin/{gcc,cc,g++,c++,...}
- /usr/bin/{as,ld,ranlib,dwp,...}

The rule of thumb is: if a tool does not have ${CTARGET}- prefix
it will probably disappear with USE=-native-symlinks.

(At least eventually) 'emerge' should still be able to build most
of packages in such environment. I expect initial breakage will be
huge though.

Using './configure && make && make install' style workflow will be more
tedious. One workaround at least for gcc is to use something like:
$ PATH="$(gcc-config -B):$PATH"
It's not perfect. We'll see if toolchain can provide nicer environment.

Typical fixes for autoconf style build systems is to use macros like:
- AC_PROG_CC
- AM_PROG_AR
- AC_CHECK_TOOL(DWP, dwp)
and so on to detect tool that corresponds to --host=/--target= flags
and allows user's override via environment variable.

-- 

  Sergei



[gentoo-dev] [PATCH] kernel-2.eclass: avoid lexicographical compare on versions, bug #705246

2020-05-22 Thread Sergei Trofimovich
Originally found in bug #705240 as:

```
if [[ ... || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
```

'>' are string comparisons. They are benign so far, but
will start failing on linux-10 :)

Let's be consistent and use version comparison.

CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705246
Signed-off-by: Sergei Trofimovich 
---
 eclass/kernel-2.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 07af8d8ab2c..d69182045c5 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1015,7 +1015,7 @@ postinst_sources() {
#   K_SECURITY_UNSUPPORTED=deblob
 
# if we are to forcably symlink, delete it if it already exists first.
-   if [[ ${K_SYMLINK} > 0 ]]; then
+   if [[ ${K_SYMLINK} -gt 0 ]]; then
[[ -h ${EROOT}usr/src/linux ]] && { rm "${EROOT}"usr/src/linux 
|| die; }
MAKELINK=1
fi
@@ -1078,7 +1078,7 @@ postinst_sources() {
KV_PATCH=$(ver_cut 3 ${OKV})
if [[ "$(tc-arch)" = "sparc" ]]; then
if [[ $(gcc-major-version) -lt 4 && $(gcc-minor-version) -lt 4 
]]; then
-   if [[ ${KV_MAJOR} -ge 3 || 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
+   if [[ ${KV_MAJOR} -ge 3 || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.24 ]] ; then
echo
elog "NOTE: Since 2.6.25 the kernel Makefile 
has changed in a way that"
elog "you now need to do"
@@ -1272,7 +1272,7 @@ unipatch() {
# do not apply fbcondecor patch to sparc/sparc64 as it breaks boot
# bug #272676
if [[ "$(tc-arch)" = "sparc" || "$(tc-arch)" = "sparc64" ]]; then
-   if [[ ${KV_MAJOR} -ge 3 || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
> 2.6.28 ]]; then
+   if [[ ${KV_MAJOR} -ge 3 || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.28 ]]; then
if [[ ! -z ${K_WANT_GENPATCHES} ]] ; then
UNIPATCH_DROP="${UNIPATCH_DROP} 
*_fbcondecor*.patch"
echo
@@ -1521,7 +1521,7 @@ kernel-2_src_unpack() {
# fix a problem on ppc where TOUT writes to /usr/src/linux breaking 
sandbox
# only do this for kernel < 2.6.27 since this file does not exist in 
later
# kernels
-   if [[ -n ${KV_MINOR} &&  ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 
]] ; then
+   if [[ -n ${KV_MINOR} && ver_test ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
-lt 2.6.27 ]] ; then
sed -i \
-e 's|TOUT  := .tmp_gas_check|TOUT  := 
$(T).tmp_gas_check|' \
"${S}"/arch/ppc/Makefile
-- 
2.26.2




[gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248

2020-05-22 Thread Sergei Trofimovich
Originally found in bug #705240 as:

```
  error=0
  ...
  if [[ ${error} > 0 ]]; then
  ...
```

'>' are string comparisons. They are benign in this case, but let's
be consistent and use integer comparison.

CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705248
Signed-off-by: Sergei Trofimovich 
---
 eclass/linux-info.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 44eebcf52a9..405ef5571e1 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -813,7 +813,7 @@ check_extra_config() {
linux_chkconfig_present ${config} || error=1
fi
 
-   if [[ ${error} > 0 ]]; then
+   if [[ ${error} -gt 0 ]]; then
local report_func="eerror" local_error
local_error="ERROR_${config}"
local_error="${!local_error}"
@@ -848,14 +848,14 @@ check_extra_config() {
fi
done
 
-   if [[ ${hard_errors_count} > 0 ]]; then
+   if [[ ${hard_errors_count} -gt 0 ]]; then
eerror "Please check to make sure these options are set 
correctly."
eerror "Failure to do so may cause unexpected problems."
eerror "Once you have satisfied these options, please try 
merging"
eerror "this package again."
export 
LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
die "Incorrect kernel configuration options"
-   elif [[ ${soft_errors_count} > 0 ]]; then
+   elif [[ ${soft_errors_count} -gt 0 ]]; then
ewarn "Please check to make sure these options are set 
correctly."
ewarn "Failure to do so may cause unexpected problems."
else
-- 
2.26.2




[gentoo-dev] gcc-10 is in ~arch

2020-05-08 Thread Sergei Trofimovich
gcc-10 was released yesterday and was pushed to ::gentoo's ~arch as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32258c6414a31898ff5592893678a3910d2c5c75

Most of packages should Just Work. But we expect some amount of
build- and runtime breakage. Non-exhaustive list of things to watch for:

- missing includes in users' code
  Example build failure would be:
  "error: 'size_t' was not declared in this scope; did you mean 'std::size_t'?"
  where missing  for used size_t types.

- extra '-fcommon->-fno-common' linker failures for packages that
  ignore users' CFLAGS and thus missed Toralf's tinderbox runs.

  https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common

- "9" -> "10" version change also managed to break many assumptions
  of how gcc versions are parsed by shell scripts and ebuilds.

  This causes all sorts of bizarre bugs:
https://trofi.github.io/posts/213-gcc-10-in-gentoo.html

- overhauled gcc-10 inliner heuristics will cause some amount of
  build/runtime breakage in existing fragile code.

  As an extreme example your stack-protected kernel might not boot:
https://lkml.org/lkml/2020/3/14/186

Tracker of common breakages:
https://bugs.gentoo.org/show_bug.cgi?id=gcc-10

Landing page to steal-fixes-from/add-fixes-to:
https://wiki.gentoo.org/wiki/Project:Toolchain#gcc-10

If you can't figure out non-trivial breakage feel free to
add toolchain@ to the bug and we'll try to sort it out together.

-- 

  Sergei



Re: [gentoo-dev] CFLAGS=-fno-common related breakage is incoming

2020-05-02 Thread Sergei Trofimovich
On Sun, 19 Jan 2020 22:36:51 +
Sergei Trofimovich  wrote:

> > What is happening?  
> 
> gcc-10 is coming soon. It will be more disruptive than gcc-9.
> 
> One of the major changes is the switch from C{,XX}FLAGS=-fcommon
> to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678
> 
> It's a planned change and not a gcc regression. It will expose some
> warts on old code and unblock minor optimisations accessing globals.
> 
> The change has already happened in gcc trunk.
> 
> > Is my package affected? Should I do anything?  
> 
> You can check proactively if your packages are affected.
> 
> Add -fno-common to your make.conf's C{,XX}FLAGS and
> see if things still build.
> 
> The typical symptom is a linker failure on multiple definitions
> for some global variable:
> 
>  ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0): 
> first defined here
> 
> > How to fix it?  
> 
> https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common contains
> some examples. Ideally code will need a few 'extern' additions and maybe
> moving variable definitions.
> 
> Example of proposed openrc fix:
> https://github.com/OpenRC/openrc/pull/348
> 
> Adding 'append-flags -fcommon' might work as a temporary workaround.
> 
> > Can I help?  
> 
> Glad you asked! We will need to gather failed packages and fix them
> upstream and downstream. Here is what you can do:
> 
> 1. Add -fno-common to your make.conf's C{,XX}FLAGS
> 2. Build packages you maintain
> 3. Fix a bug upstream (or report a failure).
> 4. Pull a fix downstream (or file a bug and add it to the tracker).
> 
> > What is already known to be broken? Can I look at example fixes?  
> 
> See https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
> for an artificial example.
> 
> Gentoo tracker bug of known issues:
>   https://bugs.gentoo.org/705764
> 15 bugs so far.
> 
> SUSE tracker bug of known issues:
>   https://bugzilla.suse.com/show_bug.cgi?id=1160244
> 95 bugs so far. A good source of packages to check against the
> ones you care about.
> 
> > What does -fcommon do?  
> 
> Look up -fcommon in https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
> 
> > I have no idea why my package broke. The error does not make sense.  
> 
> Feel free to CC toolchain@ on a bug you observe and we'll try to sort it out.

With Toralf's help we now have rough estimate of broken packages. It's about
450 yet unfixed ones:
https://bugs.gentoo.org/showdependencytree.cgi?id=705764_resolved=1

gcc-10 will be released soon. Maybe in a week.

Please look at the broken list and fix your packages.

Thanks!

-- 

  Sergei



Re: [gentoo-dev] [PATCH] rebar.eclass: Use := dependency

2020-04-25 Thread Sergei Trofimovich
On Sat, 25 Apr 2020 10:01:50 +0200
Hanno Böck  wrote:

> All erlang rebar based packages should be rebuilt after a subslot
> update of dev-lang/erlang.
> 
> Right now this is done in some ebuilds, but inconsistent.
> Given this affects all packages this should be reflected in the
> rebar.eclass, see also [1].
> 
> [1] https://bugs.gentoo.org/714702
> 
> Closes: https://bugs.gentoo.org/714702
> Signed-off-by: Hanno Böck 
> ---
> 
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> index f2a620fd8..92dd16b08 100644
> --- a/eclass/rebar.eclass
> +++ b/eclass/rebar.eclass
> @@ -32,7 +32,7 @@ esac
>  
>  EXPORT_FUNCTIONS src_prepare src_compile src_test src_install
>  
> -RDEPEND="dev-lang/erlang"
> +RDEPEND="dev-lang/erlang:="
>  DEPEND="${RDEPEND}
>   dev-util/rebar
>   >=sys-apps/gawk-4.1"  
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 

Looks good.

-- 

  Sergei



[gentoo-dev] */*: downgrade m68k down to ~m68k

2020-04-21 Thread Sergei Trofimovich
With

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dce3dc0aa1341155a31407122e079632fcd07ca
m68k does not have stable keywords in ::gentoo anymore and
thus becomes ~arch-only Gentoo target.

"""
*/*: downgrade m68k down to ~m68k
m68k and ~m68k trees are inconsistent. Let's drop keywords
down to ~m68k only. Profiles already accept both keywords:

ACCEPT_KEYWORDS="m68k ~m68k"
"""

Even basic packages don't have consistent ~m68k keywords. I don't
think stable keywords have any use today.

I will pass through and un-CC/close all STABLEREQ bugs where m68k
is CCed.

-- 

  Sergei



[gentoo-dev] Package up for grabs: dev-libs/ppl

2020-04-13 Thread Sergei Trofimovich
Single fresh test failure bug: https://bugs.gentoo.org/717258.

commit f054fd75ab013787e2c65438998067de00de04e5
Author: Sergei Trofimovich 
Date:   Mon Apr 13 09:52:03 2020 +0100

dev-libs/ppl: drop toolchain from maintainers

gcc's graphite does not use dev-libs/ppl for loop
optimizations for a while.

-- 

  Sergei



Re: [gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass

2020-04-03 Thread Sergei Trofimovich
On Fri,  3 Apr 2020 08:25:35 +0200
Tupone Alfredo  wrote:

> ---
>  eclass/toolchain.eclass | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)

Looks good!

-- 

  Sergei



[gentoo-dev] Re: Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Sergei Trofimovich
On Thu, 2 Apr 2020 12:52:13 +0200
Alfredo Tupone  wrote:

> + # Do not set ADAFLAGS to build the compiler
> + unset ADAFLAGS

Can you clarify in a comment why it's done?

>   # Older gcc versions did not detect bash and re-exec itself, so force 
> the
>   # use of bash.  Newer ones will auto-detect, but this is not harmful.
>   # This needs to be set for compile as well, as it's used in libtool
>   # generation, which will break install otherwise (at least in 3.3.6): 
> #664486
>   CONFIG_SHELL="${EPREFIX}/bin/bash" \
>   gcc_do_make ${GCC_MAKE_TARGET}

> + if use ada; then
> + gcc_do_make "-C gcc gnatlib-shared"
> + ln -s gcc ../build/prev-gcc || die
> + ln -s ${CHOST} ../build/prev-${CHOST} || die
> + gcc_do_make "-C gcc gnattools"
> + fi

Two points:
1. You probably still need CONFIG_SHELL="${EPREFIX}/bin/bash" passed.
2. Can you add an inline comment why it's needed? Why 'make' does not Just Work?

-- 

  Sergei



Re: [gentoo-dev] [PATCH 2/2] multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl*

2020-03-28 Thread Sergei Trofimovich
On Sat, 28 Mar 2020 11:19:29 -0400
Mike Gilbert  wrote:

> On Sat, Mar 28, 2020 at 5:40 AM Sergei Trofimovich  wrote:
> >
> > In contrast to glibc musl profiles use 'lib' layour for 32-bit
> > and 64-bit targets. multilib_env() did not take it into account
> > and assumed glibc's lib64 layout.
> >
> > That breaks crossdev as it uses multilib_env to extract target
> > definition. Native builds are unaffected by this change.
> >
> > Bug: https://bugs.gentoo.org/675954
> > Bug: https://gcc.gnu.org/PR90077
> > Bug: https://github.com/gentoo/musl/issues/245
> > Signed-off-by: Sergei Trofimovich   
> 
> Please also update the copyright notice in multilib.eclass while you're at it.

Updated as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a687fd280c3d33cbf7ef99cd6f96fda95039c75

-- 

  Sergei



Re: [gentoo-dev] [PATCH 1/2] eclass/tests: add basic tests for multilib_env() expansion

2020-03-28 Thread Sergei Trofimovich
On Sat, 28 Mar 2020 11:17:42 -0400
Mike Gilbert  wrote:

> > --- /dev/null
> > +++ b/eclass/tests/multilib.sh
> > @@ -0,0 +1,61 @@
> > +#!/bin/bash
> > +# Copyright 1999-2020 Gentoo Foundation  
> 
> This should say "Copyright 2020 Gentoo Authors".
...
> > +# Pick a few interesting gargets from:  
> 
> Probably a typo: s/gargets/targets/

God point! Tweaked both as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a687fd280c3d33cbf7ef99cd6f96fda95039c75

-- 

  Sergei



Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: add some missing MIPS CPU errata options to ALLOWED_FLAGS

2020-03-28 Thread Sergei Trofimovich
On Sat, 28 Mar 2020 15:17:12 -0400
Joshua Kinard  wrote:

> Noticed during a glibc build for MIPS-III ISA that the -mfix-r4000
> and -mfix-r4400 gcc flags got stripped off.  These are needed to work
> around known CPU errata in R4000 and R4400 CPUs.  In addition, also
> add the -mfix-rm7000 option (and it's -mno form) to fix errata in the
> PMC RM7000 CPU, and the -mr10k-cache-barrier to control the generation
> of cache barriers to work around the side-effects of R1's
> speculative execution capabilities.
> 
> Signed-off-by: Joshua Kinard 
> ---
>  eclass/flag-o-matic.eclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index e76eef293e..0c67ec9f7a 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -56,7 +56,9 @@ setup-allowed-flags() {
>   -mno-faster-structs -mfaster-structs -m32 -m64 -mx32 -mabi
>   -mlittle-endian -mbig-endian -EL -EB -fPIC -mlive-g0 -mcmodel
>   -mstack-bias -mno-stack-bias -msecure-plt '-m*-toc' -mfloat-abi
> - -mfix-r1 -mno-fix-r1 -mthumb -marm
> + -mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
> + -mfix-rm7000 -mno-fix-rm7000 -mfix-r1 -mno-fix-r1
> + -mr10k-cache-barrier -mthumb -marm
>  
>   # gcc 4.5
>   -mno-fma4 -mno-movbe -mno-xop -mno-lwp

Looks good!

-- 

  Sergei



[gentoo-dev] [PATCH 2/2] multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl*

2020-03-28 Thread Sergei Trofimovich
In contrast to glibc musl profiles use 'lib' layour for 32-bit
and 64-bit targets. multilib_env() did not take it into account
and assumed glibc's lib64 layout.

That breaks crossdev as it uses multilib_env to extract target
definition. Native builds are unaffected by this change.

Bug: https://bugs.gentoo.org/675954
Bug: https://gcc.gnu.org/PR90077
Bug: https://github.com/gentoo/musl/issues/245
Signed-off-by: Sergei Trofimovich 
---
 eclass/multilib.eclass   | 13 -
 eclass/tests/multilib.sh |  4 
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 63bde5cbb60..8b4a7dacaa3 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -294,11 +294,22 @@ get_modname() {
 }
 
 # This is for the toolchain to setup profile variables when pulling in
-# a crosscompiler (and thus they aren't set in the profile)
+# a crosscompiler (and thus they aren't set in the profile).
 multilib_env() {
local CTARGET=${1:-${CTARGET}}
local cpu=${CTARGET%%*-}
 
+   if [[ ${CTARGET} = *-musl* ]]; then
+   # musl has no multilib support and can run only in 'lib':
+   # - https://bugs.gentoo.org/675954
+   # - https://gcc.gnu.org/PR90077
+   # - https://github.com/gentoo/musl/issues/245
+   : ${MULTILIB_ABIS=default}
+   : ${DEFAULT_ABI=default}
+   export MULTILIB_ABIS DEFAULT_ABI
+   return
+   fi
+
case ${cpu} in
aarch64*)
# Not possible to do multilib with aarch64 and a single 
toolchain.
diff --git a/eclass/tests/multilib.sh b/eclass/tests/multilib.sh
index 308c456b98d..68c0dd6e142 100755
--- a/eclass/tests/multilib.sh
+++ b/eclass/tests/multilib.sh
@@ -57,5 +57,9 @@ test-multilib_env \
"x86_64-pc-linux-gnux32" \
"x32:x32 amd64 x86" \
"x32? ( CHOST=x86_64-pc-linux-gnux32 LIBDIR=libx32 CFLAGS=-mx32 
LDFLAGS= ) amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 LDFLAGS= 
) x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
+test-multilib_env \
+   "x86_64-gentoo-linux-musl" \
+   "default:default" \
+   "default? ( CHOST=x86_64-gentoo-linux-musl LIBDIR=lib CFLAGS= LDFLAGS= 
)"
 
 texit
-- 
2.26.0




[gentoo-dev] [PATCH 1/2] eclass/tests: add basic tests for multilib_env() expansion

2020-03-28 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 eclass/tests/multilib.sh | 61 
 1 file changed, 61 insertions(+)
 create mode 100755 eclass/tests/multilib.sh

diff --git a/eclass/tests/multilib.sh b/eclass/tests/multilib.sh
new file mode 100755
index 000..308c456b98d
--- /dev/null
+++ b/eclass/tests/multilib.sh
@@ -0,0 +1,61 @@
+#!/bin/bash
+# Copyright 1999-2020 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+source tests-common.sh
+
+inherit multilib
+
+# Run 'multilib_env' and check what variables it expands to
+test-multilib_env() {
+   local target=$1 exp_abi=$2 exp_vars=" $3"
+   tbegin "expand-target $1"
+
+   # Reset default
+   unset MULTILIB_ABIS
+   unset DEFAULT_ABI
+   CFLAGS_default=
+   LDFLAGS_default=
+   LIBDIR_default=lib
+   CHOST_default=${target}
+   CTARGET_default=${CHOST_default}
+   LIBDIR_default=lib
+
+   multilib_env ${target}
+
+   local actual_abi="${DEFAULT_ABI}:${MULTILIB_ABIS}"
+
+   local actual_vars=""
+   local abi var v
+   for abi in ${MULTILIB_ABIS}; do
+   actual_vars+=" ${abi}? ("
+   for var in CHOST LIBDIR CFLAGS LDFLAGS; do
+   v=${var}_${abi}
+   actual_vars+=" ${var}=${!v}"
+   done
+   actual_vars+=" )"
+   done
+
+   [[ "${exp_abi}" == "${actual_abi}" && "${exp_vars}" == "${actual_vars}" 
]]
+
+   if ! tend $? ; then
+   printf '### EXPECTED ABI: %s\n' "${exp_abi}"
+   printf '### ACTUAL   ABI: %s\n' "${actual_abi}"
+   printf '### EXPECTED VARS: %s\n' "${exp_vars}"
+   printf '### ACTUAL   VARS: %s\n' "${actual_vars}"
+   fi
+}
+
+# Pick a few interesting gargets from:
+# $ grep -h -o -R 'CHOST=.*' ../../profiles/ | sort -u
+
+test-multilib_env \
+   "x86_64-pc-linux-gnu" \
+   "amd64:amd64 x86" \
+   "amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 LDFLAGS= ) 
x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
+test-multilib_env \
+   "x86_64-pc-linux-gnux32" \
+   "x32:x32 amd64 x86" \
+   "x32? ( CHOST=x86_64-pc-linux-gnux32 LIBDIR=libx32 CFLAGS=-mx32 
LDFLAGS= ) amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 LDFLAGS= 
) x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
+
+texit
-- 
2.26.0




Re: [gentoo-dev] [PATCH] toolchain.eclass: fix cygwinports patching

2020-03-16 Thread Sergei Trofimovich
On Mon, 16 Mar 2020 18:41:02 +0100
ha...@gentoo.org wrote:

> From: Michael Haubenwallner 
> 
> Introduction of tc_apply_patches dropped patch dir, per
> commit bd758f25a82460f6e7011314f9fb7923864e9e1e
> 
> Signed-off-by: Michael Haubenwallner 
> ---
>  eclass/toolchain.eclass | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 9f435921922..7135af0817d 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -646,7 +646,13 @@ do_gcc_CYGWINPORTS_patches() {
>  
>   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
>   # readarray -t is available since bash-4.4 only, #690686
> - local patches=( $(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
> "${d}"/gcc.cygport) )
> + local patches=( $(
> + for p in $(
> + sed -e '1,/PATCH_URI="/d;/"/,$d' < "${d}"/gcc.cygport
> + ); do
> + echo "${d}/${p}"
> + done
> + ) )
>   tc_apply_patches "Applying cygwin port patches ..." ${patches[*]}
>  }

Looks good. Please push it.


-- 

  Sergei



[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.

2020-03-11 Thread Sergei Trofimovich
On Tue, 10 Mar 2020 20:54:12 -0700
Manoj Gupta  wrote:

> On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich  wrote:
> 
> > On Mon, 2 Mar 2020 19:03:48 -0800
> > Manoj Gupta  wrote:
> >  
> > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich 
> > > wrote:
> > >  
> > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta   
> > wrote:  
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta   
> >  
> > > > wrote:  
> > > > >>
> > > > >> gcc-config installs cc/f77 by default. This may be undesired on
> > > > >> systems that want to set their own versions of cc/f77.
> > > > >>
> > > > >> Add option "-n"/"--no-default-vars" to not install the cc/f77
> > > > >> wrappers.
> > > > >>
> > > > >> Signed-off-by: Manoj Gupta 
> > > > >> ---
> > > > >>  gcc-config | 6 +-
> > > > >>  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/gcc-config b/gcc-config
> > > > >> index f03a46a..6f306db 100755
> > > > >> --- a/gcc-config
> > > > >> +++ b/gcc-config
> > > > >> @@ -262,7 +262,7 @@ update_wrappers() {
> > > > >> # For all toolchains, we want to create the fully qualified
> > > > >> # `tuple-foo`.  Only native ones do we want the simple  
> > `foo`.  
> > > > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} )
> > > > >> -   if ! is_cross_compiler ; then
> > > > >> +   if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" == "yes"  
> > ]];  
> > > > then  
> > > > >> all_wrappers+=( "${new_wrappers[@]}" )
> > > > >> # There are a few fun extra progs which we have to  
> > > > handle #412319  
> > > > >> all_wrappers+=( cc:gcc f77:g77 )
> > > > >> @@ -951,6 +951,7 @@ FORCE="no"
> > > > >>  CC_COMP=
> > > > >>  ENV_D="${EROOT}etc/env.d"
> > > > >>  GCC_ENV_D="${ENV_D}/gcc"
> > > > >> +DEFAULT_PROGS="yes"
> > > > >>
> > > > >>  for x in "$@" ; do
> > > > >> case "${x}" in
> > > > >> @@ -972,6 +973,9 @@ for x in "$@" ; do
> > > > >> -l|--list-profiles)
> > > > >> set_doit list_profiles
> > > > >> ;;
> > > > >> +   -n|--no-default-vars)
> > > > >> +   DEFAULT_PROGS="no"
> > > > >> +   ;;
> > > > >> -S|--split-profile)
> > > > >> if [[ ( $1 != "-S" && $1 !=  
> > "--split-profile" )  
> > > > || $# -eq 1 ]] ; then  
> > > > >> usage 1
> > > > >> --
> > > > >>  
> > > > >
> > > > > Not sure of the correct mailing list for patches to gcc-config so  
> > also  
> > > > adding toolchain@gentoo .  
> > > > >  
> > > >
> > > > toolch...@gentoo.org should generally be fine.
> > > >
> > > > Today cc->gcc and gcc->${CHOST}-gcc symlinks are effectively owned by
> > > > a single sys-devel/gcc-config package.
> > > > gcc-config is calld to update symlinks every time sys-devel/gcc is
> > > > installed/updated. That way we never get cc/gcc
> > > > out of sync.
> > > >
> > > > Your change makes /usr/bin/cc an orphan symlink. I think we need to
> > > > still keep a 'cc'/'f77' ownership somewhere
> > > > (say, a separate package).
> > > >
> > > > I suggest making a decision to handle or not handle 'cc'/'f77' and
> > > > gcc-config build-time, not gcc-config call-time.
> > > > That way sys-devel/gcc updates will behave the same as manual
> > > > 'gcc-config-' calls.
> > > >
> > > > Mechanically that could be a Makefile variable that switches the
> > > 

[gentoo-dev] Re: [PATCH] profiles: remove USE="cxx" from the base profile

2020-03-09 Thread Sergei Trofimovich
On Mon,  9 Mar 2020 11:25:48 -0400
Mike Gilbert  wrote:

> This was added back in the days when all toolchain ebuilds had EAPI=0
> and IUSE defaults were not an option. toolchain.eclass now supports
> newer EAPIs, and sets IUSE="+cxx".
> 
> Signed-off-by: Mike Gilbert 
> ---
>  profiles/base/make.defaults | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
> index f4782af3b138..cf27a009b57c 100644
> --- a/profiles/base/make.defaults
> +++ b/profiles/base/make.defaults
> @@ -102,12 +102,6 @@ LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 
> lcdm001 mtxorb ncurses te
>  # Updated to include ruby25 on 2019-07-17
>  RUBY_TARGETS="ruby24 ruby25"
>  
> -# Samuli Suominen  (2009-12-03)
> -# Enable USE cxx by default so base-system and toolchain pkgs can start 
> using USE cxx
> -# instead of USE nocxx.
> -# 
> https://archives.gentoo.org/gentoo-dev/msg_a181cd0d36600067b599f4b996c6989f.xml
> -USE="${USE} cxx"
> -
>  # Enable extended filesystem attribute support by default.
>  # 
> https://archives.gentoo.org/gentoo-dev/message/ba0e3457e4b807e79816f0df03566af0
>  USE="${USE} xattr"
> -- 
> 2.25.1
> 

Looks good.

Looking at
   $ git grep -P 'IUSE.*[" ]cxx' # (full output) http://dpaste.com/1D0RC27.txt
notable changes are:
  dev-libs/boehm-gc/boehm-gc-8.0.4.ebuild:IUSE="cxx static-libs +threads"
  dev-libs/gmp/gmp-6.2.0.ebuild:IUSE="+asm doc cxx pic static-libs"
  sys-libs/db/db-18.1.32.ebuild:IUSE="doc java cxx tcl test"
and maybe
  app-text/poppler/poppler-0.86.1.ebuild:IUSE="cairo cjk curl cxx debug doc 
+introspection +jpeg +jpeg2k +lcms nss png qt5 tiff +utils"

-- 

  Sergei



Re: [gentoo-dev] [PATCH] ghc-package.eclass: limit the ghc parallel jobs to 64.

2020-03-06 Thread Sergei Trofimovich
On Fri,  6 Mar 2020 16:06:00 +0800
hero...@gentoo.org wrote:

> From: Benda Xu 
> 
>   If ghc spawns too many C compilers, it will exhaust file descripters.

I don't think ghc spawns more than 1 parallel gcc per compiled haskell file.
I'd expect a small constant overhead of file descriptors per compilation thread,
something like 5 fds (not 16 as your '64' limit implies):

- 2 opened files for write a result (one .hi and one .o file)
- 3 file descriptors per external tool to handle pipe std{in,out,err}.

Unless it's a -split-objs effect (which I don't believe is done in parallel), 
then
the FD limit is orthogonal to job count.

Running 'strace -f -y' against `ghc --make` invocation should make it obvious.

Please file a bug to find out where these file descriptors come from.

Once we understand better where descriptors come from the bug might
need to go upstream eventually to more explicitly manage scarce fd resources
on the side of compilation manager. There should be no reason to limit 
parallelism
as long as there is no external process forking.

>   In the reference, it was thought to be a macOS bug for aggressive fd
>   limits.  But the ghc bug also applies to GNU/Linux, when ghc is
>   asked to spawn, for example 256, jobs.
> 
>   This patch circumvents this ghc design flaw.

I don't see it as a design flaw.

> Reference: https://github.com/commercialhaskell/stack/issues/1177
> Reference: https://github.com/commercialhaskell/stack/issues/1979
> Signed-off-by: Benda Xu 
> ---
>  eclass/ghc-package.eclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/ghc-package.eclass b/eclass/ghc-package.eclass
> index 5361f09af1e9..d729f4a407b4 100644
> --- a/eclass/ghc-package.eclass
> +++ b/eclass/ghc-package.eclass
> @@ -203,7 +203,9 @@ ghc-make-args() {
>   #https://ghc.haskell.org/trac/ghc/ticket/9221#comment:57
>   # SMP is a requirement for parallel GC's gen0
>   # 'qb' balancing.
> - echo "-j$(makeopts_jobs) +RTS -A256M -qb0 -RTS"
> + local n=$(makeopts_jobs)
> + [[ ${n} -gt 64 ]] && n=64
> + echo "-j${n} +RTS -A256M -qb0 -RTS"

Needs an in-source comment why a limit is imposed. Otherwise looks ok to push
while we are figuring out the limits. And a an explanation how it was 
calculated.

>   ghc_make_args=()
>   fi
>   echo "${ghc_make_args[@]}"
> -- 
> 2.25.0
> 
>

-- 

  Sergei



[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.

2020-03-03 Thread Sergei Trofimovich
On Mon, 2 Mar 2020 19:03:48 -0800
Manoj Gupta  wrote:

> On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich 
> wrote:
> 
> > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta  wrote:  
> > >
> > >
> > >
> > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta   
> > wrote:  
> > >>
> > >> gcc-config installs cc/f77 by default. This may be undesired on
> > >> systems that want to set their own versions of cc/f77.
> > >>
> > >> Add option "-n"/"--no-default-vars" to not install the cc/f77
> > >> wrappers.
> > >>
> > >> Signed-off-by: Manoj Gupta 
> > >> ---
> > >>  gcc-config | 6 +-
> > >>  1 file changed, 5 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/gcc-config b/gcc-config
> > >> index f03a46a..6f306db 100755
> > >> --- a/gcc-config
> > >> +++ b/gcc-config
> > >> @@ -262,7 +262,7 @@ update_wrappers() {
> > >> # For all toolchains, we want to create the fully qualified
> > >> # `tuple-foo`.  Only native ones do we want the simple `foo`.
> > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} )
> > >> -   if ! is_cross_compiler ; then
> > >> +   if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" == "yes" ]];  
> > then  
> > >> all_wrappers+=( "${new_wrappers[@]}" )
> > >> # There are a few fun extra progs which we have to  
> > handle #412319  
> > >> all_wrappers+=( cc:gcc f77:g77 )
> > >> @@ -951,6 +951,7 @@ FORCE="no"
> > >>  CC_COMP=
> > >>  ENV_D="${EROOT}etc/env.d"
> > >>  GCC_ENV_D="${ENV_D}/gcc"
> > >> +DEFAULT_PROGS="yes"
> > >>
> > >>  for x in "$@" ; do
> > >> case "${x}" in
> > >> @@ -972,6 +973,9 @@ for x in "$@" ; do
> > >> -l|--list-profiles)
> > >> set_doit list_profiles
> > >> ;;
> > >> +   -n|--no-default-vars)
> > >> +   DEFAULT_PROGS="no"
> > >> +   ;;
> > >> -S|--split-profile)
> > >> if [[ ( $1 != "-S" && $1 != "--split-profile" )  
> > || $# -eq 1 ]] ; then  
> > >> usage 1
> > >> --
> > >>  
> > >
> > > Not sure of the correct mailing list for patches to gcc-config so also  
> > adding toolchain@gentoo .  
> > >  
> >
> > toolch...@gentoo.org should generally be fine.
> >
> > Today cc->gcc and gcc->${CHOST}-gcc symlinks are effectively owned by
> > a single sys-devel/gcc-config package.
> > gcc-config is calld to update symlinks every time sys-devel/gcc is
> > installed/updated. That way we never get cc/gcc
> > out of sync.
> >
> > Your change makes /usr/bin/cc an orphan symlink. I think we need to
> > still keep a 'cc'/'f77' ownership somewhere
> > (say, a separate package).
> >
> > I suggest making a decision to handle or not handle 'cc'/'f77' and
> > gcc-config build-time, not gcc-config call-time.
> > That way sys-devel/gcc updates will behave the same as manual
> > 'gcc-config-' calls.
> >
> > Mechanically that could be a Makefile variable that switches the
> > behaviour on/off at
> > https://gitweb.gentoo.org/proj/gcc-config.git/tree/Makefile
> > and exposed as an USE flag on sys-devel/gcc-config ebuild.
> >
> > Later we can create a separate ebuild to manage /usr/bin/cc. For gcc
> > it's not hard, as gcc-config always provides /usr/bin/gcc and
> > /usr/bin/${CHOST}-gcc.
> > These can be static symlinks that don't require maintenance updates.
> >
> > Thanks for the suggestion. I will look into adding a Makefile variable  
> exposed via an USE flag.

You might also need to look in the detail at 'c++', 'cpp' and ${CHOST}-* 
equivalents
as those also get linked by gcc-config:

$ LANG=C ls -l /usr/bin/ | fgrep 10.0.1 | fgrep -v -- '-10.0.1 ->'
lrwxrwxrwx   1 root root   43 Feb  4 10:45 c++ -> 
/usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/c++
lrwxrwxrwx   1 root root   43 Feb  4 10:45 cc -> 
/usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc
lrwxrwxrwx   1 root root   43 Feb  4 10:45 cpp -> 
/usr/x86_64-

[gentoo-dev] binutils-2.34 breakage

2020-02-02 Thread Sergei Trofimovich
Yesterday binutils-2.34 / binutils-libs-2.34 landed into gentoo.

binutils-2.34 should generally be fine.

binutils-libs-2.34 caused a bit of breakage like
"undefined reference to bfd_get_section_flags"

These are trivial to fix either via conditional patching (API usage is usually 
tiny)
or via a bit of #ifdef-ery.

Tracker bug: https://bugs.gentoo.org/707898
Tips to fix your packages: 
https://wiki.gentoo.org/wiki/Project:Toolchain#binutils-2.34

-- 

  Sergei



[gentoo-dev] CFLAGS=-fno-common related breakage is incoming

2020-01-19 Thread Sergei Trofimovich
> What is happening?

gcc-10 is coming soon. It will be more disruptive than gcc-9.

One of the major changes is the switch from C{,XX}FLAGS=-fcommon
to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678

It's a planned change and not a gcc regression. It will expose some
warts on old code and unblock minor optimisations accessing globals.

The change has already happened in gcc trunk.

> Is my package affected? Should I do anything?

You can check proactively if your packages are affected.

Add -fno-common to your make.conf's C{,XX}FLAGS and
see if things still build.

The typical symptom is a linker failure on multiple definitions
for some global variable:

 ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0): first 
defined here

> How to fix it?

https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common contains
some examples. Ideally code will need a few 'extern' additions and maybe
moving variable definitions.

Example of proposed openrc fix:
https://github.com/OpenRC/openrc/pull/348

Adding 'append-flags -fcommon' might work as a temporary workaround.

> Can I help?

Glad you asked! We will need to gather failed packages and fix them
upstream and downstream. Here is what you can do:

1. Add -fno-common to your make.conf's C{,XX}FLAGS
2. Build packages you maintain
3. Fix a bug upstream (or report a failure).
4. Pull a fix downstream (or file a bug and add it to the tracker).

> What is already known to be broken? Can I look at example fixes?

See https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
for an artificial example.

Gentoo tracker bug of known issues:
  https://bugs.gentoo.org/705764
15 bugs so far.

SUSE tracker bug of known issues:
  https://bugzilla.suse.com/show_bug.cgi?id=1160244
95 bugs so far. A good source of packages to check against the
ones you care about.

> What does -fcommon do?

Look up -fcommon in https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

> I have no idea why my package broke. The error does not make sense.

Feel free to CC toolchain@ on a bug you observe and we'll try to sort it out.

-- 

  Sergei



[gentoo-dev] Lexicographical bash comparison mistakes: things to fix

2020-01-12 Thread Sergei Trofimovich
A few ebuilds use bash '[[ ${foo} < ${bar} ]]' comparison to compare
numbers and package versions.

In bash '<' is for lexicographical string comparison (see man bash
'CONDITIONAL EXPRESSIONS' section). It's almost never what
you want:

$ [[ 1.2.3 < 1.2.3 ]] && echo yes || echo no
no # ok
$ [[ 1.2.9 < 1.2.3 ]] && echo yes || echo no
no # ok
$ [[ 1.2.9 < 1.2.10 ]] && echo yes || echo no
no # whoops

A very crude grep shows many affected packages:
$ git grep -E '\[\[.*[<>]\s*[0-9]+.*\]\]' | cat
app-misc/unfoo/unfoo-1.0.8.ebuild:  elif [[ ${REPLACING_VERSIONS} < 1.0.7 
]]; then
dev-db/libzdb/libzdb-3.1-r1.ebuild: if  [[ $(gcc-version) < 4.1 ]];then
dev-db/libzdb/libzdb-3.1.ebuild:if  [[ $(gcc-version) < 4.1 ]];then
eclass/kernel-2.eclass: if [[ ${K_SYMLINK} > 0 ]]; then
eclass/kernel-2.eclass: if [[ ${KV_MAJOR} -ge 3 || 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
eclass/kernel-2.eclass: if [[ ${KV_MAJOR} -ge 3 || 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
eclass/kernel-2.eclass: if [[ -n ${KV_MINOR} &&  
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 ]] ; then
...  ...

Some of them are benign like '[[ ${foo} > 0 ]]': I think it's still worth 
fixing them.
Some of them are worse like [[ $(gcc-version) < 4.1 ]]: gcc-version=10 will 
break here.

I've created a tracker and dumped a few suspects there:
https://bugs.gentoo.org/705240

I'm sure there are more creative ways to hide version (or just number)
compare behind lexicographical string comparison. If you have an idea how
grep those out please do report and fix them :)

Thank you!

-- 

  Sergei



[gentoo-dev] Re: [PATCH] flag-o-matic.eclass: add LDFLAGS testing against linker

2019-12-25 Thread Sergei Trofimovich
On Mon, 23 Dec 2019 11:50:43 +
Sergei Trofimovich  wrote:

> Before the change we tested only compiler driver (gcc flag parser)
> for LDFLAGS.
> 
> This does not cover cases when we would really like to filter out
> unsupported linker flags like -Wl,--hash-style=gnu passed to non-ELF
> targets.
> 
> The change adds test-flag-CCLD() helper to perform all of assembly,
> compilation and linking steps. Helper is used to filter LDFLAGS variable
> in strip-unsupported-flags().
> 
> Closes: https://bugs.gentoo.org/333763
> Signed-off-by: Sergei Trofimovich 
> ---

Pushed as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass?id=28d6437fc7009002f98f28e8900e994109927726

>  eclass/flag-o-matic.eclass   | 72 +---
>  eclass/tests/flag-o-matic.sh |  2 +-
>  2 files changed, 59 insertions(+), 15 deletions(-)
> 
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index f882b09d621..0aec22c83f2 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -441,29 +441,63 @@ test-flag-PROG() {
>   # 'type' needs a binary name
>   type -p ${comp[0]} >/dev/null || return 1
>  
> + # Set up test file.
> + local in_src in_ext cmdline_extra=()
> + case "${lang}" in
> + # compiler/assembler only
> + c)
> + in_ext='.c'
> + in_src='int main(void) { return 0; }'
> + cmdline_extra+=(-xc -c)
> + ;;
> + c++)
> + in_ext='.cc'
> + in_src='int main(void) { return 0; }'
> + cmdline_extra+=(-xc++ -c)
> + ;;
> + f77)
> + in_ext='.f'
> + # fixed source form
> + in_src='  end'
> + cmdline_extra+=(-xf77 -c)
> + ;;
> + f95)
> + in_ext='.f90'
> + in_src='end'
> + cmdline_extra+=(-xf95 -c)
> + ;;
> +
> + # C compiler/assembler/linker
> + c+ld)
> + in_ext='.c'
> + in_src='int main(void) { return 0; }'
> + cmdline_extra+=(-xc)
> + ;;
> + esac
> + local test_in=${T}/test-flag-${comp}.${lang}
> + local test_out=${T}/test-flag-${comp}.exe
> +
> + printf "%s\n" "${in_src}" > "${test_in}" || return 1
> +
>   local cmdline=(
>   "${comp[@]}"
>   # Clang will warn about unknown gcc flags but exit 0.
>   # Need -Werror to force it to exit non-zero.
>   -Werror
> - # Use -c so we can test the assembler as well.
> - -c -o /dev/null
> + "$@"
> + # -x options need to go before first source file
> + "${cmdline_extra[@]}"
> +
> + "${test_in}" -o "${test_out}"
>   )
> - if "${cmdline[@]}" -x${lang} - /dev/null ; then
> - cmdline+=( "$@" -x${lang} - )
> - else
> - # XXX: what's the purpose of this? does it even work with
> - # any compiler?
> - cmdline+=( "$@" -c -o /dev/null /dev/null )
> - fi
>  
> - if ! "${cmdline[@]}" /dev/null; then
> + if ! "${cmdline[@]}" &>/dev/null; then
>   # -Werror makes clang bail out on unused arguments as well;
>   # try to add -Qunused-arguments to work-around that
>   # other compilers don't support it but then, it's failure like
>   # any other
>   cmdline+=( -Qunused-arguments )
> - "${cmdline[@]}" /dev/null
> + "${cmdline[@]}" &>/dev/null
>   fi
>  }
>  
> @@ -491,6 +525,12 @@ test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
>  # Returns shell true if  is supported by the Fortran 90 compiler, else 
> returns shell false.
>  test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
>  
> +# @FUNCTION: test-flag-CCLD
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Returns shell true if  is supported by the C compiler and linker, 
> else returns shell false.
> +test-flag-CCLD() { test-flag-PROG "CC" c+ld "$@"; }
> +
>  test-flags-PROG() {
>   local comp=$1
>   local flags=()
> @@ -548,6 +588,12 @@ test-flags-F77() { test-flags-PROG "F77" "$@";

Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-12-24 Thread Sergei Trofimovich
On Mon, 7 Oct 2019 22:27:23 +1100
Michael Palimaka  wrote:

> Sorry for the late reply here.
> 
> On 10/3/19 1:43 AM, Matt Turner wrote:
> > On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich  
> > wrote:  
> >>
> >> I noticed that stable-bot stopped marking bugs as verified for 
> >> stbilization.
> >> Example:
> >>  https://bugs.gentoo.org/695252
> >>
> >> 1. Is it gone forever and arch teams should stop relying on it's presence? 
> >>  
> 
> There was some temporary, unintentional breakage which regrettably I did 
> not notice. Thanks to whissi for pinging me.
> 
> >> 2. If not can the owner tweak it?  
> 
> stable-bot has since returned to normal service.
> 
> >> 3. Can we have a wiki page that describes the setup and who to send 
> >> reports to?
> >> Doc would be useful to run it locally, send bugs/enhancements, post 
> >> current
> >> status if it's known to be broken.  
> 
> I agree, this is long overdue.
> 
> > It looks like it is working now, but I think we really should know a few 
> > things:
> > 
> > (1) Who maintains it  
> 
> That is me.
> 
> > (2) Where the code is  
> Due to slacking on my part, the code currently just lives on my server. 
> The intention has always been to clean it up and publish it with the 
> client at https://github.com/kensington/bugbot.
> 
> > (3) and perhaps what happened to bring it down  
> vixie-cron got last-rited and I neglected to configure its placement 
> correctly.
> 

I've added a stub page for stable bot:
https://wiki.gentoo.org/wiki/Stable_bot

Eeveryone, feel free to dump more stuff there.

-- 

  Sergei



[gentoo-dev] [PATCH] flag-o-matic.eclass: add LDFLAGS testing against linker

2019-12-23 Thread Sergei Trofimovich
Before the change we tested only compiler driver (gcc flag parser)
for LDFLAGS.

This does not cover cases when we would really like to filter out
unsupported linker flags like -Wl,--hash-style=gnu passed to non-ELF
targets.

The change adds test-flag-CCLD() helper to perform all of assembly,
compilation and linking steps. Helper is used to filter LDFLAGS variable
in strip-unsupported-flags().

Closes: https://bugs.gentoo.org/333763
Signed-off-by: Sergei Trofimovich 
---
 eclass/flag-o-matic.eclass   | 72 +---
 eclass/tests/flag-o-matic.sh |  2 +-
 2 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index f882b09d621..0aec22c83f2 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -441,29 +441,63 @@ test-flag-PROG() {
# 'type' needs a binary name
type -p ${comp[0]} >/dev/null || return 1
 
+   # Set up test file.
+   local in_src in_ext cmdline_extra=()
+   case "${lang}" in
+   # compiler/assembler only
+   c)
+   in_ext='.c'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc -c)
+   ;;
+   c++)
+   in_ext='.cc'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc++ -c)
+   ;;
+   f77)
+   in_ext='.f'
+   # fixed source form
+   in_src='  end'
+   cmdline_extra+=(-xf77 -c)
+   ;;
+   f95)
+   in_ext='.f90'
+   in_src='end'
+   cmdline_extra+=(-xf95 -c)
+   ;;
+
+   # C compiler/assembler/linker
+   c+ld)
+   in_ext='.c'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc)
+   ;;
+   esac
+   local test_in=${T}/test-flag-${comp}.${lang}
+   local test_out=${T}/test-flag-${comp}.exe
+
+   printf "%s\n" "${in_src}" > "${test_in}" || return 1
+
local cmdline=(
"${comp[@]}"
# Clang will warn about unknown gcc flags but exit 0.
# Need -Werror to force it to exit non-zero.
-Werror
-   # Use -c so we can test the assembler as well.
-   -c -o /dev/null
+   "$@"
+   # -x options need to go before first source file
+   "${cmdline_extra[@]}"
+
+   "${test_in}" -o "${test_out}"
)
-   if "${cmdline[@]}" -x${lang} - /dev/null ; then
-   cmdline+=( "$@" -x${lang} - )
-   else
-   # XXX: what's the purpose of this? does it even work with
-   # any compiler?
-   cmdline+=( "$@" -c -o /dev/null /dev/null )
-   fi
 
-   if ! "${cmdline[@]}" /dev/null; then
+   if ! "${cmdline[@]}" &>/dev/null; then
# -Werror makes clang bail out on unused arguments as well;
# try to add -Qunused-arguments to work-around that
# other compilers don't support it but then, it's failure like
# any other
cmdline+=( -Qunused-arguments )
-   "${cmdline[@]}" /dev/null
+   "${cmdline[@]}" &>/dev/null
fi
 }
 
@@ -491,6 +525,12 @@ test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
 # Returns shell true if  is supported by the Fortran 90 compiler, else 
returns shell false.
 test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
 
+# @FUNCTION: test-flag-CCLD
+# @USAGE: 
+# @DESCRIPTION:
+# Returns shell true if  is supported by the C compiler and linker, else 
returns shell false.
+test-flag-CCLD() { test-flag-PROG "CC" c+ld "$@"; }
+
 test-flags-PROG() {
local comp=$1
local flags=()
@@ -548,6 +588,12 @@ test-flags-F77() { test-flags-PROG "F77" "$@"; }
 # Returns shell true if  are supported by the Fortran 90 compiler, else 
returns shell false.
 test-flags-FC() { test-flags-PROG "FC" "$@"; }
 
+# @FUNCTION: test-flags-CCLD
+# @USAGE: 
+# @DESCRIPTION:
+# Returns shell true if  are supported by the C compiler and default 
linker, else returns shell false.
+test-flags-CCLD() { test-flags-PROG "CCLD" "$@"; }
+
 # @FUNCTION: test-flags
 # @USAGE: 
 # @DESCRIPTION:
@@ -576,9 +622,7 @@ strip-unsupported-flags() {
export CXXFLAGS=$(test-flags-CXX ${CXXFLAGS})
export FFLAGS=$(test-flags-F77 ${FFL

[gentoo-dev] [PATCH] flag-o-matic.eclass: add LDFLAGS testing against linker

2019-12-23 Thread Sergei Trofimovich
Before the change we tested only compiler driver (gcc flag parser)
for LDFLAGS.

This does not cover cases when we would really like to filter out
unsupported linker flags like -Wl,--hash-style=gnu passed to non-ELF
targets.

The change adds test-flag-CCLD() helper to perform all of assembly,
compilation and linking steps. Helper is used to filter LDFLAGS variable
in strip-unsupported-flags().

Closes: https://bugs.gentoo.org/333763
Signed-off-by: Sergei Trofimovich 
---
 eclass/flag-o-matic.eclass   | 72 +---
 eclass/tests/flag-o-matic.sh |  2 +-
 2 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index f882b09d621..0aec22c83f2 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -441,29 +441,63 @@ test-flag-PROG() {
# 'type' needs a binary name
type -p ${comp[0]} >/dev/null || return 1
 
+   # Set up test file.
+   local in_src in_ext cmdline_extra=()
+   case "${lang}" in
+   # compiler/assembler only
+   c)
+   in_ext='.c'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc -c)
+   ;;
+   c++)
+   in_ext='.cc'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc++ -c)
+   ;;
+   f77)
+   in_ext='.f'
+   # fixed source form
+   in_src='  end'
+   cmdline_extra+=(-xf77 -c)
+   ;;
+   f95)
+   in_ext='.f90'
+   in_src='end'
+   cmdline_extra+=(-xf95 -c)
+   ;;
+
+   # C compiler/assembler/linker
+   c+ld)
+   in_ext='.c'
+   in_src='int main(void) { return 0; }'
+   cmdline_extra+=(-xc)
+   ;;
+   esac
+   local test_in=${T}/test-flag-${comp}.${lang}
+   local test_out=${T}/test-flag-${comp}.exe
+
+   printf "%s\n" "${in_src}" > "${test_in}" || return 1
+
local cmdline=(
"${comp[@]}"
# Clang will warn about unknown gcc flags but exit 0.
# Need -Werror to force it to exit non-zero.
-Werror
-   # Use -c so we can test the assembler as well.
-   -c -o /dev/null
+   "$@"
+   # -x options need to go before first source file
+   "${cmdline_extra[@]}"
+
+   "${test_in}" -o "${test_out}"
)
-   if "${cmdline[@]}" -x${lang} - /dev/null ; then
-   cmdline+=( "$@" -x${lang} - )
-   else
-   # XXX: what's the purpose of this? does it even work with
-   # any compiler?
-   cmdline+=( "$@" -c -o /dev/null /dev/null )
-   fi
 
-   if ! "${cmdline[@]}" /dev/null; then
+   if ! "${cmdline[@]}" &>/dev/null; then
# -Werror makes clang bail out on unused arguments as well;
# try to add -Qunused-arguments to work-around that
# other compilers don't support it but then, it's failure like
# any other
cmdline+=( -Qunused-arguments )
-   "${cmdline[@]}" /dev/null
+   "${cmdline[@]}" &>/dev/null
fi
 }
 
@@ -491,6 +525,12 @@ test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
 # Returns shell true if  is supported by the Fortran 90 compiler, else 
returns shell false.
 test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
 
+# @FUNCTION: test-flag-CCLD
+# @USAGE: 
+# @DESCRIPTION:
+# Returns shell true if  is supported by the C compiler and linker, else 
returns shell false.
+test-flag-CCLD() { test-flag-PROG "CC" c+ld "$@"; }
+
 test-flags-PROG() {
local comp=$1
local flags=()
@@ -548,6 +588,12 @@ test-flags-F77() { test-flags-PROG "F77" "$@"; }
 # Returns shell true if  are supported by the Fortran 90 compiler, else 
returns shell false.
 test-flags-FC() { test-flags-PROG "FC" "$@"; }
 
+# @FUNCTION: test-flags-CCLD
+# @USAGE: 
+# @DESCRIPTION:
+# Returns shell true if  are supported by the C compiler and default 
linker, else returns shell false.
+test-flags-CCLD() { test-flags-PROG "CCLD" "$@"; }
+
 # @FUNCTION: test-flags
 # @USAGE: 
 # @DESCRIPTION:
@@ -576,9 +622,7 @@ strip-unsupported-flags() {
export CXXFLAGS=$(test-flags-CXX ${CXXFLAGS})
export FFLAGS=$(test-flags-F77 ${FFL

Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-18 Thread Sergei Trofimovich
On Wed, 18 Dec 2019 22:02:47 +0100
Sebastian Pipping  wrote:

> Hi all,
> 
> 
> I noticed that dev-util/cmake depends on dev-libs/expat and that
> libexpat upstream (where I'm involved) is in the process of
> dropping GNU Autotools altogether in favor of CMake in the near future,
> potentially the next release (without any known target release date).
> 
> CMake bundles a (previously outdated and vulnerable) copy of expat so
> I'm not sure if re-activating that bundle — say with a new use flag
> "system-expat" — would be a good thing to resort to for breaking the
> cycle, with regard to security in particular.
> 
> Do you have any ideas how to avoid a bad circular dependency issue for
> our users in the future?  Are you aware of similar problems and
> solutions from the past?

Fun fact: cmake is not keyworded for riscv.

To think of solutions enumerating the arising problems explicitly might
help here. I see a few:
1. initial system bootstrap requires solving a circular dependency
2. recovery from broken state (expat soname bump without preserved
  libs or cmake broken by one of many depends it has)

[2.] effectively forbids a dependency circle.

[1.] is hard to solve without users' intervention to at least flip a default 
flag.

Some other distributions provide two packages to break the cycle.
Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild",
"expat.ebuild" depends on "cmake-with-bundled-expat.ebuild".

Some examples of circular dependencies are:
a) gcc/glibc/binutils toolchain. the solution is to provide prebuilt
  binaries as part of stage3.
b) self-hosted languages without an interpreter in C (rust, golang, ghc).
  The solution is to provide prebuilt binaries in ebuilds.
c) circular dependencies in tests. The solution is careful user's USE flags
  juggling: enable USE=test only for a package being tested.
d) glibc depends on libidn2 to implement modern DNS demangling.
glibc fixes it by not depending on libidn at build time and does manual
library loading with dlopen()/dlsym().
e) vast majority of others: dependency bundling (users of autotools, gnulib, 
zlib, lua).

All the above are not pretty. a) is simplest to maintain by ebuild maintainer
and gentoo user, but probably not by releng. c) moves the burden to user.

I personally would explore [e]: unconditional bundling of expat into
cmake and make sure it's kept up-to-date there.

[c] would be nice to be solved at portage level if portage could schedule
multiple merges for the same package with different USE flags.

-- 

  Sergei



[gentoo-dev] Re: [PATCH] haskell-cabal.eclass: Fix MissingTestRestrict

2019-12-11 Thread Sergei Trofimovich
On Wed, 11 Dec 2019 10:51:36 +0100
Michał Górny  wrote:

> This fixes 564 cases of MissingTestRestrict.  According to md5-cache
> inspection, no other changes in metadata occur.
> 
> Signed-off-by: Michał Górny 

Looks good.

> ---
>  eclass/haskell-cabal.eclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/haskell-cabal.eclass b/eclass/haskell-cabal.eclass
> index 30b67bf7af94..2fc797e764cb 100644
> --- a/eclass/haskell-cabal.eclass
> +++ b/eclass/haskell-cabal.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Authors
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: haskell-cabal.eclass
> @@ -137,6 +137,7 @@ fi
>  
>  if [[ -n "${CABAL_TEST_SUITE}" ]]; then
>   IUSE="${IUSE} test"
> + RESTRICT+=" !test? ( test )"
>  fi
>  
>  # returns the version of cabal currently in use.
> -- 
> 2.24.0
> 


-- 

  Sergei



Re: [gentoo-dev] [PATCH v3] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.

2019-12-07 Thread Sergei Trofimovich
On Sat, 07 Dec 2019 06:44:21 +0100
Ulrich Mueller  wrote:

> >>>>> On Sat, 07 Dec 2019, Sergei Trofimovich wrote:  
> 
> >># The user wants us to leave things be.
> >> -  if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
> >> +  if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
> >>return 0
> >>fi  
> 
> > The rest of patch looks ok but I find I_KNOW_WHAT_I_AM_DOING
> > proliferation worrying. Having enough eclasses guard things on it I
> > don't really know what I am doing :)  
> 
> > For example developer profile sets it on by default and disables perl
> > error checks. I don't think it's intentional.  
> 
> Oh, I forgot that it is set globally in the developer profile (and I
> think that's a stupid idea). Indeed we should use a different variable
> then.
> 
> > I suggest giving this variable a unique specific name.  
> 
> Would it be acceptable to leave DONT_MOUNT_BOOT in place? It would have
> the advantage that users won't have to update their config.

Sounds good.

> > And phase out ${I_KNOW_WHAT_I_AM_DOING} uses from tree completely.  
> 
> That's a separate discussion.

Sure. As long as we don't add extra uses.


-- 

  Sergei


pgpYQCLmDsRHx.pgp
Description: Цифровая подпись OpenPGP


Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-07 Thread Sergei Trofimovich
On Fri, 06 Dec 2019 16:16:32 -0800
Georgy Yakovlev  wrote:

> On Friday, December 6, 2019 3:44:38 PM PST Sergei Trofimovich wrote:
> > On Fri,  6 Dec 2019 12:09:31 -0800
> > 
> > Georgy Yakovlev  wrote:  
> > > Default output just prints crate name.
> > > With -vv we can see all cargo options and rustc args.
> > > 
> > > Signed-off-by: Georgy Yakovlev 
> > > ---  
> > 
> > Looks good!
> > 
> > I had to do an equivalent locally at least a few times.  
> Pushed!
> > 
> > While at it I also suggest adding equivalent of
> > econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
> > to allow users to inject arbitrary stuff. For example
> > to sneak in '-Z' options globally.
> > 
> > Say, ${CARGO_BUILD_EXTRA},  ${CARGO_INSTALL_EXTRA},
> > ${CARGO_TEST_EXTRA}.
> >   
> 
> Yeah, it's on my to-do list for this eclass.
> 1 question tho, should it come after "$@" or before? Do you use it?
> I know cargo can be picky about order and some ebuilds rely on passing params 
> in phase funcs.

I don't use it frequently for carge.eclass but use it extensively for
./configure and haskell-cabal.eclass. I'd say variables are designed to
override everything else (eclass defaults and ebuild values) and thus
should come after "$@":
econf() { ... "$@" "${EXTRA_ECONF[@]}" }
${MAKE:-make} ${MAKEOPTS} "$@" ${EXTRA_EMAKE}

-- 

  Sergei



Re: [gentoo-dev] [PATCH v3] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.

2019-12-06 Thread Sergei Trofimovich
On Fri, 06 Dec 2019 16:35:53 +0100
Ulrich Müller  wrote:

>   # The user wants us to leave things be.
> - if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
> + if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]] ; then
>   return 0
>   fi

The rest of patch looks ok but I find I_KNOW_WHAT_I_AM_DOING
proliferation worrying. Having enough eclasses guard things on it I don't
really know what I am doing :)

For example developer profile sets it on by default and disables perl error
checks. I don't think it's intentional.

I suggest giving this variable a unique specific name. And phase out
${I_KNOW_WHAT_I_AM_DOING} uses from tree completely.

-- 

  Sergei



Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-06 Thread Sergei Trofimovich
On Fri,  6 Dec 2019 12:09:31 -0800
Georgy Yakovlev  wrote:

> Default output just prints crate name.
> With -vv we can see all cargo options and rustc args.
> 
> Signed-off-by: Georgy Yakovlev 
> ---

Looks good!

I had to do an equivalent locally at least a few times.

While at it I also suggest adding equivalent of
econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
to allow users to inject arbitrary stuff. For example
to sneak in '-Z' options globally.

Say, ${CARGO_BUILD_EXTRA},  ${CARGO_INSTALL_EXTRA},
${CARGO_TEST_EXTRA}.

>  eclass/cargo.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index 5b6d1f050f1..13dd5c355fb 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -146,7 +146,7 @@ cargo_src_compile() {
>  
>   export CARGO_HOME="${ECARGO_HOME}"
>  
> - cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> + cargo build -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
>   || die "cargo build failed"
>  }
>  
> @@ -156,7 +156,7 @@ cargo_src_compile() {
>  cargo_src_install() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo install -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
> --debug "") "$@" \
> + cargo install -vv -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
> --debug "") "$@" \
>   || die "cargo install failed"
>   rm -f "${ED}/usr/.crates.toml"
>  
> @@ -169,7 +169,7 @@ cargo_src_install() {
>  cargo_src_test() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
> + cargo test -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
>   || die "cargo test failed"
>  }
>  
> -- 
> 2.23.0
> 
> 


-- 

  Sergei



[gentoo-portage-dev] [PATCH] emerge: drop FEATURES=distcc-pump support, bug #702146

2019-12-06 Thread Sergei Trofimovich
'distcc' dustributes code generation for preprocessed files.

'pump' distributes preprocessing and code generation of files
and imposes very strict requirement:

"""
Note that distcc's pump-mode assumes that sources files will
not be modified during the lifetime of the include server, so
modifying source files during a build may cause inconsistent
results.
"""

`src_configure()` (where we used to start include server before
this change) almost always violates that requirement.

It is not uncommon to generate more intermediate source files
as a package builds (`bison`, `flex`, child `./configure` calls
from `make`) and thus quite unsafe to use `pump`.

This change drops `FEATURES=distcc-pump` and leaves only
FEATURES=distcc. This way all the proprocessing happens as expected
and only code generation is offloaded.

Closes: https://bugs.gentoo.org/702146
Signed-off-by: Sergei Trofimovich 
---
 bin/phase-functions.sh | 17 -
 lib/_emerge/EbuildPhase.py |  2 +-
 lib/portage/const.py   |  1 -
 3 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 92fcd3929..73f8cee9b 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -403,19 +403,6 @@ __dyn_prepare() {
trap - SIGINT SIGQUIT
 }
 
-# @FUNCTION: __start_distcc
-# @DESCRIPTION:
-# Start distcc-pump if necessary.
-__start_distcc() {
-   if has distcc $FEATURES && has distcc-pump $FEATURES ; then
-   if [[ -z $INCLUDE_SERVER_PORT ]] || [[ ! -w 
$INCLUDE_SERVER_PORT ]] ; then
-   # adding distcc to PATH repeatedly results in fatal 
distcc recursion :)
-   eval $(pump --startup | grep -v PATH)
-   trap "pump --shutdown >/dev/null" EXIT
-   fi
-   fi
-}
-
 __dyn_configure() {
 
if [[ -e $PORTAGE_BUILDDIR/.configured ]] ; then
@@ -435,7 +422,6 @@ __dyn_configure() {
fi
 
trap __abort_configure SIGINT SIGQUIT
-   __start_distcc
 
__ebuild_phase pre_src_configure
 
@@ -469,7 +455,6 @@ __dyn_compile() {
fi
 
trap __abort_compile SIGINT SIGQUIT
-   __start_distcc
 
__ebuild_phase pre_src_compile
 
@@ -493,7 +478,6 @@ __dyn_test() {
fi
 
trap "__abort_test" SIGINT SIGQUIT
-   __start_distcc
 
if [[ -d ${S} ]]; then
cd "${S}"
@@ -541,7 +525,6 @@ __dyn_install() {
return 0
fi
trap "__abort_install" SIGINT SIGQUIT
-   __start_distcc
 
# Handle setting QA_* based on QA_PREBUILT
# Those variables shouldn't be needed before src_install()
diff --git a/lib/_emerge/EbuildPhase.py b/lib/_emerge/EbuildPhase.py
index 4104cefa7..50e3dd1f4 100644
--- a/lib/_emerge/EbuildPhase.py
+++ b/lib/_emerge/EbuildPhase.py
@@ -49,7 +49,7 @@ class EbuildPhase(CompositeTask):
 
# FEATURES displayed prior to setup phase
_features_display = (
-   "ccache", "compressdebug", "distcc", "distcc-pump", "fakeroot",
+   "ccache", "compressdebug", "distcc", "fakeroot",
"installsources", "keeptemp", "keepwork", "network-sandbox",
"network-sandbox-proxy", "nostrip", "preserve-libs", "sandbox",
"selinux", "sesandbox", "splitdebug", "suidctl", "test",
diff --git a/lib/portage/const.py b/lib/portage/const.py
index 36b33af92..e95039fd5 100644
--- a/lib/portage/const.py
+++ b/lib/portage/const.py
@@ -142,7 +142,6 @@ SUPPORTED_FEATURES   = frozenset([
"config-protect-if-modified",
"digest",
"distcc",
-   "distcc-pump",
"distlocks",
"downgrade-backup",
"ebuild-locks",
-- 
2.24.0




[gentoo-dev] Last rites: sys-apps/nix and sys-apps/guix

2019-11-25 Thread Sergei Trofimovich
# Sergei Trofimovich  (2019-11-25)
# Mask for removal from main tree into ::nix-guix overlay.
# Removal in 30 days.
sys-apps/nix
sys-apps/guix

-- 

  Sergei



Re: [gentoo-dev] [PATCH 0/6] nix and guix GID/UID assignments

2019-11-25 Thread Sergei Trofimovich
On Mon, 25 Nov 2019 21:32:18 +0100
Michał Górny  wrote:

> On Mon, 2019-11-25 at 20:28 +0000, Sergei Trofimovich wrote:
> > On Mon, 25 Nov 2019 17:24:08 +0100
> > David Seifert  wrote:
> >   
> > > On Sun, 2019-11-24 at 20:35 +, Sergei Trofimovich wrote:  
> > > > On Sun, 24 Nov 2019 17:19:36 +0100
> > > > Ulrich Mueller  wrote:
> > > > 
> > > > > > > > > > On Sun, 24 Nov 2019, Sergei Trofimovich wrote:  
> > > > > > I interpreted 'reserved' as 'free to use' on
> > > > > > 
> > > > > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
> > > > > > Can you tweak it to someting other than 'reserved' so it would be
> > > > > > clear?  
> > > > > 
> > > > > That's what the "Notes" column was intended for.
> > > > > 
> > > > > > I'll use 60001 .. 60999 / 61001 .. 61999. Is it free though?
> > > > > > '60001..65533' claims to also be 'reserved' as well.  
> > > > > 
> > > > > Debian is also using the range above 6 for allocations that
> > > > > won't
> > > > > fit into the low range. Theoretically, there is some overlap with
> > > > > systemd dynamic users (61184..65519), but IIUC assigning other UIDs
> > > > > in
> > > > > that range isn't a problem, as long as there are enough free IDs
> > > > > left.
> > > > > 
> > > > > Another question, the above are about 2000 users and 2000 groups.
> > > > > Does that imply that we will eventually end up with 4000 packages
> > > > > in acct-{user,group}?
> > > > 
> > > > Should be 2000 users, 2 groups. Worst case it's 2002 packages, yes.
> > > > 
> > > 
> > > For a package manager that likely only 3 Gentoo users in the world use?  
> > 
> > I'll avoid debating you scientific method of deriving that number.
> > What is your threshold? 10 users? 1000 users? 10 users?  
> 
> Could you provide some numbers on performance impact of having that many
> users?  In particular on systems using plain text passwd database.
> 
> >   
> > > I don't consider that particularly helpful, and am very much inclined
> > > to oppose that.  
> > 
> > I'm fine with current use of user.eclass if QA grants nix and guix an
> > exception to use user.eclass indefinitely instead of GLEP-81 layout.  
> 
> I would rather be inclined to give nix and guix a special privilege of
> being moved to an overlay.  It seems so far that they are unjustly
> trying to assume growing number of privileges they have no claim for,
> and trying to run their own non-Gentoo shop inside Gentoo for no good
> reason.

As always great choice of words. So be it.

-- 

  Sergei



Re: [gentoo-dev] [PATCH 0/6] nix and guix GID/UID assignments

2019-11-25 Thread Sergei Trofimovich
On Mon, 25 Nov 2019 17:24:08 +0100
David Seifert  wrote:

> On Sun, 2019-11-24 at 20:35 +0000, Sergei Trofimovich wrote:
> > On Sun, 24 Nov 2019 17:19:36 +0100
> > Ulrich Mueller  wrote:
> >   
> > > > > > > > On Sun, 24 Nov 2019, Sergei Trofimovich wrote:
> > > > I interpreted 'reserved' as 'free to use' on
> > > > 
> > > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
> > > > Can you tweak it to someting other than 'reserved' so it would be
> > > > clear?
> > > 
> > > That's what the "Notes" column was intended for.
> > >   
> > > > I'll use 60001 .. 60999 / 61001 .. 61999. Is it free though?
> > > > '60001..65533' claims to also be 'reserved' as well.
> > > 
> > > Debian is also using the range above 6 for allocations that
> > > won't
> > > fit into the low range. Theoretically, there is some overlap with
> > > systemd dynamic users (61184..65519), but IIUC assigning other UIDs
> > > in
> > > that range isn't a problem, as long as there are enough free IDs
> > > left.
> > > 
> > > Another question, the above are about 2000 users and 2000 groups.
> > > Does that imply that we will eventually end up with 4000 packages
> > > in acct-{user,group}?  
> > 
> > Should be 2000 users, 2 groups. Worst case it's 2002 packages, yes.
> >   
> 
> For a package manager that likely only 3 Gentoo users in the world use?

I'll avoid debating you scientific method of deriving that number.
What is your threshold? 10 users? 1000 users? 10 users?

> I don't consider that particularly helpful, and am very much inclined
> to oppose that.

I'm fine with current use of user.eclass if QA grants nix and guix an
exception to use user.eclass indefinitely instead of GLEP-81 layout.

-- 

  Sergei



Re: [gentoo-dev] [PATCH 0/6] nix and guix GID/UID assignments

2019-11-24 Thread Sergei Trofimovich
On Sun, 24 Nov 2019 17:19:36 +0100
Ulrich Mueller  wrote:

> >>>>> On Sun, 24 Nov 2019, Sergei Trofimovich wrote:  
> 
> > I interpreted 'reserved' as 'free to use' on
> > 
> > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
> > Can you tweak it to someting other than 'reserved' so it would be clear?  
> 
> That's what the "Notes" column was intended for.
> 
> > I'll use 60001 .. 60999 / 61001 .. 61999. Is it free though?
> > '60001..65533' claims to also be 'reserved' as well.  
> 
> Debian is also using the range above 6 for allocations that won't
> fit into the low range. Theoretically, there is some overlap with
> systemd dynamic users (61184..65519), but IIUC assigning other UIDs in
> that range isn't a problem, as long as there are enough free IDs left.
> 
> Another question, the above are about 2000 users and 2000 groups.
> Does that imply that we will eventually end up with 4000 packages
> in acct-{user,group}?

Should be 2000 users, 2 groups. Worst case it's 2002 packages, yes.

-- 

  Sergei


pgpbk6oI4z8AQ.pgp
Description: Цифровая подпись OpenPGP


Re: [gentoo-dev] [PATCH 0/6] nix and guix GID/UID assignments

2019-11-24 Thread Sergei Trofimovich
On Sun, 24 Nov 2019 13:57:24 +0100
Ulrich Mueller  wrote:

> >>>>> On Sun, 24 Nov 2019, Sergei Trofimovich wrote:  
> 
> > I've effectively reserved space for 1000 users for each of them:
> > - 3..30999
> > - 31000..31000
> > and using only 10 of each.  
> 
> That's inside the UID_MIN..UID_MAX range which should be reserved for
> assignment on users' systems. Can't you move them into the range
> between 60001 and 65532?

I interpreted 'reserved' as 'free to use' on
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
Can you tweak it to someting other than 'reserved' so it would be clear?

I'll use 60001 .. 60999 / 61001 .. 61999. Is it free though?
'60001..65533' claims to also be 'reserved' as well.

-- 

  Sergei


pgpok9JrMh1U2.pgp
Description: Цифровая подпись OpenPGP


[gentoo-dev] [PATCH 0/6] nix and guix GID/UID assignments

2019-11-24 Thread Sergei Trofimovich
A bit of background:

  nix and guix are both hermetic builders with precise dependency
  management: all build inputs are explicit and build outputs should
  ideally not change if build inputs don't change.

  Every user in the system can trigger the build via IPC request
  to the builder daemon (nix-daemon or guix-daemon).

  For each IPC request builder daemon pick free user from user pool
  dedicated specifically for building. In case of nix pool group
  is 'nixbld' and users in that pool are 'nixbld1', 'nixbld2', and so
  on. There is no fixed limit on a pool size. Nixos creates 32 users:
  nixbld{1..32}.

  That way different users can't interfere with one anothers' build.

Groups/users have a few properties:
  - final build results are owned by root:root and never by
nixbld{1..10} users
  - nixbld{1..10} own only temporary build directory while IPC
request is handled. Temporary directory is deleted when build
is finished.
  - the more concurrent clients are there the more users should
be in the builder group.

There is a GID collision:
Both nix and guix use GID=3 for their 'nixbld'
and 'guixbuild' groups. As Gentoo allows both to co-exist
one of them has to give. I've moved guix down to 31000.

I've effectively reserved space for 1000 users for each of them:
- 3..30999
- 31000..31000
and using only 10 of each.

Sergei Trofimovich (6):
  acct-group/nixbld: new group (GID 3)
  acct-group/guixbuild: new group (GID 31000)
  acct-user/nixbld{1..10}: new user (UID {30001..30010)
  acct-user/guixbuilder{1..10}: new user (UID {31001..31010)
  sys-apps/nix: switch from user.eclass to acct-*/ depends
  sys-apps/guix: switch from user.eclass to acct-*/ depends

 acct-group/guixbuild/guixbuild-0.ebuild   |  10 ++
 acct-group/guixbuild/metadata.xml |   8 +
 acct-group/nixbld/metadata.xml|   8 +
 acct-group/nixbld/nixbld-0.ebuild |   9 +
 acct-user/guixbuilder1/guixbuilder1-0.ebuild  |  13 ++
 acct-user/guixbuilder1/metadata.xml   |   8 +
 .../guixbuilder10/guixbuilder10-0.ebuild  |  13 ++
 acct-user/guixbuilder10/metadata.xml  |   8 +
 acct-user/guixbuilder2/guixbuilder2-0.ebuild  |  13 ++
 acct-user/guixbuilder2/metadata.xml   |   8 +
 acct-user/guixbuilder3/guixbuilder3-0.ebuild  |  13 ++
 acct-user/guixbuilder3/metadata.xml   |   8 +
 acct-user/guixbuilder4/guixbuilder4-0.ebuild  |  13 ++
 acct-user/guixbuilder4/metadata.xml   |   8 +
 acct-user/guixbuilder5/guixbuilder5-0.ebuild  |  13 ++
 acct-user/guixbuilder5/metadata.xml   |   8 +
 acct-user/guixbuilder6/guixbuilder6-0.ebuild  |  13 ++
 acct-user/guixbuilder6/metadata.xml   |   8 +
 acct-user/guixbuilder7/guixbuilder7-0.ebuild  |  13 ++
 acct-user/guixbuilder7/metadata.xml   |   8 +
 acct-user/guixbuilder8/guixbuilder8-0.ebuild  |  13 ++
 acct-user/guixbuilder8/metadata.xml   |   8 +
 acct-user/guixbuilder9/guixbuilder9-0.ebuild  |  13 ++
 acct-user/guixbuilder9/metadata.xml   |   8 +
 acct-user/nixbld1/metadata.xml|   8 +
 acct-user/nixbld1/nixbld1-0.ebuild|  13 ++
 acct-user/nixbld10/metadata.xml   |   8 +
 acct-user/nixbld10/nixbld10-0.ebuild  |  13 ++
 acct-user/nixbld2/metadata.xml|   8 +
 acct-user/nixbld2/nixbld2-0.ebuild|  13 ++
 acct-user/nixbld3/metadata.xml|   8 +
 acct-user/nixbld3/nixbld3-0.ebuild|  13 ++
 acct-user/nixbld4/metadata.xml|   8 +
 acct-user/nixbld4/nixbld4-0.ebuild|  13 ++
 acct-user/nixbld5/metadata.xml|   8 +
 acct-user/nixbld5/nixbld5-0.ebuild|  13 ++
 acct-user/nixbld6/metadata.xml|   8 +
 acct-user/nixbld6/nixbld6-0.ebuild|  13 ++
 acct-user/nixbld7/metadata.xml|   8 +
 acct-user/nixbld7/nixbld7-0.ebuild|  13 ++
 acct-user/nixbld8/metadata.xml|   8 +
 acct-user/nixbld8/nixbld8-0.ebuild|  13 ++
 acct-user/nixbld9/metadata.xml|   8 +
 acct-user/nixbld9/nixbld9-0.ebuild|  13 ++
 sys-apps/guix/guix-1.0.1-r2.ebuild| 165 ++
 sys-apps/nix/nix-2.3.1-r1.ebuild  | 145 +++
 46 files changed, 765 insertions(+)
 create mode 100644 acct-group/guixbuild/guixbuild-0.ebuild
 create mode 100644 acct-group/guixbuild/metadata.xml
 create mode 100644 acct-group/nixbld/metadata.xml
 create mode 100644 acct-group/nixbld/nixbld-0.ebuild
 create mode 100644 acct-user/guixbuilder1/guixbuilder1-0.ebuild
 create mode 100644 acct-user/guixbuilder1/metadata.xml
 create mode 100644 acct-user/guixbuilder10/guixbuilder10-0.ebuild
 create mode 100644 acct-user/guixbuilder10/metadata.xml
 create mode 100644 acct-user/guixbuilder2/guixbuilder2-0.ebuild
 create mode 100644 acct-user/guixbuilder2/metadata.xml
 create mode 100644 acct-user/guixbuilder3/guixbuilder3-0.ebuild
 create mode

[gentoo-dev] [PATCH 6/6] sys-apps/guix: switch from user.eclass to acct-*/ depends

2019-11-24 Thread Sergei Trofimovich
---
 sys-apps/guix/guix-1.0.1-r2.ebuild | 165 +
 1 file changed, 165 insertions(+)
 create mode 100644 sys-apps/guix/guix-1.0.1-r2.ebuild

diff --git a/sys-apps/guix/guix-1.0.1-r2.ebuild 
b/sys-apps/guix/guix-1.0.1-r2.ebuild
new file mode 100644
index 000..1e8ec136e73
--- /dev/null
+++ b/sys-apps/guix/guix-1.0.1-r2.ebuild
@@ -0,0 +1,165 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools linux-info readme.gentoo-r1 systemd
+
+DESCRIPTION="GNU package manager (nix sibling)"
+HOMEPAGE="https://www.gnu.org/software/guix/;
+
+# taken from gnu/local.mk and gnu/packages/bootstrap.scm
+BOOT_GUILE=(
+   "aarch64-linux  20170217 guile-2.0.14.tar.xz"
+   "armhf-linux20150101 guile-2.0.11.tar.xz"
+   "i686-linux 20131110 guile-2.0.9.tar.xz"
+   "mips64el-linux 20131110 guile-2.0.9.tar.xz"
+   "x86_64-linux   20131110 guile-2.0.9.tar.xz"
+)
+
+binary_src_uris() {
+   local system_date_guilep uri
+   for system_date_guilep in "${BOOT_GUILE[@]}"; do
+   # $1  $2   $3
+   # "armhf-linux20150101 guile-2.0.11.tar.xz"
+   set -- ${system_date_guilep}
+   uri="mirror://gnu-alpha/${PN}/bootstrap/$1/$2/$3"
+   # ${uri} -> 
guix-bootstrap-armhf-linux-20150101-guile-2.0.11.tar.xz.bootstrap
+   echo "${uri} -> guix-bootstrap-$1-$2-$3.bootstrap"
+   done
+}
+
+# copy bootstrap binaries from DISTDIR to ${S}
+copy_boot_guile_binaries() {
+   local system_date_guilep
+   for system_date_guilep in "${BOOT_GUILE[@]}"; do
+   # $1  $2   $3
+   # "armhf-linux20150101 guile-2.0.11.tar.xz"
+   set -- ${system_date_guilep}
+   cp "${DISTDIR}"/guix-bootstrap-$1-$2-$3.bootstrap 
gnu/packages/bootstrap/$1/$3 || die
+   done
+}
+
+SRC_URI="mirror://gnu/${PN}/${P}.tar.gz
+   $(binary_src_uris)"
+
+LICENSE="GPL-3"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE=""
+
+RESTRICT=test # complains about size of config.log and refuses to start tests
+
+RDEPEND="
+   dev-libs/libgcrypt:0=
+   >=dev-scheme/guile-2.2:=[regex,networking,threads]
+   dev-scheme/bytestructures
+   dev-scheme/guile-gcrypt
+   >=dev-scheme/guile-git-0.2.0
+   dev-scheme/guile-json
+   dev-scheme/guile-sqlite3
+   net-libs/gnutls[guile]
+   sys-libs/zlib
+   app-arch/bzip2
+   dev-db/sqlite
+   acct-group/guixbuild
+   acct-user/guixbuilder1
+   acct-user/guixbuilder2
+   acct-user/guixbuilder3
+   acct-user/guixbuilder4
+   acct-user/guixbuilder5
+   acct-user/guixbuilder6
+   acct-user/guixbuilder7
+   acct-user/guixbuilder8
+   acct-user/guixbuilder9
+   acct-user/guixbuilder10
+"
+
+DEPEND="${RDEPEND}
+"
+
+PATCHES=("${FILESDIR}"/${PN}-0.16.0-default-daemon.patch)
+
+QA_PREBUILT="usr/share/guile/site/*/gnu/packages/bootstrap/*"
+
+DISABLE_AUTOFORMATTING=yes
+DOC_CONTENTS="Quick start user guide on Gentoo:
+
+[as root] allow binary substitution to be downloaded (optional)
+   # guix archive --authorize < /usr/share/guix/ci.guix.info.pub
+[as root] enable guix-daemon service:
+   [systemd] # systemctl enable guix-daemon
+   [openrc]  # rc-update add guix-daemon
+[as a user] ln -sf /var/guix/profiles/per-user/\$USER/guix-profile 
\$HOME/.guix-profile
+[as a user] install guix packages:
+   \$ guix package -i hello
+[as a user] configure environment:
+   Somewhere in .bash_profile you might want to set
+   export GUIX_LOCPATH=\$HOME/.guix-profile/lib/locale
+
+Next steps:
+   guix package manager user manual: 
https://www.gnu.org/software/guix/manual/guix.html
+"
+
+pkg_pretend() {
+   # USER_NS is used to run builders in a default setting in linux
+   # and for 'guix environment --container'.
+   local CONFIG_CHECK="~USER_NS"
+   check_extra_config
+}
+
+src_prepare() {
+   copy_boot_guile_binaries
+
+   default
+   # build system is very eager to run automake itself: bug #625166
+   eautoreconf
+
+   # guile is trying to avoid recompilation by checking if file
+   # /usr/lib64/guile/2.2/site-ccache/guix/modules.go
+   # is newer than
+   # guix/modules.scm
+   # In case it is instead of using 'guix/modules.scm' guile
+   # loads system one (from potentially older version of guix).
+   # To work it around we bump last modification timestamp of
+   # '*.scm' files.
+   # http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38112
+   find "${S}" -name "*.scm" -exec touch {} + || die
+
+   # Gentoo stores systemd unit files in lib, never in lib64: bug #689772
+   sed -i nix/local.mk \
+   -e 's|systemdservicedir = 
$(libdir)/systemd/system|systemdservicedir = '"$(systemd_get_systemunitdir)"'|' 
|| die
+}
+
+src_configure() {
+   # to be 

[gentoo-dev] [PATCH 5/6] sys-apps/nix: switch from user.eclass to acct-*/ depends

2019-11-24 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 sys-apps/nix/nix-2.3.1-r1.ebuild | 145 +++
 1 file changed, 145 insertions(+)
 create mode 100644 sys-apps/nix/nix-2.3.1-r1.ebuild

diff --git a/sys-apps/nix/nix-2.3.1-r1.ebuild b/sys-apps/nix/nix-2.3.1-r1.ebuild
new file mode 100644
index 000..ef50b7bb65d
--- /dev/null
+++ b/sys-apps/nix/nix-2.3.1-r1.ebuild
@@ -0,0 +1,145 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools flag-o-matic linux-info readme.gentoo-r1
+
+DESCRIPTION="A purely functional package manager"
+HOMEPAGE="https://nixos.org/nix;
+
+SRC_URI="http://nixos.org/releases/${PN}/${P}/${P}.tar.xz;
+LICENSE="LGPL-2.1"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="+etc-profile +gc doc s3 +sodium"
+
+# sys-apps/busybox is needed for sandbox mount of /bin/sh
+RDEPEND="
+   app-arch/brotli
+   app-arch/bzip2
+   app-arch/xz-utils
+   sys-apps/busybox[static]
+   dev-db/sqlite
+   dev-libs/editline:0=
+   dev-libs/openssl:0=
+   >=dev-libs/boost-1.66:0=[context]
+   net-misc/curl
+   sys-libs/libseccomp
+   sys-libs/zlib
+   gc? ( dev-libs/boehm-gc[cxx] )
+   doc? ( dev-libs/libxml2
+   dev-libs/libxslt
+   app-text/docbook-xsl-stylesheets
+   )
+   s3? ( dev-libs/aws-sdk-cpp )
+   sodium? ( dev-libs/libsodium:0= )
+   acct-group/nixbld
+   acct-user/nixbld1
+   acct-user/nixbld2
+   acct-user/nixbld3
+   acct-user/nixbld4
+   acct-user/nixbld5
+   acct-user/nixbld6
+   acct-user/nixbld7
+   acct-user/nixbld8
+   acct-user/nixbld9
+   acct-user/nixbld10
+"
+DEPEND="${RDEPEND}
+   >=sys-devel/bison-2.6
+   >=sys-devel/flex-2.5.35
+"
+
+PATCHES=(
+   "${FILESDIR}"/${PN}-2.3-libpaths.patch
+   "${FILESDIR}"/${PN}-2.3-bootstrap.patch
+)
+
+DISABLE_AUTOFORMATTING=yes
+DOC_CONTENTS=" Quick start user guide on Gentoo:
+
+[as root] enable nix-daemon service:
+   [systemd] # systemctl enable nix-daemon
+   [openrc]  # rc-update add nix-daemon
+[as a user] relogin to get environment and profile update
+[as a user] fetch nixpkgs update:
+   \$ nix-channel --update
+[as a user] install nix packages:
+   \$ nix-env -i mc
+[as a user] configure environment:
+   Somewhere in .bash_profile you might want to set
+   LOCALE_ARCHIVE=\$HOME/.nix-profile/lib/locale/locale-archive
+   but please read https://github.com/NixOS/nixpkgs/issues/21820
+
+Next steps:
+   nix package manager user manual: http://nixos.org/nix/manual/
+"
+
+pkg_pretend() {
+   # USER_NS is used to run builders in a default setting in linux:
+   # https://nixos.wiki/wiki/Nix#Sandboxing
+   local CONFIG_CHECK="~USER_NS"
+   check_extra_config
+}
+
+src_prepare() {
+   default
+
+   eautoreconf
+}
+
+src_configure() {
+   if ! use s3; then
+   # Disable automagic depend: bug #670256
+   export ac_cv_header_aws_s3_S3Client_h=no
+   fi
+   econf \
+   --localstatedir="${EPREFIX}"/nix/var \
+   $(use_enable gc) \
+   --with-sandbox-shell=/bin/busybox
+}
+
+src_compile() {
+   emake V=1
+}
+
+src_install() {
+   # TODO: emacs highlighter
+   default
+
+   readme.gentoo_create_doc
+
+   # here we use an eager variant of something that
+   # is lazily done by nix-daemon and root nix-env
+
+   # TODO: will need a tweak for prefix
+   keepdir /nix/store
+   fowners root:nixbld /nix/store
+   fperms 1775 /nix/store
+
+   keepdir /nix/var/nix/channel-cache
+   fperms 0777 /nix/var/nix/channel-cache
+
+   keepdir /nix/var/nix/profiles/per-user
+   fperms 1777 /nix/var/nix/profiles/per-user
+
+   # setup directories nix-daemon: /etc/profile.d/nix-daemon.sh
+   keepdir /nix/var/nix/gcroots/per-user
+   fperms 1777 /nix/var/nix/gcroots/per-user
+
+   newinitd "${FILESDIR}"/nix-daemon.initd nix-daemon
+
+   if ! use etc-profile; then
+   rm "${ED}"/etc/profile.d/nix.sh || die
+   rm "${ED}"/etc/profile.d/nix-daemon.sh || die
+   fi
+}
+
+pkg_postinst() {
+   if ! use etc-profile; then
+   ewarn "${EROOT}/etc/profile.d/nix.sh was removed (due to 
USE=-etc-profile)."
+   fi
+
+   readme.gentoo_print_elog
+}
-- 
2.24.0




[gentoo-dev] [PATCH 4/6] acct-user/guixbuilder{1..10}: new user (UID {31001..31010)

2019-11-24 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 acct-user/guixbuilder1/guixbuilder1-0.ebuild   | 13 +
 acct-user/guixbuilder1/metadata.xml|  8 
 acct-user/guixbuilder10/guixbuilder10-0.ebuild | 13 +
 acct-user/guixbuilder10/metadata.xml   |  8 
 acct-user/guixbuilder2/guixbuilder2-0.ebuild   | 13 +
 acct-user/guixbuilder2/metadata.xml|  8 
 acct-user/guixbuilder3/guixbuilder3-0.ebuild   | 13 +
 acct-user/guixbuilder3/metadata.xml|  8 
 acct-user/guixbuilder4/guixbuilder4-0.ebuild   | 13 +
 acct-user/guixbuilder4/metadata.xml|  8 
 acct-user/guixbuilder5/guixbuilder5-0.ebuild   | 13 +
 acct-user/guixbuilder5/metadata.xml|  8 
 acct-user/guixbuilder6/guixbuilder6-0.ebuild   | 13 +
 acct-user/guixbuilder6/metadata.xml|  8 
 acct-user/guixbuilder7/guixbuilder7-0.ebuild   | 13 +
 acct-user/guixbuilder7/metadata.xml|  8 
 acct-user/guixbuilder8/guixbuilder8-0.ebuild   | 13 +
 acct-user/guixbuilder8/metadata.xml|  8 
 acct-user/guixbuilder9/guixbuilder9-0.ebuild   | 13 +
 acct-user/guixbuilder9/metadata.xml|  8 
 20 files changed, 210 insertions(+)
 create mode 100644 acct-user/guixbuilder1/guixbuilder1-0.ebuild
 create mode 100644 acct-user/guixbuilder1/metadata.xml
 create mode 100644 acct-user/guixbuilder10/guixbuilder10-0.ebuild
 create mode 100644 acct-user/guixbuilder10/metadata.xml
 create mode 100644 acct-user/guixbuilder2/guixbuilder2-0.ebuild
 create mode 100644 acct-user/guixbuilder2/metadata.xml
 create mode 100644 acct-user/guixbuilder3/guixbuilder3-0.ebuild
 create mode 100644 acct-user/guixbuilder3/metadata.xml
 create mode 100644 acct-user/guixbuilder4/guixbuilder4-0.ebuild
 create mode 100644 acct-user/guixbuilder4/metadata.xml
 create mode 100644 acct-user/guixbuilder5/guixbuilder5-0.ebuild
 create mode 100644 acct-user/guixbuilder5/metadata.xml
 create mode 100644 acct-user/guixbuilder6/guixbuilder6-0.ebuild
 create mode 100644 acct-user/guixbuilder6/metadata.xml
 create mode 100644 acct-user/guixbuilder7/guixbuilder7-0.ebuild
 create mode 100644 acct-user/guixbuilder7/metadata.xml
 create mode 100644 acct-user/guixbuilder8/guixbuilder8-0.ebuild
 create mode 100644 acct-user/guixbuilder8/metadata.xml
 create mode 100644 acct-user/guixbuilder9/guixbuilder9-0.ebuild
 create mode 100644 acct-user/guixbuilder9/metadata.xml

diff --git a/acct-user/guixbuilder1/guixbuilder1-0.ebuild 
b/acct-user/guixbuilder1/guixbuilder1-0.ebuild
new file mode 100644
index 000..df9bbd069bf
--- /dev/null
+++ b/acct-user/guixbuilder1/guixbuilder1-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for guix-daemon from sys-apps/guix"
+
+ACCT_USER_ID=31001
+ACCT_USER_GROUPS=( guixbuild kvm )
+
+acct-user_add_deps
diff --git a/acct-user/guixbuilder1/metadata.xml 
b/acct-user/guixbuilder1/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/guixbuilder1/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+       Sergei Trofimovich
+   
+
diff --git a/acct-user/guixbuilder10/guixbuilder10-0.ebuild 
b/acct-user/guixbuilder10/guixbuilder10-0.ebuild
new file mode 100644
index 000..1672599d585
--- /dev/null
+++ b/acct-user/guixbuilder10/guixbuilder10-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for guix-daemon from sys-apps/guix"
+
+ACCT_USER_ID=31010
+ACCT_USER_GROUPS=( guixbuild kvm )
+
+acct-user_add_deps
diff --git a/acct-user/guixbuilder10/metadata.xml 
b/acct-user/guixbuilder10/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/guixbuilder10/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+   Sergei Trofimovich
+   
+
diff --git a/acct-user/guixbuilder2/guixbuilder2-0.ebuild 
b/acct-user/guixbuilder2/guixbuilder2-0.ebuild
new file mode 100644
index 000..536ba624666
--- /dev/null
+++ b/acct-user/guixbuilder2/guixbuilder2-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for guix-daemon from sys-apps/guix"
+
+ACCT_USER_ID=31002
+ACCT_USER_GROUPS=( guixbuild kvm )
+
+acct-user_add_deps
diff --git a/acct-user/guixbuilder2/metadata.xml 
b/acct-user/guixbuilder2/metadata.xml
new file mode 100644
ind

[gentoo-dev] [PATCH 2/6] acct-group/guixbuild: new group (GID 31000)

2019-11-24 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 acct-group/guixbuild/guixbuild-0.ebuild | 10 ++
 acct-group/guixbuild/metadata.xml   |  8 
 2 files changed, 18 insertions(+)
 create mode 100644 acct-group/guixbuild/guixbuild-0.ebuild
 create mode 100644 acct-group/guixbuild/metadata.xml

diff --git a/acct-group/guixbuild/guixbuild-0.ebuild 
b/acct-group/guixbuild/guixbuild-0.ebuild
new file mode 100644
index 000..acb84f9fb3b
--- /dev/null
+++ b/acct-group/guixbuild/guixbuild-0.ebuild
@@ -0,0 +1,10 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Builder group for guix-daemon from sys-apps/guix"
+# Upstream uses 3, but it clashes with acct-group/nixbld
+ACCT_GROUP_ID=31000
diff --git a/acct-group/guixbuild/metadata.xml 
b/acct-group/guixbuild/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-group/guixbuild/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+       Sergei Trofimovich
+   
+
-- 
2.24.0




[gentoo-dev] [PATCH 1/6] acct-group/nixbld: new group (GID 30000)

2019-11-24 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 acct-group/nixbld/metadata.xml| 8 
 acct-group/nixbld/nixbld-0.ebuild | 9 +
 2 files changed, 17 insertions(+)
 create mode 100644 acct-group/nixbld/metadata.xml
 create mode 100644 acct-group/nixbld/nixbld-0.ebuild

diff --git a/acct-group/nixbld/metadata.xml b/acct-group/nixbld/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-group/nixbld/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+   Sergei Trofimovich
+   
+
diff --git a/acct-group/nixbld/nixbld-0.ebuild 
b/acct-group/nixbld/nixbld-0.ebuild
new file mode 100644
index 000..194e744609b
--- /dev/null
+++ b/acct-group/nixbld/nixbld-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Builder group for nix-daemon from sys-apps/nix"
+ACCT_GROUP_ID=3
-- 
2.24.0




[gentoo-dev] [PATCH 3/6] acct-user/nixbld{1..10}: new user (UID {30001..30010)

2019-11-24 Thread Sergei Trofimovich
Signed-off-by: Sergei Trofimovich 
---
 acct-user/nixbld1/metadata.xml   |  8 
 acct-user/nixbld1/nixbld1-0.ebuild   | 13 +
 acct-user/nixbld10/metadata.xml  |  8 
 acct-user/nixbld10/nixbld10-0.ebuild | 13 +
 acct-user/nixbld2/metadata.xml   |  8 
 acct-user/nixbld2/nixbld2-0.ebuild   | 13 +
 acct-user/nixbld3/metadata.xml   |  8 
 acct-user/nixbld3/nixbld3-0.ebuild   | 13 +
 acct-user/nixbld4/metadata.xml   |  8 
 acct-user/nixbld4/nixbld4-0.ebuild   | 13 +
 acct-user/nixbld5/metadata.xml   |  8 
 acct-user/nixbld5/nixbld5-0.ebuild   | 13 +
 acct-user/nixbld6/metadata.xml   |  8 
 acct-user/nixbld6/nixbld6-0.ebuild   | 13 +
 acct-user/nixbld7/metadata.xml   |  8 
 acct-user/nixbld7/nixbld7-0.ebuild   | 13 +
 acct-user/nixbld8/metadata.xml   |  8 
 acct-user/nixbld8/nixbld8-0.ebuild   | 13 +
 acct-user/nixbld9/metadata.xml   |  8 
 acct-user/nixbld9/nixbld9-0.ebuild   | 13 +
 20 files changed, 210 insertions(+)
 create mode 100644 acct-user/nixbld1/metadata.xml
 create mode 100644 acct-user/nixbld1/nixbld1-0.ebuild
 create mode 100644 acct-user/nixbld10/metadata.xml
 create mode 100644 acct-user/nixbld10/nixbld10-0.ebuild
 create mode 100644 acct-user/nixbld2/metadata.xml
 create mode 100644 acct-user/nixbld2/nixbld2-0.ebuild
 create mode 100644 acct-user/nixbld3/metadata.xml
 create mode 100644 acct-user/nixbld3/nixbld3-0.ebuild
 create mode 100644 acct-user/nixbld4/metadata.xml
 create mode 100644 acct-user/nixbld4/nixbld4-0.ebuild
 create mode 100644 acct-user/nixbld5/metadata.xml
 create mode 100644 acct-user/nixbld5/nixbld5-0.ebuild
 create mode 100644 acct-user/nixbld6/metadata.xml
 create mode 100644 acct-user/nixbld6/nixbld6-0.ebuild
 create mode 100644 acct-user/nixbld7/metadata.xml
 create mode 100644 acct-user/nixbld7/nixbld7-0.ebuild
 create mode 100644 acct-user/nixbld8/metadata.xml
 create mode 100644 acct-user/nixbld8/nixbld8-0.ebuild
 create mode 100644 acct-user/nixbld9/metadata.xml
 create mode 100644 acct-user/nixbld9/nixbld9-0.ebuild

diff --git a/acct-user/nixbld1/metadata.xml b/acct-user/nixbld1/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/nixbld1/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+   Sergei Trofimovich
+   
+
diff --git a/acct-user/nixbld1/nixbld1-0.ebuild 
b/acct-user/nixbld1/nixbld1-0.ebuild
new file mode 100644
index 000..dd40f385eef
--- /dev/null
+++ b/acct-user/nixbld1/nixbld1-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for nix-daemon from sys-apps/nix"
+
+ACCT_USER_ID=30001
+ACCT_USER_GROUPS=( nixbld )
+
+acct-user_add_deps
diff --git a/acct-user/nixbld10/metadata.xml b/acct-user/nixbld10/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/nixbld10/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+   Sergei Trofimovich
+   
+
diff --git a/acct-user/nixbld10/nixbld10-0.ebuild 
b/acct-user/nixbld10/nixbld10-0.ebuild
new file mode 100644
index 000..3bff5c20898
--- /dev/null
+++ b/acct-user/nixbld10/nixbld10-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for nix-daemon from sys-apps/nix"
+
+ACCT_USER_ID=30010
+ACCT_USER_GROUPS=( nixbld )
+
+acct-user_add_deps
diff --git a/acct-user/nixbld2/metadata.xml b/acct-user/nixbld2/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/nixbld2/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   sly...@gentoo.org
+   Sergei Trofimovich
+   
+
diff --git a/acct-user/nixbld2/nixbld2-0.ebuild 
b/acct-user/nixbld2/nixbld2-0.ebuild
new file mode 100644
index 000..2d379cab41d
--- /dev/null
+++ b/acct-user/nixbld2/nixbld2-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Builder user for nix-daemon from sys-apps/nix"
+
+ACCT_USER_ID=30002
+ACCT_USER_GROUPS=( nixbld )
+
+acct-user_add_deps
diff --git a/acct-user/nixbld3/metadata.xml b/acct-user/nixbld3/metadata.xml
new file mode 100644
index 000..c5298995d2d
--- /dev/null
+++ b/acct-user/nixbld3/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+     

Re: [gentoo-dev] toolchain.eclass more friendly about ada/gnat

2019-11-23 Thread Sergei Trofimovich
On Sat, 23 Nov 2019 09:16:42 +0100
Alfredo Tupone  wrote:

> I would like to have comments about the followinf changes.
> I "fear" the shopts nullglob a little
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index a3081c38bac1..aca10b4f37ed 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1817,33 +1817,37 @@ toolchain_src_install() {
>   fi
>  
>   dodir /etc/env.d/gcc
>   create_gcc_env_entry
>   create_revdep_rebuild_entry
>  
>   # Setup the gcc_env_entry for hardened gcc 4 with minispecs
>   want_minispecs && copy_minispecs_gcc_specs
>  
>   # Make sure we dont have stuff lying around that
>   # can nuke multiple versions of gcc
>   gcc_slot_java
>  
>   dodir /usr/bin
>   cd "${D}"${BINPATH}
> +
> + shopt nullglob
> + local gnat_extra_bins="gnat*"
> +
>   # Ugh: we really need to auto-detect this list.
>   #  It's constantly out of date.
> - for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
> + for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo 
> ${gnat_extra_bins} ; do

You can also drop 'shopt nullglob'/'local gnat_extra_bins="gnat*"' and use 
'gnat*' directly:
for x in ... gnat* ; do
All the code below if guarded by [[ -f ${x} ]] anyway.

>   # For some reason, g77 gets made instead of ${CTARGET}-g77...
>   # this should take care of that
>   if [[ -f ${x} ]] ; then
>   # In case they're hardlinks, clear out the target first
>   # otherwise the mv below will complain.
>   rm -f ${CTARGET}-${x}
>   mv ${x} ${CTARGET}-${x}
>   fi
>  
>   if [[ -f ${CTARGET}-${x} ]] ; then
>   if ! is_crosscompile ; then
>   ln -sf ${CTARGET}-${x} ${x}
>   dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
>   /usr/bin/${x}-${GCC_CONFIG_VER}
>   fi
> 

-- 

  Sergei



Re: [gentoo-portage-dev] [PATCH] repoman: add --include-profiles=PROFILES

2019-11-18 Thread Sergei Trofimovich
On Mon, 18 Nov 2019 16:45:58 -0800
Zac Medico  wrote:

> On 11/18/19 4:21 PM, Sergei Trofimovich wrote:
> > repoman slows down ~linearly with amount of profiles being scanned.
> > In case of amd64 we have 28 stable profiles.
> > 
> > To speed up processing and fit into time budged of various CIs we can
> > split the work across different processes that handle different profiles.
> > 
> > Example benchmark on ::haskell overlay:
> > $ ./repoman full --include-arches=amd64
> > ~65 minutes
> > $ ./repoman full --include-profiles=default/linux/amd64/17.0
> > ~4 minutes
> > This allows for a crude sharding of work across processes and allows for
> > cheap tree-wide scans for early failures.
> > 
> > Bug: https://bugs.gentoo.org/700456
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  repoman/lib/repoman/actions.py  | 4 
> >  repoman/lib/repoman/argparser.py| 7 +++
> >  repoman/lib/repoman/modules/scan/depend/__init__.py | 3 ++-
> >  repoman/lib/repoman/modules/scan/depend/profile.py  | 9 +++--
> >  repoman/lib/repoman/scanner.py  | 5 +
> >  repoman/man/repoman.1   | 4 
> >  6 files changed, 29 insertions(+), 3 deletions(-)
> > 
> > diff --git a/repoman/lib/repoman/actions.py b/repoman/lib/repoman/actions.py
> > index 1c9989a72..92d4d4e94 100644
> > --- a/repoman/lib/repoman/actions.py
> > +++ b/repoman/lib/repoman/actions.py
> > @@ -412,6 +412,10 @@ the whole commit message to abort.
> > report_options.append(
> > "--include-arches=\"%s\"" %
> > " ".join(sorted(self.scanner.include_arches)))
> > +   if self.scanner.include_profiles is not None:
> > +   report_options.append(
> > +   "--include-profiles=\"%s\"" %
> > +   " ".join(sorted(self.scanner.include_profiles)))
> >  
> > if portage_version is None:
> > sys.stderr.write("Failed to insert portage version in 
> > message!\n")
> > diff --git a/repoman/lib/repoman/argparser.py 
> > b/repoman/lib/repoman/argparser.py
> > index fa0e6ff90..670a0e91d 100644
> > --- a/repoman/lib/repoman/argparser.py
> > +++ b/repoman/lib/repoman/argparser.py
> > @@ -164,6 +164,13 @@ def parse_args(argv, repoman_default_opts):
> > 'A space separated list of arches used to '
> > 'filter the selection of profiles for dependency 
> > checks'))
> >  
> > +   parser.add_argument(
> > +   '--include-profiles',
> > +   dest='include_profiles', metavar='PROFILES', action='append',
> > +   help=(
> > +   'A space separated list of profiles used to '
> > +   'define the selection of profiles for dependency 
> > checks'))
> > +
> > parser.add_argument(
> > '-d', '--include-dev', dest='include_dev', action='store_true',
> > default=False,
> > diff --git a/repoman/lib/repoman/modules/scan/depend/__init__.py 
> > b/repoman/lib/repoman/modules/scan/depend/__init__.py
> > index c3cc0ddeb..9068760bb 100644
> > --- a/repoman/lib/repoman/modules/scan/depend/__init__.py
> > +++ b/repoman/lib/repoman/modules/scan/depend/__init__.py
> > @@ -19,7 +19,8 @@ module_spec = {
> > 'func_desc': {
> > },
> > 'mod_kwargs': ['qatracker', 'portdb', 'profiles', 
> > 'options',
> > -   'repo_metadata', 'repo_settings', 
> > 'include_arches', 'caches',
> > +   'repo_metadata', 'repo_settings', 
> > 'include_arches',
> > +   'include_profiles', 'caches',
> > 'repoman_incrementals', 'env', 'have', 
> > 'dev_keywords'
> > ],
> > 'func_kwargs': {
> > diff --git a/repoman/lib/repoman/modules/scan/depend/profile.py 
> > b/repoman/lib/repoman/modules/scan/depend/profile.py
> > index d980f4eca..0b1d74483 100644
> > --- a/repoman/lib/repoman/modules/scan/depend/profile.py
> > +++ b/repoman/lib/repoman/modules/scan/depend/profile.py
> > @@ -33,6 +33,7 @@ class ProfileDependsChecks(ScanBase):
> > @param options: cli options
> > @param repo_settings: repository settings insta

[gentoo-portage-dev] [PATCH] repoman: add --include-profiles=PROFILES

2019-11-18 Thread Sergei Trofimovich
repoman slows down ~linearly with amount of profiles being scanned.
In case of amd64 we have 28 stable profiles.

To speed up processing and fit into time budged of various CIs we can
split the work across different processes that handle different profiles.

Example benchmark on ::haskell overlay:
$ ./repoman full --include-arches=amd64
~65 minutes
$ ./repoman full --include-profiles=default/linux/amd64/17.0
~4 minutes
This allows for a crude sharding of work across processes and allows for
cheap tree-wide scans for early failures.

Bug: https://bugs.gentoo.org/700456
Signed-off-by: Sergei Trofimovich 
---
 repoman/lib/repoman/actions.py  | 4 
 repoman/lib/repoman/argparser.py| 7 +++
 repoman/lib/repoman/modules/scan/depend/__init__.py | 3 ++-
 repoman/lib/repoman/modules/scan/depend/profile.py  | 9 +++--
 repoman/lib/repoman/scanner.py  | 5 +
 repoman/man/repoman.1   | 4 
 6 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/repoman/lib/repoman/actions.py b/repoman/lib/repoman/actions.py
index 1c9989a72..92d4d4e94 100644
--- a/repoman/lib/repoman/actions.py
+++ b/repoman/lib/repoman/actions.py
@@ -412,6 +412,10 @@ the whole commit message to abort.
report_options.append(
"--include-arches=\"%s\"" %
" ".join(sorted(self.scanner.include_arches)))
+   if self.scanner.include_profiles is not None:
+   report_options.append(
+   "--include-profiles=\"%s\"" %
+   " ".join(sorted(self.scanner.include_profiles)))
 
if portage_version is None:
sys.stderr.write("Failed to insert portage version in 
message!\n")
diff --git a/repoman/lib/repoman/argparser.py b/repoman/lib/repoman/argparser.py
index fa0e6ff90..670a0e91d 100644
--- a/repoman/lib/repoman/argparser.py
+++ b/repoman/lib/repoman/argparser.py
@@ -164,6 +164,13 @@ def parse_args(argv, repoman_default_opts):
'A space separated list of arches used to '
'filter the selection of profiles for dependency 
checks'))
 
+   parser.add_argument(
+   '--include-profiles',
+   dest='include_profiles', metavar='PROFILES', action='append',
+   help=(
+   'A space separated list of profiles used to '
+   'define the selection of profiles for dependency 
checks'))
+
parser.add_argument(
'-d', '--include-dev', dest='include_dev', action='store_true',
default=False,
diff --git a/repoman/lib/repoman/modules/scan/depend/__init__.py 
b/repoman/lib/repoman/modules/scan/depend/__init__.py
index c3cc0ddeb..9068760bb 100644
--- a/repoman/lib/repoman/modules/scan/depend/__init__.py
+++ b/repoman/lib/repoman/modules/scan/depend/__init__.py
@@ -19,7 +19,8 @@ module_spec = {
'func_desc': {
},
'mod_kwargs': ['qatracker', 'portdb', 'profiles', 
'options',
-   'repo_metadata', 'repo_settings', 
'include_arches', 'caches',
+   'repo_metadata', 'repo_settings', 
'include_arches',
+   'include_profiles', 'caches',
'repoman_incrementals', 'env', 'have', 
'dev_keywords'
],
'func_kwargs': {
diff --git a/repoman/lib/repoman/modules/scan/depend/profile.py 
b/repoman/lib/repoman/modules/scan/depend/profile.py
index d980f4eca..0b1d74483 100644
--- a/repoman/lib/repoman/modules/scan/depend/profile.py
+++ b/repoman/lib/repoman/modules/scan/depend/profile.py
@@ -33,6 +33,7 @@ class ProfileDependsChecks(ScanBase):
@param options: cli options
@param repo_settings: repository settings instance
@param include_arches: set
+   @param include_profiles: set
@param caches: dictionary of our caches
@param repoman_incrementals: tuple
@param env: the environment
@@ -46,6 +47,7 @@ class ProfileDependsChecks(ScanBase):
self.options = kwargs.get('options')
self.repo_settings = kwargs.get('repo_settings')
self.include_arches = kwargs.get('include_arches')
+   self.include_profiles = kwargs.get('include_profiles')
self.caches = kwargs.get('caches')
self.repoman_incrementals = kwargs.get('repoman_incrementals')
self.env = kwargs.get('env')
@@ -81,8 +83,11 @@ class ProfileDependsChecks(ScanBase):
if arch not in self.include_arches:
 

[gentoo-dev] Re: [PATCH] metadata/install-qa-check.d/08gentoo-paths: add explicit maintainer

2019-11-11 Thread Sergei Trofimovich
On Sun,  3 Nov 2019 22:17:31 +
Sergei Trofimovich  wrote:

> Bugs like bug #670902 get stuck due to unclear maintainership status.
> Let's assign it to dev-portage@ as it historicallily lived in portage
> source tree and QA does not take it over in bug #670902.
> 
> Bug: https://bugs.gentoo.org/670902
> Signed-off-by: Sergei Trofimovich 
> ---
>  metadata/install-qa-check.d/08gentoo-paths | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/metadata/install-qa-check.d/08gentoo-paths 
> b/metadata/install-qa-check.d/08gentoo-paths
> index 3ee887df08f..5161aef9922 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -1,5 +1,8 @@
>  # Check whether ebuilds are not installing new, non-Gentoo-ey paths.
>  
> +# QA check: validate Gentoo's filesystem layout policies
> +# Maintainer: Portage team 
> +
>  gentoo_path_check() {
>   # allowed path definitions
>   # 
> -- 
> 2.23.0
> 

Pushed as 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61d8c12e7207b9e22b9d63692e8157a314101742

-- 

  Sergei



Re: [gentoo-dev] [PATCH] autotools.eclass: drop outdated sys-devel/gettext blocker

2019-11-10 Thread Sergei Trofimovich
On Fri, 23 Aug 2019 22:46:22 +0200
Thomas Deutschmann  wrote:

> All  
> Reported-by: Jory Pratt 
> Signed-off-by: Thomas Deutschmann 
> ---
>  eclass/autotools.eclass | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

I pushed it as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e10485c43714c1d2bb4e241c29f60ac56c45b75b

> diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
> index 9143aa454d0d..9df0e1b93663 100644
> --- a/eclass/autotools.eclass
> +++ b/eclass/autotools.eclass
> @@ -109,10 +109,7 @@ if [[ -n ${WANT_LIBTOOL} ]] ; then
>   export WANT_LIBTOOL
>  fi
>  
> -# Force people (nicely) to upgrade to a newer version of gettext as
> -# older ones are known to be crappy.  #496454
> -AUTOTOOLS_DEPEND="! - ${_automake_atom}
> +AUTOTOOLS_DEPEND="${_automake_atom}
>   ${_autoconf_atom}
>   ${_libtool_atom}"
>  RDEPEND=""
> -- 
> 2.23.0
> 
> 


-- 

  Sergei



[gentoo-dev] glibc-2.30 went into the ~arch

2019-11-08 Thread Sergei Trofimovich
A few minutes ago glibc-2.30 got back it's ~arch keywords as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c0fbcff7b24f844b4be7b6f380a3279a46715ece
We don't expect too many build failures.

Please add new failures to the tracker bug:
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.30

As always feel free to cc toolchain@ explicitly on tricky build failures
without clear path to resolution. We will figure something out together.

Typical build failures (and sometimes example fixes) can be found at:
https://wiki.gentoo.org/wiki/Project:Toolchain#glibc-2.30

-- 

  Sergei



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Sergei Trofimovich
On Thu, 7 Nov 2019 11:52:19 -0800
Patrick McLean  wrote:

> Given glibc upstream's tentative plans to remove libcrypt [1], I think
> we should start working out the kinks well in advance. Toolchain has
> already added a package.use.force-ed "crypt" USE flag to
> sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
> which I have recently bumped and added a package.use.mask-ed "system"
> USE flag to make it provide the "system" version of libcrypt.so.
> 
> To give us time to work out dependencies in advance, I would like to
> propose a virtual to provide libcrypt.so, and we can gradually update
> all users of libcrypt to {R,}DEPEND on this virtual.

It's not clear how this virtual is supposed to work when sys-libs/libxcrypt
actually changes ABI. Do we care about the missing rebuilds or we do not?

If we don't it's (not ideal but) fine. But it should be stated explicitly and
consequences should be described: does sys-libs/libxcrypt override
glibc's libcrypt.so.1 and break existing applications? Or we guarantee it not
to happen?

>   elibc_glibc? ( || (
>   sys-libs/glibc[crypt(+)]
>   sys-libs/libxcrypt[system(-)]
>   )
>   )

Same for switching providers back and forth. For example, should we allow
user to come back from sys-libs/libxcrypt to sys-libs/glibc?

> Maybe once this is in place and the obvious/common packages are
> updated, we could request a tinderbox run to flush out what was missed.

I don't think tinderbox will find much as util-linux, shadow or any other
low-level package will pull it in as a dependency and be silently available.

I think you'll need to do extra to find those. Like, removing libcrypt.so
to make sure linker won't find it even if libcrypt.so.1 is available.

> [1] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> [2] https://bugs.gentoo.org/699422


-- 

  Sergei



Re: [gentoo-dev] Re: [PATCH] Fix tc-cpp-is-true to work with clang

2019-11-06 Thread Sergei Trofimovich
On Mon, 4 Nov 2019 20:18:11 +
Sergei Trofimovich  wrote:

> On Mon,  4 Nov 2019 10:11:20 +
> Mattias Nissler  wrote:
> 
> > Clang's preprocessor likes to output a leading newline, which makes
> > the comparison always fail. GCC generates additional output with certain
> > flags (e.g. -ggdb3) as well. Hence, switch the test to trigger a
> > preprocessor error when the condition is not true and examine the exit
> > code.
> > 
> > Bug: https://bugs.gentoo.org/698912
> > 
> > Signed-off-by: Mattias Nissler 
> > ---
> >  eclass/toolchain-funcs.eclass | 15 +++
> >  1 file changed, 7 insertions(+), 8 deletions(-)  
> 
> Looks good! I'll pull it in to ::gentoo in a few days.

Pushed to ::gentoo as:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ef6b9da7bb04afd77e1bc5db011b02d658a
Also while at it added basic regression test:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8f02136721af40dd89a09101504750fb28f8142e

-- 

  Sergei



[gentoo-dev] Re: [PATCH] Fix tc-cpp-is-true to work with clang

2019-11-04 Thread Sergei Trofimovich
On Mon,  4 Nov 2019 10:11:20 +
Mattias Nissler  wrote:

> Clang's preprocessor likes to output a leading newline, which makes
> the comparison always fail. GCC generates additional output with certain
> flags (e.g. -ggdb3) as well. Hence, switch the test to trigger a
> preprocessor error when the condition is not true and examine the exit
> code.
> 
> Bug: https://bugs.gentoo.org/698912
> 
> Signed-off-by: Mattias Nissler 
> ---
>  eclass/toolchain-funcs.eclass | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)

Looks good! I'll pull it in to ::gentoo in a few days.

Thank you!

> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index e358d484417..1bc6cbbc108 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -207,14 +207,13 @@ tc-cpp-is-true() {
>   local CONDITION=${1}
>   shift
>  
> - local RESULT=$($(tc-getTARGET_CPP) "${@}" -P - <<-EOF 2>/dev/null
> - #if ${CONDITION}
> - true
> - #endif
> - EOF
> - )
> -
> - [[ ${RESULT} == true ]]
> + $(tc-getTARGET_CPP) "${@}" -P - <<-EOF >/dev/null 2>&1
> + #if ${CONDITION}
> + true
> + #else
> + #error false
> + #endif
> + EOF
>  }
>  
>  # @FUNCTION: tc-detect-is-softfloat
> -- 
> 2.21.0
> 


-- 

  Sergei



  1   2   3   >