Recent activity

buildsrht vs buildssrht 14 days ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

While packaging and deploying builds, I keep running into a confusion
regarding the extra "s". This causes issues, for example, with this hack:

The potential discrepancy is also a consistency issue in the
configuration TOML keys. What is the correct naming and usage throughout

Sourcehut on NixOS 17 days ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

We've recently merged initial Sourcehut support into a NixOS service:

The idea is that with a bit of configuration one can easily stand up the
suite of Sourcehut services. So far this is only on the master branch of
Nixpkgs, but a configuration (http://ix.io/3oYI, example only, secrets
are only for demo purposes) can be used to do a local container
deployment, or to a public server. Git/builds/lists/todo have been the
priority for and looking to ensure all services are included. I'd
appreciate any testing/feedback/bugs/etc to improve support. Still needs
more documentation: WIP is here: https://hydra.nixos.org/build/144800223/download/2/nixos/index.html#module-services-sourcehut

Example deployment:

Re: reply to thread doesn't thread emails (at least for gmail and some other email client users) 3 months ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

> Can you conduct some simple tests to see if adding a references header
> to the mailto URL makes Google behave correctly? If so, that's easy
> enough to add. Otherwise, it's as I said in private: an upstream
> problem.

I've tried to see if editing the gmail URL or mailto link would help;
it does not, the headers are not accepted/generated even if you
specify them in the url params in the expected way. So this is a
bug/feature-missing in gmail's interface. I'd love to be wrong on
this. Also tried adding "References", did not work.

Manually setting the correct headers, but still sending via gmail SMTP
does work.

Re: [builds.sr.ht] Images must be R/W 4 months ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

Update: Found the ./control file does need to be a normal file (due to
the readlink:
but I still ran into difficulties with the root.img.qcow2 being a symlink. Everything works as expected one I reify the symlinks. Not sure what the cause is for this one, perhaps qemu?

A good run: https://builds.srht.tomberek.info/~tomberek2/job/83

[builds.sr.ht] Images must be R/W 4 months ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

Are there any restrictions on the images directory structure?

When the qemu docker loads the qcow2 images, they must be R/W? Issues
with symlinks? Or if the ./control call is made from a read-only
directory structure? I'm still debugging this, but thought others may
have encountered some issue like this.

Context: I'm putting together a NixOS module for the sourcehut
ecosystem and have noticed failures when trying to use images when
everything is placed into the read-only store, but works fine when
copying it all to a read/write structure.

Re: builds.sr.ht with NixOS 4 months ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-discuss

Raphael, I am working on a NixOS module for the Sourcehut ecosystem, including builds. I’d appreciate an extra pair of eyes and anyone to test things out. 


Re: Interaction between meta and services using OAuth 2 years ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-dev

The alternate approach i mentioned turns out to be far simpler: just
use a hosts file to direct internal requests to a private interface,
while public interfaces can retain other authentication methods.
Tested this and it works well. No change needed upstream.

Interaction between meta and services using OAuth 2 years ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-dev

Hello, I'm working with eadwu to port sr.ht to NixOS and I ran into an
OAuth issue. The issue is that the origin= setting for meta is
overloaded. It is used both for links as well as for internal GET/POST
requests in core.sr.ht/srht/oath/blueprint.py line #31. For testing
and development purposes I’ve put some additional restrictions on my
all endpoints (basic auth and mTLS) that the python script cannot
reuse and thus it fails. It works if i remove those authentication
steps. It’s as if we should be able to independently express:

1) the uri of the meta service exposed to the user
2) the uri of the meta service exposed to internal scripts

In this manner, #1 impacts all the links that can be used by a browser
and inherit any security mechanisms in place. #2 can be a different

[PATCH] template: link to origin vs self-hosted 2 years ago

From Tom Bereknyei to ~sircmpwn/sr.ht-dev

Found hard-coded link while trying to self-host.

 metasrht/templates/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/metasrht/templates/index.html b/metasrht/templates/index.html
index a9cffd0..9952ed5 100644
--- a/metasrht/templates/index.html
+++ b/metasrht/templates/index.html
@@ -20,7 +20,7 @@
        Register here {{icon('caret-right')}}
[message trimmed]

WIP: shell.nix 2 years ago

From Thomas Bereknyei to ~sircmpwn/sr.ht-dev

Looks like nixpkgs is missing a few required python packages.
Needed to add singledispatch as explicit dependency for core.sr.ht.
This fails on setup.py with the "npm i" call.

- fix "npm i"
- use proper src
- backport dependencies to nixpkgs
- other python versions?
- meta descriptions

From 7f87eab0aa46f829b785e3efb8c4943c20f4bdf7 Mon Sep 17 00:00:00 2001
From: Tom Bereknyei <tomberek@gmail.com>
[message trimmed]