Some of my repositories were updated to the new anongit uris when I last synced, but not all were. When I poked in /var/lib/layman/cache_* I found the cached metadata still pertained to gogo. So I blew them all away and let layman refresh its cache. However, `layman --sync` is still not adapting to the change on its own. 4 repositories specifically are problematic, because instead of being migrated to anongit URIs, they've been migrated to git+ssh, which gives me: > Permission denied (publickey). > fatal: Could not read from remote repository grep '<source.*git+ssh' installed.xml <source type="git">git+ssh://git@git.gentoo.org/proj/x11.git</source> <source type="git">git+ssh://git@git.gentoo.org/proj/virtualization.git</source> <source type="git">git+ssh://git@git.gentoo.org/user/luman.git</source> <source type="git">git+ssh://git@git.gentoo.org/proj/dotnet.git</source> These are for repos named "x11", "virtualization", "luman", and "dotnet" respectively, each now stored in `installed.xml` with only those sources. in the latest cache update, x11 is defined as: <source type="git">git://anongit.gentoo.org/proj/x11</source> <source type="git">https://anongit.gentoo.org/git/proj/x11.git</source> <source type="git">git+ssh://git@git.gentoo.org/proj/x11.git</source> The same pattern is present with the other 4 named repos. In the writeup of this bug, I think I realize what may have happened: - layman fetched old cache data - layman rewote my addresses to the bad r/w values which I can't access due to being present - fixing the cache data doesn't resolve the issue due to r/w being a viable clone target. - SHTF. There really aught to be a more obvious way of handling this, perhaps with an ability to distinguish read-write sources from read-only ones. But it seems for me at least, I have to find some way to resolve this manually, and I'm averse to using delete/re-add or recommending that course of action. I think the *best* manual option would be something like: > layman --refresh-uri x11 --ro # Make sure x11 is cloneable from a RO uri > layman --refresh-uri x11 --rw # Make sure x11 is cloneable from a RW uri > layman --refresh-uri x11 # autodetect based on existing URI and try to make a good choice between the above 2 The idea being that refresh always updates a repo to use the "best" uri possible when called, instead of assuming that the present one is suffice by being in the list of alternatives. You could *plausibly* always use dual-uris and have a RO-uri for fetching, but set up the RW-uri for pushes, but ECOMPLEX :)
I haven't been able to reproduce this. But I do think you were on the right track in that layman had an old cache (not yet updated) so when it failed, it began cycling thru the source listings to find one that worked. The problem occurred due to the git+ssh was the last one tried. Then it updated to the cache with the new source listings. It will then cycle thru the sources attempting to replace it . But it will only replace the url if the old url matches, so it ended up matching the git+ssh url, so stayed with it. There is only so much logic you can put into the code that is worthwhile doing. I think you were just an unlucky one due timing. Re-open this bug if you manage to replicate more bad behavior.
