Bug#849196: Sometimes, supress_warnings misses one of its attributes

2016-12-23 Thread Ole Streicher
Just to show an extremal case:

https://buildd.debian.org/status/fetch.php?pkg=skimage&arch=all&ver=0.12.3-3&stamp=1482501775

has this 15 times.

This is a regression; it did not happen with 1.11. Please fix this
regression ASAP so that skimage can migrate safely before the freeze.

Best

Ole



Bug#849203: libasound2: ALSA_PCM_DEVICE environment variable is ignored

2016-12-23 Thread Leszek Godlewski
Package: libasound2
Version: 1.1.2-1
Severity: normal

Dear Maintainer,

I have a PC with two on-board Intel HD Audio chips using the same driver. One 
of them outputs SPDIF to the HDMI connector, the other - to a separate 
SPDIF/analog jack. These chips are visible as separate cards:

inequation@BrixPro:~$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: ALC269VC Digital [ALC269VC Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

For most applications, the HDMI output is preferred and is set to be the 
default:

inequation@BrixPro:~$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
hdmi:CARD=HDMI,DEV=0
HDA Intel HDMI, HDMI 0
HDMI Audio Output
hdmi:CARD=HDMI,DEV=1
HDA Intel HDMI, HDMI 1
HDMI Audio Output
hdmi:CARD=HDMI,DEV=2
HDA Intel HDMI, HDMI 2
HDMI Audio Output
dmix:CARD=HDMI,DEV=3
HDA Intel HDMI, HDMI 0
Direct sample mixing device
dmix:CARD=HDMI,DEV=7
HDA Intel HDMI, HDMI 1
Direct sample mixing device
dmix:CARD=HDMI,DEV=8
HDA Intel HDMI, HDMI 2
Direct sample mixing device
dsnoop:CARD=HDMI,DEV=3
HDA Intel HDMI, HDMI 0
Direct sample snooping device
dsnoop:CARD=HDMI,DEV=7
HDA Intel HDMI, HDMI 1
Direct sample snooping device
dsnoop:CARD=HDMI,DEV=8
HDA Intel HDMI, HDMI 2
Direct sample snooping device
hw:CARD=HDMI,DEV=3
HDA Intel HDMI, HDMI 0
Direct hardware device without any conversions
hw:CARD=HDMI,DEV=7
HDA Intel HDMI, HDMI 1
Direct hardware device without any conversions
hw:CARD=HDMI,DEV=8
HDA Intel HDMI, HDMI 2
Direct hardware device without any conversions
plughw:CARD=HDMI,DEV=3
HDA Intel HDMI, HDMI 0
Hardware device with all software conversions
plughw:CARD=HDMI,DEV=7
HDA Intel HDMI, HDMI 1
Hardware device with all software conversions
plughw:CARD=HDMI,DEV=8
HDA Intel HDMI, HDMI 2
Hardware device with all software conversions
default:CARD=PCH
HDA Intel PCH, ALC269VC Analog
Default Audio Device
sysdefault:CARD=PCH
HDA Intel PCH, ALC269VC Analog
Default Audio Device
front:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Front speakers
surround21:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Digital
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Direct sample mixing device
dmix:CARD=PCH,DEV=1
HDA Intel PCH, ALC269VC Digital
Direct sample mixing device
dsnoop:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Direct sample snooping device
dsnoop:CARD=PCH,DEV=1
HDA Intel PCH, ALC269VC Digital
Direct sample snooping device
hw:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Direct hardware device without any conversions
hw:CARD=PCH,DEV=1
HDA Intel PCH, ALC269VC Digital
Direct hardware device without any conversions
plughw:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Hardware device with all software conversions
plughw:CARD=PCH,DEV=1
HDA Intel PCH, ALC269VC Digital
Hardware device with all software conversions
inequation@BrixPro:~$ cat /etc/asound.conf
defaults.pcm.card 0
defaults.pcm.device 3

However, for some applications, I'd rather have their playback directed to the 
jack (i.e. card #1). The ALSA environment variables ALSA_PCM_CARD and 
ALSA_PCM_DEVICE should be doing the trick; and while ALSA_PCM_CARD does work, 
ALSA_PCM_DEVICE does not. See /usr/share/alsa/alsa.conf.

What makes me suspect that is the case is this piece of an mplayer failed 
playback log:

inequation@BrixPro:~$ ALSA_PCM_CARD=1 ALSA_PCM_DEVICE=0 mplayer test.mp3
(...)
[AO_ALSA] alsa-lib: pcm_hw.c:1601:(snd_pcm_hw_open) open '/dev/snd/pcmC1D3p' 
failed (-2): No such file or directory
(...)

Please note the device path that refers to device #3, which is set as default 
in 

Bug#849204: jupyter-nbextension-jupyter-js-widgets: fails to configure

2016-12-23 Thread Norbert Preining
Package: jupyter-nbextension-jupyter-js-widgets
Version: 5.2.2-2
Severity: grave
Justification: renders package unusable

Hi all,

thanks for taking up the incredible complex job of packaging sagemath,
that is very much appreciated.

Unforunately, the above package does not configure:
Unpacking sagemath-jupyter (7.4-3) ...
Setting up jupyter-nbextension-jupyter-js-widgets (5.2.2-2) ...
/usr/lib/python3.5/runpy.py:125: RuntimeWarning: 'notebook.nbextensions' found 
in sys.modules after import of package 'notebook', but prior to execution of 
'notebook.nbextensions'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
Enabling notebook extension jupyter-js-widgets/extension...
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 1176, in 

main()
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 267, 
in launch_instance
return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
658, in launch_instance
app.start()
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 961, in 
start
super(NBExtensionApp, self).start()
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 256, 
in start
self.subapp.start()
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 871, in 
start
self.toggle_nbextension(self.extra_args[0])
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 861, in 
toggle_nbextension
logger=self.log)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 407, in 
enable_nbextension
logger=logger)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 345, in 
_set_nbextension_state
cm.update(section, {"load_extensions": {require: state}})
  File "/usr/lib/python3/dist-packages/traitlets/config/manager.py", line 85, 
in update
data = self.get(section_name)
  File "/usr/lib/python3/dist-packages/traitlets/config/manager.py", line 63, 
in get
return json.load(f)
  File "/usr/lib/python3.5/json/__init__.py", line 268, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.5/json/__init__.py", line 319, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.5/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.5/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
dpkg: error processing package jupyter-nbextension-jupyter-js-widgets 
(--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of sagemath-jupyter:
 sagemath-jupyter depends on jupyter-nbextension-jupyter-js-widgets; however:
  Package jupyter-nbextension-jupyter-js-widgets is not configured yet.

Thanks

Norbert


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

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

Versions of packages jupyter-nbextension-jupyter-js-widgets depends on:
ii  python2.7.13-1
ii  python-notebook   4.2.3-3
ii  python3   3.5.1-4
ii  python3-notebook  4.2.3-3

jupyter-nbextension-jupyter-js-widgets recommends no packages.

Versions of packages jupyter-nbextension-jupyter-js-widgets suggests:
ii  python-ipywidgets   5.2.2-2
ii  python3-ipywidgets  5.2.2-2

-- no debconf information



Bug#849205: libgd-barcode-perl: Please depend on libgd-perl instead of virtual packages

2016-12-23 Thread Jeremy Bicha
Package: libgd-barcode-perl
Version: 1.15-6

libgd-barcode-perl depends on libgd-gd2-noxpm-perl | libgd-gd2-perl
but both those packages were removed from Debian. They are now virtual
packages provided by libgd-perl so please depend on libgd-perl
directly instead.

Thank you,
Jeremy Bicha



Bug#848903: Bug#848394: Bug#848903: metastudent: autopkgtests fail since 2016-12-05

2016-12-23 Thread merlettaia
Hi Andreas,
This bug slightly differs from #848394.It relates to newer version of
blast2 packages, for now it seems that it appeared because blast2 output
has changed.
For now it is clear that this error message in metastudent run log:

Error: number of fastas and blasts dont match: 3 1

- appeared because blast database search results returned file with no
line "BLASTP", which is used to parse blast search results. I'm
working to fix this.




2016-12-23 12:32 GMT+03:00 Andreas Tille :

> On Tue, Dec 20, 2016 at 08:15:48PM +0100, Andreas Tille wrote:
> > I just notice a commit from Tanya so according to the commit log
> > the issue seems to be solved. :-)  (Well done! ;-) )
>
> Hmm, I notice that while #848394 is really done bug #848903 with the
> failed tests was not addressed.  Tanya, I think you confirmed some fix
> via mail but did you really commited the change to SVN or am I missing
> something?
>
> Kind regards and thanks for your contribution anyway
>
> Andreas.
>
> --
> http://fam-tille.de
>



-- 
Best wishes,
Tanya.


Bug#849208: Nvidia driver does not use DPMS

2016-12-23 Thread Richard B. Kreckel
Package: nvidia-driver
Version: 375.20-4

The screen blanks, but the backlight is never turned off.

It seems like DPMS is not enabled?
$ xset -q
[...]
DPMS (Energy Star):
  Standby: 0Suspend: 0Off: 0
  DPMS is Disabled

This is the card:
$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208
[GeForce GT 730] [10de:1287] (rev a1)

DPMS used to work on the same hardware when it was still running jessie.



Bug#833925: nfs-kernel-server: no_root_squash broken on amd64

2016-12-23 Thread Martin B
Control: merge -1 783212

This is almost certainly another special case of Bug #783212. 
I have tested the export line 
/home   -no_subtree_check 10.0.0.1(ro,no_root_squash,sync)
matching the original bug report with version 1.2.8-9 on
jessie/i386 and jessie/amd64. In both cases no_root_squash was overwritten
by a default security flavour containing root_squash as detailed in 
Bug #783212, leading to "Permission denied" errors.
I strongly suspect a configuration difference on the used amd64 and i386 
systems as the reason the bug was reported against amd64 only. To make 
absolutely sure it would be necessary to see the exact export lines, the 
output of exportfs -v and the contents of /var/lib/nfs/etab on both a
non-working amd64 as well as a working i386 system.

Regards
   Martin B



Bug#849205: Pending fixes for bugs in the libgd-barcode-perl package

2016-12-23 Thread pkg-perl-maintainers
tag 849205 + pending
thanks

Some bugs in the libgd-barcode-perl package are closed in revision
548ff197648e18583893bbe7d32f431cd9393aeb in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libgd-barcode-perl.git/commit/?id=548ff19

Commit message:

Add real package libgd-perl as first alternative in Depends.

Thanks: Jeremy Bicha for the bug report.
Closes: #849205



Bug#849168: pbuilder: Expect programe reported "no more ptys" and failed in rebuilding gcc with normal (non-root) user

2016-12-23 Thread James Clarke
reassign 849168 debootstrap
forcemerge 817236 849168
thanks

Hi,
> On 23 Dec 2016, at 06:24, Xiangyu LIU  wrote:
> 
> Package: pbuilder
> Version: 0.227
> Severity: minor
> 
> Dear Pbuilder Maintainers,
> 
>   I want to rebuild locally gcc-5 and gcc-4.9 in current stretch by pbuilder.
> 
> 
>   I download the source of gcc-5 (Debian) and gcc-4.9 (from Ubuntu) and 
> rebuild by "sudo pbuilder build gcc-x.dsc".
>   But building failed with reporting:
>  "The system has no more ptys. Ask your system administrator to create 
> more."
>  "while executing"
>  "spawn ls"
> 
>   I gave a try in Pbuilder with root user:
>   # expect -c "spawn ls"
>   It is OK to output "spawn ls"
> 
>   But when I type above command with normal user:
>   rleigh@WFA256:/$ expect -c "spawn ls"
> spawn ls
>The system has no more ptys.  Ask your system 
> administrator to create more.
>while executing
>"spawn ls"
>   rleigh@WFA256:/$
> 
>   I check the /dev/pts, it was mounted in Pbuilder (with both root/normal 
> users):
>   rleigh@WFA256:/$ mount | grep pts
>none on /dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> 
>   root@WFA256:/# mount | grep pts
>none on /dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> 
> 
>   I have same issue in sbuild if I rebuild gcc by:
>  $ sbuild -d stretch gcc-.dsc
> 
>   But it is OK if rebuild with root user:
>  $ sudo sbuild -d stretch gcc-.dsc
> 
> 
>   Yes I can rebuild gcc by sudo sbuild, but I don't know what is happening in 
> Pbuilder or Sbuild with normal user.
>   Any comment or advice would be very appreciated !

This is a known issue with debootstrap (#817236 as mentioned above)
which affects any tool trying to use a chroot. Josch, I'm curious as to
why you tagged the corresponding sbuild bug report (Cc'd) as
unreproducible; are you using debootstrap from stable? Anyway, I suggest
you also merge the build bug with the debootstrap one.

Regards,
James


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

2016-12-23 Thread Scott Kitterman
On Friday, December 23, 2016 02:16:21 PM you wrote:
> Package: postfix-pcre
> Followup-For: Bug #845750
> 
> I take back what I said this morning:
> the downgrade did NOT solved the problem
> 
> actually, here is the kind of errors I had in the mail.info file:
> 
> Dec 23 12:40:43 cerber postfix/cleanup[11472]: warning: unsupported
> dictionary type: pcre (no/postfix-pcre.so.1.0.1: No such file or directory)
> 
> and what I did not noticed, is the "no/..." when trying to load the file
> 
> my problem is I had the following in the main.cf
> shlib_directory = no
> 
> which is apparently something that I picked up from the following ticket
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815070#26
> 
> so, I just had to be replace with the right directory:
> shlib_directory = /usr/lib/postfix
> 
> 
> and now, everything's fine
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (90, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16-2-486
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages postfix-pcre depends on:
> ii  libc6 2.24-8
> ii  libpcre3  2:8.39-2
> ii  postfix   3.1.3-6
> 
> postfix-pcre recommends no packages.
> 
> postfix-pcre suggests no packages.
> 
> -- no debconf information



Bug#849205: Pending fixes for bugs in the libgd-barcode-perl package

2016-12-23 Thread Jeremy Bicha
On Fri, Dec 23, 2016 at 10:29 AM,
 wrote:
> Commit message:
>
> Add real package libgd-perl as first alternative in Depends.

Why are you keeping the alternate dependencies? They do not exist in
Debian stable (or unstable).

Thanks,
Jeremy Bicha



Bug#849174: RM: open-build-service [amd64 i386 arm64 armhf mips mips64el mipsel ppc64el s390] -- ANAIS; All binary packages that built from source package open-build-service no longer built on amd64,

2016-12-23 Thread Moritz Muehlenhoff
On Fri, Dec 23, 2016 at 04:49:25PM +0800, Andrew Lee (李健秋) wrote:
> Package: ftp.debian.org
> Severity: normal

Also needed for s390x, isn't it?

Cheers,
Moritz 



Bug#848180: konsole: Includes application name in window title when configured not to do so

2016-12-23 Thread Maximiliano Curia

Control: tag -1 + confirmed
Control: reassign -1 src:kxmlgui 5.8.0-1
Control: affects -1 konsole
Control: severity -1 normal

¡Hola Aaron!

El 2016-12-13 a las 19:49 -0500, Aaron Schrab escribió:
Package: konsole 
Version: 4:16.08.3-1 
Severity: minor


After unchecking the "Show application name on the titlebar" option in the 
Configure Konsole dialog it still inludes " - Konsole" at the end of window 
titles. This occurs even after closing all Konsole windows and restarting the 
application.


I first observed this with version 4:16.08.2-2 of both the konsole and 
konsole-kpart packages. I upgraded both of those to 4:16.08.3-1 from unstable 
to check if the issue was still present (and I again made sure to close all 
windows after the upgrade). Before I installed the version from testing 
yesterday I hadn't used this package in long time, so I can't say how long this 
bug has existed.


I can reproduce the issue, this seems to be a issue in kxmlgui rather than 
konsole. konsole calls setCaption or setPlainCaption depending on the value of 
the user setting, the first on documents that it would add the application 
name, and the second one that it wouldn't, but sadly this is no longer true ( 
since this was ported to qt5), as setCaption is implemented as a single call 
to setPlainCaption (and the responsible for adding the application name in the 
title is the qt qpa plugin).


The setCaption and setPlainCaption documentation can be seen here:
https://cgit.kde.org/kxmlgui.git/tree/src/kmainwindow.h

While the implementation can be seen here:
https://api.kde.org/frameworks/kxmlgui/html/kmainwindow_8cpp_source.html

The qt documentation for setWindowTitle can be found here:
http://doc.qt.io/qt-5/qwidget.html#windowTitle-prop

kxmlgui is missing a way to workaround the setWindowTitle use of the qpa 
plugin, this may need to be scale to qtbase.


Happy hacking,
--
"The sooner you start to code, the longer the program will take."
-- Roy Carlson
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Bug#849209: RFP: python-xbee -- XBee serial communication API for Python

2016-12-23 Thread Georges Khaznadar
Package: wnpp
Severity: wishlist

* Package name: python-xbee
  Version : 2.2.3
  Upstream Author : Paul Malmsten 
* URL : https://github.com/nioinnovation/python-xbee
* License : MIT
  Programming Lang: Python
  Description : XBee serial communication API for Python

 XBee provides an implementation of the XBee serial communication API.
 It allows one to easily access advanced features of one or more XBee
 devices from an application written in Python. It provides a semi-complete
 implementation of the XBee binary API protocol and allows a developer
 to send and receive the information they desire without dealing with the
 raw communication details.

I use this package to build automata for my pupils and communicate
with them by RF. This package is not yet a dependency for any other
Debian package, but it may become one later.



Bug#849161: closed by Andreas Tille (Bug#849161: fixed in snap 2013-11-29-5)

2016-12-23 Thread Jeremy Bicha
Thank you for your quick and gracious response!

While looking through the Ubuntu diff, I noticed that the autopkgtest
needs to be updated too. I'm attaching a simple patch for that.

Thanks,
Jeremy
=== modified file 'debian/tests/run-unit-test'
--- debian/tests/run-unit-test  2016-12-23 15:34:24 +
+++ debian/tests/run-unit-test  2016-12-23 15:36:28 +
@@ -5,6 +5,6 @@
   ADTTMP=`mktemp -d /tmp/${pkg}-test.XX`
 fi
 cd $ADTTMP
-snap /usr/share/snap/HMM/thale /usr/share/doc/${pkg}/examples/DNA/thale.dna.gz
-snap /usr/share/snap/HMM/worm  /usr/share/doc/${pkg}/examples/DNA/worm.dna.gz
+snap-hmm /usr/share/snap/HMM/thale 
/usr/share/doc/${pkg}/examples/DNA/thale.dna.gz
+snap-hmm /usr/share/snap/HMM/worm  
/usr/share/doc/${pkg}/examples/DNA/worm.dna.gz
 



Bug#849210: ntopng: fails to start

2016-12-23 Thread Aaron M. Ucko
Package: ntopng
Version: 2.4+dfsg1-1
Severity: important

As of version 2.4, ntopng fails to start on my system.  I'm not sure
what specifically is going wrong; all I see in ntopng.log is

23/Dec/2016 10:38:43 [Ntop.cpp:1121] Setting local networks to 127.0.0.0/8
23/Dec/2016 10:38:43 [Redis.cpp:92] Successfully connected to redis 
127.0.0.1:6379@0
23/Dec/2016 10:38:43 [Ntop.cpp:1095] Parent process is exiting (this is normal)

System logs additionally show the ndpi "INTERNAL ERROR" from
https://github.com/ntop/ntopng/issues/638, but AFAICT this error
shouldn't be fatal, and rebuilding ndpi with upstream's patch applied
made no difference.

Could you please take a look?

Thanks!

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

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

Versions of packages ntopng depends on:
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libcurl3-gnutls  7.50.1-1
ii  libgcc1  1:6.2.1-5
ii  libgeoip11.6.9-4
ii  libhiredis0.13   0.13.3-2
ii  libjson-c3   0.12.1-1.1
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libmariadbclient18   10.0.28-2
ii  libndpi4 1.8-1
ii  libpcap0.8   1.8.1-3
ii  librrd8  1.6.0-1+b1
ii  libsqlite3-0 3.15.2-1
ii  libstdc++6   6.2.1-5
ii  libzmq5  4.1.5-2
ii  lsb-base 9.20161125
ii  ntopng-data  2.4+dfsg1-1
ii  redis-server 3:3.2.6-1
ii  zlib1g   1:1.2.8.dfsg-4

ntopng recommends no packages.

Versions of packages ntopng suggests:
pn  geoip-database-contrib  

-- no debconf information



Bug#849211: Installing gives multiple errors

2016-12-23 Thread James Cloos
Package: mtpolicyd
Version: 2.02-1
Severity: important

On one mx I got:

insserv: warning: script 'opendkim.service' missing LSB tags and
overrides
Starting postfix policy server: mtpolicydcould not initialize plugin
greylist: install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in
@INC (you may need to install the DBD::SQLite module) (@INC contains:
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1
/usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24
/usr/share/perl/5.24 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base) at (eval 460) line 3.
Perhaps the DBD::SQLite perl module hasn't been fully installed,
or perhaps the capitalisation of 'SQLite' isn't right.
Available drivers: CSV, DBM, ExampleP, File, Gofer, Pg, Proxy, Sponge.
 at /usr/share/perl5/Mail/MtPolicyd/Connection/Sql.pm line 27.
 failed!
invoke-rc.d: initscript mtpolicyd, action "start" failed.
dpkg: error processing package mtpolicyd (--configure):
 subprocess installed post-installation script returned error exit
status 2
Errors were encountered while processing:
 mtpolicyd
E: Sub-process /usr/bin/dpkg returned an error code (1)

On another I got:

Starting postfix policy server: mtpolicydArgument "0.33_01" isn't
numeric in numeric lt (<) at
/usr/share/perl5/Net/Server/Log/Sys/Syslog.pm line 42.
.

and it hung.  I had to kill(1) the apt-get process from another
terminal.

Manually stopping and starting via the init.d script gives:

Argument "0.33_01" isn't numeric in numeric lt (<) at
/usr/share/perl5/Net/Server/Log/Sys/Syslog.pm line 42.


So, at the very least it should depend on libdbd-sqlite3-perl.

I haven’t figured out where the 0.33_01 comes from.

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

Kernel: Linux 3.2.0-4-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: sysvinit (via /sbin/init)

Versions of packages mtpolicyd depends on:
ii  adduser3.115
ii  libcache-memcached-perl1.30-1
ii  libconfig-general-perl 2.63-1
ii  libdbi-perl1.636-1+b1
ii  libmail-rbl-perl   1.10-1
ii  libmoose-perl  2.1806-1
ii  libmoosex-getopt-perl  0.71-1
ii  libmoosex-role-parameterized-perl  1.09-1
ii  libmoosex-singleton-perl   0.29-1
ii  libnamespace-autoclean-perl0.28-1
ii  libtie-ixhash-perl 1.23-2
ii  lsb-base   9.20161125
ii  perl   5.24.1~rc4-1

Versions of packages mtpolicyd recommends:
pn  libdbd-sqlite3-perl   
ii  libgeo-ip-perl1.50-1+b1
ii  libjson-perl  2.90-1
ii  libmail-spf-perl  2.9.0-4
ii  libnet-ldap-perl  1:0.6500+dfsg-1
ii  libnet-server-perl2.008-3
pn  libtime-piece-mysql-perl  

mtpolicyd suggests no packages.

-- no debconf information


Bug#849168: pbuilder: Expect programe reported "no more ptys" and failed in rebuilding gcc with normal (non-root) user

2016-12-23 Thread Johannes Schauer
Hi James,

Quoting James Clarke (2016-12-23 16:27:02)
> Josch, I'm curious as to why you tagged the corresponding sbuild bug report
> (Cc'd) as unreproducible; are you using debootstrap from stable?

I did not anticipate that I would have to first re-create my existing Stretch
chroot to be able to reproduce the bug. Thus, I used my existing chroot which
was created in the past with an older version of debootstrap.

> Anyway, I suggest you also merge the build bug with the debootstrap one.

Can you be more precise of what you want me to merge?

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#849174: RM: open-build-service [amd64 i386 arm64 armhf mips mips64el mipsel ppc64el s390] -- ANAIS; All binary packages that built from source package open-build-service no longer built on amd64,

2016-12-23 Thread Scott Kitterman
On Friday, December 23, 2016 04:34:53 PM Moritz Muehlenhoff wrote:
> On Fri, Dec 23, 2016 at 04:49:25PM +0800, Andrew Lee (李健秋) wrote:
> > Package: ftp.debian.org
> > Severity: normal
> 
> Also needed for s390x, isn't it?
> 
> Cheers,
> Moritz

Done.  It would have been nice if the original bug had included that.

Scott K



Bug#849154: ITP: xattrvi -- easily view and edit extended filesystem attributes in user-namespace

2016-12-23 Thread Jonas Große Sundrup
Am 23.12.2016 um 09:47 schrieb bugs-deb...@antipoul.fr:
>> * URL : https://github.com/cherti/mailexporter
> The correct URL seems to be https://github.com/cherti/xattrvi

Oops, you are absolutely right. Slipup of mine when filing the ITP, it
it will be correct in the package. Thanks for pointing out!


> Interesting piece of software though.

Thanks, I'll try to still get it into stretch, we'll see. :)


  ~ Jonas



Bug#849168: pbuilder: Expect programe reported "no more ptys" and failed in rebuilding gcc with normal (non-root) user

2016-12-23 Thread James Clarke
> On 23 Dec 2016, at 15:49, Johannes Schauer  wrote:
> 
> Hi James,
> 
> Quoting James Clarke (2016-12-23 16:27:02)
>> Josch, I'm curious as to why you tagged the corresponding sbuild bug report
>> (Cc'd) as unreproducible; are you using debootstrap from stable?
> 
> I did not anticipate that I would have to first re-create my existing Stretch
> chroot to be able to reproduce the bug. Thus, I used my existing chroot which
> was created in the past with an older version of debootstrap.

That must be an old chroot..!

>> Anyway, I suggest you also merge the build bug with the debootstrap one.
> 
> Can you be more precise of what you want me to merge?

# reassign 849169 debootstrap
# forcemerge 817236 849169
(I did the above for 849168 in my previous mail)

#817236 is the debootstrap bug which is merged with existing
pbuilder/sbuild/schroot bugs and is marked as affecting
pbuilder/sbuild/schroot.

Regards,
James



Bug#841610: fixed in statsmodels 0.8.0~rc1+git59-gef47cd9-1

2016-12-23 Thread Yaroslav Halchenko
On December 23, 2016 6:07:19 AM EST, Sebastiaan Couwenberg  
wrote:
>Hi Yaroslav,
>
>On 11/28/2016 02:38 PM, Yaroslav Halchenko wrote:
>> On Sun, 27 Nov 2016, Sebastiaan Couwenberg wrote:
>> 
>>> This bug is not fixed on i386 yet where the build failed due the
>various
>>> test failures, specifically:
>> 
>>>  ValueError: I/O operation on closed file
>> 
>>> Is work in progress to fix this issue on i386 too?
>> 
>> this particular one iirc is due to a bug in pandas, which was fixed
>but
>> build on i386 fails for other reason due to PyTables [1], which I
>will
>> ask to be included in debian package after (re)solution accepted
>> upstream.  Then hopefully we would get to the finishing line with
>> pandas, and thus statsmodels
>> 
>> [1] https://github.com/PyTables/PyTables/pull/587
>
>I see that the PR was merged, is a fix for the Debian package in the
>works?
>
>pandas and its reverse dependencies are still marked for removal from
>testing on January 5th, which is also the date for the Soft Freeze
>after
>which removed packages won't be allowed back into testing.
>
>No having pandas and geopandas in stretch would be sad.
>
>Kind Regards,
>
>Bas

I will look into those two later today... If you like to help - try updating 
packaging to the recent master of stats models?



Bug#849125: [debian-mysql] Bug#849125: mariadb-connector-c: Fix include of my_stmt.h

2016-12-23 Thread Georg Richter
Fix pushed to connector_c_2.2 branch, 3.0 (master) was not affected.

commit 1deacd5782b9dc041c50f7359d24eaef9ba8f5a5
Author: Georg Richter 
Date:   Fri Dec 23 16:53:14 2016 +0100

Fix for debian Bug#849125: fix include of my_stmt.h

/Georg


On Thu, Dec 22, 2016 at 8:24 PM, Andre Nathan  wrote:

> Package: mariadb-connector-c
> Version: 2.3.1-1
> Severity: important
>
> Hi,
>
> The mysql.h file has an #include directive as such:
>
> #include 
>
> This causes an error in C programs that include "mysql.h", making the
> library unusable. There's an upstream fix
> (https://jira.mariadb.org/browse/CONC-143) that claims to have made it
> into version 2.2.0 of the connector, but it seems the error has crept
> back in.
>
> The fix is really simple, replacing the include statement above with
>
> #include "my_stmt.h"
>
> Thanks.
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
>



-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab


Bug#809081: konsole: Crash on mouse movement

2016-12-23 Thread Maximiliano Curia

¡Hola Diederik!

El 2015-12-27 a las 02:49 +0100, Diederik de Haas escribió:
Package: konsole 
Version: 4:15.08.3-1 
Severity: normal


I was using my mouse in vim in a Konsole window and it suddenly crashed. 
As it wasn't on 'exit' this time, I'm filing a separate bug for it. 
This is just the first time I experienced it and there's a reasonable 
chance that I can't reproduce it. If it turns out I can, I'll report 
back.


This looks a lot like https://bugs.kde.org/show_bug.cgi?id=353911 as it 
also involves a mouse action and the stack traces look very similar. 
Unfortunately it doesn't contain much info besides the stack trace.



If you want more information, just ask.


Upstream closed the issue as yet another qt issue regarding qscreen and xcb 
(https://bugreports.qt.io/browse/QTBUG-42985), which should have been fixed in 
qt 5.5. Are you still being able to reproduce the issue? If not, it would be 
better to close the issue.


Happy hacking,
--
"Email is a wonderful thing for people whose role in life is to be on top of
things. But not for me; my role is to be on the bottom of things. What I do
takes long hours of studying and uninterruptible concentration."
-- Donald Knuth
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Bug#849212: msgpuck: CVE-2016-9036: Invalid handling of map16 format in mp_check()

2016-12-23 Thread Salvatore Bonaccorso
Source: msgpuck
Version: 1.0.3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/rtsisyk/msgpuck/issues/12

Hi,

the following vulnerability was published for msgpuck.

CVE-2016-9036[0]:
Invalid handling of map16 format in mp_check()

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9036
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9036
[1] https://github.com/rtsisyk/msgpuck/issues/12
[2] http://www.talosintelligence.com/reports/TALOS-2016-0254/

Regards,
Salvatore



Bug#847750: rmysql: FTBFS on mips64el

2016-12-23 Thread Radovan Birdic
Hi,

I tried to build rmysql package on my local machine (mips64el) and got the same 
error.
When I manually execute this command in chroot, error does not occur:

echo "#include " |  gcc -std=gnu99  -I/usr/include/mariadb 
-I/usr/include/mariadb/mysql -g -O2 
-fdebug-prefix-map=/build/mariadb-connector-c-dopxmU/mariadb-connector-c-2.3.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wunused -Wno-uninitialized -E -xc - >/dev/null 2>&1

But running debian/rules binary-arch the error still appears.


Regards,
Radovan


Bug#848907: frequent crashes of Xorg

2016-12-23 Thread Andrei Mikhailov
I discovered that the very same Debian installation runs perfectly stable on 
Inter hardware:

Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)

This reinforces my suspicion that the problem lies with Radeon drivers.

On Tue, 20 Dec 2016 15:38:42 -0200 Andrei Mikhailov  wrote:
> Package: base
> 
> Frequent crashes of Xorg , usually when switching windows but sometimes
> spontaneously.
> 
> Debian testing (squeeze) with systemd, Linux 4.8.0-2-amd64 x86_64
> VGA compatible controller AMD/ATI Radeon HD4250
> using packages:  xserver-xorg-video-radeon firmware-amd-graphics
> 
> Crashes started after the following update:
> 
> 2016-12-19 09:57:13 upgrade xserver-xorg-input-evdev:amd64 1:2.10.4-1
> 1:2.10.4-1+b1
> 2016-12-19 09:57:16 upgrade xserver-xorg-video-ati:amd64 1:7.8.0-1
> 1:7.8.0-1+b1
> 2016-12-19 09:57:20 upgrade xserver-xorg-video-mach64:amd64 6.9.5-1+b1
> 6.9.5-1+b2
> 2016-12-19 09:57:23 upgrade xserver-xorg-video-tdfx:amd64 1:1.4.6-2
> 1:1.4.6-2+b1
> 2016-12-19 09:57:26 upgrade xserver-xorg-video-cirrus:amd64 1:1.5.3-1+b1
> 1:1.5.3-1+b2
> 2016-12-19 09:57:29 upgrade xserver-xorg-video-amdgpu:amd64 1.2.0-1
> 1.2.0-1+b1
> 2016-12-19 09:57:33 upgrade xserver-xorg-video-vesa:amd64 1:2.3.4-1+b1
> 1:2.3.4-1+b2
> 2016-12-19 09:57:36 upgrade xserver-xorg-video-radeon:amd64 1:7.8.0-1
> 1:7.8.0-1+b1
> 2016-12-19 09:57:40 upgrade xserver-xorg-video-trident:amd64 1:1.3.7-2
> 1:1.3.7-2+b1
> 2016-12-19 09:57:45 upgrade xserver-xorg-video-vmware:amd64 1:13.2.1-1
> 1:13.2.1-1+b1
> 2016-12-19 09:57:49 upgrade xserver-xorg-video-neomagic:amd64 1:1.2.9-1
> +b1 1:1.2.9-1+b2
> 2016-12-19 09:57:53 upgrade xserver-xorg-video-openchrome:amd64 1:0.3.3
> +git20160310-1 1:0.3.3+git20160310-1+b1
> 2016-12-19 09:57:58 upgrade xserver-xorg-video-mga:amd64 1:1.6.4-2
> 1:1.6.4-2+b1
> 2016-12-19 09:58:03 upgrade xserver-xorg-video-savage:amd64 1:2.3.8-2
> 1:2.3.8-2+b1
> 2016-12-19 09:58:08 upgrade xserver-xorg-video-fbdev:amd64 1:0.4.4-1+b4
> 1:0.4.4-1+b5
> 2016-12-19 09:58:12 upgrade xserver-xorg-video-nouveau:amd64 1:1.0.13-1
> 1:1.0.13-1+b1
> 2016-12-19 09:58:17 upgrade xserver-xorg-video-qxl:amd64 0.1.4-3+b1
> 0.1.4+20161126git4d7160c-1
> 2016-12-19 09:58:21 upgrade xserver-xorg-video-r128:amd64 6.10.1-2
> 6.10.1-2+b1
> 2016-12-19 09:58:26 upgrade xserver-xorg-video-intel:amd64 2:2.99.917
> +git20161105-1 2:2.99.917+git20161105-1+b1
> 2016-12-19 09:58:34 upgrade xserver-xorg-input-mouse:amd64 1:1.9.2-1
> 1:1.9.2-1+b1
> 2016-12-19 09:58:39 upgrade xserver-xorg-input-synaptics:amd64 1.9.0-1
> 1.9.0-1+b1
> 2016-12-19 09:58:45 upgrade xserver-xorg-input-wacom:amd64 0.33.0-1
> 0.33.0-1+b1
> 2016-12-19 09:58:51 upgrade xserver-xorg-input-libinput:amd64 0.22.0-1
> 0.22.0-1+b1
> 2016-12-19 09:58:58 upgrade xserver-xorg-core:amd64 2:1.18.4-2
> 2:1.19.0-2
> 2016-12-19 10:00:39 upgrade xserver-common:all 2:1.18.4-2 2:1.19.0-2



Bug#848964: RFS: node-rx 4.1.0

2016-12-23 Thread Paolo Greppi
Hi,

now that all dependencies are in I have packaged node-rx, see the ITP I
am CC-ing and the repo:
https://anonscm.debian.org/git/pkg-javascript/node-rx.git/

Please someone more experienced than me review it and if it's OK sponsor
its upload.

Thanks,

Paolo



Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25

2016-12-23 Thread Niko Tyni
Control: retitle -1 libapache2-mod-perl2: FTBFS: test failures with Apache 
2.4.25
Control: tag -1 patch

@apache2 maintainers (cc'd): it seems that mod_perl is no longer able
to 'inject headers' with apache2 2.4.25. See below. A workaround is to
explicitly configure the server for 'unsafe' behaviour. Is mod_perl just
doing something "wrong" at the moment, or is the whole feature something
that should not be possible anymore?

On Thu, Dec 22, 2016 at 05:17:34PM +0100, gregor herrmann wrote:
> On Thu, 22 Dec 2016 17:23:24 +0200, Niko Tyni wrote:
> 
> > Package: libapache2-mod-perl2
> > Version: 2.0.10-1
> > Severity: serious

> From the apache2 changelog:
> 
>   * Security: CVE-2016-8743:
> Enforce HTTP request grammar corresponding to RFC7230 for request lines
> and request headers, to prevent response splitting and cache pollution by
> malicious clients or downstream proxies.
>   * The stricter HTTP enforcement may cause compatibility problems with
> non-conforming clients. Fine-tuning is possible with the new
> HttpProtocolOptions directive.

Indeed, these changes seem to be the cause for the two new test failures.

> >   # Failed test 1 in t/apache/read.t at line 52

> >   request has failed (the response code was: 400)

This one is trivial: in t/apache/read.t

-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",

Patch attached.

The other failure seems to be harder. The test is installing a "filter"
on the request headers and injecting new header lines on the server
side. The client code is t/filter/in_bbs_inject_header.t and the server
side is in t/filter/TestFilter/in_bbs_inject_header.pm.

  # ./t/TEST -trace=debug t/filter/in_bbs_inject_header.t
  [...]
  request has failed (the response code was: 400)
  see t/logs/error_log for more details
  t/filter/in_bbs_inject_header.t .. Dubious, test returned 255 (wstat 65280, 
0xff00)
  Failed 36/36 subtests 
 
>From t/logs/error_log:

  [  debug]  input filter called -
  [  debug] filter read:
  [
  ]
  [  debug] END of original HTTP Headers
  [  debug] queued header [X-Extra-Header2: Value 2
  ]
  [  debug] queued header [X-Extra-Header3: Value 3
  ]
  [  debug] queued header [
  ]
  [  debug] injected header: [X-Extra-Header2: Value 2
  ]
  [Fri Dec 23 16:05:28.968699 2016] [core:debug] [pid 15527:tid 
139982245197568] protocol.c(957): (22)Invalid argument: [client 
127.0.0.1:53182] Failed to read request header line X-Extra-Header2: Value 2
  [Fri Dec 23 16:05:28.968717 2016] [core:debug] [pid 15527:tid 
139982245197568] protocol.c(1313): [client 127.0.0.1:53182] AH00567: request 
failed: error reading the headers

It looks to me like the server is checking back on the received request
and noticing that the injected header was not there originally. The
400 response is certainly not caused by anything in the request itself;
a plain GET request gets the same response as well.

This passage in RFC 7230, section 9.4., seems relevant:

   A more effective mitigation is to prevent anything other than the
   server's core protocol libraries from sending a CR or LF within the
   header section, which means restricting the output of header fields to
   APIs that filter for bad octets and not allowing application servers
   to write directly to the protocol stream.

I would expect mod_perl to be classified as a 'core protocol library' in
this sense, but I have no idea yet if it's just doing something wrong.

Patch attached to revert to the old "unsafe" behaviour in the virtual
host specific to this test.
-- 
Niko Tyni   nt...@debian.org
>From f4dd0394f0975892b51a889f023d0e207553a656 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Fri, 23 Dec 2016 18:27:23 +0200
Subject: [PATCH 1/2] Fix t/apache/read.t HTTP syntax for Apache 2.4.25
 compatibility

HTTP/1.1 RFC 7230, section 2.6. "Protocol Versioning" says the HTTP name
is case sensitive. Starting with Apache 2.4.25, using lower case will
make the server issue a 400 Bad request response, causing a test failure.

https://tools.ietf.org/html/rfc7230#section-2.6

Bug-Debian: https://bugs.debian.org/849082
---
 t/apache/read.t | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/apache/read.t b/t/apache/read.t
index 83670c9..9f7f504 100644
--- a/t/apache/read.t
+++ b/t/apache/read.t
@@ -24,7 +24,7 @@ close $fh;
 
 my $size = length $data;
 
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
 "Content-length: $size",
 "") {
 my $line = "$string\r\n";
-- 
2.11.0

>From edd3ca5e9f2666e8e4936ac98446d94a5907c137 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Fri, 23 Dec 2016 18:31:01 +0200
Subject: [PATCH 2/2] Fix/workaround t/filter/in_bbs_inject_header.t failure
 with Apache 2.4.25

Since Apache 2.4.25, header injection fails with

  protocol.c(957): (22)Invalid argument: [client 127.0.0.1:53182] Failed to read request header line X-Extr

Bug#849213: Update watch file (attached)

2016-12-23 Thread Osamu Aoki
Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: normal

Well ... 1.0.8 just released.

And 1.0.6 is still in experimental.

Please update the watch file with the attached file.  Then we should be
able to keep up with the upstream better :-)

Osamu

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

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

Versions of packages arduino depends on:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  default-jre [java6-runtime]2:1.8-57
ii  libjna-java4.2.2-2
ii  librxtx-java   2.2pre2-13
ii  openjdk-8-jre [java6-runtime]  8u111-b14-3

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-4
ii  policykit-1  0.105-17

arduino suggests no packages.

-- no debconf information
version=4
opts="\
dversionmangle=s/.dfsg(?:\d[-\d\.]*)//,\
filenamemangle=s/(?:.*\/)?(\d[\d\.]*)\.tar\.gz/arduino-$1.tar.gz/" \
https://github.com/arduino/Arduino/tags (?:.*/)(\d[\d\.]*)\.tar\.gz debian 
uupdate


Bug#849214: ITP: fonts-ldco -- set of Hebrew fonts by Louis Davis & Co.

2016-12-23 Thread Tzafrir Cohen
Package: wnpp
Severity: wishlist
Owner: Tzafrir Cohen 

* Package name: fonts-ldco
  Version : 0.3.20161223
  Upstream Author : Louis Davis & Co.
* URL : 
http://www.ldcodesign.com/%D7%98%D7%99%D7%A4%D7%95%D7%92%D7%A8%D7%A4%D7%99%D7%94/
* License : OFL 1.1
  Programming Lang: Fonts (TTF, OTF, WOFF)
  Description : set of Hebrew fonts by Louis Davis & Co.
 set of 20 Hebrew fonts by Louis Davis and Co. in OTF, TTF, and WOFF
 formats.
 .
 Fonts: Daniel, Eco, Hidekel, Josef, Kimchi, Miso, Neo, Sticks,
 YamSuf, Strokes, Mixer, Patch Serif, Patch Sans, Patch Stencil,
 Lilach, Amit, Noam, Har Sinai, Saiphan and Skechers.

Note: homepage is Hebrew only. Initial packaging, for an earlier
version:

  https://git.tzafrir.org.il/cgit/fonts-ldco.git/

Those fonts, while provided under OTF, only include a limited number of
glyphs (basically Hebrew and numbers). They are indeed quite useful for
writing "artistic" text, but may not be usable for more professional
settings. The design studio intends to provide improved versions of
those under a proprietary license.

Is that acceptable for inclusion into Debian?



Bug#849216: Packages which FTBFS with AssertionError about len(context)

2016-12-23 Thread Santiago Vila
Package: checkbox-ng,dhcpcanon,ipywidgets,nbsphinx,pylibmc
Severity: serious

Dear maintainer:

The following packages currently FTBFS in testing:

checkbox-ng
dhcpcanon
ipywidgets
nbsphinx
pylibmc

with an AssertionError like this:


looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 12%] behaviors

Exception occurred:
  File "/usr/lib/python2.7/dist-packages/docutils/writers/_html_base.py", line 
671, in depart_document
assert not self.context, 'len(context) = %s' % len(self.context)
AssertionError: len(context) = 1


There are build logs available in the reproducible builds site.
For example:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/checkbox-ng.html

Is this a bug in those packages or is there a build-dependency
which broke all of them?

Please advise about what to do. If those are all different bugs
I will have to file separate bugs, but before that I want to be sure.

OTOH, if they are the same bug and there is only one package to fix,
please tell me so that I can reassign and use "affects".

Thanks.



Bug#849215: encfs: 1.9.1-3 not a drop in replacement for previous version

2016-12-23 Thread Felix Lechner
Package: encfs
Version: 1.9.1-3
Severity: important

When an encrypted home directory is on kerberized NFS4, upgrading to version 
1.9.1-3 in testing causes errors not present in the previous version.
Logging in via terminal works, but not via GNOME/gdm 3.

Also, at some point an error appears when accessing the cleartext mountpoint. 
Then the "Transport endpoint is not connected" (even though
the default idle unmount setting was disabled in /etc/security/pam_encfs.conf). 
Furthemore, some subsequent mount attempts via PAM seem to trigger
segfaults like the ones below. It is currently unclear if the idle override is 
being ignored or there is another, potentially more serious problem.

Dec 23 08:27:01 lechner-desktop kernel: [  192.786639] encfs[2308]: segfault at 
0 ip 7fce39883f36 sp 7fce37b4d970 error 4 in 
libencfs.so.1.9.1[7fce3982a000+75000]
Dec 23 08:32:50 lechner-desktop kernel: [  146.913824] encfs[1763]: segfault at 
0 ip 7f052e4dff36 sp 7f052b7a7970 error 4 in 
libencfs.so.1.9.1[7f052e486000+75000]
Dec 23 08:57:11 lechner-desktop kernel: [  166.904051] traps: encfs[1856] 
general protection ip:7fba93de28d4 sp:7fba92219958 error:0 in 
libc-2.24.so[7fba93c9e000+195000]
Dec 23 09:13:49 lechner-desktop kernel: [  747.796823] encfs[1952]: segfault at 
0 ip 7f63c3cf7f36 sp 7f63c1c91970 error 4 in 
libencfs.so.1.9.1[7f63c3c9e000+75000]

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_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 encfs depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  fuse   2.9.7-1
ii  libc6  2.24-8
ii  libfuse2   2.9.7-1
ii  libgcc11:6.2.1-5
ii  libssl1.1  1.1.0c-2
ii  libstdc++6 6.2.1-5
ii  libtinyxml2-4  4.0.1-1
ii  mount  2.29-1

encfs recommends no packages.

encfs suggests no packages.

-- debconf information:
* encfs/security-information:



Bug#849217: jruby: FTBFS (sbuild hangs)

2016-12-23 Thread Santiago Vila
Package: src:jruby
Version: 1.7.26-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 --buildsystem=maven
   dh_testdir -i -O--buildsystem=maven
   dh_update_autotools_config -i -O--buildsystem=maven
   dh_auto_configure -i -O--buildsystem=maven
find: ???/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar???: 
No such file or directory
find: ???/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar???: 
No such file or directory
find: 
???/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar???: No 
such file or directory
mh_patchpoms -pjruby --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo
[ERROR] Cannot find parent dependency org.jruby:jruby-artifacts:pom:1.7.26, use 
--no-parent option to resolve this issue or install the parent POM in the Maven 
repository
[ERROR] Cannot find parent dependency org.jruby:jruby-artifacts:pom:1.7.26, use 
--no-parent option to resolve this issue or install the parent POM in the Maven 
repository
[ERROR] Cannot find parent dependency org.jruby:jruby-ext:pom:1.7.26, use 
--no-parent option to resolve this issue or install the parent POM in the Maven 
repository
[ERROR] Cannot find parent dependency org.jruby:jruby-artifacts:pom:1.7.26, use 
--no-parent option to resolve this issue or install the parent POM in the Maven 
repository

[... snipped ...]

[INFO] JRuby .. SUCCESS [  0.002 s]
[INFO] JRuby Core . SUCCESS [02:37 min]
[INFO] JRuby Ext .. SUCCESS [  0.001 s]
[INFO] JRuby Readline . SUCCESS [  0.514 s]
[INFO] JRuby Ripper ... SUCCESS [  0.107 s]
[INFO] JRuby Lib Setup  SUCCESS [  0.000 s]
[INFO] JRuby Integration Tests  SUCCESS [  2.547 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 02:41 min
[INFO] Finished at: 2016-12-17T19:33:45+01:00
[INFO] Final Memory: 17M/90M
[INFO] 
./bin/jruby spec/mspec/bin/mspec ci
jruby 1.7.26 (1.9.3p551) 2016-11-12 fff on OpenJDK 64-Bit Server VM 
1.8.0_111-8u111-b14-3-b14 +jit [linux-amd64]
..
 
.NoMethodError:
 undefined method `daemon' for Process:Module
  daemon_at_exit at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:55
 run at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:11
  (root) at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:111
NoMethodError: undefined method `daemon' for Process:Module
  keep_stdio_open_false_stdout at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:64
   run at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:11
(root) at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:111
NoMethodError: undefined method `daemon' for Process:Module
  keep_stdio_open_false_stderr at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:69
   run at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:11
(root) at 
/<>/spec/ruby/core/process/fixtures/daemon.rb:111
NoMethodError: undefined method `daemon' for Process:Module
  keep_stdio_open_false_s

Bug#849218: transition: imagemagick

2016-12-23 Thread Bastien ROUCARIÈS
Package: release.debian.org
Severity: normal

Hi,

Due to #846385 could be possible to get transition for imagemagick.

Sorry for being late but upstream is really sloppy.

The break was in 6.9.2-10 released in mid 2015. This is moreover only two 
version latter than  current jessie and I believe it will be a security 
nightmare to support three versions with more than 100 security patches

Bastien





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


Bug#849207: libmonitoring-livestatus-perl: Outdated packaging

2016-12-23 Thread Sebastiaan Couwenberg
On 12/23/2016 02:49 PM, Bas Couwenberg wrote:
> The packaging for libmonitoring-livestatus-perl is outdated as reported
> by lintian. Amongst other the debhelper compatibility version is
> outdated, the Standards-Version is ancient, and the latest upstream
> release is not yet included.
> 
> The attached patches update the packaging to resolve this. These changes
> could not be pushed to the git repository on Alioth because it doesn't
> exist as reported in #849188.

Upstream has fixed the issues identified in version 0.76 for which
patches were included in the Debian package. The attached patches update
the package to 0.78.

Kind Regards,

Bas

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


0014-Mark-spelling-errors.patch-as-Applied-Upstream.patch
Description: inode/symlink


0015-Close-bug-in-changelog.patch
Description: inode/symlink


0016-Imported-Upstream-version-0.78.patch
Description: inode/symlink


0017-New-upstream-release.patch
Description: inode/symlink


0018-Drop-patches-applied-upstream.patch
Description: inode/symlink


Bug#849219: metview: FTBFS in testing (cannot find -lgrib_api)

2016-12-23 Thread Santiago Vila
Package: src:metview
Version: 4.8.0-3
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 --buildsystem=cmake 
--builddirectory=/<>/debian/build
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_autoreconf -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
chmod +x ./scripts/*.mv
# Hack. how to do this via ecbuild?
cp scripts/metview_base.in scripts/metview_base.in.bak
sed -e 's%@DEB_HOST_MULTIARCH@%x86_64-linux-gnu%g' < scripts/metview_base.in \
> scripts/tmpx && mv scripts/tmpx scripts/metview_base.in
dh_auto_configure -- \

[... snipped ...]

[ 78%] Building CXX object 
src/uPlot/CMakeFiles/GeoTool.dir/MvQPlaceMarkWidget.cc.o
cd /<>/debian/build/src/uPlot && /usr/bin/c++   
-DGRIB_HANDLING_PACKAGE=ecCodes -DH_INCLUDES_CC -DLITTLE_END -DMAGICS_QT5 
-DMETVIEW -DMETVIEW_QT5 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB 
-DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DR64 -DUSE_NEW_IO 
-I/<>/debian/build/module -I/<>/src/libMvQtUtil 
-I/<>/src/libMvQtGui -I/<>/src/libMetview 
-I/<>/src/libUtil -I/<>/src/libMarsClient 
-I/<>/src/libMars -I/<>/debian/build/src/libMars 
-I/<>/src -I/<>/src/libFTimeUtil 
-I/<>/src/libMvNetCDF -I/<>/src/libMvQtGui/../uPlot 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I/usr/include/x86_64-linu
 x-gnu/qt5/QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtXmlPatterns 
-I/usr/include/x86_64-linux-gnu/qt5/QtNetwork 
-I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/magics 
-I/usr/include/terralib -I/usr/include/terralib/kernel -I/usr/lib/include 
-I/usr/include/hdf5/serial -I/usr/include/python3.5m 
-I/usr/include/openjpeg-2.1 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/X11R6/include 
-I/usr/lib/python3/dist-packages/numpy/core/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -std=c++11 
-Wdate-time -D_FORTIFY_SOURCE=2 -pipe -fpermissive -Wno-write-strings 
-Wno-deprecated -O3 -DNDEBUG -fPIE   -fPIC -std=gnu++11 -o 
CMakeFiles/GeoTool.dir/MvQPlaceMarkWidget.cc.o -c 
/<>/src/uPlot/MvQPlaceMarkWidget.cc
[ 78%] Building CXX object 
src/uPlot/CMakeFiles/GeoTool.dir/MvQPlaceMarkModel.cc.o
cd /<>/debian/build/src/uPlot && /usr/bin/c++   
-DGRIB_HANDLING_PACKAGE=ecCodes -DH_INCLUDES_CC -DLITTLE_END -DMAGICS_QT5 
-DMETVIEW -DMETVIEW_QT5 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB 
-DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DR64 -DUSE_NEW_IO 
-I/<>/debian/build/module -I/<>/src/libMvQtUtil 
-I/<>/src/libMvQtGui -I/<>/src/libMetview 
-I/<>/src/libUtil -I/<>/src/libMarsClient 
-I/<>/src/libMars -I/<>/debian/build/src/libMars 
-I/<>/src -I/<>/src/libFTimeUtil 
-I/<>/src/libMvNetCDF -I/<>/src/libMvQtGui/../uPlot 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I/usr/include/x86_64-linu
 x-gnu/qt5/QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtXmlPatterns 
-I/usr/include/x86_64-linux-gnu/qt5/QtNetwork 
-I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/magics 
-I/usr/include/terralib -I/usr/include/terralib/kernel -I/usr/lib/include 
-I/usr/include/hdf5/serial -I/usr/include/python3.5m 
-I/usr/include/openjpeg-2.1 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/X11R6/include 
-I/usr/lib/python3/dist-packages/numpy/core/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -std=c++11 
-Wdate-time -D_FORTIFY_SOURCE=2 -pipe -fpermissive -Wno-write-strings 
-Wno-deprecated -O3 -DNDEBUG -fPIE   -fPIC -std=gnu++11 -o 
CMakeFiles/GeoTool.dir/MvQPlaceMarkModel.cc.o -c 
/<>/src/uPlot/MvQPlaceMarkModel.cc
[ 78%] Building CXX object src/uPlot/CMakeFiles/GeoTool.dir/MvQPlotView.cc.o
cd /<>/debian/build/src/uPlot && /usr/bin/c++   
-DGRIB_HANDLING_PACKAGE=ecCodes -DH_INCLUDES_CC -DLITTLE_END -DMAGICS_QT5 
-DMETVIEW -DMETVIEW_QT5 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NE

Bug#849220: ipykernel: FTBFS (failing tests)

2016-12-23 Thread Santiago Vila
Package: src:ipykernel
Version: 4.5.2-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 python2,python3 --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build

[... snipped ...]

ipykernel.tests.test_message_spec.test_connect_request ... ok
ipykernel.tests.test_message_spec.test_comm_info_request ... ok
ipykernel.tests.test_message_spec.test_single_payload ... ok
ipykernel.tests.test_message_spec.test_is_complete ... ok
ipykernel.tests.test_message_spec.test_history_range ... ok
ipykernel.tests.test_message_spec.test_history_tail ... ok
ipykernel.tests.test_message_spec.test_history_search ... ok
ipykernel.tests.test_message_spec.test_stream ... ok
ipykernel.tests.test_message_spec.test_display_data ... ok
ipykernel.tests.test_pickleutil.test_no_closure ... ok
ipykernel.tests.test_pickleutil.test_generator_closure ... ok
ipykernel.tests.test_pickleutil.test_nested_closure ... ok
ipykernel.tests.test_pickleutil.test_closure ... ok
ipykernel.tests.test_pickleutil.test_uncan_bytes_buffer ... ok
ipykernel.tests.test_serialize.test_roundtrip_simple ... ok
ipykernel.tests.test_serialize.test_roundtrip_nested ... ok
ipykernel.tests.test_serialize.test_roundtrip_buffered ... ok
ipykernel.tests.test_serialize.test_roundtrip_memoryview ... ok
ipykernel.tests.test_serialize.test_numpy ... ok
ipykernel.tests.test_serialize.test_recarray ... ok
ipykernel.tests.test_serialize.test_numpy_in_seq ... ok
ipykernel.tests.test_serialize.test_numpy_in_dict ... ok
ipykernel.tests.test_serialize.test_class ... ok
ipykernel.tests.test_serialize.test_class_oldstyle ... ok
ipykernel.tests.test_serialize.test_tuple ... ok
ipykernel.tests.test_serialize.test_namedtuple ... ok
ipykernel.tests.test_serialize.test_list ... ok
ipykernel.tests.test_serialize.test_class_inheritance ... ok
ipykernel.tests.test_start_kernel.test_ipython_start_kernel_userns ... ok
ipykernel.tests.test_start_kernel.test_ipython_start_kernel_no_userns ... ok
If a hook is installed, and on calling the object ... ok
If a hook is installed and on calling the object ... ok
Since there's no explicit constructor, here we confirm ... ok
Publish should prepare the message and eventually call ... ok
Confirms that the thread_local attribute is correctly ... ok
Once a hook is unregistered, it should not be called ... ok

--
Ran 93 tests in 33.394s

OK (SKIP=1)
debian/rules:16: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 124
make[1]: Leaving directory '/<>'
debian/rules:8: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends. For a full build log please see:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ipykernel.html

where it also fails in a similar way.

Thanks.



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

2016-12-23 Thread Jonathan Dowland
On Thu, Dec 22, 2016 at 06:27:32AM +0100, Fabian Greffrath wrote:
> The transitional chocolate-common package doesn't necessarily have to
> contain the same files as before. It's perfectly fine if it is an empty
> dummy.

Sorry yes, that's not quite what I meant. hopefully the latest pushes to
the proposed-consolidate branch clear that up.

I've ran out of time to work on this anymore before Xmas and possibly until
the new year -- I've pushed my latest and put builds of those packages at
the temporary location on phobos mentioned in an earlier bug. I hope you
or someone else can double check it and possibly upload it!

Best wishes for the holiday season


signature.asc
Description: Digital signature


Bug#849221: duplicity: collection-status should print approximate size of full and incremental sets on each chain level.

2016-12-23 Thread Witold Baryluk
Package: duplicity
Version: 0.7.10-2
Severity: wishlist

Hi.

This is in regards to collection-status summary.

It would really useful to show appriximate size of full and incremental
sets on each chain level, as well cummulative sizes for each chain (full
+ incrementals), to know how much space they occupy and how much data
need to be transfered for full restore to given point.

Total size of all files would also be useful.

Compressed and encrypted sizes as stored remotly would be most useful, as
this is usually what matter (i.e. when paying for storage and transfer to
remote cloud location).

This would be helpful in tuning --full-if-older-than values for example,
and remove-all-but-n-full / remove-older-than /
remove-all-inc-of-but-n-full settings, depending on a space available and
price of storage.


Thanks.

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

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

Versions of packages duplicity depends on:
ii  libc62.24-8
ii  librsync10.9.7-10
ii  python   2.7.13-1
ii  python-lockfile  1:0.12.2-2
pn  python:any   

Versions of packages duplicity recommends:
ii  python-oauthlib  2.0.1-1
ii  python-paramiko  2.0.0-1
ii  python-urllib3   1.19.1-1
ii  rsync3.1.2-1

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
ii  python-boto 2.44.0-1
pn  python-cloudfiles   
pn  python-gdata
ii  python-swiftclient  1:3.1.0-2
pn  tahoe-lafs  

-- no debconf information



Bug#848771: numexpr: FTBFS: Test failures

2016-12-23 Thread Ghislain Vaillant
control: forwarded -1 https://github.com/pydata/numexpr/issues/239



Bug#849043: privacy-breach-w3c-valid-html: incorrect lowercase "Icon" in path

2016-12-23 Thread Bastien ROUCARIES
On Thu, Dec 22, 2016 at 4:37 AM, Trent W. Buck  wrote:
> Package: lintian
> Version: 2.5.30+deb8u4
> Severity: minor
>
> While making a package I got this from lintian:
>
> E: foo: privacy-breach-w3c-valid-html usr/foo/foo.html 
> (http://www.w3.org/icons/valid-xhtml10.png)
>
> However the actual URL in the file has an uppercase I in Icons:
>
> http://www.w3.org/Icons/valid-xhtml10.png
>
> This misleading error confused me and I wasted half an hour trying to
> download the wrong URL (which 404s).
>
> Attached is a simple shell script which reproduces the problem.
>
> This file looks relevant, but I can't understand where the downcasing 
> actually happens:
>
> /usr/share/lintian/data/files/privacy-breaker-websites

We compare only lowercase string in order to be quicker. I think we
should document it
>
>
> If it is easy to do so,
> please avoid downcasing the path part of URLs in these lintian errors.



Bug#849218: Rdeps build fine

2016-12-23 Thread Bastien ROUCARIES
I forget to mention that rdeps build fine except:
trafficserver is - #848800
rss-glx due to unreleated build
conflict (#838800)



Bug#832941: RFS: 4pane (debian: to exclusive)

2016-12-23 Thread David Hart
Dear Sean,

Many thanks for your further input.

>Here's another review, based on your 4pane-debian-dir repo.
>Must-fixes
>1. At least one of the files added by AddExtraM4Files.patch isn't accounted
>for in d/copyright.
//snip
>9. Lots of files in .build/ are not accounted for in d/copyright.

Thank you. I'd completely forgotten about copyright for bitmaps/ and hadn't
considered it for debian/.
Many of the bitmaps were acquired in 2004/5 and I didn't record where from.
After spending a lot of time tracing them I believe d/copyright is now correct.

>2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo.

I'd thought that repo was just for the purpose of this review. However I've
corrected that now.

>8. Further, could you confirm that, for the files in bitmaps/ and the
>images in doc/ whose preferred format for modification is not .png, the
>.xpm/.svg/whatever source is available?  I see some .xpm/.svg files but
>not for every file.  If the preferred format for modification for those
>other files is editing the .png then it's fine.

There is no other source. I confirm that if I or anyone else wished to modify
a .png, editing it would be the preferred method.

>10. .build/DONT_README (heh) explains that the Bakefile tool is required
>to regenerate the build system.  I.e. the preferred format for
>modification of the buildsystem is not by editing Makefile.in, but by
>changing some other files and running Bakefile 

No, that's the way that Makefile.in was initially created, and it would be a
convenient way to make major changes to it. But most of the time I edit
Makefile.in by hand (as I just did when removing some unused bitmaps) and for
normal building, even with dh_autoreconf, bakefile itself is irrelevant.

>(is Makefile.in the only file that Bakefile outputs?).

There are also the 3 .m4 files in AddExtraM4Files.patch, which _are_
needed for dh_autoreconf.

>As before, this is a violation of DFSG.  I think you need to package
>Bakefile for Debian, unless you can think of a way around this.

As above I don't believe that's necessary. I'd add that bakefile was created
for the wxWidgets toolkit, which uses it far more often than does 4Pane. Yet
the wxWidgets packages e.g. libwxgtk3.0-dev don't include bakefile and their
maintainers presumably don't feel that violates DFSG.

>11. You need to run dch -r to refresh the changelog timestamp so it is
>after the various changes you've made recently.

Done


>Suggestions
>---
>
>1. You might raise the debhelper compat to 10, the latest version.  That
>means you can drop '--parallel --with autoreconf' which are automatic at
>compat 10.

Done.

>2. At the top of d/rules you define various EXTRA_ env vars.  Could you
>explain further why you can't do this "the standard way"?  Would it be
>possible to make it work by patching the upstream Makefile?  Generally
>speaking, it's better to have a short d/rules and move logic into the
>upstream Makefile (otherwise someone trying to understand it has to flip
>back and forth between two files).

I see what you mean. I've now done so.

>3. In a previous e-mail I explained why I think it would be clearer to
>call the wxWindows license "GPL-2+ or wxWindows-3.1+".  So far as I can
>tell you never responded to that -- please consider the points I made.
>Unless I'm missing something, it would make d/copyright clearer.

I think I did, but anyway:
In wxWindows circles the licence is invariably referred to as the wxWindows
one, often with the explanation that it's GPL-2 plus an exception. It's also
used in the libwxgtk3.0 packages' d/copyright. However I don't have any
expertise in such things and I'm happy to change it if it's thought necessary.

>4. You should probably s/4pane/4Pane/ in 4pane.doc-base.

Done.

>5. Rather than installing 4Pane.desktop twice, you could do something
>like this:
>
>override_dh_install:
>dh_install
>( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications )

Done.

>6. It's definitely not wrong, but it might not be optimal.  What I'm
>imagining is the following situation: Debian users expect to find
>certain files (changelogs, copyright files) in /usr/share/doc/foo.
>Since 4Pane is known as '4Pane', a user might reasonably look in
>/usr/share/doc/4Pane.  But then they wouldn't be able to find the
>standard files.  For this reason, I think /usr/share/doc/4Pane should be
>a link to /usr/share/doc/4pane and 4Pane can be patched to find its help
>files there.

Done.

Regards,

David Hart



Bug#733639: git-buildpackage: Please provide also a "gbp push" subcommand

2016-12-23 Thread Guido Günther
Hi Michael,
On Mon, Dec 19, 2016 at 08:41:38AM +0100, Michael Stapelberg wrote:
> On Fri, Nov 25, 2016 at 2:06 PM, Guido Günther  wrote:
> 
> > Hi Michael,
> > On Thu, Nov 24, 2016 at 12:34:56PM +0100, Michael Stapelberg wrote:
> > > Hi Axel and Guido,
> > >
> > > Axel Beckert  writes:
> > > > But it would be nice to do the pushing of branches and tags in one
> > > > short DWIM command instead of two short commands or one long command
> > > > (git push + git push --tags or listing all refs manually), like "dpt
> > > > push" does. So I extended "dpt push" to parse gbp.conf files, so that
> > > > I can use it outside the Debian Perl Group, too, e.g. for the Debian
> > > > Zsh Maintainers.
> > >
> > > I do agree, pushing in one command is much more user-friendly than not
> > > providing any help when pushing. I used to forget pushing the
> > > pristine-tar/upstream branches and/or tags _ALL THE TIME_.
> > >
> > > It was such a big problem for me that I wrote a custom wrapper for gbp
> > > clone, which would set up the repository in such a way that I couldn’t
> > > forget anymore:
> > >
> > > # This tells git to push all branches at once,
> > > # i.e. if you changed upstream and debian (after
> > git-import-orig),
> > > # both upstream and debian will be pushed when running “git
> > push”.
> > > git config push.default matching
> > >
> > > # This tells git to push tags automatically,
> > > # so you don’t have to use “git push && git push --tags”.
> > > git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
> > > git config --add remote.origin.push "+refs/tags/*:refs/tags/*"
> > >
> > > Needless to say, the above could easily be added to gbp clone, so that
> > > at least newly cloned repositories would be set up accordingly.
> > >
> > > What do you think of the solution above, i.e. configuring git so that
> > > “git push” is all that’s necessary, instead of introducing a new “gbp
> > > push” command? Would a corresponding patch be accepted into
> > > git-buildpackage?
> >
> > Thanks for looking into this. I think we need a "gbp push" after all
> > since matching strategy might be too broad: you might not want to push
> > changes for all releases and you might want to upload what you just
> > built in one go.
> >
> 
> How do you envision the user interface to look like for this tool? I.e.,
> what sort of command invocations should users use in order to upload
> changes?
> 
> 
> >
> > [gbp-posttag-push][0] does parts of the job already. It mostly needs
> > some cleanup and robustness to be turned into a gbp-push.
> >
> 
> I’m happy to work on this, if you provide some more details as to what
> exactly “some cleanups” entails :).

Axel describes his use of dpt-push as:
…
* Install the resulted packages and test them
* Run "git-buildpackage --git-tag-only" to set the tags
* Run dput on the changes file
* If the upload succeeds, then run "dpt push", i.e. push all relevant
  branches and tags.

And I'm ussing gbp buildpackage --git-tag-only like:

* gbp buildpackage (build, run autopkg tests, run lintian)
* Install the resulted packages and test them
* Run "git-buildpackage --git-tag-only" to
* Run dput on the changes file
* Push tags

So I'd say "gbp push" would

0.) Check if we're in a git repo and the repo is clean
1.) Check if topmost changelog is != UNRELEASED
2.) Check if there's a tag referring to the topmost changelog entry
3.) Check if there's an upstream tag available
4.) Check if there's a corresponding changes file available (and no .upload)
5.) Check if we can push debian branch, debian tag, upstream tag, upstream
branch, pristine-tar branch

6.) dput the changes
7.) Push debian branch, debian tag, upstream tag, upstream
branch, pristine-tar branch

gbp-posttag-push does 6. and 7. but it can skip some of the checks since
it can assume that it's called from within a git repo (since it's a hook
and that some of the tags are already there, since it's a posttag
hook). We'd need to add these when turning it into a standalone command.
We also need to add a manpage.

We should probably also add sloppy mode that just pushes whatever is on
the debian-branch to the remote side but that can be done in a later
version.

We also need to make the remote configurable but this can also be added
n a later version.

Hope I didn't miss something. Thanks for having look!
 -- Guido



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

2016-12-23 Thread Jonathan Dowland
...upgrade seems to work, there's a problem with downgrading from these -5
versions to -4 but I guess that's never officially supported anyway.


signature.asc
Description: Digital signature


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

2016-12-23 Thread Jonathan Dowland
On second (or third thoughts)... I've uploaded the package as-is to DELAYED-5.
I suppose worst case it's borked and a fixed package needs to be uploaded
after, that might be better than not getting this done in time for the freeze.


signature.asc
Description: Digital signature


Bug#849138: atop installation fails

2016-12-23 Thread Vincent Lefevre
On 2016-12-23 12:10:09 +0100, Marc Haber wrote:
> this is the second time this week that you're filing a duplicate of an
> already existing bug with a severely inflated severity.

This is not an inflated severity. Under no circumstances, the
installation of a package should make dpkg fail and leave the
packaging system in an inconsistent state (this can block the
correct installation of other packages). Well, actually here
the problem came from the old package from experimental, but
I wasn't aware of this.

> While I appreciate your attention on atop, I would really love if
> you could look whether the issue you're reporting already exists.

I was looking at RC bugs.

> This being said, I do agree that #842136 is an issue that we should
> look into, but I don't think it's a release stopper. The issue is
> related to a bug in the version of atop being replaced, that has been
> addressed with atop 2.2.5. I do doubt that this would happen when
> you're upgrading from the ancient version that is currently in unstable.
> 
> I would appreciate if you could test that, by installing the version
> from unstable and the upgrading to the current version in
> experimental. That would _really_ help.

It still fails:

Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
Unpacking atop (2.2.6-1~exp1) over (1.26-2+b1) ...
Setting up atop (2.2.6-1~exp1) ...
Installing new version of config file /etc/cron.d/atop ...
Installing new version of config file /etc/default/atop ...
Installing new version of config file /etc/init.d/atop ...
Created symlink /etc/systemd/system/multi-user.target.wants/atop.service → 
/lib/systemd/system/atop.service.
Created symlink /etc/systemd/system/multi-user.target.wants/atopacct.service → 
/lib/systemd/system/atopacct.service.
Job for atopacct.service failed because of unavailable resources or another 
system error.
See "systemctl status atopacct.service" and "journalctl -xe" for details.
invoke-rc.d: initscript atopacct, action "start" failed.
● atopacct.service - Atop process accounting daemon
   Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: resources) since Fri 2016-12-23 19:24:44 CET; 10ms 
ago
 Docs: man:atopacctd(8)
  Process: 2445 ExecStart=/usr/sbin/atopacctd (code=exited, status=0/SUCCESS)
 Main PID: 619 (code=killed, signal=KILL)

Dec 23 19:24:44 cventin systemd[1]: Starting Atop process accounting daemon...
Dec 23 19:24:44 cventin atopacctd[2445]: /run/pacct_shadow.d: File exists
Dec 23 19:24:44 cventin systemd[1]: atopacct.service: PID file /run/atopacc…tory
Dec 23 19:24:44 cventin systemd[1]: Failed to start Atop process accounting…mon.
Dec 23 19:24:44 cventin systemd[1]: atopacct.service: Unit entered failed state.
Dec 23 19:24:44 cventin systemd[1]: atopacct.service: Failed with result 'r…es'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package atop (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (232-8) ...
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 atop

but it doesn't fail on a different machine. I suppose that the problem
comes from the fact that there hasn't been any clean-up after purging
the buggy atop version: I still have the /run/pacct_shadow.d directory
with old files:

-rw-r--r-- 1 root root 0 2016-12-20 17:19:43 00.paf
-rw-r--r-- 1 root root 7 2016-12-20 17:19:43 current

But I wonder whether this may still be a problem. I mean that if
atopacctd complains that some file exists, isn't this because it wants
to recreate such a file, in which case the problem could occur again?

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



Bug#849203: [Pkg-alsa-devel] Bug#849203: libasound2: ALSA_PCM_DEVICE environment variable is ignored

2016-12-23 Thread Elimar Riesebieter
* Leszek Godlewski  [2016-12-23 15:54 +0100]:

> Package: libasound2
> Version: 1.1.2-1
> Severity: normal
> 
> Dear Maintainer,

[...]

> inequation@BrixPro:~$ cat /etc/asound.conf
> defaults.pcm.card 0
> defaults.pcm.device 3

As far as i understsnd the sources you must prepare your device to
interpret ALSA_PCM_DEVICE. Try /etc/asound.conf as follows:

defaults.pcm.card 0
defaults.pcm.device 3
defaults.pcm.device {
@func igetenv
vars [ ALSA_PCM_DEVICE ]
default 0 
}

Now it should be possible to run
$ ALSA_PCM_CARD=1 ALSA_PCM_DEVICE=0 mplayer test.mp3


Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)



Bug#849203: [Pkg-alsa-devel] Bug#849203: libasound2: ALSA_PCM_DEVICE environment variable is ignored

2016-12-23 Thread Leszek Godlewski
Hi Elimar,

If that is the case, why does ALSA_PCM_CARD work without such preparation?
/usr/share/alsa/alsa.conf contains a similar block for the card, yet it
isn't needed in /etc/asound.conf.

I will try it anyway and let you know if it worked, thanks!

Leszek

pt., 23 gru 2016 o 19:42 użytkownik Elimar Riesebieter 
napisał:

> * Leszek Godlewski  [2016-12-23 15:54 +0100]:
>
> > Package: libasound2
> > Version: 1.1.2-1
> > Severity: normal
> >
> > Dear Maintainer,
>
> [...]
>
> > inequation@BrixPro:~$ cat /etc/asound.conf
> > defaults.pcm.card 0
> > defaults.pcm.device 3
>
> As far as i understsnd the sources you must prepare your device to
> interpret ALSA_PCM_DEVICE. Try /etc/asound.conf as follows:
>
> defaults.pcm.card 0
> defaults.pcm.device 3
> defaults.pcm.device {
> @func igetenv
> vars [ ALSA_PCM_DEVICE ]
> default 0
> }
>
> Now it should be possible to run
> $ ALSA_PCM_CARD=1 ALSA_PCM_DEVICE=0 mplayer test.mp3
>
>
> Elimar
> --
>   Learned men are the cisterns of knowledge,
>   not the fountainheads ;-)
>


Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

2016-12-23 Thread Graham Inggs
I built leptonlib 1.73-6 including Sean's patch on powerpc and s390x.
I then ran ocrmypdf's test suite against it.

Test results went from:

tests/test_hocrtransform.py .
tests/test_main.py
...F..ss.F.
tests/test_pageinfo.py 

to:

tests/test_hocrtransform.py .
tests/test_main.py
..ss...FFF.
tests/test_pageinfo.py 

Tests on little-endian architectures remained successful, so it seems
to be a step in the right direction, but we aren't quite there yet.

Output of new failing tests attached.
= test session starts ==
platform linux -- Python 3.5.2+, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: 
/data/adttmp/autopkgtest-virt-lxc.shared.hw7c_x0x/downtmp/build.hfb/ocrmypdf-4.3.4,
 inifile: pytest.ini
collected 85 items

test_requirements.txt s
tests/test_hocrtransform.py .
tests/test_main.py 
..ss...FFF.
tests/test_pageinfo.py 

=== FAILURES ===
 test_autorotate[hocr] _

spoof_tesseract_cache = {'ADTTMP': 
'/data/adttmp/autopkgtest-virt-lxc.shared.hw7c_x0x/downtmp/autopkgtest_tmp', 
'ADT_ARTIFACTS': '/data/adttmp...untu1', 'AUTOPKGTEST_ARTIFACTS': 
'/data/adttmp/autopkgtest-virt-lxc.shared.hw7c_x0x/downtmp/test-suite-artifacts',
 ...}
renderer = 'hocr'

@pytest.mark.parametrize('renderer', [
'hocr',
'tesseract',
])
def test_autorotate(spoof_tesseract_cache, renderer):
# cardinal.pdf contains four copies of an image rotated in each cardinal
# direction - these ones are "burned in" not tagged with /Rotate
out = check_ocrmypdf('cardinal.pdf', 'test_autorotate_%s.pdf' % 
renderer,
 '-r', '-v', '1', env=spoof_tesseract_cache)
for n in range(1, 4+1):
correlation = check_monochrome_correlation(
reference_pdf=_infile('cardinal.pdf'),
reference_pageno=1,
test_pdf=out,
test_pageno=n)
>   assert correlation > 0.80
E   assert 0.0562746599316597 > 0.8

tests/test_main.py:401: AssertionError
- Captured stdout call -
  DEBUG - ocrmypdf 4.3.4
  DEBUG - 
os.symlink(/data/adttmp/autopkgtest-virt-lxc.shared.hw7c_x0x/downtmp/build.hfb/ocrmypdf-4.3.4/tests/resources/cardinal.pdf,
 /tmp/com.github.ocrmypdf.5hxi1p4t/origin)
  DEBUG - os.symlink(/tmp/com.github.ocrmypdf.5hxi1p4t/origin, 
/tmp/com.github.ocrmypdf.5hxi1p4t/origin.pdf)
  DEBUG - [{'images': [{'dpi_h': Decimal('300.000'), 'type': 'image', 'width': 
2550, 'bpc': 1, 'color': 'gray', 'dpi': Decimal('300.000'), 'name': '/Im0', 
'comp': 1, 'dpi_w': Decimal('300.000'), 'enc': 'jbig2', 'height': 3300}], 
'height_inches': Decimal('11'), 'rotate': 0, 'has_text': False, 'width_pixels': 
2550, 'width_inches': Decimal('8.5'), 'xres': Decimal('300.000'), 'yres': 
Decimal('300.000'), 'pageno': 0, 'height_pixels': 3300}, {'images': [{'dpi_h': 
Decimal('300.000'), 'type': 'image', 'width': 2550, 'bpc': 1, 'color': 'gray', 
'dpi': Decimal('300.000'), 'name': '/Im0', 'comp': 1, 'dpi_w': 
Decimal('300.000'), 'enc': 'jbig2', 'height': 3300}], 'height_inches': 
Decimal('8.5'), 'rotate': 0, 'has_text': False, 'width_pixels': 3300, 
'width_inches': Decimal('11'), 'xres': Decimal('300.000'), 'yres': 
Decimal('300.000'), 'pageno': 1, 'height_pixels': 2550}, {'images': [{'dpi_h': 
Decimal('300.000'), 'type': 'image', 'width': 2550, 'bpc': 1, 'color': 'gray', 
'dpi': Decimal('300.000'), 'name': '/Im0', 'comp': 1, 'dpi_w': 
Decimal('300.000'), 'enc': 'jbig2', 'height': 3300}], 'height_inches': 
Decimal('11'), 'rotate': 0, 'has_text': False, 'width_pixels': 2550, 
'width_inches': Decimal('8.5'), 'xres': Decimal('300.000'), 'yres': 
Decimal('300.000'), 'pageno': 2, 'height_pixels': 3300}, {'images': [{'dpi_h': 
Decimal('300.000'), 'type': 'image', 'width': 2550, 'bpc': 1, 'color': 'gray', 
'dpi': Decimal('300.000'), 'name': '/Im0', 'comp': 1, 'dpi_w': 
Decimal('300.000'), 'enc': 'jbig2', 'height': 3300}], 'height_inches': 
Decimal('8.5'), 'rotate': 0, 'has_text': False, 'width_pixels': 3300, 
'width_inches': Decimal('11'), 'xres': Decimal('300.000'), 'yres': 
Decimal('300.000'), 'pageno': 3, 'height_pixels': 2550}]
  DEBUG - os.symlink(/tmp/com.github.ocrmypdf.5hxi1p4t/01.page.pdf, 
/tmp/com.github.ocrmypdf.5hxi1p4t/01.ocr.page.pdf)
  DEBUG - os.symlink(/tmp/com.github.ocrmypdf.5hxi1p4t/02.page.pdf, 
/tmp/com.github.ocrmypdf.5hxi1p4t/02.ocr.page.pdf)
  DEBUG - os.symlink(/tmp/com.github.ocrmypdf.5hxi1p4t/03.page.pdf, 
/tmp/com.github.ocrmypdf.5hxi1p4t/03.ocr.page.pdf)
  DEBUG - os.symlink(/tmp/com.github.ocrmypdf.5hxi1p4t/04.page.pdf, 
/tmp/com.github.o

Bug#849211: Acknowledgement (Installing gives multiple errors)

2016-12-23 Thread James Cloos
And on another box I get:

  Can't locate JSON.pm in @INC

And then:

  Can't locate Geo/IP.pm in @INC

After adding those perl packages apt-get hangs again.

The postinst script needs to avoid hanging.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6



Bug#849222: FTBFS: missing build dependency libandroid-tools-annotations-java

2016-12-23 Thread Hans Joachim Desserud

Package: android-platform-frameworks-data-binding
Version: 2.2.2-1
Severity: serious
Tags: patch

Dear maintainer,

the recent upload of android-platform-frameworks-data-binding
fails to build in Debian Sid with the following error message:

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration 
':dataBinding:compilerCommon:compileClasspath'.

Could not find com.android.tools:annotations:24.5.0.

  Searched in the following locations:
  
file:/usr/share/maven-repo/com/android/tools/annotations/debian/annotations-debian.pom
  
file:/usr/share/maven-repo/com/android/tools/annotations/debian/annotations-debian.jar

  Required by:
  project :dataBinding:compilerCommon

(for a complete build log, see [1] from when it was synced to Ubuntu)

I was able to reproduce the issue on Debian Sid, but
after adding libandroid-tools-annotations-java as a build
dependency, the package built successfully. See the
attached patch. :)


[1] 
https://launchpadlibrarian.net/299784631/buildlog_ubuntu-zesty-amd64.android-platform-frameworks-data-binding_2.2.2-1_BUILDING.txt.gz


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 77c946c..e01dc6c 100644
--- a/debian/control
+++ b/debian/control
@@ -7,6 +7,7 @@ Build-Depends: antlr4,
debhelper (>=9),
default-jdk-headless | default-jdk (>= 1:1.6),
gradle-debian-helper,
+   libandroid-tools-annotations-java,
libcommons-io-java,
libguava-java,
libjuniversalchardet-java,


Bug#848761: ovito: FTBFS: Test failures

2016-12-23 Thread Ghislain Vaillant
Hopefully, updating the package to the latest upstream (2.8.1) may fix
these test problems. That's what I am trying now.

Ghis



Bug#848913: Please clear the problem

2016-12-23 Thread Anton Gladky
tag 848913 +moreinfo
thanks

Hi,

the bugreport is not quite clear for me. libeigen3-doc is built
and the list of all files can be found here [1].

Please clarify the problem.

[1] https://packages.debian.org/sid/all/libeigen3-doc/filelist

Best regards

Anton



Bug#849223: src:ovito: pybind11 vendored in ovito

2016-12-23 Thread Ghislain Antony Vaillant
Package: src:ovito
Severity: normal

Dear Maintainer,

I noticed that ovito vendors a copy of pybind11, however the latter is
now available in Debian.

pybind11 is used in `src/plugins/PyScript.h` and does not seem to be
discovered by CMake. So a patch to use the system version should simply
involve changing these paths, hopefully.

Ghis


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

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



Bug#849138: atop installation fails

2016-12-23 Thread Martin Steigerwald
Am Freitag, 23. Dezember 2016, 19:37:33 CET schrieb Vincent Lefevre:
> On 2016-12-23 12:10:09 +0100, Marc Haber wrote:
> > this is the second time this week that you're filing a duplicate of an
> > already existing bug with a severely inflated severity.
> 
> This is not an inflated severity. Under no circumstances, the
> installation of a package should make dpkg fail and leave the
> packaging system in an inconsistent state (this can block the
> correct installation of other packages). Well, actually here
> the problem came from the old package from experimental, but
> I wasn't aware of this.

The packaging system is not in an inconsistent state: You can always remove 
the package that fails to upgrade. Or pin it to a certain version to prevent 
an update.

As someone who uses Debian Sid and experimental I expect you to be aware of 
it.

> > While I appreciate your attention on atop, I would really love if
> > you could look whether the issue you're reporting already exists.
> 
> I was looking at RC bugs.

Which is, as I still think, not the right severity for this bug. Anyhow its 
always a good idea to look for bugs of all kinds of severity, as: The 
judgement of someone on severity else may be different than yours.

> > This being said, I do agree that #842136 is an issue that we should
> > look into, but I don't think it's a release stopper. The issue is
> > related to a bug in the version of atop being replaced, that has been
> > addressed with atop 2.2.5. I do doubt that this would happen when
> > you're upgrading from the ancient version that is currently in unstable.
> > 
> > I would appreciate if you could test that, by installing the version
> > from unstable and the upgrading to the current version in
> > experimental. That would _really_ help.
> 
> It still fails:
> 
> Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
> Unpacking atop (2.2.6-1~exp1) over (1.26-2+b1) ...
[…]
> but it doesn't fail on a different machine. I suppose that the problem
> comes from the fact that there hasn't been any clean-up after purging
> the buggy atop version: I still have the /run/pacct_shadow.d directory
> with old files:
> 
> -rw-r--r-- 1 root root 0 2016-12-20 17:19:43 00.paf
> -rw-r--r-- 1 root root 7 2016-12-20 17:19:43 current

Yes. So to really test this:

- Downgrade to atop 1.26
- Reboot, or make sure atopacctd is stopped and remove /run/pacct_shadow.d 
directory.
- Upgrade to 2.26.

This should work okay every single time. Unless it doesn´t there is no release 
critical bug.

> But I wonder whether this may still be a problem. I mean that if
> atopacctd complains that some file exists, isn't this because it wants
> to recreate such a file, in which case the problem could occur again?

I think there is. The one I already reported in bug #842136.

But it is not release-critical.

If you want to add some additional testing, you can try a reinstall of atop 
2.26 oder 2.26. If that doesn´t work, there is still an issue with atopacctd 
not being able to be stopped gracefully. But I do think this is fixed.

Or or so, it would be nice if the start unit could clean the directory in case 
it would still exist, to cover rare corner cases where it might still exist.

Now please relax and first have a merry christmas, before panicking about this 
issue again.

Thank you,
-- 
Martin



Bug#849224: xorg: Lots of graphical lockups

2016-12-23 Thread Ryan Mattox
Source: xorg
Severity: important

Dear Maintainer,

As I was using my computer and setting up my second monitor, my display locked
up and would only unlock when I went to a different tty and back to X. I
eventually figured out compton was locking up my graphics, so I disabled it,
but other programs such as games like supertuxkart and funguloids freeze up and
playback from vlc also freezes up. Even simple things like glxgears freeze up.
Chrome freezes up too, but firefox does not, even when playing fullscreen
video.
However, if I run games with the environment variable "vblank_mode=0", games
work again, even chrome and compton works, but vlc still has troubles decoding
video.
Also I'm running the open source radeon driver with a AMD Radeon HD 6400M card
if it matters.
Anyway, thanks for putting in the time to look at my problem.



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

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

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils 7.7+3
ii  xkb-data  2.18-1
ii  xserver-xorg-core 2:1.19.0-2
ii  xserver-xorg-input-all1:7.7+18
ii  xserver-xorg-input-libinput [xorg-driver-input]   0.22.0-1+b1
ii  xserver-xorg-input-synaptics [xorg-driver-input]  1.9.0-1+b1
ii  xserver-xorg-input-wacom [xorg-driver-input]  0.33.0-1+b1
ii  xserver-xorg-video-ati [xorg-driver-video]1:7.8.0-1+b1
ii  xserver-xorg-video-mach64 [xorg-driver-video] 6.9.5-1+b2
ii  xserver-xorg-video-r128 [xorg-driver-video]   6.10.1-2+b1
ii  xserver-xorg-video-radeon [xorg-driver-video] 1:7.8.0-1+b1
ii  xserver-xorg-video-vmware [xorg-driver-video] 1:13.2.1-1+b1

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  13.0.2-1



Bug#783212: nfs-utils updated to 1.3.4-1, please check your bug #783212

2016-12-23 Thread Martin B
Control: tags -1 security

This bug is a security issue, as noted by Stephen Dowdy. While
this won't be a problem for stretch anymore, thanks to the upload of
1.3.4-1, it remains a problem for jessie.
There are three categories of use cases allowing file access 
on the server beyond the limits of the export specifications. I will
highlight these by example, as I have documented the generic
conditions in my original bug report:
1. server1 with /etc/exports:
/path/to/export -no_root_squash client1(root_squash)
will allow client1 to access /path/to/export on server1 as root user.
2. server2 with /etc/exports:
/path/to/export -async client2(all_squash)
will allow client2 to access /path/to/export on server2 as any non-root
uid/gid, instead of anonuid/anongid being used.
3. server3 with /etc/exports:
/path/to/export -rw client3(ro)
will allow client3 to write to any files in /path/to/export on server3,
if filesystem permissions on the server allow this for the connecting
uid/gid.

Regards
  Martin B



Bug#849225: libreoffice-calc: 3D elliptical diagram are NOT a correct way to represent data

2016-12-23 Thread Nicolas Patrois
Package: libreoffice-calc
Version: 1:5.2.4~rc1-1
Severity: minor
Tags: upstream

Dear Maintainer,

LibreOffice has the ability to create 3D circular diagrams, ie elliptical 
diagram.
In fact, this way to draw a diagram is false mathematically. The area of a 
sector in the front is bigger than the area of another sector of the same 
importance if it is placed right or left or in the back.
I know that some users might reclaim this feature but it’s a classical error in 
presenting data.
As far as LibreOffice is a quality office suite, it should not let its users 
create garbage graphics.
Just keep a line in the creation window that tells that this feature is in fact 
a bad idea.

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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3 2.8.12-1+b1
ii  coinor-libcoinmp1v51.7.6+dfsg1-2
ii  coinor-libcoinutils3v5 2.9.15-4
ii  dpkg   1.18.15
ii  libatlas3-base [liblapack.so.3]3.10.3-1
ii  libblas3 [libblas.so.3]3.6.1-2
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-8
ii  libetonyek-0.1-1   0.1.6-5
ii  libgcc11:6.2.1-5
ii  libicu57   57.1-5
ii  liblapack3 [liblapack.so.3]3.6.1-2
ii  liblcms2-2 2.8-2
ii  libmwaw-0.3-3  0.3.9-1
ii  libodfgen-0.1-10.1.6-2
ii  libopenblas-base [liblapack.so.3]  0.2.19-1
ii  liborcus-0.11-00.11.2-3+b1
ii  libreoffice-base-core  1:5.2.4~rc1-1
ii  libreoffice-core   1:5.2.4~rc1-1
ii  librevenge-0.0-0   0.0.4-6
ii  libstdc++6 6.2.1-5
ii  libwps-0.4-4   0.4.4-1
ii  libxml22.9.4+dfsg1-2.1
ii  lp-solve   5.5.0.15-4+b1
ii  uno-libs3  5.2.4~rc1-1
ii  ure5.2.4~rc1-1
ii  zlib1g 1:1.2.8.dfsg-4

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.10-2

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.7
ii  fonts-opensymbol  2:102.7+LibO5.2.4~rc1-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-8
ii  libcairo2 1.14.6-1.1
ii  libclucene-contribs1v52.3.3.4-4.2
ii  libclucene-core1v52.3.3.4-4.2
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.1-2
ii  libcurl3-gnutls   7.50.1-1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libdconf1 0.26.0-2
ii  libeot0   0.01-4
ii  libexpat1 2.2.0-1
ii  libexttextcat-2.0-0   3.4.4-2
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgl1-mesa-glx [libgl1]  13.0.2-1
ii  libglew2.02.0.0-3
ii  libglib2.0-0  2.50.2-2
ii  libgltf-0.0-0v5   0.0.2-5
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.9-2
ii  libharfbuzz-icu0  1.2.7-1+b1
ii  libharfbuzz0b 1.2.7-1+b1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-1+b1
ii  libicu57  57.1-5
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblangtag1   0.6.2-1
ii  liblcms2-22.8-2
ii  libldap-2.4-2 2.4.44+dfsg-2
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libodfgen-0.1-1   0.1.6-2
ii  libpcre3  2:8.39-2
ii  libpng16-16   1.6.26-6
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.2.4~rc1-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.2.1-5
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2
ii  uno-libs3 5.2.4~rc1-1
ii  ure   5.2.4~rc1-1
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages li

Bug#849215: encfs: 1.9.1-3 not a drop in replacement for previous version

2016-12-23 Thread Eduard Bloch
Hallo,
* Felix Lechner [Fri, Dec 23 2016, 09:40:48AM]:
> Package: encfs
> Version: 1.9.1-3
> Severity: important
> 
> When an encrypted home directory is on kerberized NFS4, upgrading to version 
> 1.9.1-3 in testing causes errors not present in the previous version.
> Logging in via terminal works, but not via GNOME/gdm 3.

And via other DM, like lxdm?

> Also, at some point an error appears when accessing the cleartext mountpoint. 
> Then the "Transport endpoint is not connected" (even though
> the default idle unmount setting was disabled in 
> /etc/security/pam_encfs.conf). Furthemore, some subsequent mount attempts via 
> PAM seem to trigger

This sounds like it might be an issue of libpam-encfs which is not my
package.

> segfaults like the ones below. It is currently unclear if the idle override 
> is being ignored or there is another, potentially more serious problem.
> 
> Dec 23 08:27:01 lechner-desktop kernel: [  192.786639] encfs[2308]: segfault 
> at 0 ip 7fce39883f36 sp 7fce37b4d970 error 4 in 
> libencfs.so.1.9.1[7fce3982a000+75000]

Now this sounds more like an encfs issue. Please enable coredumps (see
below for example) and mount manually and when it crashes, please send the
dump via some secure channel.

ulimit -c unlimited >/dev/null 2>&1
echo /tmp/core-%e-%s-%u-%g-%p-%t > /proc/sys/kernel/core_pattern

Or install the -dbg package from
http://debug.mirrors.debian.org/debian-debug/ and debug locally.

(You might also configure it via /etc/sysctl.conf but not sure how to
change ulimit correctly in pam context).

Regards,
Eduard.



Bug#849104: compizconfig-settings-manager should depend on libprotoc9v5

2016-12-23 Thread Jean-Philippe MENGUAL
Hi,


Le 23/12/2016 à 04:00, Thomas Vaughan a écrit :
> I figured out what my problem is.
> 
> I had built compiz some months ago from source and installed it under
> /usr/local.
> 
> There was still some python stuff under there, and the new ccsm python
> script was importing the compizconfig module from under /usr/local,
> which is apparently in the python path first.
> 
> When I built ccsm, it must have depended on the old protobuf stuff.
> 
> So this is totally not a bug in the package dependencies.
> 
> Sorry for the noise.

No problem, it shows that Compiz makes interest in Debian. It's positive
as we need any contributor to help maintaining.

> ​By the way, I am really happy that compiz is back in Debian!
> 
> I am a bit worried that I won't be able to use it, or that there will be
> not decent replacement for it, when it finally happens that I am forced
> to use wayland.​

1. It's not in a close future I think.
2. Hypra will maintain Compiz as long as possible, and we will plan, if
we have success in general project, to help Compiz with this transition.
But again, we have time.

> 
> Right now, I'm using compiz with xfce4.

We use it with MATE.

> -- 
> Thomas E. Vaughan

-- 
Jean-Philippe MENGUAL

HYPRA, progressons ensemble

Tél.: 01 84 73 06 61

Mail: cont...@hypra.fr

Site Web: http://hypra.fr



Bug#849138: atop installation fails

2016-12-23 Thread Martin Steigerwald
Am Freitag, 23. Dezember 2016, 20:10:23 CET schrieb Martin Steigerwald:
> Am Freitag, 23. Dezember 2016, 19:37:33 CET schrieb Vincent Lefevre:
> > On 2016-12-23 12:10:09 +0100, Marc Haber wrote:
[…]
> > > I would appreciate if you could test that, by installing the version
> > > from unstable and the upgrading to the current version in
> > > experimental. That would _really_ help.
> > 
> > It still fails:
> > 
> > Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
> > Unpacking atop (2.2.6-1~exp1) over (1.26-2+b1) ...
> 
> […]
> 
> > but it doesn't fail on a different machine. I suppose that the problem
> > comes from the fact that there hasn't been any clean-up after purging
> > the buggy atop version: I still have the /run/pacct_shadow.d directory
> > with old files:
> > 
> > -rw-r--r-- 1 root root 0 2016-12-20 17:19:43 00.paf
> > -rw-r--r-- 1 root root 7 2016-12-20 17:19:43 current
> 
> Yes. So to really test this:
> 
> - Downgrade to atop 1.26
> - Reboot, or make sure atopacctd is stopped and remove /run/pacct_shadow.d
> directory.
> - Upgrade to 2.26.
> 
> This should work okay every single time. Unless it doesn´t there is no
> release critical bug.

I just downgraded to atop 1.26 and then upgraded to atop 2.26 twice. It just 
worked. Anytime I downgraded to atop 1.26 there was no /run/pacct_shadow.d 
present anymore. So it seems that on downgrading from from atop 2.26 to 1.26 
atopacctd was properly stopped as it then removes its files and directories. (I 
didn´t check for the presence of atopacctd process.)

> > But I wonder whether this may still be a problem. I mean that if
> > atopacctd complains that some file exists, isn't this because it wants
> > to recreate such a file, in which case the problem could occur again?
> 
> I think there is. The one I already reported in bug #842136.
> 
> But it is not release-critical.
> 
> If you want to add some additional testing, you can try a reinstall of atop
> 2.26 oder 2.26. If that doesn´t work, there is still an issue with atopacctd
> not being able to be stopped gracefully. But I do think this is fixed.

I also did this, but this fails due to a different issue:

merkaba:~> LANG=C aptitude reinstall atop
The following packages will be REINSTALLED:
  atop 
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not 
upgraded.
Need to get 0 B/142 kB of archives. After unpacking 0 B will be used.
(Reading database ... 581734 files and directories currently installed.)
Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
Unpacking atop (2.2.6-1~exp1) over (2.2.6-1~exp1) ...
Setting up atop (2.2.6-1~exp1) ...
Failed to preset unit: File /etc/systemd/system/multi-user.target.wants/
atop.service already exists.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on atop.service: 
No such file or directory
Processing triggers for systemd (232-8) ...
Processing triggers for man-db (2.7.6.1-2) ...
[…]

I will report this separately. And it isn´t an RC bug either.

Thanks,
-- 
Martin



Bug#849211: Acknowledgement (Installing gives multiple errors)

2016-12-23 Thread Scott Kitterman
On Fri, 23 Dec 2016 13:42:57 -0500 James Cloos  wrote:
> And on another box I get:
> 
>   Can't locate JSON.pm in @INC
> 
> And then:
> 
>   Can't locate Geo/IP.pm in @INC
> 
> After adding those perl packages apt-get hangs again.
> 
> The postinst script needs to avoid hanging.

Agreed.  I'll have a look.  Thanks for the report.

Scott K

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


Bug#849138: atop installation fails

2016-12-23 Thread Vincent Lefevre
On 2016-12-23 20:10:23 +0100, Martin Steigerwald wrote:
> Am Freitag, 23. Dezember 2016, 19:37:33 CET schrieb Vincent Lefevre:
> > This is not an inflated severity. Under no circumstances, the
> > installation of a package should make dpkg fail and leave the
> > packaging system in an inconsistent state (this can block the
> > correct installation of other packages). Well, actually here
> > the problem came from the old package from experimental, but
> > I wasn't aware of this.
> 
> The packaging system is not in an inconsistent state: You can always remove 
> the package that fails to upgrade. Or pin it to a certain version to prevent 
> an update.

No, I mean that is case of error, it may happen that other packages
in the upgrade do not get configured (I already got this problem),
and the user needs to fix this manually (e.g. dpkg --configure -a),
otherwise some part of the system may be broken.

> Yes. So to really test this:
> 
> - Downgrade to atop 1.26
> - Reboot, or make sure atopacctd is stopped and remove /run/pacct_shadow.d 
> directory.
> - Upgrade to 2.26.

After removing the /run/pacct_shadow.d directory, this works.

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



Bug#849210: ntopng: fails to start

2016-12-23 Thread Ludovico Cavedon
Hi Aaron,

On Fri, Dec 23, 2016 at 4:48 PM Aaron M. Ucko  wrote:

> As of version 2.4, ntopng fails to start on my system.  I'm not sure
> what specifically is going wrong; all I see in ntopng.log is
>
> 23/Dec/2016 10:38:43 [Ntop.cpp:1121] Setting local networks to 127.0.0.0/8
> 23/Dec/2016  10:38:43 [Redis.cpp:92]
> Successfully connected to redis 127.0.0.1:6379@0
> 23/Dec/2016 10:38:43 [Ntop.cpp:1095] Parent process is exiting (this is
> normal)
>
>
I will look into that soon.
Are you sure ntopng is not running in background after this message?
Would you be able to send me the full log, please?

Thanks,
Ludovico


Bug#849026: libxi_1.6.1-1+deb7u2 introduced free of unallocated object

2016-12-23 Thread Thomas Walker
Yes, I can confirm that those packages appear to resolve my problem as well.
Thanks for the quick response!

On Thu, Dec 22, 2016 at 1:27 PM Emilio Pozuelo Monfort 
wrote:

> Hi,
>
> On 21/12/16 23:07, Thomas Walker wrote:
> > Package: libxi
> > Version: 1.6.1-1+deb7u2
> >
> > After updating the above package (from deb7u1), various applications
> > (google-chrome-stable notably) begin to crash with messages indicating an
> > attempt to free an invalid pointer.  Upon looking into the issue
> further, I
> > noticed that the following addition to XIQueryDevice.c is flawed:
> >
> > @@ -103,7 +130,17 @@
> >  SyncHandle();
> >  return info;
> >
> > +error_loop:
> > +while (--i >= 0)
> > +{
> > +Xfree(info[i].name);
> > +Xfree(info[i].classes);
> > +}
> > error:
> > +Xfree(info);
> > +Xfree(buf);
> >UnlockDisplay(dpy);
> >SyncHandle();
> >
> > There are 3 places that "goto error", two before info and buf are
> allocated, and
> > one after we've checked and found one (or both) to be NULL.  Moving those
> > Xfree()s up a couple of lines into error_loop (where we know they are
> already
> > allocated) fixes the problem.
>
> Thanks for your report. I have tried a different approach, initializing the
> buffer to NULL, as Xfree(NULL) is safe (as Xfree is just a wrapper around
> free).
>
> Moving the Xfree()s to error_loop would avoid this, but it could leak
> memory if
> one of the two allocations fail (however unlikely that is).
>
> Can you try the packages at https://people.debian.org/~pochu/lts/libxi/ ?
>
> Thanks,
> Emilio
>


Bug#849138: atop installation fails

2016-12-23 Thread Vincent Lefevre
On 2016-12-23 20:33:15 +0100, Martin Steigerwald wrote:
> I just downgraded to atop 1.26 and then upgraded to atop 2.26 twice.
> It just worked. Anytime I downgraded to atop 1.26 there was no
> /run/pacct_shadow.d present anymore. So it seems that on downgrading
> from from atop 2.26 to 1.26 atopacctd was properly stopped as it
> then removes its files and directories. (I didn´t check for the
> presence of atopacctd process.)

But if atopacctd is killed with SIGKILL (the kernel can kill random
processes like that), the reinstallation[*] no longer works.

[*] apt install --reinstall atop/experimental

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



Bug#849205: Pending fixes for bugs in the libgd-barcode-perl package

2016-12-23 Thread gregor herrmann
On Fri, 23 Dec 2016 10:33:38 -0500, Jeremy Bicha wrote:

> > Add real package libgd-perl as first alternative in Depends.
> Why are you keeping the alternate dependencies? They do not exist in
> Debian stable (or unstable).

Right, it's probably a bit useless and over-cautious, but they still
exist in oldstable, and keeping them for now shouldn't hurt?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Funny van Dannen: Tarzan ist tot


signature.asc
Description: Digital Signature


Bug#849226: atop: reinstallation fails

2016-12-23 Thread Martin Steigerwald
Package: atop
Version: 2.2.6-1~exp1
Severity: normal

Dear Marc,

reinstallation of atop fails with the following error:

merkaba:~> LANG=C aptitude reinstall atop
The following packages will be REINSTALLED:
  atop 
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not 
upgraded.
Need to get 0 B/142 kB of archives. After unpacking 0 B will be used.
(Reading database ... 581734 files and directories currently installed.)
Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
Unpacking atop (2.2.6-1~exp1) over (2.2.6-1~exp1) ...
Setting up atop (2.2.6-1~exp1) ...
Failed to preset unit: File /etc/systemd/system/multi-user.target.wants/
atop.service already exists.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on atop.service: 
No such file or directory
Processing triggers for systemd (232-8) ...
Processing triggers for man-db (2.7.6.1-2) ...
[…]

Thanks,
Martin

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

Kernel: Linux 4.8.14-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages atop depends on:
ii  init-system-helpers  1.46
ii  initscripts  2.88dsf-59.8
ii  libc62.24-8
ii  libncurses5  6.0+20161126-1
ii  libtinfo56.0+20161126-1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages atop recommends:
ii  cronie [cron-daemon]  1.4.8-1~exp1

atop suggests no packages.

-- no debconf information


Bug#835373: Disable failing test?

2016-12-23 Thread Anton Gladky
Dear all,

I propose to disable those 8 tests for the time being to let
the package migrate to testing... I know, disabling the tests
is not the solution and it should definitely solved properly, for the
moment it is the only opportunity not to block other packages.

Regards

Anton



Bug#849138: atop installation fails

2016-12-23 Thread Martin Steigerwald
Am Freitag, 23. Dezember 2016, 20:50:29 CET schrieb Vincent Lefevre:
> On 2016-12-23 20:33:15 +0100, Martin Steigerwald wrote:
> > I just downgraded to atop 1.26 and then upgraded to atop 2.26 twice.
> > It just worked. Anytime I downgraded to atop 1.26 there was no
> > /run/pacct_shadow.d present anymore. So it seems that on downgrading
> > from from atop 2.26 to 1.26 atopacctd was properly stopped as it
> > then removes its files and directories. (I didn´t check for the
> > presence of atopacctd process.)
> 
> But if atopacctd is killed with SIGKILL (the kernel can kill random
> processes like that), the reinstallation[*] no longer works.

Vincent, I do not say there isn´t an opportunity to improve the current 
situation. The bug is reported (again #842136, and Marc merged this your bug 
report with mine).

Yet it isn´t release critical. It is highly unlikely that the kernel would 
kill atop with SIGKILL in an OOM situation and it certainly doesn´t make the 
package unusable.

I also reported

> [*] apt install --reinstall atop/experimental

as Bug#849226 atop: reinstallation fails. Please add any additional 
information about reinstallation failure there in order to avoid using this 
bug report for several issues. Reinstallation on my system fails due to a 
*different* reason and with a different error message than than an existing /
run/pacct_shadow.d

Please relax, there is nothing that can´t still be fixed and there is nothing 
release critical in here.

Thanks,
-- 
Martin



Bug#849222: [Android-tools-devel] Bug#849222: FTBFS: missing build dependency libandroid-tools-annotations-java

2016-12-23 Thread Hans-Christoph Steiner

Looks like we have another circular depends :-/
libandroid-tools-annotations-java comes from
source:android-platform-tools-base which depends on
libandroid-databinding-java/android-platform-frameworks-data-binding.  I
think Java is a lot more tolerant than C, so I'm going to go ahead an
add libandroid-tools-annotations-java as a build dep, even though that
means it will build against the old version.



Bug#849226: deb-systemd-helper failed on upgrade to atop 2.24 as well

2016-12-23 Thread Martin Steigerwald
Dear Marc,

this issue has also happened on an upgrade to atop 2.24 once. But I didn´t see 
it on any upgrade after that anymore. I do not know whether it can happen 
again on an upgrade.

merkaba:~#100> LANG=C apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up atop (2.2.4-1~exp1) ...
Failed to preset unit: File /etc/systemd/system/multi-user.target.wants/
atop.service already exists.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on atop.service: 
No such file or directory
Job for atopacct.service failed because of unavailable resources or another 
system error.
See "systemctl status atopacct.service" and "journalctl -xe" for details.
invoke-rc.d: initscript atopacct, action "start" failed.
[…]

(see atop: /run/pacct_shadow.d: File exists on restarting atopacctd on upgrade
https://bugs.debian.org/842136 for the issue why atopacct didn´t start 
properly)

Thanks,
-- 
Martin



Bug#842136: atop: /run/pacct_shadow.d: File exists on restarting atopacctd on upgrade

2016-12-23 Thread Martin Steigerwald
Am Mittwoch, 26. Oktober 2016, 10:26:47 CET schrieben Sie:
> There is also a non aborting error with deb-systemd-helper, I file
> another bug report about that if you want.
> 
> merkaba:~#100> LANG=C apt dist-upgrade
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Calculating upgrade... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] 
> Setting up atop (2.2.4-1~exp1) ...
> Failed to preset unit: File
> /etc/systemd/system/multi-user.target.wants/atop.service already exists.
> /usr/bin/deb-systemd-helper: error: systemctl preset failed on
> atop.service: No such file or directory Job for atopacct.service failed
> because of unavailable resources or another system error. See "systemctl
> status atopacct.service" and "journalctl -xe" for details.

Reported as bug#849226 atop: reinstallation fails

(might make sense to retitle that bug report…)

Thanks,
-- 
Martin



Bug#849200: [Pkg-nagios-devel] Bug#849200: nagios-images: Outdated packaging

2016-12-23 Thread Jan Wagner
Hi Bas,

Am 23.12.16 um 15:33 schrieb Bas Couwenberg:
> The packaging for nagios-images is outdated as reported by lintian. An
> ancient Standards-Version is used, and an extra-license-file false
> positive is not addressed. The package also installs symlinks for
> nagios3 which has been removed from unstable.
> 
> The attached patches resolve this issue.

maybe Alex has feelings about that, from my side, no objections to
upload your changes for this package. I never felt into really
maintaining the package.

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature


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

2016-12-23 Thread Fabian Greffrath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Freitag, den 23.12.2016, 18:27 + schrieb Jonathan Dowland:
> On second (or third thoughts)... I've uploaded the package as-is to
> DELAYED-5.
> I suppose worst case it's borked and a fixed package needs to be
> uploaded
> after, that might be better than not getting this done in time for
> the freeze.

Thank you very much for this!

> ...upgrade seems to work, there's a problem with downgrading from
> these -5
> versions to -4 but I guess that's never officially supported anyway.

I don't think we need to support downgrading at all (i.e. I don't think
any package ever did). Forward is the only way. ;)

> Sorry yes, that's not quite what I meant. hopefully the latest pushes
> to
> the proposed-consolidate branch clear that up.

Not entirely. Sorry, but I think there is a glitch in the latest
commit. The chocolate-doom package should have kept the Breaks/Replaces
against chocolate-common (<< 2.2.1-5~).

Suppose you have only chocolate-common 2.2.1-4 installed and then
attempt to install chocolate-doom 2.2.1-5. The latter package contains
files that are owned by the former one and thus the installation will
fail. Do you think it is possible to fix this and override your latest
upload again?

Cheers,

Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlhdiPgACgkQy+qOlwzN
Wd+roA/+JARbWQcgFPNPDOyBcK8f0DnJpWUOUskocYs8NLvSkSvtWKXEbL2dWJe4
M36zcfyF35xUgXPVU7TmBcl6sswl084hv+OgpIR4WbxSNRH9hSaHWJ9eA1blmJzr
C4pJIxLAAqYgA9fUbgyGq8pQEWL+b4g1+/R71CNpgZ9obO3uX7h9FxNSqS9ekxS3
sQEQuFx25EeSRaNvmEIhnrGFxyqXG+RktrLr7jPfA6boKezZjWN94qYLSsWJQ0ZV
juPuskUoEFyFVnAgwvGlhWC9OcNWFg7IZuI5l9+pED+bfhX6hS03y0R5MhYvfejD
NS/13x9GIQX8Qz9F+kzQ6nb8+cFkUGzMsTWt1A3SumyQktd09ZCbdWvZnuKScsBr
pULgao2hkw/SAbGtcOP3GlXugccpopSU1RVvevsZp1YCgswOGrbFPTRX2l1O4yQ3
U0bhZYfLtFvoYv4LnsUZ0blotYQ2LrFDT1jNJL07D6q6Ti35LXSJEsJXUgeSohN2
sUlQYhjP/VETYv8+pp3rsOj6DChv0fKIh/WS2yAsNHZpU/JYoJUSfiBAJgXoRWjq
N2r8gKf6HmX88ueUV3wC1j5KzeSJDq8S+zwMvuB10cfgisrWJxjhbXLf783uPijE
uB4rtFFl5tvWBOfJt9be7IgSOb3Ksn5KjtUgr43P+UrXH73UD8w=
=zIIt
-END PGP SIGNATURE-



Bug#849211: Installing gives multiple errors

2016-12-23 Thread Scott Kitterman
On Fri, 23 Dec 2016 15:42:09 + James Cloos  wrote:
...
> Argument "0.33_01" isn't numeric in numeric lt (<) at
> /usr/share/perl5/Net/Server/Log/Sys/Syslog.pm line 42.
> 
> 
> So, at the very least it should depend on libdbd-sqlite3-perl.
> 
> I haven’t figured out where the 0.33_01 comes from.

That looks like it's from libnet-server-perl.  I'd suggest a bug against that 
package.  I see the same error.

Scott K

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


Bug#643595: SNES9x upstream released 1.54.1

2016-12-23 Thread Marcel Partap
tarballs: https://sites.google.com/site/bearoso/snes9x/
git repo: https://github.com/snes9xgit/snes9x

> It's still alive (!)
http://www.snes9x.com/phpbb3/viewtopic.php?f=8&t=23752

> Snes9x 1.54.1
> - GTK+: Properly use --std=c++11 when compiling xBRZ.   (BearOso)
> - Win32: Save window position when toggling fullscreen. (OV2)
> - Win32: Do not assign down-left binding to down-right. (OV2)


> Snes9x 1.54
> - Changed the S-SMP core module to one written by byuu. (byuu, BearOso)
>   This has the effect of increased accuracy, fewer
>   speed hacks, but also regresses a few speed-hack games.
> - Improved IRQ emulation in several cases.  (OV2)
> - Added rewind support. (Themaister, OV2)
> - Included libretro port.   (OV2, libretro 
> team)
> - Added bps soft-patching support   (OV2)
> - Fixed MMC bank register bit 7, restored 64mbit ExLoRom
>   map   (FuSoYa)
> - GTK+, Windows: Added xBRZ filter  (Zenju, OV2, 
> nmagre)
> - GTK+: Fixed several issues with GTK+3.(BearOso)
> - GTK+: Added extra aspect ratio options.   (BearOso)
> - GTK+: Added option to mute sound when using turbo mode.   (BearOso)
> - GTK+: Fixed expose handling to reduce overdraw and(BearOso)
>   improve performance.
> - GTK+: Updated and universalized Spanish translation.  (jristz)
> - Unix: Added Xv support and fixed several bugs.(greg-kennedy)
> - Win32: Added CG meta shader support   (OV2, Themaister)
> - Win32: Added support to detect joypad changes (OV2)
> - Win32: Fixed unicode command line parameters,
>   Fixed controller command line parameters  (OV2)
> - Win32: Added quit hotkey  (OV2)
> - Win32: Fixed custom rom dialog(OV2)
> - Win32: Fixed various cheat dialog issues  (gocha, OV2)
> - Win32: Added hotkey for fast forward toggling (gocha)
> - Win32: Added drag and drop support for movies (gocha)
> - Win32: Fixed blargg filter for regular width hires(OV2)
> - Win32: Fixed snapshot loading from unicode paths  (OV2)
> - Win32: Changed open-with file-association method, should
>   no longer change explorer icons for otherwise
>   unassociated extensions; removed legacy extensions(OV2)

Would be very cool if it would find its way back into Debian, zsnes & higan 
don't work everywhere and snes9x always had a robust user experience..
#Regards!



Bug#848993: RFS: llmnrd/0.2-1 [ITP]

2016-12-23 Thread Pali Rohár
On Friday 23 December 2016 14:46:53 Andreas Henriksson wrote:
> Hi again Pali Rohár,
> 
> On Fri, Dec 23, 2016 at 11:29:59AM +0100, Pali Rohár wrote:
> > Now lintian on mentors shows warning:
> > 
> > package-uses-experimental-debhelper-compat-version
> > 10
> 
> Yes, lintian is simply wrong/outdated here. It's just a tool to help
> you find issues, don't blindly follow lintian like if it was
> religion or policy. Normally you'd consider a lintian override in
> cases where you have confirmed lintian is wrong, but in this case
> the warning will likely go away by itself if you just give it some
> time for new lintian releases to appear.
> 
> More importantly I wanted to mention a detail which might be useful
> to consider before uploading your package:
> 
> You use DAEMON_OPTS in the default file, while sysvinit seems to be
> standardizing on DAEMON_ARGS  to avoid the messy work of later
> migration of conffile settings you might want to consider switching
> to DAEMON_ARGS now before the first version has been uploaded. You
> decide.

Hm... Another option would be to use LLMNRD_OPTS. Looks like other 
daemons in Debian (e.g. ntpd or rsync) use env variable _OPTS in 
/etc/default/.

What do you think about it?

> FYI, I also filed issues upstream for potential systemd service
> improvements. #15, #16.
> Shipping the file is as simple as running
> "echo etc/llmnrd.service >> debian/llmnrd.install"

Yes, I know. But first we need fully working service file.

> as dh compat 10 takes care of the rest for you.
> You might want to consider dropping the attached patch in
> debian/patches/ and adding debian/patches/series containing it's
> name to preserve default file configuration under both init systems.
> 
> Regards,
> Andreas Henriksson

-- 
Pali Rohár
pali.ro...@gmail.com


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


Bug#849227: onionshare: CLI never shuts down after download - GUI always does

2016-12-23 Thread Henrik Ahlgren
Package: onionshare
Version: 0.6-3
Severity: important

Manual page reads:

"OnionShare's default behaviour is to shut down the hidden service and
to stop once the file has been downloaded. You can prevent this
behaviour by invoking the --stay-open option. This can be useful if
you want multiple people to access the same file."

However, the command line version always allows multiple downloads
until onionshare is manually stopped, with or without --stay-open.

-8<--
$ onionshare /usr/bin/vi
Connecting to Tor control port to set up hidden service on port 60373.
Preparing files to share.
Waiting for HS to be ready:
Trying...  * Running on http://127.0.0.1:60373/
Not ready yet.
Trying... Ready!
Give this URL to the person you're sending the file to:
http://.onion/YY

Press Ctrl-C to stop server
127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET / HTTP/YY 
1.1" 200 -
127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET /YY HTTP/1.1" 
200 -
127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET /YY HTTP/1.1" 
200 -
^C127.0.0.1 - - [DD/Dec/2016 MM:MM:SS] "GET 
/YY/shutdown HTTP/1.1" 200 -
-8<--

The GUI version malfunctions the opposite way: there is a checkbox
"Stop server automatically", but it has no effect – the server always
stops after the first download.

This is quite confusing and the CLI behaviour is potentially unsecure.

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

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

Versions of packages onionshare depends on:
ii  python   2.7.9-1
ii  python-flask 0.10.1-2
ii  python-qt4   4.11.2+dfsg-1
ii  python-stem  1.2.2-1.1
ii  torbrowser-launcher  0.1.9-1+deb8u3

onionshare recommends no packages.

onionshare suggests no packages.

-- debconf-show failed



Bug#834203: reprepro: Error including .changes: "'*.debian.tar.xz' has the wrong architecture to add it to unstable!"

2016-12-23 Thread Manuel A. Fernandez Montecelo
2016-12-22 15:06 GMT+01:00 Bernhard R. Link :
> Control: tags -1 +moreinfo
>
> First sorry for the very late reply.

Thanks for following up, in any case!


> * Manuel A. Fernandez Montecelo  [161222 14:03]:
>> Possibly I am doing something wrong and couldn't see any bugs or changes in 
>> the
>> changelog that might have caused this, but I am pretty sure that this was
>> working only weeks ago in the same system with approximately the same 
>> versions
>> (it's unstable, so I update often).
>>
>> Using "--ignore wrongarchitecture" or "surprisingarch" doesn't help.
>>
>> It happens with tar.xz and .gz files, either .debian or original (for native
>> packages) or also diff.gz.
>>
>> includedeb works fine for including the .debs in the .changes files.
>>
>> Any clue if there's a problem somewhere or if I am doing something wrong (in
>> which case, sorry for the noise)?
>
> Could you make sure you have "source" in your Architectures: line in
> conf/distributions? (Without this reprepo thinks you do not want source
> files in this distribution and thus will complain if those are added.)
>
> If you do not want to include sources, please try -T deb option before
> the checkin. (Or -A yourarchitecture)

It's been a few months now and I ended up fixing the problem after a
while -- I think that it was the "sourcce" thing that you mention...
but unfortunately I don't have access to that system anymore, so I
cannot confirm.

>From my side I think that this report can be closed, unless you want
to leave it open for some reason.


Cheers.
-- 
Manuel A. Fernandez Montecelo 



Bug#832496: Processed: closing 832496

2016-12-23 Thread Michael Biebl
Am 23.12.2016 um 06:45 schrieb Salvatore Bonaccorso:
> Control: fixed -1 2.35.4-1
> 
> On Fri, Dec 23, 2016 at 01:03:05AM +, Debian Bug Tracking System wrote:
>> Processing commands for cont...@bugs.debian.org:
>>
>>> close 832496 2.36.2-1
>> Bug #832496 [src:gdk-pixbuf] gdk-pixbuf: CVE-2016-6352: ico loader crashes 
>> when loading crafted file
>> Marked as fixed in versions gdk-pixbuf/2.36.2-1.
>> Bug #832496 [src:gdk-pixbuf] gdk-pixbuf: CVE-2016-6352: ico loader crashes 
>> when loading crafted file
>> Marked Bug as done
> 
> Actually, unless my research is wrong the first fixing version is
> 2.35.4-1.
> 
> Let me know if that's wrong please.

I just tested the current version in unstable and didn't research the
correct version. Thanks for caring and fixing it.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#841208: fixed in monkeysphere 0.41-1

2016-12-23 Thread Petter Reinholdtsen
[Daniel Kahn Gillmor]
> I'm likely to try proposal (a) as 0.41-2 unless i hear other
> suggestions.

In Debian Edu we ran into a similar problem within debian-installer, when
setting up Kerberos.  The installation would hang because the Linux kernel
collect entropy from so few sources and almost none of the sources have
activity during installation.  We solved it by running a shell script loop
in the background checking the entropy level, and flushing the disk cache
and doing find / to generate disk IO when entropy run low.

Perhaps an idea for the test code?

Check out
https://anonscm.debian.org/git/debian-edu/debian-edu-config.git/tree/share/debian-edu-config/d-i/finish-install
 >
for the Debian Edu implementation.

-- 
Happy hacking
Petter Reinholdtsen



Bug#844055: Doesn't support conversion of images with dimensions of 256x256 or greater.

2016-12-23 Thread Jeremy Bicha
I confirm that the patch works well for me.

I went ahead and pushed it to Ubuntu because there's an
Ubuntu-specific package (hdhomerun-config-gui) that can benefit from
the fix.

Thanks,
Jeremy Bicha



Bug#848825: lintian: Does not applies source-is-missing overrides unless path has wildcard

2016-12-23 Thread Bastien ROUCARIES
On Tue, Dec 20, 2016 at 12:26 AM, Jérémy Lal  wrote:
> Package: lintian
> Version: 2.5.49
> Severity: normal
>
> This doesn't override anything:
>
> source/lintian-overrides
> source-is-missing deps/v8/benchmarks/regexp.js
> source-is-missing doc/api_assets/sh_javascript.min.js
> source-is-missing test/fixtures/throws_error5.js
> source-is-missing test/fixtures/throws_error6.js
>
> and it lists those overrides as unused.
>
> This does work as intended:
> source/lintian-overrides
> source-is-missing deps/v8/benchmarks/regexp.js*
> source-is-missing doc/api_assets/sh_javascript.min.js*
> source-is-missing test/fixtures/throws_error5.js*
> source-is-missing test/fixtures/throws_error6.js*
>
> Cheers,
>
> Jérémy.
Could you check if they are some trailing whitespace in lintian output ?



>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages lintian depends on:
> ii  binutils  2.27.51.20161212-1
> ii  bzip2 1.0.6-8
> ii  diffstat  1.61-1
> ii  file  1:5.29-2
> ii  gettext   0.19.8.1-1
> ii  intltool-debian   0.35.0+20060710.4
> ii  libapt-pkg-perl   0.1.30
> ii  libarchive-zip-perl   1.59-1
> ii  libclass-accessor-perl0.34-1
> ii  libclone-perl 0.38-2+b1
> ii  libdpkg-perl  1.18.17
> ii  libemail-valid-perl   1.202-1
> ii  libfile-basedir-perl  0.07-1
> ii  libipc-run-perl   0.94-1
> ii  liblist-moreutils-perl0.416-1+b1
> ii  libparse-debianchangelog-perl 1.2.0-12
> ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
> ii  libtext-levenshtein-perl  0.13-1
> ii  libtimedate-perl  2.3000-2
> ii  liburi-perl   1.71-1
> ii  libyaml-libyaml-perl  0.63-1+b1
> ii  man-db2.7.6.1-2
> ii  patchutils0.3.4-2
> ii  perl  5.24.1~rc4-1
> ii  t1utils   1.39-2
> ii  xz-utils  5.2.2-1.2
>
> Versions of packages lintian recommends:
> ii  dpkg 1.18.17
> ii  libautodie-perl  2.29-2
> ii  libperlio-gzip-perl  0.19-1+b2
> ii  perl 5.24.1~rc4-1
> ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc4-1
>
> Versions of packages lintian suggests:
> ii  binutils-multiarch 2.27.51.20161212-1
> ii  dpkg-dev   1.18.17
> ii  libhtml-parser-perl3.72-3
> ii  libtext-template-perl  1.46-1
>
> -- no debconf information
>



Bug#849228: Tint2 with "autohide = 1" (autohide enabled) makes Virtualbox unusable.

2016-12-23 Thread Nekki Nekki
Package: tint2
Version: 0.12.12-1
Severity: important


Dear maintainers,

If "autohide" is set to 1 "virtualbox" became unusable. Please note that
ONLY "virtualbox" window and guests windows are affected. The problem is
reproducible under any DE/WM. Please, check bug #844165 for more info.

Thanks,

Nekki


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

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

Versions of packages tint2 depends on:
ii  libatk1.0-0   2.22.0-1
ii  libc6tint22.24-8
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libimlib2 1.4.8-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  librsvg2-22.40.16-1
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.4-2
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1

tint2 recommends no packages.

tint2 suggests no packages.

-- no debconf information


Bug#828342: Re: [Htt-developers] Building with OpenSSL 1.0.2 is sufficient for stretch

2016-12-23 Thread Sebastian Andrzej Siewior
On 2016-12-23 09:42:22 [+0100], Christian Liesch wrote:
> Hey all

Hi,

> Thanks for the patch, I build a new version => 2.4.18. Enjoy.

Thank you Christian.
Eva, I don't know if you have seen Christian's email regarding 2.4.18.
It did not make it to the bug report…

  
https://sourceforge.net/projects/htt/files/htt2.4/httest-2.4.18/httest-2.4.18.tar.gz/download

The new release should have everything needed.

> Gruss
> Christian

Sebastian



Bug#849230: kodi-pvr-hdhomerun: Fails to build from source with kodi 2:17.0~beta6+dfsg1-1

2016-12-23 Thread Jeremy Bicha
Package: kodi-pvr-hdhomerun
Version: 2.4.2+git20160820-1
Severity: serious

kodi-pvr-hdhomerun fails to build from source in a clean sid chroot.

[ 25%] Building CXX object CMakeFiles/pvr.hdhomerun.dir/src/client.cpp.o
/usr/bin/c++   -DBUILD_KODI_ADDON -Dpvr_hdhomerun_EXPORTS
-I/usr/include/kodi -I/usr/include/p8-platform -I/usr/include/jsoncpp
-I/usr/include/libhdhomerun  -g -O2
-fdebug-prefix-map=/<>/kodi-pvr-hdhomerun-2.4.2+git20160820=.
-fstack-protector-strong -Wformat -Werror=format-security
-I/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/src/ -Wdate-time
-D_FORTIFY_SOURCE=2 -flto -O3 -DNDEBUG -fPIC   -DTARGET_POSIX
-DTARGET_LINUX -D_LINUX -o
CMakeFiles/pvr.hdhomerun.dir/src/client.cpp.o -c
/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/src/client.cpp
/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/src/client.cpp: In
function ‘bool SeekTime(int, bool, double*)’:
/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/src/client.cpp:387:6:
error: conflicting declaration of C function ‘bool SeekTime(int, bool,
double*)’
 bool SeekTime(int,bool,double*) { return false; }
  ^~~~
In file included from
/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/src/client.cpp:26:0:
/usr/include/kodi/xbmc_pvr_dll.h:592:8: note: previous declaration
‘bool SeekTime(double, bool, double*)’
   bool SeekTime(double time, bool backwards, double *startpts);
^~~~
CMakeFiles/pvr.hdhomerun.dir/build.make:65: recipe for target
'CMakeFiles/pvr.hdhomerun.dir/src/client.cpp.o' failed
make[3]: *** [CMakeFiles/pvr.hdhomerun.dir/src/client.cpp.o] Error 1
make[3]: Leaving directory
'/<>/kodi-pvr-hdhomerun-2.4.2+git20160820/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:102: recipe for target
'CMakeFiles/pvr.hdhomerun.dir/all' failed


Since it fails in the same spot in Ubuntu, you can view the full build log at
https://launchpad.net/ubuntu/+source/kodi-pvr-hdhomerun/2.4.2+git20160820-1build1/+build/11774599

Thanks,
Jeremy Bicha



Bug#849229: Unneeded dependency on ser2net

2016-12-23 Thread Sjoerd Simons
Package: lava-dispatcher
Version: 2016.12-1
Severity: normal

Lava dispatcher has a dependency on ser2net, but this is only needed if usng
ser2net to provide serial for DUTs. Please downgrade ser2net dependency to a
recommends

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

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

Versions of packages lava-dispatcher depends on:
ii  file  1:5.29-2
ii  lava-tool 0.14-2
ii  lsb-base  9.20161125
ii  parted3.2-17
ii  python-configglue 1.0-1
ii  python-configobj  5.0.6-2
ii  python-daemon 2.1.1-1
ii  python-guestfs1:1.34.3-5
ii  python-json-schema-validator  2.3.1-3
ii  python-lzma   0.5.3-3
ii  python-netifaces  0.10.4-0.1+b2
ii  python-nose   1.3.7-2
ii  python-pexpect4.2.1-1
ii  python-pyudev 0.21.0-1
ii  python-requests   2.12.4-1
ii  python-serial 3.2.1-1
ii  python-setuptools 32.0.0-1
ii  python-yaml   3.12-1
ii  python-zmq16.0.2-2
ii  python2.7 2.7.13-1
pn  python:any
pn  ser2net   
ii  sudo  1.8.19-1
ii  tar   1.29b-1.1
ii  telnet0.17-41

Versions of packages lava-dispatcher recommends:
ii  bridge-utils 1.5-10
ii  git  1:2.11.0-1
ii  kpartx   0.6.4-1
ii  libguestfs-tools 1:1.34.3-5
ii  lxc  1:2.0.6-1
ii  nfs-kernel-server1:1.3.4-2
ii  ntp  1:4.2.8p9+dfsg-2
ii  openbsd-inetd0.20140418-2
ii  python-setproctitle  1.1.10-1
ii  qemu-system-x86  1:2.7+dfsg-3+b1
ii  rpcbind  0.2.3-0.5
ii  rsync3.1.2-1
ii  sshfs2.8-1
pn  tftpd-hpa
ii  u-boot-tools 2016.11+dfsg1-3
ii  unzip6.0-21
ii  xz-utils 5.2.2-1.2

Versions of packages lava-dispatcher suggests:
ii  bzr  2.7.0+bzr6619-4

-- no debconf information



Bug#848975: [Bash-completion-devel] Bug#848975: bash-completion: Fails to auto-complete /etc/hosts hostnames after ~/.ssh/config file created

2016-12-23 Thread Miel Donkers
I've been trying to look at the source, to find what the problem is. But
with my limited knowledge I could use some assistance.

Looking at the "ssh" completion, it seems hosts are coming from the
"hostcomplete" variable / parameter. But I haven't found where this one is
coming from.
I tried disabling loading the "~/.ssh/config" file in the "bash-completion"
script, but this didn't make a difference.

Could someone perhaps explain where the "hostcomplete" is coming from, so I
might be able to debug this further?

Thx,
Miel

On 22 December 2016 at 10:35, Ville Skyttä  wrote:

> FWIW, I (upstream) cannot reproduce using upstream bash-completion
> development code directly on Fedora, haven't tried with Debian.
>



-- 
*Miel Donkers | Agile Solution Developer*


*codecentric Nederland BVtel: +31 (0) 85.400.0011 | mobiel: +31 (0)
6.511.977.38 | miel.donk...@codecentric.nl *

*Breda office (postal address) | Reduitlaan 33 | 4814DC Breda | Netherlands*
*Amsterdam office | Johan Huizingalaan 763a | 1066VH Amsterdam |
Netherlands*
*www.codecentric.nl  | blog.codecentric.nl
 | @codecentric_nl
*


Volg ons op LinkedIn

Tweet met ons op Twitter 
Lees mee op onze blog 

Like ons op Facebook 
Volg ons op Github 

Meer over ons: codecentric Nederland BV is een Java Software Craftsmen
projecten en consultancy organisatie, met focus op Continuous Delivery,
Agile development en Applicatie Performance Management (AppDynamics Pro
). codecentric is
kennis gedreven met ruim 350 medewerkers in Nederland, Duitsland, Bosnië en
Herzegovina en Servië.


Bug#842707: aptitude keep-all hangs forever

2016-12-23 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + moreinfo


Hi,

2016-10-31 14:53 Andreas:

Package: aptitude
Version: 0.8.3-1+b1
Severity: normal

Dear Maintainer,

trying to keep back all possible upgrades with "aptitude keep-all" currently
results in aptitude hanging with aptitude generating a high CPU load (around
84% on my machine, shown by htop). Interestingly this also happens when I have
upgraded all upgradable packages before, so there would actually not be
anything to do.


Do you have GzipIndexes indexes enabled in apt/aptitude config?

I seem to remember that there were problems related with this in the
past.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#842221: W: Can't drop privileges for downloading as file 'linux_4.8.4-1~exp1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

2016-12-23 Thread Manuel A. Fernandez Montecelo

Control: severity -1 minor
Control: tags -1 + wontfix
Control: close -1


Hi,

2016-10-27 06:20 積丹尼 Dan Jacobson:

Package: aptitude
Version: 0.8.3-1+b1

# aptitude source linux
Executing 'apt source linux'

[...]
W: Can't drop privileges for downloading as file 'linux_4.8.4-1~exp1.dsc' 
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)


This is a warning coming from apt and we cannot do anything about it, so
closing.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#848825: lintian: Does not applies source-is-missing overrides unless path has wildcard

2016-12-23 Thread Jérémy Lal
Package: lintian
Version: 2.5.49
Followup-For: Bug #848825

Please see attached output obtained using
lintian --no-tag-display-limit > ../lintian_output

Jérémy
E: nodejs source: source-is-missing doc/api_assets/sh_javascript.min.js
N: 
N:The source of the following file is missing. Lintian checked a few
N:possible paths to find the source, and do not find it.
N:
N:Please repack your package to include the source or add it to
N:"debian/missing-sources" directory.
N:
N:If this is a false-positive, please report a bug against Lintian.
N:
N:Severity: serious, Certainty: possible
N:
N:Check: cruft, Type: source
N: 
E: nodejs source: source-is-missing test/fixtures/throws_error5.js line length 
is 516 characters (>512)
E: nodejs source: source-is-missing test/fixtures/throws_error6.js line length 
is 1029 characters (>512)
E: nodejs source: source-is-missing deps/v8/benchmarks/regexp.js line length is 
2305 characters (>512)


Bug#849231: phpmyadmin: create/drop index shows resulting query only briefly

2016-12-23 Thread Peter Roes
Package: phpmyadmin
Version: 4:4.2.12-2+deb8u2
Severity: normal
Tags: patch

Dear Maintainer,

After I upgraded to Debian 8, I noticed create/drop index actions in phpmyadmin
only show the executed query for a brief moment. Consequently, I am not longer
able to copy these queries, e.g. for journaling purposes.

It looks like a double refresh of the underlaying page, so I took a look at the
javascript files, and comment out a couple of lines which fixed the problem for
me.

I have created diff files which I will upload with this report.

With kind regards,

Peter



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

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

Versions of packages phpmyadmin depends on:
ii  dbconfig-common1.8.47+nmu3+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  libapache2-mod-php55.6.29+dfsg-0+deb8u1
ii  libjs-sphinxdoc1.2.3+dfsg-1
ii  perl   5.20.2-3+deb8u6
ii  php-gettext1.0.11-1
ii  php5-json  1.3.6-1
ii  php5-mcrypt5.6.29+dfsg-0+deb8u1
ii  php5-mysql 5.6.29+dfsg-0+deb8u1
ii  ucf3.0030

Versions of packages phpmyadmin recommends:
ii  apache2 [httpd]  2.4.10-10+deb8u7
ii  apache2-mpm-prefork [httpd]  2.4.10-10+deb8u7
ii  mysql-client 5.5.53-0+deb8u1
ii  mysql-client-5.5 [virtual-mysql-client]  5.5.53-0+deb8u1
ii  php-tcpdf6.0.093+dfsg-1
ii  php5-gd  5.6.29+dfsg-0+deb8u1

Versions of packages phpmyadmin suggests:
ii  epiphany-browser [www-browser]   3.14.1-1
ii  firefox-esr [www-browser]45.6.0esr-1~deb8u1
ii  iceape [www-browser] 2.7.12-1
ii  mysql-server 5.5.53-0+deb8u1
ii  mysql-server-5.5 [virtual-mysql-server]  5.5.53-0+deb8u1
ii  w3m [www-browser]0.5.3-19

-- debconf information:
  phpmyadmin/dbconfig-remove:
* phpmyadmin/reconfigure-webserver: apache2
  phpmyadmin/upgrade-backup: true
  phpmyadmin/install-error: abort
  phpmyadmin/remove-error: abort
  phpmyadmin/missing-db-package-error: abort
  phpmyadmin/remote/host:
  phpmyadmin/dbconfig-install: true
  phpmyadmin/internal/reconfiguring: false
  phpmyadmin/mysql/method: unix socket
  phpmyadmin/db/app-user: phpmyadmin
  phpmyadmin/dbconfig-reinstall: false
  phpmyadmin/internal/skip-preseed: false
  phpmyadmin/setup-username: admin
  phpmyadmin/remote/newhost:
  phpmyadmin/dbconfig-upgrade: true
  phpmyadmin/purge: false
  phpmyadmin/upgrade-error: abort
  phpmyadmin/remote/port:
  phpmyadmin/mysql/admin-user: root
  phpmyadmin/passwords-do-not-match:
--- functions.org.js	2016-12-23 22:38:47.0 +0100
+++ functions.js	2016-12-21 16:16:02.0 +0100
@@ -2987,7 +2987,7 @@
 }
 $('div.no_indexes_defined').hide();
-if (callback_success) {
-   callback_success();
-}
+//if (callback_success) {
+//   callback_success();
+//}
 PMA_reloadNavigation();
 } else {
--- indexes.org.js	2016-12-23 22:39:34.0 +0100
+++ indexes.js	2016-12-21 16:26:22.0 +0100
@@ -162,7 +162,7 @@
 PMA_highlightSQL($('#page_content'));
 }
-PMA_commonActions.refreshMain(false, function () {
-$("a.ajax[href^=#indexes]").click();
-});
+//PMA_commonActions.refreshMain(false, function () {
+//$("a.ajax[href^=#indexes]").click();
+//});
 PMA_reloadNavigation();
 } else {


Bug#846274: Fwd: Bug#846274: GNOME Software catalog entry missing for KeePassX

2016-12-23 Thread Reinhard Tartler
Felix, that patch looks OK to me.


Care to apply it upstream?

Thanks,
Reinhard

 Forwarded Message 
Subject:Bug#846274: GNOME Software catalog entry missing for KeePassX
Resent-Date:Tue, 29 Nov 2016 19:27:01 +
Resent-From:asciiw...@seznam.cz
Resent-To:  debian-bugs-dist@lists.debian.org
Resent-CC:  Reinhard Tartler 
Date:   Tue, 29 Nov 2016 20:22:11 +0100 (CET)
From:   asciiw...@seznam.cz
Reply-To:   asciiw...@seznam.cz, 846...@bugs.debian.org
To: sub...@bugs.debian.org



Package: keepassx
Version: 2.0.2-1
Severity: normal
Tags: patch

The KeePassX package cannot be found and/or installed using GNOME
Software because the keepassx.desktop file contained in the package is
missing a "Comment" section that is required by AppStream to generate
correct metadata. The attached patch fixes the issue.

[Test Case]
1. Open the GNOME Software application.
2. Type "KeePassX" into the search bar.
--- keepassx.desktop.orig	2016-11-03 17:29:34.923992352 +0100
+++ keepassx.desktop	2016-11-03 17:36:19.817971778 +0100
@@ -5,6 +5,7 @@
 GenericName[es]=Gestor de contraseñas
 GenericName[fr]=Gestionnaire de mot de passe
 GenericName[ru]=менеджер паролей
+Comment=Cross Platform Password Manager
 Exec=keepassx %f
 Icon=keepassx
 Terminal=false



Bug#849232: python-brainstorm: test_handler_operations.py::test_conv2d_forward_batch_numpy FAILED

2016-12-23 Thread Daniel Stender
Source: python-brainstorm
Version: 0.5-2
Severity: important

Since a few runs [1], Brainstorm starts to break in the DEP-8 tests:


brainstorm/tests/test_handler_operations.py::test_conv2d_forward_batch_numpy 
FAILED
=== short test summary info 
SKIP [1] brainstorm/tests/test_describable.py:315: requires pycuda and skcuda

=== FAILURES ===
___ test_conv2d_forward_batch_numpy 

def test_conv2d_forward_batch_numpy():
_h = NumpyHandler(dtype=dtype)
for input_shape in ((3, 3), (5, 4), (4, 9)):
for nr_images in (1, 4):
for nr_input_maps in (1, 3):
for nr_filters in (1, 3):
for kernel_shape in ((1, 1), (2, 2), (3, 2)):
for stride in ((1, 1), (2, 2), (1, 2)):
for padding in (0, 1):
inputs = np.random.rand(
nr_images, input_shape[0], 
input_shape[1],
nr_input_maps).astype(dtype)
weights = np.random.rand(
nr_filters, kernel_shape[0],
kernel_shape[1], nr_input_maps).astype(
dtype)
bias = np.zeros(nr_filters).astype(dtype)

output_height = \
(input_shape[0] + 2 * padding -
 kernel_shape[0]) / stride[0] + 1
output_width = \
(input_shape[1] + 2 * padding -
 kernel_shape[1]) / stride[1] + 1

outputs = np.zeros((nr_images,
output_height,
output_width,
>   nr_filters), 
> dtype=dtype)
E   TypeError: 'float' object cannot be 
interpreted as an integer

brainstorm/tests/test_handler_operations.py:86: TypeError
 pytest-warning summary 
WC1 None [pytest] section in setup.cfg files is deprecated, use [tool:pytest] 
instead.
 Interrupted: stopping after 1 failures 
== 1 failed, 72 passed, 1 skipped, 1 pytest-warnings in 0.90 seconds ===


I haven't got into it now, but it could be this is another regression from the
update of Numpy to 1.12.0, like it affected other packages.

Thanks,
DS

[1] https://ci.debian.net/packages/p/python-brainstorm/unstable/amd64/

[2] https://bugs.debian.org/849177 (python-numpy: Please revert transition that 
happened past transition freeze)

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

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



Bug#847965: aptitude: please, update Russian translation of section-descriptions

2016-12-23 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


2016-12-12 17:43 Lev Lamberov:

Package: aptitude
Version: 0.8.3-1+b2
Severity: wishlist
Tags: patch

Dear Maintainer,

please, update Russian translation of section-descriptions.


Updated, thanks!


--
Manuel A. Fernandez Montecelo 



Bug#842186: aptitude: [INTL:nl] Dutch po file for the aptitude package's documentation

2016-12-23 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


2016-10-26 20:20 Frans Spiesschaert:


Package: aptitude
Severity: wishlist
Tags: l10n patch


Dear Maintainer,

==
Please find attached the updated Dutch po file for the aptitude package's
documentation. It has been submitted for review to the
debian-l10n-dutch mailing list. Please add it to your next package
revision. It should be put as "doc/po4a/po/nl.po" in your package build tree.


Updated, thanks!


--
Manuel A. Fernandez Montecelo 



Bug#849210: ntopng: fails to start

2016-12-23 Thread Ludovico Cavedon
package ntopng
tags 849210 + confirmed
tags 849210 grave
thanks

On Fri, Dec 23, 2016 at 8:47 PM Ludovico Cavedon  wrote:

> On Fri, Dec 23, 2016 at 4:48 PM Aaron M. Ucko  wrote:
>
> As of version 2.4, ntopng fails to start on my system.  I'm not sure
> what specifically is going wrong; all I see in ntopng.log is
>
> 23/Dec/2016 10:38:43 [Ntop.cpp:1121] Setting local networks to 127.0.0.0/8
> 23/Dec/2016  10:38:43 [Redis.cpp:92]
> Successfully connected to redis 127.0.0.1:6379@0
> 23/Dec/2016 10:38:43 [Ntop.cpp:1095] Parent process is exiting (this is
> normal)
>
>
>
Yes, I was able to reproduce it.
I am bumping severity to grave because it is basically causing ntopng to
not start on almost every system.

The problem is that the default PID path changed.

The  workaound is to change
/etc/systemd/system/multi-user.target.wants/ntopng.service from
PIDFile=/var/tmp/ntopng.pid
to
PIDFile=/var/run/ntopng.pid

I will upgrade a fix soon.

Cheers,
Ludovico


<    1   2   3   >