Re: [gentoo-portage-dev] [PATCH] Default BINPKG_COMPRESSION to zstd (bug 715108)

2020-05-25 Thread Zac Medico
On 5/12/20 1:28 AM, Francesco Riosa wrote:
> 
> Il 11/05/20 22:21, Brian Dolbec ha scritto:
>> On Sun, 10 May 2020 19:29:34 -0700
>> Zac Medico  wrote:
>>
>>> This includes a _compat_upgrade.binpkg_compression script that the
>>> ebuild can call in pkg_preinst in order to maintain a
>>> backward-compatible bzip2 default when appropriate, ensuring that
>>> binary package consumers are not caught off guard.
> 
> [snip]
> 
> For your interest, the binpkg archive for a small LAMP container goes
> from 659 to 540 MB, the "--rm" flag isn't really needed for binpkgs but
> it help reminder that zstd is the only one that does _not_ remove the
> original file after compression
> 
> BINPKG_COMPRESS="zstd"
> BINPKG_COMPRESS_FLAGS="--rm --long --threads=1 --adapt=min=7,max=19"

I'm using those flag now. Thanks!
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] Default BINPKG_COMPRESSION to zstd (bug 715108)

2020-05-25 Thread Zac Medico
On 5/11/20 1:21 PM, Brian Dolbec wrote:
>> diff --git a/man/make.conf.5 b/man/make.conf.5
>> index f82fed65a..a3bd662ae 100644
>> --- a/man/make.conf.5
>> +++ b/man/make.conf.5
>> @@ -1,4 +1,4 @@
>> -.TH "MAKE.CONF" "5" "Nov 2019" "Portage VERSION" "Portage"
>> +.TH "MAKE.CONF" "5" "May 2020" "Portage VERSION" "Portage"
>>  .SH "NAME"
>>  make.conf \- custom settings for Portage
>>  .SH "SYNOPSIS"
>> @@ -115,7 +115,7 @@ This variable is used to determine the
>> compression used for \fIbinary packages\fR. Supported settings and
>> compression algorithms are: bzip2, gzip, lz4, lzip, lzop, xz, zstd.
>>  .br
>> -Defaults to "bzip2".
>> +Defaults to "zstd".
>>  .br
>>  .I Example:
>>  .nf
> looks good, I've not tested it, but changes are minor
> 

I've merged this and released it in portage-2.3.100:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=230595cf600cae6beb6ebf6f817d08ace433c3ea
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] config.environ: delay export of A and AA (bug 720180)

2020-05-25 Thread Zac Medico
Since variables like A and AA can contain extremely large values which
may trigger E2BIG errors during attempts to execute subprocesses, delay
export until the last moment, and unexport when appropriate.

Bug: https://bugs.gentoo.org/720180
Signed-off-by: Zac Medico 
---
 bin/eapi.sh   |  9 +
 bin/isolated-functions.sh | 34 
 bin/phase-functions.sh| 13 +++
 .../ebuild/_config/special_env_vars.py|  7 +++-
 lib/portage/package/ebuild/config.py  | 39 ++-
 5 files changed, 91 insertions(+), 11 deletions(-)

diff --git a/bin/eapi.sh b/bin/eapi.sh
index 29dfb008c..f56468e4a 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -26,6 +26,15 @@ ___eapi_has_S_WORKDIR_fallback() {
 
 # VARIABLES
 
+___eapi_exports_A() {
+   # https://bugs.gentoo.org/721088
+   true
+}
+
+___eapi_exports_AA() {
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3)$ ]]
+}
+
 ___eapi_has_prefix_variables() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2)$ || " ${FEATURES} " == *" force-prefix 
"* ]]
 }
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index fde684013..973450d86 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -107,6 +107,39 @@ __bashpid() {
sh -c 'echo ${PPID}'
 }
 
+# @FUNCTION: ___eapi_vars_export
+# @DESCRIPTION:
+# Export variables for the current EAPI. Calls to this function should
+# be delayed until the last moment, since exporting these variables
+# may trigger E2BIG errors suring attempts to execute subprocesses.
+___eapi_vars_export() {
+   source "${T}/environment.unexported" || die
+
+   if ___eapi_exports_A; then
+   export A
+   fi
+
+   if ___eapi_exports_AA; then
+   export AA
+   fi
+}
+
+# @FUNCTION: ___eapi_vars_unexport
+# @DESCRIPTION:
+# Unexport variables that were exported for the current EAPI. This
+# function should be called after an ebuild phase, in order to unexport
+# variables that may trigger E2BIG errors during attempts to execute
+# subprocesses.
+___eapi_vars_unexport() {
+   if ___eapi_exports_A; then
+   export -n A
+   fi
+
+   if ___eapi_exports_AA; then
+   export -n AA
+   fi
+}
+
 __helpers_die() {
if ___eapi_helpers_can_die && [[ ${PORTAGE_NONFATAL} != 1 ]]; then
die "$@"
@@ -122,6 +155,7 @@ die() {
 
set +x # tracing only produces useless noise here
local IFS=$' \t\n'
+   ___eapi_vars_unexport
 
if ___eapi_die_can_respect_nonfatal && [[ $1 == -n ]]; then
shift
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 90e622e75..df2c0d8de 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -146,6 +146,7 @@ __filter_readonly_variables() {
fi
fi
 
+   ___eapi_vars_unexport
"${PORTAGE_PYTHON:-/usr/bin/python}" 
"${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die 
"filter-bash-environment.py failed"
 }
 
@@ -212,6 +213,7 @@ __ebuild_phase() {
 
 __ebuild_phase_with_hooks() {
local x phase_name=${1}
+   ___eapi_vars_export
for x in {pre_,,post_}${phase_name} ; do
__ebuild_phase ${x}
done
@@ -223,6 +225,7 @@ __dyn_pretend() {
__vecho ">>> Remove '$PORTAGE_BUILDDIR/.pretended' to force 
pretend."
return 0
fi
+   ___eapi_vars_export
__ebuild_phase pre_pkg_pretend
__ebuild_phase pkg_pretend
>> "$PORTAGE_BUILDDIR/.pretended" || \
@@ -236,6 +239,7 @@ __dyn_setup() {
__vecho ">>> Remove '$PORTAGE_BUILDDIR/.setuped' to force 
setup."
return 0
fi
+   ___eapi_vars_export
__ebuild_phase pre_pkg_setup
__ebuild_phase pkg_setup
>> "$PORTAGE_BUILDDIR/.setuped" || \
@@ -252,6 +256,7 @@ __dyn_unpack() {
install -m${PORTAGE_WORKDIR_MODE:-0700} -d "${WORKDIR}" || die 
"Failed to create dir '${WORKDIR}'"
fi
cd "${WORKDIR}" || die "Directory change failed: \`cd '${WORKDIR}'\`"
+   ___eapi_vars_export
__ebuild_phase pre_src_unpack
__vecho ">>> Unpacking source..."
__ebuild_phase src_unpack
@@ -386,6 +391,7 @@ __dyn_prepare() {
 
trap __abort_prepare SIGINT SIGQUIT
 
+   ___eapi_vars_export
__ebuild_phase pre_src_prepare
__vecho ">>> Preparing source in $PWD ..."
__ebuild_phase src_prepare
@@ -423,6 +429,7 @@ __dyn_configure() {
 
trap __abort_configure SIGINT SIGQUIT
 
+   ___eapi_vars_export
__ebuild_phase pre_src_configure
 
__vecho ">>> Configuring source in $PWD ..."
@@ -456,6 +463,7 @@ __dyn_compile() {
 
trap __abort_compile SIGINT SIGQUIT
 
+   ___eapi_vars_export
__ebuild_phase pre_src_compile
 
__vecho ">>> Compiling source in $PWD ..."
@@ -500,6 +508,7 @@ __dyn_test() {

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 7:35 PM Alexis Ballier  wrote:
>
> On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote:
> > On Mon, May 25, 2020 at 3:18 PM Michał Górny 
> > wrote:
> > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> > > > On Mon, 25 May 2020 11:26:26 -0400
> > > > Mike Gilbert  wrote:
> > > >
> > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier <
> > > > > aball...@gentoo.org>
> > > > > wrote:
> > > > > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > > > > "Thomas Deutschmann"  wrote:
> > > > > >
> > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > > > > Author: Thomas Deutschmann  gentoo 
> > > > > > > org>
> > > > > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > > > > Commit: Thomas Deutschmann  gentoo 
> > > > > > > org>
> > > > > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > > > > URL:
> > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > > > >
> > > > > > > media-libs/x265: drop USE=pic
> > > > > > >
> > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was
> > > > > > > added,
> > > > > > > we no longer need a USE flag to control that behavior.
> > > > > >
> > > > > > You got it wrong here it seems: USE=pic does not control
> > > > > > whether
> > > > > > the toolchain produces PIC or not. Shared libs always are,
> > > > > > and have
> > > > > > always been, built that way on Gentoo.
> > > > > > In this case, USE=pic means "no matter what it costs, I do
> > > > > > not want
> > > > > > textrels", for the cases of hand written assembly that has to
> > > > > > be
> > > > > > rewritten to support PIC. And, still in this case, this costs
> > > > > > a lot
> > > > > > of performance, so it is enabled by default on hardened
> > > > > > profiles
> > > > > > and not others.
> > > > > > Textrels work fine (on some architectures), they disallow W^X
> > > > > > and
> > > > > > force each process using the shared lib to make a "copy" at
> > > > > > runtime
> > > > > > in order to resolve relocations, so are not desirable but
> > > > > > sometimes
> > > > > > the cost outweights the gain.
> > > > > >
> > > > > > Plus, profiles/features/hardened enables pic by default but
> > > > > > knows
> > > > > > nothing about USE=asm so this is a regression for them.
> > > > >
> > > > > The USE flag toggles use of assembly, not use of PIC. The
> > > > > default USE
> > > > > value in the hardened profile should not drive decisions on
> > > > > what we
> > > > > name USE flags.
> > > >
> > > > ... but using a global well documented useflag instead of a local
> > > > invention should drive such decisions.
> > >
> > > What 'global well documented useflag'?
> >
> > It's neither global, nor well-documented, but several packages do
> > define it locally.
> >
>
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680
>
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba
>
> I guess this hasn't been really discussed back then.
>
> It is also used in a global way in profiles (make.defaults).
>
> > Personally, I think it should be renamed to "asm" or something
> > similar
> > in the majority of cases where it actually disables all use of
> > assembly code.
>
> Thankfully these days there's usually no need to disable asm to have
> pic. hardened has no mention of that flag, and I think that e.g. for
> openssl they would have noticed long ago.
> And again, 'asm' as a useflag makes no sense: if it works and simply
> replaces a C function by a faster one then it shouldn't even be an
> useflag. 'pic' on the other hand conveys the tradeoff idea.

If I understand you correctly, we should just drop the USE="pic" logic
from the remaining packages that have it? Or are you trying to say
something else?



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Alexis Ballier
On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote:
> On Mon, May 25, 2020 at 3:18 PM Michał Górny 
> wrote:
> > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> > > On Mon, 25 May 2020 11:26:26 -0400
> > > Mike Gilbert  wrote:
> > > 
> > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier <
> > > > aball...@gentoo.org>
> > > > wrote:
> > > > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > > > "Thomas Deutschmann"  wrote:
> > > > > 
> > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > > > Author: Thomas Deutschmann  gentoo 
> > > > > > org>
> > > > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > > > Commit: Thomas Deutschmann  gentoo 
> > > > > > org>
> > > > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > > > URL:
> > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > > > 
> > > > > > media-libs/x265: drop USE=pic
> > > > > > 
> > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was
> > > > > > added,
> > > > > > we no longer need a USE flag to control that behavior.
> > > > > 
> > > > > You got it wrong here it seems: USE=pic does not control
> > > > > whether
> > > > > the toolchain produces PIC or not. Shared libs always are,
> > > > > and have
> > > > > always been, built that way on Gentoo.
> > > > > In this case, USE=pic means "no matter what it costs, I do
> > > > > not want
> > > > > textrels", for the cases of hand written assembly that has to
> > > > > be
> > > > > rewritten to support PIC. And, still in this case, this costs
> > > > > a lot
> > > > > of performance, so it is enabled by default on hardened
> > > > > profiles
> > > > > and not others.
> > > > > Textrels work fine (on some architectures), they disallow W^X
> > > > > and
> > > > > force each process using the shared lib to make a "copy" at
> > > > > runtime
> > > > > in order to resolve relocations, so are not desirable but
> > > > > sometimes
> > > > > the cost outweights the gain.
> > > > > 
> > > > > Plus, profiles/features/hardened enables pic by default but
> > > > > knows
> > > > > nothing about USE=asm so this is a regression for them.
> > > > 
> > > > The USE flag toggles use of assembly, not use of PIC. The
> > > > default USE
> > > > value in the hardened profile should not drive decisions on
> > > > what we
> > > > name USE flags.
> > > 
> > > ... but using a global well documented useflag instead of a local
> > > invention should drive such decisions.
> > 
> > What 'global well documented useflag'?
> 
> It's neither global, nor well-documented, but several packages do
> define it locally.
> 

https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680

https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba

I guess this hasn't been really discussed back then.

It is also used in a global way in profiles (make.defaults).

> Personally, I think it should be renamed to "asm" or something
> similar
> in the majority of cases where it actually disables all use of
> assembly code.

Thankfully these days there's usually no need to disable asm to have
pic. hardened has no mention of that flag, and I think that e.g. for
openssl they would have noticed long ago.
And again, 'asm' as a useflag makes no sense: if it works and simply
replaces a C function by a faster one then it shouldn't even be an
useflag. 'pic' on the other hand conveys the tradeoff idea.




Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-25 Thread Philip Webb
200525 Piotr Karbowski wrote:
> There are 3 common ways the xorg-server is started:
 ...
> - via `startx`,

That's how I've always started Xorg.

> if systemd or elogind are present,

I don't use those.

> can work without suid, without them, suid is required.
 ...
> What do you think about turning the current possible opt-out of Xorg as root
> into possible opt-in for running Xorg as root ?
 ...

I'ld rather you didn't.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet




[gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-25 Thread Piotr Karbowski
Hi,

For years the xorg-server in Gentoo was defaulting to be running with
suid, even those that does not really require it, like systemd users and
those who runs elogind still end up with X as uid 0 because of +suid
default.

Times has changed, we now have +elogind in desktop profile, xorg-server
can no longer work without udev (due to input drivers), so there's no
real benefit for defaulting to suid.

There are 3 common ways the xorg-server is started:

- via XDM of some sort, usually forked as root, does not require suid,
systemd or elogind.
- via better XDM that can into logind interface, started as regular user
thanks to logind interface provided by either systemd or elogind.
- via `startx`, if systemd or elogind are present, can work without
suid, without them, suid is required.

Flipping current '+suid (-)elogind' as *default* USE flags on ebuild
level into '+elogind (-)suid' will not affect first two use cases, and
affect only 3rd one if neither systemd is used, or elogind is enabled.

What I'd like to go with is to enable elogind and disable suid on ebuild
level. The systemd profiles have use.mask for elogind, meaning it's not
a problem for them. and those who do not want to use any logind provider
can still opt-out out of it and go back to use suid. It shouldn't really
affect most of the users in any negative way, if anything, it will make
more users to not run Xorg as root, which is a positive aspect.

The alternative way would be to enable elogind on default profile,
however it would also affect those who run headless Gentoo, of which a
lot refuse to use any login manager.

So, dear people of Gentoo, what do you think about turning the current
possible opt-out of Xorg as root into possible opt-in for running Xorg
as root? People still will have a choice, just the defaults will be more
sane.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 3:18 PM Michał Górny  wrote:
>
> On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> > On Mon, 25 May 2020 11:26:26 -0400
> > Mike Gilbert  wrote:
> >
> > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier 
> > > wrote:
> > > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > > "Thomas Deutschmann"  wrote:
> > > >
> > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > > Author: Thomas Deutschmann  gentoo  org>
> > > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > > Commit: Thomas Deutschmann  gentoo  org>
> > > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > > URL:
> > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > >
> > > > > media-libs/x265: drop USE=pic
> > > > >
> > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > > > > we no longer need a USE flag to control that behavior.
> > > >
> > > > You got it wrong here it seems: USE=pic does not control whether
> > > > the toolchain produces PIC or not. Shared libs always are, and have
> > > > always been, built that way on Gentoo.
> > > > In this case, USE=pic means "no matter what it costs, I do not want
> > > > textrels", for the cases of hand written assembly that has to be
> > > > rewritten to support PIC. And, still in this case, this costs a lot
> > > > of performance, so it is enabled by default on hardened profiles
> > > > and not others.
> > > > Textrels work fine (on some architectures), they disallow W^X and
> > > > force each process using the shared lib to make a "copy" at runtime
> > > > in order to resolve relocations, so are not desirable but sometimes
> > > > the cost outweights the gain.
> > > >
> > > > Plus, profiles/features/hardened enables pic by default but knows
> > > > nothing about USE=asm so this is a regression for them.
> > >
> > > The USE flag toggles use of assembly, not use of PIC. The default USE
> > > value in the hardened profile should not drive decisions on what we
> > > name USE flags.
> >
> > ... but using a global well documented useflag instead of a local
> > invention should drive such decisions.
>
> What 'global well documented useflag'?

It's neither global, nor well-documented, but several packages do
define it locally.

profiles % grep ":pic " use.local.desc
app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly
app-benchmarks/ramspeed:pic - Force shared libraries to be built as
PIC (this is slower)
dev-libs/gmp:pic - Force static libraries to be built as PIC to avoid TEXTRELs.
gnome-base/orbit:pic - Force libname-server-2 to be built as PIC;
needed on hardened systems
media-libs/x264:pic - disable optimized assembly code that is not PIC friendly
media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly
media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly
media-video/ffmpeg:pic - Force shared libraries to be built as PIC
(this is slower)
media-video/transcode:pic - disable optimized assembly code that is
not PIC friendly
www-client/chromium:pic - Disable optimized assembly code that is not
PIC friendly

I suspect this flag got copy/pasted between various packages related
to ffmpeg. That's certainly how chromium ended up with it.

Personally, I think it should be renamed to "asm" or something similar
in the majority of cases where it actually disables all use of
assembly code.



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



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Michał Górny
On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> On Mon, 25 May 2020 11:26:26 -0400
> Mike Gilbert  wrote:
> 
> > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier 
> > wrote:
> > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > "Thomas Deutschmann"  wrote:
> > > 
> > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > Author: Thomas Deutschmann  gentoo  org>
> > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > Commit: Thomas Deutschmann  gentoo  org>
> > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > URL:
> > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > 
> > > > media-libs/x265: drop USE=pic
> > > > 
> > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > > > we no longer need a USE flag to control that behavior.
> > > 
> > > You got it wrong here it seems: USE=pic does not control whether
> > > the toolchain produces PIC or not. Shared libs always are, and have
> > > always been, built that way on Gentoo.
> > > In this case, USE=pic means "no matter what it costs, I do not want
> > > textrels", for the cases of hand written assembly that has to be
> > > rewritten to support PIC. And, still in this case, this costs a lot
> > > of performance, so it is enabled by default on hardened profiles
> > > and not others.
> > > Textrels work fine (on some architectures), they disallow W^X and
> > > force each process using the shared lib to make a "copy" at runtime
> > > in order to resolve relocations, so are not desirable but sometimes
> > > the cost outweights the gain.
> > > 
> > > Plus, profiles/features/hardened enables pic by default but knows
> > > nothing about USE=asm so this is a regression for them.
> > 
> > The USE flag toggles use of assembly, not use of PIC. The default USE
> > value in the hardened profile should not drive decisions on what we
> > name USE flags.
> 
> ... but using a global well documented useflag instead of a local
> invention should drive such decisions.

What 'global well documented useflag'?

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Alexis Ballier
On Mon, 25 May 2020 11:26:26 -0400
Mike Gilbert  wrote:

> On Mon, May 25, 2020 at 9:13 AM Alexis Ballier 
> wrote:
> >
> > On Sun, 24 May 2020 20:25:11 + (UTC)
> > "Thomas Deutschmann"  wrote:
> >
> > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > Author: Thomas Deutschmann  gentoo  org>
> > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > Commit: Thomas Deutschmann  gentoo  org>
> > > CommitDate: Sun May 24 20:23:53 2020 +
> > > URL:
> > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > >
> > > media-libs/x265: drop USE=pic
> > >
> > > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > > we no longer need a USE flag to control that behavior.
> >
> >
> > You got it wrong here it seems: USE=pic does not control whether
> > the toolchain produces PIC or not. Shared libs always are, and have
> > always been, built that way on Gentoo.
> > In this case, USE=pic means "no matter what it costs, I do not want
> > textrels", for the cases of hand written assembly that has to be
> > rewritten to support PIC. And, still in this case, this costs a lot
> > of performance, so it is enabled by default on hardened profiles
> > and not others.
> > Textrels work fine (on some architectures), they disallow W^X and
> > force each process using the shared lib to make a "copy" at runtime
> > in order to resolve relocations, so are not desirable but sometimes
> > the cost outweights the gain.
> >
> > Plus, profiles/features/hardened enables pic by default but knows
> > nothing about USE=asm so this is a regression for them.
> 
> The USE flag toggles use of assembly, not use of PIC. The default USE
> value in the hardened profile should not drive decisions on what we
> name USE flags.

... but using a global well documented useflag instead of a local
invention should drive such decisions.

> 
> You can add the flag to package.use or package.use.mask in the
> hardened profile if necessary.


Sure but it was not added there and it's not really relevant here since
 USE=asm does not make any sense either. (aka: this was better
 before this series of commits)



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

2020-05-25 Thread Mike Gilbert
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.



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 9:13 AM Alexis Ballier  wrote:
>
> On Sun, 24 May 2020 20:25:11 + (UTC)
> "Thomas Deutschmann"  wrote:
>
> > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > Author: Thomas Deutschmann  gentoo  org>
> > AuthorDate: Sun May 24 19:47:08 2020 +
> > Commit: Thomas Deutschmann  gentoo  org>
> > CommitDate: Sun May 24 20:23:53 2020 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> >
> > media-libs/x265: drop USE=pic
> >
> > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > we no longer need a USE flag to control that behavior.
>
>
> You got it wrong here it seems: USE=pic does not control whether
> the toolchain produces PIC or not. Shared libs always are, and have
> always been, built that way on Gentoo.
> In this case, USE=pic means "no matter what it costs, I do not want
> textrels", for the cases of hand written assembly that has to be
> rewritten to support PIC. And, still in this case, this costs a lot of
> performance, so it is enabled by default on hardened profiles and not
> others.
> Textrels work fine (on some architectures), they disallow W^X and force
> each process using the shared lib to make a "copy" at runtime in order
> to resolve relocations, so are not desirable but sometimes the cost
> outweights the gain.
>
> Plus, profiles/features/hardened enables pic by default but knows
> nothing about USE=asm so this is a regression for them.

The USE flag toggles use of assembly, not use of PIC. The default USE
value in the hardened profile should not drive decisions on what we
name USE flags.

You can add the flag to package.use or package.use.mask in the
hardened profile if necessary.



[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Alexis Ballier
On Sun, 24 May 2020 20:25:11 + (UTC)
"Thomas Deutschmann"  wrote:

> commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> Author: Thomas Deutschmann  gentoo  org>
> AuthorDate: Sun May 24 19:47:08 2020 +
> Commit: Thomas Deutschmann  gentoo  org>
> CommitDate: Sun May 24 20:23:53 2020 +
> URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> 
> media-libs/x265: drop USE=pic
> 
> Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> we no longer need a USE flag to control that behavior.


You got it wrong here it seems: USE=pic does not control whether
the toolchain produces PIC or not. Shared libs always are, and have
always been, built that way on Gentoo.
In this case, USE=pic means "no matter what it costs, I do not want
textrels", for the cases of hand written assembly that has to be
rewritten to support PIC. And, still in this case, this costs a lot of
performance, so it is enabled by default on hardened profiles and not
others.
Textrels work fine (on some architectures), they disallow W^X and force
each process using the shared lib to make a "copy" at runtime in order
to resolve relocations, so are not desirable but sometimes the cost
outweights the gain.

Plus, profiles/features/hardened enables pic by default but knows
nothing about USE=asm so this is a regression for them.


Alexis.



[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




[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Alexis Ballier
On Sun, 24 May 2020 20:25:11 + (UTC)
"Thomas Deutschmann"  wrote:

> commit: eba596db8a926adb18595549c89294ed0a1e929e
> Author: Thomas Deutschmann  gentoo  org>
> AuthorDate: Sun May 24 15:07:04 2020 +
> Commit: Thomas Deutschmann  gentoo  org>
> CommitDate: Sun May 24 20:23:50 2020 +
> URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eba596db
> 
> media-libs/x265: rework assembly support
> 
> Closes: https://bugs.gentoo.org/681878
> Package-Manager: Portage-2.3.99, Repoman-2.3.22
> Signed-off-by: Thomas Deutschmann  gentoo.org>
> 
>  media-libs/x265/metadata.xml|  1 +
>  media-libs/x265/x265-3.3.ebuild | 66
> - 2 files changed, 34
> insertions(+), 33 deletions(-)
> 
> diff --git a/media-libs/x265/metadata.xml
> b/media-libs/x265/metadata.xml index 22a07293b83..c585d553631 100644
> --- a/media-libs/x265/metadata.xml
> +++ b/media-libs/x265/metadata.xml
> @@ -5,6 +5,7 @@
>  media-vi...@gentoo.org
>
>
> +Enable x86_64 assembly optimizations.



This should not even be an useflag.
Either it works or does not. Individual features support is controlled
by cpu_flags_* (or built-in and autodetected at runtime).
Please fix.



>  Add support for producing 10bits HEVC.
>  Add support for producing 12bits HEVC.
>  Build with support for NUMA nodes.
> 
> diff --git a/media-libs/x265/x265-3.3.ebuild
> b/media-libs/x265/x265-3.3.ebuild index 9fc0159bc00..f5c4fee6d97
> 100644 --- a/media-libs/x265/x265-3.3.ebuild
> +++ b/media-libs/x265/x265-3.3.ebuild
> @@ -19,15 +19,17 @@ HOMEPAGE="http://x265.org/
> https://bitbucket.org/multicoreware/x265/wiki/Home; LICENSE="GPL-2"
>  # subslot = libx265 soname
>  SLOT="0/188"
> -IUSE="+10bit +12bit cpu_flags_arm_neon numa pic power8 test"
> +IUSE="+asm +10bit +12bit cpu_flags_arm_neon numa pic power8 test"
>  
>  # Test suite requires assembly support and is known to be broken
>  RESTRICT="test"
>  
>  ASM_DEPEND=">=dev-lang/yasm-1.2.0"
>  
> -BDEPEND="abi_x86_32? ( ${ASM_DEPEND} )
> - abi_x86_64? ( ${ASM_DEPEND} )"
> +BDEPEND="asm? (
> + abi_x86_32? ( ${ASM_DEPEND} )
> + abi_x86_64? ( ${ASM_DEPEND} )
> + )"
>  
>  RDEPEND="numa? ( >=sys-process/numactl-2.0.10-r1[${MULTILIB_USEDEP}]
> )" 
> @@ -85,17 +87,6 @@ x265_variant_src_configure() {
>   -DENABLE_CLI=OFF
>   -DMAIN12=ON
>   )
> - if [[ ${ABI} = x86 ]] ; then
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = arm ]] ; then
> - # 589674
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = ppc64 ]] ; then
> - #
> https://bugs.gentoo.org/show_bug.cgi?id=607802#c5
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> -DENABLE_ALTIVEC=OFF )
> - fi
>   ;;
>   "main10")
>   mycmakeargs+=(
> @@ -104,17 +95,6 @@ x265_variant_src_configure() {
>   -DENABLE_SHARED=OFF
>   -DENABLE_CLI=OFF
>   )
> - if [[ ${ABI} = x86 ]] ; then
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = arm ]] ; then
> - # 589674
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = ppc64 ]] ; then
> - #
> https://bugs.gentoo.org/show_bug.cgi?id=607802#c5
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> -DENABLE_ALTIVEC=OFF )
> - fi
>   ;;


What are you trying to fix here ?
This sounds like a regression to me: some asm will not work for
10/12bits variants while 8bit is fine. You are removing this work here.



>   "main")
>   if (( "${#MULTIBUILD_VARIANTS[@]}" > 1 )) ;
> then @@ -146,7 +126,6 @@ multilib_src_configure() {
>   append-cxxflags -fPIC
>  
>   local myabicmakeargs=(
> - -DENABLE_TESTS=$(usex test ON OFF)
>   $(multilib_is_native_abi || echo "-DENABLE_CLI=OFF")
>   -DENABLE_LIBNUMA=$(usex numa ON OFF)
>   -DCPU_POWER8=$(usex power8 ON OFF)
> @@ -154,18 +133,39 @@ multilib_src_configure() {
>   -DLIB_INSTALL_DIR="$(get_libdir)"
>   )
>  
> + local supports_asm=yes
> +
>   if [[ ${ABI} = x86 ]] ; then
> - # Bug #528202
> - if use pic ; then
> + if use asm && use pic ; then
> + # Bug #528202
>   ewarn "PIC has been requested but x86 asm is
> not