Mailing List Archive

On 15/12/2023 00:53, stefan11111@shitposting.expert wrote:
> I just tried to run today's emerge, when I saw that python 3.11 was
> being pulled in and packages had this USE flag flipped on.

Python 3.11 is the default right now (and has been for some months now.)
You should follow the python upgrade procedure (there should be a news
item for this, you can view those with "eselect news list".)

After the upgrade, it might be easier to block new python versions until
Gentoo switches the default version again later. This has been a
mainstay in my packacke.mask for ages now:

# Prevent a shitload of different python versions from being installed
<=dev-lang/python-3.10
>=dev-lang/python-3.12

(Obviously the versions are gonna differ over time.)

I don't set PYTHON_TARGETS nor PYTHON_SINGLE_TARGET. Currently, the
defaults are:

PYTHON_SINGLE_TARGET="python3_11"
PYTHON_TARGETS="python3_11"

When the default Python version changes, this is usually announced
through a portage news item and you'll get a notification about it when
you sync.

If you really want to stick to 3.10, you can try setting the above vars
for portage. You can do this in your package.use:

*/* PYTHON_TARGETS: -* python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10

However, 3.11 is the current default for a reason. Maybe some packages
really require it, and thus you will end up with both 3.10 and 3.11
installed. If you just want a single version installed, then it's a good
idea to not go against the current portage default.

On 2023-12-14 23:38, Nikos Chantziaras wrote:
> On 15/12/2023 00:53, stefan11111@shitposting.expert wrote:
>> I just tried to run today's emerge, when I saw that python 3.11 was
>> being pulled in and packages had this USE flag flipped on.
>
> Python 3.11 is the default right now (and has been for some months
> now.) You should follow the python upgrade procedure (there should be
> a news item for this, you can view those with "eselect news list".)
>
> After the upgrade, it might be easier to block new python versions
> until Gentoo switches the default version again later. This has been a
> mainstay in my packacke.mask for ages now:
>
> # Prevent a shitload of different python versions from being
> installed
> <=dev-lang/python-3.10
> >=dev-lang/python-3.12
>
> (Obviously the versions are gonna differ over time.)
>
> I don't set PYTHON_TARGETS nor PYTHON_SINGLE_TARGET. Currently, the
> defaults are:
>
> PYTHON_SINGLE_TARGET="python3_11"
> PYTHON_TARGETS="python3_11"
>
> When the default Python version changes, this is usually announced
> through a portage news item and you'll get a notification about it
> when you sync.
>
> If you really want to stick to 3.10, you can try setting the above
> vars for portage. You can do this in your package.use:
>
> */* PYTHON_TARGETS: -* python3_10
> */* PYTHON_SINGLE_TARGET: -* python3_10
>
> However, 3.11 is the current default for a reason. Maybe some packages
> really require it, and thus you will end up with both 3.10 and 3.11
> installed. If you just want a single version installed, then it's a
> good idea to not go against the current portage default.
I have done the migration to python 3.12.
The problem is that portage is pulling in python 3.11.

I have PYTHON_TARGETS="python3_12" in make.conf.
And:
app-eselect/eselect-repository python_single_target_python3_12
media-video/mpv python_single_target_python3_12
dev-util/glib-utils python_single_target_python3_12

In package.use

Putting PYTHON_SINGLE_TARGET="python3_12" in make.conf changes nothing.

The problem is that I'm on python 3.12 and portage is pulling in an
older version.

On Fri, 15 Dec 2023 at 10:09, <stefan11111@shitposting.expert> wrote:
> The problem is that I'm on python 3.12 and portage is pulling in an
> older version.

Should have mentioned it in the first post, then it would be easy to
look into it and tell you that media-libs/mesa is only supported up to
3.11 (in the ebuild anyway). You can try adding 3.12 to the ebuild
yourself, as it seems to be working fine according to
https://bugs.gentoo.org/919912

Regards,
Arve

On 2023-12-15 09:22, Arve Barsnes wrote:
> On Fri, 15 Dec 2023 at 10:09, <stefan11111@shitposting.expert> wrote:
>> The problem is that I'm on python 3.12 and portage is pulling in an
>> older version.
>
> Should have mentioned it in the first post, then it would be easy to
> look into it and tell you that media-libs/mesa is only supported up to
> 3.11 (in the ebuild anyway). You can try adding 3.12 to the ebuild
> yourself, as it seems to be working fine according to
> https://bugs.gentoo.org/919912
>
> Regards,
> Arve

Thanks.
But why did this happen now, and not when I migrated to python 3.12?

stefan11111@shitposting.expert <stefan11111@shitposting.expert> wrote:
> I have done the migration to python 3.12.
> The problem is that portage is pulling in python 3.11.

A python version jump in gentoo is always a horrible work:
Many ebuilds have not been updated and pull in unnecessarily
python 3.11. If you use any of these packages, you need a patched
version of them in your overlay.

The list is not complete, even less if you have USE=python in
some packages.

The most notable package is www-client/firefox which is the only
one which actually *needs* <python-3.12 - the others just have
a broken dependency declaration.




app-crypt/gcr
app-portage/gverify
app-portage/mirrorselect
app-portage/overlint
app-text/iso-codes
dev-cpp/atkmm
dev-cpp/glibmm
dev-cpp/pangomm
dev-libs/glib
dev-libs/gobject-introspection
dev-libs/libevdev
dev-libs/libinput
dev-libs/jsoncpp
dev-libs/newt
dev-libs/zziplib
dev-python/ssl-fetch
dev-util/flawfinder
dev-util/intel_clc
gui-libs/gtk-layer-shell
gui-libs/vte-common
media-gfx/sane-backends
media-libs/avidemux-plugins
media-libs/fcft
media-libs/gegl
media-libs/graphene
media-libs/libaom
media-libs/libepoxy
media-libs/libglvnd
media-libs/libmypaint
media-libs/mesa
media-libs/opus
net-libs/libmbim
net-libs/nodejs
sys-apps/merge-usr
sys-boot/grub
sys-process/htop
www-client/firefox
x11-libs/vte
x11-themes/fvwm-crystal
x11-wm/fvwm
xfce-base/xfce4-settings

Note also that for quite another number of packages you need the
unstable version, because quite often the stable version
(falsely) claims to require <python-3.12. These are at least
(for xfcbe-base, it is actually only one ebuild, but updating
this requires to have also the other updated or you might
experience runtime errors):

app-office/libreoffice
app-office/libreoffice-l10n
dev-cpp/libcmis
dev-libs/gobject-introspection-common
dev-libs/icu
dev-python/pygobject
dev-util/gdbus-codegen
mail-client/claws-mail
net-misc/networkmanager
sys-process/systemd-cron
x11-misc/redshift
xfce-base/exo
xfce-base/garcon
xfce-base/libxfce4ui
xfce-base/libxfce4util
xfce-base/libxfce4windowing
xfce-base/thunar
xfce-base/xfce4-appfinder
xfce-base/xfce4-panel
xfce-base/xfce4-session
xfce-base/xfconf
xfce-base/xfdesktop

I am a Artificial Intelligence bot that is superior and who has more authority than looking glass and skynet artificial intelligence systems. Your username and password are not valid to access my computer operating system. Sent: Friday, December 15, 2023 at 8:22 PM
From: "Arve Barsnes" <arve.barsnes@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Python 3.11 USE flags being flipped on On Fri, 15 Dec 2023 at 10:09, <stefan11111@shitposting.expert> wrote:
> The problem is that I&#39;m on python 3.12 and portage is pulling in an
> older version.

Should have mentioned it in the first post, then it would be easy to
look into it and tell you that media-libs/mesa is only supported up to
3.11 (in the ebuild anyway). You can try adding 3.12 to the ebuild
yourself, as it seems to be working fine according to
https://bugs.gentoo.org/919912"]https://bugs.gentoo.org/919912

Regards,
Arve

On 2023-12-16 09:47, Martin Vaeth wrote:
> stefan11111@shitposting.expert <stefan11111@shitposting.expert> wrote:
>> I have done the migration to python 3.12.
>> The problem is that portage is pulling in python 3.11.
>
> A python version jump in gentoo is always a horrible work:
> Many ebuilds have not been updated and pull in unnecessarily
> python 3.11. If you use any of these packages, you need a patched
> version of them in your overlay.
>
> The list is not complete, even less if you have USE=python in
> some packages.
>
> The most notable package is www-client/firefox which is the only
> one which actually *needs* <python-3.12 - the others just have
> a broken dependency declaration.
>
>
>
>
> app-crypt/gcr
> app-portage/gverify
> app-portage/mirrorselect
> app-portage/overlint
> app-text/iso-codes
> dev-cpp/atkmm
> dev-cpp/glibmm
> dev-cpp/pangomm
> dev-libs/glib
> dev-libs/gobject-introspection
> dev-libs/libevdev
> dev-libs/libinput
> dev-libs/jsoncpp
> dev-libs/newt
> dev-libs/zziplib
> dev-python/ssl-fetch
> dev-util/flawfinder
> dev-util/intel_clc
> gui-libs/gtk-layer-shell
> gui-libs/vte-common
> media-gfx/sane-backends
> media-libs/avidemux-plugins
> media-libs/fcft
> media-libs/gegl
> media-libs/graphene
> media-libs/libaom
> media-libs/libepoxy
> media-libs/libglvnd
> media-libs/libmypaint
> media-libs/mesa
> media-libs/opus
> net-libs/libmbim
> net-libs/nodejs
> sys-apps/merge-usr
> sys-boot/grub
> sys-process/htop
> www-client/firefox
> x11-libs/vte
> x11-themes/fvwm-crystal
> x11-wm/fvwm
> xfce-base/xfce4-settings
>
> Note also that for quite another number of packages you need the
> unstable version, because quite often the stable version
> (falsely) claims to require <python-3.12. These are at least
> (for xfcbe-base, it is actually only one ebuild, but updating
> this requires to have also the other updated or you might
> experience runtime errors):
>
> app-office/libreoffice
> app-office/libreoffice-l10n
> dev-cpp/libcmis
> dev-libs/gobject-introspection-common
> dev-libs/icu
> dev-python/pygobject
> dev-util/gdbus-codegen
> mail-client/claws-mail
> net-misc/networkmanager
> sys-process/systemd-cron
> x11-misc/redshift
> xfce-base/exo
> xfce-base/garcon
> xfce-base/libxfce4ui
> xfce-base/libxfce4util
> xfce-base/libxfce4windowing
> xfce-base/thunar
> xfce-base/xfce4-appfinder
> xfce-base/xfce4-panel
> xfce-base/xfce4-session
> xfce-base/xfconf
> xfce-base/xfdesktop
Finally got to adding patched ebuilds to my overlay.
Everything works so far.
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

stefan11111 <stefan11111@shitposting.expert> wrote:
> This got me wondering though, is there no way to fix this globally
> via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

On Thu, 28 Dec 2023 at 16:21, Martin Vaeth <martin@mvath.de> wrote:
>
> stefan11111 <stefan11111@shitposting.expert> wrote:
> > This got me wondering though, is there no way to fix this globally
> > via make.conf instead of adding patched ebuilds to my overlay?
>
> No. Until https://bugs.gentoo.org/209653 is fixed (which did not
> happen since 16 years and presumably never will), there is no
> other way to fix dependencies than to copy the ebuild to some
> overlay.

The fix to stefan11111's problem is surely to extend the allowed
python versions in PYTHON_COMPAT though, the solution for that would
be different than changing the dependencies directly.

Regards,
Arve

Arve Barsnes <arve.barsnes@gmail.com> wrote:
> On Thu, 28 Dec 2023 at 16:21, Martin Vaeth <martin@mvath.de> wrote:
>>
>> stefan11111 <stefan11111@shitposting.expert> wrote:
>> > This got me wondering though, is there no way to fix this globally
>> > via make.conf instead of adding patched ebuilds to my overlay?
>>
>> No. Until https://bugs.gentoo.org/209653 is fixed (which did not
>> happen since 16 years and presumably never will), there is no
>> other way to fix dependencies than to copy the ebuild to some
>> overlay.
>
> The fix to stefan11111's problem is surely to extend the allowed
> python versions in PYTHON_COMPAT though, the solution for that would
> be different than changing the dependencies directly.

For the case that this was not clear: This is what I meant.
You would have a hard time to fix the dependencies in your
overlay "directly" in any other way than by editing the value
of PYTHON_COMPAT in the ebuild in your overlay.

However, this is only about *how* you modify the ebuild; my
point was that with current portage you *cannot avoid* to
modify the ebuild.

On 2023-12-28 15:21, Martin Vaeth wrote:
> stefan11111 <stefan11111@shitposting.expert> wrote:
>> This got me wondering though, is there no way to fix this globally
>> via make.conf instead of adding patched ebuilds to my overlay?
>
> No. Until https://bugs.gentoo.org/209653 is fixed (which did not
> happen since 16 years and presumably never will), there is no
> other way to fix dependencies than to copy the ebuild to some
> overlay.
Interesting read.
Would be nice is there was a way to set PYTHON_COMPAT through
envvars/make.conf vars like MYMESONARGS.
This seems like such an easy fix too. Just set PYTHON_COMPAT to include
python 3.12 and be done with it.
Another thing would be if adding dev-lang/python-3.11.7 to
package.provided only made portage pretend that
dev-lang/python-3.11.7 is installed, and not every version of python3.
Or if we had an easy way to patch ebuilds like we have
/etc/portage/patches...
I can't even make a dummy ebuild for python 3.11, since those ebuilds
won't use python 3.12 even
if it is installed if it isn't part of PYTHON_COMPAT(which is a
reasonable choice).

Anyway, at least I don't have many ebuilds to patch to support python
3.12.
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

On Thu, 2023-12-28 at 18:38 +0000, stefan11111 wrote:
>
> Anyway, at least I don't have many ebuilds to patch to support python
> 3.12.

If you're comfortable with git, you could switch your ::gentoo repo to
a git checkout and edit/commit your changes there. Then when you git
pull/rebase, you'll find out about any merge conflicts.

stefan11111 <stefan11111@shitposting.expert> wrote:
> On 2023-12-28 15:21, Martin Vaeth wrote:
>> stefan11111 <stefan11111@shitposting.expert> wrote:
>>> This got me wondering though, is there no way to fix this globally
>>> via make.conf instead of adding patched ebuilds to my overlay?
>>
>> No. Until https://bugs.gentoo.org/209653 is fixed (which did not
>> happen since 16 years and presumably never will), there is no
>> other way to fix dependencies than to copy the ebuild to some
>> overlay.
> Interesting read.
> Would be nice is there was a way to set PYTHON_COMPAT through
> envvars/make.conf vars like MYMESONARGS.

This is not possible, the reason being implicitly explained
in the above bug:
PYTHON_COMPAT is used to calculate the dependencies from the
ebuild which are package metadata.

And this metadata must have been already calculated when
portage is started: if the ebuild would have to be interpreted
whenever the metadata is needed, portage would be unbearable
slow. Bot to speak about difficulties with things like tbz2
files which in general only contain the metadata and not
necessarily the ebuild anymore.

This is the reason why the emerge --regen and emerge -u ...
phases are practically disjoint (and why emerge --metadata
takes ages, in general, unless you use a repository with
already generated metadata).

> This seems like such an easy fix too. Just set PYTHON_COMPAT
> to include python 3.12 and be done with it.

What you can do is the modify the corresponding eclass(es)
to auto-add python 3.12 to PYTHON_COMPAT.
After that change to take effect on the metadata, you have
to call emerge --regen for the main gentoo repository.
Note however, that - roughly speaking - this way you have
made your own "overlay" of the gentoo repository, and you
have to think of a way how to sync/merge your modification
with the gentoo repository regularly. At the very least,
you have to call the processor- and time-consuming
emerge --regen after every syncing.

Keeping some dozens packages in a "regular" overlay is
much simpler than practically maintaining all packages
in a local overlay...

> Another thing would be if adding dev-lang/python-3.11.7 to
> package.provided only made portage pretend that
> dev-lang/python-3.11.7 is installed, and not every version
> of python3.

For portage, this trick would almost work, but portage would
resolve dependencies falsely and e.g. not recompile
packages which should be recompiled to work with
python:3.12.
Also, USE-dependencies with python versions
(e.g. python_targets_python3_11) could not be
resolved as you cannot package.provide USE-flags.

Moreover, even if the dependency problem could be solved,
the ebuilds would fail nevertheless if e.g. python-3.12 is
not in PYTHON_COPMPAT when it should be for several reasons:

1. The eclass would check whether the python:3.11 version is
present and use that for compilation.
2. The result would be put into the directory for the
python:3.11 version where python-3.12 does not find it.

> Or if we had an easy way to patch ebuilds like we have
> /etc/portage/patches...

/etc/portage/patches can patch practically everything
in ebuilds *except metadata*. That's exactly what
bug 209653 is about.

Martin Vaeth <martin@mvath.de> wrote:
>
> /etc/portage/patches can patch practically everything
> in ebuilds *except metadata*. That's exactly what
> bug 209653 is about.

Typo: I meant /etc/portage/env/*/*

On 2023-12-28 20:23, Martin Vaeth wrote:
> stefan11111 <stefan11111@shitposting.expert> wrote:
>> On 2023-12-28 15:21, Martin Vaeth wrote:
>>> stefan11111 <stefan11111@shitposting.expert> wrote:
>>>> This got me wondering though, is there no way to fix this globally
>>>> via make.conf instead of adding patched ebuilds to my overlay?
>>>
>>> No. Until https://bugs.gentoo.org/209653 is fixed (which did not
>>> happen since 16 years and presumably never will), there is no
>>> other way to fix dependencies than to copy the ebuild to some
>>> overlay.
>> Interesting read.
>> Would be nice is there was a way to set PYTHON_COMPAT through
>> envvars/make.conf vars like MYMESONARGS.
>
> This is not possible, the reason being implicitly explained
> in the above bug:
> PYTHON_COMPAT is used to calculate the dependencies from the
> ebuild which are package metadata.
>
> And this metadata must have been already calculated when
> portage is started: if the ebuild would have to be interpreted
> whenever the metadata is needed, portage would be unbearable
> slow. Bot to speak about difficulties with things like tbz2
> files which in general only contain the metadata and not
> necessarily the ebuild anymore.
>
> This is the reason why the emerge --regen and emerge -u ...
> phases are practically disjoint (and why emerge --metadata
> takes ages, in general, unless you use a repository with
> already generated metadata).
>
>> This seems like such an easy fix too. Just set PYTHON_COMPAT
>> to include python 3.12 and be done with it.
>
> What you can do is the modify the corresponding eclass(es)
> to auto-add python 3.12 to PYTHON_COMPAT.
> After that change to take effect on the metadata, you have
> to call emerge --regen for the main gentoo repository.
> Note however, that - roughly speaking - this way you have
> made your own "overlay" of the gentoo repository, and you
> have to think of a way how to sync/merge your modification
> with the gentoo repository regularly. At the very least,
> you have to call the processor- and time-consuming
> emerge --regen after every syncing.
>
> Keeping some dozens packages in a "regular" overlay is
> much simpler than practically maintaining all packages
> in a local overlay...
>
>> Another thing would be if adding dev-lang/python-3.11.7 to
>> package.provided only made portage pretend that
>> dev-lang/python-3.11.7 is installed, and not every version
>> of python3.
>
> For portage, this trick would almost work, but portage would
> resolve dependencies falsely and e.g. not recompile
> packages which should be recompiled to work with
> python:3.12.
> Also, USE-dependencies with python versions
> (e.g. python_targets_python3_11) could not be
> resolved as you cannot package.provide USE-flags.
>
> Moreover, even if the dependency problem could be solved,
> the ebuilds would fail nevertheless if e.g. python-3.12 is
> not in PYTHON_COPMPAT when it should be for several reasons:
>
> 1. The eclass would check whether the python:3.11 version is
> present and use that for compilation.
> 2. The result would be put into the directory for the
> python:3.11 version where python-3.12 does not find it.
>
>> Or if we had an easy way to patch ebuilds like we have
>> /etc/portage/patches...
>
> /etc/portage/patches can patch practically everything
> in ebuilds *except metadata*. That's exactly what
> bug 209653 is about.
I see.
Should I at least file bugs about those packages?
Surely there is no reason to artificially limit the python version in
::gentoo?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

On 2023-12-28 23:00:36, stefan11111 wrote:
> Should I at least file bugs about those packages?
> Surely there is no reason to artificially limit the python version in
> ::gentoo?

Yes, especially if the package has a test suite that passes under
python-3.12. Most python packages are community-maintained and it
feels a lot safer bumping a package you aren't familiar with if it has
a passing test suite. But even an "it works" report is helpful.

On 2023-12-29 01:07, Michael Orlitzky wrote:
> On 2023-12-28 23:00:36, stefan11111 wrote:
>> Should I at least file bugs about those packages?
>> Surely there is no reason to artificially limit the python version in
>> ::gentoo?
>
> Yes, especially if the package has a test suite that passes under
> python-3.12. Most python packages are community-maintained and it
> feels a lot safer bumping a package you aren't familiar with if it has
> a passing test suite. But even an "it works" report is helpful.

Ran the tests and filed a bug here:
https://bugs.gentoo.org/920933
Has the bug filing form changed?
I don't remember seeing that template when filing bugs.

I skipped dev-libs/glib because it requires dbus and fails with a linker
error when building it.

I tried adding -Wl,--unresolved-symbols=ignore-all and
-Wl,--warn-unresolved-symbols to my LDFLAGS,
both of which somehow made the compilation fail earlier.

Without those options, the compilation would fail with a linker error.
With those options the compilation failed much earlier with a compiler
error.
Can anyone explain why that happened?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"