Bug#843726: spl-dkms: fails to build with grsecurity enabled kernel

[Alex Mestiashvili]

Package: spl-dkms
Version: 0.6.5.8-2~bpo8+2
Severity: normal

Dear Maintainer,
spl-dkms fails to build with grsecurity enabled kernel.
Not sure if this is a bug in spl or a grsec feature.
The kernel is available from jessie backports:

dpkg -l | grep grsec
ii  gradm2 3.0~201408301734-1
amd64Administration program for the grsecurity2 RBAC based ACL
system
ii  linux-grsec-base   10~bpo8+1
 all  Linux image base package, grsec featureset
ii  linux-headers-4.7.0-1-common-grsec 4.7.8-1+grsec201610161720+1~bpo8+1
amd64Common header files for Linux 4.7.0-1-grsec
ii  linux-headers-4.7.0-1-grsec-amd64  4.7.8-1+grsec201610161720+1~bpo8+1
amd64Header files for Linux 4.7.0-1-grsec-amd64
ii  linux-image-4.7.0-1-grsec-amd644.7.8-1+grsec201610161720+1~bpo8+1
amd64Linux 4.7 for 64-bit PCs, Grsecurity protection
ii  linux-image-grsec-amd6410~bpo8+1
 amd64Linux image meta-package, grsec featureset

uname -a
Linux nutch4 4.7.0-1-grsec-amd64 #1 SMP Debian
4.7.8-1+grsec201610161720+1~bpo8+1 (2016-10-20) x86_64 GNU/Linux

here is the configure output when I manually try to build the spl module:

dkms install -m spl -v  0.6.5.8

Running the pre_build script:
checking for gawk... gawk
checking metadata... META file
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static 

Bug#841163: [debian-mysql] Upload of MySQL 5.7.16 security update to unstable

[Lars Tangvald]

On 11/08/2016 10:53 PM, Dominic Hargreaves wrote:


Hi Lars,

Now uploaded.

Cheers,
Dominic.

Great, thanks!

--
Lars

Bug#823004: gplaycli: sensitive information in config file

[Matlink]

agree, but there is a potential big issue with providing default credentials : 
the google account will be subject to password change, and the more the package 
is used the more often this password will be changed. Password change means for 
me reset the password, update the default credentials and maybe update the 
Debian package. 
If someone found an alternate good solution ...

Le 9 novembre 2016 05:42:12 GMT+01:00, Paul Wise  a écrit :
>On Mon, 7 Nov 2016 19:26:57 +0100 Hans-Christoph Steiner wrote:
>
>> I think the best way forward for this issue is for the gplaycli
>> package to leave out the default credentials.
>
>This will make the package essentially useless.
>I suggest this bug report be closed wontfix.
>
>-- 
>bye,
>pabs
>
>https://wiki.debian.org/PaulWise

-- 
Matlink - sysadmin Matlink.fr

Bug#836324: tightvncserver: Typing gives wrong keys in some apps

[Ola Lundqvist]

Hi Matthew

Thank you for the information. It looks like it was a good decision to go
for tigervnc. Tigervnc have just recently been included in unstable and
testing and will be part of the next stable release.

I have the intention to remove both tightvnc and vnc4 due to the lack of
upstream development and go only for tigervnc. However I would like to know
more about reactions on tigervnc (bugs) before they are finally requested
for removal.

Best regards

// Ola

On 8 November 2016 at 17:24, Matthew Gabeler-Lee 
wrote:

> On Sat, 3 Sep 2016, Ola Lundqvist wrote:
>
> Also interesting that the problem goes away with vnc4server.
>>
>
> I just came across tigervnc which has the tight protocol support and does
> not suffer from this bug.
>
> The tigervnc website says it's based on the newer vnc4 branch of tightvnc
> that never got released, so this may be a bugfix in vnc4 that was not in
> the older tightvnc 1.3 code.
>
> What client software do you use?
>>
>
> I tried many, including vinagre, remmina, and the uber-basic vncviewer,
> all had exactly the same problem.
>
> 
>
> FWIW, since tigervnc does everything (for me) that tightvnc did, and
> doesn't have this bug, switching to that package functions as a "fix" for
> this for me, and I'm no longer concerned about tightvnc, esp. since it
> seems to be effectively unmaintained upstream, at least for open source
> linux packaging.
>
> --
> -Matt
> "Reality is that which, when you stop believing in it, doesn't go away".
> -- Philip K. Dick
> GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#843725: accerciser: Missing dependency to gir1.2-rsvg-2.0

[Michael Weghorn]

Package: accerciser
Version: 3.22.0-1
Severity: normal

Dear Maintainer,

when gir1.2-rsvg-2.0 is not installed and I try to start accerciser,
it crashes on start.

Console output:

~~~
$ accerciser 
/usr/bin/accerciser:48: PyGIWarning: Gtk was imported without specifying a 
version first. Use gi.require_version('Gtk', '3.0') before import to ensure 
that the right version gets loaded.
  from gi.repository import Gtk as gtk
Traceback (most recent call last):
  File "", line 890, in _find_spec
AttributeError: 'DynamicImporter' object has no attribute 'find_spec'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/accerciser", line 74, in 
accerciser.main()
  File "/usr/lib/python3/dist-packages/accerciser/__init__.py", line 34, in main
from .accerciser import Main
  File "/usr/lib/python3/dist-packages/accerciser/accerciser.py", line 27, in 

from .accessible_treeview import *
  File "/usr/lib/python3/dist-packages/accerciser/accessible_treeview.py", line 
26, in 
from .node import Node
  File "/usr/lib/python3/dist-packages/accerciser/node.py", line 21, in 
from gi.repository import Rsvg as rsvg
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 127, in find_module
'introspection typelib not found' % namespace)
ImportError: cannot import name Rsvg, introspection typelib not found
~~~

It works after manually installing the package "gir1.2-rsvg-2.0", so I
think this should be declared as a dependency in the control file.


Regards,
Michael


-- 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/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages accerciser depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-atk-1.0   2.22.0-1
ii  gir1.2-gdkpixbuf-2.0 2.36.0-1
ii  gir1.2-gtk-3.0   3.22.3-1
ii  gir1.2-pango-1.0 1.40.3-3
ii  gir1.2-wnck-3.0  3.20.1-2
ii  ipython3 5.1.0-2
ii  python3-cairo1.10.0+dfsg-5+b1
ii  python3-pyatspi  2.20.2+dfsg-2
pn  python3:any  

accerciser recommends no packages.

accerciser suggests no packages.

-- no debconf information

Bug#841669: MAP_NORESERVE vs. ulimit (was: Re: Bug#841669: Acknowledgement (KDE fails to start on kernel 4.7.0-0.bpo.1))

[Alain Knaff]

Hi,

After using logging in in "failsafe" mode, and using strace on kde, I 
found out what was going on.

The following call now fails with ENOMEM:

mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0)

Older kernels did not enforce ulimit -d with MAP_NORESERVE (confirmed 
this on (3.13.0-100-generic), whereas new ones do:

> uname -a ; ulimit -d 64000; ./memalloc-test 6900 
Linux lll 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
Succeeded

> uname -a ; ulimit -d 64000; ./memalloc-test 6900 
Linux hitchhiker 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) 
x86_64 GNU/Linux
Malloc: Cannot allocate memory

I'm not sure where the bug actually is (kde or kernel), as indeed the 
case could be made that KDE should not attempt to reserve a ridiculous 
amount of memory if it never intends to use it (and it doesn't use it, 
or else it would eventually get a SIGSEV on older kernels).

Thanks,

Alain
#include 
#include 
#include 

int main(int argc, char **argv) {
	void *r=mmap(0, atoi(argv[1]),
		 PROT_READ|PROT_WRITE,
		 MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
		 -1,
		 0);
	
	if(r != MAP_FAILED) {
		printf("Succeeded\n");
	} else {
		perror("Malloc");
		return -1;
	}
	return 0;
}

Bug#841733: Transition Opencv 3.1

[Sebastiaan Couwenberg]

On 11/09/2016 12:14 AM, Nobuhiro Iwamatsu wrote:
>> - otb:  FTBFS / BTS: #841408
> 
> NOTE: otb does no support Opencv 3.1 with in upstream yet.

OpenCV support has been disabled in yesterdays upload of the new 5.8.0
upstream release, currently in NEW.

>> - saga: FTBFS / BTS:  #841287 with patch

The patch for saga has been included in yesterdays upload to unstable.

Kind Regards,

Bas

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

Bug#843724: move vpx.pc to a multiarch location

[Helmut Grohne]

Package: libvpx-dev
Version: 1.6.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gst-plugins-good1.0

gst-plugins-good1.0 fails to cross build from source, because it fails
to detect the presence of vpx. It uses pkg-config for detection and
pkg-config ignores /usr/lib/pkgconfig during cross compilation. Only
/usr/share/pkgconfig and /usr/lib//pkgconfig are considered.
Please move vpx.pc to one of the supported locations. I am attaching a
patch for your convenience.

Helmut
diff --minimal -Nru libvpx-1.6.0/debian/changelog libvpx-1.6.0/debian/changelog
--- libvpx-1.6.0/debian/changelog   2016-09-01 10:46:47.0 +0200
+++ libvpx-1.6.0/debian/changelog   2016-11-09 05:59:15.0 +0100
@@ -1,3 +1,10 @@
+libvpx (1.6.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install vpx.pc into a multiarch location (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 09 Nov 2016 05:59:15 +0100
+
 libvpx (1.6.0-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru libvpx-1.6.0/debian/libvpx-dev.install 
libvpx-1.6.0/debian/libvpx-dev.install
--- libvpx-1.6.0/debian/libvpx-dev.install  2016-08-21 19:14:20.0 
+0200
+++ libvpx-1.6.0/debian/libvpx-dev.install  2016-11-09 05:59:14.0 
+0100
@@ -2,4 +2,4 @@
 builddir/vpx-vp8-*/lib/libvpx.so /usr/lib/${DEB_HOST_MULTIARCH}/
 builddir/vpx-vp8-*/lib/libvpx.a /usr/lib/${DEB_HOST_MULTIARCH}/
 builddir/vpx-vp8-*/include/vpx usr/include
-builddir/vpx-vp8-*/lib/pkgconfig usr/lib
+builddir/vpx-vp8-*/lib/pkgconfig usr/lib/${DEB_HOST_MULTIARCH}/

Bug#843723: ITP: python-django-html-sanitizer -- set of utilities to easily sanitize/escape/clean HTML inputs in django

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-django-html-sanitizer
  Version : 0.1.5
  Upstream Author : Selwin Ong 
* URL : https://pypi.python.org/pypi/django-html_sanitizer
* License : MIT
  Programming Lang: Python
  Description : set of utilities to easily sanitize/escape/clean HTML 
inputs in django

Django HTML Sanitizer provides a set of utilities to easily sanitize/escape/
clean HTML inputs in django. This app is built on top of bleach, the excellent
Python HTML sanitizer.

It supports both python and python3.

I intend to maintain this within the Debian Python Modules Team

Bug#843722: wants to write to /usr/local

[Thomas Lange]

Package: ca-certificates
Version: 20161102

My /usr/local file system is mounted read-only via NFS. This results
in an error:


stretch[~]# dpkg --configure ca-certificates
Setting up ca-certificates (20161102) ...
chmod: changing permissions of '/usr/local/share/ca-certificates': Read-only 
file system
dpkg: error processing package ca-certificates (--configure):
 subprocess installed post-installation script returned error exit status 1
 Errors were encountered while processing:
  ca-certificates
  
-- 
regards Thomas

Bug#843593: Please add support for ESP partitions

[Thomas Lange]

I found the thread on the linux-fai mailing list and also the code
that added efi support into setup-storage. In the end we remove the
code from FAI, since it was not needed any more.

It's much easier to get a partition of type ESP. Just create a disk
gpt disk label, a partition of type vfat that is mounted to /boot/efi
and set the boot flag on this partition using the bootable:1 keywork
in the disk_config line. This will result in a partition type of
esp. This is the normal parted behaviour. It should look like this:

disk_config disk1 disklabel:gpt fstabkey:uuid bootable:1
primary   /boot/efi  200 vfatrw
primary   /  1G- ext4rw


We should document this, but IMO there's no need for a patch in
setup-storage.

-- 
regards Thomas

Bug#842959: gnome-session-flashback fails due to signal 11

[Karl-Philipp Richter]

Hi,

Am 02.11.2016 um 19:16 schrieb Dmitry Shachnev:
>>> Can you please paste the output of the following command?
>>> > >
>>> > > $ dpkg -L gnome-session-fallback
>> >
>> > [...]
> Are you sure you pasted the output for gnome-session-fallback, and not
> for gnome-session-flashback? These are different package names (note the
> fall vs flash part).
`sudo apt-get install gnome-session-fallback` fails due to

Package gnome-session-fallback is not available, but is referred to
by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  gnome-session-flashback

E: Package 'gnome-session-fallback' has no installation candidate

with

deb http://ftp.de.debian.org/debian/ stretch main contrib non-free
deb-src http://ftp.de.debian.org/debian/ stretch main contrib non-free

deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib
non-free

# jessie-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ stretch-updates main contrib
non-free
deb-src http://ftp.de.debian.org/debian/ stretch-updates main
contrib non-free

in `/etc/apt/sources.list`.

> Please also paste the output of this command:
> 
> $ apt-cache policy gnome-session-fallback

gnome-session-fallback:
  Installed: (none)
  Candidate: (none)
  Version table:

-Kalle



signature.asc
Description: OpenPGP digital signature

Bug#843721: dnsmasq: Init script incorrectly hardcodes 127.0.0.1 for resolvconf registration.

[Sven Mueller]

Package: dnsmasq
Version: 2.76-4
Severity: normal
Tags: patch

I use a dnsmasq.conf setting that registers netmasq on 127.0.1.1 (still 
interface lo).
With the unmodified initscript, this results in the name resolution 
failing because
dnsmasq only listens on 127.0.1.1 which the init script tells 
resolvconf to query 127.0.0.1,

which doesn't have a listening resolver on most of my machines.

Attached is a patch that teaches the init script to read the relevant 
setting from
dnsmasq.conf and passing the correct value to resolvconf, falling back 
to 127.0.0.1

if the setting wasn't found or didn't match the right pattern.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- dnsmasq.init.orig   2016-11-08 22:27:33.352332003 -0500
+++ dnsmasq.init2016-11-08 22:27:50.548723969 -0500
@@ -132,8 +133,22 @@
[ $interface = lo ] && return
done
 
-if [ -x /sbin/resolvconf ] ; then
-   echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
+   if [ -x /sbin/resolvconf ] ; then
+   # Use the first valid listen-address but not 0.0.0.0
+   # dnsmasq.conf has one line per listen-address, not a list in
+   # one line.
+   IP=$(awk 'match( \
+   $0, \
+   /^listen-address=([0-9.]*)[^0-9.]*$/, arr \
+   ) { print arr[1] }' < /etc/dnsmasq.conf \
+   | grep -vE '^0\.0\.0\.0' \
+   | grep -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$' \
+   | head -n 1
+   )
+   if [[ -z "${IP}" ]]; then
+   IP=127.0.0.1
+   fi
+   echo "nameserver ${IP}" | /sbin/resolvconf -a lo.$NAME
fi
return 0
 }

Bug#843719: base: /var partition (13G) FILLED UP in few minutes after fresh install

[Oleksiy]

Package: base
Severity: normal
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?
  Nothing. System is freshly installed.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  Just installed a fresh system from CD.
   * What was the outcome of this action?
   * What outcome did you expect instead?

DESCRIPTION:
After fresh install and first boot I get /var partition completely filled up
during few minutes. I discovered that it is filled by files kern.log,
daemon.log, messages and syslog. All files reside in /var/log. On text console
error messages
 "...rt2800cpi ...: firmware: failed to load rt2860.bin (-2)"

HOW I FIXED:
I installed firmware-ralink from non-free. Driver got loaded immediately and
error logs stopped filling immediately.

I thought that it's critical since filling up /var or even ROOT where /var and
/tmp aren't on separate partitions, could make system at least unusable.

The driver loader script should stop trying to load a driver after first try
and not bloat logs until disk will be filled up.

Regards



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

Bug#823279: NMU + patch for debtree #833242 (Uses obsolete compressor for .deb data.tar member) + #823279 (Warning "Useless use of \E at /usr/bin/debtree line 612.")

[Axel Beckert]

Control: tag -1 + patch pending

Hi,

I've uploaded a non-maintainer upload to DELAYED/7 which fixes:

* RC bug #833242: Uses obsolete compressor for .deb data.tar member
* Bug #823279: Warning "Useless use of \E at /usr/bin/debtree line 612."
* A typo in the man page found by lintian.

Feel free to tell me if I should fast-forward it or delay it longer.
(Note that the upload delay is chosen so that the NMU has a chance to
propagate to testing before the buggy version gets removed from
testing. Otherwise I would have uploaded it to DELAYED/10.)

Additionally I've also pushed my changes to the branch "nmu" in the
collab-maint git repository:

  
https://anonscm.debian.org/cgit/collab-maint/debtree.git/log/?id=refs/heads/nmu

That way you can easily import my changes by doing a fast-forward
merge from that branch into the master branch. (I'll do the tagging
and that merge once the NMU has been accepted into the archive.)

Full debdiff:

diff -Nru debtree-1.0.10/debian/changelog debtree-1.0.10+nmu1/debian/changelog
--- debtree-1.0.10/debian/changelog 2012-06-22 01:17:19.0 +0200
+++ debtree-1.0.10+nmu1/debian/changelog2016-11-09 01:26:57.0 
+0100
@@ -1,3 +1,13 @@
+debtree (1.0.10+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove override_dh_builddeb to no more build with deprecated bzip2
+compression. (Closes: #833242)
+  * Guard …."\E" with "no warnings qw(misc);" (Closes: #823279)
+  * Fix typo in man page found by lintian.
+
+ -- Axel Beckert   Wed, 09 Nov 2016 01:26:57 +0100
+
 debtree (1.0.10) unstable; urgency=low
 
   [ Thorsten Alteholz ]
diff -Nru debtree-1.0.10/debian/rules debtree-1.0.10+nmu1/debian/rules
--- debtree-1.0.10/debian/rules 2011-04-17 01:31:33.0 +0200
+++ debtree-1.0.10+nmu1/debian/rules2016-11-09 00:35:44.0 +0100
@@ -5,6 +5,3 @@
 
 %:
dh $@
-
-override_dh_builddeb:
-   dh_builddeb -- -Zbzip2
diff -Nru debtree-1.0.10/debtree debtree-1.0.10+nmu1/debtree
--- debtree-1.0.10/debtree  2012-06-22 00:30:16.0 +0200
+++ debtree-1.0.10+nmu1/debtree 2016-11-09 00:49:33.0 +0100
@@ -609,7 +609,9 @@
 
my $pinfo = get_apt_pinfo($rdep, "");
my $deps = get_apt_deps($pinfo, $dtype);
+   no warnings qw(misc);
my $regex = "(\Q" . join("\E|\Q", @pset) . "\E)";
+   use warnings;
for my $dep_or (split(/,/, $deps)) {
next unless $dep_or =~ /(^|\|)$regex([| ]|$)/;
 
diff -Nru debtree-1.0.10/debtree.1 debtree-1.0.10+nmu1/debtree.1
--- debtree-1.0.10/debtree.12011-11-29 23:58:29.0 +0100
+++ debtree-1.0.10+nmu1/debtree.1   2016-11-09 01:26:57.0 +0100
@@ -50,7 +50,7 @@
 If a package included in an alternative dependency also needs to be displayed
 separately or is also part of some other alternative dependency set, its
 dependencies will only be included once, with the package's first occurrence.
-For the secondary occurences the package name will be shown between square
+For the secondary occurrences the package name will be shown between square
 brackets: `[...]'.
 .PP
 See also the \-\-show\-installed option below.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#843717: ITP: tablator -- Universal table translator for astronomy

[Walter Landry]

Package: wnpp
Severity: wishlist
Owner: Walter Landry 

* Package name: tablator
  Version : 1.0.0
  Upstream Author : Walter Landry 
* URL : https://github.com/Caltech-IPAC/tablator
* License : GPL
  Programming Lang: C++
  Description : Universal table translator for astronomy

Tablator is a utility for converting tables in astronomy into
different formats.  Tablator can read and write tables in fits, ipac
table, hdf5, votable, json, json5, csv, and tsv, and can write html.
The emphasis is on speed, so all conversions are done in memory.

Bug#367347: Not fixed?

[Roland Hieber]

Hi,

On Wed, 18 Aug 2010 17:07:54 +0200 Gerfried Fuchs  wrote:
>  Actually, for Felix Lee's output this is thankfully found to be in
> web.archive.org:
> 
> "You can use these critters for non-commercial purposes. Just leave my
> nametag attached, and try to take good care of them."
> 
> 
>  This is clearly a call for non-free.
> 
>  meow.cow looks suspicously similar to what Felix has as "tiger kitty"
> in there.

Unfortunately, the archive.org link provided by Rhonda is itself dead now.
But this bug makes still sense to me in version 3.03+dfsg1-16, because ...

$ echo Insert thought here | cowsay -f /usr/share/cowsay/cows/kitty.cow 
 _
< Insert thought here >
 -
 \
  \
   ("`-'  '-/") .___..--' ' "`-._
 ` *_ *  )`-.   (  ) .`-.__. `)
 (_Y_.) ' ._   )   `._` ;  `` -. .-'
  _.. `--'_..-_/   /--' _ .' ,4
   ( i l ),-''  ( l i),'  ( ( ! .-'
$ echo Insert thought here | cowsay -f /usr/share/cowsay/cows/meow.cow 
 _
< Insert thought here >
 -
  \
   \ ,   _ ___.--'''`--''//-,-_--_.
  \`"' ` || \\ \ \\/ / // / ,-\\`,_
 /'`  \ \ || Y  | \|/ / // / - |__ `-,
/@"\  ` \ `\ |  | ||/ // | \/  \  `-._`-,_.,
   /  _.-. `.-\,___/\ _/|_/_\_\/|_/ | `-._._)
   `-'``/  /  |  // \__/\__  /  \__/ \
`-'  /-\/  | -|   \__ \   |-' |
  __/\ / _/ \/ __,-'   ) ,' _|'
 (((__/(((_.' ((___..-'((__,'


... kitty.cow and meow.cow don't credit Felix Lee, and ...

$ grep 'kitty\|meow' /usr/share/doc/cowsay/copyright 
$ 

... are not listed in the copyright file.

Cheers,

 - Roland

Bug#843711: biber: FTBFS (failing tests)

[Norbert Preining]

forwarded 843711 https://github.com/plk/biber/issues/149
thanks

Hi Santiago,

the actual errors are:
# -  \\field{sortinithash}{0aa614ace9f3a40ef5a67e7f7a184048}
# +  \\field{sortinithash}{8343b463aacf48517c044b4d2c9c45ed}

all of them.

That means that some perl update broke biber building as it
did built when I uploaded it.

I have contacted upstream concerning this change, and include
the perl group in case they have an idea.

What happens is that first a "sortinitcollator" is computed by:
Unicode::Collate::Locale->new(locale => 
$sortlist->get_sortscheme->{locale}, level => 1)
and then the sortkey is collated and hashed
md5_hex($self->{sortinitcollator}->viewSortKey($sinit));

It seems something in the locale handline has changed.

Anyway, I hope to get an answer from upstream or perl group soon.

Thanks

Norbert

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

Bug#843716: Acknowledgement (setup-storage fails with fai-diskimage and btrfs)

[Sam Hartman]

control: tags -1 patch
control: severity -1 normal

Actually, the problem is somewhat simpler than that.
>From e4511f8ea11c047bf19f13c7b99d9c18f8736d89 Mon Sep 17 00:00:00 2001
From: Sam Hartman 
Date: Tue, 8 Nov 2016 18:49:38 -0500
Subject: [PATCH] Fix handling of btrfs single volume devices

---
 lib/setup-storage/Commands.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/setup-storage/Commands.pm b/lib/setup-storage/Commands.pm
index 6190343..0e0b625 100755
--- a/lib/setup-storage/Commands.pm
+++ b/lib/setup-storage/Commands.pm
@@ -332,7 +332,7 @@ sub build_btrfs_commands {
   $FAI::configs{$config}{volumes}{$volume}{mount_options} = 
$FAI::configs{$c}{partitions}{$p}{mount_options};
   $FAI::configs{$c}{partitions}{$p}{mount_options} = '-';
   $FAI::configs{$config}{volumes}{$volume}{fstabkey} = 
$FAI::configs{$c}{fstabkey};
-  if ($device =~ m|^/dev/nvme|) {
+  if ($device =~ m:^/dev/nvme|^/dev/loop:) {
 $FAI::configs{$config}{volumes}{$volume}{devices}{$device . "p" . $p} 
= {};
   } else {
 $FAI::configs{$config}{volumes}{$volume}{devices}{$device . $p} = {};
-- 
2.9.3

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Hi Vincent--

On Tue 2016-11-08 10:23:22 -0600, Vincent Lefevre wrote:
> Yes, dbus-user-session got installed automatically as a consequence
> of dependencies.

dbus-user-session is also very much in line with gpg-agent's
--standard-socket option (which is now the default): both of them have
the concept of a single session running for any given user on the
machine.

> I see, a gcr-prompter process appears when I run gpg...

yes, launched due to
/usr/share/dbus-1/services/org.gnome.keyring.SystemPrompter.service

> So, the problem occurs only because with dbus-user-session installed,
> ssh and X shares a d-bus session.
>
> Now, how does gcr-prompter decide which display to use? The problem
> may be here. This does not come from dbus-daemon, since as documented
> in the dbus-daemon(1) man page:
>
>   The per-session daemon is used for various interprocess communication
>   among desktop applications (however, it is not tied to X or the GUI in
>   any way).

From the dbus-user-session package description:

 This model merges all parallel non-graphical login sessions (text
 mode, ssh, cron, etc.), and up to one graphical session, into a
 single "user-session" or "super-session" within which all
 background D-Bus services are shared.

> This depends on how gcr-prompter currently decides which display to
> use.

it uses the graphical session attached to the dbus session.  if there is
no graphical session, it fails in a noticeable way, which is when we
choose to fall back to text.

> pinentry-gnome3 could remain unaware of displays if gcr-prompter
> communicates with it via d-bus. For instance, gcr-prompter could
> ask the values of some environment variables. Since gcr-prompter
> is the program that does the display, it should know what to ask.
> That would be the obvious thing to do in order to decide which
> display to use.

perhaps you'd like to reassign this bug to gcr-prompter?  I'm not
convinced that they would accept it -- gcr-prompter is attached to a
single d-bus session, and if that d-bus session has a graphical session
associated with it, it uses that session.

>> But pinentry-gnome3's end-user prompts currently work even when they're
>> run from a process where DISPLAY has unset for whatever reason.  It
>> sounds like you're asking to break this functionality.
>
> I actually don't understand why this should work: unsetting DISPLAY
> is a way to prevent from processes using X.

Right.  And pinentry-gnome3 does not itself use X.  It uses the gcr
prompter, which it talks to over d-bus.  We're going around in circles
on this bug report, and i'm starting to feel diminishing returns.

> I'm not asking to break this functionality, because there could be
> another test before testing DISPLAY. But one needs to know why a
> user would want an X dialog window while DISPLAY has been unset.
> And in this case, how the display is determined.

What test are you imagining?  Most users don't want an "X dialog window"
-- they want a graphical window where possible, and they have no idea
what DISPLAY is :/

>> Another possible approach would be to prompt via the terminal *in
>> addition* to prompting graphically, if the current d-bus session knows
>> about an X11 session, but that X11 session does not match the current
>> value of $DISPLAY (e.g. if $DISPLAY is unset, or if it is set to a
>> different value).
>
> The graphical prompt when unexpected is also itself a problem.
> For instance, it can make other applications freeze while the
> user hasn't acknowledged the new window via his window manager.
> I use fvwm's manual placement and it is currently a problem.
> So, it shouldn't be "in addition".

i'm sorry, but if this bug report depends on the user using manual
window placement with fvwm, i'm inclined to close it wontfix.  we're
already in a corner case (ssh to a machine where the same user is
already logged in on the graphical console) of a corner case (and the
graphical screen isn't locked, despite that we're working with sensitve
secret key material), and i need to focus what debian/GnuPG packaging
energies are available on things that affect more people.

> On a default Debian desktop system, pinentry-gnome3 is installed:
>
> cventin:~> aptitude why pinentry-gnome3
> i   evolution Depends evolution-data-server (>= 3.22.1)
> i A evolution-data-server Depends gnome-keyring
> i A gnome-keyring Depends pinentry-gnome3  

on a default debian system, the user has the GNOME lockscreen and the
GNOME window placement, and the screen will lock when they leave it long
enough to get to an ssh client elsewhere and connect in.

If you have a concrete test that you think we could implement in
pinentry-gnome3, i'm game to entertain it.  Please test.  But if what
you want is a pinentry that strictly follows the currently-attached X11
session (rather than following the attached d-bus session), you might
want to just use a different pinentry.

  

Bug#843714: dpkg: /usr/share/dpkg/pie-link.specs breaks statically linked binaries on some architectures

[Hilko Bengen]

Package: dpkg
Version: 1.18.13
Severity: important

Hi,

recent rebuilds of supermin on a few architectures (at least powerpc,
ppc64, sh4, sparc64) failed gcc no longer produces static binaries.

It looks as if this breakage was introduced when
"-specs=/usr/share/dpkg/pie-link.specs" became part of the command line
via LDFLAGS. A quick test on powerpc showed that removing this parameter
leads to a valid static binary.

Cheers,
-Hilko

Bug#832362: crashed: jaw_impl_get_instance: assertion failed

[Michael Weghorn]

Hello,

On 09/11/16 00:02, Samuel Thibault wrote:
> It should produce a warning instead of a crash, yes.
> 
> You can already fetch it from 
> 
> deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib 
> non-free 

I can confirm the issue is fixed in the new version. The following
warning appears now (multiple times):

** (java:1006): WARNING **: jaw_impl_get_instance called from
jaw_thread. If you are running a screen reader, this is expected
If you are not running a screen reader, please report this warning to
the java-atk-wrapper package, explaining how to reproduce this warning

Thanks again for fixing this.

Michael

Bug#841733: Transition Opencv 3.1

[Nobuhiro Iwamatsu]

Hi,

I update situation of opencv.

2016-10-23 6:19 GMT+09:00 Nobuhiro Iwamatsu :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi,
>
> I want to upload the opencv 3.1 to unstable. This is changed API and
> soname and remove
> oobsolete library from 2.4.x, some of the packages that depend on this
> is the need to change.
> I checked this, with regard to the possible package has sent a patch
> to the bug report both.
>
> Can you permission to upload this?
>
> https://release.debian.org/transitions/html/auto-opencv.html
>

> - ffmpeg:   Build OK
> - frei0r:   FTBFS / BTS: #841245 /  already fixed in
> Debian git repository
Fixed in unstable. can binNMU.

> - actiona:  Build OK
> - auto-multiple-choice: FTBFS / BTS; #841244 with patch
   Fixed in unstable. can binNMU.

> - cimg: FTBFS / BTS: #841263 and #841264 with patch / 
> Blocked: #819606
   Fixed in unstable, can binNMU.

> - digikam:  FTBFS / BTS: #841412
> - eviacam:  FTBFS / BTS: #841407 / NOTE: fixed in upstream
> git branch

new upstream released. Fixed in this version.
I request update for maintainer.

> - gmic: FTBFS / BTS: #841246 with patch
> - gst-plugins-bad1.0:   FTBFS / BTS: #841413 / NOTE: Fixed in upstream
   Fixed in unstable, can binNMU.

> - libkf5kface:  FTBFS / BTS: #841411

libkf5kface need of contrib library. I already worked about this
in git repository, work fine. but this is not in experimental yet.

https://anonscm.debian.org/cgit/debian-science/packages/opencv.git/log/?h=with-contrib

> - limereg:  FTBFS / BTS: #841406  with patch.
  Fixed in debian git repository.
  https://anonscm.debian.org/gitweb/?p=debian-science/packages/limereg.git

> - mldemos:  FTBFS / BTS: #812032 (non opencv issue)
> - mrpt: Build OK
> - nomacs:   FTBFS / BTS: #841370 with patch
 Fixed, can binNMU.

> - openalpr: Build OK
> - opencfu:  FTBFS / BTS: #841246 / NOTE: Fix in upstream.

 I send patches which support opencv 3.1.

> - openimageio:  Build OK
> - os-autoinst:  Build OK
> - otb:  FTBFS / BTS: #841408

NOTE: otb does no support Opencv 3.1 with in upstream yet.

> - php-facedetect:   FTBFS / BTS: #841246 with patch
 Fixed in experimental. If upload opencv 3.1 to unstable,
 maintainer upload this package to unstable too.

> - ros-vision-opencv:Build OK
> - sikuli:   FTBFS / BTS: #841409
  Fixed in unstable, can binNMU.

> - siril:Build OK
> - sitplus:  FTBFS / BTS: #841405

NMUed by 5 days

> - visp: Build OK
> - freecad:  FTBFS / BTS: #841416  with patch
   will team upload.

> - lush: FTBFS / BTS: #841410 with patch

 NMUed. can binNMU.

> - saga: FTBFS / BTS:  #841287 with patch
>

Best regards,
  Nobuhiro


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#843713: libsvn-web-perl: FTBFS (failing tests)

[Santiago Vila]

Package: src:libsvn-web-perl
Version: 0.63-2
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep
dh: Compatibility levels before 9 are deprecated (level 8 in use)
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Compatibility levels before 9 are deprecated (level 8 in use)
perl -I. Makefile.PL INSTALLDIRS=vendor
Warning: prerequisite Alien::SVN 0 not found.
Warning: prerequisite YAML 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile

[... snipped ...]

ok 1 - stub
1..1
ok
t/release-distmeta.t .. skipped: these tests are for release candidate 
testing
t/release-pod-coverage.t .. skipped: these tests are for release candidate 
testing
t/release-pod-syntax.t  skipped: these tests are for release candidate 
testing
t/svn-uris.t .. 
ok 1 - encode: simple svn-schema uri
ok 2 - decode: simple svn-schema uri
ok 3 - encode: path with spaces
ok 4 - decode: path with spaces
ok 5 - encode: path with unicode symbols
ok 6 - decode: path with unicode symbols
1..6
ok
t/timedate_format.t ... 
1..4
ok 1 - An object of class 'SVN::Web::action' isa 'SVN::Web::action'
ok 2
ok 3
ok 4
ok

Test Summary Report
---
t/1use.t(Wstat: 256 Tests: 14 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
t/2basic.t  (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/3svnweb-install.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
Files=10, Tests=25,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.56 cusr  0.07 
csys =  0.69 CPU)
Result: FAIL
Failed 3/10 test programs. 1/25 subtests failed.
Makefile:1008: recipe for target 'test_dynamic' failed
make[2]: *** [test_dynamic] Error 255
make[2]: Leaving directory '/<>'
dh_auto_test: make -j1 test TEST_VERBOSE=1 LC_ALL=C.UTF-8 returned exit code 2
debian/rules:7: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


There are full build logs available here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libsvn-web-perl.html

Note: Even if this package is Arch:all, please consider uploading in
source-only form, so that we get official build logs available here:

https://buildd.debian.org/status/package.php?p=libsvn-web-perl

Thanks.

Bug#843711: biber: FTBFS (failing tests)

[Santiago Vila]

Package: src:biber
Version: 2.6-1
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with tex
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
perl -I. Build.PL --installdirs vendor --config "optimize=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Checking prerequisites...
  requires:
!  Encode::EUCJPASCII is not installed
!  Lingua::Translit is not installed
!  Mozilla::CA is not installed

ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions

[... snipped ...]

  Non-zero exit status: 24
t/dateformats.t  (Wstat: 4096 Tests: 41 Failed: 16)
  Failed tests:  20-22, 24, 26, 28, 31, 33-41
  Non-zero exit status: 16
t/encoding.t (Wstat: 2304 Tests: 10 Failed: 9)
  Failed tests:  1-8, 10
  Non-zero exit status: 9
t/names.t(Wstat: 8192 Tests: 72 Failed: 32)
  Failed tests:  32-57, 59-60, 65-68
  Non-zero exit status: 32
t/options.t  (Wstat: 768 Tests: 9 Failed: 3)
  Failed tests:  7-9
  Non-zero exit status: 3
t/related-entries.t  (Wstat: 768 Tests: 13 Failed: 3)
  Failed tests:  1-2, 10
  Non-zero exit status: 3
t/set-dynamic.t  (Wstat: 1536 Tests: 7 Failed: 6)
  Failed tests:  2-7
  Non-zero exit status: 6
t/set-legacy.t   (Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
t/set-static.t   (Wstat: 768 Tests: 5 Failed: 3)
  Failed tests:  1-2, 5
  Non-zero exit status: 3
t/skips.t(Wstat: 2048 Tests: 15 Failed: 8)
  Failed tests:  7, 9-15
  Non-zero exit status: 8
t/sort-complex.t (Wstat: 1280 Tests: 9 Failed: 5)
  Failed tests:  2-6
  Non-zero exit status: 5
t/sortlists.t(Wstat: 512 Tests: 15 Failed: 2)
  Failed tests:  13-14
  Non-zero exit status: 2
t/xdata.t(Wstat: 512 Tests: 5 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
Files=42, Tests=1046, 40 wallclock secs ( 0.25 usr  0.08 sys + 36.73 cusr  2.18 
csys = 39.24 CPU)
Result: FAIL
Failed 16/42 test programs. 130/1046 subtests failed.
dh_auto_test: perl Build test --verbose 1 test_files=t/annotations.t 
t/basic-misc.t t/bcfvalidation.t t/biblatexml.t t/bibtex-aliases.t 
t/bibtex-output.t t/configfile.t t/crossrefs.t t/dateformats.t 
t/dm-constraints.t t/encoding.t t/extratitle.t t/extratitleyear.t t/extrayear.t 
t/full-bbl.t t/full-bblxml.t t/full-bibtex.t t/full-dot.t t/labelalpha.t 
t/labelname.t t/names.t t/names_x.t t/options.t t/related-entries.t 
t/sections-complex.t t/sections.t t/set-dynamic.t t/set-legacy.t t/set-static.t 
t/skips.t t/sort-case.t t/sort-complex.t t/sort-order.t t/sort-uc.t t/sorting.t 
t/sortlists.t t/tool-bltxml-inout.t t/tool-bltxml.t t/tool.t t/uniqueness.t 
t/utils.t t/xdata.t returned exit code 2
debian/rules:17: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:9: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The above is just the last part of the build log.
For a full build log please see:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/biber_2.6-1.rbuild.log

Note: Even if this package is Arch:all, please consider uploading in
source-only form, so that we get official build logs available here:

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

Thanks.

Bug#841060: (no subject)

[westlake]

still recurrs in 1:2.7+dfsg-3~bpo8+1

Bug#832362: crashed: jaw_impl_get_instance: assertion failed

[Michael Weghorn]

Hi Samuel,

thank you for your quick fix.

On 08/11/16 23:19, Samuel Thibault wrote
> 
> Alex, are you perhaps using a screen reader?  I would be very surprised
> if you are getting this while no screen reader is currently running,
> and I'm interested in a reproducer.  It's definitely an issue in
> java-atk-wrapper at least, thus reassigning.

Not being Alex, I had the same issue - originally with "jitsi" from
their repository, but I can reproduce it with "mediathekview" as well.

It originally happened to me when running "accerciser" (a tool that
queries the accessibility APIs as well), but I can also reproduce it
when I run orca (screen reader) instead. For me, the crash did not occur
when not running accerciser or orca.

Dropping the patch "check-thread" helped for me as a workaround as I
mentioned in #838778.

In case that helps, I can retest once version version 0.33.3-10 is
available in unstable.

Regards,
Michael

Bug#843215: fwupd: Please announce supported hardware using appstream

[Mario.Limonciello]

Paul,

> I was mainly talking about the devices that can be found in this file:
> 
> /lib/udev/rules.d/90-fwupd-devices.rules
> 
> Those are a static set of devices not determined at runtime.
> I guess for those, prompting the user to install fwupd is a good idea.
> 

On the contrary, I would disagree here.  Those devices just show
information about the current firmware on the device from udev.  
Prompting the user to install fwupd just to see this information
seems like a giant waste of time.  The really valuable ones are 
the ones that you can actually perform an update for.

> > If fwupd can be included by default in Debian I think a better experience
> can
> > be had though.
> 
> For proprietary platforms that seems like a reasonable idea but for
> fairly open platforms like ARM/etc, I would much prefer all firmware to
> be packaged for Debian and flashed using flash-kernel or similar.

Actually ARM platforms I think make a lot of sense too.  

Fwupd can perform updates for USB type devices (DFU & Colorhug) that 
can both be used with ARM platforms.

It also has specific support for Raspberry Pi FW:
https://github.com/hughsie/fwupd/blob/master/src/fu-provider-rpi.c

> 
> > So for now I think it would be better for isenkram to do one of these:
> > 1) Query fwupd for updatable objects if it's installed.
> 
> That sounds like a good idea, could you file a bug with the details?
> I am not aware how that should work.

Actually in looking closer at this, this doesn't really make sense given
what isenkram does.  It duplicates effort from what gnome-software
already does with fwupd.

Bug#843693: sddm: starting sddm results in white screen with active cursor and keyboard

[Maximiliano Curia]

Control: severity -1 important

¡Hola Jape!

El 2016-11-08 a las 14:39 -0500, Jape Person escribió:
Package: sddm 
Version: 0.13.0-1 
Severity: grave 
Justification: renders package unusable



  * What led up to the situation?


Installed task-lxqt-desktop. Replacement of lightdm by sddm resulted in inability 
to log in. Screen presented is all white, but cursor is visible, and keyboard 
functions appear to be intact.


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


Reconfigured to use lightdm and was able to log in to the system. Removed lightdm, 
installed xdm, and that was also successful for logging in.



  * What was the outcome of this action?



Have left system temporarily configured to use xdm until sddm is fixed.



ii  sddm-theme-breeze [sddm-theme]  4:5.8.2-1


The breeze theme causes sddm to use the composite mode, this has caused issues 
with certain graphical cards in the past. Could you try installing 
sddm-theme-maui and removing sddm-theme-breeze?


Also, could you share the output of:
lspci -vnn | grep VGA -A 12

Happy hacking,
--
"If I ask another professor what he teaches in the introductory programming
course, whether he answers proudly "Pascal" or diffidently "FORTRAN," I know
that he is teaching a grammar, a set of semantic rules, and some finished
algorithms, leaving the students to discover, on their own, some process of
design."
-- Robert W. Floyd
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#843707: kwin: No dbg package is built.

[Bernhard Übelacker]

I was not aware of this repo.

Just checked the source package
at packages.debian.org, but did not find
an entry for a dbg package.

Thank you very much.

Bug#837824: Fix uploaded to delayed/5

[Jordi Mallach]

tag 837824 + pending

Hi,

I've just uploaded a fixed package to delayed/5, and committed the changes
to git. Feel free to revert if you see a problem with this.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


signature.asc
Description: PGP signature

Bug#843709: Purify missed the cfitsio5 transition

[Ole Streicher]

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

Hi,

The "purify" package was in NEW while the cfitsio transition was going on,
so it missed it. Please do an binNMU for the package now.

 nmu purify_2.0.0-1 . amd64 . -m 'Rebuild against libcfitsio5'

Thanks

Ole

Bug#832362: crashed: jaw_impl_get_instance: assertion failed

[Samuel Thibault]

Control: reassign -1 java-atk-wrapper

Hello,

Michael Weghorn, on Tue 08 Nov 2016 21:43:42 +0100, wrote:
> The respective bug report against libatk-wrapper-java seems to be
> #838778 [1].
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838778

The case in #838778 is very particular, I have worked around it in
version 0.33.3-10 of java-atk-wrapper.

Alex, are you perhaps using a screen reader?  I would be very surprised
if you are getting this while no screen reader is currently running,
and I'm interested in a reproducer.  It's definitely an issue in
java-atk-wrapper at least, thus reassigning.

At least in version 0.33.3-10 you should be getting a warning, not a
crash.

Samuel

Bug#838259: Please allow communication via Tor for improved privacy

[Alexandre Viau]

The current blocker for this is TCP support in OpenDHT. This is planned,
but there is no ETA and work has not yet begun.

Contributions would be welcome:
 - https://github.com/savoirfairelinux/opendht

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#787955: openjdk-8-jre: crashes in GUI program when focussing widgets with

[Samuel Thibault]

Hello,

Sebastian Humenda, on Mon 18 Jul 2016 13:47:50 +0200, wrote:
> Erich Schubert schrieb am 17.07.2016, 11:30 +0200:
> >This seems to be fixed for me. I could not reproduce anymore.
> I'm still experiencing the same issue. I've uploaded a core dump on [^1]. It 
> is
> actually enough to start the application, in this case MediathekView, alt+tab
> out of the window and into it again. After a short while the application
> crashes. The crash did not produce a log file though. If there's anything I 
> can
> do to help, please let me know.

I believe you are here actually talking about Bug#838778, which started
happening with version 0.33.3-8 of java-atk-wrapper, right?  This is
very particular, it only happens with a screen reader, this is unrelated
with the kind of issues that people not using a screen reader could be
having.

Samuel

Bug#838778: libatk-wrapper-java: crashes JVM when launching a java application

[Samuel Thibault]

Control: clone -1 -2
Control: retitle -2 libatk-wrapper-java: gets instance from jaw thread
Control: severity -2 important
Control: done -1 0.33.3-10

Hello,

Uh, that's odd: I can't find your original report in my mails, so I
completely missed it.  That assertion is indeed quite harsh, and may
trigger while running a screen reader.  I didn't intend to keep it
applied actually, it just happened to slip in while committing something
else :/ Such a case condition can indeed pose problems in some very rare
conditions.  I have thus replaced the assertion with just a warning, so
that you don't systematically get a crash, and if there are odd things
happening, we have a clue that it might be because of this case.

Samuel

Bug#843705: ITP: r-cran-fitcoach -- R package for analysis and retrieve data of Fitbit

[Dylan]

Package: wnpp
Severity: wishlist
Owner: Dylan Aïssi 

Package name: r-cran-fitcoach
URL: https://cran.r-project.org/package=fitcoach
License: GPL-3
Description: R package for analysis and retrieve data of Fitbit
 This R package use the official API to import Fitbit data into R.
 Fitbit R API that provides fitbit coach functionality by analyzing
 your data obtained via fitbit API calls, and by giving personalized
 recommendations for the rest of the day based on your behavior.



This package will be maintained by the Debian Med Packaging Team at:
https://anonscm.debian.org/git/debian-med/r-cran-fitcoach.git/

Bug#843658: sendmail-cf: Customized sendmail.cf is being overwritten on startup

[Andreas Beckmann]

On 2016-11-08 20:38, Thomas - In:Quality wrote:
> That disclaimer is of limited use for people who bring their own
> sendmail.cf. ;-) It's a very old and possibly bad habit, but it has not
> been a problem for many years,

I can easily reproduce your problems in minimal chroots with

apt-get install sendmail
$EDITOR /etc/mail/sendmail.cf
apt-get reinstall sendmail-bin

That regenerates sendmail.cf, removing any customization (well, I only
tested with comments) while nothing of the *.m4 has changed (but perhaps
something gets touched?).
But this "works" in wheezy, jessie and stretch, so it probably has
worked always in that way.

> and I don't even see the point of
> rebuilding the file unless there was an update to the m4 stuff. Maybe
> "make" can be limited to just the database files for startup?

I have no clue how that configuration setup actually works in the Debian
package :-(


Andreas

Bug#843704: libnet-pcap-perl: FTBFS: t/09-error.t fails with newer libpcap

[Niko Tyni]

Package: libnet-pcap-perl
Version: 0.18-1
Severity: serious
User: debian-p...@lists.debian.org
Usertags: autopkgtest

As noticed by ci.debian.net, this package fails its test suite
on current sid, making it fail to build from source.

  https://ci.debian.net/packages/libn/libnet-pcap-perl/unstable/amd64/

This regressed on 20161029 or so:

  
https://ci.debian.net/data/packages/unstable/amd64/libn/libnet-pcap-perl/20161029_182428.log

  -libpcap0.8 1.7.4-3
  +libpcap0.8 1.8.1-1

The reason looks like just a cosmetic change in libpcap diagnostics:

  #   Failed test ' - $err must not be null: syntax error in filter expression: 
syntax error'
  #   at t/09-error.t line 25.
  #   'syntax error in filter expression: syntax error'
  # doesn't match '/^(?:parse|syntax) error$/'
  # Looks like you failed 1 test of 10.
 
-- 
Niko Tyni   nt...@debian.org

Bug#843703: please allow users to create multi-user chatrooms

[W. Martin Borgert]

Package: rtc.debian.org
Severity: wishlist

E.g. the maintainers of gajim and their plugins prefer to use
this means of communication (conference.debian.org or similar).

Bug#840416: xine fails to start due to missing libvdpau_i965.so

[Adrian Bunk]

On Tue, Oct 11, 2016 at 02:19:37PM +0200, Michal Hocko wrote:
> Package: xine-ui
> Version: 0.99.9-1.2+b2
> Severity: grave
> 
> I cannot seem to be able to start xine (standalone without any
> particular file to open) due to:
> Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object 
> file: No such file or directory
> vo_vdpau: Can't create vdp device : No vdpau implementation.

The above is normal.

> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  151 (XVideo)
>   Minor opcode of failed request:  17 ()
>   Serial number of failed request:  2868
>   Current serial number in output stream:  2868
>...

What is the output of "xvinfo" (in the x11-utils package)?

Does "xine -V sdl" work?

> Thanks
>...

Thanks
Adrian

-- 

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

Bug#838778: libatk-wrapper-java: crashes JVM when launching a java application

[Michael Weghorn]

The respective assertion is added by Debian patch "check-thread".

For testing purposes, I rebuilt the package without that patch. In that
case, the crash does not occur. (But that probably leads to other
problems...).

Regards,
Michael

Bug#843603: [Pkg-openssl-devel] Bug#843603: openssl fails on sid version to handshake with tls_1.2 to postfix echos ssl_errors

[Kurt Roeckx]

On Tue, Nov 08, 2016 at 04:04:56AM +0100, supp...@opensource-systems.com wrote:
> Package: openssl
> Version: 1.0.2j-1
> Severity: important
> 
>  openssl of Sid fails handshake with postfix and echos ssl_error on mail.log, 
> no mail
>  can be send with TLS_1.2 on Port 465

I can not reproduce your problem. Postfix is working fine for me.

I can connect to it both using the 1.0.2 and 1.1.0 version.
Postfix itself still seems to use 1.0.2 and not really changed
recently.


Kurt

Bug#843432: Pending fixes for bugs in the libwww-curl-perl package

[pkg-perl-maintainers]

tag 843432 + pending
thanks

Some bugs in the libwww-curl-perl package are closed in revision
d83b9f79243f28d9c1f4bc6f2016bc5a4cb859e1 in branch 'master' by
Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libwww-curl-perl.git/commit/?id=d83b9f7

Commit message:

Skip preprocessor symbol only CURL_STRICTER

Fixes "FTBFS: error: 'CURL_STRICTER' undeclared".

Thanks: Niko Tyni 

Closes: #843432

Bug#512804: synaptic: "Search" (Ctrl-F) does not work with umlauts (äöü)

[Oliver Grimm]

Package: synaptic
Version: 0.83+nmu1
Followup-For: Bug #512804

still a bug in 0.83



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.3.1
ii  libapt-pkg5.01.3.1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.2.0-10
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgnutls30  3.5.5-6
ii  libgtk-3-0   3.22.2-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpcre2-8-0 10.22-2
ii  libstdc++6   6.2.0-10
ii  libvte-2.91-00.46.0-1
ii  libx11-6 2:1.6.3-1
ii  libxapian30  1.4.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages synaptic recommends:
ii  gksu   2.0.2-9
ii  libgtk2-perl   2:1.2499-1
ii  policykit-10.105-17
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
ii  deborphan1.7.28.8-0.3
pn  dwww 
ii  menu 2.1.47
ii  software-properties-gtk  0.96.20.2-1
ii  tasksel  3.37

-- no debconf information

Bug#843662: lintian: duplicate warning binary-without-manpage, same warning counts twice

[W. Martin Borgert]

On 2016-11-08 19:10, Niels Thykier wrote:
> Lintian only checks amd64 and i386 atm., which it is why it is twice and
> not more.

This explains it, indeed. Thanks!

It does not complain why I never saw it before, but this can be
explained by my ophthalmologist :~)

> But all in all: It is the problem I suspected.

OK, if it is just that, we should downgrade to minor.

Bug#837450: faumachine: FTBFS with bindnow and PIE enabled

[Stefan Potyra]

Hi Balint,

thanks for the bug report.

I think this is in fact a problem with PIE: FAUmachine uses a just-in-time
compiler based on qemu. This is where the error happens:

  dyngen: unsupported X86_64 relocation (4)

Maybe the fix is as simple as:

diff --git a/configure.ac b/configure.ac
index 980ce16..695ec39 100644
--- a/configure.ac
+++ b/configure.ac
@@ -447,6 +447,7 @@ AC_PROG_CC_OPTION([-fno-strict-aliasing], 
[fm_jit_gen_cflags="${fm_jit_gen_cflag
 AC_PROG_CC_OPTION([-fno-reorder-blocks], 
[fm_jit_gen_cflags="${fm_jit_gen_cflags} -fno-reorder-blocks"])
 AC_PROG_CC_OPTION([-fno-ipa-icf], [fm_jit_gen_cflags="${fm_jit_gen_cflags} 
-fno-ipa-icf"])
 AC_PROG_CC_OPTION([-fno-gcse], [fm_jit_gen_cflags="${fm_jit_gen_cflags} 
-fno-gcse"])
+AC_PROG_CC_OPTION([-fno-gcse], [fm_jit_gen_cflags="${fm_jit_gen_cflags} 
-no-pie"])
 AC_SUBST([fm_jit_gen_cflags])
 
 # Compiler warnings (not needed but nice to have).


However I haven't tested this yet. Hopefully, I find some time this weekend, but
I cannot make any promises :/.

Cheers,
  Stefan.

Bug#843543: [Pkg-tigervnc-devel] Bug#843543: tigervnc: FTBFS with xserver 1.19

[Emilio Pozuelo Monfort]

On 07/11/16 17:40, Ben Hildred wrote:
> 
> 
> On Mon, Nov 7, 2016 at 9:13 AM, Emilio Pozuelo Monfort  > wrote:
> 
> Source: tigervnc
> Version: 1.6.0+dfsg-4
> Severity: important
> 
> Hi,
> 
> I rebuilt your package against xserver 1.19 (2:1.18.99.901-1 to be 
> precise,
> note we have 2:1.18.99.902-1 in experimental now) and it failed to build,
> particularly it failed to apply the patches to the new xserver:
> 
> Hunk #1 succeeded at 161 with fuzz 2 (offset 36 lines).
> Hunk #2 FAILED at 153.
> Hunk #3 FAILED at 215.
> Hunk #4 FAILED at 226.
> 3 out of 4 hunks FAILED -- saving rejects to file os/WaitFor.c.rej
> debian/rules:126: recipe for target
> 'unix/xserver/.apply-patches-vnc-patch-xorg.stamp' failed
> 
> (full log attached)
> 
> I see there is a new upstream release, so it may be good to look at that
> for xserver 1.19 compatibility.
> 
> I have seen a fix for this in the upstream change history. I cannot remember 
> if 
>   it made it into 1.7 or not from the top of my head.

I saw some patches in upstream github too[1]. IIRC they were not in the last
release, but they can probably be backported?

[1]
https://github.com/TigerVNC/tigervnc/commit/3fed95eda27dfbeee6535f987f5d14a66f64749b

Thanks,
Emilio

Bug#843700: amanda-common: missing dependency on perlapi-*

[Niko Tyni]

Package: amanda-common
Version: 1:3.3.9-2
Severity: serious
X-Debbugs-Cc: p...@packages.debian.org

This package contains binary Perl modules but doesn't depend on perlapi-*
(currently perlapi-5.24.1).

Quoting the Debian Perl Policy 4.4.2 ("Binary and Other Architecture
Dependent Modules"):

  Additionally, all binary modules (regardless of their installation
  directory) and any other modules installed into $Config{vendorarch} must
  depend on the expansion of perlapi-$Config{debian_abi} using the Config
  module. If $Config{debian_abi} is empty or not set, $Config{version}
  must be used.

This used to work (since #582220) but seems to have regressed recently
with 1:3.3.9-1 that switched to dh-style debian/rules, dropping the
'dh_perl -a usr/lib/amanda/perl' call. The default dh behaviour doesn't
know where to look for the private directory (which currently seems to
be /usr/lib//amanda/perl). Possibly something like

override_dh_perl:
dh_perl /usr/lib/*/amanda/perl

will do the trick.

Note that this is the root cause for #839603 / #839392: if the package had
had the correct dependencies, it would have been automatically binNMU'd
by the release team along with the other 600+ packages during the Perl
5.24 transition.

Even when this is fixed, partial upgrades of amanda-common from 1:3.3.9-1
without upgrading perl will be a problem, particularly as Ubuntu has
made a release with something based on 1:3.3.9-1. It looks like we need
to add a Breaks on the perl side to make sure broken combinations can't
happen.
-- 
Niko Tyni   nt...@debian.org

Bug#821181: jruby: FTBFS due to PsychParser class error

[Miguel Landaeta]

On Wed, Aug 10, 2016 at 11:58:48PM +0200, Emmanuel Bourg wrote:
> 
> [...] 
> 
> I was a bit reluctant to upgrade again bnd and maven-bundle-plugin for
> stretch but we have a good reason to do it now.

Hi Emmanuel,

I have concluded the only feasible way to get out of this hole with
jruby is to revert yecht its 1.0 behavior. This means to remove
YechtService class from yecht.jar.

I can take care of that.

This way, I can get jruby 1.7.25 building in the archive with
available versions of bnd and maven-bundle-plugin. The remaining hurdle
is to get all its tests passing.

I apologize for basically dropping the ball with jruby maintenance on
this release cycle, but I had too many stuff to deal with in real
life.

My plan here is:

* Hack/patch yecht jar and upload yecht 1.1-2 to get jruby buildable
again.

* Upload jruby 1.7.25-1 to unstable once all tests are passing, to fix
a couple of FTBFS and remaining RC bugs.

* Later (before the freeze), check if it's possible to upload the
latest 1.7.x release (1.7.26).

Unfortunately, this means "stretch" will include a jruby release with
no support from upstream [1].

Cheers,


1. https://github.com/jruby/jruby/issues/4112

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


signature.asc
Description: Digital signature

Bug#843699: ITP: opensvc -- Tools to drive OpenSVC services

[Jean-Michel Kelbert]

Package: wnpp
Severity: wishlist
Owner: "Jean-Michel Kelbert" 

* Package name: opensvc
  Version : 1.8
  Upstream Author : Christophe Varoqui 
* URL : http://www.opensvc.com
* License : GPL
  Programming Lang: Python
  Description : Tools to drive OpenSVC services

OpenSVC is a 'service' manager, as in clustered service manager,
designed for real-world heterogeneous datacenters and large-scale
operations orchestrator (disaster recovery, for example).

Services are collections of resources (virtual machine, ip, disk
groups, filesystems, file synchronizations, and application
launchers).

Services can be started, stopped and queried for status,
providing a consistent command set for wildly different
service integration types.

Service configurations, status and logs are pushed to a
central database coupled to a web front-end (collector).

Services can be administered using the stand-alone
GPLv2 software stack deployed on the nodes
(nodeware), or through the web-front end.

Bug#838997: lintian: checks/init.d: Check for initscripts that source /lib/lsb/init-functions without declaring the corresponding dependency on lsb-base (>= 3.0-6).

[Andreas Henriksson]

Hello Chris,

On Tue, Nov 08, 2016 at 06:56:10PM +, Chris Lamb wrote:
> Hi Andreas,
> 
> > Simply *why* is this error added?
> 
> I added this Lintian check after #838966 was filed against one of my
> packages.
[...]

Thanks for providing this background info.

Though I have to say this only makes me more certain we're heading down
the wrong path here. Consider the case when someone has bind-mounted
enough bits into their chroot that invoke-rc.d starts systemctl
instead of directly invoking the init script. What about upstart (which
is still supported in invoke-rc.d even though I hear upstart is no more)?
And open-rc? And ... ?

I'm hope we agree that because your package ships an init script (|| \
systemd unit || ...) you should not start depending on lsb-base &&
systemd && ... (in other words every init system?! Will it even work
to run systemctl in the chroot talking to systemd outside the chroot
starting things inside the chroot? I'd guess no.)

I'm still hoping we can solve this in one generic place. Without having
thought it through I feel like pointing the finger towards
init-system-helpers (invoke-rc.d and update-rc.d). I would think that
when you run an init-less (aka *buildd*) chroot you would also
have a policy-rc.d rule that disallows running of init-scripts etc. via
invoke-rc.d (and update-rc.d).
Maybe we could even automate that by having the *-rc.d tools auto-detect
we don't have an init system in the chroot and treat that as if a
policy-rc.d rule was in place.
(Someone with experience on how buildd setups and policy-rc.d actually
works would be welcome to hear from here.)

I'm sure there are a bunch of trivial init scripts that will work to
start in a init-less chroot, but I would think it can't be a generally
supportable concept. Likely if you skip the init system you should start
whatever you want to run directly.

Ideas and/or comments welcome.

Regards,
Andreas Henriksson

PS. sorry for both being pessimistic and incapable of writing short
mails.

Bug#828449: net-snmp and openssl 1.1.0

[Robert Story]

On Tue, 1 Nov 2016 18:39:01 +0100 Andreas wrote:
AH> Control: tags -1 + upstream patch
AH> 
AH> Hello!
AH> 
AH> The attached patch (in combination with the fix for #841554)
AH> makes the Debian net-snmp package build against openssl 1.1.0.
AH> This patch has only been compile-tested. No runtime testing. No
AH> guarantees. Please review carefully.
AH> 
AH> (Additional ifdefs likely needed to keep this compiling against
AH> older openssl versions.)

Thanks for attempting a patch. Can you create a bug report and
attach your patch there?


Thanks,
Robert

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 01:33:36PM -0400, Lennart Sorensen wrote:
> And of course I made a typo while copying things into the patch.
> 
> Doing another build test of it now.
> 
> --- vlc-2.2.4.orig/configure.ac   2016-05-31 12:11:07.0 -0400
> +++ vlc-2.2.4/configure.ac2016-11-04 12:22:02.543265439 -0400
> @@ -1422,25 +1422,24 @@
>VLC_SAVE_FLAGS
>AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
>[ac_cv_c_altivec], [
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
>  [#include ]], [
>  [vec_ld(0, (unsigned char *)0);]])], [
> -  ac_cv_c_altivec="-maltivec"
> +  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
>  ], [
>ac_cv_c_altivec="no"
>  ])
>])
> -  VLC_RESTORE_FLAGS
>AS_IF([test "${ac_cv_c_altivec}" != "no"], [
>  CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
>  AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
> are available.])
> -VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> -ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> -VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> +ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}"
> +VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}])
>  have_altivec="yes"
>])
>AC_CHECK_HEADERS(altivec.h)
> +  VLC_RESTORE_FLAGS
>  
>VLC_SAVE_FLAGS
>LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

That did not quite work, so I had to try the slightly more complicated
patch.

This patch works:

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-08 10:28:54.763640362 -0500
@@ -1422,25 +1422,23 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
--- vlc-2.2.4.orig/modules/video_filter/Modules.am  2015-02-02 
14:42:29.0 -0500
+++ vlc-2.2.4/modules/video_filter/Modules.am   2016-11-08 10:28:31.391639060 
-0500
@@ -29,6 +29,7 @@
 libdeinterlace_plugin_la_SOURCES += deinterlace/merge_arm.S
 libdeinterlace_plugin_la_CFLAGS += -DCAN_COMPILE_ARM
 endif
+libdeinterlace_plugin_la_CFLAGS += $(ALTIVEC_CFLAGS)
 video_filter_LTLIBRARIES += libdeinterlace_plugin.la
 
 libdynamicoverlay_plugin_la_SOURCES = \

With this patch, only functions inside a CPU feature check for altivec
support has any vector instructions.

And I realized the reason it was broken is that when using -maltivec and
-O4 (which vlc uses), you get -ftree-vectorize automatically enabled
which means gcc starts to automatically generate vector instructions
all over the place, which is not desired in this case.  It rather defeats
the purpose of having a cpu feature check after all.

-- 
Len Sorensen

Bug#843654: IPV6 support bug - patch included (now really included)

[Alexandre Viau]

On 08/11/16 03:18 PM, Alexandre Viau wrote:
> Hello,
> 
>> PJSIP pj_ioqueue_sendto() fails in exception if addr argument
>> is an IPv6 address and if there is a pending write.
>> This is due to an PJ_ASSERT_RETURN() check not ported for IPv6.
>>
>> This patch adds this support to the check and change
>> the internal write_operation structure to support generic IP
>> addresses.
> 
> The author is Guillaume Roguez 
> (in CC).
> 
> The patch was developed for Ring (https://ring.cx/)
> 
> Please let us know if you have any questions,
> 

Erm.

Now the patch is attached. I promise.

-- 
Alexandre Viau
alexan...@alexandreviau.net
--- a/pjlib/src/pj/ioqueue_common_abs.c	2015-11-05 23:18:46.0 -0500
+++ b/pjlib/src/pj/ioqueue_common_abs.c	2016-10-21 13:49:09.183662433 -0400
@@ -1048,5 +1048,6 @@
  * Check that address storage can hold the address parameter.
  */
-PJ_ASSERT_RETURN(addrlen <= (int)sizeof(pj_sockaddr_in), PJ_EBUG);
+PJ_ASSERT_RETURNpj_sockaddr*)addr)->addr.sa_family == pj_AF_INET() && addrlen <= (int)sizeof(pj_sockaddr_in)) ||
+	 (((pj_sockaddr*)addr)->addr.sa_family == pj_AF_INET6() && addrlen <= (int)sizeof(pj_sockaddr_in6)), PJ_EBUG);
 
 /*
--- a/pjlib/src/pj/ioqueue_common_abs.h	2013-02-21 06:18:36.0 -0500
+++ b/pjlib/src/pj/ioqueue_common_abs.h	2016-10-21 14:04:04.148928591 -0400
@@ -64,5 +64,5 @@
 pj_ssize_t  written;
 unsignedflags;
-pj_sockaddr_in	rmt_addr;
+pj_sockaddr	rmt_addr;
 int			rmt_addrlen;
 };


signature.asc
Description: OpenPGP digital signature

Bug#843694: sbuild: No way to pre-install extra-packages before build

[Felipe Sateler]

On 8 November 2016 at 16:39, Felipe Sateler  wrote:
> Package: sbuild
> Version: 0.72.0-2
> Severity: wishlist
>
> Hi,
>
> I have been trying to run some builds with a modified dpkg, but this
> currently isn't working. sbuild appears to copy the debs to the chroot
> after the initial apt-get update/upgrade, so it will not be
> automatically upgraded.
>
> --chroot-setup-commands= doesn't help because it is also run before
> setting up the apt repository, and --starting-build-commands= is run as
> non-root.
>
> Upon further reading of the manpage, it is explicitly stated that
> --extra-packages is only available for build-dependency resolution, and
> that there is no --$something-command that will run as root but after
> all chroot setup. It would be great to have such a command.

I forgot to add that it is currently possible to --add-depends to
achieve installation, but in the general case where one needs a root command
after injecting the debs (eg, to run some command from the package)
this would not be possible.

-- 

Saludos,
Felipe Sateler

Bug#843695: pnm2ppa FTCBFS: 00_use_env_buildflags.patch causes build tools to be compiled with the host arch compiler

[Helmut Grohne]

Source: pnm2ppa
Version: 1.13-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pnm2ppa fails to cross build from source, because it compiles the build
tool make_hash_ink with the host architecture compiler and then fails
executing it. The cause for this is 00_use_env_buildflags.patch, which
reverts upstream's careful choice of the build architecture compiler.
Reverting 00_use_env_buildflags.patch makes the package cross build.

The goal of that patch is beyond my understanding. The make_hash_ink is
not installed into any package, so it does not matter what build flags
are used. If you really want to force build flags for that tool, you can
use:

export CFLAGS_FOR_BUILD=$(shell dpkg-architecture -a$(DEB_BUILD_ARCH) -c 
dpkg-buildflags --get CFLAGS)

Please consider applying the attached patch (i.e. reverting
00_use_env_buildflags.patch).

Helmut
diff --minimal -Nru pnm2ppa-1.13/debian/changelog pnm2ppa-1.13/debian/changelog
--- pnm2ppa-1.13/debian/changelog   2016-02-26 17:23:49.0 +0100
+++ pnm2ppa-1.13/debian/changelog   2016-11-08 20:31:41.0 +0100
@@ -1,3 +1,10 @@
+pnm2ppa (1.13-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Revert 00_use_env_buildflags.patch (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 08 Nov 2016 20:31:41 +0100
+
 pnm2ppa (1.13-7) unstable; urgency=medium
 
   * Add patch to remove CPP timestamps usage, for reproducibility
diff --minimal -Nru pnm2ppa-1.13/debian/patches/00_use_env_buildflags.patch 
pnm2ppa-1.13/debian/patches/00_use_env_buildflags.patch
--- pnm2ppa-1.13/debian/patches/00_use_env_buildflags.patch 2014-03-06 
14:58:37.0 +0100
+++ pnm2ppa-1.13/debian/patches/00_use_env_buildflags.patch 1970-01-01 
01:00:00.0 +0100
@@ -1,13 +0,0 @@
-Description: Build make_hash_ink natively, hence use the buildflags
-Author: Didier Raboud 
-Last-Update: 2014-03-06
 a/Makefile.am
-+++ b/Makefile.am
-@@ -128,5 +128,5 @@
- LDFLAGS_FOR_BUILD =
- LDLIBS_FOR_BUILD =
- 
--make_hash_ink: make_hash_ink.c
--  $(CC_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD) 
$(LDFLAGS_FOR_BUILD) -o $@ $< $(LDLIBS_FOR_BUILD)
-+noinst_PROGRAMS = make_hash_ink
-+make_hash_ink_SOURCES = make_hash_ink.c
diff --minimal -Nru pnm2ppa-1.13/debian/patches/series 
pnm2ppa-1.13/debian/patches/series
--- pnm2ppa-1.13/debian/patches/series  2016-02-26 17:19:35.0 +0100
+++ pnm2ppa-1.13/debian/patches/series  2016-11-08 20:31:38.0 +0100
@@ -1,4 +1,3 @@
-00_use_env_buildflags.patch
 10_177295-fix_signedness.patch
 99-examples_shbangs.patch
 99-pnm2ppa_manpage.patch

Bug#843685: dpdk: FTBFS: /usr/bin/ld: unrecognized option '-specs=/usr/share/dpkg/no-pie-link.specs'

[Luca Boccassi]

Control: tags -1 pending

On Tue, 08 Nov 2016 18:58:35 + Chris Lamb  wrote:
> Source: dpdk
> Version: 16.07-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> dpdk fails to build from source in unstable/amd64:
> 

Hi,

We did the original upload 2 months ago before the changes in the
default build flags / spec files on dpkg/gcc, so we missed it until this
morning.

We are working on a solution which will hopefully be uploaded tomorrow
or the day after.

Kind regards,
Luca Boccassi


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

Bug#843693: sddm: starting sddm results in white screen with active cursor and keyboard

[Jape Person]

Package: sddm
Version: 0.13.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Installed task-lxqt-desktop. Replacement of lightdm by sddm resulted in 
inability
to log in. Screen presented is all white, but cursor is visible, and keyboard
functions appear to be intact.

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

Reconfigured to use lightdm and was able to log in to the system. Removed 
lightdm,
installed xdm, and that was also successful for logging in.

   * What was the outcome of this action?

Have left system temporarily configured to use xdm until sddm is fixed.

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

Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core)
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 sddm depends on:
ii  adduser 3.115
ii  debconf [debconf-2.0]   1.5.59
ii  libc6   2.24-5
ii  libgcc1 1:6.2.0-10
ii  libpam0g1.1.8-3.3
ii  libqt5core5a5.6.1+dfsg-3+b1
ii  libqt5dbus5 5.6.1+dfsg-3+b1
ii  libqt5gui5  5.6.1+dfsg-3+b1
ii  libqt5network5  5.6.1+dfsg-3+b1
ii  libqt5qml5  5.6.1-11
ii  libqt5quick55.6.1-11
ii  libstdc++6  6.2.0-10
ii  libsystemd0 231-9
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  qml-module-qtquick2 5.6.1-11
ii  sddm-theme-breeze [sddm-theme]  4:5.8.2-1

Versions of packages sddm recommends:
ii  libpam-systemd  231-9

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.2-1

-- debconf information:
* shared/default-x-display-manager: xdm
  sddm/daemon_name: /usr/bin/sddm

Bug#843694: sbuild: No way to pre-install extra-packages before build

[Felipe Sateler]

Package: sbuild
Version: 0.72.0-2
Severity: wishlist

Hi,

I have been trying to run some builds with a modified dpkg, but this
currently isn't working. sbuild appears to copy the debs to the chroot
after the initial apt-get update/upgrade, so it will not be
automatically upgraded.

--chroot-setup-commands= doesn't help because it is also run before
setting up the apt repository, and --starting-build-commands= is run as
non-root.

Upon further reading of the manpage, it is explicitly stated that
--extra-packages is only available for build-dependency resolution, and
that there is no --$something-command that will run as root but after
all chroot setup. It would be great to have such a command.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3.1
ii  libsbuild-perl  0.72.0-2
pn  perl:any

Versions of packages sbuild recommends:
ii  debootstrap  1.0.86

Versions of packages sbuild suggests:
pn  autopkgtest  
pn  deborphan
ii  wget 1.18-4

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

-- no debconf information

Bug#843688: dpdk: maintainer address bounces

[Luca Boccassi]

On Tue, 08 Nov 2016 19:17:49 + Chris Lamb  wrote:
> Source: dpdk
> Version: 2.54+dfsg-7
> Severity: serious
> 
> I tried to report a bug against this package, and I got:
> 
>   Your mail to 'deb-dpdk' with the subject
> 
> Bug#843685: dpdk: FTBFS: /usr/bin/ld: unrecognized option
> '-specs=/usr/share/dpkg/no-pie-link.specs'
> 
>   Is being held until the list moderator can review it for approval.
> 
>   The reason it is being held:
> 
> Post by non-member to a members-only list
> 
> As per Policy §3.3: “The email address given in the ‘Maintainer’ 
> control 
> field must accept mail from those role accounts in Debian used to send 
> automated mails regarding the package. This includes non-spam mail from 
> the bug-tracking system, […].”
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Hi,

Thanks for the heads-up, I didn't realise it was set up that way.

I will ask to open it up and if not possible we'll change it.

Kind regards,
Luca Boccassi


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

Bug#843692: sbuild: extra-packages architecture check emits warnings because it can't find the source debs

[Felipe Sateler]

Package: sbuild
Version: 0.72.0-2
Severity: normal

Hi,

sbuild is generating errors like this when pasing --extra-package:

dpkg-deb: error: failed to read archive 'dpkg_1.18.14+nmu1_i386.deb': No such 
file or directory
E: read_command failed to execute dpkg-deb
Use of uninitialized value $arch in scalar chomp at 
/usr/share/perl5/Sbuild/Build.pm line 1295.
Use of uninitialized value $arch in string ne at 
/usr/share/perl5/Sbuild/Build.pm line 1298.
Use of uninitialized value $arch in string ne at 
/usr/share/perl5/Sbuild/Build.pm line 1298.
Use of uninitialized value $arch in concatenation (.) or string at 
/usr/share/perl5/Sbuild/Build.pm line 1300.
W: Extra package dpkg_1.18.14+nmu1_i386.deb of architecture  cannot be 
installed in the chroot

Enabling debug output suggests the problem is that the program is
executed on the host, but on the wrong directory:

I: /bin/sh -c cd '/home/felipe' && 'dpkg-deb' '--field' 
'dpkg_1.18.14+nmu1_i386.deb' 'Architecture'
D: Running command: /bin/sh -c cd '/home/felipe' && 'dpkg-deb' '--field' 
'dpkg_1.18.14+nmu1_i386.deb' 'Architecture'
dpkg-deb: error: failed to read archive 'dpkg_1.18.14+nmu1_i386.deb': No such 
file or directory
E: read_command failed to execute dpkg-deb

The `cd` needs to be to the original cwd though.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3.1
ii  libsbuild-perl  0.72.0-2
pn  perl:any

Versions of packages sbuild recommends:
ii  debootstrap  1.0.86

Versions of packages sbuild suggests:
pn  autopkgtest  
pn  deborphan
ii  wget 1.18-4

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

-- no debconf information

Bug#843691: glibc: FTBFS on ppc64el: Error: operand out of range

[Fernando Seiti Furusato]

Source: glibc
Version: 2.24-5
Severity: serious

Hello,

glibc is failing to build on ppc64el, on sid with the following:

.../sysdeps/powerpc/powerpc64/power6/memset.S: Assembler messages:
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: operand out of range 
(5 is not between 0 and 1)
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: operand out of range 
(128 is not between 0 and 31)
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: missing operand

This was an attempt with sbuild with sid.
It initially built on the same version on buildd, 20 days ago or so,
but the failure was also observed on cross-compilation.

Thanks.

Fernando

Bug#843689: claws-mail: Next button malfunctioning within thread

[Joe Rowan]

Package: claws-mail
Version: 3.14.1-1
Severity: normal

Clicking on 'Next' button works to move to second item in newsgroup thread but 
does not move to leter items in the thread. The 'N' hotkey works correctly. 

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

Kernel: Linux 4.6.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 claws-mail depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo21.14.6-1.1
ii  libcompfaceg11:1.5.2-5
ii  libdb5.3 5.3.28-12
ii  libdbus-1-3  1.10.12-1
ii  libdbus-glib-1-2 0.108-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-2
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgnutls30  3.5.5-6
ii  libgtk2.0-0  2.24.31-1
ii  libice6  2:1.0.9-1+b1
ii  libldap-2.4-22.4.42+dfsg-2+b3
ii  liblockfile1 1.09-6
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libpisock9   0.12.5-dfsg-2+b2
ii  libsasl2-2   2.1.27~72-g88d82a3+dfsg-1
ii  libsm6   2:1.2.2-1+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2016.06.26-0-0.1
ii  claws-mail-i18n3.14.1-1
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  claws-mail-doc 3.14.1-1
pn  claws-mail-tools   
ii  elinks [www-browser]   0.12~pre6-12
ii  firefox-esr [www-browser]  45.4.0esr-2
ii  gedit  3.22.0-1
ii  konqueror [www-browser]4:16.08.2-1
ii  lynx [www-browser] 2.8.9dev9-1
ii  midori [www-browser]   0.5.11-ds1-4
ii  mousepad   0.4.0-4
ii  netrik [www-browser]   1.16.1-2
ii  qupzilla [www-browser] 1.8.9~dfsg1-3
ii  w3m [www-browser]  0.5.3-32

-- no debconf information

Bug#843675: asn1c-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc-base/asn1c

[Eugene Seliverstov]

> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Hello, Andreas.

Thank you for the report and for the exact policy reference.
It will be fixed with the next package upload.

---
Best regards,
Eugene Seliverstov



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#843662: lintian: duplicate warning binary-without-manpage, same warning counts twice

[Niels Thykier]

Control: tags -1 -moreinfo +confirmed
Control: retitle -1 lintian.d.o: Missing visual clue for arch tags

W. Martin Borgert:
> Quoting Niels Thykier :
>> The website suffers from an issue where it is not clear that (seemly)
>> duplicate tags are actually "once per architecture".  This is not
>> limited to any particular tag and I suspect that is what you are seeing.
> 
> The lintians are also counted twice (but not more) on the tracker:
> 
> https://tracker.debian.org/pkg/zeroinstall-injector (4 issues, should be 2)
> https://tracker.debian.org/pkg/389-dsgw (3 issues, should be 2)
> ...
> 
> If it would be "once per arch" there were many more, not only twice?
> 

Lintian only checks amd64 and i386 atm., which it is why it is twice and
not more.

As for tracker.d.o; it imports a where we basically sum up all instances
of all tags (by "code").  This has the same double counting problem.

But all in all: It is the problem I suspected.

~Niels

Bug#843645: Username unconditionally checked

[Alexandre Viau]

I have discussed with the team and we will be working on a patch.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#843021: work required to get node-yarn into Debian

[Paolo Greppi]

Control: retitle 843021 RFP: node-yarn -- a fast, reliable, and secure
package manager for Node.js

The command:
  npm2deb depends -b -r yarn
currently reports that 38 node modules are missing.

The situation is at the same time somewhat better than that, and much
worse that that.

node-gyp is actually already present
(https://packages.debian.org/sid/node-gyp) this seems to me a npm2deb
bug (see https://github.com/LeoIannacone/npm2deb/issues/34)

Some of the missing modules are being worked at:
- os-homedir, http://bugs.debian.org/841196 ITP open since Tue, 18 Oct 2016
- regenerator-runtime: https://bugs.debian.org/842894 ITP open since
Wed, 2 Nov 2016
- doctrine: http://bugs.debian.org/840925 ITP open since Sun, 16 Oct 2016
- js-tokens: https://bugs.debian.org/842857 ITP open since Tue, 1 Nov 2016
- buffer-shims: http://bugs.debian.org/840920 ITP open since Sun, 16 Oct
2016

Ans some can be skipped:
- cmd-shim: should be required only on windows
- leven: node-fast-levenshtein is in debian and it should be easy to
patch yarn to use that instead (or ask ustream, since fast-levenshtein
seems more popular than leven)
- readable-stream: according to this closed ITP "The Stream module in
nodejs v4.2.1 (LTS) is now stable. ... you can just patch to use stream
instead of readable-stream."

This leaves us with 19 modules.

But one of these is acorn, for which the closed RFA
https://bugs.debian.org/792862 reports:
"... this package depends on browserify ... so getting this packaged may
take some time. ... the package acorn has just been removed from the
Debian archive unstable"

For the other 18 see the attachment.

The conclusion is that this package has to wait for browserify, see
https://bugs.debian.org/780357 and
https://wiki.debian.org/Javascript/Nodejs/Tasks/Browserify


yarn_debian_packaging_todo.ods
Description: application/vnd.oasis.opendocument.spreadsheet


signature.asc
Description: OpenPGP digital signature

Bug#843658: sendmail-cf: Customized sendmail.cf is being overwritten on startup

[Andreas Beckmann]

On 2016-11-08 16:33, Thomas Auge wrote:
> in a recent development, updates started overwriting sendmail.cf, now it
> seems a rebuild is forced on every startup. It's completely unexpected with
> grave implications. Please do not overwrite modified configuration files
> without asking.

Something that appears prominently at the beginning of sendmail.cf (and
that is not a Debian addition):

##
#
#   DO NOT EDIT THIS FILE!  Only edit the source .mc file.
#
##

(The last time I used sendmail (iirc 8.12) in a production environment
about 15 years ago I hacked around in sendmail.mc and various *.m4
files, and had a sendmail.cf generated out of these, but never edited
sendmail.cf manually)

Andreas

Bug#838997: lintian: checks/init.d: Check for initscripts that source /lib/lsb/init-functions without declaring the corresponding dependency on lsb-base (>= 3.0-6).

[Chris Lamb]

Hi Andreas,

> Simply *why* is this error added?

I added this Lintian check after #838966 was filed against one of my
packages.

I did not add it as part of a plan to remove lsb-base, so alas I cannot
comment on the rest of your email. Apologies if you spent some time
crafting those portions.

>  - Having every package shipping an init script depend on additional
>packages […]

(Just as an aside, not every initscript uses /lib/lsb/init-functions.)

> If not, I guess I'll go stick my head in the sand and ignore lintian
> while feeling sorry (and frustrated) for all the people blindly following
> (the often good) advice given by lintian without questioning why they're
> doing so. :/

I share your dislike of noise and/or irrelevant advice from automated
tools. However, please refrain from making these kinds of "I'll take my
toys elsewhere" emotional-based arguments — in my experience, they are
not terribly productive. :)


Best wishes,

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

Bug#842429: RFS: mlocate/0.26-1.1 [NMU]

[Dan Mick]

On 11/08/2016 09:11 AM, Mattia Rizzolo wrote:
> control: owner -1 !
> control: tag -1 moreinfo
> 
> On Fri, Oct 28, 2016 at 09:50:51PM -0700, Dan Mick wrote:
>> I am looking for a sponsor for my package "mlocate"
> 
> o/

Thanks, Mattia.

> (though that template ought to be more clever and don't claim "my
> package" for a NMU :P)

I wondered about that, but the instructions were pretty explicit.  Mongo
only pawn in game of life.

>> https://mentors.debian.net/debian/pool/main/m/mlocate/mlocate_0.26-1.1.dsc
> 
>> mlocate (0.26-1.1) unstable; urgency=medium
>>
>>   * Non-maintainer upload.
>>   * Add cephfs to PRUNEFS and /var/lib/ceph to PRUNEPATHS
>> Closes: #786433
> 
> Now, that .dsc has a lot of noise:
> it creates stuff in .pc and debian/patches, which is completely
> irrelevant for this package that is not debian source format
> '3.0 (quilt)' (it's not specified, hence 1.0), and it's not using any
> patch system
> 
> Am I right that the only relevant change is this?
> 
> diff -u mlocate-0.26/debian/updatedb.conf mlocate-0.26/debian/updatedb.conf
> --- mlocate-0.26/debian/updatedb.conf
> +++ mlocate-0.26/debian/updatedb.conf
> @@ -3,2 +3,2 @@
> -PRUNEPATHS="/tmp /var/spool /media"
> -PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 
> ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf 
> fuse.glusterfs fuse.sshfs curlftpfs"
> +PRUNEPATHS="/tmp /var/spool /media /var/lib/ceph"
> +PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 
> ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf 
> fuse.glusterfs fuse.sshfs curlftpfs ceph fuse.ceph"
> 
> 
> If so, please clean up d/patches and .pc, and rebuild.  Run debdiff on
> the previous version of the package to make sure the thing is clean.

Yep, that's the only relevant change, and I would have sworn it was
quilt.  I'll redo.

> I'd also ask you to close the ubuntu bug too (just add 'LP: #1281074' in
> the changelog), that way when the package will be synced/merged it'll be
> automatically closed (actually, not sure for the "merged" part, but
> anyway…).

Super.  Thanks again.

> Then.. I'd like to rewrite the whole packaging part of that package, but
> this is a NMU and changes should be minimal
> 

Bug#828978: RFS: install-mimic/0.2.0-1 (ITP)

[Peter Pentchev]

On Sat, Aug 27, 2016 at 10:48:24AM -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Hello Peter,
> 
> Here's a few comments and questions on your package (hopefully get the
> ball rolling on sponsorship).

Oof, and here I was thinking I'd answered those... two months ago?
Sorry :(

> 1. This package has a perl and a C version of the program, and you
> install the C one.  Have you considered installing both and using the
> alternatives system to permit the user to choose?

I don't think that there would be any real purpose to that; if there is
a compiled C version available, I don't see why anyone would want/need
the other one.

> 2. Your autopkgtest test suite appears to test the perl version?  Not
> sure -- would be best to add comments to the debian/test/control file.

Not really; as Jakub Wilk pointed out, the autopkgtest suite uses
the upstream source's test suite for testing whatever is installed as
/usr/bin/install-mimic.  The fact that the test suite itself uses
Perl's Test Anything Protocol and prove(1) as the TAP handler is
kind of besides the point.

> 3. If users need to overwrite files installed by Debian packages, they
> should use dpkg-divert and/or dpkg-statoverride.  Perhaps it should be
> stated clearly in the package description that install-mimic should be
> used in combination with those tools.

Hmm, actually the whole point of install-mimic is to avoid having to
even know what dpkg-statoverride is :)  Okay, fine, the whole point of
install-mimic is to avoid hanving to know what install(1)'s arguments
are and what stat(1)/stat(2) does, but you get the idea :)

Nah, you're right, I might add a documentation section about various
tools in various OS/distributions.  However, the main use that I have
for install-mimic is either for configuration files or for files
installed by third-party packages... and, yeah, you're right that
the examples given in the manual page do not really reflect that.
I'll work on it in a future release.

Thanks for trying to get the ball rolling! :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#843683: etm: Doesn't show in GNOME Software

[Jeremy Bicha]

Package: etm
Version: 3.2.27-1

It looks like Debian Stretch's GNOME flavor will ship the Software app
(gnome-software) by default. etm does not show up in the Software app.
Although it ships an appstream metadata file, it uses an old format.
Also, etm should not ship .xpm icons because in my experience, those
icons can confuse the appstream parsers.

https://appstream.debian.org/sid/main/issues/etm.html

https://wiki.debian.org/AppStream/Guidelines

https://www.freedesktop.org/software/appstream/docs/

Thanks,
Jeremy Bicha

Bug#843631: Root cause

[Tristan Seligmann]

Control: retitle 843631 Downstream incompatibilities due to SSL_ST_*
constants not defined in OpenSSL 1.1.0

I think I have it figured out now:

OpenSSL 1.1.0 was uploaded to unstable recently, which no longer defines
(some of?) these SSL_ST_* constants. python-cryptography 1.5.2 was uploaded
and built in unstable prior to this, so it still has the values built into
the binary, but upon rebuilding against the new libssl, they are no longer
present as they cannot be found at build time. My 1.5.3 upload happened to
be the first time the package was rebuilt against libssl1.1, thus
triggering the problem.

This is indeed fixed upstream in pyopenssl 16.2.0[1], where they now
conditionally check for the presence of these constants.

Sandro: I don't think I can fix this properly from the cryptography side
since these constants are actually gone from libssl, but since they only
need to _exist_ and not actually _work_ in order to import the "OpenSSL"
module, I could try to implement a workaround that defines them to some
nonsense value if you think that would be better than waiting on an updated
python-openssl.

I'm also happy to help with preparing the python-openssl update, although I
understand that you may not be interested in further "help" from me right
at the moment.

[1] See https://github.com/pyca/pyopenssl/issues/525

Bug#843645: Username unconditionally checked

[Andrey Gursky]

Hi Alexandre,

On Tue, 8 Nov 2016 13:07:42 -0500
Alexandre Viau  wrote:

> I don't think that this is a bug, unless you point me somewhere in the
> Debian Policy that states that this is indeed a bug.
> 
> We want to make Ring as easy to use as possible for non-technical users,
> and choosing good defaults is important. This is why we check the box by
> default. We also think that looking up usernames as you type is much
> more user friendly.
>
> Please prove me wrong If I am and I will be happy to get this fixed.
>
> There is an ongoing effort to make privacy breaches a part of the Debian
> Policy here:
>  - https://bugs.debian.org/726998
> 
> However, this specific bug only talks about documentation.
> 
> If this is indeed a bug, I would fix it by adding a configure flag to
> the gnome client that would allow changing the default state of the
> checkbox.
> 
> I will wait a little bit for your answer, then I will mark this bug as
> wontfix and close it.

Easy and non-technical but secure? Hmm, it's something really hard to
achieve, if even possible. There is always a trade-off, but if the Ring
projects emphasizes the convenience, then the security part might
suffer...

As the user types? Exactly! But not picking the user's system name and
without to ask send it away. So if you insist on leaving checking by
typing, I'm fully OK with it. But never pick something (possibly
private!) and send it away. So a reasonable compromise would be to not
set a name by default, but leave the field empty. By starting typing
the user is aware, that this will be sent away.

But until secured http get's setup, please add a warning, that the name
will be sent UNencrypyed.

Regards,
Andrey

Bug#843662: lintian: duplicate warning binary-without-manpage, same warning counts twice

[W. Martin Borgert]

Quoting Niels Thykier :

The website suffers from an issue where it is not clear that (seemly)
duplicate tags are actually "once per architecture".  This is not
limited to any particular tag and I suspect that is what you are seeing.


The lintians are also counted twice (but not more) on the tracker:

https://tracker.debian.org/pkg/zeroinstall-injector (4 issues, should be 2)
https://tracker.debian.org/pkg/389-dsgw (3 issues, should be 2)
...

If it would be "once per arch" there were many more, not only twice?

Bug#841406: Fixed, verification in progress

[Nobuhiro Iwamatsu]

Hi,

Thanks for your work!

> Fixed. Next steps would be:
>
> adt-run --unbuilt-tree=limereg --- null
> git tag -s -a debian/1.4.1-1 -m "Release 1.4.1-1"
> git push --all
> git push --tag
>
> But I have a: WARNING: 'automake-1.15' is missing on your system, so I
> cannot verify before creating the tag. Will move my development PC to
> SID, maybe there automake is more recent, would be cleaner anyway.

The easiest way is to migrate the package to debhelper 10. Fix these
problems by migrating.
Please see 0002-10.patch.

Also, version 1.4.1 fails to build with opencv 2.x. I have created a
patch which support opencv 3.x
and 2.x. Could you check this patch?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
From 5e5873c21a52d0374f79a62133a33f5d9d8f088c Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Tue, 8 Nov 2016 00:01:13 +0900
Subject: [PATCH 2/2] Support debhelper 10

Signed-off-by: Nobuhiro Iwamatsu 
---
 debian/compat  | 2 +-
 debian/control | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index 66413f7..38114c4 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: science
 Priority: optional
 Maintainer: Debian Science Maintainers 
 Uploaders: Roelof Berg 
-Build-Depends: debhelper (>= 9), libopencv-dev, libboost-dev, libboost-program-options-dev, doxygen, help2man
+Build-Depends: debhelper (>= 10), libopencv-dev, libboost-dev, libboost-program-options-dev, doxygen, help2man
 Standards-Version: 3.9.6
 Homepage: http://embedded-software-architecture.com/limereg.html
 Vcs-Git: git://anonscm.debian.org/debian-science/packages/limereg.git
-- 
2.10.1

From 08b8ba3b5af921b15f5f9abb994f10c4857acac1 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Tue, 8 Nov 2016 00:59:12 +0900
Subject: [PATCH 1/2] Add support build OpenCV 3

Signed-off-by: Nobuhiro Iwamatsu 
---
 debian/patches/ocv3check | 46 ++
 debian/patches/series|  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 debian/patches/ocv3check
 create mode 100644 debian/patches/series

diff --git a/debian/patches/ocv3check b/debian/patches/ocv3check
new file mode 100644
index 000..65f9d44
--- /dev/null
+++ b/debian/patches/ocv3check
@@ -0,0 +1,46 @@
+diff --git a/configure.ac b/configure.ac
+index 6877b7a..7f55f45 100644
+--- a/configure.ac
 b/configure.ac
+@@ -42,6 +42,7 @@ else
+ fi
+ 
+ HAVE_OPENCV=false
++HAVE_OPENCV3=false
+ PKG_CHECK_MODULES(OPENCV, opencv >= 2.3.1, [HAVE_OPENCV=true], [true])
+ if test x$HAVE_OPENCV = xfalse; then
+   AC_MSG_WARN([*** opencv >= 2.3.1 not found - Cannot build the command line tool, which relies on OpenCV. Only the library will be built, because the lib has no dependency to OpenCV. http://opencvlibrary.sourceforge.net ***])
+@@ -50,8 +51,16 @@ else
+   OPENCV_CFLAGS="$OPENCV_CFLAGS -DOPENCV_PREFIX=`pkg-config opencv --variable=prefix`"
+   #OPENCV_INCLUDE=pkg-config opencv --variable=includedir_old
+   AC_DEFINE([HAVE_OPENCV],[1],[Define to 1 if you have OpenCV >= 2.3.1])
++  # OpenCV 3.x check
++  PKG_CHECK_MODULES(OPENCV3, opencv >= 3, [HAVE_OPENCV3=true], [true])
++  if test x$HAVE_OPENCV3 = xfalse; then
++AC_DEFINE([HAVE_OPENCV3],[0],[Define to 1 if you have OpenCV >= 3])
++  else
++AC_DEFINE([HAVE_OPENCV3],[1],[Define to 1 if you have OpenCV >= 3])
++  fi
+ fi
+ AM_CONDITIONAL([HAVE_OPENCV], [test x$HAVE_OPENCV = xtrue])
++AM_CONDITIONAL([HAVE_OPENCV3], [test x$HAVE_OPENCV3 = xtrue])
+ 
+ #ToDo: Make Boost optional like OpenCV. (Boost_Require takes two arguments if found and if not ...)
+ HAVE_BOOST=false
+diff --git a/exe/Makefile.am b/exe/Makefile.am
+index 15fb25f..1bb8fc2 100644
+--- a/exe/Makefile.am
 b/exe/Makefile.am
+@@ -22,7 +22,12 @@ limereg_CFLAGS += @OPENCV_CFLAGS@
+ limereg_CPPFLAGS += @OPENCV_CFLAGS@
+ #limereg_LDFLAGS += @OPENCV_LDFLAGS@
+ #limereg_LDADD += @OPENCV_LIBS@
++
++if HAVE_OPENCV3
+ limereg_LDADD += -lopencv_highgui -lopencv_core -lopencv_imgcodecs
++else
++limereg_LDADD += -lopencv_highgui -lopencv_core
++endif #HAVE_OPENCV3
+ 
+ #Manpages for the command-line utility
+ if HAVE_HELP2MAN
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..52f6da7
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+ocv3check
-- 
2.10.1

Bug#843645: Username unconditionally checked

[Alexandre Viau]

I don't think that this is a bug, unless you point me somewhere in the
Debian Policy that states that this is indeed a bug.

We want to make Ring as easy to use as possible for non-technical users,
and choosing good defaults is important. This is why we check the box by
default. We also think that looking up usernames as you type is much
more user friendly.

Please prove me wrong If I am and I will be happy to get this fixed.

There is an ongoing effort to make privacy breaches a part of the Debian
Policy here:
 - https://bugs.debian.org/726998

However, this specific bug only talks about documentation.

If this is indeed a bug, I would fix it by adding a configure flag to
the gnome client that would allow changing the default state of the
checkbox.

I will wait a little bit for your answer, then I will mark this bug as
wontfix and close it.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#843334: transition: czmq

[Emilio Pozuelo Monfort]

On 07/11/16 23:04, Luca Boccassi wrote:
> On Sun, 2016-11-06 at 10:44 +, Luca Boccassi wrote:
>> On Sun, 2016-11-06 at 11:01 +0100, Emilio Pozuelo Monfort wrote:
>>> On 06/11/16 00:43, Luca Boccassi wrote:
 On Sat, 5 Nov 2016 22:43:46 + Luca Boccassi  
 wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Dear release team,
>
> czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped
> from 3 to 4.
>
> https://packages.qa.debian.org/c/czmq.html
>
> Reverse dependencies source packages:
>
> rsyslog
>
> The reverse dependency rebuild cleanly without any patches. binNMU
> rebuilds should be all that's needed.
>
> libczmq4 is in experimental and it has rebuilt most architectures,
> with the mips and armv7 queued. I built locally in qemu and it was all
> fine so I do not expect trouble.
>
> I know it's a bit late, but given it's a very simple case I hope it
> can be authorized, to avoid having to maintain an old version for many
> years! Upstream will not release bug fixes for 3.0.x anymore.
>
> Thank you!
>
> Kind regards,
> Luca Boccassi

 Transition tracker item has been autogenerated now, here's the link:

 https://release.debian.org/transitions/html/auto-czmq.html
>>>
>>> Go ahead.
>>>
>>> Cheers,
>>> Emilio
>>
>> Thank you!
>>
>> Will upload tonight as I'm travelling.
>>
>> Kind regards,
>> Luca Boccassi
> 
> Hi,
> 
> I have uploaded czmq 4.0.0-3 to unstable:
> 
> https://packages.qa.debian.org/c/czmq/news/20161107T214955Z.html
> 
> Will rsyslog be rebuilt automatically, or manually by the ftp/release
> team?

Manually by the release team. I scheduled that earlier today.

Cheers,
Emilio

Bug#843678: mirror submission for debian.mirrors.my2pro.com

[Levi Pihema-Lindsay]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.mirrors.my2pro.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-http: /
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Levi Pihema-Lindsay 
Country: US United States
Location: Seattle, Washington
Sponsor: 2Pro International https://2prointl.co
Comment: Mirror's bandwidth is 1Gbps (give or take)

Bug#843677: RM: colt -- ROM; Non-free package colt can be replaced by libcolt-free-java

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

since libcolt-free-java is used in testing for quite some time it might
be time to clean up the package pool from a non-free component.  Thus you
can remove the package colt.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> It's ok, we get it.  You've got an axe to grind, and boy are the sparks
> flying off it thick and hot!

My axe is the same one I often have in Technical Committee
discussions.  It is the axe of challenging the unaccountable power
exercised by despotic Debian package maintainers, within the fiefdoms
of their countless petty autocracies.

My axe is the axe that would chop aside the barriers erected by those
who dislike other people's software, and who use their position to
obstruct and to destroy.  My axe is the axe that would clear the path
for collaboration.

My axe is the axe of freedom for Debian's users and contributors.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#843673: python3-pycodestyle: makes flake8 emit warnings on stdout

[Antonio Terceiro]

Control: severity -1 grave

On Tue, Nov 08, 2016 at 03:29:31PM -0200, Antonio Terceiro wrote:
> Package: python3-pycodestyle
> Version: 2.1.0-1
> Severity: normal
> 
> after upgrading to version of python3-pycodestyle recently uploaded to
> unstable, flake8 now omits some warnings. to reproduce I downgraded only
> python3-pycodestyle:
> 
> $ flake8
> $ sudo apt install python3-pycodestyle/unstable >/dev/null 2>&1
> $ flake8
> "pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
> no attribute 'previous_unindented_logical_line'
> "pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
> no attribute 'previous_unindented_logical_line'
> "pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
> no attribute 'previous_unindented_logical_line'
> "pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
> no attribute 'previous_unindented_logical_line'

actually this breaks flake8, so I am raising the severity:

$ flake8
./squad/api/views.py:21:1: E302 expected 2 blank lines, found 0

$ sudo apt install python3-pycodestyle/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2.1.0-1' (Debian:unstable [all]) for 'python3-pycodestyle'
The following packages will be upgraded:
  python3-pycodestyle
1 upgraded, 0 newly installed, 0 to remove and 41 not upgraded.
Need to get 0 B/39,7 kB of archives.
After this operation, 6.144 B of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 466636 files and directories currently installed.)
Preparing to unpack .../python3-pycodestyle_2.1.0-1_all.deb ...
Unpacking python3-pycodestyle (2.1.0-1) over (2.0.0-1) ...
Setting up python3-pycodestyle (2.1.0-1) ...
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -

$ flake8
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'

(i.e. flake8 no longer finds the style issue in place)


signature.asc
Description: PGP signature

Bug#843530: docker.io: docker broken: oci runtime error: could not synchronize with container process

[Tianon Gravi]

On 8 November 2016 at 01:09, Stef Walter  wrote:
> Nov 08 04:04:29 unassigned-hostname docker[5826]:
> time="2016-11-08T04:04:29-05:00" level=error msg="containerd: start
> container" error="oci runtime error: could not synchronise with
> container process: no subsystem for mount"
> id=4be1274a79c35a25c0ef70a866f4d20b03e5a7bf3cf60131ae49ef0ef11bfb59
> Nov 08 04:04:29 unassigned-hostname docker[5826]:
> time="2016-11-08T04:04:29.430453214-05:00" level=error msg="Handler for
> POST
> /v1.23/containers/4be1274a79c35a25c0ef70a866f4d20b03e5a7bf3cf60131ae49ef0ef11bfb59/start
> returned error: rpc error: code = 2 desc = \"oci runtime error: could
> not synchronise with container process: no subsystem for mount\""

Ouch, looks like we're now hitting
https://github.com/opencontainers/runc/issues/1175, which doesn't
appear to have a Docker or runc workaround yet (although adding
"systemd.legacy_systemd_cgroup_controller=yes" to your system boot
parameters should do the trick for now). :(


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#843674: gocryptfs: FTBFS: "pkg-config": executable file not found in $PATH

[Aaron M. Ucko]

Source: gocryptfs
Version: 1.0-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of gocryptfs in minimal environments (as on the autobuilders)
have been failing:

  pkg-config: exec: "pkg-config": executable file not found in $PATH

Please declare a build dependency on pkg-config, and confirm with
pbuilder or the like that you haven't missed anything else.

Thanks!

FTR, I classified this bug as a regression because it would affect any
binNMUs that might be necessary.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#843662: lintian: duplicate warning binary-without-manpage, same warning counts twice

[Niels Thykier]

Control: tags -1 moreinfo

W. Martin Borgert:
> Package: lintian
> Version: 2.5.49
> 
> Missing manpages are reported twice in some cases:
> 
> https://lintian.debian.org/tags/binary-without-manpage.html
> 
> E.g. for 0install-core, 389-dsgw, aapt, abw2epub and many more.
> 

The website suffers from an issue where it is not clear that (seemly)
duplicate tags are actually "once per architecture".  This is not
limited to any particular tag and I suspect that is what you are seeing.

Thanks,
~Niels

Bug#843671: okular: Okular does not print b/w as requested

[Maximiliano Curia]

Control: tag -1 + upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=252596

¡Hola Heinrich!

El 2016-11-08 a las 18:16 +0100, Heinrich Schuchardt escribió:
Package: okular 
Version: 4:16.08.2-1 
Severity: normal



I open a colored pdf.



In the print dialogue I choose


Optionen -> Einstellungen -> Graustufen 
(options -> settings -> gray scale)



The printout on my HP Deskjet 3630 Series, hpcups 3.16.10 occurs in color.


This is a really old upstream issue. It seems that for some users using a 
different printing backend in cups fixes the issue (that is, switching from a 
hplip driver to a foomatic one). My random guess is that okular is sending the 
option in a way that is interpreted only by some printing drivers.


If possible, please, send a new comment to the upstream bug [1], sometimes a 
little nudge goes a long way.


As an alternative pdf viewer, qpdfview seems to handle printing somewhat 
better (I'm not sure about gray scale, my printer is black and white, :) ), 
although it's in general not as feature full as okular.


Happy hacking,

[1]: https://bugs.kde.org/show_bug.cgi?id=252596
--
"There are two major products that come out of Berkeley: LSD and BSD.
We don't believe this to be a coincidence."
-- Jeremy S. Anderson
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#843669: RFS: eclib/20160720-3

[Julien Puydt]

Hi,

On 08/11/2016 18:30, Mattia Rizzolo wrote:

On Tue, Nov 08, 2016 at 06:22:34PM +0100, Julien Puydt wrote:

* d/copyright looks outdated; at least your own copyright is, but please
  look over all of it.
  + maybe stop mixing tabs and spaces so irregularly too?


I tried to rework it.


well, it surely has a better look now ;)


Good!


* d/rules:
  + could you instead inject the -D_LARGEFILE_SOURCE by using
dpkg-buildflags' means?  (i.e. DEB_CPPFLAGS_MAINT_APPEND variable)
autotools should be able to deal with it correctly even without
passing it at configure time like that.


Well... now you mention it :
(1) it wasn't autotools-based when I made the package, so that might explain
why everything was passed to the "configure" script ;
(2) it's one of the first packages I made, so I might have had no real clue
what I was doing ;
(3) pbuilder says it compiles as well without it!

==> Conclusion: axed!


_LARGEFILE_SOURCE is one of those definition that enables LFS support;
one way to check whether you killed LFS support by it too is to build on
i386 and run lintian with info tags enabled; there is this tag:
https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html


Well, the upload to experimental is to check nothing is broken by my new 
patch, but that will also uncover if that change was bad, won't it?



anyway, --enable-shared --disable-static should be free to go too while
you're on it (I'm not sure off-hand about --disable-static, tbh)


I don't want to ship the static lib, so it's good to have the disabling 
flag, but indeed the enabling one can go : committed (and pushed, for a 
change!).



  + can't that thing be moved over to dh_auto_install instead of
manually calling make?


Well, since the move to autotools, I don't think that is necessary : axed!
And pbuilder is still happy.


by that you also removed the thing that was deleting the *.la, btw.


As far as I remember, upstream's hand-made configure+Makefile.in called 
ldconfig by hand, and installed everything -- that's why I had to remove 
things by hand afterwards. The move to autotools produces a better 
'install' target : the *.la files don't get shipped needlessly 
(something dpkg-deb -c confirms).


Years-old cruft...

Snark on #debian-science

Bug#843631: AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

[Tristan Seligmann]

Hi Sandro,

I appreciate your frustration here, and as the maintainer of
python-cryptography of course I'm responsible when there are issues with
the package.

That said, I did actually test pyopenssl before uploading this version, and
it was working locally; in addition, the diff from 1.5.2 to 1.5.3 is almost
trivial (I've attached it for reference); the HKDF fix is a one line change
plus an added test, and the only other changes are bumping the version
number, so I'm still looking into the actual cause of the problem.

I think the mistake I made when testing locally was that I didn't update my
build chroot first; if the problem is related to newer build-dependencies
(eg. python-cffi) then that would explain why my local package does not
exhibit the problem while the one from the buildds does. (Of course this is
the result of rushing the 1.5.3 update; I do know better than to rush out a
"trivial" update, as these things often turn out to be less trivial than
assumed, but I felt there was some urgency to getting the new package into
unstable as the security issue is more likely to affect users there and I
guess I let this override my better judgement)

I will follow up again once I track down the root cause of the problem.
commit c551c1690dc2ec0a12f779eaab780da45e40d1c6
Author: Tristan Seligmann 
Date:   Tue Nov 8 05:34:19 2016 +0200

Import python-cryptography_1.5.3.orig.tar.gz

diff --git a/CHANGELOG.rst b/CHANGELOG.rst
index 0bfd328..9b0bf29 100644
--- a/CHANGELOG.rst
+++ b/CHANGELOG.rst
@@ -1,6 +1,13 @@
 Changelog
 =
 
+1.5.3 - 2016-11-05
+~~
+
+* **SECURITY ISSUE**: Fixed a bug where ``HKDF`` would return an empty
+  byte-string if used with a ``length`` less than ``algorithm.digest_size``.
+  Credit to **Markus Döring** for reporting the issue.
+
 1.5.2 - 2016-09-26
 ~~
 
diff --git a/PKG-INFO b/PKG-INFO
index 3c67042..9de24de 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 1.1
 Name: cryptography
-Version: 1.5.2
+Version: 1.5.3
 Summary: cryptography is a package which provides cryptographic recipes and primitives to Python developers.
 Home-page: https://github.com/pyca/cryptography
 Author: The cryptography developers
diff --git a/src/cryptography.egg-info/PKG-INFO b/src/cryptography.egg-info/PKG-INFO
index 3c67042..9de24de 100644
--- a/src/cryptography.egg-info/PKG-INFO
+++ b/src/cryptography.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 1.1
 Name: cryptography
-Version: 1.5.2
+Version: 1.5.3
 Summary: cryptography is a package which provides cryptographic recipes and primitives to Python developers.
 Home-page: https://github.com/pyca/cryptography
 Author: The cryptography developers
diff --git a/src/cryptography/__about__.py b/src/cryptography/__about__.py
index 02d6494..6baca0d 100644
--- a/src/cryptography/__about__.py
+++ b/src/cryptography/__about__.py
@@ -14,7 +14,7 @@ __summary__ = ("cryptography is a package which provides cryptographic recipes"
" and primitives to Python developers.")
 __uri__ = "https://github.com/pyca/cryptography;
 
-__version__ = "1.5.2"
+__version__ = "1.5.3"
 
 __author__ = "The cryptography developers"
 __email__ = "cryptography-...@python.org"
diff --git a/src/cryptography/hazmat/primitives/kdf/hkdf.py b/src/cryptography/hazmat/primitives/kdf/hkdf.py
index f738bbd..82ed9b1 100644
--- a/src/cryptography/hazmat/primitives/kdf/hkdf.py
+++ b/src/cryptography/hazmat/primitives/kdf/hkdf.py
@@ -91,7 +91,7 @@ class HKDFExpand(object):
 output = [b""]
 counter = 1
 
-while (self._algorithm.digest_size // 8) * len(output) < self._length:
+while self._algorithm.digest_size * (len(output) - 1) < self._length:
 h = hmac.HMAC(key_material, self._algorithm, backend=self._backend)
 h.update(output[-1])
 h.update(self._info)
diff --git a/tests/hazmat/primitives/test_hkdf.py b/tests/hazmat/primitives/test_hkdf.py
index e33529c..a05fd75 100644
--- a/tests/hazmat/primitives/test_hkdf.py
+++ b/tests/hazmat/primitives/test_hkdf.py
@@ -142,6 +142,17 @@ class TestHKDF(object):
 
 hkdf.verify(b"foo", u"bar")
 
+def test_derive_short_output(self, backend):
+hkdf = HKDF(
+hashes.SHA256(),
+4,
+salt=None,
+info=None,
+backend=backend
+)
+
+assert hkdf.derive(b"\x01" * 16) == b"gJ\xfb{"
+
 
 @pytest.mark.requires_backend_interface(interface=HMACBackend)
 class TestHKDFExpand(object):

Bug#843673: python3-pycodestyle: makes flake8 emit warnings on stdout

[Antonio Terceiro]

Package: python3-pycodestyle
Version: 2.1.0-1
Severity: normal

after upgrading to version of python3-pycodestyle recently uploaded to
unstable, flake8 now omits some warnings. to reproduce I downgraded only
python3-pycodestyle:

$ flake8
$ sudo apt install python3-pycodestyle/unstable >/dev/null 2>&1
$ flake8
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'
"pycodestyle" requested unknown parameters causing 'FileProcessor' object has 
no attribute 'previous_unindented_logical_line'


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

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

Versions of packages python3-pycodestyle depends on:
pn  python3:any  

python3-pycodestyle recommends no packages.

python3-pycodestyle suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ron]

On Tue, Nov 08, 2016 at 04:56:40PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to 
> package a new upstream version"):
> > I made this timeline to show how Ron thinks it is appropriate to deal
> > with this package.
> > 
> > Messages to #574947 and #816924, combined
> > Each # is one email
> > Each P is one email containing a patch or link to updated package
> > Each U is one upload
> 
> I should say that this timeline drastically _under_represents the
> change in Ron's engagement with the technical problems in this
> package, following TC referral.
> 
> Many of his copious mails in the TC thread are each in themselves
> longer than _all his pre-TC mails on this topic combined_ !

It's ok, we get it.  You've got an axe to grind, and boy are the sparks
flying off it thick and hot!

The volume of private mail I've expended, over a much longer period than
is in than is in the public archives, at trying to find a resolution to
this dwarfs anything here too - so you might understand why I'm a little
tired of repeating it to people who are bringing nothing to the table.
Or why I didn't repeat it again to people who opened duplicates of the
original BTS thread.

So please just go take a cold shower or something, instead of wasting
everyone's time bloating this thread with hysterical foaming and
misrepresentation of what I actually said, and what people actually
need, that is irrelevant to us deciding _what_ the best compromise is
for what should be in any future package of this software.

I'm sure there's plenty of other even older bugs in the BTS which haven't
been fixed yet that you could spend some of your overzealousness on if
you're that desperate to vent your rage on things you've never contributed
to, or used, or taken the time to understand.


Unless you're just trying to bury the embarrassment of your previous
hasty post under a mountain of stuff people's eyes will glaze over on.
In which case, knock yourself out.  I guess.  It's your permanent record.

But I've got Real Work to do, and we've got a release freeze looming,
and wasting time on being bullied by you isn't helping any of that.

Bug#838900: Fix for the varnish FTBFS

[Adrian Bunk]

Control: tags -1 patch

The problem seems to be that dh_auto_install is overriden,
instead of dh_auto_install-arch.

The fix for that is:

--- debian/rules.old2016-11-08 17:02:45.0 +
+++ debian/rules2016-11-08 17:12:40.0 +
@@ -52,7 +52,7 @@
 override_dh_auto_configure:
dh_auto_configure -- $(LOCAL_CONFIGURE_FLAGS)
 
-override_dh_auto_install:
+override_dh_auto_install-arch:
dh_auto_install -a
install -d debian/tmp/etc/varnish
install -T -m 0644 etc/example.vcl debian/tmp/etc/varnish/default.vcl


cu
Adrian

-- 

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

Bug#843672: RM: sga [i386 armel armhf mips mipsel s390x] -- ROM; Build depends python-pysam missing on some architectures

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

since the build dependency python-pysam is missing on some architectures
sga itself needs to be removed from these architectures as well.

Thanks for your work as ftpmaster

Andreas.

Bug#843669: RFS: eclib/20160720-3

[Julien Puydt]

Hi,

On 08/11/2016 17:55, Mattia Rizzolo wrote:

control: owner -1 !
control: tag -1 moreinfo

On Tue, Nov 08, 2016 at 05:40:45PM +0100, Julien Puydt wrote:

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


o/


Vcs-Git:
https://anonscm.debian.org/git/debian-science/packages/eclib.git


* please kill the dh-autoreconf build-dep


Done.


* d/copyright looks outdated; at least your own copyright is, but please
  look over all of it.
  + maybe stop mixing tabs and spaces so irregularly too?
* d/rules:


I tried to rework it.


  + could you instead inject the -D_LARGEFILE_SOURCE by using
dpkg-buildflags' means?  (i.e. DEB_CPPFLAGS_MAINT_APPEND variable)
autotools should be able to deal with it correctly even without
passing it at configure time like that.


Well... now you mention it :
(1) it wasn't autotools-based when I made the package, so that might 
explain why everything was passed to the "configure" script ;
(2) it's one of the first packages I made, so I might have had no real 
clue what I was doing ;

(3) pbuilder says it compiles as well without it!

==> Conclusion: axed!


  + can't that thing be moved over to dh_auto_install instead of
manually calling make?


Well, since the move to autotools, I don't think that is necessary : 
axed! And pbuilder is still happy.



  - I cleaned d/rules with a rusty axe.


:)



I thought I might have cut a bit too much... now I don't think there's 
much to remove. Still, if you think there's still some left, I'll gladly 
give another swing. *g*


Thanks,

Snark on #debian-science

Bug#843671: okular: Okular does not print b/w as requested

[Heinrich Schuchardt]

Package: okular
Version: 4:16.08.2-1
Severity: normal

Dear Maintainer,

I open a colored pdf.

In the print dialogue I choose 

Optionen -> Einstellungen -> Graustufen
(options -> settings -> gray scale)

The printout on my HP Deskjet 3630 Series, hpcups 3.16.10 occurs in color.

Best regards

Heinrich Schuchardt


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

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

Versions of packages okular depends on:
ii  kde-runtime 4:16.08.2-1
ii  libc6   2.24-5
ii  libfreetype62.6.3-3+b1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libkdecore5 4:4.14.25-1
ii  libkdeui5   4:4.14.25-1
ii  libkexiv2-114:15.04.3-1
ii  libkio5 4:4.14.25-1
ii  libkparts4  4:4.14.25-1
ii  libkprintutils4 4:4.14.25-1
ii  libkpty44:4.14.25-1
ii  libokularcore7  4:16.08.2-1
ii  libphonon4  4:4.9.0-4
ii  libpoppler-qt4-40.44.0-3
ii  libqca2 2.1.1-2
ii  libqimageblitz4 1:0.0.6-4
ii  libqmobipocket1 4:16.08.0-1
ii  libqt4-dbus 4:4.8.7+dfsg-9
ii  libqt4-declarative  4:4.8.7+dfsg-9
ii  libqt4-svg  4:4.8.7+dfsg-9
ii  libqt4-xml  4:4.8.7+dfsg-9
ii  libqtcore4  4:4.8.7+dfsg-9
ii  libqtgui4   4:4.8.7+dfsg-9
ii  libsolid4   4:4.14.25-1
ii  libspectre1 0.2.8-1
ii  libstdc++6  6.2.0-10
ii  phonon  4:4.9.0-4
ii  zlib1g  1:1.2.8.dfsg-2+b3

Versions of packages okular recommends:
ii  cups-bsd  2.2.1-1

Versions of packages okular suggests:
ii  ghostscript9.19~dfsg-3.1
ii  jovie  4:16.08.0-1
pn  okular-extra-backends  
ii  poppler-data   0.4.7-7
pn  texlive-binaries   
pn  unrar  

-- no debconf information

Bug#842429: RFS: mlocate/0.26-1.1 [NMU]

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Fri, Oct 28, 2016 at 09:50:51PM -0700, Dan Mick wrote:
> I am looking for a sponsor for my package "mlocate"

o/

(though that template ought to be more clever and don't claim "my
package" for a NMU :P)

> https://mentors.debian.net/debian/pool/main/m/mlocate/mlocate_0.26-1.1.dsc

> mlocate (0.26-1.1) unstable; urgency=medium
> 
>   * Non-maintainer upload.
>   * Add cephfs to PRUNEFS and /var/lib/ceph to PRUNEPATHS
> Closes: #786433

Now, that .dsc has a lot of noise:
it creates stuff in .pc and debian/patches, which is completely
irrelevant for this package that is not debian source format
'3.0 (quilt)' (it's not specified, hence 1.0), and it's not using any
patch system

Am I right that the only relevant change is this?

diff -u mlocate-0.26/debian/updatedb.conf mlocate-0.26/debian/updatedb.conf
--- mlocate-0.26/debian/updatedb.conf
+++ mlocate-0.26/debian/updatedb.conf
@@ -3,2 +3,2 @@
-PRUNEPATHS="/tmp /var/spool /media"
-PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 
ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf 
fuse.glusterfs fuse.sshfs curlftpfs"
+PRUNEPATHS="/tmp /var/spool /media /var/lib/ceph"
+PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 
ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf 
fuse.glusterfs fuse.sshfs curlftpfs ceph fuse.ceph"


If so, please clean up d/patches and .pc, and rebuild.  Run debdiff on
the previous version of the package to make sure the thing is clean.

I'd also ask you to close the ubuntu bug too (just add 'LP: #1281074' in
the changelog), that way when the package will be synced/merged it'll be
automatically closed (actually, not sure for the "merged" part, but
anyway…).


Then.. I'd like to rewrite the whole packaging part of that package, but
this is a NMU and changes should be minimal

-- 
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#843520: [akonadi-server] Fails to start after mysql upgrade

[Lars Tangvald]

Send the below to the incorrect address (it's largely rendered moot by the 
discussion about the kubuntu patch, but including it anyway):

The change in the MySQL default was made because the old default (unrestricted) 
was considered a potential security risk.
However, we also backported having NULL as a valid value for this, which would 
disable import/export operations unless user configures it differently.
 
Also note that the secure-file-priv option existed in older versions of MySQL 
as well, it just had a different default value (blank), so a config patch for 
akonadi would be backwards-compatible (but NULL would not be a valid option).

--
Lars

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Tue, 8 Nov 2016 15:33:32 +1030 Ron  wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading the bugs and your emails.
> 
> And "your opinion" still hasn't said even a single word to show that you
> understand the technical problem here, or to offer any solution to it.
> The problem which doesn't just magically go away regardless of who might
> implement it.

Even if your technical concerns were correct, they do not justify your
handling of the package. Saying that your actions have been wrong, and
the package needs to be handled differently, does not require
addressing the technical CGI issues in any way. You have no basis to
insist that people care about the CGI issue or try to solve it before
commenting on other handling of the package.


> > If you indeed welcome opinions from people like me, your statements
> > above are a little odd.
> 
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions" - because if this is all you have to offer then
> no, "opinions" from people "like you" are neither helpful nor welcome.
> Even if they 100% agree with me.  They are just a toxic symptom of people
> still ignoring the hard technical problem.

"The problem" here is the way you've blocked the package at an ancient
version. Fixing this does not require creating a perfect CGI framework
or in any other way fixing all upstream issues and making the software
perfect. Maybe _you_ really care about the CGI issue. But if nobody -
including you - cares enough to create a perfect solution, then it'll
be broken. Too bad, but even if you're really disappointed, holding the
package indefinitely at an obsolete version is not an acceptable
response. Again, that nobody has created a perfect upstream does not
justify your handling of the package, and you don't get to blame others
or call their behavior "toxic" because of that.


> details of _what_ we ought to do.  If we don't solve that, then who does
> it is kind of irrelevant, there'll still be a Hard Problem that someone
> won't be happy with.

You keep talking about Hard Problems and how others must solve them to
be allowed to criticize your actions or actually do anything to change
the status quo that you've failed to improve for several years. That's
bullshit. If someone packages a new upstream without solving those
issues, that'll be perfectly acceptable. Fixing software to be perfect
is not a requirement for packaging, and creating a package that lacks
some desired functionality when upstream lacks it is OK. The way you've
handled the package is not OK.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> I made this timeline to show how Ron thinks it is appropriate to deal
> with this package.
> 
> Messages to #574947 and #816924, combined
> Each # is one email
> Each P is one email containing a patch or link to updated package
> Each U is one upload

I should say that this timeline drastically _under_represents the
change in Ron's engagement with the technical problems in this
package, following TC referral.

Many of his copious mails in the TC thread are each in themselves
longer than _all his pre-TC mails on this topic combined_ !

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#840393: [Pkg-fonts-devel] Bug#840393: Bug#840393: mensis: FTBFS with newly released fontforge

[Adrian Bunk]

On Wed, Oct 12, 2016 at 10:15:34PM +0530, Vasudev Kamath wrote:
>...
> Hideki Yamane  writes:
>...
> >  However, if we'll fix header inclusion, still get failure...
> >
> > libtool: link: gcc -o makenomenh -g -O2 
> > -fdebug-prefix-map=/mensis-0.0.080507=. -fPIE -fstack-protector-strong 
> > -Wformat -Werror=format-security -Wmissing-prototypes -Wunused -Wimplicit 
> > -Wreturn-type -Wparentheses -Wformat -Wchar-subscripts -Wsequence-point 
> > -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" 
> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
> > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> > -D_NO_XINPUT=1 -D_NO_XKB=1 ./.libs/makenomenh.o  -lgdraw -lgutils 
> > -lgunicode -lSM -lICE -lX11 -ldl -lgif -lm 
> > /usr/lib/x86_64-linux-gnu/libfreetype.so 
> > ./.libs/makenomenh.o: In function `handleint':
> > ././makenomenh.c:81: undefined reference to `grealloc'
> > ./.libs/makenomenh.o: In function `makenomenh':
> > ././makenomenh.c:160: undefined reference to `grealloc'
> > ././makenomenh.c:161: undefined reference to `grealloc'
> > collect2: error: ld returned 1 exit status
> > Makefile:49: recipe for target 'mensis-en.ui' failed
> > make[1]: *** [mensis-en.ui] Error 1
> 
> Here it looks like the problem is in mensis?. I mean grealloc undefined
> reference is raising from makenomenh.c which is part of mensis. But I do
> agree the headers are slightly messed which can be reported to fontforge
> upstream. A quick google shows grealloc is defined in graphviz library
> is it a dependency for mensis?.. ¹
> 
> ¹ 
> http://www.graphviz.org/pub/graphviz/development/doxygen/html/common_2memory_8c.html#a1912ff27e68202cc621674540faa4198

In unstable this is provided by:
  /usr/include/fontforge/basics.h:extern void *grealloc(void *,long size);

cu
Adrian

-- 

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