This is just bug 915842 again. It reported the issue for --pretend, but it's not the only affected command. The solution there was to add a special case for pretend, with a note: "We could check writable instead but I'd like to get a fix in for the regression first." From a quick check, changing "not pretend" to "self.dbapi.writable" works fine for both cases so I wonder what the downsides of it are... ``` $ emerge --version Portage 3.0.58 (python 3.11.6-final-0, default/linux/amd64/17.1/desktop/systemd/merged-usr, gcc-13, glibc-2.37-r7, 6.6.5-gentoo-dist x86_64) $ emerge --search portage /usr/bin/getuto must be run as root! Traceback (most recent call last): File "/usr/lib/python-exec/python3.11/emerge", line 57, in main retval = emerge_main() ^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/_emerge/main.py", line 1308, in emerge_main return run_action(emerge_config) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/_emerge/actions.py", line 3472, in run_action mytrees["bintree"].populate( File "/usr/lib/python3.11/site-packages/portage/dbapi/bintree.py", line 928, in populate self._populate_remote( File "/usr/lib/python3.11/site-packages/portage/dbapi/bintree.py", line 1334, in _populate_remote self._run_trust_helper() File "/usr/lib/python3.11/site-packages/portage/dbapi/bintree.py", line 1320, in _run_trust_helper ret.check_returncode() File "/usr/lib/python3.11/subprocess.py", line 502, in check_returncode raise CalledProcessError(self.returncode, self.args, self.stdout, subprocess.CalledProcessError: Command '/usr/bin/getuto' returned non-zero exit status 100. ```
I got this right in the description at least...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=b071a966357a29e8450688a28ca918166b9e4eb0 commit b071a966357a29e8450688a28ca918166b9e4eb0 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-02 04:00:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-02 04:09:56 +0000 bintree: don't call trust helper unless bindb is writable Followup to 6ae45739e208b7a9d59e0b6056be72a5791aae04. My qualm there wrt writable was whether or not doing something which mutated state (and therefore possibly the package list) would be confusing but that doesn't make much sense for a few reasons. Anyway, change the test to be not just for no-pretend, but also whether the bindb is writable too, as pretend is already a proxy for whether we may not have privileges (I can imagine someone possibly having bindb privileges but not /etc/portage/gnupg, so better to just head this off entirely). Bug: https://bugs.gentoo.org/915842 Bug: https://bugs.gentoo.org/920180 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 3 ++- lib/portage/dbapi/bintree.py | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b37b3b5340a35656651134154b193dbda7cf13c6 commit b37b3b5340a35656651134154b193dbda7cf13c6 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-05 08:23:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-05 08:23:30 +0000 sys-apps/portage: add 3.0.61 Note that bug #921208 is only partly fixed but I wanted to get these fixes out, in part because we've got more people trying binpkgs right now with the binhost announcement. Bug: https://bugs.gentoo.org/921208 Closes: https://bugs.gentoo.org/921177 Closes: https://bugs.gentoo.org/920180 Closes: https://bugs.gentoo.org/921181 Closes: https://bugs.gentoo.org/921327 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.61.ebuild | 246 +++++++++++++++++++++++++++++++++ 2 files changed, 247 insertions(+)
*** Bug 921397 has been marked as a duplicate of this bug. ***
I'm running version 3.0.61-r1, but this problem does not appear to be fixed: andrew@andrew-gentoo-pc ~ % emerge --search test /usr/bin/getuto must be run as root! Traceback (most recent call last): File "/usr/lib/python-exec/pypy3/emerge", line 57, in main retval = emerge_main() File "/usr/lib/pypy3.10/site-packages/_emerge/main.py", line 1308, in emerge_main return run_action(emerge_config) File "/usr/lib/pypy3.10/site-packages/_emerge/actions.py", line 3479, in run_action mytrees["bintree"].populate( File "/usr/lib/pypy3.10/site-packages/portage/dbapi/bintree.py", line 934, in populate self._populate_remote( File "/usr/lib/pypy3.10/site-packages/portage/dbapi/bintree.py", line 1338, in _populate_remote self._run_trust_helper() File "/usr/lib/pypy3.10/site-packages/portage/dbapi/bintree.py", line 1326, in _run_trust_helper ret.check_returncode() File "/usr/lib/pypy3.10/subprocess.py", line 457, in check_returncode raise CalledProcessError(self.returncode, self.args, self.stdout, subprocess.CalledProcessError: Command '/usr/bin/getuto' returned non-zero exit status 100. The same happens if you accidentally forget to add --pretend when running emerge as an unprivileged user.
I can trivially reproduce the issue, only if I ``` export PKGDIR=/tmp/pkgdir-test-for-bug920180 emerge --search test ``` Since the current check was enhanced from "using pretend" to "either of using pretend or checking whether the dbapi is writable". Is your $PKGDIR by any chance writable as non-root? (If so, why?)
(In reply to Eli Schwartz from comment #6) > Is your $PKGDIR by any chance writable as non-root? (If so, why?) Yes, it's on a sshfs configured to be owned by root:portage, and my user is in the portage group. On a sshfs the whole thing is owned by the same user if I'm not mistaken, and the distfiles are also here so it has to be writeable by the portage user. I feel the check should be whether /etc/portage/gnupg is writeable by the current user (which is not the case for my user since this is owned by root:root), PKGDIR is not really relevant.
(In reply to Andrew Ammerlaan from comment #7) > I feel the check should be whether /etc/portage/gnupg is writeable by the > current user (which is not the case for my user since this is owned by > root:root), PKGDIR is not really relevant. It's complicated because what we really want is a check for "in some way, the current mode of operation is a read-only operation not intended to make changes". dbapi being writable doesn't really indicate this. Nor does the gnupghome being writable indicate this. Checking specifically for pretend (and maybe for search too?) is not scalable but I'm not aware offhand of a third obvious mode that would need to be handled, so the "hackily hardcoded" approach may be suitable? (Even if you run --search as root, there is arguably no need to re-run getuto just for slowness.) I'm honestly not sure what the ideal, clean, elegant design for this is. I think the problem is *no one* is sure what the ideal, clean, elegant design for this is.
It can use a test like portage.data.secpass >= 2 to check if there are enough privileges. This is the secpass meaning from the portage.data module. For unprivileged/prefix mode secpass is also 2: # Privileges secpass uid gid # normal 0 any any # group 1 any portage_gid # super 2 0 any
