18 Feb 2019 |
Linda | 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. | 07:20:58 |
Linda | And some documentation updates, rewrote the changelog too. | 07:23:18 |
Linda |
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. | 07:31:45 |
Linda |
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
fi
# low priority trust anchor question
Now it is:
if find_bad_keys; then
# always show bad keys warning
# high priority trust anchor question
else
# low priority trust anchor question
fi
| 07:37:42 |
Linda | but it will remember the answer for the trust anchor question, anyway | 07:40:29 |
andrewsh | Linda: why i386 and amd64 only? | 07:46:39 |
Linda | Matrix.org doesn't have packages for other architectures. | 07:46:54 |
Linda | I guess one could fetch the sources from there, though. | 07:47:08 |
andrewsh | aren’t they all ? | 07:47:17 |
Linda | There's two checks: One at config time, one in the debian/control file. | 07:47:18 |
Linda | Oh, I meant they have no binary packages. | 07:47:49 |
Linda | only i386 and amd64 | 07:47:57 |
andrewsh | in any case, that makes no difference for your package | 07:48:20 |
Linda | I also don't think the create_source_list() function would work on anything but amd64 and i386 . | 07:48:29 |
andrewsh | it should be all | 07:48:33 |
andrewsh | why would it not? | 07:48:45 |
Linda | 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
i386|amd64)
# 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
;;
esac
| 07:51:42 |
Linda | I also don't differentiate, both deb and deb-src get activated | 07:53:28 |
Linda | But good point, I guess I could try to make it conditional to enable deb only if it's an architecture it knows about | 07:53:59 |
Linda | or just let APT guess | 07:54:10 |
| * Linda reverts it back to Architecture: all | 07:55:47 |
Linda | and removing this i386|amd64) case | 07:56:03 |
Maximus | Linda: lots of work I see! thank you very much. I will attempt build from your sources later today! | 07:57:56 |
andrewsh | I 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 | 07:58:19 |
Linda | I agree. I'm not sure what the sensible default is:
- A
medium priority debconf(1) question when we're not on i386 or amd64 ; or
- Disregard architecture for
sources.list .
| 08:02:14 |
Linda | I just said that wrong, but okay | 08:04:45 |
Linda | 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. | 08:07:24 |
Linda | Needed for the right value of lsb_release -cs . | 08:07:48 |
Linda | I'll still relax the requirements down to warnings. | 08:08:32 |
Linda | 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. | 09:06:54 |