> One could argue that you're not editing it "directly",
> as it's not through the website / through the same interface
> that you use to read it.

This is my understanding too. I believe part of the point of a 'wiki', back
when the idea was first created was to allow for quick, direct edits to the
page. By that definition, man.sr.ht doesn't meet the definition, but
GitHub's wiki pages do.

I feel like that would add more coupling between git.sr.ht and
builds.sr.ht than isn't strictly necessary for this functionality. I'm
personally happy with the existing method, even though it does present
some minor annoyances when rehosting projects on other forges.

--Noah

On Wed Mar 4, 2020 at 5:39 PM PST, Victor Goff wrote:
> ... perhaps delete the key and submit it (or a new one) with only the
> information you would like to share publicly?

This is probably the easiest way to handle it. You don't have to do
anything special, just delete the last part of the public key when you
paste it into meta.sr.ht.

> > Also, I did a bit of digging around, and the "A list of your public ..."
> > message near the "Add key" button is quite recent [1] as I did not
> > remember reading such a comment before today.
>
> I only signed up a couple of weeks ago, so I do not remember it not
> being there.

On Fri Feb 14, 2020 at 12:56 PM, Jonas Platte wrote:
> I'm looking forward to user groups on sourcehut!
>
> One minor note though: using ^ as the sigil to denote might cause some
> unnecessary confusion for zsh users when using the url to a user group
> or one of its repositories / lists /... on the command line as zsh
> interprets unquoted strings containing a ^ as some kind of glob.
>
> Maybe a different sigil like + could be used?

As a zsh user, I think just escaping the ^ would be sufficient.
That being said, according to RFC 3986 (https://tools.ietf.org/html/rfc3986#section-3.3)
the only valid characters in a URI are:

Try adding `export` in front of the ENV.

I'm not sure exactly what you're doing, but the cases where I've
had issues connecting to the internet from within containers,
it was a botched install (missing iptables rules) or the
ipv4/ipv6 forwarding config not set on the host.

This link should help:
https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux

July 20, 2019 7:19 AM, "Dave Cottlehuber" <dch@skunkwerks.at> wrote:
> Ideally, this would be possible:
> 
> foo | curl -vXPOST \
> -Hauthorization:token\ ... \
> https://paste.sr.ht/api/pastes/filename.ext
> 
> With visibility provided either as HTTP query parameter, or as X-...header.


How about a cli utility for interfacing with paste.sr.ht?

https://git.sr.ht/~chiefnoah/psi

On Fri Jul 12, 2019 at 10:45 AM Drew DeVault wrote:
> Currently, only the mailing list owner can export the entire archives as
> an mbox file. Should I make this option available to everyone? List
> admins, do you have an opinion?

Could it be an option configured by the list owner?

> I'd like to use different parts of the build manifest file depending on
> the branch I'm pushing, for instance on `dev` I'd like to run tests,
> but on `master` I'd like to `deploy`. Is it even feasible out of the
> box? If not, what's the recommended course of action?

I don't see a mechanism in the manifests for setting constraints
on when a task should be run. This is a feature on other build
servers that I've used and it's something I think would be useful
here as well. As others have said, you can probably add logic
into your script that accomplishes the same goal, but you lose
some visibility into what each task is really doing by putting
conditional branches into the task.