Orion arm



Last active a day ago


Last active 13 days ago


Last active a month ago


Last active 1 year, 24 days ago


Last active 1 year, 1 month ago


Last active 1 year, 2 months ago
View more

Recent activity

Re: [PATCH core.sr.ht] fix scripts disappearing after pyproject.toml conversion 18 hours ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-dev

Thanks! (I tagged a new release)

to git@git.sr.ht:~sircmpwn/core.sr.ht
  24f65f7..34213d6  master -> master

Re: mh? a day ago

From Conrad Hoffmann to ~bitfehler/public-inbox


On 5/24/24 12:05 AM, David Arnold wrote:
> While it doesn’t address all of your desires, did you ever investigate mh / nmh as a local mail format?

Yes. It has some really good ideas, but my main issue is that it claws 
all mail out of your maildir into it's own storage. I can relate, as I'd 
say the mh storage format is probably still somewhat better than 
maildir, but then you're basically stuck with using the mh tools. And 
the format is not quite good enough to me to make such a concession (or 
try to build tooling on top of it).

It's all very subjective of course. If you don't care about certain 
use-cases, mh looks like some pretty good tooling (I never tried it,

[PATCH man.sr.ht] Preparations for PEP440 support 4 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-dev

Currrently, builds for patches are broken because the version numbers
generated for them are not valid according to PEP 440 [1].

This has to be solved in several steps, in coordination with the
packaging code. Procedure will be the same as for core.sr.ht:


The only difference is that the extra build step (running `make`) will
remain in `setup.py` (as there is no generic mechanism for this in
`pyproject.toml`). This just means the build process will still always
have to be performed with setuptools as backend.

[1] https://peps.python.org/pep-0440
[message trimmed]

[PATCH core.sr.ht] Makefile: consistently use $(MODULE) 5 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-dev

The target in question currently seems to not cause any issues, but it
does when switching dependents to the modern Python module structure,
where the build tools will build the package in a temporary virtual
 srht/Makefile | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/srht/Makefile b/srht/Makefile
index 8c034fc..1179775 100644
--- a/srht/Makefile
+++ b/srht/Makefile
@@ -26,9 +26,8 @@ $(MODULE)static/main.css: scss/*.scss ${SRHT_PATH}/scss/*.scss
	sassc -I${SRHT_PATH}/scss scss/main.scss $@
[message trimmed]

[PATCH scm.sr.ht] Preparations for PEP440 support 6 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-dev

Currrently, builds for patches are broken because the version numbers
generated for them are not valid according to PEP 440 [1].

This has to be solved in several steps, in coordination with the
packaging code. Just as was done with core.sr.ht, the plan is:

1. Add a pyproject.toml without touching setup.py (this commit)
2. Switch APKBUILD from `python setup.py build` to `python -m build`
3. Reduce setup.py to a stub, encoding all relevant information in

With this commit, this module can be build with both `python setup.py
build` and `python -m build`, if, _and only if_ the PKGVER environment
variable is set, which is true for all our tooling.
[message trimmed]

Re: vomit v0.7.0 compile error 13 days ago

From Conrad Hoffmann to ~bitfehler/vomit


On 5/7/24 6:08 AM, Adam House wrote:
> Trying to run `cargo install vsync` right now revealed this problem to me when
> compiling vomit as a dependency of it:

I can indeed reproduce this. I am pretty sure it comes from a change in 
the mailparse crate, which is not pinned pretty specifically in vomit's 
Cargo.toml, but I was somehow under the impression that for binaries, 
the Cargo.lock should handle this...

At any rate, I have spent the past months rewriting large swathes of 
vsync, and it's almost ready for publishing. Among many other things, it 
will get rid of the vomit dependency anyways. Hence, I am reluctant to

[PATCH scm.sr.ht] Overwrite fragment of source spec if needed 14 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-dev

Currently, `_add_commit_id_fragment()` only tests if the `basename()` of
the sources spec matches the repo name. However, if a manifest contains
e.g. the source `https://git.sr.ht/~foo/repo#main`, the `basename()` is
"repo#main" and will not match the repo name "repo".

This causes problems, as automatically generated Manifests for patch
submissions may end with two source specs referencing the same repo,
causing the clone stage to fail.

A better approach was already taken in `_auto_setup_auto_source()` a few
lines above: properly parsing the URL and calling `basename()` only on
the path. Applying the same approach here fixes the issue.
 scmsrht/submit.py | 6 ++++--
[message trimmed]

Re: git repository has vanished 14 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-discuss

On 5/13/24 4:18 PM, Divya Ranjan wrote:
> I have a personal website of mine[0] hosted on sourcehut pages, I created about an year or more ago because I wanted to not rely on anything like GitHub for its proprietary ties. For one reason or another, I was not able to keep up with updating the page. Life happened. Now, when I started looking for the page's git repo[1], I see nothing!
> This is absurd to me, since I checked my local directory and it didn't have a copy either and I wondered it's probably me who must've deleted it or something. But how could the remote repository be removed? It's not even removed, it shows the repository was added 1y3m ago, it just has nothing on it.
> The website it links to is the correct one, and something more absurd to me is that the page loads the last updated version of the git repo. So, if my sourcehut doesn't have the latest repo where is it loading the pages from?
> I pay for the domain every year despite my financial situation, so I'd really not like to lose the website. And especially out of no fault from my side, there can't be because I haven't updated it in a long time! So I haven't really checked or done anything with the repo since then, and how could something happen to it without me doing anything?

Could you kindly send this email again to the support address? It is 
~sircmpwn/sr.ht-support@lists.sr.ht - there we can track this better and 
will look into it!

Re: 403 Forbidden on login attempt 14 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-discuss


On 5/13/24 3:34 AM, mieum@tilde.team wrote:
> I can no longer login to sr.ht. I always get a 403 Forbidden message
> that says:
>> You don't have the permission to access the requested resource. It is
>> either read-protected or not readable by the server.

Can you please send an email to ~sircmpwn/sr.ht-support@lists.sr.ht 
about this, ideally stating the IP address you are trying to access the 
service from? I think you may have accidentally ended up on a blocked 
subnet. On the support list we can properly track this and sort it out 
for you.

Re: two (conflicting) sources for same repo if it has a branch suffix 14 days ago

From Conrad Hoffmann to ~sircmpwn/sr.ht-discuss

On 5/4/24 11:12 PM, raingloom@riseup.net wrote:
> 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.

Yeah, it looks like it. I recommend you remove the branch suffix for 
now, as it just points to your default branch anyway. I'll submit a fix