Kraków, Poland
Ticket created by ~nabijaczleweli on ~sircmpwn/git.sr.ht
Consider this blame (L296): https://git.sr.ht/~nabijaczleweli/foreports/blame/14c7148c0cfa0da4d3d2fae30c136c5e4d9c89e2/ar.c#L296 which reads
14c7148c наб 4 months ago 296 int tcmd(void) 08def261 наб 4 months ago 297 { 08def261 наб 4 months ago 298 if(getaf()) 299 noar();
&c. ‒ in multiple places I've found these to be doubled, for no Actual reason. This is odd and confusing, esp. with the side-bar colouring.
A normal blame is as-expected:
14c7148c (наб 2021-09-11 15:10:48 +0200 296) int tcmd(void) ^08def26 (наб 2021-09-11 15:03:21 +0200 297) { ^08def26 (наб 2021-09-11 15:03:21 +0200 298) if(getaf()) ^08def26 (наб 2021-09-11 15:03:21 +0200 299) noar();
But the porcelain one (-p) shards the exact same way (the final number is the amount of lines in a block):
14c7148c0cfa0da4d3d2fae30c136c5e4d9c89e2 296 296 1 int tcmd(void) 08def261ae73dc292ed344d65ddc45a1787207fd 269 297 1 { 08def261ae73dc292ed344d65ddc45a1787207fd 271 298 10 if(getaf()) 08def261ae73dc292ed344d65ddc45a1787207fd 272 299 noar();
Why this shards is beyond me (line number in original/line number now being non-consecutive, maybe, with the 2nd and 3rd numbers?), but it should be relatively simple to weld them in a post-processing step on libgit output.
I'll probably do it, but there's no telling when, so noting this down for future.
Comment by ~nabijaczleweli on ~sircmpwn/git.sr.ht
Landed in 0.72.12, closing
REPORTED
RESOLVED FIXEDComment by ~nabijaczleweli on ~sircmpwn/git.sr.ht
The current CSP is
content-security-policy: default-src 'none'; style-src 'self' 'unsafe-inline'; img-src *; script-src 'self'
, you needscript-src 'self' 'unself-inline'
; similar thing for inline images.
Ticket created by ~nabijaczleweli on ~nabijaczleweli/febug
But shouldn't. However, I didn't find a way to make it properly eat pkgsrc fuse, so.
Comment by ~nabijaczleweli on ~sircmpwn/hg.sr.ht
Unless I'm more blind than usual, the fix has required and still requires patching the upstream mercurial server, since the actual packaging call is
hg_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.
Ticket created by ~nabijaczleweli on ~migadu/alps
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
Happens on
92b30161962579fdd3bc133d8ccba03e4e1420fb
, I single-stepped with the same errors back to522454e00986053c86060f8a03d39a626c540652
, which fails to start.
Comment by ~nabijaczleweli on ~sircmpwn/git.sr.ht
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 thesubprocess.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.
Comment by ~nabijaczleweli on ~sircmpwn/git.sr.ht
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?
Ticket created by ~nabijaczleweli on ~sircmpwn/git.sr.ht
Consider this repo, with its
debian/0.1.0-2
andupstream/0.1.0
tags, 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
debian
tree0.1.0-2
, the tarball link to https://git.sr.ht/~nabijaczleweli/klapki.deb/archive/debian/0.1.0-2.tar.gz works, though.
Ticket created by ~nabijaczleweli on ~sircmpwn/man.sr.ht
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.
/log/branch
or/tree/branch
might be better.