Bug#951838: mktorrent: -p option typo "dissalow" [sic] in mktorrent(1) man page
Package: mktorrent Version: 1.1-1 Severity: minor Dear maintainer, notice the following typo on the man page (`man 1 mktorrent`) (sic): > -p > >set the private flag (dissalow DHT and Peer Exchange) It should instead say "disallow". -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mktorrent depends on: ii libc6 2.29-10 ii libssl1.1 1.1.1d-2 mktorrent recommends no packages. mktorrent suggests no packages. -- no debconf information
Bug#949103: default log level is too low
control: tags -1 + moreinfo + confirmed I'll summarize what was discussed in #matrix-debian:matrix.org so far. This was the original bug: https://bugs.debian.org/927057 andrewsh@ argued (suggested) OP hadn't suggested an acceptable configuration, which wouldn't reintroduce #927057 as an issue again. Quote: > The defaults should provide sane settings for a majority of users, but > the synapse's defaults don't, they're good for those who want or have > to tinker with the setup > You can't just leave synapse running with those logging settings and > forget about it > so as I said, if we want to come to a mutually useful solution, could > you please give me a combination of logging levels that doesn’t fill > up the disk space with useless debugging _but_ provides useful data > for you I and another user suggested logging "desperately needs love" at upstream, so considerably this is an upstream issue as well with everything (debug information) being logged at INFO level with high IO and disk space requirements. OP argues: > "turn everything off" is not considered useful > Please please please reconsider the default logging level, or at least > do your best to help users increase the logging before they come to us > for support. We (in the Matrix room) all seem to understand OP's frustration with the inability to support Debian package users out of the box or decreased user experience of "Debian is doing things differently". (Re: "do your best to help users increase the logging before they come to us", I still believe this is fundamentally an upstream issue to resolve too.) A brief suggestion came up to ship a Debian package with two different logging configurations. (I'm personally against this idea, for the sake of maintaining simplicity.) There were also some arguments about some WARNING and ERROR messages not being useful (debug-like information). (Some of these were already fixed upstream some releases ago.) andrewsh@ said to collect some data to decide better about the appropriate logging levels, and what changes might be required upstream.
Bug#941766: RFP: sblg -- static blog utility
Package: wnpp Severity: wishlist * Package name: sblg Version : 0.5.7 Upstream Author : Kristaps Dzonsons * URL : https://kristaps.bsd.lv/sblg/ * License : ISC Programming Lang: C Description : static blog utility It's dead simple. > sblg is a utility for creating static blogs. It knits together > articles with templates to generate static HTML files, Atom feeds, and > JSON files. It's built for use with make(1). No PHP, no database: just > a simple UNIX tool for pulling data from articles and populating > templates. The ever so popular `jekyll` and `hugo` packages (available in Debian) are big, considerably even over-engineered static HTML site generators. They use Markdown for generating documents, instead of HTML that sblg uses. For an argument against Markdown, see: https://undeadly.org/cgi?action=article=20170304230520 Additionally, due to Markdown's syntax limitations, static generated blogs with `jekyll` or `hugo` might not be able to use HTML description lists and embed images, or they do with some Markdown extensions or by embedding HTML into the Markdown source. sblg has been actively maintained since 2014: https://kristaps.bsd.lv/sblg/archive.html The lowdown utility from the same upstream author is not required for sblg, but may compliment it to add Markdown translation support. The upstream's BSD.lv projects include other notable projects (for BSD), such as acme-client, openrsync and mandoc.
Bug#921425: matrix-synapse: please preload libjemalloc to reduce memory consumption
Control: tags -1 + moreinfo Control: severity -1 wishlist On Fri, Feb 08, 2019 at 09:00:00PM +, Linda Lapinlampi wrote: > Smart ideas may not always be smart in the end. I think you'd be better > off convincing to switch the malloc(3) system call to use jemalloc(3) > everywhere, if the benefits are so good as claimed. > > You can do you by adjusting the variables in your environment. Also, If the uploader doesn't object or other discussion follow up to this in the next few weeks, I'd like to kindly recommed closing this Debian Bug# as "wontfix" soon. Thanks.
Bug#927990: sway: possibly missing libgl1-mesa-dri dependency
Source: sway Version: 1.0~rc3-1 Severity: normal Tags: experimental Dear Maintainer, an issue was reported on upstream's issue tracker about this Debian package not working out of the box on Intel GMA950 graphics: https://github.com/swaywm/sway/issues/4061 libgl1-mesa-dri may be missing from this Debian package's runtime dependencies, although I've not attempted to reproduce the issue myself yet. (This may be an issue for wlroots package instead.)
Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect
Control: reassign -1 scdoc 1.9.4-1 Control: affects -1 + sway Severity: serious On Thu, Apr 25, 2019 at 03:07:14AM +, Linda Lapinlampi wrote: > Dear Maintainer, > > My attempt to build Salsa VCS checkout with `dpkg-buildpackage -us -uc` > will fail there: > > ``` > Dependency scdoc found: YES 1.9.4 > Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0 > /usr/local/bin/scdoc > Got pkgconfig variable scdoc : /usr/local/bin/scdoc > Program /usr/local/bin/scdoc found: NO > > meson.build:100:1: ERROR: Program(s) ['/usr/local/bin/scdoc'] not found or > not executable > ``` For whatever the reason, /usr/share/pkgconfig/scdoc.pc has an unintended prefix=/usr/local. scdoc 1.9.4's debian/rules hsa PREFIX=/usr, but this may not be working.
Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect
Control: notfound -1 1.0~rc3-1 On Thu, Apr 25, 2019 at 03:07:14AM +, Linda Lapinlampi wrote: > ``` > Dependency scdoc found: YES 1.9.4 > Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0 > /usr/local/bin/scdoc > Got pkgconfig variable scdoc : /usr/local/bin/scdoc > Program /usr/local/bin/scdoc found: NO > > meson.build:100:1: ERROR: Program(s) ['/usr/local/bin/scdoc'] not found or > not executable > ``` Possibly relevant change at upstream. Not found from upstream's 1.0~rc5 release, I'd guess. https://github.com/swaywm/sway/pull/3856 > meson: use pkg-config var for scdoc path
Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect
Source: sway
Version: 1.0-1
Severity: important
Tags: experimental, ftbfs, upstream
Dear Maintainer,
My attempt to build Salsa VCS checkout with `dpkg-buildpackage -us -uc`
will fail there:
```
Dependency scdoc found: YES 1.9.4
Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0
/usr/local/bin/scdoc
Got pkgconfig variable scdoc : /usr/local/bin/scdoc
Program /usr/local/bin/scdoc found: NO
meson.build:100:1: ERROR: Program(s) ['/usr/local/bin/scdoc'] not found or not
executable
```
It looks like it finds /usr/bin/scdoc, but then pkg-config changes to
look for /usr/local/bin/scdoc and subsequently fails.
The relevant part of upstream's meson.build is:
```
scdoc = dependency('scdoc', version: '>=1.9.2', native: true, required:
get_option('man-pages'))
if scdoc.found()
scdoc_prog = find_program(scdoc.get_pkgconfig_variable('scdoc'),
native: true)
[...]
endif
```
I'm attaching Meson build logs. Thanks.
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
$ apt policy scdoc
scdoc:
Installed: 1.9.4-1
Candidate: 1.9.4-1
Version table:
*** 1.9.4-1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
Build started at 2019-04-25T02:45:02.424601
Main binary: /usr/bin/python3
Python system: Linux
The Meson build system
Version: 0.49.2
Source dir: /home/wub/.local/src/sway/sway
Build dir: /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu
Build type: native build
Project name: sway
Project version: 1.0
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.c -o /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.exe
Sanity check compile stdout:
-
Sanity check compile stderr:
-
Running test binary command: /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.exe
Appending CFLAGS from environment: '-g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security'
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,-z,now'
Appending CPPFLAGS from environment: '-Wdate-time -D_FORTIFY_SOURCE=2'
Native C compiler: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.6.0)
Determining dependency 'json-c' with pkg-config executable '/usr/bin/pkg-config'
Called `/usr/bin/pkg-config --modversion json-c` -> 0
0.13.1
Called `/usr/bin/pkg-config --cflags json-c` -> 0
-I/usr/include/json-c
Called `/usr/bin/pkg-config json-c --libs` -> 0
-L/usr/lib/x86_64-linux-gnu -ljson-c
Called `/usr/bin/pkg-config json-c --libs` -> 0
-ljson-c
Running compile:
Working directory: /tmp/tmp7u9sl240
Command line: cc /tmp/tmp7u9sl240/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -o /tmp/tmp7u9sl240/output.exe -g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -O0
Code:
#include
int main(int argc, char **argv) {
printf("%ld\n", (long)(sizeof(void *)));
return 0;
};
Compiler stdout:
Compiler stderr:
Program stdout:
8
Program stderr:
Running compile:
Working directory: /tmp/tmp0zuflusu
Command line: cc /tmp/tmp0zuflusu/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -c -o /tmp/tmp0zuflusu/output.obj -g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O0 --print-search-dirs
Code:
Compiler stdout:
install: /usr/lib/gcc/x86_64-linux-gnu/8/
programs: =/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/
libraries:
Bug#927918: sway: ambiguous version dependency on wlroots
Source: sway Version: 1.0-1 Severity: normal Tags: upstream Dear Maintainer, debian/control has Build-Depends on libwlroots-dev (>= 0.5). Upstream's release notes for tag 1.0 says the release depends on wlroots 0.5. meson.build depends on wlroots_version = '>=0.4.1'. meson.build also remains at >=0.4.1 in upstream master branch (post-1.0 release). As you can see, there's two conflicting informations for for the required wlroots version from upstream sources. https://github.com/swaywm/sway/releases/tag/1.0 Which wlroots dependency version is really required for Debian? -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927915: sway: build-adep has no version >= 0.48.0 on meson
Source: sway Version: 1.0-1 Severity: normal Tags: stretch, jessie Control: notfound -1 1.0~beta.2-3 Control: found -1 1.0~rc1-1 Dear Maintainer, meson.build declares project(meson_version: '>=0.48.0') in the source, but debian/control file omits this version number from Build-Depends. Please consider adding the dependent version number to debian/control, thanks. (I am using the Salsa VCS checkout, prior to NEW queue upload.) -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927844: matrix-synapse: Lintian incorrect-path-for-interpreter warning
Control: tags -1 + patch Please forward the following Git patch to upstream if you could, I don't have a GitHub account or other contact with the upstream. (I'm also personally banned from all of New Vector's Matrix.org rooms directly for silly reasons.) I'm also including the DEP-3 formatted patch for Debian. Description: Fix Lintian warning incorrect-path-for-interpreter Origin: vendor, https://bugs.debian.org/927844 Bug-Debian: https://bugs.debian.org/927844 Forwarded: no Author: Linda Lapinlampi Last-Update: 2019-04-24 --- a/scripts/sync_room_to_group.pl +++ b/scripts/sync_room_to_group.pl @@ -1,4 +1,4 @@ -#!/usr/bin/env perl +#!/usr/bin/perl use strict; use warnings; >From 6530ef5cbdb00eba10cbf298252f74405519c9c3 Mon Sep 17 00:00:00 2001 From: Linda Lapinlampi Date: Wed, 24 Apr 2019 03:43:54 + Subject: [PATCH] scripts: Fix Lintian incorrect-path-for-interpreter warning Replace /usr/bin/env with a direct path to the Perl interpreter under /usr/bin. Bug-Debian: https://bugs.debian.org/927844 See: https://lintian.debian.org/tags/incorrect-path-for-interpreter.html --- scripts/sync_room_to_group.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/sync_room_to_group.pl b/scripts/sync_room_to_group.pl index f0c2dfadf..be68c153e 100755 --- a/scripts/sync_room_to_group.pl +++ b/scripts/sync_room_to_group.pl @@ -1,4 +1,4 @@ -#!/usr/bin/env perl +#!/usr/bin/perl use strict; use warnings; -- 2.20.1
Bug#927844: matrix-synapse: Lintian incorrect-path-for-interpreter warning
Package: matrix-synapse Version: 0.99.2-3 Severity: normal Control: found -1 0.28.1+dfsg-1 Tags: upstream Dear Maintainer, Lintian throws a incorrect-path-for-interpreter warning for this package. It seems this package hasn't received much love to Lintian between the releases. I'm opening this issue to contribute a DEP-3 formatted patch to the package about Lintian warning incorrect-path-for-interpreter momentarily. I intend to collaborate making this package Lintian free. Expect a patch in my next message to this Debian Bug.
Bug#927842: matrix-synapse: Lintian privacy-breach-generic warnings
Package: matrix-synapse Version: 0.99.2-3 Severity: important Control: found -1 0.28.1+dfsg-1 Tags: help, upstream Dear Maintainer, Lintian throws a privacy-breach-generic warnings as follows: usr/lib/python3/dist-packages/synapse/res/templates/notif.html [https://vector.im/beta/img/50e2c2.png; />] (https://vector.im/beta/img/50e2c2.png) usr/lib/python3/dist-packages/synapse/res/templates/notif.html [https://vector.im/beta/img/76cfa6.png; />] (https://vector.im/beta/img/76cfa6.png) usr/lib/python3/dist-packages/synapse/res/templates/notif.html [https://vector.im/beta/img/f4c371.png; />] (https://vector.im/beta/img/f4c371.png) usr/lib/python3/dist-packages/synapse/res/templates/notif_mail.html [http://matrix.org/img/matrix-120x51.png; width="120" height="51" alt="[matrix]"/>] (http://matrix.org/img/matrix-120x51.png) usr/lib/python3/dist-packages/synapse/res/templates/notif_mail.html [http://matrix.org/img/riot-logo-email.png; width="83" height="83" alt="[riot]"/>] (http://matrix.org/img/riot-logo-email.png) usr/lib/python3/dist-packages/synapse/res/templates/notif_mail.html [http://matrix.org/img/vector-logo-email.png; width="64" height="83" alt="[vector]"/>] (http://matrix.org/img/vector-logo-email.png) usr/lib/python3/dist-packages/synapse/res/templates/room.html [https://vector.im/beta/img/50e2c2.png; />] (https://vector.im/beta/img/50e2c2.png) usr/lib/python3/dist-packages/synapse/res/templates/room.html [https://vector.im/beta/img/76cfa6.png; />] (https://vector.im/beta/img/76cfa6.png) usr/lib/python3/dist-packages/synapse/res/templates/room.html [https://vector.im/beta/img/f4c371.png; />] (https://vector.im/beta/img/f4c371.png) usr/lib/python3/dist-packages/synapse/static/client/register/index.html
Bug#927057: 1Gb of logs is too much
One can also adjust /etc/matrix-synapse/log.yaml, but I agree some change should be made to debian/log.yaml (default configuration file) to reduce the maximum size of logs stored and/or log level to WARN (WARNING). I also agree the logs should be compressed on daily rotation, but it remains unclear to me how one would change this in Synapse without big hacky behaviors. Preferably I'd use logrotate(8) if at all possible. This might be helpful: https://docs.python.org/3/library/logging.handlers.html So maybe change logging.handlers.RotatingFileHandler in debian/log.yaml to WatchFileHandler (use with logrotate(8)) if I've understood correctly. TimedRotatingFileHandler is an alternative to let Python manage log rotation by itself, but no logs will be compressed then.
Bug#927181: matrix-synapse: hard to troubleshoot
On Wed, Apr 24, 2019 at 02:46:24AM +0300, sergio wrote: > On 24/04/2019 02:11, Linda Lapinlampi wrote: > > What would you propose to be fixed in the Debian package? > > Instead of eating stderr to devnul, initscript must show it to the > terminal. I took a look, and it may seem to be that this is configured from /etc/matrix-synapse/log.yaml. This change by andrewsh may be relevant: https://salsa.debian.org/matrix-team/matrix-synapse/commit/ff086b91c0c7a34ab2167178174cbe3978bd442e Upstream seems to log to file and console handlers. Debian logs to file and journal. I don't think it's uncommon for running daemons to fail to journalctl (on systemd) "quietly". If this is an issue with sysvinit/non-systemd inits only, then I can agree there's a possible issue to fix.
Bug#927838: matrix-synapse: purging package does not remove dpkg-statoverride and daemon user
Package: matrix-synapse Version: 0.28.1+dfsg-1 0.99.2-3 Severity: normal Dear Maintainer, the debian/postrm script does not remove the matrix-synapse user and the dpkg-statoverride path. These are created in the debian/postinst script. They should be removed when the package is removed or purged from the system. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927837: matrix-synapse: deprecated dpkg-statoverride --force option in postrm
On Tue, Apr 23, 2019 at 11:35:25PM +, Linda Lapinlampi wrote: > for DIR in /var/lib/matrix-synapse /var/log/matrix-synapse > /etc/matrix-synapse; do > if ! dpkg-statoverride --list --quiet $DIR >/dev/null; then > dpkg-statoverride --force --quiet --update --add $USER nogroup 0755 > $DIR > fi > done This is pretty unsafe anyway, just ran into this on reinstall (after fiddling with removing some directories): Get:1 http://deb.debian.org/debian sid/main amd64 matrix-synapse all 0.99.2-3 [701 kB] Fetched 701 kB in 0s (3236 kB/s) Preconfiguring packages ... dpkg: unrecoverable fatal error, aborting: unknown system user 'matrix-synapse' in statoverride file; the system user got removed before the override, which is most probably a packaging bug, to recover you can remove the override manually with dpkg-statoverride E: Sub-process /usr/bin/dpkg returned an error code (2) Probably has to do with the daemon user bug, not being removed?
Bug#927837: matrix-synapse: deprecated dpkg-statoverride --force option in postrm
Package: matrix-synapse Version: 0.99.2-3 Severity: normal Tags: buster Dear Maintainer, dpkg-statoverride --force option is deprecated (since dpkg 1.19.5) and is replaced by --force-all instead. First time install (and only the first time install due to Bug#927445 and another bug about not removing the matrix-synapes user) prints a warning about this deprecated option. for DIR in /var/lib/matrix-synapse /var/log/matrix-synapse /etc/matrix-synapse; do if ! dpkg-statoverride --list --quiet $DIR >/dev/null; then dpkg-statoverride --force --quiet --update --add $USER nogroup 0755 $DIR fi done -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages matrix-synapse depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libjs-jquery 3.3.1~dfsg-3 ii libpython3-stdlib 3.7.3-1 ii lsb-base 10.2019031300 ii python33.7.3-1 ii python3-attr 18.2.0-1 ii python3-bcrypt 3.1.6-1 ii python3-canonicaljson 1.1.4-2 ii python3-daemonize 2.4.7-2 ii python3-distutils 3.7.3-1 ii python3-frozendict 1.2-1 ii python3-jsonschema 2.6.0-4 ii python3-msgpack0.5.6-1+b1 ii python3-nacl 1.3.0-2 ii python3-netaddr0.7.19-1 ii python3-openssl19.0.0-1 ii python3-phonenumbers 8.9.10-1 ii python3-pil5.4.1-2 ii python3-prometheus-client 0.6.0-1 ii python3-psutil 5.5.1-1 ii python3-pyasn1 0.4.2-3 ii python3-pyasn1-modules 0.2.1-0.2 ii python3-pymacaroons0.13.0-2 ii python3-service-identity 16.0.0-2 ii python3-signedjson 1.0.0+git20151019-2 ii python3-six1.12.0-1 ii python3-sortedcontainers 2.0.4-1 ii python3-systemd234-2+b1 ii python3-treq 18.6.0-0.1 ii python3-twisted18.9.0-3 ii python3-unpaddedbase64 1.1.0-4 ii python3-yaml 3.13-2 Versions of packages matrix-synapse recommends: ii python3-bleach3.1.0-1 ii python3-jinja22.10-2 ii python3-lxml 4.3.3-1 ii python3-psycopg2 2.7.7-1 Versions of packages matrix-synapse suggests: pn python3-txacme -- debconf information: * matrix-synapse/server-name: localhost * matrix-synapse/report-stats: false
Bug#927181: matrix-synapse: hard to troubleshoot
Control: tags -1 + moreinfo On Tue, Apr 16, 2019 at 02:57:45AM +0300, sergio wrote: > # su matrix-synapse > $ python3 -m "synapse.app.homeserver" --config-path > /etc/matrix-synapse/homeserver.yaml --config-path > /etc/matrix-synapse/conf.d/ > > Missing lxml library. This is required for URL preview API. > > Install by running: > sudo apt install python3-lxml Hi. This package has "Recommends: python3-lxml" already, and it's not a hard dependency to run Synapse per se. url_preview_enabled defaults to False in default homeserver configuration from Debian (according to debian/homeserver.yaml file). What would you propose to be fixed in the Debian package? As far as I'm concerned, upstream makes at least an effort to tell you need to install python3-lxml if it's missing with url_preview_enabled option enabled. APT should also install recommended packages by default, unless the sysadmin makes changes to APT::Install-Recommends option or passes the --no-install-recommends option to apt install command.
Bug#922357: internetarchive: new upstream version available
Control: notfixed -1 1.8.3-1 Control: tags -1 - fixed-in-experimental 1.8.4 has been released and 1.8.5 is to be released eventually, heads up. Thank you for the previous upload to experimental!
Bug#927734: scdoc: New upstream version available
Source: scdoc Severity: wishlist Control: block 927723 by -1 Dear Maintainer, please package the latest upstream version of scdoc available. Packaging sway 1.0 (currently 1.0~rc3) depends on scdoc >= 1.9.2. As of right now, the latest version available from upstream is 1.9.4: https://git.sr.ht/~sircmpwn/scdoc/refs/1.9.4 See: https://git.sr.ht/~sircmpwn/scdoc/refs -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#927723: sway: Please upload new upstream version
On Mon, Apr 22, 2019 at 03:13:00AM +, Linda Lapinlampi wrote:
> Finally, the "1.0" in master branch in VCS is currently unusable for two
> additional reasons:
Actually three, and the third reason is upstream's 1.0 version is broken
because of -Werror=alloc-size-larger-than= in swaybar/tray/icon.c.
https://github.com/swaywm/sway/issues/3862
https://github.com/swaywm/sway/commit/bcde298a719f60b9913133dbd2a169dedbc8dd7d
I'm attaching a DEP-3 patch for 1.0 (although you could in theory "just"
make a package release with version number 1.0+bcde298 instead, it's
one commit ahead of the 1.0 Git tag it seems).
Bug: https://github.com/swaywm/sway/issues/3862
Bug-Debian: https://bugs.debian.org/927723
Origin: upstream, https://github.com/swaywm/sway/commit/bcde298
From: emersion
Subject: Fix size_t temporary underflow in log_loaded_themes
`len` will underflow but will overflow right after, so it's not as bad as it
may appear. Still better not to under/overflow at all.
Fixes https://github.com/swaywm/sway/issues/3862
---
swaybar/tray/icon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/swaybar/tray/icon.c b/swaybar/tray/icon.c
index c7ce20b4d..2276e36de 100644
--- a/swaybar/tray/icon.c
+++ b/swaybar/tray/icon.c
@@ -307,16 +307,16 @@ static void log_loaded_themes(list_t *themes) {
return;
}
- const char *sep = ", ";
+ const char sep[] = ", ";
size_t sep_len = strlen(sep);
- size_t len = 1 - sep_len;
+ size_t len = 0;
for (int i = 0; i < themes->length; ++i) {
struct icon_theme *theme = themes->items[i];
len += strlen(theme->name) + sep_len;
}
- char *str = malloc(len);
+ char *str = malloc(len + 1);
if (!str) {
return;
}
Bug#927723: sway: Please upload new upstream version
Control: tags -1 + experimental On Mon, Apr 22, 2019 at 01:03:55AM +, Linda Lapinlampi wrote: > 1.0~rc5 and 1.0 have been packaged a month ago at VCS (salsa), but never > uploaded to Debian's distribution. Could you please upload sway 1.0 to > unstable distribution, please? (I'm aware Buster is in full freeze, and > won't be migrated to testing.) I can see now what's going on with this package. The maintainer bumped debian/changelog version from `1.0~rc4` to `1.0`, but didn't merge upstream tag `1.0` into the package or create upstream/1.0 branch. wlroots (libwlroots-dev) is available in Debian from experimental distribution only, and upstream considers it as a "pre-release" with ABI breakages. Since sway depends on wlroots, I don't think sway is ready for unstable distribution yet. Another dependency is on libjson-c-dev: 0.13.1 is only in experimental distribution, unstable has 0.12.1. Finally, the "1.0" in master branch in VCS is currently unusable for two additional reasons: 1. sway has Build-Depends on both libelogind-dev and libsystemd-dev, but only one of these can be installed at a time due to conflicts/breaks, and the maintainer forgot to make this as a group of alternative packages. 2. When cloning from Salsa, `meson.build`'s `if git.found()` triggers and later the C build fails to -Werror=date-time (which can be resolved by patching that line or removing the .git directory for building purposes). Hope that helps. Consider adding tag "help" to this bug, if necessary.
Bug#927726: wlroots: Please upload new upstream version
Source: wlroots Severity: wishlist Dear Maintainer, 0.4 and 0.5.0 have been have been packaged a month ago at VCS (salsa), but never uploaded to Debian's distribution. Could you upload wlroots 0.5.0 to experimental distribution, please? unstable could be fine too, but not because upstream still considers the 0.5.0 release as a "pre-release" and has breaking changes. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927723: sway: Please upload new upstream version
Package: sway Severity: wishlist Dear Maintainer, 1.0~rc5 and 1.0 have been packaged a month ago at VCS (salsa), but never uploaded to Debian's distribution. Could you please upload sway 1.0 to unstable distribution, please? (I'm aware Buster is in full freeze, and won't be migrated to testing.) -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#910999: RFP: mxisd -- Federated Matrix Identity Server
On Sun, Oct 14, 2018 at 03:54:16PM +, Johannes Keyser wrote: > * Package name: mxisd > Version : 1.2.0 > Upstream Author : Max Dor > * URL : https://github.com/kamax-matrix/mxisd > * License : AGPL-3.0 > Programming Lang: Java > Description : Federated Matrix Identity Server As of mxisd 1.3.1, mxisd depends on undertow (libundertow-java) instead of Spring Boot. undertow is not going to be included in Buster release: https://bugs.debian.org/903916 I also looked at the potential dependencies required. > mxisd dependencies missing from Debian GNU/Linux: > > * matrix-java-sdk > * ormlite-jdbc > * eddsa > * libphonenumber-java (`8.7.1`) – there is `7.1.0` available, and a > newer Python package for `8.9.10` > * firebase-admin > * sqlite-jdbc (?) > * twilio (Java) > * sendgrid > * zt-exec > > Testing stuff missing: > > * wiremock > * unboundid > * greenmail > > Other stuff: > > * `libc3p0-java` exists, but an older verison: `0.9.1.2`. mxisd >depends on version `0.9.5.2` it seems. > * `libmariadb-java` is quite much (?) newer in Debian than what mxisd >depends on. > * libundertow-java is `1.4.25` in Debian, mxisd depends on >`2.0.16.Final` I've also understood from a conversation with the upstream author he's not very interested to spend a lot of time on mxisd after the upcoming 1.4.0 release, but focus on gridepo stuff instead. Rewriting mxisd from undertow to some other HTTP library (e.g. Jetty) is unlikely at this time. Attached is the output of gradle dependencies from mxisd 1.3.1 (current stable version). :dependencies Root project apiElements - API elements for main. (n) No dependencies archives - Configuration for archive artifacts. No dependencies compile - Dependencies for source set 'main' (deprecated, use 'implementation ' instead). +--- org.slf4j:slf4j-simple:1.7.25 |\--- org.slf4j:slf4j-api:1.7.25 +--- commons-io:commons-io:2.5 +--- org.yaml:snakeyaml:1.23 +--- io.kamax:matrix-java-sdk:0.0.14-8-g0e57ec6 |+--- org.slf4j:log4j-over-slf4j:1.7.25 ||\--- org.slf4j:slf4j-api:1.7.25 |+--- org.apache.commons:commons-lang3:3.7 |+--- commons-io:commons-io:2.5 |+--- commons-codec:commons-codec:1.11 |+--- com.squareup.okhttp3:okhttp:3.11.0 ||\--- com.squareup.okio:okio:1.14.0 |+--- com.google.code.gson:gson:2.8.0 |\--- net.i2p.crypto:eddsa:0.1.0 +--- com.j256.ormlite:ormlite-jdbc:5.0 |\--- com.j256.ormlite:ormlite-core:5.0 +--- net.i2p.crypto:eddsa:0.1.0 +--- org.apache.directory.api:api-all:1.0.0 |+--- org.slf4j:slf4j-api:1.7.25 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:1.1.4c_7 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.dom4j:1.6.1_5 ||\--- xml-apis:xml-apis:1.0.b2 |+--- xml-apis:xml-apis:1.0.b2 |+--- commons-pool:commons-pool:1.6 |+--- org.apache.mina:mina-core:2.0.16 ||\--- org.slf4j:slf4j-api:1.7.21 -> 1.7.25 |+--- commons-lang:commons-lang:2.6 |+--- commons-collections:commons-collections:3.2.2 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.antlr:2.7.7_5 |\--- commons-codec:commons-codec:1.10 -> 1.11 +--- dnsjava:dnsjava:2.1.8 +--- org.apache.httpcomponents:httpclient:4.5.3 |+--- org.apache.httpcomponents:httpcore:4.4.6 |+--- commons-logging:commons-logging:1.2 |\--- commons-codec:commons-codec:1.9 -> 1.11 +--- com.googlecode.libphonenumber:libphonenumber:8.7.1 +--- javax.mail:javax.mail-api:1.6.2 +--- com.sun.mail:javax.mail:1.6.2 |\--- javax.activation:activation:1.1 +--- com.google.firebase:firebase-admin:5.3.0 |+--- com.google.api-client:google-api-client:1.22.0 ||+--- com.google.oauth-client:google-oauth-client:1.22.0 |||+--- com.google.http-client:google-http-client:1.22.0 ||||+--- com.google.code.findbugs:jsr305:1.3.9 -> 3.0.0 ||||\--- org.apache.httpcomponents:httpclient:4.0.1 -> 4.5.3 (*) |||\--- com.google.code.findbugs:jsr305:1.3.9 -> 3.0.0 ||+--- com.google.http-client:google-http-client-jackson2:1.22.0 |||+--- com.google.http-client:google-http-client:1.22.0 (*) |||\--- com.fasterxml.jackson.core:jackson-core:2.1.3 -> 2.8.7 ||\--- com.google.guava:guava-jdk5:17.0 |+--- com.google.api-client:google-api-client-gson:1.22.0 ||+--- com.google.api-client:google-api-client:1.22.0 (*) ||\--- com.google.http-client:google-http-client-gson:1.22.0 || +--- com.google.http-client:google-http-client:1.22.0 (*) || \--- com.google.code.gson:gson:2.1 -> 2.8.0 |+--- com.google.http-client:google-http-client:1.22.0 (*) |+--- org.json:json:20160810 |+--- com.google.guava:guava:20.0 |+--- com.google.cloud:google-cloud-storage:1.2.1 ||+---
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
On Tue, Apr 09, 2019 at 10:21:29AM -0700, Sean Whitton wrote: > On Mon 08 Apr 2019 at 11:13PM +00, Linda Lapinlampi wrote: > > > I'm attaching a patch, seems trivial. Here's the word-diff=plain to > > resolve typos. Hoping this is okay to merge as is, but more feedback is > > welcome. > > Thanks, applied. Just fyi: The debian/changelog file references section 9.11 incorrectly for UNRELEASED 4.3.0.4 version; the section should be 9.1.1. The commit has it correct.
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
On Thu, Apr 11, 2019 at 02:35:26PM +, Linda Lapinlampi wrote: > Just fyi: The debian/changelog file references section 9.11 incorrectly > for UNRELEASED 4.3.0.4 version; the section should be 9.1.1. The commit > has it correct. Actually, I think I was meant to say 9.1.2 for the changelog.
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
control: tags -1 + patch
On Fri, Feb 22, 2019 at 05:45:29PM -0700, Sean Whitton wrote:
> On Mon 18 Feb 2019 at 11:54PM +00, Linda Lapinlampi wrote:
> > FHS 3.0's section 4.5 is about a completely irrelevant /usr/include
> > directory, not about /usr/local. I think this should point to section
> > 4.9 in the FHS?
>
> Thanks. A patch would be welcome.
Hi, apologies for the delay especially now that Buster is already in
full-freeze. :(
I'm attaching a patch, seems trivial. Here's the word-diff=plain to
resolve typos. Hoping this is okay to merge as is, but more feedback is
welcome.
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 59c92ec..6e0c020 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -127,8 +127,8 @@ empty.
Note that this applies only to directories *below* ``/usr/local``, not
*in* ``/usr/local``. Packages must not create sub-directories in the
directory ``/usr/local`` itself, except those listed in FHS, section
[-4.5.-]{+4.9.+} However, you may create directories below them as you wish. You
must not remove any of the directories listed in [-4.5,-]{+4.9,+} even if you
created them.
If ``/etc/staff-group-for-usr-local`` does not exist, ``/usr/local``
>From 88353bf9931337efae5c06cad23306ff276d521e Mon Sep 17 00:00:00 2001
From: "Juuso \"Linda\" Lapinlampi"
Date: Mon, 8 Apr 2019 22:53:48 +
Subject: [PATCH] ch-opersys: Update referenced sections to FHS 3.0
The policy says in section 9.1.1 all files and directories must comply
with Filesystem Hierarchy Standard (FHS) 3.0. Later in section 9.1.2,
the references to FHS' section numbers were pointing to sections
apparently only sensible for an older FHS 2.3 document.
This fixes those references to the new numbers found in the FHS 3.0
document, and thus fixes the typos.
See: https://bugs.debian.org/922654
---
policy/ch-opersys.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 59c92ec..6e0c020 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -127,8 +127,8 @@ empty.
Note that this applies only to directories *below* ``/usr/local``, not
*in* ``/usr/local``. Packages must not create sub-directories in the
directory ``/usr/local`` itself, except those listed in FHS, section
-4.5. However, you may create directories below them as you wish. You
-must not remove any of the directories listed in 4.5, even if you
+4.9. However, you may create directories below them as you wish. You
+must not remove any of the directories listed in 4.9, even if you
created them.
If ``/etc/staff-group-for-usr-local`` does not exist, ``/usr/local``
--
2.20.1
Bug#920489: opensmtpd: new upstream version available
On Mon, Apr 08, 2019 at 10:10:10PM +, Linda Lapinlampi wrote: > Ping. Would you upload OpenSMTPD 6.4.1p2 to experimental with the > patches re-enabling OpenSSL support provided in this Bug#, please? I reminded myself how my patches don't change anything required to build/install the new smtp(1) client, man pages, etc. Some additional plumbing in debian/* may be required to make that client available.
Bug#920489: opensmtpd: new upstream version available
Control: retitle 920489 opensmtpd: new upstream version available On Sat, Feb 09, 2019 at 10:29:03AM -0500, Ryan Kavanagh wrote: > Thanks for the bug report. I think it would be best to keep 6.0.3p1 for > Buster given that it has been well tested. I am also reluctant to make > the jump to 6.4.x right before freeze given the dependency on libressl > and the changes to config file syntax. > > That said, I am willing to upload 6.4.x to experimental if there is > interest. Thank you, Linda, for the patches. Ping. Would you upload OpenSMTPD 6.4.1p2 to experimental with the patches re-enabling OpenSSL support provided in this Bug#, please? I'm aware Buster is in full freeze right now, so an upload to unstable would not be feasible anyway. I also agree #754513 (LibreSSL) dependency is/would be a good reason to block an upload to unstable, if the freeze wasn't happening.
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
Control: tags 926671 + patch Control: severity 926671 important I'm attaching a DEP-3 formatted Debian patch, backported from upstream mtxclient to nheko 0.6.3-1 in Debian. I'm also increasing the severity of this bug to "important". I think it'd be best to try to get the release managers' manual approval for unblock this change into Buster via unstable upload, since nheko in buster/stable may not be very useful in few years without this patch or a backport: https://github.com/matrix-org/matrix-doc/pull/1943 (uhoreg@ mentined libqmatrixclient may need this same patch too, but I didn't look into that.)
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
On Mon, Apr 08, 2019 at 09:22:43PM +, Linda Lapinlampi wrote:
> I'm attaching a DEP-3 formatted Debian patch, backported from upstream
> mtxclient to nheko 0.6.3-1 in Debian.
...and here's the patch I forgot to attach earlier.
Author: redsky17
Bug: https://github.com/Nheko-Reborn/mtxclient/issues/3
Bug-Debian: https://bugs.debian.org/926671
Description: Fix Room v3 Issue
This at least partially addresses #3. I have a feeling that
additional updates will be needed at some point, but this
fixes the issue where mtxclient would throw an exception for
unrecognized event id formats, which caused nheko to crash.
Origin: backport, https://github.com/Nheko-Reborn/mtxclient/commit/67d39691666bcdf3cc660db19ccc0d9941df13fd
Last-Update: 2019-04-08
diff --git a/mtxclient/include/mtx/identifiers.hpp b/mtxclient/include/mtx/identifiers.hpp
index 87acc43..7885885 100644
--- a/mtxclient/include/mtx/identifiers.hpp
+++ b/mtxclient/include/mtx/identifiers.hpp
@@ -90,7 +90,10 @@ parse(const std::string )
identifier.hostname_ = id.substr(parts + 1);
identifier.id_= id;
} else {
-throw std::invalid_argument(id + ": invalid format\n");
+// V3 event ids don't use ':' at all, don't parse them the same way.
+identifier.localpart_ = id;
+identifier.hostname_ = id;
+identifier.id_ = id;
}
return identifier;
Bug#926680: nheko: fakehome is not automatically cleaned up
Source: nheko Version: 0.6.3-1 Severity: normal Dear Maintainer, if building from source fails during the CMake build process, fakehome won't be automatically cleaned up and dpkg-source will complain about local changes. This happened to me when I ran out of storage space on /tmp where it was building. Specifically, CMake's .deps directory in fakehome can cause trouble too. It'd be the best if fakehome could be avoided altogether. dh_auto_build removes the fakehome directory, but it should probably be done in dh_auto_clean instead. > dpkg-source: info: local changes detected, the modified files are: > > nheko-0.6.3/fakehome/.cmake/packages/MatrixClient/4f5a4442c20c172452cff095aaf9ebc8 > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/nheko_0.6.3-1.1.diff.J43BJC -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#926672: debbugs: 'bug' parameter is undefined for canonical URIs
Package: debbugs Severity: normal Dear Maintainer, I noticed the HTML source of Bug# pages has the following backtrace on bugs.debian.org:
Bug#926671: nheko: Unrecognized event id formats cause nheko to crash
Package: nheko
Version: 0.6.3-1
Severity: normal
Control: tags -1 + fixed-upstream
Control: tags -1 + forwarded https://github.com/Nheko-Reborn/mtxclient/issues/3
Dear Maintainer,
because mtxclient has no package in Debian and nheko static-links with
it (Bug#926668), I'm filing this against the nheko package.
The above mentioned version of the package includes an older version of
mtxclient, which does not yet include an upstream patch for preventing a
crash in nheko Reborn in Debian.
The patch to mtxclient is attached. The crash is reproduced in Matrix
room version 3, which as of today is not yet the default room version
and thus doesn't impact the usability of this package too much yet.
Please consider fixing this issue in the package available from Debian,
due to the way mtxclient is currently packaged with nheko.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nheko depends on:
ii libboost-atomic1.67.0 1.67.0-13
ii libboost-chrono1.67.0 1.67.0-13
ii libboost-date-time1.67.0 1.67.0-13
ii libboost-iostreams1.67.0 1.67.0-13
ii libboost-random1.67.0 1.67.0-13
ii libboost-regex1.67.0 1.67.0-13
ii libboost-system1.67.0 1.67.0-13
ii libboost-thread1.67.0 1.67.0-13
ii libc6 2.28-8
ii libcmark0 0.28.3-1
ii libgcc1 1:8.3.0-5
ii liblmdb0 0.9.22-1
ii libolm2 2.2.2+git20170526.0fd768e+dfsg-1+b11
ii libqt5concurrent5 5.11.3+dfsg1-1
ii libqt5core5a 5.11.3+dfsg1-1
ii libqt5dbus5 5.11.3+dfsg1-1
ii libqt5gui55.11.3+dfsg1-1
ii libqt5multimedia5 5.11.3-2
ii libqt5network55.11.3+dfsg1-1
ii libqt5svg55.11.3-2
ii libqt5widgets55.11.3+dfsg1-1
ii libsodium23 1.0.17-1
ii libssl1.1 1.1.1b-1
ii libstdc++68.3.0-5
ii zlib1g1:1.2.11.dfsg-1
Versions of packages nheko recommends:
ii ca-certificates 20190110
nheko suggests no packages.
-- no debconf information
From 67d39691666bcdf3cc660db19ccc0d9941df13fd Mon Sep 17 00:00:00 2001
From: redsky17
Date: Fri, 22 Feb 2019 03:24:14 +
Subject: [PATCH] Fix Room v3 Issue
This at least partially addresses #3. I have a feeling that
additional updates will be needed at some point, but this
fixes the issue where mtxclient would throw an exception for
unrecognized event id formats, which caused nheko to crash.
---
include/mtx/identifiers.hpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/mtx/identifiers.hpp b/include/mtx/identifiers.hpp
index 87acc43..7885885 100644
--- a/include/mtx/identifiers.hpp
+++ b/include/mtx/identifiers.hpp
@@ -90,7 +90,10 @@ parse(const std::string )
identifier.hostname_ = id.substr(parts + 1);
identifier.id_= id;
} else {
-throw std::invalid_argument(id + ": invalid format\n");
+// V3 event ids don't use ':' at all, don't parse them the same way.
+identifier.localpart_ = id;
+identifier.hostname_ = id;
+identifier.id_ = id;
}
return identifier;
Bug#926668: nheko: mtxclient is missing from debian/control output
Source: nheko Severity: important Dear Maintainer, according to the `debian/README.sources` file (see Bug#926659), the sources of mtxclient are included with nheko's source in Debian. The source package doesn't declare to build a mtxclient package in debian/control. What I wanted to do was make an UNRELEASED package for nheko 0.6.3, with a more up-to-date mtxclient dependency (to resolve a bug causing nheko 0.6.3 to crash with Matrix v3 rooms). This dependency does not exist in the Debian tree by itself, but is static-linked with nheko Reborn. What I found was this convoluted and antiqued Standards-Version packaging, which requires running debian/rules make-orig-source and fetching sources from out of the tree. The CMake rules for this project would seem to otherwise download source tarballs from the Internet during the build process. I would also believe mtxclient would be more useful as a standalone package, and the nheko package in Debian should be patched to dynamically link to it, but that's maybe off-topic for this issue. Despite Debian Policy 4.3.0.3 § 4.13 on convenience copies saying it's a "should" and not a "must" to not use the convenience copies, but please consider if this makes the package unsuitable for release in buster (severity serious). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#926659: nheko: Wrong debian/README.source filename
Source: nheko Severity: minor Dear Maintainer, I believe the file `debian/README.sources` should be renamed to `debian/README.source` accordingly with Debian policy v4.3.0.3 § 4.14. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#926564: minetest: New upstream version available
Source: minetest Severity: wishlist Dear Maintainer, Please consider packaging the latest version of this package to Debian. The 0.4.17 version in Debian is now over a year old. 0.4.17 → 5.0.0 → 5.0.1 (released 2019-03-31). In case of a Debian freeze, please consider uploading the new version to experimental. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925337: webext-ublock-origin: deactivated with Firefox 66
On Sat, Mar 23, 2019 at 12:40:30PM +0100, Martin Steigerwald wrote: > Package: webext-ublock-origin > Version: 1.18.4+dfsg-2 > Severity: normal > > Dear Markus, > > uBlock Origin becomes deactivated with Firefox 66.0-1. Dear Maintainer, I can confirm this behavior as well with Firefox 66.0-1 update on buster/sid. uBlock Origin is "(disabled)" in about:addons, with no way to activate it again and no explanation. Another Debian webextension package, webext-https-everywhere, appears to be active and working on buster/sid with Firefox 66.0-1 update.
Bug#922871: RFS: matrix-archive-keyring/1:2015.06.11+ds.1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors (and Matrix Packaging Team), I am looking for a sponsor for my package "matrix-archive-keyring" * Package name: matrix-archive-keyring Version : 1:2015.06.11+ds.1 Upstream Author : The Matrix.org Foundation CIC * URL : https://matrix.org/packages/debian/repo-key.asc * License : GPLv3+ (key: public domain) Section : contrib/misc Programming Lang: Make, sh, bash It builds those binary packages: matrix-archive-keyring - OpenPGP archive key for the Matrix.org package repository matrix-archive-config - APT configuration for the Matrix.org package repository To access further information about this package, please visit the following URL: https://mentors.debian.net/package/matrix-archive-keyring Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/m/matrix-archive-keyring/matrix-archive-keyring_2015.06.11+ds.1.dsc Changelog: * Initial release in Debian (contrib). (Closes: #922155) * Standards-Version 4.3.0.2 and Lintian free. * debhelper compat level 12. * matrix-archive-keyring: OpenPGP keys for package verification * Installs a keyring to the /usr/share/keyrings directory. * Prompts the user about trust anchored keys in APT's trusted.gpg and trusted.gpg.d files, then removes them. * Advanced users: Provides a debconf(1) template to reconfigure the keyring as a system trusted APT keyring. (Default: false) * matrix-archive-config: APT configuration * Installs an apt_preferences(5) file (a symbolic link from APT). * Pinned to matrix.org origin. * Pinned to priority 100. * Installs a sources.list(5) file (a symbolic link from APT). * Signed-By a keyring from matrix-archive-keyring. * Aware of the APT configuration via apt-config(8). * Notable changes since pre-releases prior to uploading to Debian: * Added bug-scripts for reportbug(1). * Changed version to match the date on the keys, not the upload date found on Matrix.org's HTTP servers (epoch increase, backwards incompatible). * +ds.x version numbering for Debian Source to match a common practice. * Fixed data loss on matrix-org.list (a typo in a test case, which led to the config migration code almost never being executed properly). * Added standard error output on encountering Debian Bug#696332 in lsb_release (re-discovered while testing the change mentioned before). * Added debian/copyright disclaimer for contrib area.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
I believe this package is ready for Debian now. I'm looking for a sponsor now; more details in a RFS issue to follow. Thanks to the few people in the #debian-matrix:matrix.org room for testing experimental pre-releases.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, Feb 19, 2019 at 12:07:19PM +0100, Andrej Shadura wrote: > On Tue, 19 Feb 2019 at 12:03, Linda Lapinlampi wrote: > > I'm excited to close this ITP bug with a +debian1 release in sid / > > experimental soon. :) > > I’ll have a look soon. No big changes expected anymore, but I'm preparing 2015.12.09+ds.1 for experimental or sid today. I'll probably upload to mentors.debian.net then. +debian was a misnomer, I forgot it should've been +ds.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
An update: While I don't have a salsa.d.o account yet for hosting the source, attached is the current state of this package UNRELEASED. Technically, this might be ready for the experimental distribution tree right now? I'd have to check, to make sure. I've split the source package "matrix-archive-keyring" into two binary packages: "matrix-archive-keyring" and "matrix-archive-config". I'm excited to close this ITP bug with a +debian1 release in sid / experimental soon. :) matrix-archive-keyring_2015.12.09+debian0.15.tar.xz Description: application/xz
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
Source: debian-policy Version: 4.3.0.2 Severity: normal The policy says in section § 9.1.2. "Site-specific programs": > Packages must not create sub-directories in the directory /usr/local > itself, except those listed in FHS, section 4.5. However, you may > create directories below them as you wish. You must not remove any of > the directories listed in 4.5, even if you created them. FHS 3.0's section 4.5 is about a completely irrelevant /usr/include directory, not about /usr/local. I think this should point to section 4.9 in the FHS? In FHS 2.3, this "section 4.5" might have been right. But as said in policy 9.1.1: > The location of all files and directories must comply with the Filesystem > Hierarchy Standard (FHS), version 3.0, [...]. No other exception is noted below that.
Bug#922651: cacti: typo in debian/debian.php.dist
Package: cacti Version: 1.2.1+ds1-2 Severity: minor Dear Maintainer, debian/debian.php.dist has a typo on line 4. It says "normaly", while it should say "normally". -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
A small update on this ITP: The attached source is the current state of this package, UNRELEASED. It's not fit for the Debian distribution just yet; but I'll allow eager early testers to find the source from here. +debian1 version should follow soon for sid, to be sponsored. I'll polish it a little further and go through the Debian Policy once more to check for any remaining issues before this. matrix-archive-keyring_2015.12.09+debian0.10.tar.xz Description: application/xz
Bug#922357: internetarchive: new upstream version available
Package: internetarchive Version: 1.8.1-1 Severity: wishlist Dear Maintainer, a new version 1.8.2 (or later) is available from upstream, since 2018-07-02. Please consider packaging it to Debian. Changelog: https://archive.org/services/docs/api/internetarchive/updates.html -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages internetarchive depends on: ii python3 3.7.2-1 ii python3-internetarchive 1.8.1-1 internetarchive recommends no packages. internetarchive suggests no packages. -- no debconf information
Bug#922348: unsupported APT keyring format (GPG keybox database version 1)
Package: ubuntu-dbgsym-keyring Version: 2018.09.18.1-4 Severity: normal Dear Maintainer, the following files are in a GPG keybox database version 1 format. - keyrings/ubuntu-dbgsym-keyring.gpg - keyrings/ubuntu-dbgsym-removed-keys.gpg As said in the apt-key(8) man page: > apt-key supports only the binary OpenPGP format (also known as "GPG > key public ring") in files with the "gpg" extension, not the keybox > database format introduced in newer gpg(1) versions as default for > keyring files. $ file keyrings/ubuntu-dbgsym-keyring.gpg keyrings/ubuntu-dbgsym-removed-keys.gpg keyrings/ubuntu-dbgsym-keyring.gpg: GPG keybox database version 1, created-at Thu Feb 1 12:47:14 2018, last-maintained Thu Feb 1 12:47:14 2018 keyrings/ubuntu-dbgsym-removed-keys.gpg: GPG keybox database version 1, created-at Thu Feb 1 12:47:35 2018, last-maintained Thu Feb 1 12:47:35 2018 The latter of these keyringss can be configured with debconf(1) to be installed as an APT trust anchor. This won't work. (ubuntu-dbgsym-keyring.gpg does not seem to be offered?) The issue is not as severe, because this is not the default behavior for the package. It may also be rather unlikely anyone would install the removed keys. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ubuntu-dbgsym-keyring depends on: ii debconf [debconf-2.0] 1.5.70 Versions of packages ubuntu-dbgsym-keyring recommends: ii gpgv 2.2.12-1 ubuntu-dbgsym-keyring suggests no packages. apt 1.8.0~rc3.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote: > More important is the question if the system should /trust/ the keys. > > IMHO installing a non-Debian keyring should *not* make the keys trusted > by APT by default (i.e. with the default answer if debconf is used). I've agreed, it's the problem I'm trying to solve with this matrix-archive-keyring package. As said in the OP of Bug#922155 (ITP): > I have made this package install an OpenPGP-armored keyring to > /usr/share/keyrings (instead of /etc/apt/trusted.gpg.d); Since they are not in Dir::Etc::trusted or Dir::Etc::trustedparts, the system won't trust the Matrix archive keys for APT by default (unless the sysadmin has explicitly configured otherwise). By default, sources.list(5) entries will need to specifically have [signed-by:/usr/share/keyrings/matrix-archive-keyring.gpg] for APT to trust the data sources with this package. To clarify, trust to keys in the matrix-archive-keyring package is all a multi-step opt-in: 1. Using the keyring to manually verify packages from Matrix.org (yes) 2. Trusting the keyring for Matrix.org APT sources (default: no) 3. Trusting the keyring for any APT sources (default: hell no) What the Internet says to do and what's currently happening in practice: 1. Using the repository key to manually verify packages from Matrix.org 2. Trusting the repository key for Matrix.org APT sources (yes, but...) 3. Trusting the repository key for any APT sources (yikes) There is an additional low priority debconf(1) question in matrix-archive-keyring if #3 should be true, but with sane default of "false" and a warning about it being unnecessary in most cases. Although it's so trivial, I'm open to removing this option altogether if desired for lacking much real use. The other debconf(1) question (#2) serves to answer if the user should trust packages from the third-party repository. If you meant the description of that question does not adequately ask if the user should /trust/ packages from that repository (instead of just mentioning they are supplemental packages which are not officially supported), would you like me to change the description for the release to point out trust more prominently? The alternative may be a seperate contrib package for a sources.list source. > ubuntu-keyring does that; most other keyrings sadly do not follow this. I'd suggest to file bugs. I've found many issues in the past few days.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > I believe this package belongs in contrib, as its only use-case is with > > together with software outside of Debian main. > > ...and now posting to the actual bugreport as well. I'm not opposed to having this matrix-archive-keyring package in the contrib area, although for comparison I should note leap-archive-keyring has no rdepends, the keyring package is available from Debian's main archive area and is valid for verifying package signatures from leap.se. An example of a package from deb.leap.se is bitmask-core (which is not available in Debian), and it's not in the contrib area in the leap.se repository. Maybe this is an error/bug in the leap-archive-keyring package, but it does seem confusing. The other *-archive-keyring packages in Debian main seem to be at least vaguely related to the Debian Project or its teams, although they are all (with the exception of debian-archive-keyring) meant to be used with third-party data sources (usually with APT). As of yesterday, there is also this high-priority debconf(1) question template in the matrix-archive-keyring package: Template: matrix-archive-keyring/sources.list Type: boolean Default: false _Description: Use APT data sources from Matrix.org? The Matrix.org Debian package repository distributes supplemental Matrix.org related packages intended to work with the Debian distribution, but require software software outside of the distribution to either build or function. These packages are digitally signed with keys from matrix-archive-keyring. . The Debian Project will be unable to directly support issues faced from using supplemental packages from this third-party repository. Packages from these APT sources may be non-conforming to the technical requirements set in the Debian Policy for the Debian distribution. (Sorry if I fell under the assumption the package will be usable on Debian only, and not derivative distributions with different names.) Choosing "yes" here would obviously enable the contrib bits from the default of "false". And as I said, packages from Matrix.org are already in the contrib area (Section: contrib/*). If this debconf(1) question makes it a hard-requirement of contrib archive area, I could split the main parts (keyring) and the debconf(1) question (sources.list) to seperate packages in main and contrib sections respectively if that is more desirable. I have currently set the package's "Section:" to "contrib/misc", in any case. What do you think?
Bug#922177: ubuntu-keyring: postinst script loop loops only once (SC2066)
Source: ubuntu-keyring Version: 2018.09.18.1-4 Severity: normal Dear Maintainer, I noticed ShellCheck was raising an error in debian/*.postinst scripts. if [ -n "$RET" ]; then ->for keyring in "$RET" do rm -f /etc/apt/trusted.gpg.d/"$keyring".gpg ln -sf /usr/share/keyrings/"$keyring".gpg /etc/apt/trusted.gpg.d/ done fi The error at pointed arrow is: > SC2066: Since you double quoted this, it will not word split, and the > loop will only run once. I believe this means only one key will be ever installed from debconf template choice, if multiple answers are given from the multiselect templates. Removing double quotes should fix the issue. See: https://github.com/koalaman/shellcheck/wiki/SC2066 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#922176: ubuntu-keyring: apt-config(8)'s Dir::Etc::trustedparts option is ignored
Source: ubuntu-keyring Version: 2018.09.18.1-4 Severity: important Dear Maintainer, in debian/*.postinst files, there is the following line: ln -sf /usr/share/keyrings/"$keyring".gpg /etc/apt/trusted.gpg.d/ I believe this should actually be: TRUSTEDPARTS="/etc/apt/trusted.gpg.d/" # fallback if not configured eval "$(apt-config shell TRUSTEDPARTS Dir::Etc::trustedparts/d)" ln -sf /usr/share/keyrings/"$keyring".gpg "$TRUSTEDPARTS" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#922155: ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
Package: wnpp
Severity: wishlist
Owner: Linda Lapinlampi
* Package name: matrix-archive-keyring
Version : 2015.12.09
Upstream Author : The Matrix.org Foundation CIC
* URL : https://matrix.org/packages/debian/repo-key.asc
* License : GPLv3+ (key: public domain)
Programming Lang: Make, sh
Description : OpenPGP archive key for the Matrix.org package repository
The Matrix.org Debian package repository distributes digitally signed
releases of Matrix.org related packages. This package contains the
archive key used to verify those files, required by apt(8).
matrix-archive-keyring will also attempt to harden the apt-secure(8)
infrastructure by removing known previously installed (untrusted)
Matrix.org archive key(s) from apt(8)'s global trust database, which
have often been erroneously added via apt-key(8).
Hi, so there's few packages in Debian already such as matrix-synapse.
[1] And then there's Debian packages from third-party Matrix.org and
Riot.im package repositories at upstream.
The issue: Signing keys added to /etc/apt/trusted.gpg{,.d} will be
trusted by apt(8) for every repository, including Debian's main package
repository.
I'm currently seeing a "trend" on the Internet where tutorials and
guides suggest to use "apt-key add" to install Matrix.org's package
repository archive key recklessly without any regard to apt-secure(8).
More so, Matrix.org links to one of these guides itself. [2] Riot.im
(related to the same people running Matrix.org) also suggests "apt-key
add". [3] Synapse 0.99.0's `INSTALL.md` guide suggests to download a key
and add it via apt-key(8) too, [4] while this package is also available
from Debian.
The solution: A keyring package, as suggested by apt-secure(8).
If the sysadmin wants to install from Matrix.org or Riot.im package
repositories (instead of Debian's), fine. Who am I to argue? At least I
I can make their life more convenient while hardening APT's security for
everyone, while Debian doesn't have packages available for every
upstream package yet.
I have made this package install an OpenPGP-armored keyring to
/usr/share/keyrings (instead of /etc/apt/trusted.gpg.d); I'm also using
a db_install(8) postinst script to ensure that the keys in question
don't show up in two keyrings at once.
I will be also looking to configure debconf(1) to ask if the user also
wants to install the appropriate sources.list(5) file for the Matrix.org
and/or Riot.im repository with signed-by option.
Packages similar to this one exist in Debian: ubuntu-keyring,
leap-archive-keyring, pkg-mozilla-archive-keyring, etc.
I will be looking for a sponsor. I know someone from the Matrix
Packaging Team at Debian whom I'll be asking to kindly sponsor this
package. If they refuse, I know where to ask.
Thanks for your attention.
[1]: https://wiki.debian.org/Matrix
[2]: https://matrix.org/docs/guides/installing-synapse
[3]: https://riot.im/desktop.html
[4]: https://github.com/matrix-org/synapse/blob/release-v0.99.0/INSTALL.md
Bug#922087: runescape: please remove the unnecessary p7zip-full dependency
Package: runescape Version: 0.4-1 Severity: wishlist Dear Maintainer, currently, src/runescape.sh downloads a .dmg file and extracts it with 7z for the jagexappletviewer.jar file. The 7z executable comes from the p7zip-full package. It would be preferable if the .jar file would be downloaded directly from https://www.runescape.com/downloads/jagexappletviewer.jar instead. Thanks. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages runescape depends on: ii default-jre 2:1.11-71 ii p7zip-full 16.02+dfsg-6 ii zenity 3.30.0-2 runescape recommends no packages. runescape suggests no packages. -- no debconf information
Bug#922084: runescape: ratelimits download speed to 200 kB/s
Package: runescape Version: 0.4-1 Severity: normal Dear Maintainer, src/runescape.sh sets `--limit-rate 200k` on line 27. I have a high-speed fiber connection and would like to use it to the full extent, as I have previously done with rsu-client (not available in Debian yet). This arbitrary limit has not been well explained in the download script. Would you consider removing this wget option flag, please? Thanks. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages runescape depends on: ii default-jre 2:1.11-71 ii p7zip-full 16.02+dfsg-6 ii zenity 3.30.0-2 runescape recommends no packages. runescape suggests no packages. -- no debconf information
Bug#922083: runescape: missing wget dependency (debian/control)
Package: runescape Version: 0.4-1 Severity: important Dear Maintainer, src/runescape.sh calls into wget on line 27. This dependency is not listed in the debian/control file. wget is installed by default even from the most minimal Debian 9 netinst images, but it is not essential to the base operating system and can be removed by a system administrator. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages runescape depends on: ii default-jre 2:1.11-71 ii p7zip-full 16.02+dfsg-6 ii zenity 3.30.0-2 runescape recommends no packages. runescape suggests no packages. -- no debconf information
Bug#921961: stterm: new upstream version available
Package: stterm Version: 0.8.1-2 Severity: wishlist Dear Maintainer, stterm 0.8.2 has been released yesterday (2019-02-09). The changes are listed below. Please consider packaging it to Debian. Thanks. $ git log --oneline --no-decorate 0.8.1..0.8.2 75f92eb bump version to 0.8.2 3be4cf1 config: add Shift+Insert as selpaste() again 16d9873 Let the user specify CPPFLAGS e23acb9 Set the path of pkg-config in a variable instead of hardcoding it 7e19e11 Makefile: fix dependencies on config.h 096b125 output child WEXITSTATUS/WTERMSIG on abnormal termination d7bf023 fix memory leak in xloadcols() b4d68d4 st: small typofix in comment 30ec9a3 small code-style fix 67d0cb6 Remove the ISO 14755 feature 4f4bccd Revert "Simplify cursor color handling" 8ed7a4b Revert "Make cursor follow text color" 732be22 Revert "Fix crash when cursor color is truecolor" 5535c1f Fix crash when cursor color is truecolor b51bcd5 Make cursor follow text color 1911c92 Simplify cursor color handling 29f341d Fix crash on resize dc3b5ba config.mk: remove extra newline before EOF 235a783 code-style for pledge(2) 30ce2cc Pledge on OpenBSD 041912a error message style and use strerror in a few places bd3f7fd st -v: remove years and copyright text 74cff67 set sel.alt in selstart instead of selextend -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stterm depends on: ii libc6 2.28-6 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3 ii libx11-62:1.6.7-1 ii libxft2 2.3.2-2 ii ncurses-term6.1+20181013-1 stterm recommends no packages. stterm suggests no packages. -- no debconf information
Bug#921891: mblaze: new upstream version available
Package: mblaze Version: 0.4-1 Severity: wishlist Dear Maintainer, a new version of mblaze (0.5) has been released today. I request this updated version to be packaged to Debian. Changelog: https://github.com/chneukirchen/mblaze/blob/2c14e800cd532c5b2deea9d658551900700b1e69/NEWS.md -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mblaze depends on: ii libc6 2.28-6 mblaze recommends no packages. mblaze suggests no packages. -- no debconf information
Bug#921425: matrix-synapse: please preload libjemalloc to reduce memory consumption
I would be opposed to this, since there's no support for Valgrind since jemalloc version 5.0. As an example rationale: LibreSSL was forked from OpenSSL because of OpenSSL's custom memory allocator and the OpenBSD project not catching memory safety issues because of it. (It wasn't because of Heartbleed.) I want to rely on libc's malloc(3) and would not appreciate an additional dependency. Smart ideas may not always be smart in the end. I think you'd be better off convincing to switch the malloc(3) system call to use jemalloc(3) everywhere, if the benefits are so good as claimed. You can do you by adjusting the variables in your environment. Also, your memory issues are probably from big rooms like #matrix:matrix.org with lots of federating servers and 4.3K+ users; that's expected of being there for a long time. For what it's worth, joining that room is doable on a 512 MB virtual machine just fine with memory consumption < 100 MB (at least for a hour or few with one user). I also don't think this bug warrants "normal" severity; likely "wishlist", maybe "minor".
Bug#921686: sendmail(8) wrapper installs under /usr/sbin directory
Package: opensmtpd Version: 6.0.3p1-4 Severity: important (Actually found from my 6.4.1p2-0.2 build, where it remains unfixed.) Dear Maintainer, The install path of sendmail(1) wrapper binary follows OpenBSD's conventions, not Debian's I believe? I've had to use this configuration in my $HOME/.mblaze/profile for a long while, because sendmail doesn't appear in my $PATH as a regular user using a local OpenSMTPD MTA as a relay to an external MSA: ``` # There's a "bug" with the OpenSMTPD package on Debian GNU/Linux. OpenSMTPD # installs a sendmail wrapper to /usr/sbin, but this is not in the # non-administrative users' $PATH on Debian due to Debian policy (following # Filesystem Hierarchy Standard 2.3 strictly). # # The package maintainer maintainer for OpenSMTPD on Debian should change the # install location of sendmail wrapper to /usr/bin. This is TBD, as of # 2019-01-07. I've not reported the bug, yet. Sendmail: /usr/sbin/sendmail ``` I believe the sendmail(8) binary should be installed to /usr/bin instead. Thanks. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opensmtpd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.70 ii ed 1.15-1 ii libasr01.0.2-2 ii libc6 2.28-6 ii libdb5.3 5.3.28+dfsg1-0.3 ii libevent-2.1-6 2.1.8-stable-4 ii libpam0g 1.1.8-4 ii libssl1.1 1.1.1a-1 ii lsb-base 10.2018112800 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages opensmtpd recommends: pn opensmtpd-extras Versions of packages opensmtpd suggests: ii ca-certificates 20190110 -- Configuration Files: /etc/smtpd.conf changed [not included] -- debconf information excluded
Bug#920489: new upstream version available
tags 920489 + patch
thanks
For convenience, I've attached the updated patch series + files which
should be replaced in debian/patches.
I'll leave it up to the maintainer to decide what to do with this;
uploading to experimental might be fine (considering we really should be
using LibreSSL instead), although I've been rocking on with these
patches for over a month now with no issues at all.
Description: Enable support for OpenSSL 1.1
Author: Sebastian Andrzej Siewior
Ryan Kavanagh
Linda Lapinlampi
Origin: Debian
Bug: https://github.com/OpenSMTPD/OpenSMTPD/issues/738
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859544
Forwarded: https://github.com/OpenSMTPD/OpenSMTPD/pull/825
Last-Update: 2019-01-06
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/openbsd-compat/libressl.c
+++ b/openbsd-compat/libressl.c
@@ -81,14 +81,14 @@
x = ca = NULL;
if ((in = BIO_new_mem_buf(buf, len)) == NULL) {
- SSLerr(SSL_F_SSL_CTX_USE_CERTIFICATE_CHAIN_FILE, ERR_R_BUF_LIB);
+ SSLerr(SSL_F_SSL_CTX_USE_CERTIFICATE_FILE, ERR_R_BUF_LIB);
goto end;
}
if ((x = PEM_read_bio_X509(in, NULL,
- ctx->default_passwd_callback,
- ctx->default_passwd_callback_userdata)) == NULL) {
- SSLerr(SSL_F_SSL_CTX_USE_CERTIFICATE_CHAIN_FILE, ERR_R_PEM_LIB);
+ SSL_CTX_get_default_passwd_cb(ctx),
+ SSL_CTX_get_default_passwd_cb_userdata(ctx))) == NULL) {
+ SSLerr(SSL_F_SSL_CTX_USE_CERTIFICATE_FILE, ERR_R_PEM_LIB);
goto end;
}
@@ -99,14 +99,11 @@
* the CA certificates.
*/
- if (ctx->extra_certs != NULL) {
- sk_X509_pop_free(ctx->extra_certs, X509_free);
- ctx->extra_certs = NULL;
- }
+ SSL_CTX_clear_extra_chain_certs(ctx);
while ((ca = PEM_read_bio_X509(in, NULL,
- ctx->default_passwd_callback,
- ctx->default_passwd_callback_userdata)) != NULL) {
+ SSL_CTX_get_default_passwd_cb(ctx),
+ SSL_CTX_get_default_passwd_cb_userdata(ctx))) != NULL) {
if (!SSL_CTX_add_extra_chain_cert(ctx, ca))
goto end;
--- a/smtpd/ca.c
+++ b/smtpd/ca.c
@@ -170,6 +170,190 @@
return ok;
}
+#if (OPENSSL_VERSION_NUMBER < 0x1010L) || defined(LIBRESSL_VERSION_NUMBER)
+
+static int RSA_meth_get_flags(RSA_METHOD *meth)
+{
+ return meth->flags;
+}
+
+static int RSA_meth_set_flags(RSA_METHOD *meth, int flags)
+{
+ meth->flags = flags;
+ return 1;
+}
+
+static void *RSA_meth_get0_app_data(const RSA_METHOD *meth)
+{
+ return meth->app_data;
+}
+
+static int RSA_meth_set0_app_data(RSA_METHOD *meth, void *app_data)
+{
+ meth->app_data = app_data;
+ return 1;
+}
+
+static int (*RSA_meth_get_pub_enc(const RSA_METHOD *meth))
+(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
+{
+ return meth->rsa_pub_enc;
+}
+
+static int RSA_meth_set_pub_enc(RSA_METHOD *meth,
+ int (*pub_enc) (int flen, const unsigned char *from,
+ unsigned char *to, RSA *rsa,
+ int padding))
+{
+ meth->rsa_pub_enc = pub_enc;
+ return 1;
+}
+
+static int (*RSA_meth_get_pub_dec(const RSA_METHOD *meth))
+(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
+{
+ return meth->rsa_pub_dec;
+}
+
+static int (*RSA_meth_get_priv_enc(const RSA_METHOD *meth))
+(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
+{
+ return meth->rsa_priv_enc;
+}
+
+int RSA_meth_set_priv_enc(RSA_METHOD *meth,
+ int (*priv_enc) (int flen, const unsigned char *from,
+ unsigned char *to, RSA *rsa, int padding))
+{
+ meth->rsa_priv_enc = priv_enc;
+ return 1;
+}
+
+static int (*RSA_meth_get_priv_dec(const RSA_METHOD *meth))
+(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
+{
+ return meth->rsa_priv_dec;
+}
+
+static int RSA_meth_set_priv_dec(RSA_METHOD *meth,
+ int (*priv_dec) (int flen, const unsigned char *from,
+ unsigned char *to, RSA *rsa, int padding))
+{
+ meth->rsa_priv_dec = priv_dec;
+ return 1;
+}
+
+static int (*RSA_meth_get_mod_exp(const RSA_METHOD *meth))
+ (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
+{
+ return meth->rsa_mod_exp;
+}
+
+static int RSA_meth_set_mod_exp(RSA_METHOD *meth,
+ int (*mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx))
+{
+ meth->rsa_mod_exp = mod_exp;
+ return 1;
+}
+
+static int (*RSA_meth_get_bn_mod_exp(const RSA_METHOD *meth))
+(BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx)
+{
+ return meth->bn_mod_exp;
+}
+
+static int RSA_meth_set_bn_mod_exp(RSA_METHOD *meth, int (*bn_mod_exp)
+ (BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m,
+ BN_CTX *ctx, BN_MONT_CTX *m_ctx))
+{
+ meth->bn_mod_exp = bn_mod_exp;
+ return 1;
+}
+
+static int (*RSA_meth_get_init(const RSA_METHOD *meth)) (RSA *rsa)
+{
+ return meth->init;
+}
+
+static int RSA_meth_set_init(RSA_METHOD *meth, int (*init) (RSA *rsa))
+{
+ meth->init = init;
+ return 1;
+}
+
+static int (*RSA_meth_get_finish(const RSA_METHOD *meth)
Bug#921676: RFP: webext-decentraleyes -- web extension for local emulation of Content Delivery Networks
Package: wnpp Severity: wishlist * Package name: webext-decentraleyes Version : 2.0.9 Upstream Author : Thomas Rientjes * URL : https://decentraleyes.org/ * AMO : https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ * VCS : https://git.synz.io/Synzvato/decentraleyes * License : MPL-2.0 (+ MIT, BSD, etc. for bundled resources) Programming Lang: Javascript Description : web extension for local emulation of Content Delivery Networks > Websites have increasingly begun to rely much more on large > third-parties for content delivery. Canceling requests for ads or > trackers is usually without issue, however blocking actual content, not > unexpectedly, breaks pages. The aim of this add-on is to cut-out the > middleman by providing lightning speed delivery of local (bundled) files > to improve online privacy. I've been using this web extension on Firefox for a long while, alongside webext-ublock-origin package from Debian to improve my privacy experience while browsing. Potential packagers, please note: It may be desirable to integrate this web extension with libjs-* packages (/usr/share/javascript/*), where supported.
Bug#921673: RFP: webext-decentraleyes -- web extension for local emulation of Content Delivery Networks
Package: wnpp Severity: wishlist * Package name: webext-decentraleyes Version : 2.0.9 Upstream Author : Thomas Rientjes * URL : https://decentraleyes.org/ * AMO : https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ * VCS : https://git.synz.io/Synzvato/decentraleyes * License : MPL-2.0 (+ MIT, BSD, etc. for bundled resources) Programming Lang: Javascript Description : web extension for local emulation of Content Delivery Networks > Websites have increasingly begun to rely much more on large > third-parties for content delivery. Canceling requests for ads or > trackers is usually without issue, however blocking actual content, not > unexpectedly, breaks pages. The aim of this add-on is to cut-out the > middleman by providing lightning speed delivery of local (bundled) files > to improve online privacy. I've been using this web extension on Firefox for a long while, alongside webext-ublock-origin package from Debian to improve my privacy experience while browsing. Potential packagers, please note: It may be desirable to integrate this web extension with libjs-* packages (/usr/share/javascript/*), where supported.
