When running emerge --sync, portage bails out with an uncaught exception, when USE="-rsync-verify" Reproducible: Always Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/portage/util/_async/AsyncFunction.py", line 39, in _run result = self.target(*(self.args or []), **(self.kwargs or {})) File "/usr/lib64/python2.7/site-packages/portage/sync/controller.py", line 168, in sync taskmaster.run_tasks(tasks, func, status, options=task_opts) File "/usr/lib64/python2.7/site-packages/portage/sync/controller.py", line 67, in run_tasks result = getattr(inst, func)(**kwargs) File "/usr/lib64/python2.7/site-packages/portage/sync/syncbase.py", line 129, in sync return self.update() File "/usr/lib64/python2.7/site-packages/portage/sync/modules/rsync/rsync.py", line 278, in update exitcode = portage.process.spawn(command, **self.spawn_kwargs) File "/usr/lib64/python2.7/site-packages/portage/process.py", line 266, in spawn raise CommandNotFound(mycommand[0]) CommandNotFound: gemato
This commit will fix it to correctly interpret the "sync-rsync-verify-metamanifest = no" setting in that USE="-rsync-verify" puts in /usr/share/portage/config/repos.conf: https://gitweb.gentoo.org/proj/portage.git/commit/?id=79c21efb36cb45a2586c5141abbf9e4dc65c8ac7 We still need to handle that CommandNotFound exception, in case gemato is missing for some reason.
On that topic: it would be great if the command used to verify was actually a configuration value, instead of hardcoded in the sources.
(In reply to Fabian Groffen from comment #2) > On that topic: it would be great if the command used to verify was actually > a configuration value, instead of hardcoded in the sources. Sure, that will be more useful when we have support for quarantining repositories with verification failures. Currently, verification failure has no special handling, and postsync.d hooks are not a bad alternative for customized verification.
(In reply to Fabian Groffen from comment #2) > On that topic: it would be great if the command used to verify was actually > a configuration value, instead of hardcoded in the sources. No, it wouldn't. This call is just a band-aid until we have better gemato integration in Portage. Then Python modules will be used directly.
Hmmm, ok. I just want to plug in my own verification tool.
*** Bug 646202 has been marked as a duplicate of this bug. ***
I tried to deactivate the rsync verification by adding sync-rsync-verify-metamanifest = no to /etc/portage/repos.conf/gentoo.conf as stated in the news article. However, portage still wants to verify stuff, fetches keys from the keyserver, checks OpenPGP signature and starts to verify /usr/portage I used the default +rsync-verify, but flipping the useflag doesn't change a thing. I expected the old behavior to be restored when adding 'sync-rsync-verify-metamanifest = no' to the gentoo.conf Is this bug about that kind of behavior, or shall I open a new one?
(In reply to tt_1 from comment #7) That issue is already fixed in git, see comment #1.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=8b773727f009e63fbaecf937701d7f9f1a97f112 commit 8b773727f009e63fbaecf937701d7f9f1a97f112 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-01-31 22:20:55 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-01-31 22:20:55 +0000 rsync: handle CommandNotFound for gemato (bug 646184) Bug: https://bugs.gentoo.org/646184 pym/portage/sync/modules/rsync/rsync.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)}
Created attachment 517334 [details] emerge info amdX2-64
Created attachment 517336 [details] result of emerge-sync AMDX2-64
(In reply to Geoff Madden from comment #11) > Created attachment 517336 [details] > result of emerge-sync AMDX2-64 See bug 646194.
This is fixed in 2.3.24, and the bug has never reached stable.
