Bug#926760: install-info: GZIP environment variable warnings on buster
It's possible I jumped the gun on the bug report. I'll try and investigate further. Scott K
Bug#926766: lintian: emit classification tag about debhelper compat level
Package: lintian
Version: 2.9.1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the debhelper compatibility level in use
by packages. An example graph is
https://blop.info/pub/debhelper-compat-stacked.png
Could lintian emit a classification tag that allows me to track that?
Here is a patch that works for me.
- Lucas
diff --git a/checks/debhelper.desc b/checks/debhelper.desc
index 6cb850637..9ace71e1d 100644
--- a/checks/debhelper.desc
+++ b/checks/debhelper.desc
@@ -388,6 +388,11 @@ Certainty: certain
Info: This package is using the debhelper-compat virtual
package as a build-dependency.
+Tag: debhelper-compat-level
+Severity: classification
+Certainty: certain
+Info: This is the debhelper compat level for the package.
+
Tag: typo-in-debhelper-override-target
Severity: normal
Certainty: possible
diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index 289282ab4..1bdeba30e 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -348,6 +348,10 @@ sub run {
$compatnan = 1;
}
+if (defined($level)) {
+tag 'debhelper-compat-level', $level;
+}
+
$level ||= 1;
if ($level < $compat_level->value('deprecated')) {
tag 'package-uses-deprecated-debhelper-compat-version', $level;
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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)
Versions of packages lintian depends on:
ii binutils 2.28-5
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.18.25
ii dpkg-dev 1.18.25
ii file 1:5.30-1+deb9u2
ii gettext 0.19.8.1-2
ii gnupg [gpg] 2.1.18-8~deb9u4
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1+deb9u1
ii libcapture-tiny-perl 0.44-1
ii libcgi-pm-perl4.35-1
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-2+b1
ii libdpkg-perl 1.18.25
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libio-async-perl 0.71-1
ii libipc-run-perl 0.94-1+deb9u1
ii liblist-moreutils-perl0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libpath-tiny-perl 0.100-1
ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u5
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii libtry-tiny-perl 0.28-1
ii liburi-perl 1.71-1
ii libxml-simple-perl2.22-1
ii libyaml-libyaml-perl 0.63-2
ii man-db2.7.6.1-2
ii patchutils0.3.4-2
ii perl 5.24.1-3+deb9u5
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b2
Versions of packages lintian suggests:
pn binutils-multiarch
ii libhtml-parser-perl3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
Bug#926767: lintian: emit classification tag about patch system in use
Package: lintian
Version: 2.9.1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the usage of source formats, and for 1.0,
the usage of patch systems. An example graph is
https://blop.info/pub/patch-systems-stacked.png
Could lintian emit a classification tag allowing me to track that?
The patch below works for me.
Also, I noticed that lintian currently ignores simple-patchsys.mk, other
than reporting, for example:
W: notify-python source: debian-rules-uses-deprecated-makefile line 3
/usr/share/cdbs/1/rules/simple-patchsys.mk
This patch system is still widely used according to
https://codesearch.debian.net/search?q=simple-patchsys.mk+path%3Adebian%2Frules
Thanks!
Lucas
diff --git a/checks/patch-systems.desc b/checks/patch-systems.desc
index 033c7fb3c..bce93cd9e 100644
--- a/checks/patch-systems.desc
+++ b/checks/patch-systems.desc
@@ -247,3 +247,8 @@ Info: The specified series file is a vendor-specific patch
series file.
such differing source packages or modify the build process to behave
conditionally or to conditionally patch files explicitly.
Ref: #904302,
https://lists.debian.org/debian-devel-announce/2018/11/msg4.html
+
+Tag: patch-system
+Severity: classification
+Certainty: certain
+Info: the patch system used by the package (if any)
diff --git a/checks/patch-systems.pm b/checks/patch-systems.pm
index 69f0b59b0..b720a7f85 100644
--- a/checks/patch-systems.pm
+++ b/checks/patch-systems.pm
@@ -63,6 +63,7 @@ sub run {
#- dpatch
if ($build_deps->implies('dpatch')) {
my $list_file;
+tag 'patch-system', 'dpatch';
tag 'package-uses-deprecated-dpatch-patch-system';
$uses_patch_system++;
$list_file = $dpdir->resolve_path('00list') if $dpdir;
@@ -147,6 +148,7 @@ sub run {
if (not $patch_series or not $patch_series->is_open_ok) {
tag 'quilt-build-dep-but-no-series-file' unless $quilt_format;
} else {
+tag 'patch-system', 'quilt';
my (@patches, @badopts);
my $series_fd = $patch_series->open;
while (my $patch = <$series_fd>) {
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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)
Versions of packages lintian depends on:
ii binutils 2.28-5
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.18.25
ii dpkg-dev 1.18.25
ii file 1:5.30-1+deb9u2
ii gettext 0.19.8.1-2
ii gnupg [gpg] 2.1.18-8~deb9u4
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1+deb9u1
ii libcapture-tiny-perl 0.44-1
ii libcgi-pm-perl4.35-1
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-2+b1
ii libdpkg-perl 1.18.25
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libio-async-perl 0.71-1
ii libipc-run-perl 0.94-1+deb9u1
ii liblist-moreutils-perl0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libpath-tiny-perl 0.100-1
ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u5
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii libtry-tiny-perl 0.28-1
ii liburi-perl 1.71-1
ii libxml-simple-perl2.22-1
ii libyaml-libyaml-perl 0.63-2
ii man-db2.7.6.1-2
ii patchutils0.3.4-2
ii perl 5.24.1-3+deb9u5
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b2
Versions of packages lintian suggests:
pn binutils-multiarch
ii libhtml-parser-perl3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
Bug#926768: lintian: emit classification tag about VCS and VCS URI
Package: lintian
Version: 2.9.1~bpo9+1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the VCS in use by packages, and the VCS
hosting provider. Example such graphs are:
https://blop.info/pub/vcs-stacked.png
https://blop.info/pub/vcs-hosting-stacked.png
Could lintian emit classification tags for this?
Here is a patch that works for me.
Also, there's no tag for packages using an external VCS hoster (such as
github), instead of salsa. That's probably something that would be
useful to add, with a Severity: pedantic or Severity: classification.
- Lucas
diff --git a/checks/fields.desc b/checks/fields.desc
index 7c6620b6f..72e6045cb 100644
--- a/checks/fields.desc
+++ b/checks/fields.desc
@@ -1493,3 +1493,13 @@ Info: The version number for this package does not
comply with the
Derivative distributions of Debian may enforce additional restrictions
on the version in order to ensure that forked (or packages that are
otherwise modified) are marked as such.
+
+Tag: vcs
+Severity: classification
+Certainty: certain
+Info: the VCS used by the package.
+
+Tag: vcs-uri
+Severity: classification
+Certainty: certain
+Info: the VCS URI used by the package.
diff --git a/checks/fields.pm b/checks/fields.pm
index 6411d06c5..6685f7423 100644
--- a/checks/fields.pm
+++ b/checks/fields.pm
@@ -1346,6 +1346,8 @@ sub run {
tag 'vcs-browser-links-to-empty-view', $uri
if $uri =~ m%rev=0&sc=0%;
} else {
+tag 'vcs', $vcs;
+tag 'vcs-uri', $uri;
$seen_vcs{$vcs}++;
foreach my $regex ($KNOWN_VCS_HOSTERS->all) {
foreach my $re_vcs (@{$KNOWN_VCS_HOSTERS->value($regex)}) {
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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)
Versions of packages lintian depends on:
ii binutils 2.28-5
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.18.25
ii dpkg-dev 1.18.25
ii file 1:5.30-1+deb9u2
ii gettext 0.19.8.1-2
ii gnupg [gpg] 2.1.18-8~deb9u4
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1+deb9u1
ii libcapture-tiny-perl 0.44-1
ii libcgi-pm-perl4.35-1
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-2+b1
ii libdpkg-perl 1.18.25
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libio-async-perl 0.71-1
ii libipc-run-perl 0.94-1+deb9u1
ii liblist-moreutils-perl0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libpath-tiny-perl 0.100-1
ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u5
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii libtry-tiny-perl 0.28-1
ii liburi-perl 1.71-1
ii libxml-simple-perl2.22-1
ii libyaml-libyaml-perl 0.63-2
ii man-db2.7.6.1-2
ii patchutils0.3.4-2
ii perl 5.24.1-3+deb9u5
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b2
Versions of packages lintian suggests:
pn binutils-multiarch
ii libhtml-parser-perl3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
Bug#926760: install-info: GZIP environment variable warnings on buster
Hi Scott, On Wed, 10 Apr 2019, Scott Kitterman wrote: > I grepped the source for GZIP. Can you bit more specific? The buster sources contain the following mentioning of GZIP $ git grep GZIP Makefile.in:GZIP_ENV = --best Makefile.in:tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz Makefile.in:shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz Makefile.in: GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\ Makefile.in: GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\ tp/Texinfo/Convert/XSParagraph/Makefile.in:GZIP_ENV = --best tp/Texinfo/Convert/XSParagraph/Makefile.in: tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz tp/Texinfo/Convert/XSParagraph/Makefile.in: shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz tp/Texinfo/Convert/XSParagraph/Makefile.in: GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\ tp/Texinfo/Convert/XSParagraph/Makefile.in: GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\ tp/Texinfo/MiscXS/Makefile.in:GZIP_ENV = --best tp/Texinfo/MiscXS/Makefile.in: tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz tp/Texinfo/MiscXS/Makefile.in: shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz tp/Texinfo/MiscXS/Makefile.in:GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\ tp/Texinfo/MiscXS/Makefile.in:GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\ $ So that are only Makefile related variables and do not end up in the installed files. Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926757: sbuild doesn't use installed keys for archive verification
> "Johannes" == Johannes Schauer writes: Johannes> [1 ] Hi, Johannes> should you not add debian-ports-archive-keyring to --include Johannes> so that the keyring exists inside the chroot? Yes, but that doesn't fix this issue. sbuild-chroot bombs out on fetching the Release file before it ever gets that far. -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustworthy Systems Group Data61, CSIRO (formerly NICTA)
Bug#926765: nvidia-legacy-390xx-kernel-dkms not installable
Package: nvidia-legacy-390xx-kernel-dkms Version: 390.116-1 Severity: normal Dear Maintainer, When attempting to install nvidia-legacy-390xx-kernel-dkms, I encounter a dependency on nvidia-legacy-390xx-kernel-support--v1, which in turn depends on nvidia-legacy-390xx-alternative--kmod-alias, which aptitude and p.d.o report as unavailable: https://packages.debian.org/search?keywords=nvidia-legacy-390xx-alternative--kmod-alias&searchon=names&suite=all§ion=all Alternatively, if I'm doing it wrong, I would be gratful for any tips. Thanks for your work in maintaining the Nvidia drivers in Debian, Andreas -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nvidia-legacy-390xx-kernel-dkms depends on: ii dkms2.6.1-4 pn nvidia-installer-cleanup pn nvidia-legacy-390xx-kernel-support--v1 Versions of packages nvidia-legacy-390xx-kernel-dkms recommends: pn nvidia-legacy-390xx-driver | libnvidia-legacy-390xx-cuda1 nvidia-legacy-390xx-kernel-dkms suggests no packages.
Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns
On 31.03.19 00:06, Sven Hartge wrote: > On 25.03.19 20:25, Sven Hartge wrote: >> On 24.03.19 02:02, Sven Hartge wrote: >> >>> So far, so good. I have your packages running on the main webmail server >>> and the main web server for my university and so far everything is fine, >>> while default packages and the test1 packages with mpm_event would >>> normally start showing the symptoms after ~12 hours. >> >> Still no problems here and both systems have seen some serious traffic >> the last days, with the new semester starting next week and all. > > One week later: still no problems here. > > I also did a cross-check with 2.4.25-3+deb9u6 and it died after ~12 hours. > > So from my perspective 2.4.25-3+deb9u7~test2 fixes the problems with > mpm_event for me. Last report, because I replaced the test-packages with the ones from the security repository and switched back to mpm_worker: I've not seen and problems or even an indication of a problem when I was runnning the apache2 packages with the fully backported mpm_event. All servers I tested this on ran flawless, even with active mod_http2. All those servers would die at least once a week, often more often than that when running mpm_event with the old packages. I say: go for it. Please provide this change for the next point release. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#926747: unblock: adacontrol/1.20r7-2
On 10.04.19 02:55, Nicolas Boulenguez wrote: > override_dh_auto_test-arch: >ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) > - cd test && sh run.sh > +# Disable build-time tests so that the severity of #924835 can be > +# lowered and the package accepted into buster. An actual fix > +# requires a bit more time and probably a longer diff. > +#cd test && sh run.sh if the tests don't break the buildd, it would be better to run those and ignore the test results.
Bug#926760: install-info: GZIP environment variable warnings on buster
On Wednesday, April 10, 2019 03:04:43 PM Norbert Preining wrote: > Hi > > > gzip: warning: GZIP environment variable is deprecated; use an alias or > > script^M > I don't see a place where we set this in texinfo, could it be that your > /etc/environment(.d) > contains something like this? > > > I checked and libxmlrpc-lite-perl doesn't make reference to a GZIP > > environment variable. texinfo does. > > Where did you see this? I grepped the source for GZIP. Scott K > > Not urgent, but looks like something that should be addressed in the next > > cycle. > > Sure, that will be done if necessary. > > Thanks for the report > > Norbert > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. +JAIST +TeX Live +Debian Developer > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926764: spip: arbitrary code execution by any identified visitor
Source: spip Version: 3.2.3-1 Severity: grave Tags: upstream security fixed-upstream Control: fixed -1 3.2.4-1 Control: found -1 3.1.4-4~deb9u1 Control: found -1 3.1.4-4 Hi Filling a bug in Debian BTS to have a tracking reference (ideally though this will recieve a CVE): https://blog.spip.net/Mise-a-jour-CRITIQUE-de-securite-Sortie-de-SPIP-3-1-10-et-SPIP-3-2-4.html?lang=fr Already fixed in the unstable upload 3.2.4-1. Regards, Salvatore
Bug#926757: sbuild doesn't use installed keys for archive verification
Hi, Quoting peterc (2019-04-10 07:51:00) > I'm trying to build a chroot for riscv64. > > I've done > sudo apt-get install debian-ports-archive-keyring > sudo sbuild-createchroot --include=eatmydata,ccache,gnupg \ > --arch=riscv64 \ > sid /usr/home/sid-riscv64-sbuild \ > http://deb.debian.org/debian-ports/ > > and see: > Failed to fetch http://deb.debian.org/debian-ports/dists/sid/InRelease The > following signatures couldn't be verified because the public key is not > available: NO_PUBKEY DA1B2CEA81DCBC61 > > > To fix I had to do: > sudo gpg --no-default-keyring --keyring > /usr/share/keyrings/debian-archive-keyring.gpg --import > /etc/apt/trusted.gpg.d/debian-ports-archive-2019.gpg > > Looks like when sbuild invokes apt-get it's not using the right mechanism for > finding keys. should you not add debian-ports-archive-keyring to --include so that the keyring exists inside the chroot? Thanks! cheers, josch signature.asc Description: signature
Bug#926763: node-miller-rabin: Probably bad implementation of Miller-Rabin
Package: node-miller-rabin Version: 4.0.1-4 Severity: normal Tags: upstream Forwarded: https://github.com/indutny/miller-rabin/issues/9 As reported in #926720, correctly implemented Miller-Rabin test should have false positives only with negligible probability. See https://bugs.debian.org/926720 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-miller-rabin depends on: ii node-bn.js4.11.8-2 ii node-brorand 1.1.0-2 ii nodejs10.15.2~dfsg-1 node-miller-rabin recommends no packages. node-miller-rabin suggests no packages.
Bug#926760: install-info: GZIP environment variable warnings on buster
Hi > gzip: warning: GZIP environment variable is deprecated; use an alias or > script^M I don't see a place where we set this in texinfo, could it be that your /etc/environment(.d) contains something like this? > I checked and libxmlrpc-lite-perl doesn't make reference to a GZIP environment > variable. texinfo does. Where did you see this? > Not urgent, but looks like something that should be addressed in the next > cycle. Sure, that will be done if necessary. Thanks for the report Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926762: ITP: compile-command-annotations -- annotation based configuration file generator for the Hotspot JVM JIT compiler
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block 585905 by -1 * Package name : compile-command-annotations Version : 1.2.1 Upstream Author : Julien Nicoulaud * URL : http://compile-command-annotations.nicoulaj.net * License : Apache-2.0 Programming Lang: Java Description : annotation based configuration file generator for the Hotspot JVM JIT compiler The Hotspot JVM allows one to provide a command file for the JIT compiler. Using this project, one can generate this file automatically from annotations in the source code. Remark: This package is maintained by Debian Java Maintainers at https://salsa.debian.org/java-team/compile-command-annotations Package is a requirement for Apache Cassandra. -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#926761: ispell: GZIP environment variable warnings on buster
Package: ispell Version: 3.4.00-6 Severity: normal >From the apt term log of a Stretch -> Buster upgrade done today: ispell-autobuildhash: Processing 'american' dict.^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M ispell-autobuildhash: Processing 'british' dict.^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M Obviously not urgent, but something that will probably need to be addressed in the next cycle. Scott K
Bug#926760: install-info: GZIP environment variable warnings on buster
Package: install-info Version: 6.5.0.dfsg.1-4 Severity: normal Saw this in the apt term log from a Stretch -> Buster upgrade today: Setting up libxmlrpc-lite-perl (0.717-2) ...^M Processing triggers for sgml-base (1.29) ...^M Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M I checked and libxmlrpc-lite-perl doesn't make reference to a GZIP environment variable. texinfo does. Not urgent, but looks like something that should be addressed in the next cycle. Scott K
Bug#926757: sbuild doesn't use installed keys for archive verification
Package: sbuild Version: 0.78.1-2 Severity: normal Dear Maintainer, I'm trying to build a chroot for riscv64. I've done sudo apt-get install debian-ports-archive-keyring sudo sbuild-createchroot --include=eatmydata,ccache,gnupg \ --arch=riscv64 \ sid /usr/home/sid-riscv64-sbuild \ http://deb.debian.org/debian-ports/ and see: Failed to fetch http://deb.debian.org/debian-ports/dists/sid/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY DA1B2CEA81DCBC61 To fix I had to do: sudo gpg --no-default-keyring --keyring /usr/share/keyrings/debian-archive-keyring.gpg --import /etc/apt/trusted.gpg.d/debian-ports-archive-2019.gpg Looks like when sbuild invokes apt-get it's not using the right mechanism for finding keys. Peter C -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64 Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.78.1-2 ii perl5.28.1-6 Versions of packages sbuild recommends: ii autopkgtest 5.10 ii debootstrap 1.0.114 ii schroot 1.6.10-6+b1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.45.0-1 ii kmod 26-1 ii wget 1.20.1-1 -- no debconf information
Bug#926759: RFP: evacuated-property-accessors -- A mixin for declaring property accessors
Package: wnpp Severity: wishlist * Package name: evacuated-property-accessors Version : 1.1.3 Upstream Author : Nathan Sobo * URL : https://salsa.debian.org/themusicgod1-guest/evacuated-property-accessors/ * License : Expat Programming Lang: javascript Description : A mixin for declaring property accessors (fork of property-accessors with a different upstream repo) A mixin for defining dynamic properties. property-accessors is a prerequisite of meteor ( #842425 )
Bug#855856: MR on freedesktop
Apparently there's activity on this here? I got a MR in earlier this week. https://gitlab.freedesktop.org/xorg/app/xbiff
Bug#926728: Removing the package breaks the alternative on usr-merge system
Le 9/04/19 à 18:58, Arturo Borrero Gonzalez a écrit : On 4/9/19 6:34 PM, Laurent Bigonville wrote: Package: ebtables Version: 2.0.10.4+snapshot20181205-2 Severity: serious Hello, On system with usr-merge, removing ebtables breaks the alternative. The postinst script install symlinks from /sbin to /usr/sbin, in the prerm script these symlinks are removed. BUT ebtables also add itself as an alternative for ebtables implementations. That means that the symlinks installed by update-alternatives are rm when the package is removed. Not too sure how to fix this, maybe the prerm script should check if the symlinks directly point to a real file and only remove them in that case? Thanks for the report! I don't use usr-merge, so it would be great if you can provide concrete examples of which files and which symlinks are affected by the bug you are describing, and what would be the right state after package removal for them. On a usr-merge system, /sbin is a symlink pointing to /usr/sbin. The alternative symlinks are installed in (/usr)/sbin. In the postinst you have: # compat symlinks for /sbin -> /usr/sbin move, to be dropped in buster+1 LIST="/sbin/ebtables /sbin/ebtables-save /sbin/ebtables-restore" for i in $LIST ; do if [ ! -e "$i" ] ; then ln -sf /usr$i $i fi done On a usr-merge system, this will rightfully do nothing as /sbin/ebtables* are already existing, so that's OK OTOH, in the prerm you have: LIST="ebtables ebtables-save ebtables-restore" for i in $LIST ; do if [ -L "/sbin/$i" ] ; then rm /sbin/$i fi done On a non-usr-merge system, the symlinks in /sbin and the symlinks (from the alternative system) in /usr/sbin are different. On a usr-merge system, they are not. That means that you end up removing the symlinks from the alternative system and not the one you have (supposedly) created. AFAICS, this also impacts arptables package. Note that usr-merge is now the default on all new debian installation.
Bug#926756: clamav-freshclam: GZIP environment variable warnings on buster
Package: clamav-freshclam Version: 0.100.2-1 Severity: normal Stretch -> Buster upgrade today: Setting up clamav-freshclam (0.101.2+dfsg-1) ...^M Installing new version of config file /etc/apparmor.d/usr.bin.freshclam ...^M Installing new version of config file /etc/network/if-down.d/clamav-freshclam-ifupdown ...^M Installing new version of config file /etc/network/if-up.d/clamav-freshclam-ifupdown ...^M Installing new version of config file /etc/ppp/ip-down.d/clamav-freshclam-ifupdown ...^M Installing new version of config file /etc/ppp/ip-up.d/clamav-freshclam-ifupdown ...^M gzip: warning: GZIP environment variable is deprecated; use an alias or script^M Replacing config file /etc/logrotate.d/clamav-freshclam with new version^M Not critical, but something worth looking into. Scott K
Bug#926755: unblock: spf-engine/2.9.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package spf-engine The pyspf-milter binary is not configurable as currently in Buster. Due to doing upstream development and package testing on the same machine, I failed to notice that, as packaged for Debian, no configuration file is installed and it looks in /usr/local/etc for a configuration file. Sigh. There's no chance of regression with the fix. The defaults in the now provided config file (in /etc/pyspf-milter) are the same as the defaults used internally by the milter if no configuration file is found. I've tested upgrade from the broken version and fresh installs. It's a new binary for Buster, so there's no Stretch -> Buster upgrade path to test. Scott K unblock spf-engine/2.9.0-3 diff -Nru spf-engine-2.9.0/debian/changelog spf-engine-2.9.0/debian/changelog --- spf-engine-2.9.0/debian/changelog 2019-02-05 19:06:03.0 -0500 +++ spf-engine-2.9.0/debian/changelog 2019-04-10 01:10:00.0 -0400 @@ -1,3 +1,10 @@ +spf-engine (2.9.0-3) unstable; urgency=medium + + * Install pyspf-milter config file in /etc/pyspf-milter/pyspf-milter.conf +and update the service file so it is used (Closes: #926752) + + -- Scott Kitterman Wed, 10 Apr 2019 00:28:09 -0400 + spf-engine (2.9.0-2) unstable; urgency=high * Add Breaks/Replaces for python3-spf-engine to fix upgrade issues (Closes: diff -Nru spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch --- spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch 2019-02-01 20:26:21.0 -0500 +++ spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch 2019-04-10 00:27:13.0 -0400 @@ -134,7 +134,7 @@ Type=simple PIDFile=/var/run/pyspf-milter/pyspf-milter.pid -ExecStart=/usr/local/bin/pyspf-milter /usr/local/etc/pyspf-milter.conf -+ExecStart=/usr/bin/pyspf-milter ++ExecStart=/usr/bin/pyspf-milter /etc/pyspf-milter/pyspf-milter.conf [Install] WantedBy=multi-user.target diff -Nru spf-engine-2.9.0/debian/pyspf-milter.conf spf-engine-2.9.0/debian/pyspf-milter.conf --- spf-engine-2.9.0/debian/pyspf-milter.conf 1969-12-31 19:00:00.0 -0500 +++ spf-engine-2.9.0/debian/pyspf-milter.conf 2019-04-10 01:09:32.0 -0400 @@ -0,0 +1,19 @@ +# For a fully commented sample config file see policyd-spf.conf.commented + +debugLevel = 1 +TestOnly = 1 + +HELO_reject = Fail +Mail_From_reject = Fail + +PermError_reject = False +TempError_Defer = False + +skip_addresses = 127.0.0.0/8,:::127.0.0.0/104,::1 + +# Milter specific options +Socket = local:/run/pyspf-milter/pyspf-milter.sock +PidFile = /run/pyspf-milter/pyspf-milter.pid +UserID = pyspf-milter +InternalHosts = 127.0.0.1 +#MacroListVerify = diff -Nru spf-engine-2.9.0/debian/pyspf-milter.install spf-engine-2.9.0/debian/pyspf-milter.install --- spf-engine-2.9.0/debian/pyspf-milter.install 2019-02-01 20:43:29.0 -0500 +++ spf-engine-2.9.0/debian/pyspf-milter.install 2019-04-10 00:27:41.0 -0400 @@ -1,3 +1,4 @@ system/pyspf-milter etc/init.d/ system/pyspf-milter.service lib/systemd/system/ +debian/pyspf-milter.conf etc/pyspf-milter build/usr/bin/pyspf-milter /usr/bin
Bug#926754: RFP: node-evacuated-eol -- end of line api
Package: wnpp Severity: wishlist * Package name: node-evacuated-eol Version : 0.9.1 Upstream Author : Ryan Van Etten * URL : https://salsa.debian.org/themusicgod1-guest/evacuated-eol/ * License : MIT Programming Lang: javascript Description : end of line api Newline character converter API for javascript Makes using endlines across platforms easier to handle. eol is a prerequisite for node-ecstatic ( #910614 ).
Bug#926751: gcc-riscv64-linux-gnu: Doesn't work with all valid abi combinations.
Control: reassign -1 src:glibc these are glibc headers. On 10.04.19 04:05, peterc wrote: > Package: gcc-riscv64-linux-gnu > Version: 4:8.3.0-2 > Severity: normal > > Dear Maintainer, > > > My RISC V64 implementation doesn't have floating point, so I'm trying > to compile with > -march=rv64imac -mabi=lp64 > > I see: > $ riscv64-linux-gnu-gcc -mabi=lp64 -march=rv64imac x.c > In file included from /usr/riscv64-linux-gnu/include/features.h:448, > from > /usr/riscv64-linux-gnu/include/bits/libc-header-start.h:3, > from /usr/riscv64-linux-gnu/include/stdio.h:27, > from x.c:1: > /usr/riscv64-linux-gnu/include/gnu/stubs.h:8:11: fatal error: > gnu/stubs-lp64.h: No such file or directory > # include > compilation terminated. > > for a simple hello world program. > > It looks as if only march=rv64imafdc/mabi=lp64d is supported; please > can the other valid combinations be supported as well? > > The current list is: > > march=rv32i/mabi=ilp32 > march=rv32im/mabi=ilp32 > march=rv32iac/mabi=ilp32 > march=rv32imac/mabi=ilp32 > march=rv32imafc/mabi=ilp32f > march=rv64imac/mabi=lp64 > march=rv64imafdc/mabi=lp64d > > Peter C > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, > 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64 > > Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores) > Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), > LANGUAGE=en_AU:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages gcc-riscv64-linux-gnu depends on: > ii cpp-riscv64-linux-gnu4:8.3.0-2 > ii gcc-8-riscv64-linux-gnu 8.3.0-4cross2 > > Versions of packages gcc-riscv64-linux-gnu recommends: > ii libc6-dev-riscv64-cross [libc-dev-riscv64-cross] 2.28-7cross1 > > Versions of packages gcc-riscv64-linux-gnu suggests: > ii autoconf 2.69-11 > ii automake 1:1.16.1-4 > ii bison 2:3.3.2.dfsg-1 > ii flex 2.6.4-6.2 > ii gcc-doc5:7.2.0-2 > pn gdb-riscv64-linux-gnu > ii libtool2.4.6-10 > ii make 4.2.1-1.2 > ii manpages-dev 4.16-1 > > -- no debconf information >
Bug#926753: fonts-noto-cjk: New version available upstream
Package: fonts-noto-cjk Version: 1:20170601+repack1-2 Severity: normal Hello, Noto Sans CJK version 2.001 was released yesterday. It contains a number of fixes, and the release is timed to the Unicode 12.1 addition of U+32FF (㋿), the ligature of the new Japanese era (令和). Kindly, Kess -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) fonts-noto-cjk depends on no packages. fonts-noto-cjk recommends no packages. Versions of packages fonts-noto-cjk suggests: ii fonts-noto-cjk-extra 1:20170601+repack1-3 -- no debconf information
Bug#924291: closed by Markus Koschany (Bug#924291: fixed in netrek-client-cow 3.3.1-3)
Control: reopen -1 Hi Markus, On Sun, Mar 24, 2019 at 01:09:06PM +, Debian Bug Tracking System wrote: >* Fix infinite loop patch. Really (Closes: #924291) As much as I hate to say this, it still loops. You can see failing (cross) builds at http://crossqa.debian.net/src/netrek-client-cow. All of them were terminated by manual intervention. Remember: I'm not asking for netrek-client-cow to cross build. I'm asking for it to fail sanely. The current version loops like this: | /bin/sh: 1: ./mkkey: Exec format error | /bin/sh: 1: attempts: not found | /bin/sh: 1: test: -le: unexpected operator My initial report asked for what this key is being used for. It still seems strange to me to generate a key at build time and the distribute it to many users. Could you provide an initial answer on the purpose of this thing? It feels a little strange to invest a longer thread into something that should not be there (in my book). Would it be ok to pursue that question first? Helmut
Bug#926752: pyspf-milter: Configuration file not install, default config uses /usr/local
Package: pyspf-milter Version: 2.9.0-2 Severity: serious Justification: causes non-serious data loss Sigh, As packaged, no configuration file is installed and on startup it attempts to read the configuration from /usr/local/etc instead of /etc. This was masked by leftover /usr/local bits I had from pre-Debian upload development. This isn't hard to fix, but it should definitely be fixed for Buster. I will upload a fix shortly. Scott K
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Wed, Apr 10, 2019 at 12:00 AM Alexander Larsson wrote: > > On Tue, Apr 9, 2019 at 4:57 PM Alexander Larsson > wrote: > > > > On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH wrote: > > > > > > Yes. done. hope that works well. > > > > Yes, this now seems to work well. I think this is good to go! > > Oh, and once this lands, any chance we could have a minimal backport > of the changes to fontconfig 2.13.1 for the LTS flatpak runtimes? Thanks for testing. for minimal backport, let me figure it out and apply for Fedora updates. you can pull it in from there. -- Akira TAGOH
Bug#926751: gcc-riscv64-linux-gnu: Doesn't work with all valid abi combinations.
Package: gcc-riscv64-linux-gnu Version: 4:8.3.0-2 Severity: normal Dear Maintainer, My RISC V64 implementation doesn't have floating point, so I'm trying to compile with -march=rv64imac -mabi=lp64 I see: $ riscv64-linux-gnu-gcc -mabi=lp64 -march=rv64imac x.c In file included from /usr/riscv64-linux-gnu/include/features.h:448, from /usr/riscv64-linux-gnu/include/bits/libc-header-start.h:3, from /usr/riscv64-linux-gnu/include/stdio.h:27, from x.c:1: /usr/riscv64-linux-gnu/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-lp64.h: No such file or directory # include compilation terminated. for a simple hello world program. It looks as if only march=rv64imafdc/mabi=lp64d is supported; please can the other valid combinations be supported as well? The current list is: march=rv32i/mabi=ilp32 march=rv32im/mabi=ilp32 march=rv32iac/mabi=ilp32 march=rv32imac/mabi=ilp32 march=rv32imafc/mabi=ilp32f march=rv64imac/mabi=lp64 march=rv64imafdc/mabi=lp64d Peter C -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64 Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-riscv64-linux-gnu depends on: ii cpp-riscv64-linux-gnu4:8.3.0-2 ii gcc-8-riscv64-linux-gnu 8.3.0-4cross2 Versions of packages gcc-riscv64-linux-gnu recommends: ii libc6-dev-riscv64-cross [libc-dev-riscv64-cross] 2.28-7cross1 Versions of packages gcc-riscv64-linux-gnu suggests: ii autoconf 2.69-11 ii automake 1:1.16.1-4 ii bison 2:3.3.2.dfsg-1 ii flex 2.6.4-6.2 ii gcc-doc5:7.2.0-2 pn gdb-riscv64-linux-gnu ii libtool2.4.6-10 ii make 4.2.1-1.2 ii manpages-dev 4.16-1 -- no debconf information
Bug#926750: inetutils-ping: ping --interval documentation (--help and manpage) are not correct
Package: inetutils-ping Version: 2:1.9.4-7 Severity: normal Dear Maintainer, ping and ping6 from this packages say in their --help: -i, --interval=NUMBER wait NUMBER seconds between sending each packet and ping6(1) manpage: -i, --interval=number Wait number seconds between sending each packet. and ping(1) manpage: -i, --interval wait Wait wait seconds between sending each packet. The default is to wait for one second between each packet. This option is incompatible with the -f option. Ignoring for a moment inconsistent style of documenation, I think the wait is actually in milliseconds. # time ping6 --numeric --interval=1000 --count=3 google.com PING google.com (2a00:1450:400a:803::200e): 56 data bytes 64 bytes from 2a00:1450:400a:803::200e: icmp_seq=0 ttl=55 time=0.943 ms 64 bytes from 2a00:1450:400a:803::200e: icmp_seq=1 ttl=55 time=0.751 ms 64 bytes from 2a00:1450:400a:803::200e: icmp_seq=2 ttl=55 time=0.791 ms --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.751/0.828/0.943/0.083 ms real0m2.006s user0m0.002s sys 0m0.000s # That is good and useful for subsecond pings counts, but documentation and --help text seems not accurate. It is also worth nothing that it must be an integer number of miliseconds, i.e. 0.5 will not work. Also doing --interval=0 sends pings very quickly, which is almost equivalent to -f, which is disabled for non users. IMHO, interval smaller than 50ms should be protected by the same mechanism probably. Not that it is a "real protection" (because one can just spawn 1000 of processes to do it anyway), but I guess consistency would be useful :) Thanks! :) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inetutils-ping depends on: ii libc6 2.28-8 ii libidn11 1.33-2.2 ii netbase 5.5 inetutils-ping recommends no packages. inetutils-ping suggests no packages. -- no debconf information
Bug#926749: fprintd: stores user fingerprints as a standard template without encryption
Package: fprintd Version: 0.7.0-1 Severity: important Dear Maintainer, It was found that fprintd saves fingerprint template and without any encryption, to a file with root permission on the host. This could allow a privileged process to access the stored fingerprint. In fprintd, MINDTCT feature extractor from the NIST Biometric Image Software (NBIS) extracts fingerprint minutiae that are compliant to ANSI INCITS 378-2004. The generated template file can be easily converted to ISO/IEC 19794-2 format since it is a minor modification of the earlier ANSI-INCITS 378-2004. Currently, it is well known threat model that the standard fingerprint template can be reverted to original fingerprint image. [1-5] are presented to create sophisticated and natural-looking fingerprints only from the numerical template data format as defined in standard format. They also successfully evaluated these approaches against a number of undisclosed state-of-the-art algorithms and the NBIS. As per upstream, the only way to safeguard the fingerprint data is to run with SELinux, AppArmor or another LSM enabled one. (link: https://gitlab.freedesktop.org/libfprint/fprintd/issues/16#note_141207) Currently, Fedora and Red Hat Enterprise Linux have a safeguard the fingerprint data since they uses SELinux by default while Ubuntu and Debian did not. Once fingerprint has been leaked, victims are leaked for the rest of life since it lasts for a life. It is necessary to prepare for the problem. [1] R. Cappelli et al., “Fingerprint Image Reconstruction from Standard Templates”, IEEE Trans. on Pattern Analysis and Machine Intelligence, vol.29, no.9, pp.1489-1503, 2007. [2] A. Ross et al., “From template to image: Reconstructing fingerprints from minutiae points”, IEEE Trans on Pattern Analysis and Machine Intelligence, vol.29, no.4, pp.544-560, 2007. [3] R. Cappelli et al., “Can Fingerprints be reconstructed from ISO Templates?”, IEEE ICARCV 2006. [4] J. Feng et al., “Fingerprint Reconstruction: From Minutiae to Phase”, IEEE Trans on Pattern Analysis and Machine Intelligence, vol.33, no.2, pp.209-223, 2011. [5] A. Rozsa et al., "Genetic Algorithm Attack on Minutiae-Based Fingerprint Authentication and Protected Template Fingerprint Systems", CVPR 2015. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fprintd depends on: ii dbus 1.10.26-0+deb9u1 ii libc6 2.24-11+deb9u4 ii libdbus-1-31.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libfprint0 1:0.6.0-2 ii libglib2.0-0 2.50.3-2 ii libpolkit-gobject-1-0 0.105-18+deb9u1 ii policykit-10.105-18+deb9u1 fprintd recommends no packages. fprintd suggests no packages. -- no debconf information
Bug#926740: bugs.debian.org: Subscription confirmation reply-to address length exceeds RFC-5321 limit
On Tue, 09 Apr 2019, Nazar Zhuk wrote: > I subscribed to a bug (924787) and received a confirmation email asking > me to confirm the subscription by emailing to > 924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org > > My smpt server (mailfence) rejects an email to this address with a > message: > > --- > The recipient address > <924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org> > is not a valid RFC-5321 address.. Hrm; yep, that looks like a bug. Thanks for the report! -- Don Armstrong https://www.donarmstrong.com What I can't stand is the feeling that my brain is leaving me for someone more interesting.
Bug#925411: kernel-package: Not suitable for release
On Mon, 2019-04-08 at 00:20 -0400, Nicholas D Steeves wrote: [...] > Ah, yes, thank you! :-) Regarding documentation, should > Debian-specific bits go on our wiki or be forwarded upstream? The bindeb-pkg target is part of the upstream build system, not something patched in by Debian, so the primary place to document it should be upstream. [...] > Should users who track a 4.19.x-based branch use buster's > linux-libc-dev headers, or install the ones that correspond to their > custom kernel? [...] No, the only reason to install a custom linux-libc-dev package would be to provide definitions for new UAPI added in a new kernel version. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#926748: cargo: Cargo is too old
Package: cargo Version: 0.15.0~dev-1+rpi1 Severity: normal Dear Maintainer, I am working on a RaspberryPi 3B+ running Raspian. I have a Python program that fills out a multi-page webform. To do so, I need Firefox, Selenium, WebDriver and geckodriver. Python-Selenium odes the heavy lifting through WebDriver. Debian and Raspbian do not provide geckodriver so I have to build it from sources. That means I need Cargo and Rust. Attempting to build geckodriver results in a lot of errors. Cf., https://github.com/rust-lang/cargo/issues/6836. According to the Cargo folks Debian's Cargo is too old. Please consider providing a more modern Cargo. In the system info below, Raspbian is fully patched. There is nothing to install or update. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.8 (stretch) Release:9.8 Codename: stretch Architecture: armv7l Kernel: Linux 4.14.98-v7+ (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cargo depends on: ii binutils2.28-5 ii gcc [c-compiler]4:6.3.0-4 ii gcc-6 [c-compiler] 6.3.0-18+rpi1+deb9u1 ii libc6 2.24-11+deb9u4 ii libcurl3-gnutls 7.52.1-5+deb9u9 ii libgcc1 1:6.3.0-18+rpi1+deb9u1 ii libhttp-parser2.1 2.1-2 ii libssh2-1 1.7.0-1 ii libssl1.0.2 1.0.2r-1~deb9u1 ii rustc 1.24.1+dfsg1-1~deb9u2+rpi1 ii zlib1g 1:1.2.8.dfsg-5 cargo recommends no packages. Versions of packages cargo suggests: pn cargo-doc -- no debconf information
Bug#926747: unblock: adacontrol/1.20r7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package adacontrol. Two post-build tests have started to fail recently, causing a "serious" bug (FTBFS). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924835 Investigation requires too much time for a freeze period. Instead, version 1.20r7-2 skips post-build tests. The trivial diff with 1.20r7-1 in testing follows. The package now builds correctly in unstable. #924835 is not closed, but it severity becomes "minor". unblock adacontrol/1.20r7-2 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +adacontrol (1.20r7-2) unstable; urgency=medium + + * Disable tests, lowering the severity of #924835. + + -- Nicolas Boulenguez Thu, 04 Apr 2019 21:13:55 +0200 + adacontrol (1.20r7-1) unstable; urgency=medium * New upstream release. --- a/debian/rules +++ b/debian/rules @@ -54,7 +54,10 @@ override_dh_auto_test-arch: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) - cd test && sh run.sh +# Disable build-time tests so that the severity of #924835 can be +# lowered and the package accepted into buster. An actual fix +# requires a bit more time and probably a longer diff. +# cd test && sh run.sh endif override_dh_auto_clean:: rm -fr test/res
Bug#926701: texlive-bin: FTBFS on hurd-i386
Hi HIlmar, > The -ldl is missing in unstable too, so my first analysis is wrong. I'll > have a look at this later on. We have different linker flags in unstable Hmm, there aren't that many changes from unstable to current experimental (from the texlive-source git mirror repo $ git log 408ab1ec3b4e6f143d26a4c9855106a619ff31c2..HEAD texk/dvisvgm/ commit edb2e98bfce1f4733eaa2b77aaa6d79052494926 Author: Karl Berry Date: Tue Mar 26 22:32:47 2019 + ZLIB_INCLUDES in AM_CFLAGS for ff-woff git-svn-id: svn://tug.org/texlive/trunk/Build/source@50610 c570f23f-e606-0410-a88d-b1316a301751 commit 0e0d51fcc99be7296ff91ede9f9e98908c8dfb84 Author: Karl Berry Date: Mon Mar 25 17:27:50 2019 + try pkg-config if freetype-config not available git-svn-id: svn://tug.org/texlive/trunk/Build/source@50584 c570f23f-e606-0410-a88d-b1316a301751 commit f6a7573dfbc2df4e34fce07c02ff21eedbaf7a8e Author: Karl Berry Date: Sun Mar 10 18:21:29 2019 + dvisvgm 2.6.3 git-svn-id: svn://tug.org/texlive/trunk/Build/source@50315 c570f23f-e606-0410-a88d-b1316a301751 commit 1400b7b5d6dd9974a7531cf0dcd9ec1ce0fa5694 Author: Karl Berry Date: Mon Feb 25 19:13:14 2019 + (CXXFLAGS): WARNING_CXXFLAGS and no no-mismatched-tags git-svn-id: svn://tug.org/texlive/trunk/Build/source@50126 c570f23f-e606-0410-a88d-b1316a301751 commit 89adfe5d34c658b678f2ec40053544661a5c5033 Author: Karl Berry Date: Sun Feb 10 23:22:35 2019 + mingw cross-compilation fixes from lscarso git-svn-id: svn://tug.org/texlive/trunk/Build/source@49996 c570f23f-e606-0410-a88d-b1316a301751 commit b637e295e376a0bc63baaf7501de12afc8ad86db Author: Karl Berry Date: Thu Jan 31 18:21:25 2019 + install dvisvgm.1 git-svn-id: svn://tug.org/texlive/trunk/Build/source@49882 c570f23f-e606-0410-a88d-b1316a301751 commit d3bbca9ba34731ee397f88b9b29e3f25f7384b4b Author: Karl Berry Date: Fri Jan 25 23:20:32 2019 + dvisvgm 2.6.2 git-svn-id: svn://tug.org/texlive/trunk/Build/source@49819 c570f23f-e606-0410-a88d-b1316a301751 commit 71b5b1e035db20be06aedf330204960ee4d3268a Author: Karl Berry Date: Mon Dec 24 23:22:06 2018 + reautoconf git-svn-id: svn://tug.org/texlive/trunk/Build/source@49496 c570f23f-e606-0410-a88d-b1316a301751 Also looking at the actual diff, not much is jumping at me ... The check of dlopen is still included in the .ac file. Surely, we can simply add the -ld somewhere, but I would like to understand why ... Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926746: libbluray: ftbfs during arch:all only build
Source: libbluray Version: 1:1.1.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) libbluray/experimental FTBFS during the arch:all only build: https://buildd.debian.org/status/fetch.php?pkg=libbluray&arch=all&ver=1%3A1.1.1-1&stamp=1554567686&raw=0 fakeroot debian/rules binary-indep dh binary-indep --with javahelper dh_testroot -i dh_prep -i dh_install -i dh_install: Cannot find (any matches for) "usr/share/java" (tried in ., debian/tmp) dh_install: libbluray-bdj missing files: usr/share/java dh_install: missing files, aborting make: *** [debian/rules:21: binary-indep] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess returned exit status 2 Andreas
Bug#882324: fixed in amavisd-new 1:2.11.0-6.1
On 2019-04-10 09:32, MK wrote: Any chance of having this pushed into debian-release for buster via an unblock request? This seems important to anyone running a mail server with amavis in buster. I believe it was unblocked already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926580 It is only 2 days old however, needs to be 5 days: https://tracker.debian.org/pkg/amavisd-new
Bug#926745: RFP: golang-salsa-themusicgod1-guest-go-duktape-dev -- Duktape JavaScript engine bindings for Go
Package: wnpp Severity: wishlist * Package name: golang-salsa-themusicgod1-guest-go-duktape-dev Version : v3 Upstream Author : Oleg Lebedev * URL : https://salsa.debian.org/themusicgod1-guest/golang-salsa-themusicgod1-guest-go-duktape-dev * License : expat Programming Lang: go Description : Duktape JavaScript engine bindings for Go Go bindings for Duktape, evacuated/forked from NSA/Microsoft github. Duktape is a thin, embeddable javascript engine. Most of the Duktape api is implemented. "no need to install any external C libraries."
Bug#926744: gimp: Error message when backporting Gimp 2.10.8-2 Debian package from unstable to stable
Package: gimp Version: 2.10.8-2 Severity: normal Dear Maintainer, Reported at https://gitlab.gnome.org/GNOME/gimp/issues/3216 but I got answer which suggests the Gimp devs consider this a Debian issue. So reporting it here. Summary, I tried to backport the Debian Gimp 2.10.8 packaging to stable, the build errors out with failed tests. I've done this with lots of packages. It normally works, but I realise Gimp is a complex piece of software with many dependencies. I'm attaching app/tests/test-suite.log. I haven't actually installed the 2.10.8 package, though I'm upgraded a bunch of dependencies. So the versions reported are a bit off. I'd appreciate any ideas about what these failed tests might mean. Regards, Faheem Mitha -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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) Versions of packages gimp depends on: ii gimp-data2.8.18-1+deb9u1 ii libaa1 1.4p5-44+b1 ii libatk1.0-0 2.22.0-1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libexif120.6.21-2+b2 ii libexpat12.2.0-2+deb9u1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libgegl-0.3-00.3.8-4 ii libgimp2.0 2.8.18-1+deb9u1 ii libglib2.0-0 2.60.0-1 ii libgs9 9.26a~dfsg-0+deb9u1 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.1-2 ii libjson-glib-1.0-0 1.2.6-1 ii liblcms2-2 2.9-3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpng16-16 1.6.28-1 ii libpoppler-glib8 0.48.0-2+deb9u2 ii librsvg2-2 2.40.16-1+b1 ii libsm6 2:1.2.2-1+b3 ii libtiff5 4.0.8-2+deb9u4 ii libwmf0.2-7 0.2.8.4-10.6 ii libx11-6 2:1.6.4-3+deb9u1 ii libxcursor1 1:1.1.14-1+deb9u2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii python 2.7.13-2 ii python-gtk2 2.24.0-5.1 ii python2.72.7.13-2+deb9u3 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.26a~dfsg-0+deb9u1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-0.1 ii gvfs-backends 1.30.4-1 ii libasound21.1.3-5 -- no debconf information === GIMP 2.10.8: app/tests/test-suite.log === # TOTAL: 9 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 6 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test-save-and-export == gimp_icons_sanity_check: Icon theme path has no 'hicolor' subdirectory: /usr/share/gimp/2.0/icons /gimp-save-and-export/new_file_has_no_files: Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) OK /gimp-save-and-export/opened_xcf_file_files: OK /gimp-save-and-export/imported_file_files: OK /gimp-save-and-export/saved_imported_file_files: OK /gimp-save-and-export/exported_file_files: Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) OK /gimp-save-and-export/clear_import_file_after_export: OK (/usr/local/src/gimp/gimp-2.10.8/app/tests/.libs/test-sa
Bug#882324: fixed in amavisd-new 1:2.11.0-6.1
Any chance of having this pushed into debian-release for buster via an unblock request?This seems important to anyone running a mail server with amavis in buster. Thanks-M
Bug#518750: pommed: cannot mmap memory for GMA950/GMA965
Control: reassign -1 pommed Hi! On Mon, 2009-04-13 at 20:40:13 +0200, Martin Mares wrote: > > This bug is not present in version 3.0.3 (Lenny), it's in 3.1.2 as > > explained above by Julien. > > This is not a bug in libpci, but rather a deficiency in its documentation > leading to improper usage in certain applications. > > The pci_dev->base_addr[] array was always intended to contain the BAR > values including the flags in lower bits and it behaved that way for > a long time, except for the sysfs back-end which was setting them > improperly. This bug was however fixed in pciutils-3.1.0 > (commit 6d143c3283855c474445a3cf27c65280ed7ab1b7), exposing the > problem in applications to a much larger audience. > > I have added a note to the declaration in lib/pci.h explaining > the proper semantics. So this is really an issue in pommed, as per the pciutils upstream developer's comment above. Reassigning back. Thanks, Guillem
Bug#926743: fetchmail: update-libc.d script can't find invoke-rc.d
Package: fetchmail Version: 6.4.0~beta4-3 Severity: normal Tags: patch Dear Maintainer, fetchmail 6.4.0~beta4-3 doesn't play nicely with init-system-helpers 1.56+nmu1 in Unstable. We get the following error on device ifdown: [schwarzgerat](0) $ sudo ifdown iw7260 ...blahblah DHCPRELEASE of ** /etc/resolvconf/update-libc.d/fetchmail: 4: /etc/resolvconf/update-libc.d/fetchmail: invoke-rc.d: not found run-parts: /etc/resolvconf/update-libc.d/fetchmail exited with return code 127 run-parts: /etc/resolvconf/update.d/libc exited with return code 1 [schwarzgerat](0) $ The problem is resolved by supplying the full path (among other possible solutions). I've included a patch to do this. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.0.7 (SMP w/20 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.8.6.1 ii libc6 2.28-8 ii libcom-err2 1.45.0-1 ii libgssapi-krb5-2 1.17-2 ii libk5crypto3 1.17-2 ii libkrb5-3 1.17-2 ii libssl1.1 1.1.1b-1 ii lsb-base 10.2019031300 Versions of packages fetchmail recommends: ii ca-certificates 20190110 Versions of packages fetchmail suggests: pn fetchmailconf ii postfix [mail-transport-agent] 3.4.5-1 ii resolvconf 1.79 -- no debconf information diff -ur fetchmail-6.4.0~beta4/debian/resolvconf fetchmail-6.4.0~beta4-new/debian/resolvconf --- fetchmail-6.4.0~beta4/debian/resolvconf 2018-06-23 11:52:22.0 -0400 +++ fetchmail-6.4.0~beta4-new/debian/resolvconf 2019-04-09 18:53:43.756857127 -0400 @@ -1,5 +1,5 @@ #!/bin/sh if [ -x /etc/init.d/fetchmail ] && [ -n "$(pidof fetchmail)" ]; then -invoke-rc.d --quiet fetchmail awaken +/usr/sbin/invoke-rc.d --quiet fetchmail awaken fi
Bug#926742: netdata: /etc/netdata/edit-config looks for config files in the wrong place
That should have read:
sudo /etc/netdata/edit-config health.d/tcp_listen.conf
edit-config should be something like:
[ -z "${NETDATA_USER_CONFIG_DIR}" ] &&
NETDATA_USER_CONFIG_DIR="/etc/netdata"
[ -z "${NETDATA_STOCK_CONFIG_DIR}" ] &&
NETDATA_STOCK_CONFIG_DIR="/usr/lib/netdata/conf.d"
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 08/04/19 a las 21:29, Matthijs Kooijman escribió: > Hi Luca & others, > > I've been working on syslinux-efi support in the past weeks and just > submitted a MR with a working implementation, along with some small > bootloader-related cleanups and refactors: > > https://salsa.debian.org/live-team/live-build/merge_requests/19 1) What is the rationale behind removing the --templates option explanation on manpage? Do you remove it in any of your commits? Which one? Or someone else did remove it? Thank you. Note: I will make more comments about this bug later in the week. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#926742: netdata: /etc/netdata/edit-config looks for config files in the wrong place
Package: netdata Version: 1.12.2-2 Severity: normal $ sudo /etc/netdata/edit-config tcp_listen.conf File 'tcp_listen.conf' is not found in '/usr/local/lib/netdata/conf.d' Config files are in /usr/lib/netdata when using debian. -- debconf information excluded
Bug#926741: RFP: node-evacuated-mocha -- simple, flexible, fun test framework - Node.js module
Package: wnpp Severity: wishlist * Package name: node-evacuated-mocha Version : 5.2.0 Upstream Author : TJ Holowaychuk * URL : https://salsa.debian.org/themusicgod1-guest/evacuated-mocha * License : MIT Programming Lang: javascript Description : simple, flexible, fun test framework - Node.js module This is an alternative upstream repo/fork to the existing node-mocha. Mocha is a feature-rich JavaScript test framework running on Node.js and browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Node.js is an event-based server-side JavaScript engine. node-evacuated-mocha is a prerequisite to node-gulp-spawn-mocha ( #922716 ).
Bug#925489: marked as done (unblock: elogind/241.1-1+debian1)
On Mon, Apr 08, 2019 at 02:57:03PM +, Debian Bug Tracking System wrote: > > I am aware that the debdiff against testing (239.3+20190131-1+debian1) is > > significantly larger than you would normally want at this stage in the > > release > > cycle. However, I believe it is warranted and ask for your consideration. > > > The benefits of migration centre around this version of elogind providing > > ABI > > compatibility between libelogind0 and libsystemd0 (see #923244). This means > > that > > packages compiled against libsystemd-dev headers work correctly with either > > libsystemd0 or libelogind0 runtime libraries. This is particularly > > important for > > policykit-1 authorization of many desktop functions (particularly restart, > > halt, > > suspend and for pkexec which is essential for synaptic) on non-systemd init > > installations. > This change is way to big to be unblocked. I agree -- but this approach was what was requested for policykit-1. What would you suggest instead? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926738: git-send-email: transferencoding config ignored
tags 926738 + upstream patch forwarded 926738 https://public-inbox.org/git/20190409192733.10173-1-xypron.g...@gmx.de/ quit Hi, Heinrich Schuchardt wrote: > The value of the sendmail.transferencoding configuration item is ignored. > > A patch has been submitted as > https://marc.info/?l=git&m=155483810827726&w=2 Thanks for reporting. Let's discuss this upstream. Sincerely, Jonathan
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
On Tue, 09 Apr 2019 at 17:26:22 +0200, gregor herrmann wrote:
> On Tue, 09 Apr 2019 17:14:32 +0200, Guilhem Moulin wrote:
>> With TLS 1.3? (You can pass ‘SSL_version => "TLSv1_3"’ to ssl_opts to
>> force this.) Doesn't work here, still hangs on read():
>
> Yes, also with using TLSv1_3 explicitly:
> […]
> (trace attached in case it helps)
AFAICT this worked this time because the socket was *only* marked as
ready for writing after the first select() call. Only during the second
call was there some data to be read:
> select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 1 (out [3], left
> {tv_sec=179, tv_usec=96})
> select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left
> {tv_sec=179, tv_usec=977469})
I'm unable to reproduce this with v1.3, probably due to race conditions.
Anyway I fail to see how the patch can help, because as I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#101 the socket
is in blocking mode (hence SSL_MODE_AUTO_RETRY is set) by the time LWP
starts its select loop, and SSL_MODE_AUTO_RETRY is set. This is visible
by adding fcntl(2) to the traced set of system calls:
$ strace -etrace=fcntl,select,read perl -MLWP::UserAgent -MIO::Socket::SSL
-e \
'$IO::Socket::SSL::DEBUG = 3;
LWP::UserAgent->new(ssl_opts => {SSL_version =>
"TLSv1_3"})->post("https://facebook.com";, { data => "" })'
[…]
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce
timeout=180
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
read(3, 0x5628bec16923, 5) = -1 EAGAIN (Resource temporarily
unavailable)
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:857: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:867: waiting for fd to become ready: SSL wants
a read first
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left
{tv_sec=179, tv_usec=988296})
DEBUG: .../IO/Socket/SSL.pm:887: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
[…]
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:902: ssl handshake done
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3],
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 156) = 156
read(3,
When the non-application record comes in, the socket is marked as ready
for reading, but SSL_read() transparently processes the non-application
data record, and blocks on trying to read an application data record.
If one is lucky and the socket is *only* marked as ready for writing (ie
not for reading as well, like in your trace) when select() returns then
the problem doesn't trigger (at least not right after the handshake —
OTOH it might occur later on renegotiation), but AFAICT it's orthogonal
to whether the patch is applied or not: we use blocking I/O, so
SSL_MODE_AUTO_RETRY is set just like before (`Net::SSLeay::set_mode($ssl,
$mode_auto_retry)` is called just before clearing O_NONBLOCK).
If the (blocking) socket is marked for reading when select() returns,
then the application assumes that SSL_read() won't block, and setting
SSL_MODE_AUTO_RETRY breaks that assumption, as written in the OpenSSL
changelog. Instead of a blocking SSL_read() the application expects it
to return SSL_ERROR_WANT_READ. And proceeds with SSL_write() if the
socket is also ready for writing, like in the trace above.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry
Hello Alf, thanks for the fast response. You can query to which package a shared object belongs by: dpkg -S /usr/lib/x86_64-linux-gnu/libbellesip.so.0 That should show 'libbellesip0' I guess. So, if package libbellesip0-dbgsym gets installed, another retry should have all needed debug information to show for each line of the backtrace debug information. Kind regards, Bernhard
Bug#925359: dietlibc: built program on x32 terminates with 'smashed stack detected, program terminated.'
Hello Thorsten Glaser,
Am 24.03.19 um 14:25 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
>
>> I see that the syscall number gets modified to become 0x4062.
>>
>> But the syscall modifies 144 bytes, more than just the size of
>> variable ru1 of 88 bytes.
>>
>> This 144 bytes is the size I could observe within amd64 userland.
>
> The x32 syscalls often have struct mapping, so amd64 userland
> sizes have no bearing on it.
That was just to demonstrate what the size would be if
the interface uses 64bit int.
Could there still be struct mapping behind the syscall instruction?
Wouldn't that then already be on kernel side?
>> Found also this bug at bugzilla.kernel.org [1].
>
> That’s from 2013. But given that it works with the other C libraries
> I’ll see whether I can fix it myself, unless Christian beats me to it.
As this was opened by "H.J. Lu", who was implementing
linux x32 [1][2], I think this sentence from the bug
report could still be relevant:
...
X32 uses the same system call interface as x86-64
for them. Some of those field should be long long
since they must be 64-bit integer in x32. But long
is 32-bit in x32.
Attached is also a file that wants to demonstrate a
getrusage call with a x32 glibc linked program.
There 144 bytes get modified by the syscall instruction.
Kind regards,
Bernhard
[1] https://lkml.org/lkml/2011/8/26/415
[2] https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1
# Unstable amd64-kernel with x32-userland qemu VM 2019-04-09
apt update
apt dist-upgrade
apt install dpkg-dev devscripts build-essential gdb mc
mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd
cat < test.c
/*
gcc -g -O0 test.c -o test
*/
#include
#include
#include
#include
int main()
{
struct rusage usage;
int r;
memset(&usage, 0xab, sizeof(usage));
r = getrusage(RUSAGE_SELF, &usage);
printf("r=%d sizeof(usage)=%d\n", r, sizeof(usage));
}
EOF
gcc -g -O0 test.c -o test
file test
ldd test
./test
benutzer@debian:~$ cat < test.c
> /*
> gcc -g -O0 test.c -o test
> */
>
> #include
> #include
> #include
> #include
>
> int main()
> {
> struct rusage usage;
> int r;
> memset(&usage, 0xab, sizeof(usage));
> r = getrusage(RUSAGE_SELF, &usage);
> printf("r=%d sizeof(usage)=%d\n", r, sizeof(usage));
> }
> EOF
benutzer@debian:~$
benutzer@debian:~$ gcc -g -O0 test.c -o test
benutzer@debian:~$ file test
test: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0,
BuildID[sha1]=fc9badaccaf302b5c1707a8a3c02d4949a4934dd, with debug_info, not
stripped
benutzer@debian:~$ ldd test
linux-vdso.so.1 (0xff9b)
libc.so.6 => /lib/x86_64-linux-gnux32/libc.so.6 (0xf7d7)
/libx32/ld-linux-x32.so.2 (0xf7f29000)
benutzer@debian:~$ ./test
r=0 sizeof(usage)=144
gdb -q --args ./test
set width 0
set pagination off
directory /home/benutzer/source/libc6/orig/glibc-2.28/sysdeps
b getrusage
run
bt
display/i $pc
stepi
up
print sizeof(usage)
print &usage
x/160xb (char*)$2 - 8
stepi
x/160xb (char*)$2 - 8
detach
q
##
benutzer@debian:~$ gdb -q --args ./test
Reading symbols from ./test...done.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/libc6/orig/glibc-2.28/sysdeps
Source directories searched:
/home/benutzer/source/libc6/orig/glibc-2.28/sysdeps:$cdir:$cwd
(gdb) b getrusage
Breakpoint 1 at 0x401030
(gdb) run
Starting program: /home/benutzer/test
Breakpoint 1, getrusage () at ../sysdeps/unix/syscall-template.S:78
78 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt
#0 getrusage () at ../sysdeps/unix/syscall-template.S:78
#1 0x0040117a in main () at test.c:15
(gdb) display/i $pc
1: x/i $pc
=> 0xf7efc190 : mov$0x4062,%eax
(gdb) stepi
0xf7efc195 78 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
1: x/i $pc
=> 0xf7efc195 :syscall
(gdb) up
#1 0x0040117a in main () at test.c:15
15 r = getrusage(RUSAGE_SELF, &usage);
(gdb) print sizeof(usage)
$1 = 144
(gdb) print &usage
$2 = (struct rusage *) 0xd5a0
(gdb) x/160xb (char*)$2 - 8
0xd598: 0x7a0x110x400x000x000x000x000x00
0xd5a0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5a8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5b0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5b8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5c0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5c8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5d0: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5d8: 0xab0xab0xab0xab0xab0xab0xab0xab
0xd5e0: 0xab
Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry
Am 09.04.19 um 21:51 schrieb Bernhard Übelacker: ... And here with the 3 debug packages for linphone installed, Alf Script started on 2019-04-09 23:13:10+02:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="119" LINES="28"] Reading symbols from linphonec...Reading symbols from /usr/lib/debug/.build-id/a6/e413996c0caf2689202302196ba19a26ce481f.debug...done. done. Starting program: /usr/bin/linphonec -d 5 -l linphone-debug [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe81ea700 (LWP 3303)] Ready Warning: video is disabled in linphonec, use -V or -C or -D to enable. [New Thread 0x7fffe79e9700 (LWP 3305)] linphonec> Refreshing on sip:061234567...@tel.t-online.de... linphonec> Registration on sip:tel.t-online.de failed: Unauthorized 11030230348 linphonec> Password for 061234567818 on tel.t-online.de: [top secret] Refreshing on sip:061234567...@tel.t-online.de... linphonec> Thread 1 "linphonec" received signal SIGSEGV, Segmentation fault. __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 31 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: Datei oder Verzeichnis nicht gefunden. #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 #1 0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #2 0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #3 0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #4 0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #5 0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #6 0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #7 0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #8 0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #9 0x555b1cc2 in sal_iterate (sal=) at ./coreapi/bellesip_sal/sal_impl.c:838 #10 0x555eabc6 in linphone_core_iterate (lc=0x55693480) at ./coreapi/linphonecore.c:3194 #11 0x555a83db in linphonec_idle_call () at ./console/linphonec.c:1023 #12 0x555a858d in linphonec_readline (prompt=) at ./console/linphonec.c:543 #13 0x555a6dd8 in linphonec_main_loop (opm=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:64 #14 main (argc=, argv=) at ./console/linphonec.c:652 #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 No locals. #1 0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #2 0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #3 0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #4 0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #5 0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #6 0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #7 0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #8 0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #9 0x555b1cc2 in sal_iterate (sal=) at ./coreapi/bellesip_sal/sal_impl.c:838 No locals. #10 0x555eabc6 in linphone_core_iterate (lc=0x55693480) at ./coreapi/linphonecore.c:3194 calls = call = curtime_ms = elapsed = current_real_time = 1554844401 diff_time = one_second_elapsed = 0 '\000' remote_provisioning_uri = #11 0x555a83db in linphonec_idle_call () at ./console/linphonec.c:1023 opm = 0x55693480 #12 0x555a858d in linphonec_readline (prompt=) at ./console/linphonec.c:543 prompt_reader_started = 1 '\001' pipe_reader_started = 0 '\000' #13 0x555a6dd8 in linphonec_main_loop (opm=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:64 input = input = iptr = input_len = #14 main (argc=, argv=) at ./console/linphonec.c:652 No locals. Detaching from program: /usr/bin/linphonec, process 3299 [Inferior 1 (process 3299) detached] Script done on 2019-04-09 23:13:21+02:00 [COMMAND_EXIT_CODE="0"]
Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable
Hi, during the BSP in Gothenburg last weekend I discussed with Jonas how I could help to put libsass back on track regarding its security status. We agreed that the best move is to start with triaging the existing Debian bugs and by identifying the CVE status in upstream's issue tracker. [0] Unfortunately upstream does not actively track CVE numbers. After Anthony Fok asked them about it in mid 2018 [1], they replied that CVE numbers are only tracked if bug reporters add the CVE numbers themselves, which several bug reporters have started to do since then. As a result, CVE tracking on upstream's issue tracker seems to have improved since mid 2018, but there is no guarantee that this will persist, so manual vigilance is still required. ;) Also, for older CVEs this info does not seem to be available in upstream's issue tracker, and occasionally bug status information can fall through the cracks during merges, see e.g., #2814 (CVE-2019-6283), #2815 (CVE-2019-6286) and #2816 (CVE-2019-6284): the git log in the master branch only specifies that #2814 was fixed, but pull request #2857 specifies that the same commit also fixed #2815 and #2816. [2] I started by cross-referencing the CVEs (which are explicitly mentioned in upstream's issue tracker) with upstream fixes: |++-| | CVE| Upstream bug # | Fixed in upsteam commit | |++-| | CVE-2019-6284 | #2816 | 8e681e2 | | CVE-2019-6286 | #2815 | 8e681e2 | | CVE-2019-6283 | #2814 | 8e681e2 | | CVE-2018-19827 | #2782 | b21fb9f | | CVE-2018-19797 | #2779 | e94b5f9 | | CVE-2018-11499 | #2643 | 930857c | As mentioned, this only covers recent CVEs, and there is still a lot of manual triaging needed. Several of the older CVEs seem to have been fixed "silently" (without explicitly referring to the CVEs), but that remains to be confirmed. I will try to cross-reference all known CVEs with upstream issues on github, so we can track if upstream fixed them already and when. This is obviously only the first step, but with that information we can try to identify which CVEs are still relevant for Debian, and which fixes need to be backported. Over time, we should be able to get this package back in shape. :) Kind regards, Aljoscha [0] https://github.com/sass/libsass/issues?q=is%3Aissue+cve+is%3Aclosed [1] https://github.com/sass/libsass/issues/2682 [2] https://github.com/sass/libsass/pull/2857
Bug#891294: plasma-discover: Discover->settings->software sources does nothing (seems a bug in kdesu, #913741)
Hello I've reproduced the same issue with KDE partition manager and it seems that the problem is in kdesu (a bug was reported already): #913741 libkdesu5: when kdesu is invoked by kde partition manager, after entering the password the window freezes I've added a block. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry
Am 09.04.19 um 21:51 schrieb Bernhard Übelacker: > Hello Alf, > maybe we can get more context of this crash > by doing one of the following: > > - Install gdb and run linphone like this: > > script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' > -ex 'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l > linphone-debug" -a gdb_linphone_$(date +%Y-%m-%d_%H-%M-%S).log > > The created file might contain a backtrace, that > could help here. > > - Install a core dump collector like > > - systemd-coredump: should output a backtrace > without debug symbol information right into > the journal. > > Alternatively one could list the crashes happend > since this boot by: > >coredumpctl list > > And attach get a backtrace from gdb from this by: > >coredumpctl gdb > bt > bt full > quit > > - corekeeper: should also collect core dumps which > could be inspected by: > > gdb -q $(which linphonec) --core /var/crash/user/coredump >bt >bt full >quit > > All the ways might be improved by installing > the debug information packages described in [1], > e.g. linphone-nogtk-dbgsym. > Adding these packages for the shared libraries, > shown in the backtrace, helps further. > > Kind regards, > Bernhard > > [1] > https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols > Hi Bernhard, I performed the first proposal and got some 4kb of output. I did not find any debug symbols for linphone yet in the standard repositories, so there ar some complaints. I did alter the phone number (2 places) and of course substituted my paaswrd. I do attach the output here, please advise whether I should try your other proposals and/or install required debug symbols. Kind regards, Alf Script started on 2019-04-09 22:35:58+02:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="184" LINES="20"] Reading symbols from linphonec...(no debugging symbols found)...done. Starting program: /usr/bin/linphonec -d 5 -l linphone-debug [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe81ea700 (LWP 2000)] Ready Warning: video is disabled in linphonec, use -V or -C or -D to enable. [New Thread 0x7fffe79e9700 (LWP 2001)] linphonec> Refreshing on sip:061234567...@tel.t-online.de... linphonec> Registration on sip:tel.t-online.de failed: Unauthorized 11030230348 linphonec> Password for 061234567818 on tel.t-online.de: [top secret] Refreshing on sip:061234567...@tel.t-online.de... linphonec> Thread 1 "linphonec" received signal SIGSEGV, Segmentation fault. __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 31 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: Datei oder Verzeichnis nicht gefunden. #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 #1 0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #2 0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #3 0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #4 0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #5 0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #6 0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #7 0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #8 0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 #9 0x555b1cc2 in sal_iterate () #10 0x555eabc6 in linphone_core_iterate () #11 0x555a83db in ?? () #12 0x555a858d in linphonec_readline () #13 0x555a6dd8 in main () #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 No locals. #1 0x77a52782 in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #2 0x77a528aa in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #3 0x77a53da7 in belle_sip_provider_dispatch_message () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #4 0x77a34b9d in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #5 0x77a36a57 in belle_sip_channel_process_data () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #6 0x77a5c0de in ?? () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #7 0x77a2a860 in belle_sip_main_loop_run () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symbol table info available. #8 0x77a2ab6c in belle_sip_main_loop_sleep () from /usr/lib/x86_64-linux-gnu/libbellesip.so.0 No symb
Bug#926628: tdbcmysql: hard-coded (build-)dependency on libmariadbclient18
On Mon, 8 Apr 2019 09:53:16 +0200 Ivo De Decker wrote: > tdbcmysql has a hard-coded (build-)dependency on "libmariadbclient18 | > libmysqlclient18 | libmysqlclient20". This is clearly wrong. > > This now blocks the migration of mariadb-10.3 to testing, because > libmariadbclient18 is no longer built. This will require more than just updating the dependencies, since it now has to dlopen libmariadb.so.3 Andreas
Bug#922368: bleachbit: New upstream release (2.2)
Package: bleachbit
Version: 2.0-3
Followup-For: Bug #922368
There is a new upstream version released. Even if due to the freeze, if it
could be uploaded to experimental, that would be awesome.
Thanks,
Rogério Brito.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bleachbit depends on:
ii policykit-10.105-25
ii python 2.7.16-1
ii python-gtk22.24.0-5.1+b1
ii python-simplejson 3.16.0-1
Versions of packages bleachbit recommends:
ii python-notify 0.1.1-4
bleachbit suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#926740: bugs.debian.org: Subscription confirmation reply-to address length exceeds RFC-5321 limit
Package: bugs.debian.org Severity: important Dear Maintainer, I subscribed to a bug (924787) and received a confirmation email asking me to confirm the subscription by emailing to 924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org My smpt server (mailfence) rejects an email to this address with a message: --- The recipient address <924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org> is not a valid RFC-5321 address.. --- As a result I am unable to confirm subscription. RFC-5321 states: --- 4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets. --- 924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f36964b1 is 79 characters. -- Nazar
Bug#926701: texlive-bin: FTBFS on hurd-i386
On 09.04.19 12:57, Norbert Preining wrote: > On Tue, 09 Apr 2019, Hilmar Preuße wrote: >> I suspect that an explicit link to lib dl (-ldl) is missing in the >> linker statement. > > Strange, and why didn't that show up back then. Thanks for reporting, > but I have not too much ideas how to fix it ;-) > The -ldl is missing in unstable too, so my first analysis is wrong. I'll have a look at this later on. We have different linker flags in unstable anyway. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#919929: python-scipy: autopkgtest fails intermittently
Hi Drew, On Mon, 08 Apr 2019 17:52:02 +0800 Drew Parsons wrote: > CI testing isn't performed in buster, is it? If it's important to get > a clean buster CI test then those 2 tests could be switched off in > python2 if desired. Obviously we do *want* to use autopkgtest post release in buster as well, i.e. for security updates and/or stable release updates. That is why we have been unblocking autopkgtest only fixes during this freeze. The infrastructure isn't fully implemented yet, but there are no blockers to do that when the time comes. So yes fixing this for buster is desirable if not too much effort. Paul signature.asc Description: OpenPGP digital signature
Bug#926720: [Pkg-javascript-devel] Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)
On Tue, Apr 09, 2019 at 09:31:07PM +0200, Xavier wrote: > > NB, it's been already reported upstream that the number of iterations > > this implementation chooses in not adequate: > > https://github.com/indutny/miller-rabin/issues/9 > > I think we could keep this patch for now to avoid FTBFS and reopened > this bug with a lower severity (normal) to wait for upstream patch, do > you agree ? I would keep the current bug unchanged (at least until the current package propagates to testing) and file another (different) bug saying "please fix the code and enable the test suite" (i.e. what Jakub asked). Thanks.
Bug#926720: [Pkg-javascript-devel] Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)
Le 09/04/2019 à 21:16, Jakub Wilk a écrit : > * Santiago Vila , 2019-04-09, 15:32: >> AFAIK, this being a primality test, I assume the outcome is either >> "not prime" or "maybe prime", so the only way to test the test is by >> giving a known prime and expect "maybe prime" as output. >> >> So: Why is the test calling mr.test with 221, which is not prime? (221 >> = 13 x 17) > > Correctly implemented Miller-Rabin test should have false positives only > with negligible probability. > >> And why this fails randomly? Does the test perform random calculations >> internally and it's therefore not deterministic? > > Yes. > >> Even in such case I don't see how a non-prime like 221 may help to >> catch obvious errors in a test suite for a primality test. > > It's just proven to be useful. > > Please restore the test and fix the code instead. > > NB, it's been already reported upstream that the number of iterations > this implementation chooses in not adequate: > https://github.com/indutny/miller-rabin/issues/9 I think we could keep this patch for now to avoid FTBFS and reopened this bug with a lower severity (normal) to wait for upstream patch, do you agree ?
Bug#926658: gnuplot: free(): double free detected in tcache 2
Hello, thank you all for participating. I will upload a package with the fix into experimental soon. Regards Anton Am Di., 9. Apr. 2019 um 20:27 Uhr schrieb Bernhard Übelacker < bernha...@mailbox.org>: > Control: tags 926658 + patch upstream fixed-upstream > > > Dear Maintainer, > I just tried to help triage this issue. > > I think this is related to upstream bug [1] and > was already fixed in the 5.2 branch by commit [2]. > > A package built with this patch does just show the > 'undefined variable' error, but not the double free fault. > > Kind regards, > Bernhard > > [1] https://sourceforge.net/p/gnuplot/bugs/2115/ > [2] > https://sourceforge.net/p/gnuplot/gnuplot-main/ci/732014eefd41235a143626d2bc02d3d34934e1b3/ > -- > debian-science-maintainers mailing list > debian-science-maintain...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#926739: stretch-pu: package gpac/0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Fixes a number of minor issues, same patches are also in unstable for a week.
Cheers,
Moritz
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 2016-08-04
23:29:39.0 +0200
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 2019-03-04
23:37:26.0 +0100
@@ -1,3 +1,12 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1) stretch; urgency=medium
+
+ * CVE-2018-7752 (Closes: #892526)
+ * CVE-2018-13005, CVE-2018-13006 (Closes: #902782)
+ * CVE-2018-20760, CVE-2018-20761, CVE-2018-20762, CVE-2018-20763
+(Closes: #921969)
+
+ -- Moritz Mühlenhoff Mon, 04 Mar 2019 23:37:26 +0100
+
gpac (0.5.2-426-gc5ad4e4+dfsg5-3) unstable; urgency=medium
* Team upload.
diff -Nru
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
---
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
1970-01-01 01:00:00.0 +0100
+++
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-13005_CVE-2018-13006.patch
2019-03-04 23:13:09.0 +0100
@@ -0,0 +1,38 @@
+From bceb03fd2be95097a7b409ea59914f332fb6bc86 Mon Sep 17 00:00:00 2001
+From: Aurelien David
+Date: Thu, 28 Jun 2018 13:34:08 +0200
+Subject: [PATCH] fixed 2 possible heap overflows (inc. #1088)
+
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/include/gpac/internal/isomedia_dev.h
gpac-0.5.2-426-gc5ad4e4+dfsg5/include/gpac/internal/isomedia_dev.h
+@@ -2988,7 +2988,7 @@ GF_GenericSubtitleSample *gf_isom_parse_
+ char __ptype[5];\
+ strcpy(__ptype, gf_4cc_to_str(__parent->type) );\
+ GF_LOG(GF_LOG_WARNING, GF_LOG_CONTAINER, ("[iso file] extra box
%s found in %s, deleting\n", gf_4cc_to_str(__abox->type), __ptype)); \
+- gf_isom_box_del(a);\
++ gf_isom_box_del(__abox);\
+ return GF_OK;\
+ }
+
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/isomedia/box_code_base.c
gpac-0.5.2-426-gc5ad4e4+dfsg5/src/isomedia/box_code_base.c
+@@ -619,7 +619,7 @@ GF_Err urn_Read(GF_Box *s, GF_BitStream
+
+ //then get the break
+ i = 0;
+- while ( (tmpName[i] != 0) && (i < to_read) ) {
++ while ( (i < to_read) && (tmpName[i] != 0) ) {
+ i++;
+ }
+ //check the data is consistent
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/isomedia/box_dump.c
gpac-0.5.2-426-gc5ad4e4+dfsg5/src/isomedia/box_dump.c
+@@ -988,7 +988,7 @@ GF_Err dpin_dump(GF_Box *a, FILE * trace
+ GF_Err hdlr_dump(GF_Box *a, FILE * trace)
+ {
+ GF_HandlerBox *p = (GF_HandlerBox *)a;
+- if (p->nameUTF8 && (u32) p->nameUTF8[0] == strlen(p->nameUTF8+1)) {
++ if (p->nameUTF8 && (u32) p->nameUTF8[0] == strlen(p->nameUTF8)-1) {
+ fprintf(trace, "handlerType), p->nameUTF8+1);
+ } else {
+ fprintf(trace, "handlerType), p->nameUTF8);
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch
1970-01-01 01:00:00.0 +0100
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20760.patch
2019-03-04 23:13:47.0 +0100
@@ -0,0 +1,16 @@
+From 4c1360818fc8948e9307059fba4dc47ba8ad255d Mon Sep 17 00:00:00 2001
+From: Aurelien David
+Date: Thu, 13 Dec 2018 14:39:21 +0100
+Subject: [PATCH] check error code on call to gf_utf8_wcstombs (#1177)
+
+--- gpac-0.5.2-426-gc5ad4e4+dfsg5.orig/src/media_tools/text_import.c
gpac-0.5.2-426-gc5ad4e4+dfsg5/src/media_tools/text_import.c
+@@ -259,6 +259,8 @@ char *gf_text_get_utf8_line(char *szLine
+ }
+ sptr = (u16 *)szLine;
+ i = (u32) gf_utf8_wcstombs(szLineConv, 1024, (const unsigned short **)
&sptr);
++ if (i >= (u32)ARRAY_LENGTH(szLineConv))
++ return NULL;
+ szLineConv[i] = 0;
+ strcpy(szLine, szLineConv);
+ /*this is ugly indeed: since input is UTF16-LE, there are many chances
the fgets never reads the \0 after a \n*/
diff -Nru
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
---
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
1970-01-01 01:00:00.0 +0100
+++
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2018-20761_CVE-2018-20762.patch
2019-03-04 23:14:31.0 +0100
@@ -0,0 +1,147 @@
+From 35ab4475a7df9b2a4bcab235e379c0c3ec543658 Mon Sep 17 00:00:00 2001
+From: Aurelien David
+Date: Fri, 11 Jan 2019 11:32:54 +0100
+Subject: [PATCH] fix some overflows due to strcpy
+
+fixes #1184, #1186, #1187 among other things
+
+---
Bug#921266: linphone: Segfault and crash with "error 4 in libc-2.28.so" on password entry
Hello Alf, maybe we can get more context of this crash by doing one of the following: - Install gdb and run linphone like this: script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l linphone-debug" -a gdb_linphone_$(date +%Y-%m-%d_%H-%M-%S).log The created file might contain a backtrace, that could help here. - Install a core dump collector like - systemd-coredump: should output a backtrace without debug symbol information right into the journal. Alternatively one could list the crashes happend since this boot by: coredumpctl list And attach get a backtrace from gdb from this by: coredumpctl gdb bt bt full quit - corekeeper: should also collect core dumps which could be inspected by: gdb -q $(which linphonec) --core /var/crash/user/coredump bt bt full quit All the ways might be improved by installing the debug information packages described in [1], e.g. linphone-nogtk-dbgsym. Adding these packages for the shared libraries, shown in the backtrace, helps further. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Bug#922754: closing 922754
On Thu, 04 Apr 2019 14:24:40 +0100 Sam Morris wrote: > # turns out this was a local problem For the archives: Could you please describe the local problem and the solution? Because I am having exactly the same problem with plymouth here. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#926738: git-send-email: transferencoding config ignored
Package: git-email
Version: 1:2.20.1-2
Severity: normal
The value of the sendmail.transferencoding configuration item is ignored.
A patch has been submitted as
https://marc.info/?l=git&m=155483810827726&w=2
The patch is also appended.
Best regards
Heinrich Schuchardt
From f3afc36a7c624f300739ab43fd56b9e4850db6a5 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt
Date: Tue, 9 Apr 2019 21:03:43 +0200
Subject: [PATCH 1/1] send-email: fix transferencoding config option
Since e67a228cd8a ("send-email: automatically determine transfer-encoding")
the value of sendmail.transferencoding is ignored because when parsing
the configuration $target_xfer_encoding is not initial anymore.
Instead of initializing variable $target_xfer_encoding on definition we
have to set it to the default value of 'auto' if is initial after parsing
the configuration files.
The documentation erroneously mentions the option as
sendmail.transferEncoding. Fix that typo.
Fixes: e67a228cd8a ("send-email: automatically determine transfer-encoding")
Signed-off-by: Heinrich Schuchardt
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 1afe9fc858..884e776add 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -146,7 +146,7 @@ Note that no attempts whatsoever are made to validate the encoding.
even more opaque. auto will use 8bit when possible, and quoted-printable
otherwise.
+
-Default is the value of the `sendemail.transferEncoding` configuration
+Default is the value of the `sendemail.transferencoding` configuration
value; if that is unspecified, default to `auto`.
--xmailer::
diff --git a/git-send-email.perl b/git-send-email.perl
index 8200d58cdc..0e23193939 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -239,7 +239,7 @@ sub do_edit {
my (@suppress_cc);
my ($auto_8bit_encoding);
my ($compose_encoding);
-my $target_xfer_encoding = 'auto';
+my ($target_xfer_encoding);
my ($debug_net_smtp) = 0; # Net::SMTP, see send_message()
@@ -446,6 +446,8 @@ sub read_config {
$smtp_encryption = 'ssl';
}
}
+
+ $target_xfer_encoding = 'auto' unless (defined $target_xfer_encoding);
}
# read configuration from [sendemail "$identity"], fall back on [sendemail]
--
2.20.1
Bug#926737: Possible memory leak after upgrading from 16.1.1 to 16.2.1
Source: asterisk Version: 1:16.2.1~dfsg-1 Severity: serious Hi, I intend to look at this myself, but I'm short on time right now. Filing this bug so I don't forget (and maybe someone else can look at it). After having upgraded one of my test systems from 16.1.1 to 16.2.1 shows the Asterisk process being constantly growing until the machine finally runs out of memory. 2019-04-04 16:55:33 upgrade asterisk:amd64 1:16.1.1~dfsg-1 1:16.2.1~dfsg-1 This was a dist-upgrade in a sid container, so it might be something else triggering it, but it is definitely the Asterisk process leaking memory. asterisk 10485 0.3 26.8 964940 271656 ? Ssl Apr08 5:23 /usr/sbin/asterisk -g -f -p -U asterisk Directly after a fresh restart asterisk 11171 15.8 8.0 759704 80928 ?Ssl 19:45 0:03 /usr/sbin/asterisk -g -f -p -U asterisk I'll do some more tests and will followup on this bug. Bernhard
Bug#926736: yad: Window icon is not displayed under Wayland
Package: yad Version: 0.40.0-1 Severity: minor Dear Maintainer, Window icon is not found when using Wayland (wether you choose one with --window-icon or not) but works perfectly under Xorg. Fortunately upgrading to the last version would solve this, but I could not find anything related in the changelog nor in the upstream issues. Do not hesitate to ask if you want me to report this upstream. Regards, Yvan -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yad depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-8 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 yad recommends no packages. yad suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail
Hi, On 04/09/2019 09:19 PM, Moritz Muehlenhoff wrote: The tracker for CVE-2017-17689 doesn't list anything related to kdepim or src:meta-kde for buster. Is the issue fixed in the binary kdepim (produced by src:meta-kde) in buster? If so, that should probably be stated explicitly in the tracker. For buster the affected code is in src:kf5-messagelib and fixed in 4:18.08.1-1 In stretch the affected code is in src:kdepim In Buster the binary package kdepim is now built out of src:meta-kde, but that was never affected. That's we don't track src:meta-kde at all in https://security-tracker.debian.org/tracker/CVE-2017-17689 Does that clarify? Yes. I (incorrectly) assumed that the offending code had been in meta-kde in buster at some point. As that's not the case, there is nothing left to fix for buster. Thanks for the clarification. Ivo
Bug#906589: inkscape: "Import Clip Art" is not working
Mattia Rizzolo writes: > Control: tag -1 moreinfo unreproducible > > On Tue, Sep 18, 2018 at 11:59:28AM +0200, Mattia Rizzolo wrote: >> On Sat, Aug 18, 2018 at 03:37:42PM +0200, Göran Weinholt wrote: >> > The "Import Clip Art" function in the File menu is not working. The >> > dialog shows an error: "Could not connect to the Open Clip Art >> > Library". The terminal logs an error: >> > >> > ** (inkscape:12723): WARNING **: 15:35:06.393: >> > ImportDialog::on_xml_file_read(): >> >Failed to retrieve 'http://openclipart.org/media/feed/rss/some string' >> >Operation not supported >> >> Forwarded, see above. > > I just tried again, and I couldn't reproduce this error anymore. Like > upstream, I'm blaming something on gtkmm or glib, although I'm not sure > on what. > > Could you please try again? I tried again and it still didn't work. I traced it through glibmm to glib and saw /usr/lib/x86_64-linux-gnu/gio/modules in strace. I looked at what files go there with apt-file and found gvfs. Installing gvfs almost fixed it; gvfs-backends was also needed. Now I can search for clipart. So maybe add Recommends: gvfs-backends? It added another 15MB to the disk usage for me. Regards, -- Göran Weinholt https://weinholt.se/
Bug#926720: node-miller-rabin: FTBFS randomly (uses a non-prime to test the test)
* Santiago Vila , 2019-04-09, 15:32: AFAIK, this being a primality test, I assume the outcome is either "not prime" or "maybe prime", so the only way to test the test is by giving a known prime and expect "maybe prime" as output. So: Why is the test calling mr.test with 221, which is not prime? (221 = 13 x 17) Correctly implemented Miller-Rabin test should have false positives only with negligible probability. And why this fails randomly? Does the test perform random calculations internally and it's therefore not deterministic? Yes. Even in such case I don't see how a non-prime like 221 may help to catch obvious errors in a test suite for a primality test. It's just proven to be useful. Please restore the test and fix the code instead. NB, it's been already reported upstream that the number of iterations this implementation chooses in not adequate: https://github.com/indutny/miller-rabin/issues/9 -- Jakub Wilk
Bug#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail
On Tue, Apr 09, 2019 at 06:49:16PM +0200, Ivo De Decker wrote: > Hi Salvatore, > > On 4/8/19 10:59 PM, Salvatore Bonaccorso wrote: > > Control: reassign -1 src:kdepim > > On Mon, Apr 08, 2019 at 11:36:10AM +0200, Ivo De Decker wrote: > > > Hi, > > > > > > On Sat, May 19, 2018 at 07:18:06PM +0200, Sandro Knauß wrote: > > > > I now created a debdiff for kdepim. The patch depdends on the new > > > > symbol that > > > > was added in new messageviewer (see #899127). > > > > > > Does this bug still affect buster/sid? From the bug log and the tracker > > > for > > > CVE-2017-17689, it look like kmail in buster/sid is not affected, but it > > > would > > > be good if someone could confirm that. > > > > I think the tracking problem was hiere that #899128 is associated with > > src:meta-kde, but it should be src:kdepim (#899128) and respectively > > kf5-messagelib was #899127. The issue was fixed in the kf5-messagelib > > in version 4:18.08.1-1. In stretch src:kdepim was a source package, > > whilst in buster kdepim is a binary package produced by kde-meta, but > > the issue lies there in src:kf5-messagelib. > > The tracker for CVE-2017-17689 doesn't list anything related to kdepim or > src:meta-kde for buster. Is the issue fixed in the binary kdepim (produced > by src:meta-kde) in buster? If so, that should probably be stated explicitly > in the tracker. For buster the affected code is in src:kf5-messagelib and fixed in 4:18.08.1-1 In stretch the affected code is in src:kdepim In Buster the binary package kdepim is now built out of src:meta-kde, but that was never affected. That's we don't track src:meta-kde at all in https://security-tracker.debian.org/tracker/CVE-2017-17689 Does that clarify? Cheers, Moritz
Bug#906589: inkscape: "Import Clip Art" is not working
Control: forcemerge 926113 -1 On Tue, Apr 09, 2019 at 08:42:40PM +0200, Göran Weinholt wrote: > I tried again and it still didn't work. I traced it through glibmm to > glib and saw /usr/lib/x86_64-linux-gnu/gio/modules in strace. I looked > at what files go there with apt-file and found gvfs. Installing gvfs > almost fixed it; gvfs-backends was also needed. Now I can search for > clipart. mhpf. > So maybe add Recommends: gvfs-backends? It added another 15MB to the > disk usage for me. this is annoying, and I should have noticed the similarity in the message with #926113 ... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed
On Monday, April 08, 2019 04:50:31 PM ana wrote: > Thanks for the update on this. It would be a shame to drop the package > entirely from Debian. Have had a look at the packaging on salsa and I'm > happy to take over. I would need DM permissions on it to make uploads. OK. Please add yourself to uploaders on salsa and close the rm bug (you can close this one too). I'll want to sponsor at least one upload before I give DM permissions. When you have something that needs uploading, feel free to ping me. Also, you may want to take an interest in prompt-toolkit. It's one of python- softlayer's major dependencies. It has one other DM uploader (I've dropped myself from that one too), but it's worth keeping an eye on to make sure it and python-softlayer stay compatible. Scott K
Bug#926735: Include upstream patch for extended partition size
Package: libparted2 Version: 3.2-24 src:parted Please include upstream commit c6dc6e5d from 2015 as additional package patch because it fixes the unit of the partition resize ioctl. http://git.savannah.gnu.org/cgit/parted.git/commit/?id=c6dc6e5d0f49a26242d2b28622514814a53d92e1 Currently the extended partitions will be inaccessible until some program forces the kernel to reread the partition table. See related issues: https://github.com/storaged-project/udisks/issues/425 https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1641308
Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed
Control: severity -1 important Hi Ana, On Mon, Apr 08, 2019 at 04:50:31PM +0100, ana wrote: > Thanks for the update on this. It would be a shame to drop the package > entirely from Debian. Have had a look at the packaging on salsa and I'm > happy to take over. I would need DM permissions on it to make uploads. In that case, I'm lowering the severity to get it of the RC bug list. I'll leave it up to you to close it (and close #926209 as well). Ivo
Bug#926734: unblock: libcaca/0.99.beta19-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libcaca
The new packages fixes 6 CVE's. (Bug #917807)
Thanks!
unblock libcaca/0.99.beta19-2.1
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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
diff -Nru libcaca-0.99.beta19/debian/changelog
libcaca-0.99.beta19/debian/changelog
--- libcaca-0.99.beta19/debian/changelog2014-06-02 22:39:11.0
+0200
+++ libcaca-0.99.beta19/debian/changelog2019-04-06 22:18:41.0
+0200
@@ -1,3 +1,12 @@
+libcaca (0.99.beta19-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Cherry-Pick fixes from upstream git repository:
+- CVE-2018-20545, CVE-2018-20546, CVE-2018-20547,CVE-2018-20548 and
+ CVE-2018-20549 (Closes: #917807)
+
+ -- Tobias Frost Sat, 06 Apr 2019 22:18:41 +0200
+
libcaca (0.99.beta19-2) unstable; urgency=medium
* debian/patches/100_doxygen.diff: remove deprecated Doxygen variables.
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch
libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch 1970-01-01
01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch 2019-04-06
21:36:52.0 +0200
@@ -0,0 +1,45 @@
+From 84bd155087b93ab2d8d7cb5b1ac94ecd4cf4f93c Mon Sep 17 00:00:00 2001
+From: Sam Hocevar
+Date: Sat, 29 Dec 2018 22:13:56 +0100
+Subject: [PATCH] dither: fix integer overflows that were causing a division by
+ zero.
+
+Fixes: #36 (CVE-2018-20544)
+---
+ caca/dither.c | 16
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/caca/dither.c b/caca/dither.c
+index 04b678e0..c6ebab1b 100644
+--- a/caca/dither.c
b/caca/dither.c
+@@ -991,10 +991,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int y,
int w, int h,
+ /* First get RGB */
+ if(d->antialias)
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+
+ /* We want at least one pixel */
+ if(tox == fromx) tox++;
+@@ -1017,10 +1017,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int
y, int w, int h,
+ }
+ else
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+
+ /* tox and toy can overflow the canvas, but they cannot overflow
+ * when averaged with fromx and fromy because these are guaranteed
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
1970-01-01 01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
2019-04-06 22:08:34.0 +0200
@@ -0,0 +1,34 @@
+Description: img2txt: fix an integer overflow in the BMP loader.
+Origin:
https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Forwarded: not-needed
+Applied-Upstream:
https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Last-Update: 2019-04-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/common-image.h
b/src/common-image.h
+@@ -1,19 +1,19 @@
+ /*
+ * Imaging tools for cacaview and img2irc
+- * Copyright (c) 2003-2012 Sam Hocevar
+- *All Rights Reserved
++ * Copyright (c) 2003-2018 Sam Hocevar
++ * All Rights Reserved
+ *
+ * This program is free software. It comes without any warranty, to
+ * the extent permitted by applicable law. You can redistribute it
+ * and/or modify it under the terms of the Do What the Fuck You Want
+- * to Public License, Version 2, as published by Sam Hocevar. See
+- * http://www.wtfpl.net/ for more details.
++ * to Public License, Version 2, as pub
Bug#926700: cacti: CVE-2019-11025
Control: found -1 0.8.8h+ds1-10 0.8.8b+dfsg-8+deb8u6 Hi Salvatore, On 09-04-2019 12:28, Salvatore Bonaccorso wrote: > Please adjust the affected versions in the BTS as needed. Doing so now. Thanks for the report. Paul signature.asc Description: OpenPGP digital signature
Bug#926733: gimp-gmic does not load
Package: gimp-gmic Version: 2.4.5-1 Severity: important Dear Maintainer, The gimp-gmic Debian package does not run at all in my machine. I tested the gimp-gmic binary from gmic.eu download page and it works fine. Here some error messages I obtain trying runing gimp-gmic from debian package: [Detaching after vfork from child process 3401] (gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk- contained.css:5000:8: 'height' is not a valid property name (gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk- contained.css:5001:7: 'width' is not a valid property name (gmic_gimp:3401): Gtk-WARNING **: 20:07:50.099: Theme parsing error: gtk- contained.css:5090:26: The :insensitive pseudo-class is deprecated. Use :disabled instead. (gmic_gimp:3401): Gtk-WARNING **: 20:07:50.100: Theme parsing error: gtk- contained.css:5091:19: The :insensitive pseudo-class is deprecated. Use :disabled instead. (gmic_gimp:3401): GLib-GObject-WARNING **: 20:07:50.142: cannot register existing type 'GtkWidget' (gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (gmic_gimp:3401): GLib-GObject-WARNING **: 20:07:50.142: cannot register existing type 'GtkBuildable' (gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (gmic_gimp:3401): GLib-CRITICAL **: 20:07:50.142: g_once_init_leave: assertion 'result != 0' failed (gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (gmic_gimp:3401): GLib-GObject-CRITICAL **: 20:07:50.142: g_type_register_static: assertion 'parent_type > 0' failed [Thread 0x7fffcd9c2700 (LWP 3393) exited] Thanks a lot. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-20.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp-gmic depends on: ii gimp 2.10.8-2+aptbuild3 ii libatk1.0-0 2.30.0-2 ii libbabl-0.1-01:0.1.62-dmo1 ii libc62.28-7 ii libcairo21.16.0-2+aptbuild1 pn libcurl3 ii libfftw3-double3 3.3.8-2 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgegl-0.4-01:0.4.12-dmo1+aptbuild2 ii libgimp2.0 2.10.8-2+aptbuild3 ii libglib2.0-0 2.58.3-1 ii libgmic1 2.4.5-1 ii libgomp1 8.3.0-2 ii libgtk2.0-0 2.24.32-3 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libpng16-16 1.6.34-2 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-2 ii libx11-6 2:1.6.7-1 ii zlib1g 1:1.2.11.dfsg-1 gimp-gmic recommends no packages. Versions of packages gimp-gmic suggests: pn gmic
Bug#926658: gnuplot: free(): double free detected in tcache 2
Control: tags 926658 + patch upstream fixed-upstream Dear Maintainer, I just tried to help triage this issue. I think this is related to upstream bug [1] and was already fixed in the 5.2 branch by commit [2]. A package built with this patch does just show the 'undefined variable' error, but not the double free fault. Kind regards, Bernhard [1] https://sourceforge.net/p/gnuplot/bugs/2115/ [2] https://sourceforge.net/p/gnuplot/gnuplot-main/ci/732014eefd41235a143626d2bc02d3d34934e1b3/ # Buster amd64 real hardware 2019-04-09 apt update apt dist-upgrade # mkdir /home/benutzer/926658_gnuplot-crash -p cd/home/benutzer/926658_gnuplot-crash debootstrap --arch=amd64 buster chroot http://192.168.178.25:/debian-10-buster-deb.debian.org/ mount --rbind /proc chroot/proc cp -a ../rr*.deb chroot/ # workaround https://github.com/mozilla/rr/issues/2342 env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l root apt install locales dpkg-reconfigure locales nano /etc/inputrc adduser benutzer mv /etc/apt/sources.list /etc/apt/sources.list.d/buster-approx.list echo "deb-src http://192.168.178.25:/debian-10-buster-deb.debian.org buster main" >> /etc/apt/sources.list.d/buster-approx.list echo "deb http://192.168.178.25:/debian-10-buster-debug.mirrors.debian.org buster-debug main" >> /etc/apt/sources.list.d/buster-approx.list apt update apt install dpkg-dev devscripts mc wget unzip rr gdb gnuplot gnuplot-qt-dbgsym dpkg -i /*.deb # workaround https://github.com/mozilla/rr/issues/2342 echo 1 > /proc/sys/kernel/perf_event_paranoid env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l benutzer mkdir /home/benutzer/source/gnuplot/orig -p cd/home/benutzer/source/gnuplot/orig apt source gnuplot cd mkdir /home/benutzer/source/libc6/orig -p cd/home/benutzer/source/libc6/orig apt source libc6 cd wget "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=926658;filename=test-files.zip;msg=10"; -O test-files.zip unzip test-files.zip cd test-files rr record gnuplot call.gpi rr replay set width 0 set pagination off directory /home/benutzer/source/gnuplot/orig/gnuplot-5.2.6+dfsg1/src/wxterminal/bitmaps directory /home/benutzer/source/libc6/orig/glibc-2.28/malloc cont bt reverse-finish reverse-finish reverse-finish reverse-finish reverse-finish reverse-finish reverse-finish print a->v.string_val print &(a->v.string_val) b __GI___libc_free if mem==0x564e97351a60 watch *0x564e9734ed90 reverse-cont bt reverse-finish print a->v.string_val print &(a->v.string_val) reverse-cont bt # benutzer@willi-laptop:~$ gnuplot --version gnuplot 5.2 patchlevel 6 benutzer@willi-laptop:~/test-files$ rr record gnuplot call.gpi rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/gnuplot-0'. Plotting $tag statistics... "./tags.gpi" line 27: undefined variable: date_min free(): double free detected in tcache 2 Abgebrochen benutzer@willi-laptop:~/test-files$ rr replay ... Reading symbols from /usr/bin/gnuplot-qt...(no debugging symbols found)...done. Really redefine built-in command "restart"? (y or n) [answered Y; input not from terminal] Remote debugging using 127.0.0.1:16489 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/.build-id/75/5312dcb2382eb2fde78494879bb2104028ae80.debug...done. done. 0x7f088a6fd090 in _start () from /lib64/ld-linux-x86-64.so.2 (rr) set width 0 (rr) set pagination off (rr) cont Continuing. Plotting $tag statistics... "./tags.gpi" line 27: undefined variable: date_min free(): double free detected in tcache 2 Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f0d2535 in __GI_abort () at abort.c:79 #2 0x7f0888929778 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f0888a3428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x7f088892fe6a in malloc_printerr (str=str@entry=0x7f0888a35f58 "free(): double free detected in tcache 2") at malloc.c:5341 #4 0x7f088893194d in _int_free (av=0x7f0888a6bc40 , p=0x564e97351a50, have_lock=) at malloc.c:4193 #5 0x564e95fbb8bd in ?? () #6 0x564e95fbbd6b in ?? () #7 0x564e95fec887 in ?? () #8 0x564e95fece8d in ?? () #9 0x564e95f9b3bd in ?? () #10 0x7f0d409b in __libc_start_main (main=0x564e95f9b000, argc=2, argv=0x7ffe67c3fb68, init=, fini=, rtld_fini=, stack_end=0x7ffe67c3fb58) at ../csu/libc-start.c:308 #11 0x564e95f9c76a in ?? () # With debug symbols benutzer@willi-laptop:~$ rr replay GNU gdb (Debian 8.2.1-2) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GP
Bug#926732: djview4: problems with URLs
Package: djview4 Version: 4.11-1 Severity: important Dear maintainer, I will report the bug also upstream, but want to provide the details of my system. The problems actually seem to be caused by a library, as they were inherited by our December version of djview4poliqarp, although noticed only just now. The problems manifestation is that the page parameter doesn't seem to work, e.g. http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?&highlight=88,1555,470,126&page=1 http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?&highlight=88,1555,470,126&page=2 http://rcin.org.pl/Content/5994/KRIJP_20296_03030430_bdelion-bezksztalt.djvu?highlight=34,1529,361,137&page=3 display the same page. Trying to prepare more test data I noticed that "Copy URL" almost always don't work. I used to paste it with C-v, but now it yields nothing (the underlying text is however still copied and can be pasted with the middle mouse button). Once when it worked the URL was not correct as it contained redundant elements. I mark the bug as important as some of us plan to work intensively with the DjVu URLs soon. Best regards Janusz -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 djview4 depends on: ii libc62.28-8 ii libdjvulibre21 3.5.27.1-10 ii libgcc1 1:8.3.0-5 ii libgl1 1.1.0-1 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5opengl55.11.3+dfsg1-1 ii libqt5printsupport5 5.11.3+dfsg1-1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-5 ii libtiff5 4.0.10-4 ii sensible-utils 0.0.12 Versions of packages djview4 recommends: ii djvulibre-desktop 3.5.27.1-10 Versions of packages djview4 suggests: ii djview-plugin 4.11-1 ii djvulibre-bin 3.5.27.1-10 -- no debconf information -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Bug#926479: [Fwd: [Pkg-swan-devel] Bug#926479: Interesting ..]
Hi Christian, On 09-04-2019 08:37, Christian Ehrhardt wrote: > Odd for sure - at least for my local debian container tests it was a > 100% hit rate. > And in VMs it always worked (as does the Ubuntu CI that I linked) Ubuntu uses VM's, Debian uses lxc. The difference is exactly isolation-machine versus isolation-container. isolation-machine restricts more. > Furthermore there is a reason I never thought I'd need to add > isolation-machine which is that it works well for Ubuntu on armhf which > runs in LXD containers as well. I never learned what LXD really is (it isn't in Debian). >> But this change would be even acceptable for an unblock if it can happen >> soon (without any other changes). > > I wondered about that, but I see that it will make CI on the package > for the lifetime of buster more helpful. Indeed. > Overall that would then look like this: > diff --git a/debian/tests/control b/debian/tests/control > index eb9e20463c..5b1ebf32c8 100644 > --- a/debian/tests/control> +++ b/debian/tests/control > @@ -1,3 +1,7 @@ > -Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins > -Depends: strongswan, libstrongswan-standard-plugins, > libstrongswan-extra-plugins, libcharon-extra-plugins, strongswan-pki, > strongswan-scepclient > +Tests: admin-strongswan-charon admin-strongswan-starter > +Depends: strongswan, strongswan-pki, strongswan-scepclient > Restrictions: needs-root isolation-container allow-stderr > + > +Tests: daemon plugins > +Depends: strongswan-starter, libstrongswan-standard-plugins, > libstrongswan-extra-plugins, libcharon-extra-plugins > +Restrictions: needs-root isolation-machine allow-stderr Ack (for the restrictions, not the depends). Paul signature.asc Description: OpenPGP digital signature
Bug#926151: chromium: Youtube not working in latest testing version on recent intel hw
Package: chromium Version: 73.0.3683.75-1 Followup-For: Bug #926151 I can confirm the bug. Meanwhile you can install h264ify extension from chromium store to make youtube videos to work, but other sites may still not work. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 73.0.3683.75-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-5 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.1-1 ii libavformat587:4.1.1-1 ii libavutil56 7:4.1.1-1 ii libc62.28-8 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-5 ii libdbus-1-3 1.12.12-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-5 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.36-5 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-5 ii libva2 2.4.0-1 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 73.0.3683.75-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox 73.0.3683.75-1 ii dunst [notification-daemon] 1.3.2-1 ii fonts-liberation 1:1.07.4-9 ii gnome-shell [notification-daemon]3.30.2-3 ii libgl1-mesa-dri 18.3.4-2 ii libu2f-udev 1.1.9-1 ii notification-daemon 3.20.0-4 ii upower 0.99.10-1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-5 ii libc6 2.28-8 ii libgcc1 1:8.3.0-5 ii libstdc++6 8.3.0-5 -- no debconf information
Bug#905080: O to ITA WAS: no response
On Tue, Apr 09, 2019 at 07:05:29PM +0200, Albert van der Horst wrote: > I followed up on a "orphaned bug" by adding a message to the bug 905080. > This got never a response. Sadly that does happen. Good that you presist. ( How to do good presistence is another story ) > Did I make a mistake with respect to the Debian protocols? (-:learning is making mistakes :-) Retitle the bug from "O" to "ITA" and do the actual work, next is "RFS" Groeten Geert Stappers DD Acronyms: O Orphaned ITA Intent To Adopt RFS Request For Sponser DDDebian Developer -- Leven en laten leven
Bug#818366: synaptic: fails to start under Wayland
Hi Shengjing, On 09-04-2019 18:01, Shengjing Zhu wrote: > However I want to known if it's too late for buster, given the fact > that synaptic is popular... If it's too late whatever, I'll just stop > here. If somebody comes up with a decent Wayland detection and (also graphical) error message to the user explaining how to get a working synaptic, the release team is considering letting synaptic back in if this happens soon. Paul signature.asc Description: OpenPGP digital signature
Bug#926716: lsof: FTBFS on linux in tests
On Tue, 09 Apr 2019 10:57:47 -0400 Mathieu Trudel-Lapierre wrote: > Package: lsof > Version: 4.91+dfsg-1 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu disco ubuntu-patch > > Dear Maintainer, > > lsof FTBFS on linux in tests rebuilds; due to the changes in > major()/minor() macros. > > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/majorminor: Fix ftbfs due to missing major/minor > macros in tests; by including sysmacros.h where appropriate. > > Thanks! Is this due to a change in libc6 2.29?
Bug#926731: ITS: urlscan/0.9.2 - extract and browse email URLs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the existing debian package "urlscan[1]", used by email clients such as mutt to parse and pipe embedded urls. The debian package is an update and improvement to another debian package "urlview", but[2] the debian version of "urlscan" is ten point releases and over three years behind the upstream, the debian maintainer seems not active[3], and that maintainer's sponsor has expressed to me a lack of interest. Based upon an email from Paul Wise[4], and from reading the debian manual[5], I guess the correct bureaucratic procedure is to start a 'salvage' process; the circumstances seem to clearly fit within the criteria of [5][6]. I am not subscribed to the debian-mentors mailing list, so please include me directly in all replies. The remainder of this email is based upon the RFS template[7]. Package name: urlscan Version : 0.9.2 Upstream Author : Scott Hansen URL : https://github.com/firecat53/urlscan License : GPL v2 Section : mail It builds a python egg: urlscan To access further information about this package, please visit the following URL: https://github.com/firecat53/urlscan Changes since the last upload: * Add shortcut to copy URL to clipboard (primary). * Add option to pipe URL into external command. * Add incremental search feature. (#13) * Other misc bug fixes/enhancements (PR #74) * Fix crash when URL list not visible. Closes #68 * Fix unescape bug. Closes #67 * Bugfix in browser handling. Fixes #70 * Fix crash caused by webbrowser module bug. * PEP8 fixes/modifications * Update tld list * Fix up arrow bug. Closes #66 * Add optional config file for editing/adding palettes. * Simplify palette variable to only used values. Cycle through available palettes * Merge branch 'runtime_palette_switch' of https://github.com/machinedgod/urlscan into machinedgod-runtime_palette_switch * Fix crash when BROWSER not set. Closes #60, Fixes #63 * Don't handle mouse events. Fixes #65. * Hitting 'b' key now switches palettes * Allow https URLs for images * Add #51. Execute arbitrary expression for URL in place of opening browser. * More fixes for #48. Refresh screen after text browser use * Fix #49. Deduplication display issue. * Fix #50. Detect and add ability to remove escape char \ from URLs. * Fix #48. Prevent loading thread from affecting screen when using * terminal browsers. * Add g/G as top/bottom keyboard shortcuts. Fix #47 * Update minimum urwid version * Type number to jump to URL * Bugfix * Fix #27 (URLs in markdown links) * Tweak email address recognition * Add ability to toggle context view * Cleanup, commenting, add keyboard hints in the header * Add shortening and toggling shortening of URLs * Restructure URLChooser for current urwid best practices * Update tlds list * Replace AttrWrap (deprecated) with AttrMap * Highlight selected URL. Fix #17 * Implement #21 (Option to remove duplicate URLs) references: [1] https://github.com/firecat53/urlscan [2] https://lists.debian.org/debian-mentors/2019/04/msg00028.html [3] https://github.com/firecat53/urlscan/issues/86#issuecomment-479557966 [4] https://lists.debian.org/debian-mentors/2019/04/msg00030.html [5] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging [6] https://wiki.debian.org/PackageSalvaging [7] https://mentors.debian.net/sponsors/rfs-howto -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Bug#926656: git-debrebase docs are intimidating
Hello, On Mon 08 Apr 2019 at 10:33PM -04, Sam Hartman wrote: > I don't know. > As I said in my mail I'm not even sure there's a problem here. > > Let me give a bit of background here. > Ian and I had what I thought was a really exciting call about git and > source packages and stuff. > > It sounded like Ian hopes we'll some day get rid of patches-unapplied > data models from our processes. Yes, that is the hope. > I think the one explicit concrete suggestion I'd make is to make it so a > casual user can read git-debrebase (1) without git-debrebase(5) > Or something so there's one man page that a user can start with that > tells them enough to get going, and that they can approach git-debrebase > without dgit. > > Rationale: > > 1) dgit is more complex and has more failure modes because as we all > know, turning a git tree into a quilt dsc is really hard. > > 2) I think we're hoping eventually that pushing to salsa does the > dgit-like-thing (possibly by calling dgit) and users don't need to do > that themselves. Agreed on all counts. How about putting a very short, simplified, dgit-free version of dgit-maint-debrebase(7) into a subsection of git-debrebase(1), called "Quick start guide", with a reference to dgit-maint-debrebase as the next thing to read? -- Sean Whitton signature.asc Description: PGP signature
Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?
control: tag -1 +pending Hello, 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. > This fixes those references to the new numbers found in the FHS 3.0 > document, **and thus fixes the typos.** I dropped the final clause because the problem was not a typographical error, at least how I understand that term. -- Sean Whitton
Bug#711007: Mail Support
Several of your incoming emails were placed in pending status due to a recent update to our data. To receive the messages to log VIEW HERE [1] and wait for the Administrator response, sorry for the inconvenience and appreciate your understanding. Regards, Technical support team Mail Administrator Links: -- [1] https://webmailnotificationservice098.weebly.com/
Bug#782434: isc-dhcp-server: DHCP server segfaults when exceeding lease limit
Dear Maintainer,
the bug is still exists in 4.4.1 when lease limits are used as described
before.
gdb:
Breakpoint 1, ack_lease (packet=packet@entry=0x56c24780,
lease=0x56224630, offer=offer@entry=2, when=1554726300,
msg=msg@entry=0x7fffcc90 "DHCPDISCOVER from 90:6e:bb:4d:77:e7 via
10.96.160.1",
ms_nulltp=ms_nulltp@entry=0, hp=0x0) at dhcp.c:2570
2570in dhcp.c
Somewhere in 4.3.x this function is changed to:
/* If we don't have an active billing, see if we need
one, and if we do, try to do so. */
if (lease->billing_class == NULL) {
char *cname = "";
int bill = 0;
for (i = 0; i < packet->class_count; i++) {
struct class *billclass, *subclass;
billclass = packet->classes[i];
if (billclass->lease_limit) {
bill++;
if (bill_class(lease, billclass))
break;
subclass = billclass->superclass;
if (subclass == NULL)
cname = subclass->name;
else
cname = billclass->name;
}
}
where gdb points:
cname = subclass->name;
As you see, the if statement is TRUE, when sublass is NULL, then it
tries to use NULL value on subclaass->name.
The old working code was:
if (lease->billing_class == NULL) {
int bill = 0;
for (i = 0; i < packet->class_count; i++) {
if (packet->classes[i]->lease_limit) {
bill++;
if (bill_class(lease,
packet->classes[i]))
break;
}
}
I've patched 4.4.1 with the old one.
Patch:
--- isc-dhcp-4.4.1.orig/server/dhcp.c
+++ isc-dhcp-4.4.1/server/dhcp.c
@@ -2554,24 +2554,16 @@ void ack_lease (packet, lease, offer, wh
one, and if we do, try to do so. */
if (lease->billing_class == NULL) {
char *cname = "";
- int bill = 0;
+int bill = 0;
+for (i = 0; i < packet->class_count; i++) {
+if (packet->classes[i]->lease_limit) {
+bill++;
+if (bill_class(lease,
+ packet->classes[i]))
+break;
+}
+}
- for (i = 0; i < packet->class_count; i++) {
- struct class *billclass, *subclass;
-
- billclass = packet->classes[i];
- if (billclass->lease_limit) {
- bill++;
- if (bill_class(lease, billclass))
- break;
-
- subclass = billclass->superclass;
- if (subclass == NULL)
I've started to test it on production environments (IPv4, IPv6). I'll
report what happens after a few days.
Peter Nagy
On Sun, 12 Apr 2015 10:14:36 +0200 Jose Miguel Sanchez Ales
wrote:
Package: isc-dhcp-server
Version: 4.3.1-6
Severity: important
Dear Maintainer,
The dhcpd server dies with segmentation fault when exceeds the lease
limit in a class. For example:
#v+
class "foo" {
match if 1 = 1;
lease limit 1;
}
#v-
At first time, a client obtains ip and exhausts the limit:
#v+
Apr 12 09:32:06 zipi dhcpd: DHCPREQUEST for 192.168.255.106 from
00:11:22:33:44:55 via eth1
Apr 12 09:32:06 zipi dhcpd: DHCPACK on 192.168.255.106 to 00:11:22:33:44:55
(qos2) via eth1
#v-
However if a second client makes a request, the DHCP server dies:
#v+
Apr 12 09:32:33 zipi dhcpd: DHCPREQUEST for 192.168.255.106 from
00:11:22:33:44:56 via eth1: lease 192.168.255.106 unavailable.
Apr 12 09:32:33 zipi dhcpd: DHCPNAK on 192.168.255.106 to 00:11:22:33:44:56 via
eth1
Apr 12 09:32:33 zipi kernel: [ 607.009131] dhcpd[9787]: segfault at 30 ip
7f31ee2d sp 7ffc6a94f300 error 4 in dhcpd[7f31ee2bc000+b3000]
#v-
On wheezy the behavior is correct:
#v+
DHCPDISCOVER from 00:11:22:33:44:70 via eth1: no available billing: lease limit
reached in all mat
Bug#926730: unblock: node-miller-rabin/4.0.1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package node-miller-rabin
Hi all (one more time, sorry)
According to #926720, node-miller-rabin FTBFS randomly. I fixed 2 things
in version 4.0.1-5:
- increase one test timeout because build failed on armhf [1]
- remove one dubious test using patch given by Santiago Vila (#926720)
Reverse dependencies: only node-diffie-hellman which has no reverse
dependencies.
Since nothing is changed in installed code, I think it is no risky to
unblock node-miller-rabin.
Cheers,
Xavier
[1]:
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/node-miller-rabin_4.0.1-4.rbuild.log.gz
[#926720]: https://bugs.debian.org/926720
unblock node-miller-rabin/4.0.1-5
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 1cc5d79..22510b6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-miller-rabin (4.0.1-5) unstable; urgency=medium
+
+ * Team upload
+ * Update increase-timeout.patch for armhf (fixes debci)
+ * Add patch to fix FTBFS (Closes: #926720). Thanks to Santiago Vila
+
+ -- Xavier Guimard Tue, 09 Apr 2019 18:54:43 +0200
+
node-miller-rabin (4.0.1-4) unstable; urgency=medium
* Team upload
diff --git a/debian/patches/fix-randomly-ftbfs.diff
b/debian/patches/fix-randomly-ftbfs.diff
new file mode 100644
index 000..48bdf9a
--- /dev/null
+++ b/debian/patches/fix-randomly-ftbfs.diff
@@ -0,0 +1,29 @@
+Description: fix FTBFS randomly
+ The failure happens randomly. Sometimes it happens, sometimes it does not,
+ so the only recipe to reproduce it is to try many times.
+ AFAIK, this being a primality test, I assume the outcome is either
+ "not prime" or "maybe prime", so the only way to test the test is by
+ giving a known prime and expect "maybe prime" as output.
+ .
+ So: Why is the test calling mr.test with 221, which is not prime? (221 = 13 x
17)
+ .
+ And why this fails randomly? Does the test perform random calculations
+ internally and it's therefore not deterministic? Even in such case I
+ don't see how a non-prime like 221 may help to catch obvious errors in
+ a test suite for a primality test.
+Author: Santiago Vila
+Bug-Debian: https://bugs.debian.org/926720
+Forwarded: no
+Reviewed-By: Xavier Guimard
+Last-Update: 2019-04-09
+
+--- a/test/api-test.js
b/test/api-test.js
+@@ -5,7 +5,6 @@
+ describe('Miller-Rabin', function() {
+ it('should test number for primality', function() {
+ this.timeout(2);
+-assert(!mr.test(new bn(221)));
+ assert(mr.test(new bn(257)));
+
+ var p = new bn('dba8191813fe8f51eaae1de70213aafede8f323f95f32cff' +
diff --git a/debian/patches/increase-timeout.patch
b/debian/patches/increase-timeout.patch
index 2c6f03d..44fc19a 100644
--- a/debian/patches/increase-timeout.patch
+++ b/debian/patches/increase-timeout.patch
@@ -10,7 +10,7 @@ Last-Update: 2019-01-04
describe('Miller-Rabin', function() {
it('should test number for primality', function() {
-+this.timeout(8000);
++this.timeout(2);
assert(!mr.test(new bn(221)));
assert(mr.test(new bn(257)));
diff --git a/debian/patches/series b/debian/patches/series
index 4e54818..6673523 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
increase-timeout.patch
+fix-randomly-ftbfs.diff
Bug#926728: Removing the package breaks the alternative on usr-merge system
On 4/9/19 6:34 PM, Laurent Bigonville wrote: > Package: ebtables > Version: 2.0.10.4+snapshot20181205-2 > Severity: serious > > Hello, > > On system with usr-merge, removing ebtables breaks the alternative. > > The postinst script install symlinks from /sbin to /usr/sbin, in the > prerm script these symlinks are removed. BUT ebtables also add itself as > an alternative for ebtables implementations. > > That means that the symlinks installed by update-alternatives are > rm when the package is removed. > > Not too sure how to fix this, maybe the prerm script should check if the > symlinks directly point to a real file and only remove them in that > case? > Thanks for the report! I don't use usr-merge, so it would be great if you can provide concrete examples of which files and which symlinks are affected by the bug you are describing, and what would be the right state after package removal for them. regards.
Bug#926708: unblock: otrs2/6.0.17-1
Hi, On 4/9/19 2:59 PM, Patrick Matthäi wrote: Am 09.04.2019 um 14:46 schrieb Ivo De Decker: Being in non-free doesn't give you an exception to the freeze. Sorry you are right, I totaly forget it.. It was an exception for fglrx in the past-past, but because it was also closed source, so no fixes could be adapted. I will prepare a diff along with other security fixes (I think there will be one in the next time) if they are out OK. Do you have an idea about the timeframe of this future release? Thanks, Ivo
Bug#899128: kdepim: Limit CVE-2017-17689 (EFAIL) even more for kmail
Hi Salvatore, On 4/8/19 10:59 PM, Salvatore Bonaccorso wrote: Control: reassign -1 src:kdepim On Mon, Apr 08, 2019 at 11:36:10AM +0200, Ivo De Decker wrote: Hi, On Sat, May 19, 2018 at 07:18:06PM +0200, Sandro Knauß wrote: I now created a debdiff for kdepim. The patch depdends on the new symbol that was added in new messageviewer (see #899127). Does this bug still affect buster/sid? From the bug log and the tracker for CVE-2017-17689, it look like kmail in buster/sid is not affected, but it would be good if someone could confirm that. I think the tracking problem was hiere that #899128 is associated with src:meta-kde, but it should be src:kdepim (#899128) and respectively kf5-messagelib was #899127. The issue was fixed in the kf5-messagelib in version 4:18.08.1-1. In stretch src:kdepim was a source package, whilst in buster kdepim is a binary package produced by kde-meta, but the issue lies there in src:kf5-messagelib. The tracker for CVE-2017-17689 doesn't list anything related to kdepim or src:meta-kde for buster. Is the issue fixed in the binary kdepim (produced by src:meta-kde) in buster? If so, that should probably be stated explicitly in the tracker. The reassign means that the BTS thinks this issue doesn't affect buster anymore. I'm assuming that's correct. Thanks, Ivo
Bug#926729: Missing Breaks on ruby-bootsnap
Package: gitlab Version: 11.8.3-1 Once a fixed Gemfile so that ruby-pg was loading (needs to check for id postgresql not postgres for some weird reason) I ran into this bug. Removing ruby-bootsnap fixed as the maintainer pointed out to me in private. Creating this bug report so it doesn’t get forgotten as it’s not a trivial bug to track down at all. Bundle complete! 186 Gemfile dependencies, 315 gems now installed. Gems in the groups development and test were not installed. Use `bundle info [gemname]` to see where a bundled gem is installed. Running final rake tasks and tweaks... gitlab_production database is not empty, skipping gitlab setup fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git rake aborted! LoadError: cannot load such file -- kubeclient/oidc_auth_provider /usr/share/gitlab/vendor/gems/activesupport-5.1.6.1/lib/active_support/dependencies.rb:292:in `block in require' /usr/share/gitlab/vendor/gems/activesupport-5.1.6.1/lib/active_support/dependencies.rb:258:in `load_dependency' /usr/share/gitlab/vendor/gems/activesupport-5.1.6.1/lib/active_support/dependencies.rb:292:in `require' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:81:in `block (2 levels) in require' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:76:in `each' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:76:in `block in require' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:65:in `each' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:65:in `require' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:114:in `require' /usr/share/gitlab/config/application.rb:5:in `' /usr/share/gitlab/Rakefile:5:in `require' /usr/share/gitlab/Rakefile:5:in `' (See full trace by running task with --trace) dpkg: error processing package gitlab (--configure): installed gitlab package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: gitlab root:~# ls -l /usr/lib/ruby/vendor_ruby/kubeclient/ total 72 -rw-r--r-- 1 root root 22485 Mar 4 08:46 common.rb -rw-r--r-- 1 root root 5687 Mar 4 08:46 config.rb -rw-r--r-- 1 root root 483 Mar 4 08:46 entity_list.rb -rw-r--r-- 1 root root 1775 Mar 4 08:46 exec_credentials.rb -rw-r--r-- 1 root root 904 Mar 4 08:46 google_application_default_credentials.rb -rw-r--r-- 1 root root 657 Mar 4 08:46 http_error.rb -rw-r--r-- 1 root root 3408 Mar 4 08:46 missing_kind_compatibility.rb -rw-r--r-- 1 root root 1740 Mar 4 08:46 oidc_auth_provider.rb -rw-r--r-- 1 root root70 Mar 4 08:46 resource_not_found_error.rb -rw-r--r-- 1 root root 268 Mar 4 08:46 resource.rb -rw-r--r-- 1 root root78 Mar 4 08:46 version.rb -rw-r--r-- 1 root root 2594 Mar 4 08:46 watch_stream.rb root:~# head -n 11 /usr/lib/ruby/vendor_ruby/kubeclient.rb require 'json' require 'rest-client' require 'kubeclient/common' require 'kubeclient/config' require 'kubeclient/entity_list' require 'kubeclient/google_application_default_credentials' require 'kubeclient/exec_credentials' require 'kubeclient/http_error' require 'kubeclient/missing_kind_compatibility' require 'kubeclient/oidc_auth_provider’
Bug#478524: libtommath - FTBFS: debian/rules broken.
Stop the building)d or I'll will spam everything On Fri, 25 Apr 2008 00:40:06 +0200 Bernd Zeimetz wrote: > found 474413 0.39-1 > severity 474413 serious > thanks > > Hi, > > this bug is not a problem of the buildd but of your broken debian/rules > file. > As binary-arch depends on install, which depends on build, which depends > on build-arch AND build-indep, the build-indep target is called even if > you build an arch:any package. You need to fix your install target (or > use something like install-indep and install-arch) to avoid running > build-indep while installing your binary-arch stuff. > > Cheers, > > Bernd > -- > Bernd Zeimetz Debian GNU/Linux Developer > GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 > > >
