Ludovic Courtès <l...@gnu.org> writes: >> I tried one time to pull from Codeberg but I also got "object not found" >> on the same object which was complained when trying to use the local >> file system clone. > > We’d need a clearer bug report with all the details here: command used, > error message, etc. >
Thanks Ludo. Maybe I will but there's at least one more things I can still try. If I find out I'll say how. >> Hence my questions: >> >> Was there a recent change - to guix, libgit, guile-git, ... - such that >> the checkouts under ~/.cache/guix/checkouts are not used by guix pull as >> ubiquitously as before? > > No. > >> In normal or less-than-normal-such-as-mine circumstances, should it be >> considered a dangerous action to delete the cache of guix checkouts >> under ~/.cache/guix? > > No, you can safely delete it as long as there’s no ‘guix’ process > accessing it while you’re deleting it. > >> What is at this time the recommended way to trigger a full re-clone and >> re-authentication of guix channels from an already installed system or >> home, if any? > > Full reclone can be forced by “rm -rf ~/.cache/guix/checkouts”. Full > reauthentication really isn’t needed, but if you insist: “rm -rf > ~/.cache/guix/authentication”. You're right and I somehow got myself confused/misremembering yesterday. Indeed, I just checked, I can trigger a full re-clone from Codeberg. If I now remember correctly, it is going to fail near the end and not reach authentication. But there's no substitution for Guix itself, and at this late hour, my network is too slow for me to wait until it fails. I'll try the next time I can sit at the computer in the morning. What I may actually not have tried yet is to start from the failing state of my local clone, then do a full re-clone from Codeberg with --allow-downgrades --disable-authentication. This might yield a robust return to normalcy, at least there's no reason why not... Let's try that before bothering you more. Runciter
