On 2024-12-09 15:15, Cayetano Santos wrote:
>>lun. 09 déc. 2024 at 13:01, raingloom@riseup.net wrote:
> 
>> Are there any options I haven't considered?  Are features like this
>> planned or even possible?
> 
> Would guix authenticate be an option for you ?
> 
>     https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html
> 
> --
> Cayetano Santos
> GnuPG Key: https://meta.sr.ht/~csantosb.pgp
> FingerPrint:   CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

On 2024-12-09 14:05, Drew DeVault wrote:
> A previously proposed and approved feature request is to add SSH deploy
> keys to git repositories, wherein you can add a specific SSH key to a
> repo with read-only or read/write access rather than only granting
> access to users.
> 
> Would that support your use-case?

Thanks for the scarily quick reply. :D

Found the discussion:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C88e9bcb0-9f79-b3a8-73f7-10f2cf64a602@bpiotrowski.pl%3E

Yep, that seems to be the SSH key based solution I was thinking of, I

Hi hut inhabitants!

Like many of you, I store my dotfiles and machine configs on git.sr.ht,
but lately I've been trying to improve the separation between work and
personal machines for privacy and security reasons.

One brute force way would be to make untrusted machines pull-only and
export only the config they need with CI at a known URL, or push to a
different repo, but that means I can't sync back config changes from
them, also I don't think it's currently possible to grant access only to
a specific repo.

So I think my requirements are:

On 2024-10-15 17:06, Страхиња Радић wrote:
> Дана 24/10/15 12:45PM, raingloom@riseup.net написа:
>> The norm is Github.
> 
> For mainstream "developers", yes.
>
>> And this is how you keep Github as the norm.
> 
> On the contrary, voicing and supporting a different opinion is the only
> way to stand against anything. Choosing conformism instead of that is
> the reason why Github is how it is right now, and why mainstream
> software is how it is right now.

I'll just leave this here, since it summarizes my stance far better than

On 2024-10-14 21:14, Страхиња Радић wrote:
> Дана 24/10/14 01:39PM, a cauema написа:
>> also, a huge ps...
>> 
>> when trying to send this message above using my very simple email client
>> (edison) on android, i got the extra annoyance of the "we don't like your
>> message, please read useplaintext.email pretty please" as you all for sure
>> know. and i decided to try fairemail again, since i lost all memory of why i
>> left it around 4y ago (i do recall i used it with srht). not sure yet if me
>> and/or marcel (fairemail dev, who seemed to somehow enjoy me as a customer
>> back then) will enjoy this turn of events, but i for sure still see the way
>> srht team handles this as disappointing yet again. my first attempt had no
>> html that i added. i feel it should ideally have accepted the text part of
>> it, as a sign of "we understand this was not my/your fault or my/your first

On 2024-08-22 13:29, Virgil Dupras wrote:
> Hello all,
> 
> We're back on this mailing list. As I wrote on the private mailing list, the growing list of members joining it ended up nullifying its main advantage, coziness. It's been quite a while since an emotionally sensible subject (collapse) has been broached on the list, it's been mostly technical. Either the list has been failing to provide this safe space or the need subsided.
> 
> A private mailing list brings an unnecessary aura of mystery around the project and constitute a barrier to entry to the project, so here we go.
> 
> When I merged this list with the private one, I had a frustration with sourcehut's problematic interactions with big and arrogant providers (gmail). I don't know if things are better now, but it might not be. Well, so be it. If you're on gmail, you might be better off using another provider, someone who doesn't actively work against you.
> 
> This will be a list for both Dusk OS and Collapse OS, discussions and patches. The private ML will be closing.
> 
> Regards,
> Virgil

On 2024-07-14 15:41, Страхиња Радић wrote:
> Дана 24/07/14 03:04PM, Jakob написа:
>> - A contributor has to enable SMTP in the settings of most mail 
>> providers.
> 
> Email "providers" that don't support SMTP, like Tutanota, suck anyway.
> ...

That is not an especially productive response to give to users who want
to contribute to a project, just saying.

this build: https://builds.sr.ht/~raingloom/job/1212401
triggered by this commit:
https://git.sr.ht/~raingloom/thesis/commit/868582e02a68601383583df11bb9322b4383d330
has two sources on the CI, which results in two clones, which obviously
fails, because the directory already exists.

If there is no branch suffix, the problem seems to disappear:
https://builds.sr.ht/~raingloom/job/1212409

Is this a bug?  It definitely seems like one, but I'd like to make sure.

On 2024-05-02 11:31, Страхиња Радић wrote:
> Дана 24/05/02 10:18AM, jman написа:
>> I've explicitely asked to keep the "political" part of that article 
>> out of this email thread. You can open another thread for that if you 
>> prefer.
> 
> The "technical" arguments presented in the article are there just to 
> give its main (what you call "political") premise false sense of 
> validity.
> 
> There are many long-term free software projects which operate 
> successfully for years without Github (or Sourcehut, for that matter). 
> 
> Using Github is not a prerequisite to maintain a quality free software 

"Virgil Dupras" <hsoft@hardcoded.net> writes:

> On Thu, Jul 6, 2023, at 7:50 PM, Virgil Dupras wrote:
>> On Wed, Jul 5, 2023, at 8:27 PM, Virgil Dupras wrote:
>>> On Wed, Jul 5, 2023, at 10:25 AM, Virgil Dupras wrote:
>>>> Aaaand.. all tests pass on the ARM port! Alignment discipline for the win!
>>>
>>> I spoke a bit too fast. All tests pass on QEMU ARM, but not on the real RPi. The
>>> first failure I stumbled upon was alignment-related, but passed under the radar
>>> with QEMU. I have a few other failures which look trickier to debug, but it
>>> still goes pretty well: most DuskCC tests pass.
>>>
>>> Shouldn't be too tricky to debug...