Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0
Hi, Le 31/08/2017 à 00:10, Ximin Luo a écrit : > Julien Puydt: >> Hi, >> >> Le 29/08/2017 à 14:25, Tobias Hansen a écrit : >>> Now is a good time for the NTL transition. Julien, could you update the >>> package to 10.3.0? Then we can test-build the reverse dependencies and >>> ask for a transition. >> >> Indeed there was a soname version bump from 27 to 35, so a transition is >> in order. >> >> There also was a change of license, so I changed d/copyright -- I would >> be glad if someone could check the result. >> >> Finally, lintian complains about hardening-no-fortify-functions and >> hardening-no-bindnow, which means there's more digging to do for me. >> > > I'd ignore both: > > 1. hardening-no-fortify-functions happens naturally when the library does not > use any libc functions that change under -D_FORTIFY_SOURCE=2 and this is > probably a false positive > > 2. hardening-no-bindnow is just due to dpkg-buildflags not defaulting that to > on. If you really want to fix it you can > > export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow Won't work : the configure script isn't an autotools script -- it calls a DoConfig perl script, which does its own work in its own way. And of course it won't respect what we fix... Snark
Bug#849505: transition: nodejs
2017-08-30 23:26 GMT+02:00 Emilio Pozuelo Monfort : > On 29/08/17 23:15, Sebastiaan Couwenberg wrote: > > On 06/25/2017 01:15 PM, Jonathan Wiltshire wrote: > >> Now stretch is released we can deal with this. > >> > >> On Wed, Dec 28, 2016 at 12:49:33AM +0100, Jérémy Lal wrote: > >>> Transition should have minimal impact on these addons. > >>> Most other pure Node.js modules should be okay - they either > >>> are already compatible with Node.js 6 or have upstream updates > >>> providing that compatibility. > >> > >> This sounds rather, well, hopeful. Please stage the transition in > >> experimental first, and test/fix reverse dependencies. Then come back > and > >> we'll schedule a time to do it in unstable. > >> > >> (Transitions should really be ready to go by the time they come to us; > >> they should also be able to happen quickly, because a blocked transition > >> holds up all sorts of other work.) > > > > Jérémy, the transition was started by the upload of nodejs to unstable, > > but you've not replied to the above yet. > > > > Can you confirm that all reverse dependencies build successfully with > > the new nodejs in unstable? > > > > If so, the binNMUs can be scheduled to move this transition along. > > The problem is the nodejs mips64el failure, caused by the mips64el gcc-7 > bug > (#871514). I'm waiting for that to be fixed first. > I've tried building with g++-6 but there is one test failure. I'm looking why this is. Jérémy
Bug#873790: ITP: node-p-locate -- async version of Array#find
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-p-locate Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/p-locate#readme * License : Expat Programming Lang: JavaScript Description : async version of Array#find Get the first fulfilled promise that satisfies the provided testing function. . Array.prototype.find(): The find() method returns the value of the first element in the array that satisfies the provided testing function. p-locate is sync version of this function. . Node.js is an event-based server-side JavaScript engine. This library is a dependency of gitlab 9.x signature.asc Description: OpenPGP digital signature
Bug#873791: [python-numpy] Undefined symbols on several architectures
Package: python-numpy Version: 1.12.1-3+b2 Severity: serious Affects: src:casacore On several platforms, numpy cannot be loaded successfully due to missing symbols: import numpy as NUM; File "/usr/lib/python2.7/dist-packages/numpy/__init__.py", line 166, in from . import random File "/usr/lib/python2.7/dist-packages/numpy/random/__init__.py", line 99, in from .mtrand import * ImportError: /usr/lib/python2.7/dist-packages/numpy/random/mtrand.aarch64-linux-gnu.so: undefined symbol: PyFPE_jbuf The symbol that is reported as undefined varies between the platforms: * arm64, s390x, alpha, hurd-i386: PyFPE_jbuf * mips, mipsel, ppc64el, powerpc, ppc64: PyFPE_counter These errors cause FTBFS for the "casacore" package: https://buildd.debian.org/status/logs.php?pkg=casacore&ver=2.3.0-4 Best regards Ole
Bug#873789: init-system-helpers: autopkgtests broken in 1.49
Package: init-system-helpers
Version: 1.49
Followup-For: Bug #873789
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch
Attached is a patch which fixes the tests to also correctly handle the
escape characters in the unit names.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru init-system-helpers-1.49/t/001-deb-systemd-helper.t
init-system-helpers-1.49ubuntu1/t/001-deb-systemd-helper.t
--- init-system-helpers-1.49/t/001-deb-systemd-helper.t 2017-07-17
09:27:32.0 -0700
+++ init-system-helpers-1.49ubuntu1/t/001-deb-systemd-helper.t 2017-08-30
23:44:48.0 -0700
@@ -21,7 +21,7 @@
sub _unit_check {
my ($unit_file, $cmd, $cb, $verb) = @_;
-my $retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh $cmd $unit_file");
+my $retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh $cmd
'$unit_file'");
isnt($retval, -1, 'deb-systemd-helper could be executed');
ok(!($retval & 127), 'deb-systemd-helper did not exit due to a signal');
$cb->($retval >> 8, 0, "random unit file $verb $cmd");
@@ -96,7 +96,7 @@
'multi-user.target.wants does not exist yet');
}
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable '$random_unit'");
is($retval, 0, "enable command succeeded");
my $symlink_path = "/etc/systemd/system/multi-user.target.wants/$random_unit";
ok(-l $symlink_path, "$random_unit was enabled");
@@ -120,7 +120,7 @@
isnt_enabled($random_unit);
is_debian_installed($random_unit);
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable '$random_unit'");
is($retval, 0, "enable command succeeded");
isnt_enabled($random_unit);
@@ -133,7 +133,7 @@
ok(-f $statefile, 'state file exists');
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test _DEB_SYSTEMD_HELPER_PURGE=1
$dsh disable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test _DEB_SYSTEMD_HELPER_PURGE=1
$dsh disable '$random_unit'");
is($retval, 0, "disable command succeeded");
ok(! -f $statefile, 'state file does not exist anymore after purging');
isnt_debian_installed($random_unit);
@@ -145,7 +145,7 @@
ok(! -l $symlink_path, 'symlink does not exist yet');
isnt_enabled($random_unit);
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable '$random_unit'");
is($retval, 0, "enable command succeeded");
is_enabled($random_unit);
@@ -155,7 +155,7 @@
# ┃ Verify “disable” removes the symlinks.┃
# ┗━━━┛
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test _DEB_SYSTEMD_HELPER_PURGE=1
$dsh disable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test _DEB_SYSTEMD_HELPER_PURGE=1
$dsh disable '$random_unit'");
is($retval, 0, "disable command succeeded");
isnt_enabled($random_unit);
@@ -167,7 +167,7 @@
ok(! -l $symlink_path, 'symlink does not exist yet');
isnt_enabled($random_unit);
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable '$random_unit'");
is($retval, 0, "enable command succeeded");
is_enabled($random_unit);
@@ -177,7 +177,7 @@
# ┃ Verify the “purge” verb works.┃
# ┗━━━┛
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh purge $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh purge '$random_unit'");
is($retval, 0, "purge command succeeded");
isnt_enabled($random_unit);
@@ -190,7 +190,7 @@
ok(! -l $symlink_path, 'symlink does not exist yet');
isnt_enabled($random_unit);
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable '$random_unit'");
is($retval, 0, "enable command succeeded");
is_enabled($random_unit);
@@ -203,12 +203,12 @@
my $mask_path = "/etc/systemd/system/$random_unit";
ok(! -l $mask_path, 'mask link does not exist yet');
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh mask $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh mask '$random_unit'");
is($retval, 0, "mask command succeeded");
ok(-l $mask_path, 'mask link exists');
is(readlink($mask_path), '/dev/null', 'service masked');
-$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh unmask $random_unit");
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh unmask '$random_unit'");
is($retval, 0,
Bug#873774: Many gui apps become slow responsive after upgrading my sid
How to install a older version of scim? I tried apt-get install scim=1.4.17-1+b1, but it says version 1.4.17-1+b1 not found, neither for 1.4.17-1. On 08/31/2017 01:35 AM, Rolf Leggewie wrote: On 31.08.2017 09:36, liuxu wrote: Package: scim Version: 1.4-18 many gui apps in my mate desktop env becomes slow responsive [...] After purge all scim packages, those problematic apps become normal immediately. After reinstall scim and scim-pinyin, those apps become probelmatic again immediately. Hello Liuxu, thank you for your report. I'm sorry to hear about the troubles you are facing. Were you previously using version 1.4.17-1? Does downgrading to the version in testing help? Regards Rolf
Bug#873783: wcc: FTBFS on non-amd64 architectures
Le 31 août 2017 05:10:10 GMT+02:00, "Aaron M. Ucko" a écrit : >Source: wcc >Version: 0.0.2+dfsg-1 >Severity: important >Tags: upstream >Justification: fails to build from source > >Builds of wcc for architectures other than (Linux) amd64 have been >failing. > >On non-x86 architectures, there are two considerations: the >embedded copy of openlibm under src/wsh generally has no >$(ARCH)/Make.files, and GCC doesn't support -masm=intel regardless. >You could sidestep the former by building against separately packaged >libopenlibm-dev (as called for by Policy 4.13), but the latter may be >more of a problem. > >On non-Linux architectures (kFreeBSD and presumably also the Hurd if >and when clang becomes installable there), there's no >for arch.h to include. > >On i386, wsh somehow winds up compiled for the wrong architecture, >leading to link errors: > >/usr/bin/ld: skipping incompatible >/usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu/libiberty.a when >searching for -liberty >/usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libiberty.a >when searching for -liberty > /usr/bin/ld: cannot find -liberty > >On x32 (admittedly not a release architecture), wcc is still in the >Needs-Build queue; I'm not sure what will happen there. > >At any rate, I'm reporting this as a single bug because I suspect you >may just want to declare Architecture: amd64 (with the possible >addition of x32) and be done with it. That said, you're certainly >welcome to address any or all of these portability issues if feasible. > >Thanks! Hello Aaron, Thanks for the report ! I'll update the package to use the packaged libopenlibm-dev. For the elf-em.h, I'll check for the corresponding file in Freebsd and Hurd and add some preprocessing to support all of them. I'll test on arm, but I dunno if there is a debomatic for others arches than amd64. If you know if there is such testbed, it would be great. -- O Philippe Thierry. /Y\/ GPG: 7010 9a3c e210 763e 6341 4581 c257 b91b cdaf c1ea o#o (sent from my smartphone)
Bug#873792: qjackctl will not start at all
Package: qjackctl Version: 0.4.5-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? I use jackd to facilitate realtime audio according to my limits.conf for some software called Pianoteq. In the last update, I tried to run qjackctl and received the following error: qjackctl: symbol lookup error: /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5: undefined symbol: FT_Property_Set I am unable to start qjackctl * What exactly did you do (or not do) that was effective (or ineffective)? I do not think I intentionally installed any extra packages that stops qjackctl from launching properly. * What was the outcome of this action? qjackctl does not launch * What outcome did you expect instead? qjackctl launches normally -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (1000, 'testing'), (1000, 'stable'), (750, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-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 qjackctl depends on: ii jackd 5 ii libasound21.1.3-5 ii libc6 2.24-14 ii libgcc1 1:7.2.0-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.10+20150825git1ed50c92~dfsg-5 ii libqt5core5a 5.9.1+dfsg-9 ii libqt5dbus5 5.9.1+dfsg-9 ii libqt5gui55.9.1+dfsg-9 ii libqt5widgets55.9.1+dfsg-9 ii libqt5x11extras5 5.9.1-2+b1 ii libqt5xml55.9.1+dfsg-9 ii libstdc++67.2.0-1 ii libx11-6 2:1.6.4-3 qjackctl recommends no packages. Versions of packages qjackctl suggests: ii pulseaudio-utils 10.0-2 -- no debconf information
Bug#873793: openjdk-8-jre: NetBeans IDE becomes slower and slower after some usage
Package: openjdk-8-jre Version: 8u141-b15-1~deb9u1 Hello: I'm using the upstream version of NetBeans IDE, the version 8.2. I know that it's not software maintained by the Debian team, but I believe that the bug that I'm going to talk about is not directly related to NetBeans, but to the OpenJDK version bundled by Debian. When I open the application, it works fine, but the GUI already behaves slower than with other versions of the OpenJDK. As I start folding and unfolding the directory tree in the "Projects" panel, and opening and closing files (I only do that, nothing else), the application becomes slower and slower, until a point in which I need to stop and start it again. I've downgraded OpenJDK to the version 8u131-b11-2, but the result has been the same. Later, I've installed the JDK from Oracle, the version 1.8.0-144, and NetBeans has behaved smooth from the beginning. After some time of usage, it still performed well. It might seem that it's just a performance difference between 2 different implementations (although Oracle's is based on OpenJDK). However, I've been using OpenJDK in Kubuntu without a problem. Because I still have some Kubuntu installs in the same machine, I've decided to do the same test with different versions. And this the result: -- Kubuntu 16.04 * Kernel: Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux * libc6: 2.23-0ubuntu9 * openjdk-8-jre: 8u131-b11-2ubuntu1.16.04.3 * Result: ### SMOOTH ### -- Kubuntu 16.10 * Kernel: Linux 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux * libc6: 2.24-3ubuntu2.2 * openjdk-8-jre: 8u131-b11-0ubuntu1.16.10.2 * Result: ### SMOOTH ### -- Kubuntu 17.04 * Kernel: Linux 4.10.0-32-generic #36-Ubuntu SMP Tue Aug 8 12:10:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux * libc6: 2.24-9ubuntu2.2 * openjdk-8-jre: 8u131-b11-2ubuntu1.17.04.3 * Result: ### SLOW ### -- I know that Canonical often makes changes to some packages from Debian or even get them from upstream. But I publish these results just in case that it's of any help, since it's obvious that "something" changed between versions 16.10 and 17.04, which made OpenJDK behave like it behaves now. I'll try to do some more tests. By the way, this is the information of my current Debian install: * Distribution: Debian GNU/Linux 9.1 (stretch) * Kernel: Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux * libc6: 2.24-11+deb9u1 * openjdk-8-jre: 8u141-b15-1~deb9u1 * openjdk-8-jdk: 8u141-b15-1~deb9u1 Thank you.
Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0
Hi, On Wed, Aug 30, 2017 at 09:44:46PM +0200, Christoph Anton Mitterer wrote: > On Wed, 2017-08-30 at 21:34 +0200, Guido Günther wrote: > > You have gir1.2-spiceclientgtk-3.0 installed? > Yes > > # dpkg -l gir1.2-spiceclientgtk-3.0 > [snip snap] > ii gir1.2-spiceclientgtk-3.0 0.34-1amd64 > GTK3 > widget for SPICE clients (GObject-Introspection) It seems it has moved to a multiarch location: $ dpkg -L gir1.2-spiceclientgtk-3.0 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/girepository-1.0 /usr/lib/x86_64-linux-gnu/girepository-1.0/SpiceClientGtk-3.0.typelib /usr/share /usr/share/doc /usr/share/doc/gir1.2-spiceclientgtk-3.0 /usr/share/doc/gir1.2-spiceclientgtk-3.0/changelog.Debian.gz /usr/share/doc/gir1.2-spiceclientgtk-3.0/changelog.gz /usr/share/doc/gir1.2-spiceclientgtk-3.0/copyright $ dpkg -L gir1.2-spice-client-gtk-3.0 /. /usr /usr/lib /usr/lib/girepository-1.0 /usr/lib/girepository-1.0/SpiceClientGtk-3.0.typelib /usr/share /usr/share/doc /usr/share/doc/gir1.2-spice-client-gtk-3.0 /usr/share/doc/gir1.2-spice-client-gtk-3.0/changelog.Debian.gz /usr/share/doc/gir1.2-spice-client-gtk-3.0/changelog.gz /usr/share/doc/gir1.2-spice-client-gtk-3.0/copyright but this shouldn't make any difference. You could try strace to see if the typelib file gets picked up. Note that this is likely not related to virt-manager but rather to how libgirepository picks up things. > > > > > > virt-viewer works? > Uhm I haven't had that installed before,... so not sure whether it > would have worked then, but now it says: > Failed to connect: No virtual machine found Confusing since it only acts on running VMs. I've sent a patch upstream to turn this into: Failed to connect: No running virtual machine found Cheers, -- Guido
Bug#873244: pyjwt: CVE-2017-11424: Incorrect handling of PEM-encoded public keys
Control: notfound -1 0.2.1-1+deb8u1 Hi On Fri, Aug 25, 2017 at 08:59:33PM +0200, Salvatore Bonaccorso wrote: > Please adjust the affected versions in the BTS as needed. I think this > should be present as well in 0.2.1-1+deb8u1. Whilst the test is missing as well in 0.2.1-1+deb8u1, pyjwt in Jessie would probably not work as expected in this regard. I'm removing the found version for 0.2.1-1+deb8u1 for now. Regards, Salvatore
Bug#873795: calibre: Security risk and possible backdoor when fetching news
Package: calibre Version: 3.4.0+dfsg-1 Severity: normal Dear Maintainer, I'm using cron and /usr/bin/ebook-convert to fetch RSS news daily. Some generated ebooks are containing typos. The mistakes are located in a so-called "news fetching recipe" in Zip archive /usr/share/calibre/builtin_recipes.zip. I tried to edit the recipe code but the mistakes remain in ebooks. I wrote an own custom recipe, I edited built-in recipe in ZIP archive - nothing helps. As a last try I switched off network and had success. That maked me curious, so I repeated the procedures with Wireshark logging network traffic. The result: Calibre completely ignores built-in recipes and loads python scripts from a server in Mumbai/India: https://code.calibre-ebook.com:443/... ( using self- signed wildcard certificate) It's a absolute taboo to load scripts in background from an untrusted server and execute them on a Linux computer without user permission and without informing user. This is a Debian OS not Windows. What if the scripts are containing malware or spyware? My workarond is to remove /usr/share/calibre/calibre-ebook-root-CA.crt. That breaks unwanted HTTPS connections. Here is a test script for verifying. It runs in a terminal without the need of starting Calibre: - #!/bin/sh # test directory TARGET="$HOME/test" LABEL="Pro-Physik" RECIPE="Pro Physik.recipe" PROFILE="kindle" FORMAT="mobi" EBOOK="$TARGET/$LABEL.$FORMAT" EXEC="/usr/bin/ebook-convert" LOG="$HOME/test/fetch.log" exec >> "$LOG" 2>&1 echo -e "\n*** fetching $LABEL " $EXEC "$RECIPE" "$EBOOK" --output-profile "$PROFILE" - BTW: "Pro Physik.recipe" is a python script archived in /usr/share/calibre/builtin_recipes.zip and contains some typos. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.6-bulldozer (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calibre depends on: ii calibre-bin 3.4.0+dfsg-1 ii fonts-liberation 1:1.07.4-2 ii imagemagick 8:6.9.7.4+dfsg-16 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-16 ii libjs-coffeescript 1.10.0~dfsg-1 ii libjs-mathjax2.7.0-2 ii poppler-utils0.48.0-2 ii python-apsw 3.16.2-r1-2+b1 ii python-beautifulsoup 3.2.1-1 ii python-chardet 3.0.4-1 ii python-cherrypy3 3.5.0-2 ii python-cssselect 1.0.1-1 ii python-cssutils 1.0-4.1 ii python-dateutil 2.6.0-1 ii python-dbus 1.2.4-1+b2 ii python-feedparser5.1.3-3 ii python-lxml 3.8.0-1+b1 ii python-markdown 2.6.9-1 ii python-mechanize 1:0.2.5-3 ii python-msgpack 0.4.8-1+b1 ii python-netifaces 0.10.4-0.1+b3 ii python-pil 4.2.1-1 ii python-pkg-resources 36.2.7-2 ii python-pyparsing 2.1.10+dfsg1-1 ii python-pyqt5 5.7+dfsg-5+b1 ii python-pyqt5.qtsvg 5.7+dfsg-5+b1 ii python-pyqt5.qtwebkit5.7+dfsg-5+b1 ii python-regex 0.1.20170117-1+b1 ii python-routes2.4.1-1 ii python2.72.7.13-2 ii xdg-utils1.1.1-1 Versions of packages calibre recommends: ii python-dnspython 1.15.0-1 calibre suggests no packages. -- no debconf information
Bug#873794: syntax error in debconf preseeding
Package: debian-cloud Tags: patch In fai-cloud-image, there's a synatx error in a debconf preseeding file. This may cause grub to hang during boot. Attached is the fix 0001-double-space-single-space.patch Description: Binary data -- regards Thomas
Bug#796241: lightdm-gtk-greeter: confusing placeholder text when greeter-hide-users=true
Package: lightdm-gtk-greeter Version: 2.0.2-1 Followup-For: Bug #796241 Control: Severity -1 important Dear Maintainer, confirmed on a brand new buster system. while seemingly a minor issue, this can easily lead to exposing the password of a user. please fix this..
Bug#851424: Compile fixes merged to ACE master
Hi, The compile fixes for OpenSSL 1.1 support are merged to ACE master, see https://github.com/DOCGroup/ACE_TAO/pull/494 for all changes that had to be made. Best regards, Johnny Willemsen Remedy IT Postbus 81 | 6930 AB Westervoort | The Netherlands http://www.remedy.nl
Bug#873708: libsystemd-shared: symbol collisions
> On 30 Aug 2017, at 15:32, Felipe Sateler wrote: > > BTW, defining generic symbol names like `parse_time` in a public > library like heimdal does is a bad idea. It would be nice to have > heimdal either properly namespace their public symbols or hide > nonpublic symbols. Johan, could you file a bug on heimdal for this issue? Looking at both `libkrb5.so.26` which needs the symbol and `libroken.so.18` which holds the symbol both have versions: ``` # readelf --syms /usr/lib/x86_64-linux-gnu/libkrb5.so.26 | grep parse_time 537: 0 FUNCGLOBAL DEFAULT UND parse_time@HEIMDAL_ROKEN_1.0 (7) ``` ``` # readelf --syms /usr/lib/x86_64-linux-gnu/libroken.so.18 | grep parse_time 143: 8e8029 FUNCGLOBAL DEFAULT 13 unparse_time@@HEIMDAL_ROKEN_1.0 153: 8e7015 FUNCGLOBAL DEFAULT 13 parse_time@@HEIMDAL_ROKEN_1.0 267: 8ea029 FUNCGLOBAL DEFAULT 13 unparse_time_approx@@HEIMDAL_ROKEN_1.0 ``` What seems to be happening is that the currently unversioned symbol in `libsystemd-shared-232.so` is allowed to satisfy the reference even if the requesting library is specifying a specific version: ``` # readelf --syms /lib/systemd/libsystemd-shared-232.so | grep parse_time 546: 00110430 2646 FUNCGLOBAL DEFAULT 12 parse_timestamp 1454: 0010e4d0 828 FUNCGLOBAL DEFAULT 12 parse_time ``` Looking around we found an old (and generally unrelated) Debian bug which discusses a similar issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232920 -- jocar
Bug#831521: implement capability to run custom mk-origtargz
Package: devscripts Version: 2.17.6+deb9u1 Followup-For: Bug #831521 Just thinking aloud here: I wonder if it would make sense to create a debhelper plugin to add a get-orig-source sequence, with a sequence of commands, e.g. something like: dh_uscan dh_unpack dh_repack dh_exclude_files dh_strip_icc_profiles Packaging teams could then add commands to do common options e.g. the Java team might want a command to automatically exclude jar and war files. The commands could be overriden in debian/rules to cope with bespoke situations. Just a thought. Christopher
Bug#873796: evolution: FTBFS when building only Architecture: all
Source: evolution Version: 3.24.5-2 Severity: serious Tags: patch Justification: fails to build from source (but built successfully in the past) evolution FTBFS on the 'all' buildd: https://buildd.debian.org/status/fetch.php?pkg=evolution&arch=all&ver=3.24.5-2&stamp=1504140526&raw=0 Unlike Ubuntu, Debian builds Architecture: all packages on their own buildd, which does not build Architecture: any in the same transaction. > find debian/libevolution/ -name 'module-bogofilter.so' -delete > find: 'debian/libevolution/': No such file or directory > debian/rules:40: recipe for target 'override_dh_install' failed The two find calls in debian/libevolution/ need to be skipped when that directory does not exist, i.e. when not building architecture-specific binary packages. I'm testing the attached patch, which I hope will address this. S Index: debian/changelog === --- debian/changelog (revision 3195) +++ debian/changelog (working copy) @@ -1,3 +1,11 @@ +evolution (3.24.5-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do not try to delete bogofilter, spamassassin modules from +libevolution if only building for Architecture: all, fixing FTBFS + + -- Simon McVittie Thu, 31 Aug 2017 09:30:03 +0100 + evolution (3.24.5-2) unstable; urgency=medium * Upload to unstable (Closes: #871626) Index: debian/rules === --- debian/rules (revision 3195) +++ debian/rules (working copy) @@ -39,8 +39,10 @@ override_dh_install: dh_install --fail-missing -X.la -Xlibevolutiontestsettings.so \ -Xusr/lib/evolution/installed-tests -Xusr/share/installed-tests +ifneq ($(filter libevolution,$(shell dh_listpackages)),) find debian/libevolution/ -name 'module-bogofilter.so' -delete find debian/libevolution/ -name 'module-spamassassin.so' -delete +endif override_dh_makeshlibs: dh_makeshlibs -V'libevolution (>= $(DEB_VERSION_UPSTREAM)), libevolution (<< $(DEB_GNOME_NEXTVERSION))' -n
Bug#560683: Please add package which can be installed beside other smtps
On Fri, 11 Dec 2009 13:49:58 +0100 Klaus Ethgen wrote: > The (I think, not so uncommon) usecase is to have a laptop with no > persistent internet connection. For local Mails I want to have a local > only mail server. So I need something to flush real mails out when I > have a internet connection. ssmtp is absolutely fine for this job but > unfortunately installing ssmtp would remove the local delivery daemon. I think you should reconfigure your existing local delivery daemon to support flushing to the external smarthost on demand. This should be doable without ssmtp. The existing local delivery daemon is perfectly able to deal with intermittent internet access already.
Bug#557728: ssmtp Version 2.62
On Tue, 24 Nov 2009 10:49:46 +0100 Michelle Konzack wrote: > You complan about the 2048 Bytes sounds realy weird, because base64 > encoded attachment should not have (-> please read the RFC's) more then > 72 Bytes per line. > > If you modify the source code you schould know, that some MTA's can > reject such messages do to a violation of the RFC's. courier-mta reject > by default or convert the faulty mail to an attachment which the is send > to the originating recipient depending on its configuration. Michelle, Even though you are right that one should not create lines containing more characters than the RFCs allow, there is no excuse for deliberately being non-binary transparent. It looks like this patch actually fixes a non-fatal buffer overflow. It's *not* a good idea to reject fixes like this.
Bug#869399: unlock keyring automatically at startup
OK I used seahorse to make it unencrypted as a workaround.
Bug#815122: wireshark: add OID 1.3.6.1.4.1.11129.2.4.2
Control: fixed -1 2.4.0-1 Hi Fulano, On Fri, 19 Feb 2016 16:19:33 +1100 Fulano Diego Perez wrote: > > Package: wireshark > Version: 2.0.1+g59ea380-3+b1 > Severity: wishlist > > > please add OID 1.3.6.1.4.1.11129.2.4.2 Wireshark 2.4.0 added support for the OID. Cheers, Balint
Bug#807270: mk-origtargz: create reproducible tarballs and --mtime option
user reproducible-bui...@lists.alioth.debian.org usertags 807270 toolchain thanks Hey all, > mk-origtargz: create reproducible tarballs and --mtime option Adding a Reproducible Builds usertag and pinging the ML -- I hadn't spotted this wishlist bug before. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#872252: Debian squeak-vm bug #862576 etoys: Doesn't get beyond Squeak security key generation
Dear Petter and all interested, > On 30.08.2017, at 19:14, David T. Lewis wrote: > > Hi Petter, > > Thank you for your reply. If you have a chance, could you please try > compiling the VM from sources on your own Debian development system, and > try running the Etoys image to see if it works. I have no way to test this > myself, and I have not been able to find someone in the Squeak community > with a suitable development level Debian system to do the test. I expect > that you can do this in 15 minutes or less, as it is just a matter of > doing a "make; sudo make install". > > To ensure that we are working from a common reference point, please use > the sources that I put here: > > https://drive.google.com/file/d/0Bzi8Tf4EvjhoYTNEUDRCc09KOEk/view?usp=sharing > To follow up here, I not only managed to easily build the with the provided snapshot/script, but also it just works starting up. (screenshot attached). @David: I had just forgotten a step in my setup; yes everything works neatly. Also, everybody feel free to contact me for things debian+squeak or debian+etoys, I'll try to help in any way I can. Best regards -Tobias > Thank you very much! > Dave > >> >> Hi, and thank you for reaching out. >> >> [David T. Lewis] >>> I am an upstream maintainer for the traditional Squeak VM, which is >>> package squeak-vm on Debian. Etoys is an important package for kids >>> around the world, so I would like to help resolve the squeak-vm package >>> issue that is causing problems for Etoys on Debian, as documented in >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862576. Although I am >>> not a Debian developer (and I do not have an up to date Debian system >>> for testing), I may be able to provide some useful guidance, and I would >>> be happy to collaborate with the squeak-vm package maintainers to >>> resolve >>> the issue. >> >> Note, dropping the reduced optimizing flag is tracked as bug #872252, so >> lets follow up there instead. I bounced your original email there, and >> changed the To: field appropriately. >> >> Note, I am not much involved in the maintenance of Squeak VM in Debian, >> but come from the Debian Edu side where we use it. :) >> >>> I do need some help to get this sorted out, so please consider this a >>> plea >>> for assistance :-) >>> >>> Background: >>> >>> The squeak-vm package is based on a fairly old snapshot of the source >>> code >>> from the upstream squeakvm.org site, and has accumulated various patches >>> and changes since that snapshot of the sources. The current upstream >>> sources >>> are greatly improved since the snapshot on which the Debian squeak-vm >>> package >>> is based, and is suitable for running the Etoys package on both 32-bit >>> and >>> 64-bit distributions. >> >> One thing that would help the maintainers is to know which of the 5 >> patches in >> https://sources.debian.net/patches/squeak-vm/1:4.10.2.2614-4.1/ > >> are now included in the official upstream source. Can you tell? >> >>> The current sources are easily compiled, and are known to work with >>> the Etoys image on recent Debian-based distributions. Having said >>> that, I do not know for sure, and cannot guarantee, that there will >>> not be issues on the latest Debian version. However, if problems arise >>> I am fairly confident that we will be able to resolve them through a >>> bit of email collaboration. >> >> Is it running in valgrind without any issues reported? Does it build >> with both the most recent gcc and clang compilers? Those tests tend to >> weed out quite a few bugs, so I thought it best to ask early. :) >> >>> What we need to do: >>> >>> Replace the old source package for squeak-vm with a source snapshot >>> based >>> on the current upstream sources at squeak-vm.org. I expect that this >>> will >>> produce a reliable squeak-vm for both 32-bit and 64-bit distributions. >>> We >>> will need to confirm this by running Etoys on the new VM. >> >> Why a snapshot and not a release? >> >> -- >> Happy hacking >> Petter Reinholdtsen >> > >
Bug#838103: python2.7: pip quits with a segfault
Control: tags -1 + moreinfo On 17.09.2016 13:32, Iain R. Learmonth wrote: > Package: python2.7 > Version: 2.7.12-3 > Severity: important > > Hi, > > I noticed when running pip to install packages, it always ended with a > segfault. > > The packages get installed but then pip does not quit cleanly. > > I've attached a backtrace from gdb. > > I'm around on IRC in #debian-python as irl (also can be found in > #debian-devel) > and you're welcome to poke me to make me try different things. why do you think this is an issue in Python itself? could be cffi as well. Is this issue known to the pip maintainers?
Bug#872514: devscripts: Please add script to report on reproducibility status of installed packages
Hi, > Updated patch attached Any update? ACK to push? :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#760021: lintian: check for not wrap-and-sort formatted files
Hi Eric, > lintian: check for not wrap-and-sort formatted files Good idea. Alas, I fear that this would either require calling out to wrap-and-sort (!) and diffing the result, or essentially reimplementing it within Lintian itself? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#868262: python2.7: invalid pointer (free())
Control: reassign -1 duplicity reassigning, it's much more likely to be caused by an extension, e.g. the one built from duplicity itself. On 13.07.2017 23:10, Alexander Schier wrote: > Package: python2.7 > Version: 2.7.13-2 > Severity: normal > > Dear Maintainer, > python 2.7 as an invalid free() when running duplicity. > My usual backup script ran like every day, but it ended with a python > crash. here is the backtrace: > > *** Error in `/usr/bin/python': free(): invalid pointer: > 0x7f3fc5a58fa8 *** > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f3fc8828bcb] > /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f3fc882ef96] > /lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x7f3fc882f7de] > /usr/bin/python(+0xebc28)[0x55e6f8501c28] > /usr/bin/python(+0xdce5a)[0x55e6f84f2e5a] > /usr/bin/python(+0x11e277)[0x55e6f8534277] > /usr/bin/python(+0xdce5a)[0x55e6f84f2e5a] > /usr/bin/python(+0x11e277)[0x55e6f8534277] > /usr/bin/python(+0xebbf3)[0x55e6f8501bf3] > /usr/bin/python(+0x11e277)[0x55e6f8534277] > /usr/bin/python(+0x110917)[0x55e6f8526917] > /usr/bin/python(PyEval_EvalFrameEx+0x5f10)[0x55e6f8516c40] > /usr/bin/python(PyEval_EvalFrameEx+0x5eef)[0x55e6f8516c1f] > /usr/bin/python(PyEval_EvalFrameEx+0x5eef)[0x55e6f8516c1f] > /usr/bin/python(PyEval_EvalCodeEx+0x255)[0x55e6f850f535] > /usr/bin/python(PyEval_EvalCode+0x19)[0x55e6f850f2d9] > /usr/bin/python(+0x128e3f)[0x55e6f853ee3f] > /usr/bin/python(PyRun_FileExFlags+0x82)[0x55e6f8539d52] > /usr/bin/python(PyRun_SimpleFileExFlags+0x19e)[0x55e6f853989e] > /usr/bin/python(Py_Main+0x6c1)[0x55e6f84eaaf1] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f3fc87d82b1] > /usr/bin/python(_start+0x2a)[0x55e6f84ea31a] > === Memory map: > 55e6f8416000-55e6f8739000 r-xp fe:01 4594308 > /usr/bin/python2.7 > 55e6f8939000-55e6f893b000 r--p 00323000 fe:01 4594308 > /usr/bin/python2.7 > 55e6f893b000-55e6f89b2000 rw-p 00325000 fe:01 4594308 > /usr/bin/python2.7 > 55e6f89b2000-55e6f89d5000 rw-p 00:00 0 > 55e6f9a3d000-55e6fadb3000 rw-p 00:00 0 > [heap] > 7f3fbf10e000-7f3fbff0e000 rw-p 00:00 0 > 7f3fc000-7f3fc0021000 rw-p 00:00 0 > 7f3fc0021000-7f3fc400 ---p 00:00 0 > 7f3fc4019000-7f3fc4119000 rw-p 00:00 0 > 7f3fc41f-7f3fc42b rw-p 00:00 0 > 7f3fc42f7000-7f3fc4377000 rw-p 00:00 0 > 7f3fc4394000-7f3fc43aa000 r-xp fe:01 5505901 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f3fc43aa000-7f3fc45a9000 ---p 00016000 fe:01 5505901 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f3fc45a9000-7f3fc45aa000 r--p 00015000 fe:01 5505901 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f3fc45aa000-7f3fc45ab000 rw-p 00016000 fe:01 5505901 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f3fc45ab000-7f3fc45b6000 r-xp fe:01 5505945 > /lib/x86_64-linux-gnu/libnss_nis-2.24.so > 7f3fc45b6000-7f3fc47b5000 ---p b000 fe:01 5505945 > /lib/x86_64-linux-gnu/libnss_nis-2.24.so > 7f3fc47b5000-7f3fc47b6000 r--p a000 fe:01 5505945 > /lib/x86_64-linux-gnu/libnss_nis-2.24.so > 7f3fc47b6000-7f3fc47b7000 rw-p b000 fe:01 5505945 > /lib/x86_64-linux-gnu/libnss_nis-2.24.so > 7f3fc47b7000-7f3fc47f7000 rw-p 00:00 0 > 7f3fc4917000-7f3fc4957000 rw-p 00:00 0 > 7f3fc49ff000-7f3fc4a13000 r-xp fe:01 5505935 > /lib/x86_64-linux-gnu/libnsl-2.24.so > 7f3fc4a13000-7f3fc4c13000 ---p 00014000 fe:01 5505935 > /lib/x86_64-linux-gnu/libnsl-2.24.so > 7f3fc4c13000-7f3fc4c14000 r--p 00014000 fe:01 5505935 > /lib/x86_64-linux-gnu/libnsl-2.24.so > 7f3fc4c14000-7f3fc4c15000 rw-p 00015000 fe:01 5505935 > /lib/x86_64-linux-gnu/libnsl-2.24.so > 7f3fc4c15000-7f3fc4c57000 rw-p 00:00 0 > 7f3fc4c8e000-7f3fc4d0e000 rw-p 00:00 0 > 7f3fc4d0e000-7f3fc4d15000 r-xp fe:01 5505936 > /lib/x86_64-linux-gnu/libnss_compat-2.24.so > 7f3fc4d15000-7f3fc4f14000 ---p 7000 fe:01 5505936 > /lib/x86_64-linux-gnu/libnss_compat-2.24.so > 7f3fc4f14000-7f3fc4f15000 r--p 6000 fe:01 5505936 > /lib/x86_64-linux-gnu/libnss_compat-2.24.so > 7f3fc4f15000-7f3fc4f16000 rw-p 7000 fe:01 5505936 > /lib/x86_64-linux-gnu/libnss_compat-2.24.so > 7f3fc4f16000-7f3fc6316000 rw-p 00:00 0 > 7f3fc6316000-7f3fc6326000 r-xp fe:01 4858701 > /usr/lib/python2.7/lib-dynload/_json.x86_64-linux-gnu.so > 7f3fc6326000-7f3fc6525000 ---p 0001 fe:01 4858701 > /usr/lib/python2.7/lib-dynload/_json.x86_64-linux-gnu.so > 7f3fc6525000-7f3fc6526000 r--p f000 fe:01 4858701 > /usr/lib/python2.7/lib-dynload/_json.x86_64-linux-gnu.so > 7f3fc6526000-7f3fc6527000 rw-p 0001 fe:01 4858701 > /usr/lib/python2.7/lib-dynload/_json.x86_64-linux-gnu.so > 7f3fc6527000-7f3fc6528000 ---p 00:00 0 > 7f3fc6528000-7f3fc6de8000 rw-p 00:00 0 > 7f3fc6de8000-7f3fc6dec000 r-xp fe:01 4858743 > /usr/lib/python2.7/lib-dynload/termios.x86_64-linux-gnu.so > 7f3fc6dec000-7f3fc6feb000 ---p 4000 fe:01 4858743 > /usr/lib/python2.7/lib-dynload/termios.x86_64-linu
Bug#873798: chan_pjsip does not support TLSv1.1+
Source: asterisk Version: 1:13.14.1~dfsg-2 Severity: important Tags: upstream chan_pjsip does not support TLSv1.1 and above. See upstream bug
Bug#873797: missing fping6 breaks smokeping slaves on older systems
Package: fping Version: 4.0-1 Severity: important Tags: ipv6 Hi! The change to remove the fping6 binary breaks smokeping slaves on older Debian systems (and other distributions) for me. Example: I have defined a smokeping probe like this on my master: , | + FPing6 | binary = /usr/bin/fping | timeout = 30 ` This configuration is sent to each slave, but on the slaves running Stretch, Jessie or Wheezy this will result in errors, because the older "/usr/bin/fping" binary is not IPv6 capable. My workaround is to create a symlink /usr/bin/fping6 -> /usr/bin/fping on the master server and change the probe (back) to , | + FPing6 | binary = /usr/bin/fping6 | timeout = 30 ` so the configuration is valid for any system. I think you need to provide this compatibility symlink in the package for at least the Buster release cycle, maybe even for the one after that so that scripts and multi-server environments can be migrated. Grüße, Sven. -- Package-specific info: -rwxr-xr-x 1 root root 42988 Jun 18 23:28 /usr/bin/fping lrwxrwxrwx 1 root root 5 Jul 7 12:59 /usr/bin/fping6 -> fping -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fping depends on: ii libc62.24-17 ii libcap2-bin 1:2.25-1 ii netbase 5.4 fping recommends no packages. fping suggests no packages. -- debconf-show failed
Bug#873781: ocaml-gen: FTBFS without ocamlopt: /usr/lib/ocaml/gen/*.a missing
The *.a files should be marked as optional install items. I've just pushed a fix to alioth. My test build log of mips using sbuild can be found at https://gist.github.com/andyli/c53ebf60246bd8078c272d530bb7e1ce Stéphane: Would you review and upload, please? Best regards, Andy
Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Ian Jackson writes:
> Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
> urgency=medium"):
>> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
>> until it's no longer needed - be it other debian packages or other user
>> scripts.
>
> Earlier you said only "other Debian packages":
>
>My plan was to simply keep /usr/bin/nodejs around for some time
>until no debian package rely on it.
>
> Now you say "other user scripts". I don't know how you would ever
> tell whether "other user scripts" were relying on it. There is no way
> to for us to tell what people are doing on their computers (and nor
> should there be).
I guess that one could do something like moving the symlink into another
-legasy style package, and recomend that from the main package for one
release to keep upgrades happy. Then drop the recomendation, and wait
for popcon to show that people are not installing the package any more.
Then remove the package in testing early in a cycle and see if anyone
reports bugs about it.
That seems like rather a lot of effort though, when the alternative is
simply tolerating the existence of the two line debian/nodejs.links file.
Is there some down-side for users to having those links in place on
their systems? If so, I don't think anyone's mentioned it yet.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#865762: useradd: empty shell by default (debdiff patch available)
Hi,
I am attaching a debdiff patch that simply imports the upstream fix for
this regression.
This has been successfully run-tested on stretch amd64.
Thanks,
Baptiste
PS: it seems that the source git repo [1] is not longer up-to-date because
of a recent NMU change. Thus, the attached patch is against the source
package instead of the git repo.
[1] https://anonscm.debian.org/git/pkg-shadow/shadow.git
On 21-07-17, Baptiste Jonglez wrote:
> Is there any chance to get this bug fixed in stretch?
>
> It's quite annoying when deploying Unix users with ansible, because the
> ansible module relies on useradd. As a result of this bug, new users have
> no defined shell.
>
> The upstream patch "Fix regression in useradd not loading defaults
> properly" is available here:
>
>
> https://github.com/shadow-maint/shadow/commit/507f96cdeb54079fb636c7ce21e371f7a16a520e.patch
>
> Thanks,
> Baptiste
diff -Nru shadow-4.4/debian/changelog shadow-4.4/debian/changelog
--- shadow-4.4/debian/changelog 2017-05-17 13:59:59.0 +0200
+++ shadow-4.4/debian/changelog 2017-08-31 10:47:16.0 +0200
@@ -1,3 +1,11 @@
+shadow (1:4.4-4.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix shell not being set by useradd.
+This is a regression in 4.4 already fixed upstream. (Closes: #865762)
+
+ -- Baptiste Jonglez Thu, 31 Aug 2017 10:47:16 +0200
+
shadow (1:4.4-4.1) unstable; urgency=high
* Non-maintainer upload.
diff -Nru shadow-4.4/debian/patches/0009-Fix-regression-in-useradd-not-loading-defaults.patch shadow-4.4/debian/patches/0009-Fix-regression-in-useradd-not-loading-defaults.patch
--- shadow-4.4/debian/patches/0009-Fix-regression-in-useradd-not-loading-defaults.patch 1970-01-01 01:00:00.0 +0100
+++ shadow-4.4/debian/patches/0009-Fix-regression-in-useradd-not-loading-defaults.patch 2017-08-31 10:47:16.0 +0200
@@ -0,0 +1,37 @@
+From 507f96cdeb54079fb636c7ce21e371f7a16a520e Mon Sep 17 00:00:00 2001
+From: Tomas Mraz
+Date: Thu, 25 Aug 2016 11:20:34 +0200
+Subject: [PATCH] Fix regression in useradd not loading defaults properly.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The get_defaults() has to be called before processing the flags.
+
+Signed-off-by: Tomáš Mráz
+---
+ src/useradd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/useradd.c b/src/useradd.c
+index fefa234c..6c43e7e3 100644
+--- a/src/useradd.c
b/src/useradd.c
+@@ -2027,6 +2027,8 @@ int main (int argc, char **argv)
+ is_shadow_grp = sgr_file_present ();
+ #endif
+
++ get_defaults ();
++
+ process_flags (argc, argv);
+
+ #ifdef ENABLE_SUBIDS
+@@ -2036,8 +2038,6 @@ int main (int argc, char **argv)
+ (!user_id || (user_id <= uid_max && user_id >= uid_min));
+ #endif/* ENABLE_SUBIDS */
+
+- get_defaults ();
+-
+ #ifdef ACCT_TOOLS_SETUID
+ #ifdef USE_PAM
+ {
diff -Nru shadow-4.4/debian/patches/series shadow-4.4/debian/patches/series
--- shadow-4.4/debian/patches/series 2017-05-17 13:59:59.0 +0200
+++ shadow-4.4/debian/patches/series 2017-08-31 10:47:16.0 +0200
@@ -28,3 +28,4 @@
501_commonio_group_shadow
# does not apply cleanly, please merge at upstream
1010_vietnamese_translation
+0009-Fix-regression-in-useradd-not-loading-defaults.patch
signature.asc
Description: PGP signature
Bug#873702: lintian: False positive: desktop-entry-lacks-keywords-entry
tags 873702 + pending thanks Fixed in Git: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=802e5b42ec94f0be27956cd01e1644dc2a800f87 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#873791: [python-numpy] Undefined symbols on several architectures
Got that error on amd64, too. This started today, after the upgrading python2.7 packages to 2.7.14~rc1 in sid. Downgrading back to buster's 2.7.13-2 solves the problem. Michal K.
Bug#873792: qjackctl will not start at all
Control: tags -1 + moreinfo On 2017-08-31 02:40:59, Ed Peguillan III wrote: > Package: qjackctl > Version: 0.4.5-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > >* What led up to the situation? >I use jackd to facilitate realtime audio according to my limits.conf >for some software called Pianoteq. In the last update, I tried to run >qjackctl and received the following error: > >qjackctl: symbol lookup error: >/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5: undefined symbol: >FT_Property_Set This looks like an old version of libfreetype.so.6 lying around somewhere in the library search path (e.g. /usr/local/lib). Could you please confirm that by running ldd -r /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 and checking where the used libfreetype.so.5 is coming from? Cheers >I am unable to start qjackctl > >* What exactly did you do (or not do) that was effective (or > ineffective)? > >I do not think I intentionally installed any extra packages that stops > qjackctl from launching properly. > >* What was the outcome of this action? >qjackctl does not launch > >* What outcome did you expect instead? >qjackctl launches normally > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (1000, 'testing'), (1000, 'stable'), (750, 'stable'), (50, > 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.12.0-1-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 qjackctl depends on: > ii jackd 5 > ii libasound21.1.3-5 > ii libc6 2.24-14 > ii libgcc1 1:7.2.0-1 > ii libjack-jackd2-0 [libjack-0.125] 1.9.10+20150825git1ed50c92~dfsg-5 > ii libqt5core5a 5.9.1+dfsg-9 > ii libqt5dbus5 5.9.1+dfsg-9 > ii libqt5gui55.9.1+dfsg-9 > ii libqt5widgets55.9.1+dfsg-9 > ii libqt5x11extras5 5.9.1-2+b1 > ii libqt5xml55.9.1+dfsg-9 > ii libstdc++67.2.0-1 > ii libx11-6 2:1.6.4-3 > > qjackctl recommends no packages. > > Versions of packages qjackctl suggests: > ii pulseaudio-utils 10.0-2 > > -- no debconf information > > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#873799: lightning: window too tall for typical screen when there are many attachments
Package: lightning Version: 1:52.2.1-4~deb9u1 When using a typical notebook computer - the one used by 92.5% of all DDs :~) - with 768px height, and an average sized font, important buttons of the event dialog window are not visible. The window cannot even be resized in height, only the width. Screenshot attached: The red line is my task bar, everything at this height or lower is not visible. Note, that there are some new small, mobile devices running Debian now. They might have even smaller screens. Please make the list of attachments, the list(s) of attendees, and the description field foldable/retractable. Thanks in advance!
Bug#869282: udev: Update breaks Keyboard Configuration
El 26/08/17 a las 10:35, Michael Biebl escribió: Can you run a git bisect to identify which commit in udev changed the behaviour? How can I do that? I have no knowlegde about "how to run a git bisect". Thanks! ;)
Bug#873702: lintian: False positive: desktop-entry-lacks-keywords-entry
Hi, thank you for the fix!
diff --git a/checks/menu-format.pm b/checks/menu-format.pm
index 3de4490..be1a1c4 100644
--- a/checks/menu-format.pm
+++ b/checks/menu-format.pm
@@ -641,7 +641,7 @@ sub verify_desktop_file {
if (!defined $vals{Icon}) {
tag 'desktop-entry-lacks-icon-entry', $file;
}
-if (!defined $vals{Keywords}) {
+if (!defined $vals{Keywords} && $vals{'Type'} ne 'Link') {
tag 'desktop-entry-lacks-keywords-entry', $file;
}
}
But if I understand the specification properly, the Keywords field is
forbidden not only for links (type 2 in the specification) but also for
directories (type 3). In general, this field is allowed for applications
(type 1). I therefore think the correct condition would be like the next.
if (!defined $vals{Keywords} && $vals{'Type'} eq 'Application') {
...
}
(I'm not familiar with Perl, and I don't know how it should look).
Bug#873702: lintian: False positive: desktop-entry-lacks-keywords-entry
Коля, > But if I understand the specification properly, the Keywords field is > forbidden not only for links (type 2 in the specification) but also for > directories (type 3). Ah, of course. Fixed with regression test in: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=907507fc9e300f6c63ec09c3047d9729eeeb7a20 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#873801: node-babel FTBFS without network access
Source: node-babel Version: 6.25.0+dfsg-1 Severity: serious Hi Maintainer Node-babel fails to build on a machine without external network access: ... npm install npm ERR! Linux 4.4.0-92-generic npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" npm ERR! node v6.11.2 npm ERR! npm v3.5.2 npm ERR! code ENOTFOUND npm ERR! errno ENOTFOUND npm ERR! syscall getaddrinfo npm ERR! network getaddrinfo ENOTFOUND registry.npmjs.org registry.npmjs.org:443 npm ERR! network This is most likely not a problem with npm itself npm ERR! network and is related to network connectivity. npm ERR! network In most cases you are behind a proxy or have bad network settings. npm ERR! network npm ERR! network If you are behind a proxy, please make sure that the npm ERR! network 'proxy' config is set properly. See: 'npm help config' npm ERR! Please include the following file with any support request: npm ERR! /<>/node-babel-6.25.0+dfsg/npm-debug.log Makefile:70: recipe for target 'bootstrap' failed make[2]: *** [bootstrap] Error 1 make[2]: Leaving directory '/<>/node-babel-6.25.0+dfsg' debian/rules:13: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>/node-babel-6.25.0+dfsg' debian/rules:10: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Regards Graham
Bug#873800: node-babylon FTBFS without network access
Source: node-babylon Version: 6.14.1-1 Severity: serious Hi Maintainer Node-babylon has a build dependency on nodejs-legacy which is no longer in the archive. With this dependency removed, the build fails on a machine without external network access: ... HOME=/tmp npm install babel-cli rollup rollup-plugin-babel \ rollup-plugin-node-resolve babel-plugin-transform-flow-strip-types \ babel-preset-es2015 babel-preset-stage-0 npm ERR! Linux 4.4.0-92-generic npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" "babel-cli" "rollup" "rollup-plugin-babel" "rollup-plugin-node-resolve" "babel-plugin-transform-flow-strip-types" "babel-preset-es2015" "babel-preset-stage-0" npm ERR! node v6.11.2 npm ERR! npm v3.5.2 npm ERR! code ENOTFOUND npm ERR! errno ENOTFOUND npm ERR! syscall getaddrinfo npm ERR! network getaddrinfo ENOTFOUND registry.npmjs.org registry.npmjs.org:443 npm ERR! network This is most likely not a problem with npm itself npm ERR! network and is related to network connectivity. npm ERR! network In most cases you are behind a proxy or have bad network settings. npm ERR! network npm ERR! network If you are behind a proxy, please make sure that the npm ERR! network 'proxy' config is set properly. See: 'npm help config' npm ERR! Please include the following file with any support request: npm ERR! /<>/npm-debug.log debian/rules:11: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' debian/rules:8: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Regards Graham
Bug#873486: fcitx can not be start after upgrade to Debian buster
Hello, everyone. I find that the Debian must be restart (not shut down and turn on) several times, it maybe work. The other strange things are like the fcitx. Best regards Gulfstream 在 2017年08月28日 18:32, Shengjing Zhu 写道: Control: tags -1 moreinfo Please run fcitx-diagnose and paste the result here. Thanks On Mon, Aug 28, 2017 at 5:51 PM, gulfstream wrote: Package: fcitx Version: 1:4.2.9.1-6 Severity: grave Hi! I upgraded my Debian to buster yesterday. Then the fcitx can not be used now. When I run it, the messages are get as blew: wgl@athena:~$ fcitx wgl@athena:~$ (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-autoeng.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-chttrans.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-clipboard.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-fullwidth-char.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-imselector.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-keyboard.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-punc.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-quickphrase.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-remote-module.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-spell.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-unicode.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-dbus.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-freedesktop-notify.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-ipc.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-googlepinyin.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-kimpanel-ui.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-lua.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-vk.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-x11.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-xim.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-xkb.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-xkbdbus.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-pinyin-enhance.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-pinyin.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-sunpinyin.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-table.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-classic-ui.conf (INFO-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/addon.c:151) Load Addon ConfigFile:fcitx-notificationitem.conf (ERROR-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/lib/fcitx/ime.c:432) fcitx-keyboard-cm-mmuock already exists (WARN-6096 /build/fcitx-SJV5lg/fcitx-4.2.9.1/src/frontend/xim/xim.c:161) Please set XMODIFIERS. The fcitx works fine when the Debian is stretch before I upgrade to buster. Could you resolve this problem? Thank you very much! Best regards, Gulfstream -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fcitx depends on: ii fcitx-bin 1:4.2.9.1-6 ii fcitx-data 1:4.2.9.1-6 ii fcitx-modules 1:4.2.9.1-6 Versions of packages fcitx recommends: ii fcitx-config-gtk 0.4.8-3+b1 ii fcitx-frontend-all 1:4.2.9.1-6 ii fcitx-ui-classic 1:4.2.9.1-6 ii im-config [im-switch] 0.30-1 Versions of packages fcitx suggests: pn fcitx-m17n pn fcitx-tools -- no debconf information ___
Bug#873796: evolution: FTBFS when building only Architecture: all
On Thu, 31 Aug 2017 at 09:37:52 +0100, Simon McVittie wrote: > The two find calls in debian/libevolution/ need to be skipped when that > directory does not exist, i.e. when not building architecture-specific > binary packages. I'm testing the attached patch, which I hope will > address this. It seems to work. Here is an updated patch including the bug number; please upload as soon as is convenient, so that evolution will be installable again. (I don't intend to NMU this.) S Index: debian/changelog === --- debian/changelog (revision 3195) +++ debian/changelog (working copy) @@ -1,3 +1,12 @@ +evolution (3.24.5-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do not try to delete bogofilter, spamassassin modules from +libevolution if only building for Architecture: all, fixing FTBFS +(Closes: #873796) + + -- Simon McVittie Thu, 31 Aug 2017 09:30:03 +0100 + evolution (3.24.5-2) unstable; urgency=medium * Upload to unstable (Closes: #871626) Index: debian/rules === --- debian/rules (revision 3195) +++ debian/rules (working copy) @@ -39,8 +39,10 @@ override_dh_install: dh_install --fail-missing -X.la -Xlibevolutiontestsettings.so \ -Xusr/lib/evolution/installed-tests -Xusr/share/installed-tests +ifneq ($(filter libevolution,$(shell dh_listpackages)),) find debian/libevolution/ -name 'module-bogofilter.so' -delete find debian/libevolution/ -name 'module-spamassassin.so' -delete +endif override_dh_makeshlibs: dh_makeshlibs -V'libevolution (>= $(DEB_VERSION_UPSTREAM)), libevolution (<< $(DEB_GNOME_NEXTVERSION))' -n
Bug#873802: Multiple vulnerabilities in rubygems (CVE-2017-0899 to CVE-2017-0902)
Source: ruby2.3 X-Debbugs-CC: t...@security.debian.org secure-testing-t...@lists.alioth.debian.org Severity: important Tags: security Hi, the following vulnerabilities were published for ruby2.3. They affect rubygems more specifically. CVE-2017-0902[0]: DNS issue CVE-2017-0901[1]: overwrite any file CVE-2017-0900[2]: query command CVE-2017-0899[3]: ANSI escape issue Some patches are available here: https://www.ruby-lang.org/en/news/2017/08/29/multiple-vulnerabilities-in-rubygems/ The fixes should also be available in (upcoming) ruby 2.3.5 and ruby 2.4.2. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-0902 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0902 [1] https://security-tracker.debian.org/tracker/CVE-2017-0901 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0901 [2] https://security-tracker.debian.org/tracker/CVE-2017-0900 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0900 [3] https://security-tracker.debian.org/tracker/CVE-2017-0899 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0899 Please adjust the affected versions in the BTS as needed. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#873791: [python-numpy] Undefined symbols on several architectures
Control: reassign -1 python2.7 2.7.14~rc1-1 Control: retitle -1 python2.7: fpectl extension removal broke the ABI for C extensions Control: affects -1 python-numpy On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote: > Got that error on amd64, too. > > This started today, after the upgrading python2.7 packages to 2.7.14~rc1 > in sid. Downgrading back to buster's 2.7.13-2 solves the problem. I got the same error with Cython: ImportError: /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf. You should look at http://www.cython.org"; It seems the following change in 2.7.14~rc1-1 broke the ABI: * Stop building the fpectl extension. > Michal K. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#873797: missing fping6 breaks smokeping slaves on older systems
Hi Sven, Sven Hartge wrote: > The change to remove the fping6 binary breaks smokeping slaves on > older Debian systems (and other distributions) for me. Ah, I see. I only have several independent Smokeping installations and haven't found time to dig into how Smokeping slaves work. And in that setup I only had to change self-written parts of the configuration to cope with that change. So thanks for making me aware of that issue. > I think you need to provide this compatibility symlink in the package > for at least the Buster release cycle, maybe even for the one after that > so that scripts and multi-server environments can be migrated. Yes, I fear so, as I don't see any other possibility at the moment, either. I though will have to think about how to actually implement this. Maybe as additional binary package "fping6" which only needs to be installed if Smokeping has older slaves. At least I would provide a specific fping6 man page with not much more than a deprecation warning. And an extended NEWS.Debian file. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#873803: keepalived: Enable DBus support
Package: keepalived Version: 1:1.3.2-1 Severity: normal Tags: patch Dear Maintainer, with version 1.3.0 upstream introduced a DBus interface to control and query the daemon. I attached a patch to enable this interface in the Debian version of keepalived. Best regards, Sebastian --- a/debian/control2016-12-03 21:18:05.0 + +++ b/debian/control2017-08-31 09:57:53.911807795 + @@ -5,6 +5,7 @@ Build-Depends: autoconf, debhelper (>= 9), dh-systemd (>= 1.3), + libglib2.0-dev, libnl-3-dev, libnl-genl-3-dev, libpopt-dev, --- a/debian/rules 2016-12-03 21:18:05.0 + +++ b/debian/rules 2017-08-31 09:52:30.445349800 + @@ -7,7 +7,7 @@ dh $@ --with autoreconf --with=systemd override_dh_auto_configure: - dh_auto_configure -- --with-kernel-dir=debian/ --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 + dh_auto_configure -- --with-kernel-dir=debian/ --enable-dbus --enable-dbus-create-instance --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 override_dh_auto_install:
Bug#873804: CVE-2017-11541
Package: tcpdump X-Debbugs-CC: t...@security.debian.org secure-testing-t...@lists.alioth.debian.org Severity: important Tags: security Hi, the following vulnerability was published for tcpdump. CVE-2017-11541[0]: | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print | function in print-lldp.c, related to util-print.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11541 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541 Please adjust the affected versions in the BTS as needed.
Bug#873805: CVE-2017-11542
Package: tcpdump X-Debbugs-CC: t...@security.debian.org secure-testing-t...@lists.alioth.debian.org Severity: important Tags: security Hi, the following vulnerability was published for tcpdump. CVE-2017-11541[0]: | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print | function in print-lldp.c, related to util-print.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11541 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541 Please adjust the affected versions in the BTS as needed.
Bug#873806: CVE-2017-11543
Package: tcpdump X-Debbugs-CC: t...@security.debian.org secure-testing-t...@lists.alioth.debian.org Severity: important Tags: security Hi, the following vulnerability was published for tcpdump. CVE-2017-11541[0]: | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print | function in print-lldp.c, related to util-print.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11541 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541 Please adjust the affected versions in the BTS as needed. Note that I've not been able to reproduce the vulnerability with the pcap file provided at https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/global-overflow/print-sl but given this has a CVE I figured it's safer to bring this to your attention anyway.
Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings
An updated copy of ddcutil has been uploaded to mentors reflecting Andrey's review. Comments interspersed. On 08/20/2017 12:02 PM, Andrey Rahmatullin wrote: The package FTBFS: dh_install dh_install: Cannot find (any matches for) "/usr/bin" (tried in ., debian/tmp) dh_install: ddcutil missing files: /usr/bin dh_install: Cannot find (any matches for) "/usr/share/man" (tried in ., debian/tmp) dh_install: ddcutil missing files: /usr/share/man dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*rules" (tried in ., debian/tmp) dh_install: ddcutil missing files: /usr/share/ddcutil/data/*rules dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*conf" (tried in ., debian/tmp) dh_install: ddcutil missing files: /usr/share/ddcutil/data/*conf dh_install: missing files, aborting debian/rules:9: recipe for target 'binary' failed Fixed. Deleted file debian/ddcutil.install Please run lintian (with -EI --pedantic and against the binary .changes) and review its output. After executing pdebuild on buster for distribution buster, the lintian output is as follows: W: ddcutil source: newer-standards-version 4.1.0 (current is 4.0.0) See below. I: ddcutil source: testsuite-autopkgtest-missing ddcutil has no test suite. P: ddcutil source: debian-watch-may-check-gpg-signature There is no signature checking. Simply put I haven't been able to get it to work. P: ddcutil: no-upstream-changelog To be added in a future point release and installed in /usr/share/doc/ddcutil. However, in the spirit of DRY entries will basically just point to the web site for detail. W: ddcutil: new-package-should-close-itp-bug Should a mentors upload close the ITP bug? Please update to the current Standards-Version (you've missed that in the previous review). Was at 3.9.8, the highest version recognized by lintian in mentors. I've now changed it to 4.1.0, the version in the 2017-08-21 policy manual. Of course, this means that no release of lintian I've yet encountered recognizes the version. The first line of License: GPL-2.0+ block in d/copyright contradicts everything else (and is not actually needed). First line deleted. Why do you need DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk ? Historic cruft. Deleted. Vcs-* don't point to the packaging repo. Now we come to what I think is a substantive issue. The Vcs-* entries pointed to the upstream repository. Though it wasn't clear from the policy manual, I gather from your comment that the Vcs-* entries need to point to a debianized repository. There currently is no such repository. Trying to support the increasing number of variants for dpkg and rpm packaging in the upstream repository under autotools became an unwieldy mess. It is being factored out. The role of the upstream repo is simply to produce a distribution agnostic tarball. Accordingly, I have deleted the Vcs-* entries. The tarballs produced by upstream are published at http://www.ddcutil.com/releases/, and the watch file has been changed to point to that page instead of the git repository. Are tarballs sufficient or is a debianized repo required? Page https://wiki.debian.org/PackagingWithGit#pbuilder describes a process for maintaining one. Is this the proper method?
Bug#873791: [python-numpy] Undefined symbols on several architectures
On 31.08.2017 12:35, Adrian Bunk wrote: > Control: reassign -1 python2.7 2.7.14~rc1-1 > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for C > extensions > Control: affects -1 python-numpy > > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote: >> Got that error on amd64, too. >> >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1 >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem. > > I got the same error with Cython: > > ImportError: > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so: > undefined symbol: PyFPE_jbuf. You should look at http://www.cython.org"; > > It seems the following change in 2.7.14~rc1-1 broke the ABI: > * Stop building the fpectl extension. yes, that's intended. I'll add a break. Are there other known packages besides python-numpy?
Bug#873807: ssh-askpass FTCBFS: xmkmf is unfixable
Source: ssh-askpass Version: 1:1.2.4.1-9 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap Control: block 873764 by -1 ssh-askpass fails to cross build from source, because ... it uses xmkmf. I looked at xmkmf hard and there seems to be no way to make this work at all. I talked to vorlon, and we agreed that xmkmf should just die (#873764). As such I am asking you to migrate away from xmkmf. I am attaching a patch moves to autoconf in a minimal way that makes the binary package look mostly equal to the original package (according to diffoscope). Oh and the patch makes cross building work. Can you apply it? Or at least, can you remove xmkmf usage? Helmut diff --minimal -Nru ssh-askpass-1.2.4.1/debian/changelog ssh-askpass-1.2.4.1/debian/changelog --- ssh-askpass-1.2.4.1/debian/changelog2009-11-23 03:09:59.0 +0100 +++ ssh-askpass-1.2.4.1/debian/changelog2017-08-30 19:28:49.0 +0200 @@ -1,3 +1,10 @@ +ssh-askpass (1:1.2.4.1-9.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Rewrite build system as autoconf (Closes: #-1) + + -- Helmut Grohne Wed, 30 Aug 2017 19:28:49 +0200 + ssh-askpass (1:1.2.4.1-9) unstable; urgency=low * switch to 3.0 (quilt) source format diff --minimal -Nru ssh-askpass-1.2.4.1/debian/control ssh-askpass-1.2.4.1/debian/control --- ssh-askpass-1.2.4.1/debian/control 2009-11-23 02:05:03.0 +0100 +++ ssh-askpass-1.2.4.1/debian/control 2017-08-30 19:28:49.0 +0200 @@ -2,7 +2,7 @@ Section: net Priority: optional Maintainer: Philip Hands -Build-Depends: debhelper (>= 7.0.50~), autotools-dev, libx11-dev, libxt-dev, x11proto-core-dev, xutils-dev +Build-Depends: debhelper (>= 7.0.50~), autotools-dev, libx11-dev, libxt-dev, x11proto-core-dev, dh-autoreconf, pkg-config Standards-Version: 3.8.3 Homepage: http://www.jmknoble.net/software/x11-ssh-askpass/ diff --minimal -Nru ssh-askpass-1.2.4.1/debian/patches/autotools.patch ssh-askpass-1.2.4.1/debian/patches/autotools.patch --- ssh-askpass-1.2.4.1/debian/patches/autotools.patch 1970-01-01 01:00:00.0 +0100 +++ ssh-askpass-1.2.4.1/debian/patches/autotools.patch 2017-08-30 19:28:49.0 +0200 @@ -0,0 +1,49 @@ +Index: ssh-askpass-1.2.4.1/Makefile.am +=== +--- /dev/null ssh-askpass-1.2.4.1/Makefile.am +@@ -0,0 +1,16 @@ ++libexec_PROGRAMS = x11-ssh-askpass ++x11_ssh_askpass_SOURCES = drawing.c dynlist.c resources.c x11-ssh-askpass.c ++nodist_x11_ssh_askpass_SOURCES = SshAskpass_ad.h ++x11_ssh_askpass_CFLAGS = $(X11_CFLAGS) $(XT_CFLAGS) $(SM_CFLAGS) $(ICE_CFLAGS) ++x11_ssh_askpass_LDADD = $(X11_LIBS) $(XT_LIBS) $(SM_LIBS) $(ICE_LIBS) ++askpassconfdir = $(sysconfdir)/X11/app-defaults ++askpassconf_DATA = SshAskpass ++CLEANFILES = SshAskpass_ad.h x11-ssh-askpass.1x SshAskpass ++man1_MANS = x11-ssh-askpass.1x ++BUILT_SOURCES = SshAskpass_ad.h x11-ssh-askpass.1x ++SshAskpass_ad.h:SshAskpass-default.ad ++ sed -n '/^[^!]/s/.*/"&",/p' <$< >$@ ++x11-ssh-askpass.1x:x11-ssh-askpass.man ++ cp $< $@ ++SshAskpass:SshAskpass-default.ad ++ cp $< $@ +Index: ssh-askpass-1.2.4.1/configure.ac +=== +--- /dev/null ssh-askpass-1.2.4.1/configure.ac +@@ -0,0 +1,10 @@ ++AC_INIT([ssh-askpass],[1.2.4.1],[jmkno...@pobox.com]) ++AM_INIT_AUTOMAKE([foreign]) ++AC_PROG_CC ++PKG_CHECK_MODULES([X11],[x11]) ++PKG_CHECK_MODULES([XT],[xt]) ++PKG_CHECK_MODULES([SM],[sm]) ++PKG_CHECK_MODULES([ICE],[ice]) ++AC_SUBST(NAME,[x11-ssh-askpass]) ++AC_CONFIG_FILES([Makefile x11-ssh-askpass.man]) ++AC_OUTPUT() +Index: ssh-askpass-1.2.4.1/x11-ssh-askpass.man.in +=== +--- ssh-askpass-1.2.4.1.orig/x11-ssh-askpass.man.in ssh-askpass-1.2.4.1/x11-ssh-askpass.man.in +@@ -3,7 +3,7 @@ + .\" Modified by Jim Knoble for non-OpenBSD + .\" distribution + .\" +-.Dd @DATE@ ++.Dd September 17, 2001 + .Dt @NAME@ 1 + .Os "Version @VERSION@" + .Sh NAME diff --minimal -Nru ssh-askpass-1.2.4.1/debian/patches/series ssh-askpass-1.2.4.1/debian/patches/series --- ssh-askpass-1.2.4.1/debian/patches/series 2009-11-23 02:35:55.0 +0100 +++ ssh-askpass-1.2.4.1/debian/patches/series 2017-08-30 19:28:49.0 +0200 @@ -1,2 +1,3 @@ debian_paths debian_cflags +autotools.patch diff --minimal -Nru ssh-askpass-1.2.4.1/debian/rules ssh-askpass-1.2.4.1/debian/rules --- ssh-askpass-1.2.4.1/debian/rules2009-11-23 02:05:03.0 +0100 +++ ssh-askpass-1.2.4.1/debian/rules2017-08-30 19:28:49.0 +0200 @@ -4,21 +4,7 @@ export DH_VERBOSE=1 %: - dh $@ - -override_dh_auto_clean: - dh_auto_clean - rm -f SshAskpass.ad + dh $@ --with=autoreconf override_dh_auto_configure: dh_auto_configure -- --libexecdir=/usr/lib/ssh - -override_dh_auto_build: - xmkmf - $(MAKE) includes - $(MAKE) - -override_dh_auto_install: - $
Bug#873805: CVE-2017-11542
Hi, On Thu, Aug 31, 2017 at 12:39:33PM +0200, Guido Günther wrote: > Package: tcpdump > X-Debbugs-CC: t...@security.debian.org > secure-testing-t...@lists.alioth.debian.org > Severity: important > Tags: security > > Hi, > > the following vulnerability was published for tcpdump. > > CVE-2017-11541[0]: > | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print > | function in print-lldp.c, related to util-print.c. I've sent the attached patch upstream. I'd like to incorporate this into an upload to wheezy at one point. Shall I handle sid, stretch or jessie as well? Given the impact of the issue an update to stretch and jessie is probably more suitable for a point release (which wheezy does not have). Cheers, -- Guido From: =?utf-8?q?Guido_G=C3=BCnther?= Date: Mon, 28 Aug 2017 19:22:27 +0200 Subject: CVE-2017-11542: pimv1_print: prevent out of bounds read In case of an invalid type there's no bounds check when parsing the version field. Add this unconditionally. This fixes CVE-2017-11542 with the testcase from https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/heap-buffer-overflow/print-pim while https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=IGMP+dataset.pcap still passes --- print-pim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/print-pim.c b/print-pim.c index 2552595..674dddb 100644 --- a/print-pim.c +++ b/print-pim.c @@ -306,7 +306,7 @@ pimv1_print(netdissect_options *ndo, pimv1_join_prune_print(ndo, &bp[8], len - 8); break; } - if ((bp[4] >> 4) != 1) + if (ND_TTEST(bp[4]) && (bp[4] >> 4) != 1) ND_PRINT((ndo, " [v%d]", bp[4] >> 4)); return;
Bug#873804: CVE-2017-11541
Hi,
On Thu, Aug 31, 2017 at 12:39:17PM +0200, Guido Günther wrote:
> Package: tcpdump
> X-Debbugs-CC: t...@security.debian.org
> secure-testing-t...@lists.alioth.debian.org
> Severity: important
> Tags: security
>
> Hi,
>
> the following vulnerability was published for tcpdump.
>
> CVE-2017-11541[0]:
> | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
> | function in print-lldp.c, related to util-print.c.
I've sent the attached patch upstream. I'd like to incorporate this into
an upload to wheezy at one point. Shall I handle sid, stretch or jessie
as well? Given the impact of the issue an update to stretch and jessie
is probably more suitable for a point release (which wheezy does not have).
Cheers,
-- Guido
From: =?utf-8?q?Guido_G=C3=BCnther?=
Date: Mon, 28 Aug 2017 18:53:20 +0200
Subject: CVE-2017-11541: safeputs: check length first
Put the lenght check before accessing s since we might otherwise
read from a memory area we're not supposed to read.
Addresses CVE-2017-11541 with the testcase from
https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/heap-buffer-overflow/util-print
---
util-print.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util-print.c b/util-print.c
index 5db042a..34fc2e0 100644
--- a/util-print.c
+++ b/util-print.c
@@ -902,7 +902,7 @@ safeputs(netdissect_options *ndo,
{
u_int idx = 0;
- while (*s && idx < maxlen) {
+ while (idx < maxlen && *s) {
safeputchar(ndo, *s);
idx++;
s++;
Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings
On Thu, Aug 31, 2017 at 06:43:45AM -0400, Sanford Rockowitz wrote: > > Please run lintian (with -EI --pedantic and against the binary .changes) > > and review its output. > After executing pdebuild on buster for distribution buster You should build your packages on sid and test them on sid. > W: ddcutil: new-package-should-close-itp-bug > >Should a mentors upload close the ITP bug? You don't write a separate changelog entry for a mentors "upload". > > Please update to the current Standards-Version (you've missed that in the > > previous review). > Was at 3.9.8, the highest version recognized by lintian in mentors. I've > now changed it to 4.1.0, the version in the 2017-08-21 policy manual. Of > course, this means that no release of lintian I've yet encountered > recognizes the version. Yes, the policy version should be used. > > Vcs-* don't point to the packaging repo. > Now we come to what I think is a substantive issue. The Vcs-* entries > pointed to the upstream repository. Though it wasn't clear from the policy > manual, I gather from your comment that the Vcs-* entries need to point to a > debianized repository. The policy says "a publicly accessible repository where the Debian source package is developed". > There currently is no such repository. Then there should be no Vcs-* fields. > Trying to support the increasing number of variants for dpkg and rpm > packaging in the upstream repository under autotools became an unwieldy > mess. Sure, that's why it should be a separate repo or a separate branch (it's automatical when the package is not the upstream). > Are tarballs sufficient or is a debianized repo required? Page > https://wiki.debian.org/PackagingWithGit#pbuilder describes a process for > maintaining one. Is this the proper method? No repos are required, though they may be useful. Please remove --with autotools-dev lines from d/rules. You should not delete all COPYING files in dh_auto_install, especially not those in the upstream source. If you don't want some files to be packaged, delete them explicitly with rm(1) and full paths. -- WBR, wRAR signature.asc Description: PGP signature
Bug#873797: missing fping6 breaks smokeping slaves on older systems
On 31.08.2017 12:34, Axel Beckert wrote: > I though will have to think about how to actually implement this. > Maybe as additional binary package "fping6" which only needs to be > installed if Smokeping has older slaves. Why not just provide the symlink I mentioned in the fping package? It will allow older scripts to continue working and the only "downside" I can see from this is that "fping6" will suddenly also work for IPv4 hosts. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#873808: clementine: Segmentation fault while starting
Package: clementine Version: 1.3.1+git276-g3485bbe43+dfsg-1 Severity: grave Justification: renders package unusable Cause: It is happening because clementine is not compatible with the new qt4libs that are present in experimental repository Console output: 10: 13:30.674 WARN unknown QSslSocket: cannot resolve CRYPTO_num_locks 10: 13:30.677 WARN unknown QSslSocket: cannot resolve CRYPTO_set_id_callback 10: 13:30.677 WARN unknown QSslSocket: cannot resolve CRYPTO_set_locking_callback 10: 13:30.677 WARN unknown QSslSocket: cannot resolve sk_free 10: 13:30.678 WARN unknown QSslSocket: cannot resolve sk_num 10: 13:30.678 WARN unknown QSslSocket: cannot resolve sk_pop_free 10: 13:30.678 WARN unknown QSslSocket: cannot resolve sk_value 10: 13:30.678 WARN unknown QSslSocket: cannot resolve SSL_library_init 10: 13:30.678 WARN unknown QSslSocket: cannot resolve SSL_load_error_strings 10: 13:30.678 WARN unknown QSslSocket: cannot resolve X509_get_notAfter 10: 13:30.678 WARN unknown QSslSocket: cannot resolve X509_get_notBefore 10: 13:30.678 WARN unknown QSslSocket: cannot resolve SSLv2_client_method 10: 13:30.679 WARN unknown QSslSocket: cannot resolve SSLv23_client_method 10: 13:30.687 WARN unknown QSslSocket: cannot resolve SSLv2_server_method 10: 13:30.687 WARN unknown QSslSocket: cannot resolve SSLv23_server_method 10: 13:30.687 WARN unknown QSslSocket: cannot resolve X509_STORE_CTX_get_chain 10: 13:30.687 WARN unknown QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf 10: 13:30.687 WARN unknown QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf 10: 13:30.687 WARN unknown QSslSocket: cannot resolve SSLeay 10: 13:30.688 WARN unknown QSslSocket: cannot call unresolved function SSL_library_init 10: 13:30.690 WARN unknown QSslSocket: cannot call unresolved function SSLv23_client_method 10: 13:30.691 WARN unknown QSslSocket: cannot call unresolved function sk_num 10: 13:30.691 WARN unknown QSslSocket: cannot call unresolved function X509_get_notBefore 10: 13:30.691 WARN unknown QSslSocket: cannot call unresolved function X509_get_notAfter -- 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.13.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clementine depends on: ii gstreamer1.0-plugins-base 1.12.2-1 ii gstreamer1.0-plugins-good 1.12.2-1 ii gstreamer1.0-plugins-ugly 1:1.12.2-dmo2 ii libc6 2.25-0experimental3 ii libcdio13 0.83-4.3+b1 ii libchromaprint1 1:1.4.2-dmo1 ii libcrypto++65.6.4-8 ii libfftw3-double33.3.6p2-2 ii libgcc1 1:7.2.0-2 ii libgdk-pixbuf2.0-0 2.36.5-3 ii libglib2.0-02.53.6-1 ii libgpod40.8.3-8.2 ii libgstreamer-plugins-base1.0-0 1.12.2-1 ii libgstreamer1.0-0 1.12.2-1 ii libimobiledevice6 1.2.0+dfsg-3.1 ii liblastfm1 1.0.9-1 ii libmtp9 1.1.13-1 ii libmygpo-qt11.0.9-2 ii libplist3 2.0.0-2 ii libprojectm2v5 2.1.0+dfsg-4+b3 ii libprotobuf10 3.0.0-9 ii libpulse0 10.99.1-1 ii libqjson0 0.8.1-3+b1 ii libqt4-dbus 4:4.8.7+dfsg-12 ii libqt4-network 4:4.8.7+dfsg-12 ii libqt4-opengl 4:4.8.7+dfsg-12 ii libqt4-sql 4:4.8.7+dfsg-12 ii libqt4-sql-sqlite 4:4.8.7+dfsg-12 ii libqt4-xml 4:4.8.7+dfsg-12 ii libqtcore4 4:4.8.7+dfsg-12 ii libqtgui4 4:4.8.7+dfsg-12 ii libqxt-gui0 0.6.2-3 ii libsqlite3-03.20.1-1 ii libstdc++6 7.2.0-2 ii libtag1v5 1.11.1+dfsg.1-0.1 ii libx11-62:1.6.4-3 ii projectm-data 2.1.0+dfsg-4 ii zlib1g
Bug#873797: missing fping6 breaks smokeping slaves on older systems
Hi Sven, Sven Hartge wrote: > On 31.08.2017 12:34, Axel Beckert wrote: > > I though will have to think about how to actually implement this. > > Maybe as additional binary package "fping6" which only needs to be > > installed if Smokeping has older slaves. > > Why not just provide the symlink I mentioned in the fping package? I would like to avoid that people continue to use fping6 just because it's there. > It will allow older scripts to continue working and the only > "downside" I can see from this is that "fping6" will suddenly also > work for IPv4 hosts. That's no downside for me. :-) >From my point of view the main downside is that people won't notice that it's gone (despite NEWS.Debian, changelog.Debian.gz, etc.) and will continue to use it. But then again, you're right: As soon as even oldoldstable has an fping which works for both, IPv4 and IPv6, it doesn't hurt that the /usr/bin/fping6 symlink is still there. They will notice at latest when we make a Debian release where the symlink is dropped and by then they should be able to even switch their oldstable and oldoldstable systems to use just /usr/bin/fping and it's fine. So I'll probably just re-add that symlink plus an according man page and NEWS.Debian entry and that's it. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#871348: robocode FTBFS
I believe Robocode is just affected by the ongoing Maven 3 transition. The error message indicates some kind of problem with plexus-utils which is outdated and does not ship the MatchPatterns class. I'm not sure how this is all related to the maven-dependency-plugin but maybe an upgrade to the latest upstream release of plexus-utils will resolve #871348 ? signature.asc Description: OpenPGP digital signature
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Dear Maintainer, Is it time to upload backports of 0.2.7-3 to stretch? I'm also wondering why it didn't hit testing yet. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#873804: CVE-2017-11541
Hi, On Thu, Aug 31, 2017 at 12:52:12PM +0200, Guido Günther wrote: > I've sent the attached patch upstream. I'd like to incorporate this into > an upload to wheezy at one point. Shall I handle sid, stretch or jessie > as well? No, thank you. This vulnerability and the others have already been fixed upstream for some time and an upcoming upstream version will include the fixes. We're just waiting for upstream to lift the embargo... -- Romain Francoise https://people.debian.org/~rfrancoise/
Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> I guess that one could do something like moving the symlink into another
> -legasy style package, and recomend that from the main package for one
> release to keep upgrades happy. Then drop the recomendation, and wait
> for popcon to show that people are not installing the package any more.
> Then remove the package in testing early in a cycle and see if anyone
> reports bugs about it.
Even that would be quite unfriendly, because third party scripts might
easily be deployed onto new Debian installs as well as existing ones.
Also, it is imposing an administrative burden on all Debian users (the
metadata for the -legacy package, spurious search hits, etc.). That
burden might be small but would be completely unjustified.
Ian.
Bug#857010: Non-threadsafe local imports
Control: tags -1 + moreinfo On 07.03.2017 07:22, martin f krafft wrote: > Package: python3.6 > Version: 3.6.0-1 > Severity: normal > > Please see > https://github.com/pimutils/vdirsyncer/issues/583 for a bug that has > a hacky patch, and can only be reproduced with Debian's Python > 3.6.0. Using upstream 3.6.0 works just fine. > > In short: if more than one thread are importing a module from within > a function body, there seems to be a race condition and one thread > will throw an exception about being unable to load the name. despite the comment/rant in this upstream report, the Debian package doesn't have any extra changes in this area. A self contained test case would be good to have. Also you might check against 3.6.2 as well.
Bug#873809: Packaging newer upstreams
Package: minetest-mod-worldedit Version: 0.6-1 Severity: wishlist Hi, version 1.0 is out since 20130822, and I asked upstream to tag new releases, so probably a new one will appear quite soon. I'm ready to help if it is needed. Thanks, Snark on #debian-games
Bug#873804: CVE-2017-11541
Hi Romain, Thanks for the prompt reply! On Thu, Aug 31, 2017 at 01:16:35PM +0200, Romain Francoise wrote: > Hi, > > On Thu, Aug 31, 2017 at 12:52:12PM +0200, Guido Günther wrote: > > I've sent the attached patch upstream. I'd like to incorporate this into > > an upload to wheezy at one point. Shall I handle sid, stretch or jessie > > as well? > > No, thank you. This vulnerability and the others have already been fixed > upstream for some time and an upcoming upstream version will include the > fixes. We're just waiting for upstream to lift the embargo... O.k. Any idea when upstream will do this? Cheers, -- Guido
Bug#842375: python-3.6.pc: Dash (-) in the .pc file name
Control: tags -1 + wontfix this is the name used by upstream. Please use it as it is shipped.
Bug#351995: disagree: ssmtp is simple submission server
On Fri, 8 Jun 2007 10:05:55 +0200 Matus UHLAR - fantomas wrote: > I disagree: ssmtp is very simple mail _submission_ program, which shouldn't > take care of delivery in any way. That should be left up to the mailserver > specified in config file. The MX records are used for final delivering of > mail, which is not ssmtp's business. I concur. ssmtp is merely glue that avoids talking to port 25 using telnet by hand. This feature request should be delegated to WONTFIX.
Bug#873405: Please update to llvm-toolchain 4.0 or, better, 5.0
Hello, Lumin, on lun. 28 août 2017 04:48:16 +, wrote: > Clang-3.9 is now suffering from the GCC-7 headers as shown at bottom. FI, I managed to avoid the issue by making clang use libc++-dev: > ❯❯❯ nvcc -ccbin clang++-3.9 matrixMul.cu -I../../common/inc >Mon 28 Aug 2017 04:36:32 AM UTC > /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/std_abs.h(101): > error: identifier "__float128" is undefined nvcc -ccbin clang++-3.9 -Xcompiler -stdlib=libc++ test.cu -o test Samuel
Bug#866633: bijiben: depends on libwebkitgtk-3.0-0 which is deprecated
Hi, Any objections to me NMUing the update the 3.24 to fix this RC bug? Also, we are planning to do the tracker2 transition soon which will need a sourceful upload. Can we take care of that too? Thanks, Jeremy Bicha
Bug#873405: Please update to llvm-toolchain 4.0 or, better, 5.0
Samuel Thibault, on jeu. 31 août 2017 13:28:14 +0200, wrote: > Lumin, on lun. 28 août 2017 04:48:16 +, wrote: > > Clang-3.9 is now suffering from the GCC-7 headers as shown at bottom. > > FI, I managed to avoid the issue by making clang use libc++-dev: > > > ❯❯❯ nvcc -ccbin clang++-3.9 matrixMul.cu -I../../common/inc > >Mon 28 Aug 2017 04:36:32 AM UTC > > /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/std_abs.h(101): > > error: identifier "__float128" is undefined > > nvcc -ccbin clang++-3.9 -Xcompiler -stdlib=libc++ test.cu -o test Ah, but depending on the clang version vs libc++-dev version, there might be conflicts too. It'd mean a version of libc++-dev compatible with clang-3.9 would need to be kept. Samuel
Bug#873810: lrzsz FTCBFS: debian/rules thinks so
Source: lrzsz Version: 0.12.21-8 Tags: patch User: helm...@debian.org Usertags: rebootstrap lrzsz fails to cross build from source, because debian/rules errors out immediately. On a closer look, the statement that this doesn't work is wrong. The attached patch demonstrates that lrzsz can be cross built quite easily. Please consider applying it. Helmut diff --minimal -Nru lrzsz-0.12.21/debian/changelog lrzsz-0.12.21/debian/changelog --- lrzsz-0.12.21/debian/changelog 2015-06-07 18:43:36.0 +0200 +++ lrzsz-0.12.21/debian/changelog 2017-08-31 13:30:55.0 +0200 @@ -1,3 +1,10 @@ +lrzsz (0.12.21-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Make cross compilation work, closes: #-1. + + -- Helmut Grohne Thu, 31 Aug 2017 13:30:55 +0200 + lrzsz (0.12.21-8) unstable; urgency=low * Fixed reproducible builds, closes: #787995, thanks to Dhole. diff --minimal -Nru lrzsz-0.12.21/debian/rules lrzsz-0.12.21/debian/rules --- lrzsz-0.12.21/debian/rules 2015-06-07 18:41:36.0 +0200 +++ lrzsz-0.12.21/debian/rules 2017-08-31 13:30:55.0 +0200 @@ -3,12 +3,12 @@ testdir = test -f src/lrz.c && test -f debian/rules testroot = test x`whoami` = xroot -# FOR AUTOCONF 2.13 ONLY -ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) - confflags += $(DEB_HOST_GNU_TYPE) -else - $(error Cannot cross-compile this package out-of-the-box) +include /usr/share/dpkg/architecture.mk + +ifeq ($(origin CC),default) +CC = $(DEB_HOST_GNU_TYPE)-gcc endif +export CC CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS) CFLAGS = $(shell dpkg-buildflags --get CFLAGS) @@ -53,7 +53,7 @@ $(MAKE) prefix=$(CURDIR)/debian/tmp/usr install ifeq "$(findstring nostrip,$(DEB_BUILD_OPTIONS))" "" - strip -R .comment -R .note debian/tmp/usr/bin/* + $(DEB_HOST_GNU_TYPE)-strip -R .comment -R .note debian/tmp/usr/bin/* endif install -d -m 0755 debian/tmp/usr/share/doc/lrzsz
Bug#825608: Remove libnet-jifty-perl?
On Thu, Aug 31, 2017 at 12:40:40PM +0100, Dominic Hargreaves wrote: > I noticed that that this bug has been tagged rm-candidate, and I'd like > to support this. There has been no upstream activity on Jifty since 2011 > and Best Practical abandoned their plans to port RT to this framework > (which was, IIRC, the original reason for its creation). > > There are no rdepends and a low/dropping popcon. Any objections to me > requesting this removal? Just to add: libnet-hiveminder-perl is an rdep (my previous checking was broken). That is also abandoned by Best Practical (and is only useful for talking to a now-closed down web service). So I would remove that too. Dominic.
Bug#825608: Remove libnet-jifty-perl?
I noticed that that this bug has been tagged rm-candidate, and I'd like to support this. There has been no upstream activity on Jifty since 2011 and Best Practical abandoned their plans to port RT to this framework (which was, IIRC, the original reason for its creation). There are no rdepends and a low/dropping popcon. Any objections to me requesting this removal? Cheers, Dominic.
Bug#873804: CVE-2017-11541
On Thu, Aug 31, 2017 at 01:26:46PM +0200, Guido Günther wrote: > O.k. Any idea when upstream will do this? Last week we were promised more details within one week, and an official release date in September. But these things take time... -- Romain Francoise https://people.debian.org/~rfrancoise/
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Hi Roger, Not the maintainer here, but: On 17-08-31 20:10:35, Roger Shimizu wrote: > Is it time to upload backports of 0.2.7-3 to stretch? No: Packages need to be first in testing, before going into -backports. > I'm also wondering why it didn't hit testing yet. Read this bug report for some reasons. Cheers, Georg signature.asc Description: Digital signature
Bug#760021: lintian: check for not wrap-and-sort formatted files
On Thu, Aug 31, 2017 at 10:06:52AM +0100, Chris Lamb wrote: > > lintian: check for not wrap-and-sort formatted files > > Good idea. I don't think it is. wrap-and-sort (or the equivalent from cme) is not widely enough adopted as of yet. I personally try to have all my sponsee use it, and I sometimes force a wrap-and-sort into NMUs, but it's still too rare. Also, wouldn't you need to pick only one of the -t, -s, -a combinations? I see people disliking -t (trailing commas) also because it's not in policy, and arguments for and agaist -s and -a; see the wrap-and-sort manual if you don't understand what I'm talking about. And that's without considering cme's configuration. > Alas, I fear that this would either require calling out to > wrap-and-sort (!) and diffing the result, or essentially reimplementing > it within Lintian itself? You could use libconfig-model-dpkg-perl, most probably. Therefore elevating cme's implementation. Summing up: I don't think it's a practise ready to be nudged by lintian yet. -- 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#872514: devscripts: Please add script to report on reproducibility status of installed packages
On Aug 31, 2017 05:09, "Chris Lamb" wrote: Hi, > Updated patch attached Any update? ACK to push? :) Yeah, that's fine with me. Cheers, James
Bug#872354: [git-buildpackage/master] patch_series: don't let "git mailinfo" sanitize the subject
tag 872354 pending thanks Date: Thu Aug 31 13:30:18 2017 +0200 Author: Guido Günther Commit ID: b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8 patch_series: don't let "git mailinfo" sanitize the subject This would strip away text in []. This improves the import/export round trip. Closes: #872354
Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
2017-08-31 13:25 GMT+02:00 Ian Jackson :
> Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
> urgency=medium"):
> > I guess that one could do something like moving the symlink into another
> > -legasy style package, and recomend that from the main package for one
> > release to keep upgrades happy. Then drop the recomendation, and wait
> > for popcon to show that people are not installing the package any more.
> > Then remove the package in testing early in a cycle and see if anyone
> > reports bugs about it.
>
> Even that would be quite unfriendly, because third party scripts might
> easily be deployed onto new Debian installs as well as existing ones.
>
> Also, it is imposing an administrative burden on all Debian users (the
> metadata for the -legacy package, spurious search hits, etc.). That
> burden might be small but would be completely unjustified.
>
How about printing a "nice" warning explaining it would be a good idea to
move to /usr/bin/node ? Then in next next release drop the nodejs symlink.
Jérémy
Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
On Thu, 31 Aug 2017, Jérémy Lal wrote: > How about printing a "nice" warning explaining it would be a good idea to > move to /usr/bin/node ? That will break scripts that do: x=$(nodejs somescript) Or even ./somescript when that has a #!/usr/bin/env nodejs shebang. > Then in next next release drop the nodejs symlink. Again, “no, period”. Do not drop it before *after* the next release, so people have, at the very least, one full release of time to switch their scripts in a way that works with both the old and new names *first*, gradually. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco!** 13. und 14. September 2017, Messe Köln,** Halle 7.1, Stand E042** Digital Marketing Exposition & Conference [www.tarent.de/dmexco](http://www.tarent.de/dmexco) Wir empfehlen unseren Vortrag "Wettbewerbsanalyse im Handel: Preisvergleich online und offline" am 13. September, 18:00 Uhr im Speaker's Forum / Broadway * **Visit us at dmexco!** September 13th and 14th, 2017, Messe Köln,** Hall 7.1, Booth E042** Digital Marketing Exposition & Conference [www.tarent.de/dmexco](http://www.tarent.de/dmexco) We recommend our presentation "Competitor analysis in retail: price comparison online and offline" on September 13th, at 6 pm at the Speaker's Corner / Broadway *
Bug#825608: Remove libnet-jifty-perl?
On Thu, 31 Aug 2017 12:43:14 +0100, Dominic Hargreaves wrote: > On Thu, Aug 31, 2017 at 12:40:40PM +0100, Dominic Hargreaves wrote: > > I noticed that that this bug has been tagged rm-candidate, and I'd like > > to support this. There has been no upstream activity on Jifty since 2011 > > and Best Practical abandoned their plans to port RT to this framework > > (which was, IIRC, the original reason for its creation). > > > Just to add: libnet-hiveminder-perl is an rdep (my previous checking > was broken). That is also abandoned by Best Practical (and is only > useful for talking to a now-closed down web service). So I would remove > that too. Sounds good to me. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #261: The Usenet news is out of date
Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Le jeudi, 31 août 2017, 12.25:50 h CEST Ian Jackson a écrit :
> Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> > I guess that one could do something like moving the symlink into another
> > -legacy style package, and recomend that from the main package for one
> > release to keep upgrades happy. Then drop the recomendation, and wait
> > for popcon to show that people are not installing the package any more.
> > Then remove the package in testing early in a cycle and see if anyone
> > reports bugs about it.
>
> Even that would be quite unfriendly, because third party scripts might
> easily be deployed onto new Debian installs as well as existing ones.
>
> Also, it is imposing an administrative burden on all Debian users (the
> metadata for the -legacy package, spurious search hits, etc.). That
> burden might be small but would be completely unjustified.
This exact argument stands against not allowing NodeJS to use /usr/bin/node in
the first place, really. We accepted to enforce that change for the /usr/bin/
namespace "first-come-first-served" reason. We imposed a quite heavy
administrative burden of either targetting /u/b/nodejs additionally or (finding
out and) installing nodejs-legacy for anyone wanting to use NodeJS on Debian.
Now, there are two categories of scripts affected by this discussion:
* All scripts which support /u/b/nodejs *in addition* to /u/b/node. These do
so _because_ of a Debian-specific change, and removing the /u/b/nodejs symlink
is not going to break those.
* All scripts which support /u/b/nodejs *exclusively*. These do so _because_
of a Debian-specific change, and don't support *any* non-Debian-derivative
target (checked Fedora's nodejs RPMs: no /u/b/nodejs). Maintainers of those
scripts have at one point decided to support only Debian{, and derivatives}.
There are _plenty_ of changes that one needs to care about in a stable
upgrade: things like mandatory postfixing of Apache configuration files,
removal
of specific Python3 versions, removal of upstart, etc. Having to change a
shebang isn't a big deal given the amount of things one has to check accross a
stable release upgrade.
All that to say that despite the very small cost of keeping the symlink
around, I do see value in closing the Debian-specific /u/b/nodejs chapter *at
some point*. We should not clutter our future releases indefinitely with
convenience symlinks for historical reasons, especially not when these were
created _by_ Debian and have only been _in_ Debian.
Le jeudi, 31 août 2017, 13.52:00 h CEST Jérémy Lal a écrit :
> How about printing a "nice" warning explaining it would be a good idea to
> move to /usr/bin/node ? Then in next next release drop the nodejs symlink.
This seems like a very good plan to me: let /u/b/nodejs spit out a deprecation
warning to stderr / syslog but pass all arguments to /u/b/node in Buster;
remove it entirely in Bullseye & get proper release note entries for both
Buster and Bullseye.
Cheers.
OdyX
signature.asc
Description: This is a digitally signed message part.
Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Le jeudi, 31 août 2017, 13.58:23 h CEST Thorsten Glaser a écrit : > Do not drop it before *after* the next release, so people have, > at the very least, one full release of time to switch their > scripts in a way that works with both the old and new names > *first*, gradually. They have Stretch for that; it has both /usr/bin/nodejs and /usr/bin/node (in nodejs-legacy). Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#873812: e2fsprogs: Please move l10n package from Suggests to Recommends
Package: e2fsprogs Version: 1.43.6-1 Hi! The recently split translations ended up being added as a Suggests in e2fsprogs, which means they will not be installed by default anymore. This should probably be a Recommends, which would allow people to remove them, but would be pulled in by default. (If this was a library pulling the package then a Suggests would indeed seem more appropriate.) Also, and just in case, I don't think using something like util-linux-locales as precedent is a good idea, it even has a non-ideal package name. :) For which I'll be filing bugs. Thanks, Guillem
Bug#873811: ITP: h2o -- Optimized HTTP/1.x, HTTP/2 server
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos * Package name: h2o Version : 2.2.2 Upstream Author : DeNA Co., Ltd., Kazuho Oku * URL : https://h2o.examp1e.net * License : MIT Programming Lang: C Description : Optimized HTTP/1.x, HTTP/2 server H2O is a new generation HTTP server that provides quick response to users at a low CPU utilization. Designed from the ground-up with a strong focus on performance and security, the server takes full advantage of HTTP/2 features including prioritized content serving and server push.
Bug#868473: dh-acc: Incorrect usage of doit (Dh_Lib)
This bug is still unfixed in Debian right? It makes debci less useful for packages that use dh-acc. Thanks, Jeremy Bicha
Bug#873813: e2fsprogs-l10n: Package should be arch:all
Package: e2fsprogs-l10n Version: 1.43.6-1 Hi! This is a package containing only arch-indep files and should thus be arch:all, which will reduce disk size on the mirrors. :) It used to be the case that the .mo files were endian-specific, but that was fixed upstream and now all use the same endianness independently of the host system. Thanks, Guillem
Bug#754462: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
On Thu, 31 Aug 2017, Julien Puydt wrote: > May I suggest to have /usr/bin/nodejs print a nice deprecation warning > to use /usr/bin/node, and just *never* remove it? On Thu, 31 Aug 2017, Didier 'OdyX' Raboud wrote: > Le jeudi, 31 août 2017, 13.52:00 h CEST Jérémy Lal a écrit : > > How about printing a "nice" warning explaining it would be a good idea to > > move to /usr/bin/node ? Then in next next release drop the nodejs symlink. > > This seems like a very good plan to me: let /u/b/nodejs spit out a deprecation > warning to stderr / syslog but pass all arguments to /u/b/node in Buster; This *will* break scripts. There’s also: x=$(nodejs progname --version 2>&1 >/dev/null | head -n 1) Yes, I saw this break in other programs that suddenly decided to add extra messages to either stdout and stderr, multiple times. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco!** 13. und 14. September 2017, Messe Köln,** Halle 7.1, Stand E042** Digital Marketing Exposition & Conference [www.tarent.de/dmexco](http://www.tarent.de/dmexco) Wir empfehlen unseren Vortrag "Wettbewerbsanalyse im Handel: Preisvergleich online und offline" am 13. September, 18:00 Uhr im Speaker's Forum / Broadway * **Visit us at dmexco!** September 13th and 14th, 2017, Messe Köln,** Hall 7.1, Booth E042** Digital Marketing Exposition & Conference [www.tarent.de/dmexco](http://www.tarent.de/dmexco) We recommend our presentation "Competitor analysis in retail: price comparison online and offline" on September 13th, at 6 pm at the Speaker's Corner / Broadway *
Bug#871648: qemu-system-x86: /usr/bin/qemu-system-i386 eats slowly but surely all the Dom0 memory
Control: found -1 1:2.8+dfsg-7
Control: tags -1 + patch fixed-upstream
Hi,
After staring at GDB for ungodly spans of time I managed to track down this
bug, ipso facto discovering that it was already fixed upstream quite some time
ago...
I think you took upstream commit 04bf2526ce87f21b32c9acba1c5518708c243ad0
(exec: use qemu_ram_ptr_length to access guest ram) from v2.10.0-rc0. That
patch introduced the bug. It was fixed about a month ago in v2.10.0-rc1; see:
- https://patchwork.ozlabs.org/patch/794015/
-
https://git.qemu.org/gitweb.cgi?p=qemu.git;a=commit;f=exec.c;h=f5aa69bdc3418773f26747ca282c291519626ece
I include an easy backport of that patch (very minor tweaks needed for it to
apply to v2.8.1) that you can drop at the end of debian/patches/series. I
tested this in a trial amd64 build and it seems to have solved the problem
for me.
Suggestion: merge these threads:
tags 871648 - moreinfo unreproducible
tags 871648 + confirmed
merge 871648 871702 872257
Cheers.
From: astian
Date: Thu, 31 Aug 2017 11:02:10 +
Subject: [PATCH] exec: Add lock parameter to qemu_ram_ptr_length
This patch is a simple backport of upstream commit
f5aa69bdc3418773f26747ca282c291519626ece, which was included in
v2.10.0-rc1 (and later in the final v2.10.0), to the v2.8.1 branch
currently packaged in Debian unstable.
See:
- https://patchwork.ozlabs.org/patch/794015/
- https://git.qemu.org/gitweb.cgi?p=qemu.git;a=commit;f=exec.c;h=f5aa69bdc3418773f26747ca282c291519626ece
The original patch:
From f5aa69bdc3418773f26747ca282c291519626ece Mon Sep 17 00:00:00 2001
From: Anthony PERARD
Date: Wed, 26 Jul 2017 17:53:26 +0100
Subject: [PATCH] exec: Add lock parameter to qemu_ram_ptr_length
Commit 04bf2526ce87f21b32c9acba1c5518708c243ad0 (exec: use
qemu_ram_ptr_length to access guest ram) start using qemu_ram_ptr_length
instead of qemu_map_ram_ptr, but when used with Xen, the behavior of
both function is different. They both call xen_map_cache, but one with
"lock", meaning the mapping of guest memory is never released
implicitly, and the second one without, which means, mapping can be
release later, when needed.
In the context of address_space_{read,write}_continue, the ptr to those
mapping should not be locked because it is used immediatly and never
used again.
The lock parameter make it explicit in which context qemu_ram_ptr_length
is called.
Signed-off-by: Anthony PERARD
Message-Id: <20170726165326.10327-1-anthony.per...@citrix.com>
Reviewed-by: Stefano Stabellini
Signed-off-by: Paolo Bonzini
---
exec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/exec.c b/exec.c
index 44df5f0fcb..814baa43a1 100644
--- a/exec.c
+++ b/exec.c
@@ -1879,7 +1879,7 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t addr)
* Called within RCU critical section.
*/
static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
- hwaddr *size)
+ hwaddr *size, bool lock)
{
RAMBlock *block = ram_block;
if (*size == 0) {
@@ -1898,7 +1898,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
* In that case just map the requested area.
*/
if (block->offset == 0) {
-return xen_map_cache(addr, *size, 1);
+return xen_map_cache(addr, *size, lock);
}
block->host = xen_map_cache(block->offset, block->max_length, 1);
@@ -2613,7 +2613,7 @@ static MemTxResult address_space_write_continue(AddressSpace *as, hwaddr addr,
}
} else {
/* RAM case */
-ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l);
+ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
memcpy(ptr, buf, l);
invalidate_and_set_dirty(mr, addr1, l);
}
@@ -2704,7 +2704,7 @@ MemTxResult address_space_read_continue(AddressSpace *as, hwaddr addr,
}
} else {
/* RAM case */
-ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l);
+ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
memcpy(buf, ptr, l);
}
@@ -3007,7 +3007,7 @@ void *address_space_map(AddressSpace *as,
memory_region_ref(mr);
*plen = done;
-ptr = qemu_ram_ptr_length(mr->ram_block, base, plen);
+ptr = qemu_ram_ptr_length(mr->ram_block, base, plen, true);
rcu_read_unlock();
return ptr;
Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Hi, Le 31/08/2017 à 13:52, Jérémy Lal a écrit : > How about printing a "nice" warning explaining it would be a good idea to > move to /usr/bin/node ? Then in next next release drop the nodejs symlink. May I suggest to have /usr/bin/nodejs print a nice deprecation warning to use /usr/bin/node, and just *never* remove it? After all, that will be a very small file, won't step on anybody's toe : it's more trouble to drop it than to just leave it... Snark on #debian-js
Bug#873814: nextcloud-server: missing php-zip and php-mbstring
Package: nextcloud-server Version: 12.0.1~stretch Severity: normal Dear Maintainer, Hi, Some php packages are missing from your "Depends" list, notably php7.0-zip and php7.0-mbstring. HTH, Xav -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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) Versions of packages nextcloud-server depends on: ii apache2 [httpd] 2.4.25-3+deb9u2 ii php7.0 7.0.19-1 ii php7.0-cgi 7.0.19-1 ii php7.0-cli 7.0.19-1 ii php7.0-common7.0.19-1 ii php7.0-curl 7.0.19-1 ii php7.0-gd7.0.19-1 ii php7.0-intl 7.0.19-1 ii php7.0-json 7.0.19-1 ii php7.0-ldap 7.0.19-1 ii php7.0-mcrypt7.0.19-1 ii php7.0-mysql 7.0.19-1 ii php7.0-pgsql 7.0.19-1 ii php7.0-sqlite3 7.0.19-1 ii php7.0-xml 7.0.19-1 Versions of packages nextcloud-server recommends: ii curl7.52.1-5 ii postgresql 9.6+181 Versions of packages nextcloud-server suggests: ii clamav 0.99.2+dfsg-6+b1 ii clamav-daemon 0.99.2+dfsg-6+b1 ii php-apcu [php7.0-apcu] 5.1.8+4.0.11-1 -- no debconf information
Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0
Ximin Luo: > Julien Puydt: >> [..] >> >> I still pushed this work-in-progress, as it should be good enought for >> some tests already. >> > > I will have a go at testing it tomorrow/soon. Thanks! > eclib, giac, linbox succeeded but flint fails: [..] make[3]: Entering directory '/<>' g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/<> -c interfaces/NTL-interface.cpp -o build/interfaces/NTL-interface.o g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/<> interfaces/test/t-NTL-interface.cpp build/interfaces/NTL-interface.o -o build/interfaces/test/t-NTL-interface -L/<> -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lflint -lmpfr -lgmp -lm -lntl -lpthread make[3]: Leaving directory '/<>' ZZ_to_fmpzPASS ZZX_to_fmpz_polyPASS ZZ_pX_to_fmpz_mod_polyPASS ZZ_pE_to_fqPASS ZZ_pEX_to_fq_polyPASS zz_pX_to_fmpz_mod_polyFAIL: f_poly1 = 61 40559 2065 31588 35949 5581 18565 23027 17733 40355 21583 29748 34876 9541 13193 37235 25453 21973 26716 1397 32001 6909 21509 13786 20347 3693 31431 1471 14890 19641 12608 1894 24849 8969 15639 30973 20096 8110 30791 35078 29416 16789 35010 10460 34287 20737 768 35601 22276 17792 3619 10427 1950 5016 21067 39969 274 29530 39547 13397 8480 1868 19224 f_poly2 = 61 40559 -19790727 -303309173 -345202259 -53532299 -178238240 -221104641 -170248949 -387500890 -207234907 -285627289 -334901346 -91572681 -126652564 -357530909 -244383081 -210965945 -256508959 -13342514 -307283542 -66307056 -206504919 -132330231 -195352356 -35404314 -301808647 -14072502 -142955585 -188579709 -121015448 -18127979 -238583748 -86097788 -150133779 -297388174 -192959626 -77824611 -295644319 -336847976 -282464019 -161164677 -336158541 -100413624 -329223675 -199083394 -7299852 -341836210 -213885890 -170816716 -34714885 -100089185 -18655190 -48097958 -202287225 -383810407 -2554943 -283558998 -379754929 -128599192 -81393433 -17884651 -184564785 zz_pE_to_fqFAIL: p = 31 mod = x^2+19*x+12 f1 = 20*a+16 - 2 zzpe:[-418 -538] f2 = -538*a-418 - 2 zz_pEX_to_fq_polyAborted Makefile:211: recipe for target 'check' failed make[2]: *** [check] Error 134 [..] I did not yet try singular or pynac because they depend on flint. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#873815: pyjwt: PyJWT vulneratibility for some keys
Package: pyjwt
Version: 1.4.2-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch
Dear Maintainer,
Upstream already fixed that issue, here is the debdiff that was applied in
order to fix this.
* SECURITY UPDATE: symmetric/asymmetric key confusion attacks
- debian/patches/CVE-2017-11424.patch: Throw if key is an PKCS1
PEM-encoded public key in jwt/algorithms.py, jwt/api_jws.py,
jwt/api_jwt.py, tests/keys/testkey_pkcs1.pub.pem,
tests/test_algorithms.py, tests/test_api_jws.py, tests/test_api_jwt.py.
- CVE-2017-11424
Thanks for considering the patch.
-- System Information:
Debian Release: stretch/sid
APT prefers xenial-updates
APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500,
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pyjwt-1.4.2/debian/files pyjwt-1.4.2/debian/files
--- pyjwt-1.4.2/debian/files 1969-12-31 21:00:00.0 -0300
+++ pyjwt-1.4.2/debian/files 2017-08-30 11:51:30.0 -0300
@@ -0,0 +1 @@
+pyjwt_1.4.2-1ubuntu1_source.buildinfo python optional
diff -Nru pyjwt-1.4.2/debian/patches/CVE-2017-11424.patch pyjwt-1.4.2/debian/patches/CVE-2017-11424.patch
--- pyjwt-1.4.2/debian/patches/CVE-2017-11424.patch 1969-12-31 21:00:00.0 -0300
+++ pyjwt-1.4.2/debian/patches/CVE-2017-11424.patch 2017-08-29 11:40:17.0 -0300
@@ -0,0 +1,139 @@
+From 1922f0972b065077404c0dafa0946f2132400a2b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jos=C3=A9=20Padilla?=
+Date: Wed, 21 Jun 2017 15:49:41 -0400
+Subject: [PATCH 1/3] Throw if key is an PKCS1 PEM-encoded public key
+
+---
+ jwt/algorithms.py| 1 +
+ jwt/api_jws.py | 9 +
+ jwt/api_jwt.py | 9 +
+ tests/keys/testkey_pkcs1.pub.pem | 5 +
+ tests/test_algorithms.py | 7 +++
+ tests/test_api_jws.py| 10 ++
+ tests/test_api_jwt.py| 10 ++
+ 7 files changed, 51 insertions(+)
+ create mode 100644 tests/keys/testkey_pkcs1.pub.pem
+
+diff --git a/jwt/algorithms.py b/jwt/algorithms.py
+index 51e8f16..fd9c3ac 100644
+--- a/jwt/algorithms.py
b/jwt/algorithms.py
+@@ -121,6 +121,7 @@ class HMACAlgorithm(Algorithm):
+ invalid_strings = [
+ b'-BEGIN PUBLIC KEY-',
+ b'-BEGIN CERTIFICATE-',
++b'-BEGIN RSA PUBLIC KEY-',
+ b'ssh-rsa'
+ ]
+
+diff --git a/jwt/api_jws.py b/jwt/api_jws.py
+index 177f5ff..a91137c 100644
+--- a/jwt/api_jws.py
b/jwt/api_jws.py
+@@ -107,6 +107,15 @@ class PyJWS(object):
+
+ def decode(self, jws, key='', verify=True, algorithms=None, options=None,
+**kwargs):
++
++if not algorithms:
++warnings.warn(
++'It is strongly recommended that you pass in a ' +
++'value for the "algorithms" argument when calling decode(). ' +
++'This argument will be mandatory in a future version.',
++DeprecationWarning
++)
++
+ payload, signing_input, header, signature = self._load(jws)
+
+ if verify:
+diff --git a/jwt/api_jwt.py b/jwt/api_jwt.py
+index 9703b8d..e0e6c25 100644
+--- a/jwt/api_jwt.py
b/jwt/api_jwt.py
+@@ -58,6 +58,15 @@ class PyJWT(PyJWS):
+
+ def decode(self, jwt, key='', verify=True, algorithms=None, options=None,
+**kwargs):
++
++if not algorithms:
++warnings.warn(
++'It is strongly recommended that you pass in a ' +
++'value for the "algorithms" argument when calling decode(). ' +
++'This argument will be mandatory in a future version.',
++DeprecationWarning
++)
++
+ payload, signing_input, header, signature = self._load(jwt)
+
+ decoded = super(PyJWT, self).decode(jwt, key, verify, algorithms,
+diff --git a/tests/keys/testkey_pkcs1.pub.pem b/tests/keys/testkey_pkcs1.pub.pem
+new file mode 100644
+index 000..f690179
+--- /dev/null
b/tests/keys/testkey_pkcs1.pub.pem
+@@ -0,0 +1,5 @@
++-BEGIN RSA PUBLIC KEY-
++MIGHAoGBAOV/0Vl/5VdHcYpnILYzBGWo5JQVzo9wBkbxzjAStcAnTwvv1ZJTMXs6
++fjz91f9hiMM4Z/5qNTE/EHlDWxVdj1pyRaQulZPUs0r9qJ02ogRRGLG3jjrzzbzF
++yj/pdNBwym0UJYC/Jmn/kMLwGiWI2nfa9vM5SovqZiAy2FD7eOtVAgED
++-END RSA PUBLIC KEY-
+diff --git a/tests/test_algorithms.py b/tests/test_algorithms.py
+index e3cf1d0..fea654c 100644
+--- a/tests/test_algorithms.py
b/tests/test_algorithms.py
+@@ -84,6 +84,13 @@ class TestAlgorithms:
+ with open(key_path('testkey2_rsa.pub.pem'), 'r') as keyfile:
+ algo.prepare_key(keyfile.read())
+
++def test_hmac_should_throw_e
Bug#873816: texlive-base: Fonts handling broken in dvips?
Package: texlive-base
Version: 2016.20170123-5
Severity: normal
Dear Maintainer,
The following LaTeX file:
\documentclass[12pt,a4paper]{article}
\font\testing=cmssbx17 scaled 2500
\font\testingb=cmssbx17 scaled 1500
\font\testingt=cmss17 scaled 800
\begin{document}
\testing{first{\testingb{second}}third}\\
\testingt{fourth}
\end{document}
was working correctly with Debian wheezy LTS, for DVI, PS (via dvips)
and PDF (via pdflatex):
latex demo.tex && dvips demo.dvi -o demo.ps && pdflatex demo.tex
xdvi demo.dvi; gv demo.ps; gv demo.pdf
With jessie and stretch, the problem is a corrupted PS file which does
not contain the word "first" completely, and in addition with a
wrong font (looking like courier).
Maybe the psfonts.map file is wrong?
Thank you to look into this.
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH.U
TF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages texlive-base depends on:
ii debconf [debconf-2.0] 1.5.61
ii libpaper-utils 1.1.24+nmu5
ii tex-common 6.06
ii texlive-binaries 2016.20160513.41080.dfsg-2
ii ucf3.0036
ii xdg-utils 1.1.1-1
Versions of packages texlive-base recommends:
ii lmodern 2.004.5-3
Versions of packages texlive-base suggests:
ii atril [postscript-viewer]1.16.1-2+deb9u1
ii ghostscript [postscript-viewer] 9.20~dfsg-3.2
ii gv [postscript-viewer] 1:3.7.4-1+b1
pn perl-tk
pn xpdf-reader | pdf-viewer
Versions of packages tex-common depends on:
ii dpkg 1.18.24
ii ucf 3.0036
Versions of packages tex-common suggests:
ii debhelper 10.2.5
Versions of packages texlive-base is related to:
ii tex-common6.06
ii texlive-binaries 2016.20160513.41080.dfsg-2
-- debconf information:
texlive-base/texconfig_ignorant:
tex-common/check_texmf_wrong:
tex-common/check_texmf_missing:
texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
Bug#873789: init-system-helpers: autopkgtests broken in 1.49
On Thu, Aug 31, 2017 at 4:12 AM, Steve Langasek wrote: > Attached is a patch which fixes the tests to also correctly handle the > escape characters in the unit names. Thanks! Applied as b13d642. It will be part of the next upload. -- Saludos, Felipe Sateler
Bug#869499: [Pkg-nginx-maintainers] Bug#869499: nginx: [PATCH] Automate modules watch & upgrade process
On Sun, Jul 23, 2017 at 09:42:47PM +0300, Mpampis Kostas wrote: Package: nginx Severity: wishlist Tags: patch This patch introduces the debian/modules/uscan script and some helper files which can be used to automate the modules watch & upgrade process. The main script is executed as '$ debian/modules/uscan' without any arguments from the root of the debianized nginx source tree where you see the debian/ directory. It runs uscan for each nginx module listed in the newly deb822 formatted debian/modules/README.Modules-version using the watchfiles in debian/modules/watch. If a new version is available, it will ask you if you want to upgrade. If you agree, it will download the tarball, place it in the parent directory and upgrade the module's source. After the upgrade, it will remove the files listed in the Files-Excluded module field. Example output: $ debian/modules/uscan Thanks a lot Mpampis, great patch, it's a time saver! Since the module config is now a proper deb822 file, we can rename it to debian/modules/control. As a final step, this might be a good time to cannonicalize the module paths to exactly match the package naming. I believe this should happen first to keep the diffs as simple as possible. Regarding the script itself, I believe we can make it more generic (ngxmod?) and add uscan as a subcommand, we can the add more commands like list, add, etc.
Bug#873791: closed by Matthias Klose (Bug#873791: fixed in python3.6 3.6.2-3)
Hi Mathias, sorry, I don't see why uploading an unrelated package does actually solve the problem? "Breaks" here does only prevent python3-numpy from installed on sid, but it still allows python-numpy to be installed together with the current Python 2.7? This sounds a bit mystic to me. Could you explain why this upload closes the bug? Thank you very much Ole On 31.08.2017 14:39, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the python2.7 package: > > #873791: python2.7: fpectl extension removal broke the ABI for C extensions > > It has been closed by Matthias Klose . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Matthias Klose > by > replying to this email. > >
Bug#635964: Pending fixes for bugs in the pdfsam package
tag 635964 + pending tag 779058 + pending tag 792467 + pending tag 714394 + pending tag 796805 + pending tag 714304 + pending thanks Some bugs in the pdfsam package are closed in revision 2aef69ee6ff3c4899d7581f4a4475e359db2013c in branch 'master' by Markus Koschany The full diff can be seen at https://anonscm.debian.org/cgit/pkg-java/pdfsam.git/commit/?id=2aef69e Commit message: Import Debian changes 3.2.5-1 pdfsam (3.2.5-1) experimental; urgency=medium * New upstream version. (Closes: #635964) - Null pointer exception was fixed. (Closes: #779058) - pdfsam-console does no longer exist. (Closes: #792467) - i18n localization works as expected now. (Closes: #714394) - The update manager is disabled by default now. (Closes: #796805) - jgoodies-common is no longer a required dependency. (Closes: #714304) * New build system Maven. * Add myself to Uploaders and remove Thorsten Werner because he is not active anymore.
