Landed in 0.72.12, closing
The current CSP is
content-security-policy: default-src 'none'; style-src 'self' 'unsafe-inline'; img-src *; script-src 'self', you need
script-src 'self' 'unself-inline'; similar thing for inline images.
But shouldn't. However, I didn't find a way to make it properly eat pkgsrc fuse, so.
Unless I'm more blind than usual, the fix has required and still requires patching the upstream mercurial server, since the actual packaging call ishg_repo.client.archive(path.encode(), rev=rev, prefix=basename, type="tgz")
and mercurial uses a homebrew archiver (https://www.mercurial-scm.org/repo/hg/file/d42809b6b10f/mercurial/archival.py#l134), which shouldn't be too difficult to fix if you have a repro, which it looks like you do.
So I cloned, go ran, logged in, got redirected to http://tarta:1323/mailbox/INBOX which 500ed with the last item in the log here, and got this on the default theme:
nabijaczleweli@tarta:~/uwu/alps$ go run ./cmd/alps nabijaczleweli.xyz 2020-07-13T11:42:49+02:00 - Configured upstream IMAP server: imaps://mail.nabijaczleweli.xyz:993 2020-07-13T11:42:50+02:00 - Configured upstream SMTP server: smtp://mail.nabijaczleweli.xyz:587 2020-07-13T11:42:50+02:00 - Loaded plugin "base" 2020-07-13T11:42:50+02:00 - caldav: failed to discover CalDAV server: discovery not yet implemented 2020-07-13T11:42:50+02:00 - carddav: failed to discover CardDAV server: carddav: domain doesn't have an SRV record 2020-07-13T11:42:50+02:00 - Loaded plugin "viewhtml" 2020-07-13T11:42:50+02:00 - Loaded plugin "viewtext" 2020-07-13T11:42:50+02:00 - Loading theme "alps" 2020-07-13T11:42:50+02:00 - Loading theme "sourcehut" ⇨ http server started on [::]:1323 2020-07-13T11:42:55+02:00 - Upstream IMAP server doesn't support the METADATA extension, using transient store instead 2020-07-13T11:42:55+02:00 ERROR template: mailbox.html:30:28: executing "mailbox.html" at <.TextPart.URL>: error calling URL: value method git.sr.ht/~emersion/alps/plugins/base.IMAPPartNode.URL called using nil *IMAPPartNode pointer
And this on the sourcehut theme:
nabijaczleweli@tarta:~/uwu/alps$ go run ./cmd/alps -theme sourcehut nabijaczleweli.xyz 2020-07-13T11:44:38+02:00 - Configured upstream IMAP server: imaps://mail.nabijaczleweli.xyz:993 2020-07-13T11:44:38+02:00 - Configured upstream SMTP server: smtp://mail.nabijaczleweli.xyz:587 2020-07-13T11:44:38+02:00 - Loaded plugin "base" 2020-07-13T11:44:38+02:00 - caldav: failed to discover CalDAV server: discovery not yet implemented 2020-07-13T11:44:38+02:00 - carddav: failed to discover CardDAV server: carddav: domain doesn't have an SRV record 2020-07-13T11:44:38+02:00 - Loaded plugin "viewhtml" 2020-07-13T11:44:38+02:00 - Loaded plugin "viewtext" 2020-07-13T11:44:38+02:00 - Loading theme "alps" 2020-07-13T11:44:38+02:00 - Loading theme "sourcehut" ⇨ http server started on [::]:1323 2020-07-13T11:44:45+02:00 - Upstream IMAP server doesn't support the METADATA extension, using transient store instead 2020-07-13T11:44:45+02:00 ERROR template: mailbox.html:56:31: executing "mailbox.html" at <.TextPart.URL>: error calling URL: value method git.sr.ht/~emersion/alps/plugins/base.IMAPPartNode.URL called using nil *IMAPPartNode pointer
92b30161962579fdd3bc133d8ccba03e4e1420fb, I single-stepped with the same errors back to
522454e00986053c86060f8a03d39a626c540652, which fails to start.
Trying now, here's the output from git-gc(1):
nabijaczleweli@tarta:~/code/meta.sr.ht$ git gc > /dev/null Enumerating objects: 3644, done. Counting objects: 100% (3644/3644), done. Delta compression using up to 24 threads Compressing objects: 100% (1341/1341), done. Writing objects: 100% (3644/3644), done. Total 3644 (delta 2456), reused 3333 (delta 2252)
Note, how (a), the info all goes out over stderr, but (b) we do get a metric of how much was done, so to say: re-running the GC made the last line
Total 3644 (delta 2456), reused 3644 (delta 2456), as there was nothing to do, but the first run only reused 91% of the objects. However, this disappears if redirected and the
subprocess.run(["git", "gc"], stderr=subprocess.PIPE)we'd use also makes it go blank. Patch upstream would be necessary for this.
Alternatively, we could read the pack directory directly, which'd amount to, what, two-times-five syscalls max? and present the part that actually matters ‒ on-disk usage before/after (a quick test reveals that even an empty GC run changes inode numbers, even if the SHAs and filenames remain the same, so I'm pretty sure it gets unshared from the snapshot anyway?). As for patching git to print out file sizes: no part of git that I know of deals in bytes, much less on-disk bytes of internal data, I'm unconvinced it's worth the effort writing a patch for it to get rejected.
Pushgateway seems workable enough, I'll start on an implementation with that and directory-based metrics.
git-gc(1) is very, hm, laconic in its output (this is code for "there is none except for errors") and the only way to get the savings is to run the equivalent of du(1) (cheap, since the only difference is gonna be the size ofthe sole pack file under .git/objects/pack/), but I don't really forsee a problem with this.
However, I'm not sure where the metrics would, like, physically go? Should I just slap an LDJSON thing in /var/log, or do you have something that'd integrate better?
Consider this repo, with its
upstream/0.1.0tags, as created with gbp(1).
Opening the ref name link leads to https://git.sr.ht/~nabijaczleweli/klapki.deb/refs/debian/0.1.0-2, which 404s, as does the browse link to https://git.sr.ht/~nabijaczleweli/klapki.deb/tree/debian/0.1.0-2; the log at https://git.sr.ht/~nabijaczleweli/klapki.deb/log/debian/0.1.0-2 just says "No commits for this path." and interprets the URL as log of branch
0.1.0-2, the tarball link to https://git.sr.ht/~nabijaczleweli/klapki.deb/archive/debian/0.1.0-2.tar.gz works, though.
On the https://man.sr.ht/wiki/create/ref page, in the "Or choose an existing ref" sexion the links end in
/refs/heads/branch, which 404s: https://git.sr.ht/~nabijaczleweli/klapki/refs/heads/trunk.
/tree/branchmight be better.