>> That would depend on whether or not it waits for completion, right? If
>> it just runs a quick curl or whatever to kick off the build it should be
>> fine… or am I misunderstanding something about sourcehut's buildsystem?
>
> That would be reasonably fast but still hugely more resource intensive
> than using a webhook, which is the designed-for approach.

SourceHut's GraphQL-based webhooks are very powerful and flexible, but
they have 2 significant problems for my use case:

- I couldn't find a non-programmatic access to it.  IOW in order to
  setup a webhook, one needs to first figure out how to send a GraphQL
  request to SourceHut (which requires getting an auth token, ...), then
  read the docs to find the necessary shape of the request, etc...

Hi,

I'm curious to know if SourceHut is participating in the design of the
ForgeFed/F3 protocol/format and/or plans to support them?
https://forgefriends.org/


        Stefan

> Crucially, the light and dark variants do not inherit from the default
> variant.  The default variant is aimed to be the most natural for Emacs
> users (hence it mostly relies on standard font-lock faces), while the
> light and dark styles serve a different goal.

Aha!  I had indeed misunderstood, thanks.

> Admittedly, this adds a layer of complication to the code, and I'm not
> sure the current approach (namely the sweeprolog-defface macro) is the
> most elegant...

Maybe a more elegant approach (or at least, one that fits better with
the rest of Emacs facilities) is to make the dark and the light options
custom-themes?  A "custom theme" is nothing more than a set of

Hi,

The patch below simplifies face definitions by consolidating common
elements from dark&light into the default.

The last hunk additionally avoids the use of font-lock's deprecated
"face variables", and refers to the face directly instead.


        Stefan

> I have removed the comments (and also the displayed titles) from my keys.
>
> Even email address is not considered private on SourceHut, SSH public key
> comment can still be sensitive.
>
> The default comment generated by `ssh-keygen` is $USER@$HOST, which means
> some users would expose some kind of login_user+device map without even
> realizing that.

BTW, why are the public keys available publicly?

I mean, I understand it should be harmless, but I expect that srht
wouldn't expose it just because it's supposed to be harmless: there's
presumably some good reason/usecase to expose it.

> I tried to subscribe to the following mailing list:
>
> https://lists.sr.ht/~protesilaos/modus-themes
>
> using my email address:
>
> gautier@gautierponsinet.xyz
>
> but it doesn't work.

FWIW, I know people have trouble sending me email from *.xyz addresses
because apparently these domains are too often abused by spammers, so
messages from such domain carry a heavy "stigma".

>>     Is there some way to do mirroring more efficiently, presumably by
>>     notifying `elpa.gnu.org` whenever something is pushed [to the
>>     relevant repositories]?
> You can set up webhooks,

OK, I'll look into that.

I guess I could make it make a dummy http request to a URL which
includes the repository name, so I can then scrape my weblogs to see
what needs to be updated.

> but post-update webhooks with GQL are not ready yet.

Hmm... I thought GQL is for client-initiated operations, thus not

Hi Drew,

> You should be good to go now. Thanks for your patience!

IIUC you've un-black-listed my machine.
Thank you very much.

I wish there was a better solution, tho, that doesn't involve my putting
undesired loads on your servers (which would also reduce the load on my
machine).

IOW, I'd be happy to hear positive answers to my question:

    Is there some way to do mirroring more efficiently, presumably by

>> Even better would be to keep this kind of data in a Git repository, so
>> you can edit it on your machine and then push it to SourceHut.
> I disagree, this would be a terrible solution. This would either require push
> access for people to file bugs, or allow flooding the repo with bogus reports
> that may or may not be removable from history.

I assumed you'd only give push access to some users.  So I guess what
you're saying is that my suggestion would only solve the problem for
those lucky ones with push access.  So, indeed, whichever way it's
stored, we'd want to offer an email-based way to manipulate that info.

[ To give some background, I'd like to see forges like SourceHut become
  less centralized, e.g. allowing "pull requests" from branches hosted
  anywhere on the Internet (and in this respect SourceHut is currently

> Can you please implement some way to add or remove labels to a task via email?

Even better would be to keep this kind of data in a Git repository, so
you can edit it on your machine and then push it to SourceHut.


        Stefan