On 23-09-14 23:18:32, Jackson wrote:
> The logo is there, but it seems inconsistent with sourcehut services. Here's
> what it looks like:
> https://sr.ht/static/logo.svg

I suspect CSS can used to override the fill[1] property of the SVG so it
can be changed based on dark/light preference without needing any
changes to the file itself.

Cheers,
/Marius

[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Fills_and_Strokes#using_css

On 23-07-14 09:18:49, Geert Stappers wrote:
> On Fri, Jul 14, 2023 at 08:51:22AM +0200, Matěj Cepl wrote:
> > trying to remove a remote branch entry_points on my
> > https://git.sr.ht/~mcepl/osc repo, but although I have access

> Note the :
>  
> >     Please make sure you have the correct access rights
> >     and the repository exists.
> >     tumbleweed-pkg~/r/osc (git-support-in-service-command)$ 

Is pushing over HTTPS even supported on sourcehut?

Geert try pushing over git+ssh and see if it works.

On 23-07-04 23:20:42, Daniel Semyonov wrote:
> Hi,

Hi Daniel, thank you for your interest in BrutaLinks. :)

> As it turns out, these issues occurred since the ENV environment
> variable was set in my .profile, overwriting the value in .env.
> This seems like a bad name for that variable IMO, since AFAICT it has
> nothing to do with the original use of the ENV variable.

True, however both project support prefixes to the variable names -
which I guess I haven't documented anywhere. The current preffix that
you can use is "BRUTAL_" for BrutaLinks and "FEDBOX_" for FedBOX,
so for the ENV variable you can use "BRUTAL_ENV" and "FEDBOX_ENV".

> the key under https://meta.sr.ht/~chs.keys looks a bit weird. Maybe try
> removing it an adding it again

It looks like the ecdsa-sha2-nistp256 key has been moved on the previous
line. Is it possible that meta.sr.ht doesn't trim whitespace from the end of
the key a carriage return character was pasted by mistake?

I remember seeing something like that on the mailing list in the past
couple of months.

/Marius

On 2023-04-25 11:44, Gabriel Simmer wrote:
> Something I've found very useful for keeping build minutes down on any 
> CI provider is checking what paths have changed and depending on that 
> go ahead with the rest of the pipeline, or abort early (but still mark 
> as success). Some providers have this natively, others require a bit of 
> scripting, but as builds currently work I don't see a way of doing this 
> natively.

There was a discussion just a couple of days ago about this exact 
topic[1].

I maintain my opinion I mentioned somewhere in there: good Make targets
that have proper sources will speed your pipeline in the exact way you
want.

On 23-04-19 05:37:59, ixoh@cartitas.com wrote:
> Hello, I was wondering if there was a way to skip CI runs for commits that only
> change text files.
> 

My suggestion is to implement a small check that completes the CI
pipeline if the change is only in the README (or any other files you
want to skip). Make can probably be used for this, but here's an
example that uses the file list shown as modified in the git HEAD.

Eg:

tasks:
  - check: test -n "$(git show HEAD --name-only --oneline --format= | grep README.md)" && complete-build

Hello,

As I have added this mailing list (~mariusor/activitypub-go@lists.sr.ht)
as the notification method for github, the ammount of messages has
increased quite a lot, and it's possible that people get spammed, or for
legitimate discussions to slide through the cracks.

Therefore I decided to split it into two, one for general
discussions[1]: ~mariusor/go-activitypub-discuss and one for
development[2]: ~mariusor/go-activitypub-dev.

The former will be addressed to everyone that wants to discuss things
about the projects under the go-activitypub umbrella: the library
packages themselves[3], the FedBOX[4], Brutalinks[5], and, more recently

On 23-01-24 17:19:15, Stephen Castro-Starkey wrote:
> Greetings,
> 
> I’ve been trying to use podman to build images on builds.sr.ht but not having a lot of luck. It appears the file used to configure registries (/etc/containers/registries.conf) doesn’t contain any registries. Is there a way to change this?

I think that's a problem with the distribution not with sourcehut. (It
would be probably helpful to tell us which one you are using, to
determine if it's an actual bug with the image.)

For my pipelines I added a setup task that creates the pre-requisits[1],
but that's for Archlinux, which as far as I can see has a
registries.conf file, even though it's empty.

I would suggest you do something similar.

On 23-01-09 16:41:46, Lionel Dricot - Ploum wrote:
> It should be highlighted that "carbon-neutral" is often used as a pure
> marketing greenwashing gimmick.

At least Hetzner has a page where they detail the electricity provenance
for some of their co-locations[1]. I am not sure how much of this is
just for marketing purposes, but I assume that it's somewhat valid.

/Marius

[1] https://www.hetzner.com/unternehmen/umweltschutz/

On 22-12-12 16:23:49, Enan Ajmain wrote:
> My knowledge says it should be C4 and C5, but the word you chose,
>                                ^^^^^^^^^
> "past", makes it seem like C1 and C2.
>                            ^^^^^^^^^

You're right, I misspoke, apologies.

It's as you said, the commits that are affected are all the commits that
have the deleted commit as an ancestor. Removing it affects the hashes
of it's first order children commits, and that in turn has a cascading
effect to the tip of all the branches that used to contain it.

This makes it that all other clones of the repository past the deleted