Ticket created by ~andres on ~sircmpwn/meta.sr.ht
The following message is displayed when
ciaramultries to log in to builds.sr.ht:An error occurred Error occurred retrieving account info
git.sr.ht is logged in. Password reset did not help, clearing cookies did not help.
Comment by ~andres on ~sircmpwn/git.sr.ht
This still takes long enough to annoy github-acclimated users, taking roughly 6s for
ssh git@git.sr.ht. Most of the time seems to be taken during ssh connection establishment, after "debug2: we sent a publickey packet, wait for reply" and after "debug3: send packet: type 50", and some after "debug2: shell request accepted on channel 0". sircmpwn, is this consistent with your observations?
Ticket created by ~andres on ~sircmpwn/builds.sr.ht
At https://builds.sr.ht/~andres/job/78647#task-build it says
This is a big file! Only the last 128KiB is shown. Click here to download the full log.
and has a link to http://azusa.runners.sr.ht/logs/78647/build/log . That page, however, gives me a 403.
Ticket created by ~andres on ~sircmpwn/git.sr.ht
It seems that the TLS certificate git.sr.ht is serving expired today.
browse@ashryn ~ % curl https://git.sr.ht curl: (60) SSL certificate problem: certificate has expired
Comment by ~andres on ~sircmpwn/git.sr.ht
Some more observations:
ssh notgit@git.sr.htfails fastssh git@git.sr.htwith an unregistered key takes ~10s after "we sent a publickey packet, wait for reply"ssh git@git.sr.htwith a registered key takes ~10s after "we sent a publickey packet, wait for reply", then some more after "sign and send pubkey", and some more after "shell request accepted"Trying to trace control flow through the git.sr.ht setup, it is my understanding that trying to ssh to
git@git.sr.httakes this branch in gitsrht-dispatch and invokes gitsrht-keys which uses does anilikequery withf"%{b64key}%"to find the user with the ssh key in question. I don't understand the "fall back" logic, but in the implementation of that api there is a similarilikequery with the comment "TODO: parse this and do it properly instead of being a dumb idiot". If the key is not found, the control flow does not go much further than this, so I don't have any obvious alternative candidates for what could be taking the time. With 10k keys and 4096^2 nanoseconds per key the total time for one lookup would be 167s, so a slightly less dumb substring search applied to each key in the database is consistent with the observed 10s.The logic for adding ssh keys also looks up keys (to check for duplicates), but it does so by fingerprint instead of a substring search on the base64 representation. I just tried adding a key to my account, and it significantly took less than 10 seconds.
So I guess if I happen to tinker with this some other Sunday night, I will try to fill my local instance's database with a bunch of keys, measure whether the query I suspect is indeed the culprit, and try to replace it with a fingerprint-based lookup if so. Or perhaps (hopefully) somebody will beat me to it :).
Comment by ~andres on ~sircmpwn/builds.sr.ht
REPORTED RESOLVED FIXED
Ticket created by ~andres on ~sircmpwn/sr.ht
https://man.sr.ht/packages.md lists
1ED4E14494433AE3FD302CAB74B4BCCEA60D0437, whose self-signature on hkp://keys.gnupg.net expired on 2019-04-19.
Ticket created by ~andres on ~sircmpwn/builds.sr.ht
When building a non-master branch of a git repository in response to a push to git.sr.ht, the master branch is cloned recursively and the desired branch is checked out. However, the submodules remain at the version referenced by the master branch.
Comment by ~andres on ~sircmpwn/builds.sr.ht
In my case, the binary output was unintentional. So I would have been just fine an error message telling me that the reason I cannot see the log is that the task produced output that wasn't valid UTF-8 (or whatever the encoding of the day is). It wold be nice to be able to see the good parts of the log even if there is some garbage in there, but I am not sure what an appropriate granularity would be or how it could be implemented (though terminal emulators do various levels of okay at this).
Ticket created by ~andres on ~sircmpwn/builds.sr.ht
When a task sends arbitrary bytes to stderr or stdout, the log display fails completely with the message "Error fetching logs for task". Examples: https://builds.sr.ht/~andres/job/49896 https://builds.sr.ht/~andres/job/49897