~nabijaczleweli

Kraków, Poland

https://nabijaczleweli.xyz

Trackers

~nabijaczleweli/voreutils

Last active 3 months ago

~nabijaczleweli/febug

Last active 7 months ago

~nabijaczleweli/yaxpeax-superh

Last active 8 months ago

~nabijaczleweli/tzpfms

Last active 10 months ago

~nabijaczleweli/klapki

Last active a year ago

#310 Support for non-UTF-8 refs 6 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 6 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 7 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 9 months 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 10 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 11 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 11 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 11 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 11 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.

#44 new-wiki hard-codes "master" branch 1 year, 1 day ago

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