Page MenuHomePureOS Tracker

Please have matrix channel that gets pureos bug traffic from PureOS Tracker
Open, NormalPublic


would be great so one doesn't have to forward to the {dev,community}/pureos channels

Event Timeline

guido created this task.Feb 11 2021, 04:47
jeremiah.foster triaged this task as Normal priority.Feb 16 2021, 08:27
jeremiah.foster added a subscriber: jeremiah.foster.

Is this a Tracker <--> Matrix channel? We already have #dev/pureos-changes so you don't mean that channel I assume.

Do we need or want a channel from Gitlab to Matrix too?

guido added a comment.Feb 17 2021, 05:58

gitlab would be nice too but likely fine grained (e.g. calls -> calls channel, phosh/phoc/squeekboard -> phosh channel) - we had a bug for that somewhere in gitlab iirc, the above is about the pureos tracker only.

jeremiah.foster renamed this task from Please have matrix channel that gets pureos bug traffic to Please have matrix channel that gets pureos bug traffic from PureOS Tracker.Feb 17 2021, 11:16
jeremiah.foster claimed this task.
jeremiah.foster added a project: Restricted Project.

Phabricator's API is called conduit. I can pull data from conduit and it looks like this;


"id": "1001",
"phid": "PHID-TASK-4lpwd5rgworwzdwkbdg7",
"authorPHID": "PHID-USER-kcngpcgit2gapkthvlnm",
"ownerPHID": null,
"ccPHIDs": [
"status": "open",
"statusName": "Open",
"isClosed": false,
"priority": "Needs Triage",
"priorityColor": "violet",
"title": "amber: postgresql-common securit update blocked due to downstream changes",
"description": "As far as i can tell amber is lacking these security updates due to downstream changes in popstgresql-common:\n\n\n\nSee\n```\npostgresql-common \tbuster/updates amber-security \t200+deb10u3 \t200pureos1 \tRequires manual merge of downstream changes with source. \n```",
"projectPHIDs": [],
"uri": "",
"auxiliary": [],
"objectName": "T1001",
"dateCreated": "1613384648",
"dateModified": "1613384648",
"dependsOnTaskPHIDs": []


The id, status, title and description look suitable for dumping into a Matrix channel. Is that okay @guido or are you looking for something more?

Architecturally this should actually be implemented in such a way that a bugtracker change emits a new message on Laniakea's ZeroMQ-based message-bus, and that message is then picked up by the Matrix bot and relayed to the channel
that way, other consumers can pick up the messages as well and act on them for other purposes than showing a channel message (that's how automatic bug closing was implemented in the past, actually)
(but "in the past" means deep in the past where Trac was used for bugtracking)
The messages Laniakea sends are multipart-ZeroMQ messages with a header/subject in rDNS form, like and a JSON body with a few standardized fields and one freeform "data" part. The JSON part is signed with an Ed25519 signature from the messaging relay, so messages can be authenticated as correct
(message submission happens via a Curve25519-encrypted connection to a relay, from where they are distributed to interested parties)
and yes, this should absolutely be documented properly ;-)
Fortunately, the Laniakea Python module has helpers for this stuff so you don't have to touch it directly - in theory all this needs is a consumer of bug tracker events that submits them to the relay, and then the Matrix bot only needs to be told how to convert the messages into human-readable form

Code to send events is basically just:

emitter = EventEmitter(LkModule.TESTSUITE)
data = {'test': 'blahblah'}
emitter.submit_event('event-subject', data)

All provided the crypto secrets are present