Re: [gentoo-portage-dev] [PATCH v2] bin/doins.py: implement install -p option (bug 642632)

2017-12-30 Thread Zac Medico 
On 12/30/2017 01:45 PM, Mike Gilbert wrote:
> On Fri, Dec 29, 2017 at 7:19 PM, Zac Medico  wrote:
>> +def _set_timestamps(source_stat, dest):
>> +   """Apply timestamps from source_stat to dest.
>> +
>> +   Args:
>> +   source_stat: stat result for the source file.
>> +   dest: path to the dest file.
>> +   """
>> +   os.utime(dest, (source_stat.st_atime, source_stat.st_mtime))
>> +
>> +
>> +if sys.version_info >= (3, 3):
>> +   def _set_timestamps_ns(source_stat, dest):
>> +   os.utime(dest, ns=(source_stat.st_atime_ns, 
>> source_stat.st_mtime_ns))
>> +
>> +   _set_timestamps_ns.__doc__ = _set_timestamps.__doc__
>> +   _set_timestamps = _set_timestamps_ns
>> +
>> +
> 
> This seems weirdly complex. I guess the goal was to reduce the
> sys.version_info check to once per import?

Yeah, and generally it's cleanest to create compatibility shims in cases
like this.

> The __doc__ trick is nifty, but I'm not sure I would ever want to use it 
> myself.

Yeah, the alternative of writing the docstring twice wasn't very appealing.

> Anyway, just my thoughts as an unpracticed python programmer. It looks
> like this code will get the job done.

-- 
Thanks,
Zac

Re: [gentoo-dev] LINGUAS to be removed from USE_EXPAND

2017-12-30 Thread Chí-Thanh Christopher Nguyễn 
gro...@gentoo.org schrieb:

> The package sci-mathematics/maxima for ages uses linguas_* flags for
> installing translated documentation, the possible values of * are
> 
> de es pt pt_BR
> 
> This usage is, I suppose, wrong. I tried simply to replace all linguas_ to
> l10n_ in the ebuild, but repoman complains about pt_BR.

It should be l10n_pt-BR.
LINGUAS used POSIX locales which define _ as separator between language and
territory, while L10N uses BCP 47 which defines - as separator.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] LINGUAS to be removed from USE_EXPAND

2017-12-30 Thread grozin 

On Thu, 28 Dec 2017, Ulrich Mueller wrote:

Last year we had announced introduction of a new L10N variable
intended to replace LINGUAS as a USE_EXPAND variable [1]. Since then,
many packages have been converted to the new variable.

The next step in the conversion will be removal of LINGUAS from
USE_EXPAND, which means that LINGUAS will become a normal variable,
maintaining the standard gettext behaviour. For a transition time,
all linguas_* flags currently existing in packages' IUSE will be
added to use.desc, but will be removed again when conversion of the
remaining packages is complete.
The package sci-mathematics/maxima for ages uses linguas_* flags for 
installing translated documentation, the possible values of * are


de es pt pt_BR

This usage is, I suppose, wrong. I tried simply to replace all linguas_ to 
l10n_ in the ebuild, but repoman complains about pt_BR.


What is the correct mechanism to install translated documentation 
depending on the user's wishes?


Andrey

[gentoo-dev] Last rites: vmware-bundle.eclass

2017-12-30 Thread Mike Gilbert 
vmwware-bundle.eclass is unused since the vmware ebuilds were removed
from the gentoo repository. The eclass will be removed in 30 days.

A copy of the eclass has already been added to the vmware repository.

https://bugs.gentoo.org/642710

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile 
On 12/30/17 12:18 PM, Andreas K. Huettel wrote:
> Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
>> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
>> that gcc depend on (see bug #642316).  I went through and made the
>> changes necessary to get the eclass up to EAPI=5 and compile tested
>> across the board (ie all dependent ebuilds) for amd64.  Everything looks
>> good, so please review and I'll commit if we're okay.
> 
> - confgcc+=( $(use_enable altivec) )
> + in_iuse altivec && confgcc+=( $(use_enable altivec) )
> 
> ^ Just as an example, such a construct may change the "default setting" when 
> no altivec useflag exists...
> 
> Imagine that upstream enables altivec by default (?). In earlier eapis, 
> use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
> without the useflag, no setting is passed to configure, and it's enabled.
> 
> So, while this all works in principle, it may need careful per-flag review.
> 

Okay so I tested and found that there is no change in the default
settings due to the above construct (and there are a few).  The way I
did it was I built >=gcc-4.9.4 with and without the toolchain.eclass
patch and compared the config.log's (there's about 33 per version of
gcc).  There were no substantial differences.  If there would have been
a change in the default behavior, then lines like following would have
shown a difference.


  $ /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls
--without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.2.0
p1.1 --disable-esp --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --disable-libmpx --enable-vtable-verify
--enable-libvtv --enable-lto --without-isl --enable-libsanitizer
--disable-default-pie --enable-default-ssp


I didn't test earlier gcc versions because they're masked.  I tested
only on amd64 but I think that's oaky.  The only flag my tests don't
cover is the altivec flag (which is for ppc/ppc64), but it defaults off
on all gcc versions.

I think this puts your concern to rest.

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

Re: [gentoo-portage-dev] [PATCH v2] bin/doins.py: implement install -p option (bug 642632)

2017-12-30 Thread Mike Gilbert 
On Fri, Dec 29, 2017 at 7:19 PM, Zac Medico  wrote:
> +def _set_timestamps(source_stat, dest):
> +   """Apply timestamps from source_stat to dest.
> +
> +   Args:
> +   source_stat: stat result for the source file.
> +   dest: path to the dest file.
> +   """
> +   os.utime(dest, (source_stat.st_atime, source_stat.st_mtime))
> +
> +
> +if sys.version_info >= (3, 3):
> +   def _set_timestamps_ns(source_stat, dest):
> +   os.utime(dest, ns=(source_stat.st_atime_ns, 
> source_stat.st_mtime_ns))
> +
> +   _set_timestamps_ns.__doc__ = _set_timestamps.__doc__
> +   _set_timestamps = _set_timestamps_ns
> +
> +

This seems weirdly complex. I guess the goal was to reduce the
sys.version_info check to once per import?

The __doc__ trick is nifty, but I'm not sure I would ever want to use it myself.

Anyway, just my thoughts as an unpracticed python programmer. It looks
like this code will get the job done.

[gentoo-dev] [PATCH] Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only

2017-12-30 Thread Sergei Trofimovich 
CROSSCOMPILE_OPTS is a USE_EXPAND of a single item: headers-only.
Convert it to a global USE flag instead.

The changes are:
- mechanical ebuild rename (touches libcs and kernel headers):
$ sed -e 's@crosscompile_opts_headers-only@headers-only@g' \
-i $(git grep -l headers-only)
- added global 'headers-only' USE
- CROSSCOMPILE_OPTS USE_EXPAND is removed

'headers-only' flag is used by crossdev to bootstrap stage1 compiler
before libc is available.

crossdev switched to USE=headers-only in =sys-devel/crossdev-20171230.
After crossdev goes stable this change can go in.

CC: toolch...@gentoo.org
CC: embed...@gentoo.org
CC: ker...@gentoo.org
CC: b...@gentoo.org
CC: bluen...@gentoo.org
CC: lu_z...@gentoo.org
Reported-by: Michał Górny
Bug: https://bugs.gentoo.org/642712
Signed-off-by: Sergei Trofimovich <sly...@gentoo.org>
---
 dev-embedded/avr-libc/avr-libc-2.0.0.ebuild  | 2 +-
 dev-libs/cygwin/cygwin-1.5.25.15.ebuild  | 8 
 dev-util/mingw-runtime/mingw-runtime-3.18.ebuild | 4 ++--
 dev-util/mingw-runtime/mingw-runtime-3.20.2.ebuild   | 4 ++--
 dev-util/mingw-runtime/mingw-runtime-3.20.ebuild | 4 ++--
 dev-util/mingw-runtime/mingw-runtime-4.0.3.1.ebuild  | 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-3.0.0.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-3.1.0.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-3.2.0-r1.ebuild | 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-4.0.1.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-4.0.4.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-4.0.6.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.1.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.2-r1.ebuild | 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.2-r2.ebuild | 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.2.ebuild| 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.3-r1.ebuild | 4 ++--
 dev-util/mingw64-runtime/mingw64-runtime-5.0.3.ebuild| 4 ++--
 dev-util/w32api/w32api-3.17.2.ebuild | 4 ++--
 dev-util/w32api/w32api-4.0.3.1.ebuild| 4 ++--
 eclass/kernel-2.eclass   | 4 ++--
 eclass/toolchain-glibc.eclass| 2 +-
 eclass/toolchain.eclass  | 2 +-
 profiles/base/make.defaults  | 4 ++--
 profiles/desc/crosscompile_opts.desc | 8 
 profiles/embedded/make.defaults  | 4 ++--
 profiles/use.desc| 1 +
 sys-freebsd/freebsd-lib/freebsd-lib-10.3-r3.ebuild   | 6 +++---
 sys-freebsd/freebsd-lib/freebsd-lib-11.0-r1.ebuild   | 6 +++---
 sys-freebsd/freebsd-lib/freebsd-lib-11.1.ebuild  | 6 +++---
 sys-freebsd/freebsd-lib/freebsd-lib-8.2-r1.ebuild| 6 +++---
 sys-freebsd/freebsd-lib/freebsd-lib-9.1-r11.ebuild   | 6 +++---
 sys-libs/glibc/glibc-2.18-r1.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.19-r1.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.20-r2.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.21-r2.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.22-r4.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.23-r4.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.24-r4.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.25-r10.ebuild | 4 ++--
 sys-libs/glibc/glibc-2.25-r9.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.26-r3.ebuild  | 4 ++--
 sys-libs/glibc/glibc-2.26-r4.ebuild  | 4 ++--
 sys-libs/glibc/glibc-.ebuild | 6 +++---
 sys-libs/musl/musl-1.1.18-r1.ebuild  | 4 ++--
 sys-libs/musl/musl-1.1.18.ebuild | 4 ++--
 sys-libs/musl/musl-.ebuild   | 4 ++--
 sys-libs/newlib/newlib-2.0.0.ebuild  | 2 +-
 sys-libs/newlib/newlib-2.1.0.ebuild  | 2 +-
 sys-libs/newlib/newlib-2.2.0.20150423.ebuild | 2 +-
 sys-libs/newlib/newlib-2.2.0.ebuild  | 2 +-
 sys-libs/newlib/newlib-2.3.0.20160104.ebuild | 2 +-
 sys-libs/newlib/newlib-2.4.0.ebuild  | 2 +-
 sys-libs/newlib/newlib-2.5.0.ebuild  | 2 +-
 sys-libs/newlib/newlib-.ebuild   | 2 +-
 sys-libs/uclibc-ng/uclibc-ng-1.0.25.ebuild   | 4 ++--
 sys-libs/uclibc-ng/uclibc-ng-1.0.26.ebuild   | 4 ++--
 sys-libs/uclibc-ng/uclibc-ng-1.0.27.ebuild   | 4 ++--
 sys-libs/uclibc-ng/uclibc-ng-.ebuild | 4 ++--
 sys-libs/uclibc/uclibc-0.9.33.2-r15.ebuild   | 4 ++--
 sys-libs/uclibc/uclibc-0.9.33..ebuild| 4 ++--
 sys-libs/uclibc/uclibc-.ebuild   | 4 ++

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Andreas K. Huettel 
Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
> Hi everyone,
> 
> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
> that gcc depend on (see bug #642316).  I went through and made the
> changes necessary to get the eclass up to EAPI=5 and compile tested
> across the board (ie all dependent ebuilds) for amd64.  Everything looks
> good, so please review and I'll commit if we're okay.

-   confgcc+=( $(use_enable altivec) )
+   in_iuse altivec && confgcc+=( $(use_enable altivec) )

^ Just as an example, such a construct may change the "default setting" when 
no altivec useflag exists...

Imagine that upstream enables altivec by default (?). In earlier eapis, 
use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
without the useflag, no setting is passed to configure, and it's enabled.

So, while this all works in principle, it may need careful per-flag review.

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail m...@akhuettel.de
http://www.akhuettel.de/

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: [gentoo-kernel] Dropping stable USE flags for 4.14

2017-12-30 Thread Greg KH 
On Sat, Dec 30, 2017 at 03:14:45PM +0100, Greg KH wrote:
> On Fri, Dec 29, 2017 at 10:58:28PM +0900, Alice Ferrazzi wrote:
> > 
> > - Unbootable system with CONFIG_MCORE2 [6]

This turns out to be a gentoo-specific bug, not much upstream can do
about a broken compiler that some profiles are using :(

greg k-h

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile 
On 12/30/17 9:13 AM, Anthony G. Basile wrote:
> On 12/30/17 9:08 AM, Michael Orlitzky wrote:
>> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>>> use_if_iuse !nopie && return 0
>>
>> Does this work? The "use" function supports negation (undocumented, but
>> it's in the PMS), but I don't think use_if_iuse does.
>>
> 
> Okay I'll read the code and test.  You're right that I just assumed it
> worked liked "use" wrt negation so the semantics need to be checked.
> 
> Thanks for looking this over carefully.
> 

It looks like it would not work as expected because eutils.eclass has

in_iuse() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${#} -eq 1 ]] || die "Invalid args to ${FUNCNAME}()"

local flag=${1}
local liuse=( ${IUSE} )

has "${flag}" "${liuse[@]#[+-]}"
}

use_if_iuse() {
in_iuse $1 || return 1
use $1
}

So $1 in use_if_iuse binds to "!nopie" and then in in_iuse again to
"!nopie" which then messes up the has line, looking for a flag named
"!nopie" in IUSE which will always be true.

I'll change that line to

use_if_iuse nopie || return 0

Grepping the tree, I see only instances of

if ! use_if_iuse X ...

which is good.


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

Re: [gentoo-dev] Masking 4.12

2017-12-30 Thread Rich Freeman 
On Sat, Dec 30, 2017 at 3:49 AM, Toralf Förster  wrote:
> On 12/30/2017 07:52 AM, Alice Ferrazzi wrote:
>> Hello,
>>
>> We recently dropped the stable keywords for 4.14,
>> but 4.12 (the next stable in gentoo-sources) is no more
>> maintained from upstream.
>>
>> The last update that 4.12 got from upstream was 2017-09-20,
>> and upstream is no more backporting security fixes since then.
>> Because of this, we will proceed to mask 4.12.
>>
>> Keep in mind: If 4.14 works for you, you can keyword it and
>> continue to use it, if you need a more stable kernel, please
>> move to 4.9.
>>
> At the LKML you can read that Linus Torvalds blames Gentoo GCC patch
> set  for few issues related to 4.14.9
>

Not the patch set so much as gcc itself and the hardened profile
enabling of -fstack-protector in the spec.  It sounds like upstream
may explicitly disable it, but it probably wouldn't hurt for the
ebuilds to do so as well if it is known to cause problems, at least
until gcc fixes whatever they're doing wrong.

https://lkml.org/lkml/2017/12/29/488

-- 
Rich

[gentoo-dev] Re: [gentoo-kernel] Dropping stable USE flags for 4.14

2017-12-30 Thread Greg KH 
On Fri, Dec 29, 2017 at 10:58:28PM +0900, Alice Ferrazzi wrote:
> Hello,
> 
> We have recently started the stabilization of gentoo-sources-4.14.8.
> 
> Very soon we received reports regarding broken e1000e driver [1] and moved
> to gentoo-sources-4.14.8-r1.
> 
> Since then we keep receiving new problems related to 4.14.x kernel:
> 
> - IPSec is broken [2]
> 
> - Change in 4.14.9 broke nVIDIA driver [3]
> 
> - Colors on console are broken with some Radeon HD cards [4]
> 
> - BUG report on boot [5]
> 
> - Unbootable system with CONFIG_MCORE2 [6]
> 
> - ...more bugs [7]
> 
> While not all issues are present in gentoo-sources-4.14.8-r1 we are
> concerned about the current stability/quality of the 4.14.x branch in
> general and don't feel comfortable recommending 4.14.x branch for general
> use at the moment. But that's what a stable USE flag means for most
> Gentoo users.
> 
> So, for now, we have decided to drop gentoo-sources-4.14.x stable keywords.
> We will keep watching 4.14 branch and once the stability/quality matches
> our requirements we will restart stabilization.

Be careful, you don't want to drop back to older kernels with known
security issues that are already fixed in the latest 4.14.y release.

Most of the above issues have resolutions already, and yes, 4.14 is
being a bit more "temperamental", sorry, it will pay off in the end...

thanks,

greg k-h

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile 
On 12/30/17 9:08 AM, Michael Orlitzky wrote:
> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>> use_if_iuse !nopie && return 0
> 
> Does this work? The "use" function supports negation (undocumented, but
> it's in the PMS), but I don't think use_if_iuse does.
> 

Okay I'll read the code and test.  You're right that I just assumed it
worked liked "use" wrt negation so the semantics need to be checked.

Thanks for looking this over carefully.

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

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Michael Orlitzky 
On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
> use_if_iuse !nopie && return 0

Does this work? The "use" function supports negation (undocumented, but
it's in the PMS), but I don't think use_if_iuse does.

[gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile 
Hi everyone,

We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
causing problems with subslotting libraries like mpfr, mpc, gmp and isl
that gcc depend on (see bug #642316).  I went through and made the
changes necessary to get the eclass up to EAPI=5 and compile tested
across the board (ie all dependent ebuilds) for amd64.  Everything looks
good, so please review and I'll commit if we're okay.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
From b4a707673b7a3e36959a071292807945b07fd018 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" 
Date: Sat, 30 Dec 2017 06:56:29 -0500
Subject: [PATCH 1/2] toolchain.eclass: update to EAPI=5 standards

This eclass is inherited by ebuilds in sys-devel/{gcc,kgcc64,gcc-apple},
each which make use of different IUSE flags.   This causes problems with
`use X` construcitons when X is not in the IUSE flags.  At EAPI=4 this
simply emitted a warning, while at EAPI=5 this is an error.  We update
the eclass to make use of use_if_iuse and similar constructions where
necessary to bring the eclass into compliance with EAPI=5.

Signed-off-by: Anthony G. Basile 
---
 eclass/toolchain.eclass | 69 ++---
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a038303ec7f..bf6aa89e2fb 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -496,7 +496,7 @@ toolchain_src_prepare() {
do_gcc_PIE_patches
epatch_user
 
-   if ( tc_version_is_at_least 4.8.2 || use hardened ) && ! use vanilla ; 
then
+   if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
make_gcc_hard
fi
 
@@ -538,7 +538,7 @@ toolchain_src_prepare() {
fi
 
# >= gcc-4.3 doesn't bundle ecj.jar, so copy it
-   if tc_version_is_at_least 4.3 && use gcj ; then
+   if tc_version_is_at_least 4.3 && use_if_iuse gcj ; then
if tc_version_is_at_least 4.5 ; then
einfo "Copying ecj-4.5.jar"
cp -pPR "${DISTDIR}/ecj-4.5.jar" "${S}/ecj.jar" || die
@@ -648,20 +648,20 @@ make_gcc_hard() {
 
# Gcc >= 6.X we can use configurations options to turn pie/ssp on as 
default
if tc_version_is_at_least 6.0 ; then
-   if use pie ; then
+   if use_if_iuse pie ; then
einfo "Updating gcc to use automatic PIE building ..."
fi
-   if use ssp ; then
+   if use_if_iuse ssp ; then
einfo "Updating gcc to use automatic SSP building ..."
fi
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# Will add some optimatizion as default.
gcc_hard_flags+=" -DEXTRA_OPTIONS"
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
fi
else
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
if hardened_gcc_works ; then
@@ -909,7 +909,7 @@ toolchain_src_configure() {
 
# Use the default ("release") checking because upstream usually neglects
# to test "disabled" so it has a history of breaking. #317217
-   if tc_version_is_at_least 3.4 ; then
+   if tc_version_is_at_least 3.4 && in_iuse debug ; then
# The "release" keyword is new to 4.0. #551636
local off=$(tc_version_is_at_least 4.0 && echo release || echo 
no)
confgcc+=( --enable-checking="${GCC_CHECKS_LIST:-$(usex debug 
yes ${off})}" )
@@ -922,7 +922,7 @@ toolchain_src_configure() {
)
 
# If we want hardened support with the newer piepatchset for >=gcc 4.4
-   if tc_version_is_at_least 4.4 && want_minispecs ; then
+   if tc_version_is_at_least 4.4 && want_minispecs && in_iuse hardened ; 
then
confgcc+=( $(use_enable hardened esp) )
fi
 
@@ -934,7 +934,7 @@ toolchain_src_configure() {
fi
 
# Support to disable pch when building libstdcxx
-   if tc_version_is_at_least 6.0 && ! use pch ; then
+   if tc_version_is_at_least 6.0 && ! use_if_iuse pch ; then
confgcc+=( --disable-libstdcxx-pch )
fi
 
@@ -1058,12 +1058,12 @@ toolchain_src_configure() {
gcc-multilib-configure
 
# ppc altivec support
-   confgcc+=( $(use_enable altivec) )
+   in_iuse altivec && confgcc+=( $(use_enable altivec) )
 
# gcc

Re: [gentoo-dev] Masking 4.12

2017-12-30 Thread Toralf Förster 
On 12/30/2017 07:52 AM, Alice Ferrazzi wrote:
> Hello,
>
> We recently dropped the stable keywords for 4.14,
> but 4.12 (the next stable in gentoo-sources) is no more
> maintained from upstream.
>
> The last update that 4.12 got from upstream was 2017-09-20,
> and upstream is no more backporting security fixes since then.
> Because of this, we will proceed to mask 4.12.
>
> Keep in mind: If 4.14 works for you, you can keyword it and
> continue to use it, if you need a more stable kernel, please
> move to 4.9.
>
At the LKML you can read that Linus Torvalds blames Gentoo GCC patch
set  for few issues related to 4.14.9


-- 
Toralf
PGP 23217DA7 9B888F45




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grabs: media-sound/supercollider, media-gfx/maim, x11-misc/slop

2017-12-30 Thread Jonas Stein 
Dear all,

The following packages are up for grabs:

media-sound/supercollider
media-gfx/maim
x11-misc/slop

after retirement of the proxied maintainer.
https://bugs.gentoo.org/615364

https://packages.gentoo.org/packages/media-sound/supercollider
https://packages.gentoo.org/packages/media-gfx/maim
https://packages.gentoo.org/packages/x11-misc/slop


Open bugs:

media-sound/supercollider
many open tickets, some with patches included:
https://bugs.gentoo.org/buglist.cgi?quicksearch=media-sound%2Fsupercollider_id=3788742

media-gfx/maim
https://bugs.gentoo.org/631480

x11-misc/slop
https://bugs.gentoo.org/629440

-- 
Best,
Jonas











































signature.asc
Description: OpenPGP digital signature