| 15 Jan 2021 |
 uhoreg | I could do that, if you think that it's in a packageable state. | 16:30:51 |
| uhoreg | freeze is coming up soon, so it might be a good idea | 16:31:42 |
 kitsune | It definitely is, for a bit of time. But first libQuotient will have to be packaged (it's still libqmatrixclient even in unstable) | 17:33:26 |
| uhoreg | Yup. I was waiting for the next release of Quaternion before packaging libQuotient. Though someone else was interested in making a libQuotient package too, since Spectral is packaged. | 17:39:28 |
| kitsune | Spectral, and now Neochat. | 17:40:12 |
| kitsune | * Spectral, and now NeoChat. | 17:40:58 |
| kitsune | Arguably, NeoChat is currently the main driver, since the guys are determined to get it in as a default client for the KDE spin of Fedora. | 17:41:56 |
| kitsune | And the freeze for it is weeks away. | 17:42:35 |
|  lpoujol joined the room. | 21:19:20 |
| 16 Jan 2021 |
|  Hermógenes Oliveira left the room. | 00:12:05 |
 etbe | If you get a libQuotient package in unstable now that will reduce the time taken later on. Even if it's a bit rough, get something uploaded now and past the new package tests and update it later to fix the bugs. | 11:46:32 |
| kitsune | libQuotient 0.6 is stable for the last half a year; the problem is it has no applications using it that would be stable, until recently. Quaternion, for one, was dragging behind with the next release but beta 2 is rather good, and the upcoming beta 3 is even better in terms of stability (and either of them is definitely better than 0.0.9.4 by now). | 12:26:40 |
| etbe changed their display name from etbe (Russell Coker) to etbe. | 23:08:20 |
| 17 Jan 2021 |
|  Andres joined the room. | 06:36:06 |
| Andres | In reply to @hubert:uhoreg.ca
Yup. I was waiting for the next release of Quaternion before packaging libQuotient. Though someone else was interested in making a libQuotient package too, since Spectral is packaged. I'm planning to mess around with it Sunday evening | 06:40:03 |
|  Nik joined the room. | 10:56:22 |
| Nik | Hi there! Has anyone found the time to look into my access request on Salsa? I am packaging some bridge stuff, e.g. mautrix-telegram, and would really like to do that in the Debian Matrix team namespace | 10:57:12 |
| Nik | (But I can also use collab-maint if this is more desirable) | 10:57:49 |
| uhoreg | Nik: I've added you to the team | 15:36:00 |
| Nik | Thanks! | 15:38:55 |
| 18 Jan 2021 |
 RSS Bot [@hubert:uhoreg.ca] | Debian package news for matrix-synapse:
matrix-synapse 1.25.0-1 MIGRATED to testing | 04:44:14 |
| RSS Bot [@hubert:uhoreg.ca] | Debian package news for matrix-synapse:
matrix-synapse 1.25.0-1 MIGRATED to testing | 04:44:14 |
|  faust joined the room. | 08:16:02 |
|  jan left the room. | 09:54:05 |
| Andres | Redacted or Malformed Event | 10:20:22 |
| Andres | uhoreg: mind looking over my last libquotient commit on salsa before I upload to make sure you're happy with it? | 10:22:51 |
| Andres | actually, I guess it'll have to go through NEW anyways- I might as well just upload it | 10:43:16 |
| etbe | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977430 I would really appreciate it if this bug could be addressed in the Debian package of matrix-synapse. It's needed for proper SE Linux support of the daemon as we can't get the right label unless a per-daemon executable is used. | 15:00:20 |
| etbe | ExecStartPre=/usr/local/sbin/matrix-start-pre
ExecStart=/usr/local/sbin/matrix-start
I edited my /lib/systemd/system/matrix-synapse.service to have the above, those scripts are /bin/sh scripts that just do what the original ExecStartPre and ExecStart lines did. | 15:01:47 |
 andrewsh | sure | 15:16:29 |
