Last active 7 months ago


Last active 9 months ago


Last active 11 months ago
View more

Recent activity

[PATCH] Fix missing braces error for old GCC versions 3 months ago

From Callum Brown to ~sircmpwn/gmni-devel

With GCC 4.9.4 you get
src/certs.c:75:2: error: missing braces around initializer [-Werror=missing-braces]
  br_skey_decoder_context skdec = {0};
Or you could have
	br_skey_decoder_context skdec = {{{0}}};
and use -Wno-missing-field-initializers

Of course there probably aren't many people using error throwing
versions any more.
 src/certs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/certs.c b/src/certs.c
[message trimmed]

Re: Strange crashes 4 months ago

From Callum Brown to ~sircmpwn/gmni-discuss

I still haven't worked out what precisely is going wrong, but I have
managed to reliably reproduce the issue by sending a ton of requests
at once. Basically and extremely easy DoS attack.

while true
   gmni -j once gemini://xxxxx/ &

[PATCH gmnisrv] Set certificate expiration to maximum value 4 months ago

From Callum Brown to ~sircmpwn/gmni-devel

Quoting RFC 5280 section [0]:
> To indicate that a certificate has no well-defined expiration date,
> the notAfter SHOULD be assigned the GeneralizedTime value of
> 99991231235959Z.

This fixes commit 8b65e303b01fc573cb1c40a365fb5db166146a37 where the
certificate expiration is set to LONG_MAX seconds in the future.
Using LONG_MAX avoids an integer overflow when using 200 years on 32
bit systems, however on 64 bit systems LONG_MAX is 9223372036854775807,
which is around 292 billion years worth of seconds. Unsurpringly, this
doesn't go down well with X509 certificates.

[0] https://datatracker.ietf.org/doc/html/rfc5280#section-
[message trimmed]

Re: Strange crashes 4 months ago

From Callum Brown to ~sircmpwn/gmni-discuss

Here it is:

coredumpctl info shows the following stack trace:

	#0  0x00007ff231f86005 __GI__IO_fread (libc.so.6 + 0x86005)
	#1  0x0000561b774b1611 client_writable (gmnisrv + 0x11611)
	#2  0x0000561b774b1fcd server_run (gmnisrv + 0x11fcd)
	#3  0x0000561b774a6621 main (gmnisrv + 0x6621)
	#4  0x00007ff231f270b3 __libc_start_main (libc.so.6 + 0x270b3)
	#5  0x0000561b774a42ee _start (gmnisrv + 0x42ee)

Re: Strange crashes 4 months ago

From Callum Brown to ~sircmpwn/gmni-discuss

Ok. I've installed systemd-coredump and compiled gmnisrv with debugging
symbols, so hopefully I'll get something useful next time it crashes :)

Strange crashes 4 months ago

From Callum Brown to ~sircmpwn/gmni-discuss


I, along with some others, have noticed my gemini capsule going down
regularly in the past two weeks. Unfortunately I don't yet have much
information about what's going on, but, after being told (indirectly)
that a couple other capsules have experienced what is likely the same
problem, it seems like a good idea to post what I do know here.

Since around 2021-03-26, my capsule gemini://calcuode.com/ has become
unresponsive a couple of times per day, requiring the server to be
restarted. At those times there are no errors shown, but looking
through the logs I can see systemd has restarted gmnisrv (sometimes
multiple times) after it failed due to a segmentation fault. I have not
been able to reproduce this failure. I can also see some SSL errors in

Re: aura-web-client: failed to fetch 7 months ago

From Callum Brown to ~callum/aura-web-client

On Tue Jan 26, 2021 at 8:10 PM GMT, R K Belew wrote:
> hi Callum,
> First use of sr.ht, that's how interested i am in your aura work
> connecting to beets! but can i really be the first to post
> to your list?! in any case:

Glad to hear you're interested in aura :-)
Out of interest, how did you find the sr.ht experience?

> i get a 'failed to fetch' exception, both when i use
> `xdg-open index.html` or open the `index.html` directly
> from a browser.

Re: The brick and mortar 10 months ago

From Callum Brown to ~mieum/booksin.space

> I don't know the full details of .bib files

Neither do I :-)

> I don't know what level of detail can be idiomatically encoded in a
> .bib. If it seems that we have too much information needed, I suggest
> we stick with using the YAML for all in-site needs

I know the format used in .bib files is geared towards making citations,
cross references, etc., and that the programs that use them
(e.g. BibTeX, Biber) are tightly coupled to TeX/LaTeX.
From that point of view YAML probably makes more sense.

> I would rather have this at a separate level, e.g.

Re: The brick and mortar 10 months ago

From Callum Brown to ~mieum/booksin.space

> Speaking of .bib files, it might be nice to have a central .bib file
> that includes all the info for the whole library.

I agree. Either one file with different language entries differetiated
somehow, or each language has its own .bib file.

The citation-key could be used for the paths to the actual content:
gemini://en.booksin.space/a-citation-key/ would get you to a directory
containing all the relevant files.

> There should be a complete text available, but also it would be nice
> if the table of contents was a list of links that linked to separate
> .gmi files for each chapter

Re: The brick and mortar 10 months ago

From Callum Brown to ~mieum/booksin.space

Hi. This project sounds really cool! I'd like to contribute a few

Should there be a standard format the books should be in (e.g. contents
at the start, ## for chapter headings), or would anything be alright as
long as it's Gemtext? I think it would be nice to have some consistency,
but books can be very varied in terms of layout so it might not be
possible. Especially with non-fiction which might have references,
images etc.

I like the idea of the books having pages, but for simplicity's sake
that might be something best left to the user/client.

I think translations of the same book should all be linked, so that