date:20161126

On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote:

> This was an intentional change in 4.8.4-1~exp1 afaict, from the
> changelog entry:

I wonder if this should be promoted to a NEWS.Debian entry?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

2016-11-26 Thread Sven Joachim

Control: reassign -1 binutils 2.27.51.20161124-1
Control: retitle -1 binutils: creates unbootable kernel on x86-64
Control: severity -1 grave

On 2016-11-26 15:13 +0100, Damien Wyart wrote:

> After running further tests today, I think this is in fact *not*
> related to gcc but to the kernel itself.
>
> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the
> kernels fail to boot (balck screen just after grub and nothing in the
> logs).

Same here, downgrading binutils to 2.27.51.20161118-2 helped.  I'm
reassigning the bug and bumping the severity, since several people have
observed the problem.

Cheers,
   Sven

Bug#845943: zotero-standalone: Unable to run, 'Error opening input stream'

2016-11-26 Thread Arnaud Meyer

Package: zotero-standalone
Version: 4.0.29.5+dfsg-2
Severity: important

Dear Maintainer,

Upon starting Zotero, it crashes immediately, displaying a message box
"There was an error starting Zotero.". The program exits immediately
after confirming the message, without displaying anything else.

When running from a terminal, I get the following output :
xulrunner not found, trying firefox instead.
Error opening input stream (invalid filename?): 
chrome://global/content/nsTransferable.js
Error opening input stream (invalid filename?): 
chrome://global/content/nsTransferable.js
Error opening input stream (invalid filename?): 
chrome://global/content/nsTransferable.js

(The last message is displayed only after confirming the message box).

Running Zotero with options "--help" or "--version" only displays the
first line ("xulrunner not found...") and behave normally. Any other
option produces the same as above.

The expected behaviour would be the software running, or giving details
about an hypothetical missing package.

Using Zotero plugin for Firefox (4.0.29.16) with the same database, it
displays and behaves normally.

Regards,
Arnaud Meyer.


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 zotero-standalone depends on:
ii  firefox  50.0-3

zotero-standalone recommends no packages.

zotero-standalone suggests no packages.

-- no debconf information

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

Control: close -1

On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote:

> This was an intentional change in 4.8.4-1~exp1 afaict, from the
> changelog entry:
> 
>   * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE.
> This breaks (e)glibc 2.13 and earlier, and can be reverted using the 
> kernel
> parameter: vsyscall=emulate

Hmm, I guess we are going to have to run the buildds with that
parameter, at least until wheezy LTS runs out.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

2016-11-26 Thread Salvatore Bonaccorso

Hi Paul,

On Sun, Nov 27, 2016 at 03:12:05PM +0800, Paul Wise wrote:
> Package: src:linux
> Version: 4.8.5-1
> Severity: important
> Control: found -1 linux/4.8.7-1
> 
> After upgrading and rebooting to Linux 4.8.5-1 (now running 4.8.7-1),
> I can no longer create wheezy chroots because dpkg inside the chroot
> segfaults. In addition, for existing chroots, bash segfaults and so
> does the apt-get http helper and a variety of other executables.
> Confusingly, not every binary crashes, just a few important ones.
> This does not happen with jessie/stretch/sid chroots and does not
> happen with wheezy i386 chroots.
> 
> pabs@chianamo ~ $ sudo debootstrap --include=apt --variant=buildd 
> --force-check-gpg wheezy $(pwd)/tmp-test-debootstrap 
> http://deb.debian.org/debian
> I: Retrieving InRelease 
> I: Retrieving Release 
> I: Retrieving Release.gpg 
> I: Checking Release signature
> I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764)
> I: Retrieving Packages 
> I: Validating Packages 
> I: Resolving dependencies of required packages...
> I: Resolving dependencies of base packages...
> I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 
> libsemanage-common libsemanage1 libslang2 libustr-1.0-1 
> I: Found additional base dependencies: binutils bzip2 cpp cpp-4.7 
> debian-archive-keyring dpkg-dev g++ g++-4.7 gcc gcc-4.7 gnupg gpgv 
> libapt-pkg4.12 libc-dev-bin libc6-dev libclass-isa-perl libdpkg-perl libgdbm3 
> libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 libreadline6 
> libstdc++6 libstdc++6-4.7-dev libswitch-perl libtimedate-perl libusb-0.1-4 
> linux-libc-dev make patch perl perl-modules readline-common 
> I: Checking component main on http://deb.debian.org/debian...
> I: Retrieving libacl1 2.2.51-8
> I: Validating libacl1 2.2.51-8
> ...
> I: Chosen extractor for .deb packages: dpkg-deb
> I: Extracting libacl1...
> ...
> I: Installing core packages...
> W: Failure trying to run: chroot /home/pabs/tmp-test-debootstrap dpkg 
> --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
> W: See /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log for details
> pabs@chianamo ~ $ less 
> /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
> pabs@chianamo ~ $ cat 
> /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
> gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
> gpgv:using RSA key 8B48AD6246925553
> gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
> "
> gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
> gpgv:using RSA key 7638D0442B90D010
> gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
> "
> gpgv: Signature made Sat Jun  4 19:56:53 2016 AWST
> gpgv:using RSA key 6FB2A1C265FFB764
> gpgv: Good signature from "Wheezy Stable Release Key 
> "
> dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
>  missing description
> dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
>  missing architecture
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy bash
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy apt-get 
> update
> E: Method http has died unexpectedly!
> E: Sub-process http received a segmentation fault.
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ 
> dnsdomainname
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gunzip
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gzexe
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ login
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ rbash
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ su
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ uncompress
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcat
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcmp
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zdiff
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zegrep
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zfgrep
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zforce
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ sudo chroot

Bug#845082: numexpr FTBFS on ppc64el: test failures

2016-11-26 Thread Antonio Valentino

tags 845082 + pending

thanks

-- 
Antonio Valentino

Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later

Package: src:linux
Version: 4.8.5-1
Severity: important
Control: found -1 linux/4.8.7-1

After upgrading and rebooting to Linux 4.8.5-1 (now running 4.8.7-1),
I can no longer create wheezy chroots because dpkg inside the chroot
segfaults. In addition, for existing chroots, bash segfaults and so
does the apt-get http helper and a variety of other executables.
Confusingly, not every binary crashes, just a few important ones.
This does not happen with jessie/stretch/sid chroots and does not
happen with wheezy i386 chroots.

pabs@chianamo ~ $ sudo debootstrap --include=apt --variant=buildd 
--force-check-gpg wheezy $(pwd)/tmp-test-debootstrap 
http://deb.debian.org/debian
I: Retrieving InRelease 
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 
libsemanage-common libsemanage1 libslang2 libustr-1.0-1 
I: Found additional base dependencies: binutils bzip2 cpp cpp-4.7 
debian-archive-keyring dpkg-dev g++ g++-4.7 gcc gcc-4.7 gnupg gpgv 
libapt-pkg4.12 libc-dev-bin libc6-dev libclass-isa-perl libdpkg-perl libgdbm3 
libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 libreadline6 libstdc++6 
libstdc++6-4.7-dev libswitch-perl libtimedate-perl libusb-0.1-4 linux-libc-dev 
make patch perl perl-modules readline-common 
I: Checking component main on http://deb.debian.org/debian...
I: Retrieving libacl1 2.2.51-8
I: Validating libacl1 2.2.51-8
...
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting libacl1...
...
I: Installing core packages...
W: Failure trying to run: chroot /home/pabs/tmp-test-debootstrap dpkg 
--force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log for details
pabs@chianamo ~ $ less 
/home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
pabs@chianamo ~ $ cat 
/home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log
gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
gpgv:using RSA key 8B48AD6246925553
gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: Signature made Sat Jun  4 19:51:09 2016 AWST
gpgv:using RSA key 7638D0442B90D010
gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
"
gpgv: Signature made Sat Jun  4 19:56:53 2016 AWST
gpgv:using RSA key 6FB2A1C265FFB764
gpgv: Good signature from "Wheezy Stable Release Key 
"
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy bash
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy apt-get update
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ dnsdomainname
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gunzip
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gzexe
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ login
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ rbash
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ su
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ uncompress
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcat
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcmp
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zdiff
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zegrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zfgrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zforce
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zgrep
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zless
Segmentation fault (core dumped)
pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zmore
Segmentation fault (core

Bug#845921: icedove: crash in nsTArray::ShrinkCapacity

2016-11-26 Thread Carsten Schoenert

Hello Kim,

On Sun, Nov 27, 2016 at 12:35:54AM +0100, Kim Alvefur (Zash) wrote:
> Package: icedove
> Version: 1:45.4.0-1~deb8u1
> Severity: important
> 
> Dear Maintainer,
> 
> Icedove have been randomly crashing for me, usually when selecting a
> folder.  Attached is a gdb backtrace of from a core dump of the latest
> crash.

thanks for trying to provide helpful information. I'm a bit unsure as
the start of the GDB session isn't seen in your log, there are a lot of
"optimized out" things to see. You have installed icedove-dbg? Only
this package has the needed symbols to collect all things together in
the log later.

Regards
Carsten

Bug#845941: unbound FTCBFS: uninstallable python Build-Depends, configures for the build architecture

Source: unbound
Version: 1.5.10-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

unbound fails to cross build from source for a number of reasons. First
of all, its python Build-Depends are not installable as Python cannot be
installed for foreign architectures (its postinst fails). What is needed
here is not a host architecture Python, but a build architecture Python
and host architecture Python development files.

Secondly, it configures for the build architecture, because none of the
explicit ./configure invocations carry the necessary --host flag.
Indirecting them through dh_auto_configure fixes that as debhelper knows
when to pass --host.

And the final problem is #840080 and not fixable in unbound. I expect it
to be fixed in a week.

Can you apply the attached patch?

Helmut
--- unbound-1.5.10/debian/changelog
+++ unbound-1.5.10/debian/changelog
@@ -1,3 +1,11 @@
+unbound (1.5.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Convert python Build-Depends to cross-friendly ones.
++ Let dh_auto_configure pass --host to ./configure.
+
+ -- Helmut Grohne   Thu, 27 Nov 2016 07:07:27 +0100
+
 unbound (1.5.10-2) unstable; urgency=medium
 
   * debian/unbound.install: Install usr/sbin/unbound-checkconf
--- unbound-1.5.10/debian/control
+++ unbound-1.5.10/debian/control
@@ -24,8 +24,10 @@
  nettle-dev,
  pkg-config,
  protobuf-c-compiler,
- python-all-dev (>= 2.6.6-3~),
- python3-all-dev,
+ python-all-dev:any (>= 2.6.6-3~),
+ libpython-all-dev (>= 2.6.6-3~),
+ python3-all-dev:any,
+ libpython3-all-dev,
  swig,
 Standards-Version: 3.9.8
 Homepage: https://www.unbound.net/
--- unbound-1.5.10/debian/rules
+++ unbound-1.5.10/debian/rules
@@ -30,9 +30,7 @@
# first build -- build unbound daemon
PYTHON_VERSION="$(shell py3versions -vd)" \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed 
$(LDFLAGS)" \
-   ./configure \
-   --prefix=/usr \
-   --sysconfdir=/etc \
+   dh_auto_configure -- \
--disable-rpath \
--with-pidfile=/run/unbound.pid \
--with-rootkey-file=/var/lib/unbound/root.key \
@@ -40,6 +38,7 @@
--with-pythonmodule \
--enable-dnstap \
--with-dnstap-socket-path=/run/dnstap.sock \
+   --libdir=/usr/lib \
$(CONFIGURE_ARGS)
$(MAKE)
$(MAKE) install DESTDIR="$(CURDIR)/debian/tmp"
@@ -47,9 +46,7 @@
 
# second build -- build libunbound only, against nettle
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed 
$(LDFLAGS)" \
-   ./configure \
-   --prefix=/usr \
-   --sysconfdir=/etc \
+   dh_auto_configure -- \
--disable-rpath \
--with-libunbound-only \
--with-nettle \
@@ -57,7 +54,6 @@
--without-libevent \
--without-pythonmodule \
--without-pyunbound \
-   --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
$(CONFIGURE_ARGS)
$(MAKE)
$(MAKE) install DESTDIR="$(CURDIR)/debian/tmp-lib"
@@ -68,8 +64,7 @@
# third build - pyunbound for Python 2
PYTHON_VERSION="$(shell pyversions -vd)" \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed 
$(LDFLAGS)" \
-   ./configure \
-   --prefix=/usr \
+   dh_auto_configure -- \
--disable-rpath \
--with-pythonmodule \
--with-pyunbound \
@@ -86,8 +81,7 @@
# fourth build - pyunbound for Python 3
PYTHON_VERSION="$(shell py3versions -vd)" \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed 
$(LDFLAGS)" \
-   ./configure \
-   --prefix=/usr \
+   dh_auto_configure -- \
--disable-rpath \
--with-pythonmodule \
--with-pyunbound \

Bug#845940: hexchat-plugins: should recommend hwdata for the sysinfo plugin

Package: hexchat-plugins
Version: 2.12.0-2+b1
Severity: minor

The hexchat sysinfo plugin can lookup the proper names of PCI IDs but
only if the pci.ids file is installed via the hwdata package. The
hwdata package only symlinks to the copy in the pciutils package
though. debian/rules could override the default path but the old
path will be still be listed in user configuration files.

https://codesearch.debian.net/search?q=package:hexchat+pci.ids
https://packages.debian.org/file:pci.ids

So, I think hexchat-plugins should recommend the hwdata package.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages hexchat-plugins depends on:
ii  libc6 2.24-5
ii  libglib2.0-0  2.50.2-1
ii  libpci3   1:3.3.1-1.1
ii  libssl1.0.2   1.0.2j-4

Versions of packages hexchat-plugins recommends:
ii  hexchat  2.12.0-2+b1

hexchat-plugins suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845939: approx: After recent Debian Sid upgrade of Approx it will not start

2016-11-26 Thread Russel Winder

Package: approx
Version: 5.7-1
Severity: important

Dear Maintainer,

The recent upgrade of Approx on Sid has meant that the service will not start 
under systemd on reboot of the
server running the approx service. I am not sure what other changes happened 
recently (i.e. has systemd
switched off inetd recently or was that done earlier), but the upshot is that 
Approx does not start, and so
no updates are possible in a network of machine centred on an approx-based 
system.


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

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

Versions of packages approx depends on:
ii  adduser  3.115
ii  bzip21.0.6-8
ii  curl 7.51.0-1
ii  debconf [debconf-2.0]1.5.59
ii  libc62.24-7
ii  libpcre3 2:8.39-2
ii  rsyslog [system-log-daemon]  8.23.0-2
ii  update-inetd 4.43
ii  xz-utils 5.2.2-1.2

approx recommends no packages.

Versions of packages approx suggests:
pn  libconfig-model-approx-perl

Bug#845442: udev: does not honor configuration files in /etc/udev/hwdb.d

2016-11-26 Thread Norbert Preining

Hi Michael,

> Does it work if you rename the file to /etc/udev/hwdb.d/60-keyboard.hwdb?

Yes. But this will disable all the entries in the original one, right?

> I'm asking, because /lib/udev/hwdb.d/60-keyboard.hwdb already contains
> an entry for evdev:input:b0003v045Ep00DB* and I'm not entirely sure if
> you can override an existing entry by adding it again to a file which is
> sorted later.
> The documentation is clear though, that an existing
> /etc/udev/hwdb.d/60-keyboard.hwdb will take precedence over
> /lib/udev/hwdb.d/60-keyboard.hwdb


But the /l/u/hwdb.d/60.. file also mentiones:
# To update this file, create a new file
#   /etc/udev/hwdb.d/70-keyboard.hwdb
# and add your rules there. To load the new rules execute (as root):
#   udevadm hwdb --update
#   udevadm trigger /dev/input/eventXX
# where /dev/input/eventXX is the keyboard in question. If in
# doubt, simply use /dev/input/event* to reload all input rules.

Does that mean this works only for *new* entries, but overriding another
one I need to copy the whole file and edit it?

Is there no way to *override* entries?

All the best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#844905: node-nan: FTBFS: Tests failures

2016-11-26 Thread Pirate Praveen

On Sat, 19 Nov 2016 08:02:29 +0100 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

From upstream discussion,

"The bug is that the Global destructor runs at process exit and tries to
free the object slot but that doesn't work because the VM is dead. In ye
olden days, one could check with v8::V8::IsDead() whether it's safe to
release but that stopped working in V8 3.29..."

Can we disable this test?

signature.asc
Description: OpenPGP digital signature

Bug#845938: pulseaudio: bt headset: a2dp sink is not selectable - only hsp/hfp works

2016-11-26 Thread Lars Heer

Package: pulseaudio
Version: 9.0-4
Severity: important
Tags: d-i

Dear Maintainer,

   * What led up to the situation?
Connecting a plantronics B825-M only has the hsp/hfp sink usable in
audio configuration gui.
a2db was selectable by gui but it still used hsp/hfp (check speaker
still has mono output).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
setfacl -m u:Debian-gdm:r /usr/bin/pulseaudio
reboot

This fixed the issue. It has no other effects as far I can see.

TIA Lars



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.8.0-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 pulseaudio depends on:
ii  adduser  3.115
ii  libasound2   1.1.2-1
ii  libasound2-plugins   1:1.1.1-dmo1
ii  libc62.24-5
ii  libcap2  1:2.25-1
ii  libdbus-1-3  1.10.12-1
ii  libgcc1  1:6.2.0-13
ii  libice6  2:1.0.9-1+b1
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.26-2
ii  libpulse09.0-4
ii  libsm6   2:1.2.2-1+b1
ii  libsndfile1  1.0.27-1
ii  libsoxr0 0.1.2-1
ii  libspeexdsp1 1.2~rc1.2-1
ii  libstdc++6   6.2.0-13
ii  libsystemd0  232-6
ii  libtdb1  1.3.11-2
ii  libudev1 232-6
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.3-1
ii  libx11-xcb1  2:1.6.3-1
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.2-1+b1
ii  lsb-base 9.20161101
ii  pulseaudio-utils 9.0-4

Versions of packages pulseaudio recommends:
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter
ii  udev 232-6

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
;

Bug#845937: tiny-initramfs: init binary crashes on 4.8.x kernels - need to rebuild against newer dietlibc

2016-11-26 Thread James Braid

Package: tiny-initramfs
Version: 0.1-2
Severity: critical

Recent Debian kernels (4.8.x) have disabled support for legacy vsyscall
emulation.

changelog entry from kernel packages:

  * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE.
This breaks (e)glibc 2.13 and earlier, and can be reverted using the
kernel
parameter: vsyscall=emulate

This causes problems with tiny-initramfs as the init binary is linked
against an old version of dietlibc which uses the vsyscall for accessing
the kernel gettimeofday functions. This manifests as the init process being
killed when it attempts to access the vsyscall interface which renders the
system unbootable.

dietlibc 0.33 adds changes to use the kernel vDSO instead of the legacy
vsyscall interface.

I have tested rebuilding tiny-initramfs against the latest dietlibc in
Debian (0.34~cvs20160606-3) and the rebuilt init binary works successfully
on 4.8.x kernels.

Setting severity to critical as this renders systems using tiny-initramfs
unbootable when the upgraded kernel package is installed. It would be great
to get an updated tiny-initramfs package rebuilt against the latest
dietlibc.

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

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

Versions of packages tiny-initramfs depends on:
ii  tiny-initramfs-core  0.1-2

tiny-initramfs recommends no packages.

tiny-initramfs suggests no packages.

-- no debconf information

Bug#845936: RM: meshlab [mips mipsel mips64el] -- ROM; FTBFS on these architectures

2016-11-26 Thread Graham Inggs

Package: ftp.debian.org
Severity: normal

Hi ftpmasters

Please remove the mips, mipsel and mips64el binaries of meshlab.
Meshlab FTBFS on these architectures and it is unlikely to be used on them.

Regards
Graham

Bug#816924: Updated 6.5.5 delayed NMU to experimental uploaded

2016-11-26 Thread Wookey


I have prepared a 6.5.5-1.1 NMU based on Punit and Volker's updated
packaging and curent upstream 6.5.5 tarball. This is uploaded to
experimental as a 5-day delayed NMU. It should be available to test
from 30th Nov.

There are quite a few collected changes:

  [ Punit Agrawal ]
  * Switch to dpkg-source 3.0 (quilt) format
Split diff into individual patches by functionality.
  * Add watch file
  * Migrate local changes to latest upstream version - 6.2.11
Drop globash patch as it seems to be integrated with upstream
Drop alternate compressed suffix functionality for htags
  * Update debian/rules in line with 6.2.11
  * Update debian/global.manpages for 6.2.11
  * Fix an error encountered while installing gtags.el
  * Add debian/emacsen-compat
  * Fix lintian warning debian-rules-ignores-make-clean
  * Fix lintian warning debian-rules-missing-recommended-target
  * Replace deprecated dh_clean -k with dh_prep in debian/rules

  [ Javi Merino ]
  * Build-depend on libncurses5-dev, as global requires curses

  [ Punit Agrawal ]
  * Fix lintian warning script-not-executable
  * New upstream release - 6.2.12
  * Add links to global and the package repository

  [ Volker Mische ]
  * Install plugins from plugin-factory
  * Update to upstream release - 6.3.2

  [ Wookey ]
  * Non-maintainer upload.
  * Update to new upstream release - 6.5.5
  * Add missing emacsen-common build-dep 
  * Remove obsolete dpkg|install-info dependency
  * Bump standards to 3.9.6
  * Use system libltdl instead of embedded one
  * Ensure cgi scripts are regenerated to set perl path correctly
  * Recommend python for pygments support


Known issues:

* This version still includes Ron's htmake patch, but it probably needs
  adjusting to work properly with the current codebase.

* The two .cgi scripts in htags/ were not cleaned by upstream, and are
  shipped in the tarball (despite being generated from .cgi.in files,
  which means that they didin't get their perl shebang paths set
  correctly (they are left with the /opt/local/bin/perl they ship with)

  I tried to do this as an upstream-ready patch
  0004-Regenerate-cgi-scripts.patch to adjust the htags/Makefile.am to ensure
  that these two did get cleaned.
  Setting: CLEANFILES = global.cgi completion.cgi 
  in htags/Makefile.am seems like it might be the right thing to cause them to 
be cleaned
  but of course that's not in Makefile.in unless we autoreconf.

  Autoreconfing didn't work (see below), so I just patched Makefile.in
  as well as Makefile.am. But that still didn't work (is 'CLEANFILES'
  the wrong thing?), so I just cleaned those two files in debian/rules
  (which does work).

  It would be nice to do this properly with an upstreamble fix.

* Lintian pointed out that libltdl is embedded. Fixing that was not
  too hard, but the existence of /libltdl interacts unhelpfully with
  reautoconfig (see below). 

  Just removing 'libltdl' from the subdirs list in Makefile.am seems
  to fix things, although I think a proper fix should also change the 
  macros in configure.ac:
  LT_CONFIG_LTDL_DIR, LT_INIT, LTDL_INIT

  In fact is there any point using libtool at all? In my experience it
  does nothing useful on a modern system but makes things complicated.

  I'm not actually sure what libltdl is for. It's a loader, but libc
  already has one of those. I guess this is a question for upstream.

* Reautoconfing

  Reautoconfing is good policy and recommended in Debian (see
  https://wiki.debian.org/Autoreconf). It also should mean that we
  just have to make tiny patches to .ac/.am files for the 'htags/.cgi
  cleaning' and 'use system libltdl' then regenerate stuff and
  everything is done properly and we know it is all built from
  source. However I was not able to get this to work.
  
  I tried using dh_autoreconf to regenerate Makefile.in from
  Makeilfe.am but the build fails because libtoolise carefully
  replaces the shipped /libltdl with a new copy, and then dpkg-source
  complains that a load of files have changed.

  So then I tried removing /libltdl to shut dpkg up, as we are not
  using it anyway. This works to get a build, but now we can only do
  one build, not a second, because the second autoreconf fails because 
  /libltdl/Makefile.am gets
  ACLOCAL_AMFLAGS = -I m4
  changed to
  ACLOCAL_AMFLAGS = -I ../m4
  so now the first aclocal that autoreconf runs fails (because there is 
  an m4 dir but no ../m4 directory. This is beyond my autofoo competence 
  now. I have no idea why that's happening, nor what the right way to 
  fix it is.

  At this point I gave up with reautoconfing, and just did a
  dh_autotools-dev_update to ensure that config.{sub,guess} are up to
  date. 

* I've not updated any docs, and that should be done, depending on
  what we do about htmake vs using upstream's recommended 'just run a
  local python webserver on port 8000, if you want to expose an
  indexed source's htags over http'. This is simple and works:
  
  gtags
  htags -D
  cd

Bug#845935: gitlab postinst fails

2016-11-26 Thread Johannes Schauer

Package: gitlab
Version: 8.13.3+dfsg1-2
Severity: normal

Hi,

when upgrading my gitlab 8.8.2+dfsg-5 to 8.13.3+dfsg1-2 I encountered
the following error during package configuration:

Using health_check 2.4.0
Using jquery-turbolinks 2.1.0
Using devise-two-factor 3.0.0
Bundle complete! 135 Gemfile dependencies, 244 gems now installed.
Gems in the groups development and test were not installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
Running final rake tasks and tweaks...
gitlab_production database is not empty, skipping gitlab setup
Precompiling assets...
rake aborted!
ExecJS::RuntimeError: 
(execjs):1
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.24-5) ...
E: Sub-process /usr/bin/dpkg returned an error code (1)


It is not obvious to me what to run with "--trace". Would you like a
separate bug about adding some more helpful output to the postinst?

After reading the postinst script, I assumed that what failed was
rake-tasks.sh:

$ /usr/lib/gitlab/scripts/rake-tasks.sh --trace
gitlab_production database is not empty, skipping gitlab setup
Precompiling assets...
I, [2016-11-27T05:16:05.711600 #1428]  INFO -- : Writing 
/usr/share/gitlab/public/assets/application-baf30f6e3b767ce447b6336a8926954f3e5cbf33d224f80f966eb3215fba4a23.js
I, [2016-11-27T05:16:05.712798 #1428]  INFO -- : Writing 
/usr/share/gitlab/public/assets/application-baf30f6e3b767ce447b6336a8926954f3e5cbf33d224f80f966eb3215fba4a23.js.gz
rake aborted!
ExecJS::RuntimeError: 
(execjs):1
/usr/share/rubygems-integration/all/gems/ace-rails-ap-4.1.1/vendor/assets/javascripts/set_ace_paths.js.erb:4:in
 `block in _evaluate_template'
/usr/share/rubygems-integration/all/gems/ace-rails-ap-4.1.1/vendor/assets/javascripts/set_ace_paths.js.erb:2:in
 `each'
/usr/share/rubygems-integration/all/gems/ace-rails-ap-4.1.1/vendor/assets/javascripts/set_ace_paths.js.erb:2:in
 `_evaluate_template'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

But the last line of the output suggests that I'm supplying --trace to
the wrong process again...

Thanks!

cheers, josch

Bug#845934: RFS: libcorkipset/1.1.1+20150311-6~bpo8+1 -- C library to store sets/maps of IP address

2016-11-26 Thread Roger Shimizu

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: rogershim...@gmail.com

Dear Mentors,

I am looking for a sponsor for my package "libcorkipset" into jessie-backports.
It's a clean rebuild bpo from testing/stretch.

 * Package name: libcorkipset
   Version : 1.1.1+20150311-6~bpo8+1
   Upstream Author : Douglas Creager 
 * URL : https://github.com/redjack/ipset
 * License : BSD-3-clause
   Section : libs

It builds those binary packages:

  libcorkipset-dev - C library to store sets/maps of IP address
(development files)
  libcorkipset-doc - C library to store sets/maps of IP address
(documentation files)
  libcorkipset-utils - C library to store sets/maps of IP address
(utility files)
  libcorkipset1 - C library to store sets/maps of IP address

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libc/libcorkipset/libcorkipset_1.1.1+20150311-6~bpo8+1.dsc

or you can use git-buildpackage to build:
  gbp clone --pristine-tar https://github.com/rogers0/libcorkipset
  git checkout jessie-backports
  # DIST=jessie-backports git-pbuilder create
  gbp buildpackage --git-ignore-branch --git-pristine-tar
--git-pbuilder --git-dist=jessie-backports

I pushed my changes to git repo: https://github.com/rogers0/libcorkipset
- branch jessie-backports

Thank you!

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

Bug#845933: RFS: libcork/0.15.0+ds-10~bpo8+1 -- simple, easily embeddable, cross-platform C library

2016-11-26 Thread Roger Shimizu

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: rogershim...@gmail.com

Dear Mentors,

I am looking for a sponsor for my package "libcork" into jessie-backports.
It's a clean rebuild bpo from testing/stretch.

 * Package name: libcork
   Version : 0.15.0+ds-10~bpo8+1
   Upstream Author : Douglas Creager 
 * URL :  https://libcork.readthedocs.io
 * License : BSD-3-clause
   Section : libs

It builds those binary packages:

 libcork-dev - simple, easily embeddable, cross-platform C library (development
 libcork-doc - simple, easily embeddable, cross-platform C library (documentatio
 libcork15  - simple, easily embeddable, cross-platform C library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libc/libcork/libcork_0.15.0+ds-10~bpo8+1.dsc

or you can use git-buildpackage to build:
  gbp clone --pristine-tar https://github.com/rogers0/libcork
  cd libcork
  git checkout jessie-backports
  # DIST=jessie-backports git-pbuilder create
  gbp buildpackage --git-ignore-branch --git-pristine-tar
--git-pbuilder --git-dist=jessie-backports

I pushed my changes to git repo: https://github.com/rogers0/libcork
- branch jessie-backports

Thank you!

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

Bug#845932: Please enable FriendlyARM NanoPi NEO

2016-11-26 Thread Paul Tagliamonte

Package: u-boot-sunxi
Severity: wishlist
thanks

Please enable FriendlyARM NanoPi NEO

Thanks for all your work!
  Paul

-- 
:wq

Bug#845690: binutils 2.27.51.20161124

2016-11-26 Thread Руслан

on ubuntu same problem, after update binutils to 2.27.51.20161124-1ubuntu1 and 
gcc-6 to 6.2.1-5ubuntu1

gcc-6 6.2.1-4ubuntu1 and binutils 2.27.51.20161118-2ubuntu1 no problem.

Bug#845931: tt-rss should recommend or suggest ca-certificates

2016-11-26 Thread Johannes Schauer

Package: tt-rss
Severity: normal

Hi,

the tt-rss package should add ca-certificates to its Recommends or
Suggests. Without that package installed, https RSS feeds cannot be
added.

One might even argue that even adding ca-certificates to Depends might
be justified as not being able to add https-only feeds could be thought
as a serious flaw.

Thanks!

cheers, josch

Bug#836809: hexchat: New version of hexchat: 2.12.1 has released

2016-11-26 Thread Mattia Rizzolo

Control: severity -1 wishlist

On Mon, Sep 05, 2016 at 10:07:02PM -0600, Arcademan wrote:
> Version: 2.12.0-2~bpo8+1

the BTS has now knowledge of backports, its packages, and their
versions, therefore filing a bug against a backport version doesn't mean
anything in particular.

> Severity: important

and surely this is nothing important...

> It would be great if you could push package to version 2.12.1 in debian 
> backports.

Well, first step would be to update the version currently in unstable,
which I am about to.  Then it has to migrate to stretch, then somebody
can update the backport; guess it can as well be me...

See https://backports.debian.org/Contribute/ for more information about
how backports are done.
-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1

2016-11-26 Thread Evgeny Kapun


Control: reassign -1 lxde-common

On 27.11.2016 03:52, Andriy Grytsenko wrote:

I believe it's some dpkg error, just look at list of files in lxde-common
package at https://packages.debian.org/sid/all/lxde-common/filelist:

/etc/xdg/lxpanel/LXDE/config
/etc/xdg/lxpanel/LXDE/panels/panel
/etc/xdg/pcmanfm/LXDE/pcmanfm.conf
/usr/share/doc/lxde-common/README.Debian
/usr/share/doc/lxde-common/changelog.Debian.gz
/usr/share/doc/lxde-common/changelog.gz
/usr/share/doc/lxde-common/copyright
/usr/share/lxde/images/logout-banner.png
/usr/share/lxde/images/lxde-icon.png
/usr/share/lxde/wallpapers/lxde_blue.jpg
/usr/share/lxde/wallpapers/lxde_green.jpg
/usr/share/lxde/wallpapers/lxde_red.jpg

there is no /etc/xdg/lxsession/LXDE/autostart file there! I have no idea
what was happened in your system.



Actually, after further investigation, I think that this file is a conffile 
left from a previous version of lxde-common package. These files should be 
removed by a maintainer script [1]. Since the maintainer script for lxde-common 
package doesn't do this, this is a bug in that package.

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

Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1

2016-11-26 Thread Andriy Grytsenko

Ah, forget about previous message, found the problem.
Thank you for a report, fixed version will come soon.

Bug#845785: chromium crashes on certain websites

2016-11-26 Thread Boom Zoom

This version crashes on A LOT of websites, including facebook. Doesn't this
warrant setting a severity of "serious" or "critical"?

Bug#845930: fakeroot: should not load library symbols from redirected function

2016-11-26 Thread Samuel Thibault

Package: fakeroot
Version: 1.21-2
Severity: normal

Hello,

While investigating a hang with fakeroot on hurd-i386, I got the
following backtrace which is a concern for Linux too:

#2  0x0125a241 in __gsync_wait (task=1, addr=19101080, val1=2, val2=0, msec=0, 
flags=0)
at /usr/src/glibc-2.24/build-tree/hurd-i386-libc/mach/RPC_gsync_wait.c:175
#3  0x010b0743 in __dcigettext (domainname=0x8050740 
<_libc_intl_domainname@@GLIBC_2.2.6> "libc",
msgid1=0x8051d88 "undefined symbol: acl_get_fd", msgid2=0x0, plural=0, n=0, 
category=5) at dcigettext.c:527
#4  0x010af776 in __dcgettext (domainname=0x8050740 
<_libc_intl_domainname@@GLIBC_2.2.6> "libc",
msgid=0x8051d88 "undefined symbol: acl_get_fd", category=5) at 
dcgettext.c:47
#5  0x0124e427 in __dlerror () at dlerror.c:94
#6  0x01035ae3 in load_library_symbols () from 
/usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so
#7  0x01035cc3 in tmp___fxstat64 () from 
/usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so
#8  0x01036cd6 in __fxstat64 () from 
/usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so
#9  0x010ad831 in _nl_load_locale_from_archive (category=category@entry=0, 
namep=namep@entry=0x200399c) at loadarchive.c:211
#10 0x010ac45b in _nl_find_locale (locale_path=0x0, locale_path_len=0, 
category=category@entry=0, name=0x200399c) at findlocale.c:154
#11 0x010abde7 in setlocale (category=0, locale=0x804c2e4 "") at setlocale.c:417
#12 0x0804947f in main (argc=2, argv=0x2003ad4) at programs/locale.c:191

What happens is that the fakeroot initialization gets triggered from an
__fxtstat64 call made by _nl_load_locale_from_archive.  The issue is
that setlocale has locked __libc_setlocale_lock, and __dcigettext tries
to lock it again. On Linux, that just returns EDEADLK which is then
ignored. When __dcigettext unlocks __libc_setlocale_lock, it does get
unlocked, and execution can continue with _nl_load_locale_from_archive
doing its work with __libc_setlocale_lock unlocked, which is unsafe!

libfakeroot should not assume that the redirect calls it gets are made
in a context where anything can be done, and notably
load_library_symbols can't necessarily be done there, it should rather
be done from a library constructor or something like that.

Samuel

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

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

Versions of packages fakeroot depends on:
ii  libc62.24-5
ii  libfakeroot  1.21-2

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information

-- 
Samuel
 Cliquez sur le lien qui suit dans ce mail...vous n'avez plus qu'a vous
 inscrire pour gagner de l'argent en restant connecteet puis faites
 passer le message et vous gagnerez encore plus d'argent ...
 -+- AC in NPC : Neuneu a rencontré le Pere Noël -+-

Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1

2016-11-26 Thread Andriy Grytsenko

>Package: openbox-lxde-session
>Version: 0.99.2-1
>Severity: grave

>When trying to install openbox-lxde-session package, dpkg fails with an error 
>message:

> dpkg: error processing archive .../openbox-lxde-session_0.99.2-1_all.deb 
> (--unpack):
>  trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also 
> in package lxde-common 0.99.2-1

I believe it's some dpkg error, just look at list of files in lxde-common
package at https://packages.debian.org/sid/all/lxde-common/filelist:

/etc/xdg/lxpanel/LXDE/config
/etc/xdg/lxpanel/LXDE/panels/panel
/etc/xdg/pcmanfm/LXDE/pcmanfm.conf
/usr/share/doc/lxde-common/README.Debian
/usr/share/doc/lxde-common/changelog.Debian.gz
/usr/share/doc/lxde-common/changelog.gz
/usr/share/doc/lxde-common/copyright
/usr/share/lxde/images/logout-banner.png
/usr/share/lxde/images/lxde-icon.png
/usr/share/lxde/wallpapers/lxde_blue.jpg
/usr/share/lxde/wallpapers/lxde_green.jpg
/usr/share/lxde/wallpapers/lxde_red.jpg

there is no /etc/xdg/lxsession/LXDE/autostart file there! I have no idea
what was happened in your system.

Bug#844534: uftp: FTBFS: encrypt_openssl.c:352:20: error: storage size of 'ctx' isn't known

2016-11-26 Thread Reiner Herrmann

Control: tags -1 + patch

Hi,

attached is a patch for compatibility with OpenSSL 1.1.

Regards,
  Reiner
diff --git a/debian/patches/openssl1.1.patch b/debian/patches/openssl1.1.patch
new file mode 100644
index 000..960d827
--- /dev/null
+++ b/debian/patches/openssl1.1.patch
@@ -0,0 +1,400 @@
+Author: Reiner Herrmann 
+Description: Fix compatibility with OpenSSL 1.1
+Bug-Debian: https://bugs.debian.org/844534
+
+--- a/encrypt_openssl.c
 b/encrypt_openssl.c
+@@ -349,7 +349,7 @@
+   const unsigned char *src, unsigned int srclen,
+   unsigned char *dest, unsigned int *destlen)
+ {
+-EVP_CIPHER_CTX ctx;
++EVP_CIPHER_CTX *ctx;
+ const EVP_CIPHER *cipher = get_cipher(keytype);
+ int mode, len;
+ 
+@@ -358,32 +358,32 @@
+ return 0;
+ }
+ mode = EVP_CIPHER_mode(cipher);
+-EVP_CIPHER_CTX_init();
+-if (!EVP_EncryptInit_ex(, cipher, NULL, NULL, NULL)) {
++ctx = EVP_CIPHER_CTX_new();
++if (!EVP_EncryptInit_ex(ctx, cipher, NULL, NULL, NULL)) {
+ log_ssl_err("EncryptInit for cipher failed");
+ return 0;
+ }
+ #ifdef EVP_CIPH_GCM_MODE
+ if (mode == EVP_CIPH_GCM_MODE) {
+-if (!EVP_CIPHER_CTX_ctrl(, EVP_CTRL_GCM_SET_IVLEN, GCM_IV_LEN, 0)) {
++if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, GCM_IV_LEN, 0)) {
+ log_ssl_err("EVP_CIPHER_CTX_ctrl for IVLEN failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ } else if (mode == EVP_CIPH_CCM_MODE) {
+-if (!EVP_CIPHER_CTX_ctrl(, EVP_CTRL_CCM_SET_IVLEN, CCM_IV_LEN, 0)) {
++if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, CCM_IV_LEN, 0)) {
+ log_ssl_err("EVP_CIPHER_CTX_ctrl for IVLEN failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+-if (!EVP_CIPHER_CTX_ctrl(, EVP_CTRL_CCM_SET_TAG, CCM_TAG_LEN, 0)) {
++if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, CCM_TAG_LEN, 0)) {
+ log_ssl_err("EVP_CIPHER_CTX_ctrl for tag len failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ }
+ #endif
+-if (!EVP_EncryptInit_ex(, NULL, NULL, key, IV)) {
++if (!EVP_EncryptInit_ex(ctx, NULL, NULL, key, IV)) {
+ log_ssl_err("EncryptInit for key/IV failed");
+ return 0;
+ }
+@@ -391,53 +391,53 @@
+ #ifdef EVP_CIPH_GCM_MODE
+ if ((mode == EVP_CIPH_GCM_MODE) || (mode == EVP_CIPH_CCM_MODE)) {
+ if (mode == EVP_CIPH_CCM_MODE) {
+-if (!EVP_EncryptUpdate(, NULL, , NULL, srclen)) {
++if (!EVP_EncryptUpdate(ctx, NULL, , NULL, srclen)) {
+ log_ssl_err("EncryptUpdate for datalen failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ }
+ if ((aad != NULL) && (aadlen > 0)) {
+-if (!EVP_EncryptUpdate(, NULL, , aad, aadlen)) {
++if (!EVP_EncryptUpdate(ctx, NULL, , aad, aadlen)) {
+ log_ssl_err("EncryptUpdate for authdata failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ }
+ }
+ #endif
+-if (!EVP_EncryptUpdate(, dest, , src, srclen)) {
++if (!EVP_EncryptUpdate(ctx, dest, , src, srclen)) {
+ log_ssl_err("EncryptUpdate for data failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ *destlen = len;
+-if (!EVP_EncryptFinal_ex(, dest + *destlen, )) {
++if (!EVP_EncryptFinal_ex(ctx, dest + *destlen, )) {
+ log_ssl_err("EncryptFinal failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ #ifdef EVP_CIPH_GCM_MODE
+ if (mode == EVP_CIPH_GCM_MODE) {
+-if (!EVP_CIPHER_CTX_ctrl(, EVP_CTRL_GCM_GET_TAG, GCM_TAG_LEN,
++if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, GCM_TAG_LEN,
+  dest + *destlen)) {
+ log_ssl_err("EVP_CIPHER_CTX_ctrl for get tag failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ len += GCM_TAG_LEN;
+ } else if (mode == EVP_CIPH_CCM_MODE) {
+-if (!EVP_CIPHER_CTX_ctrl(, EVP_CTRL_CCM_GET_TAG, CCM_TAG_LEN,
++if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_GET_TAG, CCM_TAG_LEN,
+  dest + *destlen)) {
+ log_ssl_err("EVP_CIPHER_CTX_ctrl for get tag failed");
+-EVP_CIPHER_CTX_cleanup();
++EVP_CIPHER_CTX_free(ctx);
+ return 0;
+ }
+ len += CCM_TAG_LEN;
+ }
+ #endif
+ *destlen += len;
+-EVP_CIPHER_CTX_cleanup();
++

Bug#845929: lua-sandbox FTBFS on 32bit architectures: test_heka_message fails

2016-11-26 Thread Adrian Bunk

Source: lua-sandbox
Version: 1.2.1-2
Severity: serious

https://buildd.debian.org/status/package.php?p=lua-sandbox

...
  Start  7: test_heka_message
 7/14 Test  #7: test_heka_message ..***Failed0.00 sec
line: 345 (hlen == 5 + i) i: 4 received 5
Tests run: 9

  Start  8: test_heka_message_matcher
...

Bug#845928: lua-sandbox FTBFS with test failures on big endian architectures

2016-11-26 Thread Adrian Bunk

Source: lua-sandbox
Version: 1.2.1-2
Severity: important

...
 6/14 Test  #6: test_util ..   Passed0.21 sec
  Start  7: test_heka_message
 7/14 Test  #7: test_heka_message ..***Failed0.00 sec
line: 247 (v.u.d == 1) invalid value: 3.03865e-319
Tests run: 7

  Start  8: test_heka_message_matcher
 8/14 Test  #8: test_heka_message_matcher ..***Failed0.00 sec
line: 133 (lsb_eval_message_matcher(mm, )) Fields[double] == 99.9
Tests run: 3

  Start  9: test_string
 9/14 Test  #9: test_string    Passed0.00 sec
  Start 10: test_move_heka_sandbox_tests
10/14 Test #10: test_move_heka_sandbox_tests ...   Passed0.01 sec
  Start 11: test_heka_sandbox
11/14 Test #11: test_heka_sandbox ..***Failed0.01 sec
tests and results are mis-matched
test: 3
expected: 
\x0a\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x03\x22\x03\x69\x69\x6d\x4a\x02\x68\x6e\x52\x13\x0a\x06\x6e\x75\x6d\x62\x65\x72\x10\x03\x39\x00\x00\x00\x00\x00\x00\xf0\x3f\x52\x2c\x0a\x07\x6e\x75\x6d\x62\x65\x72\x73\x10\x03\x1a\x05\x63\x6f\x75\x6e\x74\x3a\x18\x00\x00\x00\x00\x00\x00\xf0\x3f\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x08\x40\x52\x0e\x0a\x05\x62\x6f\x6f\x6c\x73\x10\x04\x42\x03\x01\x00\x00\x52\x0a\x0a\x04\x62\x6f\x6f\x6c\x10\x04\x40\x01\x52\x10\x0a\x06\x73\x74\x72\x69\x6e\x67\x22\x06\x73\x74\x72\x69\x6e\x67\x52\x15\x0a\x07\x73\x74\x72\x69\x6e\x67\x73\x22\x02\x73\x31\x22\x02\x73\x32\x22\x02\x73\x33
received: 
\x0a\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x03\x22\x03\x69\x69\x6d\x4a\x02\x68\x6e\x52\x13\x0a\x06\x6e\x75\x6d\x62\x65\x72\x10\x03\x39\x3f\xf0\x00\x00\x00\x00\x00\x00\x52\x2c\x0a\x07\x6e\x75\x6d\x62\x65\x72\x73\x10\x03\x1a\x05\x63\x6f\x75\x6e\x74\x3a\x18\x3f\xf0\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x40\x08\x00\x00\x00\x00\x00\x00\x52\x0e\x0a\x05\x62\x6f\x6f\x6c\x73\x10\x04\x42\x03\x01\x00\x00\x52\x0a\x0a\x04\x62\x6f\x6f\x6c\x10\x04\x40\x01\x52\x10\x0a\x06\x73\x74\x72\x69\x6e\x67\x22\x06\x73\x74\x72\x69\x6e\x67\x52\x15\x0a\x07\x73\x74\x72\x69\x6e\x67\x73\x22\x02\x73\x31\x22\x02\x73\x32\x22\x02\x73\x33
1479420747 [3] iim lua/iim.lua:38: test: 4 err: inject_message() failed: 
rejected by the callback
line: 594 (8 == stats.im_cnt) received 0
Tests run: 13

  Start 12: test_move_luasandbox_lua_modules
...

Bug#668238: terminator: Doesn't close unlinked files

Hi,

I've just read it more carefully that you're not only worried about the
number of files, but also about the overall disk usage and the entire
design as well.

Along with the encryption, compression was also implemented, so the overall
occupied size is now (with the gtk3-based vte-0.40 or newer) about 3-4x
smaller than before. (Note that compression relies on the sparse block
features of Unix filesystems, see
https://bugzilla.gnome.org/show_bug.cgi?id=738121 and
https://git.gnome.org/browse/vte/tree/src/vtestream-file.h?h=vte-0-46 if
you really care about the technical details.)

Looking at your bullet points in order:

1. Just make your /tmp large enough, or decrease the scrollback size. "or
is actually tmpfs in memory" -- this is not a concern; the scrollback has
to reside somewhere, if it's in vte's (terminator's) memory then it's
essentially the same as being written to a file on tmpfs. You can't have a
large scrollbar that's just magical without being stored anywhere :)

2. That's a valid point, but not related to vte or terminator in
particular, and should have an app-agnostic generic solution. With a
trivial modification vte could only unlilnk those files when the widget is
destroyed, it'd make them easier to discover, yet remain on the disk if the
app crashes. Unlinking and keeping an fd open is a typical pattern used by
many others who won't need the file once the app exits, I see no reason for
vte not to follow this pattern.

3. As said, with newer (gtk3-based) vte (used by terminator-1.90) it's at
most 3 per widget.

4. I don't understand this at all. Who would select() on them? It's
unlinked as soon as created, so noone is supposed to open it other than the
creator vte / terminator itself. It's not waiting for data to appear there,
so there's no select() whatsoever going on on these files, only
read()/write() operations.

cheers,
e.

Bug#845927: No sound Acer 2730 (Gnawty Atom 36x/37x series Atom

2016-11-26 Thread Frank E. Davidson

Package: kernel
Version: 4.5
Debian Jessie 8.6.0+ gnome desktopi386
Good day,
Sorry, I'm a user, not a developer. Can't make head nor tail of the bug
reporting instructions and package finding instructions.

I cannot get sound to work on live Debian-based OSes, particularly TAILS 2.x,
3.0 alpha.

Preconditions
Machine: Acer C730 (CB3-111) Gnawty- Atom Z36/37 Baytrail / Valleyview
Live OSes run through Seabios RW Legacy (flashed by script from johnlewis.ie)

What I did
Ran Tails Debian-based as a live usb on listed machine.

What happened
Setting>sound>no output devices listed

Attempted resolution
Installed numerous alsa pulse tools but was not able to configure sound to
output to speakers.
Ran alsamixer it seems sound is routed to HDMI and can't be changed to analog
output i.e.speakers.
Ran pavucontrol. The config tab lists only HDMI devices. and can't be changed
to analog output i.e.speakers
snd_hda_intel is loaded but o/p goes to HDMI. I don't have an HDMI device it's
a chromebook.

I raised a ticket with tails bug team
They responded:
---
Hi Franck,
> 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
> High Definition Audio Controller (rev 0e)
Thanks for taking time to report this issue.
It looks that your issue is not specific to Tails, but rather to Linux
support of your hardware.
Is your soundcard working with another O.S like Debian or Ubuntu?
Could you please boot with a newer version of Debian, from which
Tails is based. You can find such live DVD ISO at
http://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/debian-live-8.6.0-i386-gnome-desktop.iso
With your help this issue could hopefully then be fixed in a future
version of linux and thus Tails.
Thanks by advance
They did not raise an upstream ticket to Debian.
---
I tried making a Debian live USB but Jessie didn't detect network controller,
audio, trackpad ... To hinder progress further, I couldn't get persistence to
work so got nowhere on submitting a Debian report via reportbug. I followed
several guides and the advice was inconsistent whether to put a file called
live-persistence.conf or persistence.conf into aa partition called rw-live /
persistence / casper-rw
Is there a correct way that works?

Nevertheless, sound did not work.
Tried with Ubuntu Live. No sound
Sound is fine with installed Ubuntu ran as a Crouton chroot (sound o/p device
listed as CRAS which is part of ChromeOS)
Figured at this juncture problem is either Linux or bios.

---
I then posted on a coreboot forum
https://plus.google.com/communities/112479827373921524726/s/baytrail
Frank E Davidson
coreboot specific
I have never got Tails 2.x, or 3.0 alpha to output sound to analogue using
Seabios RW Legacy on my Acer C730 Gnawty (aka CB3-111?). All the options in
pavucontrol > config tab are HDMI. I raised a ticket and the tails bug team
said it * may* be a Debian dependency but I can't test as can;t get a Debian
Live to detect network, trackpad, sound o/p and to further frustrate
troubleshooting persistence doesn't work. I'm wondering if the Seabios might
not be reporting the firmware to the OS. Sound works fine on Ubuntu 14 run as a
Crouton chroot. Any suggestions, anyone?

I got a response on the google+ forum

Matt DeVillier (Mr. Chromebox)
this is a known, and multi-faceted issue affecting many Baytrail ChromeOS
devices, and has nothing to do with SeaBIOS. The issues at play are the
following:
- with the RW_LEGACY firmware, the audio device is initialized by depthcharge
(the ChromeOS payload) before SeaBIOS is run. That pre-init causes problems on
some devices but not others; the only workaround is to use the BOOT_STUB
firmware (which eliminates the depthcharge payload)
- upstream linux kernels 4.5+ contain a patch that breaks audio on Baytrail
ChromeOS devices
- upstream linux kernels 4.5+ added support for audio on Braswell devices;
enabling audio on Baytrail and Braswell devices is mutually exclusive, so any
given kernel can only be configured for one or another, and most default to
Braswell.
To figure out what issue(s) you're running into, boot GalliumOS from USB and
see if you have audio there. If non-functional, your issue is at least partly
related to the depthcharge audio init. If functional, then you might try
rebuilding a tails kernel with the config options and related patch(es) used by
GalliumOS.
Any crouton instance is still using the ChromeOS kernel (and therefore audio
config/drivers as well) and will therefore work just fine. It's not a good
barometer of anything.
---
I can't change the kernel in Tails.
I still use chromeos, so unable

Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1

2016-11-26 Thread Evgeny Kapun


Package: openbox-lxde-session
Version: 0.99.2-1
Severity: grave

When trying to install openbox-lxde-session package, dpkg fails with an error 
message:

dpkg: error processing archive .../openbox-lxde-session_0.99.2-1_all.deb 
(--unpack):
 trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in 
package lxde-common 0.99.2-1

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

2016-11-26 Thread Johannes Schauer

Package: autopkgtest
Version: 4.2.1
Severity: normal

Hi,

as the man page suggests, I'm running:

$ AUTOPKGTEST_APT_PROXY=http://127.0.0.1:3142 sudo vmdebootstrap --verbose 
--serial-console --distribution=sid 
--customize=/usr/share/autopkgtest/setup-commands/setup-testbed 
--user=test/test --size=10 --grub --image=autopkgtest-sid.raw   
  
Creating disk image
Creating partitions
Creating filesystem ext4
Mounting /dev/mapper/loop0p1 on /tmp/tmpmc1xY2
Debootstrapping sid [amd64]
Give root an empty password
Removing udev persistent cd and net rules
Enabling systemd-networkd for DHCP
Enabling systemctl-resolved for DNS
Running customize script /usr/share/autopkgtest/setup-commands/setup-testbed
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
WARNING: update-grub failed!
Err:1 http://httpredir.debian.org/debian sid InRelease
  Temporary failure resolving 'httpredir.debian.org'
Reading package lists... Done
W: Failed to fetch http://httpredir.debian.org/debian/dists/sid/InRelease  
Temporary failure resolving 'httpredir.debian.org'
W: Some index files failed to download. They have been ignored, or old ones 
used instead.
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
  libdbus-1-3 libeatmydata1 libexpat1
Suggested packages:
  default-dbus-session-bus | dbus-session-bus
The following NEW packages will be installed:
  dbus eatmydata libdbus-1-3 libeatmydata1 libexpat1
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 509 kB of archives.
After this operation, 1435 kB of additional disk space will be used.
Err:1 http://httpredir.debian.org/debian sid/main amd64 libdbus-1-3 amd64 
1.10.12-1
  Temporary failure resolving 'httpredir.debian.org'
Err:2 http://httpredir.debian.org/debian sid/main amd64 libexpat1 amd64 2.2.0-1
  Temporary failure resolving 'httpredir.debian.org'
Err:3 http://httpredir.debian.org/debian sid/main amd64 dbus amd64 1.10.12-1
  Temporary failure resolving 'httpredir.debian.org'
Err:4 http://httpredir.debian.org/debian sid/main amd64 libeatmydata1 amd64 
105-5
  Temporary failure resolving 'httpredir.debian.org'
Err:5 http://httpredir.debian.org/debian sid/main amd64 eatmydata all 105-5
  Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/d/dbus/libdbus-1-3_1.10.12-1_amd64.deb
  Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/e/expat/libexpat1_2.2.0-1_amd64.deb
  Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/d/dbus/dbus_1.10.12-1_amd64.deb  
Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/libe/libeatmydata/libeatmydata1_105-5_amd64.deb
  Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/libe/libeatmydata/eatmydata_105-5_all.deb
  Temporary failure resolving 'httpredir.debian.org'
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?
EEEK! Something bad happened...
Command failed: /usr/share/autopkgtest/setup-commands/setup-testbed 
/tmp/tmpmc1xY2 autopkgtest-sid.raw


Cleaning up
Umounting /tmp/tmpmc1xY2
ERROR: Command failed: /usr/share/autopkgtest/setup-commands/setup-testbed 
/tmp/tmpmc1xY2 autopkgtest-sid.raw



This problem appears with or without AUTOPKGTEST_APT_PROXY set. My host
is able to resolve httpredir.debian.org just fine:

$ ping -c 4 httpredir.debian.org
PING httpredir.debian.org (5.153.231.35) 56(84) bytes of data.
64 bytes from httpredir-bm-01.debian.org (5.153.231.35): icmp_seq=1 ttl=41 
time=49.1 ms
64 bytes from httpredir-bm-01.debian.org (5.153.231.35): icmp_seq=2 ttl=41 
time=47.5 ms
64 bytes from httpredir-bm-01.debian.org (5.153.231.35): icmp_seq=3 ttl=41 
time=45.8 ms
64 bytes from httpredir-bm-01.debian.org (5.153.231.35): icmp_seq=4 ttl=41 
time=53.9 ms

This is with vmdebootstrap (= 1.7-1).

Thanks!

cheers, josch


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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.3
ii  libdpkg-perl1.18.13
ii  procps

Bug#668238: terminator: Doesn't close unlinked files

Hi,

It is by design that Terminator (more precisely, the vte widget that does
the actual terminal emulation) stores the scrollback data in unlinked
temporary files.

Terminator-0.98 uses the gtk2-based vte for terminal emulation, which uses
too many of them, up to 12 per vte (that is, per terminal).

Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in which we've optimized
it to use at most 3 files per vte. (Moreover, the contents are no longer in
plain text, they are encrypted.)

e.

Bug#845924: Atanks fails to compile on kFreeBSD

2016-11-26 Thread Jesse Smith

Package: atanks
Version: 6.5

When attempting to compile the latest version of Atanks on the Debian
kFreeBSD port, the compilation fails due to a fault in detecting which
operating system Atanks is building on. This is a problem with the
upstream build system.

The Debian build log showing the failure can be found here:
https://buildd.debian.org/status/fetch.php?pkg=atanks=kfreebsd-amd64=6.5~dfsg-1=1480204118=log

I believe the issue has been fixed in the upstream code repository,
though the patch is not in any final release version of Atanks yet. A
patch which should fix the build issue on the Debian servers is attached.

- Jesse
diff --git a/Changelog b/Changelog
index 827931a..9a7808d 100644
--- a/Changelog
+++ b/Changelog
@@ -1,13 +1,5 @@
 NOTE: From now on, new changes appear at the top of this file.
 
- Atanks-6.5 released ===
-
-   - Remove old Atanks binary during normal "make clean".
-
-   - Added patch from Debian which makes the build process reproducible.
- Thanks to Reiner Herrmann for submitting the patch. Closes
- Debian bug #842865.
-
Fixes:
- Falling damage that was caused by a driller or riot weapon, is now
  credited to the shooter of that weapon.
@@ -33,6 +25,15 @@ NOTE: From now on, new changes appear at the top of this 
file.
  nearer to the tank than on the point were the missile would explode
  if not shot down.
 
+ Atanks-6.5 released ===
+
+   - Remove old Atanks binary during normal "make clean".
+
+   - Added patch from Debian which makes the build process reproducible.
+ Thanks to Reiner Herrmann for submitting the patch. Closes
+ Debian bug #842865.
+
+
  Atanks-6.4 released ===
Service release with bug fixes and some improvements for the AI.
Fixes:
diff --git a/src/debug.h b/src/debug.h
index d86b1df..37e324b 100644
--- a/src/debug.h
+++ b/src/debug.h
@@ -26,7 +26,7 @@
 # define ATANKS_IS_LINUX
 #endif // Linux
 
-#if !defined(ATANKS_IS_WINDOWS) && !defined(ATANKS_IS_LINUX)
+#if !defined(ATANKS_IS_WINDOWS) && !defined(ATANKS_IS_LINUX) && 
!defined(ATANKS_IS_BSD)
 # error "Only Windows, Linux and BSD are supported at the moment"
 #endif // Windows versus Linux

Bug#845923: ITP: django-impersonate -- Django application to allow superusers to impersonate other accounts

2016-11-26 Thread Scott Kitterman

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-impersonate
  Version : 1.1~a0+hg20161126
  Upstream Author : Peter Sanchez 
* URL : http://bitbucket.org/petersanchez/django-impersonate/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Django application to allow superusers to impersonate 
accounts

 Simple Django application to allow superusers to "impersonate" other
 non-superuser accounts.

I intend to maintain this in the Debian Python Modules Team.  The initial
upload is an unreleased snapshot since there is not a Django 1.10 compatible
final release yet.  I am expecting one well before the freeze.

Bug#833901: terminator: Copy and paste from other applications to Terminator are failing

Hi,

Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug around the so-called "bracketed paste mode" which causes the
behavior you see.

Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in which we've fixed this
bracketed paste bug.

e.

Bug#831944: NMU of pyorbit


Hi,

please find the attached patch of the NMU I've just uploaded.

Regards,
Tobias
diff -u pyorbit-2.24.0/debian/changelog pyorbit-2.24.0/debian/changelog
--- pyorbit-2.24.0/debian/changelog
+++ pyorbit-2.24.0/debian/changelog
@@ -1,3 +1,12 @@
+pyorbit (2.24.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with dpkg-buildpackage -A. Thanks to
+Santiago Vila  for the patch. Closes: #831944
+  * Remove Loic Minier from Uploaders, due to Debian GNOME team policy
+
+ -- Dr. Tobias Quathamer   Sun, 27 Nov 2016 00:55:45 +0100
+
 pyorbit (2.24.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u pyorbit-2.24.0/debian/control pyorbit-2.24.0/debian/control
--- pyorbit-2.24.0/debian/control
+++ pyorbit-2.24.0/debian/control
@@ -6,7 +6,7 @@
 Section: python
 Priority: optional
 Maintainer: Sebastien Bacher 
-Uploaders: Debian GNOME Maintainers , Josselin Mouette , Loic Minier 
+Uploaders: Debian GNOME Maintainers , Josselin Mouette 
 Build-Depends: debhelper (>= 5.0.37.2),
dh-python,
gnome-pkg-tools (>= 0.10),
diff -u pyorbit-2.24.0/debian/rules pyorbit-2.24.0/debian/rules
--- pyorbit-2.24.0/debian/rules
+++ pyorbit-2.24.0/debian/rules
@@ -51,6 +51,10 @@
 	$(MAKE) -C build-$*
 	touch $@
 
+build-arch: build
+
+build-indep: build
+
 build: $(PYVERS:%=build-%/build-stamp)
 
 install-clean:
@@ -110 +114 @@
-.PHONY: build clean binary-indep binary-arch binary install patch unpatch
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install patch unpatch


signature.asc
Description: OpenPGP digital signature

Bug#818635: terminator: Terminator omits lines in some scenarios (may be related to coloring)

Hi,

Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug that sounds like the one you're describing (and yes it was
related to coloring).

Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in which we've fixed the
scrollback corruption bug that we were aware of.

e.

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

2016-11-26 Thread Roger Shimizu

On Sun, Nov 27, 2016 at 7:50 AM, Ryan Tandy  wrote:
> Control: tag -1 patch
>
> On Sat, Nov 26, 2016 at 12:59:21PM -0800, Ryan Tandy wrote:
>>
>> Unfortunately dmesg and kern.log are flooded with messages like:
>>
>> [  161.781360] Bad eraseblock 32764 at 0x0001fff0
>> [  161.786261] Bad eraseblock 32765 at 0x0001fff4
>> [  161.791159] Bad eraseblock 32766 at 0x0001fff8
>> [  161.796058] Bad eraseblock 32767 at 0x0001fffc
>>
>> and boot takes a very long time due to logging all these messages. I
>> suppose that's a side-effect of using the kurobox-pro dtb - guessing it has
>> a different flash layout?

Glad to hear it works for you.

Actually there's less flash on Linkstation GL or Pro/Live than on KuroBox Pro.
So using kurobox-pro dtb is just a tentative solution for test purpose.

> On Sun, Nov 27, 2016 at 01:20:10AM +0900, Roger Shimizu wrote:
>>
>> - start your device by kernel 4.3 first.
>> - confirm your have flash-kernel and linux-image-4.8.0-1-marvell
>> installed.
>> - cp /usr/lib/linux-image-4.8.0-1-marvell/orion5x-kuroboxpro.dtb
>> /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb
>> - flash-kernel --force 4.8.0-1-marvell

Sorry, I forgot to mention after steps above, when you want to switch
to another kernel version, and run like
- flash-kernel --force 

The flash-kernel will treat the device as Kurobox Pro. So you need the
following command to tell flash-kernel that your device is Linkstation
Pro/Live:

# echo -n "Buffalo Linkstation Pro/Live" > /etc/flash-kernel/machine

After that, you can switch back to kernel 4.3 or 4.4, which use the
device file instead of device tree, if you still installed on your
system:
# flash-kernel --force 4.3.0-1-orion5x
- or -
# flash-kernel --force 4.4.0-1-marvell

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

Bug#840667: ltsp-build-client fails at apt update call

2016-11-26 Thread Vagrant Cascadian

Control: retitle 840667 ltsp-build-client: incorrect /tmp permissions when 
TMP/TMPDIR are set
Control: tags 840667 +pending

On 2016-10-14, Wolfgang Schweer wrote:
> On Thu, Oct 13, 2016 at 06:41:53PM +0200, Wolfgang Schweer wrote:
>> I have no idea where the wrong permissions come from.

Apparently, this is because 005-tmpdir runs before debootstrap, and
creates the directories referenced by TMP and TMPDIR (usually created by
something like libpam-tmpdir).

> This seems to be caused by ltsp-build-client/Debian/005-tmpdir; /tmp 
> inherits the wrong permissions.

I've worked around the issue upstream, and will include in an upload soon:

  https://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2763

I was able to recreate the problem with libpam-tmpdir installed, and the
above commit fixes the issue for me.

> With 005-tmpdir removed, installation succeeds; the chroot's /tmp dir 
> has the correct permissions 1777.
>
> Also, this seems to work:
>
> diff --git a/server/share/ltsp/plugins/ltsp-build-client/Debian/005-tmpdir 
> b/server/share/ltsp/plugins/ltsp-build-client/Debian/005-tmpdir
> index a18a225..d52c535 100644
> --- a/server/share/ltsp/plugins/ltsp-build-client/Debian/005-tmpdir
> +++ b/server/share/ltsp/plugins/ltsp-build-client/Debian/005-tmpdir
> @@ -7,7 +7,7 @@ case $MODE in
>  mkdir -p "$ROOT/$dir"
>  # set permissions of dir
>  # FIXME: handle permissions of intermediate dirs, too
> -chmod --reference $dir "$ROOT/$dir"
> +chmod 1777 "$ROOT/$dir"
>  fi
>  done
>  ;;
>
>
> But either change might have sideeffects...

This would compromise the purpose of things like libpam-tmpdir, which
creates a directory only writeable by the user, and sets TMP and TMPDIR
to that directory.

There are arguably security implications using TMP and TMPDIR from
environment variables, and thus many applications unset or ignore those
variables... which leads to some programs requiring the directories be
present (with correct permissions by the user), and some not using them
at all... so not sure it's a good idea to use at all.

But at any rate, the next version should at least work around the issue.

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#751588: Setting TERM=terminator messes up console

The correct setting for TERM is xterm (or rather xterm-256color). This
variable is supposed to refer to a terminal behavior description, not to
the name of the executable that is a terminal emulator.

Terminator uses the VTE widget for actual terminal emulation, which in turn
tries to emulate xterm as closely as reasonable. VTE defaults to
xterm-256color nowadays (used to be xterm up until about a year ago), and
so does gnome-terminal (the "reference" frontend developed together with
VTE).

If kupfer (whatever that is) requires the terminal emulator's executable
name to be specified in $TERM then it's a bug (a fundamental
misunderstanding of this variable) in kupfer and should be fixed there.

Bug#809343: Lines disappear from scrollback

Hi,

Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug that sounds like the one you're describing.

Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in which we've fixed the
scrollback corruption bug that we were aware of.

e.

Bug#828269: [htcondor-debian] Bug#828269: Info from upstream

2016-11-26 Thread Tim Theisen

I have been working on getting HTCondor working with OpenSSL 1.1.

Although we would prefer to compile with VOMS support, it is preferable
to turn this off, rather than miss getting into stretch. I have a patch
to turn off compilation with VOMS. (rules.patch) We should revert this
patch when the VOMS folks fix up their OpenSSL issues.

Once the VOMS dependency was eliminated, I found a few minor changes
that needed to be addressed within HTCondor itself. I have included a
patch to 8.4.9 (OpenSSL1.1.patch). This update will be released as part
of the HTCondor 8.4.10 release, expected on December 1st.

Let me know if you need anything more, ...Tim

On 11/04/2016 06:31 AM, Michael Hanke wrote:
> Relaying information from upstream's triaging:
>
>
> 
> I concluded that the problem was not with HTCondor. It had to do with the
> following packages: libglobus-gsi-proxy-core, libglobus-gsi-proxy-ssl and
> voms. The Globus folks addressed the first two issues. However, the VOMS issue
> (#828595) is a blocker for us.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828595
> https://github.com/italiangrid/voms/issues/50
> 
> ___
> htcondor-debian mailing list
> htcondor-deb...@cs.wisc.edu
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian

-- 
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

diff --git a/src/condor_includes/condor_crypt_3des.h b/src/condor_includes/condor_crypt_3des.h
index e2967d8..dc29b6a 100644
--- a/src/condor_includes/condor_crypt_3des.h
+++ b/src/condor_includes/condor_crypt_3des.h
@@ -61,7 +61,7 @@ class Condor_Crypt_3des : public Condor_Crypt_Base {
 //--
 // Private constructor
 //--
-des_key_schedule  keySchedule1_, keySchedule2_, keySchedule3_;
+DES_key_schedule  keySchedule1_, keySchedule2_, keySchedule3_;
 unsigned char ivec_[8];
 int   num_;
 };
diff --git a/src/condor_io/condor_auth_ssl.cpp b/src/condor_io/condor_auth_ssl.cpp
index b8bb6cf..3c366b3 100644
--- a/src/condor_io/condor_auth_ssl.cpp
+++ b/src/condor_io/condor_auth_ssl.cpp
@@ -36,7 +36,9 @@
 #endif
 
 // Symbols from libssl
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 static long (*SSL_CTX_ctrl_ptr)(SSL_CTX *, int, long, void *) = NULL;
+#endif
 static void (*SSL_CTX_free_ptr)(SSL_CTX *) = NULL;
 static int (*SSL_CTX_load_verify_locations_ptr)(SSL_CTX *, const char *, const char *) = NULL;
 #if OPENSSL_VERSION_NUMBER < 0x1000L
@@ -55,8 +57,12 @@ static void (*SSL_free_ptr)(SSL *) = NULL;
 static int (*SSL_get_error_ptr)(const SSL *, int) = NULL;
 static X509 *(*SSL_get_peer_certificate_ptr)(const SSL *) = NULL;
 static long (*SSL_get_verify_result_ptr)(const SSL *) = NULL;
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 static int (*SSL_library_init_ptr)() = NULL;
 static void (*SSL_load_error_strings_ptr)() = NULL;
+#else
+static int (*OPENSSL_init_ssl_ptr)(uint64_t, const OPENSSL_INIT_SETTINGS *) = NULL;
+#endif
 static SSL *(*SSL_new_ptr)(SSL_CTX *) = NULL;
 static int (*SSL_read_ptr)(SSL *, void *, int) = NULL;
 static void (*SSL_set_bio_ptr)(SSL *, BIO *, BIO *) = NULL;
@@ -79,7 +85,11 @@ Condor_Auth_SSL :: Condor_Auth_SSL(ReliSock * sock, int /* remote */)
 
 Condor_Auth_SSL :: ~Condor_Auth_SSL()
 {
+#if OPENSSL_VERSION_NUMBER < 0x1000L
 ERR_remove_state( 0 );
+#elif OPENSSL_VERSION_NUMBER < 0x1010L
+ERR_remove_thread_state( 0 );
+#endif
 	if(m_crypto) delete(m_crypto);
 }
 
@@ -96,7 +106,9 @@ bool Condor_Auth_SSL::Initialize()
 
 	if ( Condor_Auth_Kerberos::Initialize() == false ||
 		 (dl_hdl = dlopen(LIBSSL_SO, RTLD_LAZY)) == NULL ||
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 		 !(SSL_CTX_ctrl_ptr = (long (*)(SSL_CTX *, int, long, void *))dlsym(dl_hdl, "SSL_CTX_ctrl")) ||
+#endif
 		 !(SSL_CTX_free_ptr = (void (*)(SSL_CTX *))dlsym(dl_hdl, "SSL_CTX_free")) ||
 		 !(SSL_CTX_load_verify_locations_ptr = (int (*)(SSL_CTX *, const char *, const char *))dlsym(dl_hdl, "SSL_CTX_load_verify_locations")) ||
 #if OPENSSL_VERSION_NUMBER < 0x1000L
@@ -115,8 +127,12 @@ bool Condor_Auth_SSL::Initialize()
 		 !(SSL_get_error_ptr = (int (*)(const SSL *, int))dlsym(dl_hdl, "SSL_get_error")) ||
 		 !(SSL_get_peer_certificate_ptr = (X509 *(*)(const SSL *))dlsym(dl_hdl, "SSL_get_peer_certificate")) ||
 		 !(SSL_get_verify_result_ptr = (long (*)(const SSL *))dlsym(dl_hdl, "SSL_get_verify_result")) ||
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 		 !(SSL_library_init_ptr = (int (*)())dlsym(dl_hdl, "SSL_library_init")) ||
 		 !(SSL_load_error_strings_ptr = (void (*)())dlsym(dl_hdl, "SSL_load_error_strings")) ||
+#else
+		 !(OPENSSL_init_ssl_ptr = (int (*)(uint64_t, const OPENSSL_INIT_SETTINGS *))dlsym(dl_hdl,

Bug#845922: virtualbox-guest-x11 broken after jessie to stretch upgrade

2016-11-26 Thread Patrick Schleizer

Package: virtualbox-guest-x11
Severity: important
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

after upgrading from jessie to stretch inside VirtualBox (Whonix), X is
no longer starting.

Even though the old kernel module was uninstalled and the new one
installed by dkms during upgrade.

no suitable module for running kernel

After "sudo apt-get purge virtualbox-guest-utils" and "sudo apt-get
install virtualbox-guest-x11" everything is back to normal.

Cheers,
Patrick

Bug#845859: kodi: switch to build depend on the metapackage default-libmysqlclient-dev

2016-11-26 Thread Bálint Réczey

Control: fixed -1 17.0~beta3+dfsg1-1

Hi Otto,

2016-11-26 23:08 GMT+01:00  :
> Package: kodi
> Severity: important
>
> Hi!
>
> This package build depends on libmysqlclient-dev. It should instead
> build-depend on default-libmysqlclient-dev metapackage, and end up
> having the run-time dependency of the libmysqlclient implementation
> Debian has chosen to use, currently MariaDB instead of Oracle MySQL.
>
> Announcement of new default-mysql-* metapackages:
> https://lists.debian.org/debian-devel-announce/2016/09/msg0.html
>
> Wiki: https://wiki.debian.org/Teams/MySQL/default-mysql-server
>
> MBF: https://lists.debian.org/debian-devel/2016/11/msg00832.html
>
> Please update the depencies accordingly. In most cases the required
> change is:
>
> * BEFORE: Build-Depends: libmysqlclient-dev
>
> * AFTER: Build-Depends: default-libmysqlclient-dev

This looks fixed for some time.

Cheers,
Balint

Bug#844081: Reproducer

2016-11-26 Thread Christian Geier

Hi Filip,
could you perhaps run the attached file on the test machine (with
`py.test vdir_test.py`, py.test is needed for the creation of a temp
directory).

On my machine the output looks like this:
[(0, 10), (0.0001, 8), (0.001, 0), (0.01, 0), (0.1, 0), (1, 0)]

Similar experiments before made me choose the current delay.

Best regards,
Christian

Quoting Filip Pytloun (2016-11-24 00:20:50)
> On 2016/11/24 00:00, Santiago Vila wrote:
> > Try using a chroot without union-type=overlay.
> 
> Unfortunately it will result in the same error :-/
import os
import time

def get_etag_from_file(f):
'''Get mtime-based etag from a filepath or file-like object.

This function will flush/sync the file as much as necessary to obtain a
correct mtime.
'''
stat = os.stat(f)
mtime = getattr(stat, 'st_mtime_ns', None)
if mtime is None:
mtime = stat.st_mtime
return '{:.9f}'.format(mtime)

def test_etag(tmpdir):
fpath = os.path.join(str(tmpdir), 'foo')
stats = dict()
for delay in [0, 0.0001, 0.001, 0.01, 0.1, 1]:
failed = list()
for one in range(10):

file_ = open(fpath, 'w')
file_.write('foo')
file_.close()

old_etag = get_etag_from_file(fpath)
time.sleep(delay)

file_ = open(fpath, 'w')
file_.write('bar')
file_.close()

new_etag = get_etag_from_file(fpath)

if old_etag == new_etag:
failed.append(
(one, new_etag)
)
stats[delay] = len(failed)
print(sorted(stats.items()))
assert False  # here to make sure we get the print output via py.test

Bug#845921: icedove: crash in nsTArray::ShrinkCapacity

2016-11-26 Thread Kim Alvefur (Zash)

Package: icedove
Version: 1:45.4.0-1~deb8u1
Severity: important

Dear Maintainer,

Icedove have been randomly crashing for me, usually when selecting a
folder.  Attached is a gdb backtrace of from a core dump of the latest
crash.


-- 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/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u6
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  hunspell-sv-se [hunspell-dictionary]  1.51-1
ii  iceowl-extension  1:45.4.0-1~deb8u1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information
#0  0x7fa54fef379b in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = 
#1  0x7fa54a56ce75 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7ffceadad2f0, context=0x7ffceadad1c0) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/toolkit/profile/nsProfileLock.cpp:185
unblock_sigs = {
  __val = {1024, 0 }
}
oldact = 
#2  0x7fa54ae47e86 in AsmJSFaultHandler (signum=, 
info=, context=0x7ffceadad1c0) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/js/src/asmjs/AsmJSSignalHandlers.cpp:1161
context = 0x7ffceadad1c0
info = 
signum = 11
#3  
No locals.
#4  jemalloc_crash () at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/memory/mozjemalloc/jemalloc.c:1626
No locals.
#5  0x00412d63 in arena_dalloc (ptr=, offset=) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/memory/mozjemalloc/jemalloc.c:4729
chunk = 
arena = 0x7fa54f40
pageind = 
mapelm = 
#6  0x7fa548a7fc5c in Free (aPtr=0x7fa51868e978) at 
../../dist/include/nsTArray.h:178
No locals.
#7  nsTArray_base::ShrinkCapacity (this=0x7fa518128580, aElemSize=48, 
aElemAlign=) at ../../dist/include/nsTArray-inl.h:230
size = 
#8  0x7fa54a0bca77 in nsTArray_Impl::~nsTArray_Impl (this=0x7fa518128580, 
__in_chrg=) at ../../dist/include/nsTArray.h:825
No locals.
#9  0x7fa54a0e83aa in ~nsTArray (this=, __in_chrg=) at ../../dist/include/nsTArray.h:2084
No locals.
#10 ~DisplayItemClip (this=, __in_chrg=) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/layout/base/DisplayItemClip.h:33
No locals.
#11 nsDisplayListBuilder::~nsDisplayListBuilder (this=0x7ffceadad9c8, 
__in_chrg=) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/layout/base/nsDisplayList.cpp:845
i = 3
#12 0x7fa54a12c798 in nsLayoutUtils::PaintFrame (aRenderingContext=0x3578, 
aRenderingContext@entry=0x0, aFrame=0x7fa528eabdb0, aDirtyRegion=..., 
aBackstop=10, aBackstop@entry=4294967295, aFlags=3940210688) at 
/build/icedove-Yu4Z2X/icedove-45.4.0/mozilla/layout/base/nsLayoutUtils.cpp:3150
builder = {
  mFrameToAnimatedGeometryRootMap = {
> = {
   >> = {
mTable = {
  mOps = 0x7fa54cdf14a0 
 
>::Ops()::sOps>, 
  mHashShift = 29,

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)


Control: tag -1 patch

On Sat, Nov 26, 2016 at 12:59:21PM -0800, Ryan Tandy wrote:

Unfortunately dmesg and kern.log are flooded with messages like:

[  161.781360] Bad eraseblock 32764 at 0x0001fff0
[  161.786261] Bad eraseblock 32765 at 0x0001fff4
[  161.791159] Bad eraseblock 32766 at 0x0001fff8
[  161.796058] Bad eraseblock 32767 at 0x0001fffc

and boot takes a very long time due to logging all these messages. I 
suppose that's a side-effect of using the kurobox-pro dtb - guessing 
it has a different flash layout?


Looks like that was the case. I applied your patch to 
orion5x-linkstation-lsgl.dts, rebuilt the dtb, dropped it into 
/etc/flash-kernel/dtbs, and ran flash-kernel again. Much better:


[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-1-marvell (debian-ker...@lists.debian.org) 
(gcc version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 Debian 4.8.5-1 (2016-10-28)
[0.00] CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a005317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] OF: fdt:Machine model: Buffalo Linkstation Pro/Live

[...]

[3.297636] sata_mv sata_mv.0: version 1.28
[3.297844] sata_mv sata_mv.0: cannot get optional clkdev
[3.320803] sata_mv sata_mv.0: slots 32 ports 2
[3.386495] scsi host0: sata_mv
[3.403996] scsi host1: sata_mv
[3.411527] ata1: SATA max UDMA/133 irq 28
[3.415723] ata2: SATA max UDMA/133 irq 28
[3.733937] ata1: SATA link down (SStatus 0 SControl 300)
[4.212767] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[4.241078] ata2.00: ATA-7: SAMSUNG SP2504C, VT100-41, max UDMA7
[4.247154] ata2.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[4.293102] ata2.00: configured for UDMA/133
[4.298609] scsi 1:0:0:0: Direct-Access ATA  SAMSUNG SP2504C  0-41 
PQ: 0 ANSI: 5
[4.402529] sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 
GiB)
[4.416368] sd 1:0:0:0: [sda] Write Protect is off
[4.421270] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[4.421705] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[4.474159]  sda: sda1 sda2 sda3 < sda5 >
[4.493519] sd 1:0:0:0: [sda] Attached SCSI disk

Bug#845920: RM: dancer-xml -- RoQA; 3 RC bugs, low popcon, no upload since 2006


Package: ftp.debian.org
Severity: normal

Dear FTP-Masters,

please remove the package dancer-xml from unstable. It has already been 
removed from testing, I don't think it needs to re-enter after the 
release of stretch.


I'm CC'ing the maintainer via Debbugs.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#806627: NMU of libconfig


Hi,

please find the attached patch of the NMU I've just uploaded.

Regards,
Tobias
diff -Nru libconfig-1.5/debian/changelog libconfig-1.5/debian/changelog
--- libconfig-1.5/debian/changelog	2015-08-04 17:20:08.0 +0200
+++ libconfig-1.5/debian/changelog	2016-11-26 23:19:25.0 +0100
@@ -1,3 +1,12 @@
+libconfig (1.5-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS when built with dpkg-buildpackage -A.
+Thanks to Santiago Vila  (Closes: #806627)
+  * Remove Jose Luis Tallon from Uploaders list. (Closes: #838077)
+
+ -- Dr. Tobias Quathamer   Sat, 26 Nov 2016 23:19:25 +0100
+
 libconfig (1.5-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libconfig-1.5/debian/control libconfig-1.5/debian/control
--- libconfig-1.5/debian/control	2015-08-04 17:20:08.0 +0200
+++ libconfig-1.5/debian/control	2016-11-26 23:19:25.0 +0100
@@ -1,7 +1,6 @@
 Source: libconfig
 Priority: optional
 Maintainer: Jonathan McCrohan 
-Uploaders: Jose Luis Tallon 
 Build-Depends: debhelper (>= 9), dh-autoreconf, texinfo, g++ (>= 4:5)
 Build-Depends-Indep: texlive-latex-base, texlive-fonts-recommended
 Standards-Version: 3.9.6
@@ -16,7 +15,7 @@
 Description: parsing/manipulation of structured configuration files
  This library features a fully reentrant parser and includes bindings for
  both the C and C++ programming languages. It runs on modern POSIX-compliant
- systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on 
+ systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on
  Microsoft Windows 2000/XP and later (Visual Studio or MinGW).
  .
  This library allows parsing, manipulating and writing structured configuration
@@ -32,7 +31,7 @@
 Description: parsing/manipulation of structured configuration files (C++ binding)
  This library features a fully reentrant parser and includes bindings for
  both the C and C++ programming languages. It runs on modern POSIX-compliant
- systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on 
+ systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on
  Microsoft Windows 2000/XP and later (Visual Studio or MinGW).
  .
  This library allows parsing, manipulating and writing structured configuration
@@ -51,7 +50,7 @@
 Description: parsing/manipulation of structured config files (development)
  This library features a fully reentrant parser and includes bindings for
  both the C and C++ programming languages. It runs on modern POSIX-compliant
- systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on 
+ systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on
  Microsoft Windows 2000/XP and later (Visual Studio or MinGW).
  .
  This library allows parsing, manipulating and writing structured configuration
@@ -86,7 +85,7 @@
 Description: parsing/manipulation of structured config files (C++ development)
  This library features a fully reentrant parser and includes bindings for
  both the C and C++ programming languages. It runs on modern POSIX-compliant
- systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on 
+ systems such as Linux, Solaris, and Mac OS X (Darwin), as well as on
  Microsoft Windows 2000/XP and later (Visual Studio or MinGW).
  .
  This library allows parsing, manipulating and writing structured configuration
diff -Nru libconfig-1.5/debian/rules libconfig-1.5/debian/rules
--- libconfig-1.5/debian/rules	2015-08-04 17:20:08.0 +0200
+++ libconfig-1.5/debian/rules	2016-11-26 23:19:25.0 +0100
@@ -3,6 +3,8 @@
 # Uncomment this to turn on verbose mode.
 # # export DH_VERBOSE=1
 
+override_dh_auto_test-indep:
+
 override_dh_auto_build-indep:
 	$(MAKE) -C doc pdf
 


signature.asc
Description: OpenPGP digital signature

Bug#845919: RM: ilohamail -- ROM; Unmaintained, old

2016-11-26 Thread Joerg Jaspert

Package: ftp.debian.org
Severity: normal


Hi

please remove this package, its unmaintained, possibly wont be ported
to PHP7.

Joerg

Bug#845918: RM: muddleftpd -- ROM; Old, unused, unmaintained

2016-11-26 Thread Joerg Jaspert

Package: ftp.debian.org
Severity: normal

Hi,

please remove, its basically unmaintained and there are loads of other
ftpds one could use.

Joerg

Bug#845841: [Pkg-freeradius-maintainers] Bug#845841: freeradius: switch to build depend on the metapackage default-libmysqlclient-dev

2016-11-26 Thread Michael Stapelberg

We already build-depend on default-libmysqlclient-dev since
https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/commit/?id=433347af786d51a095a0262f6665bb9caa419e33

I’m guessing you looked at a different version of the package? If not, is
the optional dependency an issue? We use that because the packaging is also
used by downstream distributions which need some more time to make the
switch.

On Sat, Nov 26, 2016 at 11:07 PM,  wrote:

> Package: freeradius
> Severity: important
>
> Hi!
>
> This package build depends on libmysqlclient-dev. It should instead
> build-depend on default-libmysqlclient-dev metapackage, and end up
> having the run-time dependency of the libmysqlclient implementation
> Debian has chosen to use, currently MariaDB instead of Oracle MySQL.
>
> Announcement of new default-mysql-* metapackages:
> https://lists.debian.org/debian-devel-announce/2016/09/msg0.html
>
> Wiki: https://wiki.debian.org/Teams/MySQL/default-mysql-server
>
> MBF: https://lists.debian.org/debian-devel/2016/11/msg00832.html
>
> Please update the depencies accordingly. In most cases the required
> change is:
>
> * BEFORE: Build-Depends: libmysqlclient-dev
>
> * AFTER: Build-Depends: default-libmysqlclient-dev
>
> Thanks,
>
> Otto
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-
> freeradius-maintainers
>



-- 
Best regards,
Michael

Bug#845757: geneweb FTBFS on mipsel: dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory

2016-11-26 Thread Guillaume Brochu


Dear Adrian,


Thank you for this explanation about the cause of the FTBFS on mipsel.

If I understand well, the "cannot allocate memory" error with lzma on 
mipsel is caused by the high compression level 9, while the default 
value for xz compression is 6.


This modification was introduced in June 2012:

https://anonscm.debian.org/cgit/collab-maint/geneweb.git/commit/?id=16cddde963e4169c09bfe49cb6949fe0dc484f0c

At first sight, I don't see any reason to use compression level 9, so I 
will apply your patch on the git repository.



Best regards,


Guillaume Brochu

Bug#845559: micro-evtd: service start failed since kernel 4.8


Looks like I might want /dev/gpiochip0 rather than /dev/mem?

$ cat /sys/class/gpio/gpiochip0/label
f1010100.gpio

Bug#845518: protobuf-c-compiler cannot be executed during cross compilation

On Sat, Nov 26, 2016 at 03:34:44PM -0500, Robert Edmonds wrote:
> without the compiler. I will upload a new protobuf-c package with your
> patch shortly.

Great! I'll look into how far I can get with it.

> If this were the end of the dependency chain, then OK, we can upload a
> fixed protobuf-c and that's it. But it's not the end of the chain;
> protobuf-c build-depends on src:protobuf, and protobuf has a long
> history of being difficult to get building on all architectures at the
> same time (for instance, just have a look at the current buildd logs).
> Should we (Debian) look at how to get protobuf out of the dependency
> chain for bringing up new architectures?

I completely agree. When I filed this bug, I overlooked the
Build-Depends: libprotobuf-dev. Nevertheless, I think having
protobuf-c-compiler work for cross compilation would still be useful for
cross compiler end users.

> I'm at least partially responsible for this chain. Unbound build-depends
> on src:protobuf-c because of an optional feature which I turned on in
> the unbound build (--enable-dnstap) that requires protobuf-c. I also
> implemented changes in unbound (#828699) that allowed gnutls28 to
> build-depend on libunbound-dev for DANE support. Both of these are nice
> features to have and there are at least some users who would be
> disappointed if they were removed.

When I file patches for improving bootstrappability, I try hard not to
regress on such nice features. I consider the existence of such chains
as usual and try to work with them.

> Looking farther up the chain I see the audit ??? libprelude-dev
> build-dependency is due to --with-prelude being enabled in the audit
> build. Perhaps this feature could be targeted, similarly to #840262? I
> also wonder if the audisp-prelude plugin [0] could be split from
> src:audit and built by a separate source package. (It looks like the
> upstream developers prefer a monolithic repository, though.)

In general, splitting addon features to different source packages makes
bootstrapping easier as the Build-Depends become more fine grained.
Where feasible, I even prefer it to using build profiles.  Nevertheless,
dropping the audit -> libprelude dependency is not going to buy us much
as other bootstrap components need gnutls28 as well. For instance apt
uses curl, which uses gnutls82. If we want to go with a stage, then
likely gnutls28 is the place to add it.

I do note that staged builds have a significant maintenance cost.
Keeping stages working is non-trivial. Ensuring that their output is
compatible with unstaged builds is next to impossible. Thus I try to
avoid staged builds as much as I can - to the point of considering
larger dependency chains. Profiles such as  are slightly
better, because we can leverage reproducible builds to validate them
natively.

Helmut

Bug#845819: nmu all revers build depends of eigen3

2016-11-26 Thread Anton Gladky

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

Dear release team,

the new version of header only library eigen3 has recently
been released and uploaded into the Debian. Thus it would
be good to rebuild all reverse dependencies of this package
in the archive.

The arrached list contains all possible reverse-debendencies,
which need to be binNMUed.

If there is a better mechanism to ask for such request, please
let me know.

Thank you

Anton
analitza
avogadro
cain
calligra
ceres-solver
csound
digikam
dolfin
fastqtl
freecad
gnudatalanguage
guitarix
iqtree
kalzium
kido
kstars
lammps
liggghts
mia
minieigen
movit
mpqc3
mrpt
nanopolish
openbabel
opencv
openscad
opensurgsim
orocos-kdl
palabos
paraview
pcl
probabel
purify
ros-eigen-stl-containers
ros-geometric-shapes
ros-geometry
ros-geometry-experimental
ros-laser-geometry
ros-pcl-conversions
ros-rviz
salmon
sopt
step
tiledarray
woo
yade
cufflinks

Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2

2016-11-26 Thread Heinrich Schuchardt

Package: flash-kernel
Version: 3.71
Severity: wishlist

The appended patch provides support for the Hardkernel Odroid-C2.
It depends on a solution to
Bug #845779 flash-kernel: flashkernel uses mkimage -A arm on arm64

The Hardkernel Odroid C2 is a 64bit development board based on the
Amlogic S905 processor.

As mainline u-boot support is still under construction boot.scr
is build such that the stock u-boot can execute it.

Update the u-boot environment with
setenv bootcmd "ext4load mmc 0:1 0x107 boot.scr; autoscr 0x107"
saveenv

Separate ext4 partitions for '/boot' and '/' are assumed.
From 8483746841c140dc38784866c94a802f293cdb5b Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Sat, 26 Nov 2016 21:34:43 +
Subject: [PATCH 1/1] Add support for Hardkernel Odroid C2

The Hardkernel Odroid C2 is a 64bit development board based on the
Amlogic S905 processor.

As mainline u-boot support is still under construction boot.scr
is build such that the stock u-boot can execute it.

Update the u-boot environment with
setenv bootcmd "ext4load mmc 0:1 0x107 boot.scr; autoscr 0x107"
saveenv

Separate ext4 partitions for '/boot' and '/' are assumed.

Signed-off-by: Heinrich Schuchardt 
---
 bootscript/arm64/bootscr.hardkernel-odroid-c2 | 17 +
 db/all.db | 11 +++
 2 files changed, 28 insertions(+)
 create mode 100644 bootscript/arm64/bootscr.hardkernel-odroid-c2

diff --git a/bootscript/arm64/bootscr.hardkernel-odroid-c2 b/bootscript/arm64/bootscr.hardkernel-odroid-c2
new file mode 100644
index 000..5cce3de
--- /dev/null
+++ b/bootscript/arm64/bootscr.hardkernel-odroid-c2
@@ -0,0 +1,17 @@
+setenv fdtfile meson-gxbb-odroidc2.dtb
+setenv fk_kvers '@@KERNEL_VERSION@@'
+setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
+
+setenv condev "console=ttyAML0,115200n8 console=tty0"
+setenv bootargs "root=/dev/mmcblk1p2 rootwait ro ${condev}"
+
+setenv loadaddr "0x108"
+setenv dtb_loadaddr "0x100"
+setenv initrd_loadaddr "0x1300"
+
+ext4load mmc 0:1 ${initrd_loadaddr} uInitrd
+ext4load mmc 0:1 ${loadaddr} uImage
+ext4load mmc 0:1 ${dtb_loadaddr} ${fdtpath}
+fdt addr ${dtb_loadaddr}
+
+bootm ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
diff --git a/db/all.db b/db/all.db
index a9567a9..e81cf18 100644
--- a/db/all.db
+++ b/db/all.db
@@ -427,6 +427,17 @@ DTB-Id: sun4i-a10-marsboard.dtb
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+Machine: Hardkernel ODROID-C2
+U-Boot-Kernel-Address: 0x108
+U-Boot-Initrd-Address: 0x1300
+U-Boot-Script-Address: 0x100
+U-Boot-Script-Name: bootscr.hardkernel-odroid-c2
+Boot-Kernel-Path: /boot/uImage
+Boot-Initrd-Path: /boot/uInitrd
+Boot-Script-Path: /boot/boot.scr
+Required-Packages: u-boot-tools
+DTB-Id: meson-gxbb-odroidc2.dtb
+
 Machine: Hardkernel ODROID-U3 board based on Exynos4412
 Kernel-Flavors: armmp armmp-lpae
 DTB-Id: exynos4412-odroidu3.dtb
-- 
2.10.2

Bug#845559: micro-evtd: service start failed since kernel 4.8


Control: tag -1 confirmed upstream help

strace micro-evtd:

open("/dev/mem", O_RDWR|O_SYNC) = 4
mmap2(NULL, 4095, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0xf101) = -1 EPERM 
(Operation not permitted)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10b} ---
+++ killed by SIGSEGV +++

micro-evtd.c:

static void open_gpio(void)
{
#ifndef NO_GPIO
   off_t target = 0xF1010100;
   // Grab memory resource
   m_fd = open("/dev/mem", O_RDWR | O_SYNC);
   if (m_fd>0) {
   // Grab GPIO resource
   gpio = (unsigned long*)mmap(NULL, MAP_MASK, PROT_READ | PROT_WRITE, 
MAP_SHARED, m_fd, (target & ~MAP_MA
   // Our GPIO pointer valid?
   if (gpio >0) {
   // MICON detect bit please
   gpio[GPP_DATA_IN_POL_REG] |= MICON;
   // Clear MICON interrupt BIT
   gpio[GPP_INT_CAUSE_REG] &= ~MICON;
   }
   }
#else
#warning "Button events via serial control"
#endif
}

src:linux changelog:

linux (4.8.4-1~exp1) experimental; urgency=medium

[...]

 [ Ben Hutchings ]
 * [arm*] Enable STRICT_DEVMEM
 * [arm*,powerpc*,s390x,x86] Enable IO_STRICT_DEVMEM.  This breaks dosemu and
   some old graphics drivers, and can be reverted using the kernel parameter:
   iomem=relaxed

This is somewhat outside my area of expertise. Help would be welcome.

Bug#845817: optipng FTCBFS: uses the build architecture compiler

Source: optipng
Version: 0.7.6-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

optipng fails to cross build from source, because it uses the build
architecture compiler. Simply setting up a CC environment variable
pointing to a triplet-prefixed compiler is sufficient for letting the
handcrafted ./configure pick it up and properly cross compile optipng.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru optipng-0.7.6/debian/changelog 
optipng-0.7.6/debian/changelog
--- optipng-0.7.6/debian/changelog  2016-04-08 23:13:43.0 +0200
+++ optipng-0.7.6/debian/changelog  2016-11-26 22:35:46.0 +0100
@@ -1,3 +1,10 @@
+optipng (0.7.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export triplet-prefixed CC (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 26 Nov 2016 22:35:46 +0100
+
 optipng (0.7.6-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru optipng-0.7.6/debian/rules optipng-0.7.6/debian/rules
--- optipng-0.7.6/debian/rules  2016-04-08 22:43:41.0 +0200
+++ optipng-0.7.6/debian/rules  2016-11-26 22:35:45.0 +0100
@@ -1,6 +1,11 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
+export CC
 
 override_dh_auto_configure:
./configure -prefix=/usr -mandir=/usr/share/man -with-system-libs

Bug#845816: btrfs-progs FTCBFS: configure.ac uses plain pkg-config without $ac_tool_prefix

Source: btrfs-progs
Version: 4.7.3-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

btrfs-progs fails to cross build from source, because its configure.ac
calls into plain pkg-config even though it sets up a correct $PKG_CONFIG
by calling into PKG_PROG_PKG_CONFIG. Replacing those calls with
$PKG_CONFIG (and regenerating configure) makes cross builds succeed.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru btrfs-progs-4.7.3/debian/changelog 
btrfs-progs-4.7.3/debian/changelog
--- btrfs-progs-4.7.3/debian/changelog  2016-09-22 15:48:05.0 +0200
+++ btrfs-progs-4.7.3/debian/changelog  2016-11-26 22:24:49.0 +0100
@@ -1,3 +1,11 @@
+btrfs-progs (4.7.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: cross.patch: Indirect pkg-config invocations through
+$PKG_CONFIG and autoreconf (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 26 Nov 2016 22:24:49 +0100
+
 btrfs-progs (4.7.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru btrfs-progs-4.7.3/debian/control 
btrfs-progs-4.7.3/debian/control
--- btrfs-progs-4.7.3/debian/control2016-09-22 15:46:59.0 +0200
+++ btrfs-progs-4.7.3/debian/control2016-11-26 22:24:49.0 +0100
@@ -3,6 +3,7 @@
 Priority: optional
 Maintainer: Dimitri John Ledkov 
 Build-Depends: debhelper (>= 9),
+   dh-autoreconf,
e2fslibs-dev,
pkg-config,
libacl1-dev,
diff --minimal -Nru btrfs-progs-4.7.3/debian/patches/cross.patch 
btrfs-progs-4.7.3/debian/patches/cross.patch
--- btrfs-progs-4.7.3/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ btrfs-progs-4.7.3/debian/patches/cross.patch2016-11-26 
22:24:45.0 +0100
@@ -0,0 +1,32 @@
+From: Helmut Grohne 
+Subject: use PKG_PROG_PKG_CONFIG correctly
+
+Using $PKG_CONFIG allows PKG_PROG_PKG_CONFIG to add $ac_tool_prefix which is
+crucial for cross compilation.
+
+Index: btrfs-progs-4.7.3/configure.ac
+===
+--- btrfs-progs-4.7.3.orig/configure.ac
 btrfs-progs-4.7.3/configure.ac
+@@ -55,8 +55,8 @@
+ dnl Calls pkg-config --static
+ dnl
+ AC_DEFUN([PKG_STATIC], [
+-  if AC_RUN_LOG([pkg-config --exists --print-errors "$2"]); then
+-$1=`pkg-config --libs --static "$2"`
++  if AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$2"]); then
++$1=`$PKG_CONFIG --libs --static "$2"`
+ AC_SUBST([$1])
+   else
+ AC_MSG_ERROR([pkg-config description of $2, needed for static build, is 
not available])
+@@ -165,8 +165,8 @@
+ # Our udev rule gives us the friendly dm names but isn't required (or valid)
+ # on earlier releases.
+ UDEVDIR=
+-if pkg-config udev --atleast-version 190; then
+-  UDEVDIR="$(pkg-config udev --variable=udevdir)"
++if $PKG_CONFIG udev --atleast-version 190; then
++  UDEVDIR="$($PKG_CONFIG udev --variable=udevdir)"
+ fi
+ AC_SUBST(UDEVDIR)
+ 
diff --minimal -Nru btrfs-progs-4.7.3/debian/patches/series 
btrfs-progs-4.7.3/debian/patches/series
--- btrfs-progs-4.7.3/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ btrfs-progs-4.7.3/debian/patches/series 2016-11-26 22:23:18.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru btrfs-progs-4.7.3/debian/rules 
btrfs-progs-4.7.3/debian/rules
--- btrfs-progs-4.7.3/debian/rules  2016-09-22 15:46:59.0 +0200
+++ btrfs-progs-4.7.3/debian/rules  2016-11-26 22:24:49.0 +0100
@@ -13,7 +13,10 @@
 CFLAGS := $(patsubst -O2,-Os,$(CFLAGS))
 
 %:
-   dh ${@} --parallel
+   dh ${@} --parallel --with=autoreconf
+
+override_dh_autoreconf:
+   dh_autoreconf ./autogen.sh
 
 override_dh_auto_configure:
dh_auto_configure -- --bindir=/bin

Bug#845815: efibootmgr FTCBFS: uses build architecture pkg-config

Source: efibootmgr
Version: 14-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

efibootmgr fails to cross build from source, because it uses the build
architecture pkg-config and thus fails finding efivar.h. The cause is
that debhelper simply passes cross compilers for CC and CXX, but the
build system of efibootmgr expects setting CROSS_COMPILE instead. Thus
the attached patch opts out of dh_auto_build and explicitly sets up
CROSS_COMPILE. Please consider applying it.

Helmut
diff --minimal -Nru efibootmgr-14/debian/changelog 
efibootmgr-14/debian/changelog
--- efibootmgr-14/debian/changelog  2016-09-29 17:39:14.0 +0200
+++ efibootmgr-14/debian/changelog  2016-11-26 22:10:56.0 +0100
@@ -1,3 +1,10 @@
+efibootmgr (14-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CROSS_COMPILE instead of overriding CC (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 26 Nov 2016 22:10:56 +0100
+
 efibootmgr (14-1) unstable; urgency=medium
 
   * New upstream version (14)
diff --minimal -Nru efibootmgr-14/debian/rules efibootmgr-14/debian/rules
--- efibootmgr-14/debian/rules  2016-09-29 17:39:14.0 +0200
+++ efibootmgr-14/debian/rules  2016-11-26 22:10:56.0 +0100
@@ -2,12 +2,17 @@
 # rules file for the efibootmgr package, requires debhelper / dh
 # copyright 2012 by Bdale Garbee, GPLv2 or later
 
+include /usr/share/dpkg/architecture.mk
+
 export DH_VERBOSE=1
 export DH_OPTIONS=-v
 
 %:
dh $@
 
+override_dh_auto_build:
+   CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)- $(MAKE)
+
 # upstream build installs into /usr/sbin ignoring target directory;
 # since the install step is not actually needed just skip it
 override_dh_auto_install:

Bug#845814: portmidi FTCBFS: uses build architecture toolchain

Source: portmidi
Version: 1:217-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

portmidi fails to cross build from source, because it uses the build
architecture toolchain. Switching the explicit cmake and make
invocations to dh_auto_* solves this problem, because debhelper's cmake
build system knows how to cross compile. Please consider applying the
attached patch. I note that it also switches portmidi to out-of-tree
builds.

Helmut
diff --minimal -Nru portmidi-217/debian/changelog portmidi-217/debian/changelog
--- portmidi-217/debian/changelog   2016-11-14 18:02:24.0 +0100
+++ portmidi-217/debian/changelog   2016-11-26 21:47:49.0 +0100
@@ -1,3 +1,10 @@
+portmidi (1:217-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_* pass cross tools (closes: #-1)
+
+ -- Helmut Grohne   Sat, 26 Nov 2016 21:47:49 +0100
+
 portmidi (1:217-4) unstable; urgency=medium
 
   * debian/control: switch Architecture to linux-any (closes: #654187)
diff --minimal -Nru portmidi-217/debian/rules portmidi-217/debian/rules
--- portmidi-217/debian/rules   2016-11-14 17:58:26.0 +0100
+++ portmidi-217/debian/rules   2016-11-26 21:47:47.0 +0100
@@ -9,7 +9,7 @@
dh $@
 
 override_dh_auto_configure:
-   cmake \
+   dh_auto_configure -- \
 -DCMAKE_INSTALL_PREFIX=/usr \
 -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY=$(CURDIR)/Release \
 -DCMAKE_BUILD_TYPE=Release \
@@ -19,7 +19,7 @@
 $(CURDIR)
 
 override_dh_auto_build:
-   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp VERBOSE=1
+   dh_auto_build -- DESTDIR=$(CURDIR)/debian/tmp VERBOSE=1
 
 override_dh_auto_clean:
[ ! -f Makefile ] || make clean VERBOSE=1
@@ -31,7 +31,7 @@
 override_dh_auto_install:
# do not ship executables c files
chmod a-x $(CURDIR)/pm_test/*.c $(CURDIR)/pm_common/*.h
-   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install VERBOSE=1
+   dh_auto_install -- DESTDIR=$(CURDIR)/debian/tmp install VERBOSE=1
dh_install --sourcedir=$(CURDIR)/debian/tmp
 
 override_dh_compress:

Bug#845753: Treescape fails to build on i386 and armhf architecture

2016-11-26 Thread Andreas Tille

Hi,

in the Debian bug tracking system you can find a bug report about the
build failure:

https://bugs.debian.org/845753

The build log for i386 says:


** preparing package for lazy loading
Creating a generic function for 'toJSON' from package 'jsonlite' in package 
'googleVis'
Warning in rgl.init(initValue, onlyNULL) :
  RGL: unable to open X11 display
Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE
Error: segfault from C stack overflow


I admit I have no idea how to track this down.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*

2016-11-26 Thread Cyril Brulebois

Colin Watson  (2016-11-26):
> Yep, as Thomas said, this changed back to the original state in
> 2.02~beta3.  I think that in fact allows us to close #741656 if you also
> revert your previous workaround in d-i, but please confirm.  Compare:
> 
>   
> https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=496cca85259c77b5fc8ad39a9064c83c3a39b7a6
> 
> (Sorry, I forgot that d-i had worked around this.)

(No worries.)

Yeah, a revert was what I had in mind, but I thought I'd double check
anyway. Just pushed it, triggered a build on falla and fischer, and
builds seem happier now. Thanks!

I think this bug report should be closed now?


KiBi.


signature.asc
Description: Digital signature

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)


On Sun, Nov 27, 2016 at 01:20:10AM +0900, Roger Shimizu wrote:

- start your device by kernel 4.3 first.
- confirm your have flash-kernel and linux-image-4.8.0-1-marvell installed.
- cp /usr/lib/linux-image-4.8.0-1-marvell/orion5x-kuroboxpro.dtb
/etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb
- flash-kernel --force 4.8.0-1-marvell


~ # chroot /target flash-kernel --force 4.8.0-1-marvell
DTB: orion5x-linkstation-lsgl.dtb
Installing /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb into 
/boot/dtbs/4.8.0-1-marvell/orion5x-linkstation-lsgl.dtb
Taking backup of orion5x-linkstation-lsgl.dtb.
Installing new orion5x-linkstation-lsgl.dtb.
Installing /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb into 
/boot/dtbs/4.8.0-1-marvell/orion5x-linkstation-lsgl.dtb
Taking backup of orion5x-linkstation-lsgl.dtb.
Installing new orion5x-linkstation-lsgl.dtb.
flash-kernel: installing version 4.8.0-1-marvell
flash-kernel: appending /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb to 
kernel
Generating kernel u-boot image... done.
Taking backup of uImage.buffalo.
Installing new uImage.buffalo.
Generating initramfs u-boot image... done.
Taking backup of initrd.buffalo.
Installing new initrd.buffalo.


- check the log of above command, it should use
/etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb for building
uImage.buffalo, the kernel image for booting
- reboot and see the result

If the above steps works for you, I can submit the above patch to
kernel upstream, and include it into Stretch release.
So I'm looking forward to your result. Thank you!


It booted! :)

Linux xenon 4.8.0-1-marvell #1 Debian 4.8.5-1 (2016-10-28) armv5tel GNU/Linux

Unfortunately dmesg and kern.log are flooded with messages like:

[  161.781360] Bad eraseblock 32764 at 0x0001fff0
[  161.786261] Bad eraseblock 32765 at 0x0001fff4
[  161.791159] Bad eraseblock 32766 at 0x0001fff8
[  161.796058] Bad eraseblock 32767 at 0x0001fffc

and boot takes a very long time due to logging all these messages. I 
suppose that's a side-effect of using the kurobox-pro dtb - guessing it 
has a different flash layout?


Anyway, the change to nr-ports=2 looks good!

Tested-by: Ryan Tandy 

Thanks!

Bug#845690: Same problem here!

2016-11-26 Thread Eric Valette

On Sat, 26 Nov 2016 21:50:37 +0100 Eric Valette  
wrote:

Screwed up my NAS updating the kernel. Kernel panic just after init. gcc
: 6.2.1-1  kernel = upstream 4.4.35

reverting to my own compiled 4.4.33 fixed the problem.



Ooops gcc= 6.2.1-5 and kernel is x86-64

-- eric

Bug#845813: libnet-trac-perl: uses deprecated Any::Moose

Package: libnet-trac-perl
Version: 0.16-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  $ perl -we 'use Net::Trac'
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Data/AMF.pm line 3.

There are no reverse dependencies in Debian.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845690: Same problem here!

2016-11-26 Thread Eric Valette

Screwed up my NAS updating the kernel. Kernel panic just after init. gcc 
: 6.2.1-1  kernel = upstream 4.4.35


reverting to my own compiled 4.4.33 fixed the problem.

--eric

Bug#845752: ShortRead fails do build on armel architecture with C stack overflow

2016-11-26 Thread Andreas Tille

Hi,

the Debian bug tracker contains a bug report that ShortRead fails to
build on armel architecture (while any other Debian architecture seems
to be fine).  Please have a look here:

   https://bugs.debian.org/845752

I admit I have no idea how to track this issue down.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#845812: libdata-amf-perl: uses deprecated Any::Moose

Package: libdata-amf-perl
Version: 0.09+dfsg-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  $ perl -we 'use Data::AMF'
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Data/AMF.pm line 3.

The only reverse dependency in Debian is the get-flash-videos package.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845811: libwww-nicovideo-download-perl: uses deprecated Any::Moose

Package: libwww-nicovideo-download-perl
Version: 0.06-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  $ perl -we 'use WWW::NicoVideo::Download'
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/WWW/NicoVideo/Download.pm line 11.

The package fails its autopkgtest checks due to this; see

  
https://ci.debian.net/packages/libw/libwww-nicovideo-download-perl/unstable/amd64/

There are no reverse dependencies in Debian.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845810: libwebservice-solr-perl: uses deprecated Any::Moose

Package: libwebservice-solr-perl
Version: 0.23-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=96977

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  $ perl -we 'use WebService::Solr'
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/WebService/Solr.pm line 3.

The package fails its autopkgtest checks due to this; see

  http://ci.debian.net/packages/libw/libwebservice-solr-perl/unstable/amd64/

There are no reverse dependencies in Debian.

The upstream ticket links to a pull request at

 https://github.com/bricas/webservice-solr/pull/16

but the discussion there seems to have died out in March.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845518: protobuf-c-compiler cannot be executed during cross compilation

2016-11-26 Thread Robert Edmonds

Helmut Grohne wrote:
> Package: protobuf-c-compiler
> Version: 1.2.1-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:collectd src:criu src:dnstap-ldns src:libgadu 
> src:ocserv src:php-pinba src:riemann-c-client src:unbound
> 
> protobuf-c-compiler is a build tool that is quite similar to flex and
> bison in some aspects: You run it during a build and use the resulting C
> source code together with a library in your application. When cross
> compiling this means that you need a build architecture
> protobuf-c-compiler and the corresponding host architecture library.
> What currently happens in practise is that you get the host architecture
> protofbuf-c-compiler. Thus running it fails.

Hi, Helmut:

Thanks for the detailed write-up in this bug report. I think I prefer
your first solution the best, because if I understand the second
solution correctly, it causes the libprotobuf-c-dev package to depend on
the package which provides the protobuf-c compiler, and at least in
theory the protobuf-c library has some functionality which is usable
without the compiler. I will upload a new protobuf-c package with your
patch shortly.

Some comments on the dependency chain below.

> Unfortunately, protobuf-c-compiler is something we need for bringing up
> new architectures. The dependency chain is wicked. login is essential
> and built from shadow. shadow Build-Depends on libaudit-dev, which is
> built from audit. audit Build-Depends on libprelude-dev, which is built
> from libprelude. libprelude Build-Depends on libgnutls28-dev, which is
> built from gnutls28. Since very recently gnutls28 Build-Depends on
> libunbound-dev, which is built from unbound. unbound Build-Depends on
> protobuf-c-compiler. See? Wicked.

If this were the end of the dependency chain, then OK, we can upload a
fixed protobuf-c and that's it. But it's not the end of the chain;
protobuf-c build-depends on src:protobuf, and protobuf has a long
history of being difficult to get building on all architectures at the
same time (for instance, just have a look at the current buildd logs).
Should we (Debian) look at how to get protobuf out of the dependency
chain for bringing up new architectures?

I'm at least partially responsible for this chain. Unbound build-depends
on src:protobuf-c because of an optional feature which I turned on in
the unbound build (--enable-dnstap) that requires protobuf-c. I also
implemented changes in unbound (#828699) that allowed gnutls28 to
build-depend on libunbound-dev for DANE support. Both of these are nice
features to have and there are at least some users who would be
disappointed if they were removed.

Looking farther up the chain I see the audit → libprelude-dev
build-dependency is due to --with-prelude being enabled in the audit
build. Perhaps this feature could be targeted, similarly to #840262? I
also wonder if the audisp-prelude plugin [0] could be split from
src:audit and built by a separate source package. (It looks like the
upstream developers prefer a monolithic repository, though.)

[0] 
https://github.com/linux-audit/audit-userspace/tree/master/audisp/plugins/prelude

-- 
Robert Edmonds
edmo...@debian.org

Bug#845809: libtext-clip-perl: uses deprecated Any::Moose

Package: libtext-clip-perl
Version: 0.14-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=105101

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

 $ perl -we 'use Text::Clip'
 Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Text/Clip.pm line 8.

The package fails its autopkgtest checks due to this; see

  https://ci.debian.net/packages/libt/libtext-clip-perl/unstable/amd64/

The only reverse dependency is libterm-editoredit-perl, which also
use Any::Moose (see #845807).

The upstream ticket has had no comment from the maintainer in 1.5 years.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845808: libtest-cukes-perl: uses deprecated Any::Moose

Package: libtest-cukes-perl
Version: 0.10-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  $ perl -we 'use Test::Cukes'
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Test/Cukes/Feature.pm line 2.

There are no reverse depencies in Debian.

The package fails its autopkgtest checks due to this; see

  http://ci.debian.net/packages/libt/libtest-cukes-perl/unstable/amd64/

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845807: libterm-editoredit-perl: uses deprecated Any::Moose

Package: libterm-editoredit-perl
Version: 0.16-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=104918
Control: affects -1 pinto

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

 $ perl -we 'use Term::EditorEdit'
 Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Term/EditorEdit.pm line 13.

The only reverse dependency is pinto, which now warns similarly.
Both packages fail their autopkgtest checks due to this; see

  http://ci.debian.net/packages/libt/libterm-editoredit-perl/unstable/amd64/
  https://ci.debian.net/packages/p/pinto/unstable/amd64/

The upstream ticket has had no comment from the maintainer in 1.5 years.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845806: librdf-crypt-perl: uses deprecated Any::Moose

Package: librdf-crypt-perl
Version: 0.002-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest rm-candidate
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=104929

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

 $ perl -we 'use RDF::Crypt'
 Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/RDF/Crypt/Verifier.pm line 4.

This makes the package fail its autopkgtest checks, see

  http://ci.debian.net/packages/libr/librdf-crypt-perl/unstable/amd64/

The upstream ticket has had no comment from the maintainer in 1.5 years.
There are no reverse dependencies in Debian, so I'm tagging this as a
possible candidate for removal.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845804: libpath-dispatcher-perl: uses deprecated Any::Moose

Package: libpath-dispatcher-perl
Version: 1.05-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest rm-candidate
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=83955
Control: affects -1 libpath-dispatcher-declarative-perl

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

 $ perl -we 'use Path::Dispatcher'
 Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/Path/Dispatcher.pm line 2.

This makes the libpath-dispatcher-declarative-perl package fail its
autopkgtest checks, see

  
http://ci.debian.net/packages/libp/libpath-dispatcher-declarative-perl/unstable/amd64/

The upstream ticket is 3.5 years old, with no comment from
the maintainer.  There are no reverse dependencies besides
libpath-dispatcher-declarative-perl; they seem to have been in the
archive to support the prophet package, which was recently removed from
sid (see #845541). So these two packages seem like removal candidates too.

There's a thread related to Any::Moose around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and it's not clear yet if the deprecation warning should be disabled
one way or another. The primary bug of using Any::Moose still remains
of course.
-- 
Niko Tyni   nt...@debian.org

Bug#845803: src:gpgme1.0: please consider reducing priority of -dev packages

Package: src:gpgme1.0
Version: 1.8.0-2
Severity: normal

Hi,

Today I noticed that "aptitude install ~pstandard" pulls in many more 
packages than it used to. A significant part of this seems to be 
transitive Depends of libgpgmepp-dev, via qtbase5-dev.

It looks like Priority: standard is set for the entire gpgme1.0 source 
package (all binaries). Please consider reducing the priority of the 
binary packages that are not dependencies of other Priority: standard 
packages (at least the -dev and -doc packages).

Please let me know if I should report this instead as an override 
request against ftp.debian.org.

thanks,
Ryan

Bug#845805: ITP: django-hstore -- Module for Django that integrates the PostgreSQL hstore extension

2016-11-26 Thread Scott Kitterman

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-hstore
  Version : 1.5~alpha~git20161126
  Upstream Author : Djangonauts Organization 
* URL : https://github.com/djangonauts/django-hstore
* License : MIT/Expat
  Programming Lang: Python
  Description : Module for Django that integrates the PostgreSQL hstore 
extension

 django-hstore is a niche library which integrates the hstore extension of
 PostgreSQL into Django.
 .
 HStore brings the power of NoSQL key/value stores into PostgreSQL, giving us
 the advantage of flexibility and performance without renouncing to the
 robustness of SQL databases.
 .
 Features
 .
   * Postgis compatibility.
   * Nice admin widgets.
   * Possibility to define a schema and use the standard django fields

I intend to maintain this in the Debian Python Modules Team.

I'm uploading a git snapshot as the most recent release is not compatible
with Django 1.10.  I expect a final release well before our freeze.

Bug#845802: padsp 32 bits application issue on 64 bits system

2016-11-26 Thread Nicolas DEFFAYET

Package: pulseaudio-utils
Version: 5.0-13
Severity: normal


Issue
-

padsp provided in pulseaudio-utils:amd64 support only 64 bits
applications.

32 bits applications run on 64 bits system (multiarch) fail with:
ERROR: ld.so: object
'/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsedsp.so' from LD_PRELOAD
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.


Where is the bug ?
--

The bug is due to the fact padsp provided in pulseaudio-utils:amd64
always load 64 bit version of libpulsedsp.so. This can't work for 32
bits applications as they require 32 bit version of libpulsedsp.so.


How fix the issue ?
---

# cp /usr/bin/padsp /usr/bin/padsp32
# sed -i 's/\/usr\/lib\/x86_64-linux-gnu\/pulseaudio\/libpulsedsp.so/ =>
\/usr\/lib\/i386-linux-gnu\/pulseaudio
\/libpulsedsp.so/g' /usr/bin/padsp32

/usr/bin/padsp32 must be provided in pulseaudio-utils:amd64 in addition
of /usr/bin/padsp.

Expected usage is:
/usr/bin/padsp 
/usr/bin/padsp32 


-- 
Nicolas DEFFAYET

Bug#838437: bash: (readline) regression in the behaviour of ^W in vi-mode

2016-11-26 Thread Gian Piero Carrubba


Package: bash
Version: 4.4-2
Followup-For: Bug #838437

According to [0], as a workaround you can re-enable the 4.3 behaviour by 
putting the following lines in your $HOME/.inputrc file (can confirm it 
works on my boxes):


set bind-tty-special-chars Off
set keymap vi-insert
"\C-w": unix-word-rubout

The downside is, obviously, the loss of the POSIX semantics for word 
boundaries.


Ciao,
Gian Piero.

[0] http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00024.html

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

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

Versions of packages bash depends on:
ii  base-files   9.6
ii  dash 0.5.8-2.3
ii  debianutils  4.8.1
ii  libc62.24-7
ii  libtinfo56.0+20160917-1

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

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#787956: raising the severity, prevents usage of the multilib packages

2016-11-26 Thread Matthias Klose

On 26.11.2016 20:35, Mark Brown wrote:
> On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
>> On 26.11.2016 19:42, Mark Brown wrote:
>>> On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:
> 
>>> Please allow at least a little time for a response, I've no real idea
>>> what you're even asking for here.
> 
>> well, I asked you in private before, without getting replies on all messages 
>> and
>> proposals.
> 
> You sent me a mail last week asking for some additional multilib
> packages for x32 ABI which seemed a bit strange at this point in the
> release cycle and not that urgent as a new ABI would be at most
> wishlist.  I'd been intending to have a look to try to work out what's
> going on with x32 over the weekend.  I'm having a hard time relating
> that to what you're talking about here though I do see you mentioned
> that this was for "libgphobos (gdc runtime)" in both.
> 
>> This exactly is the correct issue, not "some random bug".
> 
> I'm afraid I'm still unclear what you are trying to do or why.

well, you removed the example from your reply and didn't comment on it.

> This is
> a bug about trying to use the lib32z1-dev package, your private mails
> were about adding x32 multilib packages and I'm really confused about
> how either of these things relates to the shared libgphobos you keep
> mentioning.  The proposed changes below don't have anything to do with
> x32 either so I'm just completely confused now.

I'm filing a separate issue for the x32 multilibs.

> Can you please provide a clear, from first steps description of what's
> needed and why?

again, here is the example which you removed:

$ cat tst.c
#include 
$ gcc -m32 -c tst.c
In file included from tst.c:1:0:
/usr/include/zlib.h:34:19: fatal error: zconf.h: No such file or directory
 #include "zconf.h"
   ^
compilation terminated.

The example fails because the zconf.h header is not found. You can see the list
of the standard include paths when calling gcc with the -v option.

>> attaching the diff for the proposed changes
> 
> Please do not upload this, I will be back at home on Monday and can do
> an upload then and...
> 
>> +  * Non-maintainer upload.
>> +  * Install the zconf.h header file for the multilib packages. Closes: 
>> #787956.
>> +  * Use the target prefixed ar, available since binutils 2.26.
>> +  * Run dh_makeshlibs for the 64bit multilib library.
>> +  * Add ${misc:Depends} to zlib1g-dbg's dependencies.
>> +  * Support nobiarch build profile (Johannes Schauer). Closes: #709623.
> 
> ...this clearly isn't just fixing the bug and there are a bunch of
> additional changes not mentioned in the changelog. 

If I forgot some, sorry about these.

> I need to investigate what's going on here as I'm unconvinced that this
> doesn't introduce further problems (will this break multiarch for
> example, I appear to be able to build with -m32...).  This might be a
> lot clearer with split out incremental patches and really seems
> inappropriate for a zero notice NMU.
> 
>> -Standards-Version: 3.9.4
>> +Standards-Version: 3.9.8
> 
> If you're making changes like this they ought to be mentioned in the
> changelog.
> 
>> -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) 
>> [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc 
>> ppc64 s390 sparc s390x], dpkg-dev (>= 1.16.1)
>> +Build-Depends: debhelper (>= 9), gcc-multilib [amd64 i386 kfreebsd-amd64 
>> mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)
> 
> Not sure why the debhelper dependency got changed or why we dropped the
> binutils dependency.

The binutils dependency is not necessary anymore. even oldstable has 2.22.  The
profile change is to fix issue #709623 (also mentioned in the changelog).

Bug#845801: RM: r-bioc-shortread [armel] -- ROM; Fails to build on armel

2016-11-26 Thread Andreas Tille

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

please remove r-bioc-shortread for armel since it fails to build there.

Thanks for your work as ftpmaster

Andreas.

Bug#828800: verbiste: FTBFS in testing (Only can be included directly)

2016-11-26 Thread Sébastien Villemot

Control: tags -1 + patch pending

Le jeudi 24 novembre 2016 à 11:30 +0100, Sébastien Villemot a écrit :
> Le mardi 28 juin 2016 à 02:46 +0200, Tomasz Buchert a écrit :
> > On 27/06/16 23:52, Santiago Vila wrote:
> > > Package: src:verbiste
> > > Version: 0.1.43-1
> > > User: reproducible-bui...@lists.alioth.debian.org
> > > Usertags: ftbfs
> > > Severity: serious
> > > 
> > > Dear maintainer:
> > > 
> > > This package currently fails to build in stretch:
> > This bug is related to gtk2 vs. gtk3 API. I'll work on it during
> > debconf.
> 
> Any news on this? There is not much time left to fix it if we want
> verbiste to be part of stretch (it has been removed from testing, and
> it
> must be back there before Jan 5).
> 
> If you think this is the right solution, I can do an NMU where the
> MATE
> applet is removed.

I have uploaded to DELAYED/5 a NMU that fixes this issue, by removing
the MATE applet. The debdiff is attached. Don't hesitate to tell me if
you disagree with this NMU.

Best,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

diff -Nru verbiste-0.1.43/debian/changelog verbiste-0.1.43/debian/changelog
--- verbiste-0.1.43/debian/changelog	2016-03-25 06:52:24.0 +0100
+++ verbiste-0.1.43/debian/changelog	2016-11-26 20:37:56.0 +0100
@@ -1,3 +1,10 @@
+verbiste (0.1.43-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop verbiste-mate-applet package, fixes FTBFS. (Closes: #828800)
+
+ -- Sébastien Villemot   Sat, 26 Nov 2016 20:37:56 +0100
+
 verbiste (0.1.43-1) unstable; urgency=medium
 
   * Imported Upstream version 0.1.43
diff -Nru verbiste-0.1.43/debian/control verbiste-0.1.43/debian/control
--- verbiste-0.1.43/debian/control	2016-03-25 06:52:24.0 +0100
+++ verbiste-0.1.43/debian/control	2016-11-26 20:32:20.0 +0100
@@ -5,7 +5,6 @@
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
libgnomeui-dev,
-   libmate-panel-applet-dev,
libxml-parser-perl,
locales,
pkg-config
@@ -38,20 +37,6 @@
  .
  This package contains a GNOME graphical interface.
 
-Package: verbiste-mate-applet
-Section: x11
-Architecture: any
-Depends: libmate-panel-applet-4-1,
- libverbiste-0.1-0v5 (= ${binary:Version}),
- verbiste-gnome (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends}
-Description: French and Italian conjugator - MATE Panel applet
- Verbiste is a program that gives the complete conjugation for French and
- Italian verbs. The knowledge base contains over 6800 verbs.
- .
- This package contains a MATE panel applet.
-
 Package: verbiste-el
 Section: lisp
 Architecture: all
diff -Nru verbiste-0.1.43/debian/rules verbiste-0.1.43/debian/rules
--- verbiste-0.1.43/debian/rules	2016-03-25 06:52:24.0 +0100
+++ verbiste-0.1.43/debian/rules	2016-11-26 20:32:32.0 +0100
@@ -4,7 +4,7 @@
 CPPFLAGS += -DMATELOCALEDIR=\"/usr/share/locale\"
 
 override_dh_auto_configure:
-	dh_auto_configure -- --with-gtk-app --with-gnome-app --with-mate-applet --libexecdir=/usr/lib/mate-applets
+	dh_auto_configure -- --with-gtk-app --with-gnome-app
 
 override_dh_installdocs:
 	dh_installdocs -A README LISEZMOI HACKING
diff -Nru verbiste-0.1.43/debian/verbiste-mate-applet.install verbiste-0.1.43/debian/verbiste-mate-applet.install
--- verbiste-0.1.43/debian/verbiste-mate-applet.install	2016-03-25 06:52:24.0 +0100
+++ verbiste-0.1.43/debian/verbiste-mate-applet.install	1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-debian/tmp/usr/lib/mate-applets/verbiste-mate-applet
-debian/tmp/usr/share/dbus-1/services/org.mate.panel.applet.VerbisteAppletFactory.service
-debian/tmp/usr/share/mate-panel/applets/org.mate.applets.VerbisteApplet.mate-panel-applet
diff -Nru verbiste-0.1.43/debian/verbiste-mate-applet.lintian-overrides verbiste-0.1.43/debian/verbiste-mate-applet.lintian-overrides
--- verbiste-0.1.43/debian/verbiste-mate-applet.lintian-overrides	2016-03-25 06:52:24.0 +0100
+++ verbiste-0.1.43/debian/verbiste-mate-applet.lintian-overrides	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# False positive
-verbiste-mate-applet: hardening-no-fortify-functions usr/lib/mate-applets/verbiste-mate-applet


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

Bug#834722: dnsmasq-base: dnsmasq does not forward queries after recieving servers via DBus second time

2016-11-26 Thread Vincent Bernat

 ❦ 19 novembre 2016 09:44 +0100, Vincent Bernat  :

>>> > Here are some pointers:
>>> >
>>> >  https://bugzilla.redhat.com/show_bug.cgi?id=1367772
>>> >  
>>> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
>>> >
>>> > I am testing the above patch myself. Will tell if it works.
>>> 
>>> For me, it fixes the problem.
>>
>> Sorry to "me too" - but me too. :)
>>
>> I wonder if this can be uploaded, please? Note that there's a followup
>> crash fix:
>>
>>   
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d
>
> Thanks for pointing this out. I was looking at why dnsmasq was now
> segfaulting since a few days. I'll try with this additional patch for a
> few days, then I'll do a NMU to a delayed queue.

I have uploaded a NMU with the attached debdiff to DELAYED/5.

diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog
--- dnsmasq-2.76/debian/changelog
+++ dnsmasq-2.76/debian/changelog
@@ -1,3 +1,13 @@
+dnsmasq (2.76-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add two upstream patches to fix binding to an interface being
+destroyed and recreated. Closes: #834722.
+  + 2675f2061525bc954be14988d64384b74aa7bf8b
+  + 16800ea072dd0cdf14d951c4bb8d2808b3dfe53d
+
+ -- Vincent Bernat   Sat, 26 Nov 2016 20:15:34 +0100
+
 dnsmasq (2.76-4) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- dnsmasq-2.76.orig/src/dnsmasq.h
+++ dnsmasq-2.76/src/dnsmasq.h
@@ -487,6 +487,7 @@
   int fd;
   union mysockaddr source_addr;
   char interface[IF_NAMESIZE+1];
+  unsigned int ifindex, used;
   struct serverfd *next;
 };
 
only in patch2:
unchanged:
--- dnsmasq-2.76.orig/src/network.c
+++ dnsmasq-2.76/src/network.c
@@ -1204,6 +1204,7 @@
 static struct serverfd *allocate_sfd(union mysockaddr *addr, char *intname)
 {
   struct serverfd *sfd;
+  unsigned int ifindex = 0;
   int errsave;
 
   /* when using random ports, servers which would otherwise use
@@ -1224,11 +1225,15 @@
 	return NULL;
 #endif
 }
+
+  if (intname && strlen(intname) != 0)
+ifindex = if_nametoindex(intname); /* index == 0 when not binding to an interface */
   
   /* may have a suitable one already */
   for (sfd = daemon->sfds; sfd; sfd = sfd->next )
 if (sockaddr_isequal(>source_addr, addr) &&
-	strcmp(intname, sfd->interface) == 0)
+	strcmp(intname, sfd->interface) == 0 &&
+	ifindex == sfd->ifindex) 
   return sfd;
   
   /* need to make a new one. */
@@ -1250,11 +1255,13 @@
   errno = errsave;
   return NULL;
 }
-
+
   strcpy(sfd->interface, intname); 
   sfd->source_addr = *addr;
   sfd->next = daemon->sfds;
+  sfd->ifindex = ifindex;
   daemon->sfds = sfd;
+
   return sfd; 
 }
 
@@ -1429,12 +1436,16 @@
 {
   struct irec *iface;
   struct server *serv;
+  struct serverfd *sfd, *tmp, **up;
   int port = 0, count;
 
   /* interface may be new since startup */
   if (!option_bool(OPT_NOWILD))
 enumerate_interfaces(0);
   
+  for (sfd = daemon->sfds; sfd; sfd = sfd->next)
+sfd->used = 0;
+
 #ifdef HAVE_DNSSEC
  /* Disable DNSSEC validation when using server=/domain/ servers
 unless there's a configured trust anchor. */
@@ -1505,6 +1516,9 @@
 	  serv->flags |= SERV_MARK;
 	  continue;
 	}
+	  
+	  if (serv->sfd)
+	serv->sfd->used = 1;
 	}
   
   if (!(serv->flags & SERV_NO_REBIND) && !(serv->flags & SERV_LITERAL_ADDRESS))
@@ -1547,6 +1561,20 @@
   if (count - 1 > SERVERS_LOGGED)
 my_syslog(LOG_INFO, _("using %d more nameservers"), count - SERVERS_LOGGED - 1);
 
+  /* Remove unused sfds */
+  for (sfd = daemon->sfds, up = >sfds; sfd; sfd = tmp)
+{
+   tmp = sfd->next;
+   if (!sfd->used) 
+	{
+	  *up = sfd->next;
+	  close(sfd->fd);
+	  free(sfd);
+	} 
+  else
+	up = >next;
+}
+  
   cleanup_servers();
 }
 

-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64

2016-11-26 Thread Ben Hutchings

On Sat, 2016-11-26 at 16:54 +, Heinrich Schuchardt wrote:
> Package: flash-kernel
> Version: 3.71
> Severity: normal
> 
> Dear Maintainer,
> 
> I want to get the Hardkernel Odroid C2 supported by flash-kernel.
> 
> It is a 64bit system.
> 
> Unfortunately in file /usr/share/flash-kernel/functions the functions
> mkimage_kernel() and mkimage_initrd() both call mkimage with argument
> 
>  -A arm .
> 
> This is incorrect. On 64bit arm systems you have to use
> 
>  -A arm64 .
> 
> Otherwise neither u-boot nor the kernel can read the images.
> 
> I suggest to use `uname -m` to determine the architectue.
> If it is aarch64 use mkimage -A arm64.

I think it's currently possible to use flash-kernel:armhf on an arm64
system to build an armhf image, and this would break that.  Given that
flash-kernel is an arch-dependent package, I think it should use the
package architecture here instead of `uname -m`.

(But since flash-kernel doesn't contain any native code, I think it
wwould be even better to make it arch-independent and to specify the
machine architecture in each entry in db/all.db.)

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Bug#845750: postfix: Cleanup does not see the postfix-pcre.so.1.0.1 file (and probably others libraries)

2016-11-26 Thread Bartosz Rudnicki

It seems that this bug also occurs in the newest postfix 3.1.3-4 
version, from debian sid

Bug#787956: raising the severity, prevents usage of the multilib packages

2016-11-26 Thread Mark Brown

On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> On 26.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:

> > Please allow at least a little time for a response, I've no real idea
> > what you're even asking for here.

> well, I asked you in private before, without getting replies on all messages 
> and
> proposals.

You sent me a mail last week asking for some additional multilib
packages for x32 ABI which seemed a bit strange at this point in the
release cycle and not that urgent as a new ABI would be at most
wishlist.  I'd been intending to have a look to try to work out what's
going on with x32 over the weekend.  I'm having a hard time relating
that to what you're talking about here though I do see you mentioned
that this was for "libgphobos (gdc runtime)" in both.

> This exactly is the correct issue, not "some random bug".

I'm afraid I'm still unclear what you are trying to do or why.  This is
a bug about trying to use the lib32z1-dev package, your private mails
were about adding x32 multilib packages and I'm really confused about
how either of these things relates to the shared libgphobos you keep
mentioning.  The proposed changes below don't have anything to do with
x32 either so I'm just completely confused now.

Can you please provide a clear, from first steps description of what's
needed and why?

> attaching the diff for the proposed changes

Please do not upload this, I will be back at home on Monday and can do
an upload then and...

> +  * Non-maintainer upload.
> +  * Install the zconf.h header file for the multilib packages. Closes: 
> #787956.
> +  * Use the target prefixed ar, available since binutils 2.26.
> +  * Run dh_makeshlibs for the 64bit multilib library.
> +  * Add ${misc:Depends} to zlib1g-dbg's dependencies.
> +  * Support nobiarch build profile (Johannes Schauer). Closes: #709623.

...this clearly isn't just fixing the bug and there are a bunch of
additional changes not mentioned in the changelog.  

I need to investigate what's going on here as I'm unconvinced that this
doesn't introduce further problems (will this break multiarch for
example, I appear to be able to build with -m32...).  This might be a
lot clearer with split out incremental patches and really seems
inappropriate for a zero notice NMU.

> -Standards-Version: 3.9.4
> +Standards-Version: 3.9.8

If you're making changes like this they ought to be mentioned in the
changelog.

> -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) 
> [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc 
> ppc64 s390 sparc s390x], dpkg-dev (>= 1.16.1)
> +Build-Depends: debhelper (>= 9), gcc-multilib [amd64 i386 kfreebsd-amd64 
> mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)

Not sure why the debhelper dependency got changed or why we dropped the
binutils dependency.

Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist

2016-11-26 Thread Steve M. Robbins

Thanks Adam + Aurelien,

On Saturday, November 26, 2016 3:11:21 PM CST Aurelien Jarno wrote:
> On 2016-11-26 11:02, Adam D. Barratt wrote:
> > On Sat, 2016-11-26 at 01:02 -0600, Steve M. Robbins wrote:

> > > I don't know how to make sense of these "breaks" versions.  libc6
> > > doesn't even have a revision -7.  Should both of those be
> > > "breaks ... != 2.24-6"?
> > 
> > -7 was uploaded a little over 10 hours ago. Looking at the dak log that
> > would make sense in terms of what you're seeing - the amd64 build of -7
> > made it into the 0152UTC dinstall by a few minutes, so would have been
> > available on mirrors when you filed this report, with the i386 build
> > being part of the subsequent 0752 dinstall.

Seems I was a victim of timing!   I checked the PTS when filing the bug and 
there was no trace of -7 that I could see.  All is well now.  

Thanks again,
-Steve


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

Bug#845800: libxtables12: Replaces/Breaks have the wrong direction in the relationship

2016-11-26 Thread Guillem Jover

Package: libxtables12
Version: 1.6.0+snapshot20161117-4
Severity: important
Tags: patch

Hi!

The problem with this package and libxtables11 not being co-installable
was introduced in the first snapshot version which did not get the
SONAME bumped for the package name. But older versions should still be
co-installable as they have different SONAMES. Change the direction
of the verioned dependencies to cover this.

In addition using a >= should be safe here as long as a libxtables11
is not reintroduced, for examples due to a reversion. But beware I've
not actually tested these changes.

Thanks,
Guillem
From 48c8719ee9944948a6ab40032d71ffcd7f8455e6 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 26 Nov 2016 20:19:32 +0100
Subject: [PATCH] debian: Fix libxtables12 Replaces and Breaks relationships

The problem with this package and libxtables11 not being co-installable
was introduced in the first snapshot version which did not get the
SONAME bumped for the package name. But older versions should still be
co-installable as they have different SONAMES. Change the direction
of the verioned dependencies to cover this.

In addition using a >= should be safe here as long as a libxtables11
is not reintroduced.
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index e5e2c00..0e71510 100644
--- a/debian/control
+++ b/debian/control
@@ -56,8 +56,8 @@ Architecture: linux-any
 Priority: optional
 Section: libs
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Replaces: iptables (<< 1.4.16.3-3), libxtables11 (<= 1.6.0+snapshot20161117-1)
-Breaks: iptables (<< 1.4.16.3-3), libxtables11 (<= 1.6.0+snapshot20161117-1)
+Replaces: iptables (<< 1.4.16.3-3), libxtables11 (>= 1.6.0+snapshot20161117-1)
+Breaks: iptables (<< 1.4.16.3-3), libxtables11 (>= 1.6.0+snapshot20161117-1)
 Description: netfilter xtables library
  The user-space interface to the Netfilter xtables kernel framework.
 
-- 
2.11.0.rc1.160.g51e66c2

Bug#840364: Raise severity of bug again ...