Bug#751121: Please fix "FIXME" statements in copyright file

2015-11-18 Thread Emilio Pozuelo Monfort
On Tue, 10 Jun 2014 16:40:39 +0200 Luca Falavigna  wrote:
> Source: netatalk
> Version 2.2.2-1
> Severity: serious
> Tags: jessie sid
> 
> 
> Your debian/copyright file contains lots of FIXMEs.
> 
> For example there is an entry for
>   distrib/initscripts/rc.atalk.suse.tmpl
> but this file does not exist. The corresponding file
>   distrib/initscripts/rc.atalk.suse-sysv.tmpl
> contains just the line:
>  Copyright (c) 1996-2001 SuSE GmbH Nuernberg, Germany.  All rights reserved.
> How do you know that Debian is allowed to distribute it?

netatalk-3.1.7 ships rc.suse.tmpl, which no longer contains that sentence.

However I found a couple of files with similar sentences and no further 
licensing:

include/atalk/dsi.h
include/atalk/server_child.h

Those say:

 * Copyright (c) 1997 Adrian Sun (a...@zoology.washington.edu)
 * All rights reserved.

Everything else is either appropriately licensed, generated file, or contains no
claims at all.

Cheers,
Emilio



Bug#805481: Not limited to virtualization

2015-11-18 Thread Marc Zyngier

Unfortunately, this bug is not limited to virtualized environments.

Having thoughtlessly "upgraded my" Seattle box to systemd 227, the box 
died a horrible death very early on.


Gone back to 215 for the time being...

M.
--
Who you jivin' with that Cosmik Debris?



Bug#749029: screenkey: cannot enter Preferences, screenkey hangs

2015-11-18 Thread Torsten Paul
Package: screenkey
Version: 0.2-2
Followup-For: Bug #749029

I have the same issue on Debian/testing, updated 2015-11-18.

The following patch solves the issue for me:

https://bugs.launchpad.net/screenkey/+bug/756346
-> 00051-Fix-thread-synchronizations--.patch

ciao,
  Torsten.



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

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

Versions of packages screenkey depends on:
ii  python 2.7.9-1
ii  python-gtk22.24.0-4
ii  python-xlib0.14+20091101-5
ii  python2.7  2.7.10-5+b1
ii  x11-xserver-utils  7.7+5

screenkey recommends no packages.

screenkey suggests no packages.

-- no debconf information



Bug#805481: One important omission

2015-11-18 Thread Steven Capper
On 18 November 2015 at 17:20, Michael Biebl  wrote:

> Hi Steve,
>
> Am 18.11.2015 um 16:52 schrieb Steven Capper:
> > I neglected to mention that this running under a QEMU virtual machine
> (same
> > error for both KVM acceleration on and off).
> >
> > I will dig into this a little bit here and will update if I find
> anything.
>
> Can you pinpoint the version when this started failing?
> As a start you could pull the snapshots from [1]
>
> To make debugging easier, you can keep the old sysvinit binary around
> (assuming you have a working /etc/inittab). This way you can easily boot
> into the system via the grub menu.
>
> Regards,
> Michael
>

Thanks Michael,
I didn't know about snapshots.

I pulled down:
libsystemd0 226-4
systemd 226-4

That was then sufficient to boot the machine without issue.

Upgrading to 227-1 caused immediate segfaults and led to the same
unbootable machine.

So it looks like something introduced 227-1.

Cheers,
--
Steve


>
>
> [1] http://snapshot.debian.org/
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>


Bug#805463: quassel-client: missing dependancy to phonon4qt5-backend-gstreamer

2015-11-18 Thread Felix Geyer
Hi,

On 18.11.2015 13:24, Louis Bouchard wrote:
> Package: quassel-client
> Version: 0.12.2-2
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> quassel-client sound notifications do not work unless
> phonon4qt5-backend-gstreamer package is added.  It should
> be added as a dependancy, or at least a Recommends:

quassel-client already depends on phonon4qt5-backend-vlc | phonon-backend 
through phonon4qt5.
phonon4qt5-backend-vlc is the default backend.
There is no reason why quassel would need a specific backend.

Cheers,
Felix



Bug#805481: One important omission

2015-11-18 Thread Martin Pitt
Hello,

Steven Capper [2015-11-18 15:52 +]:
> I neglected to mention that this running under a QEMU virtual machine (same
> error for both KVM acceleration on and off).

As a data point: I can boot arm64 instances in our cloud, and systemd
225 on Linux 4.2.0 works fine. But I don't know which kind of host
system that is. I'll try 227 on it tomorrow.

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



Bug#442937: Annoying error: .aptitude is readable but not writable; unable to write configuration file.

2015-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


Hi Trent,

2007-09-18 00:48 Trent W. Buck:

Package: aptitude
Version: 0.4.6.1-1
Severity: wishlist

I invoke aptitude with "sudo aptitude" instead of "sudo -H aptitude"
so my .aptitude/config will be read (instead of root's).

The /home filesystem is an NFS mount with -o root_squash, so root can
read from but not write to ~/.aptitude:

   $ stat -L ~/.aptitude
 File: `/home/twb/.aptitude'
 Size: 4096Blocks: 8  IO Block: 32768  directory
   Device: 15h/21d Inode: 8702031 Links: 2
   Access: (0750/drwxr-x---)  Uid: ( 1187/ twb)   Gid: ( 2000/   cyber)
   Access: 2007-09-18 09:23:14.0 +1000
   Modify: 2007-09-17 05:46:40.0 +1000
   Change: 2007-09-17 05:46:40.0 +1000

Thus, every time aptitude (in GUI mode) starts up it complains:

   E: /home/twb/.aptitude is readable but not writable; unable to
   write configuration file.

This is annoying.  I don't really want to give all users write access
to ~/.aptitude.  I don't want to copy ~/.aptitude to each host's
~root/.aptitude; it would be tedious and probably irritate other
admins who prefer different configuration.  (This is the same argument
against customizing root in other ways, such as changing the default
shell to csh.)

Instead I would like to be able to configure aptitude (via
~/.aptitude/config) to defer reporting this "error" until it actually
needs to modify ~/.aptitude, which in my case will be never because I
have already configured aptitude to my liking.


This has been fixed now, it will be present in the next release, marking
as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#805488: pristine-tar: Does not efficiently compress gzip --rsyncable, dpkg's default

2015-11-18 Thread Geoffrey Thomas

Package: pristine-tar
Version: 1.33
Severity: important

(This bug may be a duplicate of other ones filed against pristine-tar; I 
haven't yet investigated their cause.)


pristine-tar seems not to know how to efficiently re-compress files 
compressed by gzip --rsyncable on both Jessie and Sid (which have gzip 
1.6-4). From a Sid chroot:


$ gunzip pristine-tar_1.33.tar.gz
$ gzip --rsyncable pristine-tar_1.33.tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz; 
storing 80% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)

No such error happens if you leave off --rsyncable.

In fact, this happens on the unmodified tarball of pristine-tar itself 
(versions 1.31, 1.32, and 1.33, but not older versions):


$ apt-get source --download-only pristine-tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz; 
storing 86% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)

I noticed this because uscan's repack mode calls mk-origtargz, which uses 
Debhelper::Compression, which uses Dpkg::Compression, which passes 
--rsyncable by default. From /usr/lib/perl5/Dpkg/Compression.pm:


gzip => {
file_ext => 'gz',
comp_prog => [ 'gzip', '--no-name', '--rsyncable' ],
decomp_prog => [ 'gunzip' ],
default_level => 9,
},

So I bet this affects a number of packages. For instance, this is how 
pristine-tar's own native tarballs were made:


$ gunzip < pristine-tar_1.33.tar.gz | gzip -9 --no-name --rsyncable | diff -s - 
pristine-tar_1.33.tar.gz
Files - and pristine-tar_1.33.tar.gz are identical

The changelog entry for pristine-tar 1.14 (August 2011) implies that it's 
supposed to support the --rsyncable option already, but perhaps since 
then, the gzip format has changed.


--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com



Bug#520260: aptitude: Should not rewrite config file unless settings have changed.

2015-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


Hi Benjamin,

2009-03-18 12:46 Benjamin M. A'Lee:

Package: aptitude
Version: 0.4.11.11-1~lenny1
Severity: wishlist

On starting aptitude, ~/.aptitude/config is rewritten. As I keep my home
directory under version control, this means it shows up as modified,
even though all that has changed is the order/layout of the options in
the file.

Would it be possible for aptitude to rewrite the config only when
options have been changed?


Thanks for the report.  This has been fixed now, marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#407284: Is ~.aptitude really neaded ?

2015-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


Hi Fabrice,

2007-01-17 11:37 Fabrice LORRAIN:

Package: aptitude
Version: 0.4.4-1
Severity: normal


Hello,

Related to BTS #272409.
Pb detected on a fresh etch installation (aptitude-0.4.4-1) but reported
from a sarge box. The package dependencies attached by reportbug is
uncorrect.

# cd /root ; rm -fr .aptitude; LANG=C aptitude clean; ls -lisa .aptitude
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
total 8
32577 4 drwx-- 2 root root 4096 2007-01-17 12:31 .
32579 4 drwxr-xr-x 5 root root 4096 2007-01-17 12:31 ..
32589 0 -rw-r--r-- 1 root root0 2007-01-17 12:31 config

Is there any usfullness in creating an empty config file when
aptitude is used ?

Reading through aptitude changelog attached to #272409, I'm even wondering if
creating .aptitude is usfull at all ?


Thanks for your report.  A fix for this is commited, empty files are not
not saved (or removed if found), and same for the directory.

It will be present in the next release, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#805295: [Pkg-octave-devel] Bug#805295: octave: Plot to file without X display does not work

2015-11-18 Thread Rafael Laboissiere

Control: tags -1 confirmed upstream

* Mike Miller  [2015-11-18 05:24]:


On Mon, Nov 16, 2015 at 18:43:46 +0100, Djalil Chafai wrote:



consider the following code stored in file plotest.m

# begin 
graphics_toolkit('gnuplot') 
set(0, 'defaultfigurevisible', 'off'); 
plot(sin(1:100)); 
print("plotest.jpg", "-djpg") 
# end


bash> export DISPLAY= 
bash> octave plotest.m


The image file plotest.jpg contains a fully black figure. It should not.


Agreed, this is due to an interaction between Octave and gnuplot v5.

[snip]

Upstream bug report for fixing interaction with gnuplot v5 is at 
https://savannah.gnu.org/bugs/?42838.


Thanks for the replay, Mike.  I am hereby tagging this bug report 
accordingly.


Rafael



Bug#805399: Appears to normally send debug logs to ~/.xsession-errors, not really welcome there either.

2015-11-18 Thread Anthony DeRobertis
Package: kded5
Version: 5.15.0-1
Followup-For: Bug #805399

It appears when it's first started, kded5 dumps that debug log to
~/.xsession-errors, not syslog. That's much better, but still a huge
waste of disk space—especially since that log isn't rotated until
logout/login (which is often months).

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

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

Versions of packages kded5 depends on:
ii  libc6  2.19-22
ii  libkf5configcore5  5.15.0-1
ii  libkf5coreaddons5  5.15.0-1
ii  libkf5crash5   5.15.0-1
ii  libkf5dbusaddons5  5.15.0-1
ii  libkf5service-bin  5.15.0+-1
ii  libkf5service5 5.15.0+-1
ii  libqt5core5a   5.5.1+dfsg-6
ii  libqt5dbus55.5.1+dfsg-6
ii  libqt5gui5 5.5.1+dfsg-6
ii  libqt5widgets5 5.5.1+dfsg-6
ii  libstdc++6 5.2.1-23

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Stefan Ahlers
Hi,

I tried to fix most of the points. I replaced my patch with a applied
upstream patch. One of the symbol files had a wrong file name. This
should be fixed, too.

I'm not sure what I have to add for upstream metadatas and I do not know
what to do with the output of

flawfinder -Q -c .


Please let me know what I should do next.

Kindly regards,
Stefan Ahlers



Bug#805481: One important omission

2015-11-18 Thread Michael Biebl
Hi Steve,

Am 18.11.2015 um 16:52 schrieb Steven Capper:
> I neglected to mention that this running under a QEMU virtual machine (same
> error for both KVM acceleration on and off).
> 
> I will dig into this a little bit here and will update if I find anything.

Can you pinpoint the version when this started failing?
As a start you could pull the snapshots from [1]

To make debugging easier, you can keep the old sysvinit binary around
(assuming you have a working /etc/inittab). This way you can easily boot
into the system via the grub menu.

Regards,
Michael


[1] http://snapshot.debian.org/
-- 
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#805489: bluez: incomplete setup when pairing with Logitech K380 keyboard

2015-11-18 Thread Patrick C
Package: bluez
Version: 5.23-2+b1
Severity: normal

Dear Maintainer,

New Logitech K380 keyboard. Bluetooth would pair with it, but not
correctly and/or not connect. Tried via KDE/bluedevil,
Gnome/gnome-bluetooth, bluetoothctl. The
file /var/lib/bluetooth///info was
created, but the [LinkKey] section was missing, no matter what
interface I used to pair, so no "Key=" or "Type=" entries. (Also, the
info file created via bluedevil had more entries than the version
created via Gnome, which was minimal). Setting "Trusted=true" in that
file did not fix the problem. As a workaround I did the following: boot
windows8.1, pair the keyboard (no problems), go into the registry and
find the 16 byte key value, then in debian manually add "[LinkKey]"
line and "Key=" and "Type=4" and "PINLength=0" entries
in the info file, then after that it has worked fine.

Note I also am using a bluetooth mouse with the same system, had no
problems pairing it with debian, and used its info file as a model for
the keyboard one. When the mouse was paired, the debian version was the
same, have only had a few updates since then not related to bluetooth.

Maybe relevant: this particular keyboard has 3 buttons to remember
separate pairings with 3 different devices. Same problem no matter
which button I used to pair it, and if I had it paired with windows on
button 1, then an unsuccessful pairing with debian on button 2 would
affect the button 1 pairing somehow so that windows would say it was
paired but wouldn't connect (had to remove/re-pair).

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

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

Versions of packages bluez depends on:
ii  dbus 1.8.20-0+deb8u1
ii  init-system-helpers  1.22
ii  kmod 18-3
ii  libc62.19-18+deb8u1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libglib2.0-0 2.42.1-1
ii  libreadline6 6.3-8+b3
ii  libudev1 215-17+deb8u2
ii  lsb-base 4.1+Debian13+nmu1
ii  udev 215-17+deb8u2

bluez recommends no packages.

bluez suggests no packages.



Bug#805487: sysvinit: consider moving invoke-rc.d, update-rc.d and service to src:init-system-helpers

2015-11-18 Thread Michael Biebl
Am 18.11.2015 um 17:32 schrieb Andreas Henriksson:
> One idea that has been tossed around is to put them in
> src:init-system-helpers which is already a source for
> init-system-agnostic utilities.
> 
> I asked Petter Reinholdtsen on IRC about this and he said that he
> doesn't care much about which git repository the scripts live in, while
> also citing that he's not to be considered a sysvinit authority[1].

I briefly discussed that during debconf 15 where hmh, one of the
(former) sysvinit maintainers, was present and IIRC he wasn't averse to
the idea.

-- 
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#504152: aptitude: leaves empty ~/.aptitude/config on exit

2015-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


2008-11-01 07:58 Paul Wise:

Package: aptitude
Version: 0.4.11.10-1lenny1.1
Severity: normal

aptitude leaves an empty ~/.aptitude/config file behind on exit which is
annoying for people like me who detest cruft and aim to destroy it.

Please make aptitude remove ~/.aptitude/config when it is empty and
remove ~/.aptitude/ when there is no config file there and no other
files there.


Thanks, fix commited and marked as +pending.

--
Manuel A. Fernandez Montecelo 



Bug#805479: ITP: networking-ovs-dpdk -- OpenStack virtual network service - Open vSwitch DPDK ML2 mechanism driver

2015-11-18 Thread James Page
Package: wnpp
Severity: wishlist
Owner: James Page 

* Package name: networking-ovs-dpdk
  Version : 2015.1.1 (+ snapshot for now)
* URL : http://github.com/openstack/networking-ovs-dpdk
* License : Apache 2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - Open vSwitch DPDK ML2 
mechanism driver

 This package provides the Python files for the Open vSwitch DPDK ML2
 mechanism driver, providing fast userspace packet processing for cloud
 instances.

 This package will be maintained under the OpenStack packaging team.



Bug#805482: CPU: 0 PID: 0 at /usr/src/packages/BUILD/linux-3.18.5/net/core/skbuff.c:3995

2015-11-18 Thread Yuri Henrique Sierakowski
Package: tech-ctte
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
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)

This is the bug found on dmesg message 

[  448.868520] [ cut here ]
[  448.873377] WARNING: CPU: 0 PID: 0 at 
/usr/src/packages/BUILD/linux-3.18.5/net/core/skbuff.c:3995 
skb_try_coalesce+0x354/0x3b0()
[  448.885292] Modules linked in: nf_log_ipv4 nf_log_common xt_recent 
iptable_nat nf_nat_ipv4 xt_comment ipt_REJECT nf_reject_ipv4 xt_addrtype 
xt_mark iptable_mangle xt_tcpudp xt_CT iptable_raw xt_multiport 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack xt_NFLOG xt_LOG nf_nat_tftp 
nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre 
nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda 
nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip 
nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp 
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp 
nf_conntrack iptable_filter ip_tables x_tables nfnetlink_queue nfnetlink_log 
nfnetlink bluetooth rfkill cpufreq_stats
[  448.959607]  dm_mod uas snd_soc_pcm512x_i2c snd_soc_pcm512x snd_soc_wm8804 
snd_soc_tas5713 regmap_spi regmap_i2c snd_soc_bcm2708_i2s regmap_mmio 
snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer i2c_bcm2708 
spi_bcm2708 snd sg
[  448.980286] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-trunk-rpi2 #1 
Debian 3.18.5-1~exp1.co1
[  448.989576] [<80018a44>] (unwind_backtrace) from [<80013cf4>] 
(show_stack+0x20/0x24)
[  448.997541] [<80013cf4>] (show_stack) from [<806474e8>] 
(dump_stack+0x9c/0xd4)
[  449.005004] [<806474e8>] (dump_stack) from [<8002aa08>] 
(warn_slowpath_common+0x84/0xa0)
[  449.030358] [<8002aa08>] (warn_slowpath_common) from [<8002aae0>] 
(warn_slowpath_null+0x2c/0x34)
[  449.074655] [<8002aae0>] (warn_slowpath_null) from [<80516648>] 
(skb_try_coalesce+0x354/0x3b0)
[  449.119790] [<80516648>] (skb_try_coalesce) from [<805736b4>] 
(tcp_try_coalesce.part.36+0x38/0xbc)
[  449.164953] [<805736b4>] (tcp_try_coalesce.part.36) from [<80574f7c>] 
(tcp_data_queue+0x7a0/0xc8c)
[  449.210206] [<80574f7c>] (tcp_data_queue) from [<80576e2c>] 
(tcp_rcv_established+0x148/0x618)
[  449.255282] [<80576e2c>] (tcp_rcv_established) from [<80580084>] 
(tcp_v4_do_rcv+0x14c/0x380)
[  449.300361] [<80580084>] (tcp_v4_do_rcv) from [<80582ef8>] 
(tcp_v4_rcv+0x988/0xa5c)
[  449.344416] [<80582ef8>] (tcp_v4_rcv) from [<8055c970>] 
(ip_local_deliver_finish+0xf0/0x2d8)
[  449.389467] [<8055c970>] (ip_local_deliver_finish) from [<8055d0bc>] 
(ip_local_deliver+0x48/0xa8)
[  449.434897] [<8055d0bc>] (ip_local_deliver) from [<8055ccbc>] 
(ip_rcv_finish+0x164/0x3ec)
[  449.479599] [<8055ccbc>] (ip_rcv_finish) from [<8055d48c>] 
(ip_rcv+0x370/0x498)
[  449.505341] [<8055d48c>] (ip_rcv) from [<80521a2c>] 
(__netif_receive_skb_core+0x688/0x89c)
[  449.549888] [<80521a2c>] (__netif_receive_skb_core) from [<805241dc>] 
(__netif_receive_skb+0x20/0x70)
[  449.596114] [<805241dc>] (__netif_receive_skb) from [<80525b48>] 
(process_backlog+0xb0/0x170)
[  449.641647] [<80525b48>] (process_backlog) from [<80525950>] 
(net_rx_action+0x17c/0x2c4)
[  449.686739] [<80525950>] (net_rx_action) from [<8002e928>] 
(__do_softirq+0x1a8/0x3cc)
[  449.731503] [<8002e928>] (__do_softirq) from [<8002eed0>] 
(irq_exit+0xd0/0x114)
[  449.757400] [<8002eed0>] (irq_exit) from [<800793a0>] 
(__handle_domain_irq+0x98/0xdc)
[  449.801817] [<800793a0>] (__handle_domain_irq) from [<8000854c>] 
(asm_do_IRQ+0x2c/0x30)
[  449.846339] [<8000854c>] (asm_do_IRQ) from [<8064ce34>] 
(__irq_svc+0x34/0x14c)
[  449.871933] Exception stack(0x8098bf00 to 0x8098bf48)
[  449.895217] bf00: ffed  ffed  8098a000  
809a9e1c 
[  449.939514] bf20:  809a9db8 80a096dc 8098bf54 809aad78 8098bf48 
80010840 80010844
[  449.983694] bf40: 6013 
[  450.004809] [<8064ce34>] (__irq_svc) from [<80010844>] 
(arch_cpu_idle+0x34/0x4c)
[  450.047254] [<80010844>] (arch_cpu_idle) from [<80064308>] 
(cpu_startup_entry+0x318/0x3c0)
[  450.090733] [<80064308>] (cpu_startup_entry) from [<806450ec>] 
(rest_init+0x94/0x98)
[  450.133936] [<806450ec>] (rest_init) from [<80914d74>] 
(start_kernel+0x410/0x41c)
[  450.176727] ---[ end trace b01db0027a07bf4f ]---



Bug#802899: nautilus: The option to delete files (without passing by "Trash") has disappeared

2015-11-18 Thread Michel Le Bihan
I reported this issue upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=757375



signature.asc
Description: OpenPGP digital signature


Bug#805474: apt-doc: [INTL:nl] Dutch po file for the apt package's documentation

2015-11-18 Thread Frans Spiesschaert
Hi Jakub,


Jakub Wilk schreef op wo 18-11-2015 om 16:04 [+0100]:
> Hi Frans!
> 
> * Frans Spiesschaert , 2015-11-18, 15:46:
> >Please find attached the Dutch po file for the apt package's 
> >documentation.
> 
> This XML fragment:
> 
> "Een minder vaak voorkomende situatie is die waarbij de geïnstalleerde versie 
> "
> "van een pakket recenter is dan welke andere beschikbare 
> "
> "versie ook. Bij het uitvoeren van de opdracht apt-get install "
> "een-bepaald-pakket of apt-get "
> "upgrade zal het pakket dan niet gedegradeerd worden."
> 
> is not well-formed. There's closing  in the one-but-last line, 
> but no corresponding opening .


This is how it should read:

"Een minder vaak voorkomende situatie is die waarbij de geïnstalleerde versie "
"van een pakket recenter is dan welke andere beschikbare "
"versie ook. Bij het uitvoeren van de opdracht apt-get install "
"een-bepaald-pakket of apt-get "
"upgrade zal het pakket dan niet gedegradeerd worden."


Would you like me to send you a corrected file?


> 
> You might want to check your PO files with i18nspector, which is how I 
> found this bug. :)
> 

Thanks for the helpful suggestion.

-- 
Cheers,
Frans

===
http://www.frans-spiesschaert.homenet.org
http://home.base.be/vt6362833/



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


Bug#805487: sysvinit: consider moving invoke-rc.d, update-rc.d and service to src:init-system-helpers

2015-11-18 Thread Andreas Henriksson
Source: sysvinit
Version: 2.88dsf-59
Severity: normal

Dear Maintainer,

I'd like to see the following three scripts moved out of src:sysvinit
and into a init-system-agnostic package:
invoke-rc.d, update-rc.d and service

*-rc.d currently lives in sysv-rc (binary package)
service in sysvinit-utils (binary package)

None of them are really tied to sysvinit.

One idea that has been tossed around is to put them in
src:init-system-helpers which is already a source for
init-system-agnostic utilities.

I asked Petter Reinholdtsen on IRC about this and he said that he
doesn't care much about which git repository the scripts live in, while
also citing that he's not to be considered a sysvinit authority[1].

Martin Pitt commented that both pkg-systemd and sysvinit maintainers
should be able to commit, but this is already possible since
init-system-helpers is maintained in collab-maint where all DDs (+more)
have commit access already. (I'm maintly mentioning this so that
everyone is aware of this "invitation" to continue (co-)maintaining the
scripts where ever they end up residing.)

Unless there are any objections I'll consider working on making this
happen (so please speak up if you object to it!... or are willing to
help).

Apart from just making sure the handover is done correctly I don't see
much possibility of major issues. There's one thing to note and that's
file-rc shipping their own *-rc.d versions (incompatible with systemd).
>From a quick look it seems file-rc uses Replaces: to overwrite the files
but has no matching Conflicts, Breaks or Depends which I wonder if it's
policy compliant. This is not a practical problem though since sysv-rc
nicely saves it by conflicting the other way around. For my first
attempt I'll probably not consider file-rc more then just using a
Conflicts: file-rc, since it has very low popcon (<100 install, even
less vote). We can then improve the situation later... (investigating
why/if file-rc really needs their own versions, switch file-rc to
divert, or whatever ends up being the best solution.)

(Fwiw, please note that I'm not the maintaining any of the involved
packages.)


Regards,
Andreas Henriksson


[1]:
http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2012-May/006033.html


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

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

-- no debconf information



Bug#805474: apt-doc: [INTL:nl] Dutch po file for the apt package's documentation

2015-11-18 Thread Jakub Wilk

Hi Frans!

* Frans Spiesschaert , 2015-11-18, 15:46:
Please find attached the Dutch po file for the apt package's 
documentation.


This XML fragment:

"Een minder vaak voorkomende situatie is die waarbij de geïnstalleerde versie "
"van een pakket recenter is dan welke andere beschikbare "
"versie ook. Bij het uitvoeren van de opdracht apt-get install "
"een-bepaald-pakket of apt-get "
"upgrade zal het pakket dan niet gedegradeerd worden."

is not well-formed. There's closing  in the one-but-last line, 
but no corresponding opening .


You might want to check your PO files with i18nspector, which is how I 
found this bug. :)


--
Jakub Wilk



Bug#805478: gauche-doc does not contain info files

2015-11-18 Thread Frank Zappa
Package: gauche-doc
Version: 0.9.4-3

The gauche-doc package does not contain the info files, only the changelogs
and copyright:

$ cat /etc/debian_version
8.2

$ dpkg -L gauche-doc
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/gauche-doc
/usr/share/doc/gauche-doc/changelog.gz
/usr/share/doc/gauche-doc/copyright
/usr/share/doc/gauche-doc/changelog.Debian.gz

$ dpkg -s gauche-doc
Package: gauche-doc
Status: install ok installed
Priority: optional
Section: doc
Installed-Size: 228
Maintainer: Debian Gauche Maintainers <
pkg-gauche-de...@lists.alioth.debian.org>
Architecture: all
Source: gauche
Version: 0.9.4-3
Description: Reference manual of Gauche
 Gauche is a Scheme implementation developed to be a handy script
 interpreter, which allows programmers and system administrators to
 write small to large scripts for their daily chores. Quick startup,
 built-in system interface, native multilingual support are some of
 the author's goals.
 .
 This package contains info documents of the reference manual of Gauche
 (English, Japanese).
Homepage: http://practical-scheme.net/gauche/


Bug#805481: systemd 227-2 SIGSEGV on boot on arm64

2015-11-18 Thread Steven Capper
Package: systemd
Version: 227-2
Severity: grave
Justification: renders package unusable



-- Package-specific info:

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

Kernel: Linux 4.2.0-1-arm64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27.1-1
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 227-2
ii  mount   2.27.1-1
ii  sysv-rc 2.88dsf-59.2
ii  udev227-2
ii  util-linux  2.27.1-1

Versions of packages systemd recommends:
ii  dbus1.10.2-1
pn  libpam-systemd  

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

-- no debconf information


-- more information

systemd immediately fails on arm64 with a SIGSEGV rendering the system
unbootable.

I have booted up with init=/bin/bash and tried running system mode in gdb
to try and narrow down the problem:

Program received signal SIGSEGV, Segmentation fault.
0x005ac868 in detect_vm () at ../src/basic/virt.c:263
263if (cached_found >= 0)

(gdb) list
258 /* Returns a short identifier for the various VM implementations */
259 int detect_vm(void) {
260static thread_local int cached_found = _VIRTUALIZATION_INVALID;
261int r;
262
263if (cached_found >= 0)
264return cached_found;
265
266/* Try xen capabilities file first, if not found try
267 * high-level hypervisor sysfs file:

(gdb) disassemble $pc
Dump of assembler code for function detect_virtualization:
   0x005ac848 <+0>: str x30, [sp,#-16]!
   0x005ac84c <+4>: bl 0x5ac680 
   0x005ac850 <+8>: cbnz w0, 0x5ac870 
   0x005ac854 <+12>: mrs x1, tpidr_el0
   0x005ac858 <+16>: adrp x0, 0x698000 
   0x005ac85c <+20>: ldr x2, [x0,#960]
   0x005ac860 <+24>: nop
   0x005ac864 <+28>: nop
=> 0x005ac868 <+32>: ldr w0, [x1,x0]
   0x005ac86c <+36>: tbnz w0, #31, 0x5ac878

   0x005ac870 <+40>: ldr x30, [sp],#16
   0x005ac874 <+44>: ret
   0x005ac878 <+48>: ldr x30, [sp],#16
   0x005ac87c <+52>: b 0x5ac388 
End of assembler dump.

(gdb) info registers
x0 0x698000 366505197568
x1 0x7fb7bea6f0 548543571696
x2 0x14 20
x3 0x7fee80 549755809408
x4 0x1 1
x5 0x0 0
x6 0x8000 140737488355328
x7 0x1 1
x8 0x42 66
x9 0x711f33356bff284d 8151290155102054477
x100x7f7f7f7f7f7f7f7f 9187201950435737471
x110x101010101010101 72340172838076673
x120x10 16
x130x20504d4f43434553 2328446010176783699
x140x2d2044494b4c422b 3251674012548088363
x150x7fb7e28588 548545922440
x160x698498 366505198744
x170x7fb7d5b2fc 548545082108
x180x7ff8e0 549755812064
x190x69c320 366505214752
x200x699000 366505201664
x210x69a000 366505205760
x220x69b320 366505210656
x230x699000 366505201664
x240x0 0
x250x699000 366505201664
x260x7ffd28 549755813160
x270x698000 366505197568
x280x69c3db 366505214939
x290x7ff820 549755811872
x300x5ac850 366504233040
sp 0x7ff800 0x7ff800
pc 0x5ac868 0x5ac868 
cpsr   0x0 0
fpsr   0x0 0
fpcr   0x100 16777216

(gdb) bt full
#0  0x005ac868 in detect_vm () at ../src/basic/virt.c:263
No locals.
#1  detect_virtualization () at ../src/basic/virt.c:410
r = 
#2  0x0057f588 in main (argc=0, argv=0x7ffd38) at
../src/core/main.c:1570
v = 
m = 0x0
r = 
retval = 1
before_startup = 
after_startup = 
timespan = '\000' ,
"\060\372\267\177\000\000\000(\321\002\000\000\000\000\000
\374\377\377\177\000\000\000\000\360\374\267\177", '\000' 
fds = 0x69b320
reexecute = false
shutdown_verb = 0x0
initrd_timestamp = {realtime = 548547799504, monotonic =
548547721128}
userspace_timestamp = {realtime = 881758864, monotonic = 

Bug#805481: One important omission

2015-11-18 Thread Steven Capper
I neglected to mention that this running under a QEMU virtual machine (same
error for both KVM acceleration on and off).

I will dig into this a little bit here and will update if I find anything.

Cheers,
--
Steve


Bug#805484: ITP: pd-extendedview -- Pure Data abstractions for panoramic image creation and projection mapping with Gem

2015-11-18 Thread IOhannes m zmoelnig
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-extendedview
  Version : 0.4
  Upstream Author : Peter Venus, Marian Weger, Cyrille Henry and IEM
* URL : http://extendedview.mur.at
* License : GPL-3+
  Programming Lang: Pd
  Description : Pure Data abstractions for panoramic image creation and 
projection mapping with Gem

 Extended View Toolkit is a set of abstractions for combining multiple video or
 image sources into a panoramic image and for projection setups with mutliple
 projectors or projection environments with challenging geometric forms, better
 known as video mapping.
 .
 Multiple input media (e.g. camera input, video files, image files, 3D
 renderings) can be processed. It is possible to create imagery or video by
 either stitching multiple inputs to one continuous, or by unwrapping a
 360-degree image taken with a special optical lens system. Such processed media
 input can then be projected onto even irregular shaped surfaces. It is possible
 to blend smoothly between multiple projectors, to create seamless immersive
 media environments.

I intend to maintain this package under the pkg-multimedia-maintainers umbrella.



Bug#802899: nautilus: The option to delete files (without passing by "Trash") has disappeared

2015-11-18 Thread Michael Biebl
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=757375
Am 18.11.2015 um 16:25 schrieb Michel Le Bihan:
> I reported this issue upstream:
> https://bugzilla.gnome.org/show_bug.cgi?id=757375

Thanks Michel,
marking as forwarded.


-- 
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#805478: [Pkg-gauche-devel] Bug#805478: gauche-doc does not contain info files

2015-11-18 Thread Jens Thiele
this is already fixed in unstable
thought there already was a bug report for it - but didn't find it.

greetings,
jens



Bug#805480: posh: Should reject ++ and -- operators in arithmetic expansion

2015-11-18 Thread Kevin Locke
Package: posh
Version: 0.12.5
Severity: normal

Dear Maintainer,

SUSv3 lists the prefix and postfix ++ and -- operators as "not
required"[1] during arithmetic expansion and their use is not excepted
from the requirements of Policy 10.4.  In practice, using these
operators would be a bad idea since they are not currently supported in
dash (the postfix versions cause syntax errors while the prefix versions
are silently ignored).  An example of current behavior across shells is:

$ FOO=1 bash -c 'echo $((FOO++)) $((++FOO))'
1 3
$ FOO=1 dash -c 'echo $((FOO++))'
dash: 1: arithmetic expression: expecting primary: "FOO++"
$ FOO=1 dash -c 'echo $((++FOO)) $((++FOO))'
1 1
$ FOO=1 posh -c 'echo $((FOO++)) $((++FOO))'
1 3

I would suggest removing support for these operators from posh so that
shell scripts which rely on them can be identified and fixed.

Thanks for considering,
Kevin

1.  
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04


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

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

Versions of packages posh depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  libc6  2.19-22

posh recommends no packages.

posh suggests no packages.

-- debconf information:
  posh/sh: false



Bug#804592: stimfit: FTBFS: pystf.i:1517: Error: Unknown SWIG preprocessor directive: Check

2015-11-18 Thread Yaroslav Halchenko

On Wed, 18 Nov 2015, Christoph Schmidt-Hieber wrote:
> > so either
> > - prepare new release and target its upload to unstable

> See http://mentors.debian.net/package/stimfit

building now

> Will this also take care of the gloomy threat that stimfit 0.13.19-1 was 
> marked for autoremoval?

that one needs to be gone, new version will replace it automagically
after a bit

btw -- since you are an active swig user, any clue about

https://github.com/swig/swig/issues/563

? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik



Bug#805483: apticron: lists all FQDNs when ALL_FQDNS is set to "0"

2015-11-18 Thread Jakob Thomas
Package: apticron
Version: 1.1.57
Severity: normal
Tags: patch

Apticron lists all FQDNs in email when ALL_FQDNS is set to "0". This is because 
this option is checked with the test "-n".

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

Kernel: Linux 3.16.0-4-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)
--- apticron.old	2014-10-01 18:20:51.0 +0200
+++ apticron	2015-11-18 00:10:43.307096557 +0100
@@ -75,7 +75,7 @@
 [ -e /etc/apticron/apticron.conf ] && . /etc/apticron/apticron.conf
 
 # Force resolving and showing all FQDNs
-if [ -n "$ALL_FQDNS" ] ; then
+if [ "$ALL_FQDNS" = "1" ] ; then
 	SYSTEM=`/bin/hostname --all-fqdns`
 fi
 


Bug#805480: posh: Should reject ++ and -- operators in arithmetic expansion

2015-11-18 Thread Clint Adams
On Wed, Nov 18, 2015 at 07:06:24AM -0800, Kevin Locke wrote:
> I would suggest removing support for these operators from posh so that
> shell scripts which rely on them can be identified and fixed.

Sounds good.



Bug#805485: ITP: pd-gil -- Geometry Interaction Library for Pure Data / Gem

2015-11-18 Thread IOhannes m zmoelnig
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-gil
  Version : 0.1
  Upstream Author : Marian Weger 
* URL : https://github.com/m---w/gil
* License : GPL-3+
  Programming Lang: Pd
  Description : Geometry Interaction Library for Pure Data / Gem

 This library provides abstractions to create interactive elements
 within a 3D-environment.
 .
 Currently supported visual elements include:
 - lines
 - circles
 - polygons
 .
 Interaction is mostly clicking, selecting and drag


I intend to maintain this package under the pkg-multimedia-maintainers umbrella.
This package is a dependency for the pd-extendedview package (ITP: #805484)



Bug#799953: gcc-4.9: incorrect double to integer conversion on i386

2015-11-18 Thread Matthias Klose

On 17.11.2015 04:02, Andreas Beckmann wrote:

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323


So you are reassigning this to PR323 without lowering the severity. Does this 
mean you are addressing this issue?




Bug#799089: Blocked by Mopidy's GStreamer 1.x transition

2015-11-18 Thread Stein Magnus Jodal
block 799089 785910
thanks

Mopidy-SoundCloud does not use GStreamer directly. It only Depends on
gstreamer0.10-plugins-ugly to ensure the required codecs are installed.
As soon as Mopidy itself transitions to GStreamer 1.x and #785910 is
closed, Mopidy-SoundCloud can update its dependency and close this bug.

-- 
Stein Magnus Jodal
jo...@debian.org
jodal at #debian-python


signature.asc
Description: Digital signature


Bug#805486: ITP: pd-kollabs -- data management and state saving for Pure Data

2015-11-18 Thread IOhannes m zmoelnig
Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-kollabs
  Version : 1.0
  Upstream Author : Marian Weger 
* URL : https://github.com/m---w/kollabs
* License : GPL-3+
  Programming Lang: Pd
  Description : data management and state saving for Pure Data

 KOLLABS is an abstraction library for Pure Data, that covers data management,
 OSC-, MIDI- and DMX-communication and state saving.
 .
 The included state engine allows complex scene management as well as fully
 programmable scene transitions.

I intend to maintain this package under the pkg-multimedia-maintainers umbrella.
This package is a dependency for the pd-extendedview package (ITP: #805484)



Bug#801580: jessie-pu: package apt-offline/1.5

2015-11-18 Thread Julien Cristau
On Wed, Nov 18, 2015 at 19:56:16 +0530, Ritesh Raj Sarraf wrote:

> On Wed, 2015-11-18 at 15:03 +0100, Julien Cristau wrote:
> > The changelog doesn't seem to correspond to the actual change.  I'm
> > tempted to reject this so you can reupload with an updated changelog.
> 
> Thank you for catching that. I've attached the revised changelog.
> Please reject the previous one. It'd help if you can respond in this
> email when it is okay for me to upload.
> 
> I'll upload it after I receive the rejection email for the previous
> upload. Hope that is okay.
> 
It should be possible to reupload now.

Cheers,
Julien


signature.asc
Description: PGP signature


Bug#804187: Please upload golang-github-mattn-go-sqlite3 1.1.0_dfsg1-1

2015-11-18 Thread Alexandre Viau
Hello Tianon,

Can you please upload golang-github-mattn-go-sqlite3 1.1.0_dfsg1-1? I
have prepared it as you requested.

It is available on mentors:
 -
http://mentors.debian.net/debian/pool/main/g/golang-github-mattn-go-sqlite3/golang-github-mattn-go-sqlite3_1.1.0~dfsg1-1.dsc

If you could also tag the repository, that would be great.

Thanks,

-- 
Alexandre Viau
alexan...@alexandreviau.net




signature.asc
Description: OpenPGP digital signature


Bug#805491: no need for lsb-release build-depends anymore

2015-11-18 Thread Andreas Henriksson
Control: tags -1 + pending

Hello Daniel Baumann.

Thanks for your bug report.

On Wed, Nov 18, 2015 at 06:49:11PM +0100, Daniel Baumann wrote:
> Package: util-linux
> Severity: wishlist
> Version: 2.27.1-1
> 
> Hi,
> 
> fortunately the distro-specific part for nfs mounts in one of the
> postinst scripts is gone. now, the build-depends on lsb-release is not
> needed anymore either.

Good spotting. One question that you might be able to help me iron
out though The lsb_release command was being used in mount.preinst
which means the target system needs the lsb-release package installed.
Why is/was it a *build*-dependency? This doesn't make much sense to me.

Either way, we should probably use dpkg-vendor nowadays if need arise
so I'll look at removing the build-dependency.

Regards,
Andreas Henriksson



Bug#594481: pbuilder not resolve APTGETOPT variable

2015-11-18 Thread Mattia Rizzolo
better late than never, somebody would say...

control: tags -1 + moreinfo

On Thu, Aug 26, 2010 at 12:35:05PM +0200, Grzegorz Kolorz wrote:
> I set variable APTGETOPT=('--force-all') in my .pbuilderrc
> but when I build packages not from debian distro
> I get following errors
> 
>   E: There are problems and -y was used without --force-yes
>   E: Unrecoverable error installing build-dependencies.
>   E: pbuilder-satisfydepends failed.

On Tue, 14 Feb 2012 22:57:43 +0100 Roman Müllenschläder wrote:
> No matter what and where I set APTGETOPT to, it doen't get read by
> pbuilder-
> satisfydepends-gdebi?!
> 
> What to do?

Well, APTGETOPT is not used for dep resolving, but only for for `apt-get
install` operation outside the resolver, for the upgrade, and starting
from the next release also for `apt-get update`.

Anyway, your use case is covered in the --allow-untrusted CLI flag
(ALLOWUNTRUSTED=yes conf entry).

Otherwise have a look also at the PBUILDERSATISFYDEPENDSOPT, though
consider it's not passed directly to apt-get, but through the resolver,
which will interprer it on its own.

A possible (= haven't tested it) workaround might be to just export
APTGETOPT.


Please tell me if this is enough to solve your problem.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#805189: [Pkg-libvirt-maintainers] Bug#805189: libvirt: error: unsupported configuration: IDE controllers are unsupported for this QEMU binary or machine type

2015-11-18 Thread Guido Günther
Hi,

On Tue, Nov 17, 2015 at 10:59:13PM +0100, Aurelien Jarno wrote:
> On 2015-11-15 22:19, Guido Günther wrote:
> > On Sun, Nov 15, 2015 at 07:56:52PM +0100, Aurelien Jarno wrote:
> > > Package: libvirt-daemon
> > > Version: 1.2.21-1
> > > Severity: important
> > > 
> > > Following the upgrade from jessie to sid, I am unable to start a mips
> > > (malta machine), powerpc (g3beige machine) or sparc (sun4u machine) VM.
> > > I get the following error message:
> > > 
> > >   error: unsupported configuration: IDE controllers are unsupported for 
> > > this QEMU binary or machine type
> > > 
> > > These machines do have an IDE controller that was supported in previous
> > > libvirt versions. And for some of them it is necessary to use it as the
> > > bootloader doesn't support scsi or virtio.
> > 
> > Please attach domain XML for the affected machines to the bug as well as
> > libvirtd's output in debug mode when trying to start the VM.
> 
> Here is the debug output for the powerpc machine. Others are similar.
> 
> $ virsh -d 0 start powerpc
> start: domain(optdata): powerpc
> start: found option : powerpc
> start:  trying as domain NAME
> error: Failed to start domain powerpc
> error: unsupported configuration: IDE controllers are unsupported for this 
> QEMU binary or machine type

This is not libvirtd's debug log unfortunately. You get that one by
enabling debug level output in /etc/libvirt/libvirtd.conf and looking
into syslog/the journal. But...

> You'll find the corresponding domain XML file attached.

...although this uses a qemu in /usr/local/bin it still happens with the
one in /usr/bin as well so I can reproduce this here so no further info
required atm.

I'll try to have a look soonish...

Thanks,
 -- Guido



Bug#805481: One important omission

2015-11-18 Thread Michael Biebl
Am 18.11.2015 um 18:35 schrieb Steven Capper:
> Upgrading to 227-1 caused immediate segfaults and led to the same
> unbootable machine.
> 
> So it looks like something introduced 227-1.

I would guess this was introduced by

https://github.com/poettering/systemd/commit/75f86906c52735c98dc0aa7e24b773edb42ee814

This is a quite invasive patch, so it's probably not that simply to
revert in on top of v227.

Steven, we uploaded 228-1 today. It would be great if you can pull that
version from unstable (should hit the mirrors in a couple of hours).

If this version is still affected we should take this upstream I think.

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#805419: rxvt-ml: krxvt and crxvt-{big5,gb} were built without CJK support

2015-11-18 Thread George Gensure
Thanks for the patch, Anthony.  Are we remiss in not providing a jrxvt with
--enable-languages and encoding sjis?

On Tue, Nov 17, 2015 at 6:23 PM, Anthony Fok  wrote:

> Package: rxvt-ml
> Version: 1:2.7.10-6
> Severity: important
> Tags: patch l10n
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> While trying to use a terminal program that can display
> Chinese characters in zh_CN.GB2312 for testing my pending fixes
> to the zh-autoconvert package, I installed rxvt-ml and tried
> to use the old trusty crxvt-gb, but could not get it to display
> any Chinese.  Looking deeper, it is even missing the -fm option
> that can be used to choose a multibyte CJK font.
>
> I then tried installing mrxvt-cjk, which works fortunately.
> "mrxvt-cjk -h" shows the following:
>
> Mrxvt v0.5.4
> Options: fade,XIM,multichar_languages,scrollbars=xterm,Resources
>
> But the current "crxvt-gb -h" instead shows:
>
> Rxvt v2.7.10 - released: 26 MARCH 2003
> Options:
> XPM,transparent,utmp,menubar,XIM,scrollbars=rxvt,graphics,XGetDefaults
>
> Note the absence of "multichar_languages".
>
> An examination of the rxvt source package reveals that upstream has
> changed its ./configure options.  The old --enable-{kanji,gb,big5}
> options were replaced with --enable-languages and the optional
> - --with-encoding options some time in the 2.7.x release.
>
> After applying the attached fix to debian/rules, I finally see that
> beautiful "multichar_languages" string:
>
> Rxvt v2.7.10 - released: 26 MARCH 2003
> Options:
> XPM,transparent,utmp,menubar,XIM,multichar_languages,scrollbars=rxvt,graphics,XGetDefaults
>
> And yes, it works!  "LANG=zh_CN.GB2312 crxvt-gb" now displays Chinese
> characters correctly, and ditto for "LANG=zh_TW.BIG5 crxvt-big5"
> and "LANG=ja_JP.EUC-JP krxvt".
>
> Many thanks!
>
> Anthony
>
> - --- rxvt-2.7.10~/debian/rules 2014-06-23 15:47:53.0 -0600
> +++ rxvt-2.7.10/debian/rules2015-11-17 15:31:41.712863538 -0700
> @@ -80,25 +80,25 @@
> mv src/rxvt src/rxvt-xpm
> $(MAKE) -C src clean
>
> - - ./configure $(CFG_XPM) --enable-kanji --disable-big5 --disable-gb
> --disable-greek
> +   ./configure $(CFG_XPM) --enable-languages --with-encoding=eucj
> echo "#define PTYS_ARE_GETPT 1" >> config.h
> $(MAKE) $(MAKEFLAGS) $(CROSS) CPPFLAGS='$(CPPFLAGS)'
> CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' rxvt
> mv src/rxvt src/krxvt
> $(MAKE) -C src clean
>
> - - ./configure $(CFG_XPM) --disable-kanji --enable-big5 --disable-gb
> --disable-greek
> +   ./configure $(CFG_XPM) --enable-languages --with-encoding=big5
> echo "#define PTYS_ARE_GETPT 1" >> config.h
> $(MAKE) $(MAKEFLAGS) $(CROSS) CPPFLAGS='$(CPPFLAGS)'
> CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' rxvt
> mv src/rxvt src/crxvt-big5
> $(MAKE) -C src clean
>
> - - ./configure $(CFG_XPM) --disable-kanji --disable-big5 --enable-gb
> --disable-greek
> +   ./configure $(CFG_XPM) --enable-languages --with-encoding=gb
> echo "#define PTYS_ARE_GETPT 1" >> config.h
> $(MAKE) $(MAKEFLAGS) $(CROSS) CPPFLAGS='$(CPPFLAGS)'
> CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' rxvt
> mv src/rxvt src/crxvt-gb
> $(MAKE) -C src clean
>
> - - ./configure $(CFG_XPM) --disable-kanji --disable-big5 --disable-gb
> --enable-greek
> +   ./configure $(CFG_XPM) --enable-greek
> echo "#define PTYS_ARE_GETPT 1" >> config.h
> $(MAKE) $(MAKEFLAGS) $(CROSS) CPPFLAGS='$(CPPFLAGS)'
> CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' rxvt
> mv src/rxvt src/grxvt
>
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages rxvt-ml depends on:
> ii  libc6 2.19-22
> ii  libx11-6  2:1.6.3-1
> ii  libxpm4   1:3.5.11-1+b1
>
> Versions of packages rxvt-ml recommends:
> ii  rxvt  1:2.7.10-6
>
> Versions of packages rxvt-ml suggests:
> pn  xcin  
> ii  xfonts-intl-chinese   1.2.1-10
> pn  xfonts-intl-european  
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJWS7btAAoJEOolALQSxZrPU5UP+wf63fFrcaK7s33TWq0DUCQ/
> W8/ZQVyygdz/935KGbqNykk5v9n9mc2SsulE791ycvOJqquaBXxR32ahd9BCDMbK
> 7Jq2LFVhCUwhUzOV6ju7h02Luc+Zzvjxo2jpVTsiZMuyKZdIX5lQS/37RGOKdinI
> pJayMjkjt5wPI1UzhurjkXl/+Nrhka34NGnCLEVyesdSc821pWGiEDM+YbMhDdEa
> qcpiXdu7TULfBwKOWbUgJa9OiKPTRABXF7AKMJ04+0xQmP09rhb1+RlUpY2EU1Fl
> LwZOTtsIJEPvBfakDub87rXWRLwnQj4SmqGY9Qac7Iy9EBe4n/SP7NXRozfqtHUH
> FQ/qcmSGdRnnjkw7I0IJLWFGqww3+wsSntsdLF5jiJ+1N7N+joQKEAXWNgQxb4BB
> 

Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Gianfranco Costamagna
Hi,


>I tried to fix most of the points. I replaced my patch with a applied
>upstream patch. One of the symbol files had a wrong file name. This
>should be fixed, too.
lets see :)

1) VCS-* they should point to Debian packaging, not to upstream packaging
(this is done in copyright)


2) symbols:
sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' package.symbols | c++filt > 
package.symbols.new

and look to the "new" file :)
(you might have many build failures and need to fix the symbols file on various 
architecture, but

this needs to be done in a later step)

3) question: why one library is called liblastfm1_1.0.9-1_amd64.deb and the 
other is called liblastfm5-1_1.0.9-1_amd64.deb



(this shouldn't be a real issue, just I'm wondering if it is a lintian complain)

4) lintian: 
X: liblastfm5-dev: package-contains-broken-symlink 
usr/lib/x86_64-linux-gnu/liblastfm_fingerprint5.so liblastfm_fingerprint5.so.1

cheers,

G.



Bug#778718: guake fails to show it systray icon on mate-panel

2015-11-18 Thread pioruns
Works fine in Debian Stable (jessie). Regression had to happened between
version 0.4.4-1 and 0.5.2-1~exp1.

Regards
pioruns



Bug#648230: Packaging (and RFS) for pymssql 2.1.1+dfsg-1

2015-11-18 Thread Geoffrey Thomas
Hi Joss,

I've updated pymssql to 2.1.1+dfsg-1, closing #648230, #709210, and
#590548, and pushed the packaging branch to DPMT git, in a new branch
"2.1.1". We've had trouble with the freetds incompatibility; the new
package solves the issue.

There are a few packaging cleanups described in debian/changelog.
Notably the new version reworks what sourceless files they include, so
I've decided to let uscan handle it and dropped the get-orig-source
target per advice on #debian-python.

Could you look over it before I push it to master?

Also, are you interested in sponsoring this upload?

Thanks,
-- 
Geoffrey Thomas
geo...@hudson-trading.com



Bug#570283: Bug #570283: runaway memory leak when processing DBOX2 CDK configure scripts

2015-11-18 Thread Gioele Barabucci

Control: reassing 570283 src:dash
Control: tags 570283 moreinfo

Hello,

is this bug still relevant? Can you still reproduce this problem on a 
SheevaPlug with the latest source package and the current gcc 
infrastructure? [1]


Regards,

[1] http://www.cyrius.com/debian/kirkwood/sheevaplug/

--
Gioele Barabucci 



Bug#805493: release-notes: Document how to migrate SELinux policies from the old store to the new one

2015-11-18 Thread Laurent Bigonville
Package: release-notes
Severity: normal
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,

With the new SELinux userspace 2.4, the policy store has moved from
/etc/selinux/ to /var/lib/selinux/ (the format
of the store has also changed).

The packages from the refpolicy (selinux-policy-default and
selinux-policy-mls) should be fixed to automatically migrate the the new
store (ATM this still need to be done, see #805492)

We should probably document how to do the migration for the policies
maintained directly by the users and quickly explain the differences.

Cheers,

Laurent Bigonville

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

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



Bug#805491: no need for lsb-release build-depends anymore

2015-11-18 Thread Daniel Baumann
Package: util-linux
Severity: wishlist
Version: 2.27.1-1

Hi,

fortunately the distro-specific part for nfs mounts in one of the
postinst scripts is gone. now, the build-depends on lsb-release is not
needed anymore either.

Regards,
Daniel



Bug#805492: refpolicy: Fix the maintainer script to support the new policy store

2015-11-18 Thread Laurent Bigonville
Source: refpolicy
Version: 2:2.20140421-9
Severity: serious

Hi,

With the userspace 2.4, the policy store has moved from
/etc/selinux/ to /var/lib/selinux/ (the format
of the store has also changed).

The semanage-utils package contains a script to do that, we should see
if we are using it (it uses python) or if we are doing the migration
manually.

The maintainer script should also be updated to use the new location to
install the modules after the initial migration. Should we use semodule
again? We should also install these modules with the correct priority.

Cheers,

Laurent Bigonville

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

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



Bug#805487: sysvinit: consider moving invoke-rc.d, update-rc.d and service to src:init-system-helpers

2015-11-18 Thread Andreas Henriksson
Hello all.

On Wed, Nov 18, 2015 at 05:48:17PM +0100, Michael Biebl wrote:
> Am 18.11.2015 um 17:32 schrieb Andreas Henriksson:
> > One idea that has been tossed around is to put them in
> > src:init-system-helpers which is already a source for
> > init-system-agnostic utilities.
[...]
> I briefly discussed that during debconf 15 where hmh, one of the
> (former) sysvinit maintainers, was present and IIRC he wasn't averse to
> the idea.

Thanks for the update on this. It looks to me like hmh is the original
author of the *-rc.d bits atleast so his blessing would be welcome.
It's also documented in the tools that each init system should ship
their own versions, but it also seems this then pretty much becomes
a "copylib" which is generally discuraged in debian so I think that
would probably be wise to reconsider. Specially since the sysvinit
versions are the ones supporting sysvinit, upstart and systemd.

I've prepared initial branches now at:

http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/log/?h=wip/init-tools
http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/log/?h=wip/init-tools

My chroot did not explode when upgrading to these versions, but haven't
had time to carefully examine things yet.

Comments/suggestions welcome!

Regards,
Andreas Henriksson

PS. the wip/ prefix means I intend to rebase as needed.



Bug#190784: aptitude: When suing to root umask is not set to root's umask

2015-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + pending


Hi Jan,

2003-04-25 23:14 Jan Schumacher:

Package: aptitude
Version: 0.2.11.1-3
Severity: normal

Hi,

When using aptitude as a user, it needs to su to root in order to update.
The user's umask is kept, however, so that files written may not be 
world-readable.
When later using aptitude as a normal user again, it might not be able to
read its package cache etc.


This has been fixed now and will be present in the next release, marking
as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#805428: tableau-parm: fix FTBFS with ld --as-needed

2015-11-18 Thread Eriberto Mota
Hi Logan,

Thanks for your message. The new package was uploaded to 1-day/delay queue[1].

[1] https://ftp-master.debian.org/deferred.html

Regards,

Eriberto


2015-11-18 0:27 GMT-02:00 Logan Rosen :
> Package: tableau-parm
> Version: 0.2.0-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu xenial ubuntu-patch
>
> Dear Maintainer,
>
> In Ubuntu, we use ld --as-needed by default in the toolchain, and your
> package fails to build from source with that option enabled because of the
> way libraries are linked.
>
> Even though Debian doesn't use ld --as-needed by default, it is a good idea
> to make this change so that (1) we don't have to maintain a delta and (2)
> you don't need to change anything in case Debian makes this default in the
> future.
>
> You can read more about this option here:
> https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * Fix FTBFS with ld --as-needed. LP: #832758.
>
> Thanks for considering the patch.
>
> Logan Rosen
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers xenial-updates
>   APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
> 'xenial'), (100, 'xenial-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-19-generic (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> forensics-devel mailing list
> forensics-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel



Bug#790103: new default build flag from dpkg: -Wdate-time

2015-11-18 Thread Hakan Ardo
Hi,
the archlinux avr-gcc seams to be a standard unpatched gcc compiled for the
avr target. I would prefere to base the main avr-gcc package on the atmel
releases as those have historically been of higiher quality for avr usage.
That means avr-gcc will be upgraded to the atmel release 3.5.0 based on gcc
4.9.2 soon. Will that help? Otherwise my suggestion would be that we
introduce a new package, say avr-gcc5, that we base on the gnu release
5.2.0 and keep avr-gcc following the atmel releases.

On Sat, Nov 14, 2015 at 10:49 AM, Mattia Rizzolo  wrote:

> reassign 790103 gcc-avr 1:4.8.1+Atmel3.4.5-1
> retitle 790103 gcc-avr: base on a newer version of gcc
> affects 790103 expeyes
>
> On Sat, Nov 14, 2015 at 10:35:46AM +0100, Georges Khaznadar wrote:
> > > > 3- rebase the package gcc-avr on a newer version of gcc, which may
> be a
> > > >hard work. Such a work seems to exist, for example at
> > > >https://www.archlinux.org/packages/community/x86_64/avr-gcc/
> since
> > > >last July
> > >
> > > This is what should be done, really.
> >
> > I had a look at this last option, but I miss knowledge to keep on with
> > it: as I could guess, the current gcc-avr package is based on a frozen
> > archive of gcc-4.8, which is modified by adding subtle modifications.
> > Obviously, I can freeze an archive of gcc-5, but I cannot craft the
> > modifications to turn it into an efficient compiler for avr.
>
> I miss those too, fwiw.
>
> > So I shall reassign bug #790103 to gcc-avr, and keep the suggested link
> > to expeyes.
>
> done.
>
> > As a matter of fact, I cannot push the severity such a bugreport higher
> > than whishlist, as I cannot provide any help about the work to be done.
>
> This is not what is used to decide the severities :), but still it's a
> whishlist bug.
>
> If this is not fixed in time for the change I'll open another bug
> against expeyes to at least disable the flag.
> If for some reason (=> allow us to test your package, maybe?) you want
> to do it now adding this to d/rules should be sufficient
> DEB_BUILD_MAINT_OPTIONS=reproducible=-timeless
>
> > Best regards, Georges.
>
> enjoy!
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>



-- 
Håkan Ardö


Bug#805477: systemd: Leak of scope units slowing down "systemctl list-unit-files" and delaying logins

2015-11-18 Thread Michael Biebl
Hi Julian,

thanks for the detailed bug report.

Am 18.11.2015 um 16:01 schrieb Julian Brost:
> I was also able to fully reproduce this on sid with systemd 227-3. With about
> 700 leaked scope units, list-unit-files took about 1.2 seconds instead of the
> normal 0.1 seconds.

On a first glance this doesn't look like a Debian specific issue.
It would therefor be great if you can file this upstream at
https://github.com/systemd/systemd/issues/new

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#805497: update libseccomp build-depends

2015-11-18 Thread Daniel Baumann
Package: systemd
Version: 228-1
Severity: wishlist

Hi,

the current systemd package needs at least libseccomp 2.2.1-2 due to the
move to /lib of libseccomp. It would be nice if you could update the
versioned build-depends to libseccomp accordingly.

Regards,
Daniel



Bug#804944: dtach seems broken on arm64

2015-11-18 Thread Stefan
Hi,

please take a look at

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

and keep

804944-forwar...@bugs.debian.org

on CC to record your messages in the BTS.

Stefan



Bug#805167: rpcbind: Regression: rpcbind doesn't start at boottime on systemd controlled machines.

2015-11-18 Thread Elimar Riesebieter
* Elimar Riesebieter  [2015-11-16 19:09 +0100]:

v> Control: retitle -1 "Regression: rpcbind doesn't start at boottime
> on systemd controlled machines."
> 
> * Elimar Riesebieter  [2015-11-15 13:56 +0100]:
> 
> > Package: rpcbind
> > Version: 0.2.3-0.2
> > Severity: important
> > 
> > Can't run nis:
> > # ypbind -no-dbus -broadcast -debug
> > 1679: add_server() domain: mynisdomain, broadcast
> > 1679: [Welcome to ypbind-mt, version 1.20.1]
> > 1679: ping interval is 20 seconds
> > Cannot register service: RPC: Unable to receive; errno = Connection refused
> > 1679: Unable to register (YPBINDPROG, YPBINDVERS, udp).

# systemctl status rpcbind.service

  rpcbind.service - RPC bind portmap service
   Loaded: loaded (/lib/systemd/system/rpcbind.service; indirect; vendor 
preset: enabled)
  Drop-In: /run/systemd/generator/rpcbind.service.d
   └─50-rpcbind-$portmap.conf
   Active: inactive (dead)

# Systemctl enable rpcbind.service
didn't help either.

Elimar
-- 
 Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)



Bug#805495: mc: Very slow opening of an ISO file

2015-11-18 Thread Brian Potkin
Package: mc
Version: 3:4.8.13-3
Severity: normal


genisoimage is a suggested package for mc and isoinfo (from the package)
is used to open an ISO archive and display the files in it. The display
is almost instantaneous with DVD-2 for Jessie.

mc is also capable of using xorriso for the same job. If xorriso is also
on the system it takes over from isoinfo. I do not know whether this
could be classed as a bug.

Whether or not genisoimage has been installed the opening of an ISO is
very, vary slow using xorriso; in excess of a minute on this machine.

  xorriso -indev debian-8.2.0-i386-DVD-4.iso -lsl

Output from

  xorriso -indev debian-installer/debian_isos/debian-8.2.0-i386-DVD-4.iso -lsl

is immediate, as is

  xorriso -indev debian-installer/debian_isos/debian-8.2.0-i386-DVD-4.iso -lsl 
pool/main

I'd conclude xorriso is not at fault.

Regards,

Brian.





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

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

Versions of packages mc depends on:
ii  e2fslibs  1.42.12-1.1
ii  libc6 2.19-18+deb8u1
ii  libglib2.0-0  2.42.1-1
ii  libgpm2   1.20.4-6.1+b2
ii  libslang2 2.3.0-2
ii  libssh2-1 1.4.3-4.1
ii  mc-data   3:4.8.13-3

Versions of packages mc recommends:
ii  mime-support  3.58
ii  perl  5.20.2-3+deb8u1
ii  unzip 6.0-16+deb8u1

Versions of packages mc suggests:
pn  arj
ii  bzip2  1.0.6-7+b3
pn  catdvi | texlive-binaries  
pn  dbview 
pn  djvulibre-bin  
ii  file   1:5.22+15-2
ii  genisoimage9:1.1.11-3
ii  gv [pdf-viewer]1:3.7.4-1
ii  imagemagick8:6.8.9.9-5
ii  lynx   2.8.9dev1-2+deb8u1
ii  mupdf [pdf-viewer] 1.5-1+b2
pn  odt2txt
ii  poppler-utils  0.26.5-2
ii  python 2.7.9-1
ii  python-boto2.34.0-2
pn  python-tz  
ii  w3m0.5.3-19
ii  xpdf [pdf-viewer]  3.03-17+b1
ii  zip3.0-8

-- no debconf information



Bug#805496: refpolicy: Check if the (build-)dependencies are still satisfied

2015-11-18 Thread Laurent Bigonville
Source: refpolicy
Version: 2:2.20140421-9
Severity: serious

Hi,

With policycoreutils 2.4, the package has been split in multiple
sub-packages.

We need to check if the needed executables are still present and adjust
the dependencies accordingly.

Cheers,

Laurent Bigonville

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

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



Bug#805417: Dtach leaves signals ignored in slave process

2015-11-18 Thread Stefan
Hi,

please keep at least 805417-forwar...@bugs.debian.org on CC to record your
messages to the Debian Bug Tracker, thanks.

Stefan

- Forwarded message from Robert de Bath  -

Date: Tue, 17 Nov 2015 22:38:27 + (GMT)
From: Robert de Bath 
To: sub...@bugs.debian.org
Subject: Bug#805417: Dtach leaves signals ignored in slave process.
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
X-Mailer: Alpine for Linux

Package: dtach
Version: 0.8-2.1

On a 'dtach'ed shell
$ grep Sig /proc/self/status
SigQ:   2/48068
SigPnd: 
SigBlk: 
SigIgn: 01001001
SigCgt: 00018000
$

Expected result, eg running under ssh or an XTerm:
$ grep Sig /proc/self/status
SigQ:   0/62981
SigPnd: 
SigBlk: 
SigIgn: 
SigCgt: 00018000
$

Converting the SigIgn to binary
100010001
98765432109876543210987654321
2211

Signal 1 -> SIGHUP
Signal 13 -> SIGPIPE
Signal 25 -> SIGXFSZ

This means that processes within a pipeline will ignore the SIGPIPE
that's supposed to terminate them when the process at the end of the
pipeline finishes early and, if programmed correctly, they will complain
about an I/O error on writing to their stdout.

Resetting the signal() to SIG_DFL in the child, just before exec(), does NOT 
seem to work.

Trapping the signals that are ignored in dtach and routing them to a
no-op handler appears to give the required semantics.

But the simplest solution/workaround seems to be to move the
signal(SIGxxx, SIG_IGN)

calls after the call to init_pty() so that the signals are not actually
ignored when the child is forked off.

-- 
Rob.  (Robert de Bath )
 

- End forwarded message -

-- 
BOFH excuse #234:

Someone is broadcasting pygmy packets and the router doesn't know how to deal 
with them.



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Stefan Ahlers
Hi,
> 1) VCS-* they should point to Debian packaging, not to upstream packaging
> (this is done in copyright)
Fixed! I've set up a new repository.
> 2) symbols:
> sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' package.symbols | c++filt > 
> package.symbols.new
>
> and look to the "new" file :)
> (you might have many build failures and need to fix the symbols file on 
> various architecture, but
>
> this needs to be done in a later step)
Oha, this is great. Now the symbols are human readable.
> 3) question: why one library is called liblastfm1_1.0.9-1_amd64.deb and the 
> other is called liblastfm5-1_1.0.9-1_amd64.deb
liblastfm1 is build against Qt4 and liblastfm5-1 is build against Qt5.
I've adopt the names of lintian.
> 4) lintian: 
> X: liblastfm5-dev: package-contains-broken-symlink 
> usr/lib/x86_64-linux-gnu/liblastfm_fingerprint5.so liblastfm_fingerprint5.so.1
There was a missing dependence in debian/control. Fixed!

How can I fix the symbol files now? Is there a way to setup a local
build farm for each architecture?

Stefan



Bug#790103: new default build flag from dpkg: -Wdate-time

2015-11-18 Thread Mattia Rizzolo
On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote:
> That means avr-gcc will be upgraded to the atmel release 3.5.0 based on gcc
> 4.9.2 soon.

soon = ?

> Will that help? Otherwise my suggestion would be that we
> introduce a new package, say avr-gcc5, that we base on the gnu release
> 5.2.0 and keep avr-gcc following the atmel releases.

sounds a lot of work for very little gain.
Only one package would FTBFS with this, and there are other workarounds
as well.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#805487: sysvinit: consider moving invoke-rc.d, update-rc.d and service to src:init-system-helpers

2015-11-18 Thread Michael Biebl
Am 18.11.2015 um 20:03 schrieb Andreas Henriksson:
> I've prepared initial branches now at:
> 
> http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/log/?h=wip/init-tools
> http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/log/?h=wip/init-tools
> 
> My chroot did not explode when upgrading to these versions, but haven't
> had time to carefully examine things yet.

Fwiw, I think it makes sense to pull those implementations out into a
init-agnostic package. Thanks for working on this!

What's the rationale for using a separate binary package instead of just
putting them into init-system-helpers?

Regarding update-rc.d: Should we add a hard dependency on insserv for
the sysv-rc path or will we add a graceful fallback?


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#803523: After installing plasma-pa I have 2 volume applets too

2015-11-18 Thread Diederik de Haas
I just installed plasma-pa and when I rebooted I have two applets too.
Do you have that package too?


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


Bug#805499: libnanoxml2-java: FTBFS with bnd 2.1.0

2015-11-18 Thread Markus Koschany
Package: libnanoxml2-java
Version: 2.2.3.dfsg-4
Severity: serious
Tags: patch

Dear maintainer,

libnanoxml2-java FTBFS with bnd 2.1.0. Please find attached a patch
that fixes this issue.

Regards,

Markus
diff -u libnanoxml2-java-2.2.3.dfsg/debian/rules libnanoxml2-java-2.2.3.dfsg/debian/rules
--- libnanoxml2-java-2.2.3.dfsg/debian/rules
+++ libnanoxml2-java-2.2.3.dfsg/debian/rules
@@ -28,7 +28,7 @@
 LITE := nanoxml-lite.jar
 SAX := nanoxml-sax.jar
 
-#Architecture 
+#Architecture
 build: build-stamp
 
 build-stamp:
@@ -37,9 +37,12 @@
 	CLASSPATH=${NANOXML} jh_build -o'${JFLAGS}' -N ${SAX} Sources/SAX/
 	jh_manifest -c /usr/share/java/${NANOXML} ${SAX}
 
-	bnd wrap *.jar
-	rm *.jar
-	prename 's/bar/jar/' *.bar
+	bnd wrap --output $(NANOXML).tmp $(NANOXML)
+	bnd wrap --output $(LITE).tmp $(LITE)
+	bnd wrap --output $(SAX).tmp $(SAX)
+	mv $(NANOXML).tmp $(NANOXML)
+	mv $(LITE).tmp $(LITE)
+	mv $(SAX).tmp $(SAX)
 
 	${JAVA_HOME}/bin/javadoc -author -link /usr/share/doc/default-jdk-doc/api -quiet \
 	-sourcepath Sources/Java/:Sources/Lite/:Sources/SAX/ -source 1.4 \
@@ -61,12 +64,12 @@
 	rm -rf Test/*/*.class
 	rm -rf debian/orig.tmp || echo "No failed source fetch"
 
-	dh_clean 
+	dh_clean
 
 install:
 	dh_testdir
 	dh_testroot
-	dh_clean -k -i 
+	dh_clean -k -i
 
 	jh_installlibs -i
 	jh_installjavadoc -plibnanoxml2-java-doc
@@ -78,10 +81,10 @@
 binary-common:
 	dh_testdir
 	dh_testroot
-	dh_installchangelogs 
+	dh_installchangelogs
 	dh_installdocs
 	dh_link
-	dh_compress 
+	dh_compress
 	dh_fixperms
 	dh_installdeb
 	dh_gencontrol
diff -u libnanoxml2-java-2.2.3.dfsg/debian/changelog libnanoxml2-java-2.2.3.dfsg/debian/changelog
--- libnanoxml2-java-2.2.3.dfsg/debian/changelog
+++ libnanoxml2-java-2.2.3.dfsg/debian/changelog
@@ -1,3 +1,12 @@
+libnanoxml2-java (2.2.3.dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Transition to bnd 2.1.0.
+  * Do not depend on a Java runtime because the Java Policy does not require
+this anymore.
+
+ -- Markus Koschany   Wed, 18 Nov 2015 21:05:35 +0100
+
 libnanoxml2-java (2.2.3.dfsg-4) unstable; urgency=low
 
   * Removed no longer needed work around for 567899 (Closes: #573697)
diff -u libnanoxml2-java-2.2.3.dfsg/debian/control libnanoxml2-java-2.2.3.dfsg/debian/control
--- libnanoxml2-java-2.2.3.dfsg/debian/control
+++ libnanoxml2-java-2.2.3.dfsg/debian/control
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 5)
 Build-Depends-Indep: default-jdk-doc,
  default-jdk,
- bnd,
+ bnd (>= 2.1.0),
  perl,
  javahelper
 Standards-Version: 3.8.4.0
@@ -13,7 +13,7 @@
 
 Package: libnanoxml2-java
 Architecture: all
-Depends: default-jre-headless | java2-runtime-headless, ${misc:Depends}
+Depends: ${misc:Depends}
 Suggests: libnanoxml2-java-doc
 Description: small XML parser for Java
  NanoXML is a (actually more than one) small XML parser for Java. It


Bug#805497: update libseccomp build-depends

2015-11-18 Thread Michael Biebl
Hi Daniel

Am 18.11.2015 um 21:07 schrieb Daniel Baumann:
> the current systemd package needs at least libseccomp 2.2.1-2 due to the
> move to /lib of libseccomp. It would be nice if you could update the
> versioned build-depends to libseccomp accordingly.

In theory, I agree with you. Unfortunately, bumping the build-depends on
libseccomp-dev has no effect. The generated dependency on libseccomp2
would still be the same.

If you want to change this, libseccomp whould have to use
 * Build-Depends-Package: libseccomp-dev
in its .symbols/.shlibs file.

Then, bumping the bdep would actually result in a tightened dep.

Do you want to file a corresponding bug report against libseccomp?


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#805214: jessie-pu: package libhtml-scrubber-perl/0.11-1

2015-11-18 Thread Niko Tyni
On Tue, Nov 17, 2015 at 09:23:01PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2015-11-15 at 22:57 +0200, Niko Tyni wrote:
> >  libhtml-scrubber-perl (0.11-1+deb8u1) jessie; urgency=medium
> >  .
> >* [SECURITY] CVE-2015-5667: Backport upstream patch fixing
> >  a cross-site scripting vulnerability in comments.
> >  (Closes: #803943)
> 
> Please go ahead; thanks.

Thanks, uploaded.
-- 
Niko



Bug#805216: wheezy-pu: package libhtml-scrubber-perl/0.09-1

2015-11-18 Thread Niko Tyni
On Tue, Nov 17, 2015 at 09:22:38PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2015-11-15 at 23:08 +0200, Niko Tyni wrote:
> >  libhtml-scrubber-perl (0.09-1+deb7u1) wheezy; urgency=medium
> >  .
> >* [SECURITY] CVE-2015-5667: Backport upstream patch fixing
> >  a cross-site scripting vulnerability in comments.
> >  (Closes: #803943)
> 
> Please go ahead; thanks.

Thanks, uploaded.
-- 
Niko



Bug#805500: sigil: please make the build reproducible

2015-11-18 Thread Reiner Herrmann
Source: sigil
Version: 0.9.0+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that sigil could not be built reproducibly.
Source files are linked in readdir() order.

The attached patch fixes this by telling CMake to sort the file list.

Regards,
 Reiner

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

diff --git a/debian/patches/reproducible b/debian/patches/reproducible
index b66ea4d..aa78d14 100644
--- a/debian/patches/reproducible
+++ b/debian/patches/reproducible
@@ -83,3 +83,13 @@ Last-Update: 2015-07-30
   

 
+--- a/internal/gumbo/CMakeLists.txt
 b/internal/gumbo/CMakeLists.txt
+@@ -15,6 +15,7 @@
+ set( GUMBO_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR} CACHE INTERNAL "" )
+ 
+ file( GLOB SOURCES *.c )
++list( SORT SOURCES )
+ 
+ if( APPLE )
+ set(CMAKE_MACOSX_RPATH 1)


signature.asc
Description: OpenPGP digital signature


Bug#790103: new default build flag from dpkg: -Wdate-time

2015-11-18 Thread Mattia Rizzolo
On Wed, Nov 18, 2015 at 09:40:51PM +0100, Hakan Ardo wrote:
> On Wed, Nov 18, 2015 at 8:31 PM, Mattia Rizzolo  wrote:
> > On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote:
> > > That means avr-gcc will be upgraded to the atmel release 3.5.0 based on
> > gcc
> > > 4.9.2 soon.
> > soon = ?
> Within a week or three...

That's totally fine.  This thing won't happen before for sure.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#805477: systemd: Leak of scope units slowing down "systemctl list-unit-files" and delaying logins

2015-11-18 Thread Felipe Sateler
On 18 November 2015 at 16:39, Michael Biebl  wrote:
> Hi Julian,
>
> thanks for the detailed bug report.
>
> Am 18.11.2015 um 16:01 schrieb Julian Brost:
>> I was also able to fully reproduce this on sid with systemd 227-3. With about
>> 700 leaked scope units, list-unit-files took about 1.2 seconds instead of the
>> normal 0.1 seconds.
>
> On a first glance this doesn't look like a Debian specific issue.
> It would therefor be great if you can file this upstream at
> https://github.com/systemd/systemd/issues/new

Maybe this is related to a debian-specific patch[1]? Julian, could you
try with this patch removed?


[1] 
http://sources.debian.net/src/systemd/227-3/debian/patches/Revert-core-one-step-back-again-for-nspawn-we-actual.patch


-- 

Saludos,
Felipe Sateler



Bug#790103: new default build flag from dpkg: -Wdate-time

2015-11-18 Thread Hakan Ardo
On Wed, Nov 18, 2015 at 8:31 PM, Mattia Rizzolo  wrote:

> On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote:
> > That means avr-gcc will be upgraded to the atmel release 3.5.0 based on
> gcc
> > 4.9.2 soon.
>
> soon = ?
>

Within a week or three...


Bug#805501: devscripts: debuild should not strip DBUS_SESSION_BUS_ADDRESS from the environment

2015-11-18 Thread Daniel Kahn Gillmor
Package: devscripts
Version: 2.15.9
Severity: normal

Hi lovely devscripts maintainers--

debuild can't make cryptographic signatures in some cases where the
user is using pinentry-gnome3.  pinentry-gnome3 depends on D-Bus to
get the prompt to display.  But is in some cases, gpg-agent doesn't
know which dbus session to tell the pinentry to talk to by default.

GnuP will tell gpg-agent which D-Bus session to use, but only if it
has access to the DBUS_SESSION_BUS_ADDRESS environment variable.

So debuild should avoid stripping that environment variable, in the
same way that it doesn't strip GPG_TTY and GPG_AGENT_INFO, etc.

Regards,

 --dkg

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.3.0-trunk-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 devscripts depends on:
ii  dpkg-dev 1.18.3
ii  libc62.19-22
ii  perl 5.20.2-6
ii  python3  3.4.3-7
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.45.0-1+b1
ii  dctrl-tools 2.24-1
ii  debian-keyring  2015.08.13
ii  dput-ng [dput]  1.10
ii  dupload 2.7.0
pn  equivs  
ii  fakeroot1.20.2-1
ii  file1:5.25-2
ii  gnupg   1.4.19-6
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.69-1
ii  libwww-perl 6.13-1
ii  lintian 2.5.38.1
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.25-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-20
ii  wdiff   1.2.2-1
ii  wget1.16.3-3
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  build-essential  11.7
pn  cvs-buildpackage 
ii  debbindiff   38
ii  devscripts-el35.12
pn  gnuplot  
ii  gpgv 1.4.19-6
ii  heirloom-mailx [mailx]   12.5-5
pn  libauthen-sasl-perl  
pn  libfile-desktopentry-perl
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:2.99.98-2+b1
pn  mutt 
ii  openssh-client [ssh-client]  1:6.9p1-2+b1
ii  svn-buildpackage 0.8.5+nmu1
ii  w3m  0.5.3-25+b1

-- debconf-show failed



Bug#804505: gnome-shell-extension-weather: Not accepting the selection of cities

2015-11-18 Thread Carsten Brandt
Package: gnome-shell-extension-weather
Version: 0~20140924.git7e28508-1
Followup-For: Bug #804505

Same problem here, I have used the whether applet before so maybe an old config 
is preventing something.

Please let me know which additional information is needed to reproduce the 
issue on your side.

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

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

Versions of packages gnome-shell-extension-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gir1.2-clutter-1.0   1.20.0-1
ii  gir1.2-glib-2.0  1.42.0-2.2
ii  gir1.2-gtk-3.0   3.14.5-1+deb8u1
ii  gir1.2-soup-2.4  2.48.0-1
ii  gnome-shell  3.14.4-1~deb8u1

Versions of packages gnome-shell-extension-weather recommends:
ii  gnome-tweak-tool  3.14.2-2

gnome-shell-extension-weather suggests no packages.

-- no debconf information



Bug#805439: RFS: visualboyadvance/1.8.0.dfsg-3 [RC]

2015-11-18 Thread Chris Lamb
> I am looking for a sponsor for my package "visualboyadvance"
[..]
> dget -x
> http://mentors.debian.net/debian/pool/main/v/visualboyadvance/visualboyadvance_1.8.0.dfsg-3.dsc

Uploaded:

  Successfully uploaded visualboyadvance_1.8.0.dfsg-3_amd64.changes to
  ftp.upload.debian.org for ftp-master.


Regards,

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



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Gianfranco Costamagna
Control: owner -1 !
Control: tags -1 moreinfo

Hi Stefan



(some issues of libjdns also apply here, and Pabs review is correct, so please 
check them before)

in additions:
please consider moving priority to optional
https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities


the other stuff LGTM :)

cheers,

G.



Bug#804499: ruby-gsl: GSL transition requires rebuild

2015-11-18 Thread Balint Reczey
Hi Dirk,

On Sun, 08 Nov 2015 17:26:29 -0600 Dirk Eddelbuettel  wrote:
> 
> Package: ruby-gsl
> Severity: serious
> 
> The GNU GSL, upon which your package as a build- and run-time dependency, had
> a 2.0 release [1] which introduced minor incompatibilities with the previous
> (1.6) release. I had left the package for many years at libgsl0ldbl because
> such a transition was never needed. But this warranted a change.
> 
> Your package as a versioned 'Depends: libgsl0ldbl (>= 1.X)' for some value of
> X which cannot be satisfied by the Provides: we added to libgsl2.  So this
> requires a rebuild of your package against libgsl-dev (>= 2.0).
> 
> If you have any questions please do not hesitate to get in touch. The release
> team has also been exceptional on this (as usual, they do rock) so see
> 
>http://bugs.debian.org/804246
> 
> which tracks the transition bug report against release.
> 
> Regards,  Dirk
> 
> [1] http://savannah.gnu.org/forum/forum.php?forum_id=8392
Thank you for the bug report.
I have prepared the fix in git [2] but tamuanova [3] needs to be transitioned
first since it is a build dependency and can't be installed together with
libgsl-dev > 2.0.

Cheers,
Balint

[2] 
http://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-gsl.git/commit/?id=126c49a55a83dda1a39e0e25b11529020bd0ee74
[3] https://packages.qa.debian.org/t/tamuanova.html



Bug#805439: RFS: visualboyadvance/1.8.0.dfsg-3 [RC]

2015-11-18 Thread Gianfranco Costamagna
Hi Chris,


>Uploaded:

>
>  Successfully uploaded visualboyadvance_1.8.0.dfsg-3_amd64.changes to
>  ftp.upload.debian.org for ftp-master.


I guess my upload was the first one... not sure, we will see :)

cheers,

G.



Bug#805449: Allow to replace the existing dbus daemon without reboot

2015-11-18 Thread Christoph Anton Mitterer
We've already had some concerns about that issue at the local institute...

Am 18. November 2015 12:10:24 MEZ, schrieb Yuri D'Elia :
>I realize debian has nothing to do with this, but still, as long as you
>don't close the bug, I'm fine with wontfix...

I don't think this should be marked wontfixed, but rather kept open and given a 
higher severity.
And especially further non desktop stuff should probably be forbidden to 
strongly require dbus until this problem has been solved by upstream.


When dbus used to be mostly for the desktop, that design problem didn't cause 
much worries, but nowadays one basically cannot circumvent it on server systems 
either, and I guess in the future it will be rather used more than less.

But not being able to restart it (e.g. for security updates) without a reboot 
is in fact a major issue that upstream  should work on.
Especially when one considers that there are still many things that can't be 
clustered.

Cheers,
Chris.



Bug#805453: kde-telepathy-text-ui: ktp-text-ui crash on opening chat with any contact

2015-11-18 Thread Gael Lalleman
Package: kde-telepathy-text-ui
Version: 15.08.2-1
Severity: important

Dear Maintainer,

ktp-text-ui crash on opening chat with any contact

Reproducible: Always

Steps to Reproduce:
1. Open KDE Telepathy contact list
2. Double click on any contact

Actual Results: ktp-text-ui window appear, but then disappear (because ktp-
text-ui crashed)

Expected Results: ktp-text-ui doesn't crash

According to https://bugs.kde.org/show_bug.cgi?id=347313 libkf5emoticons-bin
wasn't installed. After installation of this package crash is gone.

Is suggest to add libkf5emoticons-bin to dependencies.



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

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

Versions of packages kde-telepathy-text-ui depends on:
ii  kde-telepathy-data  15.08.2-3
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libjs-jquery1.11.3+dfsg-4
ii  libkf5archive5  5.15.0-1
ii  libkf5configcore5   5.15.0-1
ii  libkf5configgui55.15.0-1
ii  libkf5configwidgets55.15.0-1
ii  libkf5coreaddons5   5.15.0-1
ii  libkf5dbusaddons5   5.15.0-1
ii  libkf5emoticons55.15.0-1
ii  libkf5i18n5 5.15.0-1
ii  libkf5iconthemes5   5.15.0-1
ii  libkf5itemviews55.15.0-1
ii  libkf5kcmutils5 5.15.0-1
ii  libkf5kiocore5  5.15.0-1
ii  libkf5kiowidgets5   5.15.0-1
ii  libkf5notifications55.15.0-1
ii  libkf5notifyconfig5 5.15.0-1
ii  libkf5people5   5.15.0-1
ii  libkf5peoplewidgets55.15.0-1
ii  libkf5service-bin   5.15.0+-1
ii  libkf5service5  5.15.0+-1
ii  libkf5sonnetcore5   5.15.0-1
ii  libkf5sonnetui5 5.15.0-1
ii  libkf5textwidgets5  5.15.0-1
ii  libkf5webkit5   5.15.0-1
ii  libkf5widgetsaddons55.15.0-1
ii  libkf5windowsystem5 5.15.0-1
ii  libkf5xmlgui5   5.15.0-1
ii  libktpcommoninternals9  15.08.2-3
ii  libktplogger9   15.08.2-3
ii  libktpmodels9   15.08.2-3
ii  libktpotr9  15.08.2-3
ii  libktpwidgets9  15.08.2-3
ii  libqt5core5a5.5.1+dfsg-8
ii  libqt5dbus5 5.5.1+dfsg-8
ii  libqt5gui5  5.5.1+dfsg-8
ii  libqt5webkit5   5.5.1+dfsg-2
ii  libqt5widgets5  5.5.1+dfsg-8
ii  libqt5xml5  5.5.1+dfsg-8
ii  libstdc++6  5.2.1-23
ii  libtelepathy-qt5-0  0.9.6.1-3

Versions of packages kde-telepathy-text-ui recommends:
ii  kde-telepathy  15.08.2

kde-telepathy-text-ui suggests no packages.

-- no debconf information



Bug#804801: RFS: libjdns/2.0.3-1 [ITP]

2015-11-18 Thread Gianfranco Costamagna
Control: owner -1 !
Control: tags -1 moreinfo

Hi Stefan,
>Thank you for your hint. I tried to adjust the debian/rules. I've
>uploaded the package. Could you please review this package again?

sure, here we go:

first: congrats for the packaging skills, it wasn't an easy package, but seems 
that you did
it correctly.

lets review:

1) changelog: urgency=low would be preferred for a new package

2) control:
libqjdns-qt5-2, can't it be called libqjdns2-qt5 maybe?
(I'm not asking to change it, but to investigate, probably lintian will 
complain if the naming is wrong, that means that
it is currently fine)

Package: libqjdns-qt5-2

Depends: libjdns2, ${misc:Depends}, ${shlibs:Depends}

I did an ldd of the qt5 library, and I see it depende from libjdns2 already.
So I guess you can remove the "libjdns2" dependency because it should be taken 
care of in shlibs:Depends(please check the built package, inside DEBIAN/control 
file)


3) debian/rules: it looks really nice, maybe I would override the clean target 
to remove the build directories.
4) debian/copyright: I would avoid licensing the debian packaging under GPL-3+ 
and upstream as MIT.
this makes impossible to e.g. forward patches upstream (withour relicensing 
them)

if possible I would ask you to use MIT, the same as upstream (that way 
everybody might be able to forward patches from you
without asking to relicense them)


5) you ship usr/bin/jdns as part of libqjdns-qt4 package, but ldd shows that 
links qt5 stuff.
ldd jdns  |grep Qt5 -i
libqjdns-qt5.so.2 => not found
libQt5Network.so.5 => not found
libQt5Core.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 (0xf723)


so please choose: move in the qt5 package, move in the base package (maybe 
dropping the qt stuff), or fix it somewhat else.

this "problem" makes the qt4 package drag all the qt5 dependencies.

the other stuff looks good to me.

(I did a test build on a clean machine with some of the above fixes)


oh and please convert your package to multiarch (needs investigation and a 
probable trivial change)
https://wiki.debian.org/Multiarch/Implementation
(be careful about usr/bin)

lintian:
X: libqjdns-qt5-2: application-in-library-section libs usr/bin/jdns
W: libqjdns-qt5-2: binary-without-manpage usr/bin/jdns (help2man is a good 
starting point)

check-all-the-things output:

$ codespell --quiet-level=3
./CMakeLists.txt:91: prefered  ==> preferred

(maybe report it upstream, no need to patch of course)


cheers,

G.



Bug#804660: NMU

2015-11-18 Thread Jo Shields
I have prepared an NMU for this fix (attached), and uploaded to DELAYED/10
diff -u coco-cs-20110419/debian/changelog coco-cs-20110419/debian/changelog
--- coco-cs-20110419/debian/changelog
+++ coco-cs-20110419/debian/changelog
@@ -1,3 +1,10 @@
+coco-cs (20110419-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for CLR 4.5 transition (Closes: #804660)
+
+ -- Jo Shields   Wed, 18 Nov 2015 12:32:33 +
+
 coco-cs (20110419-5) unstable; urgency=low
 
   * Switched to CLR 4.0 (Closes: #656690)


Bug#805458: intel-cmt-cat: please list requirements in the package description

2015-11-18 Thread Stephen Kitt
Package: intel-cmt-cat
Version: 0.1.3-1
Severity: wishlist

Hi Colin,

Thanks for packaging intel-cmt-cat! It would be nice if the package
description was more specific than "modern Intel Xeon processors";
perhaps something like "on modern Intel Xeon processors: Xeon D, Xeon
E5v3, low-voltage Xeon E3v4, or later models".

Regards,

Stephen (running a Xeon E3v3)

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

Kernel: Linux 4.2.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
Init: systemd (via /run/systemd/system)

Versions of packages intel-cmt-cat depends on:
ii  libc6  2.19-22

intel-cmt-cat recommends no packages.

intel-cmt-cat suggests no packages.

-- no debconf information



Bug#805457: "We've detected you're using an older version of Chrome. Update to stay secure"

2015-11-18 Thread 積丹尼 Dan Jacobson
Package: midori
Version: 0.5.11-2
Severity: wishlist

$ midori https://www.google.com/?hl=en
says

"We've detected you're using an older version of Chrome. Update to stay secure"



Bug#805459: iptables-converter-doc: Package description truncated and confusing

2015-11-18 Thread Beatrice Torracca
Package: iptables-converter-doc
Severity: minor

Hi!

the description of the package iptables-converter-doc now reads:

«iptables-converter: convert iptables from file to iptables-save format
ip6tables-converter mentioned »

and that it is all.

I think at the very least it's truncated, but I think even what it is
there is kinda confusing.

Thanks,

beatrice



Bug#805445: Static IPv6 Default Route not configured

2015-11-18 Thread Guus Sliepen
On Wed, Nov 18, 2015 at 11:28:49AM +0100, Jeroen Massar wrote:

> Debian stable 0.7.53.1, I avoid Ubuntu like a plague :)
[...]
> Note that we zero out /etc/sysctl.d/10-ipv6-privacy.conf (empty file
> with just comments) to avoid privacy parameters to be set (Ubuntu
> actually does do that, not sure if Debian does, don't think so though)

Hm, there is no /etc/sysctl.d/10-ipv6-privacy.conf in a default Debian
install.

> 8<-
> $ cat /etc/sysctl.d/99-custom.conf
> # Disable Accept of Router Advertisements
> net.ipv6.conf.all.accept_ra=0
> net.ipv6.conf.default.accept_ra=0
> 
> # Make sure that privacy addresses are disabled
> net.ipv6.conf.default.use_tempaddr=0
> net.ipv6.conf.all.use_tempaddr=0
> ->8

Ok, tried it with and without these settings, but on a fresh install
setting the IPv6 address, netmask and gateway just works as expected,
both on Debian stable and unstable.

> That might thus be a kernel annoyance, thus just in case on that box the
> version of that:
> 
>  linux-image-3.16.0-4-686-pae  3.16.7-ckt11-1+deb8u6 i386

I have the exact same version. Well, running on amd64, but I would think
that this is not a 32 vs. 64 bits issue.

> hm you are not toggling use_tempaddr I hope as that would cause
> default route to be cleared by the kernel (some kernels do that, others
> do not btw...)?
> 
> Indeed using the accept_ra etc settings in /etc/network/interfaces would
> be a good thing, but the current sysctl method has worked for a long
> long time already and a static config should just work like that.

Actually, even if you don't explicitly specify accept_ra in /e/n/i, ifup
will set accept_ra and autoconf to 0 before configuring the IPv6 part of
the interface. The output of ifup -v eth0 in my Debian stable vm is:

Configuring interface eth0=eth0 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d

dhclient -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases eth0  
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/52:54:00:12:34:56
Sending on   LPF/eth0/52:54:00:12:34:56
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.2.2
DHCPACK from 10.0.2.2
bound to 10.0.2.15 -- renewal in 39089 seconds.
run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/upstart
Configuring interface eth0=eth0 (inet6)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.

sysctl -q -e -w net.ipv6.conf.eth0.accept_ra=0
sysctl -q -e -w net.ipv6.conf.eth0.autoconf=0
ip link set dev eth0   up
ip -6 addr add 2001:db8:ff:1234::42/64  dev eth0 
 ip -6 route add default via 2001:db8:ff:1234::1 dev eth0 
/lib/ifupdown/settle-dad.sh
Waiting for DAD... Done
run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/upstart

So the problem is elsewhere, I think. Or maybe you have more interfaces,
and something might interfere with the default gateway set by a previous
one? Maybe you should try running ifdown -a; ifup -v -a; yourself and
see what the output is? You can send me a copy as well if you want.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature


Bug#767325: Please package a new upstream release, really

2015-11-18 Thread Fabian Greffrath
Dear Printing Team,

HPLIP 3.15.x is required for the printer that I just bought yesterday.
I have seen that this version is already packaged for Ubuntu and it's
nice to see that all bug reports requesting its upload to Debian are
tagged as "pending" dating back to 22 Feb 2015.

But what would help even more would be an estimate date when this
package will be available. Or, even better, what is missing in Debian
that delays the upload? What is keeping you from uploading?

How can I help?

Thank you!

 - Fabian


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


Bug#805437: [Pkg-xfce-devel] Bug#805437: Bug#805437: light-locker build-depends unsatisfiable in testing and only satisfiable using cruft packages in unstable

2015-11-18 Thread Yves-Alexis Perez
On mer., 2015-11-18 at 13:43 +0100, Yves-Alexis Perez wrote:
> On mer., 2015-11-18 at 08:08 +, peter green wrote:
> > Package: light-locker
> > Severity: serious
> > 
> > The latest upload of light-locker added a build-dependency on 
> > libsystemd-login-dev .
> > 
> > libsystemd-login-dev is no longer built by the systemd source package 
> > and is not available in testing.
> > 
> Thanks for the notice, I'll update the build-dependency.
> 
Actually there's an issue: the upstream package still checks for libsystemd-
login library (which doesn't exist anymore at all, I guess). I'll need to
investigate a bit more.

Regards,
-- 
Yves-Alexis



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


Bug#805445: Static IPv6 Default Route not configured

2015-11-18 Thread Jeroen Massar
On 2015-11-18 11:12, Guus Sliepen wrote:
> severity 805445 important
> thanks
> 
> On Wed, Nov 18, 2015 at 10:16:29AM +0100, Jeroen Massar wrote:
> 
>> Package: ifupdown
>> Version: 0.7.53.1
>> Severity: critical
>>
>> Marking critical as it breaks IPv6 connectivity after a reboot, thus
>> hope you got IPv4 still (or KVM :) if it is a remote machine ;)
> 
> It's not dropping your SQL tables or blowing up your house, so:
> 
> important
> a bug which has a major effect on the usability of a package,
> without rendering it completely unusable to everyone.

Well actually there are folks with IPv6 only connectivity (or IPv4
behind NAT or worse CGN) and no KVM access (which is silly but still)
thus they would lose access to the host if it would restart.

There are then also people who manage their home heater system with it
and thus won't be able to access that remotely thus it could blow up
your house ;)

Hence, why I think that it should be a priority to look at.
But "important" works too.

>> See Ubuntu bug report here:
>> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1510098
> 
> Did you try this on a Debian system or on Ubuntu?

Debian stable 0.7.53.1, I avoid Ubuntu like a plague :)


$ apt-cache policy ifupdown
ifupdown:
  Installed: 0.7.53.1
  Candidate: 0.7.53.1
  Version table:
 *** 0.7.53.1 0
500 http://mirror.switch.ch/ftp/pub/debian/ stable/main amd64
Packages
100 /var/lib/dpkg/status

> And in either case, which version?

See original version above and just the text above.

> Then I can try it out in a VM and try to find the cause.

Awesome, please do. I would btw not be surprised if this is related to
having accept_ra set to 0 in sysctl as it should be for server systems.

> It would also be helpful to see your full /etc/network/interfaces,
> without any addresses censored if possible, so I can see if it might be
> caused by any scoping issues.

I am quite good with scoping issues, don't worry about that. Some of the
boxes I had this problem on where running fine for over 10 years...

It is a bog standard config, did not include it as the bog the same
details for the ubuntu bug report apply. But let me give you a simple
version:

8<-
# The loopback interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.200.42
netmask 255.255.255.0
gateway 198.168.200.1

iface eth0 inet6 static
address 2001:db8:ff:1234::42
netmask 64
gateway 2001:db8:ff:1234::1
->8


Note that we zero out /etc/sysctl.d/10-ipv6-privacy.conf (empty file
with just comments) to avoid privacy parameters to be set (Ubuntu
actually does do that, not sure if Debian does, don't think so though)

8<-
$ cat /etc/sysctl.d/99-custom.conf
# Upgrade the TCP backlog quite a bit
net.ipv4.tcp_max_syn_backlog=8192

# Disable Accept of Router Advertisements
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.default.accept_ra=0

# Disable source routing
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.all.accept_source_route=0

# Disable ICMP ratelimitting
# There are so many people who seemingly need to monitor
# SixXS boxes, that these limits are triggered all the time
net.ipv4.icmp_ratelimit=0
net.ipv4.icmp_ratemask=0
net.ipv6.icmp.ratelimit=0

# Make sure that privacy addresses are disabled
net.ipv6.conf.default.use_tempaddr=0
net.ipv6.conf.all.use_tempaddr=0
->8

Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file
mentioned above) and then when sysctl this custom file the setting is
reverted and you lose your default...

hmmm, that might actually be affecting this too now I think of it.

But the sysctl stuff should run BEFORE ifupdown comes into play (hence
setting default+all so that existing and new interfaces get that setting).

That might thus be a kernel annoyance, thus just in case on that box the
version of that:

 linux-image-3.16.0-4-686-pae  3.16.7-ckt11-1+deb8u6 i386


hm you are not toggling use_tempaddr I hope as that would cause
default route to be cleared by the kernel (some kernels do that, others
do not btw...)?

Indeed using the accept_ra etc settings in /etc/network/interfaces would
be a good thing, but the current sysctl method has worked for a long
long time already and a static config should just work like that.

>> Btw,
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ifupdown;dist=unstable
>> mentions that Guus is the maintainer while the package field has Andrew
>> listed... there is a LOT of wishlist bugs there that could just be
>> closed even though they are from ~2001
> 
> Yes, I took over but Andrew is also still contributing. I have been
> going through old bugs, most can indeed be closed, but there are also
> some bugs worth fixing (even wishlist bugs from a decade ago).

I saw the commit log, I am sure you'll fight through them :)
Good luck and thanks for working on it!

Greets,
 Jeroen



Bug#805444: multipath-tools: Installation fails with "Unit blk-availability.service failed to load"

2015-11-18 Thread Michel Meyers
On 2015-11-18 10:51, Ritesh Raj Sarraf wrote:
> Please share the content of multipath-tools.service file.
> 
> My guess is that you are using the .service file from a different
> source.


Here's the content:

[Unit]
Description=Device-Mapper Multipath Device Controller
Requires=blk-availability.service
Before=iscsi.service iscsid.service lvm2-activation-early.service
Before=local-fs-pre.target
After=multipathd.socket
DefaultDependencies=no
Wants=local-fs-pre.target multipathd.socket
Conflicts=shutdown.target

[Service]
Type=notify
NotifyAccess=main
LimitCORE=infinity
ExecStartPre=/sbin/modprobe dm-multipath
ExecStart=/sbin/multipathd -d -s
ExecReload=/sbin/multipathd reconfigure

[Install]
WantedBy=sysinit.target
Also=multipathd.socket
Alias=multipath-tools.service


This appears to match the content of the respective file from the
archive here:
https://packages.debian.org/stretch/amd64/multipath-tools/download



Bug#805445: Static IPv6 Default Route not configured

2015-11-18 Thread Guus Sliepen
On Wed, Nov 18, 2015 at 11:28:49AM +0100, Jeroen Massar wrote:

> > It's not dropping your SQL tables or blowing up your house, so:
> > 
> > important
> > a bug which has a major effect on the usability of a package,
> > without rendering it completely unusable to everyone.
> 
> Well actually there are folks with IPv6 only connectivity (or IPv4
> behind NAT or worse CGN) and no KVM access (which is silly but still)
> thus they would lose access to the host if it would restart.

I agree, and if anyone is using IPv6-only connectivity I would expect it
to be you :)

> There are then also people who manage their home heater system with it
> and thus won't be able to access that remotely thus it could blow up
> your house ;)

Yes, but even if ifupdown works you cannot assume that your network
works. Severity critical is for when one package starts overwriting
files from another package, or something else that breaks the OS. But if
the package just doesn't work it's not "critical" for Debian, even
though it might be for a user who depends on it.

> >> See Ubuntu bug report here:
> >> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1510098
> > 
> > Did you try this on a Debian system or on Ubuntu?
> 
> Debian stable 0.7.53.1, I avoid Ubuntu like a plague :)

Ok.

> > Then I can try it out in a VM and try to find the cause.
> 
> Awesome, please do. I would btw not be surprised if this is related to
> having accept_ra set to 0 in sysctl as it should be for server systems.
[...]

Aha, that might indeed affect things. Thanks for providing the details,
that will help find the problem much quicker :)

> Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file
> mentioned above) and then when sysctl this custom file the setting is
> reverted and you lose your default...
> 
> hmmm, that might actually be affecting this too now I think of it.
> 
> But the sysctl stuff should run BEFORE ifupdown comes into play (hence
> setting default+all so that existing and new interfaces get that setting).

Yes. Maybe it could also have something to do with DAD. I'll try it out
with the settings you have and poke around until I find the culprit,
then see how I can have ifupdown work around it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature


Bug#805392: pbuilder: debdelta-upgrade invocation seems incorrect

2015-11-18 Thread Mattia Rizzolo
control: tags -1 + pending

On Wed, Nov 18, 2015 at 11:33:10AM +0530, Ritesh Raj Sarraf wrote:
> On Tue, 2015-11-17 at 19:52 +, Mattia Rizzolo wrote:
> > -    if $CHROOTEXEC hash debdelta-upgrade 2> /dev/null ; then
> > +    if $CHROOTEXEC bash -c "hash debdelta-upgrade 2> /dev/null" ;

> That seems to be the correct root cause.


cool

Though the whole purpose of using `hash` was to avoid spawing yet
another process...  I think would make more sense to switch to it.
Here:
mattia@chase ~ % time /usr/bin/which cat > /dev/null 2>&1
/usr/bin/which cat > /dev/null 2>&1  0.00s user 0.00s system 0% cpu 0.001 total
mattia@chase ~ % time /bin/bash -c "hash cat"
/bin/bash -c "hash cat"  0.00s user 0.00s system 0% cpu 0.004 total

which is quite a difference (clearly spawing a full shell is harder..
even if /bin/which is actually a shell script)
(ok, we're talking about 0.003 seconds, but today I feel like checking
also those :))

So, instead I just committed

-if $CHROOTEXEC hash debdelta-upgrade 2> /dev/null ; then
+if $CHROOTEXEC which debdelta-upgrade > /dev/null 2>&1 ; then

which should also make easier to understand to non-bash-savy users.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#804258: Fwd: RE: [E1000-devel] igb / ixgbe : differences between mainline and out-of-tree drivers

2015-11-18 Thread Clement Hermann
[Cross posting to both RFS and ITP bugs, since it's relevant to both]

Hi,

there weren't any new message on the thread I started on upstream
mailing list for a week, so I guess it's time to relay.

The complete response I received is included below, at the end of the
message.

To summarize:
- RSS, EEE, InterruptThrottleRate and QueuePair can be achieve via ethtool
- LLI parameters won't, but this is considered a rarely used feature,
not supported by recent hardware
- InterruptMode is mainly used for debug, since the driver should select
the best interrupt mode available
- VDMQ, MDD and DMAC aren't supported via ethtool and probably never will.

I personally can manage what I need with ethtool, but I'm willing to
maintain this package anyway since I already use kernel parameters
(easier to use than ethtool, although less dynamic). Also people could
find the parameters not supported by ethtool useful.

Of course I'll understand if it's not acceptable for Debian. Advice and
input welcome. I updated the version on mentor to reflect this in the
description.

Cheers,

nodens

 Message transféré 
Sujet : RE: [E1000-devel] igb / ixgbe : differences between mainline
and out-of-tree drivers
Date :  Tue, 10 Nov 2015 18:26:42 +
De :Tantilov, Emil S 
Pour :  Clement Hermann ,
e1000-de...@lists.sourceforge.net 



>-Original Message-
>From: Clement Hermann [mailto:nod...@nodens.org]
>Sent: Tuesday, November 10, 2015 3:51 AM
>To: e1000-de...@lists.sourceforge.net
>Subject: [E1000-devel] igb / ixgbe : differences between mainline and out-
>of-tree drivers
>
>Hi,
>
>I'm trying to understand the differences between the out-of-tree and the
>mainline version for igb and ixgbe drivers.
>
>The issue is, I packaged the out-of-tree version for debian, but there
>are concerns from the kernel team for allowing to maintain an
>out-of-tree driver since most features should be in the mainline driver.
>
>(see discussion on
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804258 and
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804283)
>
>AFAICS, the main difference is that the mainline driver doesn't support
>configuration via modules parameter.

Except for rare cases the community is against using module parameters and 
in favor of using generic tools to control the behavior of the Ethernet drivers.

>Some parameters can be controled with ethtool on mainline version:
>
> - EE: ethtool --set-eee
> - RSS: ethtool -X
>
>For some I'm unsure:
>
> - InterruptThrottleRate: ethtool -C ? Not sure if the same is achieved.
>Input welcome.
> - QueuePairs: Seems like it could be done with ethtool -L ?

That's right. 

>Other don't seen to be:
> - IntMode:Change Interrupt Mode

The driver will pick the best available interrupt mode. This parameter is
more useful for debugging than anything else. There are also ways to limit the 
support from the kernel command line, but that is usually not a good idea.

> - Node:set the starting node to allocate memory on

The driver is designed to allocate memory from the nearest NUMA node.
If I remember correctly this parameter was rejected by the community when we 
proposed it. I think this is a leftover in igb, ixgbe does not have this 
parameter.

> - LLIPort:Low Latency Interrupt TCP Port
> - LLIPush:Low Latency Interrupt on TCP Push flag
> - LLISize:Low Latency Interrupt on Packet Size

The LLI parameters are not generic and are no longer supported in newer HW.
There is no ethtool alternative, but we haven't seen much use of them either.

> - VMDQ:Number of Virtual Machine Device Queues
> - MDD:Malicious Driver Detection
> - DMAC: Disable or set latency for DMA Coalescing
>
>Will these functions be available via ethtool in the mainline driver
>someday ?

We always try to determine if a certain parameter can be exposed via method 
other
than a module parameter, but not all of the functionality has an equivalent 
option
in ethtool. Also some parameters are introduced as a way to test new 
functionality.

Thanks,
Emil







signature.asc
Description: OpenPGP digital signature


Bug#805444: multipath-tools: Installation fails with "Unit blk-availability.service failed to load"

2015-11-18 Thread Ritesh Raj Sarraf
On Wed, 2015-11-18 at 11:01 +0100, Michel Meyers wrote:
> 
> This appears to match the content of the respective file from the
> archive here:
> https://packages.debian.org/stretch/amd64/multipath-tools/download

Thanks Michel. That indeed needs to be fixed.

But that made me wonder how my test box had a working multipath setup.


root@debian-btrfs:~# multipath -ll
36001405c2d2d9a03751406691395e741 dm-0 LIO-ORG,IBLOCK
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 3:0:0:0 sdc 8:32 active ready running
  `- 4:0:0:0 sdb 8:16 active ready running
36001405226c2409d98a4e35ba427b274 dm-1 LIO-ORG,IBLOCK
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 3:0:0:1 sde 8:64 active ready running
  `- 4:0:0:1 sdd 8:48 active ready running
root@debian-btrfs:~# multipath^C
root@debian-btrfs:~# ps aux | grep -i multipathd
root  1809  0.0  0.8 524960  8836 ?SLl  17:08   0:00 
/sbin/multipathd
root  2113  0.0  0.2  12732  2216 pts/0S+   17:11   0:00 grep
-i multipathd


root@debian-btrfs:~# /etc/init.d/multipath-tools status
[ ok ] multipathd is running.

So it seems to be running

root@debian-btrfs:~# which init
/sbin/init
root@debian-btrfs:~# dpkg -S /sbin/init
sysvinit-core: /sbin/init

And this is the reason why I didn't notice this bug.


So. I'll look into it soon (but it may take some time). Meanwhile, if
you have any suggestions/fixes/patches, please add them to this bug
report.

Thanks,
Ritesh


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



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


Bug#805461: libavahi1.0-cil: Rebuild required for Mono transition

2015-11-18 Thread Jo Shields
Package: libavahi1.0-cil
Version: 0.6.19-4.2
Severity: important

Dear Maintainer,

As part of the mono transition, a rebuild of avahi-sharp is required.



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#805445: Static IPv6 Default Route not configured

2015-11-18 Thread Jeroen Massar
On 2015-11-18 11:46, Guus Sliepen wrote:
[..]
>> Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file
>> mentioned above) and then when sysctl this custom file the setting is
>> reverted and you lose your default...
>>
>> hmmm, that might actually be affecting this too now I think of it.
>>
>> But the sysctl stuff should run BEFORE ifupdown comes into play (hence
>> setting default+all so that existing and new interfaces get that setting).
> 
> Yes. Maybe it could also have something to do with DAD.

>From my POV DAD does not come into play there, and also the kernel would
log it.

> I'll try it out with the settings you have and poke around until I
find the culprit,
> then see how I can have ifupdown work around it.

I did not check the code thus maybe it does it already but checking the
setting if accept_ra is going to be toggled might be a good thing.

Of course if is accept_ra toggle related (losing the default route) then
that is clearly a kernel thing, not much ifupdown could do about.

Greets,
 Jeroen



Bug#805458: intel-cmt-cat: please list requirements in the package description

2015-11-18 Thread Colin Ian King
Hi Stephen,

Good idea, I'll fix that right away.

Colin

On 18/11/15 11:29, Stephen Kitt wrote:
> Package: intel-cmt-cat
> Version: 0.1.3-1
> Severity: wishlist
> 
> Hi Colin,
> 
> Thanks for packaging intel-cmt-cat! It would be nice if the package
> description was more specific than "modern Intel Xeon processors";
> perhaps something like "on modern Intel Xeon processors: Xeon D, Xeon
> E5v3, low-voltage Xeon E3v4, or later models".
> 
> Regards,
> 
> Stephen (running a Xeon E3v3)
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.2.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
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages intel-cmt-cat depends on:
> ii  libc6  2.19-22
> 
> intel-cmt-cat recommends no packages.
> 
> intel-cmt-cat suggests no packages.
> 
> -- no debconf information
> 



Bug#804060: iceweasel: SIGPIPE when running under KDE

2015-11-18 Thread Arthur Marsh
Package: iceweasel
Version: 38.4.0esr-1
Followup-For: Bug #804060

Dear Maintainer,

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

   * What led up to the situation?
running iceweasel under gdb under KDE

gdb iceweasel
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from iceweasel...Reading symbols from 
/usr/lib/debug//usr/lib/iceweasel/iceweasel...done.
done.
(gdb) run
Starting program: /usr/bin/iceweasel 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe8d49700 (LWP 6821)]
[Thread 0x7fffe8d49700 (LWP 6821) exited]

(process:6811): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed
[New Thread 0x7fffe8d49700 (LWP 6826)]
[New Thread 0x7fffdeff2700 (LWP 6827)]
[New Thread 0x7fffde7f1700 (LWP 6828)]
[New Thread 0x7fffddff0700 (LWP 6829)]
[New Thread 0x7fffddbf3700 (LWP 6830)]
[New Thread 0x7fffddb72700 (LWP 6831)]
[New Thread 0x7fffddaf1700 (LWP 6832)]
[New Thread 0x7fffdda70700 (LWP 6833)]
[New Thread 0x7fffdd9ef700 (LWP 6834)]
[New Thread 0x7fffdd96e700 (LWP 6835)]
[New Thread 0x7fffdd8ed700 (LWP 6836)]
[New Thread 0x7fffdc7ff700 (LWP 6837)]
[New Thread 0x7fffdbb7a700 (LWP 6838)]
[New Thread 0x7fffdb379700 (LWP 6839)]
[New Thread 0x7fffda4a2700 (LWP 6840)]
[New Thread 0x7fffd9ca1700 (LWP 6841)]
[New Thread 0x7fffd94a0700 (LWP 6842)]
[New Thread 0x7fffd8c9f700 (LWP 6844)]
[New Thread 0x7fffd80ff700 (LWP 6845)]
[New Thread 0x7fffda73e700 (LWP 6846)]
[Thread 0x7fffd94a0700 (LWP 6842) exited]
[New Thread 0x7fffd94a0700 (LWP 6847)]
[New Thread 0x7fffd6dff700 (LWP 6848)]

Program received signal SIG38, Real-time event 38.
0x77bcdadd in read () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) continue
Continuing.
[New Thread 0x7fffd4aff700 (LWP 6849)]
[New Thread 0x7fffd42fe700 (LWP 6850)]
[New Thread 0x7fffd3dff700 (LWP 6851)]
[New Thread 0x7fffd35fe700 (LWP 6852)]
[New Thread 0x7fffd2dfd700 (LWP 6853)]
[New Thread 0x7fffd25fc700 (LWP 6854)]
[New Thread 0x7fffd1dfb700 (LWP 6855)]
[New Thread 0x7fffd15fa700 (LWP 6856)]
[Thread 0x7fffd94a0700 (LWP 6847) exited]
[Thread 0x7fffd35fe700 (LWP 6852) exited]
[Thread 0x7fffd2dfd700 (LWP 6853) exited]
[New Thread 0x7fffd09ff700 (LWP 6857)]
[New Thread 0x7fffd01fe700 (LWP 6858)]
[New Thread 0x7fffcf7ff700 (LWP 6859)]
[New Thread 0x7fffceffe700 (LWP 6860)]
[Thread 0x7fffd25fc700 (LWP 6854) exited]
[New Thread 0x7fffd25fc700 (LWP 6861)]
[Thread 0x7fffd25fc700 (LWP 6861) exited]
[New Thread 0x7fffd25fc700 (LWP 6862)]
[New Thread 0x7fffcdcff700 (LWP 6863)]
[Thread 0x7fffd15fa700 (LWP 6856) exited]
[New Thread 0x7fffd15fa700 (LWP 6864)]
[New Thread 0x7fffd94a0700 (LWP 6865)]
[New Thread 0x7fffd35fe700 (LWP 6866)]
[Thread 0x7fffd25fc700 (LWP 6862) exited]
[Thread 0x7fffd94a0700 (LWP 6865) exited]
[Thread 0x7fffd35fe700 (LWP 6866) exited]
[New Thread 0x7fffd25fc700 (LWP 6867)]
[Thread 0x7fffd15fa700 (LWP 6864) exited]
[New Thread 0x7fffd15fa700 (LWP 6868)]
[Thread 0x7fffd15fa700 (LWP 6868) exited]
[New Thread 0x7fffd15fa700 (LWP 6869)]
[Thread 0x7fffd25fc700 (LWP 6867) exited]
[New Thread 0x7fffd25fc700 (LWP 6870)]
[Thread 0x7fffd15fa700 (LWP 6869) exited]
[New Thread 0x7fffd15fa700 (LWP 6871)]
[Thread 0x7fffd25fc700 (LWP 6870) exited]
[New Thread 0x7fffd25fc700 (LWP 6872)]
[Thread 0x7fffd15fa700 (LWP 6871) exited]
[New Thread 0x7fffd15fa700 (LWP 6873)]
[New Thread 0x7fffd94a0700 (LWP 6874)]
console.error: 
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
[Thread 0x7fffd25fc700 (LWP 6872) exited]
[New Thread 0x7fffd25fc700 (LWP 6875)]
[New Thread 0x7fffd35fe700 (LWP 6876)]
console.error: 
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
[New Thread 0x7fffd2dfd700 (LWP 6877)]
[New Thread 0x7fffc8af2700 (LWP 6878)]
[New Thread 0x7fffc82f1700 (LWP 6879)]
[Thread 0x7fffd9ca1700 (LWP 6841) exited]
[New Thread 0x7fffd9ca1700 (LWP 6880)]
[New Thread 0x7fffc46ff700 (LWP 6881)]
[New Thread 0x7fffc3cf8700 (LWP 6882)]
[New Thread 0x7fffc34f7700 (LWP 6883)]
[New Thread 0x7fffc04ff700 (LWP 6884)]
[New 

  1   2   3   >