Matrix on Debian

46 Members
https://wiki.debian.org/Matrix16 Servers

Load older messages

Timestamp Message
18 Feb 2019

Maximus: Hi hi, an update. This one took very long, messing around with gpg wasn't nice... UX improvements.

  • The question about APT trust anchor will be always asked now, if the "bad keys" (APT trust anchors) were removed. Previously, you had to dpkg-reconfigure for this. The default is still "false" to install it.
  • Split to matrix-archive-keyring and matrix-archive-sourcelist binaries, one source. matrix-archive-sourcelist is the APT sources.list(5) configuration and depends on matrix-archive-keyring. ** This was done to mark the matrix-archive-sourcelist package as i386 and amd64 architecture only. ** Since there was a package split, matrix-archive-sourcelist requires matrix-archive-keyring version 2015.12.09+debian0.12 or later.
  • All trust.gpg and trust.gpg.d files will now be scanned for Matrix.org's keys (except the one from this package 😉) for removal.

APT config files are still being overwritten (data loss in matrix-org.list), still looking for some kind of a solution.


And some documentation updates, rewrote the changelog too.


All trust.gpg and trust.gpg.d files will now be scanned for Matrix.org's keys (except the one from this package 😉) for removal

Not exactly true either. It must be *.gpg or *.asc, and must not be a symlink.


The question about APT trust anchor will be always asked now, if the "bad keys" (APT trust anchors) were removed.

So the previous logic was:

if find_bad_keys; then
    # always show bad keys warning

# low priority trust anchor question

Now it is:

if find_bad_keys; then
    # always show bad keys warning
    # high priority trust anchor question
   # low priority trust anchor question

but it will remember the answer for the trust anchor question, anyway

07:46:39@andrewsh:matrix.organdrewsh Linda: why i386 and amd64 only?

Matrix.org doesn't have packages for other architectures.


I guess one could fetch the sources from there, though.

07:47:17@andrewsh:matrix.organdrewsh aren’t they all?

There's two checks: One at config time, one in the debian/control file.


Oh, I meant they have no binary packages.


only i386 and amd64

07:48:20@andrewsh:matrix.organdrewshin any case, that makes no difference for your package

I also don't think the create_source_list() function would work on anything but amd64 and i386.

07:48:33@andrewsh:matrix.organdrewsh it should be all
07:48:45@andrewsh:matrix.organdrewshwhy would it not?

Well okay, it would. I forgot I don't use the Architecture option in the sources.list(5) file, and I wouldn't use $(ARCH) anyway.

I can change it back to all, but then you'd hit this piece of code:

# Matrix.org has supplemental packages for i386 and amd64 architectures only.
case "$(dpkg --print-architecture)" in
        # Try to remember the previous choices to debconf(1) questions, even if
        # it's cache is gone.
        # The other way of thinking this is if the sysadmin attempted to
        # configure APT data sources manually before installing
        # matrix-archive-sourcelist, we'll suggest "yes" as the default.
        [ -e "$APT_SOURCESLIST_M" ] && \
            db_set matrix-archive-keyring/sources.list "true"
        db_input high matrix-archive-keyring/sources.list || true
        db_go || true

        echo "Unsupported architecture; refusing to configure APT." >&2

I also don't differentiate, both deb and deb-src get activated


But good point, I guess I could try to make it conditional to enable deb only if it's an architecture it knows about


or just let APT guess

07:55:47* @lindalap:matrix.orgLinda

reverts it back to Architecture: all


and removing this i386|amd64) case

07:57:56@max:kamax.ioMaximusLinda: lots of work I see! thank you very much. I will attempt build from your sources later today!
07:58:19@andrewsh:matrix.organdrewshI see now what you meant, matrix.org only publish packages for two arches — nevertheless since you’ve split the packages anyway, I think the users should be able to enable them if they want since we don’t know if the set of architectures changes in the future

I agree. I'm not sure what the sensible default is:

  1. A medium priority debconf(1) question when we're not on i386 or amd64; or
  2. Disregard architecture for sources.list.

I just said that wrong, but okay


andrewsh: You should also know there's some lsb_release -is checks if it's Debian or Ubuntu, because that breaks the sources.list generation more than anything right now.


Needed for the right value of lsb_release -cs.


I'll still relax the requirements down to warnings.


Explicitly opting into sources.list didn't make much sense anymore with contrib and seperating the package, so I toggled the default to true and lowered the priority to medium.

Non-Ubuntu and non-Debian users still get a high-priority input for that same question, because we don't know if it will work.

There are no newer messages yet.

Back to Room List