Conrad Hoffmann <ch@bitfehler.net> writes:

> On 7/5/23 11:45, Sarah Fairbairn wrote:
>> The build is failing on the save command with:  write 
>> /dev/stdout: no space left on device
>
> Given that error message, and this being docker, let me make a 
> wild guess:
> /dev/stdout is typically a link to /proc/self/fd/1, and both 
> /dev and /proc have
> different filesystems mounted on them (a tmpfs and procfs 
> respectively). A
> procfs isn't really writable so most likely /dev/stdout didn't 

srht@storiepvtride.it writes:


>
> I share the inconvenience of forking just to submit a patch into a merge
> request, but I didn't yet find another workflow that keeps all patches
> in order and easily discoverable.

Making your own copy of the repo that is available publicly is fairly
easy with git/hg.  Just make your repo and push to it.  Then you can
share that URL.  In this case, the only distinction is in GitHub, forked
repos show up in an index somewhere, but for the distributing code that
depends on the code it's fine.

Drew DeVault <sir@cmpwn.com> writes:

> On Fri May 29, 2020 at 4:52 AM EDT, Zachary King wrote:
>> I'm sorry, but I have to disagree on this point.
>>
>> You can't restrict what a user can do on a platform and say it is
>> increasing their freedom. That doesn't mean that it is wrong or
>> shouldn't be done, but you can't do one thing and call it another.
>
> I don't want to get into the weeds on this, but by requiring all public
> projects to use a FOSS license, it increases the freedom of *everyone
> else* by making sure that any project they see on sr.ht is something
> they can use under terms they understand.

Drew DeVault <sir@cmpwn.com> writes:

> On Fri May 29, 2020 at 2:24 AM EDT, Malcolm Matalka wrote:
>> Responding on "open core" section even though my point is more general.
>>
>> Personally, I would like to see more of a rational behind this change.
>> The usual contract I am used to is roughly: I give you money, you serve
>> my bits. With restrictions on my bits not harming your business. These
>> changes really push your beliefs on me, which I do not support. I would
>> be OK with this if the public repositories were free repositories, but
>> since I'm paying, I expect to be able to run my business how I want on a
>> paid services with obvious restrictions around abuse.
>

Drew DeVault <sir@cmpwn.com> writes:

> # Can I use an "open core" model?
>
> Yes, but you can only use sr.ht to host the "core" part of your
> project.

Responding on "open core" section even though my point is more general.

Personally, I would like to see more of a rational behind this change.
The usual contract I am used to is roughly: I give you money, you serve
my bits.  With restrictions on my bits not harming your business.  These
changes really push your beliefs on me, which I do not support.  I would

On Wed, May 20, 2020, at 23:23, silkmouse@cock.li wrote:
> On 2020-05-20 14:57, Drew DeVault wrote:
> > I would hope that you would respond the same when someone asks you to
> > buy into their ponzi scheme, if for their sake if nothing else.
> 
> How is Brave Rewards a ponzi scheme?


I don't think this thread is the correct place to debate Brave.  My comment really has nothing to do with brave but just expressing my personal expectations as a paying customer.

Drew DeVault <sir@cmpwn.com> writes:

> I would hope that you would respond the same when someone asks you to
> buy into their ponzi scheme, if for their sake if nothing else.

I would not response the same.    I don't know anything about Brave and
my comment doesn't really have much to do with the Brave..


-- 
  Malcolm Matalka
  Abiogenesis Computer Systems Lab

Hello, this email is not meant to ask for any behaviour change or
explanation or apology but just to state a position.

https://todo.sr.ht/~sircmpwn/sr.ht/243

The above ticket was opened today and the response was pretty curt.  I
don't really have an opinion one way or the other about the actual time
on it, but as a paying customer I would appreciate a more traditional
customer service etiquette.  If I were to post that item and got that
response, it would not have increased my loyalty.  It also provides a
stumbling block when I try to convince other people to become paying
customers.  If they were to come upon that ticket ask me what's the deal
with the tone, I wouldn't be able to defend it.

I do not know. I also do not know if the archive tools guarantee deterministic output.

-- 
  Malcolm Matalka
  Abiogenesis Computer Systems Lab

On Sat, Mar 7, 2020, at 14:16, Eternal Sorrow wrote:
> 
> On 3/7/20 11:07 PM, Malcolm Matalka wrote:
> > Eternal Sorrow <lynx1534@gmail.com> writes:
> >
> >> On 3/7/20 10:47 PM, Malcolm Matalka wrote:
> >>> Eternal Sorrow <lynx1534@gmail.com> writes:
> >>>

Eternal Sorrow <lynx1534@gmail.com> writes:

> On 3/7/20 10:47 PM, Malcolm Matalka wrote:
>> Eternal Sorrow <lynx1534@gmail.com> writes:
>>
>>>> When I download the tarball generated for Mercurial tag (for example
>>>> https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz), it has different
>>>> checksum every time I download it. Is there something that can be done
>>>> with this, so that the checksum would be consistent, like GitHub
>>>> downloads for example?
>>> Is anyone interested in this?
>> I don't believe hg archive guarantees the output will match between
>> runs, although you might get lucky.