tech can't fix us now


Last active a month ago


Last active 1 year, 3 months ago


Last active 1 year, 6 months ago
View more

Recent activity

Re: Should private repositores show 404 instead of 401? 5 hours ago

From dvn to ~sircmpwn/sr.ht-discuss

Do you have a link to that previous discussion?

Re: Using a non-standard SSH port a month ago

From Devan Carpenter to ~sircmpwn/sr.ht-discuss

> This is most likely due to using a non-standard SSH port. What could I do to use a non-standard SSH port without exposing it in the build manifest and the job log?

In the spirit of providing the help requested instead of telling people
they're wrong:

You could experiment with using a file type "secret". - https://builds.sr.ht/secrets

I might try something like the following:

make secret at the destination `~/.ssh_port_secret` with the following


Re: How to let non-sr.ht users subscribe to mailing lists with private browsing? a month ago

From Devan Carpenter to ~sircmpwn/sr.ht-discuss

Drew DeVault transcribed 0.3K bytes:
> On Tue Apr 6, 2021 at 8:33 AM EDT, Bastien wrote:
> > I see today's equivalence of "browsable" and "subscribable" for lists,
> > but I'd like to allow non-sr.ht users to subscribe to a list *before*
> > they can browse it.
> Yeah, this is deliberately not possible.

Will you please give the courtesy of justifying your WONTFIX.

Re: How to let non-sr.ht users subscribe to mailing lists with private browsing? a month ago

From Devan Carpenter to ~sircmpwn/sr.ht-discuss

I' going to assume Bastien wants to allow anyone to subscribe to the
mailing list, but only allow sr.ht users who are _also_ subscribers of
the list to browse.

I've seen mailinglist software, eg. GNU Mailman, which does distinguish
betwee browsing and subscription permissions, which allows for a
mailinglist to be subscribed to by anyone, but only those with elevated
permissions can browse the archives.

The big difference is that a subscriber only has messages from the
point in time they subscribe onward.

Re: [builds.sr.ht] Resubmitted builds are not associated with original build's project a month ago

From Devan Carpenter to ~sircmpwn/sr.ht-discuss

Ecmel Berk Canlıer transcribed some bytes:
> > You should commit a proper fix upstream if you want to associate it
> > with, well, the upstream project.
> Well, the issue with the build[1] wasn't caused by an upstream change,
> though. That's why I resubmitted the build instead of committing something
> upstream.
> 1: see task "setup" line 3

Yea, the intention does not line up with the actual useage, from my
point of view. You can see that other CI systems, like Gitlab CI, handle
this the opposite way. If you re-run a build manually then it will
supercede the previous build status in the UI. This is different than

Re: [pages] Behaviour of Links 2 months ago

From dvn to ~sircmpwn/sr.ht-discuss

Nguyễn Gia Phong transcribed 0.5K bytes:
> By your logic, ./rfc2732 would points to
> https://tools.ietf.org/html/rfc3986/rfc2732,
> were the base URL a directory (which in this case it isn't,
> it's an alias for rfc3986.html).

You're right, my mistake.

Okay, so what about redirecting to "<path>" to "<path>/"?

I assume there is pushback on this for some reason, no?

Re: [pages] Behaviour of Links 2 months ago

From dvn to ~sircmpwn/sr.ht-discuss

Except that <a href="./two.html"> should work, and it apparently wasn't,
though I cannot confirm anymore since solarpunk.cool/example is not
hosted on sourcehut pages now.

Take a look at the source on ietf RFC viewer:

There are relative links (eg. <a href="./rfc2732">) and that works fine.

Drew DeVault transcribed 0.2K bytes:
> That's not how the web works. We'd have to redirect /example to
> /example/ for the URLs to match like that. The browser doesn't know if
> it's a file or a directory.

Re: [pages] Behaviour of Links 2 months ago

From dvn to ~sircmpwn/sr.ht-discuss

It is though:

https://solarpunk.cool/example is actually ->


So I would expect `<a href="two.html">`

to go to ->


but it goes to ->

Re: [pages] Behaviour of Links 2 months ago

From dvn to ~sircmpwn/sr.ht-discuss

Drew DeVault transcribed 0.1K bytes:
> Yeah, the issue isn't pages, it's your markup. Your HTML needs to be
> fixed.

Right, so instead of saying the markup is wrong, why not just confirm
that pages does not support this kind of relative path?

Even w3schools says that putting "picture.jpg" is for when "The
"picture.jpg" file is located in the same folder as the current page"[0]

I looked at the server.go for pages, and you could check for a relative
path (r.URL.IsAbs() == false) in the request, and then concatenate

Re: COPYRIGHT files not being detected as being a license file 1 year, 1 month ago

From dvn to ~sircmpwn/sr.ht-discuss

Pedro Lucas Porcellis transcribed 531 bytes:
> Hello!
> > Hi Adam,
> > 
> > I haven't heard of "COPYRIGHT" as a common name for a licensing file.
> Actually projects like Godot Engine and the Drupal Project have indeed a
> their license as a plain-text "COPYRIGHT", not common, but exists.

I see!

> > for sourcehut to only support those. See the following:
> > https://producingoss.com/en/license-quickstart.html