On Sun, Nov 08, 2020 at 02:37:08PM -0500, Eli Schwartz wrote:
> That being said, you can create a symlink "LICENSE" pointing to the file
> "UNLICENSE" and sourcehut accepts this.

This. This allows software authors to include their own preferred license file
under their preferred file name, and yet have a commonly accepted and
discoverable entry point ("LICENSE" file) that any tool should be able to pick
up and use. I do not see any downside to this approach.

---
 dispatchsrht/builds.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dispatchsrht/builds.py b/dispatchsrht/builds.py
index 053f340..62ffd5e 100644
--- a/dispatchsrht/builds.py
+++ b/dispatchsrht/builds.py
@@ -1,5 +1,6 @@
 import base64
 import json
+import random
 import re
 import requests
[message trimmed]

May 12, 2020 1:13 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> This is indeed a concern. In theory it's not unfixable, but the overhead
> of implementing SVG is higher than for any other image format.

Thanks. Whoever thought it was a good idea to ruin a perfectly good
image format with scripting.

I'll stick with the PNG image for now and hope nobody ruins that. :)

May 11, 2020 8:56 PM, "Simon Ser" <contact@emersion.fr> wrote:

> I wonder whether this may be a security issue (users would be able to
> potentially embed JavaScript in the SVG and steal cookies).

That could be the reason. That would be unfortunate too, because SVG
is a nice way to include simple diagrams (I even tried inline SVG in
the Markdown, but that definitely did not work).

I've added a PNG version of the diagram for now so it works, but have
left the broken link to the SVG in there. I'm still hoping that there
is some way to make the SVG work.

I'm trying to embed an SVG in a README.md file served from git.sr.ht.
Project link: https://git.sr.ht/~ghewgill/hour-of-power

The problem is the SVG file appears to be served with a
"Content-type: text/plain; charset=utf-8" header. This causes the
browser to fail to render the SVG as an image.

How can I cause the SVG file to be served with "image/svg+xml" type?
Or is there another better way I'm missing?

March 17, 2020 11:28 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> I can help you if you share a link to your repo? There's a lot of
> different ways it gets messed up.

Sure, I'll take this off-list for diagnostics.

March 17, 2020 11:08 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> git.sr.ht rewrites the clone URLs on submission to match whichever repo
> it was pushed to. So when your collaborator pushes to their repo, the
> clone URL will be rewritten and the job will build their code. However,
> any secrets you've included in your manifest will not be added to their
> build environment.

Ok, sounds reasonable. I don't have any build secrets, so that's not an
issue. I've just had reports that some pushes to their repo does not trigger
build jobs to be created. I don't have much visibility into why this might
be happening, so I was looking at the docs to try to find a reason.

What are the possible reasons that build jobs might not be created, or

I've got a question about how the builds.sr.ht integration is supposed
to work. I have a repository that has some yml files in the .builds/
directory, and it works fine for me when pushing code to git.sr.ht. That
is, build jobs are created and started on builds.sr.ht when I push.

If I have a collaborator who is working with a clone of the code in
their own git.sr.ht repository, are the automatic build jobs supposed
to be started when they push? From man.sr.ht: 

> git.sr.ht will automatically submit builds for you if you store a
> manifest in the repository as .build.yml. Each time you push, a
> build with this manifest will be submitted. If the repo you pushed
> to is present in the manifest's sources array, we'll edit it to point
> to the ref you just pushed.

March 5, 2020 6:39 PM, "Drew DeVault" <sir@cmpwn.com> wrote:

> This issue has been discussed before. As some have pointed out, your SSH
> public key is a _public_ key. It's tautological.

To be clear, I cannot object to the *key* part of the public key
being made public. However, the *comment* part, which is a name
that is meaningful to me only, should not be exposed in the public
list of keys. In order to be meaningful to me, the name is likely
to expose some aspect of my client setup, and I don't want to remove
that or substitute the actual machine names/locations with code
words.

I would be happier if the public list of keys omitted the name part.

March 5, 2020 5:00 PM, "Victor Goff" <keeperotphones@gmail.com> wrote:

> It is similar on github: https://github.com/username.keys
> and gitlab: https://gitlab.com/username.keys

I notice that github does not expose the key comment (name) in this case.