[gentoo-user] gtk3 problem on latest update
Hi. I am having a problem with my latest world update. Portage wants me to update to a gtk3.24.x, but unless they fixed an at-spi problem, this will break gnome accessibility for me. What can I do here? The portage output is: !!! All ebuilds that could satisfy ">=x11-libs/gtk+-3.22.0:3[X,wayland=]" have been masked. !!! One of the following masked packages is required to complete your request: - x11-libs/gtk+-3.24.7::mv (masked by: package.mask) /etc/portage/package.mask: #at-spi problem - x11-libs/gtk+-3.24.7::gentoo (masked by: package.mask) - x11-libs/gtk+-3.24.4-r1::gentoo (masked by: package.mask) - x11-libs/gtk+-3.24.1::gentoo (masked by: package.mask) (dependency required by "gnome-base/gnome-control-center-3.30.3-r1::gentoo" [ebuild]) (dependency required by "net-libs/gnome-online-accounts-3.30.2::gentoo[gnome]" [ebuild]) (dependency required by "gnome-base/gvfs-1.38.2::gentoo[gnome-online-accounts]" [ebuild]) (dependency required by "app-cdr/brasero-3.12.2-r1::gentoo" [installed]) (dependency required by "media-sound/rhythmbox-3.4.3::gentoo[cdr]" [installed]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) Thanks in advance for any suggestions. -- 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] What happened to glsa-check?
Hm, my version displays a different usage help: # python3 /usr/lib64/portage/python3.6/glsa-check No mode given: what should I do? usage: glsa-check [glsa-list] optional arguments: -h, --helpshow this help message and exit -V, --version Some information about this tool -v, --verbose Print more information -n, --nocolor Disable colors -e, --emergelike Do not use a least-change algorithm -c, --cve Show CAN ids in listing mode Modes: -l, --listList all unapplied GLSA -d, --dumpShow all information about the given GLSA --print Alias for --dump -t, --testTest if this system is affected by the given GLSA -p, --pretend Show the necessary commands to apply this GLSA -f, --fix Try to auto-apply this GLSA (experimental) -i, --inject inject the given GLSA into the glsa_injected file -m, --mailSend a mail with the given GLSAs to the administrator My version belongs to portage-2.3.62. Are there more than one version in use? And why?
Re: [gentoo-user] What happened to glsa-check?
On 1/4/19 8:23 pm, Klaus-J. Wolf wrote: > Hm, my version displays a different usage help: > > #python3 /usr/lib64/portage/python3.6/glsa-check > No mode given: what should I do? > usage: glsa-check [glsa-list] > > optional arguments: > -h, --help show this help message and exit > -V, --version Some information about this tool > -v, --verbose Print more information > -n, --nocolor Disable colors > -e, --emergelike Do not use a least-change algorithm > -c, --cve Show CAN ids in listing mode > > Modes: > -l, --list List all unapplied GLSA > -d, --dump Show all information about the given GLSA > --print Alias for --dump > -t, --test Test if this system is affected by the given GLSA > -p, --pretend Show the necessary commands to apply this GLSA > -f, --fix Try to auto-apply this GLSA (experimental) > -i, --inject inject the given GLSA into the glsa_injected file > -m, --mail Send a mail with the given GLSAs to the administrator > > My version belongs to portage-2.3.62. > > Are there more than one version in use? And why? I would guess: 1. that the portage version is meant for the internal use of portage (hence why its "in an odd spot") and is divorced from the user package. 2. gentoolkit has the user version as "equery f gentoolkit" shows a /usr/bin/symlink. rattus ~ # equery f gentoolkit|grep glsa /usr/bin/glsa-check /usr/lib/python-exec/python2.7/glsa-check /usr/lib/python-exec/python3.6/glsa-check /usr/lib64/python2.7/site-packages/gentoolkit/glsa /usr/lib64/python2.7/site-packages/gentoolkit/glsa/__init__.py /usr/lib64/python2.7/site-packages/gentoolkit/glsa/__init__.pyc /usr/lib64/python2.7/site-packages/gentoolkit/glsa/__init__.pyo /usr/lib64/python3.6/site-packages/gentoolkit/glsa /usr/lib64/python3.6/site-packages/gentoolkit/glsa/__init__.py /usr/lib64/python3.6/site-packages/gentoolkit/glsa/__pycache__ /usr/lib64/python3.6/site-packages/gentoolkit/glsa/__pycache__/__init__.cpython-36.opt-1.pyc /usr/lib64/python3.6/site-packages/gentoolkit/glsa/__pycache__/__init__.cpython-36.opt-2.pyc /usr/lib64/python3.6/site-packages/gentoolkit/glsa/__pycache__/__init__.cpython-36.pyc /usr/share/man/man1/glsa-check.1.bz2 rattus ~ #
[gentoo-user] What happened to glsa-check?
Hi you people, I am not a frequent reader of any list, so I ask for patience if I am not familiar with info just recently discussed. >From olden times, and from https://wiki.gentoo.org/wiki/GLSA I know a tool called glsa-check. It was intended to check your system against recent security advisories. I was surprised I couldn't find it anymore on my Gentoo system. But stop, here it is: # find / -name glsa-check /usr/lib64/portage/python3.6/glsa-check /usr/lib64/portage/python2.7/glsa-check Really a strange place for a tool that "can be run by users" but anyway. But python3 /usr/lib64/portage/python3.6/glsa-check -l which should display "all unapplied GLSA" gives me: All GLSAs, from the beginning. So, what happened here? A dead project? Why? And if so, what replaced it? I hope you can help me. Best wishes to you - k.j.w.
Re: [gentoo-user] What happened to glsa-check?
On 1/4/19 7:45 pm, Klaus-J. Wolf wrote: > Hi you people, > > I am not a frequent reader of any list, so I ask for patience if I am > not familiar with info just recently discussed. > > From olden times, and from https://wiki.gentoo.org/wiki/GLSA I know a > tool called glsa-check. It was intended to check your system against > recent security advisories. > > I was surprised I couldn't find it anymore on my Gentoo system. But > stop, here it is: > > # find / -name glsa-check > /usr/lib64/portage/python3.6/glsa-check > /usr/lib64/portage/python2.7/glsa-check > > Really a strange place for a tool that "can be run by users" but anyway. > > But python3 /usr/lib64/portage/python3.6/glsa-check -l which should > display "all unapplied GLSA" gives me: All GLSAs, from the beginning. > > So, what happened here? A dead project? Why? > And if so, what replaced it? > > I hope you can help me. > > Best wishes to you - > > k.j.w. It belongs to gentoolkit rattus ~ # equery b glsa-check * Searching for glsa-check ... app-portage/gentoolkit-0.4.2-r1 (/usr/bin/glsa-check -> ../lib/python-exec/python-exec2) app-portage/gentoolkit-0.4.2-r1 (/usr/lib/python-exec/python3.6/glsa-check) app-portage/gentoolkit-0.4.2-r1 (/usr/lib/python-exec/python2.7/glsa-check) sys-apps/portage-2.3.62 (/usr/lib/portage/python3.6/glsa-check) sys-apps/portage-2.3.62 (/usr/lib/portage/python2.7/glsa-check) rattus ~ # and -l doesnt mean what you think it does ... rattus ~ # glsa-check --help Syntax: glsa-check [glsa-list] -l --list : list the GLSAs -d --dump : show all information about the GLSAs --print -t --test : test if this system is affected by the GLSAs -p --pretend : show the necessary steps to apply the GLSAs -f --fix : try to auto-apply the GLSAs (experimental) -i --inject : inject the given GLSA into the glsa_injected file -n --nocolor : disable colors (option) -e --emergelike : upgrade to latest version (not least-change, option) -h --help : show this help message -V --version : some information about this tool -v --verbose : print more information (option) -c --cve : show CVE ids in listing mode (option) -q --quiet : be less verbose and do not send empty mail (option) -m --mail : send a mail with the given GLSAs to the administrator glsa-list can contain an arbitrary number of GLSA ids, filenames containing GLSAs or the special identifiers 'all' and 'affected' rattus ~ # Try rattus ~ # glsa-check -t all This system is affected by the following GLSAs: 201705-10 rattus ~ # BillK
Re: [gentoo-user] What happened to glsa-check?
Ühel kenal päeval, E, 01.04.2019 kell 20:41, kirjutas Bill Kenworthy: > > Are there more than one version in use? And why? > > I would guess: > > 1. that the portage version is meant for the internal use of portage > (hence why its "in an odd spot") and is divorced from the user > package. > > 2. gentoolkit has the user version as "equery f gentoolkit" shows a > /usr/bin/symlink. The portage version is used for implementing the @security set, which I believe is a dynamic set that pulls in packages that "glsa-check -l affected" would report too. It has a glsa-check too, as it was supposed to all be unified in there eventually, but last I knew, that work has stalled and so there's almost the same backend code for this both in portage and gentoolkit. Use glsa-check from gentoolkit for manual calls and know that there is a @security set available (but research how exactly it works before relying on it for any security safety. Mart
Re: [gentoo-user] What happened to glsa-check?
On 4/1/19 9:30 AM, Michael Orlitzky wrote: > > But obviously, it was never removed from gentoolkit. And not > surprisingly, the two copies have diverged over the years. > Went to file a bug, and someone beat me to it by six years: https://bugs.gentoo.org/463952 It sounds like the plan is to make all of glsa-check's features available via the portage API, and then update gentoolkit's copy of the tool to be a wrapper around that API.
Re: [gentoo-user] What happened to glsa-check?
On 4/1/19 8:41 AM, Bill Kenworthy wrote: >> >> Are there more than one version in use? And why? > > > I would guess: > > 1. that the portage version is meant for the internal use of portage > (hence why its "in an odd spot") and is divorced from the user package. Interestingly enough, that copy was committed in 2007 with the message, commit eff61dab0a1725e73dac3c2d8709fc200dfca598 Author: Marius Mauch Date: Fri Nov 9 15:10:37 2007 + Move glsa-check from gentoolkit into portage so the gentoolkit version can be removed after 2.2 is released But obviously, it was never removed from gentoolkit. And not surprisingly, the two copies have diverged over the years. > 2. gentoolkit has the user version as "equery f gentoolkit" shows a > /usr/bin/symlink. That's the one you want for now.
