Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lucas Nussbaum]

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

[Christos Trochalakis]

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

[Michael Stapelberg]

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

[Johannes Schauer]

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)

[Ondřej Surý]

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)

[Ondřej Surý]

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

[Paul Wise]

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

[Laura Arjona Reina]

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

[Christoph Reiter]

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

[Daniel Baumann]

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

[Johannes Schauer]

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=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)

[Adrian Bunk]

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

[Paul Wise]

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=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

[duck]

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

[Lars Tangvald]

- 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

[Johannes Schauer]

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

[Lars Tangvald]

- 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

[Paul Wise]

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

[Salvatore Bonaccorso]

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'

[Salvatore Bonaccorso]

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

[Niels Thykier]

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

[Helmut Grohne]

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

[Lars Tangvald]

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

[duck]

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

[Paul Wise]

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

[Daniel Baumann]

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

[Helmut Grohne]

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

[Helmut Grohne]

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

[Johannes Schauer]

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

[Ondřej Surý]

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

[Montxero]

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   

Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)

[Ondřej Surý]

> 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, , 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, , 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

[James McCoy]

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

[Lance Lassetter]

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)

[Donald Norwood]

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

[Dmitry Smirnov]

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

[Tim Boundy]

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=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

[Kiwamu Okabe]

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

[Michel Dänzer]

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

[Dmitry Smirnov]

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

[FedEx 2Day]

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

[Julien Cristau]

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

[Dmitry Smirnov]

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

[Vagrant Cascadian]

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

[James McCoy]

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

[Ondřej Surý]

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

[pkg-go-maintainers]

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]

[Tim Connors]

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

[Paul Wise]

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

[Potter, Tim (HPE Linux Support)]

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

[Ryan Tandy]

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

[Potter, Tim (HPE Linux Support)]

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

[pkg-go-maintainers]

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

[FedEx International Next Flight]

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

[Harlan Lieberman-Berg]

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(>dtoa, p->tokenbuf, );
+ 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

[Daniel Kahn Gillmor]

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

[Scott Kitterman]

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

[Achim Schaefer]

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

[Kiwamu Okabe]

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.

[Jeffrey Cliff]

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:

[Michael Hudson-Doyle]

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

[Robert J. Clay]

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

[Egmont Koblinger]

Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/

Bug#844277: Specifying specific IP for inet_interfaces prevents postfix from starting

[Mathias Gibbens]

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

[Ben Hutchings]

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

[Pablo Di Noto]

> (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 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

[Pablo Di Noto]

(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 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

[Robert J. Clay]

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

[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


signature.asc
Description: This is a digitally signed message part.

Bug#844275: mysql_config injects build flags which breaks the build for other packages

[Michael Biebl]

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

[Mattia Rizzolo]

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

[Gaetano Guerriero]

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.

[Ole Jørgen Brønner]

(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)

[gregor herrmann]

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 

Bug#844272: RM: gnupg -- ROM; obsoleted by gnupg1 and gnupg2 source packages

[Scott Kitterman]

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

[Jacco Ligthart]

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::~_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

Bug#844262: liferea: start with hidden main window no longer working

[Wolfgang Becker]

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

[Samuel Thibault]

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

[Daniel Kahn Gillmor]

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

[Daniel Kahn Gillmor]

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

[Michael Herold]

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)

[Sebastian Andrzej Siewior]

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

[Michael Biebl]

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

[Daniel Kahn Gillmor]

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

[Michael Biebl]

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

[Kayla Morni Mohd]

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

[Kayla Morni Mohd]

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]

[Sean Whitton]

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

[Adam D. Barratt]

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

[Adam D. Barratt]

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'

[Apollon Oikonomopoulos]

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

[Daniel Kahn Gillmor]

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]

[Adam Borowski]

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'

[Jochen Sprickerhof]

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

[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.

-- 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

[Sean Whitton]

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)

[Sean Whitton]

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

[Sean Whitton]

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

[Moritz Mühlenhoff]

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

[Pedro Beja]

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