~ghewgill

Christchurch, New Zealand

https://hewgill.com

~ghewgill/neon-builds

Last active 13 days ago

~ghewgill/neon-discuss

Last active 2 years ago

~ghewgill/neon-devel

Last active 2 years ago

~ghewgill/neon-announce

Last active 2 years ago
View more

Recent activity

Re: Feature request: Count files containing "LICENSE" in the name as a valid license 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.

[PATCH dispatch.sr.ht] builds: shuffle list of manifests before limiting to first 4 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-dev

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

Re: SVG file embedded in README.md 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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

Re: SVG file embedded in README.md 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.

SVG file embedded in README.md 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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?

Re: Automatic builds launching 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.

Re: Automatic builds launching 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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

Automatic builds launching 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.

Re: Exposure of ssh public keys 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.

Re: Exposure of ssh public keys 2 years ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

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.