Re: [gentoo-user] "emerge --sync" and "gemato" screwed
On Sat, Nov 14, 2020 at 12:20:16AM -0500, Walter Dnes wrote > = > > And before anyone asks, "emerge -pv1 portage" shows rsync-verify > is disabled... > > = > Calculating dependencies... done! > [ebuild R] sys-apps/portage-3.0.8::gentoo USE="(ipc) native-extensions > xattr -apidoc -build -doc -gentoo-dev -rsync-verify (-selinux) -test" > PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 (-python3_9)" 0 KiB > ===== > > OK, so I emerged gemato, and a whole bunch of its dependencies, but > that doesn't help... It looks like I went about things exactly the wrong way. gemato should not be emerged directly. USE="rsync-verify" emerge -1 portage pulls in gemato and app-crypt/openpgp-keys-gentoo-release-20200704, and other dependencies. This would've prevented the mess about gemato not finding the keys. There's still the problem of the news item https://www.gentoo.org/support/news-items/2018-01-30-portage-rsync-verification.html -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] "emerge --sync" and "gemato" screwed
Walter Dnes wrote:
> Here's tail-end of a recent "emerge --sync" plus an update attempt...
>
> =
> Total bytes sent: 334.55K
> Total bytes received: 51.72M
>
> sent 334.55K bytes received 51.72M bytes 343.63K bytes/sec
> total size is 178.09M speedup is 3.42
> !!! Unable to verify: gemato-14.5+ is required
>
> Action: sync for repo: gentoo, returned code = 127
>
>
> [d531][root][~] emerge -pv --changed-use --deep --update @world
> * Last emerge --sync was 32d 14h 23m 26s ago.
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 KiB
> =
>
> And before anyone asks, "emerge -pv1 portage" shows rsync-verify
> is disabled...
>
> =
> Calculating dependencies... done!
> [ebuild R] sys-apps/portage-3.0.8::gentoo USE="(ipc) native-extensions
> xattr -apidoc -build -doc -gentoo-dev -rsync-verify (-selinux) -test"
> PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 (-python3_9)" 0 KiB
> =
>
> OK, so I emerged gemato, and a whole bunch of its dependencies, but
> that doesn't help...
>
> =
> [d531][root][~] emerge --sync
>>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
> * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> Traceback (most recent call last):
> File
> "/usr/lib/python3.7/site-packages/portage/util/_async/AsyncFunction.py", line
> 39, in _run
> result = self.target(*(self.args or []), **(self.kwargs or {}))
> File "/usr/lib/python3.7/site-packages/portage/sync/controller.py", line
> 165, in sync
> taskmaster.run_tasks(tasks, func, status, options=task_opts)
> File "/usr/lib/python3.7/site-packages/portage/sync/controller.py", line
> 65, in run_tasks
> result = getattr(inst, func)(**kwargs)
> File "/usr/lib/python3.7/site-packages/portage/sync/syncbase.py", line 338,
> in sync
> return self.update()
> File
> "/usr/lib/python3.7/site-packages/portage/sync/modules/rsync/rsync.py", line
> 145, in update
> with io.open(self.repo.sync_openpgp_key_path, 'rb') as f:
> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/share/openpgp-keys/gentoo-release.asc'
>
> Action: sync for repo: gentoo, returned code = 1
> =========.
>
> Now what???
>
Well, I don't even see a gemato 14 in the tree here. This is what I show.
root@fireball / # equery list -p gemato
* Searching for gemato ...
[-P-] [ ] app-portage/gemato-15.2:0
[-P-] [ ~] app-portage/gemato-16.1:0
[IP-] [ ] app-portage/gemato-16.2:0
[-P-] [ -] app-portage/gemato-:0
root@fireball / #
It seems you are a bit behind on that package if I read that correctly.
I'm not sure how to work around it but I'll make this offer if it helps
and nothing else works. I have a binary for it that I can send you off
list. This is the info for the package and USE flags if they match your
needs close enough.
[ebuild R ] app-portage/gemato-16.2::gentoo USE="gpg -test -tools"
PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 (-python3_9)"
I looked and the tarball is only ~102KBs. If you need something else,
I'd be happy to send you whatever you need. My DSL upload is slow but
it gets there, eventually. ;-)
Dale
:-) :-)
[gentoo-user] is a global use flag necessary for python?
Hello all, I just synced my system after a long delay, and I want to emerge firefox. I got this, first, I think, for something called gemato: The following REQUIRED_USE flag constraints are unsatisfied: any-of ( python_targets_python3_10 python_targets_python3_11 python_targets_python3_12 ) Not being sure exactly what was necessary, I put them all into the use file for gemato. Then, I got the same thing for meson, I think. I'm thinking this might go through all the packages. Is there a way to do it globally?
Re: [gentoo-user] Can't upgrade portage or update/install ebuilds
Nikolay Pulev schrieb am 09.06.23 um 21:40: Hi community, This is my first reach out to you. I have not update my machine for a long time and have no reached a point where I can't install or upgrade packages. My first concern is to update portage, however I get the error below error. Does anybody have any suggestions how I could progress with my machine update? # emerge --oneshot sys-apps/portage * IMPORTANT: 15 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. Calculating dependencies... done! !!! All ebuilds that could satisfy ">=app-portage/gemato-14.5[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?]" have been masked. !!! One of the following masked packages is required to complete your request: - app-portage/gemato-::gentoo (masked by: EAPI 8) - app-portage/gemato-20.4::gentoo (masked by: EAPI 8) - app-portage/gemato-20.2::gentoo (masked by: EAPI 8) - app-portage/gemato-20.1::gentoo (masked by: EAPI 8) The current version of portage supports EAPI '7'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-3.0.45.3-r2::gentoo" [ebuild]) (dependency required by "sys-apps/portage" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. If it is only about gemato then temporary disable the rsync-verify flag which pulls it in. # USE="-rsync-verify" emerge sys-apps/portage -- Regards Daniel
[gentoo-user] Can't upgrade portage or update/install ebuilds
Hi community, This is my first reach out to you. I have not update my machine for a long time and have no reached a point where I can't install or upgrade packages. My first concern is to update portage, however I get the error below error. Does anybody have any suggestions how I could progress with my machine update? # emerge --oneshot sys-apps/portage * IMPORTANT: 15 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. Calculating dependencies... done! !!! All ebuilds that could satisfy ">=app-portage/gemato-14.5[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?]" have been masked. !!! One of the following masked packages is required to complete your request: - app-portage/gemato-::gentoo (masked by: EAPI 8) - app-portage/gemato-20.4::gentoo (masked by: EAPI 8) - app-portage/gemato-20.2::gentoo (masked by: EAPI 8) - app-portage/gemato-20.1::gentoo (masked by: EAPI 8) The current version of portage supports EAPI '7'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-3.0.45.3-r2::gentoo" [ebuild]) (dependency required by "sys-apps/portage" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
Re: [gentoo-user] syncing via via git and signature failure
Hi Bill, On Sat, 07 Jul 2018 07:40:00 +0800 Bill Kenworthy wrote: I still have this error and Ive tried a number of things including: gemato create -p ebuild -K /usr/share/openpgp-keys/gentoo-release.asc /usr/portage/ next emerge --sync error-ed on a lot of private manifest files but missing toot manifest error disappeared. Deleted them and successfully resynced. olympus /usr/portage # gemato verify -s -K /usr/share/openpgp-keys/gentoo-release.asc /usr/portage/ INFO:root:Refreshing keys from keyserver... INFO:root:Keys refreshed. ERROR:root:Top-level Manifest /usr/portage/Manifest is not OpenPGP signed olympus /usr/portage # also did a "git reset --hard" still get: olympus /usr/portage # emerge --sync Syncing repository 'gentoo' into '/usr/portage'... /usr/bin/git pull Already up to date. * Using keys from /usr/share/openpgp-keys/gentoo-release.asc * Refreshing keys from keyserver ... [ ok ] * No valid signature found: unable to verify signature (missing key?) q: Updating ebuild cache in /usr/portage ... please be aware of the context of my response to Mick. He use *rsync* and so do I. It seems you are using Git and thus, a different tree verification mechanism. I don't know why you have gemato installed, because it comes usually only with sys-apps/portage[rsync-verify] set and is only related to *rsync* therefore. Have a look at: - [1] <https://www.gentoo.org/glep/glep-0074.html> - [2] <https://www.gentoo.org/support/news-items/2018-01-30-portage-rsync-verification.html> - [3] <https://wiki.gentoo.org/wiki/Portage_Security> for some further information. Maybe: $ git status --untracked-files within your tree location can help to identify and sanitise the tree from any of your (with gemato) created files. -- Regards, floyd
Re: [gentoo-user] Can't upgrade portage or update/install ebuilds
On Fri, 09 Jun 2023 15:40:36 -0400, Nikolay Pulev wrote: > > [1 ] > Hi community, > > This is my first reach out to you. I have not update my machine for a long > time and have no reached a point where I can't install or upgrade packages. > My first concern is to update portage, however I get the error below error. > Does anybody have any suggestions how I could progress with my machine > update? > > # emerge --oneshot sys-apps/portage > > * IMPORTANT: 15 news items need reading for repository 'gentoo'. > * Use eselect news read to view new items. > > Calculating dependencies... done! > > !!! All ebuilds that could satisfy > ">=app-portage/gemato-14.5[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?]" > have been masked. > !!! One of the following masked packages is required to complete your > request: > - app-portage/gemato-::gentoo (masked by: EAPI 8) > - app-portage/gemato-20.4::gentoo (masked by: EAPI 8) > - app-portage/gemato-20.2::gentoo (masked by: EAPI 8) > - app-portage/gemato-20.1::gentoo (masked by: EAPI 8) > > The current version of portage supports EAPI '7'. You must upgrade to a > newer version of portage before EAPI masked packages can be installed. > (dependency required by "sys-apps/portage-3.0.45.3-r2::gentoo" [ebuild]) > (dependency required by "sys-apps/portage" [argument]) > For more information, see the MASKED PACKAGES section in the emerge > man page or refer to the Gentoo Handbook. If it were me, I would either reinstall from scratch, or change your repository to use git and check out old enough versions so you could get one two months after your current version, and update to that, then advance your git by a couple of months and try again and gradually get up to date. Its going to be a real PITA, I am sure, so consider a re install. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] syncing via via git and signature failure
On Wed, 04 Jul 2018 23:25:16 +0100 Mick wrote: Thanks gevisz, the first line to refresh keys fails, because in /var/lib/ gentoo/ I only have a news/ subdirectory. Interestingly, I already have app-crypt/openpgp-keys-gentoo-release installed, but still get 'gpg: Can't check signature: No public key' error when running rsync. For me, using the keys from package: app-crypt/openpgp-keys-gentoo-release-20180703 [1] and running gemato with those: # gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/ solves the issue. Afterwards I was able to update (pulls and install the new version app-crypt/openpgp-keys-gentoo-release-20180703). Hope that helps. References: - [1] <https://dev.gentoo.org/~mgorny/dist/openpgp-keys/gentoo-release.asc.20180703.gz> -- Regards, floyd
Re: [gentoo-user] syncing via via git and signature failure
On 07/07/18 09:42, Floyd Anderson wrote: > Hi Bill, > > On Sat, 07 Jul 2018 07:40:00 +0800 > Bill Kenworthy wrote: >> >> I still have this error and Ive tried a number of things including: >> >> gemato create -p ebuild -K /usr/share/openpgp-keys/gentoo-release.asc >> /usr/portage/ >> >> next emerge --sync error-ed on a lot of private manifest files but >> missing toot manifest error disappeared. Deleted them and successfully >> resynced. >> >> olympus /usr/portage # gemato verify -s -K >> /usr/share/openpgp-keys/gentoo-release.asc /usr/portage/ >> INFO:root:Refreshing keys from keyserver... >> INFO:root:Keys refreshed. >> ERROR:root:Top-level Manifest /usr/portage/Manifest is not OpenPGP >> signed >> olympus /usr/portage # >> >> also did a "git reset --hard" >> >> still get: >> >> olympus /usr/portage # emerge --sync >>>>> Syncing repository 'gentoo' into '/usr/portage'... >> /usr/bin/git pull >> Already up to date. >> * Using keys from /usr/share/openpgp-keys/gentoo-release.asc >> * Refreshing keys from keyserver >> ... >> >> >> [ ok ] >> * No valid signature found: unable to verify signature (missing key?) >> q: Updating ebuild cache in /usr/portage ... > > please be aware of the context of my response to Mick. He use *rsync* > and so do I. It seems you are using Git and thus, a different tree > verification mechanism. I don't know why you have gemato installed, > because it comes usually only with sys-apps/portage[rsync-verify] set > and is only related to *rsync* therefore. > > Have a look at: > > - [1] <https://www.gentoo.org/glep/glep-0074.html> > - [2] > <https://www.gentoo.org/support/news-items/2018-01-30-portage-rsync-verification.html> > - [3] <https://wiki.gentoo.org/wiki/Portage_Security> > > for some further information. Maybe: > > $ git status --untracked-files > > within your tree location can help to identify and sanitise the tree > from any of your (with gemato) created files. > > Brings up all the manifest files so I'll clean them out, resync and see. I do have rsync-verify set but I would not have thought that the problem. The system was converted to git syncing (by deletion and recreating) soon after git became available so it could be something ancient is the cause. None of the docs I have examined seem to cover portage and git problems very well. BillK
Re: [gentoo-user] syncing via via git and signature failure
On Wed, 04 Jul 2018 19:06:29 -0400, Floyd Anderson wrote: > > On Wed, 04 Jul 2018 23:25:16 +0100 > Mick wrote: > > > > Thanks gevisz, the first line to refresh keys fails, because in /var/lib/ > > gentoo/ I only have a news/ subdirectory. > > > > Interestingly, I already have app-crypt/openpgp-keys-gentoo-release > > installed, > > but still get 'gpg: Can't check signature: No public key' error when running > > rsync. > > For me, using the keys from package: > > app-crypt/openpgp-keys-gentoo-release-20180703 [1] > > and running gemato with those: > > # gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/ > > solves the issue. Afterwards I was able to update (pulls and > install the new version > app-crypt/openpgp-keys-gentoo-release-20180703). > > Hope that helps. > > > References: > > - [1] > <https://dev.gentoo.org/~mgorny/dist/openpgp-keys/gentoo-release.asc.20180703.gz> I got the following when running your command: gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/ INFO:root:Refreshing keys from keyserver... INFO:root:Keys refreshed. ERROR:root:Top-level Manifest not found in /usr/portage/ How can I fix, or do I need to fix? Thanks. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
[gentoo-user] Portage update errors
I have a machine with Gentoo, which was installed from scratch 5 months
ago, was updated 3 months ago. Time to look at it again.
emerge --sync
told me that I was strongly advised to update portage.
emerge portage
comes back with lots of errors, see below (the output is slightly
edited for brevity).
There is nothing to mask those packages, for example the word 'certifi'
does not occur in *any* file under /etc/portage at all.
The system is a stock-standard Gentoo with nothing fancy except one
thing: although it is installed as a 64-bit system, it is told to also
install every library in 32-bit mode, because it must be able to run
closed-source 32-bit programs.
As per the "5 config files ..." bit, well, dispatch-conf and etc-update
tell me that they have nothing to do, so I have no idea what 5 files
need updating, to what and how to update them.
I don't really understand how portage works (but I'd be glad if someone
could point me to a single-entity document of its architecture and
internals) so I couldn't even guess what its problem is. And the system
is not *that* old, really.
Any help would be much appreciated,
Thanks,
Zoltan
-
tade ~ # emerge portage 2> /tmp/emsg
* IMPORTANT: 5 config files in '/etc/portage' need updating.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
[ebuild U ] app-crypt/openpgp-keys-gentoo-release-20180706
[20180703] USE="{-test%}"
[ebuild R] dev-python/setuptools-36.7.2
PYTHON_TARGETS="python3_6* -python3_5*"
[ebuild R] dev-python/certifi-2018.4.16
PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)"
[ebuild U *] app-portage/gemato- [13.0-r1]
PYTHON_TARGETS="python3_6* -python3_5* -python3_7%"
[ebuild U *] sys-apps/portage- [2.3.40-r1]
PYTHON_TARGETS="python3_6* -python3_5* -python3_7%"
!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-apps/portage:0
(sys-apps/portage-:0/0::gentoo, ebuild scheduled for merge)
pulled in by sys-apps/portage (Argument)
(sys-apps/portage-2.3.40-r1:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (app-portage/gentoolkit-0.4.2-r1:0/0::gentoo, installed)
sys-apps/portage[python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (dev-java/java-config-2.2.0-r4:2/2::gentoo, installed)
app-portage/gemato:0
(app-portage/gemato-:0/0::gentoo, ebuild scheduled for merge)
pulled in by
>=app-portage/gemato-14[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (sys-apps/portage-:0/0::gentoo, ebuild scheduled for
merge)
(app-portage/gemato-13.0-r1:0/0::gentoo, installed) pulled in by
>=app-portage/gemato-12.1[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]
required by (sys-apps/portage-2.3.40-r1:0/0::gentoo, installed)
dev-python/setuptools:0
(dev-python/setuptools-36.7.2:0/0::gentoo, ebuild scheduled for
merge) pulled in by
>=dev-python/setuptools-34[python_targets_pypy(-)?,python_tar
Re: [gentoo-user] syncing via via git and signature failure
On 06/07/18 00:06, Floyd Anderson wrote: > On Wed, 04 Jul 2018 22:57:05 -0400 > John Covici wrote: >> >> I got the following when running your command: >> gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/ >> INFO:root:Refreshing keys from keyserver... >> INFO:root:Keys refreshed. > > To be more specific, I wasn't interested in verifying the tree. My > main goal was to get: > > INFO:root:Keys refreshed. > > because my sync/update script hung at: > > INFO:root:Refreshing keys from keyserver... > > all the time, caused by: > > gpg: Can't check signature: No public key > > result, so I wasn't able to update. > >> ERROR:root:Top-level Manifest not found in /usr/portage/ >> >> How can I fix, or do I need to fix? > > I've no idea why your portage tree doesn't have a top-level Manifest > file (assuming "/usr/portage" is the location of your tree), but it > should be created/updated on next syncing. > > I still have this error and Ive tried a number of things including: gemato create -p ebuild -K /usr/share/openpgp-keys/gentoo-release.asc /usr/portage/ next emerge --sync error-ed on a lot of private manifest files but missing toot manifest error disappeared. Deleted them and successfully resynced. olympus /usr/portage # gemato verify -s -K /usr/share/openpgp-keys/gentoo-release.asc /usr/portage/ INFO:root:Refreshing keys from keyserver... INFO:root:Keys refreshed. ERROR:root:Top-level Manifest /usr/portage/Manifest is not OpenPGP signed olympus /usr/portage # also did a "git reset --hard" still get: olympus /usr/portage # emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage'... /usr/bin/git pull Already up to date. * Using keys from /usr/share/openpgp-keys/gentoo-release.asc * Refreshing keys from keyserver ... [ ok ] * No valid signature found: unable to verify signature (missing key?) q: Updating ebuild cache in /usr/portage ... BillK
[gentoo-user] "emerge --sync" and "gemato" screwed
Here's tail-end of a recent "emerge --sync" plus an update attempt...
=
Total bytes sent: 334.55K
Total bytes received: 51.72M
sent 334.55K bytes received 51.72M bytes 343.63K bytes/sec
total size is 178.09M speedup is 3.42
!!! Unable to verify: gemato-14.5+ is required
Action: sync for repo: gentoo, returned code = 127
[d531][root][~] emerge -pv --changed-use --deep --update @world
* Last emerge --sync was 32d 14h 23m 26s ago.
These are the packages that would be merged, in order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 KiB
=
And before anyone asks, "emerge -pv1 portage" shows rsync-verify
is disabled...
=
Calculating dependencies... done!
[ebuild R] sys-apps/portage-3.0.8::gentoo USE="(ipc) native-extensions
xattr -apidoc -build -doc -gentoo-dev -rsync-verify (-selinux) -test"
PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 (-python3_9)" 0 KiB
=====
OK, so I emerged gemato, and a whole bunch of its dependencies, but
that doesn't help...
=
[d531][root][~] emerge --sync
>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/portage/util/_async/AsyncFunction.py",
line 39, in _run
result = self.target(*(self.args or []), **(self.kwargs or {}))
File "/usr/lib/python3.7/site-packages/portage/sync/controller.py", line 165,
in sync
taskmaster.run_tasks(tasks, func, status, options=task_opts)
File "/usr/lib/python3.7/site-packages/portage/sync/controller.py", line 65,
in run_tasks
result = getattr(inst, func)(**kwargs)
File "/usr/lib/python3.7/site-packages/portage/sync/syncbase.py", line 338,
in sync
return self.update()
File "/usr/lib/python3.7/site-packages/portage/sync/modules/rsync/rsync.py",
line 145, in update
with io.open(self.repo.sync_openpgp_key_path, 'rb') as f:
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/share/openpgp-keys/gentoo-release.asc'
Action: sync for repo: gentoo, returned code = 1
=.
Now what???
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
[gentoo-user] [SOLVED] "emerge --sync" and "gemato" screwed
It looks like we may have a "documentation bug" on our hands. According to https://www.gentoo.org/support/news-items/2018-01-30-portage-rsync-verification.html > If you wish to disable it, you can disable the 'rsync-verify' USE > flag on sys-apps/portage or set 'sync-rsync-verify-metamanifest = > no' in your repos.conf. This was a fresh install on an old machine. I had "-rsync-verify" in package.use, but 'sync-rsync-verify-metamanifest = yes' in repos.conf. Changing that to "no" allowed the "emerge --rsync" to proceed, and I've now got the update running. I'll wait a few days and try agin. I want to check whether both the USE flag and repos.conf need to be disabled, or whether the USE flag is ignored alltogether. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] emerge --sync: problem refreshing keys
Hello to everyone, since yesterday emerge --sync fails because it can't refresh keys. The messages I get are: Syncing repository 'gentoo' into '/usr/portage'... * Using keys from /usr/share/openpgp-keys/gentoo-release.asc * Refreshing keys via WKD ... [ !! ] * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://keys.gentoo.org gpg: keyserver refresh failed: No keyserver available OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://keys.gentoo.org gpg: keyserver refresh failed: No keyserver available After that, it goes on for a while with the same message. As I have seen no messages regarding this either here or on the forums, I guess there's something wrong on my system, but I can't imagine what's wrong. Two days ago I could sync without problems. Looking at the emerge log, I that that most of the packages I installed were from kde-frameworks and kde-apps, so I don't think they can have caused this issue. Do you have any idea about how to solve this issue? Searching Google, I found several mentions of similar issues, but they were old (about one year ago) and the proposed solution was to install app-portage/gemato-14.0. Of course, all older versions of gemato aren't in portage anymore, so that can't be the issue. Does anyone have any suggestions on how to fix this issue? Thanks in advance Stefano
Re: [gentoo-user] syncing via via git and signature failure
On Wed, 04 Jul 2018 22:57:05 -0400 John Covici wrote: I got the following when running your command: gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/ INFO:root:Refreshing keys from keyserver... INFO:root:Keys refreshed. To be more specific, I wasn't interested in verifying the tree. My main goal was to get: INFO:root:Keys refreshed. because my sync/update script hung at: INFO:root:Refreshing keys from keyserver... all the time, caused by: gpg: Can't check signature: No public key result, so I wasn't able to update. ERROR:root:Top-level Manifest not found in /usr/portage/ How can I fix, or do I need to fix? I've no idea why your portage tree doesn't have a top-level Manifest file (assuming "/usr/portage" is the location of your tree), but it should be created/updated on next syncing. -- Regards, floyd
[gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On 2023-06-09, Daniel Pielmeier wrote: > If it is only about gemato then temporary disable the rsync-verify flag > which pulls it in. > > # USE="-rsync-verify" emerge sys-apps/portage The problem I ran into is that you never know how many issues there are standing in the way of upgrading. The one time I decided to muscle my way through updating an "obsolete" Gentoo install, I spent a very long day fixing "one more problem" and trying again. It took many more hours than a scratch install would have taken, but at some point I decided to keep going just to see if I could make it all the way through the process. I did. Then I promised myself never to try that again. You do learn alot about how portage/emerge works... -- Grant
[gentoo-user] python, my nemesis
Hi, I'd like to update a system that is about 1 year old. I have python3.7 and python 3.8 installed, 3.7 is the default. After updating the repo, it was suggested to update portage first (probably useful to support new EAPI versions). I read about updating to python 3.9, so I created --- ~ # cat /etc/portage/package.use/py */* PYTHON_TARGETS: -* python3_9 python3_8 */* PYTHON_SINGLE_TARGET: -* python3_9 --- as suggested. However, there are still collisions (and I don't really understand them): --- ~ # emerge -p --oneshot sys-apps/portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] acct-group/portage-0 [ebuild N ] acct-user/portage-0 [ebuild U ] sys-devel/automake-1.16.4 [1.16.1-r1] USE="-test%" [ebuild NS] dev-lang/python-3.9.6_p2 [2.7.18-r2, 3.7.8-r2, 3.8.5] USE="sqlite* -verify-sig%" [ebuild U ] dev-python/certifi-10001-r1 [10001] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/setuptools-57.4.0-r2 [46.4.0-r3] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild N ] dev-python/toml-0.10.2 USE="-test" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" [ebuild U ] dev-python/setuptools_scm-6.0.1-r1 [4.1.2-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild N ] dev-python/charset_normalizer-2.0.4 USE="-test" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" [ebuild U ] dev-python/idna-3.2 [2.10-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild R] dev-python/PySocks-1.7.1-r1 PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/urllib3-1.26.6 [1.25.10-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/requests-2.26.0 [2.24.0-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] app-portage/gemato-16.2 [15.2] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] sys-apps/portage-3.0.20-r6 [3.0.4-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-apps/portage:0 (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" pulled in by sys-apps/portage (Argument) (sys-apps/portage-3.0.4-r1-3:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" pulled in by sys-apps/portage[python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-)] required by (app-portage/gentoolkit-0.5.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8" [...] --- Plus many similar ones on packages like setuptools, gemato etc. I don't see how to get out of this vicious circle, any hints? cu Gerrit
Re: [gentoo-user] Portage update errors
On Wed, 21 Nov 2018 20:45:41 +1100, Zoltán Kócsi wrote: > > The Gentoo Handbook and man portage are good starting points. > > I read them, but what I'm missing is the understanding of the database > content that portage maintains and the exact interpretation of the files > and directories in the /etc/portage tree. I.e. the magic behind the > scenes. man portage covers the file in /etc/portage - and elsewhere. > > This would appear to be your problem, you are trying to emerge version > > of portage. Version usually refers to a git version, so not > > usually desirable, especially for a critical system tool. So the first > > step is to find out why portage wants version . > > > > grep -r portage /etc/portage > > > > will tell you if you have set it for installation. Otherwise repeat > > the emerge command with the -t option, which shows what is pulling in > > a particular package. > > Thanks a lot, I will investigate that further. > > By the way, an other (probably dumb) question. At the end of the listing > of the errors there is a complaint about certifi. > > The interesting thing is that the conflict refers to the exact same > piece of code: certifi-2018.4.16:0/0::gentoo is scheduled for merge but > it is already installed. So what's wrong with it? I would sort out the portage- situation first. That depends on gemato- which may need a later version of certifi. Fix the first error message and some of the others may go away at the same time. -- Neil Bothwick Press every key to continue. pgpH2CQave8XV.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > On 2019-07-18 19:42, Stefano Crocco wrote: > > Hello to everyone, > > since yesterday emerge --sync fails because it can't refresh keys. The > > messages I get are: > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > * Refreshing keys via WKD ... [ !! ] > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > keyring > > > > refresh failed: > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > gpg: keyserver refresh failed: No keyserver available > > > > OpenPGP keyring refresh failed: > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > gpg: keyserver refresh failed: No keyserver available > > Perhaps something to do with this? > > https://www.bleepingcomputer.com/news/security/public-certificate-poisoning-> can-break-some-openpgp-implementations/ > > Aside: > I have already switched my personal gpg configuration to use the new > isolated keyserver. Thanks for the answer. I'd heard of this attack and read this [1] article on gentoo.org. From what I understand, it said that in theory there shouldn't be problems when syncing because "The gemato tool used to verify the Gentoo ebuild repository uses WKD by default. During normal operation it should not be affected by this vulnerability". Reading the article again, I now see it also says that "In the worst case; Gentoo repository syncs will be slow or hang" which, as you suggest, could very well be what's happened on my system. Unfortunately, the article doesn't say what to do if this happens. Tomorrow I'll try investigating more. Stefano [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
Re: [gentoo-user] "masked by: EAPI 7" trying up update "portage" - how to proceed
On 2020-06-11 22:01, Rich Freeman wrote: On Thu, Jun 11, 2020 at 3:36 PM n952162 wrote: On 2020-06-11 14:47, Rich Freeman wrote: On Thu, Jun 11, 2020 at 4:10 AM Neil Bothwick wrote: Most likely what you're probably going to end up wanting to try is: USE="python_targets_python3_6 -python_targets_python3_7" emerge -p1v sys-apps/portage (Remove the -p if the output of that looks sane.) That will temporarily adjust the python dependency settings for just that one command. You shouldn't use that USE setting any further after that - this is just to get portage updated once to allow python to be updated in the future - you don't want to stick with 3.6 forever and in a little while you won't even have that option. I tried that: These are the packages that would be merged, in order: Calculating dependencies . ... done! !!! All ebuilds that could satisfy ">=app-crypt/openpgp-keys-gentoo-release-20180706" have been masked. !!! One of the following masked packages is required to complete your request: - app-crypt/openpgp-keys-gentoo-release-20191030::gentoo (masked by: EAPI 7) The current version of portage supports EAPI '6'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-::gentoo[-build,rsync-verify]" [ebuild]) (dependency required by "sys-apps/portage" [argument]) Why are you installing portage- now? This is going to be masked unless you've jumped through some hoops. ??? I didn't specify that! I put it in the config file because emerge told me to. I have no idea what really does. Here's all runs: These are the packages that would be merged, in order: Calculating dependencies ... done! The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by sys-apps/portage (argument) =sys-apps/portage-2.3.100-r1 ~amd64 * In order to avoid wasting time, backtracking has terminated early * due to the above autounmask change(s). The --autounmask-backtrack=y * option can be used to force further backtracking, but there is no * guarantee that it will produce a solution. !!! All ebuilds that could satisfy ">=app-portage/gemato-14[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]" have been masked. !!! One of the following masked packages is required to complete your request: - app-portage/gemato-::gentoo (masked by: EAPI 7) - app-portage/gemato-14.4::gentoo (masked by: EAPI 7) - app-portage/gemato-14.3::gentoo (masked by: EAPI 7) The current version of portage supports EAPI '6'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-2.3.100-r1::gentoo" [ebuild]) (dependency required by "sys-apps/portage" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. * IMPORTANT: 25 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. These are the packages that would be merged, in order: Calculating dependencies .. done! The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by sys-apps/portage (argument) =sys-apps/portage- ** NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. * In order to avoid wasting time, backtracking has terminated early * due to the above autounmask change(s). The --autounmask-backtrack=y * option can be used to force further backtracking, but there is no * guarantee that it will produce a solution. !!! All ebuilds that could satisfy ">=app-crypt/gnupg-2.2.4-r2[ssl(-)]" have been masked. !!! One of the following masked packages is required to complete your request: - app-crypt/gnupg-2.2.20::gentoo (masked by: EAPI 7) - app-crypt/gnupg-2.2.19::gentoo (masked by: EAPI 7) The current version of portage supports EAPI '6'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. (dependency required by "sys-apps/portage-::gentoo[-build,rsync-verify]" [ebuild]) (dependency required by "sys-apps/portage" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. * IMPORTANT: 25 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. These are the packages that would be merged, in order: Calculating dependenc
[gentoo-user] Determine what's keeping Python 3.7 around?
I updated one of my systems a day or two ago, and Python 3.7 went away as expected. Today, I'm updating another system and it is rebuilding tons of stuff to target python 3.8 instead of 3.7, but it's keeping 3.7 and even wants to install a _new_ package -- and build it for Python 3.7: [...] [nomerge ] app-portage/gemato-16.2::gentoo USE="gpg -test -tools" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" [nomerge ] dev-python/requests-2.24.0-r1::gentoo USE="ssl -socks5 -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" [nomerge ] dev-python/cryptography-3.2.1::gentoo [3.2::gentoo] USE="-idna -libressl -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" [ebuild R]dev-python/six-1.15.0-r1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild U ] dev-python/setuptools-50.3.0::gentoo [46.4.0-r3::gentoo] USE="-test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9 (-python2_7%*)" 2,119 KiB [ebuild N ] dev-python/setuptools_scm-4.1.2-r1::gentoo USE="-test" PYTHON_TARGETS="python3_7 python3_8 (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild U ] dev-python/certifi-10001-r1::gentoo [10001::gentoo] USE="-test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9 (-python2_7%*)" 0 KiB [...] Total: 109 packages (12 upgrades, 1 new, 96 reinstalls), Size of downloads: 924,708 KiB How do I figure out why setuptools_scm is being built with the Python 3.7 target? There are no python targets specified in /etc/portage/* -- Grant
Re: [gentoo-user] update fails, but I don't see why
On Fri, 4 Dec 2020 at 09:40, n952162 wrote: > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > dev-python/requests:0 > >(dev-python/requests-2.24.0-r1:0/0::gentoo, ebuild scheduled for > merge) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_6 > python3_7 python3_8 (-pypy3) -python3_9" pulled in by > dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] > required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for > merge) USE="gpg -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7 > python3_8 (-pypy3) -python3_6 -python3_9" > > dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] > required by (dev-python/sphinx-3.2.1:0/0::gentoo, ebuild scheduled for > merge) USE="-doc -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 > python3_8 (-pypy3) -python3_6 -python3_9" > > >(dev-python/requests-2.24.0:0/0::gentoo, installed) USE="ssl -socks5 > -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 > (-pypy3) -python3_8 -python3_9" pulled in by > > >dev-python/requests-2.21.0[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)] > required by (net-misc/streamlink-1.1.1:0/0::gentoo, installed) USE="-doc > -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" > PYTHON_TARGETS="python2_7 python3_6 -python3_5" There seems to be some python3_6 and even python2_7 in your error output, maybe you have set some older python targets somewhere that you've forgotten about? Regards, Arve
Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On 09/06/2023 21:16, Grant Edwards wrote: On 2023-06-09, Daniel Pielmeier wrote: If it is only about gemato then temporary disable the rsync-verify flag which pulls it in. # USE="-rsync-verify" emerge sys-apps/portage The problem I ran into is that you never know how many issues there are standing in the way of upgrading. The one time I decided to muscle my way through updating an "obsolete" Gentoo install, I spent a very long day fixing "one more problem" and trying again. It took many more hours than a scratch install would have taken, but at some point I decided to keep going just to see if I could make it all the way through the process. I did. Then I promised myself never to try that again. You do learn alot about how portage/emerge works... Learning that is a good idea maybe :-) But last time I had a well-out-of-date system, it was a long and messy process ... What I did was, every time portage said "giving up" or "conflict found" or whatever, I just took a note of as many of the packages I could remember that portage said it could emerge, and then manually updated them "emerge --update --one-shot". And any conflicts, if I dared, I simply deleted then "emerge -C --one-shot". And once I managed to get the system to complete an update, I then did a --deep --new-use. The idea is to update the absolute minimum possible to get your system up-to-date, so you probably only want to update @system not @world. If @system is up-to-date, it's not major if you break other stuff. Cheers, Wol
[gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On 2023-06-12, Wol wrote: > On 09/06/2023 21:16, Grant Edwards wrote: >> On 2023-06-09, Daniel Pielmeier wrote: >> >>> If it is only about gemato then temporary disable the rsync-verify flag >>> which pulls it in. >>> >>> # USE="-rsync-verify" emerge sys-apps/portage >> >> The problem I ran into is that you never know how many issues there >> are standing in the way of upgrading. The one time I decided to muscle >> my way through updating an "obsolete" Gentoo install, [...] >> >> You do learn alot about how portage/emerge works... >> > Learning that is a good idea maybe :-) > > But last time I had a well-out-of-date system, it was a long and > messy process ... > > What I did was, every time portage said "giving up" or "conflict found" > or whatever, I just took a note of as many of the packages I could > remember that portage said it could emerge, and then manually updated > them "emerge --update --one-shot". > > And any conflicts, if I dared, I simply deleted then "emerge -C --one-shot". IIRC, at one point Python was one of those problems, and I stupidly removed Python before realizing what that meant... Hilarity ensued. Removing/skipping as many of the non-essential "big" packages and their dependancies and getting the base system updated is indeed the best way to go.
[gentoo-user] Re: google-chrome can render pages after update
On 2023-06-12, Grant Edwards wrote: > I did an update this morning which installed the following: > > aleph ~ # fgrep '>>> emerge ' emerge.log > > 1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to / > 1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to / > 1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to / > 1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to / > 1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to / > 1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to / > 1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to / > 1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to / > 1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to / > 1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 to / > 1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to / > > > Now google-chrome-stable Version 114.0.5735.106 (Official Build) > (64-bit) can lo longer display pages proplerly. It looks like chunks > of the application window are randomly scrambled or shown in the wrong > places. AFIACT, the pages are being parsed/process properly but the > actaul rendering of the X11 window is broken. It seems to be a variation on this bug which affects only AMD GPUs: https://bugs.gentoo.org/907431 Clearing the GPU driver cache or using the -disable-gpu-driver-bug-workarounds option avoids the problem. In my case, It wasn't a mesa update that triggered the problem. I think it was the llvm update (I haven't confirmed that). -- Grant
Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On Tue, Jun 13, 2023 at 10:38 AM Grant Edwards wrote: > On 2023-06-12, Wol wrote: > > On 09/06/2023 21:16, Grant Edwards wrote: > >> On 2023-06-09, Daniel Pielmeier wrote: > >> > >>> If it is only about gemato then temporary disable the rsync-verify flag > >>> which pulls it in. > >>> > >>> # USE="-rsync-verify" emerge sys-apps/portage > >> > >> The problem I ran into is that you never know how many issues there > >> are standing in the way of upgrading. The one time I decided to muscle > >> my way through updating an "obsolete" Gentoo install, [...] > >> > >> You do learn alot about how portage/emerge works... > >> > > Learning that is a good idea maybe :-) > > > > But last time I had a well-out-of-date system, it was a long and > > messy process ... > > > > What I did was, every time portage said "giving up" or "conflict found" > > or whatever, I just took a note of as many of the packages I could > > remember that portage said it could emerge, and then manually updated > > them "emerge --update --one-shot". > > > > And any conflicts, if I dared, I simply deleted then "emerge -C > --one-shot". > > IIRC, at one point Python was one of those problems, and I stupidly > removed Python before realizing what that meant... > > Hilarity ensued. > > Removing/skipping as many of the non-essential "big" packages and > their dependancies and getting the base system updated is indeed the > best way to go. I second this approach. When rescuing a Gentoo system, my first step would be to deselect any and every non-critical package from @world, then try to get @system updated through any means necessary. In the past, I've removed packages instead of deselecting them, but I've had cases where depclean refused to do anything because there were already dependency problems, and sometimes it's hard to know what's safe to unmerge with "-C".
[gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning
Rich Freeman wrote: >> I was speaking about gentoo's git repository, of course >> (the one which was attacked on github), not about a Frankensteined one >> with metadata history filling megabytes of disk space unnecessarily. >> Who has that much disk space to waste? > > Doesn't portage create that metadata anyway when you run it You should better have it created by egencache in portage-postsyncd; and even more you should download some other repositories as well (news announcements, GLSA, dtd, xml-schema) which are maintained independently, see e.g. https://github.com/vaeth/portage-postsyncd-mv It is the Gentoo way: Download only the sources and build it from there. That's also a question of mentality and why I think most gentoo users who use git would prefer that way. > negating any space savings at the cost of CPU to regenerate the cache? It's the *history* of the metadata which matters here: Since every changed metadata file requires a fraction of a second, one can estimate rather well that several ten thousand files are changed hourly/daily/weekly (the frequency depending mainly on eclass changes: One change in some eclass requires a change for practically every version of every package) so that the history of metadata changed produced by this over time is enormous. This history, of course, is completely useless and stored completely in vain. One of the weaknesses of git is that it is impossible, by design, to omit such superfluous history selectively (once the files *are* maintained by git). >> For the official git repository your assertions are simply false, >> as you apprently admit: It is currently not possible to use the >> official git repo (or the github clone of it which was attacked) >> in a secure manner. > > Sure, but this also doesn't support signature verification at all > [...] so your points still don't apply. Hu? This actually *was* my point. BTW, portage might easily support signature verification if just distribution of the developers' public keys would be properly maintained (e.g. via gkeys or simpler via some package): After all, gentoo infra should always have an up-to-date list of these keys anyway. (If they don't, it would make it even more important to use the source repo instead of trusting a signature which is given without sufficient verification) >> Your implicit claim is untrue. rsync - as used by portage - always >> transfers whole files, only. > > rsync is capable of transferring partial files. Yes, and portage is explicitly disabling this. (It costs a lot of server CPU time and does not save much transfer data if the files are small, because a lot of hashes have to be transferred (and calculated - CPU-time!) instead.) > However, this is based on offsets from the start of the file There are new algorithms which support also detection of insertions and deletions via rolling hashes (e.g. for deduplicating filesystems). Rsync is using quite an advanced algorithm as well, but I would need to recheck its features. Anyway, it plays no role for our discussion, because for such small files it hardly matters, and portage is disabling said algorithm anyway. > "The council does not require that ChangeLogs be generated or > distributed through the rsync system. It is at the discretion of our > infrastructure team whether or not this service continues." The formulation already makes it clear that one did not want to put pressure on infra, and at that time it was expected that every user would switch to git anyway. At that time also the gkeys project was very active, and git was (besides webrsync) the only expected way to get checksums for the full tree. In particular, rsync was inherently insecure. The situation has changed meanwhile on both sides: gkeys was apparently practically abandoned, and instead gemato was introduced and is actively supported. That suddenly the gentoo-mirror repository is more secure than the git repository is also a side effect of gemato, because only for this the infra keys are now suddenly distributed in a package. > If you're using squashfs git pull probably isn't the right solution for you. Exactly. That's why I completely disagree with portage's regression of replacing the previously working solution by the only partially working "git pull". >> 4. Even if the user made the mistake to edit a file, portage should >>not just die on syncing. > > emerge --sync won't die in a situation like in general. It does: git push refuses to start if there are uncommitted changes. > but I don't think the correct default in this case should be > to just wipe out the user's changes. I do: Like for rsync a user should not do changes to the distributed tree (unless he makes a PR) but in an overlay; otherwise he will permanently have outdated files which are not correctly updated. *If* a user wants such c
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > Hello to everyone, > > > since yesterday emerge --sync fails because it can't refresh keys. The > > > messages I get are: > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > * Refreshing keys via WKD ... [ !! ] > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > keyring > > > > > > refresh failed: > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > gpg: keyserver refresh failed: No keyserver available > > > > > > OpenPGP keyring refresh failed: > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > gpg: keyserver refresh failed: No keyserver available > > > > Perhaps something to do with this? > > > > https://www.bleepingcomputer.com/news/security/public-certificate-poisonin > > g-> > can-break-some-openpgp-implementations/ > > > Aside: > > I have already switched my personal gpg configuration to use the new > > isolated keyserver. > > Thanks for the answer. I'd heard of this attack and read this [1] article on > gentoo.org. From what I understand, it said that in theory there shouldn't > be problems when syncing because "The gemato tool used to verify the Gentoo > ebuild repository uses WKD by default. During normal operation it should > not be affected by this vulnerability". Reading the article again, I now > see it also says that "In the worst case; Gentoo repository syncs will be > slow or hang" which, as you suggest, could very well be what's happened on > my system. Unfortunately, the article doesn't say what to do if this > happens. > > Tomorrow I'll try investigating more. > > Stefano > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html It seems I found out how to fix the issue. I tried comparing my /usr/share/portage/config/repos.conf with the one which comes with a current stage3 and found out mine had the line sync-openpgp-keyserver = hkps://keys.gentoo.org which was missing in the file from stage3. Removing it (both here and in /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope this is the correct fix. I don't remember ever writing this line, so I suppose it came with the original stage3 I built my system from or was changed by another update (an update of what, however? According to `equery b`, this file doesn't belong to any package). I hope thing will keep working. Stefano
Re: [gentoo-user] Re: google-chrome can render pages after update
On Monday, 12 June 2023 17:05:31 BST Grant Edwards wrote: > On 2023-06-12, Grant Edwards wrote: > > I did an update this morning which installed the following: > > aleph ~ # fgrep '>>> emerge ' emerge.log > > > > 1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to / > > 1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to / > > 1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to / > > 1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to / > > 1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to / > > 1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to / > > 1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to / > > 1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to / > > 1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to / > > 1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 > > to / > > 1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to / > > > > Now google-chrome-stable Version 114.0.5735.106 (Official Build) > > (64-bit) can lo longer display pages proplerly. It looks like chunks > > of the application window are randomly scrambled or shown in the wrong > > places. AFIACT, the pages are being parsed/process properly but the > > actaul rendering of the X11 window is broken. > > It seems to be a variation on this bug which affects only AMD GPUs: > > https://bugs.gentoo.org/907431 > > Clearing the GPU driver cache or using the > -disable-gpu-driver-bug-workarounds option avoids the problem. > > In my case, It wasn't a mesa update that triggered the problem. I > think it was the llvm update (I haven't confirmed that). > > -- > Grant Did you (re)compile anything graphics related using llvm, which might be used by the Chrome binary? I don't have chrome/chromium installed here to directly compare notes and so far qtwebengine appears to work fine after updating llvm this morning, as does www-client/microsoft-edge. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
able, but portage can't upgrade it, so we need to move on to the next step once more. dev-python/pyopenssl:0 (dev-python/pyopenssl-19.1.0-r1:0/0::gentoo, ebuild scheduled for merge) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" pulled in by >=dev-python/pyopenssl-0.14[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/urllib3-1.25.11:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" (dev-python/pyopenssl-19.1.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" pulled in by >=dev-python/pyopenssl-0.14[python_targets_python2_7(-),python_targets_python3_6(-),python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/urllib3-1.25.10:0/0::gentoo, installed) USE="-brotli -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" So here we have the same problem with dev-python/urllib3-1.25.10, there is a newer version available, but portage can't upgrade it, so we need to move on to the next step once more. dev-python/urllib3:0 (dev-python/urllib3-1.25.11:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" pulled in by dev-python/requests-2.21.0[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)] required by (net-misc/streamlink-1.1.1:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_6 -python3_5" dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (app-portage/gemato-16.2:0/0::gentoo, installed) USE="gpg -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" Two packages are holding it back. net-misc/streamlink requires PYTHON_TARGETS="python2_7 python3_6" and app-portage/gemato requires PYTHON_TARGETS="python3_7". gemato is already at the latest version, but on the old python targets, not sure if that means it's been set in /etc/portage/package.use, but net-misc/streamlink is an old version. All its versions seem to be unstable though, and I think you were running a stable system? You might need to manually keyword a newer version (in /etc/portage/package.accept_keywords) to be able to upgrade, or uninstall if this is not a package you need. Hope this can help you read the massive amount of output portage throws at you in these situations. Regards, Arve
Aw: Re: [gentoo-user] slot conflict when updating portage
Oh, I wish I'd use .txt as an extension. Here's one in the raw:
10~>sudo emerge --oneshot portage
Password:
!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:
default/linux/amd64/17.0/desktop
You may use the following command to upgrade:
eselect profile set default/linux/amd64/17.0/desktop
* IMPORTANT: 6 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
* IMPORTANT: 26 config files in '/etc/portage' need updating.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
Calculating dependencies... done!
[ebuild N ] app-crypt/openpgp-keys-gentoo-release-20190427 USE="{-test}"
[ebuild N ] dev-python/bz2file-0.98 PYTHON_TARGETS="python2_7 (-pypy)"
[ebuild U ] dev-libs/libgpg-error-1.29 [1.27-r1]
[ebuild NS] dev-lang/python-3.6.5 [2.7.14-r1, 3.5.4-r1] USE="gdbm ipv6
ncurses readline ssl (threads) xml -build -examples -hardened -libressl -sqlite
{-test} -tk -wininst"
[ebuild U ] dev-python/setuptools-40.6.3 [36.7.2]
PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)"
[ebuild U ] dev-python/certifi-2018.4.16 [2017.4.17]
PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)"
[ebuild U ] app-crypt/gnupg-2.2.10 [2.2.4] USE="ssl%*"
[ebuild N ] app-portage/gemato-14.1 USE="blake2 bzip2 gpg -lzma -sha3
{-test} -tools" PYTHON_TARGETS="python2_7 python3_6 (-pypy) -python3_5
(-python3_7)"
[ebuild U ~] sys-apps/portage-2.3.67 [2.3.13-r1] USE="rsync-verify%*
-gentoo-dev%" PYTHON_TARGETS="python3_6* -python3_5* -python3_7%"
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-apps/portage:0
(sys-apps/portage-2.3.67:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)
(sys-apps/portage-2.3.13-r1:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_python2_7(-),python_targets_python3_5(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]
required by (app-portage/gentoolkit-0.4.0:0/0::gentoo, installed)
dev-python/setuptools:0
(dev-python/setuptools-40.6.3:0/0::gentoo, ebuild scheduled for merge) pulled
in by
dev-python/setuptools[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (app-portage/gemato-14.1:0/0::gentoo, ebuild scheduled for merge)
dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (dev-python/certifi-2018.4.16:0/0::gentoo, ebuild scheduled for
merge)
>=dev-python/setuptools-34[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_pyth
Re: [gentoo-user] Portage update errors
On Wed, 21 Nov 2018 13:52:50 +1100, Zoltán Kócsi wrote:
> I have a machine with Gentoo, which was installed from scratch 5 months
> ago, was updated 3 months ago. Time to look at it again.
>
> emerge --sync
>
> told me that I was strongly advised to update portage.
>
> emerge portage
>
> comes back with lots of errors, see below (the output is slightly
> edited for brevity).
>
> There is nothing to mask those packages, for example the word 'certifi'
> does not occur in *any* file under /etc/portage at all.
>
> As per the "5 config files ..." bit, well, dispatch-conf and etc-update
> tell me that they have nothing to do, so I have no idea what 5 files
> need updating, to what and how to update them.
find /etc/portage -name ._cfg\*
Config files for updating start with ._cfg
> I don't really understand how portage works (but I'd be glad if someone
> could point me to a single-entity document of its architecture and
> internals) so I couldn't even guess what its problem is. And the system
> is not *that* old, really.
The Gentoo Handbook and man portage are good starting points.
> tade ~ # emerge portage 2> /tmp/emsg
>
> * IMPORTANT: 5 config files in '/etc/portage' need updating.
> * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
> * sections of the emerge man page to learn how to update config files.
>
> [ebuild U ] app-crypt/openpgp-keys-gentoo-release-20180706
>[20180703] USE="{-test%}"
>
> [ebuild R] dev-python/setuptools-36.7.2
>PYTHON_TARGETS="python3_6* -python3_5*"
>
> [ebuild R] dev-python/certifi-2018.4.16
> PYTHON_TARGETS="python3_6* -python3_5* (-python3_7)"
>
> [ebuild U *] app-portage/gemato- [13.0-r1]
> PYTHON_TARGETS="python3_6* -python3_5* -python3_7%"
>
> [ebuild U *] sys-apps/portage- [2.3.40-r1]
> PYTHON_TARGETS="python3_6* -python3_5* -python3_7%"
This would appear to be your problem, you are trying to emerge version
of portage. Version usually refers to a git version, so not
usually desirable, especially for a critical system tool. So the first
step is to find out why portage wants version .
grep -r portage /etc/portage
will tell you if you have set it for installation. Otherwise repeat the
emerge command with the -t option, which shows what is pulling in a
particular package.
>
> !!! Multiple package instances within a single package slot have been
> pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> sys-apps/portage:0
>
> (sys-apps/portage-:0/0::gentoo, ebuild scheduled for merge)
> pulled in by sys-apps/portage (Argument)
This implies you have somehow unmasked portage-
--
Neil Bothwick
[ Printed on recycled electrons ]
pgpNtiyHYUZYI.pgp
Description: OpenPGP digital signature
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On 06/06/19 06:00, n952...@web.de wrote: The handbook is great information, but unfortunately, it uses concepts - specific gentoo concepts - that many readers doesn't know. They are then often cross-referenced to other pages, which likewise define things based on expected internal understanding of the mechanisms, goals, and potential scenarios. I have "read" the handbook - multiple times. But not really understood what it was saying - and I have decades of development experience. Consider slots. I'm sure I've read that slots are used to allow multiple ... versions? configurations? of the same package to be installed. It was gradually dawning on me, that it's the developer who specifies the slot. Now, I can't figure out what use case that benefits, but the ability to have slots react to realities at a particular installation see to me to make a lot of sense. So, there must be something basic that I don't understand. I think cases like my simple case would help new comers and I'm hoping to make a blog describing it, once I fully understand the implications. In trying to update portage (before I update my system), I have this: /!!! All ebuilds that could satisfy ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been mas// //!!! One of the following masked packages is required to complete your request:// //- dev-python/setuptools-::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot conflict)// //- dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot conflict)/ Looking at https://packages.gentoo.org/packages/dev-python/setuptools shows that the only two versions stable for am64 are 40.6.3 and 36.7.2. What is *backtracking* and how can I have a *slot conflict *if it's the developers who determine what version sits in a slot? One might say, I have a package already dependent on /setuptools/ and it's not the right one, but how can it be that two different versions want to go into the same slot? Backtracking is something to do with dependency checking. I haven't seen any explanation of what goes on in dependency checking and why backtracking is necessary. Can someone point to an explanation? My emerge output goes on to say: /The current version of portage supports EAPI '6'. You must upgrade to a// //newer version of portage before EAPI masked packages can be installed.// //(dependency required by "app-portage/gemato-::gentoo" [ebuild])// //(dependency required by "sys-apps/portage-2.3.66-r1::gentoo[-build,rsync-verify]" [ebuil// //(dependency required by "portage" [argument])// //For more information, see the MASKED PACKAGES section in the emerge// //man page or refer to the Gentoo Handbook.// / Is this telling me that I have to *first* update my system and *then* update portage?
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > Hello to everyone, > > > > since yesterday emerge --sync fails because it can't refresh keys. The > > > > messages I get are: > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > * Refreshing keys via WKD ... [ !! ] > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > > keyring > > > > > > > > refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > OpenPGP keyring refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > Perhaps something to do with this? > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-poison > > > in > > > g-> > > > > can-break-some-openpgp-implementations/ > > > > > Aside: > > > I have already switched my personal gpg configuration to use the new > > > isolated keyserver. > > > > Thanks for the answer. I'd heard of this attack and read this [1] article > > on gentoo.org. From what I understand, it said that in theory there > > shouldn't be problems when syncing because "The gemato tool used to > > verify the Gentoo ebuild repository uses WKD by default. During normal > > operation it should not be affected by this vulnerability". Reading the > > article again, I now see it also says that "In the worst case; Gentoo > > repository syncs will be slow or hang" which, as you suggest, could very > > well be what's happened on my system. Unfortunately, the article doesn't > > say what to do if this happens. > > > > Tomorrow I'll try investigating more. > > > > Stefano > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > It seems I found out how to fix the issue. I tried comparing my > /usr/share/portage/config/repos.conf with the one which comes with a current > stage3 and found out mine had the line > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > which was missing in the file from stage3. Removing it (both here and in > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope > this is the correct fix. I don't remember ever writing this line, so I > suppose it came with the original stage3 I built my system from or was > changed by another update (an update of what, however? According to `equery > b`, this file doesn't belong to any package). > > I hope thing will keep working. > > Stefano I grepped two older installations I had immediate access to and there is no directive containing "openpgp" anywhere within /etc/portage/. In a new-ish installation there were a number of entries in /etc/portage/ repos.conf/gentoo.conf, but no keyserver URI: $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc sync-openpgp-key-refresh-retry-count = 40 sync-openpgp-key-refresh-retry-overall-timeout = 1200 sync-openpgp-key-refresh-retry-delay-exp-base = 2 sync-openpgp-key-refresh-retry-delay-max = 60 sync-openpgp-key-refresh-retry-delay-mult = 4 Perhaps you had added a keyserver as a fall back when you were configuring your system to use WKD? I haven't implemented WKD because there was no news item advising us to do so. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] update fails, but I don't see why
On 12/4/20 9:53 AM, Arve Barsnes wrote: On Fri, 4 Dec 2020 at 09:40, n952162 wrote: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-python/requests:0 (dev-python/requests-2.24.0-r1:0/0::gentoo, ebuild scheduled for merge) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_6 python3_7 python3_8 (-pypy3) -python3_9" pulled in by dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for merge) USE="gpg -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 (-pypy3) -python3_6 -python3_9" dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/sphinx-3.2.1:0/0::gentoo, ebuild scheduled for merge) USE="-doc -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 (-pypy3) -python3_6 -python3_9" (dev-python/requests-2.24.0:0/0::gentoo, installed) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" pulled in by >dev-python/requests-2.21.0[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)] required by (net-misc/streamlink-1.1.1:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_6 -python3_5" There seems to be some python3_6 and even python2_7 in your error output, maybe you have set some older python targets somewhere that you've forgotten about? Regards, Arve Forgotten about? I'm flattered! That would imply I understood something here ... Here's my python situation: $ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u */* PYTHON_TARGETS: python3_7 >=dev-lang/python-2.7.16:2.7 sqlite >=dev-lang/python-3.6.9 sqlite >=dev-libs/libxml2-2.9.9-r1 python >=dev-python/PySocks-1.7.1 python_targets_python3_6 >=dev-python/certifi-10001-r1 python_targets_python3_7 >=dev-python/certifi-2019.11.28 python_targets_python3_6 >=dev-python/cffi-1.14.0 python_targets_python3_6 >=dev-python/chardet-3.0.4 python_targets_python3_6 >=dev-python/cryptography-2.8-r1 python_targets_python3_6 >=dev-python/docutils-0.16 -python_targets_python2_7 >=dev-python/idna-2.8 python_targets_python3_6 >=dev-python/isodate-0.6.0-r1 python_targets_python3_6 >=dev-python/ply-3.11 python_targets_python3_6 >=dev-python/pycparser-2.20 python_targets_python3_6 >=dev-python/pycryptodome-3.9.4 python_targets_python3_6 >=dev-python/pyopenssl-19.1.0 python_targets_python3_6 >=dev-python/requests-2.23.0 python_targets_python3_6 >=dev-python/setuptools-46.4.0-r1 python_targets_python3_6 >=dev-python/setuptools-50.3.0 python_targets_python3_7 >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6 >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7 >=dev-python/six-1.14.0 python_targets_python3_6 >=dev-python/six-1.15.0-r1 python_targets_python3_7 >=dev-python/urllib3-1.25.8 python_targets_python3_6 >=virtual/python-cffi-0 python_targets_python3_6 dev-lang/python readline net-print/cups X python
Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On Tuesday, 13 June 2023 19:06:33 BST Laurence Perkins wrote: > >From: Mitch D. futurehyp...@gmail.com<mailto:futurehyp...@gmail.com> > >Sent: Tuesday, June 13, 2023 9:36 AM > >To: gentoo-user@lists.gentoo.org<mailto:gentoo-user@lists.gentoo.org> > >Subject: Re: [gentoo-user] Re: Can't upgrade portage or update/install > >ebuilds > >On Tue, Jun 13, 2023 at 10:38 AM Grant Edwards > >grant.b.edwa...@gmail.com<mailto:grant.b.edwa...@gmail.com> wrote: On > >2023-06-12, Wol antli...@youngman.org.uk<mailto:antli...@youngman.org.uk> > >wrote:> > >> On 09/06/2023 21:16, Grant Edwards wrote: > >> > >>> On 2023-06-09, Daniel Pielmeier > >>> bil...@gentoo.org<mailto:bil...@gentoo.org> wrote: >>> > >>> > >>> > >>>> If it is only about gemato then temporary disable the rsync-verify > >>>> flag > >>>> which pulls it in. > >>>> > >>>> > >>>> > >>>> # USE="-rsync-verify" emerge sys-apps/portage > >>> > >>> > >>> > >>> The problem I ran into is that you never know how many issues there > >>> are standing in the way of upgrading. The one time I decided to muscle > >>> my way through updating an "obsolete" Gentoo install, [...] > >>> > >>> > >>> > >>> You do learn alot about how portage/emerge works... > >>> > >>> > >>> > >> Learning that is a good idea maybe :-) > >> > >> > >> > >> But last time I had a well-out-of-date system, it was a long and > >> messy process ... > >> > >> > >> > >> What I did was, every time portage said "giving up" or "conflict found" > >> or whatever, I just took a note of as many of the packages I could > >> remember that portage said it could emerge, and then manually updated > >> them "emerge --update --one-shot". > >> > >> > >> > >> And any conflicts, if I dared, I simply deleted then "emerge -C > >> --one-shot". > > > > >IIRC, at one point Python was one of those problems, and I stupidly > >removed Python before realizing what that meant... > > > >Hilarity ensued. > > > >Removing/skipping as many of the non-essential "big" packages and > >their dependancies and getting the base system updated is indeed the > >best way to go. > > > >I second this approach. When rescuing a Gentoo system, my first step would > >be to deselect any and every non-critical package from @world, then try to > >get @system updated through any means necessary. In the past, I've removed > >packages instead of deselecting them, but I've had cases where depclean > >refused to do anything because there were already dependency problems, and > >sometimes it's hard to know what's safe to unmerge with "-C". > > I have noticed that doing a --unmerge on virtual/* clears away whole > sections of conflicts in a lot of cases. > Doing the same on dev-perl/* is a decent trick too if it's snarled enough > that perl-cleaner runs into conflicts. But sometimes perl dependencies > aren't correctly spelled out, so you may have to reinstall some of it by > hand in some cases. > And you'd be surprised how many “hard” dependency version requirements are > “softer” than expected. Using the "ebuild" tool to force it to "just do > what it's told" and install the new version, and then "emerge -e @world" at > the end of it all to clean up any mess uses a lot of machine time, but it > can save a lot of human time. > LMP I start with the basic toolchain and if this succeeds, I proceed with @system. I never remove packages belonging to the toolchain. If the toolchain Blockers are impossible to resolve, I download a Stage 3, chroot into it with a LiveUSB and build binary packages for the blocked toolchain components. Then it is a matter of copying them over, emerging them and trying again to update/upgrade the toolchain, before I start on @system. If things are seriously broken I tend to reinstall, because in many cases it is a faster route. signature.asc Description: This is a digitally signed message part.
RE: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
>From: Mitch D. futurehyp...@gmail.com<mailto:futurehyp...@gmail.com> >Sent: Tuesday, June 13, 2023 9:36 AM >To: gentoo-user@lists.gentoo.org<mailto:gentoo-user@lists.gentoo.org> >Subject: Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds > >On Tue, Jun 13, 2023 at 10:38 AM Grant Edwards >grant.b.edwa...@gmail.com<mailto:grant.b.edwa...@gmail.com> wrote: >On 2023-06-12, Wol antli...@youngman.org.uk<mailto:antli...@youngman.org.uk> >wrote: >> On 09/06/2023 21:16, Grant Edwards wrote: >>> On 2023-06-09, Daniel Pielmeier bil...@gentoo.org<mailto:bil...@gentoo.org> >>> wrote: >>> >>>> If it is only about gemato then temporary disable the rsync-verify flag >>>> which pulls it in. >>>> >>>> # USE="-rsync-verify" emerge sys-apps/portage >>> >>> The problem I ran into is that you never know how many issues there >>> are standing in the way of upgrading. The one time I decided to muscle >>> my way through updating an "obsolete" Gentoo install, [...] >>> >>> You do learn alot about how portage/emerge works... >>> >> Learning that is a good idea maybe :-) >> >> But last time I had a well-out-of-date system, it was a long and >> messy process ... >> >> What I did was, every time portage said "giving up" or "conflict found" >> or whatever, I just took a note of as many of the packages I could >> remember that portage said it could emerge, and then manually updated >> them "emerge --update --one-shot". >> >> And any conflicts, if I dared, I simply deleted then "emerge -C --one-shot". > >IIRC, at one point Python was one of those problems, and I stupidly >removed Python before realizing what that meant... > >Hilarity ensued. > >Removing/skipping as many of the non-essential "big" packages and >their dependancies and getting the base system updated is indeed the >best way to go. > >I second this approach. When rescuing a Gentoo system, my first step would be >to deselect any and every non-critical package from @world, then try to get >@system updated through any means necessary. In the past, I've removed >packages instead of deselecting them, but I've had cases where depclean >refused to do anything because there were already dependency problems, and >sometimes it's hard to know what's safe to unmerge with "-C". > I have noticed that doing a --unmerge on virtual/* clears away whole sections of conflicts in a lot of cases. Doing the same on dev-perl/* is a decent trick too if it's snarled enough that perl-cleaner runs into conflicts. But sometimes perl dependencies aren't correctly spelled out, so you may have to reinstall some of it by hand in some cases. And you'd be surprised how many “hard” dependency version requirements are “softer” than expected. Using the "ebuild" tool to force it to "just do what it's told" and install the new version, and then "emerge -e @world" at the end of it all to clean up any mess uses a lot of machine time, but it can save a lot of human time. LMP
[gentoo-user] How to recover gentoo keys and verify portage following recent update debacle
My use case may be slightly different to others who use git or webrsync. I've always used rsync to keep portage up to date. Since the portage gentoo keys went out of sync a couple of days ago I ended up like other gentoo users with a 'chicken and egg' situation. The rsync process would fail verification because the public key was not available without app-crypt/openpgp-keys- gentoo-release first being updated to the latest 20180703 version. A poster on another thread has provided advice on using gemato to verify the gentoo keys, but I don't know or understand the process gemato follows to just type incantations on a keyboard and hope for the best. The process I ended up using involved: - removing all stale portage files; - refreshing the gentoo keys manually; - downloading the latest portage snapshot md5sum and its gpg signature; - verifying the snapshot with gpg and using it to install the latest app- crypt/openpgp-keys-gentoo-release. You may find all this too radical for your needs, but I post it here in case others benefit from it. 1. Fetch the gentoo keys on your user keyring: >From Gentoo Release media signatures web page[1] I can see the fingerprint of the Gentoo Portage Snapshot Signing Key is 0xDB6B8C1F96D8BF6D. I assumed here if this key had gone bad then Release Engineering would have replaced it by now. $ gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0xDB6B8C1F96D8BF6D This downloads all keys and signatures. $ gpg --check-signatures 0xDB6B8C1F96D8BF6D The output shows the signature on the keyserver is still valid and has not been revoked. 2. Remove stale portage and download the latest portage snapshot from your local mirror[2]: # cd /usr # rm -Rf portage/* # wget <ftp://your_local_mirror.com>/snapshots/portage-latest.tar.xz* 3. Verify the snapshot was signed by the gentoo keys: $ cd /usr $ gpg --verify portage-latest.tar.xz.gpgsig portage-latest.tar.xz gpg: enabled debug flags: memstat gpg: Signature made Thu Jul 5 01:51:21 2018 BST gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 gpg: using subkey EC590EEAC9189250 instead of primary key DB6B8C1F96D8BF6D gpg: using classic trust model gpg: Good signature from "Gentoo ebuild repository signing key (Automated Signing Key) " [unknown] gpg: aka "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 gpg: binary signature, digest algorithm SHA512, key algorithm rsa4096 gpg: keydb: handles=2 locks=0 parse=0 get=3 gpg:build=0 update=0 insert=0 delete=0 gpg:reset=1 found=3 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=18 cached=18 good=18 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x calls=0 bytes=0 gpg: secmem usage: 0/65536 bytes in 0 blocks OK, the "Good signature" message above and the correct fingerprint is an encouraging indication. Had I selected to trust this key the signature would be shown as trusted. 4. Untar the snapshot into portage/ # tar -xvf portage-latest.tar.xz 5. Install the latest app-crypt/openpgp-keys-gentoo-release-20180703 # emerge -1aDv app-crypt/openpgp-keys-gentoo-release 6. Remove uneeded files: # rm -Rf portage-latest.tar.xz* 7. Sync your portage as usual, in my case: # eix-sync This time the verification process completes without any complains about public keys missing: .. Number of files: 161,932 (reg: 134,484, dir: 27,448) Number of created files: 25 (reg: 24, dir: 1) Number of deleted files: 13 (reg: 13) Number of regular files transferred: 118 Total file size: 218.65M bytes Total transferred file size: 2.67M bytes Literal data: 2.67M bytes Matched data: 0 bytes File list size: 3.41M File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 32.27K Total bytes received: 5.88M sent 32.27K bytes received 5.88M bytes 358.23K bytes/sec total size is 218.65M speedup is 36.99 * Manifest timestamp: 2018-07-05 15:38:30 UTC * Manifest timestamp: 2018-07-05 15:38:30 UTC * Valid OpenPGP signature found: * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D total size is 218.65M speedup is 36.99 * Manifest timestamp: 2018-07-05 15:38:30 UTC * Valid OpenPGP signature found: * Valid OpenPGP signature found: * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 * - timestamp: 2018-07-05 15:38:30 UTC * - timestamp: 2018-07-05 15:38:30 UTC * Verifying /usr/portage ...
Re: [gentoo-user] no ebuilds for telegram
I did an emerge --sync and then "emerge -v1 portage" and it blew up all
over the place. Log in the attachment.
How can I get things reestablished? Or, does gentoo simply require a
smarter user than me, and I should go back to ubuntu?
On 05/14/20 23:36, Rich Freeman wrote:
On Thu, May 14, 2020 at 5:10 PM n952162 wrote:
On 05/14/20 22:46, Rich Freeman wrote:
On Thu, May 14, 2020 at 4:13 PM n952162 wrote:
Action: sync for repo: gentoo, returned code = 0
* An update to portage is available. It is _highly_ recommended
* that you update portage now, before any other packages are updated.
* To update portage, run 'emerge --oneshot portage' now.
...and? Did you update portage as it was _highly_ recommended that
you do so first? What version of portage are you using? This appears
on the top line of emerge --info.
$ emerge --info
Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0,
glibc-2.26-r7, 4.14.65-gentoo x86_64)
That version of portage has been removed from the repo for over a year.
I would update your system so that is current and then try again. I
believe that version of portage should still support EAPI 7 but there
could be some other issue that is giving it problems with more recent
packages in the tree.
These are the packages that would be merged, in order:
Calculating dependencies
* IMPORTANT: 23 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
done!
[ebuild U ] dev-lang/python-exec-2.4.6-r1:2::gentoo [2.4.6:2::gentoo]
PYTHON_TARGETS="(pypy3) (python2_7) (python3_6) (python3_7*) (python3_8%*)
(-jython2_7%*) (-pypy%*) (-python3_4%*) (-python3_5%*)" 86 KiB
[ebuild N ] virtual/libcrypt-1-r1:0/1::gentoo USE="static-libs" 0 KiB
[ebuild N ] dev-perl/TimeDate-2.300.0::gentoo 31 KiB
[ebuild N ] dev-perl/MailTools-2.190.0::gentoo USE="-examples -test" 55
KiB
[ebuild N ] dev-perl/Error-0.170.250::gentoo USE="-test" 32 KiB
[ebuild U ] dev-lang/perl-5.30.1:0/5.30::gentoo [5.24.3-r1:0/5.24::gentoo]
USE="berkdb gdbm -debug -doc -ithreads" 12200 KiB
[ebuild N ] virtual/perl-Digest-SHA-6.20.0::gentoo 0 KiB
[ebuild N ] dev-perl/Digest-HMAC-1.30.0-r1::gentoo 0 KiB
[ebuild N ] dev-perl/Authen-SASL-2.160.0-r1::gentoo USE="-kerberos" 0 KiB
[ebuild NS] dev-lang/python-3.7.7-r2:3.7/3.7m::gentoo [2.7.15:2.7::gentoo,
3.6.5:3.6/3.6m::gentoo] USE="gdbm ipv6 ncurses readline sqlite ssl xml
-bluetooth -build -examples -hardened -libressl -test -tk -wininst" 16879 KiB
[ebuild N ] dev-vcs/git-2.26.2::gentoo USE="blksha1 curl gpg iconv nls
pcre pcre-jit perl threads webdav -cgi -cvs -doc -emacs -gnome-keyring
-highlight -libressl (-mediawiki) (-mediawiki-experimental) -perforce
(-ppcsha1) -subversion -test -tk -xinetd" PYTHON_SINGLE_TARGET="python3_7
-python3_6" 6319 KiB
[ebuild U ] dev-python/setuptools-44.1.0::gentoo [36.7.2::gentoo]
USE="-test" PYTHON_TARGETS="python2_7 python3_7%* (-pypy3) -python3_6*
(-python3_8) (-pypy%) (-python3_4%) (-python3_5%)" 839 KiB
[ebuild U ] dev-python/certifi-2019.11.28::gentoo [2018.4.16::gentoo]
PYTHON_TARGETS="python2_7 python3_7* (-pypy3) -python3_6* (-python3_8) (-pypy%)
(-python3_4%) (-python3_5%)" 153 KiB
[ebuild U ] app-portage/gemato-14.3::gentoo [14.0::gentoo] USE="gpg -test
-tools (-blake2%*) (-bzip2%*) (-lzma%) (-sha3%)" PYTHON_TARGETS="python3_7*
(-pypy3) -python3_6* (-python3_8) (-pypy%) (-python2_7%*) (-python3_4%)
(-python3_5%)" 70 KiB
[ebuild U *] sys-apps/portage-::gentoo [2.3.49::gentoo] USE="(ipc)
native-extensions rsync-verify xattr -apidoc% -binpkg-zstd% -build -doc
-gentoo-dev (-selinux) (-epydoc%)" PYTHON_TARGETS="python3_7* -pypy3%
-python3_6* (-python3_8) (-pypy%) (-python2_7%*) (-python3_4%) (-python3_5%)" 0
KiB
Total: 15 packages (6 upgrades, 8 new, 1 in new slot), Size of downloads: 36659
KiB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-lang/perl:0
(dev-lang/perl-5.24.3-r1:0/5.24::gentoo, installed) pulled in by
dev-lang/perl:0/5.24= required by
(virtual/perl-Scalar-List-Utils-1.420.200_rc-r1:0/0::gentoo, installed)
dev-lang/perl:0/5.24=[-build(-)] required by
(dev-perl/File-DesktopEntry-0.40.0-r1:0/0::gentoo, installed)
dev-lang/perl:0/5.24= required by
(virtual/perl-Data-Dumper-2.160.0-r1:0/0::gentoo, insta
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
recated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:
default/linux/amd64/17.0/desktop
You may use the following command to upgrade:
eselect profile set default/linux/amd64/17.0/desktop
These are the packages that would be merged, in order:
Calculating dependencies . . . ... done!
[ebuild N ] app-crypt/openpgp-keys-gentoo-release-20190427::gentoo
USE="{-test}" 59 KiB
[ebuild N ] dev-python/bz2file-0.98::gentoo PYTHON_TARGETS="python2_7
(-pypy)" 12 KiB
[ebuild U ] dev-libs/libgpg-error-1.29::gentoo [1.27-r1::gentoo] USE="nls
static-libs -common-lisp" ABI_X86="(64) -32 (-x32)" 874 KiB
[ebuild NS] dev-lang/python-3.6.5:3.6/3.6m::gentoo [2.7.14-r1:2.7::gentoo,
3.5.4-r1:3.5/3.5m::gentoo] USE="gdbm ipv6 ncurses readline ssl (threads) xml
-build -examples -hardened -libressl -sqlite {-test} -tk -wininst" 16663 KiB
[ebuild U ] dev-python/setuptools-40.6.3::gentoo [36.7.2::gentoo]
USE="{-test}" PYTHON_TARGETS="python2_7 python3_6* (-pypy) (-pypy3) -python3_5*
(-python3_7) (-python3_4%)" 820 KiB
[ebuild U ] dev-python/certifi-2018.4.16::gentoo [2017.4.17::gentoo]
PYTHON_TARGETS="python2_7 python3_6* (-pypy) (-pypy3) -python3_5* (-python3_7)
(-python3_4%)" 147 KiB
[ebuild U ] app-crypt/gnupg-2.2.10::gentoo [2.2.4::gentoo] USE="bzip2 ldap
nls readline smartcard ssl%* usb -doc (-selinux) -tofu -tools -wks-server
(-gnutls%*)" 6504 KiB
[ebuild N ] app-portage/gemato-14.1::gentoo USE="blake2 bzip2 gpg -lzma
-sha3 {-test} -tools" PYTHON_TARGETS="python2_7 python3_6 (-pypy) -python3_5
(-python3_7)" 70 KiB
[ebuild U ~] sys-apps/portage-2.3.67::gentoo [2.3.13-r1::gentoo] USE="(ipc)
native-extensions rsync-verify%* xattr -build -doc -epydoc -gentoo-dev%
(-selinux)" PYTHON_TARGETS="python2_7 python3_6* -pypy -python3_5* -python3_7%
(-python3_4%)" 1002 KiB
Total: 9 packages (5 upgrades, 3 new, 1 in new slot), Size of downloads: 26147
KiB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-apps/portage:0
(sys-apps/portage-2.3.67:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)
(sys-apps/portage-2.3.13-r1:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_python2_7(-),python_targets_python3_5(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]
required by (app-portage/gentoolkit-0.4.0:0/0::gentoo, installed)
dev-python/setuptools:0
(dev-python/setuptools-40.6.3:0/0::gentoo, ebuild scheduled for merge) pulled
in by
dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (dev-python/certifi-2018.4.16:0/0::gentoo, ebuild scheduled for
merge)
>=dev-python/setuptools-34[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]
required by (app-portage/gemato-14.1:0/0::gentoo, ebuild scheduled for merge)
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On domenica 21 luglio 2019 12:44:14 CEST Mick wrote: > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > > Hello to everyone, > > > > > since yesterday emerge --sync fails because it can't refresh keys. > > > > > The > > > > > messages I get are: > > > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > > * Refreshing keys via WKD ... [ !! ] > > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > > > keyring > > > > > > > > > > refresh failed: > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > OpenPGP keyring refresh failed: > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > Perhaps something to do with this? > > > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-pois > > > > on > > > > in > > > > g-> > > > > > > can-break-some-openpgp-implementations/ > > > > > > > Aside: > > > > I have already switched my personal gpg configuration to use the new > > > > isolated keyserver. > > > > > > Thanks for the answer. I'd heard of this attack and read this [1] > > > article > > > on gentoo.org. From what I understand, it said that in theory there > > > shouldn't be problems when syncing because "The gemato tool used to > > > verify the Gentoo ebuild repository uses WKD by default. During normal > > > operation it should not be affected by this vulnerability". Reading the > > > article again, I now see it also says that "In the worst case; Gentoo > > > repository syncs will be slow or hang" which, as you suggest, could very > > > well be what's happened on my system. Unfortunately, the article doesn't > > > say what to do if this happens. > > > > > > Tomorrow I'll try investigating more. > > > > > > Stefano > > > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > > > It seems I found out how to fix the issue. I tried comparing my > > /usr/share/portage/config/repos.conf with the one which comes with a > > current stage3 and found out mine had the line > > > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > > > which was missing in the file from stage3. Removing it (both here and in > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope > > this is the correct fix. I don't remember ever writing this line, so I > > suppose it came with the original stage3 I built my system from or was > > changed by another update (an update of what, however? According to > > `equery > > b`, this file doesn't belong to any package). > > > > I hope thing will keep working. > > > > Stefano > > I grepped two older installations I had immediate access to and there is no > directive containing "openpgp" anywhere within /etc/portage/. > > In a new-ish installation there were a number of entries in /etc/portage/ > repos.conf/gentoo.conf, but no keyserver URI: > > $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc > sync-openpgp-key-refresh-retry-count = 40 > sync-openpgp-key-refresh-retry-overall-timeout = 1200 > sync-openpgp-key-refresh-retry-delay-exp-base = 2 > sync-openpgp-key-refresh-retry-delay-max = 60 > sync-openpgp-key-refresh-retry-delay-mult = 4 > > Perhaps you had added a keyserver as a fall back when you were configuring > your system to use WKD? I haven't implemented WKD because there was no news > item advising us to do so. Maybe. I really know nothing about these issues, so I'm sure I wouldn't have added that line by myself. Maybe I read about them somewhere and I forgot about it. Stefano
Re: [gentoo-user] no ebuilds for telegram
On 5/16/20 12:23 PM, n952162 wrote: Oh oh oh! Are you saying ... given "..." in this: Synopsis: emerge [options] [action] [ebuild | tbz2file | file | @set | atom] ... that the solution to my problems is to - for each conflict - to select one of the two and put it on the same command line? e.g: sudo emerge -av =sys-apps/portage-2.3.89-r3 =app-portage/gemato-14.3 =dev-python/setuptools-44.1.0 dev-python/certifi-2019.11.28 Maybe. The issue is to first understand (for each slot conflict) what is pulling in each of the conflicting versions. The newer version is probably being pulled in as the default (highest version not flagged or masked or ...). The older version is likely being pulled in by an older version of some other package. Rather than specifying specific version, just include the other package also. The basic idea is to upgrade as few packages at a time as possible - but you can't do just one because of these conflicts. So starting with "emerge -1 portage" and seeing the older version of portage is being pulled in by gentookit, just "emerge -1 portage gentoolkit". You may have to go through many iterations to find a set of packages which will cleanly upgrade together. On 05/16/20 18:16, Jack wrote: On 2020.05.16 11:56, n952162 wrote: Okay, I'm blocked here, at the very beginning: sys-apps/portage:0 (sys-apps/portage-*2.3.89-r3:0*/0::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/portage-2.3.89-r3 (Argument) (sys-apps/portage-*2.3.49:0/0*::gentoo, installed) pulled in by sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (app-portage/gentoolkit-0.4.2-r1:0/0::gentoo, installed) I'm trying to update from 2.3.49 to 2.3.89 and it tells me it has a slot conflict there. I can hardly delete portage and then add it ... First, if you post a slot conflict, post the whole thing. (This one is OK, but your previous one for gentoolkit only showed one of the two entries. In this case, you probably need to upgrade gentoolkit and portage at the same time. On 05/16/20 17:38, n952162 wrote: e.g. sudo emerge -av =*sys-apps/portage-2.3.89-r3 <https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/portage/portage-2.3.89-r3.ebuild>* ? I got (amongst tons of other stuff): * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (app-portage/gentoolkit-0.4.2-r1:0/0::gentoo, installed) pulled in by app-portage/gentoolkit required by @selected On 05/16/20 16:19, Jack wrote: On 5/16/20 8:53 AM, n952162 wrote: I did an emerge --sync and then "emerge -v1 portage" and it blew up all over the place. Log in the attachment. How can I get things reestablished? Or, does gentoo simply require a smarter user than me, and I should go back to ubuntu? I think the bottom line is that Gentoo needs to be updated more often than yearly. Others may also comment, but right now, I think a reinstall might be easier than working through all the problems, unless you are trying to learn more about how things work. My first question is why you have portage- unmasked? I suggest going for the lowest version currently in the tree. I'm not sure if your first step should really be portage itself, or upgrading packages where the installed version is now masked due to security errors or being too out of date. Jack On 05/14/20 23:36, Rich Freeman wrote: On Thu, May 14, 2020 at 5:10 PM n952162 wrote: On 05/14/20 22:46, Rich Freeman wrote: On Thu, May 14, 2020 at 4:13 PM n952162 wrote: Action: sync for repo: gentoo, returned code = 0 * An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * To update portage, run 'emerge --oneshot portage' now. ...and? Did you update portage as it was _highly_ recommended that you do so first? What version of portage are you using? This appears on the top line of emerge --info. $ emerge --info Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0, glibc-2.26-r7, 4.14.65-gentoo x86_64) That version of portage has been removed from the repo for over a year. I would update your system so that is current and then try again. I believe that version of portage should still support EAPI 7 but there could be some other issue that is giving it problems with more recent packages in the tree.
Re: [gentoo-user] no ebuilds for telegram
Oh oh oh! Are you saying ... given "..." in this: Synopsis: emerge [options] [action] [ebuild | tbz2file | file | @set | atom] ... that the solution to my problems is to - for each conflict - to select one of the two and put it on the same command line? e.g: sudo emerge -av =sys-apps/portage-2.3.89-r3 =app-portage/gemato-14.3 =dev-python/setuptools-44.1.0 dev-python/certifi-2019.11.28 On 05/16/20 18:16, Jack wrote: On 2020.05.16 11:56, n952162 wrote: Okay, I'm blocked here, at the very beginning: sys-apps/portage:0 (sys-apps/portage-*2.3.89-r3:0*/0::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/portage-2.3.89-r3 (Argument) (sys-apps/portage-*2.3.49:0/0*::gentoo, installed) pulled in by sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (app-portage/gentoolkit-0.4.2-r1:0/0::gentoo, installed) I'm trying to update from 2.3.49 to 2.3.89 and it tells me it has a slot conflict there. I can hardly delete portage and then add it ... First, if you post a slot conflict, post the whole thing. (This one is OK, but your previous one for gentoolkit only showed one of the two entries. In this case, you probably need to upgrade gentoolkit and portage at the same time. On 05/16/20 17:38, n952162 wrote: e.g. sudo emerge -av =*sys-apps/portage-2.3.89-r3 <https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/portage/portage-2.3.89-r3.ebuild>* ? I got (amongst tons of other stuff): * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (app-portage/gentoolkit-0.4.2-r1:0/0::gentoo, installed) pulled in by app-portage/gentoolkit required by @selected On 05/16/20 16:19, Jack wrote: On 5/16/20 8:53 AM, n952162 wrote: I did an emerge --sync and then "emerge -v1 portage" and it blew up all over the place. Log in the attachment. How can I get things reestablished? Or, does gentoo simply require a smarter user than me, and I should go back to ubuntu? I think the bottom line is that Gentoo needs to be updated more often than yearly. Others may also comment, but right now, I think a reinstall might be easier than working through all the problems, unless you are trying to learn more about how things work. My first question is why you have portage- unmasked? I suggest going for the lowest version currently in the tree. I'm not sure if your first step should really be portage itself, or upgrading packages where the installed version is now masked due to security errors or being too out of date. Jack On 05/14/20 23:36, Rich Freeman wrote: On Thu, May 14, 2020 at 5:10 PM n952162 wrote: On 05/14/20 22:46, Rich Freeman wrote: On Thu, May 14, 2020 at 4:13 PM n952162 wrote: Action: sync for repo: gentoo, returned code = 0 * An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * To update portage, run 'emerge --oneshot portage' now. ...and? Did you update portage as it was _highly_ recommended that you do so first? What version of portage are you using? This appears on the top line of emerge --info. $ emerge --info Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0, glibc-2.26-r7, 4.14.65-gentoo x86_64) That version of portage has been removed from the repo for over a year. I would update your system so that is current and then try again. I believe that version of portage should still support EAPI 7 but there could be some other issue that is giving it problems with more recent packages in the tree.
Re: [gentoo-user] Going through these one by one.
On Sat, 13 Feb 2021 20:59:08 -0800
cal wrote:
> Did you run emerge --sync before emerge -1vUD @world?
A cron job here runs "emerge --sync && emerge --update --fetchonly"
every day at 0300.
> The Python 3.7 change is old news -- by now it's already migrated to
> 3.8 on my system.
This system has been fried ever since
2020-04-22-python3-7
Title Python 3.7 to become the default target
AuthorMichał Górny
Posted2020-04-22
Revision 1
On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one
of the default Python targets for Gentoo systems. The new default
values will be:
Followed those instructions -- don't use python for anything here
and the local copies of what I actually use are in /opt/perl,
/opt/postgresql, etc, built from git checkouts.
At this point I've added and removed python single and multiple
target entries from make.conf & package.use/local, with various
sets of values and exclusions.
A bare sync tells me there is a new version of portage available,
installing it fails, however with:
# emerge --sync;
Action: sync for repo: gentoo, returned code = 0
* An update to portage is available. It is _highly_ recommended
* that you update portage now, before any other packages are updated.
* To update portage, run 'emerge --oneshot sys-apps/portage' now.
# emerge --oneshot sys-apps/portage 2>&1 | tee a;
Calculating dependencies ... done!
[ebuild N ] dev-lang/python-exec-conf-2.4.6 PYTHON_TARGETS="python3_8
-pypy3 -python3_7 -python3_9"
[ebuild N ] acct-group/portage-0
[ebuild U ] dev-lang/python-exec-2.4.6-r4 [2.4.6-r1]
USE="native-symlinks%*" PYTHON_TARGETS="(python3_8%*) (python3_9%*)"
[ebuild N ] acct-user/portage-0
[ebuild U ] dev-python/certifi-10001-r1 [10001]
PYTHON_TARGETS="python3_8*"
[ebuild U ~] dev-python/setuptools-53.0.0 [44.0.0]
PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ~] dev-python/setuptools_scm-5.0.1 [4.1.2]
PYTHON_TARGETS="python3_8*"
[ebuild U ] dev-python/chardet-4.0.0 [3.0.4]
PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ] dev-python/idna-2.10-r1 [2.8] PYTHON_TARGETS="python3_8*
-python3_9%"
[ebuild U ] dev-python/PySocks-1.7.1-r1 [1.6.8]
PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ~] dev-python/urllib3-1.26.3-r1 [1.24.2] USE="-brotli%"
PYTHON_TARGETS="python3_8%* -python3_9%"
[ebuild U ] dev-python/requests-2.25.1-r1 [2.21.0-r1] USE="-test%"
PYTHON_TARGETS="python3_8%* -python3_9%"
[ebuild U ~] app-crypt/gnupg-2.2.27 [2.2.20] USE="-scd-shared-access%"
[ebuild U ] app-portage/gemato-16.2 [14.3] PYTHON_TARGETS="python3_8*
-python3_7* -python3_9%"
[ebuild U ~] sys-apps/portage-3.0.14 [3.0.1] USE="-test%"
PYTHON_TARGETS="python3_8* -python3_7*"
[blocks B ] <=dev-lang/python-2.7.18-r3:2.7
("<=dev-lang/python-2.7.18-r3:2.7" is blocking dev-lang/python-exec-2.4.6-r4)
[blocks B ] =dev-lang/python-exec-2:=[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/chardet-4.0.0:0/0::gentoo, ebuild scheduled for merge)
USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7
-python3_9"
>=dev-lang/python-exec-2:=[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/setuptools-53.0.0:0/0::gentoo, ebuild scheduled for
merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 -pypy3
-python3_9"
Full output at:
<https://pastebin.com/mEJg3N7N>
Q: Is there any way to clean up python at this point without
a full re-install?
thanks
--
Steven Lembark
Workhorse Computing
lemb...@wrkhors.com
+1 888 359 3508
[gentoo-user] google-chrome can render pages after update
I did an update this morning which installed the following:
aleph ~ # fgrep '>>> emerge ' emerge.log
1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to /
1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to /
1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to /
1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to /
1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to /
1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to /
1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to /
1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to /
1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to /
1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 to /
1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to /
Now google-chrome-stable Version 114.0.5735.106 (Official Build)
(64-bit) can lo longer display pages proplerly. It looks like chunks
of the application window are randomly scrambled or shown in the wrong
places. AFIACT, the pages are being parsed/process properly but the
actaul rendering of the X11 window is broken.
You can see examples here:
https://www.panix.com/~grante/chrome/foo.png
https://www.panix.com/~grante/chrome/bar.png
None of the other "big" X11 apps seem to be affected (firefox,
thunderbird, libre-office, etc. all work fine).
The console window where I launch chrome now spews almost continuous
errors like those show below. Has anybody else run into this? I'm
going to start backing out the updates above, but thought I'd check to
see if this was a known problem. I haven't found anything in buzilla
yet...
Errors:
link failed but did not provide an info log
[7110:7110:0612/103618.780116:ERROR:shared_context_state.cc(81)] Skia
shader compilation error
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;uniform float2 uAtlasSizeInv_S0;in float2
inPosition;in half4 inColor;in ushort2 inTextureCoords;noperspective out float2
vTextureCoords_S0;flat out float vTexIndex_S0;noperspective out half4
vinColor_S0;void main() {// Primitive Processor BitmapText
int texIdx = 0;float2 unormTexCoords = float2(inTextureCoords.x,
inTextureCoords.y);vTextureCoords_S0 = unormTexCoords *
uAtlasSizeInv_S0;vTexIndex_S0 = float(texIdx);vinColor_S0 = inColor;float2
_tmp_1_inPosition = inPosition;sk_Position = inPosition.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
const int kFillBW_S1_c0 = 0;
const int kInverseFillBW_S1_c0 = 2;
const int kInverseFillAA_S1_c0 = 3;
uniform float4 urectUniform_S1_c0;uniform sampler2D uTextureSampler_0_S0;
noperspective in float2 vTextureCoords_S0;flat in float
vTexIndex_S0;noperspective in half4 vinColor_S0;half4 Rect_S1_c0(half4 _input) {
half4 _tmp_0_inColor = _input;
half coverage;
if (int(2) == kFillBW_S1_c0 || int(2) == kInverseFillBW_S1_c0) {
coverage = half(all(greaterThan(float4(sk_FragCoord.xy,
urectUniform_S1_c0.zw), float4(urectUniform_S1_c0.xy, sk_FragCoord.xy;
} else {
half4 dists4 = saturate(half4(1.0, 1.0, -1.0, -1.0) *
half4(sk_FragCoord.xyxy - urectUniform_S1_c0));
half2 dists2 = (dists4.xy + dists4.zw) - 1.0;
coverage = dists2.x * dists2.y;
}
if (int(2) == kInverseFillBW_S1_c0 || int(2) == kInverseFillAA_S1_c0) {
coverage = 1.0 - coverage;
}
return half4(half4(coverage));
}
half4 Blend_S1(half4 _src, half4 _dst) {
return blend_modulate(Rect_S1_c0(_src), _src);}
void main() {// Stage 0, BitmapText
half4 outputColor_S0;outputColor_S0 = vinColor_S0;half4 texColor;{ texColor
= sample(uTextureSampler_0_S0, vTextureCoords_S0).; }half4
outputCoverage_S0 = texColor;half4 output_S1;output_S1 =
Blend_S1(outputCoverage_S0, half4(1));{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * output_S1;}}
// Vertex GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
uniform highp vec2 uAtlasSizeInv_S0;
in highp vec2 inPosition;
in mediump vec4 inColor;
in mediump uvec2 inTextureCoords;
noperspective out highp vec2 vTextureCoords_S0;
flat out highp float vTexIndex_S0;
noperspective out mediump vec4 vinColor_S0;
void main() {
highp int texIdx = 0;
highp vec2 unormTexCoords = vec2(float(inTextureCoords.x),
float(inTextureCoords.y));
vTextureCoords_S0 = unormTexCoords * uAtlasSizeInv_S0;
vTexIndex_S0 = float(texIdx);
vinColor_S0 = inColor;
gl_Position = vec4(inPosition, 0.0, 1
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On Mon, Jun 10, 2019 at 5:39 PM n952162 wrote: > > On 06/06/19 06:00, n952...@web.de wrote: > > In trying to update portage (before I update my system), I have this: > > !!! All ebuilds that could satisfy > ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" > have been mas > !!! One of the following masked packages is required to complete your request: > - dev-python/setuptools-::gentoo (masked by: EAPI 7) > - dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7) > - dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot > conflict) > - dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot > conflict) > > Looking at https://packages.gentoo.org/packages/dev-python/setuptools shows > that the only two versions stable for am64 are 40.6.3 and 36.7.2. > > What is backtracking and how can I have a slot conflict if it's the > developers who determine what version sits in a slot? Backtracking refers to how the dependency resolver works - it couldn't figure out a way to satisfy your requirements. You have a slot conflict because two different packages that you asked for require two different versions of setuptools to be installed at the same time in the same slot, or at least that is what portage interprets what it is finding. I'd need to see more of the output to get a sense of what is actually going on - posting 10 lines out of what was probably 1000+ lines of output honestly doesn't help anybody to assist you. Yes, the whole output is tedious but probably contains clues. > > One might say, I have a package already dependent on setuptools and it's not > the right one, but how can it be that two different versions want to go into > the same slot? There are many ways this can happen. Maybe package A wants setuptools 40.7.3 or greater, and package B wants setuptools 40.6.3 or lesser, and you asked for both. Often though it is an issue with not backtracking enough - if you're doing a huge update often you need to add --backtrack=100 or rarely even a larger value in order for portage to find a way to meet the requirements. Sometimes you need to include --with-bdeps=y because something portage isn't considering in-scope is pulling in something that conflicts, and it could be resolved by letting portage update more packages. > Backtracking is something to do with dependency checking. I haven't seen any > explanation of what goes on in dependency checking and why backtracking is > necessary. Can someone point to an explanation? Basically your config files, like the world file, and the profile system set, contain a list of stuff you want. Portage wants to give you want you want. Maybe these files specify 200 packages you're interested in directly. Each of these might ask for 5 more, and each of those 5 more, and so on. Portage works backwards through the dependency tree to generate a list of every requirement of every package. These can form circular loops, and the tree can get quite large very quickly. As an optimization I believe portage avoids traversing the entire thing and only goes back so far - usually it can find a solution to your requirements without traversing the entire tree. The --backtrack option controls how far back portage will try going. Increasing the value will slow things down, but can't hurt anything. > > My emerge output goes on to say: > > The current version of portage supports EAPI '6'. You must upgrade to a > newer version of portage before EAPI masked packages can be installed. > (dependency required by "app-portage/gemato-::gentoo" [ebuild]) > (dependency required by > "sys-apps/portage-2.3.66-r1::gentoo[-build,rsync-verify]" [ebuil > (dependency required by "portage" [argument]) > For more information, see the MASKED PACKAGES section in the emerge > man page or refer to the Gentoo Handbook. > > Is this telling me that I have to *first* update my system and *then* update > portage? So, if you blindly follow portage's instructions there is a good chance that you'll make your life using Gentoo a living nightmare, because portage doesn't really know what you want and often will get in over its head. The risk of this happening goes up quickly if you wait a long time between updates, as you seem to have done. You probably don't need those EAPI 7 packages, but if you do then the version of portage you have can't install them. You could upgrade p
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On domenica 21 luglio 2019 13:22:55 CEST Stefano Crocco wrote: > On domenica 21 luglio 2019 12:44:14 CEST Mick wrote: > > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > > > Hello to everyone, > > > > > > since yesterday emerge --sync fails because it can't refresh keys. > > > > > > The > > > > > > messages I get are: > > > > > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > > > * Refreshing keys via WKD ... [ !! ] > > > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org > > > > > > ...OpenPGP > > > > > > keyring > > > > > > > > > > > > refresh failed: > > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > > > OpenPGP keyring refresh failed: > > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > Perhaps something to do with this? > > > > > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-po > > > > > is > > > > > on > > > > > in > > > > > g-> > > > > > > > > can-break-some-openpgp-implementations/ > > > > > > > > > Aside: > > > > > I have already switched my personal gpg configuration to use the new > > > > > isolated keyserver. > > > > > > > > Thanks for the answer. I'd heard of this attack and read this [1] > > > > article > > > > on gentoo.org. From what I understand, it said that in theory there > > > > shouldn't be problems when syncing because "The gemato tool used to > > > > verify the Gentoo ebuild repository uses WKD by default. During normal > > > > operation it should not be affected by this vulnerability". Reading > > > > the > > > > article again, I now see it also says that "In the worst case; Gentoo > > > > repository syncs will be slow or hang" which, as you suggest, could > > > > very > > > > well be what's happened on my system. Unfortunately, the article > > > > doesn't > > > > say what to do if this happens. > > > > > > > > Tomorrow I'll try investigating more. > > > > > > > > Stefano > > > > > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > > > > > It seems I found out how to fix the issue. I tried comparing my > > > /usr/share/portage/config/repos.conf with the one which comes with a > > > current stage3 and found out mine had the line > > > > > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > > > > > which was missing in the file from stage3. Removing it (both here and in > > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I > > > hope > > > this is the correct fix. I don't remember ever writing this line, so I > > > suppose it came with the original stage3 I built my system from or was > > > changed by another update (an update of what, however? According to > > > `equery > > > b`, this file doesn't belong to any package). > > > > > > I hope thing will keep working. > > > > > > Stefano > > > > I grepped two older installations I had immediate access to and there is > > no > > directive containing "openpgp" anywhere within /etc/portage/. > > > > In a new-ish installation there were a number of entries in /etc/portage/ > > > > repos.conf/gentoo.conf, but no keyserver URI: > > $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf > > > > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc > > sync-openpgp-key-refresh-retry-count = 40 > > sync-openpgp-key-refresh-retry-overall-timeout = 1200 > > sync-openpgp-key-refresh-retry-delay-exp-base = 2
[gentoo-user] Re: Determine what's keeping Python 3.7 around?
On 2020-12-06, Neil Bothwick wrote: > On Sun, 6 Dec 2020 20:01:27 - (UTC), Grant Edwards wrote: > >> I updated one of my systems a day or two ago, and Python 3.7 went away >> as expected. Today, I'm updating another system and it is rebuilding >> tons of stuff to target python 3.8 instead of 3.7, but it's keeping >> 3.7 and even wants to install a _new_ package -- and build it for >> Python 3.7: > > emerge -cpv python:3.7 will show you what is keeping 3.7 Something's wrong. That lists 43 packages. I checked the first few, and none of them require python 3.7. # emerge -cpv python:3.7 Calculating dependencies... done! dev-lang/python-3.7.9 pulled in by: app-office/gnumeric-1.12.47 requires dev-lang/python:3.7 app-office/libreoffice-6.4.7.2 requires dev-lang/python:3.7[threads(+),xml] app-portage/gemato-16.2 requires dev-lang/python:3.7[threads(+)] app-portage/gentoolkit-0.5.0-r2 requires dev-lang/python:3.7[xml(+),threads(+)] app-portage/mirrorselect-2.2.6-r1 requires dev-lang/python:3.7[xml] app-text/asciidoc-9.0.2 requires dev-lang/python:3.7 dev-embedded/libftdi-1.4 requires dev-lang/python:3.7 dev-java/java-config-2.3.1 requires dev-lang/python:3.7 dev-java/javatoolkit-0.6.3 requires dev-lang/python:3.7[xml(+)] dev-libs/gobject-introspection-1.64.1-r1 requires dev-lang/python:3.7[xml] dev-libs/libxml2-2.9.10-r3 requires dev-lang/python:3.7[xml] dev-libs/newt-0.52.21-r1 requires dev-lang/python:3.7 dev-python/PyQt5-5.15.1 requires dev-lang/python:3.7 dev-python/PyQt5-sip-4.19.24 requires dev-lang/python:3.7 dev-python/PySocks-1.7.1-r1 requires dev-lang/python:3.7 dev-python/bcrypt-3.2.0 requires dev-lang/python:3.7 dev-python/beautifulsoup-4.9.3 requires dev-lang/python:3.7 dev-python/cairocffi-1.1.0 requires dev-lang/python:3.7 dev-python/certifi-10001 requires dev-lang/python:3.7 dev-python/cffi-1.14.0-r3 requires dev-lang/python:3.7 dev-python/chardet-3.0.4-r1 requires dev-lang/python:3.7 dev-python/configobj-5.0.6 requires dev-lang/python:3.7 dev-python/cryptography-3.2 requires dev-lang/python:3.7[threads(+)] dev-python/cssselect2-0.3.0 requires dev-lang/python:3.7 dev-python/cython-0.29.21-r1 requires dev-lang/python:3.7[threads(+)] dev-python/defusedxml-0.7.0_rc1 requires dev-lang/python:3.7[xml(+)] dev-python/docutils-0.16-r1 requires dev-lang/python:3.7 dev-python/future-0.18.2-r1 requires dev-lang/python:3.7 dev-python/html5lib-1.1 requires dev-lang/python:3.7[xml(+)] dev-python/idna-2.10-r1 requires dev-lang/python:3.7 dev-python/imapclient-2.1.0 requires dev-lang/python:3.7 dev-python/importlib_metadata-2.0.0 requires dev-lang/python:3.7 dev-python/jinja-2.11.2-r1 requires dev-lang/python:3.7[threads(+)] dev-python/lxml-4.6.2 requires dev-lang/python:3.7 dev-python/mako-1.1.3-r1 requires dev-lang/python:3.7 dev-python/markdown-3.3.3 requires dev-lang/python:3.7 dev-python/markups-3.0.0-r1 requires dev-lang/python:3.7 dev-python/markupsafe-1.1.1-r1 requires dev-lang/python:3.7 dev-python/netifaces-0.10.9 requires dev-lang/python:3.7 dev-python/olefile-0.46-r1 requires dev-lang/python:3.7 dev-python/paho-mqtt-1.5.0 requires dev-lang/python:3.7 dev-python/paramiko-2.7.1 requires dev-lang/python:3.7[threads(+)] dev-python/pbkdf2-1.3-r1 requires dev-lang/python:3.7 dev-python/pillow-7.2.0 requires dev-lang/python:3.7[tk,threads(+)] dev-python/pip-20.2.4 requires dev-lang/python:3.7[ssl(+),threads(+)] dev-python/ply-3.11-r1 requires dev-lang/python:3.7 dev-python/pyalsa-1.1.6-r1 requires dev-lang/python:3.7 dev-python/pyasn1-0.4.8-r1 requires dev-lang/python:3.7 dev-python/pycairo-1.18.2 requires dev-lang/python:3.7[threads(+)] dev-python/pycparser-2.20-r1 requires dev-lang/python:3.7 dev-python/pycurl-7.43.0.6 requires dev-lang/python:3.7 dev-python/pygments-2.7.2 requires dev-lang/python:3.7 dev-python/pygobject-3.36.1-r1 requires dev-lang/python:3.7 dev-python/pynacl-1.4.0 requires dev-lang/python:3.7 dev-python/pyopenssl-19.1.0-r1 requires dev-lang/python:3.7[threads(+)] dev-python/pyphen-0.9.5 requires dev-lang/python:3.7 dev-python/pyserial-3.4 requires dev-lang/python:3.7 dev-python/python-markdown-math-0.7 requires dev-lang/python:3.7 dev-python/qrcode-6.1 requires dev-lang/python:3.7 dev-python/requests-2.24.0-r1 requires dev-lang/python:3.7[threads(+)] dev-python/setuptools-46.4.0-r3 requires dev-lang/python:3.7[xml(+)] dev-python/sip-4.19.24 requires dev-lang/python:3.7 dev-python/six-1.15.0-r1 requires dev-lang/python:3.7 dev-python/soupsieve-2.0.1 requires dev-lang/python:3.7 dev-python/ssl-fetch-0.4 requires dev-lang/python:3.7 dev-python/tinycss2-1.0.2 requires dev-lang/python:3.7 dev-python/toml-0.10.1-r1 requires dev-lang/python:3.7 dev-python/urllib
Re: [gentoo-user] Python:2.7 and removing it early
At least gimp-help scribus nut fbpanel are Python2 only, didn't check stuff from overlays Il Lun 4 Mag 2020, 18:31 Dale ha scritto: > Howdy, > > As some know, python 2.7 is leaving the building. I'm wanting to try to > clean it out a bit now, a little at a time if needed. I found some > commands on -dev that shows what still depends on python 2.7. Thing is, > I think it is listing packages that *may* use 2.7 but can or is set to > use a newer version. In other words, I'm getting false positives. > Another command returns nothing and I think that command shows what > requires *only* python 2.7 and no newer version. Thing is, when I do a > emerge -ac python:2.7, it spits out a list of packages that says they > need it. It's confusing to say the least. I think I'm on information > overload or something. > > What I don't want to do, add targets to make.conf that may change > defaults later on. In other words, I don't want to add the target line > and then later on forget it is there and it bite me when say 3.6 is > leaving the building. I think if I can get it to where I can remove > python 2.7's package, it will leave it buried. How to get there tho?? > > I don't want to attach a ton of info that may not be relevant. I'm > going to share this tho. If anyone needs more info, let me know and > I'll post it. > > > root@fireball / # emerge -ca python:2.7 > > Calculating dependencies... done! > dev-lang/python-2.7.18 pulled in by: > app-doc/gimp-help-2.8.2 requires >=dev-lang/python-2.7.5-r2:2.7 > app-office/scribus-1.5.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > app-portage/gemato-14.3 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-lang/spidermonkey-1.8.5-r7 requires > >=dev-lang/python-2.7.5-r2:2.7[threads] > dev-lang/spidermonkey-60.5.2_p0-r4 requires > >=dev-lang/python-2.7.5-r2:2.7[ncurses,sqlite,ssl,threads] > dev-libs/boost-1.72.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-libs/libxml2-2.9.9-r3 requires >=dev-lang/python-2.7.5-r2:2.7[xml] > dev-python/PyQt5-5.14.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/PyQt5-sip-4.19.22 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/PySocks-1.7.1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/backports-1.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/backports-lzma-0.0.13 requires > >=dev-lang/python-2.7.5-r2:2.7 > dev-python/bz2file-0.98 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/certifi-2019.11.28 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/cffi-1.14.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/chardet-3.0.4 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/cryptography-2.8-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/cython-0.29.15 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/dbus-python-1.2.16 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/docutils-0.16 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/enum34-1.1.6-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/idna-2.8 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/ipaddress-1.0.23 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/lxml-4.5.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/mako-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/markupsafe-1.1.1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/numpy-1.16.5-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/olefile-0.46 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pathlib2-2.3.5 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pbr-4.2.0-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pillow-6.2.2 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/ply-3.11 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyblake2-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycairo-1.18.2 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pyclipper-1.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycparser-2.20 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycryptodome-3.9.4 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pygments-2.5.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygobject-2.28.6-r55 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygobject-3.34.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygtk-2.24.0-r5 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/p
[gentoo-user] Python:2.7 and removing it early
Howdy, As some know, python 2.7 is leaving the building. I'm wanting to try to clean it out a bit now, a little at a time if needed. I found some commands on -dev that shows what still depends on python 2.7. Thing is, I think it is listing packages that *may* use 2.7 but can or is set to use a newer version. In other words, I'm getting false positives. Another command returns nothing and I think that command shows what requires *only* python 2.7 and no newer version. Thing is, when I do a emerge -ac python:2.7, it spits out a list of packages that says they need it. It's confusing to say the least. I think I'm on information overload or something. What I don't want to do, add targets to make.conf that may change defaults later on. In other words, I don't want to add the target line and then later on forget it is there and it bite me when say 3.6 is leaving the building. I think if I can get it to where I can remove python 2.7's package, it will leave it buried. How to get there tho?? I don't want to attach a ton of info that may not be relevant. I'm going to share this tho. If anyone needs more info, let me know and I'll post it. root@fireball / # emerge -ca python:2.7 Calculating dependencies... done! dev-lang/python-2.7.18 pulled in by: app-doc/gimp-help-2.8.2 requires >=dev-lang/python-2.7.5-r2:2.7 app-office/scribus-1.5.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7 app-portage/gemato-14.3 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-lang/spidermonkey-1.8.5-r7 requires >=dev-lang/python-2.7.5-r2:2.7[threads] dev-lang/spidermonkey-60.5.2_p0-r4 requires >=dev-lang/python-2.7.5-r2:2.7[ncurses,sqlite,ssl,threads] dev-libs/boost-1.72.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-libs/libxml2-2.9.9-r3 requires >=dev-lang/python-2.7.5-r2:2.7[xml] dev-python/PyQt5-5.14.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/PyQt5-sip-4.19.22 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/PySocks-1.7.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/backports-1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/backports-lzma-0.0.13 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/bz2file-0.98 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/certifi-2019.11.28 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/cffi-1.14.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/chardet-3.0.4 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/cryptography-2.8-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/cython-0.29.15 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/dbus-python-1.2.16 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/docutils-0.16 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/enum34-1.1.6-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/idna-2.8 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/ipaddress-1.0.23 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/lxml-4.5.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/mako-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/markupsafe-1.1.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/numpy-1.16.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/olefile-0.46 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pathlib2-2.3.5 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pbr-4.2.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pillow-6.2.2 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/ply-3.11 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyblake2-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycairo-1.18.2 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pyclipper-1.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycparser-2.20 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycryptodome-3.9.4 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pygments-2.5.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygobject-2.28.6-r55 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygobject-3.34.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygtk-2.24.0-r5 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyopengl-3.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyopenssl-19.1.0 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/python-gammu-2.11 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyyaml-5.3.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/requests-2.23.0 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/scandir-1.10.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/setuptools-44.1.0 requires >=dev-lang/python-2.7.5-r2:2.7[xml(+)] d
Re: [gentoo-user] is a global use flag necessary for python?
On 3/9/24 20:51, Walter Dnes wrote: On Sat, Mar 09, 2024 at 07:55:13PM +0100, n952162 wrote Hello all, I just synced my system after a long delay, That's your problem right there. Is there a way to do it globally? First of all python targets should not need to be mentioned in make.conf or package.use. Gentoo manages versions automatically... if you update often enough. First thing to do is update python so programs have somthing up-to-date to build against. Try... emerge -1 python ...and then update world. * IMPORTANT: 2 config files in '/etc/portage' need updating. Calculating dependencies * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS * sections of the emerge man page to learn how to update config files. .. ... ... done! [ebuild N ] dev-python/gentoo-common-1 [ebuild N ] dev-python/ensurepip-pip-24.0 [ebuild U ] dev-lang/python-exec-2.4.10 [2.4.8] PYTHON_TARGETS="(python3_11%*) (python3_12%*)" [ebuild U ] app-arch/gzip-1.13 [1.11] USE="-verify-sig%" [ebuild N ] app-alternatives/gzip-1 USE="reference (split-usr) -pigz" [ebuild U ] dev-build/autoconf-2.71-r6 [2.71-r1] [ebuild U ] dev-build/automake-1.16.5-r2 [1.16.4] [ebuild NS ] dev-lang/python-3.12.2_p1 [3.6.15, 3.7.12_p1, 3.8.13, 3.9.9-r1, 3.10.2_p1] USE="ensurepip%* -debug% -valgrind%" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/python-exec:2 (dev-lang/python-exec-2.4.10:2/2::gentoo, ebuild scheduled for merge) USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_10) (python3_11) (python3_12)" pulled in by dev-lang/python-exec[python_targets_python3_12(-)] required by (dev-lang/python-3.12.2_p1:3.12/3.12::gentoo, ebuild scheduled for merge) USE="ensurepip gdbm ncurses readline sqlite ssl -bluetooth -build -debug -examples -libedit -pgo -test -tk -valgrind -verify-sig" ABI_X86="(64)" (dev-lang/python-exec-2.4.8:2/2::gentoo, installed) USE="(native-symlinks) userland_GNU -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_10) python3_8 python3_9" pulled in by >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (dev-python/pyparsing-2.4.7-r1:0/0::gentoo, installed) USE="userland_GNU -examples" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (app-portage/gemato-16.2:0/0::gentoo, installed) USE="gpg userland_GNU -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (dev-python/namespace-sphinxcontrib-1.0:0/0::gentoo, installed) USE="userland_GNU" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (dev-python/cython-0.29.24-r1:0/0::gentoo, installed) USE="userland_GNU -doc -emacs -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (x11-base/xcb-proto-1.14.1:0/0::gentoo, installed) USE="userland_GNU" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 python3_9" dev-lang/python-exec[python_targets_python3_9(-)] required by (dev-lang/python-3.9.9-r1:3.9/3.9::gentoo, installed) USE="gdbm ncurses readline sqlite ssl userland_GNU xml -bluetooth -build -examples -hardened -lto -pgo -test -tk -verify-sig -wininst" ABI_X86="(64)" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-)] required by (dev-python/backports-zoneinfo-0.2.1-r1:0/0::gentoo, installed) USE="userland_GNU -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3)" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (dev-python/lxml-4.6.3-r1:0/0::gentoo, installed) USE="threads userland_GNU -doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (dev-python/sphinxcontrib-devhelp-1.0.2:0/0::gentoo, installed) USE="userland_GNU -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_10" >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] required by (
Re: [gentoo-user] is a global use flag necessary for python?
Le dim. 10 mars 2024 à 00:22, n952162 a écrit : > > On 3/9/24 20:51, Walter Dnes wrote: > > On Sat, Mar 09, 2024 at 07:55:13PM +0100, n952162 wrote > >> Hello all, > >> > >> I just synced my system after a long delay, > >That's your problem right there. > > > >> Is there a way to do it globally? > >First of all python targets should not need to be mentioned in > > make.conf or package.use. Gentoo manages versions automatically... if > > you update often enough. First thing to do is update python so programs > > have somthing up-to-date to build against. Try... > > > > emerge -1 python > > > > ...and then update world. > > > > > * IMPORTANT: 2 config files in '/etc/portage' need updating. > Calculating dependencies * See the CONFIGURATION FILES and > CONFIGURATION FILES UPDATE TOOLS > * sections of the emerge man page to learn how to update config files. > .. ... ... done! > [ebuild N ] dev-python/gentoo-common-1 > [ebuild N ] dev-python/ensurepip-pip-24.0 > [ebuild U ] dev-lang/python-exec-2.4.10 [2.4.8] > PYTHON_TARGETS="(python3_11%*) (python3_12%*)" > [ebuild U ] app-arch/gzip-1.13 [1.11] USE="-verify-sig%" > [ebuild N ] app-alternatives/gzip-1 USE="reference (split-usr) -pigz" > [ebuild U ] dev-build/autoconf-2.71-r6 [2.71-r1] > [ebuild U ] dev-build/automake-1.16.5-r2 [1.16.4] > [ebuild NS] dev-lang/python-3.12.2_p1 [3.6.15, 3.7.12_p1, 3.8.13, > 3.9.9-r1, 3.10.2_p1] USE="ensurepip%* -debug% -valgrind%" > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > dev-lang/python-exec:2 > >(dev-lang/python-exec-2.4.10:2/2::gentoo, ebuild scheduled for merge) > USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) > (python3_10) (python3_11) (python3_12)" pulled in by > dev-lang/python-exec[python_targets_python3_12(-)] required by > (dev-lang/python-3.12.2_p1:3.12/3.12::gentoo, ebuild scheduled for > merge) USE="ensurepip gdbm ncurses readline sqlite ssl -bluetooth -build > -debug -examples -libedit -pgo -test -tk -valgrind -verify-sig" > ABI_X86="(64)" > > >(dev-lang/python-exec-2.4.8:2/2::gentoo, installed) > USE="(native-symlinks) userland_GNU -test" ABI_X86="(64)" > PYTHON_TARGETS="(pypy3) (python3_10) python3_8 python3_9" pulled in by > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] > required by (dev-python/pyparsing-2.4.7-r1:0/0::gentoo, installed) > USE="userland_GNU -examples" ABI_X86="(64)" PYTHON_TARGETS="python3_8 > python3_9 (-pypy3) -python3_10" > > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] > required by (app-portage/gemato-16.2:0/0::gentoo, installed) USE="gpg > userland_GNU -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 > (-pypy3) -python3_10" > > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] > required by (dev-python/namespace-sphinxcontrib-1.0:0/0::gentoo, installed) > USE="userland_GNU" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 > (-pypy3) -python3_10" > > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] > required by (dev-python/cython-0.29.24-r1:0/0::gentoo, installed) > USE="userland_GNU -doc -emacs -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 > python3_9 (-pypy3) -python3_10" > > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)] > required by (x11-base/xcb-proto-1.14.1:0/0::gentoo, installed) > USE="userland_GNU" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 > python3_9" > > dev-lang/python-exec[python_targets_python3_9(-)] required by > (dev-lang/python-3.9.9-r1:3.9/3.9::gentoo, installed) USE="gdbm ncurses > readline sqlite ssl userland_GNU xml -bluetooth -build -examples > -hardened -lto -pgo -test -tk -verify-sig -wininst" ABI_X86="(64)" > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-)] required > by (dev-python/backports-zoneinfo-0.2.1-r1:0/0::gentoo, installed) > USE="userland_GNU -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3)" > > > >=dev-lang/python-exec-2:2/2=[python_targets_python3_8(-),python_targets_python3_9(-)
[gentoo-user] update fails, but I don't see why
9" 0 KiB [ebuild R ] dev-python/m2crypto-0.36.0-r1::gentoo USE="-libressl" PYTHON_TARGETS="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild R ] dev-libs/gobject-introspection-1.64.1-r1::gentoo USE="-doctool -gtk-doc -test" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7*" 0 KiB [ebuild U ] media-libs/dav1d-0.7.1:0/4::gentoo [0.7.0:0/4::gentoo] USE="10bit 8bit asm" ABI_X86="(64) -32 (-x32)" 630 KiB [ebuild U ] dev-libs/libinput-1.16.3:0/10::gentoo [1.16.1:0/10::gentoo] USE="-doc -test" INPUT_DEVICES="-wacom" 582 KiB [ebuild R ] dev-python/jinja-2.11.2-r1::gentoo USE="-doc -examples -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild U ] media-libs/babl-0.1.78::gentoo [0.1.74::gentoo] USE="-introspection -lcms -vala%" CPU_FLAGS_X86="mmx sse sse2 -avx2 -f16c -sse3 -sse4_1" 292 KiB [ebuild U ] dev-libs/jsoncpp-1.9.4:0/24::gentoo [1.9.3:0/24::gentoo] USE="-doc -test" 210 KiB [ebuild U ] dev-python/pycparser-2.20-r1::gentoo [2.20::gentoo] PYTHON_TARGETS="python3_6 python3_8* (-pypy3) -python3_7* -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] dev-python/Babel-2.8.0-r2::gentoo USE="-doc -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild R ] dev-python/docutils-0.16-r1::gentoo PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild R ] dev-python/packaging-20.4-r1::gentoo USE="-test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild U ] dev-python/lxml-4.6.2::gentoo [4.5.2-r1::gentoo] USE="threads -doc -examples -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 927 KiB [ebuild R ] dev-python/isodate-0.6.0-r1::gentoo USE="-test" PYTHON_TARGETS="python3_6 python3_8* (-pypy3) -python3_7* -python3_9% (-python2_7%*)" 0 KiB [ebuild R ] dev-python/html5lib-1.1::gentoo USE="-test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild R ] dev-python/mako-1.1.3-r1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_8* (-pypy3) -python3_6 -python3_7* -python3_9" 0 KiB [ebuild U ] sys-auth/pambase-20201103::gentoo [20201013::gentoo] USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty (-selinux) -systemd" 4 KiB [ebuild r U ] app-text/poppler-20.11.0:0/104::gentoo [0.90.1:0/101::gentoo] USE="cairo cxx introspection jpeg jpeg2k lcms tiff utils -cjk -curl -debug -doc -nss -png -qt5" 1610 KiB [ebuild U ] dev-python/cffi-1.14.0-r3:0/1.14.0::gentoo [1.14.0-r2:0/1.14.0::gentoo] USE="-doc -test" PYTHON_TARGETS="python3_6 python3_8* -python3_7* -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] dev-python/rdflib-5.0.0::gentoo USE="berkdb -examples -sqlite -test" PYTHON_TARGETS="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild R ] net-dns/avahi-0.8-r2::gentoo USE="dbus gdbm introspection ipv6 nls -autoipd -bookmarks -doc -gtk -gtk2 -howl-compat -mdnsresponder-compat -mono -python -qt5 (-selinux) -systemd -test" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8* -python3_6 -python3_7*" 0 KiB [ebuild R ] media-libs/gexiv2-0.12.1::gentoo USE="introspection vala -gtk-doc -python -static-libs -test" PYTHON_TARGETS="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild U ] dev-python/cryptography-3.2.1::gentoo [2.9::gentoo] USE="-idna -libressl -test" PYTHON_TARGETS="python3_6 python3_8* (-pypy3) -python3_7* -python3_9 (-python2_7%*)" 529 KiB [ebuild R ] media-libs/lv2-1.18.0::gentoo USE="-doc -plugins" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild rR ] net-print/cups-filters-1.27.4::gentoo USE="foomatic jpeg png postscript tiff -dbus -ldap -pclm -pdf -perl -static-libs -test -zeroconf" 0 KiB [ebuild U ] media-libs/gegl-0.4.24:0.4::gentoo [0.4.22:0.4::gentoo] USE="cairo -debug -ffmpeg -introspection -lcms -lensfun -openexr -pdf -raw -sdl -svg -test -tiff -umfpack -v4l -vala -webp" 4822 KiB [ebuild U ] app-admin/sudo-1.9.3_p1::gentoo [1.9.2::gentoo] USE="nls pam secure-path sendmail ssl -gcrypt -ldap -libressl -offensive -sasl (-selinux) -skey -sssd" 3866 KiB [ebuild R ] net-analyzer/rrdtool-1.7.2:0/8.0.0::gentoo USE="graph perl tcpd -dbi -doc -lua -python -rados -rrdcgi -ruby -static-libs -tcl -test" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7*" 0 KiB [e
Re: [gentoo-user] update fails, but I don't see why
dev-libs/jsoncpp-1.9.4:0/24::gentoo [1.9.3:0/24::gentoo] USE="-doc -test" 210 KiB [ebuild U ] dev-python/pycparser-2.20-r1::gentoo [2.20::gentoo] PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] dev-python/Babel-2.8.0-r2::gentoo USE="-doc -test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild R ] dev-python/docutils-0.16-r1::gentoo PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild R ] dev-python/packaging-20.4-r1::gentoo USE="-test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild U ] dev-python/lxml-4.6.2::gentoo [4.5.2-r1::gentoo] USE="threads -doc -examples -test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 927 KiB [ebuild R ] dev-python/isodate-0.6.0-r1::gentoo USE="-test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6* -python3_9% (-python2_7%*)" 0 KiB [ebuild R ] dev-python/html5lib-1.1::gentoo USE="-test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild R ] dev-python/mako-1.1.3-r1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild U ] sys-auth/pambase-20201103::gentoo [20201013::gentoo] USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty (-selinux) -systemd" 4 KiB [ebuild r U ] app-text/poppler-20.11.0:0/104::gentoo [0.90.1:0/101::gentoo] USE="cairo cxx introspection jpeg jpeg2k lcms tiff utils -cjk -curl -debug -doc -nss -png -qt5" 1610 KiB [ebuild U ] dev-python/cffi-1.14.0-r3:0/1.14.0::gentoo [1.14.0-r2:0/1.14.0::gentoo] USE="-doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] dev-python/rdflib-5.0.0::gentoo USE="berkdb -examples -sqlite -test" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild R ] net-dns/avahi-0.8-r2::gentoo USE="dbus gdbm introspection ipv6 nls -autoipd -bookmarks -doc -gtk -gtk2 -howl-compat -mdnsresponder-compat -mono -python -qt5 (-selinux) -systemd -test" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_7 python3_8* -python3_6" 0 KiB [ebuild U ] media-libs/gegl-0.4.24:0.4::gentoo [0.4.22:0.4::gentoo] USE="cairo -debug -ffmpeg -introspection -lcms -lensfun -openexr -pdf -raw -sdl -svg -test -tiff -umfpack -v4l -vala -webp" 4822 KiB [ebuild R ] media-libs/gexiv2-0.12.1::gentoo USE="introspection vala -gtk-doc -python -static-libs -test" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild R ] app-office/gnumeric-1.12.47::gentoo USE="introspection -libgda -perl" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild U ] dev-python/cryptography-3.2.1::gentoo [2.9::gentoo] USE="-idna -libressl -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 529 KiB [ebuild R ] media-libs/lv2-1.18.0::gentoo USE="-doc -plugins" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild rR ] net-print/cups-filters-1.27.4::gentoo USE="foomatic jpeg png postscript tiff -dbus -ldap -pclm -pdf -perl -static-libs -test -zeroconf" 0 KiB [ebuild U ] app-admin/sudo-1.9.3_p1::gentoo [1.9.2::gentoo] USE="nls pam secure-path sendmail ssl -gcrypt -ldap -libressl -offensive -sasl (-selinux) -skey -sssd" 3866 KiB [ebuild U ] media-gfx/gimp-2.10.20-r3:0/2::gentoo [2.10.18-r2:0/0::gentoo] USE="doc -aalib -alsa (-aqua) -debug -gnome -heif -jpeg2k -mng -openexr -postscript -test -udev -unwind -vector-icons -webp -wmf -xpm (-python%)" CPU_FLAGS_X86="mmx sse" PYTHON_SINGLE_TARGET="(-python2_7%*)" 32333 KiB [ebuild U ] dev-python/pyopenssl-19.1.0-r1::gentoo [19.1.0::gentoo] USE="-doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 0 KiB [ebuild U ] media-libs/sratom-0.6.6::gentoo [0.6.4::gentoo] USE="-doc -static-libs -test" ABI_X86="(64) -32 (-x32)" 340 KiB [ebuild U ] media-libs/suil-0.10.8::gentoo [0.10.6::gentoo] USE="-doc -gtk -qt5" 349 KiB [ebuild U ] dev-python/urllib3-1.25.11::gentoo [1.25.10::gentoo] USE="-brotli -doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 255 KiB [ebuild U ] media-libs/lilv-0.24.10::gentoo [0.24.8-r1::gentoo] USE="dyn-manifest -doc -static-libs -test" A
Re: [gentoo-user] update fails, but I don't see why
dev-python/cffi-1.14.0-r3:0/1.14.0::gentoo [1.14.0-r2:0/1.14.0::gentoo] USE="-doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] dev-python/rdflib-5.0.0::gentoo USE="berkdb -examples -sqlite -test" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild R ] net-dns/avahi-0.8-r2::gentoo USE="dbus gdbm introspection ipv6 nls -autoipd -bookmarks -doc -gtk -gtk2 -howl-compat -mdnsresponder-compat -mono -python -qt5 (-selinux) -systemd -test" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_7 python3_8* -python3_6" 0 KiB [ebuild U ] media-libs/gegl-0.4.24:0.4::gentoo [0.4.22:0.4::gentoo] USE="cairo -debug -ffmpeg -introspection -lcms -lensfun -openexr -pdf -raw -sdl -svg -test -tiff -umfpack -v4l -vala -webp" 4822 KiB [ebuild R ] media-libs/gexiv2-0.12.1::gentoo USE="introspection vala -gtk-doc -python -static-libs -test" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild R ] app-office/gnumeric-1.12.47::gentoo USE="introspection -libgda -perl" PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB [ebuild U ] dev-python/cryptography-3.2.1::gentoo [2.9::gentoo] USE="-idna -libressl -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 529 KiB [ebuild R ] media-libs/lv2-1.18.0::gentoo USE="-doc -plugins" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild rR ] net-print/cups-filters-1.27.4::gentoo USE="foomatic jpeg png postscript tiff -dbus -ldap -pclm -pdf -perl -static-libs -test -zeroconf" 0 KiB [ebuild U ] app-admin/sudo-1.9.3_p1::gentoo [1.9.2::gentoo] USE="nls pam secure-path sendmail ssl -gcrypt -ldap -libressl -offensive -sasl (-selinux) -skey -sssd" 3866 KiB [ebuild U ] media-gfx/gimp-2.10.20-r3:0/2::gentoo [2.10.18-r2:0/0::gentoo] USE="doc -aalib -alsa (-aqua) -debug -gnome -heif -jpeg2k -mng -openexr -postscript -test -udev -unwind -vector-icons -webp -wmf -xpm (-python%)" CPU_FLAGS_X86="mmx sse" PYTHON_SINGLE_TARGET="(-python2_7%*)" 32333 KiB [ebuild U ] dev-python/pyopenssl-19.1.0-r1::gentoo [19.1.0::gentoo] USE="-doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 0 KiB [ebuild U ] media-libs/sratom-0.6.6::gentoo [0.6.4::gentoo] USE="-doc -static-libs -test" ABI_X86="(64) -32 (-x32)" 340 KiB [ebuild U ] media-libs/suil-0.10.8::gentoo [0.10.6::gentoo] USE="-doc -gtk -qt5" 349 KiB [ebuild U ] dev-python/urllib3-1.25.11::gentoo [1.25.10::gentoo] USE="-brotli -doc -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 255 KiB [ebuild U ] media-libs/lilv-0.24.10::gentoo [0.24.8-r1::gentoo] USE="dyn-manifest -doc -static-libs -test" ABI_X86="(64) -32 (-x32)" 434 KiB [ebuild U ] dev-python/requests-2.24.0-r1::gentoo [2.24.0::gentoo] USE="ssl -socks5 -test" PYTHON_TARGETS="python3_6 python3_7 python3_8* (-pypy3) -python3_9 (-python2_7%*)" 0 KiB [ebuild R ] app-portage/gemato-16.2::gentoo USE="gpg -test -tools" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild U ] sys-apps/portage-3.0.9::gentoo [3.0.8::gentoo] USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 1024 KiB [ebuild R ] app-portage/gentoolkit-0.5.0-r2::gentoo USE="-test" PYTHON_TARGETS="python3_7 python3_8* (-pypy3) -python3_6 -python3_9" 0 KiB [ebuild NS ] sys-devel/clang-11.0.0:11::gentoo [8.0.1:8::gentoo, 9.0.1:9::gentoo, 10.0.1:10::gentoo] USE="static-analyzer -debug -default-compiler-rt -default-libcxx -default-lld -doc -test -xml" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -VE% -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB [ebuild NS ] sys-libs/compiler-rt-11.0.0:11.0.0::gentoo [8.0.1:8.0.1::gentoo, 9.0.1:9.0.1::gentoo, 10.0.0:10.0.0::gentoo, 10.0.1:10.0.1::gentoo] USE="clang -test" 0 KiB [ebuild NS ] sys-libs/compiler-rt-sanitizers-11.0.0:11.0.0::gentoo [8.0.1:8.0.1::gentoo, 9.0.1:9.0.1::gentoo, 10.0.0:10.0.0::gentoo, 10.0.1:10.0.1::gentoo] USE="clang libfuzzer profile sanitize xray -test" 0 KiB [ebuild NS ] sys-devel/clang-runtime-11.0.0:11.0.0::gentoo [8.0.1:8.0.1::gentoo, 9.0.1:9.0.1::gentoo, 10.0.0:10.0.0::gent
[gentoo-user] override PYTHON_TARGETS to avoid a slot collision
>=dev-python/setuptools-42.0.2[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-util/scons-4.0.1:0/0::gentoo, installed) USE="-doc -test"
ABI_X86="(64)" PYTHON_TARGETS="python3_7 -python3_6 -python3_8 -python3_9"
>=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/Babel-2.8.0-r2:0/0::gentoo, installed) USE="-doc
-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8
-python3_9"
>=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/markupsafe-1.1.1-r1:0/0::gentoo, installed)
USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
-python3_8 -python3_9"
>=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc -latex
-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8
-python3_9"
>=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (app-portage/gemato-16.2:0/0::gentoo, installed) USE="gpg -test
-tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -py
[gentoo-user] Tensorflow 2.1.0 failing to compile
er' 'run_in_build_dir' 'do_compile'
* environment, line 2999: Called _python_multibuild_wrapper
'run_in_build_dir' 'do_compile'
* environment, line 1099: Called run_in_build_dir 'do_compile'
* environment, line 3991: Called do_compile
* environment, line 4016: Called ebazel 'build'
'//tensorflow/tools/pip_package:build_pip_package'
* environment, line 2357: Called die
* The specific snippet of code:
* "${@}" || die "ebazel failed"
*
* If you need support, post the output of `emerge --info
'=sci-libs/tensorflow-2.1.0::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sci-libs/tensorflow-2.1.0::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/sci-libs/tensorflow-2.1.0/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sci-libs/tensorflow-2.1.0/temp/environment'.
* Working directory:
'/var/tmp/portage/sci-libs/tensorflow-2.1.0/work/tensorflow-2.1.0-python3_6'
* S: '/var/tmp/portage/sci-libs/tensorflow-2.1.0/work/tensorflow-2.1.0'
make.conf:
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-march=native -O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
# set cpu flags for better compilation
CPU_FLAGS_X86="aes avx avx2 avx512f avx512dq avx512cd avx512bw avx512vl f16c
fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3"
# NOTE: This stage was built with the bindist Use flag enabled
FEATURES="ccache"
PORTDIR="/var/db/repos/gentoo"
DISTDIR="/var/cache/distfiles"
PKGDIR="/var/cache/binpkgs"
# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C
# The following licence is required, in addition to @FREE, for GNOME.
ACCEPT_LICENSE="CC-Sampling-Plus-1.0"
# Use the 'stable' branch - 'testing' no longer required for Gnome 3.
# NB, amd64 is correct for both Intel and AMD 64-bit CPUs
ACCEPT_KEYWORDS="amd64"
# also set lm-sensors for getting information about vitals
USE="${USE} lm-sensors"
# additional use flags for parallel computing
USE="${USE} openmp cuda mpi opencl threads mpi-threads"
# for cuda compat
TF_CUDA_COMPUTE_CAPABILITIES=3.5,3.5
# Turn on logging - see http://gentoo-en.vfose.ru/wiki/Gentoo_maintenance.
PORTAGE_ELOG_CLASSES="info warn error log qa"
# Echo messages after emerge, also save to /var/log/portage/elog
PORTAGE_ELOG_SYSTEM="echo save"
# Ensure elogs saved in category subdirectories.
# Build binary packages as a byproduct of each emerge, a useful backup.
FEATURES="split-elog buildpkg"
# Settings for X11
VIDEO_CARDS="intel nvidia"
INPUT_DEVICES="libinput"
# rsync mirrors for better sync support
GENTOO_MIRRORS="rsync://mirrors.rit.edu/gentoo/
rsync://rsync.gtlib.gatech.edu/gentoo"
# make grub use efi for 64 bit
GRUB_PLATFORMS="efi-64"
eix-installed -a:
acct-group/input-0
acct-group/kvm-0
acct-group/mail-0
acct-group/man-0
acct-group/messagebus-0
acct-group/plugdev-0
acct-group/render-0
acct-group/smtpd-0
acct-group/smtpq-0
acct-group/sshd-0
acct-group/tor-0
acct-group/video-0
acct-user/mail-0
acct-user/man-1
acct-user/messagebus-0
acct-user/postmaster-0
acct-user/smtpd-0
acct-user/smtpq-0
acct-user/sshd-0
acct-user/tor-0
app-accessibility/at-spi2-atk-2.34.2
app-accessibility/at-spi2-core-2.34.0
app-admin/doas-6.0
app-admin/eselect-1.4.16
app-admin/haskell-updater-1.3.2
app-admin/logrotate-3.14.0
app-admin/perl-cleaner-2.27
app-admin/syslog-ng-3.22.1
app-arch/bzip2-1.0.6-r11
app-arch/cpio-2.12-r1
app-arch/gzip-1.9
app-arch/libarchive-3.4.2
app-arch/rpm2targz-9.0.0.5g
app-arch/snappy-1.1.8
app-arch/tar-1.32
app-arch/unzip-6.0_p25-r1
app-arch/xz-utils-5.2.4-r2
app-arch/zip-3.0-r3
app-benchmarks/ramspeed-3.5.0-r2
app-benchmarks/stress-ng-0.11.03
app-crypt/gnupg-2.2.19
app-crypt/gpgme-1.13.0-r1
app-crypt/libb2-0.98.1-r2
app-crypt/openpgp-keys-gentoo-release-20191030
app-crypt/p11-kit-0.23.19-r1
app-crypt/pinentry-1.1.0-r2
app-crypt/rhash-1.3.6-r1
app-dicts/aspell-en-2018.04.16.0
app-editors/emacs-26.3-r1
app-emacs/emacs-common-gentoo-1.6-r3
app-emacs/emacs-daemon-0.22
app-eselect/eselect-ctags-1.18
app-eselect/eselect-emacs-1.18
app-eselect/eselect-fontconfig-1.1-r1
app-eselect/eselect-java-0.4.0
app-eselect/eselect-lib-bin-symlink-0.1.1-r1
app-eselect/eselect-opencl-1.1.0-r4
app-eselect/eselect-pinentry-0.7
app-eselect/eselect-python-20190417
app-eselect/eselect-ruby-20190121
app-misc/ca-certificates-20190110.3.43
app-misc/c_rehash-1.7-r1
app-misc/editor-wrapper-4-r1
app-misc/mime-types-9
app-misc/pax-utils-1.2.5
app-misc/tmux-2.9a
app-portage/eix-0.33.9-r1
app-portage/elt-patches-20170815
app-p
Re: [gentoo-user] pcre build failure
ib (-selinux) -skey" 0 KiB > [ebuild U ] sys-libs/pam-1.4.0_p20200829::gentoo > [1.3.1_p20200128-r1::gentoo] USE="berkdb filecaps* pie (split-usr) -audit > -debug -nis (-selinux) (-cracklib%*) (-static-libs%)" ABI_X86="(64) -32 > (-x32)" 0 KiB > [ebuild NS] sys-libs/db-6.0.35-r2:6.0::gentoo [5.3.28-r2:5.3::gentoo] > USE="-cxx -doc -examples -java -tcl -test" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild N ] sys-auth/passwdqc-1.4.0-r1::gentoo 0 KiB > [ebuild U ] sys-apps/iproute2-5.8.0::gentoo [5.7.0::gentoo] USE="berkdb > iptables ipv6 -atm -caps -elf -minimal (-selinux)" 0 KiB > [ebuild U ] sys-apps/kbd-2.3.0-r1::gentoo [2.2.0-r2::gentoo] USE="nls > pam -test" 0 KiB > [ebuild N ] dev-python/cython-0.29.21-r1::gentoo USE="-doc -emacs > -test" PYTHON_TARGETS="python3_7 -pypy3 -python3_6 -python3_8 -python3_9" 0 > KiB > [ebuild N ] dev-python/lxml-4.5.2-r1::gentoo USE="threads -doc > -examples -test" PYTHON_TARGETS="python3_7 -pypy3 -python3_6 -python3_8 > -python3_9" 0 KiB > [ebuild N ] app-arch/libarchive-3.4.3:0/13::gentoo USE="acl bzip2 > e2fsprogs iconv lzma threads xattr zlib -blake2 -expat -libressl -lz4 -lzo > -nettle -static-libs -zstd" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild U ] dev-libs/openssl-1.1.1h:0/1.1::gentoo [1.1.1g:0/1.1::gentoo] > USE="asm zlib -bindist* -rfc3779 -sctp -sslv3 -static-libs -test > -tls-heartbeat -vanilla" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="(sse2)" 0 > KiB > [ebuild N ] app-crypt/rhash-1.4.0::gentoo USE="nls ssl -debug -libressl > -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild NS] dev-lang/python-3.9.0_rc2:3.9::gentoo > [2.7.18-r2:2.7::gentoo, 3.7.8-r2:3.7/3.7m::gentoo, 3.8.5:3.8::gentoo] > USE="gdbm ipv6 ncurses readline ssl xml -bluetooth -build -examples -hardened > -libressl -sqlite -test -tk -wininst" 0 KiB > [ebuild U ] sys-libs/glibc-2.32-r2:2.2::gentoo [2.31-r6:2.2::gentoo] > USE="(crypt) multiarch (multilib) ssp (static-libs) -audit -caps (-cet) > -compile-locales -custom-cflags -doc -gd -headers-only -nscd -profile > (-selinux) -static-pie -suid -systemtap -test (-vanilla)" 0 KiB > [ebuild U ] sys-libs/gdbm-1.18.1-r1:0/6::gentoo [1.18.1:0/6::gentoo] > USE="berkdb nls readline -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild U ] dev-libs/expat-2.2.10::gentoo [2.2.8::gentoo] > USE="(split-usr) unicode -examples -static-libs" ABI_X86="(64) -32 (-x32)" 0 > KiB > [ebuild U ] dev-lang/perl-5.30.3-r1:0/5.30::gentoo > [5.30.3:0/5.30::gentoo] USE="berkdb gdbm -debug -doc -ithreads" 0 KiB > [ebuild U ] sys-devel/automake-1.16.2:1.16::gentoo > [1.16.1-r1:1.16::gentoo] USE="-test%" 0 KiB > [ebuild U ] dev-libs/libgpg-error-1.39::gentoo [1.38::gentoo] USE="nls > -common-lisp" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild U ] dev-util/ninja-1.10.1::gentoo [1.10.0::gentoo] USE="-doc > -emacs -test -vim-syntax" 0 KiB > [ebuild U ] app-text/opensp-1.5.2-r6::gentoo [1.5.2-r3::gentoo] USE="nls > -doc -static-libs -test" 0 KiB > [ebuild U ] dev-perl/Unicode-LineBreak-2019.1.0::gentoo > [2017.4.0-r1::gentoo] 0 KiB > [ebuild U ] app-text/po4a-0.61::gentoo [0.57::gentoo] USE="-test" 0 KiB > [ebuild N ] dev-libs/jsoncpp-1.9.4:0/24::gentoo USE="-doc -test" 0 KiB > [ebuild N ] dev-libs/libuv-1.40.0:0/1::gentoo USE="-static-libs" > ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild N ] dev-util/cmake-3.18.3::gentoo USE="ncurses -doc -emacs -qt5 > -test" 0 KiB > [ebuild N ] app-arch/lz4-1.9.2:0/r132::gentoo USE="-static-libs" > ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild U ] dev-libs/libksba-1.4.0::gentoo [1.3.5-r1::gentoo] > USE="-static-libs" 0 KiB > [ebuild U ] app-crypt/gnupg-2.2.23::gentoo [2.2.20-r1::gentoo] > USE="bzip2 nls readline smartcard ssl -doc -ldap (-selinux) -tofu -tools -usb > -user-socket -wks-server" 0 KiB > [ebuild U ] app-crypt/libb2-0.98.1-r3::gentoo [0.98.1-r2::gentoo] > USE="openmp -native-cflags -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild U ] app-crypt/gpgme-1.14.0:1/11::gentoo [1.13.0-r1:1/11::gentoo] > USE="cxx -common-lisp -python -qt5 -static-libs" PYTHON_TARGETS="python3_7 > -python3_6 -python3_8" 0 KiB > [ebuild U ] net-misc/iputils-20200821::gentoo [20190709-r1::gentoo] > USE="arping filecaps* ipv6 nls ssl -caps -clockdiff -
