Bug#844480: notmuch-emacs-mua not available

[Vagrant Cascadian]

Package: notmuch-emacs
Version: 0.23.1-1
Severity: wishlist

The notmuch-emacs-mua man page is shipped in "notmuch" but the actual
notmuch-emacs-mua is not shipped in any package, as far as I can tell.

I haven't yet used notmuch-emacs-mua, but it seems like it might be
useful, if for no other purpose than making it simpler to use reportbug
to file more notmuch related bugs.

At a quick glance, the biggest dependency notmuch-emacs-mua relies on is
bash.


live well,
  vagrant


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

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

Versions of packages notmuch-emacs depends on:
ii  emacs24 24.5+1-7
ii  emacsen-common  2.0.8
ii  notmuch 0.23.1-1

notmuch-emacs recommends no packages.

notmuch-emacs suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#836454: texlive-binaries: xetex produces bad dvi at MIPS

[Hilmar Preuße]

Am 15.11.2016 um 23:54 schrieb Norbert Preining:

Hi,


Thanks for the confirmation.


Hilmar, I think upstream bug #133 should be closed too. Could you check it? 
Thanks!


Hilmar, I posted there that it can be closed but I cannot close it, please.


Can't do either even after login. Seems they have to do it themselves.

Hilmar
--
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#844465: libelfin: FTBFS on several architectures with test errors

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/aclements/libelfin/issues/19

[Aaron M. Ucko]
> Per https://buildd.debian.org/status/logs.php?pkg=libelfin&ver=0.2-5,
> builds of libelfin for mips, s390x, and the non-release architectures
> hppa, powerpc, and ppc64 all failed with test suite errors.  (FWIW,
> all are big-endian, but so is m68k, which ran into no such trouble.)
> 
> Could you please take a look?

Thank you for your interest in libelfin.  I noticed the new build problem
a few minutes after they happened, and have reported them upstream.  I'll
request the broken architectures removed from Debian.

The tests are new in 0.2, and exposes that the library do not work on some
architectures.   It never worked on these, so a porting effort is needed
to fix it.

Until that happen, we will have to limit libelf to the architectures where
testing show that it is working.

When the broken binaries are removed, the severity of this issue should be
reduced to normal.
-- 
Happy hacking
Petter Reinholdtsen

Bug#792163: Reviewing kipi-plugins dependencies

[Simon Frei]

On 16/11/16 06:49, Steve M. Robbins wrote:
> On Tuesday, November 15, 2016 2:05:27 PM CST Simon Frei wrote:
>> I second this request. Please make konqueror a suggested package instead
>> of a recommended. Digikam is aiming to be a cross-platform/-DE
>> applications, especially since version 5 where many parts have been
>> ported to QT from KDE framework.
> I agree in principle.  Before making the change, I want to check the code to 
> see whether or not anything actually calls konqueror.
>
> -Steve

I just had a quick grep look and the only place "konqueror" shows up as
a string is in flashexport and remotestorage. In both cases there is no
explicit call to konqueror, only calls to QDesktopServices::openUrl or
KRun::runUrl (or konqueror is just used as an example in a UI string).
So removing konqueror shouldn't be a problem.



signature.asc
Description: OpenPGP digital signature

Bug#844464: kodi: FTBFS on mips(el): undefined gl* and egl* symbols

[James Cowgill]

On 16/11/16 03:39, Aaron M. Ucko wrote:
> Source: kodi
> Version: 17.0~beta5+dfsg1-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> The mips and mipsel builds of kodi failed with undefined references to
> gl* and egl* symbols, per the log excerpt below.  Could you please
> take a look?

FYI I am aware of this (with many packages affected) and it looks like
it's probably a toolchain issue but I'll let you know once I've
investigated it.

James



signature.asc
Description: OpenPGP digital signature

Bug#844481: plasma-desktop: No taskbar visible and context menu does not work!

[Peter Schütt]

Package: plasma-desktop
Version: 4:5.8.2-1
Severity: normal

When I logged in the task bar is not visible and the context menu does not
work.
This system is unusable.

I had an old Konsole open which is saved in the session so I can start
reportbug.

I tried start in an empty user, but it produced the same error.



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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.8.2-1
ii  kactivitymanagerd5.8.2-1
ii  kde-cli-tools4:5.8.2-1
ii  kded55.27.0-1
ii  kio  5.27.0-2
ii  libc62.24-5
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.7
ii  libgcc1  1:6.2.0-10
ii  libkf5activities55.27.0-1
ii  libkf5activitiesstats1   5.27.0-1
ii  libkf5archive5   5.27.0-1
ii  libkf5auth5  5.27.0-1
ii  libkf5baloo5 5.27.0-1
ii  libkf5bookmarks5 5.27.0-1
ii  libkf5codecs55.27.0-1
ii  libkf5completion55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5emoticons-bin  5.27.0-1
ii  libkf5emoticons5 5.27.0-1
ii  libkf5globalaccel5   5.27.0-1
ii  libkf5guiaddons5 5.27.0-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5iconthemes55.27.0-1
ii  libkf5itemmodels55.27.0-1
ii  libkf5itemviews5 5.27.0-1
ii  libkf5jobwidgets55.27.0-1
ii  libkf5kcmutils5  5.27.0-1
ii  libkf5kdelibs4support5   5.27.0-1
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiofilewidgets55.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5notifyconfig5  5.27.0-1
ii  libkf5parts5 5.27.0-1
ii  libkf5people55.27.0-1
ii  libkf5peoplewidgets5 5.27.0-1
ii  libkf5plasma55.27.0-1
ii  libkf5plasmaquick5   5.27.0-1
ii  libkf5quickaddons5   5.27.0-1
ii  libkf5runner55.27.0-1
ii  libkf5service-bin5.27.0-1
ii  libkf5service5   5.27.0-1
ii  libkf5solid5 5.27.0-1
ii  libkf5sonnetui5  5.27.0-1
ii  libkf5wallet-bin 5.27.0-1
ii  libkf5wallet55.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libkfontinst54:5.8.2-1
ii  libkfontinstui5  4:5.8.2-1
ii  libkworkspace5-5 4:5.8.2-1
ii  libpackagekitqt5-0   0.9.6-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  9.0-4
ii  libpulse09.0-4
ii  libqt5concurrent55.6.1+dfsg-3+b1
ii  libqt5core5a 5.6.1+dfsg-3+b1
ii  libqt5dbus5  5.6.1+dfsg-3+b1
ii  libqt5gui5   5.6.1+dfsg-3+b1
ii  libqt5network5   5.6.1+dfsg-3+b1
ii  libqt5printsupport5  5.6.1+dfsg-3+b1
ii  libqt5qml5   5.6.1-11
ii  libqt5quick5 5.6.1-11
ii  libqt5quickwidgets5  5.6.1-11
ii  libqt5sql5   5.6.1+dfsg-3+b1
ii  libqt5svg5   5.6.1-2
ii  libqt5widgets5   5.6.1+dfsg-3+b1
ii  libqt5x11extras5 5.6.1-2
ii  libqt5xml5   5.6.1+dfsg-3+b1
ii  libscim8v5   1.4.17-1
ii  libstdc++6   6.2

Bug#839150: Adding the Homepage also

[Mathieu Malaterre]

It would also be nice to add the Homepage in d/control:
https://cgit.freedesktop.org/xorg/app/edid-decode/

Bug#844017: coz-profiler: FTBFS: unknown mnemonic `pause' -- `pause'

[Petter Reinholdtsen]

Control: tags -1 + pending

The issue is fixed upstream, and I've pulled the patch from upstream into
our git repository.  Thus this issue should be fixed in the next upload.
-- 
Happy hacking
Petter Reinholdtsen

Bug#844482: RFS/ITP: node-vlq/0.2.0-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-vlq"

 * Package name: node-vlq
   Version : 0.2.0-1
   Upstream Author : Rich Harris
 * URL : https://github.com/Rich-Harris/vlq
 * License : Expat
   Section : web

  It builds those binary packages:

node-vlq   - Variable-length quantity mapper for Node.js

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


  https://mentors.debian.net/package/node-vlq


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-vlq/node-vlq_0.2.0-1.dsc


  It is packaged within the Debian Javascript Maintainers git repository:
  Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-vlq.git
  Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-vlq.git

Cheers,

Snark on #debian-js

Bug#844428: Pending fixes for bugs in the libspring-java package

[pkg-java-maintainers]

tag 844428 + pending
thanks

Some bugs in the libspring-java package are closed in revision
0eb23c659e70596f01760b11486299df66cf1e6a in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libspring-java.git/commit/?id=0eb23c6

Commit message:

Rebuild with gradle-debian-helper 1.4.4 to fix the optional dependencies in 
the poms (Closes: #844428)

Bug#800891: Please adjust the licensing of afex

[Andreas Tille]

Hi Henrik,

On Tue, Nov 15, 2016 at 08:57:20PM +0100, Henrik Singmann wrote:
> Hi Andreas, (this time with list in CC)
> 
> Thanks for warning me. And no problem. I will change to GPL2 in the next
> release version. Can you give me some time to implement these changes and
> others I have planned for the next release? Let's say 4 weeks?

As I said 4 weeks is a bit dense.  If you really manage in 4 weeks it
might make it.  However, it is not my power to push any package after
the freeze.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#840928: RFS on ITP: node-doctrine/1.5.0-1 -- JSDoc parser

[Julien Puydt]

Hi,

On 18/10/2016 16:02, Gianfranco Costamagna wrote:

Hi Julien

(note: this is probably for Upstream not Debian)


I have seen the LICENSE.closure-compiler file, it is mentioned in
README.md, but I didn't find any trace of it in the code.
Same thing : there is a LICENSE.esprima, and they mention it in the
README.md, but I have found nothing about it in the code.

Should I still put something in d/copyright? But then which file should
I point to?



"some of functions is derived from *"

lets ignore grammar, I guess this means
"some of the functions in the source code, have been derived from foo/bar"
so, you need to ask them which functions, or maybe release under FOO and BAR 
and FOOBAR licenses
the whole package.
I'm not sure, but copying files with a different copyright shouldn't be 
ignored, if you
can't know which files have such licenses, my suggestion is to relicense
the whole package.

But as said, this is something for upstream.



Upstream relicensed things under Apache-2.0 ; please see the new 2.0.0 
upstream version, available both here:


dget -x 
https://mentors.debian.net/debian/pool/main/n/node-doctrine/node-doctrine_2.0.0-1.dsc

and here:

Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-doctrine.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-doctrine.git


I hope it's better this time,

Snark on #debian-js

Bug#844484: Warning: slow font initialization + graph not displayed in the window

[Vincent Lefevre]

Package: gnuplot-qt
Version: 5.0.5+dfsg1-4
Severity: important

With the following:

$ /usr/bin/gnuplot -persist <

Bug#823330: closed by gustavo panizzo (Bug#823330: fixed in tsocks 1.8beta5-9.5)

[eric2.valette]

  
  
On 10/28/2016 01:03 PM, Debian Bug
  Tracking System wrote:


  This is an automatic notification regarding your Bug report
which was filed against the tsocks package:

#823330: tsocks: The actual configure command disable host name resolution in tsocks.conf when it was supposed to enable it

It has been closed by gustavo panizzo .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact gustavo panizzo  by
replying to this email.




The sid version does not work as expected. Please test!


-- eric


  _

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Bug#844421: [Pkg-rpm-devel] Bug#844421: rpmlint: FTBFS (failing tests)

[Arturo Borrero Gonzalez]

On 15 November 2016 at 16:12, Santiago Vila  wrote:
> Package: src:rpmlint
> Version: 1.9-4
> Severity: serious
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>

Know issue, already discussed with upstream [0].

[0] https://github.com/rpm-software-management/rpmlint/issues/82

Bug#844483: RFS: python-backports-abc/0.5-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "python-backports-abc"

 * Package name: python-backports-abc
   Version : 0.5-1
   Upstream Author : Stefan Bahnel et al.
 * URL : https://github.com/cython/backports_abc
 * License : Python-2.0
   Section : python

  It builds those binary packages:

python-backports-abc - Backport of the "collections.abc" stdlib 
module (Python 2)


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


  https://mentors.debian.net/package/python-backports-abc


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-backports-abc/python-backports-abc_0.5-1.dsc


 It is packaged within the Debian Python Modules Team's git repository:
Vcs-Git: 
https://anonscm.debian.org/git/python-modules/packages/python-backports-abc.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/python-backports-abc.git/


Thanks,

Snark on #debian-python

Bug#818731: approx: weekly cronjob breaks with removal of Files field from Sources

[Ian Campbell]

On Tue, 2016-11-15 at 20:48 -0500, Eric Cooper wrote:
> On Sun, Mar 20, 2016 at 08:04:56AM +, Ian Campbell wrote:
> > I've just received the following in a cron mail:
> >
> > /etc/cron.weekly/approx:
> > File
> /var/cache/approx/debian/dists/experimental/main/source/Sources.xz,
> line 1: missing "Files" field
> > run-parts: /etc/cron.weekly/approx exited with return code 1
> >
> > Which I pressume relates to the changes announced in
> > https://lists.debian.org/debian-devel-announce/2016/03/msg6.htm
> l
> >
> > Tagging as blocking the corresponding archive bug.
> >
> > There is a newer version in sid but the changelog doesn't indicate
> that it
> > resolves this issue.
> 
> I can't reproduce this problem.  When I include a deb-src line for
> experimental,  I don't see any Sources.xz files in my approx server's
> cache.

It perhaps depends on the version of apt being used and which
compression it prefers? My system with experimental configured is a
mostly-testing/some-unstable infrequently updated one, which doesn't
tell us much since I don't know what I was running when that file was
created.

> Can you please send me the output of
> ls -l /var/cache/approx/debian/dists/experimental/main/source/

Some weeks ago my /var/cache/approx filled up so I manually removed
that file and ran the cleanup, which succeeded. However since then I am
sure I've been getting cron messages about other paths, but stupidly I
seem to have been deleting it rather than archiving it.

I've just run the following by hand and it matches what I recall the
most recent cron mail to look like:

root@celaeno:~# /usr/sbin/approx-gc
File /var/cache/approx/debian-multimedia/dists/sid/main/source/Sources.xz, line 
1: missing "Files" field

This will correspond to my mythtv box (another testing/unstable hybrid,
not updated as often as I should) which has in sources.list:

# mythtv, liblame, mplayer etc
deb http://mirror/debian-multimedia/ sid main
deb-src http://mirror/debian-multimedia/ sid main

To answer your question, I see:

root@celaeno:~# ls -lrt /var/cache/approx/debian/dists/experimental/main/source/
total 264
-rw-r--r-- 1 approx approx 261196 Jul 12 03:31 Sources.xz
-- 1 approx approx  0 Oct 19 09:12 Sources
drwxr-xr-x 3 approx approx   4096 Oct 23 04:38 by-hash

Which I suppose is no longer relevant to this bug but I included it
because the files are so old and Sources is zero sized which seemed odd
to me (and doesn't match the official mirrors). I just ran "apt update"
on a system with experimental configured and those files have not
changed (the system also runs cronapt nightly). I then ran "apt update
--print-uris and from that ran "curl -o /dev/null http://mirror/debian/
dists/experimental/main/source/Sources.xz" and now:

root@celaeno:~# ls -lrt /var/cache/approx/debian/dists/experimental/main/source/
total 208
-- 1 approx approx  0 Oct 19 09:12 Sources
drwxr-xr-x 3 approx approx   4096 Oct 23 04:38 by-hash
-rw-r--r-- 1 approx approx 201732 Nov 16 02:18 Sources.xz

I've no idea what is up with a plain "apt update", but not a approx
issue I guess.

WRT this bug I suppose you would now be more interested in:

root@celaeno:~# ls -rtl 
/var/cache/approx/debian-multimedia/dists/sid/main/source
total 348
drwxr-xr-x 2 approx approx   4096 May 22  2013 Sources.diff
-rw-r--r-- 1 approx approx 134988 Jul 24  2015 Sources.gz
-rw-r--r-- 1 approx approx 140282 Jul 30 15:09 Sources.bz2
-rw-r--r-- 1 approx approx  57992 Nov 12 18:08 Sources.xz

A representative first stanza from the Sources.xz is:

Package: 2mandvd-dmo
Binary: 2mandvd, 2mandvd-data
Version: 1:1.8.5-dmo4
Maintainer: Christian Marillat 
Build-Depends: debhelper (>= 9), quilt, ccache, libswscale-dev, 
libavformat-dev, libqt4-dev (>= 4:4.7.2~), libqt4-opengl-dev, libqtwebkit-dev, 
libavcodec-dev
Build-Conflicts: qtbase5-dev
Architecture: any all
Standards-Version: 3.9.7
Format: 1.0
Checksums-Sha256:
 9d5882145478bcecaf43cbecc4f70afead88538f669bcbcc08f76c5114f70316 1920 
2mandvd-dmo_1.8.5-dmo4.dsc
 8d34d7fd748f29ab065cec64817628b573dc4781d48fb4ead049a4b7a362f83b 29534393 
2mandvd-dmo_1.8.5.orig.tar.gz
 7e1c97557334517ed9ac974b0e57abccb09cba8b61eefd6c05265c835f894269 11584 
2mandvd-dmo_1.8.5-dmo4.diff.gz
Homepage: http://2mandvd.tuxfamily.org/
Package-List: 
 2mandvd deb video extra arch=any
 2mandvd-data deb video extra arch=all
Directory: pool/main/2/2mandvd-dmo
Priority: extra
Section: misc

AIUI omitting the Files block with their md5 checksums in favour of
Checksums-Sha256 (or other checksum varieties stronger than md5) is
valid and I think something Debian ftp-masters are moving towards as
well (https://lists.debian.org/debian-devel-announce/2016/03/msg6.h
tml, although I see Files entries in
/var/cache/approx/debian/dists/experimental/main/source/Sources.xz and 
ftp://ftp.debian.org/debian/dists/experimental/main

Bug#844486: gnuplot-qt: Mismatch between the program and library build versions with GNUTERM=wxt

[Vincent Lefevre]

Package: gnuplot-qt
Version: 5.0.5+dfsg1-4
Severity: serious

(Set to serious as I believe that the ABI mismatch may yield obscure
bugs and should be solved before the next stable release.)

When I use GNUTERM=wxt and plot data, I get a warning like:

10:01:38: Warning: Mismatch between the program and library build versions 
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx 
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx 
containers,compatible with 2.8).

for instance with:

$ GNUTERM=wxt /usr/bin/gnuplot -persist <

Bug#844487: linux-image-4.8.0-1-amd64: Debian fails to prompt for encrypted disk password on boot

[Martin Ždila]

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

Dear Maintainer,

I am using Debian Scratch with encrypted root partition. The last kernel
version where it worked was 4.6.0. For kernels 4.7.0 and 4.8.0 it prints
on the boot repeatedly and forever following messages:

  WARNING: Failed to connect to lvmetad. Falling back to device
  scanning.
  Volume group "martin-vg" not found
  Cannot process volume group martin-vg

In 4.6.0 these messages are shown too, but only twice and then it prompts for a 
password:

Please unlock disk sda5_crypt:

Therefore I am forced to stay with old 4.6.0 kernel.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: MSI
product_name: MS-7978
product_version: 2.0
chassis_vendor: MSI
chassis_version: 2.0
bios_vendor: American Megatrends Inc.
bios_version: A.20
board_vendor: MSI
board_name: Z170A GAMING M3 (MS-7978)
board_version: 2.0

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Sky Lake Host Bridge/DRAM 
Registers [8086:191f] (rev 07)
Subsystem: Micro-Star International Co., Ltd. [MSI] Skylake Host 
Bridge/DRAM Registers [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Sky Lake Integrated 
Graphics [8086:1912] (rev 06) (prog-if 00 [VGA controller])
DeviceName:  Onboard IGD
Subsystem: Micro-Star International Co., Ltd. [MSI] HD Graphics 530 
[1462:7978]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation Sky Lake Gaussian Mixture 
Model [8086:1911]
Subsystem: Micro-Star International Co., Ltd. [MSI] Skylake Gaussian 
Mixture Model [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H USB 
3.0 xHCI Controller [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-H 
Thermal subsystem [8086:a131] (rev 31)
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H 
Thermal subsystem [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-H 
LPSS I2C Controller #0 [8086:a160] (rev 31)
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H 
Serial IO I2C Controller [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-H 
LPSS I2C Controller #1 [8086:a161] (rev 31)
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H 
Serial IO I2C Controller [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME 
HECI #1 [8086:a13a] (rev 31)
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H 
CSME HECI [1462:7978]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA 
controller [AHCI mode] [8086:a102] (rev 31) (prog-if 01 [AHCI 1.0])
Subsystem: Micro-Star International Co., Ltd. [MSI] Sunrise Point-H 
SATA controller [AHCI mode] [1462:7978]
Control: I/O+ Mem+ Bu

Bug#746005: Still FTBFS with lilypond 2.19-50

[Dr. Tobias Quathamer]

Hi,

short update: The build still fails with the current upstream version of 
2.19.50.


There are only about six weeks left before the freeze for Stretch 
happens. I don't have much hope that lilypond will be part of the next 
Debian stable release.


Antonio, did you manage to get in contact with anybody?

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#844485: RFS: node-moment/2.16.0+ds-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "node-moment"

 * Package name: node-moment
   Version : 2.16.0+ds-1
   Upstream Author : Tim Wood, Iskren Chernev and Moment.js contributors
 * URL : https://github.com/moment/moment
 * License : Expat
   Section : web

  It builds those binary packages:

libjs-moment - Work with dates in JavaScript (library)
 node-moment - Work with dates in JavaScript (Node.js module)

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


  https://mentors.debian.net/package/node-moment


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-moment/node-moment_2.16.0+ds-1.dsc


  It is packaged within the Debian Javascript Maintainers' team's git 
repository:

Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-moment.git
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-moment.git

Thanks,

Snark on #debian-js

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

[Fabien Wernli]

On Sat, 15 Oct 2016 17:06:00 +0200 Frank Brokken  wrote:
> Package: mutt
> Version: 1.7.0-6
> Severity: normal
> 
> Dear Maintainer,
> 
> When trying to S/MIME sign a message mutt no longer finds my secret key
> file. However, the locations of the key files were not changed, the key file
> is still there, and until now I've had no probllems when S/MIE signing
> messages. 
> 
> When trying to S/MIE sign a message mutt replies with:
> 
> secret key `6fe6935f.0' not found: End of file?
> 
> Maybe this is related to the recent change of how mutt handles PGP? Looking
> for clues via Google didn't bring up any useful suggestions. 
> 
> My S/MIME certificate is valid, so that can't be the cause of the problem.
> 
> 
> -- Package-specific info:
> NeoMutt 20160916 (1.7.0)
> Copyright (C) 1996-2016 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
> 
> System: Linux 4.7.0-1-amd64 (x86_64)
> libidn: 1.33 (compiled with 1.33)
> hcache backend: tokyocabinet 1.4.48
> 
> Compiler:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-4' 
> --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
> --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
> --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-mu!
>  ltiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
> --enable-multilib --with-tune=generic --enable-checking=release 
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 6.2.0 20160914 (Debian 6.2.0-4) 
> 
> Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
> '--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
> '--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
> '--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
> '--disable-dependency-tracking' '--with-mailpath=/var/mail' 
> '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
> '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
> '--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
> '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
> '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
> 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
> -fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-fPIE 
> -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-tim!
>  e -D_FORTIFY_SOURCE=2'
> 
> Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
> -fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security
> 
> Compile options:
> +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
> +DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
> -SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
> +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
> +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
> +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
> +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
> +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
> +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
> -DOMAIN
> MIXMASTER="mixmaster"
> -ISPELL

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

[Fabien Wernli]

On Sat, 15 Oct 2016 17:06:00 +0200 Frank Brokken  wrote:
> Package: mutt
> Version: 1.7.0-6
> Severity: normal
> 
> Dear Maintainer,
> 
> When trying to S/MIME sign a message mutt no longer finds my secret key
> file. However, the locations of the key files were not changed, the key file
> is still there, and until now I've had no probllems when S/MIE signing
> messages. 
> 
> When trying to S/MIE sign a message mutt replies with:
> 
> secret key `6fe6935f.0' not found: End of file?
> 
> Maybe this is related to the recent change of how mutt handles PGP? Looking
> for clues via Google didn't bring up any useful suggestions. 
> 
> My S/MIME certificate is valid, so that can't be the cause of the problem.
> 
> 
> -- Package-specific info:
> NeoMutt 20160916 (1.7.0)
> Copyright (C) 1996-2016 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
> 
> System: Linux 4.7.0-1-amd64 (x86_64)
> libidn: 1.33 (compiled with 1.33)
> hcache backend: tokyocabinet 1.4.48
> 
> Compiler:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-4' 
> --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
> --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
> --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-mu!
>  ltiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
> --enable-multilib --with-tune=generic --enable-checking=release 
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 6.2.0 20160914 (Debian 6.2.0-4) 
> 
> Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
> '--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
> '--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
> '--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
> '--disable-dependency-tracking' '--with-mailpath=/var/mail' 
> '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
> '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
> '--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
> '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
> '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
> 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
> -fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-fPIE 
> -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-tim!
>  e -D_FORTIFY_SOURCE=2'
> 
> Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
> -fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security
> 
> Compile options:
> +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
> +DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
> -SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
> +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
> +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
> +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
> +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
> +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
> +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
> -DOMAIN
> MIXMASTER="mixmaster"
> -ISPELL

Bug#844194: InfoPane.qml:54:22: Unable to assign [undefined] to int

[Maximiliano Curia]

¡Hola Helge!

El 2016-11-15 a las 19:41 +0100, Helge Kreutzmann escribió:

Since Sep. 21 I repeatedly see the following error (?) message in my logs:
Sep 21 21:42:48 samd sddm-greeter[17492]:
file:///usr/share/sddm/themes/breeze/components/InfoPane.qml:54:22:
Unable to assign [undefined] to int Everything (except the PID and 
the date) is always the same.


That file (/usr/share/sddm/themes/breeze/components/InfoPane.qml) is 
not included in our packages, where did it come from?



I never manipulate anything within /usr directly, only via apt/dpkg.


Ah, ok, it was present in the 5.7.4 version. The report was made listing 
sddm-theme-breeze 5.8.2 hence the confusion.


Anyway, the message is still present if you restart sddm (remember to close 
your graphical session before doing this)?



Nov 14 22:28:23 samd sddm-greeter[3210]: 
file:///usr/share/sddm/themes/breeze/components/Battery.qml:39:18: Unable to 
assign [undefined] to int



And this file is clearly in the current package:
sddm-theme-breeze: /usr/share/sddm/themes/breeze/components/Battery.qml


Mmh, what's the version of your currently installed plasma-workspace? It 
could be that we are missing a versioned depend in sddm-theme-breeze against 
plasma-workspace.


Happy hacking,
--
"By definition, when you are investigating the unknown, you do not know what
you will find"
-- The Ultimate Principle
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

[840850bugs . debian . org]

I'm having the exact same issue

Bug#835274: dh-text no longer needed

[Dmitry Bogatov]

control: tags -1 -moreinfo
control: unblock -1 by 834313
control: close 834313

With dpkg-dev >= 1.18.11, implementing S:field substitution, dh-text
is no longer needed, this request is active again.

In attachment there is an email from current maintainer (in CC), giving
me permission to make these changes on his behalf.

Changes since last upload:

  * Write debian/watch
  * Change source package format to quilt, remove manual patches
application
  * Convert package to use debhelper
  * Use `dh-runit' to install runit scripts and generate log scripts
(Closes: #832656)
  * Use `dh-buildinfo' to simplify tracking bugs, related to build-tools
  * Avoid need of hand-written maintainer scripts by
use of `dh-runit' and `dh-sysuser'
  * Drop diet libc build due issues with errno
  * Remove no longer needed README files
  * Move 'debian/crontab' into 'debian/contrib' for more clean package layout
  * Enable hardening
  * Fix @dircategory in texinfo manual
  * Install `doc-base' document
  * Add Homepage field
  * Bump standards version to 3.9.8 (no changes needed)
  * Remove Section field from `bcron-run' field, since it duplicated one
defined in first paragraph.
  * Update Vcs-Git and Vcs-Browser fields
  * Convert `debian/copyrigh' to dep5 format
  * Use S:fieldname substitution to avoid duplication in `debian/control'.
+ Add versioned dependency on (dpkg-dev >= 1.18.11)

Regards,
  Dmitry Bogatov

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.
--- Begin Message ---
On Sat, Jul 30, 2016 at 01:53:50PM +0300, Dmitry Bogatov wrote:
> I investigated issue a bit more. From all listed -run packages, currently
> only following are problematic:
> 
>   bcron-run
>   twoftpd-run
>   tinydns-run
> 
> I started fixing bcron-run, and discovered, that to use dh_runit, I
> need also at least dh_installdeb, dh_prep and dh_gencontrol. And this is
> on half way to converting to debhelper (which is inapporiate for NMU).
> 
> Here I ask you for permission:
> 
>  - convert those 3 packages to debhelper and upload them with myself
>as maintainer (unfortunately, I can't do this in NMU). Feel free
>to add 'I reserve right to take this package back' clause to your
>permission.
> 
>  - the same for rest of -run packages. This is not so urgent, since
>right now they are coinstallable with runit/unstable, and I do not
>plan to touch them, as long as they just work.
> 
> I am sorry about all this situation, but since I need to resolve
> (Bug#832656), I am forced to bother you. And since this bug is
> serious, I really want to resolve it till freeze. Dropping a mail
> on debian-mentors should suffice as permission.

Hi Dmitry,

I'm still much interested in the djbdns (provides tinydns-run) and bcron
packages, while twoftpd isn't that fency any more.

If you want, please take over maintainership for twoftpd.  For the other
two packages, I suggest you switch them to debhelper (I never liked
that) with my permission, since it appears to be really necessary.  Add
yourself as uploader, but please (not yet) switch the maintainer.

Best Regards, thanks for all the time you put into Debian, Gerrit.

--- End Message ---

Bug#844488: RFS: node-regenerate/1.3.2-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "node-regenerate"

 * Package name: node-regenerate
   Version : 1.3.2-1
   Upstream Author : Mathias Bynens
 * URL : https://mths.be/regenerate
 * License : Expat
   Section : web

  It builds those binary packages:

libjs-regenerate - Unicode-aware regular expression generator 
(JavaScript library)
 node-regenerate - Unicode-aware regular expression generator (Node.js 
module)


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


  https://mentors.debian.net/package/node-regenerate

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

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-regenerate/node-regenerate_1.3.2-1.dsc


 It is packaged within the Debian Javascript Maintainer's team's git 
repository :

Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-regenerate.git
Vcs-Browser: 
https://anonscm.debian.org/git/pkg-javascript/node-regenerate.git



Thanks,

Snark on #debian-js

Bug#844489: ITP: python-maxminddb -- Python module for reading MaxMind DB files

[Martin Kratochvil]

Package: wnpp
Severity: wishlist
Owner: Martin Kratochvil 

* Package name: python-maxminddb
  Version : 1.2.1
  Upstream Author : MaxMind, Inc. 
* URL : https://github.com/maxmind/MaxMind-DB-Reader-python
* License : Apache-2
  Programming Lang: Python
  Description : Python module for reading MaxMind DB files

This is a Python module for reading MaxMind DB files. The module includes both 
a pure Python reader
and an optional C extension.
MaxMind DB is a binary file format that stores data indexed by IP address 
subnets (IPv4 or IPv6).

I'm going to maintain this package inside DPMT. I have sponsor for upload.

Bug#844491: linux-atm: FTBFS: time.h:9:8: error: redefinition of 'struct timespec'

[Chris Lamb]

Source: linux-atm
Version: 1:2.5.1-1.6
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

linux-atm fails to build from source in unstable/amd64:

  […]

(void) write(1,rotor[i = (i+1) & 3],2);
^~
  mv -f .deps/aping.Tpo .deps/aping.Po
  /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -I../../src/include -g 
-O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes  
-Wl,-z,relro -o aping aping.o ../../src/lib/libatm.la 
  libtool: link: gcc -I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wl,-z 
-Wl,relro -o .libs/aping aping.o  ../../src/lib/.libs/libatm.so
  gcc -DHAVE_CONFIG_H -I. -I../..   -Wdate-time -D_FORTIFY_SOURCE=2  
-I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -MT br.o -MD 
-MP -MF .deps/br.Tpo -c -o br.o br.c
  mv -f .deps/br.Tpo .deps/br.Po
  /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -I../../src/include -g 
-O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes  
-Wl,-z,relro -o br br.o ../../src/lib/libatm.la 
  libtool: link: gcc -I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wl,-z 
-Wl,relro -o .libs/br br.o  ../../src/lib/.libs/libatm.so
  gcc -DHAVE_CONFIG_H -I. -I../..   -Wdate-time -D_FORTIFY_SOURCE=2  
-I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -MT bw.o -MD 
-MP -MF .deps/bw.Tpo -c -o bw.o bw.c
  bw.c: In function 'main':
  bw.c:60:19: warning: ignoring return value of 'write', declared with 
attribute warn_unused_result [-Wunused-result]
while (blocks--) (void) write(s,buffer,BSIZE);
 ^~~~
  bw.c:62:6: warning: ignoring return value of 'write', declared with attribute 
warn_unused_result [-Wunused-result]
(void) write(s,buffer,size);
^~~
  mv -f .deps/bw.Tpo .deps/bw.Po
  /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -I../../src/include -g 
-O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes  
-Wl,-z,relro -o bw bw.o ../../src/lib/libatm.la 
  libtool: link: gcc -I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wl,-z 
-Wl,relro -o .libs/bw bw.o  ../../src/lib/.libs/libatm.so
  gcc -DHAVE_CONFIG_H -I. -I../..   -Wdate-time -D_FORTIFY_SOURCE=2  
-I../../src/include -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161116094316.Tj0RL2UOKo.db.linux-atm/linux-atm-2.5.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-Wall -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -MT isp.o 
-MD -MP -MF .deps/isp.Tpo -c -o isp.o isp.c
  isp.c: In function 'send_msg':
  isp.c:40:44: warning: format '%d' expects argument of type 'int', but 
argument 4 has type 'long unsigned int' [-Wformat=]
   else fprintf(stderr,"bad write: %d != %d\n",wrote,sizeof(*msg));
  ^
  isp.c: In function 'recv_msg':
  isp.c:52:43: warning: format '%d' expects argument of type 'int', but 
argument 4 has type 'long unsigned int' [-Wformat=]
   else fprintf(stderr,"bad read: %d != %d\n",got,sizeof(*msg));
 ^
  mv -f .deps/isp.Tpo .deps/isp.Po
  /bin/bash ../../ylwrap ispl_y.y y.tab.c ispl_y.

Bug#844490: FTBFS with boost1.62

[Thibaut Paumard]

Package: src:gyoto
Version: 1.1.1-2+b1
Severity: serious
Justification: fails to build from source (but built successfully in the
past)

Dear BTS,

gyoto FTBFS with boost1.62 on several release architectures:
https://buildd.debian.org/status/package.php?p=gyoto

It looks like it was known before the upload of boost1.62 to unstable:
http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html

The failure occurs in the test suite. Some debugging shows that the
culprit lies in lib/Screen.C, line 567. More precisely, the function
acos() overloaded for type boost::multiprecision::cpp_dec_float_100
sometimes never returns. It appears to be somewhat reproducible (I think
the test suite of gyoto fails always at the same point in its execution
on a given architecture, when it fails), but I was not able to isolate a
specific value of the argument that would hang acos().

The test suite can succeed if I decrease somewhat the number of digits,
e.g. using only 50 or even 90 decimal digits instead of 100. The build
failure occurs earlier if I use even more digits, so it looks like a
memory leak of some sort.

Several approaches could hide the problem under the carpet:
 - skipping the test suite on the affected architectures ;
 - decreasing the number of digits.

I'm very reluctant to do any of this because there, even if the test
suite goes through, there is no guarantee that the bug will not bite
users in the middle of a weeks-long simulation.

Besides, decreasing the number of digits means gyoto will loose in accuracy.

Looks like this needs to be fixed in boost.

Kind regards, Thibaut.

Bug#844493: twisted-web2: FTBFS: twisted.python.dist module not found

[Chris Lamb]

Source: twisted-web2
Version: 8.1.0-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

twisted-web2 fails to build from source in unstable/amd64:

  […]

  
   debian/rules build
  python2.7 setup.py build
  twisted.python.dist module not found.  Make sure you have installed the 
Twisted core package before attempting to install any other Twisted projects.
  debian/rules:13: recipe for target 'build-python2.7' failed
  make: *** [build-python2.7] Error 1

  […]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


twisted-web2.8.1.0-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#746005: Still FTBFS with lilypond 2.19-50

[Antonio Ospite]

On Wed, 16 Nov 2016 10:08:04 +0100
"Dr. Tobias Quathamer"  wrote:

> Hi,
> 
> short update: The build still fails with the current upstream version of 
> 2.19.50.
> 
> There are only about six weeks left before the freeze for Stretch 
> happens. I don't have much hope that lilypond will be part of the next 
> Debian stable release.
> 
> Antonio, did you manage to get in contact with anybody?
>

Hi Tobias,

I've been talking with Don and some lilypond devs, sorry for not keeping
you in the loop I didn't realize you were one of the maintainers, here
is my updated notes:
https://ao2.it/tmp/lilypond-guile2/NOTES_2016-11-10.txt

The eight patches at https://ao2.it/tmp/lilypond-guile2/ should fix the
FTBFS, I guess Don hasn't had the chance to add them to the debian
package yet, let me know how they work out.

However, even if the build succeeds there are still some encoding
issues:
http://lists.gnu.org/archive/html/lilypond-devel/2016-11/msg00076.html

The full thread starts at:
http://lists.gnu.org/archive/html/lilypond-devel/2016-11/msg00030.html

Ciao,
   Antonio

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

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

Bug#844492: lua-sql: FTBFS: cc: error: .specs: No such file or directory

[Chris Lamb]

Source: lua-sql
Version: 2.3.0-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

lua-sql fails to build from source in unstable/amd64:

  […]

  Preparing to unpack .../02-pkg-config_0.29-4_amd64.deb ...
  Unpacking pkg-config (0.29-4) ...
  Selecting previously unselected package liblua5.3-0:amd64.
  Preparing to unpack .../03-liblua5.3-0_5.3.1-1.1+b1_amd64.deb ...
  Unpacking liblua5.3-0:amd64 (5.3.1-1.1+b1) ...
  Selecting previously unselected package libtinfo-dev:amd64.
  Preparing to unpack .../04-libtinfo-dev_6.0+20160917-1_amd64.deb ...
  Unpacking libtinfo-dev:amd64 (6.0+20160917-1) ...
  Selecting previously unselected package libreadline-dev:amd64.
  Preparing to unpack .../05-libreadline-dev_7.0-1_amd64.deb ...
  Unpacking libreadline-dev:amd64 (7.0-1) ...
  Selecting previously unselected package liblua5.3-dev:amd64.
  Preparing to unpack .../06-liblua5.3-dev_5.3.1-1.1+b1_amd64.deb ...
  Unpacking liblua5.3-dev:amd64 (5.3.1-1.1+b1) ...
  Selecting previously unselected package lua5.3.
  Preparing to unpack .../07-lua5.3_5.3.1-1.1+b1_amd64.deb ...
  Unpacking lua5.3 (5.3.1-1.1+b1) ...
  Selecting previously unselected package liblua5.2-0:amd64.
  Preparing to unpack .../08-liblua5.2-0_5.2.4-1.1+b1_amd64.deb ...
  Unpacking liblua5.2-0:amd64 (5.2.4-1.1+b1) ...
  Selecting previously unselected package liblua5.2-dev:amd64.
  Preparing to unpack .../09-liblua5.2-dev_5.2.4-1.1+b1_amd64.deb ...
  Unpacking liblua5.2-dev:amd64 (5.2.4-1.1+b1) ...
  Selecting previously unselected package lua5.2.
  Preparing to unpack .../10-lua5.2_5.2.4-1.1+b1_amd64.deb ...
  Unpacking lua5.2 (5.2.4-1.1+b1) ...
  Selecting previously unselected package liblua5.1-0:amd64.
  Preparing to unpack .../11-liblua5.1-0_5.1.5-8.1+b2_amd64.deb ...
  Unpacking liblua5.1-0:amd64 (5.1.5-8.1+b2) ...
  Selecting previously unselected package liblua5.1-0-dev:amd64.
  Preparing to unpack .../12-liblua5.1-0-dev_5.1.5-8.1+b2_amd64.deb ...
  Unpacking liblua5.1-0-dev:amd64 (5.1.5-8.1+b2) ...
  Selecting previously unselected package lua5.1.
  Preparing to unpack .../13-lua5.1_5.1.5-8.1+b2_amd64.deb ...
  Unpacking lua5.1 (5.1.5-8.1+b2) ...
  Selecting previously unselected package libnumber-compare-perl.
  Preparing to unpack .../14-libnumber-compare-perl_0.03-1_all.deb ...
  Unpacking libnumber-compare-perl (0.03-1) ...
  Selecting previously unselected package libtext-glob-perl.
  Preparing to unpack .../15-libtext-glob-perl_0.10-1_all.deb ...
  Unpacking libtext-glob-perl (0.10-1) ...
  Selecting previously unselected package libfile-find-rule-perl.
  Preparing to unpack .../16-libfile-find-rule-perl_0.34-1_all.deb ...
  Unpacking libfile-find-rule-perl (0.34-1) ...
  Selecting previously unselected package dh-lua.
  Preparing to unpack .../17-dh-lua_23+nmu2_all.deb ...
  Unpacking dh-lua (23+nmu2) ...
  Selecting previously unselected package mysql-common.
  Preparing to unpack .../18-mysql-common_5.8+1.0.1_all.deb ...
  Unpacking mysql-common (5.8+1.0.1) ...
  Selecting previously unselected package libmysqlclient20:amd64.
  Preparing to unpack .../19-libmysqlclient20_5.7.16-1_amd64.deb ...
  Unpacking libmysqlclient20:amd64 (5.7.16-1) ...
  Selecting previously unselected package zlib1g-dev:amd64.
  Preparing to unpack .../20-zlib1g-dev_1%3a1.2.8.dfsg-2+b3_amd64.deb ...
  Unpacking zlib1g-dev:amd64 (1:1.2.8.dfsg-2+b3) ...
  Selecting previously unselected package libmysqlclient-dev.
  Preparing to unpack .../21-libmysqlclient-dev_5.7.16-1_amd64.deb ...
  Unpacking libmysqlclient-dev (5.7.16-1) ...
  Selecting previously unselected package libsqlite3-dev:amd64.
  Preparing to unpack .../22-libsqlite3-dev_3.15.1-1_amd64.deb ...
  Unpacking libsqlite3-dev:amd64 (3.15.1-1) ...
  Selecting previously unselected package libpq5:amd64.
  Preparing to unpack .../23-libpq5_9.6.1-2_amd64.deb ...
  Unpacking libpq5:amd64 (9.6.1-2) ...
  Selecting previously unselected package libpq-dev.
  Preparing to unpack .../24-libpq-dev_9.6.1-2_amd64.deb ...
  Unpacking libpq-dev (9.6.1-2) ...
  Setting up libtool-bin (2.4.6-2) ...
  Setting up libsqlite3-dev:amd64 (3.15.1-1) ...
  Setting up mysql-common (5.8+1.0.1) ...
  update-alternatives: using /etc/mysql/my.cnf.fallback to provide 
/etc/mysql/my.cnf (my.cnf) in auto mode
  Setting up libtinfo-dev:amd64 (6.0+20160917-1) ...
  Setting up dctrl-tools (2.24-2) ...
  Setting up libtext-glob-perl (0.10-1) ...
  Setting up lua5.1 (5.1.5-8.1+b2) ...
  update-alternatives: using /usr/bin/lua5.1 to provide /usr/bin/lua 
(lua-interpreter) in auto mode
  update-alternatives: using /usr/bin/luac5.1 to provide /usr/bin/luac 
(lua-compiler) in auto mode
  Setting up pkg-config (0.29-4) ...
  Setting up libpq5:amd64 (9.6.1-2) ...
  Processing triggers for libc-bin (2.24-5) ...
  Setting up lua5.2 (5.2.4-1.1+b1) ...
  update-alternatives: using /usr/bin/lua5.2 to 

Bug#844420: FTBFS: tests fail on hosts without network access

[Ximin Luo]

Aurelien Jarno:
> On 2016-11-15 16:00, Ximin Luo wrote:
>> Package: glibc
>> Version: 2.24-5
>> Severity: important
>> Tags: upstream patch
>> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826
>>
>> Dear Maintainer,
>>
>> posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
>> tests.reproducible-builds.org:
>>
>> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz
>>
>> The attached patch should fix this; I gave a more detailed description in 
>> the upstream bug report.
> 
> Hum, I am not sure it is the correct way to fix that. I think that
> libnss_files should be able to resolve entries from /etc/hosts when the
> query is relative, but also when it is fully qualified. This is how
> libnss_dns behaves.
> 

Looks like I was wrong before about getaddrinfo bypassing /etc/hosts, and it 
does indeed look at /etc/hosts.

$ sudo -u sbuild getent hosts localhost
127.0.0.1   profitbricks-build17-amd64.debian.net 
profitbricks-build17-amd64 localhost
$ sudo -u sbuild getent hosts localhost.
# no results

However if you change "localhost" in /etc/hosts to "localhost." then the above 
results would be reversed.

What do you think the full behaviour should be?

> Also note that technically the glibc doesn't require network access,
> just a DNS server able to resolve 'localhost.'
> 

So how do you want to fix this? glibc doesn't currently build-depend on a name 
server, and I assume you wouldn't want to do that. Can you give me some hints 
on what to patch, to fix libnss_files?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#835185: #835185: mysql-workbench: Segfault when opening connection

[Rene Engelhard]

On Wed, Nov 16, 2016 at 07:45:12AM +1100, Dmitry Smirnov wrote:
> On Tuesday, 15 November 2016 9:25:09 AM AEDT Rene Engelhard wrote:
> > I saw mysql-connector-c++ 1.1.7-4 but that gives you only a dependency
> > libmysqlcppconn7v5 (>= 1.1.7).
> > 
> > Whereas to be sure here we should add a >= 1.1.7-3. There were the
> > ((probably) broken) 1.1.7-1 and 1.1.7-2 in the arhive; admittedly only in
> > experimental to people would have needed to install it maually, but...
> 
> I'm sure that installs from experimental can be safely ignored...
> IMHO (>= 1.1.7) is sufficient because it will work for everybody except those 
> who installed libmysqlcppconn7v5 1.1.7-1 or 1.1.7-2 from "experimental"...

Yeah, let's see. Personally I think "better safe than sorry", but...

Re-enabled libreoffice-mysql-connector. Upload in progress (will be NEW
"of course", though)

Regards,

Rene

Bug#844494: reopen: Should close stderr when becoming multiplex master

[Julien Palard]

Package: openssh-client
Version: 1:7.3p1-3+b1
Severity: normal

Dear Maintainer,

I think that the bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714526 is still
live, after upgrading to 1:7.3p1-3+b1 (should have been fixed still
1:7.2p2-6).

I straced SSH with and without `ControlMaster` and extracted revelant
bits of information, redacting it, and removing useless lines. First,
without `ControlMaster`:

```
# Here, Python 3 Popen prepares pipes for stdin, stdout, and stderr:
7880  1479228055.059186 pipe2([8, 9], O_CLOEXEC) = 0
7880  1479228055.059226 pipe2([10, 11], O_CLOEXEC) = 0
7880  1479228055.059258 pipe2([12, 13], O_CLOEXEC) = 0
# Then ssh is cloned:
7880  1479228055.060158 clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f7bfd7fa9d0) = 7949
7949  1479228055.121259 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fd3f2a63650) = 7954
7954  1479228055.121135 execve("/bin/sh", ["/bin/sh", "-c", "exec ssh 
user@gate.redacted -W dev2.redacted:22"], [/* 16 vars */] 
# Normal exit
7949  1479228055.592488 +++ exited with 0 +++
7871  1479228055.592519 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, 
si_pid=7949, si_uid=1003, si_status=0, si_utime=0, si_stime=2} ---
7954  1479228055.592786 exit_group(129) = ?
# Python receive EOF on stdout AND stderr
7880  1479228055.694455 read(12,  
7880  1479228055.694480 <... read resumed> "", 32768) = 0
7880  1479228055.738380 read(10,  
7880  1479228055.738410 <... read resumed> "", 32768) = 0
# So, as the process is exited, AND stdout/stderr had their EOF, Python 3 
subprocess.Popen.communicate allows itself to wait for it:
7880  1479228055.924898 wait4(7949,  
7880  1479228055.925334 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 
0}], 0, NULL) = 7949
```

Now, with `ControlMaster`:

```
# Same pipes for stdin, stdout, and stderr from Python Popen:
6749  1479227922.771783 pipe2([8, 9], O_CLOEXEC) = 0
6749  1479227922.771831 pipe2([10, 11], O_CLOEXEC) = 0
6749  1479227922.771865 pipe2([12, 13], O_CLOEXEC) = 0
# A bunch of clones, SSH starting its master process:
6749  1479227922.774839 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fa1957fa9d0) = 6824
6824  1479227922.818219 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7ff4c6f11650) = 6827
6827  1479227922.820940 execve("/bin/sh", ["/bin/sh", "-c", "exec ssh 
user@redacted -W redacted:22"], [/* 16 vars */] 
6824  1479227923.204918 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7ff4c6f11650) = 6856
6856  1479227923.205441 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7ff4c6f11650) = 6857
6857  1479227923.206004 <... clone resumed> child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7ff4c6f11650) = 6858
# Normal exit after work is done:
6824  1479227923.335999 +++ exited with 0 +++
6749  1479227923.336042 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, 
si_pid=6824, si_uid=1003, si_status=0, si_utime=0, si_stime=0} ---
# Python is getting EOF on STDOUT
6749  1479227923.336086 read(10, "", 32768) = 0
# But here, process is a zombie (dead but not awaited), after like a minute,
# I send a SIGINT and a SIGQUIT to the Python process, so everyone dies and 
finally:
6749  1479227986.358448 read(12, "", 32768) = 0
6827  1479227986.328027 exit_group(130) = ?
6858  1479227986.329254 exit_group(255) = ?
6749  1479227986.578489 wait4(6824,  
6749  1479227986.578546 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 
0}], 0, NULL) = 6824
```

So here it looks like the bug is exactly the same as before: stdout is
closed but stderr is kept open. As Python's
``subprocess.Popen.communicate`` want to wait for both to be closed before
waiting for the process, it yields to stuck Python process and zombies.

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable'), (200, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages openssh-client depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.17.27
ii  libc6 2.24-5
ii  libedit2  3.1-20140620-2
ii  libgssapi-krb5-2  1.14.3+dfsg-2
ii  libselinux1   2.3-2
ii  libssl1.0.2   1.0.2j-1
ii  passwd1:4.2-3+deb8u1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- no debconf information

Bug#844165: virtualbox: Virtualbox & guests windows moving "alone" when mouse pointer moves.

[Gianfranco Costamagna]

Hi,
> If you want you can start by downgrading vbox to a 5.0.* version, even if I 
> don't think this is a vbox issue.

can you please try the official virtualbox builds and report the problem there 
if still persists?
https://www.virtualbox.org/wiki/Bugtracker

don't forget to link it here :)

thanks,

G.



signature.asc
Description: OpenPGP digital signature

Bug#844495: multiprecision acos() sometimes does not return

[Thibaut Paumard]

Package: libboost1.62-dev
Version: 1.62.0+dfsg-4
Severity: serious
Justification: regression causes FTBFS

Dear maintainer,

gyoto FTBFS on several release architectures, apparently due to a
regression in Boost.multiprecision introduced in boost1.62.

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

It looks like a memory leak.

Regards, Thibaut.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: s390x

Kernel: Linux 3.16.0-4-s390x (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libboost1.62-dev depends on:
ii  libstdc++-6-dev [libstdc++-dev]  6.2.0-13

libboost1.62-dev recommends no packages.

Versions of packages libboost1.62-dev suggests:
pn  libboost-atomic1.62-dev   
pn  libboost-chrono1.62-dev   
pn  libboost-date-time1.62-dev
pn  libboost-exception1.62-dev
pn  libboost-filesystem1.62-dev   
pn  libboost-graph-parallel1.62-dev   
pn  libboost-graph1.62-dev
pn  libboost-iostreams1.62-dev
pn  libboost-locale1.62-dev   
pn  libboost-log1.62-dev  
pn  libboost-math1.62-dev 
pn  libboost-mpi-python1.62-dev   
ii  libboost-mpi1.62-dev  1.62.0+dfsg-4
pn  libboost-program-options1.62-dev  
pn  libboost-python1.62-dev   
pn  libboost-random1.62-dev   
pn  libboost-regex1.62-dev
ii  libboost-serialization1.62-dev1.62.0+dfsg-4
pn  libboost-signals1.62-dev  
pn  libboost-system1.62-dev   
pn  libboost-test1.62-dev 
pn  libboost-thread1.62-dev   
pn  libboost-timer1.62-dev
pn  libboost-type-erasure1.62-dev 
pn  libboost-wave1.62-dev 
pn  libboost1.62-doc  
pn  libboost1.62-tools-dev
pn  libmpfrc++-dev
pn  libntl-dev

-- no debconf information

Bug#844497: seccomp "Invalid argument" due to old library version

[Stefan Bühler]

Package: systemd
Version: 232-3

Hi,

pdns.service (from pdns-server in testing) didn't start anymore with
this message:

pdns.service: Failed at step SECCOMP spawning /usr/sbin/pdns_server: Invalid 
argument

(See http://sources.debian.net/src/pdns/4.0.1-5/pdns/pdns.service.in/
for the service configuration.)

Updating libseccomp2 from 2.1.1-1 (stable) to 2.3.1-2 (testing) fixed
it.

systemd 232-3 has a build dependency `libseccomp-dev (>= 2.2.3-3~)`, but
the resulting package only depends on `libseccomp2 (>= 2.1.0)`.

I filed a bug with libseccomp too, and maybe they'll fix their symbols
file for future builds.

In the meantime I suggest adding an explicit minimum libseccomp2
dependency.  Given the same build dependency in 230-7~bpo8+2 this is
probably broken in jessie-backports too.

regards,
Stefan

Bug#807010: xl2tpd freezes all system

[Mark Morgan Lloyd]

On Fri, 30 Sep 2016 20:55:08 +0600 anabioz34  wrote:
> On Sun, Sep 25, 2016 at 10:26:46PM +0100, Ben Hutchings wrote:
> > Is this still reproducible with Linux 4.7 (currently in unstable)?
> >
> > Ben.
> I checked it. Yes, still reproducible with Linux 4.7.5-1 i686 and 
xl2tpd 1.3.6+dfsg-4.


For general info, we've been running upstream's 1.3.7 reliably here for 
several months on ARM, compiled to not use the kernel. There might be 
additional issues on aarch64.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Bug#844496: seccomp "Invalid argument" due to old library version

[Stefan Bühler]

Package: libseccomp
Version: 2.3.1-2

Hi,

pdns.service (from pdns-server in testing) didn't start anymore with
this message:

pdns.service: Failed at step SECCOMP spawning /usr/sbin/pdns_server: Invalid 
argument

Updating libseccomp2 from 2.1.1-1 (stable) to 2.3.1-2 (testing) fixed
it.

systemd 232-3 has a build dependency `libseccomp-dev (>= 2.2.3-3~)`, but
the resulting package only depends on `libseccomp2 (>= 2.1.0)`.

I guess systemd uses a feature from newer libseccomp versions which
wasn't tracked by the symbols file.  Maybe you should consider upgrading
the minimum versions in the symbols file.  (Probably broken in backports
too.)

regards,
Stefan

Bug#844498: disorderfs: using it for building kills the host (with a 686 kernel)

[Holger Levsen]

Package: disorderfs
Version: 0.5.1-1
Severity: normal

Hi,

so we had disorderfs disabled for a long time on our reproducible setup
and yesterday I enabled it again for i386 only, which rather immediatly
caused profitbricks-build2-i386.debian.net to hang/die… so I rebootet it
and logged in to investigate…

and while watched diskspace… and suddenly the host was "gone". I observed this
as I typed "ps fax|grep wesnot" in another shell. Also Trying to ssh in 
resulted 
in this:

$ ssh profitbricks-build2-i386.debian.net 
Last login: Wed Nov 16 10:14:27 2016 from …

and hangs there.

So "killing the host" means: the kernel and processes are still running but
are stuck on io, eg I had "watch df" running in an ssh session, it was
not updating anymore but I could ctrl-c it and get back to the shell
prompt. as soon as i pressed enter on a command, it hung.

Interesting, disorderfs was used on two hosts, but this only happened on pb2,
but not pb6! pb2 is running 3.16.0-4-686-pae while pb6 is running 3.16.0-4-amd64
(and both run i386 userland).

Thogh it's unclear whether it would not also "kill" pb6 if we were using it
long enough.

Also, using disorderfs for a few jobs seems to be fine, but there are 8 pbuilder
jobs running simultaenously on each of these hosts and half of them are using
disorderfs.

Next easy tests:
- enable disorderfs on some armhf hosts (running 32bit kernels too)
- upgrade pb2 to a 4.7 bpo 686 kernel
- eneable disorderfs on amd64


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844486: gnuplot-qt: Mismatch between the program and library build versions with GNUTERM=wxt

[Vincent Lefevre]

On 2016-11-16 10:10:09 +0100, Vincent Lefevre wrote:
> Package: gnuplot-qt
> Version: 5.0.5+dfsg1-4
> Severity: serious
> 
> (Set to serious as I believe that the ABI mismatch may yield obscure
> bugs and should be solved before the next stable release.)

More generally, isn't there anything missing in the build dependency
rules to avoid this mismatch?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844421: reassign to pycodestyle

[Arturo Borrero Gonzalez]

Hi,

upstream reports this is an issue with pycodestyle which is used by flake8.
I'm doing the reassign now.

Bug#636362: gnome-activity-journal: Several warnings in journalctl with zeitgeist.

[Pam]

Package: gnome-activity-journal
Version: 0.8.0-2
Followup-For: Bug #636362

Dear Maintainer,



Launch gnome-activity-journal with gnome-terminal.

ERROR:dbus.connection:Unable to set arguments (1453417200, 1453503599) 
according to signature u'uus': : More items found 
in D-Bus signature than in Python arguments
ERROR:dbus.connection:Unable to set arguments (1453330800, 1453417199) 
according to signature u'uus': : More items found 
in D-Bus signature than in Python arguments 
[A lot of same messages] 

Nov 16 10:41:29 Debian wpa_supplicant[780]: wlan0: WPA: Group rekeying 
completed with 68:a3:78:66:78:87 [GTK=TKIP]
Nov 16 10:41:39 Debian org.a11y.Bus[945]: Reloaded configuration
Nov 16 10:41:39 Debian org.a11y.Bus[945]: Reloaded configuration
Nov 16 10:41:39 Debian org.a11y.Bus[945]: Reloaded configuration
Nov 16 10:41:39 Debian org.a11y.Bus[945]: Reloaded configuration
Nov 16 10:51:29 Debian wpa_supplicant[780]: wlan0: WPA: Group rekeying 
completed with 68:a3:78:66:78:87 [GTK=TKIP]
Nov 16 11:01:24 Debian org.gnome.Terminal[945]: (gnome-terminal-server:1372): 
GLib-GIO-WARNING **: Failed to parse translated string 
'visible-name\u0004'Unnamed'' for key 'visible-name' in schema 
'org.gnome.Terminal.Legacy.Profile': 0:expected value
Nov 16 11:01:24 Debian org.gnome.Terminal[945]: (gnome-terminal-server:1372): 
GLib-GIO-WARNING **: Using untranslated default instead.
Nov 16 11:01:29 Debian wpa_supplicant[780]: wlan0: WPA: Group rekeying 
completed with 68:a3:78:66:78:87 [GTK=TKIP]



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

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

Versions of packages gnome-activity-journal depends on:
ii  gconf2  3.2.6-3
ii  python  2.7.9-1
ii  python-cairo1.8.8-1+b2
ii  python-dbus 1.2.0-2+b3
ii  python-gconf2.28.1+dfsg-1.1
ii  python-gnome2   2.28.1+dfsg-1.1
ii  python-gtk2 2.24.0-4
ii  python-support  1.0.15
ii  python-xdg  0.25-4
ii  zeitgeist   0.9.14-2.2
ii  zeitgeist-core  0.9.14-2.2

Versions of packages gnome-activity-journal recommends:
ii  gstreamer0.10-plugins-base  0.10.36-2
ii  python-gst0.10  0.10.22-3
ii  python-pygments 2.0.1+dfsg-1.1+deb8u1

gnome-activity-journal suggests no packages.

-- no debconf information

Bug#844499: piuparts: links to README and manpage on https://piuparts.debian.org/ are broken

[Holger Levsen]

Package: piuparts
Severity: normal

Jochen Sprickerhof reported this on IRC:

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Tobias Hansen]

Control: tags -1 + patch

This was fixed upstream. Here is the patch:

https://github.com/cython/cython/commit/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch

Best,
Tobias



On Wed, 10 Aug 2016 14:20:36 +0200 Andreas Tille  wrote:
> On Wed, Aug 10, 2016 at 02:12:20PM +0200, Jakub Wilk wrote:
> > * Andreas Tille , 2016-08-10, 09:54:
> > >I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function
> > >call should be fine - so probably the problem is somewhere else - but
> > >where?
> > 
> > https://github.com/cython/cython/issues/551
> 
> Thanks a lot for tracking this down
> 
>  Andreas. 
> 
> -- 
> http://fam-tille.de
> 
> 

Bug#505173: Any update

[u]

Hi!

Ben Finney:
> Thanks for your interest.
> 
> On 15-Nov-2016, u wrote:
> 
>> I'd like to be able to use SFTP to upload from Debian to a Ubuntu
>> PPA too.
> 
> What tools already exist to do this?

Well, dput is supposed to work with SFTP simply by specifying "method =
sftp" in any dput config file such as ~/.dput.cf.

However, when specifying this method, dput throws this error: "Unknown
upload method: sftp"

There is an answer to this here:
https://bugs.launchpad.net/launchpad/+bug/251685/comments/12 claiming
"The dput package on Ubuntu installs a /usr/share/dput/sftp.py file -
maybe you can copy it to your Debian instance although I'm surprised if
it's not in Debian's dput by now?"

Hence, my question actually is: why can't Debian's dput work with SFTP now?

I understand that besides this problem there is a dependency on bzr -
which seems unnecessary.

Hence my second question: there are some patches attached to this bug -
will they be integrated and what's the ETA for that?

Currently, I'm able to use dput only using FTP, which seems slightly
insecure to me :)

Cheers!
u.

Bug#843773: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus

[Raphael Hertzog]

Hi,

On Mon, 14 Nov 2016, Johannes Schauer wrote:
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
> 
> I found Guillem's suggestion the most sensible and as far as I understand the
> matter also the easiest to implement:
> 
> Quoting Guillem Jover (2016-11-09 00:18:25)
> > So the actual problem is that the last timestamp gets reused for the
> > binNMUs, which seems totally bogus to me. This needs to be fixed in
> > whatever is injecting the binNMU entries on the buildds.
> 
> but that proposal did not get any attention so I somehow assumed that there's
> probably a reason not to do so

I don't think so. Given the discussions we had, I agree that it would be
best if the bin-nmu timestamp could be set by wanna-build itself, at the
time the binnmus are requested. That would give a consistent (and real)
timestamp across all arches being rebuilt together.

> and thus I suggested an alternative: choose the
> new timestamp by using the binNMU number and add that many number of seconds. 
> A
> +b17 binNMU would add 17 seconds to the original changelog timestamp. Thus, no
> archive lookups would be required.

This is assuming that the bin-nmu versioning space is linear. It no longer
is because the bin-nmu is no longer defined by the "+bX" added to the
version but by the "binary-only=yes" changelog attribute.

In fact, I expect that we will want bin-nmu within PPA and that we will
have bin-nmu versions like +ppafoo1 in one repo and
+ppabar1 in another repository. (Ubuntu could also benefit
from this when it rebuilds a single source package for multiple release
in a PPA.)

That's something that you could already implement in sbuild BTW. It
currently does not allow to pass such a binNMU version while dpkg
allows it. :-)

Maybe it can be smart and if the parameter to --binNMU-version contains
(or starts with?) non-digits, then it should assume that it's the full
bin-NMU suffix that is passed.

> But maybe to talk about this option: what would speak against changing the
> "nmu" command of wanna-build to also add an option that allows setting a
> timestamp, or even let wanna-build generate that timestamp itself (from the
> time it processes the "nmu" command) and then pass it to sbuild via a
> not-yet-existing --binNMU-timestamp option?
> 
> With that solution we would not have to change anything other than wanna-build
> and sbuild. And I would take care of the latter.

+1 from me on this solution. I don't see anything significant drawback.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#838897: jitsi: Replace the glassfish dependencies

[Emmanuel Bourg]

On Sun, 23 Oct 2016 21:55:16 +0200 "Ingo Bauersachs"  wrote:

> I'm not sure where these dependencies would come from. javax.activation is
> nowhere to be found in the source code, and Jitsi doesn't send mails either.

You are right, there is no import from javax.mail in the code, the
dependencies can simply be removed.


> Anyway if the Jitsi package poses a problem, please remove it from Debian.
> It is unusable anyway as libjitsi is missing. Once I manage to get version
> 2.10 out, I'll try to continue packaging dependencies so it can come back to
> Debian in a clean fashion.

Jitsi isn't a problem, don't worry. If you need any help with the Java
dependencies used by Jitsi feel free to ping the Java Team and we'll be
happy to give a hand.

Emmanuel Bourg

Bug#844481: plasma-desktop: No taskbar visible and context menu does not work!

[Maximiliano Curia]

¡Hola Peter!

El 2016-11-16 a las 09:20 +0100, Peter Schütt escribió:
When I logged in the task bar is not visible and the context menu does not 
work. 
This system is unusable.


I had an old Konsole open which is saved in the session so I can start 
reportbug.



I tried start in an empty user, but it produced the same error.


I guess your plasmashell is crashing, sadly this isn't enough to track the 
issue. Could you share the ~/.xsession-errors of yout empty user, it might 
provide some useful information.


Happy hacking,
--
: You are in a dark room with a compiler, emacs, an internet connection,
: and a thermos of coffee.
: Your move ?
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#844444: [Pkg-privacy-maintainers] Bug#844444: parcimonie: should depend on gnupg1-curl (and obsolete gnupg-curl only as fallback)

[Daniel Kahn Gillmor]

Control: affects 84 + gnupg

On Wed 2016-11-16 03:42:14 +0900, Jonas Smedegaard wrote:
> Package: parcimonie
> Version: 0.10.2-4
> Severity: serious
> Justification: Policy 3.5
>
> parcimonie depends on gnupg-curl, but that package is no longer available
> in the Debian unstable archive.

parcimonie does *not* depend on gnupg-curl, it Recommends: gnupg-curl.

> I guess the best would be if parcimonie could be adapted to the
> interfaces provided by gnupg 2.x, but as a short-term workaround it
> seems a fix would be to change to instead depend on gnupg-curl.

it does support gnupg 2.x.  please do not make it resort to gnupg1.

> To ease backporting use, the no longer available gnupg-curl can be
> preserved as fallback - like this:
>
>   Depends: gnupg1-curl | gnupg-curl

better to drop the recommendation for gnupg-curl entirely.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#844361: qemu: Upgraded from 2.6 to 2.7. Win 2008 R2 machine crasches during boot. I can see "qemu-system-x86_64: pci_get_msi_message: unknown interrupt type" in libvirt log.

[Michael Tokarev]

16.11.2016 01:44, Peter Xu wrote:
> On Mon, 14 Nov 2016 21:17:39 +0100  wrote:
>> Package: qemu
>> Version: 1:2.7+dfsg-3+b1
>> Severity: important
>>
>> I use libvirt for runing Windows 2008 R2 server on qemu-kvm. VirtIO disks and
>> VirtIO network adapters.
>> After upgrading qemu from 2.6 to 2.6 Windows do not boot correctly.
>> The virtual machine crasches after Windows starts to show the "first logo".
>> Windows is able to run repair tools. It looks like the repair console do not
>> see the C: drive.
>>
>> In the libvirt log of the machine one can see this:
>> 2016-11-13T12:19:49.458189Z qemu-system-x86_64: pci_get_msi_message: unknown
>> interrupt type
>> 2016-11-13 12:19:54.141+: shutting down, reason=crashed
> 
> Hi, Maciej,
> 
> Thanks for the issue reported. Could you please try whether the below
> patch can solve your issue?

Thank you Peter for the patch.

I rebuilt qemu with this patch applied, the result can be downloaded
from http://www.corpit.ru/mjt/tmp/qemu-system-x86_64 (gpg signature
http://www.corpit.ru/mjt/tmp/qemu-system-x86_64.sig ).

Maciej, please copy this binary to your /usr/bin/ in place of your
current qemu-system-x86_64 and try your win2008 guest.

Thank you!

/mjt

Bug#844500: reproducible builds: vary order of $PATH entries

[Paul Wise]

Package: qa.debian.org
Severity: wishlist
Tags: patch
User: qa.debian@packages.debian.org
Usertags: jenkins

The attached patch varies the order of PATH entries for the second
build in the reproducible builds project. I don't expect this will make
a while lot of difference since PATH is already varied with a 
non-existent path at the end but it may uncover bugs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 11033b76c2f0450e9933004c09bdfd3aaff3551a Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Wed, 16 Nov 2016 18:24:21 +0800
Subject: [PATCH] Vary the order of PATH entries

---
 bin/reproducible_common.sh  | 2 +-
 hosts/bbx15-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/bpi0-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/cb3a-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/cbxi4a-armhf-rb/etc/pbuilderrc| 2 +-
 hosts/cbxi4b-armhf-rb/etc/pbuilderrc| 2 +-
 hosts/cbxi4pro0-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/ff2a-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/ff2b-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/ff4a-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/hb0-armhf-rb/etc/pbuilderrc   | 2 +-
 hosts/jenkins-test-vm/etc/pbuilderrc| 2 +-
 hosts/jenkins/etc/pbuilderrc| 2 +-
 hosts/jtk1a-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/odu3a-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/odxu4-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/odxu4b-armhf-rb/etc/pbuilderrc| 2 +-
 hosts/odxu4c-armhf-rb/etc/pbuilderrc| 2 +-
 hosts/opi2a-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/opi2b-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/opi2c-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/profitbricks-build1-amd64/etc/pbuilderrc  | 2 +-
 hosts/profitbricks-build10-amd64/etc/pbuilderrc | 2 +-
 hosts/profitbricks-build2-i386/etc/pbuilderrc   | 2 +-
 hosts/profitbricks-build3-amd64/etc/pbuilderrc  | 2 +-
 hosts/profitbricks-build4-amd64/etc/pbuilderrc  | 2 +-
 hosts/profitbricks-build5-amd64/etc/pbuilderrc  | 2 +-
 hosts/profitbricks-build6-i386/etc/pbuilderrc   | 2 +-
 hosts/profitbricks-build7-amd64/etc/pbuilderrc  | 2 +-
 hosts/profitbricks-build9-amd64/etc/pbuilderrc  | 2 +-
 hosts/rpi2b-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/rpi2c-armhf-rb/etc/pbuilderrc | 2 +-
 hosts/wbd0-armhf-rb/etc/pbuilderrc  | 2 +-
 hosts/wbq0-armhf-rb/etc/pbuilderrc  | 2 +-
 34 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/bin/reproducible_common.sh b/bin/reproducible_common.sh
index d41759a..19e65d3 100755
--- a/bin/reproducible_common.sh
+++ b/bin/reproducible_common.sh
@@ -414,7 +414,7 @@ write_variation_table() {
 		write_page "env LC_ALLnot setLC_ALL=\"fr_CH.UTF-8\""
 	fi
 	if [ "$1" != "FreeBSD" ] && [ "$1" != "Arch Linux" ]  ; then
-		write_page "env PATHPATH=\"/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:\"PATH=\"/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/i/capture/the/path\""
+		write_page "env PATHPATH=\"/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:\"PATH=\"/usr/games:/bin:/sbin:/usr/bin:/usr/sbin:/i/capture/the/path\""
 	else
 		write_page "env PATH is not yet varied between rebuilds of $1."
 	fi
diff --git a/hosts/bbx15-armhf-rb/etc/pbuilderrc b/hosts/bbx15-armhf-rb/etc/pbuilderrc
index d6b11e2..7d01099 100644
--- a/hosts/bbx15-armhf-rb/etc/pbuilderrc
+++ b/hosts/bbx15-armhf-rb/etc/pbuilderrc
@@ -33,7 +33,7 @@ PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
 
 # used for reproducible builds tests, when doing the 2nd build
 if [ "$(readlink /proc/1/ns/uts)" != "$(readlink /proc/self/ns/uts)" ]; then
-	PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/i/capture/the/path"
+	PATH="/usr/games:/bin:/sbin:/usr/bin:/usr/sbin:/i/capture/the/path"
 fi
 
 # needed to ignore failures due to running 398 days in the future…
diff --git a/hosts/bpi0-armhf-rb/etc/pbuilderrc b/hosts/bpi0-armhf-rb/etc/pbuilderrc
index d6b11e2..7d01099 100644
--- a/hosts/bpi0-armhf-rb/etc/pbuilderrc
+++ b/hosts/bpi0-armhf-rb/etc/pbuilderrc
@@ -33,7 +33,7 @@ PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
 
 # used for reproducible builds tests, when doing the 2nd build
 if [ "$(readlink /proc/1/ns/uts)" != "$(readlink /proc/self/ns/uts)" ]; then
-	PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/i/capture/the/path"
+	PATH="/usr/games:/bin:/sbin:/usr/bin:/usr/sbin:/i/capture/the/path"
 fi
 
 # needed to ignore failures due to running 398 days in the future…
diff --git a/hosts/cb3a-armhf-rb/etc/pbuilderrc b/hosts/cb3a-armhf-rb/etc/pbuilderrc
index d6b11e2..7d01099 100644
--- a/hosts/cb3a-armhf-rb/etc/pbuilderrc
+++ b/hosts/cb3a-armhf-rb/etc/pbuilderrc
@@ -33,7 +33,7 @@ PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
 
 # used for reproducible builds tests, when doing the 2nd build
 if [ "$(readlink /proc/1/ns/uts)" != "$(readlink /proc/self/ns/uts)" ]; then
-	PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/i/capture/the/path"
+	PATH="/usr/games:

Bug#844031: [monitoring-plugins] Openssl 1.1 support missing

[Christoph Berg]

Re: Jan Wagner 2016-11-11 
> Building against libssl1.0-dev, which was suggested in the
> announcement of the openssl switch, results (actual) into:
> 
> [...]
> checking for PQsetdbLogin in -lpq... no
> configure: WARNING: Skipping PostgreSQL plugin (check_pgsql)
> configure: WARNING: LIBS="-lcrypt " CPPFLAGS="-Wdate-time
> -D_FORTIFY_SOURCE=2 -I/usr/include"
> configure: WARNING: install PostgreSQL libs to compile this plugin
> (see REQUIREMENTS).
> [...]
> 
> This is due postgresql-9.6 beeing linked against libssl1-1-dev and
> libpg5 beeing remove when installing libssl1.0-dev. So check_psql can
> not be build anymore.

I don't see a problem here:

ii  libpq-dev   9.6.1-2  amd64header files for 
libpq5 (PostgreSQL library)
ii  libpq5:amd649.6.1-2  amd64PostgreSQL C 
client library
ii  libssl1.0-dev:amd64 1.0.2j-4 amd64Secure Sockets 
Layer toolkit - development files
ii  libssl1.0.0:amd64   1.0.2d-1 amd64Secure Sockets 
Layer toolkit - shared libraries
ii  libssl1.0.2:amd64   1.0.2j-4 amd64Secure Sockets 
Layer toolkit - shared libraries
ii  libssl1.1:amd64 1.1.0c-1 amd64Secure Sockets 
Layer toolkit - shared libraries

libpq-dev used to have a direct dependency on libssl-dev, but this has
been removed in 9.6.1-2 (which is not in testing yet).

Christoph

Bug#824169: ftp.debian.org: src:chocolate-doom/2.2.1-3 is in both main and contrib

[Jonathan Dowland]

On Thu, Aug 11, 2016 at 10:24:37AM +0100, Jonathan Dowland wrote:
> Could we work around this for chocolate-doom at least by uploading a new
> version in sid/main? Obviously ideally we'll find some other reason to
> update the package too :)

It's not clear to me whether this would work, or not, but it might be
worth a try. Fabian, if we can convince Simon that we should release a
new c-d version from the master branch, we could then upload that, and
see if that newer version string managed to avoid this bug. I don't think
there's anything to lose trying...



-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#844501: alsa-firmware-loaders: udev rule causes race condition which blocks us-122 initialisation (with fix!)

[jaimet]

Package: alsa-firmware-loaders
Version: 1.0.28-1
Severity: grave
Justification: renders package unusable

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

I'm trying to use my tascam us-122 on a new jessie installation. The usb 
soundcard should initialise on hotplug but it doesn't. I've traced the 
cause back to the following line:

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="1604", 
ATTR{idProduct}=="8007", RUN+="/lib/udev/tascam_fpga"

in /lib/udev/rules.d/60-alsa-firmware-loaders.rules

This line "tries" to run usx2yloader once the new device (1604:8007) is 
detected, but usx2yloader depends on the ""hardware dependent interface" 
which is not yet up (see alsa-tools/usx2yloader/README for more info).

My udev-fu is very weak, but after stumbling around with "udevadm 
monitor" for a bit, I replaced that udev rule line with:

SUBSYSTEM=="sound", ACTION=="add", KERNEL=="hwC2D0", 
RUN+="/lib/udev/tascam_fpga"

and now all is good (my us-122 initialises correctly regardless of 
whether it is hot-plugged once the machine has booted, disconnected and 
reconnected with the machine up, or even connected before the machine is 
switched on).

I understand that this may *not* be the best replacement udev rule, but 
at least it fixes the problem.

J :-)

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-586
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 alsa-firmware-loaders depends on:
ii  fxload  0.0.20081013-1
ii  libasound2  1.0.28-1
ii  libc6   2.19-18+deb8u6
ii  udev215-17+deb8u5

alsa-firmware-loaders recommends no packages.

alsa-firmware-loaders suggests no packages.

-- no debconf information

Bug#844502: ITP: python-geoip2 -- Python geoip2 API for web services and databases

[Martin Kratochvil]

Package: wnpp
Severity: wishlist
Owner: Martin Kratochvil 

* Package name: python-geoip2
  Version : 2.4.0
  Upstream Author : MaxMind, Inc. 
* URL : https://github.com/maxmind/GeoIP2-python
* License : Apache-2
  Programming Lang: Python
  Description : Python geoip2 API for web services and databases

This package provides an API for the GeoIP2 web services and databases. The
API also works with MaxMind’s free GeoLite2 databases.

Bug#796246: libc recently more aggressive about pthread locks in stable ?

[Gert Wollny]

Am Dienstag, den 15.11.2016, 18:06 +0200 schrieb Adrian Bunk:
> 
> > Unfortunately, in current unstable with thread sanitizer one might
> > get #796246 (at least I had this).
> 
> Does "-fsanitize=thread -no-pie" work for you?

Indeed, that fixed the problem with g++-6.2 (g++-5.4 doesn't has this
problem). 

Best, 
Gert 

Bug#844504: debhelper: please stop doing autoreconf when build system is cmake

[Gianfranco Costamagna]

Source: debhelper
Version: 10.2.2
Severity: normal

Hi, I noticed a build failure everywhere with libpng1.6 in experimental.

changes are the switch to cmake, and a bug in the experimental resolver picking 
the wrong autotools.

The main issue seems however to be in debhelper, why is it running autoreconf 
with --buildsystem=cmake?

quoting the build log [1].
I just depend on cmake, not on dh-autoreconf, neither autoreconf or autoconf*

dpkg-buildpackage: info: source package libpng1.6
dpkg-buildpackage: info: source version 1.6.26-3
dpkg-buildpackage: info: source distribution experimental
dpkg-source --before-build libpng1.6-1.6.26
dpkg-buildpackage: info: host architecture amd64
fakeroot debian/rules clean
dh clean --buildsystem=cmake
dh_testdir -O--buildsystem=cmake
dh_auto_clean -O--buildsystem=cmake
dh_autoreconf_clean -O--buildsystem=cmake
dh_clean -O--buildsystem=cmake
debian/rules build-arch
dh build-arch --buildsystem=cmake
dh_testdir -a -O--buildsystem=cmake
dh_update_autotools_config -a -O--buildsystem=cmake
dh_autoreconf -a -O--buildsystem=cmake
main::scan_file() called too early to check prototype at /usr/bin/aclocal line 
644.
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'scripts'.
libtoolize: copying file 'scripts/libtool.m4'
libtoolize: copying file 'scripts/ltoptions.m4'
libtoolize: copying file 'scripts/ltsugar.m4'
libtoolize: copying file 'scripts/ltversion.m4'
libtoolize: copying file 'scripts/lt~obsolete.m4'
main::scan_file() called too early to check prototype at /usr/bin/aclocal line 
644.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 4159.
configure.ac:37: require Automake 1.13, but have 1.11.6
autoreconf: automake failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
debian/rules:14: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libpng1.6&arch=amd64&ver=1.6.26-3&stamp=1479248169

I would appreciate dh-autoreconf being a no-op in case buildsystem is cmake
(I'm not even sure if this is a bug, and if this is in debhelper or 
dh-autoreconf, or whatever, feel free to reassing
in case)


thanks!

cheers,

G.

Bug#844503: salt-call fails with libcrypto.so.1.1: undefined symbol: OPENSSL_no_config

[Filip Pytloun]

Package: salt
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: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#844031: [Pkg-nagios-devel] Bug#844031: [monitoring-plugins] Openssl 1.1 support missing

[Jan Wagner]

Hi,

Am 11.11.16 um 23:25 schrieb Jan Wagner:
> Building against libssl1.0-dev, which was suggested in the
> announcement of the openssl switch, results (actual) into:
> 
> [...]
> checking for PQsetdbLogin in -lpq... no
> configure: WARNING: Skipping PostgreSQL plugin (check_pgsql)
> configure: WARNING: LIBS="-lcrypt " CPPFLAGS="-Wdate-time
> -D_FORTIFY_SOURCE=2 -I/usr/include"
> configure: WARNING: install PostgreSQL libs to compile this plugin
> (see REQUIREMENTS).
> [...]
> 
> This is due postgresql-9.6 beeing linked against libssl1-1-dev and
> libpg5 beeing remove when installing libssl1.0-dev. So check_psql can
> not be build anymore.
> As monitoring-plugins is linked against a couple of libs for it's
> plugins, I expect the same for more plugins when their libs are build
> against openssl 1.1.

This was part of the issue fixed by postgresql-9.6 (9.6.1-2):

[...]
  * libpq-dev: Remove dependency on libssl-dev (and comerr-dev and
krb5-multidev) to unbreak co-installation with libssl1.0-dev.

 -- Christoph Berg   Wed, 02 Nov 2016
11:04:52 +0100
[...]



signature.asc
Description: OpenPGP digital signature

Bug#844503: Acknowledgement (salt-call fails with libcrypto.so.1.1: undefined symbol: OPENSSL_no_config)

[Filip Pytloun]

To reproduce the issue simply install salt-master and run salt-call:

apt-get install salt-master
salt-call

Following exception will occur:

Traceback (most recent call last):
  File "/usr/bin/salt-call", line 11, in 
salt_call()
  File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 346, in 
salt_call
import salt.cli.call
  File "/usr/lib/python2.7/dist-packages/salt/cli/call.py", line 6, in 
from salt.utils import parsers
  File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 28, in 

import salt.config as config
  File "/usr/lib/python2.7/dist-packages/salt/config/__init__.py", line 41, in 

import salt.utils.sdb
  File "/usr/lib/python2.7/dist-packages/salt/utils/sdb.py", line 9, in 
import salt.loader
  File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 30, in 
import salt.utils.event
  File "/usr/lib/python2.7/dist-packages/salt/utils/event.py", line 72, in 

import salt.payload
  File "/usr/lib/python2.7/dist-packages/salt/payload.py", line 17, in 
import salt.crypt
  File "/usr/lib/python2.7/dist-packages/salt/crypt.py", line 42, in 
import salt.utils.rsax931
  File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py", line 69, in 

libcrypto = _init_libcrypto()
  File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py", line 63, in 
_init_libcrypto
libcrypto.OPENSSL_no_config()
  File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in __getattr__
func = self.__getitem__(name)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined symbol: 
OPENSSL_no_config

On 2016/11/16 11:06, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   fi...@pytloun.cz
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  Debian Salt Team 
> 
> If you wish to submit further information on this problem, please
> send it to 844...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 844503: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844503
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems


signature.asc
Description: Digital signature

Bug#844505: disper -S → Segmentation fault

[Jonas Smedegaard]

Package: disper
Version: 0.3.1-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Running "disper -S" simply emits "Segmentation fault".

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

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

Versions of packages disper depends on:
ii  libx11-62:1.6.3-1
ii  libxrandr2  2:1.5.0-1
pn  python:any  

Versions of packages disper recommends:
ii  libnotify-bin  0.7.7-1

disper suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYLEAZAAoJECx8MUbBoAEhe1AP/iQpX0HSGU2xgunrpMuatWM3
n2Ar4uH/Achq9OfBM47YIjKGuL7Wwx2cfkmZ7nwY6rd+cTDSoMbqG7VgRmKj3CCQ
sugIgjWZ/4TCcawk0p/jYx13O+iH5Acz6XKDQYgcjTK6c6kvKu6HE7aEQwyQggfN
qn7JH2WhYmMStkMftGlzGNlh5NHtrOoeZ3a2C7nx+rkQJKE4i/1RHH9TZSClg4lw
KgekWPC/nyjuDqdqSOcaDroEI9D8geYgixtjGF62ipy9kRsDCiCzNryUJy1voLA/
P4USozA0D4P8rbpN1R2bFYaFFDU+QG7FuDm+vWd71oiWW8cW76i89V7Qvj7zkqUC
/113MfbHu13WJWQ+32M7tWWhU3QhcKmu7gvqv4jlgQsnKn1Q9XzBVYbDJbneyfMw
tMqVpig7f2RdXJz/tOoQM7N4+HZ4W+r1Ix7SlWKsq/JzGRqyZmKrlprk87D9wNU+
LGApiPmvEthTAZ7DTZBS5dz8SqKglUV0GlPIEaU08ntnlhB6NS/wuGFpJfGceFF6
S1AlKcHsLHL+yIwlwvuzE24bdXNJ6rfGrtd85ob/sDBFYfRsofaIsbbYLyBptlOF
HoTcO82Tvk7S3030EmPUKF3ZswwfBrfIVezeflMxA9KbaAcqQ7mFBNOHMCLwkjqS
5Ut6FovLTwp30hoJ/YN+
=vBl4
-END PGP SIGNATURE-

Bug#844506: nginx: Fails to build twice in same sourcedir

[Sven-Haegar Koch]

Source: nginx
Version: 1.10.2-2
Severity: minor
Tags: patch

Found while creating a personal jessie backport:

The package fails to build twice in the same source directory, because the
quilt patches for the modules are not removed in the clean target, and
then trying to apply them again fails.

The following patch fixes this, but perhaps not in the nicest way.

(I needed to use ||true because quilt exits with status code 2 when there
are no patches applied yet)

Greetings
Haegar


diff -urN 1/debian/rules 2/debian/rules
--- 1/debian/rules  2016-11-12 08:18:12.0 +0100
+++ 2/debian/rules  2016-11-16 12:07:27.0 +0100
@@ -145,7 +145,7 @@
 override_dh_auto_configure: config_patch_modules $(foreach 
flavour,$(FLAVOURS),config.arch.$(flavour))
 override_dh_auto_build: $(foreach 
flavour,$(FLAVOURS),build.arch.$(flavour))
 override_dh_strip:  $(foreach 
flavour,$(FLAVOURS),strip.arch.$(flavour)) $(foreach 
mod,$(DYN_MODS),strip.mods.$(mod))
-override_dh_clean:  $(foreach flavour,$(FLAVOURS),clean.$(flavour))
+override_dh_clean:  clean_patch_modules $(foreach 
flavour,$(FLAVOURS),clean.$(flavour))
dh_clean
 
 override_dh_install:
@@ -174,6 +174,10 @@
 config.patch.%:
cd $(MODULESDIR)/$* && QUILT_PATCHES=$(MODULESPATCHDIR)/$* quilt push -a
 
+clean_patch_modules: $(foreach mod,$(modules_with_patches),clean.patch.$(mod))
+clean.patch.%:
+   cd $(MODULESDIR)/$* && QUILT_PATCHES=$(MODULESPATCHDIR)/$* quilt pop -a 
-f || true
+
 config.arch.%:
dh_testdir
mkdir -p $(BUILDDIR_$*)
@@ -188,4 +192,4 @@
 clean.%:
rm -rf $(BUILDDIR_$*)
 
-.PHONY: config_patch_modules
+.PHONY: config_patch_modules clean_patch_modules


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'squeeze-lts'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#844454: autopkgtest: does not apply quilt patches when running tests from source package directory

[Martin Pitt]

Control: tag -1 pending

Hello Florian,

Florian Schlichting [2016-11-15 23:39 +0100]:
> When running 'autopkgtest -s -- schroot unstable-amd64-sbuild', quilt
> patches are applied when building the package, but they are not applied
> in tests-tree / real-tree.

Nicely spotted! I did have a test case for this already, but for a
slightly different scenario. I reproduced this in two more tests
and fixed the remaining cases:

  https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=7d49515

Now your command succeeds in a libhttp-throwable-perl-0.026/ directory
with unapplied patches.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#844490: FTBFS with boost1.62

[Thibaut Paumard]

Control: tags 844490 +pending
Control: severity 844495 normal

For the record, the bug appears when doing:

acos(cos(alpha100)*cos(delta100));

where the type of alpha100 and delta100 is
boost::multiprecision::cpp_dec_float_100.

I've realized that, when acos() does not return, delta100 above is
always zero. I can simplify the case by simply doing
acos(cos(alpha100))

in which case acos() also does not return. Does not look like a memory
leak after all.

However, doing just that in an isolated main function does not exhibit
the bug (I've also tried activating all the hardening features)

On the contrary, single-casing delta100==0 does allow Gyoto's test suite
to run through.

So I do have a workaround, that still smells like hiding the problem
under the carpet.

Kind regards, Thibaut.

Bug#844507: ftp.debian.org: Why did old version of my package enter incoming recently?

[Roger Shimizu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: rogershim...@gmail.com

Dear FTP Master,

Recently I found my package wide-dhcpv6 has a old version in incoming
[0] from my QA page [1].

wide-dhcpv6 latest version is 20080615-18, which already entered
testing this week.
So the old version, 20080615-16, in incoming seems weird to me.

Yesterday, reproducible-builds team helped to trigger a rebuild on armhf [2]
I think it should be nothing to do with the issue in incoming.

[0] https://incoming.debian.org/debian-buildd/pool/main/w/wide-dhcpv6/
[1] https://qa.debian.org/developer.php?login=rosh
[2] 
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20161114/007666.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'

[James Cowgill]

Control: reassign -1 binutils 2.25-5
Control: severity -1 important
Control: affects -1 src:fracplanet
Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol 
table

Hi,

On 14/11/16 19:08, Adrian Bunk wrote:
> Package: fracplanet
> Version: 0.4.0-5
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=fracplanet&suite=sid
> 
> g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet 
> obj/common.o obj/control.o obj/control_about.o obj/control_render.o 
> obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o 
> obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o 
> obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o 
> obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o 
> obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o 
> obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o 
> obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o 
> obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o 
> obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o 
> obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o 
> obj/moc_control_terrain.o obj/moc_dialog_documentation.o 
> obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang
>  le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib 
> -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
> /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd'
> 
> 
> Michael Biebl mentioned #844227 on IRC, are these bugs coincidence,
> or is there something that broke/changed in Mesa on mips* recently?

Looking at this a bit closer, it appears to be a longstanding binutils
bug which was recently made worse due to a change in counting local
symbols.

Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the
first (long standing) bug:

$ readelf --syms libGL.so.1 | head -n15
Symbol table '.dynsym' contains 1559 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1: 000163c0 0 SECTION LOCAL  DEFAULT   10
 2: 000902a8 0 SECTION LOCAL  DEFAULT   16
 3: 0007264052 FUNCGLOBAL DEFAULT   11 
glCheckFramebufferStatusE
 4: 0006c47052 FUNCGLOBAL DEFAULT   11 glConvolutionFilter1D
 5: 0007219828 FUNCGLOBAL DEFAULT   11 glVertexAttrib3fvARB
 6: 0006b73052 FUNCGLOBAL DEFAULT   11 glLoadMatrixd
 7: 000943d0 0 NOTYPE  LOCAL  DEFAULT   24 _fbss
 8: 0006c6a052 FUNCGLOBAL DEFAULT   11 
glGetConvolutionParameter
 9: 0006973052 FUNCGLOBAL DEFAULT   11 glVertex4i
10: 0006ebe052 FUNCGLOBAL DEFAULT   11 
glGetBufferPointervARB
11: 0006e3d828 FUNCGLOBAL DEFAULT   11 glWindowPos2f

Here the _fbss symbol is LOCAL which is prohibited by the ELF standard
which requires all LOCAL symbols to precede GLOBAL symbols. This bug is
definitely present in jessie's binutils, because jessie's libGL also
has a symbol table similar to this. Wheezy's mesa doesn't have this bug
but I don't know if binutils definitely doesn't have it in wheezy.

Ordinarily this wasn't much of an issue since glibc and ld would just
skip LOCAL symbols when processing the symbol tables. However somewhere
between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for
calculating the 'st_info' field for the .dynsym section header changed.
Recompiling mesa with both versions of binutils gives identical libGL
binaries except for this difference in the section header:

diffoscope output (- 2.27-9, + 2.27.51.20161108-1):
│ -  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   3  8
│ +  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   9  8

Here 3 = the index of the first non-global symbol, and 9 = the total
number of local symbols. These values should of course be equal if the
rules about symbol ordering were followed. ld uses the value of the
'st_info' field to skip LOCAL symbols when linking, which explains why
only the 5 symbols from 3-8 in the above symbol table cause link errors.

I'm still investigating, but getting a reduced testcase is quite tricky
and recompiling mesa on mips takes about an hour.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#761177: Bug#843397: python-rdflib-jsonld: Requires python-rdflib 4.2.1 to work properly with schema.org contexts

[chrysn]

Hello Andreas,

On Tue, Nov 08, 2016 at 03:12:09PM +0100, Andreas Tille wrote:
> You can now do
> 
>gbp clone 
> ssh://git.debian.org/git/python-modules/packages/sparqlwrapper.git
> 
> I think I'm fine if you ping me about "the latest commit that can be
> uploaded".  Please do not tag at this point in time since its not sure
> that it will be uploaded as is.

now being part of the DPMT, I could push to the repository. To err on
the side of caution, I didn't push my upstream tag either; you'll
probably need to

git tag upstream/1.7.6 ecd5c3dc5869e3bc4f0cc7f8c41a8a93eb8ab291

to build the the master (768719500f19fab7a06f8128373927f109a4ee9e).

The package should build cleanly in any environment, and lintian should
produce only spelling-error-in-description-synopsis warnings[1].

Please sponsor this as a team upload.

Thanks
chrysn

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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#844508: RM: akonadi-googledata -- ROM; Upstream dead, not usable and newer alternative is available

[Sandro Knauß]

Package: ftp.debian.org
Severity: normal

Hey,

I request to delete akonadi-googledata for stretch, because:
 * upstream is dead for around four year
 * not needed anymore, because libkgapi
 * an akonadi-resource for google data is created directly in
   kdepim-runtime package depending on libkgapi
 * is used by kdepim based on KDE 4 on unstable we have kdepim depended
   on KF 5
 * akonadi4 do not ship anymore a akonadi binary, so there is nothing
   that could consume that akonadi resource (akonadi resources build
   against Qt4/KDE4 are not compatible with Qt5/KF5)
 * it is a leaf package - no reverse dependencies.

For users, using kdepim they need kdepim-runtime to be installed to have the new
google resources available, but kdepim-runtime is already a hard
dependency for kdepim (kontact, kmail, korganizer) packages, so we do not need
to provide a special upgrade path.

The only problem that can occur for users, is that the new akonadi don't
do a default upgrade to the new resource. But the upgrade process from
akonadi4 -> akonadi5 must be done anyways and this old package isn't
helping in this upgrade process.

Me is part of the Debian Qt/KDE Maintainers Team, that is the maintainer
of the package. I actually filed a Bug against akonadi-googledata
[#844247], to make sure that the whole team is informed about the
planned removal. I talked with others at IRC #debian-kde-qtand they also
think, that requesting the removal is the right thing to do.

Best Regards,

Sandro Knauß

Bug#835661: Pending fixes for bugs in the prometheus package

[Pirate Praveen]

On Mon, 14 Nov 2016 01:34:24 +
pkg-go-maintain...@lists.alioth.debian.org wrote:
> Commit message:
> 
> Replace libjs-handlebars with libjs-mustache. Closes: #835661.

Great to see prometheus remaining in main by removing dependency on
libjs-handlebars.

Any blockers to this upload? I'd like to reupload the libjs-handlebars
package in experimental to unstable once you upload prometheus without
libjs-handlebars dependency.

This will allow me to move ruby-handlebars-assets to contrib from
non-free as node-handlebars provided by libjs-handlebars source package
currently in experimental provides source code for ruby-handlebars-assets.




signature.asc
Description: OpenPGP digital signature

Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Gianfranco Costamagna]

control: tags -1 pending
Hi,

I'm currently going to test a build for the attached patch, will upload in 
deferred/5 in case everything is good.

Please let me know if I can speed it up, or you want to do a maintainer upload 
:)

thanks!

G.
diff -Nru cython-0.24.1/debian/changelog cython-0.24.1/debian/changelog
--- cython-0.24.1/debian/changelog  2016-08-11 19:50:15.0 +0200
+++ cython-0.24.1/debian/changelog  2016-11-16 11:55:53.0 +0100
@@ -1,3 +1,11 @@
+cython (0.24.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch:
+- fix macs build failure (Closes: #833288)
+
+ -- Gianfranco Costamagna   Wed, 16 Nov 2016 
10:09:01 +0100
+
 cython (0.24.1-2) unstable; urgency=medium
 
   * patches/deb_nopngmath
diff -Nru 
cython-0.24.1/debian/patches/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch 
cython-0.24.1/debian/patches/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch
--- cython-0.24.1/debian/patches/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch 
1970-01-01 01:00:00.0 +0100
+++ cython-0.24.1/debian/patches/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch 
2016-11-16 10:09:23.0 +0100
@@ -0,0 +1,57 @@
+From 6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2 Mon Sep 17 00:00:00 2001
+From: Robert Bradshaw 
+Date: Tue, 15 Nov 2016 22:42:03 -0800
+Subject: [PATCH] Don't infer unbond function types for bound methods.
+
+This fixes #551.
+---
+ Cython/Compiler/ExprNodes.py |  4 
+ tests/run/type_inference.pyx | 23 +++
+ 2 files changed, 27 insertions(+)
+
+diff --git a/Cython/Compiler/ExprNodes.py b/Cython/Compiler/ExprNodes.py
+index 8bfb538..85fc39a 100644
+--- a/Cython/Compiler/ExprNodes.py
 b/Cython/Compiler/ExprNodes.py
+@@ -6205,6 +6205,10 @@ def infer_type(self, env):
+ # builtin types cannot be inferred as C functions as
+ # that would prevent their use as bound methods
+ return py_object_type
++elif self.entry and self.entry.is_cmethod:
++# special case: bound methods should not be inferred
++# as their unbound method types
++return py_object_type
+ return self.type
+ 
+ def analyse_target_declaration(self, env):
+diff --git a/tests/run/type_inference.pyx b/tests/run/type_inference.pyx
+index ab74108..cf10eed 100644
+--- a/tests/run/type_inference.pyx
 b/tests/run/type_inference.pyx
+@@ -722,3 +722,26 @@ cdef class InferInProperties:
+ d = enum_y
+ c = d
+ return typeof(a), typeof(b), typeof(c), typeof(d)
++
++cdef class WithMethods:
++cdef int offset
++def __init__(self, offset):
++self.offset = offset
++cpdef int one_arg(self, int x):
++return x + self.offset
++cpdef int default_arg(self, int x, int y=0):
++return x + y + self.offset
++
++def test_bound_methods():
++  """
++  >>> test_bound_methods()
++  """
++  o = WithMethods(10)
++  assert typeof(o) == 'WithMethods', typeof(o)
++
++  one_arg = o.one_arg
++  assert one_arg(2) == 12, one_arg(2)
++
++  default_arg = o.default_arg
++  assert default_arg(2) == 12, default_arg(2)
++  assert default_arg(2, 3) == 15, default_arg(2, 2)
diff -Nru cython-0.24.1/debian/patches/series 
cython-0.24.1/debian/patches/series
--- cython-0.24.1/debian/patches/series 2016-08-11 19:50:15.0 +0200
+++ cython-0.24.1/debian/patches/series 2016-11-16 10:09:01.0 +0100
@@ -1,3 +1,4 @@
 deb_nopngmath
 deb_disable_googleanalytics
 honour_SOURCE_DATE_EPOCH_for_copyright_year
+6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch


signature.asc
Description: OpenPGP digital signature

Bug#844509: [openblas/custom build] please consider appending -march&-mtune parameters when building custom package

[lumin]

Package: libopenblas-base
Version: 0.2.19-1
Severity: minor

Hi,

BLAS is performance sensitive software, would you mind adding

  -march=native -mtune==native

to CFLAGS when building custom package with the debian source?

Thanks.

Bug#844496: seccomp "Invalid argument" due to old library version

[Laurent Bigonville]

tag 844496 + patch
thanks

On Wed, 16 Nov 2016 11:02:08 +0100 =?UTF-8?Q?Stefan_B=c3=bchler?= 
 wrote:

> Hi,
>
> pdns.service (from pdns-server in testing) didn't start anymore with
> this message:
>
> pdns.service: Failed at step SECCOMP spawning /usr/sbin/pdns_server: 
Invalid argument

>
> Updating libseccomp2 from 2.1.1-1 (stable) to 2.3.1-2 (testing) fixed
> it.
>
> systemd 232-3 has a build dependency `libseccomp-dev (>= 2.2.3-3~)`, but
> the resulting package only depends on `libseccomp2 (>= 2.1.0)`.
>
> I guess systemd uses a feature from newer libseccomp versions which
> wasn't tracked by the symbols file. Maybe you should consider upgrading
> the minimum versions in the symbols file. (Probably broken in backports
> too.)


The attached patch should fix this I think

Cheers,

Laurent Bigonville
diff -Nru libseccomp-2.3.1/debian/libseccomp2.symbols libseccomp-2.3.1/debian/libseccomp2.symbols
--- libseccomp-2.3.1/debian/libseccomp2.symbols	2016-05-16 12:15:58.0 +0200
+++ libseccomp-2.3.1/debian/libseccomp2.symbols	2016-11-16 12:41:47.0 +0100
@@ -1,4 +1,5 @@
 libseccomp.so.2 libseccomp2 #MINVER#
+* Build-Depends-Package: libseccomp-dev
  seccomp_attr_get@Base 0.0.0~20120605
  seccomp_attr_set@Base 0.0.0~20120605
  seccomp_export_bpf@Base 0.0.0~20120605

Bug#844510: RFS: pyfr/1.5.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: pyfr
  Version : 1.5.0-1
  Upstream Author : Imperial College London
* URL : http://www.pyfr.org
* License : BSD
  Section : science

It builds those binary packages:

  pyfr  - flux reconstruction in Python
  pyfr-doc   - documentation for PyFR

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pyfr/pyfr_1.5.0-1.dsc


Changes since the last upload:

  * Track GitHub instead of PyPI releases.
  * Refresh patch queue.
  * Add missing build dependencies on h5py, mako, numpy and pytools.
  * Add new build dependency on gimmik.
  * Upgrade packaging to debhelper 10.
  * Drop superfluous Testsuite field.

Regards,
Ghislain Vaillant

Bug#843773: [buildd-tools-devel] Bug#843773: Bug#843773: Bug#843773: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoting Holger Levsen (2016-11-14 18:25:34)
> To me it seems a binNMU should change SOURCE_DATE_EPOCH, as debian/changelog
> gets modified by changelog.$arch, so it's actually a different source which
> is being build.

debian/changelog doesn't get modified by changelog.$arch. The latter is
generated by dh_installchangelogs from debian/changelog and gets installed into
the binary package. The order is (currently) the following:

 - "nmu" command is sent to wanna-build
 - sbuild is executed with the --make-binNMU on the buildds
 - sbuild modifies debian/changelog in the source package by adding a new
   changelog entry at the top, copying the timestamp of the last entry
 - sbuild executes dpkg-buildpackage
 - dpkg-buildpackage parses debian/changelog and calculates SOURCE_DATE_EPOCH
   from the top-most entry
 - debian/rules calls dh_installchangelogs which creates changelog.$arch

Maybe you were talking about reproducing the package build from the timestamp
in changelog.$arch?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#838294: dvdisaster: please consider packaging

[Karsten Hilbert]

Package: dvdisaster
Version: 0.79.3-1
Followup-For: Bug #838294

Dear maintainers,

it would be really nice if you would consider packaging the newer version
which is much faster on modern machines.

Thanks for your time,
Karsten


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages dvdisaster depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-5
ii  libcairo2   1.14.6-1.1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libglib2.0-02.50.2-1
ii  libgtk2.0-0 2.24.31-1
ii  libpango1.0-0   1.40.3-3
ii  xdg-utils   1.1.1-1

Versions of packages dvdisaster recommends:
ii  dvdisaster-doc  0.72.4-1

dvdisaster suggests no packages.

-- no debconf information

Bug#810489: Merge the node-nodeunit

[Adrian Bunk]

Control: forcemerge 810489 844307

Hi Jonathan, hi Pirate,

both of you submitted ITPs for node-nodeunit.

Please coordinate who of you will actually package it.

Thanks
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#844393: blhc still uses dpkg architecture triplets

[Simon Ruderich]

On Tue, Nov 15, 2016 at 08:47:41AM +0100, Johannes Schauer wrote:
> Hi,
>
> recently, dpkg switched from the triplettable to architecture
> quadruplets. When now trying to run blhc with the new libdpkg-perl, one
> will get:
>
> Undefined subroutine &Dpkg::Arch::debarch_to_debtriplet called at 
> /usr/bin/blhc line 1032.

Hello,

Fixed in bf41976 [1].

Jari, could you please cherry-pick this commit and apply it to
the Debian package.

Regards
Simon

[1]: 
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=bf419763b81c704b86244b0b7f0e92dda492af8a
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#844297: Workaround

[Thierry Fouchard]

Hi,

Keeping @include common-auth in /etc/pam.d/vsftpd and apt-get remove
libpam-smbpass make vsftpd working again.

I have not noticed any side effect on Samba AD member server integration.

Best regards,
Thierry

Bug#844393: blhc still uses dpkg architecture triplets

[Eriberto Mota]

2016-11-16 9:46 GMT-02:00 Simon Ruderich :
> On Tue, Nov 15, 2016 at 08:47:41AM +0100, Johannes Schauer wrote:
>> Hi,
>>
>> recently, dpkg switched from the triplettable to architecture
>> quadruplets. When now trying to run blhc with the new libdpkg-perl, one
>> will get:
>>
>> Undefined subroutine &Dpkg::Arch::debarch_to_debtriplet called at 
>> /usr/bin/blhc line 1032.
>
> Hello,
>
> Fixed in bf41976 [1].


Thanks Simon.


> Jari, could you please cherry-pick this commit and apply it to
> the Debian package.


If needed, I can sponsor it to speed up.

Regards,

Eriberto

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Felipe Sateler]

On 15 November 2016 at 18:17, Wookey  wrote:
> On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
>> On Tue, 15 Nov 2016 17:22:12 + Wookey  wrote:
>> > Package: dpkg
>> > Version: 1.18.10
>> > Severity: normal
>> >
>> > I built a large package (mythtv) with this recipie:
>> > git clone https://github.com/MythTV/packaging -b fixes/0.28
>> > cd packaging/deb
>> > ./build-debs.sh fixes/0.28
>> >
>> > This all works fine until the dh_shlibdeps when packing it up at the
>> > end.
>> >
>> > which complains about missing dependency info for
>> > /usr/lib/ld-linux-armhf.so.3
>>
>> This is the same as #843073, so merging. Raphael has proposed a patch
>> on that bug, but it needs more testing before it is accepted.
>
> Right. Cheers for that. (I failed to check the dpkg bugs first because
> I started filing against glibc and checked that list, then realised
> part way through that this was best filed against dpkg).
>
> How is the usrmerge done? bind-mounting? hardlinks?

Softlinks. /bin => usr/bin, /sbin => usr/sbin , /lib => usr/lib,
/lib${multilib} => usr/lib/lib${multilib} .

> Is dpkg-shlibdeps the only thing that is going to wrong if files stop
> having a canonical location in the system? It's a pretty major change
> having every library (and a load of binaries?) appear twice? (Or do I
> misunderstand how this is implemented?).

Guillem pointed out on IRC that dpkg-query --search will also be confused.
For most things it shouldn't matter, as things will be where people expect
them. Some other programs are bound to be confused. systemd-delta, for
example, was also confused, but it was fixed already. To my knowledge,
dpkg-query --search and dlocate are the only ones (in fact, the problem in
dpkg-shlibdeps is because it uses dpkg-query --search).

> Like Guillem, I'd be a lot happier if files, especially libraries,
> only existed in the place they existed, and if we want to move that
> then we should move it in the packaging.

That would be great from my POV. However, it has some drawbacks: Stuff in
/bin cannot be moved to /usr/bin until /bin is a link to /usr/bin (ditto
sbin). Otherwise, for example fsck won't find the /sbin/fsck.$fs programs.
In general, way too many things hardcode paths in /bin or /sbin. So the
options are a period where package metadata does not match the filesystem,
or we have a long period of uninstallability until all packages + usrmerge
are installed.

> Isn't there potential for
> autoconf or libtool to get confused too?

Yes, there is some potential for confusion. If you program detects the path
of binaries or libraries and then hardcodes that, it may get paths wrong,
as it will probably choose the / path over the /usr one. This won't be a
problem for usrmerged systems, but it will for non-merged ones.

> Anyway, I'll test raphael's patch.

Thanks!

-- 

Saludos,
Felipe Sateler

Bug#843910: cups-pdf FTCBFS: uses build architecture compiler

[Martin-Éric Racine]

2016-11-10 18:10 GMT+02:00 Helmut Grohne :
> Source: cups-pdf
> Version: 2.6.1-21
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> cups-pdf fails to cross build from source, because it uses the build
> architecture compiler. Defaulting CC to a triplet-prefixed compiler
> fixes the build. Please consider applying the attached patch.
>
> Helmut

Thanks for the patch.

I cannot help but wonder if setting CC for cross-build would be best
handled by the build tools themselves, rather than compensated for by
individual packages' debian/rules.

Opinions?

Cheers!
Martin-Éric

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On 2016, നവംബർ 12 9:46:15 PM IST, Pirate Praveen  wrote:
>We now have grunt in the archive, but the upstream philosophy of grunt
>is to force everyone to use a locally installed grunt for each project
>and not support using globally installed grunt (patches for this
>support
>was rejected upstream).
>
>We'll need to patch grunt to be able to use it for building packages in
>debian environment.
>
>http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-November/015240.html
>
>I hope we can resolve this issue before stretch release.

This issue of building projects with globally installed grunt is fixed by 
patching grunt.

But there are more hurdles for handlebars.

1. It needs packaging of babel-runtime, babel-handlers and grunt-babel. I hope 
to be able to package them.

But it also needs webpack, which I hope to work around by using 
node-browserify-lite.

>So I'd like to request exception for packages if the build system is
>using gulp or browserify, 

But if I fail to get libjs-handlebars built using node-browserify-lite and will 
need to package webpack, I'd like to ask an exception for libjs-handlebars as 
well, because its a case similar to grunt, needs more than 100 dependencies 
packaged.

Bug#843983: [Vmdebootstrap-devel] Bug#843983: vmdebootstrap: root of squashfs filesystem has no g+x or o+x permissions

[Iain R. Learmonth]

Control: affects 843983 live-wrapper

Hi,

Uploaded 0.5 of live-wrapper to unstable with a workaround, but this should
be better fixed in vmdebootstrap still.

Thanks,
Iain.

Bug#698527: Already fixed in oldstable

[Adrian Bunk]

Control: reopen -1

On Sat, Oct 29, 2016 at 06:13:21PM +0200, Francesco Poli wrote:
> On Mon, 17 Oct 2016 22:59:06 +0200 Francesco Poli wrote:
> 
> > On Sat, 15 Oct 2016 19:54:28 +0300 Adrian Bunk wrote:
> > 
> > > I am closing this bug since it is already fixed in oldstable.
> > 
> > ElmerGUI is included in the experimental package (elmerfem/7.0.svn.6034
> > +dfsg-2): it's not clear to me how the OpenSSL linking issue was solved.
> > I cannot find any explanation in the changelog: could someone please
> > clarify?
> > 
> > Please let me know.
> > Thanks for your time!
> 
> Ping?

Thanks a lot for noticing, and apologies for the late reply.

I completely missed that the more recent version in experimental
is not fixed, reopening.

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#810489: Merge the node-nodeunit

[Pirate Praveen]

Control: owner -1 "Pirate Praveen  wrote:
> Control: forcemerge 810489 844307
> 
> Hi Jonathan, hi Pirate,
> 
> both of you submitted ITPs for node-nodeunit.
> 
> Please coordinate who of you will actually package it

I have it almost complete in pkg-javascript alioth git repo.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#844511: should libvirt be FTBFS at the moment due to the new gnutls?

[Christian Ehrhardt]

Package: libvirt
Version:  2.4.0-2

Hi,

#1 - not the bug, but required background
I ran into an issue on Ubuntu recently and along debugging I found that you
have the same issue in regard to the recent gnutls version breaking libvirt
autotests.
I work on that issue in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1641615 and I think
we need to get a fix upstream to libvirt for that and then pull that into
Debian and Ubuntu.

#2 - the bug?
But in regard to the Debian packaging I wondered why your build succeeds,
but found you have just the same issue.
Search:
https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=amd64&ver=2.4.0-2&stamp=1479241026
For: "FAIL: virnettlssessiontest"

I thought that on the amd64 build the FAIL_CHECK in d/rules should be set
and make this a test result a build breaking error, but it did not.

So I wonder - is it a bug that this actually "should" be a FTBFS for you as
well?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#835274: dh-text no longer needed

[Christian Seiler]

Hi there,

Am 16. November 2016 10:28:41 MEZ, schrieb Dmitry Bogatov :
>  * Drop diet libc build due issues with errno

As a current co-maintainer of dietlibc in Debian, could you elaborate here? 
I've spent the last couple of months fixing all sorts of bugs in there (and 
improving packaging, for example dietlibc-dev is now M-A: same), and if 
problems remain, I'd also like to see them fixed.

Of course, you are free to use/drop usage of dietlibc for whatever reason, and 
maybe there are others than just a specific bug. But irrespective of whether 
you keep building against it, I'd like to fix potential bugs.

Thanks,
Christian

Bug#844512: reprotest: make diffoscope optional

[Ximin Luo]

Package: reprotest
Version: 0.3.2
Severity: wishlist

Dear Maintainer,

It would be good to make diffoscope optional. Sometimes for various reasons a
developer might want to run reprotest inside a container/chroot/environment
where they don't want to install diffoscope. Then reprotest should save the
build output so the user can copy it to a system that does have diffoscope.

For example I have access to a remote jessie machine, so I have to run all my
builds inside a schroot already. Inside the schroot I run reprotest with a null
virtual server, but I don't want diffoscope's dependencies to possibly affect
the build.

(Yes I could use another schroot inside the schroot but I have a feeling this
wouldn't work so well and I'd rather not spend time debugging it. Also this
would not be possible on Debian porter machines where we don't have root to be
able to set up the inner schroots.)

X

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

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

Versions of packages reprotest depends on:
ii  apt-utils  1.3.1
ii  diffoscope 62
ii  libdpkg-perl   1.18.10
ii  procps 2:3.3.12-2
ii  python3-debian 0.1.29
ii  python3-pkg-resources  28.0.0-1
pn  python3:any

Versions of packages reprotest recommends:
ii  autodep8 0.8
ii  disorderfs   0.5.1-1
ii  locales-all  2.24-5
ii  qemu-system  1:2.7+dfsg-3
ii  qemu-utils   1:2.7+dfsg-3
ii  schroot  1.6.10-2+b1

reprotest suggests no packages.

-- no debconf information

Bug#844513: Uncaught bootstrap-datetimepicker requires Moment.js to be loaded first

[Sam Morris]

Package: prometheus
Version: 1.2.3+ds2-1
Severity: normal

The graph editor does not work, and the following messages are logged in
the browser console:

Uncaught bootstrap-datetimepicker requires Moment.js to be loaded first

http://prometheus:9090/static/eonasdan-bootstrap-datetimepicker/bootstrap-datetimepicker.min.js:31
Uncaught TypeError: self.endDate.datetimepicker is not a function
http://prometheus:9090/static/js/graph.js?v=1:112

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (500, 'testing-updates'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.7.0-0.bpo.1-686-pae (SMP w/1 CPU core)
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 prometheus depends on:
ii  daemon   0.6.4-1
ii  libc62.19-18+deb8u6
ii  libjs-bootstrap  3.3.7+dfsg-2
ii  libjs-eonasdan-bootstrap-datetimepicker  4.17.43-1
ii  libjs-handlebars 2:0.21.0-5
ii  libjs-jquery 3.1.1-1
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2
ii  libjs-rickshaw   1.5.1.dfsg-1

Versions of packages prometheus recommends:
pn  prometheus-cli
ii  prometheus-node-exporter  0.12.0+ds+really0.12.0-2

prometheus suggests no packages.

-- Configuration Files:
/etc/default/prometheus changed [not included]
/etc/prometheus/prometheus.yml changed [not included]

-- no debconf information

Bug#844514: mosh: major issues with queued control sequences

[Dominik George]

Package: mosh
Version: 1.2.6-1+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have trouble using mosh together with screen and even a normal shell
because mosh does not handle control sequences correctly.

Two example:

  Ctrl-A n  for switching to the next screen inside GNU screen works
  under normal circumstances, but when the connection gets bad and
  mosh starts queueing and predicting things, once the connection comes
  back, ^An is written to the shell verbatim, making the behaviour
  wrong and non-deterministic and even leading to data corruption
  if unnoticed.

  Escape sequences, like  Esc #  for terminating the current shell
  input line and prefixing it with a #, do not work at all.

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

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

Versions of packages mosh depends on:
ii  dpkg1.18.10
ii  libc6   2.24-5
ii  libgcc1 1:6.2.0-10
ii  libprotobuf10   3.0.0-7
ii  libssl1.0.2 1.0.2j-1
ii  libstdc++6  6.2.0-10
ii  libtinfo5   6.0+20160917-1
ii  libutempter01.1.6-3
ii  openssh-client  1:7.3p1-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  libio-socket-ip-perl  0.37-1
ii  perl-base [libio-socket-ip-perl]  5.24.1~rc3-3

mosh suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJYLFAAMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
MOMP/i/hkXApBtJh6XQIPpgn+OCmQJ+0XU+KaAQs2/DHWZ3Hq8ECkL7wF8ZXB9RS
gtMyDcLvCo7WTp6FWdAosZ3ScITn/gq99r+u74wKUdowPbVwykvnJDZZVDmE1JS6
3+EJujCBUMI6A8SldgtfDal9KCbVK+rOYayAf//lIoAkP32kT+Xy6vhCTuCRFcUB
zHXGuYG0g0JeEjS8o01vsyDc9mrWamKId7gaHme3wNXWuUTILaxVC93O5XauBtYW
VNjq9wNof/fR9lHAcTR1bSV2X+7mRUyRtmrznZ/H/ikw/0j/+V68HiYT0JE9hS1O
bEo3nFlkOKAOk/zcMoYMdzM8pzQOXGQ72SymaEwb7H6R2R2rHHPTjhQtuByagHq8
yvY58sQnmAhQ+UUK8d8JYJdBFxwVt6uVxrv6iYLhSM41tNsMzcQRUZcu9XfvDPaL
XK6A2d/gdMRROYDExJQ0wontaaRqnPGPYbg/YLd/NrGuJsz5Ot3l2XqIFJF3tY8w
ksac7cKThYS0SjdsJhtC/I657t2Acz8HNeSInJXX3s3seVuS3rqhLI0rfuJYeC8a
jFTXfST0PQCAeXz41enan8DuewVlm+HFYfRd4+7L+fEJgLzTfUhZ0wI6Ua5KOToU
Q6H9Hyo1mknfcvGTDghNfWNrOVr+uecLr/mRvrxGNnhSq4Jg
=Av/J
-END PGP SIGNATURE-

Bug#722497: "Waiting for headers" without progress

[Vincent Lefevre]

Control: found -1 1.3.1

I also have this bug on one of my machines, both with "apt update" and
with aptitude. Since the bug is noticeable in aptitude, I suppose that
the actual bug is in libapt-pkg5.0, not in apt itself.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#828231: Building with OpenSSL 1.0.2 is sufficient for stretch

[Sebastian Andrzej Siewior]

Control: tags -1 - patch

On 2016-11-10 12:31:00 [+0200], Adrian Bunk wrote:
> 
> Not a perfect solution but sufficient for stretch is the following 
> change to use OpenSSL 1.0.2:
> 
> --- debian/control.old2016-11-10 10:20:58.0 +
> +++ debian/control2016-11-10 10:21:32.0 +
> @@ -5,7 +5,7 @@
>  Uploaders: Andreas Tille , Luke Faraone 
> ,
>   Unit 193 
>  Build-Depends: debhelper (>= 9), libldap2-dev, libpam0g-dev, libncurses-dev,
> - libssl-dev, dh-autoreconf, ca-certificates, automake, autoconf, libtool, 
> libkrb5-dev,
> + libssl1.0-dev, dh-autoreconf, ca-certificates, automake, autoconf, libtool, 
> libkrb5-dev,
>   aspell, dpkg-dev (>= 1.16.1~)
>  Standards-Version: 3.9.6
>  Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/alpine.git

Adrian, seriously? This is not a patch. While you are technically
correct to describe this is a patch - it is not.
The issue reported here (not building against openssl 1.1.0) is not
solved by this. Tagging this as patch makes people think that there is
indeed a patch which is not the case.
If the maintainer decides to stick with openssl 1.0.2 for the Stretch
release I assume he is able to do the change himself and lowering the
severity to important rather than closing this bug.
Please also untag any other patch tag in other bugs should they contain
only this kind of a patch.

> cu
> Adrian

Sebastian

Bug#844515: packer: FTBFS on s390x (go install -v -p 1 died with signal 4)

[Daniel Stender]

Package: packer
Version: 0.10.1+dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Packer currently (recently 0.10.2+dfsg-1) fails to build on s390x:


   dh_auto_build -O--buildsystem=golang
cd obj-s390x-linux-gnu
go install -v -p 1
dh_auto_build: go install -v -p 1 died with signal 4
cd /<>/packer-0.10.2+dfsg
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 255
dpkg-buildpackage: error: debian/rules build gave error exit status 2


This is a regression from 0.10.1+dfsg-1 [1] (the build on 2016-10-16 [2] failed
for a dependency reason which is solved in the meanwhile, see #841605 [3]).

[1] https://buildd.debian.org/status/logs.php?pkg=packer&arch=s390x

[2] 
https://buildd.debian.org/status/fetch.php?pkg=packer&arch=s390x&ver=0.10.1%2Bdfsg-1&stamp=1476596269

[3] https://bugs.debian.org/841605 (packer: FTBFS: 
src/github.com/Azure/go-autorest/autorest/azure/token.go:140: undefined: 
jwt.MapClaims)

I can reproduce this locally in a qemu-chroot for Sbuild, however a test build 
on
the zelenka porterbox succeeded:


{...}
dpkg-deb: building package 'golang-github-mitchellh-packer-dev' in 
'../golang-github-mitchellh-packer-dev_0.10.2+dfsg-1_all.deb'.
dpkg-deb: building package 'packer' in '../packer_0.10.2+dfsg-1_s390x.deb'.
 dpkg-genbuildinfo
dpkg-genbuildinfo: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
 dpkg-genchanges  >../packer_0.10.2+dfsg-1_s390x.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build packer-0.10.2+dfsg
dpkg-buildpackage: info: full upload (original source is included)
(sid_s390x-dchroot)stender@zelenka:~/sandbox/packer-0.10.2+dfsg$


Thanks for hints,
DS

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

Kernel: Linux 4.7.0-1-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 packer depends on:
ii  libc6  2.24-5

Versions of packages packer recommends:
pn  docker.io  
ii  qemu   1:2.7+dfsg-3+b1

Versions of packages packer suggests:
ii  ansible  2.1.1.0-1
pn  chef 

-- no debconf information

Bug#835274: dh-text no longer needed

[Gianfranco Costamagna]

control: tags -1 moreinfo


>Of course, you are free to use/drop usage of dietlibc for whatever reason, and 
>maybe there are others than just a specific bug. But irrespective of whether 
>you keep >building against it, I'd like to fix potential bugs.



this is worth a moreinfo tag :)


G.

Bug#761177: Bug#843397: python-rdflib-jsonld: Requires python-rdflib 4.2.1 to work properly with schema.org contexts

[Andreas Tille]

On Wed, Nov 16, 2016 at 12:40:59PM +0100, chrysn wrote:
> Hello Andreas,
> 
> On Tue, Nov 08, 2016 at 03:12:09PM +0100, Andreas Tille wrote:
> > You can now do
> > 
> >gbp clone 
> > ssh://git.debian.org/git/python-modules/packages/sparqlwrapper.git
> > 
> > I think I'm fine if you ping me about "the latest commit that can be
> > uploaded".  Please do not tag at this point in time since its not sure
> > that it will be uploaded as is.
> 
> now being part of the DPMT, I could push to the repository. To err on
> the side of caution, I didn't push my upstream tag either; you'll
> probably need to
> 
> git tag upstream/1.7.6 ecd5c3dc5869e3bc4f0cc7f8c41a8a93eb8ab291
> 
> to build the the master (768719500f19fab7a06f8128373927f109a4ee9e).
> 
> The package should build cleanly in any environment, and lintian should
> produce only spelling-error-in-description-synopsis warnings[1].

I droped the duplicated Python in the short description to work around
this and I also used DPMT as Maintainer and put Olivier and you as
Uploaders which seems to reflect the reality.  I hope you are OK with
this.

> Please sponsor this as a team upload.

Done - thanks a lot for your work on this

 Andreas.

-- 
http://fam-tille.de

Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot

[Martin Pitt]

Hello Josch,

Johannes Schauer [2016-11-16  1:12 +0100]:
> in the context of #833407 I told you about my plan of adding a
> virtualization backend which would allow completely unprivileged chroot
> operation by using linux user namespaces.

Nice!

> In contrast to what I thought was required back then, I now managed
> to write that backend using just lxc-usernsexec and lxc-unshare.
> Thus, I was able to get it to work using the existing Python
> modules. You can find the script attached.  As you can see, it is
> extremely simple, which I find makes the beauty of it all. All you
> need is:

>  - the lxc package installed for lxc-usernsexec and lxc-unshare

I'd like to eliminate this even. util-linux' unshare has known about
--user/-U for a while now, and thus replaces lxc-unshare and
lxc-usernsexec:

  $ unshare -rmU  sh -c 'whoami; mount -t tmpfs foo /mnt; touch /mnt/foo; ls -l 
/mnt/foo'
  root
  -rw-r--r-- 1 root root 0 Nov 16 12:59 /mnt/foo

And you can use util-linux' nsenter to enter an existing namespace.

These lxc-* tools were written before util-linux learned about those,
and I'm not sure if they are going to stick around forever as they are
basically obsolete. It would also avoid the lxc dependency.

Would you be willing to try this?

>  - sbuild from git (a tiny fix to its autopkgtest backend is required)

OOI, is that required for running autopkgtest with uchroot itself, or
"just" sbuild's integration with automatically running autopkgtest
after a package build?

> $ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=uchroot \
> --autopkgtest-virt-server-opts="-- /srv/chroot/%r-%a-sbuild.tar.gz 
> /tmp/rootfs"
> 
> The path /tmp/rootfs is the path that the rootfs will be extracted to
> and can be at any location that the user has access to.

I think it would be more comfortable to use mkdtemp() by default, and
provide --unpack-dir as an option?

> I don't think there is an existing backend which allows unprivileged
> package building with so little overhead in terms of configuration.

lxd is quite nice and similarly easy (and a bit more powerful too),
but unfortunately not available in Debian right now.

> It would be great if this backend could be added to autopkgtest itself.
> If you think that it is not a good fit for autopkgtest, then I can
> maintain it in a separate package.

I think it would be a great fit, but in order to accept it I have some
stricter requirements:

 * tests/autopkgtest should run at least the standard
   DebTestsVirtContainer tests. Look at classes LxcRunner and LxdRunner, should
   be a fairly simple extension.

   This will show the limits of what the backend can do, uncover
   possible encoding/locale/whatever issues, and ensure that this will
   keep working over time.

 * It should get a manpage, probably starting from
   virt/autopkgtest-virt-chroot.1.

As building such a chroot tarball doesn't require new tools, that
should be it (the manpage should just explain how to build them, with
sbuild-createchroot or mk-sbuild).

I actually have wanted to deprecate the "chroot" backend for a long
time, as it's inherently insecure and I never use it myself any more.
I wonder if uschroot could completely replace that? At first sight it
should have the same isolation and robustness capabilities like
lxc/lxd (at least wrt. the file system and mounting), except with a
lot fewer dependencies.

| tarball = None
| rootdir = None
| 
| 
| def parse_args():
| global tarball, rootdir
| 
| parser = argparse.ArgumentParser()
| parser.add_argument('-d', '--debug', action='store_true',
| help='Enable debugging output')
| parser.add_argument('tarball', help='path to rootfs tarball')
| 
| def hook_open():
| global tarball, rootdir
| 
| # We want to find out our user and group id inside the chroot but we want
| # to avoid having to parse /etc/subuid and /etc/subgid. We solve the
| # situation by creating a temporary file from inside the user namespace
| # and then checking its user and group ids from outside the user 
namespace.
| probe = VirtSubproc.check_exec(['lxc-usernsexec', 'mktemp',
| '/tmp/uchroot.XX'], outp=True)
| inner_uid = os.stat(probe)[stat.ST_UID]
| inner_gid = os.stat(probe)[stat.ST_GID]
| VirtSubproc.check_exec(['lxc-usernsexec', 'rm', probe])
| outer_uid = os.getuid()
| outer_gid = os.getgid()

This dance wouldn't even be necessary with unshare -rU -- you know
that the outside uid/gid is just the normal user, and the inside one
is root/root.

I'm not sure if there is something to be gained from the UID shift --
that isolates the chroot test better, but also makes it much harder to
clean up after a failed tests, as your normal user cannot touch/rm the
temporary directories? But if you want this, there's newuidmap(1).

| # Unpack the tarball into the new directory.
| # Make sure not to extract any character special files because w

Bug#844465: libelfin: FTBFS on several architectures with test errors

[Petter Reinholdtsen]

I had a closer look at m68k, which surprised me if the problem is all
big endian machines.  And the only reason the build succeeded in m68k,
I believe, is that the dh_auto_test script did not run the test suite.

This make me believe the problem is simply that this library only work
on little endian machines.  
-- 
Happy hacking
Petter Reinholdtsen