#357 Blame view shards at (arbitrary?) porcelain boundary instead of at SHAs 21 hours ago

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.

#310 Support for non-UTF-8 refs 10 months ago

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

Landed in 0.72.12, closing

REPORTED RESOLVED FIXED

#338 Line numbering script violates CSP 10 months ago

Comment 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 need script-src 'self' 'unself-inline'; similar thing for inline images.

#1 febug-pkgsrc relies on fusefs-libs3 from FreeBSD ports 11 months ago

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.

#33 Generated archives have unstable checksum due to changing timestamps 1 year, 1 month ago

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.

#102 Error rendering "mailbox.html" => can't use past the login page 1 year, 3 months ago

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 to 522454e00986053c86060f8a03d39a626c540652, which fails to start.

#324 Add push metrics to gitsrht-periodic 1 year, 3 months ago

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

#324 Add push metrics to gitsrht-periodic 1 year, 3 months ago

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?

#323 Refs with slashes unusable 1 year, 3 months ago

Ticket created by ~nabijaczleweli on ~sircmpwn/git.sr.ht

Consider this repo, with its debian/0.1.0-2 and upstream/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 tree 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.

#45 select_ref() links to produces links to git.sr.ht/~u/r/refs/heads/branch, which 404s 1 year, 3 months ago

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.