Bug#832391: consensuscore2: figured out the resolution

[Afif Elghraoui]

While this package was removed from unstable in favor of unanimity
(which didn't get processed in time to be considered as part of the
release of Stretch), I figured out the solution to this RC bug, as
unanimity was showing similar issues.

I didn't realize that pybuild itself does build-system detection and its
detection is not reproducible when there is more than one possibility.
In this case, when it detects "distutils", the build works. When it
detects "cmake", the package comes out empty. The solution (and what was
done for unanimity) was to explicitly set it to "distutils".

Just posting here for the record in case someone else stumbles across a
similar issue.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849527: RFS: python-mechanicalsoup/0.6.0-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-mechanicalsoup"

* Package name: python-mechanicalsoup
  Version : 0.6.0-1
  Upstream Author : Mirth Hickford 
* URL : https://github.com/hickford/MechanicalSoup
* License : Expat
  Section : python

It builds those binary packages:

  python-mechanicalsoup - library for automating interaction with
websites (Python 2)
  python3-mechanicalsoup - library for automating interaction with
websites (Python 3)

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

  https://mentors.debian.net/package/python-mechanicalsoup

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

  dget -x https://mentors.debian.net/debian/pool/main/p/python-mechanic
alsoup/python-mechanicalsoup_0.6.0-1.dsc

Successful build on debomatic:

  http://debomatic-amd64.debian.net/distribution#unstable/python-mechan
icalsoup/0.6.0-1/buildlog

Changes since the last upload:

  * Initial release. (Closes: #849475)

Regards,
Ghis

Bug#844137: node-groove: FTBFS: Tests failures

[Petter Reinholdtsen]

[Felipe Sateler]
> However as I cannot reproduce the error, I cannot test if this indeed
> fixes the issue...

I talked to lucas on #debian-js about such access, and he allowed me to
use one of his VMs.  Lets talk about this there.

-- 
Happy hacking
Petter Reinholdtsen

Bug#848788: Moving scikit-learn to Debian Science Git to let more people work on its issues

[Andreas Tille]

Hi,

I intend to move scikit-learn to Debian Science to enable more people
working on issues like #848788 easily.  Please tell me soon if you think
that it is not a good idea.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#849526: python-beanbag: v2 example in index.html doesn't work

[Russell Stuart]

Package: python-beanbag
Version: 1.9.2-1
Severity: normal
Tags: patch

While your at it you could apply the supplied patch for #804357 too.


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

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

Versions of packages python-beanbag depends on:
ii  python-requests  2.11.1-1
pn  python:any   

python-beanbag recommends no packages.

Versions of packages python-beanbag suggests:
ii  python-beanbag-doc1.9.2-1
ii  python-requests-oauthlib  0.7.0-0.1

-- no debconf information
diff -Nur beanbag-1.9.2/docs/index.rst beanbag-1.9.2.new/docs/index.rst
--- beanbag-1.9.2/docs/index.rst	2015-03-27 18:03:37.0 +1000
+++ beanbag-1.9.2.new/docs/index.rst	2016-12-28 16:25:44.543216567 +1000
@@ -25,7 +25,7 @@
 
>>> import beanbag.v2 as beanbag # version 2 api
>>> github = beanbag.BeanBag("https://api.github.com;)
-   >>> watchers = GET(github.repos.ajtowns.beanbag.watchers)
+   >>> watchers = beanbag.GET(github.repos.ajtowns.beanbag.watchers)
>>> for w in watchers:
... print(w.login)
 

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Sebastiaan Couwenberg]

On 12/28/2016 05:41 AM, Adam Di Carlo wrote:
> Sebastiaan Couwenberg  writes:
> 
>>> -- Configuration Files:
>>> /etc/default/nagios-nrpe-server changed:
>>> USE_SSL=1
>>
>> Please note that the /etc/default/nagios-nrpe-server changed in
>> nagios-nrpe (3.0.1-3) because of the systemd service file.
>>
>> The USE_SSL option is no longer used, instead the NRPE_OPTS variable is
>> used to disable SSL in both the init script and systemd service file.
>> The default content is now as attached.
> 
> Gotit.
> 
> I'll work my way through your instructions, attempt to fix my interop
> issue.  Its always *overconfiguration* that gets me.

As documented in /usr/share/doc/nagios-nrpe-server/NEWS.Debian.gz which
is shown to you on upgrade when you have apt-listchanges installed:

"
  SSL support is disabled by default, the reworked SSL/TLS support in
  NRPE requires configuration before it can be used. Read the
  instructions in /usr/share/doc/nagios-nrpe-server/README.SSL.md.gz
  before enabling SSL support in /etc/default/nagios-nrpe-server.

  The default check_nrpe command in check_nrpe.cfg has been updated
  to disable SSL by default too. The check_nrpe_ssl command has been
  added to connect to the NRPE daemon over SSL.

  Beware that the new NRPE daemon only works with old check_nrpe
  plugins when SSL support is disabled on both sides, likewise the
  new check_nrpe plugin only works with the old NRPE daemon when SSL
  support is disabled.

  To use SSL between the NRPE client and server, configuring Stunnel
  is recommended.
"

Once all systems have upgraded to NRPE 3.x using its SSL support is an
option, but that will take some time (no other distributions have
upgraded to 3.x yet).

> Thank you for taking the time to help!
> 
> 
> However, no matter my legacy misconfig, isn't it still problematic to
> segfault like this?  Let me know if a backtrace would help.

Due to the signal handler in NRPE you won't easily get a backtrace since
SIGSEGV is caught too and NRPE just continues instead of terminating. If
you can get a backtrace (with debug symbols installed) that would be
helpful.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#810506: Upload of linux-grsec to jessie-backports?

[Salvatore Bonaccorso]

Hi,

On Tue, Dec 27, 2016 at 09:24:02PM -0500, anarcat wrote:
> On Mon, Apr 25, 2016 at 08:19:42AM +0200, Yves-Alexis Perez wrote:
> > On lun., 2016-04-25 at 05:45 +, Amarildo Júnior wrote:
> > > Any news?
> > 
> > Stay tuned? As already said I was waiting on the kernel to become eligible 
> > for
> > migration. This happened two days ago, so I'll prepare a jessie-backport
> > upload. But you're not forced to stop breathing in the meantime.
> 
> It's been a few months and the package is still not in stretch, partly
> because of this bug (but also because of #835949).
> 
> It is also considered bad practice to upload a package to backports if
> it is not in testing yet, especially if it's destined to be packaged
> there...
> 
> It would be great to settle this before the stretch freeze, which is
> coming real soon now (soft freeze on jan 5th would block this, iirc):

As per #810506 src:linux-grsec will not be part of stretch on purpose
(thus this blocking bug). But src:linux-grsec got an exception from
the usual rule from a backports ftp-master in
https://bugs.debian.org/810506#65 to get to stable users via
backports.

The idea is, that when src:linux-grsec would have been eligible to
migrate to testing under normal circumstances without the blocking
bug, then it is allowed to upload the version to jessie-backports.

Hope this helps,

Regards,
Salvatore

Bug#849524: further debugging with qemu

[Marc Lehmann]

I was able to replicate it in a qemu vm that containsd a copy of the disk
of that server. When I start a gdb session at the time where it hangs,
I get the output below - obviously. my gdb only sees 0's instead of the
actual memory (so disassembles garbage), but ni seems to work and shows
that it runs in a 5 insn loop. I hope this helps.

(gdb) target remote tcp::1212
Remote debugging using tcp::1212
0x1bee in ?? ()
(gdb) disass $eip-16,$eip+16
Dump of assembler code from 0x1bde to 0x1bfe:
   0x1bde:  add%al,(%eax)
   0x1be0:  add%al,(%eax)
   0x1be2:  add%al,(%eax)
   0x1be4:  add%al,(%eax)
   0x1be6:  add%al,(%eax)
   0x1be8:  add%al,(%eax)
   0x1bea:  add%al,(%eax)
   0x1bec:  add%al,(%eax)
=> 0x1bee:  add%al,(%eax)
   0x1bf0:  add%al,(%eax)
   0x1bf2:  add%al,(%eax)
   0x1bf4:  add%al,(%eax)
   0x1bf6:  add%al,(%eax)
   0x1bf8:  add%al,(%eax)
   0x1bfa:  add%al,(%eax)
   0x1bfc:  add%al,(%eax)
End of assembler dump.
(gdb) ni
0x1bf1 in ?? ()
(gdb) 
0x1bf3 in ?? ()
(gdb) 
0x1bea in ?? ()
(gdb) 
0x1bec in ?? ()
(gdb) 
0x1bee in ?? ()
(gdb) 
0x1bf1 in ?? ()
(gdb) 
0x1bf3 in ?? ()
(gdb) 
0x1bea in ?? ()
(gdb) 
0x1bec in ?? ()
(gdb) 
0x1bee in ?? ()
(gdb) 
0x1bf1 in ?? ()
(gdb) 
0x1bf3 in ?? ()
(gdb) 
0x1bea in ?? ()
(gdb) 
0x1bec in ?? ()

Bug#849525: gvfs-bin: gvfs insists on password to mount samba shares which have no password

[Markus Hamilton]

Package: gvfs-bin
Version: 1.22.2-1
Severity: important

I cannot access samba shares which do not require a password. The problem was
discovered using pcmanfm (LXDE desktop) as well as with caja (MATE desktop).
Both programs probably use gvfs-mount to mount samba shares.
To confirm, I tried gvfs-mount in a terminal window:
gvfs-mount smb://servername/sharename
gvfs-mount asks for user, domain and password. Entering an empty password is
impossible. gvfs-mount asks again. To make sure that this is not a samba
problem, I tried to mount the samba share with "mount":
sudo mount -t cifs //servername/sharename /mnt -o username=markus,password=""
This works without a problem. It is just not useful. Users want to use the
builtin funtionality of their file managers.



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

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

Versions of packages gvfs-bin depends on:
ii  gvfs-common   1.22.2-1
ii  libc6 2.19-18+deb8u6
ii  libglib2.0-0  2.42.1-1+b1

gvfs-bin recommends no packages.

Versions of packages gvfs-bin suggests:
ii  gvfs  1.22.2-1

-- no debconf information

Bug#849495: python-crypto: CVE-2013-7459

[Salvatore Bonaccorso]

Hi

Proposed debdiff attached.

Regards,
Salvatore
diff -Nru python-crypto-2.6.1/debian/changelog 
python-crypto-2.6.1/debian/changelog
--- python-crypto-2.6.1/debian/changelog2015-12-06 15:03:16.0 
+0100
+++ python-crypto-2.6.1/debian/changelog2016-12-28 06:21:20.0 
+0100
@@ -1,3 +1,11 @@
+python-crypto (2.6.1-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Throw exception when IV is used with ECB or CTR (CVE-2013-7459)
+(Closes: #849495)
+
+ -- Salvatore Bonaccorso   Wed, 28 Dec 2016 06:21:20 +0100
+
 python-crypto (2.6.1-6) unstable; urgency=medium
 
   * debian/control:
diff -Nru python-crypto-2.6.1/debian/patches/CVE-2013-7459.patch 
python-crypto-2.6.1/debian/patches/CVE-2013-7459.patch
--- python-crypto-2.6.1/debian/patches/CVE-2013-7459.patch  1970-01-01 
01:00:00.0 +0100
+++ python-crypto-2.6.1/debian/patches/CVE-2013-7459.patch  2016-12-28 
06:21:20.0 +0100
@@ -0,0 +1,84 @@
+From 8dbe0dc3eea5c689d4f76b37b93fe216cf1f00d4 Mon Sep 17 00:00:00 2001
+From: Legrandin 
+Date: Sun, 22 Dec 2013 22:24:46 +0100
+Subject: [PATCH] Throw exception when IV is used with ECB or CTR
+
+The IV parameter is currently ignored when initializing
+a cipher in ECB or CTR mode.
+
+For CTR mode, it is confusing: it takes some time to see
+that a different parameter is needed (the counter).
+
+For ECB mode, it is outright dangerous.
+
+This patch forces an exception to be raised.
+---
+ lib/Crypto/SelfTest/Cipher/common.py | 31 +++
+ src/block_template.c | 11 +++
+ 2 files changed, 34 insertions(+), 8 deletions(-)
+
+--- a/lib/Crypto/SelfTest/Cipher/common.py
 b/lib/Crypto/SelfTest/Cipher/common.py
+@@ -239,19 +239,34 @@ class RoundtripTest(unittest.TestCase):
+ return """%s .decrypt() output of .encrypt() should not be garbled""" 
% (self.module_name,)
+ 
+ def runTest(self):
+-for mode in (self.module.MODE_ECB, self.module.MODE_CBC, 
self.module.MODE_CFB, self.module.MODE_OFB, self.module.MODE_OPENPGP):
++
++## ECB mode
++mode = self.module.MODE_ECB
++encryption_cipher = self.module.new(a2b_hex(self.key), mode)
++ciphertext = encryption_cipher.encrypt(self.plaintext)
++decryption_cipher = self.module.new(a2b_hex(self.key), mode)
++decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
++self.assertEqual(self.plaintext, decrypted_plaintext)
++
++## OPENPGP mode
++mode = self.module.MODE_OPENPGP
++encryption_cipher = self.module.new(a2b_hex(self.key), mode, self.iv)
++eiv_ciphertext = encryption_cipher.encrypt(self.plaintext)
++eiv = eiv_ciphertext[:self.module.block_size+2]
++ciphertext = eiv_ciphertext[self.module.block_size+2:]
++decryption_cipher = self.module.new(a2b_hex(self.key), mode, eiv)
++decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
++self.assertEqual(self.plaintext, decrypted_plaintext)
++
++## All other non-AEAD modes (but CTR)
++for mode in (self.module.MODE_CBC, self.module.MODE_CFB, 
self.module.MODE_OFB):
+ encryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+ ciphertext = encryption_cipher.encrypt(self.plaintext)
+-
+-if mode != self.module.MODE_OPENPGP:
+-decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+-else:
+-eiv = ciphertext[:self.module.block_size+2]
+-ciphertext = ciphertext[self.module.block_size+2:]
+-decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
eiv)
++decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+ decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
+ self.assertEqual(self.plaintext, decrypted_plaintext)
+ 
++
+ class PGPTest(unittest.TestCase):
+ def __init__(self, module, params):
+ unittest.TestCase.__init__(self)
+--- a/src/block_template.c
 b/src/block_template.c
+@@ -170,6 +170,17 @@ ALGnew(PyObject *self, PyObject *args, P
+   "Key cannot be the null string");
+   return NULL;
+   }
++  if (IVlen != 0 && mode == MODE_ECB)
++  {
++  PyErr_Format(PyExc_ValueError, "ECB mode does not use IV");
++  return NULL;
++  }
++  if (IVlen != 0 && mode == MODE_CTR)
++  {
++  PyErr_Format(PyExc_ValueError,
++  "CTR mode needs counter parameter, not IV");
++  return NULL;
++  }
+   if (IVlen != BLOCK_SIZE && mode != MODE_ECB && mode != MODE_CTR)
+   {
+   PyErr_Format(PyExc_ValueError,
diff -Nru python-crypto-2.6.1/debian/patches/series 
python-crypto-2.6.1/debian/patches/series
--- python-crypto-2.6.1/debian/patches/series   2015-12-06 

Bug#849524: lilo: lock, lilo -R and fallback= broken, only display first letter and hang on boot

[Marc Lehmann]

Package: lilo
Version: 1:24.1-1
Severity: normal

Dear Maintainer,

I have a rather old (flaky, and hard to access) server which uses the
fallback= mechanism in lilo.conf to round-robin between various boot
configs, which worked fine in the past.

I don't know when exactly I tested the mechanism last, but it might have
been before the upgrade to jessie.

Recently, I upgraded the debian kernel and re-ran lilo, then tried to test
the fallback mechanism.

The first boot was normal, the second boot (which should switch to the
first fallback, didn't, lilo did hang like this:

   LILO 24.1 boot: p

The "p" is the first letter of the fallback image name
("previous"). Booting again booted the default image, as if no fallback
was given (so not all was lost :).

After experimenting, neither fallback= nor lilo -R nor the lock option
work anymore - all of them lead to a display similar like the above and a
hang at boot, with only the first character of the image name displayed.

So, basically, doing this:

   lilo
   lilo -R gxpe

Leads to hang like this:

   LILO 24.1 boot: g

Or a lock use like this:

   boot: rescue-emdeb abc lock

Leads to a hang like this:

   LILO 24.1 boot: r

The (slightly cleaned-up to the essentials) lilo.conf looks like this:

   boot = "/dev/disk/by-id/ata-Hitachi_HDS722020ALA330_JK1130YAH69SMT"

   append = "root=/dev/disk/by-label/ROOT ..."

   delay = 50
   timeout = 100
   unattended
   serial = 2,115200n8

   lba32
   compact
   large-memory
   map=/boot/map

   default=default

   ### cycling through these:

   image=/boot/vmlinuz-3.16.0-4-amd64
  initrd=/boot/initrd.img-3.16.0-4-amd64
  label=default
  fallback=previous
  read-only
  addappend="..."

   image=/boot/vmlinuz-3.16.0-4-amd64
  initrd=/boot/initrd.img-3.16.0-4-amd64
  label=previous
  fallback=rescue
  read-only
  addappend="..."

   image = /boot/rescue-kernel
  label = rescue
  fallback = rescue-emdeb
  initrd = /boot/rescue-initrd

   image = /boot/rescue-emdeb-kernel
  label = rescue-emdeb
  fallback = gpxe
  initrd = /boot/rescue-emdeb-initrd

   image = /boot/rain.gpxe
  label = gpxe
  fallback = default

When I run a "lilo" and keep the output of "strings /boot/map" and then
run "lilo -R rescue" and compare it with the saved stings output, then I
can see an additional "rescue" string. Likewise, the commandline I enter
with lock ends up in /boot/map (e.g. "rescue abc lock"), so storing the
commandline seems to work, but booting form it does not.

Thanks for still maintaining lilo, btw., it's much appreciated for its
stability and options such as fallback.

Greetings,
Marc

Bug#841532: libgit2 update in debian fixing #841532

[Russell Sim]

Hey Andreas,

I should be fine to do it.  I'm currently in a different city and didn't
take my laptop with me.  I'll be back on the 1st Jan and can push up 0.24.5
with your patch applied easily before the 5th.  I originally was not
considering that patch because I didn't think that it would make it past
freeze.  But it appears that my assumption was mistaken.  Thanks for
prodding me

I'll wait until after the full freeze to package and push 0.25.0 to
experimental.

Thanks,
Russell

On 28 December 2016 at 00:27, Andreas Henriksson  wrote:

> Hello Russell Sim.
>
> Wanted to check with you if you have any plans to deal with
> debian bug #841532 in the libgit2 package soon?
> My (quite trivial) patch went in upstream and is sitting
> in the master branch.
> https://github.com/libgit2/libgit2/commit/23c9ff8632d8ae90d211601d3254ab
> 7f4d35e853.patch
>
> Do you want some help?
>
> I was thinking I could help you out with updating to 0.24.5 (since 0.25.0
> release seems to have broken API/ABI and we're past transition freeze)
> and also pull in the above mentioned patch to fix the GMT-14 issue.
>
> Just tell me if you want to work on this or if you want my help.
>
> Regards,
> Andreas Henriksson
>

Bug#845196: imagemagick 8:6.8.9.9-5+deb8u6 still vulnerable to Bug#845196

[Salvatore Bonaccorso]

Hi,

On Tue, Dec 27, 2016 at 04:32:02PM -0500, Antoine Beaupré wrote:
> On 2016-12-27 00:52:06, Salvatore Bonaccorso wrote:
> > Hi Antonie and Bastien,
> >
> > On Tue, Dec 20, 2016 at 02:58:21PM -0500, Antoine Beaupré wrote:
> >> Hi secteam,
> >> 
> >> I believe the fix for bug#845196 shipped with DSA-3726-1 is incomplete,
> >> at least in stable. It does ship with this patch:
> >> 
> >> https://github.com/ImageMagick/ImageMagick/commit/1be809ae06f2fcb094836960edb707f81422e964
> >> 
> >> but not this one:
> >> 
> >> https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
> >> 
> >> so it is missing one fputc check in convert.
> >> 
> >> On 2016-12-20 13:34:03, Bastien Roucaries wrote:
> >> > Please reopen and.notify sécurity team
> >> 
> >> The bug report is actually still opened in stable, according to the BTS,
> >> so I don't believe a change is required there. I have removed the fixed
> >> marker from the security tracker and added a relevant note.
> >
> > So for reference, CVEs were assigned for those. Actually as well one
> > more for the "fwrite issue in ReadGROUP4Image", we should fill that as
> > separate bugreport.
> >
> > CVE assignment:
> > http://www.openwall.com/lists/oss-security/2016/12/26/9
> 
> Hi!
> 
> I see that some of those CVE assigments were integrated in the security
> tracker, but I haven't reviewed them all. Am I correct in assuming that
> all this is done and I don't need to review mitre's message in detail at
> this point?

Yes, I did update the security-tracker information yesterday.

Regards,
Salvatore

Bug#849523: couriergrey needs to be updated for changes in courier-mta

[Adam Warner]

Package: couriergrey
Version: 0.3.2-5+b1

Saw this in mail.log with courier-mta from testing:

430 Greylisting DB could not be opened currently. Please try again
later: Could not open database at /var/cache/couriergrey/deli...

A purge/reinstall of couriergrey plus the modification below appears to
be a sufficient workaround:

cd /var/cache/
chown courier:courier couriergrey/


[courier-mta now has its own `courier' user name and group]


Regards,
Adam Warner

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Adam Di Carlo]

Sebastiaan Couwenberg  writes:

>> -- Configuration Files:
>> /etc/default/nagios-nrpe-server changed:
>> USE_SSL=1
>
> Please note that the /etc/default/nagios-nrpe-server changed in
> nagios-nrpe (3.0.1-3) because of the systemd service file.
>
> The USE_SSL option is no longer used, instead the NRPE_OPTS variable is
> used to disable SSL in both the init script and systemd service file.
> The default content is now as attached.

Gotit.

I'll work my way through your instructions, attempt to fix my interop
issue.  Its always *overconfiguration* that gets me.

Thank you for taking the time to help!


However, no matter my legacy misconfig, isn't it still problematic to
segfault like this?  Let me know if a backtrace would help.

-- 
...Adam Di Carlo......

Bug#849522: ITP: gnome-shell-extension-radio -- GNOME shell extension for listening to internet radio streams

[leo]

Package: wnpp
Severity: wishlist
Owner: Léo Andrès 

* Package name : gnome-shell-extension-radio
Version : 1.3
Upstream Author : hslbck
* URL : http://www.some.org/
* License : GPL
Description : GNOME shell extension for listening to Internet radio 
streams
 A GNOME shell extension for listening to Internet radio streams. Main 
features
 are: search online radio directory, manage radio station list, mark 
stations as
 favourites, support for multimedia keys (play/stop, next/prev) and 
title

 notification.

This is my first debian package, I'll need a sponsor. Current version is 
available on GitLab: 
https://gitlab.com/zapashcanon/gnome-shell-extension-radio-packaging/tree/master/debian 
; but I don't mind having to maintain it somewhere else.

Bug#849365: libphp-phpmailer: CVE-2016-10033

[Salvatore Bonaccorso]

On Mon, Dec 26, 2016 at 10:54:47AM +0100, Salvatore Bonaccorso wrote:
> Source: libphp-phpmailer
> Version: 5.2.9+dfsg-2
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> Hi,
> 
> the following vulnerability was published for libphp-phpmailer.
> 
> CVE-2016-10033[0]:
> remote code execution

Further analysis of the fix via
https://github.com/PHPMailer/PHPMailer/commit/4835657cd639fbd09afd33307cef164edf807cdc
has shown that this fix might be incomplete. See

http://www.openwall.com/lists/oss-security/2016/12/28/1

for further details.

Regards,
Salvatore

Bug#849439: imagemagick: CVE-2016-10062: fwrite issue in ReadGROUP4Image

[Salvatore Bonaccorso]

Hi Bastien,

On Tue, Dec 27, 2016 at 11:42:12PM +0100, Bastien ROUCARIES wrote:
> I suppose experimental version is immune ?

Just checked. AFAICT, as well in version 8:6.9.7.0+dfsg-1 as right now
in experimental, there is still no error handling for the fwrite's in
ReadGROUP4Image.

I added a comment to
https://github.com/ImageMagick/ImageMagick/issues/196

Regards,
Salvatore

Bug#849521: RFS: rutorrent/3.7-1 [ITP] -- A front-end for the rTorrent torrent client

[Taylor Kline]

Package: sponsorship-requests
Severity: wishlist

Hello fine mentors,

I am looking for a sponsor for "rutorrent"

Package name: rutorrent
Version : 3.7-1
Upstream Author : Novik 
URL : https://github.com/Novik/ruTorrent
License : GPL-3
Section : net

---

It installs the files for the front-end in:

  /etc/ruTorrent  - server files

  /usr/share/ruTorrent  - user-set configuration files chmod'd to a+rwX

I also provided a detailed manpage for the configuration, including how to
configure from scratch using nginx.

lintian is throwing the following 'serious' errors that I haven't been
entirely sure what to do with:

  jquery.flot.js source missing - this file has an inlined function of 3134
characters. Unfortunately this cannot be corrected in a straightforward
manner because the flot library has not been maintained since 2014.

The other two errors are because the source files have lines longer than
expected (288 characters and 553 characters), but these are just long lines.

I also was not able to create an override for any of these lintian errors;
overriding any of these generated an error that source-is-missing was
expecting binary files and I gave it source files.

There are also a few warnings about using embedded js libraries. The
versions included are much older than the libjs versions available in the
Debian packaging system. Thus it may take some conversations with upstream
to integrate these wishlist items.

I am also experiencing a small error with 'watch.' uscan -vv outputs:

  uscan debug: Checking href :S2EngEditor.zip
  uscan debug: Checking href :S2SteamPatch.zip
  uscan debug: Checking href :plugins-3.6.tar.gz
  uscan debug: Checking href :plugins/
  uscan debug: Checking href :ruTorrent-3.7.zip
  uscan debug: Checking href :rutorrent-3.6.tar.gz
  uscan warn: In debian/watch no matching files for watch line
https://dl.bintray.com/novik65/generic/
ru[tT]orrent[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)

I'm not sure why:
  ru[tT]orrent@ANY_VERSION@@ARCHIVE_EXT@
would not match any of these files.

---

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/r/rutorrent/rutorrent_3.7-1.dsc

---

This closes this ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671744

---

This is my first package! I did my best to follow all policy, and I foresee
no problems continuing to maintain it!

Regards,
Taylor Kline

Bug#849520: jq: diff for NMU version 1.5+dfsg-1.2

[Harlan Lieberman-Berg]

Package: jq
Version: 1.5+dfsg-1.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for jq (versioned as 1.5+dfsg-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru jq-1.5+dfsg/debian/changelog jq-1.5+dfsg/debian/changelog
--- jq-1.5+dfsg/debian/changelog2016-11-13 19:48:12.0 -0500
+++ jq-1.5+dfsg/debian/changelog2016-12-27 19:04:39.0 -0500
@@ -1,3 +1,12 @@
+jq (1.5+dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix double-build failure. (Closes: #802218)
+  * Add new packages for jq library (Closes: #833213)
+  * Correct description to be more accurate (Closes: #824810)
+
+ -- Harlan Lieberman-Berg   Tue, 27 Dec 2016 19:04:39 
-0500
+
 jq (1.5+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru jq-1.5+dfsg/debian/control jq-1.5+dfsg/debian/control
--- jq-1.5+dfsg/debian/control  2016-11-26 20:54:42.0 -0500
+++ jq-1.5+dfsg/debian/control  2016-12-27 19:04:39.0 -0500
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Simon Elsbrock 
-Build-Depends: debhelper (>= 9), dh-autoreconf, flex, bison, valgrind [amd64 
i386], rake, ruby-ronn, libonig-dev
+Build-Depends: debhelper (>= 9), dh-autoreconf, flex, bison, libtool-bin, 
valgrind [amd64 i386], rake, ruby-ronn, libonig-dev
 Standards-Version: 3.9.6
 Homepage: https://github.com/stedolan/jq
 Vcs-Git: git://anonscm.debian.org/users/else-guest/jq.git
@@ -18,7 +18,7 @@
  the same ease that sed, awk, grep and friends let you
  play with text.
  .
- It is written in portable C, and it has zero runtime
+ It is written in portable C, and it has minimal runtime
  dependencies.
  .
  jq can mangle the data format that you have into the
@@ -26,18 +26,17 @@
  program to do so is often shorter and simpler than
  you’d expect.
 
-Package: libjq-dev
+Package: libjq1
 Architecture: any
-Multi-Arch: foreign
-Section: libdevel
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: development files for jq, the lightweight JSON processor
+Description: lightweight and flexible command-line JSON processor - shared 
library
  jq is like sed for JSON data – you can use it to slice
  and filter and map and transform structured data with
  the same ease that sed, awk, grep and friends let you
  play with text.
  .
- It is written in portable C, and it has zero runtime
+ It is written in portable C, and it has minimal runtime
  dependencies.
  .
  jq can mangle the data format that you have into the
@@ -45,19 +44,20 @@
  program to do so is often shorter and simpler than
  you’d expect.
  .
- This package contains the development files for jq.
+ This package contains the shared library.
 
-Package: libjq1
-Section: libs
+Package: libjq-dev
+Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: library for jq, the lightweight JSON processor
+Description: lightweight and flexible command-line JSON processor - 
development files
  jq is like sed for JSON data – you can use it to slice
  and filter and map and transform structured data with
  the same ease that sed, awk, grep and friends let you
  play with text.
  .
- It is written in portable C, and it has zero runtime
+ It is written in portable C, and it has minimal runtime
  dependencies.
  .
  jq can mangle the data format that you have into the
@@ -65,4 +65,4 @@
  program to do so is often shorter and simpler than
  you’d expect.
  .
- This package contains the library for jq.
+ This package contains the development files.
diff -Nru jq-1.5+dfsg/debian/docs jq-1.5+dfsg/debian/docs
--- jq-1.5+dfsg/debian/docs 2016-11-13 19:27:52.0 -0500
+++ jq-1.5+dfsg/debian/docs 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README
diff -Nru jq-1.5+dfsg/debian/jq.docs jq-1.5+dfsg/debian/jq.docs
--- jq-1.5+dfsg/debian/jq.docs  1969-12-31 19:00:00.0 -0500
+++ jq-1.5+dfsg/debian/jq.docs  2016-12-27 19:00:48.0 -0500
@@ -0,0 +1,2 @@
+README
+AUTHORS
diff -Nru jq-1.5+dfsg/debian/jq.install jq-1.5+dfsg/debian/jq.install
--- jq-1.5+dfsg/debian/jq.install   2016-11-26 20:54:20.0 -0500
+++ jq-1.5+dfsg/debian/jq.install   2016-12-27 19:00:48.0 -0500
@@ -1,3 +1,2 @@
 usr/bin/jq
 usr/share/man/man1/jq.1
-usr/share/doc/jq
\ No newline at end of file
diff -Nru jq-1.5+dfsg/debian/libjq1.install jq-1.5+dfsg/debian/libjq1.install
--- jq-1.5+dfsg/debian/libjq1.install   2016-11-26 20:52:58.0 -0500
+++ jq-1.5+dfsg/debian/libjq1.install   2016-12-27 19:00:48.0 -0500
@@ -1 +1 @@
-usr/lib/*/lib*.so.*
\ No newline at end of file
+usr/lib/*/libjq.so.*
diff -Nru jq-1.5+dfsg/debian/libjq-dev.install 
jq-1.5+dfsg/debian/libjq-dev.install
--- jq-1.5+dfsg/debian/libjq-dev.install2016-11-26 20:50:06.0 
-0500
+++ jq-1.5+dfsg/debian/libjq-dev.install2016-12-27 

Bug#849519: dput: make unknown-character signature emit more explicit message

[Ben Finney]

Package: dput
Version: 0.11.0
Severity: normal

When ‘dput’ encounters an unknown result from checking a GnuPG
signature, the message is misleading.

gpgme: ./gpick/gpick_0.2.5+git20161221-1_i386.changes: Unknown signature 
from C9F1CBF56351F719

With “Unknown signature from […]” an obvious inference would be that
the signature is unknown. This is incorrect; it is the *result from
the function call* that is unrecognised.

The message should explicitly signal that ‘dput’ did not recognise the
result.

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849518: dvdisaster: Add support for BD-ROM media-type

[Corey Wright]

Package: dvdisaster
Version: 0.72.4-1
Severity: minor
Tags: patch

The attached patch adds support to dvdisaster for the BD-ROM
media-type.  This allows dvdisaster to scan and read (ie create ISO
images of) BD-ROM media.

Corey
--
undefi...@pobox.com
diff -urNpd dvdisaster-0.72.1~/scsi-layer.c dvdisaster-0.72.1/scsi-layer.c
--- dvdisaster-0.72.1~/scsi-layer.c	2016-09-24 14:04:44.0 -0500
+++ dvdisaster-0.72.1/scsi-layer.c	2016-09-24 14:16:10.529774227 -0500
@@ -1008,7 +1008,7 @@ static int query_bd(DeviceHandle *dh, in
 
if(!strncmp((char*)[4+8], "BDO", 3))
{  dh->typeDescr = g_strdup("BD-ROM");
-  dh->subType = UNSUPPORTED;
+  dh->subType = BD;
}
 
if(!strncmp((char*)[4+8], "BDW", 3))

Bug#849517: bash: invalid free() - address in brk data segment

[Harlan Lieberman-Berg]

Package: bash
Version: 4.4-2
Severity: normal

Dear Maintainer,

During testing of another package, I noticed that valgrind seems to
complain about bash on pretty much any invocation.

A minimal test case is: `valgrind -- bash -c ""`

This produces errors similar to:

==32208== Invalid free() / delete / delete[] / realloc()
==32208==at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==32208==by 0x465B27: ??? (in /bin/bash)
==32208==by 0x465F4F: run_unwind_frame (in /bin/bash)
==32208==by 0x485B66: parse_and_execute (in /bin/bash)
==32208==by 0x41F680: ??? (in /bin/bash)
==32208==by 0x421531: main (in /bin/bash)
==32208==  Address 0x422f258 is in the brk data segment 0x4225000-0x423bfff

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bash depends on:
ii  base-files   9.7
ii  dash 0.5.8-2.3
ii  debianutils  4.8.1
ii  libc62.24-8
ii  libtinfo56.0+20161126-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#849516: virtualbox: crash after install driver

[treaki]

Package: virtualbox
Version: 5.1.8-dfsg-6~bpo8+2
Severity: important

Dear Maintainer,


   * What led up to the situation?
installed vbox 5 through backports, updated the vm tools inside my win7 vm
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
install vmware tools with directx support
   * What was the outcome of this action?
crash of the vm:
0:33:08.041540 NAT: DHCP offered IP address 10.0.2.15
00:41:53.049722 Guest Additions capability report: (0x5 -> 0x0) seamless: no, 
hostWindowMapping: no, graphics: no
00:41:56.551529 Guest Additions capability report: (0x0 -> 0x1) seamless: yes, 
hostWindowMapping: no, graphics: no
00:41:56.551745 Guest Additions capability report: (0x1 -> 0x5) seamless: yes, 
hostWindowMapping: no, graphics: yes
00:46:03.243920 Stopping the host clipboard service
00:46:03.243952 ClipStopX11: stopping the shared clipboard X11 backend
00:46:03.244056 Shared clipboard: shared clipboard thread terminated 
successfully
00:46:03.245727 Guest Additions capability report: (0x5 -> 0x0) seamless: no, 
hostWindowMapping: no, graphics: no
00:47:38.446982 Guest requests the VM to be turned off
00:47:38.447048 Changing the VM state from 'RUNNING' to 'POWERING_OFF'.
00:47:38.447068 ** Guest state at power off **
00:47:38.447074 Guest CPUM (VCPU 0) state: 
00:47:38.447079 rax=7f50e08c rbx=fa800230e08c rcx=fa800230e08c 
rdx=d020
00:47:38.447087 rsi=fa80019b1980 rdi=0006 r8 =fa80019b1a98 
r9 =fa80019b1980
00:47:38.447093 r10= r11=7f50e08c r12= 
r13=f8000279ce00
00:47:38.447097 r14= r15=f8b96080
00:47:38.447099 rip=f880012062b8 rsp=f880009e4c30 rbp= 
iopl=0 nv up ei pl nz na po nc
00:47:38.447104 cs={0010 base= limit= flags=209b}
00:47:38.447107 ds={002b base= limit= flags=c0f3}
00:47:38.447109 es={002b base= limit= flags=c0f3}
00:47:38.447111 fs={0053 base=fffe limit=3c00 flags=40f3}
00:47:38.447114 gs={002b base=f800027fcd00 limit= flags=c0f3}
00:47:38.447117 ss={ base= limit= flags=0001c000}
00:47:38.447119 cr0=80050031 cr2=0bd5b000 cr3=00187000 
cr4=06f8
00:47:38.447123 dr0= dr1= dr2= 
dr3=
00:47:38.447126 dr4= dr5= dr6=0ff0 
dr7=0400
00:47:38.447129 gdtr=f8b95000:007f  idtr=f8b95080:0fff  
eflags=0246
00:47:38.447133 ldtr={ base= limit= flags=0001c000}
00:47:38.447135 tr  ={0040 base=f8b96080 limit=0067 flags=008b}
00:47:38.447138 SysEnter={cs= eip= esp=}
00:47:38.447141 FCW=027f FSW=3800 FTW=0080 FOP=0301 MXCSR=1f80 
MXCSR_MASK=
00:47:38.447144 FPUIP=0268d214 CS=f800 Rsrvd1=  FPUDP=0210ae00 DS=f880 
Rsvrd2=
00:47:38.447148 ST(0)=FPR7={4008'9fc0'} t1 
+1.0002287828610704211968 ^ 16392
00:47:38.447154 ST(1)=FPR0={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447160 ST(2)=FPR1={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447165 ST(3)=FPR2={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447170 ST(4)=FPR3={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447174 ST(5)=FPR4={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447179 ST(6)=FPR5={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447184 ST(7)=FPR6={4008'9fc0'} t0 
+1.0002287828610704211968 ^ 16392
00:47:38.447189 XMM0 =5e2252b2'3f7afe15'f42e68ff'9fad61e3  XMM1 
=003d0065'0070006f'00630053'006e006f
00:47:38.447197 XMM2 =00220053'00780053'006e006f'006e0022  XMM3 
=0079'0079'0079'0079
00:47:38.447202 XMM4 =004b0063'0069006c'00620075'00700020  XMM5 
=003d006e'0065006b'006f0054'00790065
00:47:38.447208 XMM6 ='''  XMM7 
='''
00:47:38.447213 XMM8 ='''  XMM9 
='''
00:47:38.447218 XMM10='''  
XMM11='''
00:47:38.447222 XMM12='''  
XMM13='''
00:47:38.447227 XMM14='''  
XMM15='''
00:47:38.447232 EFER =0d01
00:47:38.447233 PAT  =0007010600070106
00:47:38.447235 STAR =00230010
00:47:38.447237 CSTAR=f80002689380
00:47:38.447239 LSTAR=f80002689640
00:47:38.447241 SFMASK   =4700
00:47:38.447242 KERNELGSBASE =07fde000
00:47:38.447244 ***

Bug#849515: Add debian-watch-uses-insecure-uri tag (HTTP usage instead of HTTPS)

[Emanuel Bronshtein]

Subject: lintian: Add debian-watch-uses-insecure-uri tag (HTTP usage instead of 
HTTPS)
Package: lintian
Severity: wishlist

Dear Maintainer,

Add debian-watch-uses-insecure-uri tag (HTTP usage instead of HTTPS)

/debian/watch file can point to HTTP urls while HTTPS available, for example:
(from: 
https://sources.debian.net/src/texinfo/6.3.0.dfsg.1-1/debian/watch/?hl=3#L3)

opts=dversionmangle=s/\.dfsg\.\d+$// 
http://ftp.gnu.org/gnu/texinfo/texinfo-(.*)\.tar\.gz

while https://ftp.gnu.org/ is available.

list of affected packages: '13406 files grepped (14424 results)'
https://codesearch.debian.net/search?q=http%3A%2F%2F+path%3Adebian%2Fwatch
list of not affected packages: '9638 files grepped (9904 results)'
https://codesearch.debian.net/search?q=https%3A%2F%2F+path%3Adebian%2Fwatch

Bug#849288: [Pkg-zsh-devel] Bug#849288: zsh-dev: installing config.h breaks reproducibility (followup to #776964)

[Daniel Shahaf]

Axel Beckert wrote on Tue, Dec 27, 2016 at 18:21:43 +0100:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > Axel Beckert wrote on Sun, Dec 25, 2016 at 17:17:36 +0100:
> So let me recap:
> 
> * Upstream installs only header files which are marked mod_export.
>   This does not include e.g. config.h.
> 
> * config.h is needed in some cases anyways, c.f. #776964.
> 
> So after that, it looks to me (again) like an upstream issue to me:
> Upstream does not install all files necessary to compile external
> modules. http://www.zsh.org/mla/workers/2016/msg02720.html seems to
> summarize this issue rather well.

Yes, the issue should be fixed upstream.  However, that does not negate
the fact that the package is wrong to install all *.h/*.epro files
indiscriminately...

In an ideal world, upstream's "make install" puts in ${prefix}/include/zsh/
header files that contain only stuff blessed for use by modules, and the
package just uses that as-is.  Upstream's makefile does not currently
behave this way.  So, I think two distinct fixes are needed:

1) Upstream's makefile needs to install whatever third-party modules
need to be able to build outside a zsh build tree.  (That means header
files containing the appropriate subset of declarations, etc., and
possibly pkg-config files and so on.)

2) In the meantime, the package shouldn't be exposing its users to
interfaces that upstream has not labeled as "mod_export" (or the
equivalent for non-functions).  In my understanding of API's, since
findpwd() is not marked "mod_export", calling it in a module is
undefined behaviour.

What makes this hairy is that zpython's build script appears to depend
on having access to config.h, which upstream has specifically (in the
mail above the one you linked) stated is _not_ a module-facing
interface...  so anything we or upstream do to install only public
headers, is probably going to break the zpython build.  (And I'd rather
not do that; however, I do think the zpython build will have to change
at some point.)

> > > But what I currently plan to do is to use the patch from
> > > http://www.zsh.org/mla/workers/2016/msg02716.html and hence make
> > > zsh-dev reproducible again without having decided on the config.h
> > > inclusion discusssion.
> > 
> > +1, and thanks.  I'll push it upstream soon.
> 
> Planned to import that, but got confused, as patch thinks that patch
> is already applied:
> 
> → GET http://www.zsh.org/mla/workers/2016/msg02716.html | tail -53 | head -27

For future reference, the mbox-formatted messages are available
directly:

http://www.zsh.org/mla/zsh-workers/40232

> I don't get why patch thinks that the patch is already applied. It's
> clearly not. Anyone an idea here?

The diff did not apply to your working tree:

% diff -U0 =(GET http://www.zsh.org/mla/workers/2016/msg02716.html | tail -53 | 
head -27 ) \
   =(caste http://www.zsh.org/mla/zsh-workers/40232) \
  | tail -3
@@ -14 +70 @@
--[if test `/bin/sh -c \echo '\\n'\` = \\n; 
then
+-[if test "`/bin/sh -c \"echo '\\n'\"`" = "\\n"; then

That said, I'd have expected patch(1) to create *.rej file.

> > > Would that action close this issue, too, or not? Because if zsh-dev
> > > becomes reproducible, this is mere a "we differ from upstream" issue,
> > > nothing more and not really a bug anymore, at most a wishlist item.
> > 
> > Making zsh-dev reproducible would not close this issue.
> 
> I agree. And there's currently no bug report for that reproducibility
> issue. (Not sure if opening one helps, though.)

Right, I haven't filed a separate bug for that, since I knew I was about
to fix it upstream.  I did add it to the reproducible builds' notes.git,
though.

Cheers,

Daniel

Bug#849455: dput: gpgme reports “Invalid value” when checking signature

[Ben Finney]

On 27-Dec-2016, Elías Alejandro  wrote:

> Recently I wanted to sign my package with debsign and then upload to
> debian mentors but I got an error, the steps was the following:

Thank you for providing the files needed to do the same checks.

I get different results; the error message you report doesn't appear
when I try.

The message from ‘dput’ implies that it does not recognise the result
from GPGME about the signature. So this is a valuable test case, thank
you for reporting it.


So I need to know more details about the key and signature.
Especially, I need to know what GnuPG itself says about that
signature.

Can you try to reproduce this session, in a clean chroot (so no
keyring with the public key yet) and show what results you get?

=
Script started on Wed 28 Dec 2016 13:56:00 AEDT

$ gpg1 --version
gpg (GnuPG) 1.4.21
Copyright (C) 2015 Free Software Foundation, Inc.
[…]

$ gpg1 --list-key C9F1CBF56351F719
gpg: error reading key: public key not found

$ gpg1 --verify ./gpick/gpick_0.2.5+git20161221-1_i386.changes
gpg: Signature made Wed 28 Dec 2016 08:44:36 AEDT using RSA key ID 6351F719
gpg: Can't check signature: public key not found

$ gpg1 --import ./bug-849455.pubkey.asc
gpg: keyring `/home/bignose/.gnupg/pubring.gpg' created
gpg: key 6351F719: public key "Elías Alejandro Año Mendoza " 
imported
gpg: Total number processed: 1
gpg:   imported: 1  (RSA: 1)

$ gpg1 --verify ./gpick/gpick_0.2.5+git20161221-1_i386.changes
gpg: Signature made Wed 28 Dec 2016 08:44:36 AEDT using RSA key ID 6351F719
gpg: Good signature from "Elías Alejandro Año Mendoza "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 64CF 7C59 E56B 38F0 4CA6  F861 C9F1 CBF5 6351 F719


$ gpg2 --version
gpg (GnuPG) 2.1.16
libgcrypt 1.7.3-beta
Copyright (C) 2016 Free Software Foundation, Inc.
[…]

$ gpg2 --list-key C9F1CBF56351F719
gpg: error reading key: No public key

$ gpg2 --verify ./gpick/gpick_0.2.5+git20161221-1_i386.changes
gpg: Signature made Wed 28 Dec 2016 08:44:36 AEDT
gpg:using RSA key C9F1CBF56351F719
gpg: Can't check signature: No public key

$ gpg2 --import ./bug-849455.pubkey.asc
gpg: key C9F1CBF56351F719: "Elías Alejandro Año Mendoza " not 
changed
gpg: Total number processed: 1
gpg:  unchanged: 1

$ gpg2 --verify ./gpick/gpick_0.2.5+git20161221-1_i386.changes
gpg: Signature made Wed 28 Dec 2016 08:44:36 AEDT
gpg:using RSA key C9F1CBF56351F719
gpg: Good signature from "Elías Alejandro Año Mendoza " 
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 64CF 7C59 E56B 38F0 4CA6  F861 C9F1 CBF5 6351 F719


$ exit

Script done on Wed 28 Dec 2016 14:00:39 AEDT
=

So in either case there is a clear answer: the public key is not
found, or (when the public key is in the keyring) the signature is
good. I don't know how to get the result you showed.

-- 
 \ “Leave nothing to chance. Overlook nothing. Combine |
  `\  contradictory observations. Allow yourself enough time.” |
_o__) —Hippocrates |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849514: lintian: Add homepage-uses-insecure-uri tag (HTTP uri in Homepage field)

[Emanuel Bronshtein]

Package: lintian
Severity: wishlist

Dear Maintainer,

Homepage field can point to HTTP uri, for example (from: 
https://sources.debian.net/src/libreoffice/1:5.2.4-2/debian/control/?hl=191#L191):
Homepage: http://www.libreoffice.org
while HTTPS is available for the domain: https://www.libreoffice.org

The tag will be useful even for homepages that currently don't support HTTPS, 
as HTTPS becoming the standard for the entire web (HTTP 2 require TLS)
also some browsers are working on deprecating HTTP:
'Deprecating Non-Secure HTTP' 
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
'Marking HTTP As Non-Secure'  
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
it will (hopefully) encourage upstream to support HTTPS for their website.

it looks like at least 1500 packages are affected by this:
https://codesearch.debian.net/search?q=Homepage%3A+http%3A%2F%2F+path%3Adebian%2F

Bug#798801: libkf5wallet-bin: Configuration file "//.config/kwalletd5rc" not writable

[Sandro Knauß]

Control: tags -1 +moreinfo

Hey,

can you still reproduce this issue with uptodate version?

Best Regards,

sandro

--
Am Sonntag, 13. September 2015, 09:06:46 CET schrieb Ben Hay:
> Package: libkf5wallet-bin
> Version: 5.13.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Logging into the desktop produces a dialog
> 
> Configuration file "//.config/kwalletd5rc" not writable".  Please
> contact your system administrator.
> 
> After login I can start and use both KDE Wallet and KWalletManager
> without seeing any errors.
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.1.0-2-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libkf5wallet-bin depends on:
> ii  libc6 2.19-19
> ii  libgcc1   1:5.2.1-17
> ii  libkf5configcore5 5.13.0-1
> ii  libkf5coreaddons5 5.13.0-1
> ii  libkf5dbusaddons5 5.13.0-1
> ii  libkf5i18n5   5.13.0-1
> ii  libkf5iconthemes5 5.13.0-1
> ii  libkf5notifications5  5.13.0-1
> ii  libkf5service55.13.0-2
> ii  libkf5wallet5 5.13.0-1
> ii  libkf5widgetsaddons5  5.13.0-1
> ii  libkf5windowsystem5   5.13.0-3
> ii  libkwalletbackend5-5  5.13.0-1
> ii  libqt5core5a  5.4.2+dfsg-9
> ii  libqt5dbus5   5.4.2+dfsg-9
> ii  libqt5gui55.4.2+dfsg-9
> ii  libqt5widgets55.4.2+dfsg-9
> ii  libstdc++65.2.1-17
> 
> libkf5wallet-bin recommends no packages.
> 
> libkf5wallet-bin suggests no packages.
> 
> -- no debconf information



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

Bug#844137: node-groove: FTBFS: Tests failures

[Felipe Sateler]

Hi all,

On 26 December 2016 at 05:08, Petter Reinholdtsen  wrote:
>
> [Felipe Sateler]
> > This suggests there is some wrong thread usage. Andrew, any idea what
> > could this be?
>
> There are several bugs that can trigger this.  For example trying to unlock an
> non-locked lock.  Using 'valgrind --tool=helgrind' make it possible to see 
> incorrect
> lock usage.

Does anyone have hardware to test this fix? It appears the problem is
not on node-groove, but on libgrooveplayer. In particular, the dummy
device thread unlocks a mutex too early when an underrun occurs, and
then later on it is unlocked again. The following diff fixes the
helgrind error (but leaves plenty of other possible data race
warnings):

diff --git a/grooveplayer/player.c b/grooveplayer/player.c
index 5d2239c..ad4ad75 100644
--- a/grooveplayer/player.c
+++ b/grooveplayer/player.c
@@ -198,7 +198,7 @@ static void *dummy_thread(void *arg) {
 // track of time, we're going to pretend that we did *not*
 // just get a buffer underrun. Instead we'll wait patiently
 // for the next buffer to appear and handle it
appropriately.
-pthread_mutex_unlock(>play_head_mutex);
 break;
 }
 }

However as I cannot reproduce the error, I cannot test if this indeed
fixes the issue...


-- 

Saludos,
Felipe Sateler

Bug#810506: Upload of linux-grsec to jessie-backports?

[anarcat]

On Mon, Apr 25, 2016 at 08:19:42AM +0200, Yves-Alexis Perez wrote:
> On lun., 2016-04-25 at 05:45 +, Amarildo Júnior wrote:
> > Any news?
> 
> Stay tuned? As already said I was waiting on the kernel to become eligible for
> migration. This happened two days ago, so I'll prepare a jessie-backport
> upload. But you're not forced to stop breathing in the meantime.

It's been a few months and the package is still not in stretch, partly
because of this bug (but also because of #835949).

It is also considered bad practice to upload a package to backports if
it is not in testing yet, especially if it's destined to be packaged
there...

It would be great to settle this before the stretch freeze, which is
coming real soon now (soft freeze on jan 5th would block this, iirc):

https://release.debian.org/

A.

-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein


signature.asc
Description: Digital signature

Bug#846459: another NMU

[Adam Borowski]

Helmut Grohne wrote:
> Control: reopen -1
> The "libfl-dev:native" dependency is still missing.

My upload fixed the FTBFS, leaving a FT-cross-BFS, which is not RC.

Still, I understand how much bootstrap guys hate such failures, especially
on an essential package.  As apparently Steve are totally out of tuits,
here's another NMU.  I'm uploading to DELAYED/7.  Debdiff attached.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11
diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,11 @@
+pam (1.1.8-3.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on libfl-dev:native as well, for cross builds.
+Re-closes: #846459
+
+ -- Adam Borowski   Tue, 20 Dec 2016 06:57:40 +0100
+
 pam (1.1.8-3.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u pam-1.1.8/debian/control pam-1.1.8/debian/control
--- pam-1.1.8/debian/control
+++ pam-1.1.8/debian/control
@@ -4,7 +4,7 @@
 Uploaders: Sam Hartman , Roger Leigh 
 Maintainer: Steve Langasek 
 Standards-Version: 3.9.8
-Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, 
docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
+Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, 
libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
 Build-Conflicts-Indep: fop
 Build-Conflicts: libdb4.2-dev, libxcrypt-dev
 Vcs-Bzr: https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid

Bug#849512: reportbug: claims that "APT prefers unstable-debug"

[Adam Borowski]

Package: reportbug
Version: 7.1.1
Severity: minor

Hi!
If a $RELEASE-debug apt source has been configured, reportbug claims that
it's the preferred one.  Obviously, the message should point at "unstable".


Meow!
-- Package-specific info:
** Environment settings:
EDITOR="jstar"
EMAIL="kilob...@angband.pl"
INTERFACE="text"

** /home/kilobyte/.reportbugrc:
reportbug_version "3.17"
mode advanced
ui text

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.1
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.1.3
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88-2
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.5-1
pn  gir1.2-vte-2.91
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

-- no debconf information

Bug#849513: binary package name "ninja" is up for grabs

[Adam Borowski]

Package: ninja-build
Version: 1.7.2-1
Severity: wishlist

Hi!
The privilege escalation detector "ninja" has been removed.  This means, you
can claim the package name.

It is too late to do so for stretch, it would also be a bad idea to grab the
name without letting users of that old package have a release cycle to
notice it got removed.

But, once the freeze is over, the name is yours!


Meow.
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#728993: [BANNED]: Parcel #0000322994 shipment problem, please review

[FedEx Ground]

Atención: Este mensaje contenía uno o más anexos que han sido eliminados
Atención: (Item-Delivery-Details-322994.zip, 
Item-Delivery-Details-322994.doc.wsf).
Atención: Por favor, lea el(los) anexo(s) "VirusWarning.txt" para más 
información.

Dear Customer,



We can not deliver your parcel arrived at December 27.



You can download the shipment label attached!



With thanks and appreciation,

Joe Hurst,

Chief Station Manager.

Este es un mensaje del Servicio de Protección de Virus para Correo
Electrónico MailScanner
--
Se considera que el archivo anexado original 
"Item-Delivery-Details-322994.zip"
ha sido infectado por un virus y por ello, ha sido 
reemplazado por este mensaje de aviso.

Debido a las limitaciones que nos afectan por el Acta de Regulación
de Poderes de Investigación de 2000 en algunos países, no podemos
mantener una copia del anexo original.

El Wed Dec 28 02:12:02 2016 el analizador de virus dijo:
   Windows Script Host files are dangerous in email 
(Item-Delivery-Details-322994.doc.wsf)

-- 
Postmaster

Bug#849484: libavformat57 has circular Depends on libchromaprint1

[James Cowgill]

Control: forwarded -1 https://bitbucket.org/acoustid/chromaprint/pull-requests/8

Hi,

On 28/12/16 00:16, Andreas Cadhalpun wrote:
> Control: reassign -1 libchromaprint1 1.4.1-1
> Control: severity -1 serious
> 
> Hi Bill,
> 
> On 27.12.2016 19:06, Bill Allombert wrote:
>> There is a circular dependency between libavformat57 and libchromaprint1:
>>
>> libavformat57:Depends: libchromaprint1 (>= 1.3.2)
>> libchromaprint1  :Depends: libavformat57 (>= 7:3.2.2)
>>
>> Circular dependencies involving shared libraries are known to cause problems
>> during upgrade between stable releases, so we should try to avoid them.
> 
> Thanks for catching that.
> 
> Libavformat uses libchromaprint since version 7:3.0-1, while libchromaprint
> started linking libavformat only in the last uploaded version 1.4.1-1.
> Previously only libchromaprint-tools used libavformat.
> 
> While it would be easy to disable chromaprint support in ffmpeg, that
> would be a feature regression, so I'd rather not do that.
> 
> Hence I'm reassigning this to chromaprint.
> As this is not the time in the release cycle to let such issues slip
> into testing, I'm raising the severity to serious to prevent testing
> migration of the new chromaprint, until this issue is solved.
> 
> Now the question is, why did libchromaprint start using libavformat?
> Can this functionality be moved to libchromaprint-tools or at least
> be disabled?

libchromaprint.so.1 doesn't seem to use any symbols from libavformat,
so it should not link to it. I submitted a simple PR upstream to fix it.

In the meantime, the Debian package could just link with
-Wl,--as-needed to avoid having to patch anything.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#849511: general: java and javac can't run , it said "java: error while loading shared libraries: libjli.so",

[Jason.katcom]

Package: general
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



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

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

Bug#849510: ruby-parallel: FTBFS (failing tests)

[Santiago Vila]

Package: src:ruby-parallel
Version: 1.9.0-1
Severity: serious

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]

Pending: (Failures listed here are expected and do not affect your suite's 
status)

  1) Parallel.in_processes kills the processes when the main process gets 
killed through ctrl+c
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:85

  2) Parallel.in_processes kills the processes when the main process gets 
killed through a custom interrupt
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:92

  3) Parallel.in_processes kills the threads when the main process gets killed 
through ctrl+c
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:98

  4) Parallel.in_processes does not kill processes when the main process gets 
sent an interrupt besides the custom interrupt
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:105

  5) Parallel.in_processes does not kill threads when the main process gets 
sent an interrupt besides the custom interrupt
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:114

  6) Parallel.in_processes does not kill anything on ctrl+c when everything has 
finished
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:123

  7) Parallel.in_processes preserves original intrrupts
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:135

  8) Parallel.in_processes does not open unnecessary pipes
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:174

  9) Parallel.map can be killed instantly
 # Temporarily skipped with xit
 # ./spec/parallel_spec.rb:370

Failures:

  1) Parallel.map saves time
 Failure/Error:
   time_taken{
   `ruby spec/cases/parallel_map_sleeping.rb`
   }.should <= 3.5

   expected: <= 3.5
got:4.040697336196899
 # ./spec/parallel_spec.rb:205:in `block (3 levels) in '

  2) Parallel.map starts new process imediatly when old exists
 Failure/Error:
   time_taken{
   `ruby spec/cases/parallel_map_uneven.rb`
   }.should <= 3.5

   expected: <= 3.5
got:4.034336805343628
 # ./spec/parallel_spec.rb:219:in `block (3 levels) in '

Finished in 45.2 seconds (files took 0.07625 seconds to load)
112 examples, 2 failures, 9 pending

Failed examples:

rspec ./spec/parallel_spec.rb:202 # Parallel.map saves time
rspec ./spec/parallel_spec.rb:216 # Parallel.map starts new process imediatly 
when old exists

/usr/bin/ruby2.3 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
documentation failed
ERROR: Test "ruby2.3" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-parallel 
returned exit code 1
debian/rules:15: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


The build was made in a QEMU/KVM virtual machine with a single CPU, using 
sbuild.

To be sure, I repeated the build several times.

I tried 11 times in total, in 6 different machines, and it always failed.
I've put the build logs here:

https://people.debian.org/~sanvila/ruby-parallel/

Maybe the author did not try this at all in a single CPU machine, or maybe
he/she believes all CPUs have the same speed.

Thanks.

Bug#849458: cannot upgrade imagemagick-6-common

[積丹尼 Dan Jacobson]

$ apt-cache policy imagemagick-6-common
imagemagick-6-common:
  Installed: 8:6.9.6.6+dfsg-1
  Candidate: 8:6.9.7.0+dfsg-1
  Version table:
 8:6.9.7.0+dfsg-1 990
990 http://free.nchc.org.tw/debian experimental/main amd64 Packages
 *** 8:6.9.6.6+dfsg-1 500
500 http://free.nchc.org.tw/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

Bug#849509: popularity-contest installed momentarily even if user says No

[積丹尼 Dan Jacobson]

Package: installation-reports

Using
DISTRIB_RELEASE="9 (stretch) - installer build 20161212-00:04"
the user chooses "No", the default, to the popularity-contest question.

He notices through the corner of his eye, something about the package
flashing by on the screen anyway!

Indeed the logs expose the fact that the package is installed then
removed right away.

One big no-op!

Please don't install it in the first place if the user has said No.

Dec 25 23:38:10 in-target: The following NEW packages will be installed:
Dec 25 23:38:10 in-target:   popularity-contest
Dec 25 23:38:10 in-target: 0 upgraded, 1 newly installed, 0 to remove and 0 not 
upgraded.
Dec 25 23:38:10 in-target: Need to get 0 B/70.6 kB of archives.
Dec 25 23:38:10 in-target: After this operation, 179 kB of additional disk 
space will be used.
Dec 25 23:38:10 in-target: Get:1 cdrom://[Debian GNU/Linux testing _Stretch_ - 
Official Snapshot amd64 NETINST Binary-1 20161212-05:24] stretch/main amd64 
popularity-contest all 1.64 [70.6 kB]
Dec 25 23:38:10 in-target: Preconfiguring packages ...
Dec 25 23:38:14 in-target: Selecting previously unselected package 
popularity-contest.
Dec 25 23:38:14 in-target: ^M
Dec 25 23:38:14 in-target: (Reading database ...
Dec 25 23:38:14 in-target: 15048 files and directories currently installed.)
Dec 25 23:38:14 in-target: Preparing to unpack 
.../popularity-contest_1.64_all.deb ...
Dec 25 23:38:14 in-target: Unpacking popularity-contest (1.64) ...^M
Dec 25 23:38:14 in-target: Setting up popularity-contest (1.64) ...
Dec 25 23:38:15 in-target: (Reading database ... 15073 files and directories 
currently installed.)
Dec 25 23:38:15 in-target: Removing popularity-contest (1.64) ...
Dec 25 23:38:15 in-target: Purging configuration files for popularity-contest 
(1.64) ...
Dec 25 23:38:16 pkgsel: starting tasksel
Dec 25 23:39:30 in-target: Reading package lists...

Bug#849508: add GO BACK choice to save logs question

[積丹尼 Dan Jacobson]

Package: installation-reports

Using
DISTRIB_RELEASE="9 (stretch) - installer build 20161212-00:04"
when getting to the question about saving logs,
the user is prompted with /mnt .

At this point the user wants to GO BACK to choose "open a shell" to
inspect what places are in fact mounted.

However at this point there is no GO BACK choice, only Continue!

In fact you might check for other questions that lack GO BACK to see if
they sould have it added or not.

Bug#849284: insserv: fopen(/etc/insserv.conf): No such file or directory

[積丹尼 Dan Jacobson]

OK I have repeated the process on a new system and here are the logs.

First I installed a minimal system offline, with
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20161212-00:04"
on a USB stick.

Then I went online and installed more and more packages. Here you can
see a birds eye view,

48 matches in 26 lines for "insserv" in buffer: *compilation*
   1216:Selecting previously unselected package insserv.
   1217:Preparing to unpack .../06-insserv_1.16.0-5_amd64.deb ...
   1218:Unpacking insserv (1.16.0-5) ...
   4803:insserv: fopen(/etc/insserv.conf): No such file or directory
   5476:insserv: fopen(/etc/insserv.conf): No such file or directory
   5536:insserv: fopen(/etc/insserv.conf): No such file or directory
   5764:insserv: fopen(/etc/insserv.conf): No such file or directory
   5770:insserv: fopen(/etc/insserv.conf): No such file or directory
   5774:insserv: fopen(/etc/insserv.conf): No such file or directory
   5823:insserv: fopen(/etc/insserv.conf): No such file or directory
   5824:insserv: fopen(/etc/insserv.conf): No such file or directory
   5869:insserv: fopen(/etc/insserv.conf): No such file or directory
   5905:insserv: fopen(/etc/insserv.conf): No such file or directory
   5961:insserv: fopen(/etc/insserv.conf): No such file or directory
   6022:insserv: fopen(/etc/insserv.conf): No such file or directory
   6055:insserv: fopen(/etc/insserv.conf): No such file or directory
   6127:insserv: fopen(/etc/insserv.conf): No such file or directory
   6130:insserv: fopen(/etc/insserv.conf): No such file or directory
   6131:insserv: fopen(/etc/insserv.conf): No such file or directory
   6287:insserv: fopen(/etc/insserv.conf): No such file or directory
   6328:insserv: fopen(/etc/insserv.conf): No such file or directory
   6361:insserv: fopen(/etc/insserv.conf): No such file or directory
   6367:insserv: fopen(/etc/insserv.conf): No such file or directory
   6417:insserv: fopen(/etc/insserv.conf): No such file or directory
   6576:insserv: fopen(/etc/insserv.conf): No such file or directory
   6607:Setting up insserv (1.16.0-5) ...

of what is happening.
We see the problem only occurs between the time insserv has been
unpacked, and when it is finally set up.

After it has been set up, the problem no longer occurs, for many days
afterwards so far.

Here are the logs,



apt.log.gz
Description: *compilation* buffer

Bug#833037: [PKG-Openstack-devel] Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Thomas Goirand  writes:

> If you're supposed to maintain this package, the least you can do is
> subscribe to the package bug reports. You cannot expect bug reporters to
> manually add you in their report, nor anyone to double-guess that you
> aren't receiving emails sent to the BTS (I did thought you were
> receiving them myself).

Errr... I am not the maintainer. The maintainer is:
PKG OpenStack 

I am not part of the openstack team, and never have been.

Looking at the changelog, I have never made an upload, so really don't
know why you think I am the maintainer.

I simply reported this bug. Reporting a bug doesn't magically make me
the maintainer.

> Now, if you want to save the package for Stretch, you'll have to act
> quick. You are probably already too late for a migration of your next
> upload without asking for an unblock.

If somebody wants me to do a NMU of some random package that I do not
maintain, I really do need to asked before the freeze. I can't subscribe
to every bug report for every package just in case somebody might ask me
to do a NMU.
-- 
Brian May 

Bug#849487: /sbin/umount.nfs4: error while loading shared libraries:

[Elimar Riesebieter]

* Elimar Riesebieter  [2016-12-27 20:38 +0100]:

> Package: nfs-common
> Version: 1:1.3.4-2
> Severity: important
> 
> Either mounting or unmounting nfs shares I get:
> /sbin/umount.nfs4: error while loading shared libraries: R_PPC_REL24
> relocation at 0x205cc8ec for symbol 'time' out of range
> 
> Please note that I recognize this only on ppc32 platform which
> indeed indicates that -fPIC wasn't use on buildtime?
> 
> reverting to 1:1.3.4-2 works fine

Uuups, I meant 1:1.3.4-1.

Elimar
-- 
  The path to source is always uphill!
-unknown-

Bug#849487: /sbin/umount.nfs4: error while loading shared libraries:

[Elimar Riesebieter]

* Elimar Riesebieter  [2016-12-27 20:38 +0100]:

> Package: nfs-common
> Version: 1:1.3.4-2
> Severity: important
> 
> Either mounting or unmounting nfs shares I get:
> /sbin/umount.nfs4: error while loading shared libraries: R_PPC_REL24
> relocation at 0x205cc8ec for symbol 'time' out of range
> 
> Please note that I recognize this only on ppc32 platform which
> indeed indicates that -fPIC wasn't use on buildtime?

I've rebuild the package and set

CFLAGS += -O2 -fPIC

explicitly. So it works flawless.

Elimar
-- 
  "Talking much about oneself can also
   be a means to conceal oneself."
 -Friedrich Nietzsche

Bug#849397: Easytag mistaken for a File Manager

[James Cowgill]

Control: merge -1 849398
Control: tags -1 wontfix

Hi,

On 26/12/16 16:54, Edward Jeckyll wrote:
> Package: Easytag
> Version: 2.2.4-1
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> I installed Easytag 2.2.4-1 via the Synaptic Package Manager
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I clicked on the Home Folder icon in the Places Menu
>* What was the outcome of this action? When clicking on the Home
> Folder icon in the Places Menu it launches Easytag instead of the Caja
> File Manager
>* What outcome did you expect instead? The Caja File Manager should
> launch. This bug appears to have been in place for at least 3 years -
> see:
> http://superuser.com/questions/568161/mate-panel-opens-application-instead-of-caja

This bug comes up every so often (I think #788325 [1] was the last
time). It's caused by a combination of easytag registering a handler for
inode/directory and using a DE which does not set a default handler.

As previously discussed, easytag is not the right place to fix this bug.
Having easytag accept the 'inode/directrory' mime type is correct
because you may want to open a directory with easytag. The correct
solution is probably for MATE to register Caja as the default handler
for 'inode/directory'. I notice the package
'debian-mate-default-settings' does this, but I do not know why it uses
the global 'defaults.list' file instead of 'mate-mimeapps.list' which I
would have thought would be the right place to do this.

Thanks,
James

[1] https://bugs.debian.org/788325



signature.asc
Description: OpenPGP digital signature

Bug#849507: imagemagick-6.q16: convert generates monochrome images with inverted colors (black and white)

[Rogério Brito]

Package: imagemagick-6.q16
Version: 8:6.9.6.6+dfsg-1
Severity: normal

Hi.

I have a grayscale gif that I want to print for my son to color. In the
process, I wanted to convert it to monochrome, but, surprisingly, I got an
inverted image.

The command that I used was:

convert MINIONS-PINTAR.gif -monochrome minions-pintar-mono.png

I am attaching the problematic file to this message.

If needed, please let me know and I will try my best to supply any extra
information.


Thanks,

Rogério Brito.


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
compare:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
convert:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
composite:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
conjure:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
display:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
identify:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
import:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
montage:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org
stream:  ImageMagick 6.9.6-6 Q16 x86_64 20161125 http://www.imagemagick.org

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

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.15-1
ii  libc6  2.24-8
ii  libmagickcore-6.q16-2  8:6.9.6.6+dfsg-1
ii  libmagickwand-6.q16-2  8:6.9.6.6+dfsg-1

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.20~dfsg-1
ii  libmagickcore-6.q16-2-extra  8:6.9.6.6+dfsg-1
ii  netpbm   2:10.0-15.3+b1

Versions of packages imagemagick-6.q16 suggests:
ii  autotrace0.31.1-17
ii  cups-bsd [lpr]   2.2.1-2
ii  curl 7.50.1-1
pn  enscript 
ii  ffmpeg   7:3.2.2-1
ii  fig2dev [transfig]   1:3.2.6-3
ii  gimp 2.8.18-1
ii  gnuplot  5.0.5+dfsg1-4
pn  grads
ii  graphviz 2.38.0-16
ii  groff-base   1.22.3-9
pn  hp2xx
pn  html2ps  
pn  imagemagick-doc  
pn  libwmf-bin   
ii  mplayer  2:1.3.0-6
pn  povray   
pn  radiance 
ii  sane-utils   1.0.25-2+b1
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080-8
pn  ufraw-batch  
ii  xdg-utils1.1.1-1

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#846002: blends-tasks must not be priority:important - ballot proposal

[Sam Hartman]

Is our intent to override the maintainer or provide advice?
I don't care what the answer is but perhaps we want to be clear.
I'm fine with this ballot beyond that.
Perhaps we want to override the blends-tasks maintainers to the extent
that they disagree with the tasksel maintainers?

Bug#844134: scilab segfaults with TSX

[Adrian Bunk]

reassign 844134
reassign 844135
reassign 844138
forcemerge 844134 844135 844138
retitle 844134 scilab segfaults with TSX
affects 844134 src:scilab-ann src:scilab-plotlib src:scilab-celestlab: F
thanks

This looks like a threading bug in Scilab exposed by TSX.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#849484: libavformat57 has circular Depends on libchromaprint1

[Andreas Cadhalpun]

Control: reassign -1 libchromaprint1 1.4.1-1
Control: severity -1 serious

Hi Bill,

On 27.12.2016 19:06, Bill Allombert wrote:
> There is a circular dependency between libavformat57 and libchromaprint1:
> 
> libavformat57 :Depends: libchromaprint1 (>= 1.3.2)
> libchromaprint1   :Depends: libavformat57 (>= 7:3.2.2)
> 
> Circular dependencies involving shared libraries are known to cause problems
> during upgrade between stable releases, so we should try to avoid them.

Thanks for catching that.

Libavformat uses libchromaprint since version 7:3.0-1, while libchromaprint
started linking libavformat only in the last uploaded version 1.4.1-1.
Previously only libchromaprint-tools used libavformat.

While it would be easy to disable chromaprint support in ffmpeg, that
would be a feature regression, so I'd rather not do that.

Hence I'm reassigning this to chromaprint.
As this is not the time in the release cycle to let such issues slip
into testing, I'm raising the severity to serious to prevent testing
migration of the new chromaprint, until this issue is solved.

Now the question is, why did libchromaprint start using libavformat?
Can this functionality be moved to libchromaprint-tools or at least
be disabled?

Best regards,
Andreas

Bug#792248: tcpreplay: New upstream version available (4.0.0)

[Christoph Biedl]

Alexander List wrote...

> There is a new upstream release 4.0.0 available:

Gentle ping?

Upstream is at 4.1.2 already, contains the fix for CVE-2016-6160, builds
without problems (you can drop *all* the patches), at a quick glance
nothing got lost. Aaaand it's not too late for stretch yet.

Anything else I could do? Threaten you with a friendly takeover? :->

Christoph


signature.asc
Description: Digital signature

Bug#848764: theano: FTBFS: Test failures

[Daniel Stender]

Thanks for reporting this.

There are 3 errors and 2 failures in the tests in that build, the TypeError: 
"'numpy.float64' object cannot be interpreted
as an index" (3) points to being another problem with numpy 1.12.0.

1)

ERROR: test_infer_shape (theano.sparse.tests.test_sp2.BinomialTester)
--
Traceback (most recent call last):
  File "/<>/theano/sparse/tests/test_sp2.py", line 100, in 
test_infer_shape
self.op_class)
  File "/<>/theano/tests/unittest_tools.py", line 251, in 
_compile_and_check
numeric_outputs = outputs_function(*numeric_inputs)
  File "/<>/theano/compile/function_module.py", line 871, in 
__call__
storage_map=getattr(self.fn, 'storage_map', None))
  File "/<>/theano/gof/link.py", line 314, in raise_with_op
reraise(exc_type, exc_value, exc_trace)
  File "/<>/theano/compile/function_module.py", line 859, in 
__call__
outputs = self.fn()
  File "/<>/theano/gof/op.py", line 912, in rval
r = p(n, [x[0] for x in i], o)
  File "/<>/theano/sparse/sandbox/sp2.py", line 125, in perform
binomial = numpy.random.binomial(n, p, size=shape)
  File "mtrand.pyx", line 3764, in mtrand.RandomState.binomial 
(numpy/random/mtrand/mtrand.c:31661)
TypeError: Cannot cast array data from dtype('float64') to dtype('int64') 
according to the rule 'safe'
Apply node that caused the error: Binomial{format='csc', 
dtype='float64'}(, , 
)
Toposort index: 0
Inputs types: [TensorType(float64, scalar), TensorType(float64, scalar), 
TensorType(int64, vector)]
Inputs shapes: [(), (), (2,)]
Inputs strides: [(), (), (8,)]
Inputs values: [array(5.0), array(0.25), array([3, 5])]
Outputs clients: [['output']]

Backtrace when the node is created(use Theano flag traceback.limit=N to make it 
longer):
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 177, in __call__
return self.run(*arg, **kw)
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 224, in run
test(orig)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 45, in __call__
return self.run(*arg, **kwarg)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 133, in run
self.runTest(result)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 151, in runTest
test(result)
  File "/usr/lib/python2.7/unittest/case.py", line 393, in __call__
return self.run(*args, **kwds)
  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/<>/theano/sparse/tests/test_sp2.py", line 98, in 
test_infer_shape
[Binomial(sp_format, o_type)(*self.inputs)],

HINT: Use the Theano flag 'exception_verbosity=high' for a debugprint and 
storage map footprint of this apply node.


2)

RROR: test_op (theano.sparse.tests.test_sp2.BinomialTester)
--
Traceback (most recent call last):
  File "/<>/theano/sparse/tests/test_sp2.py", line 85, in test_op
tested = f(*self._inputs)
  File "/<>/theano/compile/function_module.py", line 871, in 
__call__
storage_map=getattr(self.fn, 'storage_map', None))
  File "/<>/theano/gof/link.py", line 314, in raise_with_op
reraise(exc_type, exc_value, exc_trace)
  File "/<>/theano/compile/function_module.py", line 859, in 
__call__
outputs = self.fn()
  File "/<>/theano/gof/op.py", line 912, in rval
r = p(n, [x[0] for x in i], o)
  File "/<>/theano/sparse/sandbox/sp2.py", line 125, in perform
binomial = numpy.random.binomial(n, p, size=shape)
  File "mtrand.pyx", line 3764, in mtrand.RandomState.binomial 
(numpy/random/mtrand/mtrand.c:31661)
TypeError: Cannot cast array data from dtype('float64') to dtype('int64') 
according to the rule 'safe'
Apply node that caused the error: Binomial{format='csc', 
dtype='float64'}(, , 
)
Toposort index: 0
Inputs types: [TensorType(float64, scalar), TensorType(float64, scalar), 
TensorType(int64, vector)]
Inputs shapes: [(), (), (2,)]
Inputs strides: [(), (), (8,)]
Inputs values: [array(5.0), array(0.25), array([3, 5])]
Outputs clients: [['output']]

Backtrace when the node is created(use Theano flag traceback.limit=N to make it 
longer):
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 177, in __call__
return self.run(*arg, **kw)
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 224, in run
test(orig)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 45, in __call__
return self.run(*arg, **kwarg)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 133, in run
self.runTest(result)
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 151, in runTest
test(result)
  File "/usr/lib/python2.7/unittest/case.py", line 393, in __call__
return self.run(*args, **kwds)
  File "/usr/lib/python2.7/unittest/case.py", 

Bug#849506: RFS: niceshaper/1.2.4-1 -- Dynamic Traffic Shaper

[Mariusz Jedwabny]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name    : niceshaper
  Version : 1.2.4-1
  Upstream Author : Mariusz Jedwabny 
* URL :http://niceshaper.jedwabny.net
* License : GPL-2
  Section : net

It builds those binary packages:

   niceshaper - Dynamic Traffic Shaper

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

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


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

   dget -x https://mentors.debian.net/debian/pool/main/n/niceshaper/nic
eshaper_1.2.4-1.dsc

More information about niceshaper can be obtained from http://niceshape
r.jedwabny.net.

Changes since the last upload:

niceshaper (1.2.4-1) unstable; urgency=medium
  * New upstream release.
    - Auto Hosts feature added.
    - Status, show, and stop commands work even if errors in global
section
      configuration are found.
    - Fix a bug where the commands status and show with --remote
parameter
      don't work if NiceShaper is not running locally.
    - Allow additional dashes within the iface directive.
    - Language fixes and updates introduced into the English
translation
      of documentation.  
  * Fix watch file to check for stable releases only.

 -- Mariusz Jedwabny   Tue, 27 Dec 2016 23:52:52
+0100


Regards,
  Mariusz Jedwabny

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Adam Di Carlo]

Sebastiaan Couwenberg  writes:

> Thanks for reporting this issue. Unfortunately I cannot reproduce it.

Oh dear.

> To help reproduce this issue, can you clarify how nagios-nrpe-server is
> configured. I assume that you configured SSL before removing the -n
> option of the nrpe daemon? Do you use a CA certificate, or
> self-signed?

Hmm, actually I left all those settings (ssl_cacert_file, ssl_cert_file,
ssl_privatekey_file) commented out.

FYI, I'm trying to interoperate with nagios-nrpe-plugin from jessie
(version 2.15-1), which doesn't seem to have any way to configure a CA
or client cert.  Any advice is welcome.

-- 
.Adam Di carloa...@debian.org.

Bug#849505: transition: nodejs

[Jérémy Lal]

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

nodejs 4.6.1~dfsg-1 provides nodejs-abi-46
nodejs 6.9.2~dfsg-1 provides nodejs-abi-48

I recently uploaded fixes to all Node.js c++ addons
so they use dh_nodejs to depend on the correct nodejs-abi-xx
provided by nodejs-dev used during build.

Transition should have minimal impact on these addons.
Most other pure Node.js modules should be okay - they either
are already compatible with Node.js 6 or have upstream updates
providing that compatibility.

Thanks,
Jérémy

Ben file:

title = "nodejs";
is_affected = .depends ~ "nodejs-abi-46" | .depends ~ "nodejs-abi-48";
is_good = .depends ~ "nodejs-abi-48";
is_bad = .depends ~ "nodejs-abi-46";

Bug#849474: consolation and kernel issue

[Adam Borowski]

On Tue, Dec 27, 2016 at 10:22:34PM +0100, Bill Allombert wrote:
> This can be automated using the attached program
> (warning, this is slightly dangerous since it copy-paste dummy text to
> the console, be careful. It is safer to use it in a X terminal since then
> the pasted text is sent to the underlying VT which is disabled, but it
> is less reliable)

My naive attempts to reproduce it on recent kernels have so far failed.

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#833037: [PKG-Openstack-devel] Bug#833037: python-factory-boy: missing depends on ipaddress

[Thomas Goirand]

On 12/27/2016 02:56 AM, Brian May wrote:
> Chris Lamb  writes:
> 
>> severity 833037 serious
>> thanks
>>
>> Surely this bug is RC severity? :)
>>
>>> I'm surprised to see no resolution within 2 months of time for such an
>>> easy bug to fix.
>>>
>>> Brian, if you don't want to take care of this package, I will ask for
>>> its removal from Debian again. I have no time for it myself.
>>
>> This might be the time :)
> 
> Errr... If somebody wants me to fix a bug, it would be really could if
> they could actually contact me. Thomas Goirand's email was never sent to
> me - the email was sent to the BTS only, not me. I have a backlog right
> now, will see what I can do.

Brian,

If you're supposed to maintain this package, the least you can do is
subscribe to the package bug reports. You cannot expect bug reporters to
manually add you in their report, nor anyone to double-guess that you
aren't receiving emails sent to the BTS (I did thought you were
receiving them myself).

Now, if you want to save the package for Stretch, you'll have to act
quick. You are probably already too late for a migration of your next
upload without asking for an unblock.

Cheers,

Thomas Goirand (zigo)

P.S: Since you're a DD, I suppose you know how to subscribe to the bugs
of a given package.

Bug#847819: [performous] update the ffmpeg and continue the issue

[Andreas Cadhalpun]

Hi Fernando,

On 24.12.2016 18:58, ftol...@docksud.com.ar wrote:
> I test in a new machine (no external repos and differnte hardware) and have 
> same issue.
> The graphics freeze and the sound continue. 
> 
> i wait if another people can reproducte it.

I suspect the issue is rather in the graphics stack than in performous itself.

Did this work for you previously?

If so, you could try using older versions of linux/mesa/Xorg/etc. to narrow down
the culprit.

Best regards,
Andreas

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

Package: nbd-server
Version: 1:3.12-1
Severity: serious
Forwarded: https://github.com/NetworkBlockDevice/nbd/issues/43

A bug was reported upstream in nbd upstream when combining copy-on-write
and multiple threads. The latter was a new feature for nbd 3.12, and the
bug was always present since that implementation of multiple threads, so
filing this bug on the version that introduced it into Debian.

We should not release Debian with this bug present; however, I don't
want to fix this right now, or 1:3.15.1-1 will miss the freeze cutoff.
I'll upload a package as soon as that version migrates to testing.

-- System Information:
Debian Release: stretch/sid
  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.8.0-2-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.59
ii  libc6  2.24-8
ii  libglib2.0-0   2.50.2-2
ii  libgnutls303.5.7-3
ii  ucf3.0036

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded

Bug#849503: python-drizzle FTBFS on 32bit: drizzle/tests/test_drizzle.py::test_square_with_point debian/rules:14: recipe for target 'test-python2.7' failed

[Adrian Bunk]

Source: python-drizzle
Version: 1.5-1
Severity: serious

https://buildd.debian.org/status/package.php?p=python-drizzle=sid

...
utest_dobox_01  PASS
utest_dobox_02  PASS
utest_dobox_03  PASS
utest_dobox_04  PASS
utest_doblot_01 ... PASS
utest_doblot_02 ... PASS



PASSED (35/35 tests in 2.060879s)
PASSED
drizzle/tests/test_drizzle.py::test_square_with_point debian/rules:14: recipe 
for target 'test-python2.7' failed
make[1]: *** [test-python2.7] Error 245
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:10: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Bug#439121: Add a .pc file for libapt-pkt

[Corentin Noël]

Hi,
Here is the correct patch to add pkg-config to apt-pkg and apt-inst.

I hope I've fixed all the requirements above.

Please note that I haven't been able to test the new test in the debian 
package.


Kind regards,
Corentin Noël
>From f14b869bc92c066693c4f36e61fb216bd4c26692 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Corentin=20No=C3=ABl?= 
Date: Sat, 29 Oct 2016 16:07:24 +0200
Subject: [PATCH] Enable PkgConfig on the apt-pkg and apt-inst libraries

---
 apt-inst/CMakeLists.txt   |  3 +++
 apt-inst/apt-inst.pc.in   | 11 +++
 apt-pkg/CMakeLists.txt|  3 +++
 apt-pkg/apt-pkg.pc.in | 10 ++
 debian/libapt-pkg-dev.install |  1 +
 debian/tests/control  |  5 +++--
 6 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 apt-inst/apt-inst.pc.in
 create mode 100644 apt-pkg/apt-pkg.pc.in

diff --git a/apt-inst/CMakeLists.txt b/apt-inst/CMakeLists.txt
index f757823..d1a 100644
--- a/apt-inst/CMakeLists.txt
+++ b/apt-inst/CMakeLists.txt
@@ -10,6 +10,8 @@ set(APT_INST_MAJOR ${MAJOR} PARENT_SCOPE)
 file(GLOB_RECURSE library "*.cc")
 file(GLOB_RECURSE headers "*.h")
 
+configure_file(apt-inst.pc.in ${CMAKE_CURRENT_BINARY_DIR}/apt-inst.pc @ONLY)
+
 # Create a library using the C++ files
 add_library(apt-inst SHARED ${library})
 
@@ -23,4 +25,5 @@ add_version_script(apt-inst)
 # Install the library and the headers
 install(TARGETS apt-inst LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR})
 install(FILES ${headers} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/apt-pkg)
+install(FILES ${CMAKE_CURRENT_BINARY_DIR}/apt-inst.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
 flatify(${PROJECT_BINARY_DIR}/include/apt-pkg/ "${headers}")
diff --git a/apt-inst/apt-inst.pc.in b/apt-inst/apt-inst.pc.in
new file mode 100644
index 000..c752f46
--- /dev/null
+++ b/apt-inst/apt-inst.pc.in
@@ -0,0 +1,11 @@
+prefix=@CMAKE_INSTALL_PREFIX@
+exec_prefix=${prefix}
+libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
+includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
+
+Name: apt-inst
+Description: deb package format runtime library
+Version: @MAJOR@.@MINOR@
+Libs: -L${libdir} -lapt-inst
+Cflags: -I${includedir}/apt-pkg
+Requires: apt-pkg
diff --git a/apt-pkg/CMakeLists.txt b/apt-pkg/CMakeLists.txt
index 25ed13e..3d58235 100644
--- a/apt-pkg/CMakeLists.txt
+++ b/apt-pkg/CMakeLists.txt
@@ -29,6 +29,8 @@ execute_process(COMMAND grep "^#define APT_PKG_RELEASE"
 message(STATUS "Building libapt-pkg ${MAJOR} (release ${MINOR})")
 set(APT_PKG_MAJOR ${MAJOR} PARENT_SCOPE) # exporting for methods/CMakeLists.txt
 
+configure_file(apt-pkg.pc.in ${CMAKE_CURRENT_BINARY_DIR}/apt-pkg.pc @ONLY)
+
 # Definition of the C++ files used to build the library
 file(GLOB_RECURSE library "*.cc"  "${CMAKE_CURRENT_BINARY_DIR}/tagfile-keys.cc")
 file(GLOB_RECURSE headers "*.h")
@@ -62,6 +64,7 @@ add_version_script(apt-pkg)
 install(TARGETS apt-pkg LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR})
 install(FILES ${headers} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/apt-pkg)
 flatify(${PROJECT_BINARY_DIR}/include/apt-pkg/ "${headers}")
+install(FILES ${CMAKE_CURRENT_BINARY_DIR}/apt-pkg.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
 
 if(CMAKE_BUILD_TYPE STREQUAL "Coverage")
   target_link_libraries(apt-pkg PUBLIC noprofile)
diff --git a/apt-pkg/apt-pkg.pc.in b/apt-pkg/apt-pkg.pc.in
new file mode 100644
index 000..ea762f6
--- /dev/null
+++ b/apt-pkg/apt-pkg.pc.in
@@ -0,0 +1,10 @@
+prefix=@CMAKE_INSTALL_PREFIX@
+exec_prefix=${prefix}
+libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
+includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
+
+Name: apt-pkg
+Description: package management runtime library
+Version: @MAJOR@.@MINOR@
+Libs: -L${libdir} -lapt-pkg
+Cflags: -I${includedir}/apt-pkg
diff --git a/debian/libapt-pkg-dev.install b/debian/libapt-pkg-dev.install
index 42e7c34..563e999 100644
--- a/debian/libapt-pkg-dev.install
+++ b/debian/libapt-pkg-dev.install
@@ -1,3 +1,4 @@
 usr/include/apt-pkg/
 usr/lib/*/libapt-inst*.so
 usr/lib/*/libapt-pkg*.so
+usr/lib/*/pkgconfig/apt-*.pc
diff --git a/debian/tests/control b/debian/tests/control
index a282584..516e1d2 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,8 +1,9 @@
-Tests: run-tests
+Tests: run-tests, autopkgtest
 Restrictions: allow-stderr
 Depends: @, @builddeps@, fakeroot, wget, stunnel4, lsof, db-util,
  gnupg (>= 2) | gnupg2,
  gnupg1 | gnupg (<< 2),
  gpgv (>= 2) | gpgv2,
  gpgv1 | gpgv (<< 2),
- libfile-fcntllock-perl, python3-apt
+ libfile-fcntllock-perl, python3-apt,
+ pkg-config
-- 
2.7.4

Bug#849455: gpgme reports “Invalid value” when checking signature

[Elías Alejandro]

I'm sorry. I've attached again.

Best regards,
Elías Alejandro

On Tue, Dec 27, 2016 at 7:26 PM, Ben Finney  wrote:
> On 27-Dec-2016, Elías Alejandro wrote:
>>
>> On Tue, Dec 27, 2016 at 5:04 PM, Ben Finney  wrote:
>> > Can you send (to this bug report) the public key you used for signing,
>> > and the resulting signed file? This will allow reproducing the
>> > behaviour.
>>
>> Ok. It's  attached.
>
> Thank you. I see a tarball of the build products, but we'll need the
> public GnuPG key; you attached an SSH key instead :-)
>
> --
>  \ “The most dangerous man to any government is the man who is |
>   `\   able to think things out for himself, without regard to the |
> _o__)  prevailing superstitions and taboos.” —Henry L. Mencken |
> Ben Finney 
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1

mQINBEuSqIQBEADA6TdVokhWf+mOZYiNsXDsDODn6yo1+i9YDQ8El10AGlja/cQP
NMgAGvXjqKrG7JVspMr7XT/cZe3G4XTzS3lF+xA/KJluvtDmdiX9PTaCENSXmJ4C
a7JcGZMK9ueckfNiglYHeNC863KePr+Sq0XkVUjVYREwRJR30R5IyhCi13KWMQa5
EWmDEqISpyrMrnsgV8vLWJtE+isUuUL99nCX/mMhIyl3mw2x/Ek7jNW6X6Gg2js1
gWV2af6OM3gCZTZhhnImYCyKNLPD36/8Zy7qLGCcuOzJcqkn81E9k5kBCLoF/MkK
bklE8HBM1SWO69e8bgLu4rIRR/Xc/7/VAdx4Jdk3QZwcHJqgx+h4MefAZI1U1p9y
mysmyUy7rWUvB0/qDJmawW9nReMR8hv4g459lnG2xoVlncXJXIn0hoiVUoFy/WhW
SCF/sapLH06Sm5Po5dIzpdl2CBPRGnHeJBii0Hl4aUmsYH3SzUBkmh9xJ5XXEaAM
CtoO6THCra0yCPB4mS/NOcGue+/1cOVcvHYatUYBthXkv7hwXHhyAUOi6tqFb4Db
eOm1trzOvtufO/r8SaddE1tDgf/UO+WctRX61PLH/l3XHo+Y8GQTdaz1cmImwQZ7
MyWeohJbs0JJKLiGO1R8O/q78m57KrBBmMmt1+P7t0KjirKcXHj2xnP3gQARAQAB
tDBFbMOtYXMgQWxlamFuZHJvIEHDsW8gTWVuZG96YSA8ZWFsbWR6QGdtYWlsLmNv
bT6JAjcEEwEIACEFAkuSqIQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQ
yfHL9WNR9xlyYg/+OMvvxB+wd0GVQKcmoQUx3YyKfJdYAefBR0wYqCWSvzrpgZ//
rUq7gFhEkokK/2O8hQOLaxWfcJQtTbXbw0aqF/G/MmrMC3PV1cpnkNY8Fa6rQfg/
bgnryVAc7ko7PCj1YleN87rmJt9vFLR4PMHG8qT0tNco/K4pcemnT0+uMeDECS7r
6HeNJX5x23humlhi8Y7oCotw9H64itWlsZGNh5Wfp69+f3GnuzPwKORIehbGb+Cv
Jfb+f9CpFWa/aEe4zqbsH3CypqOMisUhbMbaRjEd9Ol96njG6Tho+bOjgLzPjWNC
/x0EOKe+iUVrhrxuti1D7qfAr1blSUHydZdKtHa3Olmt4ms7Bgbq4qmgKHWS3KVP
U8ikBK8OpHrW0XNC9HaR9F3ARSl8N3mQD+rcdOWpj3As0SeO2pLvCxRI18DNd9gy
nyG51VNWKjxU/6kQWh/P1/sBoPcFy2vxu1usWRJSb2TS9i5liAq2XvFxn+rfIDli
7kWuh2acz/Y8SwGKUB5uDLHNJuKsrCZk7xZfP3FnkRvWtiOhVBzBHT56GajPnLPT
6jITEyrdsWKqTI0DueyuwnVdUUzb7boTof18njiCIaBA3hegQ7lSZ1b2e19VSfdX
RVqGnfyHLVd/8C3V4x2ZO+mMr2CDHonn1odXD2HcWcgFzgnWkyCErKX66Z65Ag0E
S5KohAEQANLKySwfISRdSUoafuqjysuXr5sUGVLSAFUxtOA8Kz3yCopAeN9H+6vv
eEkrNfNW7pqu8icGSALjKae4fYgffTdb58NWGPYgzhZ9auH852YwXpCu7GwruAZ5
0RHnB0StC09xWsrNqMtGZdh8PTqBDotdIwucL0ttksGCK8sHrZt4wz1l8ri/ZBCk
Ooic0kqYRHfh7lpL4nJro8QB2lu9ZVTJv6PRo/9SUenV1EehnTSsc/tDPHof2srp
qy4BCOfvn8NTG8TltmNHAuJ4FxXPgbPX0/qVE6LIrIFjG9F1tV+SqXHampqodJyo
Zd0Y9Je0kIQxhmLoAP7ZXuo48Q9HTlPukbSQ2Ep6DdSyUjA5Pvu3TrDlgtCBkCX4
C2BLOw3reK2ymV98m/aFkiELS+wGedq54pPNpv+hz9rYvKEl61DgQezTX8r9UjrF
AEF0wCk5XcY/Kf10leGLzoX7KTqfAg6E4VqaYuPmCjtkYB511034JpVtxGc7aNIz
PiqiI+1F2fAHTZMyBRyBoodcqn5zT18snYOUNievermICRR8UvMd8gM8GKsaIhaY
lY8R2UtbYdKTyzMxCwx04NMOib81HdomNTkPgy2rTx7j/1oR/pZM2YT/lchsfOw4
7q37pqzUi8acpVoFr3xxUKcBuRQ1wfI90QfgkYKxvYd4pr4SRoQNABEBAAGJAh8E
GAEIAAkFAkuSqIQCGwwACgkQyfHL9WNR9xljAw//YyHv/x6UPWZYp+t6QXFM+SqA
CXXQQim0nnMc3SM8mA0C68T8kzJQ0EefepDsl3Ue+rp+P/KmvsAOzqhjXYpCQ9+A
4uAASyeoGO/Q0s3SalIBDvaViTvO5VlCsTWCFW1/wOkV4LOJ3i0VruOnEs4wiuOR
65VXphwc4mpgtr5ErzhQmhNAxyeimXGmlkkEgh8dPJNmXmBmPToTlD4p5zGnCSla
2rhzrD1czIk7yM5/xlbjyw++3gHhe8+ceLu5TwxyOurrxIYnvXLBOZAEljbTeYU4
Ro5V6Kx9JayrtHQVSicOEQvi/KhULNbKSJ/f3XkvoD3jCNB8zEcnUt31krifuTpq
Fx+w3BUIgLa7T7c9JHoLNotKc1kvX5v/35m8MZkGcPZwI3SOcZjzPx2X2GRuwROc
kmZNdQAP4QGZBwQOmejXyWaVc1WBNMblfjJT2dyA2HkLNDYI37Oi+9UAEjyOIqki
ElJlkYMAXArFMMFeQfOx0gz8Le0Rv6VYW/TrF3Vqv1xEmJyy0kZzNbsBy5yF4NhP
rWbEwlZF+rbHycZWplFYcak7FSBzwBMGN7emFHDeYAUaGykbm+fodP7qBVwoK6CX
YkZP+gMUKn64o/B9S52XQmw847ztET6ghh4Qo+6GwWW5U/rklbeUU4LCgmidHEvc
8gniwecROQe8yt1bRJ4=
=qp3T
-END PGP PUBLIC KEY BLOCK-

Bug#849439: imagemagick: CVE-2016-10062: fwrite issue in ReadGROUP4Image

[Bastien ROUCARIES]

I suppose experimental version is immune ?

On Tue, Dec 27, 2016 at 8:42 AM, Salvatore Bonaccorso  wrote:
> Source: imagemagick
> Version: 8:6.8.9.9-5
> Severity: important
> Tags: upstream security
>
> Hi,
>
> the following vulnerability was published for imagemagick. AFAICT,
> this is not yet fixed up to the version in unstable. the CVE
> assignment is at[1] and reads as:
>
>> > Check return of write function
>> > ==
>> >
>> > Debian bug: https://bugs.debian.org/845196
>> > Reference URL: https://security-tracker.debian.org/845196
>> > Upstream commit:
>> >   - 
>> > https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
>> >   - 
>> > https://github.com/ImageMagick/ImageMagick/commit/4e914bbe371433f0590cefdf3bd5f3a5710069f9
>> > Upstream issue: https://github.com/ImageMagick/ImageMagick/issues/196
>> > Upstream version fixed: 7.0.1-10
>> >
>> > The above fixes may be incomplete, according to the upstream issue. In
>> > addition, the -6 branch seems to have an incomplete fix as well.
>>
>> Use CVE-2016-10060 for the issue fixed in 
>> 933e96f01a8c889c7bf5ffd30020e86a02a046e7.
>> Use CVE-2016-10061 for the issue fixed in 
>> 4e914bbe371433f0590cefdf3bd5f3a5710069f9.
>>
>> Use CVE-2016-10062 for the fwrite issue in ReadGROUP4Image. This was
>> specifically noted at the beginning of issues/196, but not fixed in
>> either of these commits. It is not the same as the fputc issue in
>> ReadGROUP4Image.
>
> CVE-2016-10062[0]:
> fwrite issue in ReadGROUP4Image
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-10062
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10062
> [1] http://www.openwall.com/lists/oss-security/2016/12/26/9
>
> Regards,
> Salvatore
>

Bug#849218: Build fine waiting for green light

[Bastien ROUCARIES]

Hi,

experimental build fine. Waiting for green light

I see you have setup the transition matrix

Bastien

Bug#849458: cannot upgrade imagemagick-6-common

[Bastien ROUCARIES]

I suppose you use the experimental version

On Tue, Dec 27, 2016 at 1:37 PM, 積丹尼 Dan Jacobson  wrote:
> Package: imagemagick-6-common
>
> # aptitude full-upgrade
> The following packages will be upgraded:
>   imagemagick-6-common
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 180 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
>  libmagickwand-6.q16-2 : Depends: imagemagick-6-common (= 8:6.9.6.6+dfsg-1) 
> but 8:6.9.7.0+dfsg-1 is to be installed
> The following actions will resolve these dependencies:
>
>  Keep the following packages at their current version:
> 1) imagemagick-6-common [8:6.9.6.6+dfsg-1 (now, unstable)]
>
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
>
>  Remove the following packages:
> 1) emacs25 [25.1+1-3 (now, unstable)]
> 2) libmagickwand-6.q16-2 [8:6.9.6.6+dfsg-1 (now, unstable)]
> 3) zbar-tools [0.10+doc-10+b2 (now, unstable)]
>
>  Install the following packages:
> 4) emacs25-nox [25.1+1-3 (unstable)]
>

Bug#849455: gpgme reports “Invalid value” when checking signature

[Ben Finney]

On 27-Dec-2016, Elías Alejandro wrote:
> 
> On Tue, Dec 27, 2016 at 5:04 PM, Ben Finney  wrote:
> > Can you send (to this bug report) the public key you used for signing,
> > and the resulting signed file? This will allow reproducing the
> > behaviour.
> 
> Ok. It's  attached.

Thank you. I see a tarball of the build products, but we'll need the
public GnuPG key; you attached an SSH key instead :-)

-- 
 \ “The most dangerous man to any government is the man who is |
  `\   able to think things out for himself, without regard to the |
_o__)  prevailing superstitions and taboos.” —Henry L. Mencken |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849502: [src:python-astropy] Use of embedded external libraries

[Vincent Prat]

Package: src:python-astropy
Version: 1.3-2
Severity: normal
Control: affects -1 astroquery

Astropy ships its own copies of some external libraries (ConfigObj, PLY,
pytest, Six, jQuery, DataTables) that are already available in Debian.
Debian Astropy packages should instead use the system libraries.
A consequence of this is that some CI tests of affiliated packages may
fail (see e.g.
https://ci.debian.net/data/packages/unstable/amd64/a/astroquery/20161227_173008.autopkgtest.log.gz).

Bug#849501: [python-astropy] Unable to disable remote_data test option

[Vincent Prat]

Package: python-astropy
Version: 1.3
Severity: normal
Control: affects -1 astroplan

The test option remote_data of Astropy now seems to be enabled by
default and cannot be disabled (at least easily).
This causes the tests of some Astropy affiliated packages to fail (e.g.
https://ci.debian.net/data/packages/unstable/amd64/a/astroplan/20161227_031316.autopkgtest.log.gz).

Bug#847288: libdbd-firebird-perl: FTBFS randomly (failing tests)

[Santiago Vila]

On Tue, Dec 27, 2016 at 09:28:55PM +, Damyan Ivanov wrote:

> Santiago, can you try building firebird3.0_3.0.1.32609.ds4-10 a few 
> times on a similar mix of slow/fast builders? If it fails the same, 
> I think that would indicate that the problem is in firebird3.0 and not 
> in libdbd-firebird-perl. I think upstream would find helpful if a core 
> file can be provided along the build log.

Hmm, I pass my autobuilders a distribution, a package, and a version.
Since 3.0.1.32609.ds4-10 is no longer in testing, that would
be very tricky.

However, I still keep the build logs for Bug #846025,
so I put them here, both successful and unsuccessful:

https://people.debian.org/~sanvila/firebird3.0/

Sorry, I'm not sure if that helps.

Thanks.

Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Sean Whitton]

Hello Pierre,

On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote:
> Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> > control: tag -1 +moreinfo
> > 
> > Dear Pierre,
> > 
> > Thank you for your interest in adopting this package.
> > 
> > Unfortunately, your work has not been properly integrated with what is
> > already in Debian:
> > 
> > - you marked version 0.4.74-4 as released but it was never uploaded
> 
> True. Yet, it is in the team repo.

The changelog tracks the Debian archive.  You should merge the existing
0.4.74-4 changelog entry with your changes.

> > - you haven't included the NMU 0.4.74-3.1
> 
> Actually, it is included. The commit is just hidden in the history of the
> team git repository for an unknown reason. See commit
> 53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit
> 6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog
> that has been truncated in the merge.

Sorry, my fault, thanks for fixing up the changelog in your upload.

> > - your work is not pushed to the team git repository
> 
> I have no permission to push.

Have you asked to join the team?

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

control: tag -1 +moreinfo

Dear David,

Thanks for your source package.  A few comments:

On Tue, Dec 27, 2016 at 08:04:33PM +, David Davies-Jones wrote:
>  * QA upload.
>  * New upstream release (Closes: #839027)
>  * Set maintainer to QA Group

It would be good to refer to the orphaning bug here.  E.g. "(see
#xx)".

>
>  * Converted rules to dh format
>  * Compat level 10
>  * Converted patches to quilt & refreshed

Did you change the source package format?  Please say this explicitly.

>
>  * Converted copyright to DEP-5
>  * Standards version 3.9.8

Did you have to update anything in the packaging to conform to this new
standards version?  If not, it's conventional to append "(no changes
required)".

>  * Replaced menu file with desktop

I think you mean "with a desktop file" -- and do you mean the menu file
in the debian/ directory?  Please be more explicit.

Changes missing from changelog:

- added d/clean
- stopped installing darksnow_icon.xpm

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849500: libconfig-model-dpkg-perl: improper handling of comments

[Afif Elghraoui]

Package: libconfig-model-dpkg-perl
Version: 2.087
Severity: normal

Hello,

I'm not a cme user, but I've seen as part of team uploads in my packages
before that comments in debian/control are moved away from the lines
they refer to in the process of reorganization (and inadvertently committed
without being checked).

In bringing this up, I was strongly opposed in that there is no reason for
there to be comments in debian/control. Regardless of the position taken on
this, cme does not handle comments properly: either their relative position
to the lines they refer to should be preserved, or they should be removed
altogether.

Many thanks and regards
Afif

Bug#849499: llvmlite: ERROR: test_get_host_cpu_features (llvmlite.tests.test_binding.TestMisc)

[Daniel Stender]

Source: llvmlite
Version: 0.14.0-2
Severity: serious
File: llvmlite
Justification: fails to build from source

llvmlite [1] (currently in experimental) has a test failure on some archs 
(mips, ppc64el, s390x etc.) [2]:


==
ERROR: test_get_host_cpu_features (llvmlite.tests.test_binding.TestMisc)
--
Traceback (most recent call last):
  File "/«PKGBUILDDIR»/llvmlite/tests/test_binding.py", line 237, in 
test_get_host_cpu_features
features = llvm.get_host_cpu_features()
  File "/«PKGBUILDDIR»/llvmlite/binding/targets.py", line 61, in 
get_host_cpu_features
outdict[feat[1:]] = flag_map[feat[0]]
IndexError: string index out of range


get_host_cpu_features() is defined in llvmlite/binding/targets.py:


def get_host_cpu_features():
"""
Returns a dictionary-like object indicating the CPU features for current
architecture and whether they are enabled for this CPU.  The key-value pairs
are the feature name as string and a boolean indicating whether the feature
is available.  The returned value is an instance of ``FeatureMap`` class,
which adds a new method ``.flatten()`` for returning a string suitable for
use as the "features" argument to ``Target.create_target_machine()``.
"""
with ffi.OutputString() as out:
ffi.lib.LLVMPY_GetHostCPUFeatures(out)
outdict = FeatureMap()
flag_map = {'+': True, '-': False}
for feat in str(out).split(','):
outdict[feat[1:]] = flag_map[feat[0]]
return outdict


It appears ffi.lib.LLVMPY_GetHostCPUFeatures() doesn't return anything (e.g. on 
s390x):


Python 2.7.13 (default, Dec 18 2016, 20:19:42) 
[GCC 6.2.1 20161215] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from llvmlite.binding import ffi
>>> with ffi.OutputString() as out:
... ffi.lib.LLVMPY_GetHostCPUFeatures(out)
... print(out)
... 
0


Could this be a regression from LLVM?

DS

[1] https://packages.qa.debian.org/l/llvmlite.html

[2] https://buildd.debian.org/status/package.php?p=llvmlite=experimental

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python-llvmlite depends on:
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libtinfo5  6.0+20161126-1
ii  llvm-3.8   1:3.8.1-16
ii  python 2.7.11-2
ii  python-enum34  1.1.6-1
ii  python-six 1.10.0-3
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-4

Versions of packages python-llvmlite recommends:
ii  llvmlite-doc  0.14.0-2

python-llvmlite suggests no packages.

-- no debconf information

Bug#849498: cme: Please allow "fixing" without restyling

[Afif Elghraoui]

Package: cme
Version: 1.016-1
Severity: wishlist

Hello,

For the case of team uploads (and maybe NMU's) where people like to use cme to
fix certain issues in debian/control, it would be helpful if calling cme fix
would *only* fix issues and not restyle it. If the primary maintainer is
not using cme, the uploader would have to either not use cme in this case or
take care to commit only the necessary changes, which adds extra work and
disrupts the uploader's workflow. It would be great if `cme fix` only fixed
and there was another command that would do this in addition to
restyling/reorganizing the files.

Many thanks for your consideration.

regards
Afif

Bug#849387: RFS: farmhash/0~20161014-g92e897b-1 [ITP]

[Adam Borowski]

On Tue, Dec 27, 2016 at 09:14:25AM +, lumin wrote:
> On Tue, 2016-12-27 at 05:10 +0100, Adam Borowski wrote:
> > 
> > I'm afraid that the -dev package installs a lot of cruft to /usr/share/doc/,
> > this includes all the sources and test cases for the testsuite, instructions
> > how to run the testsuite, and so on.
> > 
> > That place is meant for user documentation, or possibly examples.
> 
> Thank you for reviewing the package. Initially I was thinking of the
> convenience of shipping the docs in the -dev package but the fact shows
> the docs are somewhat mess...

There's nothing wrong with shipping docs in -dev if they don't take too much
space, or break other considerations (such as multiarch).  And here you
hardly have any actual docs: besides "NEWS" (a changelog) there's a "README"
that describes some performance notes and (irrelevant for a compiled
package) build instructions, and "Understanding_Hash_Functions" (some generic
design talk).

> I've split up those docs and examples into a separate package
> farmhash-doc, and uploaded the latest version to mentors:

I don't see why you would do that...?

What I meant is that you install a lot of cruft that doesn't appear to be
user docs at all: testsuite sources, testsuite test cases, a warning about
required syntax for the testsuite, that's it.  Nothing that's of any use to
someone who wants to use the library in his own programs rather than to make
changes in the library itself -- ie, stuff that's pointless outside a source
package.

Thus sorry if you misunderstood me, but I did not request a split, but
questioned inclusion of stuff in the docs directory (and now package).


On the other hand, I see no end-user docs, although the installed .h is
moderately easy to read.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#849495: python-crypto: CVE-2013-7459

[Salvatore Bonaccorso]

Source: python-crypto
Version: 2.6.1-5
Severity: grave
Tags: patch upstream security
Justification: user security hole
Forwarded: https://github.com/dlitz/pycrypto/issues/176

Hi,

the following vulnerability was published for python-crypto.

CVE-2013-7459[0]:
Buffer overflow

A reporducer can be found on upstream issue.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2013-7459
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7459
[1] https://github.com/dlitz/pycrypto/issues/176
[2] 
https://github.com/dlitz/pycrypto/commit/8dbe0dc3eea5c689d4f76b37b93fe216cf1f00d4
[3] https://marc.info/?l=oss-security=148280482630855=2

Regards,
Salvatore

Bug#849497: ITP: ruby-whitequark-parser -- Ruby parser written in pure Ruby

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: ruby-whitequark-parser
  Version : 2.3.3.1
  Upstream Author : Peter Zotov 
* URL : https://github.com/whitequark/parser
* License : Expat
  Programming Lang: Ruby
  Description : Ruby parser written in pure Ruby

 parser is a production-ready Ruby parser written in pure Ruby. It
 recognizes as much or more code than Ripper, Melbourne, JRubyParser
 or ruby_parser, and is vastly more convenient to use.
 .
 Among its keys features are: it provides precise source location
 reporting, it has a documented AST format which is convenient to work
 with, it parses 1.8, 1.9, 2.0, 2.1, 2.2 and 2.3 syntax with
 backwards-compatible AST formats and also parses MacRuby and
 RubyMotion syntax extensions. It also has improved clang-like
 diagnostic messages with location information.
 .
 Since it's written in pure Ruby, runs on MRI 1.8.7 or >=1.9.2, JRuby
 and Rubinius, it has excellent test coverage and the source code is
 readable and well commented.
 .
 Not to be confused with ruby_parser gem from Ryan Davis, of seattle.rb
 Ruby user group.

Needed as dependency of rubocop.
To be maintained in the Ruby team.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#849496: ITP: ruby-ast -- Ruby library for working with abstract syntax trees

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: ruby-ast
  Version : 2.3.0
  Upstream Author : Peter Zotov 
* URL : https://github.com/whitequark/ast
* License : Expat
  Programming Lang: Ruby
  Description : Ruby library for working with abstract syntax trees

 ast embraces immutability; each AST node is inherently frozen at
 creation, and updating a child node requires recreating that node
 and its every parent, recursively.
 .
 This is a design choice. It does create some pressure on
 garbage collector, but completely eliminates all concurrency
 and aliasing problems.
 .
 See also AST::Node, AST::Processor::Mixin and AST::Sexp classes for
 additional recommendations and design patterns.

Needed as a dependency of ruby-whitequark-parser.
To be maintained in the Ruby team.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#847288: libdbd-firebird-perl: FTBFS randomly (failing tests)

[Damyan Ivanov]

-=| Niko Tyni, 26.12.2016 18:32:20 +0200 |=-
> [explicitly cc'ing Damyan as the firebird3.0 maintainer; see the
>  backtraces below. Any ideas?]

Thanks, my comments are below.

> On Mon, Dec 26, 2016 at 11:07:53AM +0100, Santiago Vila wrote:
> > On Mon, Dec 26, 2016 at 02:03:25AM +0100, gregor herrmann wrote:
> > > On Sun, 25 Dec 2016 20:06:46 +0100, Santiago Vila wrote:
> > > 
> > > > The "slowness" is the inverse of the speed. My unit of measure
> > > > (i.e. slowness 1) is the speed of my i3-3217U @ 1.80GHz at home,
> > > > which was my first autobuilder.
> > > 
> > > Don't know where my laptop qualifies with
> > > model name: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
> > > :)
> > 
> > Most probably, yes.
> 
> FWIW I've tried quite a bit locally with different VM setups but I don't
> see any failures, with the underlying HW a quad-core of
> 
>  model name  : Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> 
> However, I had temporary access to a host where the original failure
> happened: t/embed-90-dbinfo.t and others get a SIGSEGV at cleanup phase,
> after passing all the tests.
> 
> Observations:
> 
> - it needs PERL_DL_NONLAZY=1 to happen
> - the gcc optimization level of DBD::Firebird XS parts doesn't affect it
> - strace makes it go away, and IIRC so does valgrind
> - there are always three threads active when it crashes; the crashing
>   thread backtrace is totally unhelpful but the main thread seems to be
>   the Firebird server unloading plugin modules or something like that

the third thread is something running a timer. It could be that the 
timer-driven code tries to access something that is being dlclose'd.

This all reminds be of #846025 (random crashes during test-like 
activity when building firebird3.0).

Santiago, can you try building firebird3.0_3.0.1.32609.ds4-10 a few 
times on a similar mix of slow/fast builders? If it fails the same, 
I think that would indicate that the problem is in firebird3.0 and not 
in libdbd-firebird-perl. I think upstream would find helpful if a core 
file can be provided along the build log.

(3.0.1.32609.ds4-10 is required sinde -11 makes the crashes in the 
"tests" non-fatal)

Another cause can be related to 
http://tracker.firebirdsql.org/browse/CORE-4508 -- fb_shutdown() 
apparently needs to be called before libfbembed is unloaded 
(dlclose'd?). DBD::FirebirdEmbedded doesn't call fb_shutdown at all.

I'll try to find time to provide a patch for DBD::Firebird 
incorporating fb_shutdown in the embedded variant that is used during 
tests. No guarantees on a timeline, sadly.

-=| Santiago Vila, 26.12.2016 17:46:52 +0100 |=-
> On Mon, Dec 26, 2016 at 06:32:20PM +0200, Niko Tyni wrote:
> 
> > FWIW I've tried quite a bit locally with different VM setups but I don't
> > see any failures, with the underlying HW a quad-core of
> > 
> >  model name  : Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> > 
> > However, I had temporary access to a host where the original failure
> > happened: t/embed-90-dbinfo.t and others get a SIGSEGV at cleanup phase,
> > after passing all the tests.
> 
> For the record, and just in case it matters, the host where we were
> able to reproduce this more or less easily was a single-CPU virtual
> machine inside a quad-core of:
> 
> model name: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz

Hmm, My laptop has Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz and my 
office PC has an quad-core AMD@3.4GHz, but still I wasn't able to 
reproduce this. Ghosts everywhere :)


-- Damyan


signature.asc
Description: Digital signature

Bug#849455: dput: gpgme reports “Invalid value” when checking signature

[Elías Alejandro]

Hello,

On Tue, Dec 27, 2016 at 5:06 PM, Ben Finney  wrote:
> On 27-Dec-2016, Elías Alejandro  wrote:
>
>> $ dput mentors gpick_0.2.5+git20161221-1_i386.changes
>> Checking signature on .changes
>> gpgme: /tmp/gpick_upload/gpick_0.2.5+git20161221-1_i386.changes: error 55: 
>> Invalid value
>> (7, 55, u'Invalid value')
>
> This implies the ‘gpgme’ library didn't like some value provided to it
> (and the library doesn't give much more information than that).
>
Yes.

>> I've tried with: debsign -pgpg2 gpick_0.2.5+git20161221-1_i386.changes
>> but I got the same "Invalid value".
>
> There is an experimental ‘dput’ built to use a different,
> better-maintained GnuPG library. Can you try again with ‘dput’ version
> “0.11.1”, which is in the Debian ‘experimental’ suite?

I've just tried with the experimental dput 0.11.1 and it works fine.
It works ok.

Best regards.
Elías Alejandro

Bug#849494: ITP: libproc-guard-perl -- process runner with RAII pattern

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libproc-guard-perl
  Version : 0.07
  Upstream Author : Tokuhiro Matsuno 
* URL : https://metacpan.org/release/Proc-Guard
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : process runner with RAII pattern

Proc::Guard runs a process, and destroys it when the calling perl script
exits.

This is useful for testing code working with e.g. server processes.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#845196: imagemagick 8:6.8.9.9-5+deb8u6 still vulnerable to Bug#845196

[Antoine Beaupré]

On 2016-12-27 00:52:06, Salvatore Bonaccorso wrote:
> Hi Antonie and Bastien,
>
> On Tue, Dec 20, 2016 at 02:58:21PM -0500, Antoine Beaupré wrote:
>> Hi secteam,
>> 
>> I believe the fix for bug#845196 shipped with DSA-3726-1 is incomplete,
>> at least in stable. It does ship with this patch:
>> 
>> https://github.com/ImageMagick/ImageMagick/commit/1be809ae06f2fcb094836960edb707f81422e964
>> 
>> but not this one:
>> 
>> https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7
>> 
>> so it is missing one fputc check in convert.
>> 
>> On 2016-12-20 13:34:03, Bastien Roucaries wrote:
>> > Please reopen and.notify sécurity team
>> 
>> The bug report is actually still opened in stable, according to the BTS,
>> so I don't believe a change is required there. I have removed the fixed
>> marker from the security tracker and added a relevant note.
>
> So for reference, CVEs were assigned for those. Actually as well one
> more for the "fwrite issue in ReadGROUP4Image", we should fill that as
> separate bugreport.
>
> CVE assignment:
> http://www.openwall.com/lists/oss-security/2016/12/26/9

Hi!

I see that some of those CVE assigments were integrated in the security
tracker, but I haven't reviewed them all. Am I correct in assuming that
all this is done and I don't need to review mitre's message in detail at
this point?

Thanks,

A.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  "Coup de cafard..."

Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64

[Stijn Segers]

Hi,

The only modification needed is actually in zpl_inode.c. You can pull 
in this patch [1] and apply it in /usr/src/zfs-0.6.5.8/module/zfs, then 
run $ sudo dpkg-reconfigure zfs-dkms.


That should fix it in the meantime.

Cheers

Stijn

[1]: http://ix.io/1Ot5

Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)

[Adam D. Barratt]

On Tue, 2016-12-27 at 16:13 -0500, Theodore Ts'o wrote:
> On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote:
> > Thankfully none of that worked. I say thankfully, because you'd have
> > given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's
> > certainly not so for release.d.o) and removed the original bug from
> > where it belongs. (The binNMU doesn't resolve the fact that the original
> > issue existed - and for some versions still exists - in e2fsprogs.)
> 
> It only exists in the versions of e2fsprogs shipping in Jessie and
> before.  So unless the SRM's think that it's worth it to fix this
> issue via a change to e2fsprogs going to proposed-updates for Jessie
> (I'm not entirely convinced but if you want me to add the Built-Using
> and ask for a update to Jessie stable, I can do that, and we can punt
> on the binNMU for e2fsck-static since it will be obsoleted by the fix
> of e2fsprogs in Debian stable.)

I already scheduled the binNMUs for the handful of architectures that I
could, in the cloned #849488. You may wish to check the architecture
list there and confirm whether any of the others were typoes or if the
three architectures mentioned are sufficient.

Regards,

Adam

Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)

[Theodore Ts'o]

On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote:
> Thankfully none of that worked. I say thankfully, because you'd have
> given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's
> certainly not so for release.d.o) and removed the original bug from
> where it belongs. (The binNMU doesn't resolve the fact that the original
> issue existed - and for some versions still exists - in e2fsprogs.)

It only exists in the versions of e2fsprogs shipping in Jessie and
before.  So unless the SRM's think that it's worth it to fix this
issue via a change to e2fsprogs going to proposed-updates for Jessie
(I'm not entirely convinced but if you want me to add the Built-Using
and ask for a update to Jessie stable, I can do that, and we can punt
on the binNMU for e2fsck-static since it will be obsoleted by the fix
of e2fsprogs in Debian stable.)

Otherwise, I plan to close the e2fsprogs bugs since it's fixed in
Debian Stretch, and with the decision not to try to address this in
Jessie, a "wontfix" for older versions of e2fsprogs.

Apologies for not adjusting the priority as part of my attempt to move
this bug to release.debian.org, but the theory was that fixing this
via a binNMU of e2fsck-static was sufficient, given how late we are in
Jessie's life cycle, and it wasn't worth trying to fix this bug in
stable.  If I'm wrong in this, and the SRM's would support/prefer to
fix this via an update to e2fsprogs in Jessie and spinning new binary
debs for all architectures, I'll stand corrected and we can go down
that route.

Cheers,

- Ted

Bug#849493: RFS: vc/1.3.0-1 [ITP]

[Aleksey Samoilov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

   Package name: vc
   Version : 1.3.0-1
   Upstream Author : Matthias Kretz
   URL :https://github.com/VcDevel/Vc
   License : BSD-3-Clause
   Section : libs

It builds those binary packages:

vc-dev - SIMD Vector Classes for C++

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

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


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

dget -xhttps://mentors.debian.net/debian/pool/main/v/vc/vc_1.3.0-1.dsc


  Changes since the last upload:

  vc (1.3.0-1) unstable; urgency=medium

  * Initial release (Closes: #846491)


  Regards,
   Aleksey Samoilov

Bug#710696: libsoup2.4: FTBFS with test failures

[Simon McVittie]

On Tue, 27 Dec 2016 at 12:22:03 +0100, Santiago Vila wrote:
> Cc:ing the submitter, who also happen to be a Release Manager.
> I wish we would not lower our standards to allow packages like
> this one to FTBFS as much as they want as a normal thing.

Speaking as a maintainer of a package whose tests intermittently fail
(ostree), I'd love to have a standard way to get test results recorded,
without partial/intermittent test failures being treated as RC or
preventing testing migration. The bugs that cause the test failure would
often not qualify to be RC if the tests weren't run at build time or
weren't hooked up to autopkgtest, but many packages' tests can only be
run at build time or have better coverage when run at that time.

> Cc:ing also Simon McVittie: I have not tested version 2.56.0-2 yet,
> sorry. Is it likely or possible that the changes in such version make
> the failing tests I experience to disappear, or are they unrelated?

Looking at the first couple of failures, a segmentation fault in a
test whose name mentions "async" seems like it might be the bug fixed
in 2.56.0-2. That bug was a lack of thread safety, and GLib APIs like
libsoup frequently use a worker thread to make a blocking operation
asynchronous; in particular it was one of at least two root causes
for ostree's tests intermittently failing.

ostree's tests are *still* intermittently failing (with a timeout,
so probably a deadlock or something, which I haven't been able to fix),
but I've made them non-fatal at build time because that isn't a
regression. I don't know whether the timeout is libsoup's fault or
ostree's fault (or something else).

S

Bug#849075: cups-filters-core-drivers: Please consider some changes to driverless(1)

[Till Kamppeter]

Fixed in upstream BZR rev. 7592.

Thank you for the bug report.

Bug#736909: where are we at with this?

[Laurent Bigonville]

Hi Russell,


Le 27/12/16 à 13:20, Russell Coker a écrit :

The lxc_contents file is in selinux-policy-default and a quick check indicates
that the policy might be ok.

What do we have to do to test it?  I can provide root on a test system to
anyone who wants to help test this.



The initial bug, the fact that libvirt is not starting is fixed at two 
different level, libvirt now checks if the lxc_context file is present 
or not before doing any SELinux operations and it's also fixed now that 
the policy ships this file.


But I just tried now (with the refpolicy) and all the processes are 
running under "system_u:system_r:virtd_lxc_t:s0-s0:c0.c1023" (not sure 
it's the one expected here), so we might have an other problem here.


My test case is quite easy, I've debootstrapped a debian unstable 
(debootstrap sid /tmp/sid). Then in virt-manager, I've added a new "LXC" 
connection and then created a new "system" container. And then started 
that container.

Bug#671744: ITP: rutorrent

[Taylor Kline]

Since this has had no activity since 2013, I have packaged version 3.7 and
will be uploading it with a request for sponsorship soon.

Bug#849492: linux-image-4.8.0-2-amd64: kernel BUG at /build/linux-lIgGMF/linux-4.8.11/net/netfilter/nf_conntrack_helper.c:369

[Davide Chiarello]

Package: src:linux
Version: 4.8.11-1
Severity: important



-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=98c4bdeb-c50b-475d-86a5-8aab5244912d ro quiet

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[3.489930] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[3.490034] iTCO_wdt: Found a Braswell SoC TCO device (Version=3, 
TCOBASE=0x0460)
[3.490976] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[3.491248] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[3.497696] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[3.534518] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[3.538826] iwlwifi :02:00.0 wlp2s0: renamed from wlan0
[3.611391] snd_hda_intel :00:1b.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[3.611422] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on minor 0
[3.735904] fbcon: inteldrmfb (fb0) is primary device
[3.762161] scsi 3:0:0:0: Direct-Access WD   Elements 25A21014 
PQ: 0 ANSI: 6
[3.764529] sd 3:0:0:0: Attached scsi generic sg2 type 0
[3.764806] sd 3:0:0:0: [sdc] 3906963456 512-byte logical blocks: (2.00 
TB/1.82 TiB)
[3.765221] sd 3:0:0:0: [sdc] Write Protect is off
[3.765235] sd 3:0:0:0: [sdc] Mode Sense: 47 00 10 08
[3.765633] sd 3:0:0:0: [sdc] No Caching mode page found
[3.765643] sd 3:0:0:0: [sdc] Assuming drive cache: write through
[3.815978] Console: switching to colour frame buffer device 240x67
[3.861728] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[8.935071]  sdc: sdc1
[8.939434] sd 3:0:0:0: [sdc] Attached SCSI disk
[8.974694] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC283: 
line_outs=2 (0x1b/0x21/0x0/0x0/0x0) type:hp
[8.974699] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[8.974702] snd_hda_codec_realtek hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[8.974704] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[8.974707] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0
[8.974709] snd_hda_codec_realtek hdaudioC0D0:inputs:
[8.974712] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x19
[9.249014] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[9.250626] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[9.250852] input: HDA Intel PCH Headphone Front as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[9.251070] input: HDA Intel PCH Front Headphone Surround as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[9.256553] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[   10.406186] random: crng init done
[   25.600305] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: 
errors=remount-ro
[   25.688050] r8169 :03:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168h-2.fw
[   25.705957] r8169 :03:00.0 enp3s0: link down
[   25.706047] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[   25.706473] r8169 :03:00.0 enp3s0: link down
[   25.896160] bridge: automatic filtering via arp/ip/ip6tables has been 
deprecated. Update your scripts to load br_netfilter if you need this.
[   26.048229] tun: Universal TUN/TAP device driver, 1.6
[   26.048233] tun: (C) 1999-2004 Max Krasnyansky 
[   26.938188] br0: port 1(enp3s0) entered blocking state
[   26.938197] br0: port 1(enp3s0) entered disabled state
[   26.938802] device enp3s0 entered promiscuous mode
[   26.957784] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
[   27.218771] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)



[   27.313455] [ cut here ]
[   27.318351] kernel BUG at 
/build/linux-lIgGMF/linux-4.8.11/net/netfilter/nf_conntrack_helper.c:369!
[   27.323222] invalid opcode:  [#1] SMP
[   27.328070] Modules linked in: nf_conntrack_sip(+) iptable_mangle 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_filter tun bridge stp llc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic arc4 iTCO_wdt iTCO_vendor_support intel_rapl coretemp 
kvm_intel kvm iwlmvm irqbypass crct10dif_pclmul mac80211 crc32_pclmul iwlwifi 
joydev i915 snd_hda_intel ghash_clmulni_intel serio_raw cfg80211 pcspkr 
drm_kms_helper lpc_ich mfd_core snd_hda_codec snd_intel_sst_acpi shpchp drm 
snd_hda_core snd_intel_sst_core snd_hwdep sg i2c_algo_bit 
snd_soc_sst_mfld_platform snd_soc_rt5670 btusb snd_soc_sst_match snd_soc_rl6231 
hci_uart btrtl snd_soc_core btqca btbcm 

Bug#849491: ITP: bctoolbox -- C/C++ utility library for Linphone

[Daniel Gnoutcheff]

Package: wnpp
Severity: wishlist
Owner: Daniel Gnoutcheff 

* Package name: bctoolbox
  Version : 0.2.0
  Upstream Author : Belledonne Communications
* URL : http://linphone.org/releases/sources/bctoolbox/
* License : GPL-2+
  Programming Lang: C++
  Description : C/C++ utility library for Linphone

This is a dependency of current versions of Linphone and related
libraries (e.g. belle-sip).  Packaging this is part of an effort to
prepare packages for modern Linphone versions.

I'm working on this as I have a personal and professional desire for a
NAT-traversing, end-to-end encrypted, cross-platform federated SIP
client, and Linphone seems to be the closest thing available.

I'm doing this under the same of the Debian VoIP Team


As of this writing, I'm neither a DM nor a DD, so I'll be looking for
review and sponsorship.



signature.asc
Description: OpenPGP digital signature

Bug#849490: libconfig-model-systemd-perl: cme check systemd-user crashes when directory ~./config/systemd/user is missing

[Dominique Dumont]

Package: libconfig-model-systemd-perl
Version: 0.232.3-1
Severity: normal
Tags: upstream

Dear Maintainer (well... that would be me :o) )

cme check systemd-user crashes when directory ~./config/systemd/user is missing

For instance:

$ ls ~/.config
lxpanel  openbox  pcmanfm
$ cme check systemd-user
cme: using Systemd model
loading data
Backend error: Unknown directory /home/domi/.config/systemd/user at 
/usr/share/perl5/Config/Model/Backend/Systemd.pm line 46,  line 16.

cme should not crash: an empty config should be valid. This bug also
prevents using 'cme edit systemd-user'.

Workaround:
$ mkdir -p ~/.config/systemd/user

This bug will be fixed upstream soon.

All the best

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-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 libconfig-model-systemd-perl depends on:
ii  libconfig-model-perl  2.097-1
ii  liblog-log4perl-perl  1.47-2
ii  libmouse-perl 2.4.5-2+b1
ii  libpath-tiny-perl 0.098-1
ii  perl  5.24.1~rc4-1

Versions of packages libconfig-model-systemd-perl recommends:
ii  cme1.016-1
ii  libconfig-model-tkui-perl  1.359-1

Versions of packages libconfig-model-systemd-perl suggests:
ii  libconfig-model-cursesui-perl  1.105-1

-- no debconf information

Bug#849455: dput: gpgme reports “Invalid value” when checking signature

[Ben Finney]

On 27-Dec-2016, Elías Alejandro  wrote:

> $ dput mentors gpick_0.2.5+git20161221-1_i386.changes
> Checking signature on .changes
> gpgme: /tmp/gpick_upload/gpick_0.2.5+git20161221-1_i386.changes: error 55: 
> Invalid value
> (7, 55, u'Invalid value')

This implies the ‘gpgme’ library didn't like some value provided to it
(and the library doesn't give much more information than that).

> I've tried with: debsign -pgpg2 gpick_0.2.5+git20161221-1_i386.changes
> but I got the same "Invalid value".

There is an experimental ‘dput’ built to use a different,
better-maintained GnuPG library. Can you try again with ‘dput’ version
“0.11.1”, which is in the Debian ‘experimental’ suite?

-- 
 \ “I was married by a judge. I should have asked for a jury.” |
  `\ —Groucho Marx |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#837379: mime-support: purge left files on system

[Jörg Frings-Fürst]

Hello Charles,

Am Montag, den 12.12.2016, 21:40 +0900 schrieb Charles Plessy:
> Le Sun, Sep 11, 2016 at 08:31:10AM +0200, Jörg Frings-Fürst a écrit :
> > 
> > by running piuparts for scons I get:
> > 
> > [quote]
> > 0m52.2s DEBUG: Recording chroot state
> > 0m54.7s DEBUG: Modified(user, group, mode, size, target):
> > /var/lib/dpkg/info
> > /mime-support.list expected(root, root, - 100644, 40, None) !=
> > found(root,
> > root, - 100644, 855, None)
> > 0m54.7s DEBUG: Modified(user, group, mode, size, target):
> > /etc/mime.types
> > expected(root, root, - 100644, 24241, None) != found(root, root, -
> > 100644,
> > 24301, None)
> > 0m54.8s ERROR: FAIL: Package purging left files on system:
> >   /etc/mailcap   not owned
> >   /usr/bin/compose -> run-mailcapowned by: mime-support
> 
> ...
> 
> Hi Jörg,
> 
> sorry for taking time to answer...

the same here...

> 
> I am a bit puzzled: the main piuparts checks are running fine.
> 
> https://piuparts.debian.org/sid/source/p/piuparts.html
> 
> Are you sure that the problem is with mime-support, or could there be
> a problem with your piuparts installation ?
> 

I don't think. I use piuparts with a daily updated sid and stretch
chroot.


> Have a nice day,
> 
> Charles
> 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

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

[David Davies-Jones]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: darksnow
   Version : 0.7.1-1
   Upstream Author : Rafael Diniz 
 * URL : http://darksnow.radiolivre.org/
 * License : GPL-2+
   Section : sound

It builds those binary packages:

 darksnow   - simple graphical user interface to darkice

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

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


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

 dget -x 
https://mentors.debian.net/debian/pool/main/d/darksnow/darksnow_0.7.1-1.dsc

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

Changes since the last upload:

 * QA upload.
 * New upstream release (Closes: #839027)
 * Set maintainer to QA Group
 * Converted rules to dh format
 * Compat level 10
 * Converted patches to quilt & refreshed
 * Converted copyright to DEP-5
 * Standards version 3.9.8
 * Replaced menu file with desktop


Regards,
 David William Richmond Jones

Bug#849455: gpgme reports “Invalid value” when checking signature

[Ben Finney]

Control: retitle -1 dput: gpgme reports “Invalid value” when checking signature
Control: tags -1 + moreinfo

On 27-Dec-2016, Elías Alejandro  wrote:

> $ debsign gpick_0.2.5+git20161221-1_i386.changes
> 
> Successfully signed dsc and changes files

Can you send (to this bug report) the public key you used for signing,
and the resulting signed file? This will allow reproducing the
behaviour.

-- 
 \“Fascism is capitalism plus murder.” —Upton Sinclair |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)

[Adam D. Barratt]

Control: clone -1 -2
Control: close -1
Control: reassign -2 release.debian.org
Control: severity -2 normal
Control: retitle -2 nmu: e2fsck-static
Control: tags -2 + jessie pending

On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote:
> retitle -1 release.debian.org: binNMU for e2fsck-static to rebuild against 
> latest dietlibc
> reassign -1 release.debian.org
> user release.debian@packages.debian.org
> usertag -1 binnmu
> thanks

Thankfully none of that worked. I say thankfully, because you'd have
given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's
certainly not so for release.d.o) and removed the original bug from
where it belongs. (The binNMU doesn't resolve the fact that the original
issue existed - and for some versions still exists - in e2fsprogs.)

> Agreed, that seems to be the best way to handle things.  So that means
> we would need to do a binNMU for e2fsck-static/1.42.12-2 for the
> following architectures:
> 
> alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc
> 
> I've reassigned this to the release team to see if the Stable Release
> Managers agree (which hopefully they will).

Only three of those architectures - amd64, i386 and powerpc - are in
stable so are the only ones that are relevant as far as the release.d.o
bug is concerned. I've scheduled binNMUs for those; you'll have to
handle the others separately, or explain which Debian architectures you
actually meant (for instance, "arm" hasn't been used as a Debian
architecture name for several releases now).

Regards,

Adam

Bug#848722: dash-el: possibly unnecessary emacs dependency

[Rob Browning]

Rob Browning  writes:

> I suspect dash-el would be (or could be made to be) fine with just the
> emacsen-common dependency.

OK, I've tested, and the package seems to build fine in an sbuild
chroot, and to work fine in emacs25 (at least via some simple tests), so
if there are no objections, I thought I'd upload a trivial (delayed) NMU
for that in a bit.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849251: allow using sftp for uploads to ftp.debian.org

[Ben Finney]

Control: tags -1 - moreinfo
Control: reassign -1 dput-ng

On 24-Dec-2016, Adam D. Barratt wrote:

> dput isn't maintained by ftp-master (and if it were it wouldn't be
> under the ftp.d.o meta-package); reassigning.

On further enquiry:

On 27-Dec-2016, Pirate Praveen wrote:
> On ചൊവ്വ 27 ഡിസംബര്‍ 2016 12:34 വൈകു, Ben Finney wrote:
> > So I'm not sure how “Changing method to sftp in ~/.dput.cf” is working
> > for you; there must be some changes from the Debian ‘dput’ package on
> > the host you're using.
> 
> I'm using dput-ng.

Thanks; reassigning this report to that package.

-- 
 \ “It is not enough to have a good mind. The main thing is to use |
  `\ it well.” —Rene Descartes |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature