~andres


#127 Log-in fails with confusing error message 4 months ago

Ticket created by ~andres on ~sircmpwn/meta.sr.ht

The following message is displayed when ciaramul tries 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.

#181 Slow git operations over SSH 5 months ago

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?

#238 "403 Forbidden" on "download the full log" 5 months ago

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.

#227 git.sr.ht certificate expired 6 months ago

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

#181 Slow git operations over SSH 6 months ago

Comment by ~andres on ~sircmpwn/git.sr.ht

Some more observations:

  • ssh notgit@git.sr.ht fails fast
  • ssh git@git.sr.ht with an unregistered key takes ~10s after we sent a publickey packet, wait for reply
  • ssh git@git.sr.ht with 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.ht takes this branch in gitsrht-dispatch and invokes gitsrht-keys which uses does an ilike query with f"%{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 similar ilike query 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 :).

#214 git branches are built with submodules of master 7 months ago

Comment by ~andres on ~sircmpwn/builds.sr.ht

https://git.sr.ht/~sircmpwn/builds.sr.ht/commit/20aa65c0ee59bbcd5d0b0ea9a57e0b43942007e1

REPORTED RESOLVED FIXED

#193 Arch package repository key is expired 10 months ago

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.

#214 git branches are built with submodules of master 10 months ago

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.

#210 Binary output breaks log display "Error fetching logs for task" 10 months ago

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).

#210 Binary output breaks log display "Error fetching logs for task" 10 months ago

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