Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures
On 13/11/16 at 22:59 -0800, Lars Tangvald wrote: > > - lu...@debian.org wrote: > > > > Do you have the logs from the last run? > > > While we could disable the test that's failing, it would be > > counterproductive since we can't reproduce the issue in any of our > > normal build environments. > > > > This is the log without your patch applied > > > > Lucas > > Or did you mean with? no, the log was without the patch. I did not keep the log with the patch > It's failing in a different way. I think the way it's failing here is to do > with insufficient system resources. unlikely, that node has 64 cores and 256 GB of RAM. Lucas
Bug#821114: nginx: Please use KillSignal=SIGQUIT in systemd service
On Thu, Nov 10, 2016 at 10:42:36PM +0100, Michael Biebl wrote: On Tue, 8 Nov 2016 11:20:45 +0200 Christos Trochalakis wrote: On Fri, Apr 15, 2016 at 06:54:55PM +0200, Laurent Bigonville wrote: >Package: nginx >Version: 1.6.2-3 >Severity: normal >User: pkg-systemd-maintain...@lists.alioth.debian.org > >Hi, > >Wouldn't it be better to use KillSignal=SIGQUIT in the .service file >rather than using this hack? > >ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid > >Is it necessary really necessary to send QUIT, then TERM and then KILL? > By using KillSignal=SIGQUIT systemd would forcibly (SIGKILL) nginx after the timeout is reached. SIGQUIT triggers graceful shutdown so it waits for all existing client connections to terminate. If for example you have websocket or SSE long running clients you will hit the timeout. In such cases we don't want systemd to SIGKILL nginx. The current solution fallbacks to SIGTERM that forces systemd to close existing clients and terminate. Would ExecStop=/bin/kill -QUIT $MAINPID work? This would first send SIQUIT to the main process, after TimeoutStopSec= it would send SIGTERM to all remaining processes and after another TimeoutStopSec=, SIGKILL. Is this the behaviour you want? It feels a bit more systemdish to me then involving start-stop-daemon If I remember correctly that wont do it. Systemd expects the ExecStop= command to block until the service is stopped, or it fallbacks to SIGTERM. According to the systemd.service(5): After the commands configured in this option are run, all processes remaining for a service are terminated according to the KillMode= setting. I remember testing this a while back and decided to use start-stop-daemon which has the ability to block until the service is stopped: https://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=caee1c2a
Bug#789196: debsecan: Support SUITE=stretch
control: tags -1 + patch Hi, Nye Liu writes: > Please support SUITE=stretch or implement #466407 or #612539 Attached you can find the following patch: [PATCH] Allow any suite, improve error message when downloading This way, the files available at security-tracker.debian.org become authoritative for what valid values are, as opposed to a hard-coded list that quickly goes out of date. -- Best regards, Michael >From 31cb69e4f825ce7fde1a401708dd9f0e45edf684 Mon Sep 17 00:00:00 2001 From: Michael Stapelberg Date: Mon, 14 Nov 2016 08:51:56 +0100 Subject: [PATCH] Allow any suite, improve error message when downloading This way, the files available at security-tracker.debian.org become authoritative for what valid values are, as opposed to a hard-coded list that quickly goes out of date. --- src/debsecan | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/debsecan b/src/debsecan index 96ba9c3..625ab2e 100644 --- a/src/debsecan +++ b/src/debsecan @@ -316,9 +316,7 @@ def parse_cli(): parser.add_option("--config", metavar="FILE", help="sets the name of the configuration file", default='/etc/default/debsecan') -parser.add_option("--suite", type="choice", - choices=['woody', 'sarge', 'etch', 'lenny', 'squeeze', 'wheezy', - 'jessie', 'sid'], +parser.add_option("--suite", help="set the Debian suite of this installation") parser.add_option("--source", metavar="URL", help="sets the URL for the vulnerability information") @@ -531,6 +529,12 @@ def fetch_data(options, config): # In cron mode, we suppress almost all errors because we # assume that they are due to lack of Internet connectivity. except urllib2.HTTPError, e: +if e.code == 404: +sys.stderr.write("error: while downloading %s:\n%s\n" % (url, e)) +if options.suite: +sys.stderr.write("Are you sure \"%s\" is a Debian codename?\n" % + (options.suite)) +sys.exit(1) if (not options.cron) or e.code == 404: sys.stderr.write("error: while downloading %s:\n%s\n" % (url, e)) sys.exit(1) -- 2.9.3
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
Hi, Quoting Paul Wise (2016-11-14 08:42:27) > On Mon, 2016-11-14 at 08:30 +0100, Johannes Schauer wrote: > > > why do you have to supply the exact version as well? > > Otherwise the wrong package could get installed: ah, indeed, so it's not just a list of packages. > > you could do it like sbuild and ... create a dummy binary package > > That is a bit ugly IMO, I would prefer #275379 to get implemented. How about using equivs, then? > > Alternatively, sbuild would be happy with parsing the .dsc you already > > provide and pass the contents of the Build-Depends field to apt. > > That would work for sbuild because build-essential is installed in > build chroots, but not for cats more generally. No, it would work for sbuild because sbuild knows how to parse a .dsc and turn that into a binary package. In this case: into a binary package without build-essential. Thanks! cheers, josch signature.asc Description: signature
Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)
On Mon, Nov 14, 2016, at 08:21, Adrian Bunk wrote: > On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote: > > > Looking at mod_ssl_openssl.h and the comment in #828330, > > > I'd suggest the change below to add a dependency on libssl1.0-dev > > > to apache2-dev. > > > > And that exactly happens meaning that PHP 7.0 can no longer be built > > unless all it's build-depends (including PHP 7.0) and rdepends move to > > libssl1.0-dev as well. > > > > So a nice deadlock, right? To be honest I would rather have a slightly > > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go > > than revert all the work I have done. > > > > I reviewed the patch Kurt has provided and I don't see any strong reason > > why anything should break. > >... > > Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when > Apache itself uses 1.1? Why? > That is the most important question here. No, I think the question is: Can we migrate (or drop) all rdeps to 1.0.2? > This is what my "mod_ssl_openssl.h and the comment in #828330" > was referring to. > > The dual 1.0.2/1.1 setup for stretch can only work when any set of > packages in the archive that needs the same OpenSSL version stays > at 1.0.2 unless *all* packages in this set are compiling and working > fine with 1.1 The *set* you are talking probably cover whole archive, since the Build-Depends of PHP are quite vast and here are the Build-Depends of Build-Depends: (This is from stretch, not from unstable) apache2-dev libssl-dev (>= 0.9.8m) libc-client2007e-dev libssl-dev libcurl4-openssl-dev libssl-dev libevent-dev libssl-dev libkrb5-dev libssl-dev libpq-dev libssl-dev libsasl2-dev libssl-dev libsnmp-dev libssl-dev (>> 0.9.8) Greping just Depends: on -dev packages is slightly more optimistic: apache2-dev libssl-dev (<< 1.1) libc-client2007e-dev libssl-dev libpq-dev libssl-dev libsnmp-dev libssl-dev But ultimately I am afraid that libssl dependencies are so entagled that it will cover all archive. > And since the OpenSSL version used is part of the libcurl3 ABI > (see #844018 for details), using 1.1 in stretch is anyway not > really an option for Apache/PHP in stretch. What you are really saying is that using OpenSSL 1.1 is generally not an option for stretch. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu
Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)
On Mon, Nov 14, 2016, at 08:44, Ondřej Surý wrote: > On Mon, Nov 14, 2016, at 08:21, Adrian Bunk wrote: > > On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote: > > > > Looking at mod_ssl_openssl.h and the comment in #828330, > > > > I'd suggest the change below to add a dependency on libssl1.0-dev > > > > to apache2-dev. > > > > > > And that exactly happens meaning that PHP 7.0 can no longer be built > > > unless all it's build-depends (including PHP 7.0) and rdepends move to > > > libssl1.0-dev as well. > > > > > > So a nice deadlock, right? To be honest I would rather have a slightly > > > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go > > > than revert all the work I have done. > > > > > > I reviewed the patch Kurt has provided and I don't see any strong reason > > > why anything should break. > > >... > > > > Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when > > Apache itself uses 1.1? > > Why? > > > That is the most important question here. > > No, I think the question is: > > Can we migrate (or drop) all rdeps to 1.0.2? I meant s/1.0.2/1.1.0/ > > This is what my "mod_ssl_openssl.h and the comment in #828330" > > was referring to. > > > > The dual 1.0.2/1.1 setup for stretch can only work when any set of > > packages in the archive that needs the same OpenSSL version stays > > at 1.0.2 unless *all* packages in this set are compiling and working > > fine with 1.1 > > The *set* you are talking probably cover whole archive, since the > Build-Depends of PHP are quite vast and here are the Build-Depends > of Build-Depends: > > (This is from stretch, not from unstable) > apache2-dev libssl-dev (>= 0.9.8m) > libc-client2007e-dev libssl-dev > libcurl4-openssl-dev libssl-dev > libevent-dev libssl-dev > libkrb5-dev libssl-dev > libpq-dev libssl-dev > libsasl2-dev libssl-dev > libsnmp-dev libssl-dev (>> 0.9.8) > > Greping just Depends: on -dev packages is slightly more optimistic: > > apache2-dev libssl-dev (<< 1.1) > libc-client2007e-dev libssl-dev > libpq-dev libssl-dev > libsnmp-dev libssl-dev > > But ultimately I am afraid that libssl dependencies are so entagled > that it will cover all archive. > > > And since the OpenSSL version used is part of the libcurl3 ABI > > (see #844018 for details), using 1.1 in stretch is anyway not > > really an option for Apache/PHP in stretch. > > What you are really saying is that using OpenSSL 1.1 is generally > not an option for stretch. > > Cheers, > -- > Ondřej Surý > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server > Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, > fast DNS(SEC) resolver > Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro > pečení chleba všeho druhu
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
On Mon, 2016-11-14 at 08:30 +0100, Johannes Schauer wrote: > why do you have to supply the exact version as well? Otherwise the wrong package could get installed: .../check-all-the-things (master=) $ git grep -h ^apt.= | sed s/apt.=.// | grep '[^-a-z0-9, ]' cypher-lint (>= 0.3.4) cme | libconfig-model-perl (<< 2.063), libconfig-model-dpkg-perl fontforge-nox | fontforge licensecheck | devscripts (<< 2.16.6~) devscripts, devscripts (>= 2.13.1~) | python-magic, devscripts (<< 2.13.1~) | python3-magic licensecheck | devscripts (<< 2.16.6~) licensecheck | devscripts (<< 2.16.6~) clang-modernize-3.5 php-cli | php5-cli pyflakes (>= 0.7.3) pyflakes3 | pyflakes (>= 0.7.3), pyflakes3 | pyflakes (<< 1.1.0-1) pylint (>= 1.1.0) pylint3 (>= 1.1.0) python3-bashate | python-bashate python3-restructuredtext-lint | python-restructuredtext-lint python3-doc8 | python-doc8 > you could do it like sbuild and ... create a dummy binary package That is a bit ugly IMO, I would prefer #275379 to get implemented. > Alternatively, sbuild would be happy with parsing the .dsc you already provide > and pass the contents of the Build-Depends field to apt. That would work for sbuild because build-essential is installed in build chroots, but not for cats more generally. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#844295: [lightdm] "FAILED to start Light Desktop Manager" errors after dpkg-reconfigure lightdm and choosing another desktop manager
Package: lightdm Version: 1.18.2-2 Severity: normal Dear maintainers Thanks for your work in lightdm!! I just upgraded my desktop from jessie to stretch. I use lightdm and KDE plasma. I did: dpkg-reconfigure lightdm and chose "kdm" as my default desktop manager, just to try kdm. Then when I boot the PC, I get "FAILED to start light display manager" errors. If I do dpkg-reconfigure lightdm and I choose lightdm again, the errors disappear. I guess the service is not correctly disabled when I choose a different desktop manager. If I should report this bug against a different package, please tell. Best regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona --- System information. --- Architecture: amd64 Kernel: Linux 4.7.0-1-amd64 Debian Release: stretch/sid 500 testing httpredir.debian.org --- Package information. --- Depends (Version) | Installed =-+-== adduser | 3.115 dbus | 1.10.12-1 libpam-systemd | 231-9 OR consolekit | 0.4.6-5 lightdm-gtk-greeter | 2.0.1-2 OR lightdm-greeter | debconf (>= 0.5) | 1.5.59 OR debconf-2.0 | libaudit1 (>= 1:2.2.1) | 1:2.6.7-1 libc6 (>= 2.14) | libgcrypt20 (>= 1.7.0) | libglib2.0-0 (>= 2.37.3) | libpam0g (>= 0.99.7.1) | libxcb1 | libxdmcp6 | Recommends (Version) | Installed ===-+-=== xserver-xorg | 1:7.7+16 Suggests (Version) | Installed ==-+-=== accountsservice | 0.6.40-3 upower | 0.99.4-4
Bug#844294: gnome-shell-extensions: Please re-enable nautilus-classic in gnome-classic.session
Package: gnome-shell-extensions Version: 3.22.2-1 Severity: normal Dear Maintainer, With gnome 3.22 the nautilus process was split into a desktop part and a file manager part. Since this change afaics, starting the gnome classic session no longer shows icons on the desktop and one has to manually start +f2 "nautilus-desktop" on each session start. Please consider dropping the debian patch (dont-require-nautilus-classic.patch) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-shell-extensions depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2 ii gir1.2-atk-1.0 2.22.0-1 ii gir1.2-clutter-1.0 1.26.0+dfsg-1 ii gir1.2-gdkpixbuf-2.0 2.36.0-1 ii gir1.2-glib-2.0 1.50.0-1 ii gir1.2-gmenu-3.0 3.13.3-8 ii gir1.2-gtk-3.0 3.22.3-2 ii gir1.2-mutter-3.03.22.2-1 ii gir1.2-pango-1.0 1.40.3-3 ii gnome-session3.22.2-1 ii gnome-shell 3.22.2-1 ii gvfs 1.30.2-2 Versions of packages gnome-shell-extensions recommends: ii gnome-tweak-tool 3.22.0-1 gnome-shell-extensions suggests no packages. -- no debconf information
Bug#844290: criu FTBFS if source directory has a tilde in it
On 2016-11-14 07:47, Salvatore Bonaccorso wrote: Are you sure it is related to the ~ in the directory name? it builds otherwise fine on stretch, yes. Regards, Daniel
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
Hi, Quoting Paul Wise (2016-11-14 08:12:03) > I haven't yet found a way to resolve recommends to a definitive list of > package=version tuples why do you have to supply the exact version as well? > and that would probably be undesirable anyway, so the WIP patch creates a > fake .dsc containing a Build-Depends line with the requested check > dependencies in it and passes that to apt build-dep, but unfortunately that > installs build-essential, which would be too much in situations where > build-essential isn't installed yet. > > https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/commit/?h=wip/install&id=1271658cf0e143fb6da6fff96219ecb2ff42b2ed you could do it like sbuild and instead of assembling a .dsc, create a dummy binary package. Either using equivs or by manually creating DEBIAN/control and then running dpkg-deb. This would avoid the build-essential dependency. Here is how sbuild does it: http://sources.debian.net/src/sbuild/0.72.0-2/lib/Sbuild/ResolverBase.pm/#L947 Alternatively, sbuild would be happy with parsing the .dsc you already provide and pass the contents of the Build-Depends field to apt. Thanks! cheers, josch signature.asc Description: signature
Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)
On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote: > > Looking at mod_ssl_openssl.h and the comment in #828330, > > I'd suggest the change below to add a dependency on libssl1.0-dev > > to apache2-dev. > > And that exactly happens meaning that PHP 7.0 can no longer be built > unless all it's build-depends (including PHP 7.0) and rdepends move to > libssl1.0-dev as well. > > So a nice deadlock, right? To be honest I would rather have a slightly > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go > than revert all the work I have done. > > I reviewed the patch Kurt has provided and I don't see any strong reason > why anything should break. >... Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when Apache itself uses 1.1? That is the most important question here. This is what my "mod_ssl_openssl.h and the comment in #828330" was referring to. The dual 1.0.2/1.1 setup for stretch can only work when any set of packages in the archive that needs the same OpenSSL version stays at 1.0.2 unless *all* packages in this set are compiling and working fine with 1.1 And since the OpenSSL version used is part of the libcurl3 ABI (see #844018 for details), using 1.1 in stretch is anyway not really an option for Apache/PHP in stretch. 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#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
On Mon, 2016-11-14 at 08:01 +0100, Johannes Schauer wrote: > Yes. That's why the existing lintian, autopkgtest and piuparts checkers are > disabled by default. I don't think they should be part of it at all but anyway... > What is "cats"? If it's check-all-the-things, then I don't see what the "s" is > doing at the end. Check-All-The-thingS: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README#n96 https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/commit/doc/README?id=037828554a68b64870022398b96705eb8059db2b You can blame paultag/zack for that. > As far as sbuild is concerned, it doesn't need check-all-the-things to call > apt > itself. It would be sufficient if check-all-the-things would somehow produce a > list of binary packages that sbuild will then install using whatever resolver > the user selected. I haven't yet found a way to resolve recommends to a definitive list of package=version tuples and that would probably be undesirable anyway, so the WIP patch creates a fake .dsc containing a Build-Depends line with the requested check dependencies in it and passes that to apt build-dep, but unfortunately that installs build-essential, which would be too much in situations where build-essential isn't installed yet. https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/commit/?h=wip/install&id=1271658cf0e143fb6da6fff96219ecb2ff42b2ed -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#818702: Old mscompress already has msexpand
Quack, On 2016-11-14 04:06, Julius Schwartzenberg wrote: I just discovered that there's an old package already called mscompress which contains an msexpand binary. This binary seems to support fewer formats than the one from libmspack though. Thanks for the report; it would be nice to simplify indeed. My suggestion would be to remove the mscompress package and replace it with the binaries from libmspack. The sources in test/ are clearly not indented to be more than mere tests. As for the expand functionality, test/expand.c should work but the command line options differ, so as is it cannot be renamed and replace mscompress's one directly. I see no program to compress, so I guess it would have to be written. I don't have time for this, but patches are welcome. \_o< -- Marc Dequènes
Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures
- lu...@debian.org wrote: > > Do you have the logs from the last run? > > While we could disable the test that's failing, it would be > counterproductive since we can't reproduce the issue in any of our > normal build environments. > > This is the log without your patch applied > > Lucas Or did you mean with? It's failing in a different way. I think the way it's failing here is to do with insufficient system resources. -- Lars
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
Hi, Quoting Paul Wise (2016-11-14 07:55:59) > I expect blhc will work for packages that use clang too? maybe. The man page says "Only gcc is detected as compiler at the moment". > > So instead of adding a checker for gcc-based packages today... > > sbuild is a tool for building packages, I don't think it should be > running any QA related tools at all, unless maybe someone manually > configured a hook for this. Yes. That's why the existing lintian, autopkgtest and piuparts checkers are disabled by default. > > How about running check-all-the-things, for example? > > See above but I mainly see cats as something to be run manually. What is "cats"? If it's check-all-the-things, then I don't see what the "s" is doing at the end. > cats will tell you at the end which commands are missing and there is a WIP > branch for automatically installing the right stuff using apt, unfortunately > I won't be merging that because apt build-dep installs build-essential as > well as the requested packages. > > https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/log/?h=wip/install > > The heuristics available in cats are currently only filename and mime type, > as well as a way to check that commands are installed properly, for > everything else you would need to insert a grep into the command. > > https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/build-logs As far as sbuild is concerned, it doesn't need check-all-the-things to call apt itself. It would be sufficient if check-all-the-things would somehow produce a list of binary packages that sbuild will then install using whatever resolver the user selected. Thanks! cheers, josch signature.asc Description: signature
Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures
- lu...@debian.org wrote: > > Do you have the logs from the last run? > > While we could disable the test that's failing, it would be > counterproductive since we can't reproduce the issue in any of our > normal build environments. > > This is the log without your patch applied > > Lucas And with the patch? -- Lars
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
On Mon, 2016-11-14 at 06:40 +0100, Johannes Schauer wrote: > blhc on the other hand is only applicable for packages that run gcc at some > point during the build and will never be useful for all the other packages. I expect blhc will work for packages that use clang too? > So instead of adding a checker for gcc-based packages today... sbuild is a tool for building packages, I don't think it should be running any QA related tools at all, unless maybe someone manually configured a hook for this. > How about running check-all-the-things, for example? See above but I mainly see cats as something to be run manually. > I do not have much experience with it, but it might be possible to > find a good way to run it as part of sbuild with the right checks? Running cats in the post-build tree is a bit rarer and noisier. > It also supports running blhc. cats currently unconditionally runs blhc on any build logs that were found. > I wonder if there exists a heuristic to know which Recommends to be install? cats will tell you at the end which commands are missing and there is a WIP branch for automatically installing the right stuff using apt, unfortunately I won't be merging that because apt build-dep installs build-essential as well as the requested packages. https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/log/?h=wip/install The heuristics available in cats are currently only filename and mime type, as well as a way to check that commands are installed properly, for everything else you would need to insert a grep into the command. https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/build-logs -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#844290: criu FTBFS if source directory has a tilde in it
Hi Daniel, Thanks for your report! On Mon, Nov 14, 2016 at 07:14:15AM +0100, Daniel Baumann wrote: > Package: criu > Version: 2.7-2 > > Hi, > > if the criu source directory contains a tilde, the package fails to > build from source, e.g.: > > apt-get source criu && mv criu-2.7 criu-2.7-2~local1 && cd > criu-2.7-2~local1 && dpkg-buildpackage Are you sure it is related to the ~ in the directory name? I just found out that 2.7-2 (which build previously on unstable, see buildd logs), now FTBFS. I'm opening a serious bug for this. Regards, Salvatore
Bug#844293: criu: FTBFS: ld: unrecognized option '-specs=/usr/share/dpkg/no-pie-link.specs'
Source: criu Version: 2.7-2 Severity: serious Justification: FTBFS but built previously with same version (related to changes in unstable) 2.7-2 built previously sucessfully, but recent changes in unstable make it FTBFS: make[3]: Entering directory '/build/criu-2.7' make[3]: Entering directory '/build/criu-2.7' GEN criu/arch/x86/../../include/syscall-codes.h GEN criu/arch/x86/../../include/syscall.h DEP criu/pie/piegen/main.d DEP criu/pie/piegen/elf-x86-64.d DEP criu/pie/piegen/elf-x86-32.d GEN criu/arch/x86/syscalls.S DEP criu/arch/x86/syscalls.d GEN criu/arch/x86/sys-exec-tbl.c CC criu/arch/x86/syscalls.o CC criu/pie/piegen/elf-x86-32.o CC criu/pie/piegen/elf-x86-64.o CC criu/pie/piegen/main.o LINK criu/arch/x86/syscalls.built-in.o ld: unrecognized option '-specs=/usr/share/dpkg/no-pie-link.specs' ld: use the --help option for usage information /build/criu-2.7/scripts/nmk/scripts/build.mk:150: recipe for target 'criu/arch/x86/syscalls.built-in.o' failed make[3]: *** [criu/arch/x86/syscalls.built-in.o] Error 1 make[3]: Leaving directory '/build/criu-2.7' criu/Makefile:56: recipe for target 'syscalls_lib' failed make[2]: *** [syscalls_lib] Error 2 make[2]: *** Waiting for unfinished jobs LINK criu/pie/piegen/built-in.o ld: unrecognized option '-specs=/usr/share/dpkg/no-pie-link.specs' ld: use the --help option for usage information /build/criu-2.7/scripts/nmk/scripts/build.mk:150: recipe for target 'criu/pie/piegen/built-in.o' failed make[3]: *** [criu/pie/piegen/built-in.o] Error 1 make[3]: Leaving directory '/build/criu-2.7' criu/Makefile:71: recipe for target 'criu/pie/piegen/built-in.o' failed make[2]: *** [criu/pie/piegen/built-in.o] Error 2 make[2]: Leaving directory '/build/criu-2.7' Makefile:199: recipe for target 'criu' failed make[1]: *** [criu] Error 2 make[1]: Leaving directory '/build/criu-2.7' dh_auto_build: make -j8 returned exit code 2 debian/rules:9: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Salvatore
Bug#844274: [FP] wildcard-matches-nothing-in-dep5-copyright should not be raised for deleted files
Bastien ROUCARIÈS: > Package: lintian > Version: 2.5.49 > Severity: normal > > wildcard-matches-nothing-in-dep5-copyright is raised for files deleted by > patch > > This is a false positive. Copyright exist even if files are deleted. > Copyright > is against origin + debian files > > nthykier do you have how to avoid this kind of problem ? > > Bastien > You would have to use the "src-orig-index" and the related API. Mind you, it has never been used before so it is completely untested. ~Niels
Bug#844292: kerneloops FTCBFS: uses build architecture pkg-config, gcc
Source: kerneloops Version: 0.12+git20140509-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap kerneloops fails to cross build from source, because it uses build architecture tools in a few remaining places. dh_auto_build already substitutes CC, but the Makefile still invokes a plain pkg-config and has two plain gcc calls. Substituting all calls makes the cross build succeed. Please consider applying the attached patch. Helmut diff --minimal -Nru kerneloops-0.12+git20140509/debian/changelog kerneloops-0.12+git20140509/debian/changelog --- kerneloops-0.12+git20140509/debian/changelog2016-09-15 00:18:47.0 +0200 +++ kerneloops-0.12+git20140509/debian/changelog2016-11-14 07:29:15.0 +0100 @@ -1,3 +1,10 @@ +kerneloops (0.12+git20140509-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use triplet-prefixed pkg-config (Closes: #-1) + + -- Helmut Grohne Mon, 14 Nov 2016 07:29:15 +0100 + kerneloops (0.12+git20140509-5) unstable; urgency=medium * Rename conffile in maintainer scripts properly (Closes: 837760) diff --minimal -Nru kerneloops-0.12+git20140509/debian/patches/0005-cross.patch kerneloops-0.12+git20140509/debian/patches/0005-cross.patch --- kerneloops-0.12+git20140509/debian/patches/0005-cross.patch 1970-01-01 01:00:00.0 +0100 +++ kerneloops-0.12+git20140509/debian/patches/0005-cross.patch 2016-11-14 07:29:15.0 +0100 @@ -0,0 +1,47 @@ +Subject: fix cross compilation +From: Helmut Grohne + +Allow substituting pkg-config with a triplet-prefixed version. + +Allow substituting gcc with a triplet-prefixed version in all places. + +Index: kerneloops-0.12+git20140509/Makefile +=== +--- kerneloops-0.12+git20140509.orig/Makefile kerneloops-0.12+git20140509/Makefile +@@ -9,17 +9,18 @@ + LOCALESDIR=/usr/share/locale + MANDIR=/usr/share/man/man8 + CC?=gcc ++PKG_CONFIG?=pkg-config + + CFLAGS ?= -O2 -g -fstack-protector -D_FORTIFY_SOURCE=2 -Wall -W -Wstrict-prototypes -Wundef -fno-common -Werror-implicit-function-declaration -Wdeclaration-after-statement -Wformat -Wformat-security -Werror=format-security + +-MY_CFLAGS = $(shell pkg-config --cflags libnotify gtk+-2.0 dbus-glib-1) ++MY_CFLAGS = $(shell $(PKG_CONFIG) --cflags libnotify gtk+-2.0 dbus-glib-1) + # + # pkg-config tends to make programs pull in a ton of libraries, not all + # are needed. -Wl,--as-needed tells the linker to just drop unused ones, + # and that makes the applet load faster and use less memory. + # +-LDF_A ?= -Wl,--as-needed $(shell pkg-config --libs libnotify gtk+-2.0 dbus-glib-1) $(LDFLAGS) +-LDF_D ?= -Wl,--as-needed $(shell pkg-config --libs glib-2.0 dbus-glib-1) $(shell curl-config --libs) -Wl,"-z relro" -Wl,"-z now" $(LDFLAGS) ++LDF_A ?= -Wl,--as-needed $(shell $(PKG_CONFIG) --libs libnotify gtk+-2.0 dbus-glib-1) $(LDFLAGS) ++LDF_D ?= -Wl,--as-needed $(shell $(PKG_CONFIG) --libs glib-2.0 dbus-glib-1) $(shell curl-config --libs) -Wl,"-z relro" -Wl,"-z now" $(LDFLAGS) + + all: kerneloops kerneloops-applet kerneloops.8.gz + +@@ -30,11 +31,11 @@ + + + kerneloops: kerneloops.o submit.o dmesg.o configfile.o kerneloops.h +- gcc kerneloops.o submit.o dmesg.o configfile.o $(LDF_D) -o kerneloops ++ $(CC) kerneloops.o submit.o dmesg.o configfile.o $(LDF_D) -o kerneloops + @(cd po/ && $(MAKE)) + + kerneloops-applet: kerneloops-applet.o +- gcc kerneloops-applet.o $(LDF_A) -o kerneloops-applet ++ $(CC) kerneloops-applet.o $(LDF_A) -o kerneloops-applet + + kerneloops.8.gz: kerneloops.8 + gzip -9 -c $< > $@ diff --minimal -Nru kerneloops-0.12+git20140509/debian/patches/series kerneloops-0.12+git20140509/debian/patches/series --- kerneloops-0.12+git20140509/debian/patches/series 2016-09-15 00:18:47.0 +0200 +++ kerneloops-0.12+git20140509/debian/patches/series 2016-11-14 07:27:53.0 +0100 @@ -2,3 +2,4 @@ 0002-n-is-two-characters-long.patch 0003-Don-t-parse-newline-to-configured-values.patch 0004-Use-oops.kernel.org-host.patch +0005-cross.patch diff --minimal -Nru kerneloops-0.12+git20140509/debian/rules kerneloops-0.12+git20140509/debian/rules --- kerneloops-0.12+git20140509/debian/rules2016-09-15 00:18:47.0 +0200 +++ kerneloops-0.12+git20140509/debian/rules2016-11-14 07:29:14.0 +0100 @@ -4,6 +4,9 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +include /usr/share/dpkg/architecture.mk +export PKG_CONFIG=$(DEB_HOST_GNU_TYPE)-pkg-config + export DEB_BUILD_MAINT_OPTIONS = hardening=+all # This has to be exported to make some magic below work.
Bug#841592: Fwd: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures
Forgot the bug -- Lars--- Begin Message --- - lu...@debian.org wrote: > On 09/11/16 at 07:27 -0800, Lars Tangvald wrote: > > > > - lu...@debian.org wrote: > > > > > > > > Hi, > > > > > > I don't think that my test is run as root. So it might be > something > > > else... > > > > > > Lucas > > > > The error message is access denied for 'root'@'localhost', but the > test itself tries to log in as the current system user (it's supposed > to be blank, but that's not working right), so it does seem to be > running as root. However, if I try a full sbuild as root, there are > some other tests that will fail too, so it doesn't seem like the test > suite in general is running as root. > > > > I've made a patch that should fix the test to actually specify a > blank user. Are you able to test your build with the head of > https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/log/?h=mysql-5.7/ltangvald > ? > > It's the same as the 5.7.16 uploaded to unstable, just with that one > extra commit. > > Hi, > > I can confirm that it does not fix the problem; sorry. > > Lucas Do you have the logs from the last run? While we could disable the test that's failing, it would be counterproductive since we can't reproduce the issue in any of our normal build environments. -- Lars --- End Message ---
Bug#828247: fixed in bip 0.8.9-1.1
Quack, On 2016-11-14 03:47, Salvatore Bonaccorso wrote: Just to clarify: the issue is not that it does not build with libssl1.0-dev, but that it does not build with libssl-dev. Thus the reopening since the bug is about src:bip (not) building with OpenSSL 1.1. You're right. In fact the build problem I found out was with libssl-dev indeed, because I did not check the the B-D and unfortunately the NMU was not added to collab-maint as it should have… Don't know if the new upstream release fixes this, but I assume Kurt and the OpenSSL team will be more than happy if this is the case and the Build-Depends can be switched back to libssl-dev in that course. It does :-) https://projects.duckcorp.org/projects/bip/repository/revisions/39414f8ff9df63c8bc2e4eee34f09f829a5bf8f5 Regards and thanks for your work on it, In fact that's Pilou's work, I'm just around as a Debian mentor. Thanks for the clarification. -- Marc Dequènes
Bug#823004: gplaycli: sensitive information in config file
On Sun, 2016-11-13 at 10:53 +0100, Matlink wrote: > Another solution would be to tell gplaycli to fetch the credentials > from a server. In this case, when the credentials are changed, I just > have to change this file on the server and every instance of gplaycli > will fetch this file and have the new credentials. You could combine the two options. Keep the credentials in gplaycli and release new versions when they change. When gplaycli detects that the default credentials are in use and that the default credentials are incorrect, then get the new default credentials (over Tor if possible). -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#844290: criu FTBFS if source directory has a tilde in it
Package: criu Version: 2.7-2 Hi, if the criu source directory contains a tilde, the package fails to build from source, e.g.: apt-get source criu && mv criu-2.7 criu-2.7-2~local1 && cd criu-2.7-2~local1 && dpkg-buildpackage Regards, Daniel
Bug#844291: timidity FTBFS: fails to rebuild configure from configure.in, automake1.9 is no longer in unstable
Source: timidity Version: 2.13.2-40.5 Severity: serious Justification: configure cannot be built from source User: helm...@debian.org Usertags: rebootstrap timidity still builds fine on buildds, because it uses ./configure as a pre-built artifact. Unfortunately ./configure cannot be regenerated anymore, because autogen.sh relies on aclocal-1.9 which was formerly part of automake1.9. The latter got removed from unstable two years ago. There are essentially three ways to resolve this bug: * Move timidity to a newer automake. * Reintroduce automake1.9 into unstable. * Remove timidity. Helmut
Bug#844289: joe FTCBFS: uses build architecture toolchain
Source: joe Version: 4.3-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap joe fails to cross build from source, because it configures the build for the build architecture (by failure of passing --host) and uses the build architecture strip. The attached patch addresses both issues and makes joe cross build. Alternatively, moving to dh_auto_configure and dh_strip also fixes the cross build as both tools are well aware of cross building. Please consider applying the attached patch or moving to debhelper. Helmut diff --minimal -Nru joe-4.3/debian/changelog joe-4.3/debian/changelog --- joe-4.3/debian/changelog2016-11-06 14:40:14.0 +0100 +++ joe-4.3/debian/changelog2016-11-14 06:48:12.0 +0100 @@ -1,3 +1,12 @@ +joe (4.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: closes: #-1 ++ Pass --host to ./configure ++ Use triplet-prefixed strip + + -- Helmut Grohne Mon, 14 Nov 2016 06:48:12 +0100 + joe (4.3-1) unstable; urgency=low * New upstream version. diff --minimal -Nru joe-4.3/debian/rules joe-4.3/debian/rules --- joe-4.3/debian/rules2016-11-06 14:39:13.0 +0100 +++ joe-4.3/debian/rules2016-11-14 06:48:11.0 +0100 @@ -1,5 +1,7 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk + tmp := $(CURDIR)/debian/joe docdir := $(tmp)/usr/share/doc/joe @@ -8,6 +10,10 @@ CFLAGS += -O2 endif +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +CONFIGURE_FLAGS += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) +endif + build: build-indep build-arch build-indep: @@ -17,7 +23,7 @@ config.status: dh_autoreconf CFLAGS="$(CFLAGS)" ./configure --sysconfdir=/etc --prefix=/usr \ - --mandir='$${datadir}/man' + --mandir='$${datadir}/man' $(CONFIGURE_FLAGS) joe/joe: joe/main.c $(MAKE) @@ -32,7 +38,7 @@ rm -rf $(tmp) $(MAKE) DESTDIR=$(tmp) install ifeq "$(findstring nostrip,$(DEB_BUILD_OPTIONS))" "" - strip --remove-section=.comment --remove-section=.note $(tmp)/usr/bin/joe + $(DEB_HOST_GNU_TYPE)-strip --remove-section=.comment --remove-section=.note $(tmp)/usr/bin/joe endif rm -f $(tmp)/usr/bin/termidx gzip -9 $(tmp)/usr/share/man/man1/joe.1
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
Hi, Quoting Sean Whitton (2016-11-13 22:37:15) > It might be nice if sbuild could run blhc(1), just like it runs lintian, > autopkgtest and piuparts. sbuild supports running lintian, autopkgtest and piuparts because they are (or should) be applicable to *all* Debian packages. blhc on the other hand is only applicable for packages that run gcc at some point during the build and will never be useful for all the other packages. So instead of adding a checker for gcc-based packages today, one for OCaml packages tomorrow and then 20 more for all the other programming languages we have in Debian, I'd rather implement support for a wrapper to these tools which is then doing the right thing. How about running check-all-the-things, for example? I do not have much experience with it, but it might be possible to find a good way to run it as part of sbuild with the right checks? It also supports running blhc. It also has loads of Recommends which will not get installed by the current sbuild resolver which will ignore Recommends and Suggests. On the other hand, one probably only ever wants to install a subset of these, depending on the source package at hand. blhc for example should only be installed for source packages actually making use of gcc. I wonder if there exists a heuristic to know which Recommends to be install? CC-ing pabs for advice. > deb-o-matic recently started doing this. that sounds like there is already a patch? Thanks! cheers, josch signature.asc Description: signature
Bug#843478: No rdeps now
JFTR kamailio stopped building with libval-dev (and has unrelated FTBFS on powerpc), so I think it's safe to remove this package now. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu
Bug#844288: gnome: Laptop monitor goes black when external monitor connected
Package: gnome Version: 1:3.14+3 Severity: important Dear Maintainer, The problem occurs on a 13" Macbook pro (mid 2012). Problem (bug situation): The laptop monitor turns black when connected to an external monitor. Adjusting the laptop monitor brightness has no effect. If the external monitor is disconnected while the laptop monitor is black, the laptop monitor remains black and the main remedy is a hard reset. Work around: Changing the resolution of the external monitor to another (lower or higher) resolution, then changing the resolution again to another (lower or higher but usually the optimal screen) resolution causes the laptop monitor to work normally. Sometimes the process needs to be repeated several times to work. Similar bugs This bug is similar to bug #776358 but differs because Adjusting the laptop monitor brightness has no effect on the problem. System Details: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) Processor: Intel® Core™ i5-3210M CPU @ 2.50GHz × 4 Graphics: Intel® Ivybridge Mobile -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome depends on: ii alacarte 3.11.91-2 ii avahi-daemon 0.6.31-5 ii bijiben3.14.2-1+b1 ii brasero3.11.4-1.1 ii cheese 3.14.1-2 ii cups-pk-helper 0.2.5-2+b1 ii desktop-base 8.0.2 ii evolution 3.12.9~git20141130.241663-1+b1 ii evolution-plugins 3.12.9~git20141130.241663-1+b1 ii file-roller3.14.1-1 ii gedit 3.14.0-3 ii gedit-plugins 3.14.0-2 ii gimp 2.8.14-1+deb8u1 ii gnome-clocks 3.14.1-1 ii gnome-color-manager3.14.1-1 ii gnome-core 1:3.14+3 ii gnome-documents3.14.2-1 ii gnome-games1:3.14+3 ii gnome-getting-started-docs 3.14.1-1 ii gnome-logs 3.14.2-1 ii gnome-maps 3.14.3.1-1 ii gnome-music3.14.1-1 ii gnome-nettool 3.8.1-1 ii gnome-orca 3.14.0-4+deb8u1 ii gnome-photos 3.14.2-1 ii gnome-shell-extension-weather 0~20151125.gitccaa1eb-1~deb8u1 ii gnome-sound-recorder 3.14.0.1-1 ii gnome-tweak-tool 3.14.2-2 ii goobox 3.3.1-6 ii gstreamer1.0-libav 1.4.4-2 ii gstreamer1.0-plugins-ugly 1.4.4-2+b1 ii hamster-applet 2.91.3+git20120514.b9fec3e1-1 ii inkscape 0.48.5-3 ii libgtk2-perl 2:1.2492-4 ii libreoffice-calc 1:4.3.3-2+deb8u5 ii libreoffice-evolution 1:4.3.3-2+deb8u5 ii libreoffice-gnome 1:4.3.3-2+deb8u5 ii libreoffice-impress1:4.3.3-2+deb8u5 ii libreoffice-writer 1:4.3.3-2+deb8u5 ii nautilus-sendto3.8.2-1 ii network-manager-gnome 0.9.10.0-2 ii polari 3.14.1-1 ii rhythmbox 3.1-1 ii rhythmbox-plugin-cdrecorder3.1-1 ii rhythmbox-plugins 3.1-1 ii rygel-playbin 0.24.2-1+b1 ii rygel-tracker 0.24.2-1+b1 ii seahorse 3.14.0-2 ii simple-scan3.14.0-1 ii telepathy-gabble 0.18.3-1+b1 ii telepathy-rakia0.8.0-3 ii telepathy-salut0.8.1-4 ii totem-plugins 3.14.0-2 ii transmission-gtk 2.84-0.2 ii vinagre3.14.1-1 ii xdg-user-dirs-gtk 0.10-1 Versions of packages gnome recommends: pn gnome-software Versions of packages gnome suggests: pn iceweasel-l10n-all pn xul-ext-adblock-plus pn xul-ext-gnome-keyring Versions of packages gnome-core depends on: ii adwaita-icon-theme 3.14.0-2 ii at-spi2-core 2.14.0-1 ii baobab 3.14.1-1 ii caribou0.4.15-1 ii caribou-antler 0.4.15-1 ii dconf-gsettings-backend0.22.0-1 ii dconf-tools0.22.0-1 ii empathy3.12.7-1 ii eog3.14.1-1 ii evince 3.14.1-2+deb8u1 ii evolution-data-server 3.12.9~git20141128.5242b0-2+deb8u2 ii fonts-cantarell0.0.16-1 ii gdm3 3.14.1-7 ii gkbd-capplet 3.6
Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)
> Looking at mod_ssl_openssl.h and the comment in #828330, > I'd suggest the change below to add a dependency on libssl1.0-dev > to apache2-dev. And that exactly happens meaning that PHP 7.0 can no longer be built unless all it's build-depends (including PHP 7.0) and rdepends move to libssl1.0-dev as well. So a nice deadlock, right? To be honest I would rather have a slightly less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go than revert all the work I have done. I reviewed the patch Kurt has provided and I don't see any strong reason why anything should break. ~~~ ssl_engine_io_init() is called but return value is not checked although it might obviously fail as the function can return 0 on failure. ~~~ This bit looks suspicious as it changes the existing behavior: -/* XXX: Should replace setting state with SSL_renegotiate(ssl); - * However, this causes failures in perl-framework currently, - * perhaps pre-test if we have already negotiated? - */ -#ifdef OPENSSL_NO_SSL_INTERN -SSL_set_state(ssl, SSL_ST_ACCEPT); -#else -ssl->state = SSL_ST_ACCEPT; -#endif +/* XXX: Why is this done twice? */ +SSL_renegotiate(ssl); +/* XXX: Return value ignored, uses SSL_get_state instead? */ but it might be correct... ~~~ There also seem to be some changes unrelated to OpenSSL 1.1.0 as: -RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH); +/* XXX: Return value not checked. */ +RAND_bytes(iv, EVP_MAX_IV_LENGTH); or adding: +SRP_user_pwd_free(u); I think this should be in separate patch. ~~~ Kurt, can you confirm this doesn't change behavior of the code? -else if (cert->valid && X509_check_issued(cert,cert) == X509_V_OK) { +else if (X509_check_issued(cert, cert) == X509_V_OK) { ~~~ Wrong ws here: -nid = OBJ_obj2nid((ASN1_OBJECT *)(xs->cert_info->key->algor->algorithm)); +X509_PUBKEY *pubkey = X509_get_X509_PUBKEY(xs); + X509_ALGOR *algor; + X509_PUBKEY_get0_param(NULL, NULL, NULL, &algor, pubkey); +nid = OBJ_obj2nid(algor->algorithm); and here: @@ -398,7 +403,9 @@ static int stapling_check_response(serve if (bio) { int n; -if ((i2a_ASN1_INTEGER(bio, cinf->cid->serialNumber) != -1) && +ASN1_INTEGER *serial; + OCSP_id_get0_info(NULL, NULL, NULL, &serial, cinf->cid); +if ((i2a_ASN1_INTEGER(bio, serial) != -1) && ((n = BIO_read(bio, snum, sizeof snum - 1)) > 0)) snum[n] = '\0'; BIO_free(bio); Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Sun, Nov 13, 2016, at 13:36, Debian Bug Tracking System wrote: > Your message dated Sun, 13 Nov 2016 12:34:03 + > with message-id > and subject line Bug#844160: fixed in apache2 2.4.23-7 > has caused the Debian Bug report #844160, > regarding apache2-dev should depend on libssl1.0-dev > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what this > message is talking about, this may indicate a serious mail system > misconfiguration somewhere. Please contact ow...@bugs.debian.org > immediately.) > > > -- > 844160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844160 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Email had 2 attachments: > + apache2-dev should depend on libssl1.0-dev > 3k (message/rfc822) > + Bug#844160: fixed in apache2 2.4.23-7 > 8k (message/rfc822)
Bug#844286: grep: Non-deterministic behavior when output redirected to /dev/null
On Sun, Nov 13, 2016 at 08:40:02PM -0500, James McCoy wrote: > The relevant part of the script is just looking for whether patch > numbers are applied or marked NA in neovim's src/nvim/version.c: > > is_missing="$(sed -n '/static int included_patches/,/}/p' > "${NVIM_SOURCE_DIR}/src/nvim/version.c" | > grep -x -e "[[:space:]]*//[[:space:]]${patch_number} NA.*" -e > "[[:space:]]*${patch_number}," >/dev/null && echo "false" || echo "true")" Playing with this some more, I attempted to change this to use “grep -q …” instead of the redirection to /dev/null. This exhibited the same problematic behavior, regardless of which version of grep I was using (back to 2.22). So, the problematic behavior seems to be related to the "immediate exit" behavior of -q (and now also when output is redirected to /dev/null) causing the left-hand side of the pipe to get a SIGPIPE. Since the script has “set -o pipefail”, this causes the "sed … | grep …" to be considered a failure and echo the wrong value. I'm not sure if the above snippet from the script was intentionally using redirection to /dev/null to avoid the SIGPIPE, but if so I can assume that it isn't the only script to do so. The redirection was, prior to the upstream commit, an escape hatch for avoiding SIGPIPE when the exit code was the important data, not the output. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#828286: dovecot-core: upgraded to 1:2.2.26.0-3 and OpenSSL still fails
Package: dovecot-core Version: 1:2.2.26.0-3 Followup-For: Bug #828286 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? apt-get update && apt-get dist-upgrade Also tried building dovecot from source Debian package. * What exactly did you do (or not do) that was effective (or ineffective)? Attempted to disable SSLv2 in /etc/dovecot/conf.d/10-ssl.conf and checked log file as set /var/log/dovecot.log error message is "imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'" Email clients tried were Gmail client app on tablet and K9 app on tablet. * What was the outcome of this action? Clients refuse to connect. * What outcome did you expect instead? Seamless connection as before. Also observed this behvior with dnssec-trigger a few weeks ago. -- Package-specific info: dovecot configuration - # 2.2.26.0 (23d1de6): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.16 (fed8554) # OS: Linux 4.7.0-1-grsec-amd64 x86_64 Debian stretch/sid auth_mechanisms = cram-md5 debug_log_path = /var/log/dovecot-debug.log listen = xx.xx.xx.xx log_path = /var/log/dovecot.log mail_location = maildir:~/Maildir namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Spam { special_use = \Junk } mailbox Trash { special_use = \Trash } prefix = } passdb { args = scheme=cram-md5 /dir driver = passwd-file } passdb { driver = pam } protocols = imap service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } } service imap-login { inet_listener imap { port = 0 } inet_listener imaps { port = 993 ssl = yes } } ssl_cert = ii dovecot-imapd 1:2.2.26.0-3 pn dovecot-ldap pn dovecot-lmtpd pn dovecot-lucene pn dovecot-managesieved pn dovecot-mysql pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.2.26.0-3 pn dovecot-solr pn dovecot-sqlite pn ntp Versions of packages dovecot-core is related to: ii dovecot-core [dovecot-common] 1:2.2.26.0-3 pn dovecot-dbg pn dovecot-dev pn dovecot-gssapi ii dovecot-imapd 1:2.2.26.0-3 pn dovecot-ldap pn dovecot-lmtpd pn dovecot-managesieved pn dovecot-mysql pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.2.26.0-3 pn dovecot-sqlite -- Configuration Files: /etc/default/dovecot changed [not included] -- no debconf information
Bug#844287: Updated Debian mirror submission (debian.mirror.netelligent.ca)
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Control: submitter -1 Netelligent Mirror Admins Forwarded Message Subject: Updated Debian mirror submission (debian.mirror.netelligent.ca) Date: Thu, 20 Oct 2016 17:08:29 + From: Netelligent Mirror Admins To: mirr...@debian.org Submission-Type: update Site: debian.mirror.netelligent.ca Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ CDImage-ftp: /debian-cd/ CDImage-http: /debian-cd/ CDImage-rsync: debian-cd/ IPv6: no Archive-upstream: debian.mirror.rafal.ca CDImage-upstream: cdimage.debian.org Updates: four Maintainer: Netelligent Mirror Admins Country: CA Canada Location: Montreal, Quebec Sponsor: Netelligent Hosting Services Inc. http://www.netelligent.ca Comment: 100 Mbps signature.asc Description: OpenPGP digital signature
Bug#843949: mysql-workbench: Cannot Connect to Database Server
On Friday, 11 November 2016 9:42:59 AM AEDT Ivan Zharenkov wrote: > fresh installed mysql-workbench cannot connect to local mysql server with > error: > > Your connection attempt failed for user 'root' from your host to server at > localhost:3306: > Cannot start SSH tunnel manager Could you please try on 6.3.6+dfsg-1 from "unstable"? Besides I could not reproduce the problem and I've never seen this error before. Are you sure that connection settings are correct? If so then please provide enough details to reproduce. Thanks. -- All the best, Dmitry Smirnov. --- And those who were seen dancing were thought to be insane by those who could not hear the music. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#825380: [Pkg-samba-maint] Bug#825380: winbind: Netbios name resolution can't find Windows clients
That patch seems to have resolved the System error issue. On 14 November 2016 at 07:24, Mathieu Parent wrote: > Hi TIm, > > Can you try the proposed patch: > https://bugzilla.samba.org/attachment.cgi?id=12657&action=edit > > Regards > > 2016-11-13 2:39 GMT+01:00 Tim Boundy : > > Yes, I have 2:4.4.7+dfsg-1 of libnss-winbind installed > > > > I've attached the 'strace ping google.com' output when using wins in > > nsswitch.conf > > > > On 13 November 2016 at 08:44, Mathieu Parent > wrote: > >> > >> is.Hello, > >> > >> 2016-11-09 10:14 GMT+01:00 Tim Boundy : > >> > I've just updated to 2:4.4.7+dfsg-1 to see if there's any improvement. > >> > Massive regression. Now I can't ping via dns. > >> > > >> > ping: google.com: System error > >> > > >> > If I remove wins from nsswitch.conf, dns starts working again. > >> > >> Do you have libnss-winbind installed? This is where libnss_wins.so.2 is. > >> > >> If you already have this package. What does outputs?: > >> > >> sudo strace ping google.com > >> > >> Regards > >> -- > >> Mathieu Parent > > > > > > > > -- > Mathieu >
Bug#840424: RFS: verilog-mode/0:20160910.debfc6d.vpo-1
Dear Sean, On Mon, Nov 14, 2016 at 9:38 AM, Kiwamu Okabe wrote: > I would like to support xemacs with verilog-mode, in the future. > However xemacs-mule package is not installable, today. Indeed, > http://www.xemacs.org seems like shutdown... > > I think I should use dh_elpa if the Debian system will drop supporting xemacs. My Debian environment has had error with following known bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844176 I would like to support xemacs on this package. I'm testing this package in the git repository with xemacs without emacs-goodies-el. Also it's tested by pbulilder. Best regards, -- Kiwamu Okabe at METASEPI DESIGN
Bug#839381: xserver-xorg-video-amdgpu: very long Xorg initilization time in recent kernels
On 13/11/16 09:09 PM, Michael Strobel wrote: > Hi, > > i think i found the problem: it's powerplay. The bisection showed that > 3466904d38ff1e63f0a19cb31166db67f2d05c61 is the commit which introduced > the problem: > > while the code before checked if amdgpu_powerplay > 0 now it checks > equality. The default value is -1 so pp is enabled. I booted with > amdgpu.powerplay=0 and the problem is gone for the testing kernel 4.7. > > I tried a more recent kernel (4.9-rc5) and it seemed that it's not > checked anymore if amdgpu.powerplay equals 0. I'm adding a patch which > re enables the boot parameter. > > Furthermore i'm not sure what causes the problem with my GPU in the > first place. If there is anything i can do please let me know. Adding the amd-gfx mailing list to Cc. This bug report should be reassigned to the kernel package. > On 10/03/2016 04:45 AM, Michel Dänzer wrote: >> On 01/10/16 06:30 PM, Michael Strobel wrote: >>> Package: xserver-xorg-video-amdgpu >>> Version: 1.1.2-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> i'm running debian testing and for quite a while i have problems with my >>> xserver on newer kernels. While linux-image-4.2.0-1-amd64 works fine >>> linux-image-4.6.0-1-amd64 and linux-image-4.7.0-1-amd64 my xserver spends >>> very long time (several minutes) on initialization. >>> The only problem i can spot is a lot of >>> >>> Failed to send Previous Message. >>> Failed to send Message. >>> >>> messages in dmesg. I'm not complete sure if the problem is even xserver >> >> Yeah, unless this doesn't happen with an older version of >> xserver-xorg-video-amdgpu (and possibly related packages), it sounds >> like an amdgpu kernel driver regression. Any chance you can bisect or at >> least narrow down which kernel version introduced the problem? >> >> > -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#842579: #842579 cdebootstrap: Internal error when trying to create a system
Interesting thing is that command used to work successfully with cdebootstrap v0.6.4 but it fails with v0.7.5 and v0.7.6... For now I removed (e2fsprogs, init) packages from "exclude" to fix the problem. Is there a way to pass something like "--allow-remove-essential" through cdebootstrap command line? Thanks. -- Regards, Dmitry Smirnov. --- Success consists of going from failure to failure without loss of enthusiasm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#767682: We could not deliver your parcel, #8886715
Hello, Your parcel has arrived at 14.11.2016. Courier was unable to deliver the parcel to you. Please, download Delivery Label attached to this email. Shiloh Poulos - Area Manager FedEx , CA Yours trully FedEx.doc Description: MS-Word document
Bug#819300: should provide default HTTPS mirrors for non-Debian releases too
Control: tag -1 moreinfo On Sat, Mar 26, 2016 at 10:51:21AM +0100, Evgeni Golov wrote: > Package: debootstrap > Version: 1.0.80 > Severity: wishlist > > Hi, > > currently debootstrap only knows about an HTTPS mirror for Debian, but not > e.g. for Ubuntu. Does ubuntu even run https mirrors? A pointer to official documentation would be appreciated, I couldn't find it in a quick search. Cheers, Julien
Bug#842380: gitlab-ci-multi-runner: mk-prebuilt-images.sh fails at install time
Hi Vincent, Sorry it took so long for me to get back to this problem... On Sunday, 30 October 2016 3:03:19 PM AEDT Vincent Danjean wrote: > So, I will try to argue a little bit more ;-) :) > Do you try the cdebootstrap command itself? Yes, through mk-prebuilt-images.sh and directly during development of mk- prebuilt-images.sh. It actually works with cdebootstrap v0.6.4 but not with later versions... > Setting up gitlab-ci-multi-runner (1.7.1+dfsg-1) ... > W: Docker is not available. Docker is required to generate image... > atsina:/tmp/test# cdebootstrap \ > --flavour=minimal \ > --exclude="dmsetup,e2fsprogs,init,systemd-sysv,systemd,udev" \ > --include="bash,ca-certificates,git,netcat-traditional" \ > stable ./debian-minbase |& tee /tmp/log > P: Retrieving Release > P: Retrieving Release.gpg > [...] > P: Configuring helper cdebootstrap-helper-apt > E: Internal error: install This may suggest an error in cdebootstrap... I see you've already reported #842579 against cdebootstrap -- thank you. > Do the cdebootstrap command really works on your systems? It was working just a few days ago... > I also tried to remove this file. mk-prebuilt-images.sh recreates > a (not working) one. That may give us a clue why it is happening... Do you have enough disk space on the box? Maybe exporting/compressing image runs out of disk space and produce invalid file as result? Anyway I've found a bug that may result in incomplete images because bash ignores errors in comands used with pipe even with "set -e". I've just uploaded fix for that ("set -o pipefail"). > In this case, please remove the bad gitlab-runner-prebuilt.tar.xz > Or ask the user to re-create it with a --force parameter to > mk-prebuilt-images.sh if he wants to keep a probably problematic > image. Noted. I'll think about it. Thanks. For now I've made some changes that should make image generation more reliable. Hopefully "--force" won't be necessary. Thanks again for your help, feedback and testing, Vincent. Just uploaded 1.7.1+dfsg-2 should fix this problem. -- Cheers, Dmitry Smirnov. --- What is the truth, but a lie agreed upon. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#843916: debian-installer: fails to FTBFS when u-boot bits go missing
On 2016-11-10, Cyril Brulebois wrote: > Steve noted that the armel build fails on the cdimage side because > kirkwood/u-boot stuff is missing for openrd. This isn't entirely > surprising because the latest u-boot upload to unstable, which got > used to build debian-installer 20161031 had: > | u-boot (2016.09+dfsg1-2) unstable; urgency=medium > […] > | * Remove openrd targets, as they do not boot (Closes: #837629). > | > | -- Vagrant Cascadian Sun, 23 Oct 2016 19:36:36 -0700 > > I might have missed messages on debian-boot@, but a quick search on > kirkwood or openrd doesn't get me any unread messages warning us about > their imminent removal. It really would be nice to make sure > debian-boot@ knows about such things in advance (even better if I get > explicitly cc'ed on this so as to make sure I don't miss something > affecting next d-i releases). Apologies; I had been intending to commit the removal myself after the openrd testers got back to me, but testing took much longer than expected, and I neglected to follow-up with the removals needed for d-i. I'll make sure with future removals to CC debian-boot if it's one of the targets currently supported in d-i, even if I plan to make the commits myself. live well, vagrant signature.asc Description: PGP signature
Bug#844286: grep: Non-deterministic behavior when output redirected to /dev/null
Package: grep Version: 2.26-1 Severity: grave Tags: upstream Justification: renders package unusable Upstream commit af6af288 causes inconsistent results when output is redirected to /dev/null. I'm setting this to grave because grep is a very common glue and if its results aren't reliable, then there's lots of unknown behavior that may exhibit from things using it. Unfortunately, the simplest test case I've been able to find so far is a script from neovim's source package. $ git clone https://github.com/neovim/neovim $ cd neovim $ ./scripts/vim-patch.sh -l When grep is working properly (i.e., with af6af288 reverted), this should start printing out numbers starting around 7.4.1559. Instead, it is printing out numbers starting around 7.4.630. The relevant part of the script is just looking for whether patch numbers are applied or marked NA in neovim's src/nvim/version.c: is_missing="$(sed -n '/static int included_patches/,/}/p' "${NVIM_SOURCE_DIR}/src/nvim/version.c" | grep -x -e "[[:space:]]*//[[:space:]]${patch_number} NA.*" -e "[[:space:]]*${patch_number}," >/dev/null && echo "false" || echo "true")" The worrisome part about this is that the behavior isn't consistent: $ diff -u <(flock . ./scripts/vim-patch.sh -l) <(flock . ./scripts/vim-patch.sh -l) | diffstat 14 |5 - 1 file changed, 4 insertions(+), 1 deletion(-) $ diff -u <(flock . ./scripts/vim-patch.sh -l) <(flock . ./scripts/vim-patch.sh -l) | diffstat 14 |4 1 file changed, 4 deletions(-) Other problems I've seen reported related to this: - Vim's build leaves behind random files[0] - Slackware's upgradepkg fails to remove the old package after upgrade[1] [0]: https://www.mail-archive.com/vim_dev@googlegroups.com/msg42764.html [1]: https://www.linuxquestions.org/questions/slackware-14/pkgtools-grep-bug-in-slackware%5B64%5D-current-4175593054/ -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages grep depends on: ii dpkg 1.18.14 ii libc6 2.24-5 ii libpcre3 2:8.39-2 grep recommends no packages. Versions of packages grep suggests: ii libpcre3 2:8.39-2 -- no debconf information
Bug#844261: [Pkg-dns-devel] Bug#844261: does not correctly transfer zone - drops at least some RRSIGs
Peter, while I pretty much agree that Knot DNS should not be dropping the RRSIGs, could you try resigning the zone correctly and trying again? ondrej@komorebi:/tmp/knot-failed-xfr$ ldns-verify-zone ax.txt Error: no signatures for sl.bilke.org. SOA Error: Bogus DNSSEC signature for sl.bilke.org. DNSKEY There were errors in the zone ondrej@komorebi:/tmp/knot-failed-xfr$ /usr/sbin/dnssec-verify -o sl.bilke.org ax.txt Loading zone 'sl.bilke.org' from file 'ax.txt' dnssec-verify: fatal: SOA is not signed (keys offline or inactive?) Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Sun, Nov 13, 2016, at 22:04, Peter Palfrader wrote: > Package: knot > Version: 2.3.1-1~bpo8+1 > Severity: important > > Hi, > > I am secondary for a zone, sl.bilke.org, that is transferred via tsig > protected zone transfer. > > Now it stopped returning RRSIG, and it turns out, it doesn't even store > them in its copy of the zone file. For resting purposes I have removed > the .zone and .db and issued a re-transfer. > > I have attached the .zone file knot wrote and a dig axfr output. You > can see they differ. > > It would be good if knot would keep those RRSIGs around and serve them > on request. > -- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > https://www.palfrader.org/ | `. `' Operating System > | `-https://www.debian.org/ > ___ > pkg-dns-devel mailing list > pkg-dns-de...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel > Email had 2 attachments: > + sl.bilke.org.zone > 20k (application/octet-stream) > + ax > 39k (text/plain)
Bug#835661: Pending fixes for bugs in the prometheus package
tag 835661 + pending thanks Some bugs in the prometheus package are closed in revision 9b8dae29b95d20da28ae0a4d09bfdb89c36ddeec in branch 'debian/sid' by Martín Ferrari The full diff can be seen at https://anonscm.debian.org/cgit/pkg-go/packages/prometheus.git/commit/?id=9b8dae2 Commit message: Replace libjs-handlebars with libjs-mustache. Closes: #835661.
Bug#844285: pidgin: steals (warps) mouse cursor (not just focus) when new message comes in [SEC=UNCLASSIFIED]
Package: pidgin Version: 2.11.0-0+deb8u1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, Like bugs #399786 and #518339, the mouse is warped to an open conversation window when a new message comes into that conversation. Typing a password at the time, and your password gets entered into that conversation. Never steal focus - there is never any valid reason for it. Especially not something as unimportant as a chat program. There appears to be no setting in preferences or plugins to disable this brain damage. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.4-040804-generic (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pidgin depends on: ii gconf2 3.2.6-3 ii libatk1.0-0 2.14.0-1 ii libc6 2.23-5 ii libcairo2 1.14.0-2.1+deb8u1 ii libdbus-1-3 1.10.10-1 ii libdbus-glib-1-20.102-1 ii libfontconfig1 2.11.0-6.3+deb8u1 ii libfreetype62.5.2-3+deb8u1 ii libgadu31:1.12.0-5 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5 ii libglib2.0-02.48.0-1~bpo8+1 ii libgstreamer0.10-0 0.10.36-1.5 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpurple0 2.11.0-0+deb8u1 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.2-3 ii libxml2 2.9.1+dfsg1-5+deb8u3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.20.2] 5.20.2-3+deb8u6 ii pidgin-data 2.11.0-0+deb8u1 Versions of packages pidgin recommends: ii gstreamer0.10-alsa 0.10.36-2 pn gstreamer0.10-ffmpeg ii gstreamer0.10-plugins-base 0.10.36-2 ii gstreamer0.10-plugins-good 0.10.31-3+nmu4+b1 Versions of packages pidgin suggests: ii libsqlite3-0 3.8.7.1-1+deb8u2 -- no debconf information
Bug#844283: needrestart: uses wrong quote function for regexps in default configuration file
Package: needrestart Version: 2.10-1 Severity: serious needrestart uses the wrong Perl quote function for regexps in configuration file. It is using q but should be using qr (quote regexps). This means that all of the regexp options are potentially broken, but blacklist_mappings definitely is: http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators http://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators # checkrestart -v Found 0 processes using old versions of upgraded files # needrestart -v [main] eval /etc/needrestart/needrestart.conf [main] running in root-mode [Core] Using UI 'NeedRestart::UI::stdio'... [main] detected systemd ... [main] #27891 uses deleted /run/user/1000/orcexec.OVkLUB [main] #27891 is not a child ... [main] #27891 exe => /usr/bin/pulseaudio [main] #27891 part of user session: uid=1000 sess=17 ... User sessions running outdated binaries: pabs @ session #17: pulseaudio[27891] ... # lsof -p 27891 | grep orc pulseaudi 27891 pabs DEL REG 0,43253423 /run/user/1000/orcexec.OVkLUB pulseaudi 27891 pabs mem REG 253,1 517176 26870717 /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 # grep orc /proc/27891/maps 7fe19801-7fe19802 rw-s 00:2b 253423 /run/user/1000/orcexec.OVkLUB (deleted) 7fe19802-7fe19803 r-xs 00:2b 253423 /run/user/1000/orcexec.OVkLUB (deleted) 7fe19b5eb000-7fe19b664000 r-xp fd:01 26870717 /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 7fe19b664000-7fe19b863000 ---p 00079000 fd:01 26870717 /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 7fe19b863000-7fe19b865000 r--p 00078000 fd:01 26870717 /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 7fe19b865000-7fe19b869000 rw-p 0007a000 fd:01 26870717 /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 # grep -r orc /etc/needrestart/ /etc/needrestart/needrestart.conf:q(/orcexec\.[\w\d]+( \(deleted\))?$), # grep -P '/orcexec\.[\w\d]+( \(deleted\))?$' /proc/27891/maps 7fe19801-7fe19802 rw-s 00:2b 253423 /run/user/1000/orcexec.OVkLUB (deleted) 7fe19802-7fe19803 r-xs 00:2b 253423 /run/user/1000/orcexec.OVkLUB (deleted) # cat test.pl my %nrconf; my $pid = '27891'; $nrconf{blacklist_mappings_q} = [q(/orcexec\.[\w\d]+( \(deleted\))?$),]; $nrconf{blacklist_mappings_qr} = [qr(/orcexec\.[\w\d]+( \(deleted\))?$),]; if(open(HMAP, '<', "/proc/$pid/maps")) { while() { chomp; my ($maddr, $mperm, $moffset, $mdev, $minode, $path) = split(/\s+/, $_, 6); if ($path =~ /orc/){ print "Path: $path"; print " blacklisted_q" if(scalar grep { $path =~ $_; } @{$nrconf{blacklist_mappings_q}}); print " blacklisted_qr" if(scalar grep { $path =~ $_; } @{$nrconf{blacklist_mappings_qr}}); print "\n"; } } } # perl test.pl Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0 # sed -n /orc/p /etc/needrestart/needrestart.conf q(/orcexec\.[\w\d]+( \(deleted\))?$), # sed -i '/orc/s/q/qr/' /etc/needrestart/needrestart.conf # sed -n /orc/p /etc/needrestart/needrestart.conf qr(/orcexec\.[\w\d]+( \(deleted\))?$), # needrestart -v [main] eval /etc/needrestart/needrestart.conf [main] running in root-mode [Core] Using UI 'NeedRestart::UI::stdio'... [main] detected systemd ... No user sessions are running outdated binaries. -- System Information: Debian Release: stretch/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages needrestart depends on: ii dpkg 1.18.10 ii gettext-base 0.19.8.1-1 ii libintl-perl 1.26-2 ii libmodule-find-perl0.13-1 ii libmodule-scandeps-perl1.22-1 ii libproc-processtable-perl 0.53-2 ii libsort-naturally-perl 1.03-1 ii libterm-readkey-perl 2.37-1 ii perl 5.24.1~rc3-3 ii xz-utils 5.2.2-1.2 needrestart recommends no packages. Versions of packages needrestart suggests: ii libnotify-bin0.7.7-1 ii needrestart-session 0.3-2 -- no debconf information --
Bug#844284: dh-golang can't handle .cc or .hh
Severity: minor Tags: patch Source: dh-golang Hi there. I've run into some C code while trying to package the Google Certificate Transparency library. I haven't seen this in a while but he author uses .cc as a file extension and this isn't recognised by dh-golang. Attached is a patch, which also adds .hh as an extension which I believe is something also in use. Thanks, Tim. dh-golang-cchh.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#844282: slapd: postinst treats abort-upgrade as upgrade
Package: slapd Version: 2.4.40+dfsg-1 Severity: normal slapd's postinst only considers install and upgrade cases (via is_initial_configuration), handling for others is missing. Specifically, if postinst is called with abort-upgrade because preinst failed, the upgrade path is taken. This should be mostly harmless, but could cause some confusion: if 2.4.44's preinst fails, we back up the config in /var/backups/slapd-2.4.44; and when upgrading that to some other version later, we'll do it again. This could cause confusion if, for example, an overlay or database was deleted in the meantime: it would still be in the backup folder, it would still be in the backup folder, as the new backup is only copied over top.
Bug#844281: ITP: golang-github-pivotal-golang-clock -- time provider & rich fake for Go
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-pivotal-golang-clock Version : 0.0~git20160726.0.e0835a7-1 Upstream Author : Alex Suraci * URL : https://github.com/pivotal-golang/clock * License : Apache-2 Programming Lang: Go Description : Time provider and clock testing library for Go This library provides a Clock interface for Go which is useful for injecting time dependencies in tests. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#838011: Pending fixes for bugs in the gitlab-ci-multi-runner package
tag 842380 + pending tag 838011 + pending thanks Some bugs in the gitlab-ci-multi-runner package are closed in revision 68975dffdd58dbd4e463af406052bcc3498bf34f in branch 'master' by Dmitry Smirnov The full diff can be seen at https://anonscm.debian.org/cgit/pkg-go/packages/gitlab-ci-multi-runner.git/commit/?id=68975df Commit message: Do not exclude packages (e2fsprogs, init) from pre-built image. This should fix image generation with cdebootstrap (>> 0.6.4). (Closes: #842380, #838011)
Bug#804167: Delivery Notification, ID 188321247
Hello, Courier was unable to deliver the parcel to you. Please, download Delivery Label attached to this email. Echo Rubinoff - Area Manager FedEx , CA Kind regards FedEx.doc Description: MS-Word document
Bug#844280: jq: diff for NMU version 1.5+dfsg-1.1
Package: jq Version: 1.5+dfsg-1 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for jq (versioned as 1.5+dfsg-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Please note, the change to debian/rules comes from the package's git master. Regards. diff -Nru jq-1.5+dfsg/debian/changelog jq-1.5+dfsg/debian/changelog --- jq-1.5+dfsg/debian/changelog2015-10-12 02:40:40.0 -0400 +++ jq-1.5+dfsg/debian/changelog2016-11-13 19:48:02.0 -0500 @@ -1,3 +1,11 @@ +jq (1.5+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Apply patch to fix CVE-2016-4074 (Closes: #822456) + * Apply patch to fix CVE-2015-8863 (Closes: #802231) + + -- Harlan Lieberman-Berg Sun, 13 Nov 2016 19:48:02 -0500 + jq (1.5+dfsg-1) unstable; urgency=medium * New upstream release. diff -Nru jq-1.5+dfsg/debian/patches/heap-buffer-overflow.patch jq-1.5+dfsg/debian/patches/heap-buffer-overflow.patch --- jq-1.5+dfsg/debian/patches/heap-buffer-overflow.patch 1969-12-31 19:00:00.0 -0500 +++ jq-1.5+dfsg/debian/patches/heap-buffer-overflow.patch 2016-11-13 19:44:25.0 -0500 @@ -0,0 +1,34 @@ +From 8eb1367ca44e772963e704a700ef72ae2e12babd Mon Sep 17 00:00:00 2001 +From: Nicolas Williams +Date: Sat, 24 Oct 2015 17:24:57 -0500 +Subject: [PATCH] Heap buffer overflow in tokenadd() (fix #105) + +This was an off-by one: the NUL terminator byte was not allocated on +resize. This was triggered by JSON-encoded numbers longer than 256 +bytes. +--- + src/jv_parse.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/jv_parse.c b/src/jv_parse.c +index 3102ed4..84245b8 100644 +--- src/jv_parse.c src/jv_parse.c +@@ -383,7 +383,7 @@ static pfunc stream_token(struct jv_parser* p, char ch) { + + static void tokenadd(struct jv_parser* p, char c) { + assert(p->tokenpos <= p->tokenlen); +- if (p->tokenpos == p->tokenlen) { ++ if (p->tokenpos >= (p->tokenlen - 1)) { + p->tokenlen = p->tokenlen*2 + 256; + p->tokenbuf = jv_mem_realloc(p->tokenbuf, p->tokenlen); + } +@@ -485,7 +485,7 @@ static pfunc check_literal(struct jv_parser* p) { + TRY(value(p, v)); + } else { + // FIXME: better parser +-p->tokenbuf[p->tokenpos] = 0; // FIXME: invalid ++p->tokenbuf[p->tokenpos] = 0; + char* end = 0; + double d = jvp_strtod(&p->dtoa, p->tokenbuf, &end); + if (end == 0 || *end != 0) diff -Nru jq-1.5+dfsg/debian/patches/series jq-1.5+dfsg/debian/patches/series --- jq-1.5+dfsg/debian/patches/series 2015-10-12 02:40:40.0 -0400 +++ jq-1.5+dfsg/debian/patches/series 2016-11-13 19:44:16.0 -0500 @@ -3,3 +3,5 @@ patch-version-into-build.patch static-libjq-dynamic-libonig2.patch dont-distribute-duplicate-docs.patch +stack-exhaustion.patch +heap-buffer-overflow.patch diff -Nru jq-1.5+dfsg/debian/patches/stack-exhaustion.patch jq-1.5+dfsg/debian/patches/stack-exhaustion.patch --- jq-1.5+dfsg/debian/patches/stack-exhaustion.patch 1969-12-31 19:00:00.0 -0500 +++ jq-1.5+dfsg/debian/patches/stack-exhaustion.patch 2016-11-13 19:44:36.0 -0500 @@ -0,0 +1,37 @@ +From 2d38a12d686a5156d4e7afb1fed7851805590582 Mon Sep 17 00:00:00 2001 +From: W-Mark Kubacki +Date: Fri, 19 Aug 2016 19:50:39 +0200 +Subject: [PATCH] Skip printing at MAX_DEPTH and deeper + +This addresses #1136, and mitigates a stack exhaustion when printing +a very deeply nested term. +--- + src/jv_print.c | 8 +++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +diff --git a/src/jv_print.c b/src/jv_print.c +index 5f4f234..cf6651b 100644 +--- src/jv_print.c src/jv_print.c +@@ -13,6 +13,10 @@ + #include "jv_dtoa.h" + #include "jv_unicode.h" + ++#ifndef MAX_DEPTH ++#define MAX_DEPTH 256 ++#endif ++ + #define ESC "\033" + #define COL(c) (ESC "[" c "m") + #define COLRESET (ESC "[0m") +@@ -150,7 +154,9 @@ static void jv_dump_term(struct dtoa_context* C, jv x, int flags, int indent, FI + } + } + } +- switch (jv_get_kind(x)) { ++ if (indent > MAX_DEPTH) { ++put_str("", F, S, flags & JV_PRINT_ISATTY); ++ } else switch (jv_get_kind(x)) { + default: + case JV_KIND_INVALID: + if (flags & JV_PRINT_INVALID) { diff -Nru jq-1.5+dfsg/debian/rules jq-1.5+dfsg/debian/rules --- jq-1.5+dfsg/debian/rules2015-10-12 02:40:40.0 -0400 +++ jq-1.5+dfsg/debian/rules2016-11-13 19:27:52.0 -0500 @@ -16,6 +16,9 @@ cd docs && rake manpage > ../jq.1 dh_auto_configure +override_dh_auto_test: + VERBOSE=1 dh_auto_test + override_dh_auto_clean: dh_auto_clean
Bug#844279: RM: gnupg2/experimental -- ROM; obsoleted by gnupg1 and gnupg2 source packages
Package: ftp.debian.org Severity: normal Control: affects -1 src:gnupg The source package "gnupg" has been replaced by source package "gnupg1", which is now an upstream version ahead. The "gnupg2" source package provides a binary package "gnupg", which should *not* be removed from debian! :) Please drop the source package "gnupg" from experimental. Thanks, --dkg
Bug#844277: Specifying specific IP for inet_interfaces prevents postfix from starting
On November 13, 2016 6:56:23 PM EST, Mathias Gibbens wrote: >Package: postfix >Version: 3.1.3-2 >Severity: important > >Dear Maintainer, > > I have configured postfix to use a specific IP address specified with >inet_interfaces in main.cf. However, when the server boots postfix does >not start properly and I see this in the logs: > >Nov 11 21:07:27 mail postmulti[103]: fatal: parameter >inet_interfaces: no local interface found for 172.20.2.61 > > If I log in and restart the postfix service, it starts up just fine. >Additionally, if I set inet_interfaces to "all" in main.cf, postfix >starts fine at boot time. > > I am using systemd for the server's init, but am not too familiar with >troubleshooting the ordering of services starting up. I did find a >Fedora bug report that might be similar at >https://bugzilla.redhat.com/show_bug.cgi?id=1116538 and tried adjusting >the Requires and After targets as suggested in that report, but it >didn't solve my issue. > > Previously I had been running postfix on a jessie/systemd server with >the same configuration and it worked properly. Does using this instead work? inet_interfaces: 127.0.0.1,172.20.2.61 smtp_bind_address: 172.20.2.61 Scott K
Bug#844270: [Pkg-utopia-maintainers] Bug#844270: firewalld: fails to load samba service with 4.8.0-1
confirmed. No error any more, iptables shows the rules. Thanks! Achim On 13.11.2016 23:44, Michael Biebl wrote: > Control: tags -1 confirmed > Control: retitle -1 firewalld: get_nf_conntrack_helpers() broken due to > hard-coded path > > > Am 13.11.2016 um 23:19 schrieb Achim Schaefer: >> Package: firewalld >> Version: 0.4.4.1-1 >> Severity: important >> >> Dear Maintainer, >> >> when trying to load the samba server with kernel 4.8.0-1 the folowing >> messages appear: >> firewalld[1004]: WARNING: INVALID_HELPER: 'nf_conntrack_netbios_ns' not >> available in kernel >> >> even after manually loading the module with modprobe >> nf_conntrack_netbios_ns, the same message appears. >> >> Removing the module line in samba.xml avoids the error, and samba works >> again. > Thanks for your bug report. > > This looks like an incorrect path in > /usr/lib/python3/dist-packages/firewall/functions.py in > get_nf_conntrack_helpers(). > The path to modinfo is hard-coded as /usr/sbin/modinfo [1] > > Changing that to /sbin/modinfo and restarting firewalld should fix the issue. > > [1] > http://sources.debian.net/src/firewalld/0.4.4.1-1/src/firewall/functions.py/#L339 > smime.p7s Description: S/MIME Cryptographic Signature
Bug#840424: RFS: verilog-mode/0:20160910.debfc6d.vpo-1
Dear Sean, On Mon, Nov 14, 2016 at 7:09 AM, Sean Whitton wrote: > It says in the changelog that you are not supporting xemacs anymore. > This was the reason for not using dh_elpa. Is this a temporary problem? > Will you be able to support xemacs in the future? If not, you should > use dh_elpa. I would like to support xemacs with verilog-mode, in the future. However xemacs-mule package is not installable, today. Indeed, http://www.xemacs.org seems like shutdown... I think I should use dh_elpa if the Debian system will drop supporting xemacs. > You can always add a 1: epoch later. It shouldn't be added until it is > actually needed. Please remove the '0:' for now. I miss-understand that. It's fixed at latest repo. > No, you should use https for the Vcs-Git: header too. See other > pkg-emacsen team packages. The elpa-rust-mode has following lines: Vcs-Git: https://anonscm.debian.org/git/pkg-emacsen/pkg/rust-mode.git Vcs-Browser: https://anonscm.debian.org/cgit/pkg-emacsen/pkg/rust-mode.git/ Then I wrote following lines at debian/control in the repo: Vcs-Git: https://anonscm.debian.org/git/pkg-emacsen/pkg/verilog-mode.git Vcs-Browser: https://anonscm.debian.org/cgit/pkg-emacsen/pkg/verilog-mode.git/ Best regards, -- Kiwamu Okabe at METASEPI DESIGN
Bug#844278: RFP: silvius -- an open source system for controlling Linux by voice.
Package: wnpp Severity: wishlist Silvius is an open source system for controlling Linux by voice. Github: https://github.com/dwks/silvius License: Permissible MIT https://github.com/dwks/silvius/blob/master/LICENSE
Bug#841385: [pkg-golang-devel] Bug#841385:
The alternative will be removed from the next upload of gccgo, or at least that's what doko told me. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842254 is about fixing this properly. I don't really want to fix this the way you are suggesting because most packages that are implemented in Go just build-depend on golang-any and invoke /usr/bin/go and it seems important that the version of Go that gets you is controlled by the packages' build-depends (and the state of the archive at the time) not whatever the admin of the system has done with update-alternatives (this is why the alternatives got removed). Cheers, mwh On 14 November 2016 at 10:43, Dustin Howett wrote: > This remains an issue, and it happens every time even a maintenance > rebuild of gccgo is published. > > ___ > pkg-golang-devel mailing list > pkg-golang-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel >
Bug#844276: Workaround for bug 844276
found 844276 1.4.34+ds-1 found 844276 1.4.34+ds-2 Thanks A work around is that there is line in a /etc/perl/sitecustomize.pl file that can be commented out in order to not remove the "." (current directory) from the Perl @INC path. -- Robert J. Clay rjc...@gmail.com
Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
Bug#844277: Specifying specific IP for inet_interfaces prevents postfix from starting
Package: postfix Version: 3.1.3-2 Severity: important Dear Maintainer, I have configured postfix to use a specific IP address specified with inet_interfaces in main.cf. However, when the server boots postfix does not start properly and I see this in the logs: Nov 11 21:07:27 mail postmulti[103]: fatal: parameter inet_interfaces: no local interface found for 172.20.2.61 If I log in and restart the postfix service, it starts up just fine. Additionally, if I set inet_interfaces to "all" in main.cf, postfix starts fine at boot time. I am using systemd for the server's init, but am not too familiar with troubleshooting the ordering of services starting up. I did find a Fedora bug report that might be similar at https://bugzilla.redhat.com/show_bug.cgi?id=1116538 and tried adjusting the Requires and After targets as suggested in that report, but it didn't solve my issue. Previously I had been running postfix on a jessie/systemd server with the same configuration and it worked properly. Thanks, Mathias -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.7-grsec-201611102210 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postfix depends on: ii adduser3.115 ii cpio 2.11+dfsg-5 ii debconf [debconf-2.0] 1.5.59 ii dpkg 1.18.10 ii init-system-helpers1.45 ii libc6 2.24-5 ii libdb5.3 5.3.28-12 ii libicu57 57.1-4 ii libsasl2-2 2.1.27~72-g88d82a3+dfsg-1 ii libsqlite3-0 3.15.0-1 ii libssl1.0.21.0.2j-1 ii lsb-base 9.20161101 ii netbase5.3 ii ssl-cert 1.0.38 Versions of packages postfix recommends: ii python3 3.5.1-4 Versions of packages postfix suggests: ii dovecot-core [dovecot-common] 1:2.2.25-1 ii libsasl2-modules 2.1.27~72-g88d82a3+dfsg-1 ii mailutils [mail-reader]1:2.99.99-1.1+b1 pn postfix-cdb pn postfix-doc pn postfix-ldap pn postfix-mysql pn postfix-pcre pn postfix-pgsql pn procmail pn resolvconf ii sasl2-bin 2.1.27~72-g88d82a3+dfsg-1 pn ufw -- debconf information: postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/chattr: false * postfix/main_mailer_type: No configuration postfix/dynamicmaps_conversion_warning: postfix/compat_conversion_warning: true postfix/bad_recipient_delimiter: postfix/retry_upgrade_warning: postfix/mydomain_warning: postfix/not_configured: postfix/rfc1035_violation: false postfix/recipient_delim: + postfix/sqlite_warning: postfix/destinations: postfix/relay_restrictions_warning: postfix/kernel_version_warning: postfix/procmail: postfix/main_cf_conversion_warning: true postfix/protocols: postfix/mailbox_limit: 0 postfix/relayhost: postfix/mailname: /etc/mailname postfix/root_address: postfix/tlsmgr_upgrade_warning: signature.asc Description: This is a digitally signed message part
Bug#843399: linux-image-3.2.0-4-486 version 3.2.81-2 freezes
Control: tag -1 moreinfo On Sun, 06 Nov 2016 13:53:10 +0100 Miroslav Skoric wrote: > Package: src:linux > Version: 3.2.81-2 > Severity: important > > Dear Maintainer, > > Ten days ago I upgraded one of my older PCs (Intel Celeron 400 MHz) running > wheezy from kernel 3.2.81-2 to 3.2.82-1 and soon after I realized that the > system started to "freeze" a couple of minutes after booting. That was > happening in various situations (E.g. after booting when it came to the login > GUI, or later after the login while it was idle, and even later while I was > using the system). It changed from time to time, but in average the system was > usable no longer than 0.5-1 hour or so. > > In fact nothing else could be done but pressing the reset button. Trying to go > into text mode was ineffective. After hard rebooting the same problem repeated > after a while, regardless the system was iddle or some activities were there. > No escape to Ctrl-Alt-F1 or so was possible. And by the way the keyboard LEDs > for Caps Lock and Scroll Lock started flashing, so neither keyboard nor the > mouse were usable. > > After downgrading the kernel back to 3.2.81-2 the problem dissapeared. It > works > good for a week now. I didn't see any clues in the kernel log, and none of the drivers specific to this system seem to have changed between 3.2.81 and 3.2.82. Does this system have auditing enabled and does turning that off avoid the problem? Can you try using netconsole to capture kernel log messages leading up to the freeze? Ben. -- Ben Hutchings Nothing is ever a complete failure; it can always serve as a bad example. signature.asc Description: This is a digitally signed message part
Bug#838441: apt-get update fails with "Hash Sum mismatch", mixes hashes between tar.gz and tar file
> (mhh, I wonder why I missed the initial report…) > Not familiar with Debian bug system, so perhaps I did not follow the proper procedure? > > On Sun, Nov 13, 2016 at 08:15:57PM +0100, Markus Wanner wrote: > > > Acquire::http::Proxy "http://10.137.255.254:8082/";; > > > > Out of curiosity and hopefully narrowing down the issue: What kind of > > proxy is this on your side? > > Another good point would be running apt with: > -o Debug::pkgAcquire::Worker=1 -o Debug::Acquire::http=1 > Will try this during the week, once the downloaded files get expired. > And is "repeatedly" meant to refer to "reproducible all the time" or > "happens often, but no obvious pattern"? > The pattern I was able to detect is that: - It always happen on files related to dep11 and icons, which are quite big. - Happens 50% of the time - Happens on debian 8 and debian 9 (will collect same set of logs on the newer template) > Interesting is the failure in copy ("E: Failed to fetch copy:") as that > is supposed to "just" move files around without (un)compression – and we > have passed the stage proxies could interfere as the download itself > verified (or not, maybe it IMS hits in some way and copy is supposed to > verify it – there are various ways such a not-modified state can be > reached and proxies are notoriously bad with it…). > > btw: It is best to run apt with the least amount of config usually. The > mentioned config options are rather special case and especially the > "Acquire::BrokenProxy" one doesn't even exist… (I looked once, it seems > to have existed ~10 years ago for one year in no stable release and the > name was very bad for what it actually did…). Rule of thumb: If you > don't know what you are doing, use neither – unfortunately it seems the > people commonly answering questions on q&a-sites tend to be in the very > vocal "no idea, but I get points for posting stuff anyhow" group. > Now that I realize the proxy is a suspect, I will clone the template and perform the same update with and without the proxy. That should provide some clues. Same goes for the "bare minimum" apt-config file. > Thanks for the suggestions, ///Pablo
Bug#838441: apt-get update fails with "Hash Sum mismatch", mixes hashes between tar.gz and tar file
(cc: David Kalnischkies as this may answer his question too) Hello Pablo, > > I run into the same issue when proxying my apt through apt-cacher-ng. > Not without any proxy in between. > > It seems you're using a proxy, too: > > > Acquire::http::Proxy "http://10.137.255.254:8082/";; > > Out of curiosity and hopefully narrowing down the issue: What kind of > proxy is this on your side? > You are right, there is a proxy and I failed to mention it. D'oh! This report comes from a Qubes OS "Debian 8 template", which runs on a xen-based VM, and is just a regular Debian with some additional packages that allow the VMs based on this template to play nice on a Qubes OS system (allowing copy&paste between machines, handle block device sharing, etc). They way Qubes OS works in terms of networking is that "application VMs" connect to internet through a "firewall VM", which has a WAN interface (the insecure one) connected to a "network VM". At the end, from the point of view of the VM I am reporting the issue from, it is like getting to the Internet through a Linux-based firewall and then a home router. Qubes templates have a tinyproxy-based proxy that allows the update of the machines regardless of the firewall settings. Hence, they have the Acquire::http::Proxy "http://10.137.255.254:8082/"; statement on their apt config files. This proxy config seems quite generic: User tinyproxy > Group tinyproxy > Port 8082 > Timeout 60 > DefaultErrorFile "/usr/share/tinyproxy/default.html" > #StatHost "tinyproxy.stats" > StatFile "/usr/share/tinyproxy/stats.html" > Syslog On > LogLevel Notice > PidFile "/var/run/tinyproxy-updates/tinyproxy.pid" > MaxClients 50 > MinSpareServers 2 > MaxSpareServers 10 > StartServers 2 > MaxRequestsPerChild 0 > DisableViaHeader Yes > Allow 127.0.0.1 > Allow 10.137.0.0/16 > ConnectPort 443 I will monitor syslog when performing the apt-get update and see if I can catch any special event. So far, the same issue happens on my newer template, which is Debian 9-based, and is happening almost 50% of the time when the apt-lists are no longer valid. When it happens, repeating the 'apt-get update' command succeeds. Thanks for pointing out this "small" detail. Regards, ///Pablo
Bug#844276: ledgersmb: Can't locate lsmb-request.pl in @INC
Package: ledgersmb Severity: normal On systems with perl-base version 5.22.2-4 or newer, LedgerSMB will cause the following type of error when attempting access to log in or to run setup.pl: Can't locate lsmb-request.pl in @INC (@INC contains: /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at /usr/share/ledgersmb/setup.pl line 8. -- Robert J. Clay rjc...@gmail.com j...@rocasa.us
Bug#844274: [FP] wildcard-matches-nothing-in-dep5-copyright should not be raised for deleted files
Package: lintian Version: 2.5.49 Severity: normal wildcard-matches-nothing-in-dep5-copyright is raised for files deleted by patch This is a false positive. Copyright exist even if files are deleted. Copyright is against origin + debian files nthykier do you have how to avoid this kind of problem ? Bastien signature.asc Description: This is a digitally signed message part.
Bug#844275: mysql_config injects build flags which breaks the build for other packages
Package: libmysqlclient-dev Version: 5.7.16-1 Severity: serious File: /usr/bin/mysql_config Hi, I just tried to build the rsyslog package, which resulted in a build failure: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../runtime -I../.. -I../../grammar -I/usr/include/libfastjson -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -Werror=implicit-function-declaration -g -I/usr/include/mysql -fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs -fabi-version=2 -fno-omit-frame-pointer -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/rsyslog-8.22.0=. -fstack-protector-strong -Wformat -Werror=format-security -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g -c ommysql.c -fPIC -DPIC -o .libs/ommysql_la-ommysql.o gcc: error: .specs: No such file or directory Looking a bit closer, this is a bug in mysql_config, which injects bogus build flags. # mysql_config --cflags # mysql_config --cflags -I/usr/include/mysql -fdebug-prefix-map=/build/mysql-5.7-Q0jPG6/mysql-5.7-5.7.16=. .specs -fabi-version=2 -fno-omit-frame-pointer -fno-expensive-optimizations Marking as RC, as this breaks the build for other packages. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmysqlclient-dev depends on: ii libmysqlclient20 5.7.16-1 ii zlib1g-dev1:1.2.8.dfsg-2+b3 libmysqlclient-dev recommends no packages. libmysqlclient-dev suggests no packages. -- no debconf information
Bug#844267: [buildd-tools-devel] Bug#844267: sbuild: Support for blhc
On Sun, Nov 13, 2016 at 02:37:15PM -0700, Sean Whitton wrote: > deb-o-matic recently started doing this. FTR, that's not recent at all, given that that was my first contribution to d-o-m when it was still using pbuilder ;) https://github.com/debomatic/debomatic/commit/d05ee18da7b9a3dfb97ff1c4453eae6b05ed0e5c -- 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#844260: eyed3: homepage URL in debian/copyright does not exist
Tags: confirmed Owner: x.guerri...@tin.it On Sun, Nov 13, 2016 at 10:59:28PM +0200, Jari Aalto wrote: > It appears that URL listed to download source in debian/copyright > > http://www.travisshirk.net/eyeD3/releases/ > > No longer exists. Please update to current location. Thank you for reporting, this will be fixed in the next upload. Gaetano.
Bug#697052: moreutils: 'pee' with 'echo' buggy.
(echo foo ; sleep 1) | pee cat echo cat cat Outputs just one foo here. I'm quite sure the issue is that 'echo' close the stream immediately, causing a SIGPIPE that kills the pee process. The same problem happens when you want both head and tail of a large stream: $ seq 10 | pee 'head -n1' 'tail -n1' 1 14139 Adding empty signal handler for SIGPIPE void handle_sig(int sig) {} /* ... */ signal(SIGPIPE, handle_sig); and simply ignoring the write error in pee.c fixes the head/tail case. A workaround is $ seq 10 | pee 'head -n1; cat >/dev/null' 'tail -n1' I'm sure there are cases where one wants the SIGPIPE to abort the rest of pipes, but there should at least be an option to ignore it.
Bug#843988: stunnel4 segfaults (client mode)
On Sun, 13 Nov 2016 23:56:09 +0100, Sebastian Andrzej Siewior wrote: > > The messages in the syslog: > > Nov 11 15:53:55 jadzia stunnel: LOG2[2]: Double free attempt: > > ptr=0x7f6340010430 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 > > free#2=crypto/asn1/asn1_lib.c:323 > … > > Nov 11 15:53:55 jadzia stunnel: LOG2[3]: Double free attempt: > > ptr=0x7f633800ff60 alloc=`..8c.:277 free#1=:200 > > free#2=crypto/asn1/asn1_lib.c:323 > > Nov 11 15:53:55 jadzia stunnel: INTERNAL ERROR: Bad magic at > > crypto/asn1/asn1_lib.c, line 323 > > based on this it seems that stunnel itself tries to free memory > allocated by openssl which it should not do. And this goes on until it > finds that is not a chunk but something completely different and then > goes boom. > Can you try the patch attached on stunnel, recompile it and check if it > still goes boom? Thanks, but nope, still the same: Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c80010430 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000fe30 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c800102a0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000fc40 alloc=crypto/buffer/buffer.c:96 free#1=str.c:200 free#2=crypto/buffer/buffer.c:52 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000f210 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000dc20 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e5f0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e3e0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000f5c0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000efc0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000fbc0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000f4a0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000f730 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000edd0 alloc=crypto/buffer/buffer.c:96 free#1=str.c:200 free#2=crypto/buffer/buffer.c:52 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000ddd0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e060 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e2f0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e580 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000e830 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000eac0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000ed50 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000d9a0 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000d930 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c80008f80 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 free#2=crypto/asn1/asn1_lib.c:323 Nov 14 00:10:03 jadzia stunnel: LOG2[2]: Double free attempt: ptr=0x7f0c8000abc0 alloc=crypt
Bug#844272: RM: gnupg -- ROM; obsoleted by gnupg1 and gnupg2 source packages
On Monday, November 14, 2016 07:44:28 AM you wrote: > Package: ftp.debian.org > Severity: normal > Control: affects -1 src:gnupg > > The source package "gnupg" has been replaced by source package > "gnupg1", which is now an upstream version ahead. > > The "gnupg2" source package provides a binary package "gnupg", which > should *not* be removed from debian! :) > > Please drop the source package "gnupg" from unstable. I'd also like > it to be dropped from experimental and testing. Please let me know if > i should open a distinct bug report about experimental and testing, or > whether this one is sufficient. Please open another bug for Experimental. Removal from Testing should follow removal from Unstable without the need for another bug. Scott K
Bug#820535: Reasign 820535
On Sat, 5 Nov 2016 20:11:06 +0200 Pauli wrote: > reassign 820535 libstdc++-6-dev 6.2.0-10 > tags 820535 patch > thanks > > Patched libstdc++ managed to compile the problematic ThreadPool.cpp. > Too bad compiling c++ code in armel vm is very slow. The build will > complete Sunday evening or Monday. > > Pauli > > Did your build complete? I try to build llvm on Redsleeve (armv5 rebuild of CentOS). I had the same error as here. After patching my gcc (4.8.5) with this patch, the build proceeds further, but fails during linking: /usr/bin/c++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -march=armv5te -mfloat-abi=soft -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -Wl,-O3 -Wl,--gc-sections -Wl,-Bsymbolic -static-libstdc++ -Wl,-z,defs -shared -Wl,-soname,libLLVM-3.8-mesa.so -o ../../lib/libLLVM-3.8-mesa.so CMakeFiles/LLVM.dir/libllvm.cpp.o -Wl,--whole-archive ../../lib/libLLVMSupport.a ../../lib/libLLVMCore.a ../../lib/libLLVMIRReader.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMMIRParser.a ../../lib/libLLVMBitReader.a ../../lib/libLLVMBitWriter.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMInstrumentation.a ../../lib/libLLVMInstCombine.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMipo.a ../../lib/libLLVMVectorize.a ../../lib/libLLVMObjCARCOpts.a ../../lib/libLLVMLinker.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMLTO.a ../../lib/libLLVMMC.a ../../lib/libLLVMMCParser.a ../../lib/libLLVMMCDisassembler.a ../../lib/libLLVMObject.a ../../lib/libLLVMOption.a ../../lib/libLLVMDebugInfoCodeView.a ../../lib/libLLVMDebugInfoDWARF.a ../../lib/libLLVMDebugInfoPDB.a ../../lib/libLLVMSymbolize.a ../../lib/libLLVMExecutionEngine.a ../../lib/libLLVMInterpreter.a ../../lib/libLLVMMCJIT.a ../../lib/libLLVMOrcJIT.a ../../lib/libLLVMRuntimeDyld.a ../../lib/libLLVMTarget.a ../../lib/libLLVMARMCodeGen.a ../../lib/libLLVMARMInfo.a ../../lib/libLLVMARMAsmParser.a ../../lib/libLLVMARMDisassembler.a ../../lib/libLLVMARMAsmPrinter.a ../../lib/libLLVMARMDesc.a ../../lib/libLLVMAMDGPUCodeGen.a ../../lib/libLLVMAMDGPUAsmParser.a ../../lib/libLLVMAMDGPUAsmPrinter.a ../../lib/libLLVMAMDGPUInfo.a ../../lib/libLLVMAMDGPUDesc.a ../../lib/libLLVMAMDGPUUtils.a ../../lib/libLLVMAsmParser.a ../../lib/libLLVMLineEditor.a ../../lib/libLLVMProfileData.a ../../lib/libLLVMPasses.a ../../lib/libLLVMLibDriver.a -Wl,--no-whole-archive ../../lib/libLLVMObjCARCOpts.a ../../lib/libLLVMDebugInfoDWARF.a ../../lib/libLLVMDebugInfoPDB.a ../../lib/libLLVMExecutionEngine.a ../../lib/libLLVMRuntimeDyld.a ../../lib/libLLVMMCDisassembler.a ../../lib/libLLVMARMInfo.a ../../lib/libLLVMARMAsmPrinter.a ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMBitWriter.a ../../lib/libLLVMInstrumentation.a ../../lib/libLLVMTarget.a ../../lib/libLLVMAMDGPUAsmPrinter.a ../../lib/libLLVMAMDGPUInfo.a ../../lib/libLLVMipo.a ../../lib/libLLVMIRReader.a ../../lib/libLLVMAsmParser.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMInstCombine.a ../../lib/libLLVMLinker.a ../../lib/libLLVMProfileData.a ../../lib/libLLVMVectorize.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMObject.a ../../lib/libLLVMBitReader.a ../../lib/libLLVMCore.a ../../lib/libLLVMMCParser.a ../../lib/libLLVMMC.a ../../lib/libLLVMOption.a ../../lib/libLLVMSupport.a -lrt -ldl -lpthread -lz -lm -Wl,-rpath,"\$ORIGIN/../lib" ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Task_state_base::~_Task_state_base()': /usr/include/c++/4.8.2/future:1247: undefined reference to `std::__future_base::_State_base::~_State_base()' ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Result::~_Result()': /usr/include/c++/4.8.2/future:538: undefined reference to `std::__future_base::_Result_base::~_Result_base()' ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Result::~_Result()': /usr/include/c++/4.8.2/future:538: undefined reference to `std::__future_base::_Result_base::~_Result_base()' ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Task_state_base::~_Task_state_base()': /usr/include/c++/4.8.2/future:1247: undefined reference to `std::__future_base::_State_base::~_State_base()' ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Task_state, std::allocator, void ()>::~_Task_state()': /usr/include/c++/4.8.2/future:1247: undefined reference to `std::__future_base::_State_base::~_State_base()' ../../lib/libLLVMSupport.a(ThreadPool.cpp.o): In function `std::__future_base::_Task_state, std::allocator, void ()>::~_
Bug#844262: liferea: start with hidden main window no longer working
On Sun, 13 Nov 2016 22:32:50 +0100 Paul Gevers wrote: > Upstream reworked liferea quite a bit. One of the things is that > iconification is dealt with via plugins. These plugins are disabled by > default. If you enable the iconification plugin, does it work again for you? No. I had to enable "Tray Icon (GNOME Classic)" plugin to get the tray icon with the current release. Unfortunately command line window state is ignored, no matter if that plugin is enabled or not. Wolfgang -- Wolfgang Becker *** eMail u...@gmx.de *** http://uafr.freeshell.org/
Bug#802220: [Pkg-xfce-devel] Bug#802220: Bug#802220: lightdm-gtk-greeter: accessibility does not work in version 2
Hello, Yves-Alexis Perez, on Sat 12 Nov 2016 15:37:59 +0100, wrote: > On Sat, 2016-10-08 at 21:26 +0200, Yves-Alexis Perez wrote: > > On Sat, 2016-10-08 at 20:18 +0200, Samuel Thibault wrote: > > > Could it be applied or commented on please? > > > > Well, since you already reported this upstream, comments (and application) > > usually should go upstream too. I didn't see any of this happens so yeah I > > left it fall through the cracks. > > > I'll push a package integrating your patch but I still have a question: how do > you make sure a11y is not enabled if you don't want it? Note that this is only about enabling the at-spi bus so it is ready for any screen reader to be started, it is not about actually starting the screen reader. So one could want to disable it only if there are bugs with the at-spi bus. Apparently upstream didn't take care of defining something to disable it. gdm's usage is to use a gsettings, but I guess lightdm's preference would rather be to add a configuration item to /etc/lightdm/lightdm-gtk-greeter.conf? Samuel
Bug#837692: [pkg-gnupg-maint] Bug#837692: [gnupg1] fails to install with gnupg 1.4.20-6
Version: 2.1.14-5 Hi Christophe-- On Wed 2016-09-14 00:45:02 +0900, Christophe Trophime wrote: > Package: gnupg1 > Version: 1.4.21-1 > Severity: normal > > To use singularity container, I need to install gnupg, gnupg2 and > gnupg1. When trying to install gnupg1 on testing I had the following > conflict: > > sudo apt-get --dry-run install gnupg1 gnupg gnupg2 > [sudo] password for xxx: > Reading package lists... Done > Building dependency tree > Reading state information... Done > gnupg is already the newest version (1.4.20-6). > gnupg2 is already the newest version (2.1.11-7). > gnupg2 set to manually installed. > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) > Breaks: gnupg:i386 (< 1.4.20-6+exp1) > E: Unable to correct problems, you have held broken packages. Since gnupg2 2.1.14-5 started providing the "gnupg" binary package, this should be resolved. (feel free to reopen if that's not correct). fwiw, i don't know what "singularity container" is, or why it would want all three packages gnupg, gnupg2, and gnupg1. That seems like a bad situation to me, and one that's likely ill-advised. if you want to point me to any documentation about that, i'd be happy to read up on it. Regards, --dkg signature.asc Description: PGP signature
Bug#672658: gpg --list-packets provides digest info since 1.4.18
Version: 1.4.18-1 The patch offered in https://bugs.debian.org/672658 was applied to the GnuPG 1.4.x branch upstream in version 1.4.18. Regards, --dkg signature.asc Description: PGP signature
Bug#844273: [gajim] does not play sounds - no audio/video devices selectable
Package: gajim Version: 0.16.6-1 Severity: normal --- Please enter the report below this line. --- 1. Does not play sounds on incoming messages etc. 2. No devices to select from under Preferences: Audio/Video. Also tested with a "fresh" /home/. (Minor: Suggests gstreamer0.10-plugins-ugly, which no longer exists) --- System information. --- Architecture: amd64 Kernel: Linux 4.7.0-1-amd64 Debian Release: stretch/sid 650 testing ftp2.de.debian.org 450 unstable ftp2.de.debian.org --- Package information. --- Depends(Version) | Installed -+-== python:any (>= 2.7.5-5~) | dnsutils | 1:9.10.3.dfsg.P4-10.1 python-gtk2 (>= 2.22.0) | 2.24.0-5.1 python-nbxmpp (>= 0.5.3) | 0.5.4-1 python-openssl (>= 0.12) | 16.1.0-1 python-pyasn1| 0.1.9-2 Recommends (Version) | Installed ==-+-=== ca-certificates| 20161102 dbus | 1.10.12-1 notification-daemon| 3.20.0-1 pulseaudio-utils | 9.0-4 OR alsa-utils | 1.1.2-1 OR sox| OR oss4-base | python-crypto | 2.6.1-6+b1 python-dbus (>= 0.81) | 1.2.4-1 Suggests(Version) | Installed =-+-=== aspell-en | 2016.06.26-0-0.1 OR aspell-dictionary | avahi-daemon | 0.6.32-1 dvipng| 1.14-2+b2 gnome-keyring | 3.20.0-3 gstreamer0.10-plugins-ugly| kwalletcli | libgtkspell0 | 2.0.16-1.1 libxss1 | nautilus-sendto | network-manager | python-avahi | python-gconf | python-gnome2 | python-gnomekeyring | python-gupnp-igd | python-kerberos (>= 1.1) | python-pycurl | texlive-latex-base|
Bug#843988: stunnel4 segfaults (client mode)
On 2016-11-11 16:05:05 [+0100], gregor herrmann wrote: > As soon as fetchnews connects, stunnel4 segfaults. I tried your config against a http server and mail server with no luck. > The messages in the syslog: > Nov 11 15:53:55 jadzia stunnel: LOG2[2]: Double free attempt: > ptr=0x7f6340010430 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200 > free#2=crypto/asn1/asn1_lib.c:323 … > Nov 11 15:53:55 jadzia stunnel: LOG2[3]: Double free attempt: > ptr=0x7f633800ff60 alloc=`..8c.:277 free#1=:200 > free#2=crypto/asn1/asn1_lib.c:323 > Nov 11 15:53:55 jadzia stunnel: INTERNAL ERROR: Bad magic at > crypto/asn1/asn1_lib.c, line 323 based on this it seems that stunnel itself tries to free memory allocated by openssl which it should not do. And this goes on until it finds that is not a chunk but something completely different and then goes boom. Can you try the patch attached on stunnel, recompile it and check if it still goes boom? > Cheers, > gregor Sebastian diff --git a/src/tls.c b/src/tls.c index 3964f9ce6f2d..8b2b18938d74 100644 --- a/src/tls.c +++ b/src/tls.c @@ -100,6 +100,7 @@ void tls_cleanup() { tls_data=tls_get(); if(!tls_data) return; +OPENSSL_thread_stop(); str_cleanup(tls_data); str_free(tls_data->id); /* detached allocation */ tls_set(NULL);
Bug#824532: udev: Include udev rules for more U2F devices
Am 13.11.2016 um 16:06 schrieb Michael Biebl: > Am 13.11.2016 um 07:46 schrieb Simon Josefsson: >> Hi. The udev file is needed by all applications using u2f, and not all >> uses libu2f-host. For example, chromium needs the udev rule to work. It >> just needs to be present on all systems for u2f to work. Alternatively, >> every package that wants to talk to a u2f device needs to ship the file >> which doesn't scale very well. > > Or such applications depend on a libu2f-common package. > Btw, splitting out the udev rules from the libu2f-host0 library package seems like something you should do in any case. Otherwise it makes soname bumps needlessly complicated as the two library packages need to conflict with each other. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#844272: RM: gnupg -- ROM; obsoleted by gnupg1 and gnupg2 source packages
Package: ftp.debian.org Severity: normal Control: affects -1 src:gnupg The source package "gnupg" has been replaced by source package "gnupg1", which is now an upstream version ahead. The "gnupg2" source package provides a binary package "gnupg", which should *not* be removed from debian! :) Please drop the source package "gnupg" from unstable. I'd also like it to be dropped from experimental and testing. Please let me know if i should open a distinct bug report about experimental and testing, or whether this one is sufficient. Regards, --dkg
Bug#844270: [Pkg-utopia-maintainers] Bug#844270: firewalld: fails to load samba service with 4.8.0-1
Control: tags -1 confirmed Control: retitle -1 firewalld: get_nf_conntrack_helpers() broken due to hard-coded path Am 13.11.2016 um 23:19 schrieb Achim Schaefer: > Package: firewalld > Version: 0.4.4.1-1 > Severity: important > > Dear Maintainer, > > when trying to load the samba server with kernel 4.8.0-1 the folowing > messages appear: > firewalld[1004]: WARNING: INVALID_HELPER: 'nf_conntrack_netbios_ns' not > available in kernel > > even after manually loading the module with modprobe nf_conntrack_netbios_ns, > the same message appears. > > Removing the module line in samba.xml avoids the error, and samba works again. Thanks for your bug report. This looks like an incorrect path in /usr/lib/python3/dist-packages/firewall/functions.py in get_nf_conntrack_helpers(). The path to modinfo is hard-coded as /usr/sbin/modinfo [1] Changing that to /sbin/modinfo and restarting firewalld should fix the issue. [1] http://sources.debian.net/src/firewalld/0.4.4.1-1/src/firewall/functions.py/#L339 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#119544: Dear Benficiary
Greeting ! Dear Benficiary I want to inform you that my bank have prepare your your fund amount $3.8Million Usd, in Atm Debit Card and ready to post to your address. Reply back for more delivery direction it is very important notice. Yours Faithful Kayla Morni Mohd
Bug#819530: Dear Benficiary
Greeting ! Dear Benficiary I want to inform you that my bank have prepare your your fund amount $3.8Million Usd, in Atm Debit Card and ready to post to your address. Reply back for more delivery direction it is very important notice. Yours Faithful Kayla Morni Mohd
Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]
control: tag -1 +moreinfo control: owner -1 ! Dear Nicholas, On Sat, Nov 12, 2016 at 10:18:54PM -0500, Nicholas D Steeves wrote: > I am looking for review and a sponsor for my package "src:muse-el". > I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and > any emacs-on-Debian integration issues. In the future, when submitting a new bug, please use X-Debbugs-CC: rather than CC: so that the bug gets assigned a number before reaching my inbox. I've split my review into two sections: things that I would consider must-fixes before an upload to Debian, and suggested improvements. The latter aren't strictly necessary, but they would help demonstrate to a potential sponsor that you are committed to maintaining this package in Debian. Must-fixes == 1. Your changelog could do with some work. - you should close the ITA bug - "Elpafy!" is not informative; please rewrite - the change to use 3.0 (quilt) and debhelper compat 9 should be separate entries - "Include images used by the QuickStart.muse example" -- what does 'include' mean? Are you installing them? Be specific. - "Fix misattributed source" -- which? - "Update format." -- from what to what? - "add override" -- you could say specifically which overrides you added - "Install docs and examples the new dh_way." -- it's not really new, so I would say "Install docs and examples with dh_install* tools." - "Thank you Kevin Ryde ..." -- it's good to thank people, but I find it too informal to talk about your personal history of learning the command ;) How about just "Thank you to Kevin Ryde for suggesting this change." (and thanks, I didn't know about see(1) either :)) - "texi stuff" -- again, informal and not informative. How about just s/stuff/documentation/? > Is debian/changelog too verbose and could it be condensed? I don't find it to be too verbose. 2. Use spaces, not tabs, to wrap lines in debian/NEWS. 3. README.Debian should have a single timestamp. Remove the previous maintainer's timestamp, add subheadings for the parts added by each of you, and put your timestamp at the bottom. 4. The maintainer should be the pkg-emacsen team, with you as an uploader. See other team packages. 5. There are a lot of Lintian warnings. Please make the package Lintian-clean. 6. The package fails testing with adequate: 2m16.3s ERROR: FAIL: Inadequate results from running adequate! elpa-muse: py-file-not-bytecompiled /usr/share/emacs/site-lisp/elpa-src/muse-3.20/getstamps.py elpa-muse: py-file-not-bytecompiled /usr/share/emacs/site-lisp/elpa-src/muse-3.20/hardcodedates.py elpa-muse: py-file-not-bytecompiled /usr/share/emacs/site-lisp/elpa-src/muse-3.20/metadate.py 7. These .py files should probably not be installed into /usr/share/emacs -- or is it impossible to use them outside of Muse? Have you considered installing them according to the python packaging policy? Can Muse be patched to use them when installed that way? > Are the generated packages in the correct sections for an elpafied > package? Yup. > Is removing hrefs to favicon.ico (Bug: #775885) sufficient? > Distributing a favicon.ico seems unnecessary and honestly, I'm > against it. In Canada, because the author retains all distribution > rights in the absence of a license or declared copyright, even > something as trivial as a favicon.ico can be unredistributable. I > couldn't find the license on Michael Olson's website > , so I decided it was best not to copy it. Yes, I think just removing the href is fine. > Do my patches look ok? 8. They need patch headers, preferably conforming to DEP-3, explaining what each of them is for. Try to include a Forwarded: header, in particular. > Should elpafied packages continue to be arch-independent? Yup. Suggestions === 1. Consider using dh compat 10. 2. Consider adding Enhances: emacs25. 3. Consider priority: optional, not extra. 4. Please use secure URIs in Vcs-* fields. 5. Please add doc-base registration. I haven't tried installing and running the package yet, but the above should be enough to be going on with. -- Sean Whitton signature.asc Description: PGP signature
Bug#844150: jessie-pu: package lxc/1:1.0.6-6+deb8u4
Control: tags -1 + pending On Sun, 2016-11-13 at 16:20 +0100, Evgeni Golov wrote: > On Sun, Nov 13, 2016 at 09:50:09AM +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Sat, 2016-11-12 at 21:33 +0100, Evgeni Golov wrote: > > > we would like to fix two bugs in LXC in stable: > > > #838517 lxc-alpine template broken > > > simple one-line patch to tell OpenSSL which hashing algo to use > > > #838957 read-only bind mounts are in fact read/write > > > another quite short patch to trigger remounting bind mounts as RO > > > > Please go ahead. > > Thanks, uploaded. Flagged for acceptance; thanks. Regards, Adam
Bug#844161: jessie-pu: package redmine/3.0~20140825-8~deb8u4
Control: tags -1 + pending On Sun, 2016-11-13 at 08:51 -0200, Antonio Terceiro wrote: > On Sun, Nov 13, 2016 at 09:47:05AM +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Sat, 2016-11-12 at 19:05 -0200, Antonio Terceiro wrote: > > > redmine (3.0~20140825-8~deb8u4) jessie; urgency=medium > > > > > > * debian/postinst: handle dependency check failure when triggered, to > > > avoid > > > breaking in the middle of dist-upgrades. > > > * gemfile-adjustments.patch: avoid opening database configuration that > > > are > > > not readable (Closes: #826663) > > > > Please go ahead. > > Uploaded, thanks Thanks; flagged for acceptance. Regards, Adam
Bug#844271: imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'
Control: tags -1 upstream Control: severity -1 important Hi Jochen, Thanks very much for the report! On 23:20 Sun 13 Nov , Jochen Sprickerhof wrote: > upgrading dovecot from 1:2.2.26.0-1 to 1:2.2.26.0-3 results in this > error in the log: > > dovecot: imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol > 'SSLv2' > > and not being able to log in. Adding > > ssl_protocols = !SSLv3 > > to my config fixed it for now. Note that I hadn't specified ssl_protocols > before, so I guess the default is broken. Yes, this seems to originate from the defaults for ssl_protocols which is "!SSLv2". Apparently, OpenSSL 1.1 knows nothing about SSLv2, hence the message. I'll forward this upstream. Regards, Apollon
Bug#844117: [pkg-gnupg-maint] Bug#844117: gnupg locks up until straced
On Sun 2016-11-13 01:45:45 +0900, Ian Jackson wrote: > Package: gnupg > Version: 2.1.15-4 > > I just tried to use caff. I found that it seemed to hang, every > time. I tried debugging it with strace. > > I discovered that caff had run a gpg-connect-agent process. It was > calling connect() to connect to /run/user/1000/gnupg/S.dirmngr. The > corresponding listening socket in question was owned by a dirmngr > process. > > I straced the dirnmgr process and got: > > root(ian)@zealot:~> strace -fp14006 > strace: Process 14006 attached with 3 threads > [pid 17554] futex(0x7f459d683200, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ) = -1 > EAGAIN (Resource temporarily unavailable) > [pid 17554] getsockopt(1, SOL_SOCKET, SO_PEERCRED, {pid=17553, uid=1000, > gid=1000}, [12]) = 0 > [pid 17554] futex(0x7f459d683200, FUTEX_WAKE_PRIVATE, 1) = 0 > ... > > And then caff unwedged. > > This all happened to me twice. I may be able to repro it. > > I suspect thread mishandling by dirmngr. This looks like #840680 to me, which was resolved in 2.1.15-6. Please test a more recent version of dirmngr, and if it resolves your problems, please merge this bug report into 840680. Regards, --dkg signature.asc Description: PGP signature
Bug#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]
On Sun, Nov 13, 2016 at 12:43:28PM -0500, Ross Vandegrift wrote: > I am looking for a sponsor for my package "terminology" > > * Package name: terminology > > Changes since the last upload: > > [ Ross Vandegrift ] > * Non-maintainer upload. > * New upstream release > - Fix for "CVE-2015-8971: Escape Sequence Command Execution > vulnerability" (Closes: #843434) > * Enable build hardening options > * Suggest libemotion-players for media support (Closes: #773057, #766705) > * Reformat package descriptions (Closes: #779494, #782082) > * Use secure Vcs- URLs in debian/control > * Bump Standards-Version to 3.9.8 > * fix-minus-signs-manpage.patch: drop patch, fixed upstream > * use-system-lz4.patch: defuzz > * fix-del-backspace-key.patch: defuzz > * Provide x-terminal-emulator alternative (Closes: #774111) > * debian/copyright: remove unused ltmain.sh paragraph > * Add gbp.conf and notes on usage in README.source > > [ Nicolas Braud-Santoni ] > * Normalize links and use HTTPS Such a laundry list of changes is grossly inappropriate for a NMU. On the other hand, the package got orphaned just 18 minutes after you filed this RFS. This means, there's no M to N.U anymore... Could you please decide whether you'd want to adopt this package, and change the maintainer field to yourself if yes, or to the QA team if not? Obviously, in either case this upload won't be a NMU anymore. Meow! -- A true bird-watcher waves his tail while doing so.
Bug#844271: imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'
Package: dovecot-imapd Version: 1:2.2.26.0-3 Severity: normal Dear Maintainer, upgrading dovecot from 1:2.2.26.0-1 to 1:2.2.26.0-3 results in this error in the log: dovecot: imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2' and not being able to log in. Adding ssl_protocols = !SSLv3 to my config fixed it for now. Note that I hadn't specified ssl_protocols before, so I guess the default is broken. Cheers Jochen -- Package-specific info: dovecot configuration - # 2.2.26.0 (23d1de6): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.16 (fed8554) # OS: Linux 4.7.0-1-amd64 x86_64 Debian stretch/sid mail_location = mbox:~/mail:INBOX=/var/mail/%u mail_max_userip_connections = 50 namespace inbox { [..] } passdb { driver = pam } passdb { args = scheme=CRYPT username_format=%u /etc/dovecot/users driver = passwd-file } plugin { sieve = file:~/sieve;active=~/.dovecot.sieve } protocols = " imap" ssl_cert = Versions of packages dovecot-imapd is related to: ii dovecot-core [dovecot-common] 1:2.2.26.0-3 pn dovecot-dbg pn dovecot-dev pn dovecot-gssapi ii dovecot-imapd 1:2.2.26.0-3 pn dovecot-ldap pn dovecot-lmtpd pn dovecot-managesieved pn dovecot-mysql pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.2.26.0-3 pn dovecot-sqlite -- no debconf information
Bug#844270: firewalld: fails to load samba service with 4.8.0-1
Package: firewalld Version: 0.4.4.1-1 Severity: important Dear Maintainer, when trying to load the samba server with kernel 4.8.0-1 the folowing messages appear: firewalld[1004]: WARNING: INVALID_HELPER: 'nf_conntrack_netbios_ns' not available in kernel even after manually loading the module with modprobe nf_conntrack_netbios_ns, the same message appears. Removing the module line in samba.xml avoids the error, and samba works again. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firewalld depends on: ii dbus 1.10.12-1 ii gir1.2-glib-2.0 1.50.0-1 ii init-system-helpers 1.46 ii iptables 1.6.0-4 ii policykit-1 0.105-17 ii python3-dbus 1.2.4-1 ii python3-gi 3.22.0-1 ii python3-slip-dbus0.6.1-3 pn python3:any Versions of packages firewalld recommends: ii ebtables 2.0.10.4-3.5 ii ipset 6.29-1 firewalld suggests no packages. -- Configuration Files: /etc/firewalld/firewalld.conf [Errno 13] Keine Berechtigung: u'/etc/firewalld/firewalld.conf' /etc/firewalld/lockdown-whitelist.xml [Errno 13] Keine Berechtigung: u'/etc/firewalld/lockdown-whitelist.xml' -- no debconf information
Bug#840424: RFS: verilog-mode/0:20160910.debfc6d.vpo-1
control: owner -1 ! Dear Kiwamu, On Wed, Nov 09, 2016 at 07:42:56PM +0900, Kiwamu Okabe wrote: > Could you again review my package? It says in the changelog that you are not supporting xemacs anymore. This was the reason for not using dh_elpa. Is this a temporary problem? Will you be able to support xemacs in the future? If not, you should use dh_elpa. > The '.vpo' suffix should be removed, because it has no meaning. > But I would like to use '0:' prefix for bumping up version with epoch. > Could you see following `uim` package?: > > https://anonscm.debian.org/git/collab-maint/uim.git/tree/debian/changelog You can always add a 1: epoch later. It shouldn't be added until it is actually needed. Please remove the '0:' for now. > > 4. Use secure URIs for the Vcs-* fields. > > Following causes lintian vcs-field-uses-not-recommended-uri-format error: > > Vcs-Git: ssh://git.debian.org/git/pkg-emacsen/pkg/verilog-mode.git > > Following is correct? > > Vcs-Git: git://anonscm.debian.org/pkg-emacsen/pkg/verilog-mode.git > Vcs-Browser: https://anonscm.debian.org/git/pkg-emacsen/pkg/verilog-mode.git No, you should use https for the Vcs-Git: header too. See other pkg-emacsen team packages. -- Sean Whitton signature.asc Description: PGP signature
Bug#828978: RFS: install-mimic/0.2.0-1 (ITP)
control: tag -1 -moreinfo Hello Peter, On Tue, Nov 08, 2016 at 08:39:46PM +0200, Peter Pentchev wrote: > Oof, and here I was thinking I'd answered those... two months ago? > Sorry :( Well, stretch hasn't been frozen yet, so no need for an apology :) > > 1. This package has a perl and a C version of the program, and you > > install the C one. Have you considered installing both and using > > the alternatives system to permit the user to choose? > > I don't think that there would be any real purpose to that; if there is > a compiled C version available, I don't see why anyone would want/need > the other one. I think you're right. > > 2. Your autopkgtest test suite appears to test the perl version? > > Not sure -- would be best to add comments to the debian/test/control > > file. > > Not really; as Jakub Wilk pointed out, the autopkgtest suite uses > the upstream source's test suite for testing whatever is installed as > /usr/bin/install-mimic. The fact that the test suite itself uses > Perl's Test Anything Protocol and prove(1) as the TAP handler is > kind of besides the point. Right, okay. > > 3. If users need to overwrite files installed by Debian packages, > > they should use dpkg-divert and/or dpkg-statoverride. Perhaps it > > should be stated clearly in the package description that > > install-mimic should be used in combination with those tools. > > Hmm, actually the whole point of install-mimic is to avoid having to > even know what dpkg-statoverride is :) Okay, fine, the whole point of > install-mimic is to avoid hanving to know what install(1)'s arguments > are and what stat(1)/stat(2) does, but you get the idea :) > > Nah, you're right, I might add a documentation section about various > tools in various OS/distributions. However, the main use that I have > for install-mimic is either for configuration files or for files > installed by third-party packages... and, yeah, you're right that > the examples given in the manual page do not really reflect that. > I'll work on it in a future release. Personally, I wouldn't want to upload install-mimic to Debian until these documentation changes come through. It's perfectly fine to give users the choice of using install-mimic, but they should know how it relates to the standard Debian tools. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, On Wed, Nov 09, 2016 at 05:17:29PM +, David Hart wrote: > Dear Sean, > > Thank you for your comments. > > >I'd recommend including the upstream code in the git repository, too. > >But what you've done is fine -- thanks! > > I've now added that too. I think you misunderstood what I was suggesting. You've committed the tarball to git, but I meant adding the unpacked upstream source. Unfortunately, your change means that I can't build your package from the git repository, so it's hard for me to continue my review. Please consider using gbp-import-dsc(1), or reverting to only having debian/ in git if you prefer. Also, the Vcs-* fields still point to the upstream source, not the packaging repository. -- Sean Whitton signature.asc Description: PGP signature
Bug#816042: Don't include in stretch
On Thu, Nov 10, 2016 at 11:29:09AM +0100, Bernhard Schmidt wrote: > On Fri, Feb 26, 2016 at 10:31:43PM +0100, Moritz Muehlenhoff wrote: > > Hi Moritz, > > > Source: asterisk > > Severity: serious > > 0;115;0c> > asterisk hasn't seen a maintainer upload to unstable in 2015. It's > > already excluded from testing due to an unrelated FTBFS bug. This > > bug is used to ensure that it doesn't enter stretch unless maintenance > > (especially for the lifetime of stable) is properly ensured again. > > Looking at the history now, does the security team feel that asterisk is > sufficiently maintained to be included in Stretch now? Yeah, if you're continuing what you've been doing in the past months, feel free to close the bug. Cheers, Moritz
Bug#452764: #452764 - epiphany-webkit: view page source feature does not work
Hi Intrigeri, this is an old bug ... Could you please still try to reproduce this issue with newer versions of epiphany ? How did you set a preferred application in ~/.local/share/applications/defaults.list ? thanks regards Pedro