Grant Edwards wrote: > On 2018-07-05, Grant Edwards <grant.b.edwa...@gmail.com> wrote: >> As of today, I seem to be unable to a an "emerge --sync". >> >> The process either hangs forever at the "Refreshing keys from keyserver step: > [...] > >> Or, it fails because there are no public key to verify a manfest: > For now, I've had to set add "sync-rsync-verify-metamanifest = no" to > my repo conf file so that I can actually do updates, but that seems > like a dangerous work-around. > > Is access to a keyserver via TCP port 11371 now a requirement for > using portage? > > Is there any other way to get keys updated that only requires the > normal https and rsync access? >
For those having this problem, may I suggest this. Look at the USE flags here for portage. [ebuild R ] sys-apps/portage-2.3.40-r1::gentoo USE="(ipc) native-extensions rsync-verify xattr -build -doc -epydoc -gentoo-dev (-selinux)" PYTHON_TARGETS="python2_7 python3_5 (-pypy) -python3_4 -python3_6" It seems to me that one could emerge portage with rsync-verify USE flag disabled. After that, do one update, hopefully that will update the keys etc and then emerge portage again with the USE flag enabled. Hopefully after that one time workaround, the keys will be updated and things will work like they should. It seems to me that a perfect set of problems popped up at a rather bad time. It seems some keys expired AND the verify option which requires those keys was enabled. Now you have a catch 22 problem since you can't get the new keys and verify at the same time due to the expired/bad keys. Add in the recent git issue and it has folks a little touchy about working around this problem. I suspect one could use some variable on the command line or in make.conf as a one time workaround as well. Would this work for everyone, rsync, websync and git or am I missing something else? Could this at least lead to a fix that everyone should be able to use??? Dale :-) :-)
