~dvn

Heaven

tech can't fix us now

~dvn/docuweb

Last active 2 years ago

~dvn/secusharebox

Last active 3 years ago

~dvn/hyperwalker

Last active 4 years ago

~dvn/olaplayer

Last active 4 years ago
View more

Recent activity

Project plans - Both Gio and Terminal? 2 years ago

From dvn to ~ghost08/photon

Hello,

I've been interested in Photon since shortly after its inception, due to
my longstanding interest in Gio. I noticed that you recently split the
project into a core library, and two clients; The one using Gio, and the
other using Sixel in the terminal.


I noticed that the terminal client seems to be getting some more
improvements that the GUI client hasn't received yet.

Is the plan to continue developing both, or was the intention to
supercede the Gio client with the terminal client? I have noticed some
performance issues with the Gio client sometimes - namely high CPU

Re: Should private repositores show 404 instead of 401? 3 years ago

From dvn to ~sircmpwn/sr.ht-discuss

Do you have a link to that previous discussion?

Re: Using a non-standard SSH port 3 years 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:

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

SSH_PORT=2222

Re: How to let non-sr.ht users subscribe to mailing lists with private browsing? 3 years 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? 3 years 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 3 years 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 3 years 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 3 years 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:
https://tools.ietf.org/html/rfc3986

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 3 years ago

From dvn to ~sircmpwn/sr.ht-discuss

It is though:

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

https://solarpunk.cool/example/index.html

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

to go to ->

https://solarpunk.cool/example/two.html

but it goes to ->

Re: [pages] Behaviour of Links 3 years 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
accordingly...