Bug#852284: remove unixstuff.net from merchandise page due complains

[Geert Stappers]

Package: www.debian.org
Severity: normal

Hello debian-www people,

Here a posting from a member of debian-events.

There are complains about "unixstuff.net" taking money without sending goods.

Those are report to events AT debian.org as
page https://www.debian.org/misc/merchandise says.

A patch againsst webml is work in progress.
It will be sent to the bugreport.

First are the complains send to justify the removal.



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#852281: Acknowledgement (Please do not make libasound2 dependent on python)

[Michael Biebl]

Control: tags -1 + patch

Am 23.01.2017 um 08:44 schrieb Michael Biebl:

> As smixer seemingly provides only optional functionality, please split
> that out into a libasound-plugins-smixer or similarly named package and
> maybe add a Suggests to libasound2.

Attached is a patch doing that. Thanks for considering.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 4b426c7caa20db6b24a52f2beb001d64eb5880a5 Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Mon, 23 Jan 2017 09:04:26 +0100
Subject: [PATCH] Split off smixer plugin into separate package

Closes: #852281
---
 debian/control  | 10 ++
 debian/libasound-plugins-smixer.install |  1 +
 debian/libasound2.install   |  1 -
 3 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 debian/libasound-plugins-smixer.install

diff --git a/debian/control b/debian/control
index d5b2a60..fd3d040 100644
--- a/debian/control
+++ b/debian/control
@@ -76,3 +76,13 @@ Description: documentation for user-space ALSA application programming
  use ALSA.
  .
  ALSA is the Advanced Linux Sound Architecture.
+
+Package: libasound-plugins-smixer
+Architecture: linux-any
+Depends: libasound2 (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Breaks: libasound2 (<< 1.1.3-1)
+Replaces: libasound2 (<< 1.1.3-1)
+Description: smixer module for ALSA library
+ This package contains the smixer (Simple Mixer) interface for ALSA.
diff --git a/debian/libasound-plugins-smixer.install b/debian/libasound-plugins-smixer.install
new file mode 100644
index 000..38cb7b6
--- /dev/null
+++ b/debian/libasound-plugins-smixer.install
@@ -0,0 +1 @@
+usr/lib/*/alsa-lib/smixer/*.so
diff --git a/debian/libasound2.install b/debian/libasound2.install
index fc0615c..3de3b10 100644
--- a/debian/libasound2.install
+++ b/debian/libasound2.install
@@ -1,2 +1 @@
 usr/lib/*/*.so.*
-usr/lib/*/alsa-lib/smixer/*.so
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#852284: FWD: Complain about unixstuff.net

[Geert Stappers]

- Forwarded message from Giovanni D'Ortenzio -

Date: Mon, 16 Jan 2017 22:16:34 +
From: Giovanni D'Ortenzio
To: Geert Stappers 
Subject: R: Complain about unixstuff.net

https://www.debian.org/misc/merchandise



There you go my friend.

Have a great day



Giovanni



Da: Geert Stappers
Inviato: domenica 15 gennaio 2017 13:05
A: Giovanni D'Ortenzio
Cc: eve...@debian.org
Oggetto: Re: Complain about unixstuff.net



On Sat, Jan 14, 2017 at 09:15:47PM +, Giovanni D'Ortenzio wrote:
> Dear Debian project volunteer,

Hello Giovanni,

> I write to inform you that some weeks ago I completed a purchase from
> one of the websites in your Debian Merchandise page.
> I never received any information about the order status from the
> website support and neither my messages to them were replied.
> I just wanted to inform you because of my love for the Debian project,
> take your choice on wheter removing unixstuff.net from the list or not.

What is the URL of "the list"?


Groeten
Geert Stappers
DD
--
Leven en laten leven

- End forwarded message -

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#820974: bind9 crypto issue

[Arturo Borrero Gonzalez]

On Fri, 20 Jan 2017 07:38:32 -0700 LaMont Jones  wrote:
>
> Can you provide a named.conf that reproduces the issue?
>

file named.conf:

=== 8< ===
include "/etc/rndc/rndc.key";

controls {
inet 1.1.1.1 port 953
allow {
2.2.2.2;
} keys { "rndc-key"; };

inet fe00::1 port 953
allow {
fe00::2;
} keys { "rndc-key"; };
};

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
=== 8< ===

file named.conf.options:

=== 8< ===
acl clients {
10.1.1.1/8;
};

options {
directory "/var/cache/bind";

recursion yes;
allow-query { clients; };

dnssec-validation auto;

auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
=== 8< ===

File named.conf.local and named.conf.default-zones contains nothing
worth mentioning.

Bug#852285: installer broken: multipath-udeb depends on non-existent libmpathcmd udeb

[Allan Jacobsen]

Package: installation-reports

Boot method: PXE (network install)
Image version: 
http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/
Date: 20170123

Machine: Cisco UCSB-B200-M4
Processor: Intel Xeon E5-2660
Memory: 32Gbyte
Partitions: Not found, that is the problem.

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [E]
Detect hard drives: [E]

During multipath install, the installer tries to load dm-emc module
which it should not do, then tries to run /sbin/multipath which gives
the error:

disk-detect: /sbin/multipath: error while loading shared libraries:
libmpathcmd.so.0: cannot open shared object file: No such file or
directory

Bug#852281: Acknowledgement (Please do not make libasound2 dependent on python)

[Michael Biebl]

Am 23.01.2017 um 09:06 schrieb Michael Biebl:
> +Breaks: libasound2 (<< 1.1.3-1)
> +Replaces: libasound2 (<< 1.1.3-1)

This obviously wasn't correct. Assuming the next upload is 1.1.3-2, I've
adjusted that version accordingly in the updated patch.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 5f06017ef3eeff50ff883f1416a84cda8f853045 Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Mon, 23 Jan 2017 09:04:26 +0100
Subject: [PATCH] Split off smixer plugin into separate package

Closes: #852281
---
 debian/control  | 10 ++
 debian/libasound-plugins-smixer.install |  1 +
 debian/libasound2.install   |  1 -
 3 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 debian/libasound-plugins-smixer.install

diff --git a/debian/control b/debian/control
index d5b2a60..f9d194f 100644
--- a/debian/control
+++ b/debian/control
@@ -76,3 +76,13 @@ Description: documentation for user-space ALSA application programming
  use ALSA.
  .
  ALSA is the Advanced Linux Sound Architecture.
+
+Package: libasound-plugins-smixer
+Architecture: linux-any
+Depends: libasound2 (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Breaks: libasound2 (<< 1.1.3-2)
+Replaces: libasound2 (<< 1.1.3-2)
+Description: smixer module for ALSA library
+ This package contains the smixer (Simple Mixer) interface for ALSA.
diff --git a/debian/libasound-plugins-smixer.install b/debian/libasound-plugins-smixer.install
new file mode 100644
index 000..38cb7b6
--- /dev/null
+++ b/debian/libasound-plugins-smixer.install
@@ -0,0 +1 @@
+usr/lib/*/alsa-lib/smixer/*.so
diff --git a/debian/libasound2.install b/debian/libasound2.install
index fc0615c..3de3b10 100644
--- a/debian/libasound2.install
+++ b/debian/libasound2.install
@@ -1,2 +1 @@
 usr/lib/*/*.so.*
-usr/lib/*/alsa-lib/smixer/*.so
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Samuel Thibault  schrieb am 15.01.2017, 15:36 +0100:
>Eric Scheibler, on Fri 13 Jan 2017 13:04:24 +0100, wrote:
>> I'am not absolutely sure about that. Could you upload a new version with a 
>> default value of 20 or
>> even 10 ms just for testing purposes?
>
>I have uploaded packages on https://people.debian.org/~sthibault/tmp/
>which use the value from the ESPEAK_NG_BUFLEN environment variable, i.e.
>you run
>
>ESPEAK_NG_BUFLEN=10 brltty -s es blabla...
>
>to set to 10ms. I don't think it will change much the feeling you have.

You were right - it doesn't change much if at all.

Bug#852284: Your List form merchandise.de.html

[Geert Stappers]

On Sun, Jan 22, 2017 at 12:31:37AM +0100, Joost van Baal-Ili?? wrote:
> Hi events,
> 
> Someone from events@ should have a look at this.  I myself _might_ get to it, 
> soonish,
> I hope...

Work in progress at https://bugs.debian.org/852284
 

> Bye,
> Joost
> 
> 
> On Tue, Jan 10, 2017 at 11:34:31AM +0100, Steffen T wrote:
> > Hello,
> > 
> > I checked your list of official merch here (
> > https://www.debian.org/misc/merchandise.de.html) and orderd from
> > http://www.unixstuff.net/
> > 
> > Unfortunatly it seems like this store just collects money and don't send
> > anything. Please also review their facebook page, a lot of people didn't
> > get anything.
> > https://www.facebook.com/Unixstuffnet-Linux-Store-501743496530751
> > 
> > People (me included) think that this is an official list. Please get in
> > contact with http://www.unixstuff.net/ what they're doing right now or
> > remove the shop from the list - if a bad seller is on your merch list it
> > has a very bad influence in this marvelous projekt.
> > 
> > Kind regards,
> > Steffen

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#852262: RM: kicad [mips64el s390x] -- ANAIS; no longer built on mips64el and s390x

[Emilio Pozuelo Monfort]

Control: retitle -1 RM: kicad-common [all] -- ANAIS; arch:all pkg now arch:any

On Mon, 23 Jan 2017 00:41:47 +0200 Adrian Bunk  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> 
> kicad (4.0.5+dfsg1-3) unstable; urgency=medium
> 
>   [ Carsten Schoenert ]
>   * [1835f2e] debian/control: decrease Architectures for arch packages
> + minimize the platform where kicad should be build, libboost-context-dev
>   isn't on all platforms available

That's not the problem, kicad didn't build on mips64el or s390x before. The
issue is the old kicad-common_4.0.5+dfsg1-1_all package.

Cheers,
Emilio

Bug#839695: 67 X11/GTK related packages on a headless server

[Michael Tokarev]

23.01.2017 10:55, Rob J. Epping wrote:
> Hi,
> 
> qemu 1:2.8+dfsg-1 has hit jessie-backorts.
> 
> With the fix for bug #839695 my server now wants to install 67 X11/GTK
> related new packages. This is on a headless server where this is just
> more atack surface, i.e. less security.
> 
> Would it be possible to make the X11/GTK stuff optional? Maybe by
> creating 2 binary versions for example a -gtk and a -nox version.

Please see #813658 .

In brief, being a 20+ years paranoic sysadmin myself, I don't see it
being a security treat. Either we fix all needed X client libs to
not depend on X itself (ie, being split into a headless and headful
part), or we live with this.

People want features even on a headless server (eg, 3d support via
spice), -- this will bring half of X anyway. So making just display
optional doesn't work.

Thanks,

/mjt

Bug#852284: webml patch to remove unixstuff from merchandise list

[Geert Stappers]

Control: tag -1 patch

The actual patch, twice.
Once in-line and once attachet.

Index: english/misc/merchandise.data
===
RCS file: /cvs/webwml/webwml/english/misc/merchandise.data,v
retrieving revision 1.68
diff -u -r1.68 merchandise.data
--- english/misc/merchandise.data   29 Nov 2016 11:12:17 -  1.68
+++ english/misc/merchandise.data   23 Jan 2017 08:21:45 -
@@ -122,11 +122,14 @@
   >
 
 
-
-  
-  http://www.unixstuff.net/";>
-  , >
-
+# disabled due complains, 2017-01-21
+#  Unixstuff takes money, but does NOT sent goods
+#  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852284
+# 
+#   
+#   http://www.unixstuff.net/";>
+#   , >
+# 
 
 
 # disable, shop has no products currently (2016/09/17)
Index: english/misc/merchandise.data
===
RCS file: /cvs/webwml/webwml/english/misc/merchandise.data,v
retrieving revision 1.68
diff -u -r1.68 merchandise.data
--- english/misc/merchandise.data	29 Nov 2016 11:12:17 -	1.68
+++ english/misc/merchandise.data	23 Jan 2017 08:21:45 -
@@ -122,11 +122,14 @@
   >
 
 
-
-  
-  http://www.unixstuff.net/";>
-  , >
-
+# disabled due complains, 2017-01-21
+#  Unixstuff takes money, but does NOT sent goods
+#  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852284
+# 
+#   
+#   http://www.unixstuff.net/";>
+#   , >
+# 
 
 
 # disable, shop has no products currently (2016/09/17)


signature.asc
Description: Digital signature

Bug#824420: python-phply: Building with DEB_BUILD_OPTIONS="nocheck" causes parsetab.py not to be included

[Gianfranco Costamagna]

Control: fixed -1 1.0.0-1
Control: close -1

Seems fixed/addressed in 1.0.0

G.



signature.asc
Description: OpenPGP digital signature

Bug#852286: [l10n] Updated Belarusian translation of grub2 debconf messages

[Viktar Siarheichyk]

Package: grub2
Severity: wishlist
Tags: l10n, patch

Hi,

in attachement there is updated Belarusian (be.po) translation of
grub2 debconf messages. Please include it with the package.

Thank you


be.po
Description: Binary data

Bug#847292: proot: diff for NMU version 5.1.0-1.2 (was: proot misses the "binary loader size" fix)

[Simon McVittie]

On Sat, 14 Jan 2017 at 16:23:44 +, Simon McVittie wrote:
> I've prepared an NMU for proot (versioned as 5.1.0-1.2) and
> uploaded it to DELAYED/7.

This has reached unstable, but doesn't seem to have reset the countdown
for autoremoval from testing. Hopefully this mail will. If not, I'll
contact the release team later in the week.

S

Bug#852253: kryo-serializers: FTBFS (Cannot access central (https://repo.maven.apache.org/maven2) in offline mode)

[Emmanuel Bourg]

Hi Santiago,

I think this is a duplicate of #851037, it'll be fixed today once
libkryo-java/2.20-6 migrates to testing.

Emmanuel Bourg

Bug#852276: libfltk1.3-dev: Fix FLTK-Targets-noconfig.cmake libdir

[Javier Serrano Polo]

This new patch fixes shared library names; it supersedes the previous
patch. Now configuration can finish.
--- fltk1.3-1.3.4.orig/debian/fix-fltk-targets-noconfig	2015-08-18 15:34:34.0 +0200
+++ fltk1.3-1.3.4/debian/fix-fltk-targets-noconfig	2017-01-23 09:59:06.0 +0100
@@ -3,9 +3,10 @@
 
 my $to_untag = '';
 while (<>) {
-s,(\${_IMPORT_PREFIX}/lib),$1/$ENV{DEB_HOST_MULTIARCH},g;
+s,(\${_IMPORT_PREFIX}/lib)(?!/$ENV{DEB_HOST_MULTIARCH}),$1/$ENV{DEB_HOST_MULTIARCH},g;
 s,\.so\.1\.3\.\d*,\.so,g;
 s,([^a-z]fltk\w*(?

smime.p7s
Description: S/MIME cryptographic signature

Bug#850632: openuniverse: fails to start "input in flex scanner failed

[Petter Reinholdtsen]

Control: tags -1 + patch

[Petter Reinholdtsen]
> I guess the install target for the configuration file is bad.

The problem seem to be that autoconf/automake have changed behaviour, breaking
the old install target in conf/Makefile.am in combination with the symlinks
created by dh.

The following patch fixes the miscompile, but do not solve the upgrade
problem caused by the fact that /etc/openuniverse.conf/ is a directory
in existing versions and not a configuration file.  The idea is to
make sure 'make install' do not see the symlink in /usr/share/ and install
the file as before, and after install the file is moved to /etc/ and replaced
by a symlink.

After removing the /etc/openuniverse.conf/ directory and I install the new debs
and run the program.

-- 
Happy hacking
Petter Reinholdtsen
diff -u openuniverse-1.0beta3.1+dfsg/debian/changelog openuniverse-1.0beta3.1+dfsg/debian/changelog
--- openuniverse-1.0beta3.1+dfsg/debian/changelog
+++ openuniverse-1.0beta3.1+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+openuniverse (1.0beta3.1+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * fix wrong location for conf file
+
+ -- Petter Reinholdtsen   Mon, 23 Jan 2017 09:32:33 +0100
+
 openuniverse (1.0beta3.1+dfsg-5) unstable; urgency=low
 
   * debian/rules:
diff -u openuniverse-1.0beta3.1+dfsg/debian/openuniverse.install openuniverse-1.0beta3.1+dfsg/debian/openuniverse.install
--- openuniverse-1.0beta3.1+dfsg/debian/openuniverse.install
+++ openuniverse-1.0beta3.1+dfsg/debian/openuniverse.install
@@ -4 +4,2 @@
-usr/share/openuniverse/conf/ou.conf /etc/openuniverse.conf
+etc/openuniverse.conf
+usr/share/openuniverse/conf/ou.conf
diff -u openuniverse-1.0beta3.1+dfsg/debian/openuniverse.links openuniverse-1.0beta3.1+dfsg/debian/openuniverse.links
--- openuniverse-1.0beta3.1+dfsg/debian/openuniverse.links
+++ openuniverse-1.0beta3.1+dfsg/debian/openuniverse.links
@@ -1,2 +1 @@
-/etc/openuniverse.conf /usr/share/openuniverse/conf/ou.conf  
 /usr/share/openuniverse/docs /usr/share/doc/openuniverse/manual
diff -u openuniverse-1.0beta3.1+dfsg/debian/rules openuniverse-1.0beta3.1+dfsg/debian/rules
--- openuniverse-1.0beta3.1+dfsg/debian/rules
+++ openuniverse-1.0beta3.1+dfsg/debian/rules
@@ -22,6 +22,12 @@
 override_dh_auto_build:
 	CXXFLAGS="-I/usr/include/plib/" LIBS="-lplibfnt -lplibul -lglut" ./configure --prefix= --exec_prefix=/usr --mandir=\$${exec_prefix}/share/man --infodir=\$${exec_prefix}/share/info --sysconfdir=\$${prefix}/etc/ --includedir=\$${exec_prefix}/include --datadir=\$${exec_prefix}/share
 	$(MAKE)
+override_dh_auto_install:
+	dh_auto_install
+	mkdir `pwd`/debian/tmp/etc
+	mv `pwd`/debian/tmp/usr/share/openuniverse/conf/ou.conf \
+	  `pwd`/debian/tmp/etc/openuniverse.conf
+	ln -s /etc/openuniverse.conf debian/tmp/usr/share/openuniverse/conf/ou.conf
 
 
 override_dh_fixperms-arch:

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

[Ondřej Surý]

Niels,

do you think this might get resolved in time to make the freeze
deadline? I would like to enter freeze with up-to-date PHP version, so I
don't have to upload to testing-security right away ;)

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Sun, Jan 22, 2017, at 08:37, Niels Thykier wrote:
> Sebastian Andrzej Siewior:
> > On 2017-01-20 21:36:00 [+], Niels Thykier wrote:
> >> Hi Ondřej,
> >>
> >> Sorry for being the "messenger" triggering this issue in php7.0.
> >>
> >> Kurt/Sebastian, what are you recommendations here?  Should we migrate
> >> net-snmp itself to ssl1.1 (possibly with all of its rdeps) or can we
> >> detangle net-snmp and php7 from each other in a graceful manner?
> > 
> > [...] I grep the deps [0] and didn't find a user of
> > cert_util.h so it looks like nobody cares about that.
> > 
> 
> Thanks. :)
> 
> Codesearch also appears to agree with this (assuming we are only looking
> at rdeps). :)  Internally, snmp appears to have a few uses of it.
> 
> > 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
> 
>  * 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 will try to make that change tomorrow and rebuild the packages [0].
> > 
> > [...]
> 
> Thanks.  Let me know how it goes.  I am happy to do the upload if your
> test says go and you can provide me with the "#if"-guard.  (apparently,
> net-snmp also needs an unrelated patch for pie - see #852023)
> 
> 
> Thanks,
> ~Niels
> 
> 

Bug#852287: terminix: Terminix should provide x-terminal-emulator

[Jonathan Carter]

Package: terminix
Version: 1.3.0-5
Severity: normal
Tags: newcomer

Dear Maintainer,

Please consider adding the following line to debian/control:

Provides: x-terminal-emulator

Currently, if terminix is intended to be the only terminal emulator on the 
system,
packages which depend on x-terminal-emulator will result in an additional 
terminal
emulator being installed.

Thanks,

-Jonathan

Bug#261415: network installation always asks for proxy

[Philip Hands]

Josh Triplett  writes:

> On Fri, 28 Feb 2014 23:49:59 +0100 Cyril Brulebois  wrote:
>> Martin Pitt  (2004-03-24):
>> > - network installation always asks for proxy; I know what a proxy is,
>> >   but not all potential users may; would it be possible to try without
>> >   proxy first and ask for proxy settings only if direct connection
>> >   does not work?  Never mind if that is not possible, just asking :-)
>> 
>> Some translations have a less-techy way of explaining what a proxy is,
>> and a default empty value should just be OK (people are expected to
>> install Debian by pressing Enter most of the time, right? :)). I'm not
>> sure we want to play with trial-and-error in d-i too much…
>> 
>> Tagging wontfix for now to allow for somebody to step up and say
>> otherwise.
>
> I do think we ought to attempt autodetection for this.  As long as a
> means exists for preseeders and expert installs to specify one anyway
> (for optional caching proxies), autodetecting by default seems like a
> good idea, to eliminate one of the more highly technical questions in
> the install.

I've certainly been behind site-wide filtering that plays badly with
package downloads, where someone in the IT department has routed round
that by setting up a secret ADSL line that can be used if one specifies
a proxy using IP:port that's scribbled on the office whiteboard.

I suspect that pretty-much any test you can think of will result in you
going via the filter, and thus getting really dire download rates (In
the case I'm thinking of ~20kbits/s on a 10Gbit/s line, out-of-hours --
the filter was also not caching its own results, so it didn't even speed
up for subsequent downloads)

Making it difficult to perform a test install on such a site will drive
new users elsewhere.

Of course, incomprehensible questions will also drive users elsewhere,
so we need to make sure that people understand that they almost
certainly don't care, unless they already know that they do care.

I could imagine using auto-detection to populate default values for a
site's proxy, assuming that the software to achieve that has a decent
chance of success, and isn't too big.

Alternatively, one could make sure that the subsequent package download
progress page made it clear that it would be safe to cancel that, and
that doing so would let one back up and specify a proxy to go via and
then retry the install -- that would let the person looking at a
download that's going depressingly slowly plenty of time to remember
that they have a faster alternative, and the reassurance that they can
switch to it without having to start the install from scratch (assuming
we can get the code to work that way).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850940: fixed in xorg-server 2:1.19.1-1

[MAG4 Piemonte]

Hi, upgrading to version 1.19.1-1 solve the problem.
Thank you and regards!

Guido

Bug#846389: plasma-workspace: random plasmashell freezes

[MAG4 Piemonte]

Hi, upgrading to version 1.19.1-1 solve the problem ...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850940
Regards!

Guido

Bug#826069: [Debichem-devel] Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

[Michael Banck]

tags 826069 +help
thanks

On Mon, Jan 23, 2017 at 08:12:53AM +0100, Petter Reinholdtsen wrote:
> [Carlo Segre]
> > When installed from sid, ghemical will only render in greyscale instead of 
> > color.  In addition, building a molecule atom-by-atom is not functional.
> > 
> > In order to get ghemical working again, I have to revert to the wheezy 
> > version
> > as there is no version available in jessie.
> 
> This RC bug will cause ghemical to be removed from Stretch in a few days.  Is 
> there
> any hope for a fix in time to rescue it?

Well, any help is welcome, but at least I haven't had time to look at
it.

Do you need ghemical as part of debian-edu or something?  Maybe we can
discuss alternatives in this case?


Michael

Bug#850889: suricata: Inconsistent behaviour between .init and .service

[Arturo Borrero Gonzalez]

On 22 January 2017 at 23:41, Christoph Biedl
 wrote:
> Arturo Borrero Gonzalez wrote...
>
>> do you have any other comment?
>
> I didn't get your message. Please check
> https://lists.debian.org/debian-devel/2016/12/msg00613.html
> So I found your answers rather by coincidence.
>
>> Thinking again about this, how have you find the inconsistency you are
>> referring to?
>> I mean, In which form does this affects users? Were you migrating your
>> system from sysvinit to systemd?
>
> This was an upgrade, I cannot check the version numbers right now.
> I guess you introduced the service file rather recently?
>

Yes, true. In version 3.1.1-1 dated back in 25 Jul 2016.

> However, after that upgrade the daemon was silently started, put eth0
> into promiscuous mode which was quite a bad idea in that very
> configuration. I'll check again in a few days.
>

So, the problem then is upgrading from a sysvinit based debian to a
systemd based one.

Bug#851647: hypersan: upstream v4.4 and 'fat runtime' vs suricata

[Arturo Borrero Gonzalez]

On 20 January 2017 at 15:33, Sascha Steinbiss  wrote:
>
> BTW, It hasn't escaped our notice that there is a new
> 'hs_valid_platform()' function in Hyperscan 4.4 which checks at runtime
> whether the executing CPU has SSSE3 support. This may help to no longer
> require a Hyperscan-specific Debian package for Suricata: if Suricata
> could check at runtime whether Hyperscan can be used -- and fall back to
> the classic BM/AC matchers if not -- we can just depend on and use
> libhyperscan4 for all archs on which Hyperscan is available by default.
> I wonder what your thoughts are?

That sounds more elegant than our current implementation. I would go this way.

> To test this, I have started working on a proof-of-concept patch
> for Suricata to do exactly that. Upstream might be interested as well?
>

I guess so! yes! That would be great indeed :-)

>>> It looks like there probably isn't going to be much friction w.r.t. this
>>> new version, assuming that the release won't diverge a lot any more from
>>> the current upstream 'develop' branch.
>>
>> Thanks for your work Sascha, it's really appreciated :-)
>
> Always happy to help. As you might have noticed, the 4.4 release was
> just accepted into unstable.
>

yeah! thanks!

Bug#850997: [Android-tools-devel] Bug#850997: android-platform-tools-base: FTBFS: InstantRunVerifier.java:172: error: method diffList in class InstantRunVerifier cannot be applied to given types;

[Hans-Christoph Steiner]

There is always hope!  The best way to ensure that this gets updated is
to find people to join in the effort.  We have an update to
android-platform-tools-base underway, but there is still quite a bit to
be done.  I think we have all the dependencies needed for updating this
to 2.2.2 complete, we just need to get the final
android-platform-tools-base 2.2.2 done.  And the core team does not have
much time to spare these days.  The work that needs doing is Java/gradle
building.

.hc

Bug#806037: [Debian GNUstep maintainers] Bug#806037: gnumail: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[gurkan]

On 22.01.2017 14:35, Andreas Beckmann wrote:

On 2017-01-22 09:30, Gürkan Myczko wrote:

ahm no wait this one is not good i think.


OK, cancelled.


A sorry Andreas and Eric, of course Erics git update of GNUmail is 
fine. Please upload it again with no delayed.

I got it wrong, sorry about the mistake.

Yours,

Bug#852288: Data corruption when multiple threads are allowed and copyonwrite is enabled

[Wouter Verhelst]

Package: nbd-server
Version: 1:3.12-0
Severity: grave
Tags: upstream
Forwarded: https://github.com/NetworkBlockDevice/nbd/issues/43

There's a data corruption bug in nbd which has existed since the
upstream release of 3.12. We should not release nbd in stretch with that
bug.

I have a preliminary fix, but it needs some testing. However, I'm
currently swamped with other work, and this has gone to the backburner a
bit. Since I don't want to forget about this issue, filing a bugreport
in the Debian BTS should help.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages nbd-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-9
ii  libglib2.0-0   2.50.2-2
ii  libgnutls303.5.8-1
ii  ucf3.0036

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded

Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Dhole]

Source: python-passlib
Version: 1.7.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed that
python-passlib could not be built reproducibly.

The version string of the package includes a timestamp that is generated at
build time.

The attached patch fixes this by using SOURCE_DATE_EPOCH as the timestamp for
the version string. Once applied, python-passlib can be built reproducibly in
our current experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds

Regards,
-- 
Dhole
diff -Nru python-passlib-1.7.0/debian/changelog 
python-passlib-1.7.0/debian/changelog
--- python-passlib-1.7.0/debian/changelog   2016-11-28 17:31:28.0 
+0100
+++ python-passlib-1.7.0/debian/changelog   2017-01-23 10:36:30.0 
+0100
@@ -1,3 +1,11 @@
+python-passlib (1.7.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use date from SOURCE_DATE_EPOCH for version number to make the build
+reproducible. 
+
+ -- red   Mon, 23 Jan 2017 10:36:30 +0100
+
 python-passlib (1.7.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-passlib-1.7.0/debian/patches/reproducible-version-name.patch 
python-passlib-1.7.0/debian/patches/reproducible-version-name.patch
--- python-passlib-1.7.0/debian/patches/reproducible-version-name.patch 
1970-01-01 01:00:00.0 +0100
+++ python-passlib-1.7.0/debian/patches/reproducible-version-name.patch 
2017-01-23 10:36:30.0 +0100
@@ -0,0 +1,20 @@
+Description: Generate a reproducible version name
+ Use date from SOURCE_DATE_EPOCH for version number to make the build
+ reproducible.
+Author: red 
+
+
+Index: python-passlib-1.7.0/setup.py
+===
+--- python-passlib-1.7.0.orig/setup.py
 python-passlib-1.7.0/setup.py
+@@ -58,7 +58,8 @@ if os.environ.get("PASSLIB_SETUP_TAG_REL
+ stamp = stamp.decode("ascii")
+ except (OSError, subprocess.CalledProcessError):
+ # fallback - just use build date
+-stamp = time.strftime("%Y%m%d%H%M%S")
++build_date = int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++stamp = time.strftime("%Y%m%d%H%M%S", time.gmtime(build_date))
+ 
+ # modify version
+ if version.endswith((".dev0", ".post0")):
diff -Nru python-passlib-1.7.0/debian/patches/series 
python-passlib-1.7.0/debian/patches/series
--- python-passlib-1.7.0/debian/patches/series  2016-11-28 17:31:28.0 
+0100
+++ python-passlib-1.7.0/debian/patches/series  2017-01-23 10:36:30.0 
+0100
@@ -1 +1,2 @@
 0001-Disable-Django-support.patch
+reproducible-version-name.patch

Bug#851016: beets: diff for NMU version 1.3.19-2.1

[Simon McVittie]

Control: tags 851016 + patch
Control: tags 851016 + pending

Dear maintainer,

I've prepared an NMU for beets (versioned as 1.3.19-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
S
diffstat for beets-1.3.19 beets-1.3.19

 changelog  |   14 
 control|4 
 patches/Test-true-FLAC-bitrate-from-Mutagen-1.35.patch |   24 +
 patches/mediafile-Cleanup-mutagen-error-handling.patch |  241 +
 patches/series |2 
 5 files changed, 283 insertions(+), 2 deletions(-)

diff -Nru beets-1.3.19/debian/changelog beets-1.3.19/debian/changelog
--- beets-1.3.19/debian/changelog	2016-08-30 06:07:14.0 +0100
+++ beets-1.3.19/debian/changelog	2017-01-23 09:41:08.0 +
@@ -1,3 +1,17 @@
+beets (1.3.19-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/mediafile-Cleanup-mutagen-error-handling.patch:
+Add patch backported from upstream to update exception handling for
+python-mutagen >= 1.33. This fixes a test failure and
+FTBFS (Closes: #851016)
+  * d/p/Test-true-FLAC-bitrate-from-Mutagen-1.35.patch:
+Add patch backported from upstream to fix a failing test with
+python-mutagen >= 1.35
+- d/control: depend and build-depend on a compatible version
+
+ -- Simon McVittie   Mon, 23 Jan 2017 09:41:08 +
+
 beets (1.3.19-2) unstable; urgency=medium
 
   * Fix occasional FTBFS due to lack of mock cleanup. Thanks Santiago Vila.
diff -Nru beets-1.3.19/debian/control beets-1.3.19/debian/control
--- beets-1.3.19/debian/control	2016-08-30 04:40:16.0 +0100
+++ beets-1.3.19/debian/control	2017-01-23 09:41:08.0 +
@@ -17,7 +17,7 @@
  python-mpd,
  python-munkres,
  python-musicbrainzngs (>= 0.4),
- python-mutagen (>= 1.27),
+ python-mutagen (>= 1.35),
  python-pathlib,
  python-pylast,
  python-rarfile,
@@ -41,7 +41,7 @@
  libjs-underscore,
  python-enum34,
  python-musicbrainzngs (>= 0.4),
- python-mutagen (>= 1.21),
+ python-mutagen (>= 1.35),
  python-pkg-resources,
  ${misc:Depends},
  ${python:Depends}
diff -Nru beets-1.3.19/debian/patches/mediafile-Cleanup-mutagen-error-handling.patch beets-1.3.19/debian/patches/mediafile-Cleanup-mutagen-error-handling.patch
--- beets-1.3.19/debian/patches/mediafile-Cleanup-mutagen-error-handling.patch	1970-01-01 01:00:00.0 +0100
+++ beets-1.3.19/debian/patches/mediafile-Cleanup-mutagen-error-handling.patch	2017-01-23 09:41:08.0 +
@@ -0,0 +1,241 @@
+From: Christoph Reiter 
+Date: Mon, 27 Jun 2016 09:43:48 +0200
+Subject: mediafile: Cleanup mutagen error handling
+
+Instead of the individial mutagen format exceptions use the
+mutagen.MutagenError exception introduced in 1.25.
+
+Since 1.33 mutagen will only raise MutagenError for load/save/delete
+and no longer raise IOError. Translate both errors to UnreadableFileError
+to support older and newer mutagen versions. Unify error handling
+in __init__(), save() and delete().
+
+Since it's no longer possible to get an IOError from MediaFile, adjust
+all callers and tests accordingly.
+
+This was tested with mutagen 1.27 and current mutagen master.
+
+[smcv: backported to 1.3.19 by replacing six.text_type with unicode]
+
+Origin: upstream, 1.4.1, commit:629241efd389bea7b4075f2591a06f2ef462dc82
+---
+ beets/library.py   |  8 +++
+ beets/mediafile.py | 65 +++---
+ beetsplug/scrub.py | 13 ++
+ test/test_mediafile.py | 23 +-
+ 4 files changed, 64 insertions(+), 45 deletions(-)
+
+diff --git a/beets/library.py b/beets/library.py
+index 3450a35a..70fff1a7 100644
+--- a/beets/library.py
 b/beets/library.py
+@@ -25,7 +25,7 @@ import re
+ from unidecode import unidecode
+ 
+ from beets import logging
+-from beets.mediafile import MediaFile, MutagenError, UnreadableFileError
++from beets.mediafile import MediaFile, UnreadableFileError
+ from beets import plugins
+ from beets import util
+ from beets.util import bytestring_path, syspath, normpath, samefile
+@@ -560,7 +560,7 @@ class Item(LibModel):
+ read_path = normpath(read_path)
+ try:
+ mediafile = MediaFile(syspath(read_path))
+-except (OSError, IOError, UnreadableFileError) as exc:
++except UnreadableFileError as exc:
+ raise ReadError(read_path, exc)
+ 
+ for key in self._media_fields:
+@@ -607,14 +607,14 @@ class Item(LibModel):
+ try:
+ mediafile = MediaFile(syspath(path),
+   id3v23=beets.config['id3v23'].get(bool))
+-except (OSError, IOError, UnreadableFileError) as exc:
++except UnreadableFileError as exc:
+ raise ReadError(self.path, exc)
+ 
+ # Write the tags to the file.
+ mediafile.update(item_tags)
+ try:
+ mediafile.save()
+-e

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

[Maarten van Gompel]

Hi Andreas,

Thanks for your elaborate response! It seems this has indeed opened quite a can
of worms.. Here we go:

Quoting Andreas Beckmann (2017-01-22 22:27:08)
> TL;DR: You have an ambitious task before you.

So I see...

> Let me see if I understand what's going on.
>
> Renaming conffiles and changing the owning package at the same time is a
> PITA.
> You add an extra point by making the old name a symlink to the new one,
> owned by the new package
>
> In jessie, everything in /etc/ucto was owned by ucto.
> In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata
> or libucto2, a m-a:same library package. These come from 2 different
> source packages.

Indeed..

> Yuck. While putting conffiles in m-a:same packages is allowed, I highly
> discourage this. Even if I haven't seen this fail once, yet. I'm just
> afraid, someone has to clean up a mess caused by this at some point in
> the future. and I'm afraid, I won't keep my fingers out of then :-(

Ok, we'll come back to this in your later suggestion to move the conffiles to a
new package.

> Before we start: Are these really conffiles? Supposed to be modified by
> the local admin? Or are these rather data files that are not supposed to
> be updated locally? And would better live in /usr/share in that case?

You have a point there; the user MAY add a new configuration or modify an
existing one, but it is indeed not something that NEEDS to be modified to run. 
You may be right that
/usr/share might be better here. I'd have to discuss with the main upstream
developer, but I think we're not opposed to such 'radical' solutions if that
solves the packaging problems and makes more semantic sense anyway.
What do you think is best for the short term to get this fixed before the
freeze?

> And nearly everything from jessie's /etc/ucto content is now renamed and
> a symlink.

> Can't you just fork the project? I'd suggest 'hpgb' and then use
> /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new
> source packages ...
>
> Oh yeah, it well be a mess. But we will do it right. Including making
> dpkg forget about the old conffiles.
>
> Right now, all upgrade attempts from jessie to stretch should always
> have failed, so there is no further messed up state inbetween that
> should be supported for clean upgrades.

Right

> can we move the conffiles from libucto2 to a new package, e.g.
> ucto-common (which would be either m-a:foreign or m-a:allowed, but I
> always mess up these two, I need to look up what's right?

Okay, that sounds good to me, if there's no objection to having yet another
package.

> * Which version introduced the new layout?
> * can you give me a list of
>   + removed conffiles
>   + renamed conffiles (old name, new name, new owning package, whether
> they have a compat symlink, did the content change between jessie and sid)

ucto 0.9.2 introduced the split into uctodata. The jessie version is very old: 
0.5.3-3.1
The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata 
package:

 config/es.abr
 config/exotic-eos.eos
 config/exotic-quotes.quote
 config/ligatures.filter
 config/nl_afk.abr
 config/pt.abr  (not in jessie version)
 config/tokconfig-de
 config/tokconfig-en
 config/tokconfig-es
 config/tokconfig-fr
 config/tokconfig-fy
 config/tokconfig-it
 config/tokconfig-nl
 config/tokconfig-nl-sonarchat
 config/tokconfig-nl-twitter
 config/tokconfig-nl-withplaceholder(not in jessie version)
 config/tokconfig-pt(not in jessie version)
 config/tokconfig-ru(not in jessie version)
 config/tokconfig-sv
 config/tokconfig-tr(not in jessie version)

The following remained in ucto 0.9.2 (libucto2)
 
 config/e-mail.rule
 config/smiley.rule
 config/url.rule
 config/standard-eos.eos(not in jessie version)
 config/standard-quotes.quote   (not in jessie version)
 config/tokconfig-generic   (not in jessie version)

The very latest uctodata 0.3.1-1 introduces the new naming scheme for the 
language
codes:

 config/tokconfig-de -> config/tokconfig-deu
 config/tokconfig-en -> config/tokconfig-eng
 config/tokconfig-es -> config/tokconfig-spa
 config/tokconfig-fr -> config/tokconfig-fra
 config/tokconfig-fy -> config/tokconfig-fry
 config/tokconfig-it -> config/tokconfig-ita
 config/tokconfig-nl -> config/tokconfig-nld
 config/tokconfig-nl-sonarchat -> config/tokconfig-nld-sonarchat
 config/tokconfig-nl-twitter -> config/tokconfig-nld-twitter
 config/tokconfig-nl-withplaceholder(not in jessie version)   -> 
config/tokconfig-nld-withplaceholder
 config/tokconfig-pt(not in jessie version)   -> 
config/tokconfig-por
 config/tokconfig-ru(not in jessie version)   -> 
config/tokconfig-rus
 config/tokconfig-tr(not in jessie version)   -> 
config/tokconfig-tur
 config/tokconfig-sv -> config/tokconfig-swe

At that point we decided to symlink from  the old 

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Alberto Garcia]

On Sat, Jan 21, 2017 at 09:17:55AM +0100, Emilio Pozuelo Monfort wrote:

> > By the way, nearly exactly the same error happens on mips:
> 
> Huh? mips built fine:
> 
> https://buildd.debian.org/status/package.php?p=webkit2gtk&suite=sid
> 
> Can you explain what you mean?

webkit2gtk itself builds fine, seed-webkit2 is what fails:

https://buildd.debian.org/status/package.php?p=seed-webkit2&suite=sid

I'll see if I have time to check it later, but it indeed looks like a
regression.

Berto

Bug#850632: openuniverse: fails to start "input in flex scanner failed

[Javier Fernandez-Sanguino]

On 23 January 2017 at 10:19, Petter Reinholdtsen  wrote:

> Control: tags -1 + patch
>
> [Petter Reinholdtsen]
> > I guess the install target for the configuration file is bad.
>
> The problem seem to be that autoconf/automake have changed behaviour,
> breaking
> the old install target in conf/Makefile.am in combination with the symlinks
> created by dh.
>

Thank you for investigating the issue Petter. I will try to make an upload
with this fix tonight.

Regards

Javier

Bug#659102: Problem with the apache resource solved

[Christoph Berg]

Version: 1:3.9.6-1

Re: Michal Vyoral 2012-02-22 <20120222141253.gd2...@osit-vyoral.chmi.cz>
> Hello,
> I have solved the problem by adding the parameter
> 
>   statusurl="http://127.0.0.1/server-status";

Re: Harald Dunkel 2012-08-01 <5018d7fc.9000...@aixigo.de>
> Explicitly setting the statusurl is a workaround, but it
> doesn't fix the problem.
> 
> The problem is that the apache resource script fails to
> guess the server-status url from the config file. It uses
> 
>   http://localhost:

Hi,

there's been various fixes upstream in that area, I'm closing the
Debian bug now. Thanks for the reports!

Christoph


signature.asc
Description: PGP signature

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

[Tim Wienk]

Package: inkscape
Version: 0.92.0-3~bpo8+1
Severity: normal

Dear Maintainer,

Please note, this bug only applies to Debian Jessie (using inkscape from
jessie-backports and python-scour from jessie - there is no backported
version of python-scour).

When saving as an optimised SVG, inkscape uses the scour library to
optimise the SVG. An error is reported when doing so, triggered by
importing `scourString` from `scour.scour`.

The problem is most likely a result of a change in the python-scour
package:

- In package version 0.26-3 (jessie), scour.py exists as:
  /usr/lib/python2.7/dist-packages/scour.py
- In package version 0.32-2 (stretch), scour.py exists as:
  /usr/lib/python2.7/dist-packages/scour/scour.py


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:
+from scour import scourString
 except Exception as e:


Thanks for the continued work and effort on maintaining this package.

Kind regards,

Tim.


-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'testing'), (10, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-1.3
ii  libatk1.0-02.14.0-1
ii  libatkmm-1.6-1 2.22.7-2.1
ii  libc6  2.19-18+deb8u7
ii  libcairo2  1.14.0-2.1+deb8u2
ii  libcairomm-1.0-1   1.10.0-1.1
ii  libcdr-0.1-1   0.1.0-3
ii  libdbus-1-31.8.22-0+deb8u1
ii  libdbus-glib-1-2   0.102-1
ii  libfontconfig1 2.11.0-6.3+deb8u1
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgc1c2   1:7.2d-6.4
ii  libgcc11:4.9.2-10
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii  libglib2.0-0   2.42.1-1+b1
ii  libglibmm-2.4-1c2a 2.42.0-1
ii  libgomp1   4.9.2-10
ii  libgsl0ldbl1.16+dfsg-2
ii  libgtk2.0-02.24.25-3+deb8u1
ii  libgtkmm-2.4-1c2a  1:2.24.4-1.1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.3.1-12
ii  liblcms2-2 2.6-3+b3
ii  libmagick++-6.q16-58:6.8.9.9-5+deb8u6
ii  libmagickcore-6.q16-2  8:6.8.9.9-5+deb8u6
ii  libmagickwand-6.q16-2  8:6.8.9.9-5+deb8u6
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpangoft2-1.0-0  1.36.8-3
ii  libpangomm-1.4-1   2.34.0-1.1
ii  libpng12-0 1.2.50-2+deb8u3
ii  libpoppler-glib8   0.26.5-2+deb8u1
ii  libpoppler46   0.26.5-2+deb8u1
ii  libpopt0   1.16-10
ii  libpotrace01.12-1+deb8u1
ii  librevenge-0.0-0   0.0.1-3
ii  libsigc++-2.0-0c2a 2.4.0-1
ii  libstdc++6 4.9.2-10
ii  libvisio-0.1-1 0.1.0-2
ii  libwpg-0.3-3   0.3.0-3
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u4
ii  libxslt1.1 1.1.28-2+deb8u2
ii  python 2.7.9-1
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages inkscape recommends:
ii  aspell0.60.7~20110707-1.3
ii  imagemagick   8:6.8.9.9-5+deb8u6
pn  libimage-magick-perl  
pn  libwmf-bin
ii  python-lxml   3.4.0-1
ii  python-numpy  1:1.8.2-2
ii  python-scour  0.26-3
pn  transfig  

Versions of packages inkscape suggests:
ii  dia  0.97.3-1
pn  libsvg-perl  
pn  libxml-xql-perl  
pn  pstoedit 
pn  python-uniconvertor  
ii  ruby 1:2.1.5+deb8u2

-- no debconf information

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

[Raphaël Halimi]

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.

> * Please use reportbug so you supply dependency information

Sorry. Please see below.

> * Please use sane severities

My mistake, I thought the impossibility to create proper backports was
serious enough.

> Can you please provide the full command, the full output and the
> versions as reported by reportbug?

Here you go.

Full command and full output:

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

Reportbug information:

-%<-
-- 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=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages git-buildpackage depends on:
ii  devscripts2.17.0
ii  git   1:2.11.0-2
ii  man-db2.7.6.1-2
ii  python-dateutil   2.5.3-2
ii  python-pkg-resources  33.1.1-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.84
ii  pbuilder 0.228.1
ii  pristine-tar 1.37
ii  python-requests  2.12.4-1

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.19p1-1
ii  unzip  6.0-21

-- no debconf information
->%-

Do you need (parts of) my configuration files too ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#815170: love: New upstream version available

[Alexandre Detiste]

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.

Greets,

Alexandre Detiste

Bug#261415: network installation always asks for proxy

[Geert Stappers]

> 
> Of course, incomprehensible questions will also drive users elsewhere,
> so we need to make sure that people understand that they almost
> certainly don't care, unless they already know that they do care.

This e-mail is about "worry about a proxy
   when there is need to worry about a proxy"

> I could imagine using auto-detection to populate default values for a
> site's proxy, assuming that the software to achieve that has a decent
> chance of success, and isn't too big.
> 
> Alternatively, one could make sure that the subsequent package download
> progress page made it clear that it would be safe to cancel that, and
> that doing so would let one back up and specify a proxy to go via and
> then retry the install -- that would let the person looking at a
> download that's going depressingly slowly plenty of time to remember
> that they have a faster alternative, and the reassurance that they can
> switch to it without having to start the install from scratch (assuming
> we can get the code to work that way).

Currently we have these steps

* hardware detect
* network configuration with DHCP and manual config upon fail
* allways ask for proxy
* do the download

What I would like to see, are these steps

* hardware detect
* network configuration with DHCP and manual configuration upon failure
* inform user there is test download going on, allow "quick fail" (don't wait 
for time out)
** upon fail: ask for a proxy configuration 
** upon succes: fine, just continue
* do the download



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#852291: RM: letsencrypt.sh -- RoM; superseded by src:dehydrated

[Mattia Rizzolo]

package: ftp.debian.org
X-Debbugs-Cc: letsencrypt...@packages.debian.org

Dear ftp-masters,

all the binaries previously built by src:letsencrypt.sh has been took
over by src:dehydrated, so now src:letsencrypt is only a obsoleted
source package and can be removed.

Please take extra care of removing only the old binaries from
src:letencrypt.sh (version 0.3.0-2) and not the one coming from
src:dehydrated (version 0.3.1-2), just to avoid annoyances during the
freeze :)


% dak rm -Rn letsencrypt.sh
Will remove the following packages from unstable:

letsencrypt.sh |0.3.0-2 | source, all
letsencrypt.sh-apache2 |0.3.0-2 | all

Maintainer: Debian Let's Encrypt 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#826069: [Debichem-devel] Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

[Petter Reinholdtsen]

[Michael Banck]
> Well, any help is welcome, but at least I haven't had time to look at
> it.

Right.  Unless that changes, I guess it will not make it to Stretch.

> Do you need ghemical as part of debian-edu or something?  Maybe we can
> discuss alternatives in this case?

According to 'apt-cache rdepends ghemical', it is part of several
metapackages, among them education-chemistry.  I do not know anything
more about it.

-- 
Happy hacking
Petter Reinholdtsen

Bug#851509: qemu: Please enable sdl frontend too

[Laurent Bigonville]

On Sun, 15 Jan 2017 21:31:07 +0100 Samuel Thibault 
 wrote:

> Hello,
>
> Currently, only the GTK frontend is enabled. From what I read in
> #839695, this is because Michael wanted to make it modular. But can't
> we just let qemu depend on both gtk and sdl?
>
> The sdl display is very useful because it provides a simple one-window
> GUI, possibly without any frame, which makes it easily embeddable in
> various graphical interfaces.

FTR, Fedora is building with both GTK+3 and SDL*2.0*

Bug#851509: qemu: Please enable sdl frontend too

[Michael Tokarev]

23.01.2017 13:36, Laurent Bigonville wrote:
> On Sun, 15 Jan 2017 21:31:07 +0100 Samuel Thibault
>  wrote:
>> Hello,
>>
>> Currently, only the GTK frontend is enabled. From what I read in
>> #839695, this is because Michael wanted to make it modular. But can't
>> we just let qemu depend on both gtk and sdl?
>>
>> The sdl display is very useful because it provides a simple one-window
>> GUI, possibly without any frame, which makes it easily embeddable in
>> various graphical interfaces.
> 
> FTR, Fedora is building with both GTK+3 and SDL*2.0*

I'm reverting back virgl and gtk3 for now, it will solve these probs.

We'll deal with it in stretch+1

/mjt

Bug#851509: qemu: Please enable sdl frontend too

[Laurent Bigonville]

Le 23/01/17 à 11:40, Michael Tokarev a écrit :

23.01.2017 13:36, Laurent Bigonville wrote:

On Sun, 15 Jan 2017 21:31:07 +0100 Samuel Thibault
 wrote:

Hello,

Currently, only the GTK frontend is enabled. From what I read in
#839695, this is because Michael wanted to make it modular. But can't
we just let qemu depend on both gtk and sdl?

The sdl display is very useful because it provides a simple one-window
GUI, possibly without any frame, which makes it easily embeddable in
various graphical interfaces.

FTR, Fedora is building with both GTK+3 and SDL*2.0*

I'm reverting back virgl and gtk3 for now, it will solve these probs.

We'll deal with it in stretch+1

:(

Could you please keep a build with virgl, gtk3 and sdl2 in experimental? 
With maybe also spice >= 0.13 if you have time? So people can test the 
thing?

Bug#851112: gcstar: violates font license

[Simon McVittie]

On Fri, 13 Jan 2017 at 15:08:41 +0100, Jörg Frings-Fürst wrote:
> I have removed the fonts directory at the source tarball. The new
> package is uploaded to mentors and my sponsor has an mail to review the
> changes.

Upload sponsored. Hopefully this won't annoy your usual sponsor
too much.

Regards,
S

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

[Mattia Rizzolo]

Control: notfound -1 0.92.0-3~bpo8+1
Control: found -1 0.92.0-2
Control: retitle -1 inkscape: fails with older python-scour (as found in jessie)

On Mon, Jan 23, 2017 at 11:19:46AM +0100, Tim Wienk wrote:
> Package: inkscape
> Version: 0.92.0-3~bpo8+1
> 
> Please note, this bug only applies to Debian Jessie (using inkscape from
> jessie-backports and python-scour from jessie - there is no backported
> version of python-scour).

Thanks for the bug report!
Unfortunately the Debian bug tracker doesn't really know about
backports, but anyway, this is (should, haven't yet tried myself)
actually a bug reproducible in the unstable version of inkscape with
just a older version of python-scour.

Note that it can't be workarounded in the packaging side by backporting
the newer python-scour and forcing an higher version, as python-scour is
only "Recommend"ed, and versioned recomends are not really considered.

> When saving as an optimised SVG, inkscape uses the scour library to
> optimise the SVG. An error is reported when doing so, triggered by
> importing `scourString` from `scour.scour`.
> 
> The problem is most likely a result of a change in the python-scour
> package:
> 
> - In package version 0.26-3 (jessie), scour.py exists as:
>   /usr/lib/python2.7/dist-packages/scour.py
> - In package version 0.32-2 (stretch), scour.py exists as:
>   /usr/lib/python2.7/dist-packages/scour/scour.py

Thank you for the analysis!

> 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).
> +from scour import scourString
>  except Exception as e:

I'll forward this upstream soon.

Thank you again for your bug!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851509: qemu: Please enable sdl frontend too

[Michael Tokarev]

23.01.2017 13:44, Laurent Bigonville wrote:

> Could you please keep a build with virgl, gtk3 and sdl2 in experimental?
> With maybe also spice >= 0.13 if you have time? So people can test the
> thing?

Sure, will do right after I'll upload 2.8+dfsg-2

Thanks,

/mjt

Bug#826069: [Debichem-devel] Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

[Michael Banck]

Hi,

On Mon, Jan 23, 2017 at 11:31:34AM +0100, Petter Reinholdtsen wrote:
> According to 'apt-cache rdepends ghemical', it is part of several
> metapackages, among them education-chemistry.  I do not know anything
> more about it.

Unless there is a "no Qt" policy, I strongly advise to replace ghemical
with avogadro. Hrm Kalzium depends on libavogadro anyway, but I think
there is some non-overlapping functionality between the two.

Ghemical has been unmaintained upstream for many years, and the only
thing it has going for it is direct quantum chemistry computations via
libsc (from mpqc); however, those are really very simple.

Avogadro has a much better GUI and support for geometry optimizations
via force fields as well; and can read/write output/input of severl
quantum chemistry packages in Debian; you'd have to run the computation
yourself, though.

Also, bkchem might be a better choice than chemtool at this point,
although none of the 2d drawing packages is really heavily maintained
right now.


Michael

Bug#261415: network installation always asks for proxy

[Geert Stappers]

On Mon, Jan 23, 2017 at 11:30:31AM +0100, Geert Stappers wrote:
> 
> This e-mail is about "worry about a proxy
>when there is need to worry about a proxy"
> 
> 
> Currently we have these steps
> 
> * hardware detect
> * network configuration with DHCP and manual config upon fail
> * allways ask for proxy
> * do the download
> 
> What I would like to see, are these steps
> 
> * hardware detect
> * network configuration with DHCP and manual configuration upon failure
> * inform user there is test download going on, allow "quick fail" (don't wait 
> for time out)
> ** upon fail: ask for a proxy configuration 
> ** upon succes: fine, just continue
> * do the download
> 

Use case "home"
---

The SOHO router does DHCP, there is no web proxy,
so not need to bother the user about web proxy settings.


Use case "wpad"
---

The network has "web proxy auto detection" provisioning.
( https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol )
The debian-installer downloader honours those settings,
no need to prompt the proxy settings screen.


Use case "there is special web proxy for Debian installs"
-

The "quick fail" allows the user to go fast to
the screen whichs asks for the web proxy settings.


Use case "a web proxy is indeed needed"
---

Inform user that download might possible
after providing settings for a webproxy.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#261415: network installation always asks for proxy

[Philip Hands]

Geert Stappers  writes:

>> 
>> Of course, incomprehensible questions will also drive users elsewhere,
>> so we need to make sure that people understand that they almost
>> certainly don't care, unless they already know that they do care.
>
> This e-mail is about "worry about a proxy
>when there is need to worry about a proxy"
>
>> I could imagine using auto-detection to populate default values for a
>> site's proxy, assuming that the software to achieve that has a decent
>> chance of success, and isn't too big.
>> 
>> Alternatively, one could make sure that the subsequent package download
>> progress page made it clear that it would be safe to cancel that, and
>> that doing so would let one back up and specify a proxy to go via and
>> then retry the install -- that would let the person looking at a
>> download that's going depressingly slowly plenty of time to remember
>> that they have a faster alternative, and the reassurance that they can
>> switch to it without having to start the install from scratch (assuming
>> we can get the code to work that way).
>
> Currently we have these steps
>
> * hardware detect
> * network configuration with DHCP and manual config upon fail
> * allways ask for proxy
> * do the download
>
> What I would like to see, are these steps
>
> * hardware detect
> * network configuration with DHCP and manual configuration upon failure
> * inform user there is test download going on, allow "quick fail" (don't wait 
> for time out)
> ** upon fail: ask for a proxy configuration 
> ** upon succes: fine, just continue
> * do the download

Which in the case I described, would result in a probe that would
succeed followed by a download that was going to take several days.

I'm not trying to claim that it's a common case, but I've also certainly
done many slow installs by over-enthusiastically hitting return and then
remembering that there is a caching server locally that I should have
specified.

Actually, I was assuming that the scenario you describe would provoke
the same behaviour as the user interrupting the slow download, so I
agree that a failed download should also allow one to specify a proxy.

I am sceptical that a reliable test can be constructed that isn't going
to be just doing the download, so if we're going to change things it
should be to deal with all errors that might point at the need for a
proxy, including being aborted by a user during the download.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#851647: hypersan: upstream v4.4 and 'fat runtime' vs suricata

[Sascha Steinbiss]

Hi Arturo,

>> BTW, It hasn't escaped our notice that there is a new
>> 'hs_valid_platform()' function in Hyperscan 4.4 which checks at runtime
>> whether the executing CPU has SSSE3 support. This may help to no longer
>> require a Hyperscan-specific Debian package for Suricata: if Suricata
>> could check at runtime whether Hyperscan can be used -- and fall back to
>> the classic BM/AC matchers if not -- we can just depend on and use
>> libhyperscan4 for all archs on which Hyperscan is available by default.
>> I wonder what your thoughts are?
> 
> That sounds more elegant than our current implementation. I would go this way.

Good to hear that we agree :)

>> To test this, I have started working on a proof-of-concept patch
>> for Suricata to do exactly that. Upstream might be interested as well?
>>
> 
> I guess so! yes! That would be great indeed :-)

I've prepared some first code [1] and will be testing it today in a QEMU
VM with SSSE3 disabled. If that works I'll ping upstream, OK?

Cheers
Sascha


[1]
https://github.com/satta/suricata/commit/1c41e89a4661223c997c846fbc6e1810614cba04

Bug#848285: closed by Julien Cristau (Re: Bug#852042: nmu: jackd2_1.9.10+20150825git1ed50c92~dfsg-4)

[James Cowgill]

Control: notfixed -1 1.9.10+20150825git1ed50c92~dfsg-4+b1

Hi,

On 22/01/17 16:55, Francesco Poli wrote:
> Control: fixed -1 jackd2/1.9.10+20150825git1ed50c92~dfsg-4+b1
> 
> On Sun, 22 Jan 2017 16:27:03 + Debian Bug Tracking System wrote:
> 
>> This is an automatic notification regarding your Bug report
>> which was filed against the jackd2 package:
>>
>> #848285: jackd2: spits verbose output and exits immediately when the client 
>> stops sending audio
>>
>> It has been closed by Julien Cristau .
> 
> Many thanks to all people involved in fixing the bug in GCC and in
> fixing the resulting issue in Jackd!
> 
> I am looking forward to seeing the binNMU migrate to Debian testing.
> 
> In the meanwhile, apt-listbugs users risk seeing the package unpinned
> and upgraded to the buggy version currently in testing, just because
> this bug report has been closed with -done without version info.
> I know that 1.9.10+20150825git1ed50c92~dfsg-4+b1 is not a source
> version, but I guess that adding it as a fixed version should not harm
> the BTS version tracking and would probably make apt-listbugs understand
> that the bug was *not* closed as invalid, just fixed in a binNMU...
> I am adding such a fixed version, I hope nobody will get angry because
> of this.

Unfortunately I don't think this is going to work. Now that there is a
"fixed" version, the BTS will only regard this bug as fixed in unstable
if it sees a source changelog containing that version. Since this will
never happen (it's a binNMU) the BTS will never regard this bug as fixed.

Given that binNMUs have no testing migration delay, hopefully this won't
affect people for too long.

James




signature.asc
Description: OpenPGP digital signature

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

[Fabian Greffrath]

Mattia Rizzolo wrote:
> Note that it can't be workarounded in the packaging side by backporting
> the newer python-scour and forcing an higher version, as python-scour is
> only "Recommend"ed, and versioned recomends are not really considered.

Not directly, but you can still enforce higher versions by using a Breaks
relation against the older version.

 - Fabian

Bug#845555: Bug Fixed lxpanel 0.9.3-1

[G. L. Gragnani]

I tried lxpanel 0.9.3 and the battery monitor basically works.
There is only a minor issue (or is it a feature?): with the AC adapter 
connected and the battery not fully charged
the monitor shows a green battery and displays the time remaining to 
charge (all is OK), but

when the battery is fully charged its color changes from green to yellow
Ciao
Gigi

Bug#261415: network installation always asks for proxy

[Geert Stappers]

Thing we really should prevent is hiding that a proxy might be needed.

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

[Maarten van Gompel]

Hi Andreas et al,

Short follow up: we discussed it internally and think it's indeed best to just
move the 'configuration' files to /usr/share, as you pointed out; simplifying 
the package and
resolving the conflicts. 

We're currently working on new upstream releases for
ucto, uctodata, frogdata, and frog  (the latter two have the same division and
make the same mistake, and depends on ucto/uctodata too) that implement this. I
hope releasing four new packages so close to the freeze is not going to be a
problem. At least it should fix this bug for good.

Regards,

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd



Quoting Maarten van Gompel (2017-01-23 11:10:18)
> Hi Andreas,
> 
> Thanks for your elaborate response! It seems this has indeed opened quite a 
> can
> of worms.. Here we go:
> 
> Quoting Andreas Beckmann (2017-01-22 22:27:08)
> > TL;DR: You have an ambitious task before you.
> 
> So I see...
> 
> > Let me see if I understand what's going on.
> >
> > Renaming conffiles and changing the owning package at the same time is a
> > PITA.
> > You add an extra point by making the old name a symlink to the new one,
> > owned by the new package
> >
> > In jessie, everything in /etc/ucto was owned by ucto.
> > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata
> > or libucto2, a m-a:same library package. These come from 2 different
> > source packages.
> 
> Indeed..
> 
> > Yuck. While putting conffiles in m-a:same packages is allowed, I highly
> > discourage this. Even if I haven't seen this fail once, yet. I'm just
> > afraid, someone has to clean up a mess caused by this at some point in
> > the future. and I'm afraid, I won't keep my fingers out of then :-(
> 
> Ok, we'll come back to this in your later suggestion to move the conffiles to 
> a
> new package.
> 
> > Before we start: Are these really conffiles? Supposed to be modified by
> > the local admin? Or are these rather data files that are not supposed to
> > be updated locally? And would better live in /usr/share in that case?
> 
> You have a point there; the user MAY add a new configuration or modify an
> existing one, but it is indeed not something that NEEDS to be modified to 
> run. You may be right that
> /usr/share might be better here. I'd have to discuss with the main upstream
> developer, but I think we're not opposed to such 'radical' solutions if that
> solves the packaging problems and makes more semantic sense anyway.
> What do you think is best for the short term to get this fixed before the
> freeze?
> 
> > And nearly everything from jessie's /etc/ucto content is now renamed and
> > a symlink.
> 
> > Can't you just fork the project? I'd suggest 'hpgb' and then use
> > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new
> > source packages ...
> >
> > Oh yeah, it well be a mess. But we will do it right. Including making
> > dpkg forget about the old conffiles.
> >
> > Right now, all upgrade attempts from jessie to stretch should always
> > have failed, so there is no further messed up state inbetween that
> > should be supported for clean upgrades.
> 
> Right
> 
> > can we move the conffiles from libucto2 to a new package, e.g.
> > ucto-common (which would be either m-a:foreign or m-a:allowed, but I
> > always mess up these two, I need to look up what's right?
> 
> Okay, that sounds good to me, if there's no objection to having yet another
> package.
> 
> > * Which version introduced the new layout?
> > * can you give me a list of
> >   + removed conffiles
> >   + renamed conffiles (old name, new name, new owning package, whether
> > they have a compat symlink, did the content change between jessie and sid)
> 
> ucto 0.9.2 introduced the split into uctodata. The jessie version is very 
> old: 0.5.3-3.1
> The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata 
> package:
> 
>  config/es.abr
>  config/exotic-eos.eos
>  config/exotic-quotes.quote
>  config/ligatures.filter
>  config/nl_afk.abr
>  config/pt.abr  (not in jessie version)
>  config/tokconfig-de
>  config/tokconfig-en
>  config/tokconfig-es
>  config/tokconfig-fr
>  config/tokconfig-fy
>  config/tokconfig-it
>  config/tokconfig-nl
>  config/tokconfig-nl-sonarchat
>  config/tokconfig-nl-twitter
>  config/tokconfig-nl-withplaceholder(not in jessie version)
>  config/tokconfig-pt(not in jessie version)
>  config/tokconfig-ru(not in jessie version)
>  config/tokconfig-sv
>  config/tokconfig-tr(not in jessie version)
> 
> The following remained in ucto 0.9.

Bug#850917: [Piuparts-devel] Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Holger Levsen]

Hi,

thanks for your work on this. It looks pretty good already.

On Sun, Jan 22, 2017 at 03:41:22PM +0100, Andreas Beckmann wrote:
> I don't think exporting more than one file is feasible with a
> master-slave setup.
 
while Michael has shown it's feasible, I wonder if this doesn't cause
too much overhead and fragility and whether we shouldn't transmit a
default tarball, which then in turn can contain several payloads?

aux_$pkg_$version.tgz and that has arbitrary (defined) contents…
(on or more tarballs again)

> Report the md5sum of the export file from post_purge_export_alternatives
> (just in case something gets mixed up later on).

I like that idea…

> The slave should send the aux file immediately before the corresponding
> log file and after sending logs for a section delete all unknown aux
> files. aux files without log file should be deleted, not sent to master.
 
agreed on the last part which makes the first part mandatory :) (I
slightly dislike sending the aux file before the log file…)

> master-bin/archive_old_logs should also handle old aux files.

indeed.

> For the final patch I would probably want to see it as a series of
> commits e.g. master-slave protocol support, piuparts support, glueing it
> together.

I'd also like several commits for this, if/where sensible. 

> I expect this will be a project for buster, not stretch, I don't want to
> hurry this into piuparts for stretch.

Here I disagree: I plan to upload 0.75 tomorrow or latest on wednesday
(not thursday) and let it migrate to stretch. After that, I'll be happy
to merge Michael's work on this and will/would like to include it in
0.76. And then, assuming the freeze lasts longer than a month or two,
I'll probably ask the release time to accept 0.76 into stretch, and will
be happy with whatever they'll decide.

During all this, piuparts.d.o will continue running code from the
develop branch, so this code should be running there as soon as it has
been merged.

That said, I neither want to hurry this in. I want this in, when it's
ready. :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Michael Meskes]

On Sun, Jan 22, 2017 at 10:20:19PM +0100, Adrien CLERC wrote:
> Severity: important

Actually I'm tempted to say this should get a higher severity because it breaks
existing prosody installations.

> After upgrading to the latest version, my Prosody setup fails, because
> I'm relying on SASL authentication using a unix socket.
> Is it easily fixable?

Downgrading to 3.0-rc1+git+321c0c9-2 gets prosody up again. Both later versions
do not work. Fortunately the packages are all available on snapshot.debian.org.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#852292: fex: Installs weird symlink /:sexsend:sexget:

[Guus Sliepen]

Source: fex
Version: 20160328-1
Severity: serious
Justification: Policy 9.1.1

Fex installs the following symlink in the root of the filesystem:

lrwxrwxrwx root/root 0 2016-08-30 13:54 ./:sexsend:sexget: -> 
/usr/share/fex/htdocs/download/sexstream

I assume this is an error. The link is created by debian/fex.links. In
any case, no package should create symlinks in /.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#851647: hypersan: upstream v4.4 and 'fat runtime' vs suricata

[Arturo Borrero Gonzalez]

On 23 January 2017 at 12:01, Sascha Steinbiss  wrote:
>
> I've prepared some first code [1] and will be testing it today in a QEMU
> VM with SSSE3 disabled. If that works I'll ping upstream, OK?
>

Ok, the patch looks good. Ping me if you need additional testing.

best regards.

Bug#838665: /usr/lib/python3/dist-packages/speechd_config/config.py: runs argparse on Python module import

[Sebastian Humenda]

Hi

Adrian Bunk schrieb am 18.01.2017, 20:34 +0200:
>On Mon, Sep 26, 2016 at 02:16:45PM +0200, Sebastian Humenda wrote:
>> I'll provide a patch to upstream shortly and attach it here as well, so that 
>> it
>> is fixed both upstream and downstream.
>
>any news regarding that?
Yes, I've investigated where my patch went and it was applied upstream for
0.8.*, which in turn was already uploaded to Debian. On my Stretch box, I cannot
confirm the issue anymore. If you execute the attached file as:

python3 test.py -k

it works fine. It previously complaint about a missing option, because it was 
executing
argparse on module import, which it doesn't do anymore.

I'd say the issue is fixed and would ask the maintainer to verify this or give
more details, so that I can provide more patches.

Thanks
Sebastian
#!/usr/bin/env python3
import speechd_config
print("hi")


signature.asc
Description: PGP signature

Bug#852293: kde-l10n-de: Version to old missing translations

[ZevenOS]

Package: kde-l10n-de
Version: 4:16.04.3-1
Severity: important
Tags: l10n

Dear Maintainer,


   * What led up to the situation?

untranslated strings in dolphins contextmenu coming from a missing
translation
of ark.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

used the version by debian 16.04.3 which includes an old translation.
   * What was the outcome of this action?

untranslated contextmenu entries for ark.
Later I checked ark and found untranslated strings there too

   * What outcome did you expect instead?

translated strings

I manually compiled 16.12.1 kde-l10n-de and checked the strings again
and they
were all translated.
I guess kde-l10n version should match at least with the kde applications
version like ark or
dolphin in version number to have proper translation


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



-- 
ZevenOS / Neptune Team
http://www.zevenos.com / http://www.neptuneos.com
Leszek Lesner 

Bug#848285: closed by Julien Cristau (Re: Bug#852042: nmu: jackd2_1.9.10+20150825git1ed50c92~dfsg-4)

[Jonas Smedegaard]

Quoting James Cowgill (2017-01-23 11:59:10)
> Control: notfixed -1 1.9.10+20150825git1ed50c92~dfsg-4+b1
> 
> Hi,
> 
> On 22/01/17 16:55, Francesco Poli wrote:
> > Control: fixed -1 jackd2/1.9.10+20150825git1ed50c92~dfsg-4+b1
> > 
> > On Sun, 22 Jan 2017 16:27:03 + Debian Bug Tracking System wrote:
> > 
> >> This is an automatic notification regarding your Bug report
> >> which was filed against the jackd2 package:
> >>
> >> #848285: jackd2: spits verbose output and exits immediately when the 
> >> client stops sending audio
> >>
> >> It has been closed by Julien Cristau .
> > 
> > Many thanks to all people involved in fixing the bug in GCC and in
> > fixing the resulting issue in Jackd!
> > 
> > I am looking forward to seeing the binNMU migrate to Debian testing.
> > 
> > In the meanwhile, apt-listbugs users risk seeing the package unpinned
> > and upgraded to the buggy version currently in testing, just because
> > this bug report has been closed with -done without version info.
> > I know that 1.9.10+20150825git1ed50c92~dfsg-4+b1 is not a source
> > version, but I guess that adding it as a fixed version should not harm
> > the BTS version tracking and would probably make apt-listbugs understand
> > that the bug was *not* closed as invalid, just fixed in a binNMU...
> > I am adding such a fixed version, I hope nobody will get angry because
> > of this.
> 
> Unfortunately I don't think this is going to work. Now that there is a
> "fixed" version, the BTS will only regard this bug as fixed in unstable
> if it sees a source changelog containing that version. Since this will
> never happen (it's a binNMU) the BTS will never regard this bug as fixed.
> 
> Given that binNMUs have no testing migration delay, hopefully this won't
> affect people for too long.

I think the correct approach is to reassign the bug to gcc and mark it 
as affecting jackd - i.e. not try track which jackd package is fixed: 
Purpose of binNMUs is to operate independent of the package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#813658: Reverting gtk/virgl support in qemu for stretch

[Michael Tokarev]

Control: reopen 839695
Control: reopen 813658
Control: found 839695 1:2.8+dfsg-2
Control: found 813658 1:2.8+dfsg-2

I'm reverting these changes (virgl and gtk support) for stretch.

After the new qemu hit backports yesterday, I received HUGE number
of complaints, just like I expected, from "server people", including
debian server team and debian admin team, complaining about extra
dependencies.

Since this has been enabled just a month ago and haven't received
much testing, I'm reverting it for stretch, going back to old good
sdl1 frontend and without any 3d support.

We'll deal with all this during next debian release development
cycle, and the result surely will be available in backports.

Thanks,

/mjt

Bug#850289: debian-policy: Patch so that there is an Example section in manual pages

[Thorsten Glaser]

Hi,

please break the lines, as is customary, do not use overlong lines.

I also believe you are confusing packages with executables. Packages
do not have manual pages, executables do. Packages oftentimes *do*
have instructions in /usr/share/doc/. This also means that the second
sentence (missing a full stop) is probably unnecessary.

Also (no affront intended), please run this through the English l10n
team before applying the patch…

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#829243: qemu-user-static: bad binfmts for mipsn32{,el}

[Michael Tokarev]

Control: reopen -1
Control: found -1 1:2.8+dfsg-2

01.07.2016 18:10, Adam Borowski wrote:
> Package: qemu-user-static
> Version: 1:2.6+dfsg-3
> Severity: normal
> Tags: patch
> 
> Hi!
> While you do ship -user executables for mipsn32 and mipsn32el, the binfmt
> magics detect them as mips/mipsel which obviously fails.
> 
> To tell them apart, we can use byte 36 bit &0x20.

Since jessie runs kernel 3.16, and 3.16 binfmt can't handle byte 36
in the binfmt masks (see #843032), and since we don't have an easy
workaround for this, I'm reverting this change for stretch.

For stretch+1 it wont be an issue, since stretch will be running
a capable kernel, but I see no other solution for stretch itself.
Especially this late in the release cycle, unortunately.

Thanks,

/mjt

Bug#814339: nghttp2: missing build-dependency on python-sphinxcontrib.rubydomain

[Roman Mamedov]

Hello,

I just hit the same snag that the original report is describing, and had to
spend some time digging around to figure out what's wrong. Would it really
hurt to just add the single missing build-depends line as the OP is proposing?

Alternatively, yes, please backport the 1.17 version into jessie-backports,
it's really so much different and more feature-complete than 0.64 which is
currently there.

Thanks

-- 
With respect,
Roman

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

[Ian Jackson]

Ian Jackson writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):
> Sean Whitton writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):
> > We already have several `dgit setup-foo` commands that mess around with
> > the working tree, so it seemed appropriate to me to add this one as
> > another setup- command.
> > 
> > How would you feel about shipping it as a standalone script, but then
> > having `dgit setup-maint-merge` call out to that script?
> 
> Let me think about this.

I'm afraid that having slept on this I'm more resistant to the idea
that this command should be `dgit anything', and particularly `dgit
setup-anything'.  In fact, I'm now more opposed to calling it
`dgit-something', even.

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.

I don't think of dgit as a kind of extensible collection of utilities
with a common data format (contrast git, which is).  The set of
principal dgit operations is closed.  (Things like `dgit build-source'
are UI improvements which simply provide different combinations of the
existing operations.)

In practical terms, the dgit manpage is a reference manual for the
dgit tool itself.  I don't want to add material to it relating to
specific workflows and particularly to fairly ad-hoc programs like
your proposed script.  That material would be distracting.

A similar consideration applies to the command namespace.

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.

So I think that all workflow-specific helpers and utilities should
have names which are not `dgit-foo'.  (And if a particular workflow
needs a specific enhancement to dgit, that should be done by a formal
and generic API/interface/protocol/whatever.)

This applies a fortiori to `dgit setup-*'.  All the existing `dgit
setup-*' commands are pieces of `dgit setup-new-tree'.  They are
provided because dgit clone does certain things; that plus the
principle of composability means that those functions must be
available separately from dgit clone, and that's what `dgit setup-*'
are.  (And of course it follows from dgit's design goals that other
kinds of `prepare my package branch' commands should not be required;
`dgit quilt-fixup' is itself very regrettable, but unavoidable -
arising as it does from design mistakes in dpkg-source.)

There are other reasons to want to separate this script from dgit
itself.  The script does not need the same level of mature
documentation, QA, command line parsing, configurability, etc., that
dgit has.  It is run manually, and its results will normally be
subject to human review.  It may want to be written in a different
language (python and bash both seem good options, and are already in
dgit's dependency set).

The name of this new script does not matter very much to its users.
It is run rarely, and its users will mostly have just read the
documentation.

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

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

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#851304: tomcat8 use 100% cpu time - confirmation

[Kai Moritz]

Dear Maintainer,


I can confirm the observations of RickLinux.

I have observed the exact same behaviour on several debian-hosts, that
are running Jessie with the version 8.0.14-1+deb8u6 of the
tomcat-packages (and also u4 and u5).


In my case, the effect is triggered by scans, that hit the servers that
I am administering at random. Each scan can be seen in the LOG-files
with an entry like:

62.210.246.66 - - [18/Jan/2017:16:20:16 +0100] "-" 400 -

Each hit leads to one cpu hogging 100%. Hence, if the machine has only
one cpu, one hit leads to an DOS, if it has for example 8 cpu's, 8 hits
are needed.

At first glance, I thought, that the scans are running a specialized
DOS-attack. But after I read the bug-report of RickLinux I produced the
exact same behaviour with an https-GET on the port, where tomcat is
listening for http-connections.

Like RickLinux I also tested a vanilla 8.0.14 Tomcat and found, that it
does not show this behavior.


Kind Regards

Kai Moritz

-- 
juplo
Inhaber: Kai Moritz

Tel: +49 (0)176 20 50 47 47
k...@juplo.de
http://juplo.de

Bug#851918: MPI_Comm_dup error still occurs on s390x, ppc64, sparc64 builds of mpgrafic-0.3.9-1

[Boud Roukema]

Just for the record: in mpgrafic-0.3.9-1, the symptoms of this
bug remain - mpgrafic-0.3.9-1 fails to build on s390x, ppc64, ppc64, sparc64:

https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=s390x&ver=0.3.9-1&stamp=1485163445&raw=0

FAIL: regression-test-0.3.7.9.sh


Code regression test: does the standard input file generate an
output file identical to that produced by version 0.3.7.9
of mpgrafic? IEEE_UNDERFLOW_FLAG and IEEE_DENORMAL exceptions
are considered acceptable and ignored. Other minor warnings are
ignored too on some systems/implementations.

This looks like a debian openmpi system.
[zemlinsky:3690] *** An error occurred in MPI_Comm_dup
[zemlinsky:3690] *** reported by process [1324089345,0]
[zemlinsky:3690] *** on communicator MPI_COMM_WORLD
[zemlinsky:3690] *** MPI_ERR_COMM: invalid communicator
[zemlinsky:3690] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will 
now abort,
[zemlinsky:3690] ***and potentially your MPI job)
Warning: A 32^3 mpi run of mpgrafic did not match the expected output.

Equivalent output is on:

https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=ppc64&ver=0.3.9-1&stamp=1485164619&raw=0

https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=sparc64&ver=0.3.9-1&stamp=1485164111&raw=0

with the process lines:

[ookuninushi:8387] *** reported by process [1226178561,0]

[landau:151008] *** reported by process [2975596545,0]


Possible clue: Does the line "*** reported by process [1324089345,0]" mean
that the PID number is assumed to be 1324089345? It sounds extremely high
for a PID. Unsigned 32-bit integers go up to approx 4e9. A build of mpgrafic
should not spawn a billion or so processes :P.

This looks like a report from lines 25-29 of ompi/errhandler/help-mpi-errors.txt

25  [mpi_errors_are_fatal]
26  %s *** An error occurred %s %s
27  %s *** reported by process [%lu,%lu]
28  %s *** on %s %s
29  %s *** %s


Another possible clue: line 988 of ompi/communicator/comm.c

 988  rc =  ompi_comm_set ( &newcomp,   /* new 
comm */

uses a pointer to a pointer for the new communicator. So a bug related
to fortran-C interfacing (non-use of iso_C_binding?) together with endianness
for a pointer to a pointer might be the source of the bug.

Bug#847939: Re: Bug#847939: emacs24: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory

[Hermann Lauer]

On Sun, Jan 22, 2017 at 01:05:12PM -0600, Rob Browning wrote:
> > starting emacs on a testing system (remote via ssh) yields to:
> >
> > Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No 
> > such file or directory
>   - Which Emacs package was installed on the remote system: emacs24,
> emacs24-nox, or emacs24-lucid?

emacs24

>   - Did you install libgl1 to the local system or the remote system to
> fix the problem?

on the remote system.

>   - How exactly were you testing, via ssh -X or ssh -Y, and do you have
> any ssh config changes that might affect their meaning?

With the equivalent of "-X" in my local /etc/ssh/ssh_config:
Host *
   ForwardX11 yes

Thanks for careing,
 greetings
  Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: hermann.la...@iwr.uni-heidelberg.de

Bug#852267: [debian-mysql] Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

[Otto Kekäläinen]

2017-01-23 0:48 GMT+02:00 Jean-Marc :
> On 21/01, a dist-upgrade replaced mariadb 10.0 with 10.1.
>
> It removed mariadb-server-10.0:amd64 (10.0.28-2), mariadb-client-10.0:amd64 
> (10.0.28-2), mariadb-client-core-10.0:amd64 (10.0.28-2) but just installed 
> mariadb-client-10.1:amd64 (10.1.20-3, automatic), 
> mariadb-client-core-10.1:amd64 (10.1.20-3, automatic).
>
> So, no server anymore breaking my dolibarr instance.
>
> Manually installing mariadb-server-10.1 worked like a charm and solved the 
> dolibarr issue, also replacing mariadb-server-core-10.0 (still installed 
> after the mariadb-server-10.0 removal) with mariadb-client-core-10.1.
>
> Another strange behavior: this dist-upgrade upgraded the default-mysql-client 
> from 1.0.1 but removed the
> default-mysql-server instead of upgrading it.


Can you provide me steps on how to reproduce this? What packages
exactly did you have installed before the upgrade (mariadb-*,
default-mysql-server, something that depends on mariadb-* or mysql-*)?


When I tested dist-upgrade today, it does not even install
mariadb-server automatically (due to the removes of old packages) and
I needed to apt install it manually. When done so, everything removed
and upgraded as expected.


1610:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  mariadb-server
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.


# apt install mariadb-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  galera-3 libjemalloc1 mariadb-client-10.1 mariadb-client-core-10.1
mariadb-server-10.1 mariadb-server-core-10.1 socat
Suggested packages:
  mailx mariadb-test tinyca
The following packages will be REMOVED:
  mariadb-client-10.0 mariadb-client-core-10.0 mariadb-server-10.0
mariadb-server-core-10.0
The following NEW packages will be installed:
  galera-3 libjemalloc1 mariadb-client-10.1 mariadb-client-core-10.1
mariadb-server-10.1 mariadb-server-core-10.1 socat
The following packages will be upgraded:
  mariadb-server

Bug#850705: libqt5gui5: enabling software rendering in 90qt5-opengl

[Александр Волков]

Sorry, the software renderer is built-in in Qt 5.8.
So it makes sense to package qtdeclarative-render2d-opensource-src only 
for Qt 5.7.

And for Qt 5.8 you can remove 90qt5-opengl.

Bug#852294: sawfish: Non-transient windows ignored in tiling functions

[Jose Antonio Ortega Ruiz]

Package: sawfish
Version: 3:1.12.0-1nano
Severity: normal

Dear Maintainer,

The current version of sawfish has a problem with its tiling layout
functions, described in this upstream report:

  https://github.com/SawfishWM/sawfish/pull/21

it affects tiling in the presence of applications such as Conky or
Corebird.

the problem was fixed upstream in their version 1.12.0.

thanks!
jao

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

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

Versions of packages sawfish depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgmp10 2:6.1.2+dfsg-1
ii  libgtk2.0-0  2.24.31-1
ii  libice6  2:1.0.9-1+b1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libpangoxft-1.0-01.40.3-3
ii  librep16 3:0.92.6-1nano
ii  libsm6   2:1.2.2-1+b1
ii  libx11-6 2:1.6.4-2
ii  libxext6 2:1.3.3-1
ii  libxft2  2.3.2-1
ii  libxinerama1 2:1.1.3-1+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxtst6 2:1.2.3-1
ii  rep  3:0.92.6-1nano
ii  rep-gtk  3:0.90.8.3-1nano
ii  rxvt-unicode-256color [x-terminal-emulator]  9.22-1+b1
ii  sawfish-data 3:1.12.0-1nano
ii  xterm [x-terminal-emulator]  327-2

sawfish recommends no packages.

sawfish suggests no packages.

-- no debconf information

Bug#826959: linux-signed is not yet suitable for testing

[Luca Boccassi]

On Fri, 02 Sep 2016 16:54:10 +0100 Ben Hutchings  wrote:
> Control: severity -1 important
> 
> On Fri, 10 Jun 2016 16:55:43 +0100 Ben Hutchings 
> wrote:
> > Package: src:linux-signed
> > Version: 1.1
> > Severity: serious
> >Â 
> > Several changes are needed before it's ready for release:
> >Â 
> > 1. Building signed udebs
> > 2. Removing the -signed suffix from signed image packages
> 
> These are now done as of version 2.2.
> 
> > 3. Signing with an HSM
> 
> This is not, and it really should be, but I think we can't treat this
> as a blocker for testing propagation.
> 
> Ben.

Hello Ben,

I've done some minor changes to add flags to use pesign which supports
hardware tokens via PKCS11. Inline patch for review.

Fortunately kbuild's sign-file already supports just passing a PKCS11
URI, which makes it so much simpler. On the other hand as you most
likely have found out already pesign needs an NSS DB and cert nicknames
and tokens, and all in all it's a really awkward API to use, but that's
what we have to work with I suppose.

What do you think?

Thanks!

Kind regards,
Luca Boccassi

From d41492d4b7ee9c76973a644eb66a4be14d30335d Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Mon, 23 Jan 2017 11:59:38 +
Subject: [PATCH] Add support for pesign

As an alternative signing method add options to use pesign instead of
sbsign. pesign supports, among other things pkcs11 which means
support for hardware tokens.
---
 debian/README.source |  9 -
 debian/bin/sign.py   | 35 +--
 debian/rules |  2 +-
 debian/rules.defs|  6 ++
 4 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/debian/README.source b/debian/README.source
index 9a9b873..ed7c1b1 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -29,7 +29,7 @@ To generate the signatures:
- KERNEL_IMAGE_VERSION: Version of the linux-image packages to be
  signed.
- KERNEL_MODULES_PRIVKEY: Name of the private key file (RSA PEM
- format) for module signing.
+ format) for module signing, or PKCS11 URI.
- KERNEL_MODULES_CERT: Name of the certificate file (X.509 PEM
  format) for module signing.  This file must also be included in
  src:linux and listed in CONFIG_SYSTEM_TRUSTED_KEYS.
@@ -38,9 +38,16 @@ To generate the signatures:
- KERNEL_IMAGE_CERT: Name of the certificate file (X.509 PEM
  format) for image signing.  This certificate must be trusted by
  the boot loader for Secure Boot to work.
+ When using pesign, this will be used as the certificate NSS
+ nickname.
- MIRROR_SUITE: Suite from which to download the linux-image
  packages, if they are not already provided in
  debian/localpackages.
+   - SIGNER: default is sbsign, supports pesign too.
+   - NSS_DIR: if using pesign, points to the NSS database directory.
+   - NSS_TOKEN: if using pesign with an hardware token, represents the
+ token as it is known by NSS. Can be found out with:
+ modutil -dbdir sql:`${NSS_DIR}` -list
 2. If the packages are not yet publicly available (e.g. for a security
update), create debian/localpackages/ and copy or link them into
there.
diff --git a/debian/bin/sign.py b/debian/bin/sign.py
index 5ac3848..87c9310 100755
--- a/debian/bin/sign.py
+++ b/debian/bin/sign.py
@@ -170,8 +170,22 @@ def sign_image_efi(image_name, signature_name, 
privkey_name, cert_name):
 if not os.path.isfile(signature_name):
 raise Exception('sbsign failed')
 
+def sign_image_efi_pesign(image_name, signature_name, nss_dir, cert_name,
+  nss_token=""):
+print('I: Signing image %s' % image_name)
+print('I: Storing detached signature as %s' % signature_name)
+os.makedirs(os.path.dirname(signature_name), exist_ok=True)
+subprocess.check_call(['pesign', '-s', '-n', nss_dir, '-c', cert_name,
+   '--export-signature', signature_name,
+   '-i', image_name] +
+   ([] if len(nss_token) == 0 else ['-t', nss_token]))
+# Work around bug #819987
+if not os.path.isfile(signature_name):
+raise Exception('pesign failed')
+
 def sign(config_name, imageversion_str, modules_privkey_name, 
modules_cert_name,
- image_privkey_name, image_cert_name, mirror_url, suite):
+ image_privkey_name, image_cert_name, mirror_url, suite, 
signer='sbsign',
+ nss_dir=None, nss_token=""):
 config = ConfigCoreDump(fp=open(config_name, 'rb'))
 
 # Check current linux-support version
@@ -228,11 +242,20 @@ def sign(config_name, imageversion_str, 
modules_privkey_name, modules_cert_name,
 kconfig = kconfig_file.readlines()
 if ('CONFIG_EFI_STUB=y\n' in kconfig and
 'CONFIG_EFI_SECURE_BOOT_SECURELEVEL=y\n' in kconfig):
-sign_image_efi('%s/boot/vmlinuz-%s' %
-   (package_dir, kernelversion),
-   

Bug#852296: yade FTBFS on arm64: compiler processes terminated (machine runs out of RAM?)

[Adrian Bunk]

Source: yade
Version: 2017.01a-1
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=yade&arch=arm64

...
make -j6
...
[  4%] Building CXX object gui/CMakeFiles/_GLViewer.dir/qt5/OpenGLManager.cpp.o
cd /«PKGBUILDDIR»/debian/build/gui && /usr/bin/c++   -DNDEBUG -DQT_CORE_LIB 
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-DYADE_ODEINT -DYADE_SPH -D_GLViewer_EXPORTS -I/«PKGBUILDDIR» 
-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 
-I/usr/include/eigen3 -I/usr/include/vtk-6.3 -I/usr/include/aarch64-linux-gnu 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/«PKGBUILDDIR»/debian/build -I/usr/include/QGLViewer -isystem 
/usr/include/aarch64-linux-gnu/qt5 -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtGui -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtXml -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtOpenGL  -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -O2 
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security 
-Wall -std=c++11 -fext-numeric-literals -DYADE_VTK -DYADE_OPENMP -fopenmp 
-DYADE_GTS  -DQGLVIEWER_FOUND -DYADE_OPENGL -DYADE_QT5  -DYADE_CGAL 
-DFLOW_ENGINE -DYADE_GL2PS -DLBM_ENGINE -fPIC   -ftrack-macro-expansion=0 
-save-temps -fstack-protector-strong -DEIGEN_DONT_VECTORIZE -DEIGEN_DONT_ALIGN 
-DEIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT -DCGAL_DISABLE_ROUNDING_MATH_CHECK 
-frounding-math -fPIC -std=gnu++11 -o 
CMakeFiles/_GLViewer.dir/qt5/OpenGLManager.cpp.o -c 
/«PKGBUILDDIR»/gui/qt5/OpenGLManager.cpp
[  5%] Building CXX object gui/CMakeFiles/_GLViewer.dir/qt5/GLViewer.cpp.o
[  5%] Building CXX object gui/CMakeFiles/_GLViewer.dir/qt5/_GLViewer.cpp.o
cd /«PKGBUILDDIR»/debian/build/gui && /usr/bin/c++   -DNDEBUG -DQT_CORE_LIB 
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-DYADE_ODEINT -DYADE_SPH -D_GLViewer_EXPORTS -I/«PKGBUILDDIR» 
-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 
-I/usr/include/eigen3 -I/usr/include/vtk-6.3 -I/usr/include/aarch64-linux-gnu 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/«PKGBUILDDIR»/debian/build -I/usr/include/QGLViewer -isystem 
/usr/include/aarch64-linux-gnu/qt5 -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtGui -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtXml -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtOpenGL  -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -O2 
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security 
-Wall -std=c++11 -fext-numeric-literals -DYADE_VTK -DYADE_OPENMP -fopenmp 
-DYADE_GTS  -DQGLVIEWER_FOUND -DYADE_OPENGL -DYADE_QT5  -DYADE_CGAL 
-DFLOW_ENGINE -DYADE_GL2PS -DLBM_ENGINE -fPIC   -ftrack-macro-expansion=0 
-save-temps -fstack-protector-strong -DEIGEN_DONT_VECTORIZE -DEIGEN_DONT_ALIGN 
-DEIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT -DCGAL_DISABLE_ROUNDING_MATH_CHECK 
-frounding-math -fPIC -std=gnu++11 -o 
CMakeFiles/_GLViewer.dir/qt5/GLViewer.cpp.o -c 
/«PKGBUILDDIR»/gui/qt5/GLViewer.cpp
cd /«PKGBUILDDIR»/debian/build/gui && /usr/bin/c++   -DNDEBUG -DQT_CORE_LIB 
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-DYADE_ODEINT -DYADE_SPH -D_GLViewer_EXPORTS -I/«PKGBUILDDIR» 
-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 
-I/usr/include/eigen3 -I/usr/include/vtk-6.3 -I/usr/include/aarch64-linux-gnu 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/«PKGBUILDDIR»/debian/build -I/usr/include/QGLViewer -isystem 
/usr/include/aarch64-linux-gnu/qt5 -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtGui -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtXml -isystem 
/usr/include/aarch64-linux-gnu/qt5/QtOpenGL  -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -O2 
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security 
-Wall -std=c++11 -fext-numeric-literals -DYADE_VTK -DYADE_OPENMP -fopenmp 
-DYADE_GTS  -DQGLVIEWER_FOUND -DYADE_OPENGL -DYADE_QT5  -DYADE_CGAL 
-DFLOW_ENGINE -DYADE_GL2PS -DLBM_ENGINE -fPIC   -ftrack-macro-expansion=0 
-save-temps -fstack-protector-strong -DEIGEN_DONT_VECTORIZE -DEIGEN_DONT_ALIGN 
-DEIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT -DCGAL_DISABLE_ROUNDI

Bug#852295: RFS: freecell-solver/4.8.0-1 NMU

[Shlomi Fish]

Package: sponsorship-requests
  Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "freecell-solver"

 * Package name: freecell-solver
   Version : 4.8.0-1
   Upstream Author : Shlomi Fish 
 * URL : http://fc-solve.shlomifish.org/
 * License : Expat
   Section : devel

  It builds those binary packages:

freecell-solver-bin - Library for solving Freecell games
 libfreecell-solver-dev - Library for solving Freecell games (Development files)
 libfreecell-solver0 - Library for solving Freecell games

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

  https://mentors.debian.net/package/freecell-solver


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

dget -x
https://mentors.debian.net/debian/pool/main/f/freecell-solver/freecell-solver_4.8.0-1.dsc

  More information about freecell-solver can be obtained from
 http://fc-solve.shlomifish.org/ .

  Changes since the last upload:

  Updated to the new upstream version with several fixes and improvements - see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841445


  Regards,
   Shlomi Fish

Bug#852147: sawfish: Upstream version 1.12.0 available since August 06

[Jose A. Ortega Ruiz]

On Mon, Jan 23 2017, Jose M Calhariz wrote:

[...]

> Can you open a bug report against Debian about this tiling glitch?  It
> will help me to backport sawfish for stretch, for the benefit of
> stretch users.

done (i hope):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852294


thanks a lot!

Bug#852297: dnssec-trigger: Installs config files directly in the root of the filesystem

[Guus Sliepen]

Package: dnssec-trigger
Version: 0.13-3
Severity: serious
Justification: Policy 9.1.1

It appears the dnssec-trigger package installs the following files
directly in the root:

-rw-r--r-- root/root   215 2016-12-22 12:01 ./dnssec-triggerd-keygen.service
-rw-r--r-- root/root   573 2016-12-22 12:01 ./dnssec-triggerd.service
-rw-r--r-- root/root  4640 2016-12-22 12:01 ./dnssec.conf 

This looks like a bug to me, in any case it would be a violation of the
FHS.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#839695: 67 X11/GTK related packages on a headless server

[Rob J. Epping]

Hi

On 01/23/2017 09:31 AM, Michael Tokarev wrote:
> 23.01.2017 10:55, Rob J. Epping wrote:
>> Hi,
>>
>> qemu 1:2.8+dfsg-1 has hit jessie-backorts.
>>
>> With the fix for bug #839695 my server now wants to install 67 X11/GTK
>> related new packages. This is on a headless server where this is just
>> more atack surface, i.e. less security.
>>
>> Would it be possible to make the X11/GTK stuff optional? Maybe by
>> creating 2 binary versions for example a -gtk and a -nox version.
> 
> Please see #813658 .
> 
> In brief, being a 20+ years paranoic sysadmin myself, I don't see it
> being a security treat. Either we fix all needed X client libs to
> not depend on X itself (ie, being split into a headless and headful
> part), or we live with this.
> 
> People want features even on a headless server (eg, 3d support via
> spice), -- this will bring half of X anyway. So making just display
> optional doesn't work.

Let me be the voice of other people who do not need any graphical stuff.
For me personally, I only run headless virtual machines on a headless
server and do not want to install all the additional libraries.

As an example, some people want vim with GTK support and some don't.
So there is a bunch of vim packages available.

I guess what I want put forward is that I like to have a choice here,
similar to vim-nox and vim-gtk.

> Thanks,
> 
> /mjt

THNX && GRTNX,
RobJE





signature.asc
Description: OpenPGP digital signature

Bug#852298: ignition-math2 FTBFS on mipsel: Inertiald_Test.SetRotationNonuniqueNondiagonal failed

[Adrian Bunk]

Source: ignition-math2
Version: 2.7.0-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=ignition-math2&arch=mipsel&ver=2.7.0-1&stamp=1484689954&raw=0

...
[ RUN  ] Inertiald_Test.SetRotationNonuniqueNondiagonal
/«PKGBUILDDIR»/src/Inertial_TEST.cc:248: Failure
  Expected: moi
  Which is: 4 -1 0 -1 4 0 0 0 5
To be equal to: inertial.MOI()
  Which is: 4 -1 -1e-06 -1 4 -1e-06 -1e-06 -1e-06 5
[  FAILED  ] Inertiald_Test.SetRotationNonuniqueNondiagonal (9 ms)
...

Bug#819382: 3% korko lainan

[JOHANN ROGERS FIRM]

Tarvitsetko lainaa? jos kyllä ota yhteyttä saadaksesi lisätietoja.

Bug#852239: atop: please drop the initscripts dependency

[Marc Haber]

On Sun, Jan 22, 2017 at 09:11:34PM +0100, Stephen Kitt wrote:
> The atop 2.2.3-1~exp1 package introduced a dependency on initscripts,
> apparently to ensure /run is present. This is no longer necessary
> since base-files now provides /run (since version 6.4). In addition,
> it is possible to run a system without initscripts installed at all.

Can I have this as a Suggests to be nice to backporters?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#852296: yade FTBFS on arm64: compiler processes terminated (machine runs out of RAM?)

[Graham Inggs]

On 23/01/2017 14:08, Adrian Bunk wrote:

This buildd has 6 CPUs, but it has only 8 GB of RAM.


From the last changelog entry:

  * [d763fbf] Set compat level to 10.

The switch to debhelper 10 enabled parallel builds.

Yade 2017.01a-1 FTBFS on most architectures in Ubuntu.
The following changed helped there:

--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 tmpDirMatplotLib = $(CURDIR)/debian/matplotlib

 %:
-   dh $@ --builddirectory=$(BUILDDIR) --with python2
+   dh $@ --builddirectory=$(BUILDDIR) --with python2 --max-parallel=1

 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-no-keep-memory

Bug#852295: RFS: freecell-solver/4.8.0-1 NMU

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

Please read and follow
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu

Your debian/patches/debian-changes is full of conflict markers, this is
unacceptable and also means you did something wrong.

B-D changes are not reflected in d/changelog.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#852299: alsa-utils: ship alsaucm man page

[Antonio Ospite]

Package: alsa-utils
Version: 1.1.3-1
Severity: wishlist

Dear Maintainer,

since alsa-utils 1.1.3 alsa-utils ships a man page for the alsaucm
utility program.

It would be great if you can ship it in the debian package.

The unix man page is built from a reStructuredText source file using the
rst2man program which in Debian can be found in python-docutils
or python3-docutils; so build-depending on either one of these should be
enough to make the build system generate alsaucm.1.

If you are building from tarballs and alsaucm.rst is missing there, this
has been fixed after 1.1.3, see:
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=c6bdde171e1532f7b37333a5a746b6e662f12c53

If this is the case tell if you want me to send a patch which adds
alsucm.rst at packaging time, until the next stable tarball.

Thanks,
   Antonio

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages alsa-utils depends on:
ii  dialog1.3-20160828-2
ii  kmod  23-2
ii  libasound21.1.3-1
ii  libc6 2.24-9
ii  libfftw3-single3  3.3.5-3
ii  libncursesw5  6.0+20161126-1
ii  libsamplerate00.1.8-8
ii  libtinfo5 6.0+20161126-1
ii  lsb-base  9.20161125
ii  whiptail  0.52.19-1

alsa-utils recommends no packages.

alsa-utils suggests no packages.

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#852300: RM: fleet -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: timothy.pot...@hpe.com,pkg-go-maintain...@lists.alioth.debian.org

Please remove source package "fleet" from "unstable".

Fleet became obsolete as it was abandoned by upstream. Moreover currently
Fleet is affected by FTBFS but considering its unmaintained state upstream
Fleet is probably not worth time spent on it...

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Perhaps is is better to be irresponsible and right, than to be responsible
and wrong.
-- Winston Churchill


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

Bug#813658: Reverting gtk/virgl support in qemu for stretch

[ge...@riseup.net]

Hi Michael, all,

Thanks for reverting - the additional needed dependencies to be installed
on a headless server were just way too invasive.

Could just push this to j-bp as well?

Cheers and thanks for your work!
Best,
Georg


signature.asc
Description: Digital signature

Bug#839695: 67 X11/GTK related packages on a headless server

[ge...@riseup.net]

Hi Michael, all,

As written by Rob already: Thanks for reverting the changes - the
additional dependencies to install on a headless server were just
insane.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#852301: RM: wims [armel] -- RoQA; build depends on node-uglify, which is not available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

Since version 1:4.13c~dfsg1-1 wims build depends on node-uglify (uglifyjs),
which is not installable on armel:
It depends on nodejs, which is no longer available on armel.

Bug#813658: Reverting gtk/virgl support in qemu for stretch

[Michael Tokarev]

23.01.2017 15:23, ge...@riseup.net wrote:

> 
> Could just push this to j-bp as well?

As per bpo policy, a package needs to hit testing
first. Since we're in a freeze, migration to testing
require mandatory 10 days waiting period, and should
be manually approved.  So I'm not sure it's a good
idea to push these to j-bp right away.

Thanks,

/mjt

Bug#839695: 67 X11/GTK related packages on a headless server

[Michael Tokarev]

23.01.2017 15:12, Rob J. Epping wrote:

> Let me be the voice of other people who do not need any graphical stuff.
> For me personally, I only run headless virtual machines on a headless
> server and do not want to install all the additional libraries.
> 
> As an example, some people want vim with GTK support and some don't.
> So there is a bunch of vim packages available.
> 
> I guess what I want put forward is that I like to have a choice here,
> similar to vim-nox and vim-gtk.

As I already said multiple times, first, we need not one but EIGHT new
packages like this (for each of qemu-system-foo variant), and second,
even for headless, people want 3d gpu support, which brings all this
X stuff back again.

Sorry but this is not a solution. And sure thing I considered it
multiple times.

Thanks,

/mjt

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

[Andreas Tille]

Hi Carnë,

On Fri, Jan 20, 2017 at 05:44:00PM +, Carnë Draug wrote:
> I have filled a RFP (bug # 852004) for bioperl's Bio-EUtilities
> package [1].  Unlike Bio-Coordinate, which was split from bioperl and
> was recently packaged in Debian, Bio-EUtilities development started
> already after bioperl commenced its splitting.
> 
> I was wondering if it was possible for the debian-med team to package
> it.  While I am not a debian maintainer, I am one of the
> Bio-EUtilities developers, have an interest on seeing it packaged in
> Debian, and I'm willing to support it upstream.

I have commited some initial packaging to

   https://anonscm.debian.org/git/debian-med/libbio-eutilities-perl.git 

This build fails due to the failure of several tests - as far as I can
see due to the attempt to access the internet.  It would help if you
could provide an option: "Just do all tests than can be done offline"
since the Debian packaging process needs to run fully offline.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Charles Malaheenee]

Package: ipxe-qemu
Version: 1.0.0+git-20161027.b991c67-1
Severity: normal
Tags: upstream

Dear Maintainer,

It's not possible to PXE boot in QEMU at all. When we choose --pxe option in 
virt-install (or virt-manager), the machine moves to a paused state
immediately after the 'starting PXE rom execution...' message appears.

More information can be found here: 
https://bugs.launchpad.net/qemu/+bug/1623276/

As mentioned at the link above, build a new version from git 
(http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005244.html) solves 
the problem.

Best regards,
Malaheenee

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

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

-- debconf-show failed

Bug#852082: gwc in testing crashes at startup

[Jaromír Mikeš]

2017-01-22 1:11 GMT+01:00 James Cowgill :

> Control: severity -1 grave
>

Hi,

sorry for slightly delayed answer :(


> On 21/01/17 14:18, Christian Grigis wrote:
> > Package: gwc
> > Version: 0.21.19~dfsg0-6
> > Severity: important
> >
> > Running 'gnome_wave_cleaner' from the testing package version
> > (0.21.19~dfsg0-6) crashes immediately at startup:
> >
> > $ gnome_wave_cleaner
> > Current stack limit: 8388608 bytes
> > Segmentation fault
>
> This bug is clearly RC. Jaromír, you did test this before uploading it
> right?
>

Actually I didn't as upload was only "debian packaging improvement" not new
upstream release
I was not expecting problems of this kind ... sorry


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

best regards

mira

Bug#852012: Debian-Installer: mount of partition failed

[Manuel Ambauen]

Close bug report 852012


Booting with a newer kernel version via PXE fixes the problem.

Cheers
Manuel

Bug#838064: Still happening with 1.7.2-1

[Edward Betts]

Hi,

The latest version (1.7.2-1) it is still crashing when I sent an e-mail.

Here is a backtrace.

Do you need any more information?

Core was generated by `mutt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55814bff0710 in mutt_pattern_exec (pat=pat@entry=0x55814d637d80, 
flags=flags@entry=MUTT_MATCH_FULL_ADDRESS, ctx=ctx@entry=0x55814d60ead0, 
h=h@entry=0x55814dde1d30) at ../../pattern.c:1256
1256../../pattern.c: No such file or directory.
(gdb) bt
#0  0x55814bff0710 in mutt_pattern_exec (pat=pat@entry=0x55814d637d80, 
flags=flags@entry=MUTT_MATCH_FULL_ADDRESS, ctx=ctx@entry=0x55814d60ead0, 
h=h@entry=0x55814dde1d30) at ../../pattern.c:1256
#1  0x55814bff0a16 in perform_and (hdr=0x55814dde1d30, ctx=0x55814d60ead0, 
flags=MUTT_MATCH_FULL_ADDRESS, pat=0x55814d637d80) at ../../pattern.c:1052
#2  0x55814bff0a16 in mutt_pattern_exec (pat=, 
flags=flags@entry=MUTT_MATCH_FULL_ADDRESS, ctx=ctx@entry=0x55814d60ead0, 
h=h@entry=0x55814dde1d30)
at ../../pattern.c:1170
#3  0x55814bfbc92d in mutt_set_header_color (ctx=ctx@entry=0x55814d60ead0, 
curhdr=curhdr@entry=0x55814dde1d30) at ../../curs_main.c:3204
#4  0x55814bfc012b in _mutt_set_flag (ctx=ctx@entry=0x55814d60ead0, 
h=0x55814dde1d30, flag=flag@entry=8, bf=, 
upd_ctx=upd_ctx@entry=1)
at ../../flags.c:277
#5  0x55814bfc05ff in _mutt_set_flag (ctx=ctx@entry=0x55814d60ead0, 
h=, flag=flag@entry=8, bf=, 
upd_ctx=upd_ctx@entry=1)
at ../../flags.c:30
#6  0x55814c001706 in ci_send_message (flags=, 
flags@entry=3, msg=, 
msg@entry=0x0, tempfile=tempfile@entry=0x0, ctx=0x55814d60ead0, 
cur=) at ../../send.c:2149
#7  0x55814bfe99bf in mutt_pager (banner=banner@entry=0x0, 
fname=fname@entry=0x7ffc6a8cf9b0 "/tmp/mutt-x1-1000-3765-12324164561639679986", 
flags=, 
flags@entry=66, extra=extra@entry=0x7ffc6a8cf980) at ../../pager.c:2890
#8  0x55814bfa69f5 in mutt_display_message (cur=0x55814dde1d30) at 
../../commands.c:225
#9  0x55814bfb5f0c in mutt_index_menu () at ../../curs_main.c:2041
#10 0x55814bf96f16 in main (argc=1, argv=, 
environ=) at ../../main.c:896

-- 
Edward.

Bug#852303: pywavelets FTBFS on all architectures

[Adrian Bunk]

Source: pywavelets
Version: 0.5.1-1
Severity: serious

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

...
make[1]: Entering directory '/«PKGBUILDDIR»'
dh_fixperms
# Remove execution flag set by upstream for all files.
find debian/python*-pywt -type f -exec chmod -x {} \;
# Remove execution flag set by upstream also on examples.
find debian/python-pywt-doc -type f -exec chmod -x {} \;
find: 'debian/python-pywt-doc': No such file or directory
debian/rules:32: recipe for target 'override_dh_fixperms' failed
make[1]: *** [override_dh_fixperms] Error 1

Bug#579215: display-manager alternative support added in 0.12-1.1

[Mike Gabriel]

Control: close -1
Control: fixed -1 0.12-1.1

Hi Petter,

recently there has been a nodm NMU with a patch by Simon McVittie that  
adds display-manager support.


Thus closing #579215.

Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpLFxdUsw6WU.pgp
Description: Digitale PGP-Signatur

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

[Michael Tokarev]

Control: severity -1 serious

23.01.2017 15:40, Charles Malaheenee wrote:
> Package: ipxe-qemu
> Version: 1.0.0+git-20161027.b991c67-1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> It's not possible to PXE boot in QEMU at all. When we choose --pxe option in 
> virt-install (or virt-manager), the machine moves to a paused state
> immediately after the 'starting PXE rom execution...' message appears.
> 
> More information can be found here: 
> https://bugs.launchpad.net/qemu/+bug/1623276/
> 
> As mentioned at the link above, build a new version from git 
> (http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005244.html) solves 
> the problem.

If that's the case, it's a serious issue, since this package
mostly becomes useless.  I can't verify it now since I don't
have any pxe-capable environmet here, but it looks like it's
real.  Oh well.

Thanks,

/mjt

Bug#852304: RFS: groonga/6.1.5-1

[Kentaro Hayashi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: groonga
  Version : 6.1.5-1
  Upstream Author : Groonga Project 
* Url : http://groonga.org/
* Licenses: LGPL-2.1
  Section : database

It builds those binary packages:

  * groonga
  * groonga-server-common
  * groonga-server-gqtp
  * libgroonga-dev
  * libgroonga0
  * groonga-tokenizer-mecab
  * groonga-token-filter-stem
  * groonga-plugin-suggest
  * groonga-bin
  * groonga-httpd
  * groonga-doc
  * groonga-examples
  * groonga-munin-plugins

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

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

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_6.1.5-1.dsc


More information about groonga can be obtained from
http://groonga.org/

Changes since last upload:
 * New upstream release.
  * debian/patches/fix-a-bug-that-AND-optimization-may-skip-matched-rec.patch
debian/patches/really-fix-a-bug-that-AND-optimization-may-skip-matc.patch
- Drop needless patch files. These changes are already merged in
  Groonga 6.1.5.


pgp1TsdcoRwz6.pgp
Description: PGP signature