Bug#860791: seafile-gui: fails to install

[Andreas Henkel]

Package: seafile-gui
Severity: important

Dear Maintainer,


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt install seafile-gui
   * What was the outcome of this action?
 Paketlisten werden gelesen... Fertig
 Abhängigkeitsbaum wird aufgebaut.   
 Statusinformationen werden eingelesen Fertig
 Einige Pakete konnten nicht installiert werden. Das kann bedeuten,
 dass
 Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
 Unstable-Distribution verwenden, dass einige erforderliche Pakete
 noch
 nicht erstellt wurden oder Incoming noch nicht verlassen haben.
 Die folgenden Informationen helfen Ihnen vielleicht, die Situation
 zu lösen:

 Die folgenden Pakete haben unerfüllte Abhängigkeiten:
  seafile-gui : Hängt ab von: libssl1.0.0 (>= 1.0.0) ist aber nicht 
installierbar
Hängt ab von: ccnet (>= 5.1.2) soll aber nicht installiert 
werden
Hängt ab von: seafile-daemon (>=5.1.2) soll aber nicht 
installiert werden

   * What outcome did you expect instead?
 successful install



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

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

Bug#860790: freecad: "couldn't create parsetab in /usr/lib...."

[lkcl]

Package: freecad
Version: 0.16+dfsg2-3
Severity: normal
Tags: upstream

on OpenSCAD CSG import (previous version did not do this) the following output
occurs:

FreeCAD 0.16, Libs: 0.16R
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2015
  #   ###     
  ##  # #   #   # 
  # ##     # #   #  #   # 
    # # #  # #  #  # #  #   # 
  # #      ## # #   # 
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##

ImportCSG Version 0.5d
Start Lex
End Lex
Load Parser
WARNING: Token 'DOT' defined, but not used
WARNING: Token 'WORD' defined, but not used
WARNING: There are 2 unused tokens
WARNING: Couldn't create 'parsetab'. [Errno 13] Permission denied: 
'/usr/lib/freecad/Mod/OpenSCAD/parsetab.py'
Parser Loaded
Start Parser


that looks very familiar: it's likely to be python-ply, which by default
will try to write an optimised cache of its parse table into the cwd
unless otherwise told not to (or a writeable location given).




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

Kernel: Linux 4.9.0-1-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

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.23-4
ii  libcoin80v5 3.1.4~abc9f50+dfsg1-1
ii  libfreeimage3   3.17.0+ds1-1.1+b1
ii  libfreetype62.6.3-3+b1
ii  libgcc1 1:6.3.0-10
ii  libgl1-mesa-glx [libgl1]13.0.6-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-1
ii  liboce-modeling10   0.17.2-1
ii  liboce-ocaf-lite10  0.17.2-1
ii  liboce-ocaf10   0.17.2-1
ii  liboce-visualization10  0.17.2-1
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-1
ii  libqt4-network  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-opengl   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-svg  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtwebkit42.3.4.dfsg-3
ii  libshiboken1.2v51.2.2-2+b2
ii  libsoqt4-20 1.6.0~e8310f-2+b1
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-10
ii  libx11-62:1.6.4-3
ii  libxerces-c3.1  3.1.1-5
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-5.2
ii  pyside-tools0.2.15-1
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0~rc2-1
ii  python-pivy 0.5.0~v609hg-3.1
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-1
pn  python:any  
ii  zlib1g  1:1.2.8.dfsg-2+b1

freecad recommends no packages.

Versions of packages freecad suggests:
ii  graphviz  2.38.0-16
pn  povray

-- no debconf information

Bug#860789: freecad: import of openscad file turns "differences" into "unions"

[lkcl]

Package: freecad
Version: 0.16+dfsg2-3
Severity: normal
Tags: upstream

in attempting to convert from OpenSCAD to STEP,
found the advice here and followed it:
https://forum.lulzbot.com/viewtopic.php?t=243

however the following file has all of its "difference" (removal)
objects turned into "unions" (additions):
http://hands.com/~lkcl/microdesktop_prog2.scad



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

Kernel: Linux 4.9.0-1-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

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.23-4
ii  libcoin80v5 3.1.4~abc9f50+dfsg1-1
ii  libfreeimage3   3.17.0+ds1-1.1+b1
ii  libfreetype62.6.3-3+b1
ii  libgcc1 1:6.3.0-10
ii  libgl1-mesa-glx [libgl1]13.0.6-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-1
ii  liboce-modeling10   0.17.2-1
ii  liboce-ocaf-lite10  0.17.2-1
ii  liboce-ocaf10   0.17.2-1
ii  liboce-visualization10  0.17.2-1
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-1
ii  libqt4-network  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-opengl   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-svg  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtwebkit42.3.4.dfsg-3
ii  libshiboken1.2v51.2.2-2+b2
ii  libsoqt4-20 1.6.0~e8310f-2+b1
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-10
ii  libx11-62:1.6.4-3
ii  libxerces-c3.1  3.1.1-5
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-5.2
ii  pyside-tools0.2.15-1
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0~rc2-1
ii  python-pivy 0.5.0~v609hg-3.1
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-1
pn  python:any  
ii  zlib1g  1:1.2.8.dfsg-2+b1

freecad recommends no packages.

Versions of packages freecad suggests:
ii  graphviz  2.38.0-16
pn  povray

-- no debconf information

Bug#860637: mkosi: FTBFS on i386: help2man: can't get `--help' info from ./mkosi

[Lucas Nussbaum]

retitle 860637 mkosi: arch:all, but builds only on amd64 and arm64
severity 860637 wishlist 
thanks

On 20/04/17 at 07:36 +0200, Andreas Henriksson wrote:
> Hello,
> 
> On Wed, Apr 19, 2017 at 04:58:00PM +0200, Lucas Nussbaum wrote:
> [...]
> > Don't known the i686 architecture.
> [...]
> 
> Thanks.
> 
> While I'm not very familiar with mkosi I guess I should have understood
> from the "legacy free" description that i386 "obviously" isn't supported:
> 
> if platform.machine() == "x86_64":
> GPT_ROOT_NATIVE = GPT_ROOT_X86_64
> elif platform.machine() == "aarch64":
> GPT_ROOT_NATIVE = GPT_ROOT_ARM_64
> else:
> sys.stderr.write("Don't known the %s architecture.\n" % 
> platform.machine())
> sys.exit(1)
> 
> http://sources.debian.net/src/mkosi/1-1/mkosi/#L52
> 
> 
> So apparently this isn't valid (even though the code itself builds no
> architecture-specific binaries, it's still not arch-independent):
> 
> Architecture: all
> 
> http://sources.debian.net/src/mkosi/1-1/debian/control/#L18

It is valid: there's no way to say: "this package builds only arch:all
binaries, but must be built on $SET_OF_ARCHS".

I filed those bugs because some of them might indicate serious breakage
on i386. In the present case, there's not much we can do.

I'm downgrading to wishlist and retitling: it's probably a good idea to
keep a trace of this in the BTS to avoid additional bugs getting filed.

Lucas

Bug#860788: jbig2dec: CVE-2017-7975: Out-of-bound memory write vulnerability due to integer overflow in function jbig2_build_huffman_table

[Salvatore Bonaccorso]

Source: jbig2dec
Version: 0.13-4
Severity: important
Tags: upstream security
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=697693
Control: found -1 0.13-4~deb8u1

Hi,

the following vulnerability was published for jbig2dec.

CVE-2017-7975[0]:
| Artifex jbig2dec 0.13, as used in Ghostscript, allows out-of-bounds
| writes because of an integer overflow in the jbig2_build_huffman_table
| function in jbig2_huffman.c during operations on a crafted JBIG2 file,
| leading to a denial of service (application crash) or possibly
| execution of arbitrary code.

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-2017-7975
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7975
[1] https://bugs.ghostscript.com/show_bug.cgi?id=697693

Regards,
Salvatore

Bug#860787: jbig2dec: CVE-2017-7976: Integer overflow in function jbig2_image_compose

[Salvatore Bonaccorso]

Source: jbig2dec
Version: 0.13-4
Severity: important
Tags: security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=697683
Control: found -1 0.13-4~deb8u1

Hi,

the following vulnerability was published for jbig2dec.

CVE-2017-7976[0]:
| Artifex jbig2dec 0.13 allows out-of-bounds writes and reads because of
| an integer overflow in the jbig2_image_compose function in
| jbig2_image.c during operations on a crafted .jb2 file, leading to a
| denial of service (application crash) or disclosure of sensitive
| information from process memory.

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-2017-7976
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7976
[1] https://bugs.ghostscript.com/show_bug.cgi?id=697683

Regards,
Salvatore

Bug#860759: Please update current Project Leader references

[Martin Michlmayr]

* Chris Lamb  [2017-04-19 20:48]:
>  [0] https://www.debian.org/devel/leader

Fixed in CVS.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#860425: unblock: emacs24/24.5+1-9

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Rob Browning:
> Niels Thykier  writes:
> 
>> Rob Browning:
> 
>> Ok.  Is there any easy way to figure this out?  I am ready to consider
>> additionally targeted fixes for non-deterministic build failures.
> 
> I suspect both of those fixes may be appropriate.  I'll see what I can
> come up with.
> 

Ok, given this and that the current diff is trivially reviewable, please
go ahead with the upload to unstable and notify us via this bug once it
has been built on all release architectures (by removing the moreinfo
tag). ...

>> If it is just a question of moving two insecure commands from one list
>> (auto-try) to another (manual request) or even just removing them, then
>> I am quite happy to accept it for stretch.
>>
>> The stretch-can-defer/stretch-ignore means we won't stall the release
>> for that bug, but often we are still happy to accept a targeted fix for
>> it. :)
> 
> Understood.  What's the proper procedure there, i.e. presumably I'd need
> to upload new packages to unstable, and then would I send an incremental
> debdiff, and an additional unblock request, or would I send a full
> debdiff...?
> 
> Thanks
> 

The procedure depends on what we are dealing with, though we generally
prefer to reuse open unblock bugs.  An incremental (or full) debdiff
since testing is generally preferred - also as a self-control test for
you to assert that the source dir hasn't been affected by a partial
patch (e.g. from an earlier iteration).

Thanks,
~Niels

Bug#858771: thunderbird: Migration fails if .icedove is a symlink

[Carsten Schoenert]

Hello,

please note that this report is closed.
It's probably better to open a new issue.

On Wed, Apr 19, 2017 at 08:50:06PM -0500, debian_supp...@skagitattic.com wrote:
... 
> The homedir itself is a symlink.  Starting Thunderbird results in "
> usr/bin/thunderbird: [profile migration] Couldn't migrate Icedove into
> Thunderbird profile due existing or symlinked folder".  After that it
> created a new .icedove.
> 
> I can get it to start by doing "export HOME=/home/remote/user" then
> starting thunderbird.  /home/ is full of symlinks for each remote user
> to /home/remote/user.  /home/remote is a NFS mount from a central
> server.
> 
> Let me know if you need more information.  I can setup a test user and
> add some terminal output if needed.

A full log of starting thunderbird from the cli would be helpful so see
what's going on.

Regards
Carsten

Bug#860786: README.Debian: include IPv6 in examples for /etc/network/interfaces

[Daniel Pocock]

Package: openvswitch-switch
Version: 2.3.0+git20140819-3+deb8u1
Severity: wishlist


Looking at the examples for /etc/network/interfaces, none of them
include IPv6.

I've tried configuring it using the example below and it appears to be
working fine in a dual stack DHCP environment.

In another environment, I used an "up ip addr add [ipv6 addr] ..."
command in the inet stanza

Please confirm if the inet6 stanza is fully supported and if this is the
right way to use it and consider adding it to README.Debian:




# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto ovsbr0
iface ovsbr0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0

iface ovsbr0 inet6 dhcp
ovs_type OVSBridge
ovs_ports eth0

allow-ovsbr0 eth0
iface eth0 inet manual
ovs_bridge ovsbr0
ovs_type OVSPort

Bug#860759: Please update current Project Leader references

[Martin Michlmayr]

* Chris Lamb  [2017-04-19 20:48]:
>  [0] https://www.debian.org/devel/leader
>  [1] https://www.debian.org/doc/manuals/project-history/ch-leaders

For the latter, I made the change in SVN.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#860637: mkosi: FTBFS on i386: help2man: can't get `--help' info from ./mkosi

[Andreas Henriksson]

Hello,

On Wed, Apr 19, 2017 at 04:58:00PM +0200, Lucas Nussbaum wrote:
[...]
> Don't known the i686 architecture.
[...]

Thanks.

While I'm not very familiar with mkosi I guess I should have understood
from the "legacy free" description that i386 "obviously" isn't supported:

if platform.machine() == "x86_64":
GPT_ROOT_NATIVE = GPT_ROOT_X86_64
elif platform.machine() == "aarch64":
GPT_ROOT_NATIVE = GPT_ROOT_ARM_64
else:
sys.stderr.write("Don't known the %s architecture.\n" % platform.machine())
sys.exit(1)

http://sources.debian.net/src/mkosi/1-1/mkosi/#L52


So apparently this isn't valid (even though the code itself builds no
architecture-specific binaries, it's still not arch-independent):

Architecture: all

http://sources.debian.net/src/mkosi/1-1/debian/control/#L18


Regards,
Andreas Henriksson

Bug#860785: qemu: CVE-2017-7471: 9p: virtfs allows guest to change filesystem attributes on host

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.8+dfsg-3
Severity: important
Tags: upstream security patch fixed-upstream

Hi,

the following vulnerability was published for qemu.

CVE-2017-7471[0]:
9p: virtfs allows guest to change filesystem  attributes on host

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-2017-7471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7471
[1] 
http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=9c6b899f7a46893ab3b671e341a2234e9c0c060e

Please adjust the affected versions in the BTS as needed. AFAICT it is
not yet included in stable-2.8.

Regards,
Salvatore

Bug#860663: [Python-modules-team] Bug#860663: pytest: FTBFS on i386: segfault during tests

[Lucas Nussbaum]

On 19/04/17 at 20:42 +0200, Sebastian Ramacher wrote:
> Control: tags -1 + moreinfo unreproducible
> 
> On 2017-04-19 09:26:48, Lucas Nussbaum wrote:
> > Source: pytest
> > Version: 3.0.6-1
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20170418-i386 qa-ftbfs
> > Justification: FTBFS in stretch on i386
> > 
> > Hi,
> > 
> > During a rebuild of all packages in stretch (in a stretch chroot, not a
> > sid chroot), your package failed to build on i386.
> > 
> > Relevant part (hopefully):
> > > ../../../testing/test_pluginmanager.py ...
> > > ../../../testing/test_pytester.py x...
> > > ../../../testing/test_recwarn.py ..
> > > ../../../testing/test_resultlog.py ...
> > > ../../../testing/test_runner.py 
> > > ...sss.....x...
> > > ../../../testing/test_runner_xunit.py ...
> > > ../../../testing/test_session.py .
> > > ../../../testing/test_skipping.py 
> > > ..x..
> > > ../../../testing/test_terminal.py 
> > > ..s..s.
> > > ../../../testing/test_tmpdir.py ...s
> > > ../../../testing/test_unittest.py 
> > > 
> > > ../../../testing/code/test_code.py ..
> > > ../../../testing/code/test_excinfo.py Segmentation fault
> > > E: pybuild pybuild:283: test: plugin custom failed with: exit code=139: 
> > > cd debian/tmp/test-working-directory && pypy -m pytest --lsof -rfsxX 
> > > --ignore=/<>/testing/freeze 
> > > --ignore=/<>/testing/test_entry_points.py 
> > > --ignore=/<>/testing/test_pdb.py /<>/testing
> > > dh_auto_test: pybuild --test -i pypy -p 5.6 --system=custom 
> > > --test-args=cd debian/tmp/test-working-directory && {interpreter} -m 
> > > pytest --lsof -rfsxX --ignore={dir}/testing/freeze 
> > > --ignore={dir}/testing/test_entry_points.py 
> > > --ignore={dir}/testing/test_pdb.py {dir}/testing returned exit code 13
> > > debian/rules:20: recipe for target 'override_dh_auto_test' failed
> 
> I'm unable to reproduce the crash. Could you please provide a backtrace?

Can you provide a build log and diff it with mine?

Lucas

Bug#860784: linux-image-4.9.0-2-amd64: Hauppage WinTV Aero-M no longer works in kernel 4.9

[stevev]

Package: src:linux
Version: 4.9.18-1
Severity: normal

Dear Maintainer,

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

On upgrading to the prerelease stretch, I found that my Hauppage WinTV
Aero-M (a USB digital TV receiver) no longer works.  The device is
recognized by USB but fails to initialize.  The last time it was working
for me I was running the latest 3.16 kernel in jessie.

I created /etc/modprobe.d/dvb_usb_mxl111sf.conf to enable as much
debugging as possible:

options dvb_usb_mxl111sf debug=31

[  871.791023] usb 3-1: dvb_usb_v2: found a 'Hauppauge WinTV-Aero-M' in warm 
state
[  871.791076] usb 3-1: dvb_usb_v2: will pass the complete MPEG2 transport 
stream to the software demuxer
[  871.791149] DVB: registering new adapter (Hauppauge WinTV-Aero-M)
[  871.791674] mxl1x1sf_soft_reset: ()
[  871.791680] usb 3-1: dvb_usb_v2: usb_bulk_msg() failed=-11
[  871.791686] mxl111sf_ctrl_msg: error -11 on line 80
[  871.791688] mxl111sf_write_reg: error -11 on line 122
[  871.791690] error writing reg: 0xff, val: 0x00
[  871.791692] mxl1x1sf_soft_reset: error -11 on line 61
[  871.791695] mxl111sf_lgdt3305_frontend_attach: error -11 on line 446
[  871.791974] dvb_usb_mxl111sf: probe of 3-1:1.0 failed with error -11
[  871.791995] usbcore: registered new interface driver dvb_usb_mxl111sf

I'll also include a full lsusb -v since that doesn't appear to have been
automatically included in reportbug.

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x0024 Integrated Rate Matching Hub
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval  12
Hub Descriptor:
  bLength  11
  bDescriptorType  41
  nNbrPorts 8
  wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00 0x00
  PortPwrCtrlMask0xff 0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
   Port 5: .0100 power
   Port 6: .0100 power
   Port 7: .0100 power
   Port 8: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0002 2.0 root hub
  bcdDevice4.09
  iManufacturer   3 Linux 4.9.0-2-amd64 ehci_hcd
  iProduct2 EHCI Host Controller
  iSerial 1 :00:1d.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfac

Bug#860783: fai-client: wrong subroutine name in install_packages

[Thomas Lange]

Package: fai-client
Version: 5.3.5
Severity: important
Tags: patch

Softupdates do not work in fai 5.3.5. You get an error message during
task_instsoft, "Undefined subroutine &main::insert called at
/usr/sbin/install_packages line 547.". If you edit that file and
change the subroutine call from insert to insert_pkg, it works.

This error will also appear if you have any package name appended by
a colon and the architecture.

Here's the fix for this.

diff --git a/bin/install_packages b/bin/install_packages
index 6a7505d..022f789 100755
--- a/bin/install_packages
+++ b/bin/install_packages
@@ -544,7 +544,7 @@ sub clean_pkg_list {
 
 # remove :arch from package name
 if ( $pack =~ s/:\S+//) {
-  insert($n, $pack, 1, "$n using $pack found") && next;
+  insert_pkg($n, $pack, 1, "$n using $pack found") && next;
 }
 
 # else package is unknown

-- 
regards Thomas

Bug#678609: gnupg2: Global configuration file /etc/gnupg2/gpgconf.conf missing

[Daniel Kahn Gillmor]

Control: done 678609 2.0.5-2
Control: unarchive 434878
Control: forcemerge 434878 678609

On Sat 2012-06-23 09:57:45 +0200, Ralf Jung wrote:
> running "gpgconf --list-config" results in the following output:
> gpgconf: can not open global config file `/etc/gnupg2/gpgconf.conf': No such
> file or directory
>
> Obviously gpgconf expects such a file to exist, and therefore, it should be
> shipped.

And yet, upstream does not ship such a file.  gpgconf(1) itself doesn't
expect it to always exist:

   /etc/gnupg/gpgconf.conf
If this file exists, it is processed as a global configuration 
file.
A commented example can be found in the ‘examples’ directory of
the distribution.


The gpgconf.conf file 

> This looks similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434878,
> which however is claimed to be fixed since 2007 - which it obviously is not.


that was closed with this remark:

  * debian/gnupg2.examples: New file, install gpgconf.conf as an example
into /usr/share/doc. Hope this is a good compromise Bernhard. (Closes:
#434878)

This is still the case:

0 dkg@alice:~$ dpkg -S gpgconf.conf
gnupg: /usr/share/doc/gnupg/examples/gpgconf.conf
0 dkg@alice:~$ 

So i'm going to try to close and merge these two bug reports.


Regards,

--dkg


signature.asc
Description: PGP signature

Bug#860242: unblock: neovim/0.1.7-4

[James McCoy]

On Thu, Apr 13, 2017 at 08:13:31AM -0400, James McCoy wrote:
> Please unblock package neovim
> 
> This upload includes fixes for CVE-2017-{5953,6349,6350}.
> 
> unblock neovim/0.1.7-4

Ping?

> diffstat for neovim-0.1.7 neovim-0.1.7
> 
>  changelog   |9 ++
>  patches/0001-debcherry-fixup-patch.patch|   32 
> +++-
>  patches/0002-test-Handle-SIGHUP-in-tty-test-fixture.patch   |4 -
>  patches/0003-tui-backpressure-Drop-messages-to-avoid-flooding.patch |4 -
>  patches/0004-vim-patch-8.0.0377.patch   |   38 
> ++
>  patches/0005-vim-patch-8.0.0378.patch   |   37 
> +
>  patches/series  |2 
>  7 files changed, 118 insertions(+), 8 deletions(-)
> 
> diff -Nru neovim-0.1.7/debian/changelog neovim-0.1.7/debian/changelog
> --- neovim-0.1.7/debian/changelog 2017-01-16 07:18:35.0 -0500
> +++ neovim-0.1.7/debian/changelog 2017-04-10 08:15:38.0 -0400
> @@ -1,3 +1,12 @@
> +neovim (0.1.7-4) unstable; urgency=high
> +
> +  * Cherry-pick b338bb9d & 4af6c608 from upstream to fix buffer overflow if a
> +spellfile has an invalid length in it.  (CVE-2017-5953)
> +  * Cherry-pick fb66a7c6 & ad66826a from upstream to fix buffer overflows 
> when
> +reading corrupted undo files.  (CVE-2017-6349 & CVE-2017-6350)
> +
> + -- James McCoy   Mon, 10 Apr 2017 08:15:38 -0400
> +
>  neovim (0.1.7-3) unstable; urgency=medium
>  
>* Disable global_spec.lua since it's rather flaky.
> diff -Nru neovim-0.1.7/debian/patches/0001-debcherry-fixup-patch.patch 
> neovim-0.1.7/debian/patches/0001-debcherry-fixup-patch.patch
> --- neovim-0.1.7/debian/patches/0001-debcherry-fixup-patch.patch  
> 2017-01-16 07:18:35.0 -0500
> +++ neovim-0.1.7/debian/patches/0001-debcherry-fixup-patch.patch  
> 2017-04-10 08:15:38.0 -0400
> @@ -1,8 +1,12 @@
> -From 2ef123279cbff7afeb5546992dc34c902664b4db Mon Sep 17 00:00:00 2001
> +From 5a06ba6f8d7c464ec319eac1a805575849203371 Mon Sep 17 00:00:00 2001
>  From: James McCoy 
> -Date: Mon, 16 Jan 2017 07:19:41 -0500
> -Subject: [PATCH 1/3] debcherry fixup patch
> +Date: Mon, 10 Apr 2017 08:16:34 -0400
> +Subject: [PATCH 1/5] debcherry fixup patch
>  
> +53bde37a vim-patch:8.0.0376
> +  - no changes against upstream or conflicts
> +aa0c704e vim-patch:8.0.0322
> +  - extra changes or conflicts
>  7b3fc809 out_data_decide_throttle(): timeout instead of hard limit.
>- no changes against upstream or conflicts
>  443f0387 out_data_decide_throttle(): Avoid too-small final chunk.
> @@ -22,11 +26,12 @@
>   src/nvim/main.c   |   2 +-
>   src/nvim/memory.c |  31 ---
>   src/nvim/os/shell.c   | 147 
> --
> + src/nvim/spell.c  |   6 +-
>   test/functional/eval/execute_spec.lua |  17 ++--
>   test/functional/terminal/helpers.lua  |   1 +
>   test/functional/ui/output_spec.lua|  21 +
>   test/functional/ui/screen.lua |  47 ---
> - 10 files changed, 235 insertions(+), 49 deletions(-)
> + 11 files changed, 240 insertions(+), 50 deletions(-)
>  
>  diff --git a/runtime/doc/various.txt b/runtime/doc/various.txt
>  index a1bf379d..3c147244 100644
> @@ -353,6 +358,25 @@
> if (cnt) {
>   rbuffer_consumed(buf, cnt);
> }
> +diff --git a/src/nvim/spell.c b/src/nvim/spell.c
> +index 7119ac6d..7dc9eb05 100644
> +--- a/src/nvim/spell.c
>  b/src/nvim/spell.c
> +@@ -3589,9 +3589,13 @@ spell_read_tree (
> + 
> +   // The tree size was computed when writing the file, so that we can
> +   // allocate it as one long block. 
> +-  int len = get4c(fd);
> ++  long len = get4c(fd);
> +   if (len < 0)
> + return SP_TRUNCERROR;
> ++  if ((size_t)len >= SIZE_MAX / sizeof(int)) {
> ++// Invalid length, multiply with sizeof(int) would overflow.
> ++return SP_FORMERROR;
> ++  }
> +   if (len > 0) {
> + // Allocate the byte array.
> + bp = xmalloc(len);
>  diff --git a/test/functional/eval/execute_spec.lua 
> b/test/functional/eval/execute_spec.lua
>  index b5b48143..fc13c0a7 100644
>  --- a/test/functional/eval/execute_spec.lua
> diff -Nru 
> neovim-0.1.7/debian/patches/0002-test-Handle-SIGHUP-in-tty-test-fixture.patch 
> neovim-0.1.7/debian/patches/0002-test-Handle-SIGHUP-in-tty-test-fixture.patch
> --- 
> neovim-0.1.7/debian/patches/0002-test-Handle-SIGHUP-in-tty-test-fixture.patch 
> 2017-01-16 07:18:35.0 -0500
> +++ 
> neovim-0.1.7/debian/patches/0002-test-Handle-SIGHUP-in-tty-test-fixture.patch 
> 2017-04-10 08:15:38.0 -0400
> @@ -1,7 +1,7 @@
> -From 867ed903bffe6befb44208a34c8084db4ea44497 Mon Sep 17 00:00:00 2001
> +From e54118bdb9165d11ebe6250ab08ff2e4b85e29d2 Mon Sep 17 00:00:00 2001
>  From: "Justin M. Keyes" 
>  Date: Wed, 7 Dec 2016 14:01:51 +0100
> -Subj

Bug#860782: libnauty2-dev: suggest include geng.c source

[Kevin Ryde]

Package: libnauty2-dev
Version: 2.6r7+ds-1
Severity: wishlist

The source codes geng.c, gentourng.c, gentreeg.c have some #define
GENG_MAIN stuff allowing them to be included in a user program.  Those
files could be helpfully included in the package for that.  Not certain
where they might best live, maybe /usr/share/nauty/.

callgeng.c example program shows the way to use them.  Perhaps it would
go with the other examples in /usr/share/doc/nauty-doc/examples.  Though
the Makefile there might then want the special compile rule shown in
callgeng.c and perhaps plus -I/usr/include/nauty, unless wanted to
change geng.c #include "gtools.h" to  which is where
that file is packaged.  That could be helpful for all uses.


-- System Information:
Debian Release: 9.0
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libnauty2-dev depends on:
ii  dpkg   1.18.23
ii  libnauty2  2.6r7+ds-1

libnauty2-dev recommends no packages.

Versions of packages libnauty2-dev suggests:
ii  nauty-doc   2.6r7+ds-1
ii  pkg-config  0.29-4+b1

-- no debconf information

Bug#860723: vim-runtime: documentation bug in term.txt

[James McCoy]

On Wed, Apr 19, 2017 at 01:59:58PM +0200, Rhonda D'Vine wrote:
>  while trying to figure out why I don't get rgb color support in vim
> inside tmux I stumbled upon a documentation bug. :)
> 
>  in term.txt there are these two lines:
> 
>  let &t_8f = "\[38:2:%lu:%lu:%lum"
>  let &t_8b = "\[48:2:%lu:%lu:%lum"

Which are just a clarification on the preceding paragraph (emphasis
added):

Sometimes setting 'termguicolors' is not enough and one has to set the 
|t_8f|
and |t_8b| options explicitly. 𝐃𝐞𝐟𝐚𝐮𝐥𝐭 𝐯𝐚𝐥𝐮𝐞𝐬 𝐨𝐟 𝐭𝐡𝐞𝐬𝐞 𝐨𝐩𝐭𝐢𝐨𝐧𝐬 𝐚𝐫𝐞
"^[[38;2;%lu;%lu;%lum" and "^[[48;2;%lu;%lu;%lum" respectively, but it is 
only
set when `$TERM` is `xterm`. 𝐒𝐨𝐦𝐞 𝐭𝐞𝐫𝐦𝐢𝐧𝐚𝐥𝐬 𝐚𝐜𝐜𝐞𝐩𝐭 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐬𝐞𝐪𝐮𝐞𝐧𝐜𝐞𝐬, 𝐛𝐮𝐭
𝐰𝐢𝐭𝐡 𝐚𝐥𝐥 𝐬𝐞𝐦𝐢𝐜𝐨𝐥𝐨𝐧𝐬 𝐫𝐞𝐩𝐥𝐚𝐜𝐞𝐝 𝐛𝐲 𝐜𝐨𝐥𝐨𝐧𝐬 (this is actually more compatible, 
but
less widely supported):

>  Actually, after 38 and 48 there should be a semicolon instead of a
> colon.  I figured out that part with setting xterm-256color (which
> worked) and screen-256color (which didn't, had it set to empty, which is
> set inside tmux as default).

If have recent enough terminfo files (and tmux), I'd suggest using
tmux-256color instead since that will also enable displaying italic
text.

>  Now I don't know if it is a vim bug that t_8f and t_8b are empty when
> therm is screen-256color (I still have to figure out why that is), but
> the documentation bug for those values in term.txt should definitely get
> fixed. :)

I'd check https://gist.github.com/XVilka/8346728 for more details, but
it seems likely it's due to there being disagreement about a standard
way to advertise support for true color.

Neovim seems to handle this a bit better in that you can always "set
termguicolors" but it just won't do anything if it doesn't think the
term supports it.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#726486: pump.io packaging help (from upstream)

[Alex Jordan]

Heya!

Relatively recently I became the primary maintainer of the pump.io
project and I just wanted to reach out and say hi!

I know there was [an effort][1] to package pump.io for Debian a while
back, though it seems to have stalled out. I just wanted to say that
we're very interested in getting pump.io into Debian - with the
upcoming 4.0.0 release the codebase will finally(!) in a state where
I'd feel comfortable about okaying it being frozen long-term.

If anyone is interested in restarting this effort, please feel free to
reach out to me! I'd be happy to consider upstream changes or offer
advice to make this (and npm packaging in general) easier. I can't
guarantee anything but we would also consider committing to long-term
security support for whatever release gets packaged for Debian.

As a side note, it would be great to be in the loop if this does end
up happening - from looking at [1] I see some things that would end
disastrously. For example, that page was tracking packaging a pump.io
version that used Express 2.x, but it seems that the plan was to
depend on Express 4.x packages? (Correct me if I'm wrong, obviously.)
Trying to do so would be a very bad idea - that upgrade took _months_
of work upstream and hundreds of commits, which is obviously untenable
for downstream packagers to maintain.

Anyway! Just wanted to say hi and that I hope to work with you all at
some point in the future.

Cheers!

AJ

 [1]: https://wiki.debian.org/Javascript/Nodejs/Tasks/Pump.io


signature.asc
Description: PGP signature

Bug#860781: linux-image-4.9.0-2-amd64: High system load, probably due to interrupts

[Stefan Ott]

Package: src:linux
Version: 4.9.18-1
Severity: normal

Dear Maintainer,

I installed Debian on an older Laptop and noticed that my system load
was very high even though the system was just sitting there being
idle, not even running X:


# uptime
 03:23:45 up 21 min,  2 users,  load average: 7.53, 3.25, 2.10


According to top, the only processes that cause any load are kworkers.
After reading several similar reports from other people I proceeded to
investigate my ACPI interrupts and noticed this:


# cat /sys/firmware/acpi/interrupts/gpe17
  509091  EN enabled  unmasked
# cat /sys/firmware/acpi/interrupts/gpe17
  515942  EN enabled  unmasked


I.e. lots of interrupts happening on gpe17 (these commands were run
within 1 second of eachother). I then disabled gpe17:


echo "disable" >/sys/firmware/acpi/interrupts/gpe17


This brought the load down to about 2.0 (still rather high) when idle.
However, as soon as I start Xorg the load goes up again (currently at
17.1, after about 3 minutes) and this time I don't see anything
interesting in the ACPI interrupts.

The high load does not appear to affect the system's performance much.
I have however noticed that the fans are unusually active and, more
importantly, the acpi command seems to have trouble communicating:


# time acpi -Vi >/dev/null 
real1m22.340s


# time acpi -Vi >/dev/null
real0m13.737s


On a possibly related note, I am getting a lot of these messages:
[ 2325.736093] hpet1: lost 9600 rtc interrupts


The dmesg log attached also shows an issue with the GPU; I don't
think that's related to this problem but at the moment I can't say
for sure.

Are there any other workarounds that I could try?


-- Package-specific info:
** Version:
Linux version 4.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170321 (Debian 6.3.0-11) ) #1 SMP Debian 4.9.18-1 (2017-03-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-2-amd64 root=/dev/mapper/vg_vetinari-root ro 
quiet irqpoll

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Apple Inc.
product_name: MacBookAir1,1
product_version: 1.0
chassis_vendor: Apple Inc.
chassis_version: Mac-F42C8CC8
bios_vendor: Apple Inc.
bios_version:MBA11.88Z.00BB.B03.0803171226
board_vendor: Apple Inc.
board_name: Mac-F42C8CC8
board_version: PVT

** Loaded modules:
nls_ascii
nls_cp437
vfat
fat
joydev
arc4
iTCO_wdt
iTCO_vendor_support
coretemp
kvm_intel
b43
kvm
applesmc
bcma
input_polldev
mac80211
efi_pstore
i915
irqbypass
btusb
btrtl
btbcm
btintel
uvcvideo
bluetooth
videobuf2_vmalloc
cfg80211
videobuf2_memops
pcspkr
videobuf2_v4l2
sg
videobuf2_core
efivars
asix
snd_hda_codec_realtek
videodev
crc16
drm_kms_helper
usbnet
libphy
rfkill
mii
rng_core
media
bcm5974
snd_hda_codec_generic
drm
evdev
acpi_als
kfifo_buf
snd_hda_intel
industrialio
lpc_ich
snd_hda_codec
i2c_algo_bit
mfd_core
snd_hda_core
video
snd_hwdep
sbs
snd_pcm
apple_bl
sbshc
snd_timer
battery
shpchp
ac
button
snd
soundcore
acpi_cpufreq
tpm_tis
tpm_tis_core
tpm
xfs
libcrc32c
crc32c_generic
xts
gf128mul
algif_skcipher
af_alg
hid_apple
hid_appleir
usbhid
hid
dm_crypt
dm_mod
sd_mod
ata_generic
ahci
libahci
ata_piix
libata
i2c_i801
i2c_smbus
scsi_mod
ssb
mmc_core
pcmcia
ehci_pci
pcmcia_core
uhci_hcd
ehci_hcd
usbcore
usb_common
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory 
Controller Hub [8086:2a00] (rev 03)
Subsystem: Apple Inc. Mobile PM965/GM965/GL960 Memory Controller Hub 
[106b:00a2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (primary) [8086:2a02] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: Apple Inc. Mobile GM965/GL960 Integrated Graphics Controller 
(primary) [106b:00a2]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (secondary) [8086:2a03] (rev 03)
Subsystem: Apple Inc. Mobile GM965/GL960 Integrated Graphics Controller 
(secondary) [106b:00a2]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #4 [8086:2834] (rev 03) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
  

Bug#860780: compiz-plugins-default: please add Breaks+Replaces: compiz-core (<< 1:0.9.4+bzr20110606-0ubuntu3)

[Andreas Beckmann]

Package: compiz-plugins-default
Version: 1:0.9.13.0+16.10.20160818.2-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + compiz-dev

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'squeeze'.
It installed fine in 'squeeze', then the upgrade via 'wheezy' and
'jessie' to 'stretch' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package compiz-plugins-default.
  Preparing to unpack 
.../compiz-plugins-default_1%3a0.9.13.0+16.10.20160818.2-5_amd64.deb ...
  Unpacking compiz-plugins-default (1:0.9.13.0+16.10.20160818.2-5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/compiz-plugins-default_1%3a0.9.13.0+16.10.20160818.2-5_amd64.deb
 (--unpack):
   trying to overwrite '/usr/share/compiz/commands.xml', which is also in 
package compiz-core 0.8.4-4

There was no compiz version wheezy and jessie, so the squeeze packages
were kept installed.
According to the changelog compiz-plugins-default was introduced in
1:0.9.4+bzr20110606-0ubuntu3

There may be more B+R missing, but piuparts didn't run into them,
yet. (And specifically searching for them is non-trivial due to the
two "skipped" releases.)

It would be great if these Breaks+Replaces could be added for stretch.


cheers,

Andreas


compiz-dev_1:0.9.13.0+16.10.20160818.2-5.log.gz
Description: application/gzip

Bug#860405: marionnet: segfaults after installation, not usable

[Eriberto Mota]

The same situation here...

eriberto@canopus:~$ marionnet
Segmentation fault

Debian Stretch, updated today. marionnet 0.90.6+bzr457-1+b1 installed today.

Regards,

Eriberto

Bug#860747: dh_ruby: please inject versioned dependency on ruby metapackage

[Aaron M. Ucko]

Antonio Terceiro  writes:

> Ah fair enough, I missed that bit. These dependencies are specified in
> ruby-all-dev, so I am reassigning accordingly. It should be just a
> matter of including the << dependency there.

Sounds good, thanks!  Sorry for the sloppy reporting; I just got back
from vacation a couple of days ago, and was trying to sort out entirely
too many things at once.

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

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Josh Triplett]

On Wed, Apr 19, 2017 at 11:11:00PM +, Ximin Luo wrote:
> Ximin Luo:
> > [..]
> 
> I've made some more process and have pushed 0.17.0 to git. However we're 
> getting build errors and I don't know how to proceed:
> 
> https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/TODO
> https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/cargo-vendor-pack.py
> 
> I'm not familiar with the Cargo repo formats, and I don't know how 
> d/cargo-vendor-pack.py should be fixed. Help would be appreciated.
> 
> Josh, is this anything related to how your dh-cargo works? Any code that we 
> can reuse?

Not directly, until we're ready to package all the individual crate
dependencies (which we'll want to do at some point).  But you can
definitely use the same mechanism; it'd be much easier to generate a
directory registry than the full Cargo index format.  Rather than
generating an index file and repo, just:

1) Copy every crate directory, verbatim, into a subdirectory of a vendor
   directory.

2) Create a file .cargo-checksum.json in the crate directory, containing
   {"package":"$SHA256","files":{}} , where $SHA256 is the sha256 of the
   .crate file.

3) Create a directory containing a file "config", containing:

[source.crates-io]
replace-with = "my-registry"

[source.my-registry]
directory = "/path/to/the/vendor/directory"

4) Set CARGO_HOME to the directory containing that config file, and
   build.

debcargo can help a bit with this.  Run it on a crate, move
debian/cargo-checksum.json to .cargo-checksum.json , aggregate
debian/copyright, remove the rest of debian/ , and put the resulting
directory into the registry directory.

...and looking at git from 20 minutes ago, it looks like you've switched
over to directory registries now.

Bug#858771: thunderbird: Migration fails if .icedove is a symlink

[debian_support]

Hello,

This bug appears to still be an issue on my setup:

$ a-policy thunderbird
thunderbird:
  Installed: 1:45.8.0-3
  Candidate: 1:45.8.0-3
  Version table:
 *** 1:45.8.0-3 800
800 http://httpredir.debian.org/debian testing/main amd64
Packages 100 /var/lib/dpkg/status

The homedir itself is a symlink.  Starting Thunderbird results in "
usr/bin/thunderbird: [profile migration] Couldn't migrate Icedove into
Thunderbird profile due existing or symlinked folder".  After that it
created a new .icedove.

I can get it to start by doing "export HOME=/home/remote/user" then
starting thunderbird.  /home/ is full of symlinks for each remote user
to /home/remote/user.  /home/remote is a NFS mount from a central
server.

Let me know if you need more information.  I can setup a test user and
add some terminal output if needed.

Thanks!



On Thu, 30 Mar 2017 01:36:27 + Christoph Goehre 
wrote:
> Source: icedove
> Source-Version: 1:45.8.0-3
> 
> We believe that the bug you reported is fixed in the latest version of
> icedove, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 858...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Christoph Goehre  (supplier of updated icedove
> package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Wed, 29 Mar 2017 19:28:32 -0400
> Source: icedove
> Binary: thunderbird icedove thunderbird-dev icedove-dev
> thunderbird-dbg icedove-dbg lightning iceowl-extension
> calendar-google-provider thunderbird-l10n-all thunderbird-l10n-ar
> thunderbird-l10n-ast thunderbird-l10n-be thunderbird-l10n-bg
> thunderbird-l10n-bn-bd thunderbird-l10n-br thunderbird-l10n-ca
> thunderbird-l10n-cs thunderbird-l10n-da thunderbird-l10n-de
> thunderbird-l10n-el thunderbird-l10n-en-gb thunderbird-l10n-es-ar
> thunderbird-l10n-es-es thunderbird-l10n-et thunderbird-l10n-eu
> thunderbird-l10n-fi thunderbird-l10n-fr thunderbird-l10n-fy-nl
> thunderbird-l10n-ga-ie thunderbird-l10n-gd thunderbird-l10n-gl
> thunderbird-l10n-he thunderbird-l10n-hr thunderbird-l10n-hu
> thunderbird-l10n-hy-am thunderbird-l10n-id thunderbird-l10n-is
> thunderbird-l10n-it thunderbird-l10n-ja thunderbird-l10n-ko
> thunderbird-l10n-lt thunderbird-l10n-nb-no thunderbird-l10n-nl
> thunderbird-l10n-nn-no thunderbird-l10n-pa-in thunderbird-l10n-pl
> thunderbird-l10n-pt-br thunderbird-l10n-pt-pt thunderbird-l10n-rm
> thunderbird-l10n-ro thunderbird-l10n-ru thunderbird-l10n-si
> thunderbird-l10n-sk thunderbird-l10n-sl thunderbird-l10n-sq
> thunderbird-l10n-sr thunderbird-l10n-sv-se thunderbird-l10n-ta-lk
> thunderbird-l10n-tr thunderbird-l10n-uk thunderbird-l10n-vi
> thunderbird-l10n-zh-cn thunderbird-l10n-zh-tw icedove-l10n-all
> icedove-l10n-ar icedove-l10n-ast icedove-l10n-be icedove-l10n-bg
> icedove-l10n-bn-bd icedove-l10n-br icedove-l10n-ca icedove-l10n-cs
> icedove-l10n-da icedove-l10n-de icedove-l10n-el icedove-l10n-en-gb
> icedove-l10n-es-ar icedove-l10n-es-es icedove-l10n-et icedove-l10n-eu
> icedove-l10n-fi icedove-l10n-fr icedove-l10n-fy-nl icedove-l10n-ga-ie
> icedove-l10n-gd icedove-l10n-gl icedove-l10n-he icedove-l10n-hr
> icedove-l10n-hu icedove-l10n-hy-am icedove-l10n-id icedove-l10n-is
> icedove-l10n-it icedove-l10n-ja icedove-l10n-ko icedove-l10n-lt
> icedove-l10n-nb-no icedove-l10n-nl icedove-l10n-nn-no
> icedove-l10n-pa-in icedove-l10n-pl icedove-l10n-pt-br
> icedove-l10n-pt-pt icedove-l10n-rm icedove-l10n-ro icedove-l10n-ru
> icedove-l10n-si icedove-l10n-sk icedove-l10n-sl icedove-l10n-sq
> icedove-l10n-sr icedove-l10n-sv-se icedove-l10n-ta-lk icedove-l10n-tr
> icedove-l10n-uk icedove-l10n-vi icedove-l10n-zh-cn icedove-l10n-zh-tw
> lightning-l10n-ar lightning-l10n-be lightning-l10n-bg
> lightning-l10n-bn-bd lightning-l10n-br lightning-l10n-ca
> lightning-l10n-cs lightning-l10n-cy lightning-l10n-da
> lightning-l10n-de lightning-l10n-el lightning-l10n-es-ar
> lightning-l10n-es-es lightning-l10n-en-gb lightning-l10n-et
> lightning-l10n-eu lightning-l10n-fi lightning-l10n-fr
> lightning-l10n-fy-nl lightning-l10n-ga-ie lightning-l10n-gd
> lightning-l10n-gl lightning-l10n-he lightning-l10n-hr
> lightning-l10n-hu lightning-l10n-hy-am lightning-l10n-id
> lightning-l10n-is lightning-l10n-it lightning-l10n-ja
> lightning-l10n-ko lightning-l10n-lt lightning-l10n-nb-no
> lightning-l10n-nl lightning-l10n-nn-no lightning-l10n-pa-in
> lightning-l10n-pl lightning-l10n-pt-br lightning-l10n-pt-pt
> lightning-l10n-rm lightning-l10n-ro lightning-l10n-ru
> lightning-l10n-si lightning-l10n-sk lightning-l10n-

Bug#860779: smbclient: installation of smbclient appears to install and run samba server

[Ross Boylan]

Package: smbclient
Version: 2:4.2.14+dfsg-0+deb8u5
Severity: normal

I do not think that installing client software should, without much
notice, install and activate the associated server.  But that seems to
be what happens with smbclient.  Among other things, this seems an
unnecessary security risk.

   * What led up to the situation?
   I wanted to access a samba share being served by another machine.
   So I installed smbclient using aptitude, accepting the defaults,
   which I noticed included samba (the main package) and a lot of
   other things.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I first ran systemtcl status samba which seemed to indicate the
 server was not running.  However, the samba logs and netstat
 indicated it was, as did /etc/init.d/samba status
 
   * What was the outcome of this action?
   Big picture: installing the client resulted in a running server on
   my machine.  As for my diagnostics:
ross@ross-node1:/tmp$ systemctl status samba
● samba.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)
ross@ross-node1:/tmp$ /etc/init.d/samba status
● nmbd.service - LSB: start Samba NetBIOS nameserver (nmbd)
   Loaded: loaded (/etc/init.d/nmbd)
   Active: active (running) since Wed 2017-04-19 16:36:11 PDT; 41min ago
   CGroup: /system.slice/nmbd.service
   └─52137 /usr/sbin/nmbd -D
● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
   Loaded: loaded (/etc/init.d/smbd)
   Active: active (running) since Wed 2017-04-19 16:36:10 PDT; 41min ago
   CGroup: /system.slice/smbd.service
   ├─52068 /usr/sbin/smbd -D
   └─52072 /usr/sbin/smbd -D

   * What outcome did you expect instead?
   Well, I wasn't too surprised to find the server running given
   the packages installed.  But my original expectation was that I
   could install the client without getting a server started.

Our network admin is pretty strict and takes a dim view of random
services running on the network.  So I'm going to remove all the
packages for now.

As a side note, I find the current interaction of samba and systemd to
be mysterious and undocumented.  I did find bug 740942 which shed some
light (namely that the samba.service link to /dev/null sort of tells
systemd to ignore the package), but I remain puzzled.  The end of that
bug links to
http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=8828d90
but that link doesn't seem to work anymore.  Then again, I find
systemd to be generally mysterious.

In particular, I don't know what the proper way to disable the
services is.

I do notice that smbclient relies on configuration parameters in
smb.conf, and so it may be that getting a "pure" client is technically
difficult.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/40 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 smbclient depends on:
ii  dpkg  1.17.27
ii  libarchive13  3.1.2-11+deb8u3
ii  libbsd0   0.7.0-2
ii  libc6 2.19-18+deb8u7
ii  libpopt0  1.16-10
ii  libreadline6  6.3-8+b3
ii  libsmbclient  2:4.2.14+dfsg-0+deb8u5
ii  libtalloc22.1.2-0+deb8u1
ii  libtevent00.9.28-0+deb8u1
ii  samba-common  2:4.2.14+dfsg-0+deb8u5
ii  samba-libs2:4.2.14+dfsg-0+deb8u5

smbclient recommends no packages.

Versions of packages smbclient suggests:
ii  cifs-utils   2:6.4-1
pn  heimdal-clients  

-- no debconf information

Bug#860425: unblock: emacs24/24.5+1-9

[Rob Browning]

Niels Thykier  writes:

> Rob Browning:

> Ok.  Is there any easy way to figure this out?  I am ready to consider
> additionally targeted fixes for non-deterministic build failures.

I suspect both of those fixes may be appropriate.  I'll see what I can
come up with.

> If it is just a question of moving two insecure commands from one list
> (auto-try) to another (manual request) or even just removing them, then
> I am quite happy to accept it for stretch.
>
> The stretch-can-defer/stretch-ignore means we won't stall the release
> for that bug, but often we are still happy to accept a targeted fix for
> it. :)

Understood.  What's the proper procedure there, i.e. presumably I'd need
to upload new packages to unstable, and then would I send an incremental
debdiff, and an additional unblock request, or would I send a full
debdiff...?

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

Bug#860778: okular: Often fails to open via symlinks

[Ben Longbons]

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

Dear Maintainer,

The following perfectly-legitimate, common, use of symlinks works with
*all* programs that don't go out of their way to *break* it.

Okular manages to do this wrong, presumably by trying to do filesystem
operations without, you know, talking to the filesystem.


#!/bin/sh
set -e
mkdir -p /tmp/okular-bug/
cd /tmp/okular-bug/
mkdir -p bar/baz
echo 'Hello, World!' > bar/hello.txt
ln -sf bar/baz foo
cat bar/hello.txt
okular bar/hello.txt
cat foo/../hello.txt
okular foo/../hello.txt

-Ben


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.9.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 okular depends on:
ii  kde-runtime 4:16.08.3-2
ii  libc6   2.24-10
ii  libfreetype62.6.3-3.1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libkdecore5 4:4.14.26-1
ii  libkdeui5   4:4.14.26-1
ii  libkexiv2-114:15.04.3-1
ii  libkio5 4:4.14.26-1
ii  libkparts4  4:4.14.26-1
ii  libkprintutils4 4:4.14.26-1
ii  libkpty44:4.14.26-1
ii  libokularcore7  4:16.08.2-1+b1
ii  libphonon4  4:4.9.0-4
ii  libpoppler-qt4-40.48.0-2
ii  libqca2 2.1.1-4+b2
ii  libqimageblitz4 1:0.0.6-4+b2
ii  libqmobipocket1 4:16.08.0-1
ii  libqt4-dbus 4:4.8.7+dfsg-11
ii  libqt4-declarative  4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libsolid4   4:4.14.26-1
ii  libspectre1 0.2.8-1
ii  libstdc++6  7-20170407-1
ii  phonon  4:4.9.0-4
ii  zlib1g  1:1.2.8.dfsg-5

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

Versions of packages okular suggests:
ii  ghostscript9.20~dfsg-3
ii  jovie  4:16.08.0-1+b1
ii  okular-extra-backends  4:16.08.2-1+b1
ii  poppler-data   0.4.7-8
ii  texlive-binaries   2016.20160513.41080.dfsg-2
pn  unrar  

-- no debconf information

Bug#860714: general: disk became full after running a perl program

[Gunnar Wolf]

Luis Duarte dijo [Wed, Apr 19, 2017 at 09:40:10AM +0100]:
> Package: general
> Severity: normal
> 
> My windows manager is Xfce. Using Thunar - when I opened a directory 
> containing
> perl programs, somethimes I click two times on a perl program to start it. No
> Xterm appears - what I think that happen is that my disk become full. I happen
> a lot of times in Wheezy, but in Jessie it happened one times. I don't know if
> this happens (the disk became full) as I described, if it is a bug of Xfce, or
> if it is a bug of Jessie. In Jessie I freed some space on disk, and I restat 
> my
> computer, and everything runs as normal (with space freed). I Wheezy I had a
> lot of problems.

Hi,

What kind of Perl programs are they? Are they made by yourself, or
shipped by Debian?

Please give us some more insight on what is causing this bug. Only
this way we can be sure what component of Debian is at hand - Or if
it's something we can help you with in your programming.

Bug#860560: qbittorrent process not terminated after closing program

[Frédéric Brière]

On Tue, Apr 18, 2017 at 06:33:38PM +0200, Beatrice Torracca wrote:
> whenever I close qbittorrent (Menu File -> Exit), the program seems
> closed but it really is not.
> 
> Apparently the code S means it is sleeping, but it stays like that
> forever (or I never saw it go away) unless I kill it.
> 
> I hope I am not missing something obvious.

Don't worry: it's not just you.  :)

There are many reports of qBittorrent taking a long time to shut down,
most of which can be found here:

  https://github.com/qbittorrent/qBittorrent/issues/5097

(#6460 and #3074 might also be relevant in some situations.)

The majority opinion seems to be that it's the tearing down of all
network connections that is to blame.  Unfortunately, this happens after
the GUI is torn down, so there's no visual indication of whether or not
the process is still running.


If you're curious, you can observe a running qBittorrent instance to try
to figure out what is keeping it busy:

  strace -p `pidof qbittorrent`

If it's not doing much, it might be waiting for something, in which case
a full backtrace (with debug packages installed) may be more useful:

  gdb -batch -ex 'thread apply all bt' -p `pidof qbittorrent`

Bug#860742: liferea: 'Update Monitor' dialog does not expand properly

[Paul Wise]

On Wed, 2017-04-19 at 20:39 +0200, Paul Gevers wrote:

> Thanks for reporting the issue. However, this issue was already reported
> and fixed upstream, but RC3 was released too late to make it into Stretch.

Would it be possible to get it at least into experimental?

I notice that RC3 fixes a data loss bug (usually release-critical in
Debian), considering that and that the other changes look low risk,
I bet you could convince the release team to allow RC3 into stretch.

https://github.com/lwindolf/liferea/releases
https://github.com/lwindolf/liferea/issues/208

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#846630: Workaround

[Milos Protic]

export QT_QPA_PLATFORMTHEME=gtk2

Fix works on ubuntu 17.04 also, but you must install qt5-style-plugins package 
first.

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Ben Finney]

On 19-Apr-2017, Brian Potkin wrote:

> Set up this print queue (as root):
> 
>  lpadmin -p testq -v /home//testq-out -E -P 
> 

I have set that queue up now.

The server now stops when I try to print to a queue:

=
$ sudo systemctl restart cups

$ sudo systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Thu 2017-04-20 09:13:47 AEST; 2s ago
 Docs: man:cupsd(8)
 Main PID: 15217 (cupsd)
Tasks: 1 (limit: 4915)
   Memory: 3.9M
  CPU: 32ms
   CGroup: /system.slice/cups.service
   └─15217 /usr/sbin/cupsd -l

Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.

$ lpstat -t
scheduler is running
system default destination: SCX-4623-Series
device for HP-LaserJet-MFP-M227-M231: 
dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
device for PDF: cups-pdf:/
device for SCX-4623-Series: 
usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
device for testq: /home/bignose/testq-out
device for XP-310: 
usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
device for XP-310-Series: 
usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
HP-LaserJet-MFP-M227-M231 accepting requests since Tue 18 Apr 2017 20:33:31 AEST
PDF accepting requests since Tue 18 Apr 2017 20:22:05 AEST
SCX-4623-Series accepting requests since Wed 05 Apr 2017 11:29:50 AEST
testq accepting requests since Thu 20 Apr 2017 08:39:26 AEST
XP-310 accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
XP-310-Series accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
printer HP-LaserJet-MFP-M227-M231 is idle.  enabled since Tue 18 Apr 2017 
20:33:31 AEST
printer PDF is idle.  enabled since Tue 18 Apr 2017 20:22:05 AEST
printer SCX-4623-Series is idle.  enabled since Wed 05 Apr 2017 11:29:50 AEST
printer testq is idle.  enabled since Thu 20 Apr 2017 08:39:26 AEST
printer XP-310 disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
printer XP-310-Series disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off

$ sudo cupsctl --debug-logging

$ [… submit a Test Page job to ‘testq’, using GNOME 3 control center …]

$ lpq
lpq: Unable to connect to server.

$ sudo systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Thu 2017-04-20 09:14:08 AEST; 20s 
ago
 Docs: man:cupsd(8)
  Process: 15217 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
 Main PID: 15217 (code=exited, status=1/FAILURE)
  CPU: 44ms

Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
Apr 20 09:14:08 lantana systemd[1]: cups.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 20 09:14:08 lantana systemd[1]: cups.service: Unit entered failed state.
Apr 20 09:14:08 lantana systemd[1]: cups.service: Failed with result 
'exit-code'.

$ ls /home/bignose/testq*
ls: cannot access '/home/bignose/testq*': No such file or directory

=

I am attaching the resulting ‘/var/log/cups/error_log’ to this message.

-- 
 \ “Sometimes I — no, I don't.” —Steven Wright |
  `\   |
_o__)  |
Ben Finney 
I [20/Apr/2017:09:13:47 +1000] Listening to [v1.::1]:631 (IPv6)
I [20/Apr/2017:09:13:47 +1000] Listening to 127.0.0.1:631 (IPv4)
I [20/Apr/2017:09:13:47 +1000] Listening to /var/run/cups/cups.sock (Domain)
I [20/Apr/2017:09:13:47 +1000] Remote access is disabled.
D [20/Apr/2017:09:13:47 +1000] Added auto ServerAlias lantana
I [20/Apr/2017:09:13:47 +1000] Loaded configuration file "/etc/cups/cupsd.conf"
D [20/Apr/2017:09:13:47 +1000] Using keychain "/etc/cups/ssl" for server name 
"lantana".
I [20/Apr/2017:09:13:47 +1000] Using default TempDir of /var/spool/cups/tmp...
I [20/Apr/2017:09:13:47 +1000] Configured for up to 100 clients.
I [20/Apr/2017:09:13:47 +1000] Allowing up to 100 client connections per host.
I [20/Apr/2017:09:13:47 +1000] Using policy "default" as the default.
I [20/Apr/2017:09:13:47 +1000] Full reload is required.
I [20/Apr/2017:09:13:47 +1000] Loaded MIME database from "/usr/share/cups/mime" 
and "/etc/cups": 50 types, 86 filters...
D [20/Apr/2017:09:13:47 +1000] Loading printer HP-LaserJet-MFP-M227-M231...
D [20/Apr/2017:09:13:47 +1000] load_ppd: Loading 
/var/cache/cups/HP-LaserJet-MFP-M227-M231.data...
D [20/Apr/2017:09:13:47 +1000] 
cupsdRegisterPrinter(p=0x55c12f42e4b0(HP-LaserJet-MFP-M227-M231))
D [20/Apr/2017:09:13:47 +1000] load_ppd: Loading 
/var/cache/cups/HP-LaserJet-MFP-M227-M231.data...
D [20/Apr/2017:09:13:47 +1000] 
cupsdRegisterPrinter(p=0x55c12f42e4b0(HP-LaserJet-MFP-M227-M231))
D [20/Apr/2017:09:13:47 +1000] Loading printer PDF...
D [20/Apr/2017:09:13:47 +1000] load_ppd: Load

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Ximin Luo]

Ximin Luo:
> [..]

I've made some more process and have pushed 0.17.0 to git. However we're 
getting build errors and I don't know how to proceed:

https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/TODO
https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/cargo-vendor-pack.py

I'm not familiar with the Cargo repo formats, and I don't know how 
d/cargo-vendor-pack.py should be fixed. Help would be appreciated.

Josh, is this anything related to how your dh-cargo works? Any code that we can 
reuse?

X

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

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Brian Potkin]

On Thu 20 Apr 2017 at 08:46:21 +1000, Ben Finney wrote:

> =
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P 
> /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice 
> directive in "/etc/cups/cups-files.conf".
> 
> $ sudo emacs /etc/cups/cups-files.conf
> 
> $ grep FileDevice /etc/cups/cups-files.conf
> FileDevice Yes
> 
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P 
> /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice 
> directive in "/etc/cups/cups-files.conf".
> =

Did you restart cups?

systemctl restart cups

Regards,

Brian.

Bug#860011: xspim

[Vincent Danjean]

tags 860011 +patch
thanks

  Hi,

  If someone want the CLI part of xspim to be in stretch, here is
a patch that remove xspim from the package (and so close this bug).
Not using it myself, I wont ask the release managers for a freeze
exception myself nor upload the package with this patch.

  Regards,
Vincent

$ svn diff debian/
Index: debian/spim.install
===
--- debian/spim.install (révision 27204)
+++ debian/spim.install (copie de travail)
@@ -1,6 +1,3 @@
 spim/spim   usr/bin
-xspim/xspim usr/bin
 CPU/exceptions.susr/lib/spim
-debian/xspim.desktop   usr/share/applications
-debian/xspim.svg   usr/share/pixmaps
 debian/spim-docusr/share/doc-base/
Index: debian/spim.manpages
===
--- debian/spim.manpages(révision 27204)
+++ debian/spim.manpages(copie de travail)
@@ -1,2 +1 @@
 Documentation/spim.man
-Documentation/xspim.man




-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

Hi,

1st, I have always had the idea the the spd service had bugs and was not
really usable: spent so resource, didn't run really, etc. Hence the fact
it's always been in "no" in defaults/speech-dispatcher.

2nd, given this feedback, maybe we may try requesting to the initscript
to wait for some seconds, with a kind of pause parameter? Would it fix
the bug?

Regards,


Le 19/04/2017 à 22:18, Cindy-Sue Causey a écrit :
> On 4/18/17, Paul Gevers  wrote:
>> Hi all,
>>
>> I don't know what to make of it, but when I first start the speechd-up
>> daemon by hand, then the init script succeeds (because it finds the
>> daemon already running). But now it comes, I then can stop and start the
>> daemon successfully, but only when I am quick enough. This is
>> reproducible, sleep 4 works always, sleep 5 always fails (so far).
>>
>> paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
>> --quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
>> --pidfile "/var/run/speechd-up.pid" -- -l1
>> [Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
>> "/etc/speechd-up.conf"
>>
>> paul@testavoira ~ $ sudo service speechd-up start
>>
>> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
>> service speechd-up start
>>
>> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
>> service speechd-up start
>> Job for speechd-up.service failed because the control process exited
>> with error code.
>> See "systemctl status speechd-up.service" and "journalctl -xe" for details.
> 
> 
> Some things have been snipped above while I hope I left enough of
> Paul's latest feedback to give it due Respect. :)
> 
> Simultaneous in my inbox is a different bug about Synaptic possibly
> keeping Orca from operating while Synaptic is open. It's this Bug
> #859262.
> 
> Synaptic "freezes Orca screen reader"
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262
> 
> Is something like that maybe a possibility?
> 
> Seeing the word "Synaptic" also originally made me wonder if our
> *_CHOICE_* of package managers is affecting things somehow.
> 
> In my case, I have neither Synaptic nor Orca open because I don't use
> those. I only use "apt-get" via terminal interface for my package
> management.
> 
> One thing is that I still don't know how to actually test speechd-up's
> functionality. For now, all I know is that it appeared to have
> successfully, initially installed with no complaints (via "apt-get
> install speechd-up").
> 
> Another factor in my install attempt is that mine was a brand new
> install. There was no residual "clutter" of past installs that could
> potentially also be causing unknown complications.
> 
> Cindy :)
> 

-- 
Logo Hypra  
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin

Bug#860747: dh_ruby: please inject versioned dependency on ruby metapackage

[Antonio Terceiro]

Control: reopen -1
Control: reassign -1 ruby-all-dev
Control: retitle -1 ruby-all-dev: include upper bound on generated ruby 
dependencies

On Wed, Apr 19, 2017 at 03:53:57PM -0400, Aaron M. Ucko wrote:
> Hi, Antonio.  Thanks for the quick response!
> 
> Antonio Terceiro  writes:
> 
> > ruby-fast-xs is broken on m68k because it is a very old binary, from before
> > this was implemented, and AFAICT it can't be built anymore because something
> > else is not available.
> 
> The ruby-fast-xs version in play at the time (now superseded by a +b3
> build against ruby 2.3) had, per
> https://buildd.debian.org/status/fetch.php?pkg=ruby-fast-xs&arch=m68k&ver=0.8.0-3%2Bb2&stamp=1456486333&raw=0,
> 
> Depends: libc6 (>= 2.1.3), libgmp10, libruby2.2 (>= 2.2.0~1), ruby (>= 1:2.2)
> 
> However, there was (and still is) no upper bound on the ruby
> metapackage's version, allowing for mismatches.

Ah fair enough, I missed that bit. These dependencies are specified in
ruby-all-dev, so I am reassigning accordingly. It should be just a
matter of including the << dependency there.


signature.asc
Description: PGP signature

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Ben Finney]

On 19-Apr-2017, Brian Potkin wrote:
> On Thu 20 Apr 2017 at 06:32:08 +1000, Ben Finney wrote:
> > How can you tell that a job doesn't get that far?
>
> It would have printed. You record that it didn't.

Oh, I thought you were seeing something in the output that
independently verified that, so I wanted to know what that information
was :-)

> > > Set up this print queue (as root):
> > >
> > >  lpadmin -p testq -v /home//testq-out -E -P 
> > > 
>
> […] change it to "-v file:/home//testq-out". The idea is to
> discover whether the job goes through the filtering system.

=
$ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P 
/etc/cups/ppd/SCX-4623-Series.ppd
lpadmin: File device URIs have been disabled. To enable, see the FileDevice 
directive in "/etc/cups/cups-files.conf".

$ sudo emacs /etc/cups/cups-files.conf

$ grep FileDevice /etc/cups/cups-files.conf
FileDevice Yes

$ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P 
/etc/cups/ppd/SCX-4623-Series.ppd
lpadmin: File device URIs have been disabled. To enable, see the FileDevice 
directive in "/etc/cups/cups-files.conf".
=

-- 
 \   “Following fashion and the status quo is easy. Thinking about |
  `\your users' lives and creating something practical is much |
_o__)harder.” —Ryan Singer, 2008-07-09 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#710028: gnome-terminal: resize window after adding a tab and switching desktop, then coming back gets the previous size

[Jake]

The problem seems to occur when the terminal is losing focus, no need to switch 
desktop.


is this ever going to get fixed?  it's really annoying.

gnome-terminal 3.18.3

Linux Mint 18
LSB Version: 
core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Linux fur 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

-jake

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

On 04/19/2017 11:36 PM, Bastien ROUCARIES wrote:
> Package: wnpp
> Severity: wishlist
> Owner: ro...@debian.org
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-diffie-hellman
>   Version : 5.0.2
>   Upstream Author : Calvin Metcalf
> * URL : https://github.com/crypto-browserify/diffie-hellman
> * License : Expat
>   Programming Lang: JavaScript
>   Description : pure js diffie-hellman key exchange
> 
>  Diffie–Hellman key exchange (D–H)  is a specific method of securely
>  exchanging cryptographic keys over a public channel. The
> Diffie–Hellman key exchange method allows two parties that have no
> prior knowledge of each other to jointly establish a shared secret key
> over an insecure channel. This key can then be used to encrypt
> subsequent communications using a symmetric key cipher.
>  .
>  Node.js is an event-based server-side JavaScript engine.

Is this timing safe? From the github page it uses a pure-JS
BigNum implementation (bn.js) for the complicated stuff, but
the README of that code doesn't mention timing at all. And
from perusing the source code of bn.js, it doesn't appear to
be the case that their implementation of exponentiation in
a prime field is geared towards constant-time execution (when
the sizes are the same).

If you look at e.g. OpenSSL's source code (bn_exp.c), there's
a specific function (bn_mod_exp_mont_consttime) in there that
takes great care of making sure that the operation runs in
constant time - down to how the memory layout is organized. I
wouldn't know how you'd even do that in an interpreted
language such as JavaScript, but even if that's possible, I'd
suspect that a lot of brain power would need to go into
designing that [1], while bn.js's implementation of the
Red.pow function seems rather straight-forward. (Which is
fine, bn.js appears to have the goal to be a generic bignum
library, and not targeted at crypto.)

What I'm saying is: while not having tested that, I believe
that this implementation of DH is going to be susceptible to
timing attacks. (And if it isn't, the author should really
provide some rationale why not, with some test results. The
README is rather sparse, though.) Which would be fine if you
just wanted to use this library to generate the DH prime
itself (that is not timing critical), or just use it in an
academic context (to let people play around with DH), but
I'd not want to use this for real-world applications of the
actual key exchange protocol.

Regards,
Christian

[1] Especially if this is to be run in browsers, with
different JITs etc. Designing algorithms in pure JS
for these environments that are timing-safe looks rather
daunting to me.

Bug#860769: please fix testing symlink and add stable symlink

[Andreas Beckmann]

On 2017-04-19 22:51, Michael Stapelberg wrote:
> $ ls -l /srv/piuparts.debian.org/htdocs/{testing,stable}
> ls: cannot access /srv/piuparts.debian.org/htdocs/stable: No such file or 
> directory
> lrwxrwxrwx 1 piupartsm piuparts 6 Jan 25  2015 
> /srv/piuparts.debian.org/htdocs/testing -> jessie
> 
> testing should point to stretch, not jessie.
> It’d be nice if “stable” could be created (pointing to jessie).

Given the age of the testing link, I'd rather remove it. And I would not
recommend adding any new *manually* created links. But if we could
manage these with piuparts-report.py via piuparts.conf ... patches
welcome :-)


Andreas

Bug#860777: sysv init scripts fail to stop daemons

[Markus Wanner]

Package: courier-mta
Version: 0.76.1-1
Severity: important
Tags: pending

Hi,

all of the daemons from src:courier-mta cannot be stopped via their sysv
init scripts due to $PIDFILE not being set properly. Looking at the git
history, this seems broken since the addition of support for
non-standard pid file locations (see #822067 as well) and the change to
use init-d-script.

For the same reason, status doesn't work, either. Installations using
systemd are not affected, obviously.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#860776: ITP: r-cran-cellranger -- GNU R package to map spreadsheet cell ranges to rows and columns

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-cellranger
  Version : 1.1.0
  Upstream Author : Jennifer Bryan
* URL or Web page : 
https://cloud.r-project.org/web/packages/cellranger/index.html
* License : MIT
  Description : GNU R package to map spreadsheet cell ranges to rows and 
columns

Just like yesterday's ITP r-cran-rematch (which is used by this package),
r-cran-cellranger is now a build-dependency of the existing package
r-cran-readxl.

Thanks for accepting r-cran-rematch within a day.  Much appreciated.  Once
this one is in I can update r-cran-readxl.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#860775: libpcl-dev: PCLConfig.cmake needs update for libopenmpi2

[Michael Bleier]

Package: libpcl-dev
Version: 1.8.0+dfsg1-3+b1
Severity: normal

Dear Maintainer,

the CMake config file of PCL
(/usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake) currently adds
"/usr/lib/libmpi.so" to "VTK_LIBRARIES" (see line 493 of
PCLConfig.cmake).

With libopenmpi2 available in Debian stretch there is no libmpi in "/usr/lib"
anymore. The libs were moved to "/usr/lib/x86_64-linux-gnu". This
currently breaks building other CMake projects with PCL.

The PCLConfig.cmake probably just needs to me regenerated.

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.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 libpcl-dev depends on:
ii  libboost-all-dev1.62.0.1
ii  libeigen3-dev   3.3.2-1
ii  libflann-dev1.9.1+dfsg-2
ii  libopenni-dev   1.5.4.0-14+b1
ii  libopenni2-dev  2.2.0.33+dfsg-7
ii  libpcl-apps1.8  1.8.0+dfsg1-3+b1
ii  libpcl-common1.81.8.0+dfsg1-3+b1
ii  libpcl-features1.8  1.8.0+dfsg1-3+b1
ii  libpcl-filters1.8   1.8.0+dfsg1-3+b1
ii  libpcl-io1.81.8.0+dfsg1-3+b1
ii  libpcl-kdtree1.81.8.0+dfsg1-3+b1
ii  libpcl-keypoints1.8 1.8.0+dfsg1-3+b1
ii  libpcl-ml1.81.8.0+dfsg1-3+b1
ii  libpcl-octree1.81.8.0+dfsg1-3+b1
ii  libpcl-outofcore1.8 1.8.0+dfsg1-3+b1
ii  libpcl-people1.81.8.0+dfsg1-3+b1
ii  libpcl-recognition1.8   1.8.0+dfsg1-3+b1
ii  libpcl-registration1.8  1.8.0+dfsg1-3+b1
ii  libpcl-sample-consensus1.8  1.8.0+dfsg1-3+b1
ii  libpcl-search1.81.8.0+dfsg1-3+b1
ii  libpcl-segmentation1.8  1.8.0+dfsg1-3+b1
ii  libpcl-stereo1.81.8.0+dfsg1-3+b1
ii  libpcl-surface1.8   1.8.0+dfsg1-3+b1
ii  libpcl-tracking1.8  1.8.0+dfsg1-3+b1
ii  libpcl-visualization1.8 1.8.0+dfsg1-3+b1
ii  libqhull-dev2015.2-2
ii  libvtk6-dev 6.3.0+dfsg1-4

libpcl-dev recommends no packages.

Versions of packages libpcl-dev suggests:
pn  libpcl-doc  

-- no debconf information

Bug#860011: xspim

[Tim Retout]

tags 860011 serious
retitle 860011 xspim: white screen, broken gui, 100% cpu
thanks

Thanks Vincent.

After resolving the fonts issues, I still get the white screen
(although running under Xephyr there's some text, but not all).

I've also noticed CPU gets pegged at 100% when this happens.  Here's a
backtrace from gdb:

(gdb) run
Starting program: /usr/bin/xspim
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x55573638 in yylex () at lex.yy.c:813
813 lex.yy.c: No such file or directory.
(gdb) bt
#0  0x55573638 in yylex () at lex.yy.c:813
#1  0x5556defc in yyparse () at y.tab.c:2856
#2  0x55561bcb in read_assembly_file (name=0x557f0930
"/usr/lib/spim/exceptions.s") at ../CPU/spim-utils.c:210
#3  0x55561939 in initialize_world
(exception_file_names=0x55582580 "/usr/lib/spim/exceptions.s") at
../CPU/spim-utils.c:122
#4  0x5557619c in main (argc=1, argv=0x7fffe2d8) at xspim.c:483

So I suspect something's going wrong when parsing the default exceptions.s?

-- 
Tim Retout 

Bug#854348: ipv6: refcnt pb when removing a peer address

[Ben Hutchings]

On Mon, 2017-02-06 at 11:09 +0100, Nicolas Dichtel wrote:
> Package: src:linux
> Version: 3.16.39-1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> Under some circumstances, when an ipv6 peer addresse is removed, there is a
> refcnt problem:
>   kernel:[ 9614.220549] unregister_netdevice: waiting for lo to become free. 
> Usage count = 2
> 
> This bug has been fixed by the following upstream patch:
>   f24062b07dda ipv6: fix a refcnt leak with peer addr
> 
> You may also consider backporting thoses patches:
>   e7478dfc4656 ipv6: use addrconf_get_prefix_route() to remove peer addr

I'm happy to apply those two.

>   8e3d5be73681 ipv6: Avoid double dst_free
[...]

I don't understand this well enough to safely backport it.  Do you know
whether the issue it fixes actually exists in 3.16?  Also, it needs at
least one follow-on fix:

   02bcf4e082e4 ipv6: Check rt->dst.from for the DST_NOCACHE route

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Brian Potkin]

On Thu 20 Apr 2017 at 06:32:08 +1000, Ben Finney wrote:

> On 19-Apr-2017, Brian Potkin wrote:
> > On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
> > 
> > > =
> > > $ lpstat -t
> > > scheduler is running
> > > system default destination: SCX-4623-Series
> > > device for HP-LaserJet-MFP-M227-M231: 
> > > dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
> > 
> > There is a direct connection to the printer via its Airprint facilty,
> > No other CUPS server is involved. A job doesn't get as far as using the
> > device.
> 
> How can you tell that a job doesn't get that far?

It would have printed. You record that it didn't. Assuming the device is
correct and wireless and printer are working soundly.

> > > device for PDF: cups-pdf:/
> > > device for SCX-4623-Series: 
> > > usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
> > 
> > A local connection. Looks ok.
> 
> This is the printer queue which worked fine until early 2017.
> 
> > > printer SCX-4623-Series now printing SCX-4623-Series-65.  enabled since 
> > > Wed 19 Apr 2017 21:03:20 AEST
> > > Waiting for printer to become available.
> > 
> > This is a stuck job.
> 
> Every job that I submit now gets stuck like this.
> 
> > You should be able to cancel the stuck job and clear the last two
> > lines with 'cancel -a -x'. Check /var/spool/cups before and after
> > the command.
> 
> =
> $ sudo ls -l /var/spool/cups/
> total 4
> drwxrwx--T 2 root lp 4096 Apr 20 06:21 tmp
> 
> [… submit a Test Page job using GNOME 3's control center …]
> 
> $ sudo ls -l /var/spool/cups/
> total 12
> -rw--- 1 root lp  970 Apr 20 06:23 c00066
> -rw-r- 1 root lp  234 Apr 20 06:23 d00066-001
> drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp
> 
> $ lpstat -t
> $ lpstat -t
> scheduler is running
> system default destination: SCX-4623-Series
> […]
> SCX-4623-Series accepting requests since Thu 20 Apr 2017 06:23:15 AEST
> […]
> printer SCX-4623-Series now printing SCX-4623-Series-66.  enabled since Thu 
> 20 Apr 2017 06:23:15 AEST
> Waiting for printer to become available.
> […]
> SCX-4623-Series-66  bignose   1024   Thu 20 Apr 2017 06:23:15 AEST
> 
> $ cancel -a -x
> 
> $ sudo ls -l /var/spool/cups/
> total 8
> -rw--- 1 root lp  970 Apr 20 06:23 c00066
> drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp
> 

The d file has been removed from the queue.

> =
> 
> > Set up this print queue (as root):
> > 
> >  lpadmin -p testq -v /home//testq-out -E -P 
> > 
> 
> Hasn't that already been done?

No. Note the different device-uri (-v). However, it is incorrect; change
it to "-v file:/home//testq-out". The idea is to discover whether
the job goes through the filtering system.
 
> I initially set up this print queue using GNOME 3 control center. I
> didn't need to specify any PPD manually.
>
> The printer has been working unchanged for years until early 2017. Are
> you saying I need to remove it and start again? I would prefer to
> diagnose what's wrong, so that this problem can be fixed for others
> too.

I haven't said anything about removing your present queues as part of
the suggested outlined diagnostic approch.

Regards,

Brian.

Bug#857955: libnb-ide14-java: broken symlinks: /usr/share/netbeans/ide14/modules/ext/*.jar

[Markus Koschany]

Control: severity -1 serious

I think this should be fixed for Stretch. Broken symlinks are of course
unintended. I took the opportunity to fix another yet unreported bug [1]
that is at least annoying.

Markus

[1] https://netbeans.org/bugzilla/show_bug.cgi?id=256166



signature.asc
Description: OpenPGP digital signature

Bug#860773: unblock: pysal/1.13.0-4

[Bas Couwenberg]

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

Please unblock package pysal

It "fixes" #860694 by ignoring test failure on i386 where it's normally
not built (the source only builds arch:all packages).

unblock pysal/1.13.0-4

Kind Regards,

Bas
diff -Nru pysal-1.13.0/debian/changelog pysal-1.13.0/debian/changelog
--- pysal-1.13.0/debian/changelog   2017-01-28 12:38:13.0 +0100
+++ pysal-1.13.0/debian/changelog   2017-04-19 11:19:27.0 +0200
@@ -1,3 +1,11 @@
+pysal (1.13.0-4) unstable; urgency=medium
+
+  * Team upload.
+  * Ignore test failures on i386, package not normally built there.
+(closes: #860694)
+
+ -- Bas Couwenberg   Wed, 19 Apr 2017 11:19:27 +0200
+
 pysal (1.13.0-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru pysal-1.13.0/debian/rules pysal-1.13.0/debian/rules
--- pysal-1.13.0/debian/rules   2017-01-28 12:36:16.0 +0100
+++ pysal-1.13.0/debian/rules   2017-04-19 11:18:38.0 +0200
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+
 export PYBUILD_NAME=pysal
 export PYBUILD_TEST_NOSE=1
 export PYBUILD_TEST_ARGS=--exclude test_DistanceBand_arc  
--exclude-dir=pysal/contrib --exclude-dir pysal/network
@@ -8,6 +10,14 @@
 %:
dh  $@ --with python2,python3 --buildsystem pybuild
 
+override_dh_auto_test:
+# Ignore test failures on problematic architectures only
+ifneq (,$(findstring $(DEB_BUILD_ARCH),"i386"))
+   dh_auto_test || echo "Ignoring test failures"
+else
+   dh_auto_test
+endif
+
 override_dh_python2:
dh_python2 -ppython-pysal
dh_numpy -ppython-pysal

Bug#860774: relax dependency on libldap-common

[Ryan Tandy]

Package: libldap-2.4-2
Version: 2.4.44+dfsg-1

The tightly-versioned libldap-common dependency is causing frequent B-D 
uninstallability on the buildds and making extra work for porters having 
to re-bootstrap it.


e.g. the last upload failed on ppc64el, was given back, and immediately 
went BD-Uninstallable:


 openldap build-depends on:
 - heimdal-multidev:ppc64el
 heimdal-multidev depends on:
 - libhdb9-heimdal:ppc64el (= 7.1.0+dfsg-12)
 libhdb9-heimdal depends on:
 - libldap-2.4-2:ppc64el (>= 2.4.7)
 libldap-2.4-2 depends on missing:
 - libldap-common:ppc64el (= 2.4.44+dfsg-3)

For now the dependency could probably just be unversioned, as 
libldap-common's contents haven't changed since it was introduced.

Bug#860772: unblock: python-geopandas/0.2.1-3

[Bas Couwenberg]

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

Please unblock package python-geopandas

It "fixes" #860621 by ignoring test failure on i386 where it's normally
not built (the source only builds arch:all packages)

unblock python-geopandas/0.2.1-3

Kind Regards,

Bas
diff -Nru python-geopandas-0.2.1/debian/changelog 
python-geopandas-0.2.1/debian/changelog
--- python-geopandas-0.2.1/debian/changelog 2017-01-02 19:37:48.0 
+0100
+++ python-geopandas-0.2.1/debian/changelog 2017-04-19 10:28:22.0 
+0200
@@ -1,3 +1,11 @@
+python-geopandas (0.2.1-3) unstable; urgency=medium
+
+  * Team upload.
+  * Ignore test failures on i386, package not normally built there.
+(closes: #860621)
+
+ -- Bas Couwenberg   Wed, 19 Apr 2017 10:28:22 +0200
+
 python-geopandas (0.2.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-geopandas-0.2.1/debian/rules 
python-geopandas-0.2.1/debian/rules
--- python-geopandas-0.2.1/debian/rules 2017-01-02 19:35:41.0 +0100
+++ python-geopandas-0.2.1/debian/rules 2017-04-19 10:09:47.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+
 export PYBUILD_NAME=geopandas
 
 %:
@@ -16,8 +18,16 @@
 override_dh_auto_test:
# Disable geocode tests as these require online access
cp -v debian/nybb_*.zip examples/
+
+# Ignore test failures on problematic architectures only
+ifneq (,$(findstring $(DEB_BUILD_ARCH),"i386"))
+   PYBUILD_SYSTEM=custom \
+   PYBUILD_TEST_ARGS="TRAVIS=1 nosetests -v -e test_geocode.py" 
dh_auto_test || echo "Ignoring test failures"
+else
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="TRAVIS=1 nosetests -v -e test_geocode.py" 
dh_auto_test
+endif
+
rm -f examples/nybb_*.zip
 
 override_dh_auto_install:

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-diffie-hellman
  Version : 5.0.2
  Upstream Author : Calvin Metcalf
* URL : https://github.com/crypto-browserify/diffie-hellman
* License : Expat
  Programming Lang: JavaScript
  Description : pure js diffie-hellman key exchange

 Diffie–Hellman key exchange (D–H)  is a specific method of securely
 exchanging cryptographic keys over a public channel. The
Diffie–Hellman key exchange method allows two parties that have no
prior knowledge of each other to jointly establish a shared secret key
over an insecure channel. This key can then be used to encrypt
subsequent communications using a symmetric key cipher.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#852059: [Pkg-dns-devel] Bug#852059: Bug#852059: severity of 852059 is important, severity of 859418 is important, severity of 859419 is important

[Ondřej Surý]

Hmm, didn't know that. Next time then, thanks for the info.


On 19 April 2017 23:21:12 Michael Biebl  wrote:


Am 19.04.2017 um 23:02 schrieb Ondřej Surý:

Sorry, combination of auto-removal with lack of time right now. I will
bump the severity back to RC and fix opendnssec this week.


You can reset the autoremoval counter by simply replying to the bug report.
That would be less confusing then a downgrade/upgrade dance and it keeps
the issue on the radar of the release team.

Regards,
Michael


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




--
___
pkg-dns-devel mailing list
pkg-dns-de...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#860317: upgrade to latest stretch version breaks

[Brent S. Elmer Ph.D.]

On Wed, 2017-04-19 at 18:45 +0200, Andreas Metzler wrote:
> On 2017-04-17 "Brent S. Elmer Ph.D."  wrote:
> [...]
> > paniclog and mainlog contains this:
> > 2017-04-17 14:30:26 IPv6 socket creation failed: Address family not
> > supported by protocol
> 
> This looks like 610918, i.e. having changed Debian's default default
> setup to disable IPv6 without adapting exim4 configuration
> accordingly.
> 
> Are you able to manually start a daemon instance?
> update-exim4.conf && exim4 -bd -d
> 
> cu Andreas

No, here is the output.

# update-exim4.conf && exim4 -bd -d
Exim version 4.89 uid=0 gid=0 pid=3468 D=fbb95cfd
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
DNSSEC Event OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm
dbmjz dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Compiler: GCC [6.3.0 20170221]
Library version: Glibc: Compile: 2.24
Runtime: 2.24
Library version: GnuTLS: Compile: 3.5.8
 Runtime: 3.5.8
Library version: PCRE: Compile: 8.39
   Runtime: 8.39 2016-06-14
Total 13 lookups
WHITELIST_D_MACROS: "OUTGOING"
TRUSTED_CONFIG_LIST: "/etc/exim4/trusted_configs"
changed uid/gid: forcing real = effective
  uid=0 gid=0 pid=3468
  auxiliary group list: 
seeking password data for user "uucp": cache not available
getpwnam() succeeded uid=10 gid=10
configuration file is /var/lib/exim4/config.autogenerated
log selectors = cffc 0e320202
cwd=/home/brente 3 args: exim4 -bd -d
trusted user
admin user
seeking password data for user "mail": cache not available
getpwnam() succeeded uid=8 gid=8
DSN: hubbed_hosts propagating DSN
DSN: nonlocal propagating DSN
DSN: real_local propagating DSN
DSN: system_aliases propagating DSN
DSN: userforward propagating DSN
DSN: procmail propagating DSN
DSN: maildrop propagating DSN
DSN: lowuid_aliases propagating DSN
DSN: local_user propagating DSN
DSN: mail4root propagating DSN
user name "root" extracted from gecos field "root"
originator: uid=0 gid=0 login=root name=root
 3468 listening on 127.0.0.1 port 25
 3468 LOG: MAIN
 3468   IPv6 socket creation failed: Address family not supported by
protocol
 3468 LOG: PANIC DIE
 3468   IPv6 socket creation failed: Address family not supported by
protocol
 3468 search_tidyup called
 3468  Exim pid=3468 terminating with rc=1

Bug#849752: lintian: dpkg-source failed with status 2 / no such file or directory

[Niels Thykier]

Drew Parsons:
> On Fri, 30 Dec 2016 15:52:02 +0100 Patrick Matthäi wrote:
>>  
>> with both versions of lintian on jessie/jessie-backports (I think
> since a stable update of
>> jessie itself) I get an error on checking most of my packages:
>>  
>> # export LINTIAN_DEBUG=1; lintian -IE --pedantic
> /var/cache/pbuilder/result/ckport*.changes
>> warning: the authors of lintian do not recommend running it with root
> privileges!
>> N: Using dpkg-source to unpack ckport
>> cp: cannot stat '/tmp/temp-lintian-lab-
> ...: No such file or directory
> 
> 
> I'm now hitting this lintian bug.  Not on all packages, but on the
> changes file (binary changes, not source) generated by pdebuild for
> instant 2016.2.0-2.
> 
> Drew
> 

Hi,

Patrick, can you also "only" reproduce this on pdebuild produced binary
.changes files?

Thanks,
~Niels

Bug#852059: [Pkg-dns-devel] Bug#852059: severity of 852059 is important, severity of 859418 is important, severity of 859419 is important

[Michael Biebl]

Am 19.04.2017 um 23:02 schrieb Ondřej Surý:
> Sorry, combination of auto-removal with lack of time right now. I will
> bump the severity back to RC and fix opendnssec this week.

You can reset the autoremoval counter by simply replying to the bug report.
That would be less confusing then a downgrade/upgrade dance and it keeps
the issue on the radar of the release team.

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#859262: Re: freezes Orca screen reader

[Joanmarie Diggs]

On 04/19/2017 04:28 PM, Samuel Thibault wrote:
> Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
>> Time to hunt for some dbus experts who can tell us why a process might
>> fail to respond to a ping.
> 
> Well, the application could simply be busy doing other stuff, like
> processing huge packages lists for synaptic.  And that's not a reason
> for Orca to freeze, for me that's the most important bug to fix: Orca
> shouldn't rely on applications behaving correctly.

Orca knows better than to do that. ;) There may be yet another bad
behavior that it's failing to handle.

Please send me a full debug.out, captured from Orca master or Orca
3.24.x (i.e. current stable). Instructions here:
https://wiki.gnome.org/Projects/Orca/Debugging

Thanks.
--joanie

Bug#859438: reopening [ Re: Bug#859438: marked as done (preseed header magic) ]

[Holger Wansing]

Control: reopen -1


ow...@bugs.debian.org (Debian Bug Tracking System) wrote:
> Your message dated Tue, 18 Apr 2017 23:04:18 +
> with message-id 
> and subject line Bug#859438: fixed in installation-guide 20170419
> has caused the Debian Bug report #859438,
> regarding preseed header magic
> to be marked as done.

As I wrote in
https://lists.debian.org/debian-boot/2017/04/msg00187.html
this is not completely done.

There are additional changings required to the get the example-preseed.txt
file updated (patch attached in above mail).

Thus I am reopening this bug.


Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#852059: [Pkg-dns-devel] Bug#852059: severity of 852059 is important, severity of 859418 is important, severity of 859419 is important

[Ondřej Surý]

Sorry, combination of auto-removal with lack of time right now. I will bump 
the severity back to RC and fix opendnssec this week.


Ondřej


On 19 April 2017 22:03:13 Michael Biebl  wrote:


On Tue, 18 Apr 2017 17:21:13 +0200 =?UTF-8?Q?Ond=C5=99ej?=
=?UTF-8?Q?_Sur=C3=BD?=  wrote:

severity 852059 important
severity 859418 important
severity 859419 important
thanks


Could you please elaborate why you downgraded those bug reports,
especially 852059? Rendering your system unbootable looks pretty much RC
to me.

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




--
___
pkg-dns-devel mailing list
pkg-dns-de...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#859262: Re: gnome-orca: Gets stuck if target app is busy

[Samuel Thibault]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=756514

Michael Biebl, on mer. 19 avril 2017 22:55:01 +0200, wrote:
> Am 19.04.2017 um 22:37 schrieb Niels Thykier:
> > Control: retitle -1 gnome-orca: Gets stuck if target app is busy
> > 
> > Samuel Thibault:
> >> Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
> >>> Time to hunt for some dbus experts who can tell us why a process might
> >>> fail to respond to a ping.
> >>
> >> Well, the application could simply be busy doing other stuff, like
> >> processing huge packages lists for synaptic.  And that's not a reason
> >> for Orca to freeze, for me that's the most important bug to fix: Orca
> >> shouldn't rely on applications behaving correctly.
> >>
> >> Samuel
> >>
> > 
> > Ok, thanks for clarifying. :)
> > 
> > I have retitled the bug to reflect the situation.
> 
> Is this https://bugzilla.gnome.org/show_bug.cgi?id=756514 maybe?

That very much looks so :)

Now, the bug is reported as being a regression from Jessie, perhaps for
the Stretch case we should check what changed, since Orca not being
robust against non-responsive applications is not really something new.

Samuel

Bug#860770: qjackctl: please make the build reproducible

[Chris Lamb]

Source: qjackctl
Version: 0.4.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that qjackctl could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/10_reproducible_build.patch1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/10_reproducible_build.patch2017-04-19 
21:53:36.249919428 +0100
@@ -0,0 +1,16 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-04-19
+
+--- qjackctl-0.4.4.orig/configure.ac
 qjackctl-0.4.4/configure.ac
+@@ -9,6 +9,9 @@ AC_CONFIG_FILES(Makefile qjackctl.spec s
+ AC_CACHE_VAL([ac_cv_build_date],
+[ac_cv_build_date=$(date +"%b %d %Y %H:%M %z")])
+ ac_build_date="$ac_cv_build_date"
++if test -n "$SOURCE_DATE_EPOCH"; then
++  ac_build_date="`LC_ALL=C date --utc --date="@$SOURCE_DATE_EPOCH" +"%b 
%d %Y %H:%M %z"`"
++fi
+ AC_DEFINE_UNQUOTED(CONFIG_BUILD_DATE, ["$ac_build_date"], [Build date and 
time.])
+ 
+ # Build version string.
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2017-04-19 21:53:34.737912684 +0100
@@ -0,0 +1 @@
+10_reproducible_build.patch

Bug#860673: [Python-modules-team] Bug#860673: python-django: FTBFS on i386: E: Build killed with signal TERM after 150 minutes of inactivity

[Brian May]

Chris Lamb  writes:

> Lucas Nussbaum wrote:
>
>> > test_output_verbose (test_runner.test_debug_sql.TestDebugSQL) ... ok
>> > E: Build killed with signal TERM after 150 minutes of inactivity
>
> Can't reproduce this locally alas...

I couldn't reproduce this locally. I use a 32bit schroot.
-- 
Brian May 

Bug#859262: Re: gnome-orca: Gets stuck if target app is busy

[Michael Biebl]

Am 19.04.2017 um 22:37 schrieb Niels Thykier:
> Control: retitle -1 gnome-orca: Gets stuck if target app is busy
> 
> Samuel Thibault:
>> Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
>>> Time to hunt for some dbus experts who can tell us why a process might
>>> fail to respond to a ping.
>>
>> Well, the application could simply be busy doing other stuff, like
>> processing huge packages lists for synaptic.  And that's not a reason
>> for Orca to freeze, for me that's the most important bug to fix: Orca
>> shouldn't rely on applications behaving correctly.
>>
>> Samuel
>>
> 
> Ok, thanks for clarifying. :)
> 
> I have retitled the bug to reflect the situation.

Is this https://bugzilla.gnome.org/show_bug.cgi?id=756514 maybe?


-- 
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#860769: please fix testing symlink and add stable symlink

[Michael Stapelberg]

Package: piuparts.debian.org
Severity: normal

$ ls -l /srv/piuparts.debian.org/htdocs/{testing,stable}
ls: cannot access /srv/piuparts.debian.org/htdocs/stable: No such file or 
directory
lrwxrwxrwx 1 piupartsm piuparts 6 Jan 25  2015 
/srv/piuparts.debian.org/htdocs/testing -> jessie

testing should point to stretch, not jessie.
It’d be nice if “stable” could be created (pointing to jessie).

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

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

Bug#860768: ITP: python-ordered-set -- ordered set implementation for Python

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-ordered-set
  Version : 2.0.2
  Upstream Author : Luminoso Technologies, Inc.
* URL : https://github.com/LuminosoInsight/ordered-set/
* License : Expat
  Programming Lang: Python
  Description : ordered set implementation for Python

This package is a dependency for sphinxcontrib-bibtex. It will be
co-maintained by the DPMT.

Bug#860767: Failure to bind to addresses on some ipv4 only configurations

[Sam Hartman]

package: krb5-kdc
version: 1.15-1
severity: important
tags: fixed-upstream

krb5-kdc can fail to work at all on some systems where getaddrinfo(NULL)
returns a v6 wildcard address.
Depending on kernel modules and socket configuration, you can get
address family not supported  even though v4 is working.

You'd think that  you could then explicitly configure a wildcard
address.
That doesn't work because pktinfo ends up not being used on an
explicitly configured wildcard address.
See upstream bugs  8530 and 8531

Bug#858876: Pending fixes for bugs in the libnb-platform-java package

[pkg-java-maintainers]

tag 858876 + pending
thanks

Some bugs in the libnb-platform-java package are closed in revision
d3eb2da837fb75478873254a14e513b18940e3f7 in branch '  stretch' by
Markus Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libnb-platform-java.git/commit/?id=d3eb2da

Commit message:

Use the correct library name for libjna-jni library.

Closes: #858876

Bug#859262: Re: gnome-orca: Gets stuck if target app is busy

[Niels Thykier]

Control: retitle -1 gnome-orca: Gets stuck if target app is busy

Samuel Thibault:
> Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
>> Time to hunt for some dbus experts who can tell us why a process might
>> fail to respond to a ping.
> 
> Well, the application could simply be busy doing other stuff, like
> processing huge packages lists for synaptic.  And that's not a reason
> for Orca to freeze, for me that's the most important bug to fix: Orca
> shouldn't rely on applications behaving correctly.
> 
> Samuel
> 

Ok, thanks for clarifying. :)

I have retitled the bug to reflect the situation.

Thanks,
~Niels

Bug#860702: pcl: FTBFS on i386: segmentation fault

[Jochen Sprickerhof]

* Jochen Sprickerhof  [2017-04-19 22:10]:
> > > Segmentation fault
> > > doc/doxygen/CMakeFiles/doc.dir/build.make:60: recipe for target 
> > > 'doc/doxygen/CMakeFiles/doc' failed
> > > make[3]: *** [doc/doxygen/CMakeFiles/doc] Error 139
> 
> I'm unable to reproduce this. Could you provide a backtrace?
> Note that it's pdfTeX segfaulting, not really related to pcl ;).

Oups, it's actually doxygen. Could it be that it's running out of disk
space or against some file system limit, as it's generating a lot of
files with potentially long names?


signature.asc
Description: PGP signature

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Markus Koschany]

Control: reassign -1 libnb-platform18-java

Hi,

As discussed in this bug report and on IRC, I am going to reassign this
bug to libnb-platform18-java. We haven't found any hints of embedded jar
files. It is strange that the recent change of libjna-java had no effect
on Netbeans though. For the sake of moving forward I will change the
jna.boot.library.name to jnidispatch.system.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Ben Finney]

On 19-Apr-2017, Brian Potkin wrote:
> On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
> 
> > =
> > $ lpstat -t
> > scheduler is running
> > system default destination: SCX-4623-Series
> > device for HP-LaserJet-MFP-M227-M231: 
> > dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
> 
> There is a direct connection to the printer via its Airprint facilty,
> No other CUPS server is involved. A job doesn't get as far as using the
> device.

How can you tell that a job doesn't get that far?

> > device for PDF: cups-pdf:/
> > device for SCX-4623-Series: 
> > usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
> 
> A local connection. Looks ok.

This is the printer queue which worked fine until early 2017.

> > printer SCX-4623-Series now printing SCX-4623-Series-65.  enabled since Wed 
> > 19 Apr 2017 21:03:20 AEST
> > Waiting for printer to become available.
> 
> This is a stuck job.

Every job that I submit now gets stuck like this.

> You should be able to cancel the stuck job and clear the last two
> lines with 'cancel -a -x'. Check /var/spool/cups before and after
> the command.

=
$ sudo ls -l /var/spool/cups/
total 4
drwxrwx--T 2 root lp 4096 Apr 20 06:21 tmp

[… submit a Test Page job using GNOME 3's control center …]

$ sudo ls -l /var/spool/cups/
total 12
-rw--- 1 root lp  970 Apr 20 06:23 c00066
-rw-r- 1 root lp  234 Apr 20 06:23 d00066-001
drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp

$ lpstat -t
$ lpstat -t
scheduler is running
system default destination: SCX-4623-Series
[…]
SCX-4623-Series accepting requests since Thu 20 Apr 2017 06:23:15 AEST
[…]
printer SCX-4623-Series now printing SCX-4623-Series-66.  enabled since Thu 20 
Apr 2017 06:23:15 AEST
Waiting for printer to become available.
[…]
SCX-4623-Series-66  bignose   1024   Thu 20 Apr 2017 06:23:15 AEST

$ cancel -a -x

$ sudo ls -l /var/spool/cups/
total 8
-rw--- 1 root lp  970 Apr 20 06:23 c00066
drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp

=

> Set up this print queue (as root):
> 
>  lpadmin -p testq -v /home//testq-out -E -P 
> 

Hasn't that already been done?

I initially set up this print queue using GNOME 3 control center. I
didn't need to specify any PPD manually.

The printer has been working unchanged for years until early 2017. Are
you saying I need to remove it and start again? I would prefer to
diagnose what's wrong, so that this problem can be fixed for others
too.

-- 
 \   “Courage is resistance to fear, mastery of fear — not absence |
  `\   of fear.” —Mark Twain, _Pudd'n'head Wilson_ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#860766: gimp-data recommendations

[Ricardo Fabian Peliquero]

Package: gimp-data
Version: 2.8.20-1
Severity: wishlist

Dear Maintainer,

Please consider removing gimp from gimp-data recommendations. Would it make any 
sense to move it into the suggested category?

Kind regards,

Ricardo

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

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

gimp-data depends on no packages.

Versions of packages gimp-data recommends:
pn  gimp  

gimp-data suggests no packages.

-- no debconf information

Bug#859262: Re: freezes Orca screen reader

[Samuel Thibault]

Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
> Time to hunt for some dbus experts who can tell us why a process might
> fail to respond to a ping.

Well, the application could simply be busy doing other stuff, like
processing huge packages lists for synaptic.  And that's not a reason
for Orca to freeze, for me that's the most important bug to fix: Orca
shouldn't rely on applications behaving correctly.

Samuel

Bug#859262: Re: freezes Orca screen reader

[Niels Thykier]

Paul Gevers:
> Hi
> 
> On 19-04-17 01:13, Niels Thykier wrote:
>> Reading the log file, we at least have one bug in Orca itself (a Python
>> "NameError").  I am not entirely sure whether this bug triggers the
>> "hung" process or the "hung" process triggers the "NameError".
> 
> Not sure if you (Niels) looked at the code, but when I look at it, that
> NameError is something that is not uncommon to happen as the whole
> exception handling is written exactly to handle that:
> https://sources.debian.net/src/gnome-orca/3.22.2-2/src/orca/generator.py/#L233
> 
> The "hung" happens in the exception handling (which in itself is also in
> a try/except block). To me (but I am not very good in Python and not at
> all familiar with Orca) it still looks like synaptic is doing something
> that in the end triggers a time out. I hope somebody with more Python
> and/or Orca knowledge can shine a light on this.
> 
> Paul
> 

Hi Paul,


I had a brief look at the code and:

 * You are right that the NameError is expected.  It appears to be some
   method for lazily loading/evaluating values.

 * The actual issue is the other stacktrace.

 * The exception appears to be thrown from accessing an attribute.  I am
   assuming that object/attribute is a reference to an GUI object in
   the synaptic process using a GLib/GTK protocol.

 * I have not seen that error before, but codesearch.d.n helpfully
   points us to [1].

 * From that, I found [2], which suggests atspi concludes synaptic to be
   hung because it does not respond to a dbus "ping" call to
   "org.freedesktop.DBus.Peer".  Not that it makes me any wiser as to
   why the problem occurs.

Time to hunt for some dbus experts who can tell us why a process might
fail to respond to a ping.

Thanks,
~Niels


[1]:
https://sources.debian.net/src/at-spi2-core/2.22.0-5/atspi/atspi-misc.c/?hl=1080#L1080

[2]:
https://sources.debian.net/src/at-spi2-core/2.22.0-5/atspi/atspi-misc.c/?hl=1080#L1028

Bug#860702: pcl: FTBFS on i386: segmentation fault

[Jochen Sprickerhof]

Control: tags -1 + moreinfo unreproducible

* Lucas Nussbaum  [2017-04-19 09:26]:
> > This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
> > (preloaded format=latex)
> >  restricted \write18 enabled.
> > entering extended mode
> > (./_formulas.tex
> > LaTeX2e <2017/01/01> patch level 3
> > Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
> > (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
> > Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
> > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics/epsfig.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
> > (/usr/share/texlive/texmf-dist/tex/latex/graphics-def/dvips.def
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
> > No file _formulas.aux.
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd) [1] [2] [3] [4]
> > [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
> > [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35]
> > [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50]
> > [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65]
> > [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80]
> > [81] [82] [83] (./_formulas.aux) )
> > Output written on _formulas.dvi (83 pages, 9352 bytes).
> > Transcript written on _formulas.log.
> > Segmentation fault
> > doc/doxygen/CMakeFiles/doc.dir/build.make:60: recipe for target 
> > 'doc/doxygen/CMakeFiles/doc' failed
> > make[3]: *** [doc/doxygen/CMakeFiles/doc] Error 139

I'm unable to reproduce this. Could you provide a backtrace?
Note that it's pdfTeX segfaulting, not really related to pcl ;).

Cheers Jochen


signature.asc
Description: PGP signature

Bug#860765: courier-mta: wrong delimiter in systemd service files

[Markus Wanner]

Package: courier-mta
Version: 0.75.0-6
Tags: pending

Hi,

systemd complains it cannot "add dependency on
courier-authdaemon.service,courier.service,courierfilter.service,
ignoring: Invalid argument". This simply is due to using commas rather
than spaces in the service file's Requires and After definitions.

Kind Regards

Markus Wanner




signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Cindy-Sue Causey]

On 4/18/17, Paul Gevers  wrote:
> Hi all,
>
> I don't know what to make of it, but when I first start the speechd-up
> daemon by hand, then the init script succeeds (because it finds the
> daemon already running). But now it comes, I then can stop and start the
> daemon successfully, but only when I am quick enough. This is
> reproducible, sleep 4 works always, sleep 5 always fails (so far).
>
> paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
> --quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
> --pidfile "/var/run/speechd-up.pid" -- -l1
> [Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
> "/etc/speechd-up.conf"
>
> paul@testavoira ~ $ sudo service speechd-up start
>
> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
> service speechd-up start
>
> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
> service speechd-up start
> Job for speechd-up.service failed because the control process exited
> with error code.
> See "systemctl status speechd-up.service" and "journalctl -xe" for details.


Some things have been snipped above while I hope I left enough of
Paul's latest feedback to give it due Respect. :)

Simultaneous in my inbox is a different bug about Synaptic possibly
keeping Orca from operating while Synaptic is open. It's this Bug
#859262.

Synaptic "freezes Orca screen reader"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262

Is something like that maybe a possibility?

Seeing the word "Synaptic" also originally made me wonder if our
*_CHOICE_* of package managers is affecting things somehow.

In my case, I have neither Synaptic nor Orca open because I don't use
those. I only use "apt-get" via terminal interface for my package
management.

One thing is that I still don't know how to actually test speechd-up's
functionality. For now, all I know is that it appeared to have
successfully, initially installed with no complaints (via "apt-get
install speechd-up").

Another factor in my install attempt is that mine was a brand new
install. There was no residual "clutter" of past installs that could
potentially also be causing unknown complications.

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Bug#860611: dsniff: FTBFS: ld: cannot find -lmissing

[Julián Moreno Patiño]

Hello Lukas,

Uploaded. Thanks for your contribution, Please go forward with unblock request.

Kind regards,


-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513

Bug#860746: ITP: easel -- a library of C functions for biological sequence analysis

[Andreas Tille]

Hi Michael,

On Wed, Apr 19, 2017 at 10:44:06PM +0300, Michael Crusoe wrote:
> You are welcome!

:-)
 
> git+ssh://git.debian.org/git/debian-med/easel.git is ready for review

I commited a change which renames easel-dev package to libeasel-dev (not
tested yet).  I also think that the effort of a separate library package
should end up with a dynamic library as well.  When I did so for
biosquid I used the existing configure.ac and created a Makefile.am from
the information in Makefile.in.  This enabled using autoreconf and
creating a dynamic library was easy.

As far as I can see the Makefile.am is only needed in the root dir - all
other Makefile.in might remain.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#860764: dict: recommending virtual package awk instead of gawk

[Ricardo Fabian Peliquero]

Package: dict
Version: 1.12.1+dfsg-4
Severity: wishlist

Dear Maintainer,

Please, consider replacing recommendation of gawk for virtual package awk (e.g. 
mawk, original-awk, gawk). That, of course, if you consider gawk not to be 
absolutely needed for proper dict functionality. I have been successfuly using 
dict for years, although original-awk is installed instead of gawk.

Kind regards,

Ricardo

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

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

Versions of packages dict depends on:
ii  libc62.24-10
ii  libmaa3  1.3.2-3+b2
ii  netbase  5.4
ii  recode   3.6-23

Versions of packages dict recommends:
pn  gawk  
ii  m41.4.18-1

Versions of packages dict suggests:
pn  dictd | dict-server  

-- no debconf information

Bug#860763: imagemagick: /etc/imagemagick-6/policy.xml useless limits settings

[chris_blues]

Package: imagemagick
Version: 8:6.9.7.4+dfsg-5
Severity: important

Dear Maintainer,

   * What led up to the situation?
 The need to edit large images

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 removing the limits, defined in /etc/imagemagick-6/policy.xml

   * What was the outcome of this action?
 I was able to use IM again :-/

 On this topic:
 I believe the limits are meant to make life easier for admins of 
webservers. Users on desktop machines have to have root access and the 
knowledge to find this file, and how to change it correctly. IMHO, this is not 
a good idea. I think an admin will have higher chances of finding that file and 
change than a desktop user!
 Please go back and make it a vanilla IM file again!

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

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

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

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.7.4+dfsg-5

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#767389: module hpsa no longer detects MSL2024 tape changer

[Ben Hutchings]

On Fri, 3 Mar 2017 13:47:55 +0100 Sergio Gelato  
wrote:
> control: fixed -1 4.9.2-2~bpo8+1
> 
> I confirm that the latest kernel in jessie-backports does not suffer from
> this problem.
> 
> Am building a patched 3.16.39 (it compiles OK) but won't be able to test it
> until the next maintenance window for the affected system.

Have you had a chance to do this?

The code that this patch touches didn't change between 3.14.15 and
3.16.3 (where you reported the regression) so I suspect that it is not
a complete fix.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Bug#852059: severity of 852059 is important, severity of 859418 is important, severity of 859419 is important

[Michael Biebl]

On Tue, 18 Apr 2017 17:21:13 +0200 =?UTF-8?Q?Ond=C5=99ej?=
=?UTF-8?Q?_Sur=C3=BD?=  wrote:
> severity 852059 important
> severity 859418 important
> severity 859419 important
> thanks

Could you please elaborate why you downgraded those bug reports,
especially 852059? Rendering your system unbootable looks pretty much RC
to me.

-- 
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#860762: courier-mta: certificate verification failure for CNAMEs

[Markus Wanner]

Package: courier-mta
Version: 0.73.1-1.6
Severity: important
Tags: fixed-upstream patch pending

Hi,

as Viktor Szépe recently pointed out to me, courier-mta fails to verify
certificates of other MTAs using CNAMEs as their host name. With Amazon
SES, Mailjet, etc. this recently became more common and therefore more
important to fix.

Upstream provides a fix [0] that's easy enough to backport to stretch. I
haven't tried jessie, yet.

Kind Regards

Markus Wanner


[0]: Upstream commit: Fix TLS verification when DNS lookup comes back
with CNAMEs:
https://github.com/svarshavchik/courier-libs/commit/5e522ab14f45c6f4f43c43e32a2f72fbf6354f1c



signature.asc
Description: OpenPGP digital signature

Bug#860761: upgrade to 3.3.3

[Matthias Urlichs]

Package: libeigen3-dev
Version: 3.3.2-1
Severity: important

OpenMVS does not build because of a bug that's fixed in version 3.3.3.

https://github.com/cdcseacave/openMVS/issues/164

Unfortunately, don't even think of isolating this problem …

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (750, 'testing'), (700, 'unstable'), (650, 'stable'), (550, 
'experimental'), (550, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 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 libeigen3-dev depends on:
ii  pkg-config  0.29-4+b1

libeigen3-dev recommends no packages.

Versions of packages libeigen3-dev suggests:
pn  libeigen3-doc  
pn  libmrpt-dev

-- no debconf information

Bug#860747: dh_ruby: please inject versioned dependency on ruby metapackage

[Aaron M. Ucko]

Hi, Antonio.  Thanks for the quick response!

Antonio Terceiro  writes:

> ruby-fast-xs is broken on m68k because it is a very old binary, from before
> this was implemented, and AFAICT it can't be built anymore because something
> else is not available.

The ruby-fast-xs version in play at the time (now superseded by a +b3
build against ruby 2.3) had, per
https://buildd.debian.org/status/fetch.php?pkg=ruby-fast-xs&arch=m68k&ver=0.8.0-3%2Bb2&stamp=1456486333&raw=0,

Depends: libc6 (>= 2.1.3), libgmp10, libruby2.2 (>= 2.2.0~1), ruby (>= 1:2.2)

However, there was (and still is) no upper bound on the ruby
metapackage's version, allowing for mismatches.

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

Bug#860760: RM: libnss-mysql-bg -- RoQA; RC-buggy; unmaintained upstream; (un)maintained by QA; not in Jessie or Stretch

[Paul Gevers]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While going through RC bugs of packages maintained by QA, I noticed that
libnss-mysql-bg has an RC bug open since Nov 2013 and is orphaned since Dec
2013 without anybody stepping up to fix the situation.

The package isn't in Jessie or Stretch, I think it is best to remove the
package.

Paul

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlj3wBgACgkQnFyZ6wW9
dQqAUAf/SbaFL+KnAQRMHzBsSMRmF8a32Hut0JnMfU6uXZEENDli9+P0KIyVyLZb
RcQ3cV1SvETmx215EHJ8Xbl3IpGNA8HsvUDn5PiZidp8x7VfTme/DbNJHqhHdSb2
tnP3VJU/YP9DylKLyUq//D5o6qeaAjZUUIIX4bWSeFjkBEnMXg3sycKB0l102ZsO
lDq8J/jcM7RZrh3QLOPcH/RJP6bM+O1jLcP1hA6BmMBIlUXrQ2TIzF3T6P+M02qw
CYN+0qEpzFGSTWEu7UpmvB7W3xOqzQPsyKFxssaltSaEa37KAuj0FC419wNbWhYK
nR8EXmVKUpUxzzblGZ54EPWQImetFA==
=55pm
-END PGP SIGNATURE-

Bug#860759: Please update current Project Leader references

[Chris Lamb]

Package: www.debian.org
Severity: wishlist

Dear web team,

Please update [0] (and possibly [1]...?) to reflect the result
of the recent vote.

 [0] https://www.debian.org/devel/leader
 [1] https://www.debian.org/doc/manuals/project-history/ch-leaders


Regards,

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

Bug#860746: ITP: easel -- a library of C functions for biological sequence analysis

[Michael Crusoe]

You are welcome!

git+ssh://git.debian.org/git/debian-med/easel.git is ready for review

2017-04-19 20:11 GMT+03:00 Andreas Tille :

> Very sensible!  Thanks for working on this
> Andreas.
>
> On Wed, Apr 19, 2017 at 10:06:57AM -0700, Michael R. Crusoe wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Debian Med team 
> >
> > * Package name: easel
> >   Version : 0.43
> >   Upstream Author : Sean R. Eddy 
> > * URL : https://github.com/EddyRivasLab/easel
> > * License : BSD-3-clause
> >   Programming Lang: C
> >   Description : a library of C functions for biological sequence
> analysis
> >
> >  Easel is an ANSI C code library for computational analysis of
> >  biological sequences using probabilistic models. Easel is used by
> >  HMMER, the profile hidden Markov model software that underlies the
> >  Pfam protein families database, and by Infernal, the profile
> >  stochastic context-free grammar software that underlies the Rfam RNA
> >  family database. Easel aims to make similar applications more robust
> >  and easier to develop, by providing a set of reusable, documented, and
> >  well-tested functions.
> >
> > Several existing packages contain code copies and it is high time this
> and the example
> > apps were seperately packaged.
> >
> > This will be team maintained by Debian Med
> >
> >
>
> --
> http://fam-tille.de
>



-- 
Michael R. Crusoe
Community Engineer & Co-founder
Common Workflow Language project 
https://impactstory.org/u/-0002-2961-9670
michael.cru...@gmail.com
+1 480 627 9108
+32 2 808 25 58

Bug#860236: xen pv domU crash with 3.16 kernel and xen 4.8

[Ben Hutchings]

On Fri, 2017-04-14 at 11:18 +0200, Vincent Legout wrote:
[...]
> Could cpu hotplug be buggy in 3.16? And Xen triggers this bug after 5
> minutes even without doing any 'xl vcpu-set'?

The MCE polling timer for each CPU runs every 5 minutes, so this is
presumably the first time it runs.  Perhaps this domain is configured
such that CPUs are hot-removed shortly after boot?

In the first crash, it looks like the timer for CPU x!=0 is being
called on CPU 0.  In general this can happen if CPU x is hot-removed;
its timers are migrated to another CPU.  This should *not* be possible
with the MCE timer, as there is a hotplug callback that removes the
timer when a CPU is removed.  There is a check for the timer having
been migrated anyway, which triggers the WARNING.  The timer function
then tries to re-add the timer for the current CPU, but that's still
pending, which triggers the BUG.  Either the hotplug callback was not
called, or the timer was migrated before being removed resulting in a
race condition.

> With "maxvcpus" set larger "vcpus", xl vcpu-set seems to work most of
> the time (between 1 and 16 vcpus), but after several tries, I got the
> attached trace.

I'm not sure what's going on in this crash, but as it's a null
dereference in migrate_timer_list it seems somewhat related.

I didn't find any changes that would explain how this was fixed between
4.0 and 4.2.  I suggest you work around it by adding 'nomce' to the
kernel command line as I would expect Xen or dom0 to handle MCEs.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Bug#721976: (no subject)

[Jacob Hoffman-Andrews]

Hi! Any updates on this? Thanks!

Bug#860520: Voting for TC Chair

[Keith Packard]

Didier 'OdyX' Raboud  writes:

> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> ===END===

I vote:

B > A = C = D = E = F > G

-- 
-keith


signature.asc
Description: PGP signature

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Hi,
- car...@debian.org wrote:

> Hi Lars,
> 
> On Wed, Apr 19, 2017 at 04:26:30AM -0700, Lars Tangvald wrote:
> > Hi,
> > 
> > 
> > We've prepared and tested the update to MySQL 5.5.55 for Jessie.
> > Debdiff output is attached.
> > Only packaging changes are one refreshed patch and one that is no
> > longer needed (5.5.54 for Wheezy had an additional patch added,
> > which is also no longer needed).
> 
> Thanks for preparing the update.
> 
> CVE-2017-3302 is as well know nin BTS as #854713, can you add a bug
> closer for
> this one as well? If it's too much of hassle, then leave it, and we
> close it
> manually.
> 
> Ok, please upload to security-master.
> 
> Regards,
> Salvatore

Ah right, that's the bug for the patch in the Wheezy 5.5.54 packages. I'll add 
it.

--
Lars

Bug#860758: Note in mdadm.conf that the initramfs has its own copy

[Anthony DeRobertis]

Package: mdadm
Version: 3.4-4+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems that not everyone knows that the initramfs keeps its own copy
of mdadm.conf and thus you often need to run update-initramfs after
editing /etc/mdadm/mdadm.conf.

I think a comment in the file would help with that. The mdadm.conf(5)
man page doesn't appear to mention it either.

Not being aware of this breaks people's systems, e.g.,:

https://unix.stackexchange.com/questions/359952/md-raid-fails-on-first-boot-of-the-day

https://unix.stackexchange.com/questions/210416/new-raid-array-will-not-auto-assemble-leads-to-boot-problems

https://unix.stackexchange.com/questions/165959/degraded-raid1-array-boots-with-one-drive-not-with-the-other
 (possibly)

https://unix.stackexchange.com/questions/23879/using-mdadm-examine-to-write-mdadm-conf
 (RHEL)

Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start

[Tuxicoman]

Everyone who want to send audio to an bluetooth receiver will face this
issue.

Can we at least include the workaround from the wiki https://wiki.debia
n.org/BluetoothUser/a2dp

In order to prevent GDM from capturing the A2DP sink on session start,
edit /var/lib/gdm3/.config/pulse/client.conf (or create it, if it
doesn't exist):

autospawn = no
daemon-binary = /bin/true

After that you have to grant access to this file to Debian-gdm user:

# chown Debian-gdm:Debian-gdm /var/lib/gdm3/.config/pulse/client.conf

Bug#860757: RM: jsonbot -- RoQA; RC-buggy and (un)-maintained by QA; not in jessie or stretch

[Paul Gevers]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While going through RC bugs of packages maintained by QA, I noticed that
jsonbot has an RC bug open since 2011 and is orphaned since 2014 without
anybody stepping up to fix the situation.

The package isn't in Jessie or Stretch, I think it is best to remove the
package.

Paul

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlj3tuEACgkQnFyZ6wW9
dQoQTggAzgf0PK/I1byaq362Dd7HCr4gfEIK2hKOgNlMEBDHmpjbVpAz00BfhTiN
DlMicI0TvV68Ur0Jpg4iGOF2TyfA6FlKvNXT5pvZ6mfFS/36WJ99g5ycOK8LXndi
MUJ1mwCJQT30Vh0oVborEBWUZZcrvDvQBC+pEqWDmRyKdTChsgiZmxNjLqm/4d9V
stRIuPYL2DUQiGGN+cf5TnTcMuMjY5gvn9NtxXPfhLd9QOxOrXIN4tuvVG5in6Vd
y/AVitm4+S+w+6piO4BNJ6yg6EOHu7rlL+wS+zGYpCDECBCcU9azi1bCL5PY8fU8
MV/XKOKQSlDUnKsJKlhQnyeQ09VI9w==
=uEGj
-END PGP SIGNATURE-

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

[Heinrich Schuchardt]

On 03/19/2017 09:44 PM, Vagrant Cascadian wrote:
> On 2017-03-19, Vagrant Cascadian wrote:
>> On 2017-03-17, Martin Michlmayr wrote:
>>> * Heinrich Schuchardt  [2017-03-18 02:39]:
 U-Boot 2017-3 does not contain MMC support for the Odroid
 C2. I have seen a recent patch series for MMC support. But I
 did not yet build with it.
>>> 
>>> If they are accepted for 2017.05, maybe Vagrant could add them
>>> to the 2017.03 Debian package.
>> 
>> I also have an odroid-c2 I'd like to get working... I'd be happy
>> to look into it! Do you have a link to the patchset for MMC
>> support?
> 
> Found the v6 series, which needs some minor fixes and people to
> test it:
> 
> https://lists.denx.de/pipermail/u-boot/2017-February/thread.html#28194
3
>
> 
https://lists.denx.de/pipermail/u-boot/2017-March/282944.html
> https://lists.denx.de/pipermail/u-boot/2017-March/283633.html 
> https://lists.denx.de/pipermail/u-boot/2017-March/283634.html
> 
> But otherwise sounds promising...
> 
> 
> live well, vagrant
> 
The patch series is inside 2017.05-rc2.

You additionally need:

https://patchwork.ozlabs.org/patch/751082/
[U-Boot,v3,1/1] meson: gxbb: enable MMC as boot target

https://patchwork.ozlabs.org/patch/750920/
[U-Boot,v2,1/1] meson: gxbb: change ramdisk_addr_r

Best regards

Heinrich Schuchardt