Hi Jeremiah,

Perhaps we can set up ourselves the tooling we need? Is there a way we can use the server at 45.33.86.90 to enable the PureOS changes notifications?

I mean, ideally we would not like to start relying on third-party infrastructure especially as we had previous discussed not relying too much on this particular machine so we can blow it away and reset at any point… But to be honest, after so long there is a strong argument for just getting anything up and running.

However if I'm not in the chat rooms I feel I miss things, I also am easily distracted by other issues that pop-up there, to the detriment of my communication via email.

Indeed, I agree completely. I further get a low-level "fear of missing out" feeling every time I am there and is acutely stressful when trying to follow all the scrollback. So, can we try pushing more chat conversations to this list? Just throwing out a random/strong idea, but perhaps if we find ourselves writing more than a few sentences we should notice that and then force ourselves — at least at first — to pause the conversation there and insist we/others resume it here? We don't need to write long, well-worded messages so the additional investment should really just be the extra time needed to fill in the "To:" field. :) Best wishes, -- Chris Lamb https://puri.sm

Am Mi., 3. Juli 2019 um 16:48 Uhr schrieb Chris Lamb <chris.lamb@puri.sm>:

Chris Lamb wrote:

...

I'm generally not one to send "me too" or "+1" emails, but I will get over my usual reticence that here to underline that this would be great.

How can I help?

Very gentlest of reminders on this thread/question? :)

In theory you could start writing the "Mirk" Matrix bot - I have not looked into how to do that uch yet, but there are some Python modules to help with creating it. I could also add a simple project template to the Laniakea repository. All the bot will do is to subscribe to a ZeroMQ publisher socket on a Lighthouse relay and listen to the stream of events, publishing the information it find interesting to the channels it is in. The event publishing is something I am currently writing, the first step was to add a few unittests for Lighthouse last weekend - because I will not write this feature without at least a basic level of testing, now that that's possible easily in the Laniakea repo. So, each message that any subscriber to the event stream receives will have the following format: ```json { "id": "_lk.modulename.eventname", "format": "1.0", "time": "<timestamp>", "origin": "<machine_name>", "author": "<message author>", "data": { "key1": "value1" } "signatures": { "<entity>": { "ed25519:<key_id>": "<base64_signature>" } } } ``` id: This is the type identifier of the message, also repeated in the ZeroMQ multipart message, to allow clients to efficiently subscribe to events. It follows a reverse-DNS scheme, with the "_lk" "domain" being reserved for Laniakea built-in modules. The modulename is the name of the module, the event is an event identifier. A valid ID could be for example: "_lk.synchrotron.package-synced" format: Message format, always 1.0 until it's changed. There only for future-proofing. time: Timestamp (will likely be ISO 8601) of when the message was emitted. origin: Optional entry showing from which machine (hostname) the message originated. author: Optional entry denoting a user or other entity who triggered the event emission data: Arbitrary payload, with format matching the event id (e.g. a "_lk.synchrotron.package-synced" event will most certainly carry the information which package was synced from where to where) signatures: ED25519 signatures of services which have seen this message and have emitted it. This will be the original sender of the event as well as a signature of the Lighthouse relay which has re-emitted the message. The basic flow of information is source-relay-sink: laniakea-module --> lighthouse-relay ---> many message consumers A module can also be both consumer and emitter of events. Ultimately, the goal of this is to make the archive react to changes faster and get rid of a bunch of cronjobs. The Matrix bot is more of a byproduct (and a very nice piece for testing the feature, once it's implemented). Once the feature is finished, you'll be able to find a more sophisticated writeup of this mail in the documentation as well. All in all, I am not sure how much people can help me with implementing this, but at least for package upload information subscribing to pureos-changes will get you the data as emails. Cheers, Matthias

Am Mi., 3. Juli 2019 um 22:46 Uhr schrieb Chris Lamb <chris.lamb@puri.sm>:

Hi Matthias,

...

...

...

How can I help?

Very gentlest of reminders on this thread/question? :)

[..]

Neat, thanks for writing this! I've done a quick skim of it but will re-read it soon, likely tomorrow. In the meantime:

...

but at least for package upload information subscribing to pureos-changes will get you the data as emails.

Jeremiah, what can we do sysadmin-wise to get notifications regarding Git pushes to our source.puri.sm Gitlab instance?

Oh yeah, that particular information should get piped through Laniakea eventually to inform it about changes to Git repositories and trigger automatic source package builds, but it's not actually in the immediate scope to be implemented. Having some really dumb run-off-the-mill GitLab bot for it right now would do the trick well, I think. Cheers, Matthias

Hi Matthias,

...

Jeremiah, what can we do sysadmin-wise to get notifications regarding Git pushes to our source.puri.sm Gitlab instance? […] Having some really dumb run-off-the-mill GitLab bot for it right now would do the trick well,

Mmm indeed… but even a (as you describe it) "really dumb" thing has seemingly taken over a year to be actioned by the sysadmins. ;) Best wishes, -- Chris Lamb https://puri.sm