Bug#852397: lightdm does not display a greeter dialog when accessed via XDMCP from a cygwin XWin server

[Paul Ausbeck]

Package: lightdm
Version: 1.18.3-1

I attempt to connect via XDMCP to a machine running Debian Sid/Stretch 
from a remote cygwin based Xserver. The remote session starts and 
displays a black screen with nothing but a mouse cursor in the very 
middle. The mouse cursor then jumps to the upper left corner of the 
screen and nothing further happens. I am expecting to see the lightdm 
greeter which never appears. I have several other machines running 
Debian Jessie and Debian Wheezy and can connect to them with no 
problems. I have two machines running Sid/Stretch and I can't connect to 
either. The problem is specific to Sid/Stretch and I would classify it 
as a regression.


I have included the lightdm greeter error log, 
/var/log/lightdm/(null)-greeter.log, from the Sid/Stretch machine below. 
The WARNING related to the upstart command and the WARNING related to 
negative dimensions are present in the greeter log for the physical 
monitor/keyboard so I guess that they are not related to the problem. I 
would guess that the problem lies with the gdk_pixbuf calls.


I have also included the lightdm greeter log from a successful 
connection to a Debian Jessie machine even further below. Note that the 
name of the greeter log file is "x-192.168.1.50-0-greeter.log" for a 
successful connection and "(null)-greeter.log" for an unsuccessful 
connection. Perhaps the name difference is related to the problem.


I don't know enough about the various pieces of this puzzle so I don't 
know if I should file this bug against Debian or cygwin. I'm thinking 
somehow that I shouldn't have to make changes to my Xserver to connect 
to a Sid/Stretch machine when I can connect just fine to Jessie and 
Wheezy machines with the same Xserver.


The problem machines are running  freshly updated/upgraded Debian 
Sid/Stretch: /etc/debian_version 9.0



Unsuccessful greeter log from Debian Sid/Stretch machine:

root@dn2800mt2:/var/log/lightdm# cat \(null\)-greeter.log
** Message: Starting lightdm-gtk-greeter 2.0.2 (Nov 16 2016, 20:48:17)
** Message: [Configuration] Reading file: 
/usr/share/lightdm/lightdm-gtk-greeter.conf.d/01_debian.conf
** Message: [Configuration] Reading file: 
/etc/lightdm/lightdm-gtk-greeter.conf

Activating service name='org.a11y.atspi.Registry'
Successfully activated service 'org.a11y.atspi.Registry'

** (lightdm-gtk-greeter:1422): WARNING **: [PIDs] Failed to execute 
command: upstart


(lightdm-gtk-greeter:1422): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: 
assertion 'width > 0' failed


(lightdm-gtk-greeter:1422): GdkPixbuf-CRITICAL **: gdk_pixbuf_composite: 
assertion 'GDK_IS_PIXBUF (dest)' failed


(lightdm-gtk-greeter:1422): GLib-GObject-CRITICAL **: g_object_ref: 
assertion 'G_IS_OBJECT (object)' failed


** (lightdm-gtk-greeter:1422): WARNING **: [Background] Failed to read 
wallpaper: /usr/share/images/desktop-base/login-background.svg


(lightdm-gtk-greeter:1422): GLib-GObject-CRITICAL **: g_object_unref: 
assertion 'G_IS_OBJECT (object)' failed


(lightdm-gtk-greeter:1422): Gtk-WARNING **: Drawing a gadget with 
negative dimensions. Did you forget to allocate a size? (node menubar 
owner GreeterMenuBar)
Gdk-Message: lightdm-gtk-greeter: Fatal IO error 11 (Resource 
temporarily unavailable) on X server 192.168.1.50:0.



Successful greeter log from Debian Jessie machine:

root@dn2800mt:/var/log/lightdm# cat x-192.168.1.50-0-greeter.log
(lightdm-gtk-greeter:1686): Gtk-CRITICAL **: gtk_container_foreach: 
assertion 'GTK_IS_CONTAINER (container)' failed


(lightdm-gtk-greeter:1686): Gtk-CRITICAL **: gtk_container_foreach: 
assertion 'GTK_IS_CONTAINER (container)' failed


(lightdm-gtk-greeter:1686): Gtk-CRITICAL **: gtk_container_foreach: 
assertion 'GTK_IS_CONTAINER (container)' failed

Bug#793106: htop: malfunctions with TERM=linux-16color [was: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)]

[Daniel Lange]

Control: severity -1 minor
Control: tags -1 moreinfo

TERM=xterm-256color htop # works in xterm from Jessie. No issues.
TERM=linux-16color htop # works, looks ugly (underlines)

So this all works as intended. Obviously a bad choice of terminal
emulation will lead to ugly rendering. I *assume* the original reporter
also had a weird combination of the TERM variable and terminal
application and that led to only highlighted lines rendering readably.

It is not possible for htop to render correctly in all cases where
people have broken terminfo, esp. people sshing from Macs etc.

Bug#852264: gbp buildpackage: doesn't pass options correctly anymore

[Guido Günther]

Hi James,
On Mon, Jan 23, 2017 at 09:51:06PM +, James Clarke wrote:
> Control: tags -1 pending
> (I see you already reassigned)
> 
> On 23 Jan 2017, at 20:21, Guido Günther  wrote:
> > control: tags -1 -unreproducible
> > control: gbp buildpackage quotes arguments twice with 
> > GIT_PBUILDER_AUTOCONF=no
> > 
> > On Mon, Jan 23, 2017 at 11:26:44AM +0100, Raphaël Halimi wrote:
> >> Le 23/01/2017 à 08:29, Guido Günther a écrit :
>  A couples of lines above, I can see:
>  
>  I: Generating source changes file for original dsc
>  dpkg-genchanges: error: unknown option ''-v0.9-1''
> >>> 
> >>> I'm not seeing double quotes here. We changed quoting in 80a1c39
> >>> (0.8.10) so there might be a bug but I can't reproduce this with
> >>> pbuilder 0.227 and 0.228.1.
> >> 
> >> Sorry if I wasn't clear. Those are not double quotes, but two pairs of
> >> single quotes.
> > 
> > I meant doubled quotes - sorry for the confusion ;)
> > 
> > [..snip..]
> >> raph@arche:~/Divers/dev/debian/mine/official/tlp$ DIST=jessie gbp 
> >> buildpackage -v0.9-1
> >> Building with pbuilder
> >> I: Distribution set to jessie (environment variable)
> >> I: using pbuilder as pbuilder
> >> dpkg-checkbuilddeps: error: Unmet build dependencies: dh-systemd
> >> W: Unmet build-dependency in source
> >> dh_testdir
> >> dh_testroot
> >> # add here commands to clean up after the build process.
> >> /usr/bin/make clean
> >> make[1]: Entering directory 
> >> '/home/raph/Divers/dev/debian/mine/official/tlp'
> >> rm -f tlp tlp-functions tlp-nop tlp-rdw-nm tlp-rdw.rules tlp-rdw-udev 
> >> tlp-rf tlp.rules tlp-run-on tlp.service tlp-sleep.service tlp-stat 
> >> tlp.upstart tlp-usb-udev
> >> make[1]: Leaving directory '/home/raph/Divers/dev/debian/mine/official/tlp'
> >> dh_clean
> >> dpkg-source: info: using source format '3.0 (quilt)'
> >> dpkg-source: info: building tlp using existing ./tlp_0.9.orig.tar.gz
> >> dpkg-source: info: building tlp in tlp_0.9-2~bpo8+1.debian.tar.xz
> >> dpkg-source: info: building tlp in tlp_0.9-2~bpo8+1.dsc
> >> I: Generating source changes file for original dsc
> >> dpkg-genchanges: error: unknown option ''-v0.9-1''
> >> 
> >> Use --help for program usage information.
> >> gbp:error: 'BUILDER=pbuilder GIT_PBUILDER_AUTOCONF=no 
> >> /usr/bin/git-pbuilder -v0.9-1' failed: it exited with 2
> >> ->%-
> > 
> > That's the difference. You're using 'GIT_PBUILDER_AUTOCONF=no' (which
> > then used pbuilder instead of cowbuilder):
> > 
> > With GIT_PBUILDER_AUTOCONF=no git-pbuilder invokes pdebuild like
> > 
> >pdebuild --pbuilder cowbuilder --debbuildopts ' '\''-v1.0'\''' -- 
> > --hookdir /home/agx/.pbuilder/hooks
> > 
> > and without GIT_PBUILDER_AUTOCONF=no:
> > 
> >pdebuild --buildresult ../ --pbuilder cowbuilder --debbuildopts ' 
> > '\''-v1.0'\''' -- --hookdir /home/agx/.pbuilder/hooks --basepath 
> > /var/cache/pbuilder/tmpbuild//base-sid.cow
> > 
> > The quoting looks indentical to me so it seems cowbuilder is happy with
> > the quoting while pbuilder isn't. I'm cc'ing the the pbuilder
> > maintainers for their input since I think pbuilder should accept the
> > input (and it did in 0.227). Note that unqoted doesn't work either:
> > 
> >pdebuild --pbuilder cowbuilder --debbuildopts -v1.0 -- --hookdir 
> > /home/agx/.pbuilder/hooks
> > 
> > which I think it should. Raphaël, could you check if downgrading
> > pbuilder 0.227 works for you too.
> 
> This was a bug introduced in pbuilder 0.228.1. The key thing is that the
> GIT_PBUILDER_AUTOCONF=no branch does not specify a BUILDRESULT, so it defaults
> to /var/cache/pbuilder/result. To support backwards compatibility, this ends 
> up
> generating *two* _source.changes:
> 
> 1. *Before* the build in the chroot, using the .dsc generated by dpkg-source.
> This is placed in ../ alongside the .dsc. Note that in the normal case,
> BUILDRESULT is *also* ../, and so pdebuild skips generating this
> _source.changes file, since the .dsc will be replaced by 2.
> 
> 2. *After* the build in the chroot, if SOURCE_ONLY_CHANGES=yes. This is copied
> back to BUILDRESULT.
> 
> The second one was fine, but you're hitting the first case. Unfortunately the
> two cases were expanding the variables differently; 1. ended up doing less
> expansion than 2., so you end up with single quotes not being removed. This 
> has
> been fixed in git by [1].
> 
> (In case you're wondering, the single quotes get stripped correctly, but when
> building up the list of arguments to dpkg-genchanges, they are added around
> each, which is why both the final examples you gave have the problem.)

Thanks for the detailed explanation and the fix!
Cheers,
 -- Guido

Bug#852383: icedove: Telemetry running though toolkit.telemetry.enabled=false

[Carsten Schoenert]

Control: -1 moreinfo

Hello Heinrich,

On Tue, Jan 24, 2017 at 05:05:18AM +0100, Heinrich Schuchardt wrote:
> In my icedove profile I have
> toolkit.telemetry.enabled = false
> 
> But in the error log I find:
> 
> ? Toolkit.Telemetry   WARN
> TelemetryStorage::_enforcePendingPingsQuota - Unable to find the size of ping 
> ----

can you give please some more information about your issue? Sorry, I've
no clue that your are doing and what you expecting here?

Have you checked for similar entries in the Bugzilla bugtracker on
Mozilla? This issues is obviously no Debian specific thing.

Regards
Carsten.

Bug#852004: RFP for bioperl's Bio-EUtilities

[Andreas Tille]

Hi Gregor,

On Mon, Jan 23, 2017 at 11:45:29PM +0100, gregor herrmann wrote:
> 
> The tests fail for me as well, in a chroot with networking firewalled
> off.
> 
> The errors are slightly different, probably because I have http_proxy
> set:
> 
> http error : Operation in progress
> XML::Simple called at 
> /build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
> # Looks like your test exited with 255 before it could output anything.
> t/egquery.t . 
> 1..18
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 18/18 subtests 
> 
> etc. for all t/e*.t tests
> 
> /*
> With http_proxy unset I get:

Thanks for verifying this.
 
> Anyway, it's quite clear that the tests try to access the internet
> which is forbidden by Debian policy (regardless of the fact if the
> fail gracefully or not), so they have to be skipped.
> 
> Andreas, you already know the trick with debian/tests/pkg-perl/smoke-skip
> and using the file in debian/rules as well to disable tests during
> build + autopkgtest. If you don't run okg-perl-autopkgtests, you can
> use:

Yes, I know.  I simply have forwarded the issue upstream since the RFP
came from upstream and I considered it more sensible if they provide
some means to exclude http access directly in their code.
 
> Of course an upstream fix, e.g. skipping tests if
> $ENV{NETWORK_TESTING} is not set etc., would be nicer.

Exactly. :-)

> (Hm, is this the package that was discussed on #debian-perl on IRC
> earlier yesterday? :))

May be - I'm usually not on IRC ...
 
> BTW: I think override_dh_installchangelogs in d/rules is not needed,
> dh_installchangelogs should find Changes by itself.

Thanks, dropped this.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#852396: wireshark: GUI using wrong capture interface

[Philipp Marek]

Package: wireshark
Version: 2.2.3+g57531cd-1
Severity: normal

Clicking on the "lo" interface (with or without a capture filter) results 
in this process tree:

 5985 ?Sl 0:21 /usr/bin/wireshark
 6787 ?Sl 0:00  \_ /usr/bin/dumpcap -t -n -i eth0 ...

and that doesn't work, of course.

# wireshark -i lo -f tcp port 4005 -k

works fine, though.


Similarly, using "any" in the GUI starts a capture...
with "eth0 and eth0" in the statusbar, instead of "eth0", "wlan0", "lo", 
and the various virtual interfaces ("virbr0", "virbr1", "vnet0", etc.),
which is what I would have expected and needed here.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireshark depends on:
ii  wireshark-qt  2.2.3+g57531cd-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

Bug#852039: [pkg-opensc-maint] Bug#852039: pam-p11: diff for NMU version 0.1.5-6.1

[Eric Dorland]

Hi Sam,

Thanks for the patch. I'll prepare an upload for it tomorrow if you
want to hold off for a bit.

* hartm...@debian.org (hartm...@debian.org) wrote:
> Control: tags 852039 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for pam-p11 (versioned as 0.1.5-6.1) and
> uploaded it to DELAYED/2day. I realize this is a small delay, but I want the 
> changes to make it in before the freeze.  Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> diff -Nru pam-p11-0.1.5/debian/changelog pam-p11-0.1.5/debian/changelog
> --- pam-p11-0.1.5/debian/changelog2016-12-10 20:32:54.0 -0500
> +++ pam-p11-0.1.5/debian/changelog2017-01-23 15:13:19.0 -0500
> @@ -1,3 +1,10 @@
> +pam-p11 (0.1.5-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix segfault after token login, Closes: #852039
> +
> + -- Sam Hartman   Mon, 23 Jan 2017 15:13:19 -0500
> +
>  pam-p11 (0.1.5-6) unstable; urgency=medium
>  
>* debian/control: Explicit build-deps on libssl1.0-dev.
> diff -Nru pam-p11-0.1.5/debian/patches/reread_certs_on_token_login 
> pam-p11-0.1.5/debian/patches/reread_certs_on_token_login
> --- pam-p11-0.1.5/debian/patches/reread_certs_on_token_login  1969-12-31 
> 19:00:00.0 -0500
> +++ pam-p11-0.1.5/debian/patches/reread_certs_on_token_login  2017-01-20 
> 17:23:43.0 -0500
> @@ -0,0 +1,40 @@
> +Index: pam-p11/src/pam_p11.c
> +===
> +--- pam-p11.orig/src/pam_p11.c
>  pam-p11/src/pam_p11.c
> +@@ -56,6 +56,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + const char *user;
> + char *password;
> + char password_prompt[64];
> ++int loggedin = 0;
> + 
> + struct pam_conv *conv;
> + struct pam_message msg;
> +@@ -119,7 +120,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + }
> + 
> + /* get all certs */
> +-rv = PKCS11_enumerate_certs(slot->token, , );
> ++ cert_scan: rv = PKCS11_enumerate_certs(slot->token, , );
> + if (rv) {
> + pam_syslog(pamh, LOG_ERR, "PKCS11_enumerate_certs failed");
> + rv = PAM_AUTHINFO_UNAVAIL;
> +@@ -156,7 +157,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + goto out;
> + }
> + 
> +-if (!slot->token->loginRequired)
> ++if (!slot->token->loginRequired ||loggedin)
> + goto loggedin;
> + 
> + /* get password */
> +@@ -209,6 +210,9 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + goto out;
> + }
> + 
> ++loggedin = 1;
> ++goto cert_scan;
> ++
> +   loggedin:
> + /* get random bytes */
> + fd = open(RANDOM_SOURCE, O_RDONLY);
> diff -Nru pam-p11-0.1.5/debian/patches/series 
> pam-p11-0.1.5/debian/patches/series
> --- pam-p11-0.1.5/debian/patches/series   2016-12-10 20:32:54.0 
> -0500
> +++ pam-p11-0.1.5/debian/patches/series   2017-01-20 17:22:14.0 
> -0500
> @@ -1 +1,2 @@
>  0001-Use-INSTALL-instead-of-libLTLIBRARIES_INSTALL.patch
> +reread_certs_on_token_login
> 
> ___
> pkg-opensc-maint mailing list
> pkg-opensc-ma...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#852354: move ptlib.pc to a multiarch location

[Helmut Grohne]

On Mon, Jan 23, 2017 at 09:19:24PM +0100, Eugen Dedu wrote:
> Thank you for the patch.  If you tested the patch and it works, do you mind
> to upload it too?

Yeah, I tested that it makes the opal build go further. Still, changing
--libdir moves other files and thus as a small non-zero chance of
introducing a regression. I therefore suggest postponing the bug until
after stretch as we are very close to the full freeze now. We shouldn't
be fixing non-rc bugs now.

Helmut

Bug#852395: unblock: gssproxy/0.5.1-2

[Robbie Harwood]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gssproxy

gssproxy has been 10 days in unstable, and allowing it to migrate will fix
bug#848306 (severity: important) in nfs-common.  gssproxy is a new package in
unstable (so no debdiff is included), and would have made the freeze had I not
made a mistake documenting copyright.

Thanks.

unblock gssproxy/0.5.1-2

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (600, 'testing-debug'), (600, 'testing'), (400, 
'unstable-debug'), (400, 'unstable'), (200, 'experimental-debug'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#851989: release.debian.org: de-branding Icedove, Thunderbird packages in Stretch?

[Carsten Schoenert]

Hello Julien,

On Sun, Jan 22, 2017 at 05:32:01PM +0100, Julien Cristau wrote:
> I guess it's better to do that now rather than after the release.  What
> are the effects of the rebranding on reverse dependencies, if any?

thanks for your positive answer in principal about that! And yes, we
think also the switch is done better now than some weeks after the
relase.

I'm running Thunderbird packages for about at least 1/2 year in all
versions since 45.1.0. I haven't had any problems on that and haven't
seen any non working reverse depended packages. But I can't test all
xul-ext-* packages and other named plugins that can be found in the
repository. As far as I've seen most of the maintainers of such packages
have already done the extension the the package description with the
adoption of the Provides/Enhances and the Depends field of their
packages.
So maybe some extension may break now simply because the package
dependencies are now to strict. Such packages should be easy to find as
if the icedove package is referenced the thunderbird package needed to
be provided as well. Christoph could (and should) address such problems
in his announcement.

The typical extensions I'm using are working so far. Normaly I've
installed enigmail, xul-ext-adblock-plus, xul-ext-compactheader,
xul-ext-dispmua.

I don't know a binary based reverse package that is using header and
libs from icedove-dev or thunderbird-dev package. And I haven't done a
look in detail into the the libraries in

/usr/lib/icedove-devel/sdk/lib/

and

/usr/lib/thunderbird-devel/sdk/lib/

Namely there are four libararies there:
  libldap60.so, libldif60.so, libprldap60.so, libxul.so

So I can't say right now if there are some potentially pitfall inside.
But that should be easy to check.

Regards
Carsten

Bug#819273: Roboto Slab, Roboto Mono and additional weights of Roboto are missing

[Stefan Tatschner]

On Tue, 13 Dec 2016 19:26:31 +0100 Paride Legovini 
wrote:
> I assume the same is true for the Mono variant.
> Will you consider including the Apache licensed Slab and Mono variants from
> 
> https://github.com/google/fonts/tree/master/apache/robotoslab
> https://github.com/google/fonts/tree/master/apache/robotomono
> 
> in this package?

I personally would also be fine if a separate package is being created
for the mono variants. What do the debian maintainers think about this?

Stefan

Bug#816313: patch and proposed NMU

[Adam Borowski]

Control: tags -1 +patch

Hi!
Here's a fix.  I've used a modified version of bash's approach: let's check
the first line only, but declare any bytes 0..8, 16..26, 28..31, 127 as
non-text.

As dash hasn't seen a maintainer upload in three years, and the effective
freeze date is this Thursday, I'm uploading a DELAYED/2 NMU immediately.
Besides this RC fix, I've picked two other trivial bugs as well; please
shout if you want the upload cancelled or amended.

Patch and proposed NMU diff attached.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11
>From fe901f54d6504076ead29c9447f3abf7a903e9a8 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Tue, 24 Jan 2017 05:11:38 +0100
Subject: [PATCH 1/2] Don't execute binary files if execve() returned ENOEXEC.

Both "dash -c foo" and "./foo" are supposed to be able to run hashbang-less
scripts, but attempts to execute common binary files tend to be nasty:
especially both ELF and PE tend to make dash create a bunch of files with
unprintable names, that in turn confuse some tools up to causing data loss.

Thus, let's read the first line and see if it looks like text.  This is a
variant of the approach used by bash and zsh; mksh instead checks for
signatures of a bunch of common file types.

POSIX says: "If the executable file is not a text file, the shell may bypass
this command execution.".

Signed-off-by: Adam Borowski 
---
 src/exec.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/src/exec.c b/src/exec.c
index ec0eadd..72acd5e 100644
--- a/src/exec.c
+++ b/src/exec.c
@@ -148,6 +148,38 @@ shellexec(char **argv, const char *path, int idx)
 }
 
 
+/*
+ * Check if an executable that just failed with ENOEXEC shouldn't be
+ * considered a script (wrong-arch ELF/PE, junk accidentally set +x, etc).
+ * We check only the first line to allow binaries encapsulated in a shell
+ * script without proper quoting.  The first line, if not a hashbang, is
+ * likely to contain comments; even ancient encodings, at least popular
+ * ones, don't use 0x7f nor values below 0x1f other than whitespace (\t,
+ * \n, \v, \f, \r), ISO/IEC 2022 can have SI, SO and \e).
+ */
+STATIC int file_is_binary(const char *cmd)
+{
+	char buf[128];
+	int fd = open(cmd, O_RDONLY|O_NOCTTY);
+	if (fd == -1)
+		return 1;
+	int len = read(fd, buf, sizeof(buf));
+	for (int i = 0; i < len; ++i) {
+		char c = buf[i];
+		if (c >= 0 && c <= 8 ||
+		c >= 16 && c <= 31 && c != 27 ||
+		c == 0x7f) {
+			close(fd);
+			return 1;
+		}
+		if (c == '\n')
+			return 0;
+	}
+	close(fd);
+	return 0;
+}
+
+
 STATIC void
 tryexec(char *cmd, char **argv, char **envp)
 {
@@ -162,6 +194,8 @@ repeat:
 	execve(cmd, argv, envp);
 #endif
 	if (cmd != path_bshell && errno == ENOEXEC) {
+		if (file_is_binary(cmd))
+			return;
 		*argv-- = cmd;
 		*argv = cmd = path_bshell;
 		goto repeat;
-- 
2.11.0

diff -u dash-0.5.8/debian/changelog dash-0.5.8/debian/changelog
--- dash-0.5.8/debian/changelog
+++ dash-0.5.8/debian/changelog
@@ -1,3 +1,12 @@
+dash (0.5.8-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't execute binary files as scripts. (Closes: #816313)
+  * printf '\e' (Closes: #816295)
+  * Fix bad permissions on dash.md5sums (Closes: #832173)
+
+ -- Adam Borowski   Tue, 24 Jan 2017 06:16:56 +0100
+
 dash (0.5.8-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dash-0.5.8/debian/implicit dash-0.5.8/debian/implicit
--- dash-0.5.8/debian/implicit
+++ dash-0.5.8/debian/implicit
@@ -92,6 +92,7 @@
@cd debian/$* && find * -path 'DEBIAN' -prune -o \
  -type f -print0 | LC_ALL=C sort -z | \
xargs -0r md5sum >>DEBIAN/md5sums
+   @chmod 0644 debian/*/DEBIAN/md5sums
 %.deb-DEBIAN: %.deb-checkdir %.deb-DEBIAN-base %.deb-DEBIAN-scripts \
  %.deb-DEBIAN-md5sums
: debian/$*/DEBIAN/ ok
only in patch2:
unchanged:
--- 
dash-0.5.8.orig/debian/diff/0007-Don-t-execute-binary-files-if-execve-returned-ENOEXE.diff
+++ 
dash-0.5.8/debian/diff/0007-Don-t-execute-binary-files-if-execve-returned-ENOEXE.diff
@@ -0,0 +1,77 @@
+From fe901f54d6504076ead29c9447f3abf7a903e9a8 Mon Sep 17 00:00:00 2001
+From: Adam Borowski 
+Date: Tue, 24 Jan 2017 05:11:38 +0100
+Subject: [PATCH 1/2] Don't execute binary files if execve() returned ENOEXEC.
+
+Both "dash -c foo" and "./foo" are supposed to be able to run hashbang-less
+scripts, but attempts to execute common binary files tend to be nasty:
+especially both ELF and PE tend to make dash create a bunch of files with
+unprintable names, that in turn confuse some tools up to causing data loss.
+
+Thus, let's read the first line and see if it looks like text.  This is a
+variant of the approach used by bash and zsh; mksh instead checks for
+signatures of a bunch of common file types.
+
+POSIX says: "If the executable file is not a text file, 

Bug#850920: Cabal-debian bundled packages

[Kei Hibino]

Hi Gianfranco,

I think this outout is good because this build-depends does not
contain built-in package with version constraint.

On Thu, Jan 19, 2017 at 11:02 PM, Gianfranco Costamagna
 wrote:
> Hello Kei,
> On Tue, 17 Jan 2017 19:42:57 + David Fox  wrote:
>> Fortunately or unfortunately, I made extensive changes to this code in
>> November:
>>
>
> I did apply your patch and the head result didn't change
>
>> https://github.com/ddssff/cabal-debian/commit/480f4f099657a20eb46a45c0ca5f492038773e5b
>>
>> Could you test the latest version of cabal-debian and see if it resolves
>> your issue?  Thanks!
> this version returns the following (in a clean sid chroot)
>
> head -12 debian/control
> Source: haskell-time-locale-compat
> Maintainer: Debian Haskell Group 
> 
> Priority: extra
> Section: haskell
> Build-Depends: debhelper (>= 10),
>  haskell-devscripts-minimal | haskell-devscripts (>= 0.8),
>  cdbs,
>  ghc,
>  ghc-prof,
>  libghc-old-locale-dev,
>  libghc-old-locale-prof,
> Build-Depends-Indep: ghc-doc,
>
> is that good?
>
> package is available here [1]
>
> [1] 
> http://debomatic-amd64.debian.net/distribution#unstable/cabal-debian/4.35.6-1/lintian
>
> G.
>
>
>
> ___
> Pkg-haskell-maintainers mailing list
> pkg-haskell-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-haskell-maintainers

Bug#852387: O: ifuse -- FUSE module for iPhone and iPod Touch devices

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of ifuse, Julien Lavergne ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ifuse
Binary: ifuse, ifuse-dbg
Version: 1.1.2-0.1
Maintainer: Julien Lavergne 
Build-Depends: debhelper (>= 9~), dh-autoreconf, libfuse-dev (>= 2.7.0), 
libimobiledevice-dev (>= 1.1.0), libplist-dev
Architecture: any
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 bbc2b425328d3ec43244d5ea7bc9d785 1814 ifuse_1.1.2-0.1.dsc
 4152526b2ac3c505cb41797d997be14d 84645 ifuse_1.1.2.orig.tar.bz2
 fc5a7ee3d27ab105cc0191fb6f1879ae 5282 ifuse_1.1.2-0.1.debian.tar.gz
Checksums-Sha256:
 0442ae55b19cdfd2ffb82e496b6697c2712829743ab242ac9653e03481b0e75d 1814 
ifuse_1.1.2-0.1.dsc
 47835c8afb72588b3202fe0b206d7ea37a68663d9aa4eaf73f0a4bcb6215fc05 84645 
ifuse_1.1.2.orig.tar.bz2
 c0998d3e60692a54607f33bbcd1c58428c33cb2a82a27aa82b62056d79e5f167 5282 
ifuse_1.1.2-0.1.debian.tar.gz
Homepage: http://libimobiledevice.org
Package-List: 
 ifuse deb utils optional
 ifuse-dbg deb debug extra
Directory: pool/main/i/ifuse
Priority: source
Section: utils

Package: ifuse
Source: ifuse (1.1.2-0.1)
Version: 1.1.2-0.1+b4
Installed-Size: 44
Maintainer: Julien Lavergne 
Architecture: amd64
Depends: fuse, libc6 (>= 2.4), libfuse2 (>= 2.8), libimobiledevice6 (>= 1.1.0), 
libplist3 (>= 1.11)
Description-en: FUSE module for iPhone and iPod Touch devices
 iFuse is a FUSE filesystem driver which uses libiphone to connect to iPhone
 and iPod Touch devices without needing to "jailbreak" them. iFuse uses the
 native Apple AFC protocol over a normal USB cable in order to access the
 device's media files.
 .
 Although iFuse is now in a working state it is still under heavy
 development and should be considered experimental.
Description-md5: f98578e76fc102c53d3c118fa494c4f0
Homepage: http://libimobiledevice.org
Section: utils
Priority: optional
Filename: pool/main/i/ifuse/ifuse_1.1.2-0.1+b4_amd64.deb
Size: 14038
MD5sum: 2ef8d5e70b3ef8ff2417cdb4e8f616ba
SHA256: e54feb52bccdc9d24b72e413e60ded0d8a683bdda2657ccc1af53d20162c6dbf

Package: ifuse-dbg
Source: ifuse (1.1.2-0.1)
Version: 1.1.2-0.1+b4
Installed-Size: 40
Maintainer: Julien Lavergne 
Architecture: amd64
Depends: ifuse (= 1.1.2-0.1+b4)
Description-en: FUSE module for iPhone and iPod Touch devices - debug package
 iFuse is a FUSE filesystem driver which uses libiphone to connect to iPhone
 and iPod Touch devices without needing to "jailbreak" them. iFuse uses the
 native Apple AFC protocol over a normal USB cable in order to access the
 device's media files.
 .
 Although iFuse is now in a working state it is still under heavy
 development and should be considered experimental.
 .
 This package contains the debugging symbols.
Description-md5: 04fb7fb48082e06978e75e2691ba6613
Homepage: http://libimobiledevice.org
Build-Ids: 93006f918f947265409b88826befa907e2c17da3
Tag: role::debug-symbols
Section: debug
Priority: extra
Filename: pool/main/i/ifuse/ifuse-dbg_1.1.2-0.1+b4_amd64.deb
Size: 21820
MD5sum: 1ee2b5183f167f44655e1f2ccb1d0c0d
SHA256: 7a32c29efaf713535e4ef978967099699ef19e2666a79f86b7be7be01d0ebee1



signature.asc
Description: PGP signature

Bug#852388: O: ideviceinstaller -- Utility to manage installed applications on an iDevice

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of ideviceinstaller, Julien Lavergne 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ideviceinstaller
Binary: ideviceinstaller, ideviceinstaller-dbg
Version: 1.0.1-0.2
Maintainer: Julien Lavergne 
Build-Depends: debhelper (>= 7.0.50~), dh-autoreconf, libimobiledevice-dev (>= 
1.0.0), libplist-dev (>= 0.15), libzip-dev (>= 0.8)
Architecture: any
Standards-Version: 3.9.1.0
Format: 3.0 (quilt)
Files:
 62826e9a5baf5c815ac97af2a606fa55 1313 ideviceinstaller_1.0.1-0.2.dsc
 749b2062e86a00c0903ca8d5f0acabc6 259871 ideviceinstaller_1.0.1.orig.tar.bz2
 5e1c9f51f05a7358420b6c1d85ee6548 4073 ideviceinstaller_1.0.1-0.2.debian.tar.gz
Checksums-Sha1:
 b8666e606b6457b0440b48166a240b24875919e2 1313 ideviceinstaller_1.0.1-0.2.dsc
 7dd57f5d6d4466d8eca5d28fef3c22033b2af2da 259871 
ideviceinstaller_1.0.1.orig.tar.bz2
 bd34c24132a9686b6c0f7c9b5a64f19698e4fff9 4073 
ideviceinstaller_1.0.1-0.2.debian.tar.gz
Checksums-Sha256:
 2ed01f8bd6419b978233b582c9fa57b99d3fdb57b7d5c57cf0e1c482f1f0 1313 
ideviceinstaller_1.0.1-0.2.dsc
 e2e5dc41c08cce7cec9edaf4596322f424d5195c255d3c1b957b81b45529b4f5 259871 
ideviceinstaller_1.0.1.orig.tar.bz2
 b0042c71398afe69283094fc948de1f1befe91320c3ba8033baf3988d25ca62f 4073 
ideviceinstaller_1.0.1-0.2.debian.tar.gz
Homepage: http://libimobiledevice.org/
Package-List: 
 ideviceinstaller deb utils optional
 ideviceinstaller-dbg deb debug extra
Directory: pool/main/i/ideviceinstaller
Priority: source
Section: utils

Package: ideviceinstaller
Binary: ideviceinstaller, ideviceinstaller-dbg
Version: 1.0.1-0.3
Maintainer: Julien Lavergne 
Build-Depends: debhelper (>= 7.0.50~), dh-autoreconf, libimobiledevice-dev (>= 
1.0.0), libplist-dev (>= 0.15), libzip-dev (>= 0.8)
Architecture: any
Standards-Version: 3.9.1.0
Format: 3.0 (quilt)
Files:
 159d049e96350defa3e41b23d3281a85 1950 ideviceinstaller_1.0.1-0.3.dsc
 749b2062e86a00c0903ca8d5f0acabc6 259871 ideviceinstaller_1.0.1.orig.tar.bz2
 f098cbafa4e4b2002219f9811a6941f6 4664 ideviceinstaller_1.0.1-0.3.debian.tar.xz
Checksums-Sha256:
 b26c3368dc9875501b490691ed206a32cfea04dad103b33de4728aa6d4e17cd3 1950 
ideviceinstaller_1.0.1-0.3.dsc
 e2e5dc41c08cce7cec9edaf4596322f424d5195c255d3c1b957b81b45529b4f5 259871 
ideviceinstaller_1.0.1.orig.tar.bz2
 83ead4f0f60fbe45d7fc9dabf1ed6203395669a03cd537568e1ba26fdfcaaa52 4664 
ideviceinstaller_1.0.1-0.3.debian.tar.xz
Homepage: http://libimobiledevice.org/
Package-List: 
 ideviceinstaller deb utils optional arch=any
 ideviceinstaller-dbg deb debug extra arch=any
Directory: pool/main/i/ideviceinstaller
Priority: source
Section: utils

Package: ideviceinstaller
Source: ideviceinstaller (1.0.1-0.3)
Version: 1.0.1-0.3+b1
Installed-Size: 42
Maintainer: Julien Lavergne 
Architecture: amd64
Depends: libc6 (>= 2.14), libimobiledevice6 (>= 1.1.5), libplist3 (>= 1.11), 
libzip4 (>= 0.10), zlib1g (>= 1:1.1.4)
Description-en: Utility to manage installed applications on an iDevice
 ideviceinstaller is a tool to interact with the installation_proxy
 of an iDevice allowing to install, upgrade, uninstall, archive, restore,
 and enumerate installed or archived applications.
 .
 It makes use of the libimobiledevice library that allows communication
 with the devices.
Description-md5: 90af38530619f287fcb09421b4b1a146
Homepage: http://libimobiledevice.org/
Tag: role::program
Section: utils
Priority: optional
Filename: pool/main/i/ideviceinstaller/ideviceinstaller_1.0.1-0.3+b1_amd64.deb
Size: 13278
MD5sum: 8141453fb78b96abf83f1b70c3974a4f
SHA256: ce1817251a89ea38cf925d78ad4548880a1e0228f60d44a8546fdd414666fd7d

Package: ideviceinstaller
Source: ideviceinstaller (1.0.1-0.2)
Version: 1.0.1-0.2+b1
Installed-Size: 31
Maintainer: Julien Lavergne 
Architecture: amd64
Depends: libc6 (>= 2.14), libimobiledevice4 (>= 1.1.5), libplist2 (>= 1.11), 
libzip2 (>= 0.10), zlib1g (>= 1:1.1.4)
Description-en: Utility to manage installed applications on an iDevice
 ideviceinstaller is a tool to interact with the installation_proxy
 of an iDevice allowing to install, upgrade, uninstall, archive, restore,
 and enumerate installed or archived applications.
 .
 It makes use of the libimobiledevice library that allows communication
 with the devices.
Description-md5: 90af38530619f287fcb09421b4b1a146
Homepage: http://libimobiledevice.org/
Tag: role::program
Section: utils
Priority: optional
Filename: pool/main/i/ideviceinstaller/ideviceinstaller_1.0.1-0.2+b1_amd64.deb
Size: 13344
MD5sum: 

Bug#851946: Depending on libssl1.0-dev breaks PHP builds

[Niels Thykier]

Sebastian Andrzej Siewior:
> On 2017-01-22 07:37:00 [+], Niels Thykier wrote:
>> [...]
>>> I would suggest to drop the the libssl1.0-dev dep in libsnmp-dev and add
>>> a guard cert_util.h to ensure openssl's version is less than 1.1.0 in
>>> case someone tries to use this on its own.
>>
>> The header file is used internally by snmp, so this change implies
>> upgrading snmp to ssl1.1.  All in all, we need to:
>>
>>  * Apply the patch in #828449
> Haven't look at it yet but if the patch was already blessed then maybe I
> don't have to :)
> 

The guard, you proposed, is using 1.0.2, so this patch will be
unnecessary (guess I misunderstood your original intention).  But the
end result should be the same. :)

>>  * Remove "libssl1.0-dev | libssl-dev (<< 1.1)" from Depends and add a
>>"libssl-dev" to Suggests in the the "-dev" package?
>>
>>  * Add an "#if"-guard rejecting ssl1.0 in the cert_util.h file.
>>(Can you provide me with an example/patch for the guard?)
> 
> I attached a debdiff I did for testing against 1.0.2. It contains the
> guard and the removal of -lcrypto from part of its exported cflags.
> [...]
> 

Thanks for the extensive testing! :)

> Waiting for further instructions.
> 
>[...]

I will do an NMU tonight with these changes and the -pie ones from the
other bug.

Thanks,
~Niels

Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

[Jean-Marc]

Tue, 24 Jan 2017 04:21:45 +0100
Andreas Beckmann  écrivait :

hi Andreas,

> I expect that the upgrade behavior improves once mariadb-10.0 is gone
> from testing (and mysql-5.6 needs to go away as well).
> From what I observed apt does not easily switch from package A to
> package B if A still has an installation candidate. Once that is gone, A
> is more likely a candidate for removal.

Any idea when mariadb-10.0 will be gone from testing ?


> 
> 
> Andreas

Jean-Marc 


pgp1pYhncEMI1.pgp
Description: PGP signature

Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

[Gijs Hillenius]

Package: dirmngr
Version: 2.1.17-6
Followup-For: Bug #849845

Dear Maintainer,

For the record - this bug shows upstream is already aware of possible problems 
with IPv6 - on this IPv6 host, dirmngr is unable to find the default 
hkps.pool.sks-keyservers.net

pg2   --search-keys  somekeyhere
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available



with the debug log showing:


DBG: chan_6 <- KS_SEARCH -- somekeyhere_again
can't connect to 'hkps.pool.sks-keyservers.net': no IP address for host
error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[29062.6] marking host 'hkps.pool.sks-keyservers.net' as dead
dirmngr[29062.6] host 'hkps.pool.sks-keyservers.net' marked as dead
dirmngr[29062.6] command 'KS_SEARCH' failed: No keyserver available


gpg-connect-agent --dirmngr 'keyserver --alive hkps.pool.sks-keyservers.net' 
/bye
S # marking 'hkps.pool.sks-keyservers.net' as alive
OK


with the debug log showing

DBG: chan_6 -> OK Dirmngr 2.1.17 at your service
dirmngr[29062.6] connection from process 15130 (1000:1000)
dirmngr[29062.6] DBG: chan_6 <- keyserver --alive hkps.pool.sks-keyservers.net
dirmngr[29062.6] DBG: chan_6 -> S # marking 'hkps.pool.sks-keyservers.net' as 
alive
dirmngr[29062.6] DBG: chan_6 -> OK

but then, again:

gpg2   --search-keys  samesomekeyhere 
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available




-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.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 dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-2
ii  libc6  2.24-9
ii  libgcrypt201.7.5-3
ii  libgnutls303.5.8-1
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libldap-2.4-2  2.4.44+dfsg-3
ii  libnpth0   1.3-1
ii  lsb-base   9.20161125

Versions of packages dirmngr recommends:
ii  gnupg  2.1.17-6

Versions of packages dirmngr suggests:
ii  dbus-user-session  1.10.14-1
ii  pinentry-gnome31.0.0-1
pn  tor

-- no debconf information

Bug#852386: O: nautilus-image-converter -- nautilus extension to mass resize or rotate images

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of nautilus-image-converter, Julien Lavergne 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: nautilus-image-converter
Binary: nautilus-image-converter
Version: 0.3.1~git20110416-1
Maintainer: Julien Lavergne 
Build-Depends: debhelper (>= 7.0.50~), autotools-dev, intltool, 
libxml-parser-perl, pkg-config, libnautilus-extension-dev (>= 3.0.0), 
libgtk-3-dev (>= 3.0.0), libglib2.0-dev (>= 2.28.0)
Architecture: any
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 c39c47d1643e94c1a88e2bf8679f1c3f 2300 
nautilus-image-converter_0.3.1~git20110416-1.dsc
 428ac71743431992a89996838d88ee93 352988 
nautilus-image-converter_0.3.1~git20110416.orig.tar.gz
 d0abff22a41c001ae6ff565a02ac4623 8220 
nautilus-image-converter_0.3.1~git20110416-1.debian.tar.gz
Vcs-Browser: 
http://svn.debian.org/wsvn/collab-maint/deb-maint/nautilus-image-converter/trunk/
Vcs-Svn: 
svn://svn.debian.org/svn/collab-maint/deb-maint/nautilus-image-converter/trunk/
Checksums-Sha1:
 c0e73b00ce2c49676e8535fee793e64a0bfc9d85 2300 
nautilus-image-converter_0.3.1~git20110416-1.dsc
 41920f030b3cd30aea3a999d07c12c9342427bcf 352988 
nautilus-image-converter_0.3.1~git20110416.orig.tar.gz
 00d0e1c418a431713b34866ecce0491b141297ca 8220 
nautilus-image-converter_0.3.1~git20110416-1.debian.tar.gz
Checksums-Sha256:
 cdbff10bb1cc313d062683e40821a02cd0573b8a6e3262d2163a67a1338a6cac 2300 
nautilus-image-converter_0.3.1~git20110416-1.dsc
 aab6f6fa7ced32731755dea1a6c33236cc5d4836902bb94516fe59f815d7a245 352988 
nautilus-image-converter_0.3.1~git20110416.orig.tar.gz
 e3f80d9a5d0889abeccb59a85f371f8761ae25eec4e638c7f63ba6f1bd850d20 8220 
nautilus-image-converter_0.3.1~git20110416-1.debian.tar.gz
Homepage: http://git.gnome.org/browse/nautilus-image-converter/
Package-List: 
 nautilus-image-converter deb gnome optional
Directory: pool/main/n/nautilus-image-converter
Priority: source
Section: gnome

Package: nautilus-image-converter
Binary: nautilus-image-converter
Version: 0.3.1~git20110416-1
Maintainer: Julien Lavergne 
Build-Depends: debhelper (>= 7.0.50~), autotools-dev, intltool, 
libxml-parser-perl, pkg-config, libnautilus-extension-dev (>= 3.0.0), 
libgtk-3-dev (>= 3.0.0), libglib2.0-dev (>= 2.28.0)
Architecture: any
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 c39c47d1643e94c1a88e2bf8679f1c3f 2300 
nautilus-image-converter_0.3.1~git20110416-1.dsc
 428ac71743431992a89996838d88ee93 352988 
nautilus-image-converter_0.3.1~git20110416.orig.tar.gz
 d0abff22a41c001ae6ff565a02ac4623 8220 
nautilus-image-converter_0.3.1~git20110416-1.debian.tar.gz
Vcs-Browser: 
http://svn.debian.org/wsvn/collab-maint/deb-maint/nautilus-image-converter/trunk/
Vcs-Svn: 
svn://svn.debian.org/svn/collab-maint/deb-maint/nautilus-image-converter/trunk/
Checksums-Sha256:
 cdbff10bb1cc313d062683e40821a02cd0573b8a6e3262d2163a67a1338a6cac 2300 
nautilus-image-converter_0.3.1~git20110416-1.dsc
 aab6f6fa7ced32731755dea1a6c33236cc5d4836902bb94516fe59f815d7a245 352988 
nautilus-image-converter_0.3.1~git20110416.orig.tar.gz
 e3f80d9a5d0889abeccb59a85f371f8761ae25eec4e638c7f63ba6f1bd850d20 8220 
nautilus-image-converter_0.3.1~git20110416-1.debian.tar.gz
Homepage: http://git.gnome.org/browse/nautilus-image-converter/
Package-List: 
 nautilus-image-converter deb gnome optional
Directory: pool/main/n/nautilus-image-converter
Priority: source
Section: gnome

Package: nautilus-image-converter
Version: 0.3.1~git20110416-1
Installed-Size: 116
Maintainer: Julien Lavergne 
Architecture: amd64
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo-gobject2 (>= 
1.10.0), libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.8.0), libfreetype6 (>= 
2.2.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.28.0), libgtk-3-0 
(>= 3.0.0), libnautilus-extension1a (>= 2.91), libpango1.0-0 (>= 1.14.0), 
imagemagick
Recommends: nautilus (>= 3.0.0)
Description-en: nautilus extension to mass resize or rotate images
 This package adds a "Resize Images..." menu item to
 the context menu of all images. This opens a dialog
 where you set the desired image size and file name.
 A click on "Resize" finally resizes the image(s)
 using ImageMagick's convert tool.
Description-md5: ce93008694c0e402fc4a48eb79d56cf9
Homepage: http://git.gnome.org/browse/nautilus-image-converter/
Tag: implemented-in::c++, interface::x11, role::plugin, role::program,
 scope::utility, suite::gnome, uitoolkit::gtk, use::compressing,
 use::converting, works-with::image, works-with::image:raster,
 x11::application
Section: 

Bug#851946: Depending on libssl1.0-dev breaks PHP builds

[Paul Gevers]

Hi,

On 01/23/17 22:39, Sebastian Andrzej Siewior wrote:

> failed [0] (/attempted):
> - cacti-spine_0.8.8h-2_amd64-2017-01-22T22:38:06Z
>   Failed due missing -lssl. Maybether since #834057. The last built
>   packages on buildd

Let me fix that shortly. Don't hesitate to still file a bug ;)

Paul



signature.asc
Description: OpenPGP digital signature

Bug#852385: libplist: CVE-2017-5545

[Salvatore Bonaccorso]

Source: libplist
Version: 1.11-3
Severity: important
Tags: upstream patch security fixed-upstream
Forwarded: https://github.com/libimobiledevice/libplist/issues/87

Hi,

the following vulnerability was published for libplist.

CVE-2017-5545[0]:
| The main function in plistutil.c in libimobiledevice libplist through
| 1.12 allows attackers to obtain sensitive information from process
| memory or cause a denial of service (buffer over-read) via Apple
| Property List data that is too short.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-5545
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5545
[1] https://github.com/libimobiledevice/libplist/issues/87

Regards,
Salvatore

Bug#851778: change CONFIG_FB from 'm' to 'y' on arm64

[Ben Hutchings]

On Wed, 2017-01-18 at 17:10 +, Leif Lindholm wrote:
> Package: linux-image-arm64
> Version: 4.9+78
> Severity: wishlist
> 
> Linux commit 9822504c1, included in v4.7, introduced EFI framebuffer
> support on arm/arm64.
> 
> The Debian arm64 kernel config currently explicitly sets CONFIG_FB to
> 'm', overriding the defconfig 'y'.

You seem to be working on the assumption that the Debian config is
related to upstream defconfig files.  This is not the case - the
upstream defaults we start from are those in the Kconfig files.

Currently we don't explicitly set CONFIG_FB for arm64, and the only
reason it's enabled as a module is that the DRM drivers (which are
built as modules) select it.  We *do* explicitly set CONFIG_FB=y on
almost all other architectures and flavours, one by one.

I'm going to simplify this by setting CONFIG_FB=y at the top level and
overriding in a few cases, not including arm64.

> Since CONFIG_FB_EFI is "depends on
> (FB = y)", this means we don't get efifb support on arm64. So could we
> flip it to 'y', please?
>
> This would also be a nice thing to do on armhf, but affect fewer
> platforms.

So what you're actually requesting is to enable CONFIG_FB_EFI on arm64
and armhf.  I'll do that too.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#852384: lvm2: unable to reset settings set with --cachesettings, making it impossible to switch cachepolicy

[Marc Lehmann]

Package: lvm2
Version: 2.02.168-1
Severity: normal

Dear Maintainer,

the --cachesettings swotch (to lvchange) apparently accepts
space-separated key-value pairs (this is undocumented, but not the issue
here). For example:

  # lvchange --cachesettings 'read_promote_adjustment=8' vg_cerebro/bp

However, different cache policies accept different key-value pairs. For
example, smq does not support any key-value pairs, therefore switching the
cachepolicy to it fails:

  # lvchange --cachepolicy smq vg_cerebro/bp
  device-mapper: reload ioctl on (252:1) failed: Invalid argument

Unfortunately, --cachesettings, while enbaling changes to cachesettings,
does not allow clearing the key-value pairs:

  # lvchange --cachesettings '' vg_cerebro/bp
  Command failed with status code 5.
  # lvchange --cachepolicy smq --cachesettings '' vg_cerebro/bp
  Command failed with status code 5.

The fix, IMHO, would be to allow one to clear cachesettings.

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.41-040441-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.90-2.2+deb8u1
ii  dmsetup   2:1.02.137-1
ii  init-system-helpers   1.22
ii  libblkid1 2.25.2-6
ii  libc6 2.24-8
ii  libdevmapper-event1.02.1  2:1.02.90-2.2+deb8u1
ii  libdevmapper1.02.12:1.02.137-1
ii  liblvm2app2.2 2.02.168-1
ii  libreadline5  5.2+dfsg-2
ii  libudev1  230-7
ii  lsb-base  4.1+Debian13+nmu1

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
ii  thin-provisioning-tools  0.3.2-1

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]

-- debconf information excluded

Bug#846792: linux-image-4.8.0-1-amd64: ACPI : EC: EC started delay on boot

[Ben Hutchings]

Control: tag -1 - fixed-upstream
Control: tag -1 patch

Although the bugzilla.k.o report has been closed, this is not yet fixed
upstream.  However there is a tested patch which was sent to the linux-
acpi list: https://www.spinics.net/lists/linux-acpi/msg71496.html

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Andreas Beckmann]

On 2017-01-22 22:46, Michael Stapelberg wrote:
> Thanks for the good tips! Answers inline:

Acked-By: Andreas Beckmann 

> If the patch works for you, could you merge it and apply it on
> piuparts.d.o please? Thank you!

Holger, we should merge this for 0.76 (not 0.75) and activate it
thereafter (starting with sid, and if the output works as desired, for
other non-upgrade distros, too). I'll send patches for the config then.

We shouldn't close this bug but retitle it for the more general solution
initially discussed.


Andreas

Bug#847100: [#XIF-791-60064]: Bug#847100 closed by Donald Norwood <don...@debian.org> (Bug#847100: Acknowledgement (mirror listing update for debian.mirror.globo.tech))

[GloboTech]

ow...@bugs.debian.org,

Thank you for contacting us. This is an automated response confirming the 
receipt of your ticket. One of our agents will get back to you as soon as 
possible. For your records, the details of the ticket are listed below. When 
replying, please make sure that the ticket ID is kept in the subject line to 
ensure that your replies are tracked appropriately.

Ticket ID: XIF-791-60064
Subject: Bug#847100 closed by Donald Norwood  
(Bug#847100: Acknowledgement (mirror listing update for 
debian.mirror.globo.tech))
Department: Support
Type: Issue
Status: Open
Priority: Medium

You can check the status of or reply to this ticket online at: 
http://support.globo.tech/index.php?/Tickets/Ticket/View/XIF-791-60064

Kind regards,

GloboTech Communications


--
Support Center: http://support.globo.tech/index.php?

Bug#851916: linux-image-4.9.0-1-amd64: RT5677_SPI driver not built

[Ben Hutchings]

Control: tag -1 pending

On Thu, 2017-01-19 at 17:19 -0600, Kinsey Moore wrote:
> Package: src:linux
> Version: 4.9.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
>    Installing and running the in-repo 4.9.0-1-amd64 kernel instead of
>    the kernel hosted on raphael's linux-samus github repo
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  N/A, module is not built
>    * What was the outcome of this action?
>    * What outcome did you expect instead?

I assume you mean SND_SOC_RT5677_SPI.  This config symbol can't be
directly enabled as it's only useful in conjunction with another
driver.

So I think you actually want SND_SOC_INTEL_BDW_RT5677_MACH enabled,
which is what I've done.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#852383: icedove: Telemetry running though toolkit.telemetry.enabled=false

[Heinrich Schuchardt]

Package: icedove
Version: 1:45.6.0-2
Severity: normal

Dear Maintainer,

In my icedove profile I have
toolkit.telemetry.enabled = false

But in the error log I find:

?   Toolkit.Telemetry   WARN
TelemetryStorage::_enforcePendingPingsQuota - Unable to find the size of ping 
----

Best regards

Heinrich Schuchardt

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages icedove depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgdk-pixbuf2.0-02.36.3-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.16.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.1-5
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.4-2
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-1
ii  hunspell-de-ch [hunspell-dictionary]  20161207-1
ii  hunspell-de-de [hunspell-dictionary]  20161207-1
ii  hunspell-en-us [hunspell-dictionary]  20070829-7
ii  iceowl-extension  1:45.6.0-2

Versions of packages icedove suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15-1

-- no debconf information

Bug#847131: patch merged

[Bdale Garbee]

tags 847131 +pending
thanks

Patch merged into my git repo, will be part of the next upload.

Bdale

Bug#852382: packages.debian.org: Add javascript and rust sections

[Josh Triplett]

Package: www.debian.org
Tags: patch
User: www.debian@packages.debian.org
Usertags: packages

The attached patch adds the new archive sections "javascript" and "rust"
to packages.debian.org.

- Josh Triplett
>From ff24f73923e0bd733b400363fdffa920ce226ef8 Mon Sep 17 00:00:00 2001
From: Josh Triplett 
Date: Mon, 23 Jan 2017 19:28:14 -0800
Subject: [PATCH] Packages::Sections: Add javascript and rust sections

---
 lib/Packages/Sections.pm | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Packages/Sections.pm b/lib/Packages/Sections.pm
index b618fae..f028073 100644
--- a/lib/Packages/Sections.pm
+++ b/lib/Packages/Sections.pm
@@ -57,6 +57,8 @@ our %sections_descs = (
 	 N_("Machine readable introspection data for use by development tools.") ],
 		  java	=> [ N_("Java"),
  N_("Everything about Java.") ],
+		  javascript	=> [ N_("JavaScript"),
+	 N_("JavaScript programming language, libraries, and development tools.") ],
 		  kde	=> [ N_("KDE"),
  N_("The K Desktop Environment, a powerful, easy to use set of integrated applications.") ],
 		  kernel	=> [ N_("Kernels"),
@@ -95,6 +97,8 @@ our %sections_descs = (
  N_("Everything about Python, an interpreted, interactive object oriented language.") ],
 		  ruby	=> [ N_("Ruby"),
  N_("Everything about Ruby, an interpreted object oriented language.") ],
+		  rust	=> [ N_("Rust"),
+ N_("Rust programming language, library crates, and development tools") ],
 		  science	=> [ N_("Science"),
  N_("Basic tools for scientific work") ],
 		  shells	=> [ N_("Shells"),
-- 
2.11.0

Bug#851241: www.debian.org: packages.debian.org update hangs every now and then

[Cyril Brulebois]

Control: tag -1 patch pending

Hi,

Rhonda D'Vine  (2017-01-13):
>  I got notified today that the packages website didn't update, and that
> this seems to be an issue appearing more regularly.  I didn't had much
> time unfortunately to investigate it further, but this is what appeared
> to me:
> 
> #v+
> pkg_user 21873  0.0  0.0 103296  5192 ?SJän07   0:07 sshd: 
> pkg_user@notty
> pkg_user 21887  0.0  0.0   4336   764 ?Ss   Jän07   0:00  \_ dash -c 
> /srv/packages.debian.org/bin/push_update
> pkg_user 21898  0.0  0.0  13348  1656 ?SJän07   0:00  \_ 
> /bin/bash /srv/packages.debian.org/bin/push_update
> pkg_user 21958  0.0  0.0   4224  1476 ?SJän07   0:00  \_ 
> run-parts --verbose /srv/packages.debian.org/cron.d
> pkg_user 22309  0.0  0.0  13344  1640 ?SJän07   0:00  
> \_ /bin/bash /srv/packages.debian.org/cron.d/200proce
> pkg_user 25601 99.0  0.7 154500 122188 ?   RJän07 7804:48 
>  \_ /usr/bin/perl -w ./bin/parse-contents
> pkg_user 20378  0.0  0.0   4336   712 ?SJän07   0:00  
> \_ sh -c sort  -T /srv/packages.debian.org/tm
> pkg_user 20379  0.0  0.0   9080  3864 ?SJän07   3:24  
> \_ sort -T /srv/packages.debian.org/tmp -
> #v-
> 
>  The running time of parse-contents was increasing, but the sort didn't
> do anything. An strace showed that it was hanging:
> 
> #v+
> $ strace -p 20379
> Process 20379 attached
> write(1, "-data:kfreebsd-i386\nyp.margorp_e"..., 4096^CProcess 20379 detached
>  
> #v-
> 
>  Unfortunately I didn't had the time to investigate further, but if it
> hangs again and maybe at the same place I guess the tmp file(s) would be
> useful to investigate further.

Following a ping on #debian-devel then #debian-www I've checked what was
happening (running still Jan 15): sort was stuck on a write, sh -c stuck
on wait, and perl wasn't really doing much (no syscalls, but eating CPU,
apparently somewhere in libdb according to gdb, but I'm not sure this is
accurate / relevant).

Looking at the sizes of sid files, the aggregation is between 15-16 GB,
which might explain why piping sort's output to a perl file handle might
be suboptimal / sometimes getting stuck.

I've experimented a bit with the idea of creating a temporary file
instead, and it seems to do the job / work around this issue properly:

  
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?id=1b065791a50c7a0e606f2577bcae02b7c5aa190b

I've taken the opportunity to fix progress reporting, since it can be
off by a lot with the big fat files we have in today's distributions,
through a sub called from that specific part of parse-contents, but also
from earlier in the code, cheating a bit with gzip -l's help:

  
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?id=a45ab468c3d18ee671f1f65ef0cc64ebb8e9d408
  
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?id=657f137df07726c41a399652618928cdc2fe8b97

Following Paul's advice, I've pushed that to master, merged into
debian-master, and deployed it on picconi since I'm still in the right
pkg group (which dates me quite a lot but can be useful at times it
seems). I'll keep an eye on cron.log, since I've killed a number of
occurrences while I was running final tests there.

Tagging with patch & pending until we get a confirmation stuff looks
better…
 

KiBi.


signature.asc
Description: Digital signature

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Courtney Bane]

I just ran in to this problem affecting my ekeyd installation (just
reported as #852380). Unix domain sockets are available, but the API
changed in the new version.

Instead of calling socket.unix() to create a socket, you now need to
call socket.unix.tcp(). Note that there is another API change coming
that changes this to socket.unix.stream(). (This change is not yet in
Debian. It's upstream commit 3a33c37b;
https://github.com/diegonehab/luasocket/commit/3a33c37b9ce852d0b3531e82c6ffdb47bb937f0a.)

Bug#852381: IP version issue with stretch clients and jessie servers. Possiblly should be in release notes.

[peter green]

Package: openvpn

My server is running openvpn on jessie and I recently added a new client 
running stretch, using a similar configuration to my existing Jessie clients.

The server has both A and  record in DNS (put there for other services) but 
jessie's openvpn defaults to listening on only v4. The stretch client first 
tries to connect on v6, then times out and connects successfully on v4. The 
timeout is long enough that I initially thought the client wasn't working at 
all.

Possible solutions are to either specify udp4 explicitly on the client or 
upgrade the server to a version that supports dual stack (stretch-backports 
appears to have 2.4) .

Maybe this should be in the release notes so people consider it when upgrading. 
If you agree please reassign this bug to release notes.

Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

[Andreas Beckmann]

Control: block -1 with 851980

On Mon, 23 Jan 2017 22:50:00 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
 wrote:
> 2017-01-23 19:09 GMT+02:00 Jean-Marc :
> > I'll try to simulate it by installing dolibarr on a Debian Jessie and 
> > upgrading it to testing.
> >
> > I'll keep you posted.
> 
> Thanks for your help! I cannot possibly test all the upgrade scenarios
> people might have out there, so it is very good if you can get to the
> bottom of this.

I expect that the upgrade behavior improves once mariadb-10.0 is gone
from testing (and mysql-5.6 needs to go away as well).
>From what I observed apt does not easily switch from package A to
package B if A still has an installation candidate. Once that is gone, A
is more likely a candidate for removal.


Andreas

Bug#851993: Acknowledgement (which: doesn't respect $PATH when it contains '~' character)

[Arthur D.]

OK, I see. Thanks for you response.

I just migrated from Gentoo. It uses this version of 'which':
https://carlowood.github.io/which/
LinuxFromScratch uses this one (probably the same):
http://ftp.gnu.org/gnu/which/which-2.21.tar.gz

I didn't found this package in debian repository, that's why
I decided to make bugreport.

Thanks again!

Bug#852380: ekeyd: Does not start after luasocket upgrade

[Courtney Bane]

Package: ekeyd
Version: 1.1.5-6.1
Severity: grave
Tags: patch
Justification: renders package unusable

After the recent upgrade of the lua-socket package to version
3.0~rc1+git+ac3201d-2, ekeyd no longer starts if Unix domain sockets are
used (for either the control or EGD socket). Instead, it exits with this
error message:

Unable to run configuration file:
control.lua:755: control.lua:526: attempt to index global 'socket' (a nil value)

This is due to an incompatible change in the lua-socket API for Unix domain 
sockets.

I have attached a patch which allows ekeyd to work with both the old and
new versions of lua-socket, as well as an upcoming change that has not
yet been packaged in Debian. (Git commit 3a33c37b;
https://github.com/diegonehab/luasocket/commit/3a33c37b9ce852d0b3531e82c6ffdb47bb937f0a.)

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 ekeyd depends on:
ii  libc62.24-8
ii  liblua5.1-0  5.1.5-8.1+b2
ii  lua-socket   3.0~rc1+git+ac3201d-2
ii  lua5.1   5.1.5-8.1+b2

Versions of packages ekeyd recommends:
ii  udev  232-8

Versions of packages ekeyd suggests:
pn  munin-node  

-- Configuration Files:
/etc/entropykey/ekeyd.conf changed [not included]
/etc/entropykey/keyring [Errno 13] Permission denied: '/etc/entropykey/keyring'

-- no debconf information
From: Courtney Bane 
Date: Mon, 23 Jan 2017 20:30:59 -0600
Subject: Fix compatibility problems with Unix domain sockets in newer
 versions of luasocket.

---
 host/control.lua | 14 --
 host/ekeydctl.in |  7 ---
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/host/control.lua b/host/control.lua
index 7b9b1b8..22d700f 100644
--- a/host/control.lua
+++ b/host/control.lua
@@ -38,11 +38,11 @@ local PROTOCOL_VERSION = "1"
 local dos_callcount = 0
 
 -- Libraries we need
-require "socket"
+socket = require "socket"
 
 local have_unix_domain_sockets = false
 function tryload_unix()
-   require "socket.unix"
+   socket.unix = require "socket.unix"
have_unix_domain_sockets = true
 end
 
@@ -521,14 +521,15 @@ end
 
 if have_unix_domain_sockets then
function UnixControlSocket(sockname)
+  local sock = socket.unix.stream or socket.unix.tcp or socket.unix
   -- Add a UDS control socket to the set of control sockets available
   -- First, try and connect, so we can abort if it's present.
-  if socket.unix():connect(sockname) then
+  if sock():connect(sockname) then
 	 error("Control socket " .. sockname .. " already present. Is ekeyd already running?")
   end
   -- Okay, clean up (ignoring errors) and create a fresh socket
   unlink(sockname)
-  local u = socket.unix()
+  local u = sock()
   assert(u:bind(sockname))
   assert(u:listen())
   addctlsocket(u, "U:" .. sockname)
@@ -554,12 +555,13 @@ end _ "TCPControlSocket"
 if have_unix_domain_sockets then
function EGDUnixSocket(sockname, modestr, user, group)
   SetFoldedOutput()
-  if socket.unix():connect(sockname) then
+  local sock = socket.unix.stream or socket.unix.tcp or socket.unix
+  if sock():connect(sockname) then
 	 error("EGD socket " .. sockname .. " already present. Is ekeyd/EGD already running?")
   end
   -- Add a UDS control socket to the set of control sockets available
   unlink(sockname)
-  local u = socket.unix()
+  local u = sock()
   assert(u:bind(sockname))
   assert(u:listen())
   addctlsocket(u, "U:" .. sockname, false, egd_ctlread)
diff --git a/host/ekeydctl.in b/host/ekeydctl.in
index 9292ac6..802cf38 100755
--- a/host/ekeydctl.in
+++ b/host/ekeydctl.in
@@ -1,11 +1,11 @@
 #!/usr/bin/env lua@LUA_V@
 -- -*- Lua -*-
 
-require "socket"
+local socket = require "socket"
 
 -- Try to load the UNIX domain sockets support
 pcall(function()
-	 require "socket.unix"
+	 socket.unix = require "socket.unix"
   end)
 
 
@@ -98,7 +98,8 @@ end
 
 function connect_to_daemon()
if __unixcontrolpath then
-  __socket = socket.unix()
+  local sock = socket.unix.stream or socket.unix.tcp or socket.unix
+  __socket = sock()
   local result, msg = __socket:connect(__unixcontrolpath)
   if not result then
 	 error("Unable to connect to ekeyd at " .. __unixcontrolpath .. " (" .. msg .. ") Is ekeyd running?")

Bug#851462: [pkg-gnupg-maint] Bug#851462: gpg-agent: a gpg-agent is already running - not starting a new one

[Daniel Kahn Gillmor]

On Wed 2017-01-18 05:13:19 -0500, Dominik George wrote:
> Well, when I reported this bug, I wasn't aware that gpg-agent is now
> handled by systemd.
>
> In fact, it wasn't me who configured that, but it was your package.
>
> One day I could use gpg-agent for SSH and I could kill and start it, the
> next day it behaved oddly for no obvious reason.
>
> I might have missed the relevant NEWS, but even after reading up on it,
> I still find the behaviour a bit odd.
>
> But it probably isn't a bug.

Ok, closing this bug report.  in the next upload to unstable (hopefully
today) i'll make sure that the NEWS in the gnupg-agent package explains
this change.

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#851440: [pkg-gnupg-maint] Bug#851440: sign_and_send_pubkey: signing failed: agent refused operation

[Daniel Kahn Gillmor]

Version: 2.1.17-6

On Thu 2017-01-19 13:36:20 -0500, Dominik George wrote:
>> > Do you have the dbus-user-session package installed?
>> 
>> No, I have dbus-x11.
>
> Installing dbus-user-session actually fixes it.
>
> I leave it up to you to decide whether this is a bug or using the ssh
> feature is not a standard use of the package.
>
> Maybe you shiould at least Recommend dbus-user-session.

I've put dbus-user-session into the Suggests: for gnupg-agent, and
included some more extensive documentation in
/usr/share/doc/gnupg-agent/README.Debian as well.  So i think we can
close https://bugs.debian.org/851440

Thanks for the feedback, Dominik!

   --dkg


signature.asc
Description: PGP signature

Bug#852019: [pkg-gnupg-maint] Bug#852019: gpgv: unknown type of key resource 'trustedkeys.kbx'

[Daniel Kahn Gillmor]

On Fri 2017-01-20 13:36:57 -0500, Antoine Beaupre wrote:

> For some reason, gpgv fails to verify a file that verifies properly
> with gpg -v:
>
> $ dget 
> https://mentors.debian.net/debian/pool/main/d/dnsdiag/dnsdiag_1.4.0-1.dsc
> dget: retrieving 
> https://mentors.debian.net/debian/pool/main/d/dnsdiag/dnsdiag_1.4.0-1.dsc
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100  1489  100  14890 0   2534  0 --:--:-- --:--:-- --:--:--  2532
> dget: using existing dnsdiag_1.4.0.orig.tar.gz
> dget: using existing dnsdiag_1.4.0-1.debian.tar.xz
> dnsdiag_1.4.0-1.dsc:
>   Good signature found
>validating dnsdiag_1.4.0.orig.tar.gz
>validating dnsdiag_1.4.0-1.debian.tar.xz
> All files validated successfully.
> gpgv: Signature made Sun Jan 15 08:40:29 2017 EST
> gpgv:using RSA key A3200222CEE5D1A5
> gpgv: Can't check signature: No public key
> dpkg-source: warning: failed to verify signature on ./dnsdiag_1.4.0-1.dsc
> dpkg-source: info: extracting dnsdiag in dnsdiag-1.4.0
> dpkg-source: error: unpack target exists: dnsdiag-1.4.0

This is reasonable.  dget doesn't know about this particular key, so it
can't check the signature.

dget relies on dscverify to verify the file, and dscverify(1) says:

   dscverify  checks that the GPG signatures on the given .changes or .dsc
   files are good signatures made by keys in the current Debian  keyrings,
   found  in  the  debian-keyring and debian-maintainers packages.  (Addi‐
   tional keyrings can be specified using the --keyring option any  number
   of  times.)  It then checks that the other files listed in the .changes
   or .dsc files have the correct sizes and checksums (MD5 plus  SHA1  and
   SHA256  if  the latter are present).  The exit status is 0 if there are
   no problems and non-zero otherwise.

The key in question is not in any of the listed default keyrings, so if
dget verified the .dsc as "ok" it would be a pretty severe bug in dget.

> I can reproduce this with gpgv directly:
>
> $ gpgv dnsdiag_1.4.0-1.dsc   
> gpgv: unknown type of key resource 'trustedkeys.kbx'
> gpgv: keyblock resource '/home/anarcat/.gnupg/trustedkeys.kbx': General error
> gpgv: Signature made Sun Jan 15 08:40:29 2017 EST
> gpgv:using RSA key A3200222CEE5D1A5
> gpgv: Can't check signature: No public key
>
> It seems there's a problem with some kbx file. Oddly enough, gpg2
> doesn't have that problem:

I suspect that the problem with the listed file is that it doesn't
exist.  i don't have that file either, and i don't plan to -- that file
is treated by gpgv as a curated keyring; if you put something in it,
gpgv will decide that that key can be relied on to make signatures in
general.

gpgv doesn't verify against any old arbitrary stuff in your keyring.
it's designed to be something that can be used correctly and
rigorously -- it needs to know exactly which keys are acceptable for
making a signature, so it needs to be told where those keys are.

AFAICT, the verification process all works fine if i know what i'm
checking against:

gpg --export 0D35E41F08444E72C1CCC3FF95146A1CBA141817 > mentee.key
dscverify --no-default-keyring --keyring $(pwd)/mentee.key *.dsc

This also works with "gpgv --keyring $(pwd)/mentee.key *.dsc"

Please note that you have to supply the full path to the keyring because
gpgv assumes that any pathless filename lives in ~/.gnupg/ -- i think
that kind of deviation from convention is bad and unhelpful, but it's
been that way for too long to fix it now.

If anything of the above doesn't work for you, please re-open this bug
report to explain.


> That's bad! It means I need to use the `-u` flag to dget, it breaks
> the trust path to the developr.
>
> I tried verifying the key with the gnupg1 package, which works, but
> that doesn't ship with a gpgv binary anymore, so I can't use that gpgv
> either.

If you want the gpgv1 binary, please install the gpgv1 package :)  It
will have the same behavior

> I wonder if this should be marked as 'grave' because it fails to
> verify valid signatures, but since this is a corner case, I figured i
> would stick with 'important'.

I was considering whether to mark it as "normal" and tag it with
"moreinfo", but i think this report just describes confusion about what
the tools are supposed to do, so i'm going ahead and closing the report
directly.  The tools are all behaving as documented, from what i can
tell.  Please feel free to reopen if i've misunderstood, or if there are
specific changes that you think should be made that don't involve
breaking existing API.

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#852379: nmu: slepc_3.7.3+dfsg1-4

[Drew Parsons]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

hppa was slow to build petsc 3.7.5. So slepc on hppa was built against
petsc 3.7.4 which is now removed. The conflict means dolfin can't
build on hppa. Rebuilding slepc on hppa will fix it.

nmu slepc_3.7.3+dfsg1-4 . hppa . unstable . -m "Rebuild against PETSc 3.7.5"


If you're able to, could you also give back petsc on alpha?  alpha
builds of petsc have been intermittently failing, but they ought to
succeed.

gb petsc_3.7.5+dfsg1-3 . alpha


Thanks,
Drew


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-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)

Bug#851907: graphicsmagick: gm convert: unrecognized operator (-operator).

[Daniel Kahn Gillmor]

On Thu 2017-01-19 15:07:12 -0500, Bob Friesenhahn wrote:
> On Thu, 19 Jan 2017, Daniel Kahn Gillmor wrote:
>>   -operator channel operator rvalue[%]
>>  apply a mathematical, bitwise, or value  operator  to  an  image
>>  channel
>>
>> But:
>>
>> 0 dkg@alice:~$ gm convert /usr/share/pixmaps/debian-logo.png -operator all 
>> invert '100%' foo.png
>> gm convert: Unrecognized operator (-operator).
>> 1 dkg@alice:~$
>>
>> Somehow this functionality is missing from the compiled build!
>
> The 'invert' keyword sounds useful but the GraphicsMagick 
> documentation specifies to use 'Negate' for this purpose.

d'oh!  so it does.

> This is not a bug.

please consider it a wishlist bug about the error message, then.  In
particular, the error message:

gm convert: Unrecognized operator (-operator).

reads to me like gm doesn't know what to do with "-operator".  I woul
dhave expected it to say:

gm convert: Unrecognized operator "invert"

or:

gm convert: Unrecognized operator "invert" (-operator)


or something to indicate that (-operator) is the origin of the message,
rather than the subject of it.

thanks for pointing out my goof, though!

   --dkg



signature.asc
Description: PGP signature

Bug#852375: RFS: dash-el/2.13.0-1~bpo8+1

[Nicholas D Steeves]

Hi Sean,

On Mon, Jan 23, 2017 at 06:06:44PM -0700, Sean Whitton wrote:
> 
> dash-el 2.13.0-1.1 is set to migrate to stretch in 5 days.  If that
> happens before this gets processed out of backports-NEW, it would be
> rejected by the backports ftp-masters.
> 
> Since 2.13.0-1.1 is very likely the version of dash-el that will be
> frozen in stretch, how about uploading this backport in 5 days, to avoid
> wasting anyone's time?

Sounds good to me!  Updated .dsc available here:
https://mentors.debian.net/debian/pool/main/d/dash-el/dash-el_2.13.0-1.1~bpo8+1.dsc

IIRC, this also also means with-editor and/or magit bpos will need to
be updated, so I'll take a look at those and push to the
jessie-backports branch of the respective package.

Cheers,
Nicholas

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Andreas Beckmann]

On 2017-01-24 02:51, Andreas Beckmann wrote:
> spotted a typo (trailing "a") in frogdata.maintscript
> 
> echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt 0.13.7~"a

but that's harmless, its still a valid version to achieve your goal


Andreas

Bug#852378: openjdk-8: missingn "stretch" in rules makes package depend on libjpeg8.

[Daniel Serpell]

Source: openjdk-8
Version: 8u121-b13-1
Severity: minor

Dear maintainer,

Current debian/rules does not mention "stretch" in the list of distros
that should depend on libjpeg62-turbo, making the openjdk-8-jre-headless
package depends to libjpeg8, and I believe the package should not depend
on that library.

Thanks,


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.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)

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Andreas Beckmann]

Hi,

just browsed the git commits in the web interface

spotted a typo (trailing "a") in frogdata.maintscript

echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt 0.13.7~"a

BTW, you could also add the slash here:

for subdir in "" "nld/" "nl/"

besides that, everything looks ok on a quick glance

will report after I got piuparts results tomorrow ...


Andreas

Bug#825928: lilyterm: Breaks the environment, adding a "=" entry in it. ("env | grep '^=$'" is true)

[Zhong Jianxin]

Package: lilyterm
Version: 0.9.9.4+git20150208.f600c0-5
Followup-For: Bug #825928

I'm sorry to say but the empty environment variable problem was not fix
in version 0.9.9.4+git20150208.f600c0-5.

Maybe I was wrong about the upstream fix, I was too lazy to compile and
test myself.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.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 lilyterm depends on:
ii  libc6   2.24-9
ii  libgdk-pixbuf2.0-0  2.36.4-1
ii  libglib2.0-02.50.2-2
ii  libgtk-3-0  3.22.7-2
ii  libpango-1.0-0  1.40.3-3
ii  libvte-2.91-0   0.46.1-1
ii  libx11-62:1.6.4-2

lilyterm recommends no packages.

lilyterm suggests no packages.

-- no debconf information

Bug#852326: libreoffice-common: Please add Multi-Arch: foreign

[Elrond]

Hi,

On Mon, Jan 23, 2017 at 21:15:03 +0100, Rene Engelhard wrote:
> notfound 852326 1:5.2.4-2~bpo8+1
> tag 852326 + wontfix
> thanks
> 
> On Mon, Jan 23, 2017 at 04:47:50PM +0100, Elrond wrote:
> > Package: libreoffice-common
> 
> This BTS is not for BPO bugs. *If* you file bugs here, file them with
> a proper version. The BTS does NOT know about bpo versions and gets confused.

Okay, will take a note for next time.



> > Version: 1:5.2.4-2~bpo8+1
> > Severity: wishlist
> > 
> > Hi,
> > 
> > It looks like libreoffice-common offers an architecture
> > independent interface to its users.
> 
> No, it doesn't. Except maybe soffice which basically is just a wrapper
> script around soffice.bin and "data"

It is Architecture=all. So it is very, very likely
architecture independent, really.
There are only a few cases, where Architecture=all packages
that should not be tagged M-A:foreign.


> > Would you mind setting it to Multi-Arch: foreign?
> > It's usually a matter of adding one line to debian/control.
> > 
> > This would hopefully improve install options for different
> > architectures.  Like running x32 tools on an amd64 system.
> 
> How? You still need to have the binary "rest" for a working LO. How
> would libreoffice-common on/for x32 help?

Let's assume an amd64 system. untagged Arch=all packages
have the implicit arch of the host system, so, they are
amd64.

If you want to install libreoffice-core/x32, it depends on
libreoffice-common/x32. But libreoffice-common is only
available as /all[amd64] (see above). So you can't
install libreoffice-core/x32.

If libreoffice-common is M-A-foreign, than
libreoffice-common/all[amd64] is allowed to be used instaed
of libreoffice-common/all[x32].  Then installing
libreoffice-core would work.


> And I assume the UNO thingies will have severe problems with multi-arch
> anyway.

The uno-libs3 package isn't a problem. The x32 one can be
installed on amd64.
Neither is ure.

The python thingies could become a problem.

This request is one step in the right direction.

I am actually trying to run different versions of LO on my
machine for different reasons. And this is currently
stopping me from doing so.


> No, won't do that.

What exactly would break? What is the real problem you're
trying to avoid?

fonts-opensymbol (from the same source package) is already
marked Multi-Arch=foreign, so what's different here?

Please help me understand.


> Regards,
> 
> Rene


Cheers

Elrond

Bug#852377: RFS: tikzit/1.0-1 [ITP]

[Gard Spreemann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "tikzit"

* Package name: tikzit
  Version : 1.0-1
  Upstream Author : Aleks Kissinger 
* URL : http://tikzit.sourceforge.net/
* License : Mostly GPL-3+, some LGPL-2+
  Section : tex

It builds these binary packages:

  tikzit - Graphical tool for creating node-and-edge style graphs

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/tikzit

Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/t/tikzit/tikzit_1.0-1.dsc

The current version of the package is based on the "v1.0" tag in
upstream's git repository. There are four patches on top of this,
corresponding to later upstream commits, that fix a bison parser
declaration error.

The orig tarball does not match the tarball released by upstream. It
is a repack of the git tree with some website-related files removed. I
realize therefore that the version should be something like
1.0+dfsg.1-1.

I am aware that the package lacks a watch file. I need advice as to
how this is best done when upstream releases both as tarball and as
tagged git commits, with slight differences.


Regards,
 Gard Spreemann

Bug#852375: RFS: dash-el/2.13.0-1~bpo8+1

[Sean Whitton]

control: owner -1 !

Dear Nicholas,

dash-el 2.13.0-1.1 is set to migrate to stretch in 5 days.  If that
happens before this gets processed out of backports-NEW, it would be
rejected by the backports ftp-masters.

Since 2.13.0-1.1 is very likely the version of dash-el that will be
frozen in stretch, how about uploading this backport in 5 days, to avoid
wasting anyone's time?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#824169: "Source packages building main+contrib binaries end up in both components"

[Andreas Beckmann]

Followup-For: Bug #824169

For the record, in nvidia-settings I worked around this problem by
disabling the nvidia-settings-dbgsym/contrib package, but still building
libxnvctrl0-dbgsym (which goes into main).

Please let me know if I can remove that workaround again.

libxnvctrl-dev | 375.26-3 | unstable | amd64, 
arm64, armel, ...
libxnvctrl0| 375.26-3 | unstable | amd64, 
arm64, armel, ...
libxnvctrl0-dbgsym | 375.26-3 | unstable-debug   | amd64, 
arm64, armel, ...
nvidia-settings| 375.26-3 | unstable | source
nvidia-settings| 375.26-3 | unstable-debug   | source
nvidia-settings| 375.26-3 | unstable/contrib | amd64, 
armhf, i386


Andreas

Bug#849489: RFS: darksnow/0.7.1-1 [QA]

[David Davies-Jones]

In all honesty I don't think I'll have any more free time until June, so it
would probably be better to close the bug

On 24 Jan 2017 01:00, "Sean Whitton"  wrote:

> Dear David,
>
> On Tue, Jan 24, 2017 at 12:33:49AM +, David Davies-Jones wrote:
> > I'm really sorry but my time has evaporated, I'm no longer able to fix
> > the problems with this.
>
> That's fine.  There is no need to apologise.
>
> If you will have time after Debian Stretch is released, we could upload
> this then?  Otherwise, we can just close the bug.  Let me know.
>
> --
> Sean Whitton
>

Bug#849489: RFS: darksnow/0.7.1-1 [QA]

[Sean Whitton]

Dear David,

On Tue, Jan 24, 2017 at 12:33:49AM +, David Davies-Jones wrote:
> I'm really sorry but my time has evaporated, I'm no longer able to fix
> the problems with this.

That's fine.  There is no need to apologise.

If you will have time after Debian Stretch is released, we could upload
this then?  Otherwise, we can just close the bug.  Let me know.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851148: tracker-extract: dumps core repeatedly if seccomp raises SIGSYS

[Ben Longbons]

FYI, your mailer is not using TLS, so it's getting marked a spam.


On Thu, Jan 12, 2017 at 5:07 AM, Simon McVittie  wrote:
>> should log those details
>
> Logging in response to an async signal is problematic: it is not safe
> to use anything much more complicated than a syscall in a signal
> handler (in particular, stdio or GLib logging is a bad idea and
> could deadlock). I think the correct thing here is for tracker-extract
> to just crash, and let system-level diagnostic tools like
> systemd-coredump work out why.

It's quite true that doing anything *complicated* is forbidden. But
there's no need to be complicated.

Just write(2) a newline, a handful of fixed strings, and the hex value
of the syscall and instruction. snprintf(3) isn't safe, but converting
an integer to hex by hand is trivial anyway, compared to using a
seccomp sandbox. Personally, I would've just chrooted (having userns
these days makes sandboxing *so* much easier since you don't need
permissions to become a new "root").

>> During a recent apt run, my system became almost completely
>> unresponsive.
>
> I suspect that the thing stalling your system here is actually
> the repeated core-dump processing, not the repeated
> tracker-extract startup - at least, that has been my experience when
> dealing with repeatedly crashing software. systemd-coredump uses
> relatively expensive compression.

True, but the crashing application is still responsible for the
consequences, especially when it's something that nobody ever asked
for anyway.

Bug#850269: gpgme1.0: FTBFS randomly (not enough entropy)

[Daniel Kahn Gillmor]

On Mon 2017-01-23 19:21:30 -0500, Santiago Vila wrote:
>> > I wonder, however, why the tests need to generate a key at all,
>> > just to discard it after the package is built. Would not be possible
>> > to use a pregenerated key for the tests?
>> 
>> gpgme exercises functionality of the GnuPG suite, including key
>> generation.  If we were to use a pregenerated key, we might as well just
>> skip the test suite :)
>
> Well, it could be argued that the key creation part should be already
> covered by the test suite of gnupg itself.

hm, that wouldn't test whether gpgme is actually doing the right thing
to drive gpg, though.  I think we do still need that test in gpgme, just
like we'd need a higher-level test for a mail user agent that was
supposed to generate keys, or to do anything else that involves
randomness.  Build processes and testing should in general avoid the use
of randomness, but a test suite that tries to exercise code that should
use randomness in the real world (even at other lower levels) should
still be allowed access to that randomness during the compile-time
testing.  no?

   --dkg

Bug#852376: ITP: tikzit -- Graphical tool for rapidly creating and editing node-and-edge style graphs in TikZ.

[Gard Spreemann]

Package: wnpp
Severity: wishlist
Owner: Gard Spreemann 

* Package name: tikzit
  Version : 1.0
  Upstream Author : Aleks Kissinger 
* URL : http://tikzit.sourceforge.net/
* License : Mostly GPL-3+, some LGPL-2+
  Programming Lang: Mostly Objective C
  Description : Graphical tool for rapidly creating and editing 
node-and-edge style graphs in TikZ.

TikZiT is a graphical tool for rapidly creating and editing
node-and-edge style graphs. It was originally created to aid in the
typesetting of "dot" diagrams of interacting quantum observables (see
arXiv:0906.4725), but can be used as a general graph editing program.

I used to maintain a version of this software in an Ubuntu PPA that
was moderately popular. To this day a few people e-mail me requesting
updated versions of the software, so I believe this package will be
useful.

There was little development following the 2013 release of version
1.0. However, development has recently restarted and a version 1.1
appears to be forthcoming.

I would need a sponsor for the package.

Bug#793106: htop: malfunctions with TERM=linux-16color [was: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)]

[Ben Longbons]

FYI, your mailer config is broken, so you're being classified as spam.
Please read https://support.google.com/mail/answer/81126?hl=en#authentication

On Wed, Jan 11, 2017 at 12:57 PM, Daniel Lange  wrote:
> How can I reproduce the issue on Debian Linux?

Pretty much anybody who *ever* edits their ~/.bashrc adds something like:

case $TERM in
xterm) TERM=xterm-256color;;
esac

I just added a second case for linux.

Bug#815170: love: New upstream version available

[Markus Koschany]

Control: owner -1 !

On 23.01.2017 11:29, Alexandre Detiste wrote:
> control: tag -1 +pending
> 
>> 2016-12-18 15:15 GMT+01:00 Bart van Strien :
> 
> Hi,
> 
> I had some time to work again on this & have now a updated package
> awaiting review & upload by a sponsor.
> 

Hi Alexandre,

thanks for working on this package. I intend to sponsor it provided that
you push your upstream and pristine-tar branches as well!

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#849489: RFS: darksnow/0.7.1-1 [QA]

[David Davies-Jones]

Hello

I'm really sorry but my time has evaporated, I'm no longer able to fix the
problems with this.

On 28 December 2016 at 22:56, Sean Whitton  wrote:

> Hello David,
>
> On Wed, Dec 28, 2016 at 10:53:00PM +, David Davies-Jones wrote:
> > I shall go through it with a fine toothcomb over the next few days. Yes,
> this
> > may be a better method. At the moment, I make changes as I can, which can
> > result in loosing track of what I've done. I shall experiment with using
> git
> > like this and see how I go on. With the packages that I've been putting
> up to
> > mentors I've been constructing a mental checklist of what I'm learning,
> need to
> > start putting it down in writing and following it rigidly.
>
> Cool.  It's not arduous once you're in the habit of updating the
> changelog every time you make a git commit.  I'm biased here, but a
> decent git workflow is in this tutorial: dgit-maint-merge(7)
>
> --
> Sean Whitton
>

Bug#802300: still in stretch

[Fernando Toledo]

Hi, this bug still present in stretch due to outdated release.
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814734

Saludos!

Bug#850269: gpgme1.0: FTBFS randomly (not enough entropy)

[Santiago Vila]

> > I wonder, however, why the tests need to generate a key at all,
> > just to discard it after the package is built. Would not be possible
> > to use a pregenerated key for the tests?
> 
> gpgme exercises functionality of the GnuPG suite, including key
> generation.  If we were to use a pregenerated key, we might as well just
> skip the test suite :)

Well, it could be argued that the key creation part should be already
covered by the test suite of gnupg itself.

Thanks.

Bug#852082: gwc in testing crashes at startup

[James Cowgill]

Control: tags -1 patch

Hi,

On 23/01/17 15:29, James Cowgill wrote:
> On 23/01/17 12:39, Jaromír Mikeš wrote:
>> 2017-01-22 1:11 GMT+01:00 James Cowgill :
>> On 21/01/17 14:18, Christian Grigis wrote:
>> [...]
>> > The gdb backtrace gives:
>> >
>> > (gdb) run
>> > Starting program: /home/glove/tmp/gwc-testing/gwc-0.21.19~dfsg0/gwc
>> > [Thread debugging using libthread_db enabled]
>> > Using host libthread_db library 
>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> > Current stack limit: 8388608 bytes
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x76e047f9 in g_type_is_a () from 
>> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
>> > (gdb) bt
>> > #0  0x76e047f9 in g_type_is_a () from 
>> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
>> > #1  0x77519084 in gtk_type_new () from 
>> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
>> > #2  0x5557223c in led_bar_new (segments=20, orientation=0) at 
>> gtkledbar.c:82
>>
>> The problem is here. led_bar_get_type returns an unsigned int, but
>> gtk_type_new expects a "GtkType" which is an integer with the same size
>> as a pointer. This code is going to need porting to work on 64-bit
>> arches.
>>
>> James I guess as it wouldn't be trivial to fix it by patch and we need
>> to this issue must be fixed upstream.
>> Am I right?
> 
> It's definitely an upstream issue, but I fear that by just pushing it
> upstream the package will be kicked out of stretch. It's hard to say how
> much work it would be until someone tries to fix it - it could be just
> this one function that's broken, or it could be many. You can probably
> catch a lot of these by enabling -Wconversion.

Looks like there weren't many instances of this particular bug (loads of
warnings to sieve through though). This patch should fix it.

James
Description: Fix pointer truncation issues in 2 _get_type functions
 On 64-bit architectures the pointers returned by these functions were being
 truncated to 32-bits causing segfaults.
Author: James Cowgill 
Bug-Debian: https://bugs.debian.org/852082
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/gtkgamma.c
+++ b/gtkgamma.c
@@ -202,10 +202,10 @@ static char *xpm[][27] =
 }
   };
 
-guint
+GtkType
 gtk_gamma_curve_get_type (void)
 {
-  static guint gamma_curve_type = 0;
+  static GtkType gamma_curve_type = 0;
 
   if (!gamma_curve_type)
 {
--- a/gtkgamma.h
+++ b/gtkgamma.h
@@ -68,7 +68,7 @@ struct _GtkGammaCurveClass
 };
 
 
-guint  gtk_gamma_curve_get_type (void);
+GtkTypegtk_gamma_curve_get_type (void);
 GtkWidget* gtk_gamma_curve_new  (void);
 
 
--- a/gtkledbar.c
+++ b/gtkledbar.c
@@ -28,10 +28,10 @@
 static void led_bar_class_init(LedBarClass *klass);
 static void led_bar_init  (LedBar  *led_bar);
 
-guint
+GtkType
 led_bar_get_type ()
 {
-  static guint led_bar_type = 0;
+  static GtkType led_bar_type = 0;
 
   if (!led_bar_type)
 {
--- a/gtkledbar.h
+++ b/gtkledbar.h
@@ -57,7 +57,7 @@ struct _LedBarClass
   GtkVBoxClass   parent_class;
 };
 
-guint led_bar_get_type(void);
+GtkType   led_bar_get_type(void);
 GtkWidget*led_bar_new (gint   segments,
 	   gint   orientation);
 gint  led_bar_get_num_segments(GtkWidget  *bar);


signature.asc
Description: OpenPGP digital signature

Bug#852106: [pkg-gnupg-maint] Bug#852106: gpgme1.0: Build allocates 200 GB as a normal thing

[Santiago Vila]

On Mon, Jan 23, 2017 at 05:41:29PM -0500, Daniel Kahn Gillmor wrote:

> I'm open for suggestions for how to address this.  We could just drop
> THREAD_COUNT from 100 to 10 to reduce the RAM consumption, but that
> would mean minimizing some of the concurrency that the test suite is
> (rightly) trying to judge itself against.  I'd rather not remove those
> kinds of checks if we don't need to.
> 
> Any suggestions about what the right thing to do is?  

Just try to be more "normal", i.e. try reducing the memory
requirements to, say, 4 GB, or 8 GB if you really need it.
I would consider 16 GB to be already too much by today's standards,
considering the memory requirements of all the other packages.

I have put the current memory requirements for the packages
that may be built with "dpkg-buildpackage -A" here:

https://people.debian.org/~sanvila/A.memory.txt

Try "sort -k2 -n" on that file and you will see not only that gpgme1.0
is at the end but also how far this package is from the average, the
median, or any other significant statistic measure that you can
imagine.

Of course, there is not a policy anywhere saying "packages must not
use more than X GB of memory", so just apply common sense.

Thanks.

Bug#852029: netbeans: CVE-2016-5537: Import directory traversal

[Markus Koschany]

On 23.01.2017 07:23, Salvatore Bonaccorso wrote:
> Hi Markus,
> 
> Thanks for looking into the issue.
[...]
> I agree, upstream has not really provided any usefull information, and
> we have somehow to trust Oracle here, that 8.2 contains the fix. I'm
> confident, since the 8.2 version gives now a warning, if you try to
> import a project from a zip file containing members with "../". But I
> was unable to determine the exact code change.
> 
> I'm not sure about the options.
> 
> 1/ try to determine the required changes and backport them to 8.1
> ideally, but seems a bit hard.
> 2/ live with the issue, and once stretch is a stable release mark it
> as no-dsa as well there.
> 3/ Ask release team if having 8.2+dfsg1-1 in stretch, but I guess that
> unblock is not feasible anymore now.
> 4/ something missing?
> 
> Regards, and sorry for not beeing more helpfull here,
> Salvatore

Hi Salvatore,

definitely not your fault and thanks for reporting, much appreciated as
always.

At the moment I think I will mark it as no-dsa in Stretch, 8.2 isn't
ready for prime time yet but in the future it will eventually close this
bug report. Of course if someone else can point me to the
commit/fix/patch I will try to get this into Stretch.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#852290: inkscape: saving as "optimised SVG" fails, due to error when importing scourString

[Tim Wienk]

Dear Mattia,

Thanks for picking up the issue on such short notice. I saw the issue
and patch on launchpad, I'll be following and awaiting that issue as
well to see how and when the problem is resolved.

Mattia Rizzolo wrote:
>> I have implemented the following patch locally to work around the
>> problem:
>>
>> --- /usr/share/inkscape/extensions/scour.inkscape.py~
>> +++ /usr/share/inkscape/extensions/scour.inkscape.py
>> @@ -6,3 +6,6 @@
>>  import scour
>> -from scour.scour import scourString
>> +try:
>> +from scour.scour import scourString
>> +except Exception as e:
> If anything, this should catch inly ImportError over all of Exception
> (besides, there is no need to keep the exception info in the 'e'
> variable here).

You are obviously correct, there is no need to catch every exception or
to store it in `e`. I guess I was lazy in implementing the fix, and
duplicated the `except` statement from two lines below (I implemented
the change when I quickly needed a fix, submitted the report about an
hour later).

> Thank you again for your bug!

I am just a user, I'm sure I don't deserve a lot of credit. :-) Thanks
again for the effort and the quick action.

Kind regards,

Tim.

Bug#822091: libxmlbeans-java: Embeds classes without source

[Markus Koschany]

Control: severity -1 normal
Control: tags -1 pending

On 23.01.2017 23:11, Emmanuel Bourg wrote:
> I got another look at this, and maybe it isn't as bad as we thought. The
> piccolo jars in external/lib/ do not contain compiled .class files, but
> only .java source files. The xmlbeans build unpacks them to
> build/private/piccolo/src, changes the package to
> org.apache.xmlbeans.impl.piccolo, and then compiles them.
> 
> There are still a few jar files with compiled classes (junit, saxon,
> jsr173, oldxbean) but they aren't used to build the package. So this is
> more a matter of cleaning the upstream tarball of unnecessary files than
> fixing a severe policy violation.

Very well then, I let this one pass for once. ;)




signature.asc
Description: OpenPGP digital signature

Bug#852302: ipxe-qemu: Crash with QEMU newer than 2.6

[Charles Malaheenee]

We have qemu 2.8 (1:2.8+dfsg-1) and ipxe-qemu (1.0.0+git-20161027.b991c67-1)

With this versions, we attempt to run virt-install with pxe option and got a 
messages in logs like this:

2017-01-23 11:45:17.987+: starting up libvirt version: 2.5.0, package: 3 
(Guido Günther  Fri, 23 Dec 2016 16:18:12 +0100), qemu 
version: 2.8.0(Debian 1:2.8+dfsg-1), hostname: big-pc.home
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name 
guest=git.debian.decelles.ca,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-git.debian.decelles./master-key.aes
 -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu 
core2duo,-vmx -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 
-uuid 03a68d52-2249-4c61-b1f1-0a5b666f6317 -display none -no-user-config 
-nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-git.debian.decelles./monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -global 
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive 
file=/home/libvirt/pool/git.debian.qcow2,format=qcow2,if=none,id=drive-virtio-disk
 0 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:10:01:13,bus=pci.0,addr=0x2,bootindex=1
 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-git.debian.decelles./org.qemu.guest_agent.0,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
char device redirected to /dev/pts/3 (label charserial0)
KVM internal error. Suberror: 1
emulation failure
EAX=e010 EBX=00a0 ECX=2e70 EDX=000a38b8
ESI=1ffa2fe0 EDI=1fed EBP= ESP=7b92
EIP=06a1 EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   00c09300
CS =9c48 0009c480  00809b00
SS =   00809300
DS =9ccc 0009ccc0  00c09300
FS =   00c09300
GS =   00c09300
LDT=   8200
TR =   8b00
GDT=  
IDT=  03ff
CR0=0010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=
Code=00 16 66 9c 66 60 0f a8 0f a0 06 1e 16 0e fa 2e 8e 1e 86 06 <0f> ae 06 20 
1d 0f 01 0e 16 1d 0f 01 06 10 1d fc 66 b9 38 00 00 00 66 ba 10 02 00 00 66 68
2017-01-23T11:45:30.186063Z qemu-system-x86_64: terminating on signal 15 from 
pid 483 (/usr/sbin/libvirtd)
2017-01-23 11:45:30.386+: shutting down, reason=destroyed

So, It may be fixed with newest ipxe, not only with qemu itself.

-- 
Best Regards,
Charles Malaheenee

Bug#851918: might not be endianness-related - mips build of mpgrafic is OK

[Boud Roukema]

The mips build (including the code regression test) of mpgrafic-0.3.9-1 
succeeded:

https://buildd.debian.org/status/fetch.php?pkg=mpgrafic=mips=0.3.9-1=1485163898=0

So this bug might not be purely an endianness bug.

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-22 23:02 GMT+01:00 Jens Reyer :
> On 01/22/2017 10:36 PM, Matthias Klumpp wrote:
>> 2017-01-22 22:02 GMT+01:00 Jens Reyer :
>>> The new wine-development now shows up in GNOME Software Center, the
>>> installed status is correct and install/removal works.
>>>
>>> But wine is still broken in there (install status is always
>>> "installed"). I don't know if I just broke my system, or if everyone is
>>> affected.  Feedback from anyone is welcome.
>>
>> Sounds like a GNOME Software bug... Maybe it assumes stuff to be
>> installed when a metainfo file exists in /usr/share/metainfo, so if
>> you manually place it there, GS gets confused. If that's not the case,
>> this is a weird GS bug - can you verify this bug with GNOME Software
>> 3.22.5 (in unstable)?
>
> Still there with 3.22.5-1.
>
> What's strange is that this only happens with wine, but not with
> wine-development, although both are identical here besides their
> AppStream id and name.
>
> While testing I indeed had placed the files manually somewhere (maybe
> only the one for wine, but not that for wine-development), but removed
> them since. With all wine packages uninstalled:
>
> $ ls /usr/share/applications/*wine*
> ls: cannot access '/usr/share/applications/*wine*': No such file or
> directory
>
> $ ls /usr/share/metainfo
> org.freedesktop.appstream.cli.metainfo.xml
>
> $ ls /var/cache/app-info/xmls/
> fwupd.xml

Very strange - I can't reproduce this here, everything looks as
expected. If this persists, it's probably worth filing an upstream
bug...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#852375: RFS: dash-el/2.13.0-1~bpo8+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my backport of "dash-el".  It is a
prerequisite for a bpo of magit 2.x (really nice emacs interface for
git).  I have received Hajime Mizuno, the maintainer's, blessing to
maintain a bpo of dash-el.

I hope that this RFS is in the correct format, because the package I
uploaded to mentors does not appear under packages/my, and I've
had to manually populated these fields.

Package name: dash-el
Version : 2.13.0-1~bpo8+1

It builds those binary packages:

dash-el - Modern list manipulation library for Emacs

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/dash-el

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/d/dash-el/dash-el_2.13.0-1~bpo8+1.dsc

Changes since the last upload:

dash-el (2.13.0-1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.

 -- Nicholas D Steeves   Mon, 16 Jan 2017 23:12:50 -0500

dash-el (2.13.0-1) unstable; urgency=medium

  * new upstream release
  * debian/control
- set Standards-Version: 3.9.8.

 -- Hajime Mizuno   Sat, 20 Aug 2016 21:45:15 +0900

dash-el (2.12.1-1) unstable; urgency=medium

  * new upstream release

 -- Hajime Mizuno   Wed, 13 Jan 2016 11:19:26 +0900

dash-el (2.11.0-1) unstable; urgency=medium

  * new upstream release

 -- Hajime Mizuno   Sun, 12 Jul 2015 20:16:52 +0900

dash-el (2.10.0-1) unstable; urgency=low

  * Initial release (Closes: #770466)

 -- Hajime Mizuno   Fri, 21 Nov 2014 22:21:54 +0900

Regards,
Nicholas

Bug#852374: sagemath FTBFS on i386: recipe for target 'had-few-failures' failed

[Adrian Bunk]

Source: sagemath
Version: 7.4-7
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=sagemath=i386=7.4-7=1485112049=0

...
--
sage -t --long 
src/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py  # 1 
doctest failed
sage -t --long src/sage/plot/plot.py  # 1 doctest failed
sage -t --long src/sage/tests/cmdline.py  # 4 doctests failed
sage -t --long src/sage/coding/linear_code.py  # 3 doctests failed
sage -t --long src/sage/plot/arrow.py  # 1 doctest failed
sage -t --long src/sage/misc/cython.py  # 2 doctests failed
sage -t --long src/sage/rings/integer.pyx  # 1 doctest failed
sage -t --long src/sage/interfaces/maxima.py  # 1 doctest failed
sage -t --long src/sage/tests/french_book/recequadiff.py  # 2 doctests failed
sage -t --long src/sage/misc/randstate.pyx  # 13 doctests failed
sage -t --long src/sage/interfaces/r.py  # 2 doctests failed
sage -t --long src/sage/gsl/probability_distribution.pyx  # 1 doctest failed
sage -t --long src/sage/coding/codecan/autgroup_can_label.pyx  # 1 doctest 
failed
sage -t --long src/sage/algebras/group_algebra.py  # 2 doctests failed
sage -t --long src/sage/libs/libecm.pyx  # 1 doctest failed
sage -t --long src/sage/numerical/optimize.py  # 1 doctest failed
sage -t --long src/sage/libs/singular/function.pyx  # 2 doctests failed
sage -t --long src/sage/groups/matrix_gps/matrix_group.py  # 1 doctest failed
sage -t --long src/sage/geometry/polyhedron/backend_cdd.py  # 1 doctest failed
sage -t --long src/sage/rings/number_field/number_field_element.pyx  # 1 
doctest failed
sage -t --long src/sage/functions/wigner.py  # Timed out (and interrupt failed)
--
Total time for all tests: 7560.0 seconds
cpu time: 2648.0 seconds
cumulative wall time: 2811.0 seconds
make[2]: Entering directory '/«PKGBUILDDIR»'
debian/rules:130: recipe for target 'had-few-failures' failed
make[2]: *** [had-few-failures] Error 1

Bug#852373: libesedb FTBFS on i386/armel/armhf: test_library.sh fails

[Adrian Bunk]

Source: libesedb
Version: 20170121-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libesedb

...
SKIP: test_esedbexport.sh
SKIP: test_esedbinfo.sh
SKIP: test_python_module.sh
FAIL: test_library.sh
=
   libesedb 20170121: tests/test-suite.log
=

# TOTAL: 4
# PASS:  0
# SKIP:  3
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test_library.sh
=

Testing: catalog  (PASS)
Testing: catalog_definition  (PASS)
Testing: column  (PASS)
Testing: column_type  (PASS)
Testing: data_definition  (PASS)
esedb_test_data_segment.c:135 result (1) != -1
Unable to run test: libesedb_data_segment_initialize
Testing: data_segment  (FAIL)
FAIL test_library.sh (exit status: 1)

SKIP: test_esedbinfo.sh
===

Test input directory: input not found.
SKIP test_esedbinfo.sh (exit status: 77)

SKIP: test_esedbexport.sh
=

Test input directory: input not found.
SKIP test_esedbexport.sh (exit status: 77)

SKIP: test_python_module.sh
===

Testing Python-bindings functions: support  (PASS)
Test input directory: input not found.
SKIP test_python_module.sh (exit status: 77)


Testsuite summary for libesedb 20170121

# TOTAL: 4
# PASS:  0
# SKIP:  3
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to joachim.m...@gmail.com

Makefile:1460: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1
make[4]: Leaving directory '/«PKGBUILDDIR»/tests'
Makefile:1566: recipe for target 'check-TESTS' failed
make[3]: *** [check-TESTS] Error 2
make[3]: Leaving directory '/«PKGBUILDDIR»/tests'
Makefile:1660: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/«PKGBUILDDIR»/tests'
Makefile:784: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_test: make -j4 check VERBOSE=1 returned exit code 2
debian/rules:8: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2

Bug#850269: gpgme1.0: FTBFS randomly (not enough entropy)

[Daniel Kahn Gillmor]

Hi Santiago--

On Sat 2017-01-21 12:21:44 -0500, Santiago Vila wrote:

> I confirm that it's lack of entroy what makes this package to fail.
>
> Since I'm using sbuild, I added this line to /etc/schroot/default/fstab:
>
> /dev/urandom/dev/random nonerw,bind 0   0
>
> then tried to build this package 40 times, and I got 40 successful
> builds.
>
> I wonder, however, why the tests need to generate a key at all,
> just to discard it after the package is built. Would not be possible
> to use a pregenerated key for the tests?

gpgme exercises functionality of the GnuPG suite, including key
generation.  If we were to use a pregenerated key, we might as well just
skip the test suite :)

 --dkg

Bug#852372: czmq FTBFS on mips: build killed after after 150 minutes of inactivity

[Adrian Bunk]

Source: czmq
Version: 4.0.2-4
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=czmq=mips=4.0.2-4=1485124953=0

...
make[2]: Entering directory '/«PKGBUILDDIR»'
Making check in doc
make[3]: Entering directory '/«PKGBUILDDIR»/doc'
make[3]: Circular czmq.txt <- czmq.txt dependency dropped.
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/«PKGBUILDDIR»/doc'
make[3]: Entering directory '/«PKGBUILDDIR»'
make  src/czmq_selftest
make[4]: Entering directory '/«PKGBUILDDIR»'
make[4]: 'src/czmq_selftest' is up to date.
make[4]: Leaving directory '/«PKGBUILDDIR»'
make  check-TESTS check-local
make[4]: Entering directory '/«PKGBUILDDIR»'
make[5]: Entering directory '/«PKGBUILDDIR»'

Testsuite summary for czmq 4.0.2

# TOTAL: 0
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[5]: Leaving directory '/«PKGBUILDDIR»'
/bin/bash ./libtool --mode=execute ./src/czmq_selftest
make[2]: *** wait: No child processes.  Stop.
make[2]: *** Waiting for unfinished jobs
make[2]: *** wait: No child processes.  Stop.
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Terminated
debian/rules:21: recipe for target 'override_dh_auto_test' failed
make[1]: [override_dh_auto_test] Terminated (ignored)
Build killed with signal TERM after 150 minutes of inactivity
Build killed with signal KILL after 5 minutes of inactivity

Bug#851927: This is still broken on 55.0.2883.75-6

[Jean-Francois Pirus]

The extensions are still disabled when starting chromium. Having to edit 
the startup script every time there is an update is not a valid solution.


This should either go back to the previous behaviour, or have a way of 
enabling the previous behaviour (ie: extensions that work) that is 
permanent across updates.

Bug#852371: RFS: udftools/1.3-1

[Pali Rohár]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "udftools"

 * Package name: udftools
   Version : 1.3-1
   Upstream Author : Pali Rohár 
 * URL : https://github.com/pali/udftools
 * License : GPL-2+
   Section : otherosfs

It builds those binary packages:

  udftools   - tools for UDF filesystems and DVD/CD-R(W) drives

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/udftools


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/u/udftools/udftools_1.3-1.dsc

More information about udftools can be obtained from 
https://github.com/pali/udftools.

Changes since the last upload:

 * New upstream release


Regards,
 Pali Rohár


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

Bug#852329: libreoffice-calc: mishandles backslashes and double-quotes during CSV import

[Thorsten Glaser]

Rene Engelhard dixit:

>Why reporting on this ooold version?

Apparently, nullmailer in schroot requires a dæmon to actually
send mails to the postfix running on localhost. I have to find
out a different way to send mails from a chroot. sendmail, probably.

Those were old bugreports, but I had to fixup the From line,
so I put them into the regular MUA, which also changed Date.

>> LibreOffice Calc violates the CSV specification in two ways.
>
>Does it still happen in 5.2.4 as in stretch/sid? (Which is what you apparently
>are aiming to use, so...)

I’ll try that…

>And it also might be worth to try with 5.3 (experimental).

… but not that. I run sid only, x32 preferably (amd64 in a chroot).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#852370: override: udftools:otherosfs/optional

[Pali Rohár]

Package: ftp.debian.org
Severity: normal

Package udftools does not conflicts with others, so optional priority
level fits better then extra.

Bug#851790: installation-reports: DNS not working

[Aurelien Jarno]

On 2017-01-23 17:30, Wookey wrote:
> On 2017-01-19 11:04 +0100, Cyril Brulebois wrote:
> > Steve McIntyre  (2017-01-19):
> > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> > > >
> > > >The workaround are to make sure the chroots are up-to-date (which should
> > > >be the case now on the build daemons). An other alternative would be to
> > > >avoid copying a library in mklibs if it is already present in the image.
> > > >That might break if some very strict dependencies are used, though
> > > >I guess the way the udebs are downloaded, they should always have the
> > > >same or a newer version than in the chroot.
> > > 
> > > Thanks for the explanation - it's appreciated!
> > 
> > Yeah, thanks for the confirmation.
> 
> OK. I tested today's image (2017-01-23 04:56) and the install went
> through OK, so we are back in sync and this issue is gone for now. It should
> probably be retitled to something about library sync/using host libs
> and left open until it's fixed propoerly.

I have pushed a patch a few days ago that should fix the issue. Well I
don't know if it should be considered as a fix or a hack, but at least
it looks less a hack than the existing code...

The longterm solution is clearly to fully get rid of mklibs. That should
wait for after stretch though, as it requires new udebs from some
packages and thus some coordination.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#852345: ssvnc: Lower recommends on default-jre to suggests

[Magnus Holmgren]

måndag 23 januari 2017 kl. 10:06:53 CET skrev du:
> Please consider demoting the Recommends on "default-jre |
> java5-runtime" to a Suggests. SSVNC is certainly useful without java;
> I'm not sure what functionality it adds.
> 
> SSVNC is part of the VNC dependency chain used by epoptes, and other
> than the issue with recommends pulling in a large number of additional
> packages, would likely be the preferred VNC client.
> 
> Maybe there is something I'm unaware of that makes running SSVNC
> without java unusual?

ssvncviewer adds support for the UltraVNC file transfer extension. That part 
is written in Java, which is a bit unfortunate. but I find it pretty useful. 
I'm not sure how recommendable it is. Probably in a grey zone.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#848064: radicale: Add debconf support for basic configuration

[James Valleroy]

On Tue, 13 Dec 2016 12:14:52 -0500 James Valleroy
 wrote:
> The attached patch set implements this, by adding several debconf
> questions to set the server hostnames, base url, well-known paths,
> authentication type, and rights type. These questions all have low
> priority. I used augtool (from augeas-tools) to read/modify the config
> file, and ucf to merge user settings with updates to the packaged file.

After sending this patch, I discovered this rule given in the Debconf
Programmer's Tutorial:
"Note that the config script is run before the package is unpacked. It
should only use commands that are in essential packages."

But in the patch I submitted (part 0002), I used augtool in
debian/radicale.config to parse the ini-file config and read current
settings from disk. So that is a problem for the 0002 and 0003 patches
above.

Patch 0001, which only adds ucf to improve merging changes to the
config, should still be ok.



signature.asc
Description: OpenPGP digital signature

Bug#698378: Daniel has orphaned libvorbisidec

[Daniel Kahn Gillmor]

On Mon 2017-01-23 15:52:03 -0500, Adrian Bunk wrote:
> Control: retitle -1 O: libvorbisidec -- Integer-only Ogg Vorbis decoder, AKA 
> 'tremor'
>
> Daniel has orphaned libvorbisidec.

thanks for taking care of my orphans (and the archive in general),
Adrian!

Regards,

--dkg

Bug#852004: RFP for bioperl's Bio-EUtilities

[gregor herrmann]

On Mon, 23 Jan 2017 22:45:24 +0100, Andreas Tille wrote:

> > The first is from a missing dependency (Bio::ASN1::EntrezGene),
> > which is really optional (the comp test should skip that
> > directory). The other is from XML::Simple, which is unusual; I’m
> > wondering whether the underlying XML parser is checking the XML
> > schema for the test reports. Any idea what the specific XML::SAX
> > backend parser module used was?
> 
> Sorry, I've sended a wrong version of the log with missing
> Build-Depends.  Please check again.

The tests fail for me as well, in a chroot with networking firewalled
off.

The errors are slightly different, probably because I have http_proxy
set:

http error : Operation in progress
XML::Simple called at 
/build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
# Looks like your test exited with 255 before it could output anything.
t/egquery.t . 
1..18
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 18/18 subtests 

etc. for all t/e*.t tests

/*
With http_proxy unset I get:

http error : Unknown IO error
http error : connection refused
XML::Simple called at 
/build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
# Looks like your test exited with 255 before it could output anything.
t/egquery.t . 
1..18
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 18/18 subtests 

*/

Anyway, it's quite clear that the tests try to access the internet
which is forbidden by Debian policy (regardless of the fact if the
fail gracefully or not), so they have to be skipped.

Andreas, you already know the trick with debian/tests/pkg-perl/smoke-skip
and using the file in debian/rules as well to disable tests during
build + autopkgtest. If you don't run okg-perl-autopkgtests, you can
use:

#v+
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,13 @@
 #!/usr/bin/make -f

+TEST_FILES = $(filter-out $(wildcard t/e*.t),$(wildcard t/*.t))
+
 %:
dh $@

 override_dh_installchangelogs:
dh_installchangelogs Changes
+
+override_dh_auto_test:
+   # disable tests which need a network connection
+   dh_auto_test -- TEST_FILES="$(TEST_FILES)"
#v-


Of course an upstream fix, e.g. skipping tests if
$ENV{NETWORK_TESTING} is not set etc., would be nicer.
(Hm, is this the package that was discussed on #debian-perl on IRC
earlier yesterday? :))


BTW: I think override_dh_installchangelogs in d/rules is not needed,
dh_installchangelogs should find Changes by itself.
 

Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Track 6


signature.asc
Description: Digital Signature

Bug#852106: [pkg-gnupg-maint] Bug#852106: gpgme1.0: Build allocates 200 GB as a normal thing

[Daniel Kahn Gillmor]

Hi Santiago--

On Sat 2017-01-21 12:40:06 -0500, Santiago Vila wrote:
> I have a cron job monitoring "Committed_AS" in /proc/meminfo every time
> my autobuilders are running, that way I know how much memory each
> package requires.
>
> Well, building gpgme1.0 allocates 100 GB, 200 GB and sometimes 500 GB.

yikes!  I've never noticed that, but i can replicate it now that i'm
looking for it.  I'm a bit surprised a cronjob would have caught it,
because i only see the effect for a few seconds at most.  but it's
definitely a significant spike in Committed_AS.

> Then try to build this package in such machine, and it will fail.
>
> I have detected only one other package with a problem like this.
> If you are curious:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848589
>
> Every other package which I tried builds fine with only 20 GB of RAM,
> so this is clearly an anomaly.

I would have guessed that this happens in gpgme due to the C++ library
build which is now part of libgpgme -- i know that g++ and the linker
can both be pretty beastly.  and snap-align is also C++.

however, i did a bit more inspection, and i see these commitments only
during the test suite.  in particular, on a system with 8GiB of RAM, my
RAM commitments moved from a normal level of:

Committed_AS: 7360592 kB

to:

Committed_AS:   108890120 kB

during the execution of tests/gpg/t-thread-keylist-verify.


this test makes 200 threads, 100 of which do a gpg verification
operation, and the other 100 do a keylist operation; that's when the RAM
allocation spikes.

Interestingly, just before that happens is tests/gpg/t-thread-keylist,
which doesn't seem to allocate nearly as much RAM despite being of the
same general form (it just does keylist without the simultaneous verify,
though).

Each thread does spawn an additional gpg process, so there's certainly
memory committments there.  But even with 200 concurrent processes, that
amounts to 0.5GiB of RAM commitments per process, which seems large to
me.

I'm open for suggestions for how to address this.  We could just drop
THREAD_COUNT from 100 to 10 to reduce the RAM consumption, but that
would mean minimizing some of the concurrency that the test suite is
(rightly) trying to judge itself against.  I'd rather not remove those
kinds of checks if we don't need to.

Any suggestions about what the right thing to do is?  

--dkg


signature.asc
Description: PGP signature

Bug#852158: Preseeding debconf/priority causes main menu to display

[Josh Triplett]

On Mon, Jan 23, 2017 at 08:16:02PM +0100, Philip Hands wrote:
> Josh Triplett  writes:
> 
> > On Sun, Jan 22, 2017 at 06:46:14PM +0100, Philip Hands wrote:
> >> Josh Triplett  writes:
> >> > Package: main-menu
> >> > Severity: normal
> >> >
> >> > I'd like to use preseeding to pre-answer some questions in the
> >> > installer, while leaving others for the user to answer, including
> >> > questions asked with priority "high".  Using "auto url=..." sets the
> >> > priority to critical, so I tried including the following in my preseed
> >> > file:
> >> >
> >> > d-i debconf/priority high
> >> 
> >> Not a direct answer to the question you're asking, but you can get what
> >> you want without having to preseed the priority back down again.
> >> 
> >> The 'auto' target is a shortcut that adds priority=critical and
> >> auto=true so if you don't want the priority setting just add 'auto=true'
> >> as well as the url setting to the normal target (IIRC 'install'), so:
> >> 
> >>   install auto=true url=...
> >
> > Yes, I managed to get that working in a VM.  It's longer to type,
> > though. :)
> >
> > More importantly, leaving the priority at "high" for the initial run of
> > netcfg causes it to prompt for hostname and domain before it obtains and
> > loads the preseed file.  Hence wanting to start out at "critical" and
> > then lower the priority after processing the preseed file.
> 
> Good point -- does this perhaps point towards needing to make the
> setting of auto=true delay the asking of the hostname and domain until
> after preseeding, as with the keyboard/locale questions?
> 
> I know it's a bit odd to ask those questions after the network comes up,
> but if one has set auto=true then you either need to set those on the
> command line or in an initrd preseed say, or you need the network to
> come up without them being set, so it makes sense to delay the
> processing of those settings until later -- IIRC this is something that
> is a bit broken anyway, since preseeding the hostname doesn't do what
> one might hope some of the time (unless that's been fixed while I wasn't
> paying attention -- I'm pretty sure it used to be the case that the
> hostname on the target would not be changed if one set these during
> network preseeding).

Yeah, I'd prefer to have those questions deferred until after
preseeding.  That way, for instance, I could preseed the domain but not
the hostname, eliminating one more question.

- Josh Triplett

Bug#852264: gbp buildpackage: doesn't pass options correctly anymore

[Raphaël Halimi]

Le 23/01/2017 à 23:03, James Clarke a écrit :
> On 23 Jan 2017, at 21:58, Raphaël Halimi  wrote:
>> Le 23/01/2017 à 22:51, James Clarke a écrit :
>>> This was a bug introduced in pbuilder 0.228.1. The key thing is that the
>>> GIT_PBUILDER_AUTOCONF=no branch does not specify a BUILDRESULT, so it 
>>> defaults
>>> to /var/cache/pbuilder/result.
>>
>> Yes, but my ~.pbuilderrc does set a BUILDRESULT:
>>
>> BUILDRESULT="/var/cache/pbuilder/result/$NAME"
>>
>> (with $NAME ending up as either sid-amd64, sid-i386, jessie-amd64, etc)
> 
> Ok; doesn't matter what it is, really. If it's anything other than ../ you 
> will
> run into this bug.

Oh, now I understand. Thanks for the clarification.

> It's been fixed in the repository, yes; if you can't wait for an upload, you
> can edit /usr/bin/pdebuild to make the change given by that commit ([1]).

I usually don't like to manually modify anything outside /etc, but I
made an exception to my habit and indeed, it fixed the problem.

Thanks a lot for your work !

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Barry Warsaw]

On Jan 23, 2017, at 04:40 PM, Eli Collins wrote:

>In case this helps the debian package maintainer decide on this patch /
>schedule things, the timestamp problem this addresses is due to a bug in
>the passlib 1.7.0 setup script, which should be fixed in the 1.7.1 upstream
>release (due out next weekend).

Thanks for the status Eli.  If the bug is fixed upstream, I think it makes
sense to just wait until 1.7.1.  Feel free to drop us a ping when that's
available (though I'll eventually notice it anyway).  If Brian doesn't beat me
to it, I'm happy to update to 1.7.1 once it's available.

Bug#822091: libxmlbeans-java: Embeds classes without source

[Emmanuel Bourg]

I got another look at this, and maybe it isn't as bad as we thought. The
piccolo jars in external/lib/ do not contain compiled .class files, but
only .java source files. The xmlbeans build unpacks them to
build/private/piccolo/src, changes the package to
org.apache.xmlbeans.impl.piccolo, and then compiles them.

There are still a few jar files with compiled classes (junit, saxon,
jsr173, oldxbean) but they aren't used to build the package. So this is
more a matter of cleaning the upstream tarball of unnecessary files than
fixing a severe policy violation.

Emmanuel Bourg

Bug#784612: [anki] Qt4's WebKit removal

[Julian Gilbey]

On Mon, Jan 23, 2017 at 10:48:53PM +0100, Nicolas Kuttler wrote:
> On 2017-01-23 21:40, Julian Gilbey wrote:
> > On Wed, Jul 13, 2016 at 07:08:23AM +0200, Nicolas Kuttler wrote:
> > > There are alpha builds with Qt5 available,
> > >
> > > http://ankisrs.net/download/mirror/alpha/
> > >
> > > https://anki.tenderapp.com/discussions/beta-testing/172-anki-210-alpha-1
> > >
> > > https://anki.tenderapp.com/discussions/beta-testing/174-anki-210-alpha-2
> >
> > I have managed to create a working Debian package based on the latest
> > alpha.  Would you like me to send the changes to the collab-maint
> > repository?
> 
> I'm not an Anki dev, just a user, I don't know about their repositories.
> As a Debian user, at the moment I'd rather see Anki removed from Debian.
> It doesn't look like we'll have a usable release before the stretch
> freeze, but by all means, contribute your code upstream. I hope a stable
> Qt5 Anki will appear in backports rather sooner than later.

Hi Nicolas,

This was a comment on the Debian bug report; I'm suggesting uploading
my changes to the Debian anki collab-maint repository.  It's too late
for anki to get into stretch, as we are now in quite deep freeze, and
it has been removed from testing.  But the version I have created,
especially when 2.1.0 has stabilised, should be able to be backported
to backports.  In the meantime, it can be uploaded to unstable (at
least once my new package, python3-send2trash, which is needed by anki
2.1.0, has been processed through the NEW queue; this can also easily
be backported to stretch-backports).

Best wishes,

   Julian

Bug#852369: lintian: [PATCH] add three spelling corrections

[Edward Betts]

Package: lintian
Version: 2.5.50
Severity: wishlist
Tags: patch

---
 data/spelling/corrections | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/data/spelling/corrections b/data/spelling/corrections
index c396355b0..815b200d5 100644
--- a/data/spelling/corrections
+++ b/data/spelling/corrections
@@ -68,6 +68,7 @@ accomadates||accommodates
 accomadating||accommodating
 accomodate||accommodate
 accomodates||accommodates
+accomodation||accommodation
 accompagnied||accompanied
 accompagnies||accompanies
 accompagny||accompany
@@ -1048,6 +1049,7 @@ descryption||description
 descryptions||descriptions
 desctiptor||descriptor
 desctiptors||descriptors
+desgined||designed
 desination||destination
 desinations||destinations
 desireable||desirable
@@ -2397,6 +2399,7 @@ offets||offsets
 offical||official
 officialy||officially
 ofthe||of the
+omiting||omitting
 omitt||omit
 ommited||omitted
 ommiting||omitting
-- 
2.11.0

Bug#846398: GNOME Software catalog entry missing for Hardinfo

[asciiwolf]

The issue has been fixed upstream (https://github.com/lpereira/hardinfo).

Bug#852368: keepassx FTCBFS: runs tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: keepassx
Version: 2.0.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

keepassx fails to cross build from source, because its test suite fails
executing host architecture binaries. The test suite is run despite
setting DEB_BUILD_OPTIONS=nocheck. After honouring the nocheck value,
keepassx cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru keepassx-2.0.3/debian/changelog 
keepassx-2.0.3/debian/changelog
--- keepassx-2.0.3/debian/changelog 2017-01-10 22:33:14.0 +0100
+++ keepassx-2.0.3/debian/changelog 2017-01-23 23:02:26.0 +0100
@@ -1,3 +1,10 @@
+keepassx (2.0.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 23 Jan 2017 23:02:26 +0100
+
 keepassx (2.0.3-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #845163)
diff --minimal -Nru keepassx-2.0.3/debian/rules keepassx-2.0.3/debian/rules
--- keepassx-2.0.3/debian/rules 2016-02-04 21:27:52.0 +0100
+++ keepassx-2.0.3/debian/rules 2017-01-23 23:02:22.0 +0100
@@ -9,9 +9,11 @@
 override_dh_auto_configure:
dh_auto_configure -- -DWITH_GUI_TESTS=ON -DWITH_CXX11=ON
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test:
dh_auto_test -- ARGS+="-E testgui"
xvfb-run -a --server-args="-screen 0 800x600x24" dh_auto_test -- 
ARGS+="-R testgui"
+endif
 
 override_dh_makeshlibs:
# keepassx only ships plugins

Bug#852365: [buildd-tools-devel] Bug#852365: sbuild: append-to-version may overwrite incorrect .buildinfo

[Johannes Schauer]

Hi,

Quoting Vagrant Cascadian (2017-01-23 22:40:13)
> Package: sbuild
> Version: 0.73.0-2
> Severity: normal
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> When building a package, I wanted to test the build and do a
> source-only upload after testing the package:
> 
>   sbuild -d unstable -c sid --arch-all --source-only --run-lintian
> 
> This produced the buildinfo file epoptes_0.5.10-2_amd64.buildinfo.
> 
> Which is awesome! Thanks for the work on supporting buildinfo files!
> Very Exciting!
> 
> 
> Then I ran:
> 
>   sbuild -d UNRELEASED -c sid --arch-all --no-source \
>   --maintainer='Vagrant Cascadian <vagr...@debian.org>' \
>   --append-to-version=~20170123~12.1 epoptes_0.5.10-2.dsc
> 
> It also created epoptes_0.5.10-2_amd64.buildinfo, overwriting the
> .buildinfo created with the build. I would have expected it to
> generate a buildinfo with the --append-to-version appended, rather than
> overwriting the file matching the .dsc's version.

I wouldn't because that's not what dpkg-buildpackage is doing.

See the man page of dpkg-genbuildinfo. The filename of the .buildinfo file is
generated from the source version, not the binary version.

So this bug seems to be a WONTFIX.

Do you agree?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#852264: gbp buildpackage: doesn't pass options correctly anymore

[James Clarke]

On 23 Jan 2017, at 21:58, Raphaël Halimi  wrote:
> Le 23/01/2017 à 22:51, James Clarke a écrit :
>> This was a bug introduced in pbuilder 0.228.1. The key thing is that the
>> GIT_PBUILDER_AUTOCONF=no branch does not specify a BUILDRESULT, so it 
>> defaults
>> to /var/cache/pbuilder/result.
> 
> Yes, but my ~.pbuilderrc does set a BUILDRESULT:
> 
> BUILDRESULT="/var/cache/pbuilder/result/$NAME"
> 
> (with $NAME ending up as either sid-amd64, sid-i386, jessie-amd64, etc)

Ok; doesn't matter what it is, really. If it's anything other than ../ you will
run into this bug.

> I don't quite understand, but if you're saying this is fixed, I can't
> wait for the new version to be uploaded to either sid or experimental.

It's been fixed in the repository, yes; if you can't wait for an upload, you
can edit /usr/bin/pdebuild to make the change given by that commit ([1]).

Regards,
James

[1] 
https://anonscm.debian.org/cgit/pbuilder/pbuilder.git/commit/?id=051e0a634b72528c66fdc5015e1d429608f0bb9f

Bug#852367: wims build-depends on autoconf2.59

[Adrian Bunk]

Source: wims
Version: 1:4.13b~dfsg1-1
Severity: serious

autoconf2.59 is planned to be removed from Debian (see #852235).

wims build-depends on autoconf2.59|autoconf, and the buildds
are only considering the first alternative.

Please change the build dependency from "autoconf2.59|autoconf"
to "autoconf".

Bug#850965: freecad: GNOME Software catalog entry missing

[asciiwolf]

The issue seems to be still present.

Bug#852366: aumix FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: aumix
Version: 2.9.1-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

aumix fails to cross build from source, because it uses the build
architecture pkg-config and thus fails finding gtk. By using the
PKG_PROG_PKG_CONFIG macro, $ac_tool_prefix is properly considered and
the cross build succeeds. Please consider applying the attached patch.

Helmut
diff --minimal -Nru aumix-2.9.1/debian/changelog aumix-2.9.1/debian/changelog
--- aumix-2.9.1/debian/changelog2016-07-19 23:15:12.0 +0200
+++ aumix-2.9.1/debian/changelog2017-01-23 21:50:38.0 +0100
@@ -1,3 +1,10 @@
+aumix (2.9.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: 19_cross.patch (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 23 Jan 2017 21:50:38 +0100
+
 aumix (2.9.1-4) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru aumix-2.9.1/debian/patches/19_cross.patch 
aumix-2.9.1/debian/patches/19_cross.patch
--- aumix-2.9.1/debian/patches/19_cross.patch   1970-01-01 01:00:00.0 
+0100
+++ aumix-2.9.1/debian/patches/19_cross.patch   2017-01-23 21:50:38.0 
+0100
@@ -0,0 +1,27 @@
+From: Helmut Grohne 
+Subject: use triplet-prefixed pkg-config
+
+Index: aumix-2.9.1/configure.ac
+===
+--- aumix-2.9.1.orig/configure.ac
 aumix-2.9.1/configure.ac
+@@ -155,8 +155,8 @@
+   gtk_must=off, gtk_must=on)
+ if test $gtk_must = on; then
+   dnl from gftp 
+-  AC_CHECK_PROG(PKG_CONFIG, pkg-config, yes, no)
+-  if test "$PKG_CONFIG" = "no"; then
++  PKG_PROG_PKG_CONFIG
++  if test -z "$PKG_CONFIG"; then
+ echo "pkg-config not found--compiling without GTK+ 2.0." ; 
+   else
+ echo "pkg-config found--compiling with GTK+ 2.0." ; 
+@@ -181,7 +181,7 @@
+ else
+   AC_MSG_RESULT([Compiling without GTK+ 2.0.])
+ fi
+-AM_CONDITIONAL(GTK, test "$gtk_must" = on && test "$PKG_CONFIG" != "no")
++AM_CONDITIONAL(GTK, test "$gtk_must" = on && test -n "$PKG_CONFIG")
+ 
+ AC_MSG_CHECKING([whether dummy mixer is requested])
+ AC_ARG_ENABLE(dummy-mixer,
diff --minimal -Nru aumix-2.9.1/debian/patches/series 
aumix-2.9.1/debian/patches/series
--- aumix-2.9.1/debian/patches/series   2014-04-30 01:07:31.0 +0200
+++ aumix-2.9.1/debian/patches/series   2017-01-23 21:49:12.0 +0100
@@ -7,3 +7,4 @@
 16_potfiles.patch
 17_zh-tw-po.patch
 18_ncursesw.patch
+19_cross.patch

Bug#784612: [anki] Qt4's WebKit removal

[Nicolas Kuttler]

On 2017-01-23 21:40, Julian Gilbey wrote:
> On Wed, Jul 13, 2016 at 07:08:23AM +0200, Nicolas Kuttler wrote:
> > There are alpha builds with Qt5 available,
> >
> > http://ankisrs.net/download/mirror/alpha/
> >
> > https://anki.tenderapp.com/discussions/beta-testing/172-anki-210-alpha-1
> >
> > https://anki.tenderapp.com/discussions/beta-testing/174-anki-210-alpha-2
>
> I have managed to create a working Debian package based on the latest
> alpha.  Would you like me to send the changes to the collab-maint
> repository?

I'm not an Anki dev, just a user, I don't know about their repositories.
As a Debian user, at the moment I'd rather see Anki removed from Debian.
It doesn't look like we'll have a usable release before the stretch
freeze, but by all means, contribute your code upstream. I hope a stable
Qt5 Anki will appear in backports rather sooner than later.

Bug#852264: gbp buildpackage: doesn't pass options correctly anymore

[Raphaël Halimi]

Le 23/01/2017 à 22:51, James Clarke a écrit :
> This was a bug introduced in pbuilder 0.228.1. The key thing is that the
> GIT_PBUILDER_AUTOCONF=no branch does not specify a BUILDRESULT, so it defaults
> to /var/cache/pbuilder/result.

Yes, but my ~.pbuilderrc does set a BUILDRESULT:

BUILDRESULT="/var/cache/pbuilder/result/$NAME"

(with $NAME ending up as either sid-amd64, sid-i386, jessie-amd64, etc)

I don't quite understand, but if you're saying this is fixed, I can't
wait for the new version to be uploaded to either sid or experimental.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#852226: dgit: Want `dgit setup-maint-merge`

[Sean Whitton]

control: owner -1 !
control: retitle -1 dgit: Want script to setup/update dgit-maint-merge(7) 
source package configuration

Dear Ian,

On Mon, Jan 23, 2017 at 11:30:40AM +, Ian Jackson wrote:
> I'm not comfortable with workflow-specific (and, unless unavoidable,
> Debian-specific) helpers or functions in dgit proper.  This seems to
> me to breach an abstraction layer I conceive of, above dgit.
> [...]
> Also, using `dgit-*' as the name increases the risk that people will
> think that this is _the_ way to use dgit.  This is a perennial
> confusion.  Most people who have not had dgit explained to them assume
> that it is a competitor to gbp or git-dpm or quilt.  (#852090 is a
> typical example of this effect.)
> 
> This proposed subcommand precisely _is_ part of such a competitor.  I
> want dgit to remain completely workflow-ignorant, and as far as
> possible git-management-tool-ignorant.
> [...]

I share these goals, and after reading your message, completely agree
with you that this should definitely not be a dgit subcommand.

> FAOD I am still content for the script to be in the dgit package.

I think that still makes sense because dgit-maint-merge(7) itself is in
the dgit package.

> How about:
>   git deb-maint-merge-prepare
> ?

I don't think that it should be a subcommand of git.  The only git thing
that it will do is `git commit`.  Otherwise, it will do dpkg-source things.

My prototype is ~/bin/maintmerge.  So perhaps just /usr/bin/maintmerge,
or if you are worried about namespacing, debmaintmerge.

But let's leave this for now until I have a better version of the script
(probably Perl since I'm actively trying to learn Perl).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#852264: gbp buildpackage: doesn't pass options correctly anymore

[James Clarke]

Control: tags -1 pending
(I see you already reassigned)

On 23 Jan 2017, at 20:21, Guido Günther  wrote:
> control: tags -1 -unreproducible
> control: gbp buildpackage quotes arguments twice with GIT_PBUILDER_AUTOCONF=no
> 
> On Mon, Jan 23, 2017 at 11:26:44AM +0100, Raphaël Halimi wrote:
>> Le 23/01/2017 à 08:29, Guido Günther a écrit :
 A couples of lines above, I can see:
 
 I: Generating source changes file for original dsc
 dpkg-genchanges: error: unknown option ''-v0.9-1''
>>> 
>>> I'm not seeing double quotes here. We changed quoting in 80a1c39
>>> (0.8.10) so there might be a bug but I can't reproduce this with
>>> pbuilder 0.227 and 0.228.1.
>> 
>> Sorry if I wasn't clear. Those are not double quotes, but two pairs of
>> single quotes.
> 
> I meant doubled quotes - sorry for the confusion ;)
> 
> [..snip..]
>> raph@arche:~/Divers/dev/debian/mine/official/tlp$ DIST=jessie gbp 
>> buildpackage -v0.9-1
>> Building with pbuilder
>> I: Distribution set to jessie (environment variable)
>> I: using pbuilder as pbuilder
>> dpkg-checkbuilddeps: error: Unmet build dependencies: dh-systemd
>> W: Unmet build-dependency in source
>> dh_testdir
>> dh_testroot
>> # add here commands to clean up after the build process.
>> /usr/bin/make clean
>> make[1]: Entering directory '/home/raph/Divers/dev/debian/mine/official/tlp'
>> rm -f tlp tlp-functions tlp-nop tlp-rdw-nm tlp-rdw.rules tlp-rdw-udev tlp-rf 
>> tlp.rules tlp-run-on tlp.service tlp-sleep.service tlp-stat tlp.upstart 
>> tlp-usb-udev
>> make[1]: Leaving directory '/home/raph/Divers/dev/debian/mine/official/tlp'
>> dh_clean
>> dpkg-source: info: using source format '3.0 (quilt)'
>> dpkg-source: info: building tlp using existing ./tlp_0.9.orig.tar.gz
>> dpkg-source: info: building tlp in tlp_0.9-2~bpo8+1.debian.tar.xz
>> dpkg-source: info: building tlp in tlp_0.9-2~bpo8+1.dsc
>> I: Generating source changes file for original dsc
>> dpkg-genchanges: error: unknown option ''-v0.9-1''
>> 
>> Use --help for program usage information.
>> gbp:error: 'BUILDER=pbuilder GIT_PBUILDER_AUTOCONF=no /usr/bin/git-pbuilder 
>> -v0.9-1' failed: it exited with 2
>> ->%-
> 
> That's the difference. You're using 'GIT_PBUILDER_AUTOCONF=no' (which
> then used pbuilder instead of cowbuilder):
> 
> With GIT_PBUILDER_AUTOCONF=no git-pbuilder invokes pdebuild like
> 
>pdebuild --pbuilder cowbuilder --debbuildopts ' '\''-v1.0'\''' -- 
> --hookdir /home/agx/.pbuilder/hooks
> 
> and without GIT_PBUILDER_AUTOCONF=no:
> 
>pdebuild --buildresult ../ --pbuilder cowbuilder --debbuildopts ' 
> '\''-v1.0'\''' -- --hookdir /home/agx/.pbuilder/hooks --basepath 
> /var/cache/pbuilder/tmpbuild//base-sid.cow
> 
> The quoting looks indentical to me so it seems cowbuilder is happy with
> the quoting while pbuilder isn't. I'm cc'ing the the pbuilder
> maintainers for their input since I think pbuilder should accept the
> input (and it did in 0.227). Note that unqoted doesn't work either:
> 
>pdebuild --pbuilder cowbuilder --debbuildopts -v1.0 -- --hookdir 
> /home/agx/.pbuilder/hooks
> 
> which I think it should. Raphaël, could you check if downgrading
> pbuilder 0.227 works for you too.

This was a bug introduced in pbuilder 0.228.1. The key thing is that the
GIT_PBUILDER_AUTOCONF=no branch does not specify a BUILDRESULT, so it defaults
to /var/cache/pbuilder/result. To support backwards compatibility, this ends up
generating *two* _source.changes:

1. *Before* the build in the chroot, using the .dsc generated by dpkg-source.
This is placed in ../ alongside the .dsc. Note that in the normal case,
BUILDRESULT is *also* ../, and so pdebuild skips generating this
_source.changes file, since the .dsc will be replaced by 2.

2. *After* the build in the chroot, if SOURCE_ONLY_CHANGES=yes. This is copied
back to BUILDRESULT.

The second one was fine, but you're hitting the first case. Unfortunately the
two cases were expanding the variables differently; 1. ended up doing less
expansion than 2., so you end up with single quotes not being removed. This has
been fixed in git by [1].

(In case you're wondering, the single quotes get stripped correctly, but when
building up the list of arguments to dpkg-genchanges, they are added around
each, which is why both the final examples you gave have the problem.)

Regards,
James

[1] 
https://anonscm.debian.org/cgit/pbuilder/pbuilder.git/commit/pdebuild?id=051e0a634b72528c66fdc5015e1d429608f0bb9f