Heaven
tech can't fix us now
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
From dvn to ~sircmpwn/sr.ht-discuss
Do you have a link to that previous discussion?
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
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.
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.
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
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?
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.
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 ->
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...