Bug#817117: ldirectord does fail, so the installation cannot finish

[Michael Schwartzkopff]

Package: ldirectord
Version: 1:3.9.7-1
Severity: normal

Dear Maintainer,

The installation of ldirectord-3.9.7-1 from the testing repository
on a fresh installaed Jessie machine fails.

After intstallation the installaer wants to start the ldirectord service.
But since no configuration file exists at /et/ha.d/ldirectord.cf the start
fails. with this failure the whole installation process fails.

After a apt-get install ldirectord you are left with a 

iF ldirectord 1:3.9.7-1 all Monitors virtual services provided by LVS

Solution:
Put a dummy configuration file to /etc/ha.d/ldirectord.cf or
prevent the automatic start during installation.


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

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

Versions of packages ldirectord depends on:
ii  init-system-helpers   1.22
ii  ipvsadm   1:1.28-3
ii  libauthen-radius-perl 0.24-1
ii  libcrypt-ssleay-perl  0.73.04-1+b1
ii  libdbi-perl   1.634-1+b1
ii  libdigest-hmac-perl   1.03+dfsg-1
ii  libmail-pop3client-perl   2.19-1
ii  libmailtools-perl 2.13-1
ii  libnet-dns-perl   0.81-2+b1
ii  libnet-imap-simple-perl   1.2206-1
ii  libnet-imap-simple-ssl-perl   1.3-3
ii  libnet-ldap-perl  1:0.6500+dfsg-1
ii  libperl5.22 [libdigest-md5-perl]  5.22.1-7
ii  libsocket6-perl   0.25-1+b2
ii  libwww-perl   6.08-1
ii  perl  5.22.1-7
ii  perl-modules-5.22 [libnet-perl]   5.22.1-7

Versions of packages ldirectord recommends:
ii  logrotate3.8.7-1+b1
ii  rsyslog [system-log-daemon]  8.4.2-1+deb8u2

ldirectord suggests no packages.

-- debconf information:
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at 
/usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 
30.

Bug#817086: [Pkg-privacy-maintainers] Bug#817086: clicking on circuits doesn't show any info

[Paul Wise]

On Tue, 2016-03-08 at 07:11 +, Sascha Steinbiss wrote:

> It looks like you chose not to install tor’s recommended tor-geoipdb package.

I have recommends turned off by default.

> I feel that it might be worthwhile to make onioncircuits itself a bit
> more robust if geoipdb is missing. 

Agreed.

> I have created a patch to check for this error (see attached) and
> will forward it upstream.

This would print (?) next to the IP address for every hop. I would go
with a slightly different set of changes; don't show the country next
to the IP address unless country info is available and have a text item
suggesting to install the Tor GeoIP DB if it is missing.

> Also, I’ll make onioncircuits suggest tor-geoipdb. Any comments?

Recommends or Suggests seems reasonable.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817086: [Pkg-privacy-maintainers] Bug#817086: clicking on circuits doesn't show any info

[Sascha Steinbiss]

Dear Paul,

thanks for the bug report.

> When I click on circuits onioncircuits doesn't show any info and I get
> this traceback in the terminal.
[…]
>   File "/usr/lib/python3/dist-packages/stem/response/getinfo.py", line 40, in 
> _parse_message
> raise stem.ProtocolError("GETINFO response didn't have an OK status:\n%s" 
> % self)
> stem.ProtocolError: GETINFO response didn't have an OK status:
> GeoIP data not loaded

It looks like you chose not to install tor’s recommended tor-geoipdb package. I 
can reproduce this issue if I manually remove tor-geoipdb on my system. Making 
tor-geoipdb (and hence tor itself) a dependency of onioncircuits would remedy 
this, but I feel that it might be worthwhile to make onioncircuits itself a bit 
more robust if geoipdb is missing. 
I have created a patch to check for this error (see attached) and will forward 
it upstream.
Also, I’ll make onioncircuits suggest tor-geoipdb. Any comments?

Cheers
Sascha



allow-failing-country-lookup.patch
Description: Binary data

Bug#817006: ack to NMU

[Adam Borowski]

On Tue, Mar 08, 2016 at 04:31:24PM +0900, Benda Xu wrote:
> Basically, my taking to this bug is to ignore it, leaving the users to
> fix the breakage by
> 
>   dpkg-divert --remove /usr/sbin/invoke-rc.d
>   dpkg-divert --remove /usr/sbin/update-rc.d
> 
> manually.  
> 
> 0.20.4-1 lasted only 10days.  Only few users would be affected.

The popcon for openrc is 83, which, assuming that 10% of users run popcon
(a wild-ass guess) means 830 users.  I have no idea what part of this is
unstable, but as openrc in Debian is quite experimental, I guess quite a
bunch of such users are affected.

The breakage is pretty severe -- it does match the description of "critical"
after all.  Every affected user would have to research the fix and apply
it manually.  Thus, I don't think it's a good idea to ignore this bug,
especially that the fix is easy.

> That said, I understand theoretically your NMU is the correctly way to
> go.  So if you intend to do so, consider this email as an ack to NMU
> from the maintainer team.

I'll upload it then.

> One thing to notice is that we are tracking the package at
> 
>   http://anonscm.debian.org/cgit/openrc/openrc.git
> 
> Would you mind if I ask you to prepare a commit to the master
> corresponding to the NMU?

Of course.  I don't have push rights to that repository, so two commits are
attached to this mail (one for the fix, one for changelog).

> BTW, if you are interested in OpenRC, you are welcomed to join the
> maintenance team.

I'm afraid I don't really know inner workings of openrc, I use it on only
one machine (which happens to be my main desktop, but still...).  Everywhere
else I'm on sysv-rc.  This said, keeping openrc viable seems important for
resisting systemd-ization of Debian so I probably should help in _some_ way.

> 1. 0.20.4-1 was uploaded in a hurry to keep itself in testing.  The pts
> system lied and we did not make it.  divert should not have existed in
> OpenRC.

It can be removed in some time, after the affected systems are fixed.


Meow!
-- 
A tit a day keeps the vet away.
>From b4653519c5109967be09976e1fbf431316d07dcf Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Tue, 8 Mar 2016 05:19:25 +0100
Subject: [PATCH 1/2] Remove dangling diverts introduced by 0.20.4-1.

---
 debian/openrc.postinst | 13 +
 1 file changed, 13 insertions(+)

diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 4d09a68..cd0284e 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -2,6 +2,19 @@
 
 set -e
 
+# Remove diverts made by 0.20.4-1
+if [ "$(dpkg-divert --list /usr/sbin/invoke-rc.d)" = \
+ "diversion of /usr/sbin/invoke-rc.d to /usr/sbin/invoke-rc.d.init-system-helpers by openrc" ]
+	then dpkg-divert --package openrc --remove --rename \
+		--divert /usr/sbin/invoke-rc.d.init-system-helpers /usr/sbin/invoke-rc.d
+fi
+if [ "$(dpkg-divert --list /usr/sbin/update-rc.d)" = \
+ "diversion of /usr/sbin/update-rc.d to /usr/sbin/update-rc.d.init-system-helpers by openrc" ]
+	then dpkg-divert --package openrc --remove --rename \
+		--divert /usr/sbin/update-rc.d.init-system-helpers /usr/sbin/update-rc.d
+fi
+
+
 if [ "${1}" = "configure" ] ; then
 	echo "Add existing services ..."
 
-- 
2.7.0

>From 26d115187fdb7d64cd0569ade30421216d210714 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Tue, 8 Mar 2016 05:20:10 +0100
Subject: [PATCH 2/2] release 0.20.4-2.1 into sid.

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 15aaae8..8e5269d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+openrc (0.20.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove diversions to update-rc.d + invoke-rc.d (Closes: #817006).
+
+ -- Adam Borowski   Tue, 08 Mar 2016 05:17:44 +0100
+
 openrc (0.20.4-2) unstable; urgency=high
 
   * Bump standard to 3.9.7.
-- 
2.7.0

Bug#817118: RFS: complexity/1.5+dfsg-1~bpo8+1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: complexity
  Version : 1.5+dfsg-1~bpo8+1
  Upstream Author : Bruce Korb 
* Url : https://gnu.org/software/complexity
* Licenses: GFLD-1.2+, GPL-3+
  Section : devel

It builds those binary packages:

complexity -- tool for analyzing the complexity of C program functions
complexity-doc -- tool for analyzing the complexity of C program 
(documentation)

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

http://mentors.debian.net/package/complexity

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


http://mentors.debian.net/debian/pool/main/c/complexity/complexity_1.5+dfsg-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/complexity.git

More information about complexity can be obtained from 
https://gnu.org/software/complexity

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Bug#816697: jessie-pu: package fonts-sil-andika/1.004-2+deb8u1

[Petter Reinholdtsen]

[Andreas Beckmann]
>> +rm_conffile /etc/fonts/conf.avail/65-andika.conf 1.004-2~ fonts-sil-andika
>
> That won't work as expected ... you will need a version of 1.004-2+deb8u2~
> otherwise that "fix" won't be applied to systems that already have
> 1.004-2 installed.

Ah, good point.  I did not remember to change that file after I decided
the package version number.  I'll upload a fixed version.

Thank you for noticing. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#817119: usrmerge: /etc/shells contains links to actual shells

[Michele Orru`]

Package: usrmerge
Version: 10
Severity: important

Dear Maintainer,

with usrmerge, some programs - such as pkexec, or LEAP's bitmask on top of that-
fails to run. Specifically, the error I get is:

The value for the SHELL variable was not found the /etc/shells file

and indeed my SHELL variable is set to "/usr/bin/bash", but /etc/shells
contains "/bin/bash". Adding $SHELL to /etc/shells solves the problem.

I would be happy to provide a patch for this if needed, but first: do you
acknowledge that this is a bug of usrmerge? I couldn't find anywhere that lines
of /etc/shells must not be symlinks.

Kind regards,

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

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

Versions of packages usrmerge depends on:
ii  debconf [debconf-2.0]   1.5.58
ii  libfile-find-rule-perl  0.34-1

usrmerge recommends no packages.

usrmerge suggests no packages.

-- debconf information:
  usrmerge/title:
  usrmerge/autoconvert: true

Bug#817120: ITP: python-pylxd -- Python library for interacting with LXD REST API

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pylxd
  Version : 2.0.0~b1
  Upstream Author : Canonical Ltd
* URL : https://github.com/lxd/pylxd
* License : Apache-2.0
  Programming Lang: Python
  Description : Python library for interacting with LXD REST API

 LXD offers a REST API to remotely manage containers over the network, using an
 image based workflow and with support for live migration.
 .
 pylxd is a small Python library for interacting the with the LXD REST API.

Note from maintainer: this is a new dependency for Manila, the file share as a
service of OpenStack. I am currently unsure if I will maintain LXD itself in
Debian, this is currently an ongoing discussion.

Bug#817041: librem0: Missing run-time dependency on libre0

[Vasudev Kamath]

Guillem Jover  writes:

> Package: librem0
> Version: 0.4.7-1
> Severity: serious
>
> Hi!
>
> This package provides a shared library that is not self-contained, and
> it is missing a run-time dependency on libre0, as it uses some of its
> symbols. The library should link against all libraries it uses directly,
> because otherwise it is pushing an internal implementation detail towards
> its users.
>
> A very simple example to illustrate:
>
>   $ echo 'int main() { return 0; }' >rem.c
>   $ gcc -o rem rem.c -lrem
>   [ lots of undefined references to missing symbols… ]

Oh.. That is new, let me check. Upstream ships hand written make file
but I guess it has to do something with we fiddling with Makefile to
build it properly for Debian.

>
> I guess there's just a «-lre» missing somewhere in the build system.

Thanks I will check on this.


> (I found this while trying to build a local baresip package, so thanks
> for trying to get that in Debian. :)

Ah cool. We were working on packaging baresip, some initial work is here
¹. Again custom Makefile is making our life bit hard to build it
properly. 

¹ http://anonscm.debian.org/cgit/pkg-voip/baresip.git

Bug#817011: vagrant: domain_name gem not found

[Antonio Terceiro]

Control: done -1
Control: affects 817011 + vagrant

On Mon, Mar 07, 2016 at 12:10:33PM -0500, Guy Hughes wrote:
> Package: vagrant
> Version: 1.8.1+dfsg-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Until #817011 on ruby-domain-name is fixed by the maintainer, vagrant
> does not work without a manual fix (gemspec file) available in the bts
> report.[1] See below.
> 
> I'm reporting this against your package for the benefit of others,
> especially those using virtualbox from sid.

Thanks for your concern, but creating duplicate bugs on affected
packages is not useful as there is nothing to be fixed on them.

The BTS has a feature to say that a bug affects other packages, what is
what I am doing now.


signature.asc
Description: PGP signature

Bug#814976: whitedune: diff for NMU version 0.30.10-2.1

[Sebastian Ramacher]

On 2016-03-07 23:22:58, Raúl Benencia wrote:
> Control: tags 814976 + patch
> Control: tags 814976 + pending
> 
> Dear maintainer,
> 
> This bug is caused by a recent update on grep. This update modified a bit
> the heuristic used for determining when the given input is binary.
> 
> I've prepared an NMU for whitedune (versioned as 0.30.10-2.1). As I don't
> have privileges to upload it to DELAYED, I've uploaded it to the mentors
> repository.
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/whitedune
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/main/w/whitedune/whitedune_0.30.10-2.1.dsc

Thank you, uploaded.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#771241: still not available in jessie?

[Luca Olivetti]

I'm having this issue in jessie with 3:5.06-2+deb8u1.
Looking at the changelog it seems this fix hasn't been backported.

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Dmitry Bogatov]

[2016-03-06 19:48] Nikos Tsipinakis 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "newsbeuter"
> 
> * Package name: newsbeuter
>   Version : 2.9-1
>   Upstream Author : Andreas Krennmair 
> * URL : https://github.com/akrennmair/newsbeuter
> * License : MIT
>   Section : net
>
> It builds those binary packages:
>
>newsbeuter - text mode rss feed reader with podcast support
>newsbeuter-dbg - debugging symbols for newsbeuter

[NO DD, can't sponsor]

There is nice tool `check-all-the-things'. It reveals

 * loads of spelling errors in po/
 * wrong formatting of your email (email is formatted this way: Name 
,
   your formatting in patches/podbeuter-segfault-fix misses <> symbols)
 * installation instruction (README) should not find way into binary package

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#767173:

[lluis]

Hello, I have the same bug, after freeze, owner
of /run/user/1000/dconf/user changes to root:

-rw--- 1 root root 2 Mar  8 09:58 /run/user/1000/dconf/user

Bug#803488: bugs.debian.org: "500 Internal Server Error" on kernel team's bug list

[Roger Shimizu]

Dear Maintainer,

I confirmed that the bug is not reproducible anymore.

- 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-kernel%40lists.debian.org

The above site can be accessed, though it loads for around 100 seconds.

I'm not sure why the status changed. Maybe because the number of
kernel bug has changed, or you reboot the machine hosting
bugs.debian.org
Please comment if possible.
If the issue get resolved, you may close this bug.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#817121: schroot: Failing lintian call via --run-session

[Mathias Behrle]

Package: schroot
Version: 1.7.2-3
Severity: normal

Dear Maintainer,

I am hit by this error with lintian failing when called in post build
chroot by sbuild. Not entirely sure if the assignment to schroot is
correct, but seems to me most adequate.

The relevant lines of the sbuild debug log:

...
D: Setting Dummy package path=undef
D: Setting Dummy archive directory=undef
D: Setting Dummy Release file=undef
I: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865 --run-session -q -u 
mathiasb -p -- lintian tryton-server_3.8.3-2_amd64.changes
D: Running command: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865 
--run-session -q -u mathiasb -p -- lintian tryton-server_3.8.3-2_amd64.changes
tryton-server_3.8.3-2_amd64.changes is not available
D: Setting Lintian Reason=pass

D: Setting Lintian Reason=error
D: Setting Lintian Reason=fail
E: Lintian run failed (policy violation)
...

Basic information:
- I am using overlay in schroot conf
- I am aware of #798835 and running sbuild from experimental (0.68.0-1.0~exp1)

For debugging purposes I kept the chroot sessions available by running 
$ sbuild --purge=never -D

Indeed the command fails when calling lintian from outside the chroot:

mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
schroot -d /build/tryton-seriver-g23533 \
-c sid-amd64-sbuild-IgSZzA-3865 --run-session -q -u mathiasb \
-p -- lintian tryton-server_3.8.3-2_amd64.changes
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.utf8"
 are supported and installed on your system.
 perl: warning: Falling back to the standard
 locale ("C").
tryton-server_3.8.3-2_amd64.changes is not available

but succeeds with a call to ls:

mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
schroot -d /build/tryton-server-g23533 -c sid-amd64-sbuild-IgSZzA-3865 \
--run-session -q -u mathiasb -p -- ls
tryton-server-3.8.3  tryton-server-doc_3.8.3-2_all.deb
tryton-server_3.8.3-2.debian.tar.xz  tryton-server_3.8.3-2.dsc
tryton-server_3.8.3-2_all.deb  tryton-server_3.8.3-2_amd64.changes
tryton-server_3.8.3.orig.tar.gz

also the lintian call succeeds inside the chroot:

mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
schroot -r -c sid-amd64-sbuild-IgSZzA-3865
...
(sid-amd64-sbuild)mathiasb@monsterix:/$ cd build/tryton-server-g23533/
(sid-amd64-sbuild)mathiasb@monsterix:/build/tryton-server-g23533$
lintian -v tryton-server_3.8.3-2_amd64.changes 
N: Using profile debian/main.
N: Setting up lab in /tmp/temp-lintian-lab-WUBBSgAJE8 ...
N: Unpacking packages in group tryton-server/3.8.3-2
N: 
N: Processing changes file tryton-server (version 3.8.3-2, arch source
all) ...
N: 
N: Processing source package tryton-server (version 3.8.3-2, arch
source) ...
N: 
N: Processing binary package tryton-server-doc (version 3.8.3-2, arch
all) ...
N: 
N: Processing binary package tryton-server (version 3.8.3-2, arch all)
...


I am running out of ideas why especially the lintian command is failing
with schroot --run-session. Just now I am unable to reboot this machine,
but this will be one of the next steps to check. Please let me know what
I can do to track down further this issue.

Cheers,
Mathias


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

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

Versions of packages schroot depends on:
ii  libboost-filesystem1.58.0   1.58.0+dfsg-5+b1
ii  libboost-program-options1.58.0  1.58.0+dfsg-5+b1
ii  libboost-system1.58.0   1.58.0+dfsg-5+b1
ii  libc6   2.21-9
ii  libgcc1 1:5.3.1-10
ii  libsbuild1.7.2  1.7.2-3
ii  libstdc++6  5.3.1-10
ii  schroot-common  1.7.2-3

schroot recommends no packages.

Versions of packages schroot suggests:
ii  aufs-tools1:3.2+20130722-1.1
ii  btrfs-tools   4.4-1
ii  debootstrap   1.0.79
ii  lvm2  2.02.142-1+b1
ii  qemu-user-static  1:2.5+dfsg-5
ii  unionfs-fuse  1.0-1

-- Configuration Files:
/etc/schroot/buildd/nssdatabases changed [not included]
/etc/schroot/default/nssdatabases changed [not included]
/etc/schroot/sbuild/fstab changed [not included]
/etc/schroot/schroot.conf changed [not included]

-- no debconf information

Bug#817122: awesome: Package new 3.5.9 release

[Eugen Dedu]

Package: awesome
Version: 3.5.6-1
Severity: wishlist

Dear Maintainer,

Would it be possible to package the latest awesome release?  It fixes an 
annoying bug for me.


Thank you,
Eugen

Bug#817124: librarian-puppet requires 'rsync' gem but it doesn't exist

[Vincent Bernat]

Package: librarian-puppet
Version: 2.2.1-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

After the latest update of librarian-puppet, just running it triggers this 
error:

/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot 
load such file -- rsync (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/vendor_ruby/librarian/puppet/util.rb:1:in `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/vendor_ruby/librarian/puppet/source/local.rb:1:in 
`'
[...]

There doesn't seem to be any gem available for this in Debian.

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

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

Versions of packages librarian-puppet depends on:
ii  puppet-common   3.8.5-1
ii  ruby1:2.3.0+1
ii  ruby-json   1.8.3-1+b2
ii  ruby-librarian  0.1.2-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1
ii  ruby2.3 [ruby-interpreter]  2.3.0-4

librarian-puppet recommends no packages.

librarian-puppet suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW3p1xAAoJEJWkL+g1NSX5QIAP/iv78RKifK7DP0JHcBSG30T3
9w+bKTVz/KiacomnJ8Grgf/QQQ0CNpfviDZX+/EjkZxzLjhfDEK3kAwFwDYoZP4Z
EX5VhqcmqDmAQJrRYCey5FEI9PNiGxNXZQcz2yiO9r/QqQr2HDJg5ZcYylnEIA0x
mxvjQ77KW6FbuSmKQmhY1PSyGwVAr4gHfuuh/icjFf3u6LzDWWvAi/2uHhu/XpTu
ZIStil5U2oaWIOO0+9PCkNh7Qn4Rjfxg4hEYxLmQsVGmq9rPiQbgpgM/N5Dz9eks
xIc7RoaHhWZxIgT+JE0tzCa9oEZi+ag8ZU2y3JKM1wj+A7q7BXLOgYiRiKXdPqE0
PDFQKISWfNd4NDKYahJI4YpgidOmURMKsOEolIcgZ0vB3mCv3f2rEGqfSdb5O8Kf
aNP5Kmpgjwfynd8RtEzPxFPutqey9DIiQTLou/aGcEvx2HbMov8UdU5RQEh1kp6r
nevRskZMb7n1JSBtBKhjPqzHT7xg1YLGJHanURO3glbAn3McZbk+5kPvWh85pQ1p
ZkjjuAbgRua11qdpumzsdA3h9f/f8px3yMCja36LH6LWnHwBc6J6fP3czGyO/PaH
1F2Ek35w9dswiVPevTI6GQUgVqQ0Eekq2w8xPvRqtKJzuG5/L/goURlwEmKh2BJl
V9Bdic3wzEhB2U05vzpP
=r44l
-END PGP SIGNATURE-

Bug#817123: network-manager: No WiFi after network-manager upgraded

[Alexandre]

Package: network-manager
Version: 1.1.91-1
Severity: normal

Dear Maintainer,

After network-manager package upgraded i don't have any wifi anymore on my
laptop.



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

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

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.10.6-1
ii  init-system-helpers1.29
ii  isc-dhcp-client4.3.3-8
ii  libbluetooth3  5.36-1
ii  libc6  2.21-9
ii  libglib2.0-0   2.46.2-3
ii  libgnutls303.4.9-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.4.12-1
ii  libndp01.4-2
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.1.91-1
ii  libpam-systemd 229-2
ii  libpolkit-agent-1-00.105-14.1
ii  libpolkit-gobject-1-0  0.105-14.1
ii  libreadline6   6.3-8+b4
ii  libsoup2.4-1   2.52.2-1
ii  libsystemd0229-2
ii  libteamdctl0   1.23-1
ii  libuuid1   2.27.1-3
ii  lsb-base   9.20160110
ii  policykit-10.105-14.1
ii  udev   229-2
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
ii  crda3.13-1+b1
ii  dnsmasq-base2.75-1
ii  iptables1.6.0-2
ii  iputils-arping  3:20150815-2
ii  modemmanager1.4.12-1
ii  ppp 2.4.7-1+2

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#798835: [buildd-tools-devel] Bug#798835: sbuild fails without any error message when /var/lib/sbuild is not writable in the chroot

[Mathias Behrle]

I am also using overlay in the sbuild/schroot configuration and can confirm,
that I need to run 0.68.0-1.0~exp1 to get the build results correctly copied to
<>.

JFTR: Currently hitting (probably unrelated) #817121.

Cheers,
Mathias

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpksw3E2tdQI.pgp
Description: Digitale Signatur von OpenPGP

Bug#817125: vice: FTBFS with 'failed to write cache'

[Graham Inggs]

Source: vice
Version: 2.4.dfsg+2.4.24-1

Hi Maintainer

Vice has been FTBFS on the Ubuntu buildds since version 
2.4.dfsg+2.4.24-1 with the following error:


Preparing fontdir, please wait...
cp: cannot stat '/usr/lib/vice/fonts/CBM.ttf': No such file or directory
/home/buildd/.fonts: failed to write cache
Makefile:628: recipe for target 'install' failed

I noticed the following line was removed from debian/rules in that 
version, and replacing it made the builds succeed.


unexport HOME

Please consider replacing this line in the Debian packaging.

Regards
Graham

Bug#786658: quota: Cannot install quota package on a jessie system

[Michael Meskes]

On Sun, May 24, 2015 at 08:37:23AM +0200, Simone Rossetto wrote:
> Hi all, I cannot install quota package on a jessie system, the configuration 
> step always ends with the following error:
> ...

Could you please try with the latest version? It works for me.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#813423: Workaround

[Raphaël POITEVIN]

Dear maintainer,

In response to your answer to Jean-Philippe who Im' working with, I 
tried the workaround.


If I understood correctly, this workaround consist in disabling 
module-switch-on-port-available.


I tried to comment the line in /etc/pulse-default.pa. I tried also to 
disable this module after login with pactl unload 
module-switch-on-port-available.


Unfortunately, I meet the same problems.

I tried also to disable auto-mute in alsamixer. It seems to work better, 
plug and unplug switches correctly between headphone and speakers, but 
sound disappears sometime after reboot.


Thank you for your help.

Regards,
--
Raphaël POITEVIN
Hypra S.A.S.
http://www.hypra.fr
tél. : 01 84 73 06 61
ligne directe : 09 72 49 77 48

Bug#816861: fuser does not show the PID that keeps busy a schroot mount-point

[Craig Small]

On Sun, Mar 6, 2016 at 8:33 AM Franco Martelli 
wrote:

> The "fuser" command does not print nothing about PID of processes that
> keep busy a schroot's generated mount-point. Error messages when I
> logout a schroot session:
>
> It actually finds the process you are looking for, however it also finds a
lot of other processes.

~# fuser -m
> /var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
>
Find something that is in that mount point OR the device of this file.

However there is something odd about that mount point.

> /proc/2061/mountinfo:196 41 253:3 /
> /var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
> rw,relatime shared:135 - ext4 /dev/mapper/ld0-lv2
> rw,stripe=256,data=ordered
>
 Device 253:3
I suspect this device is more than just your schroot.
It looks awfully like /dev/dm-3

$ ls -l /dev/dm-3
brw-rw 1 root disk 253, 3 Mar  1 19:33 /dev/dm-3

so.. considering the chroot device id is the same as whatever /dev/dm-3 is,
you'll get a long list of processes because it probably something like /home

 - Craig


-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#817126: grafana: FTBFS when built with dpkg-buildpackage -A (unable to chdir to _build)

[Santiago Vila]

Package: src:grafana
Version: 2.6.0+dfsg-3
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
## Build CSS: http://lesscss.org/usage/index.html
mkdir -p public/css
cd public/css \
&& lessc --include-path=../less --include-path=../vendor/bootstrap/less 
../less/bootstrap.dark.less grafana.dark.min.css.tmp \
&& cat grafana.dark.min.css.tmp 
/usr/share/fonts-font-awesome/css/font-awesome.css > grafana.dark.min.css \
&& lessc --include-path=../less --include-path=../vendor/bootstrap/less 
../less/bootstrap.light.less grafana.light.min.css.tmp \
&& cat grafana.light.min.css.tmp 
/usr/share/fonts-font-awesome/css/font-awesome.css > grafana.light.min.css \
;
tsc --module amd public/test/lib/common.ts 
public/test/core/utils/rangeutil_specs.ts 
public/test/core/utils/datemath_specs.ts 
public/test/core/utils/flatten_specs.ts public/test/core/table_model_specs.ts 
public/app/headers/lodash/lodash.d.ts public/app/headers/moment/moment.d.ts 
public/app/headers/moment/moment-node.d.ts 
public/app/headers/angularjs/angularjs.d.ts public/app/headers/common.d.ts 
public/app/headers/jquery/jquery.d.ts public/app/headers/require/require.d.ts 
public/app/features/panel/panel_meta.ts 
public/app/features/dashboard/timepicker/timepicker.ts 
public/app/plugins/datasource/elasticsearch/specs/index_pattern_specs.ts 
public/app/plugins/datasource/elasticsearch/specs/query_ctrl_specs.ts 
public/app/plugins/datasource/elasticsearch/specs/query_def_specs.ts 
public/app/plugins/datasource/elasticsearch/specs/elastic_response_specs.ts 
public/app/plugins/datasource/elasticsearch/specs/query_builder_specs.ts 
public/app/plugins/datasource/elasticsearch/specs/datasource_specs
 .ts public/app/plugins/datasource/graphite/specs/gfunc_specs.ts 
public/app/plugins/datasource/graphite/specs/query_ctrl_specs.ts 
public/app/plugins/datasource/graphite/specs/datasource_specs.ts 
public/app/plugins/datasource/cloudwatch/specs/datasource_specs.ts 
public/app/plugins/datasource/prometheus/specs/datasource_specs.ts 
public/app/plugins/datasource/influxdb/influx_query.ts 
public/app/plugins/datasource/influxdb/specs/query_ctrl_specs.ts 
public/app/plugins/datasource/influxdb/specs/influx_series_specs.ts 
public/app/plugins/datasource/influxdb/specs/query_builder_specs.ts 
public/app/plugins/datasource/influxdb/specs/query_part_specs.ts 
public/app/plugins/datasource/influxdb/specs/influx_query_specs.ts 
public/app/plugins/datasource/influxdb/query_part.ts 
public/app/plugins/datasource/influxdb_08/specs/influx_series_specs.ts 
public/app/plugins/datasource/influxdb_08/specs/query_builder_specs.ts 
public/app/plugins/datasource/influxdb_08/specs/datasource-specs.ts 
public/app/core/ti
 me_series.ts public/app/core/directives/give_focus.ts 
public/app/core/directives/array_join.ts public/app/core/utils/rangeutil.ts 
public/app/core/utils/datemath.ts public/app/core/utils/flatten.ts 
public/app/core/controllers/signup_ctrl.ts public/app/core/core.ts 
public/app/core/routes/bundle_loader.ts public/app/core/table_model.ts 
public/app/core/filters/filters.ts public/app/core/core_module.ts 
public/app/panels/table/module.ts public/app/panels/table/editor.ts 
public/app/panels/table/specs/renderer_specs.ts 
public/app/panels/table/specs/table_model_specs.ts 
public/app/panels/table/specs/transformers_specs.ts 
public/app/panels/table/controller.ts public/app/panels/table/renderer.ts 
public/app/panels/table/transformers.ts
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=golang --with=golang,systemd 
--builddirectory=_build --parallel
   debian/rules build-indep
make[1]: Entering directory '/<>/grafana-2.6.0+dfsg'
## Build CSS: http://lesscss.org/usage/index.html
mkdir -p public/css
cd public/css \
&& lessc --include-path=../less --include-path=../vendor/bootstrap/less 
../less/bootstrap.dark.less grafana.dark.min.css.tmp \
&& cat grafana.dark.min.css.tmp 
/usr/share/fonts-font-awesome/css/font-awesome.css > grafana.dark.min.css \
&& lessc --include-path=../less --include-path=../vendor/bootstrap/less 
../less/bootstrap.light.less grafana.light.min.css.tmp \
&& cat grafana.light.min.css.tmp 
/usr/share/fonts-font-awesome/css/font-awesome.css > grafana.light.min.css \
;
tsc --module amd public/test/lib/common.ts 
public/test/core/utils/rangeutil_specs.ts 
public/test/core/utils/datemath_specs.ts 
public/test/core/utils/flatten_specs.ts public/test/core/table_model_specs.ts 
public/app/headers/lodash/lodash.d.ts public/app/headers/moment/moment.d.ts 
public/app/headers/moment/moment-node.d.ts 
public/app/headers/angularjs/angularjs.d.ts public/app/headers/common.d.ts 
public/app/headers/jquery/jquery

Bug#817127: grib-api: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:grib-api
Version: 1.14.5-4
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake --with=python2 
--builddirectory=/<>/debian/build
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
F77=gfortran dh_auto_configure -- \
-DCMAKE_BUILD_TYPE=Release \
-DDISABLE_OS_CHECK=ON \
-DENABLE_PNG=ON -DENABLE_PYTHON=ON \
-DENABLE_AEC=ON \
-DENABLE_RPATHS=OFF \

[... snipped ...]

-- Installing: 
/<>/debian/tmp/usr/share/grib_api/ifs_samples/grib1_mlgrib2_ieee64/reduced_gg_pl_640_grib1.tmpl
-- Installing: 
/<>/debian/tmp/usr/share/grib_api/ifs_samples/grib1_mlgrib2_ieee64/gg_ml.tmpl
-- Installing: 
/<>/debian/tmp/usr/share/grib_api/ifs_samples/grib1_mlgrib2_ieee64/gg_sfc.tmpl
-- Installing: 
/<>/debian/tmp/usr/share/grib_api/ifs_samples/grib1_mlgrib2_ieee64/sh_ml.tmpl
-- Installing: 
/<>/debian/tmp/usr/share/grib_api/ifs_samples/grib1_mlgrib2_ieee64/sh_sfc.tmpl
make[1]: Leaving directory '/<>/debian/build'
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
for d in libgrib_api_f77.so  libgrib_api_f90.so libgrib_api.so ; do \
mv debian/tmp/usr/lib/$d.0 debian/tmp/usr/lib/$d.0.0.0 ; done
dh_numpy
# Make properly visible
mv debian/tmp/usr/lib/python2.7/site-packages/grib_api 
debian/tmp/usr/lib/python2.7/site-packages/gribapi
mv debian/tmp/usr/lib/python2.7/site-packages/gribapi/gribapi.py 
debian/tmp/usr/lib/python2.7/site-packages/gribapi/__init__.py
dh_install
find . -name grib_to_netcdf -exec chrpath -d {} \;
# Setup cmake files for magics++, metview, etc.
mkdir -p debian/libgrib-api-dev//usr/lib/x86_64-linux-gnu/cmake/grib_api
cp debian/tmp/usr/share/grib_api/cmake/* 
debian/libgrib-api-dev//usr/lib/x86_64-linux-gnu/cmake/grib_api
sed -e 's%${_IMPORT_PREFIX}%/usr%' \
   < debian/tmp/usr/share/grib_api//cmake/grib_api-targets-release.cmake \
  > 
debian/libgrib-api-dev//usr/lib/x86_64-linux-gnu/cmake/grib_api/grib_api-targets-release.cmake
make[1]: Leaving directory '/<>'
   dh_installdocs -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_installchangelogs -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_python2 -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_perl -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_link -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_strip_nondeterminism -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_compress -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
dh_fixperms
chmod +x 
debian/libgrib-api0/usr/share/grib_api/definitions/installDefinitions.sh
chmod: cannot access 
'debian/libgrib-api0/usr/share/grib_api/definitions/installDefinitions.sh': No 
such file or directory
debian/rules:65: recipe for target 'override_dh_fixperms' failed
make[1]: *** [override_dh_fixperms] Error 1
make[1]: Leaving directory '/<>'
debian/rules:18: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

Thanks.

Bug#815919: nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-1 sikuli_1.0~x~rc3.tesseract3-dfsg1-12

[Philip Rinn]

retitle 815919 nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 
gimagereader_3.1.2+git368fa8f-2 sikuli_1.0~x~rc3.tesseract3-dfsg1-12
thanks


On 25/02/16 18:50, Andreas Beckmann wrote:
> nmu gimagereader_3.1.2+git368fa8f-1 . ANY . unstable . -m "Rebuild against 
> libtesseract3."

No, please not, it's -2:

nmu gimagereader_3.1.2+git368fa8f-2 . ANY . unstable . -m "Rebuild against 
libtesseract3."

Thanks,
Philip


signature.asc
Description: PGP signature

Bug#817128: lintian: automatically find the .changes/.dsc/.deb files based on debian/{control,changelog}

[Paul Wise]

Package: lintian
Severity: wishlist

It would be nice if lintian could automatically find the relevant
.changes/.dsc/.deb files based on debian/{control,changelog}. This
would make it easier to run lintian from a just-built source tree.

I wonder if this functionality should be a part of dpkg-dev, since
dpkg-buildpackage seems to know the names of the right files, and then
lintian should just make use of it via libdpkg-perl?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[Graham Inggs]

Hi Maintainer

This problem still occurs from time to time.

See build logs of:

2.4.dfsg+2.4.20-1 on hurd-i386
https://buildd.debian.org/status/fetch.php?pkg=vice&arch=hurd-i386&ver=2.4.dfsg%2B2.4.20-1&stamp=1431810973

2.4.dfsg+2.4.24-2 on kfreebsd-amd64
https://buildd.debian.org/status/fetch.php?pkg=vice&arch=kfreebsd-amd64&ver=2.4.dfsg%2B2.4.24-2&stamp=1454237493

2.4.dfsg+2.4.25-1 on kfreebsd-i386
https://buildd.debian.org/status/fetch.php?pkg=vice&arch=kfreebsd-i386&ver=2.4.dfsg%2B2.4.25-1&stamp=1455382728

Regards
Graham

Bug#807264: dpkg: Please allow negative Architecture lists in debian/control

[Guillem Jover]

On Tue, 2016-03-08 at 08:27:32 +0100, Axel Beckert wrote:
> Guillem Jover wrote:
> > Can you present a case where using a negative specification would be
> > more correct than a positive one?
> 
> "More correct" maybe not (not sure what "more correct" means as
> "correct" is boolean for me), but surely way easier to maintain since
> I wouldn't have to follow all new architectures which pop up
> occassionally:
> 
> There was a time where gnudatalanguage didn't build on exactly one
> architecture (arm64): See https://bugs.debian.org/803552 and
> https://anonscm.debian.org/cgit/debian-astro/packages/gnudatalanguage.git/commit/?id=638bc9c3be31a4e5bd747f6c0f985da1afbc26ba
> 
> The full architecture list reads:
> 
> Architecture: any-alpha any-amd64 any-armeb any-arm any-avr32 any-hppa
> any-i386 any-ia64 any-m32r any-m68k any-mips any-mips64 any-mips64el
> any-mipsel any-or1k any-powerpc any-powerpcel any-ppc64 any-ppc64el
> any-s390 any-s390x any-sh3 any-sh3eb any-sh4 any-sh4eb any-sparc
> any-sparc64 mipsn32 mipsn32el powerpcspe x32
> 
> I had to write small script to get it done properly and found that
> line/commit rather tedious. And if the bug wouldn't have been fixed
> properly soon afterwards, I'd have had to keep that field uptodate or
> at least check it everytime a new architectures pops up, e.g. on
> Debian Ports.

This falls into one of the cases I mentioned in my previous mail. Here
I think to correct course of action would have been to request the
removal of the offending binaries for the broken arch. That makes that
FTBFS non-serious as it's not a regression (anymore). And the buildds
will be able to build it with a simple retry (automatic or manual), and
no new upload is required.

If the problem would have been, say, a misbuild instead of a FTBFS,
I'd probably have opted for adding instead a '$(error )' call in
debian/rules on arm64, which is a hack, but a temporary one in any
case, and certainly more manegable.

There's a very relevant thread on debian-devel started by
Steve Chamberlain, precisely about the underlying issue caused by
using exclusions instead of inclusions in Architecture fields which
I think also is spot on.

Thanks,
Guillem

Bug#772555: untested hacky attempt at using systemctl preset

[Raphael Hertzog]

Hi,

On Fri, 04 Mar 2016, Felipe Sateler wrote:
> This is only needed when creating links manually. As noted above, when
> invoking via systemctl it does the reload automatically.

Ok. So here's the final patch that I'm now using in Kali. It seems to work
from the quick tests that I did.

And I believe that it does the right thing given the contstraint.

It would be even better if we changed all maintainer scripts to call a true
"preset" action but I believe that's out of scope for now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 2a87cb4..07521a8 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -98,6 +98,7 @@ my $masked_state_dir = 
'/var/lib/systemd/deb-systemd-helper-masked';
 # Globals are bad, but in this specific case, it really makes things much
 # easier to write and understand.
 my $changed_sth;
+my $has_systemctl = -x "/bin/systemctl";
 
 sub error {
 print STDERR "$0: error: @_\n";
@@ -218,8 +219,49 @@ sub get_link_closure {
 return @links;
 }
 
-sub make_systemd_links {
+sub all_links_installed {
+my ($scriptname, $service_path) = @_;
+
+my @links = get_link_closure($scriptname, $service_path);
+my @missing_links = grep { ! -l $_->{src} } @links;
+
+return (@missing_links == 0);
+}
+
+sub no_link_installed {
+my ($scriptname, $service_path) = @_;
+
+my @links = get_link_closure($scriptname, $service_path);
+my @existing_links = grep { -l $_->{src} } @links;
+
+return (@existing_links == 0);
+}
+
+sub enable {
 my ($scriptname, $service_path) = @_;
+if ($has_systemctl) {
+# We use systemctl preset on the initial installation only
+# On upgrade, we manually add the missing symlinks only if
+# the service already has some links installed.
+my $create_links = 0;
+if (debian_installed($scriptname)) {
+$create_links = 1 unless no_link_installed($scriptname, 
$service_path);
+} else {
+debug "Using systemctl preset to enable $scriptname";
+system("/bin/systemctl", "--preset-mode=enable-only",
+"preset", $scriptname) == 0 or
+error("systemctl preset failed on $scriptname: $!");
+}
+make_systemd_links($scriptname, $service_path, create_links => 
$create_links);
+} else {
+# We create all the symlinks ourselves
+make_systemd_links($scriptname, $service_path);
+}
+}
+
+sub make_systemd_links {
+my ($scriptname, $service_path, %opts) = @_;
+$opts{'create_links'} //= 1;
 
 my $dsh_state = dsh_state_path($scriptname);
 
@@ -234,7 +276,7 @@ sub make_systemd_links {
 $statefile =~ s,^/etc/systemd/system/,$enabled_state_dir/,;
 next if -e $statefile;
 
-if (! -l $service_link) {
+if ($opts{'create_links'} && ! -l $service_link) {
 make_path(dirname($service_link));
 symlink($service_path, $service_link) or
 error("unable to link $service_link to $service_path: $!");
@@ -472,9 +514,7 @@ for my $scriptname (@ARGV) {
 debug "action = $action, scriptname = $scriptname, service_path = 
$service_path";
 
 if ($action eq 'is-enabled') {
-my @links = get_link_closure($scriptname, $service_path);
-my @missing_links = grep { ! -l $_->{src} } @links;
-my $enabled = (@missing_links == 0);
+my $enabled = all_links_installed($scriptname, $service_path);
 print STDERR ($enabled ? "enabled\n" : "disabled\n") unless $quiet;
 $rc = 0 if $enabled;
 }
@@ -520,7 +560,7 @@ for my $scriptname (@ARGV) {
 }
 
 if ($action eq 'enable') {
-make_systemd_links($scriptname, $service_path);
+enable($scriptname, $service_path);
 }
 
 if ($action eq 'mask') {

Bug#816858: Logical volumes on external USB disk cause boot to enter emergency shell

[Christoph Pleger]

Hello,

I have to modify my statement about a new version of lvm2. After
installing systemd again (for getting the journal messages) and rebooting,
the computer booted completely, without entering the emergency shell.
Downgrading lvm2 to the jessie version re-introduced the problem. So, the
bug is already solved in the current lvm2 version in stretch.

Regards
  Christoph

Bug#768073: ITP: lxd - The Linux Container Daemon

[Thomas Goirand]

Hi Adnan,

It's been more than a month already since you've said that we should
"stay tuned". Well, I can't hold my breath anymore... :)

Is there any update on the release of this package? Is there a temporary
Git repository which we could use for this packaging?

FYI, I have packaged and I have just uploaded python-pylxd (it currently
is in the NEW queue), which is needed by OpenStack Manila (ie: file
share as a service).

The upstream sources of python-pylxd are very much like the other
OpenStack source code I've been packaging for OpenStack: it uses PBR,
has {test-,}requirements.txt, and has (build-)dependencies on many
OpenStack components. So it makes a lot of sense to have it packaged
under the PKG OpenStack.

The main use of LXD, from Canonical point of view, is also so it can be
leveraged by OpenStack compute (ie: nova-lxd), to provision LXC
containers instead of using KVM. So, from my point of view, it would
also make a lot of sense to maintain LXD within the PKG OpenStack group
as well. I of course welcome anyone in this packaging group on Alioth. I
would very much like to be co-maintaining this package as well (even if
I don't know Go packaging so much).

As soon as we have LXD in Debian, I will add a nova-lxd source package
to the nova source package, so that it can depend on LXD itself, and set
the relevant /etc/nova/nova-compute.conf options.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

Upstream confirmed that:
* current gspell-1 0.1.* (libgspell-1.so.0.0.0) and gspell-1 0.2.* 
 (libgspell-1.so.0.0.0 as well) are development versions with no stable 
 API, although LaTeXila 3.18 depends on gspell-1 0.1;
* gpell-1 1.0.0 (libgspell-1.so.1.0.0) is planned to be released for 
 GNOME 3.20.


Considering this information, and according to upstream suggestions, the 
best course of action is probably to skip development versions and only 
start packaging with gspell-1 1.0.0 (libgspell-1.so.1.0.0, package 
libgspell-1-1). This implies that it will not be possible to package 
LaTeXila 3.18, but hopefully LaTeXila 3.20 will use gspell-1 1.0.0.


I will notify the Debian GNOME Maintainers, as next Gedit will be able 
to use gspell.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#817083: [Debconf-devel] Bug#817083: debconf templates are not loaded in prerm

[Colin Watson]

On Tue, Mar 08, 2016 at 01:04:06AM +, Ben Hutchings wrote:
> It appears that using debconf in a preinst or postinst script causes
> debconf templates to be loaded automagically.  However, since version
> 4.4.1-1~exp1 the linux-image-* packages only use debconf in the prerm
> script.  In the case where the script asks a question, debconf does
> not find the template and the prerm script fails.
> 
> The manual page for debconf-loadtemplate says it should never be used
> from maintainer scripts, so I don't see how we're supposed to make
> this work.

Can you see if this patch works?  (If you're applying this directly to
/usr/share/debconf/frontend, note that comments are stripped on
installation, but it should be reasonably obvious what to do.)

diff --git a/frontend b/frontend
index 690bedc..0e90cd1 100755
--- a/frontend
+++ b/frontend
@@ -96,6 +96,15 @@ debug developer => "frontend running, package name is 
$package";
 $frontend->default_title($package) if length $package and !$no_title;
 $frontend->info(undef);
 
+# Load any associated templates if we're being run from a package maintainer
+# script.
+if ($ARGV[0] =~/^(.*[.\/])(?:preinst|postinst|prerm|postrm)$/) {
+   my $base=$1;
+   my $templates=$base."templates";
+   Debconf::Template->load($templates, $package)
+   if -e $templates;
+}
+
 # See if the preinst or postinst of the package is being run, and if there
 # is a config script associated with this package. If so, run it first as a
 # confmodule (also loading the templates). This is a bit of a nasty hack, that
@@ -106,11 +115,6 @@ $frontend->info(undef);
 if ($ARGV[0] =~/^(.*[.\/])(?:postinst|preinst)$/) {
my $base=$1;
 
-   # Load templates, if any.
-   my $templates=$base."templates";
-   Debconf::Template->load($templates, $package)
-   if -e $templates;
-
# Run config script, if any.
my $config=$base."config";
if (-e $config) {

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#817129: dose-distcheck: provide option to ignore certain packages

[Michael Prokop]

Package: dose-distcheck
Version: 4.1-4
Severity: wishlist

Hi,

it would be great if there'd be an option like --ignore=VPKGLIST
similar to the existing --checkonly=VPKGLIST option, but having the
opposite behaviour: do not consider the provided arguments in the
package report. This would allow usage of dose-distcheck with
known-to-be-broken package(s), which is something you might e.g.
have to deal with when introducing dose-distcheck in a new
environment where you have known problems on existing (custom)
repositories.

Thanks for dose-distcheck!

regards,
-mika-

Bug#817130: README.Debian refers to non-existent /etc/default/pulseaudio

[chrysn]

Package: pulseaudio
Version: 8.0-1
Severity: minor

the pulseaudio README.Debian file shipped in the pulseaudio package
refers to a non-existent file:

> By default pulseaudio is configured for using a per-user session daemon
> (see comments in /etc/default/pulseaudio). If you wish to prevent per-
> user session daemons from being invoked, remember to edit
> /etc/pulse/client.conf (or create ~/.pulse/client.conf) and ensure that
> "autospawn = no" is present and uncommented.

that file was shipped in jessie's pulseaudio, but is nonexistent in
pulseaudio 8.

please consider updating the documentation for system-wide pulseaudio
operation.

best regards
chrysn

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


-- 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.5.0-rc5 (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: sysvinit (via /sbin/init)

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.1.0-1
ii  libasound2-plugins1.1.0-1
ii  libc6 2.21-9
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.6-1
ii  libfftw3-single3  3.3.4-2+b1
ii  libgcc1   1:5.3.1-10
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.6-0.1
ii  liborc-0.4-0  1:0.4.25-1
ii  libpulse0 8.0-1
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-10
ii  libsoxr0  0.1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.3.1-10
ii  libsystemd0   229-2
ii  libtdb1   1.3.8-1
ii  libudev1  229-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.11.1-1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20160110
ii  pulseaudio-utils  8.0-1
ii  udev  229-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  8.0-1
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1+b2
ii  paprefs  0.9.10-2
ii  pavucontrol  3.0-3+b2
ii  pavumeter0.9.3-4+b2

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Bálint Réczey]

Hi Guillem,

2016-03-08 1:52 GMT+01:00 Guillem Jover :
> Control: block -1 by 812782
>
> On Fri, 2016-01-29 at 12:55:42 +0100, Bálint Réczey wrote:
>> 2016-01-29 0:46 GMT+01:00 Guillem Jover :
>> > On Tue, 2016-01-26 at 15:33:40 +0100, Balint Reczey wrote:
>> >> Package: dpkg
>> >> Version: 1.18.4
>> >> Severity: wishlist
>> >> Tags: patch
>> >> User: bal...@balintreczey.hu
>> >> Usertags: hardened1-linux-amd64
>> >
>> >> This is the second patch enabling extra flags in dpkg in case the
>> >> hardened1-linux-amd64 port is accepted in #812782.
>> >
>> >> diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
>> >> index db40b2c..2f39d82 100644
>> >> --- a/scripts/Dpkg/Vendor/Debian.pm
>> >> +++ b/scripts/Dpkg/Vendor/Debian.pm
>> >> @@ -177,6 +177,14 @@ sub _add_reproducible_flags {
>> >
>> >> +if ($abi =~ /^(?:gnuhardened1)$/) {
>> >> + # Enable bindnow on hardened ports
>> >> + $use_feature{bindnow} = 1;
>> >> +}
>> >> +
>>
>> > Unfortunately I don't think this is a good idea. Due to at least two
>> > reasons. First not all packages are using dpkg-buildflags, which means
>> > that many will simply fail to build if one of the libraries they use
>> > is using ASAN but the program is not (AFAIUI). And because this is
>
>> I plan providing patches for those packages, but I see your point.
>>
>> > part of the ABI so it should really be a default in the compiler. This
>> > is part of the architecure definition. So this to me seems like the
>> > wrong place to set these.
>
>> I'm working towards to adding those as default GCC flags. I have already 
>> added
>> PIE which I previously set in dpkg: #812889 .
>
> Actually setting bindnow and PIE would be fine as part of the default
> build flags from dpkg, because those do not change the ABI in
> principle. And those are the only ones I'd accept from this bug
> report, but certainly not the ABI changing ones.
Do you mean you would be open to setting PIE and maybe bindnow as default
flags for a potential new architecture or even for existing ones like amd64?
In the latter case would you like to discuss that on debian-devel?
I would support such changes and I think we are in time for enabling
PIE for Stretch
and bindnow for Stretch+1 (maybe Stretch).

>
>> Setting the flags in dpkg makes it possible to create the port before the GCC
>> patches are stable. My thinking was that I could migrate to changing GCC 
>> later
>> without breaking the ABI.
>
> Not an option really. Having a stable ABI is a prerequisite for any new
> dpkg architecture, until that has happened I'm not planning on considering
> such additions.
OK, I agree.

Cheers,
Balint

Bug#803488: bugs.debian.org: "500 Internal Server Error" on kernel team's bug list

[Ben Hutchings]

On Tue, 2016-03-08 at 18:28 +0900, Roger Shimizu wrote:
> Dear Maintainer,
> 
> I confirmed that the bug is not reproducible anymore.
> 
> - 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-kernel%40lists.debian.org
> 
> The above site can be accessed, though it loads for around 100 seconds.
[...]

I had similar problems with the query
 but that's
been working reliably for a week or so now.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

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

Bug#817131: python-flake8: Missing binary

[Joel Cross]

Package: python-flake8
Version: 2.5.4-1
Severity: important

I have just upgraded python-flake8 to the latest version, but it is missing the
binary file.

$ which flake8
flake8 not found

A binary should be installed as /usr/bin/flake8



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

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

Versions of packages python-flake8 depends on:
ii  pep8   1.7.0-1
ii  pyflakes   1.0.0-4
ii  python-mccabe  0.2.1-1
ii  python-pep81.7.0-1
ii  python-pyflakes1.0.0-4
ii  python-setuptools  20.1.1-1
pn  python:any 

python-flake8 recommends no packages.

Versions of packages python-flake8 suggests:
pn  python-mock  

-- no debconf information

Bug#679763: debsnap: bisect option/script

[Osamu Aoki]

Hi,

On Tue, Mar 08, 2016 at 10:17:58AM +0800, Paul Wise wrote:
> On Mon, 2016-03-07 at 21:44 +0900, Osamu Aoki wrote:
> 
> > For source history, "gbp inport-dscs --debsnap" gives you access to real
> > "git bisect" access.  So no point reinvention it in debsnap itself.
> 
> I wasn't aware of that, thanks for the tip.
> 
> > (Yes, I am living in high bandwidth region.)
> 
> Yeah, for me that would be a prohibitive exercise.
> 
> I can't imagine how Joey Hess would use that ;)

Then try --list approach in few weeks.

> > For binary package history checking, dependency etc. matters and most
> > likely needs your manual attention.  At least with the new --list option
> > printing out sorted list of versions, you can do bisect like action
> > manually whice checking dependencyetively recent versions. 
> 
> I don't see any --list option in the debsnap in unstable.

Oh, that is pending upload feature :-)  I just coded it.
 
> pabs@chianamo ~ $ debsnap --binary --list libc6
> Unknown option: list
> ...
> 
> I would really like to see a general bisect tool that could wrap
> debsnap and other bisect situations.
> 
> This can be hacked around using a fake git repo and git bisect though,
> so once debsnap --list is available that should be enough.
> 
> > Do you still think we should add complexities into debsnap?
> 
> No. 
> 
> Please close this bug with the upload that adds debsnap --list.

OK.

Bug#788279: RM: geoclue -- ROM; unmaintained upstream

[Laurent Bigonville]

Hi,

The only remaining rdep in unstable is now python-geoclue and nothing is 
using it.


So I guess geoclue package can be removed from the archive.

Cheers,

Laurent Bigonville

Bug#610048: option --dry-run for debsnap

[Osamu Aoki]

Hi Joachim ,

Unless you have strong opsition, I am thinking to close this bug with
the recent --list option addition.

(Joachim did not comment on the mail from Marc Dequènes and did not
apply Joachim's patch when Joachim commited other patches to VCS.  So it
looks to me Joachim agrees with Marc's assessment.  Mail to Marc from me
is bounced so Marc may not know my recent postings.)

Regards,

Osamu

Bug#807264: dpkg: Please allow negative Architecture lists in debian/control

[Axel Beckert]

Hi Guillem,

Guillem Jover wrote:
> On Tue, 2016-03-08 at 08:27:32 +0100, Axel Beckert wrote:
> > There was a time where gnudatalanguage didn't build on exactly one
> > architecture (arm64): See https://bugs.debian.org/803552 and
> > https://anonscm.debian.org/cgit/debian-astro/packages/gnudatalanguage.git/commit/?id=638bc9c3be31a4e5bd747f6c0f985da1afbc26ba
> > 
> > The full architecture list reads:
> > 
> > Architecture: any-alpha any-amd64 any-armeb any-arm any-avr32 any-hppa
> > any-i386 any-ia64 any-m32r any-m68k any-mips any-mips64 any-mips64el
> > any-mipsel any-or1k any-powerpc any-powerpcel any-ppc64 any-ppc64el
> > any-s390 any-s390x any-sh3 any-sh3eb any-sh4 any-sh4eb any-sparc
> > any-sparc64 mipsn32 mipsn32el powerpcspe x32
> > 
> > I had to write small script to get it done properly and found that
> > line/commit rather tedious. And if the bug wouldn't have been fixed
> > properly soon afterwards, I'd have had to keep that field uptodate or
> > at least check it everytime a new architectures pops up, e.g. on
> > Debian Ports.
> 
> This falls into one of the cases I mentioned in my previous mail. Here
> I think to correct course of action would have been to request the
> removal of the offending binaries for the broken arch. That makes that
> FTBFS non-serious as it's not a regression (anymore).

I did that, but it wasn't executed in time.

> And the buildds will be able to build it with a simple retry
> (automatic or manual), and no new upload is required.

And I also think that's a more unfriendly variant towards buildd
admins and porters.

> If the problem would have been, say, a misbuild instead of a FTBFS,
> I'd probably have opted for adding instead a '$(error )' call in
> debian/rules on arm64, which is a hack, but a temporary one in any
> case, and certainly more manegable.

Urgh, that's quite ugly IMHO.

> There's a very relevant thread on debian-devel started by
> Steve Chamberlain, precisely about the underlying issue caused by
> using exclusions instead of inclusions in Architecture fields which
> I think also is spot on.

Thanks for that pointer. Will eventually have a look.

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

Bug#817006: [PKG-OpenRC-Debian] Bug#817006: ack to NMU

[Benda Xu]

Hi Adam,

Adam Borowski  writes:

> The popcon for openrc is 83, which, assuming that 10% of users run popcon
> (a wild-ass guess) means 830 users.  I have no idea what part of this is
> unstable, but as openrc in Debian is quite experimental, I guess quite a
> bunch of such users are affected.
>
> The breakage is pretty severe -- it does match the description of "critical"
> after all.  Every affected user would have to research the fix and apply
> it manually.  Thus, I don't think it's a good idea to ignore this bug,
> especially that the fix is easy.

Okay, I will take this lesson. Thank you for your help!

>> That said, I understand theoretically your NMU is the correctly way to
>> go.  So if you intend to do so, consider this email as an ack to NMU
>> from the maintainer team.
>
> I'll upload it then.

Great!  It is in Sid now.

>> One thing to notice is that we are tracking the package at
>> 
>>   http://anonscm.debian.org/cgit/openrc/openrc.git
>> 
>> Would you mind if I ask you to prepare a commit to the master
>> corresponding to the NMU?
>
> Of course.  I don't have push rights to that repository, so two commits are
> attached to this mail (one for the fix, one for changelog).

Applied and pushed.

You could apply at

https://alioth.debian.org/projects/openrc

to get push rights.

>> BTW, if you are interested in OpenRC, you are welcomed to join the
>> maintenance team.
>
> I'm afraid I don't really know inner workings of openrc, I use it on only
> one machine (which happens to be my main desktop, but still...).  Everywhere
> else I'm on sysv-rc.

Ah-ha. Me too, desktops, laptops or newly installed servers (those I
could access the consoles).

> This said, keeping openrc viable seems important for resisting
> systemd-ization of Debian so I probably should help in _some_ way.

Agreed.

>> 1. 0.20.4-1 was uploaded in a hurry to keep itself in testing.  The pts
>> system lied and we did not make it.  divert should not have existed in
>> OpenRC.
>
> It can be removed in some time, after the affected systems are fixed.

Okay.


Also I would like to thank Andreas for pointing this out.

Yours,
Benda

Bug#788108: Processed: severity of 788108 is serious, tagging 788108

[Laurent Bigonville]

Le 04/03/16 03:05, Lisandro Damián Nicanor Pérez Meyer a écrit :

On Monday 22 February 2016 11:45:56 Lisandro Damián Nicanor Pérez Meyer wrote:

It was discussed in upstream's mailing list, but I'm on the phone now :(

According to 5.6.0's git repo:

  - [QTBUG-40702] Removed dependency towards libgeoclue. The plugin uses the
GeoClue DBus interface.

I'm now working to disable the support in 5.5.1 to close this bug ASAP. We
need to understand what we will need to depend upon for 5.6.

Laurent: does it rings you any bells?

For the runtime dependency, you should Depends/Recommends/Suggests the 
geoclue-2.0 package.


If your code is resilient enough and support the case where the daemon 
is not installed, I would personally go for the Recommends.

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Mon, 07 Mar 2016, Ansgar Burchardt wrote:
> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
> 
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.
> 
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
> 
>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

I also second this improved wording or any other wording in the same spirit.

I agree it's better than the initial wording. Though it would be good to
list the most common values of "{path}" (and you want to use 
path in docbook instead of {path}).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#816682: live-installer: Inaccessible utility

[Iain R. Learmonth]

Hi,

On 08/03/16 01:16, Cyril Brulebois wrote:
>> - adding the content of libgail-common-udeb and libatk-adaptor-udeb to
>> the d-i image used by the live installer.  I don't know which image the
>> live installer uses, is it just using the standard gtk d-i image (in
>> which case we can just add the packages to g-i), or is it building its
>> own image?
> 
> Would probably make sense to include debian-live/debian-cd at some
> point… Doing so to get their input, along with irl@ who helped with
> getting live stuff built on d.o machines IIRC.

I have not yet looked at the integration of the installer into the new
live-wrapper tool, and I'm not sure what exactly is used in live-build.

If you can add the packages into the standard d-i used on debian-cd, I'm
happy to use the installer that is built by the d-i team, I don't want
to have to build our own installer and I want to be using only things
that are in Debian main.

Thanks,
Iain.

Bug#817121: [buildd-tools-devel] Bug#817121: schroot: Failing lintian call via --run-session

[Johannes Schauer]

Control: reassign -1 sbuild 0.68.0-1.0~exp1

Quoting Mathias Behrle (2016-03-08 10:28:04)
> I am hit by this error with lintian failing when called in post build
> chroot by sbuild. Not entirely sure if the assignment to schroot is
> correct, but seems to me most adequate.
> 
> The relevant lines of the sbuild debug log:
> 
> ...
> D: Setting Dummy package path=undef
> D: Setting Dummy archive directory=undef
> D: Setting Dummy Release file=undef
> I: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865 --run-session -q 
> -u mathiasb -p -- lintian tryton-server_3.8.3-2_amd64.changes
> D: Running command: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865 
> --run-session -q -u mathiasb -p -- lintian tryton-server_3.8.3-2_amd64.changes
> tryton-server_3.8.3-2_amd64.changes is not available
> D: Setting Lintian Reason=pass
> 
> D: Setting Lintian Reason=error
> D: Setting Lintian Reason=fail
> E: Lintian run failed (policy violation)
> ...
> 
> Basic information:
> - I am using overlay in schroot conf
> - I am aware of #798835 and running sbuild from experimental (0.68.0-1.0~exp1)
> 
> For debugging purposes I kept the chroot sessions available by running 
> $ sbuild --purge=never -D
> 
> Indeed the command fails when calling lintian from outside the chroot:
> 
> mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> schroot -d /build/tryton-seriver-g23533 \
> -c sid-amd64-sbuild-IgSZzA-3865 --run-session -q -u mathiasb \
> -p -- lintian tryton-server_3.8.3-2_amd64.changes
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "de_DE.utf8"
>  are supported and installed on your system.
>  perl: warning: Falling back to the standard
>  locale ("C").
> tryton-server_3.8.3-2_amd64.changes is not available
> 
> but succeeds with a call to ls:
> 
> mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> schroot -d /build/tryton-server-g23533 -c sid-amd64-sbuild-IgSZzA-3865 \
> --run-session -q -u mathiasb -p -- ls
> tryton-server-3.8.3  tryton-server-doc_3.8.3-2_all.deb
> tryton-server_3.8.3-2.debian.tar.xz  tryton-server_3.8.3-2.dsc
> tryton-server_3.8.3-2_all.deb  tryton-server_3.8.3-2_amd64.changes
> tryton-server_3.8.3.orig.tar.gz
> 
> also the lintian call succeeds inside the chroot:
> 
> mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> schroot -r -c sid-amd64-sbuild-IgSZzA-3865
> ...
> (sid-amd64-sbuild)mathiasb@monsterix:/$ cd build/tryton-server-g23533/
> (sid-amd64-sbuild)mathiasb@monsterix:/build/tryton-server-g23533$
> lintian -v tryton-server_3.8.3-2_amd64.changes 
> N: Using profile debian/main.
> N: Setting up lab in /tmp/temp-lintian-lab-WUBBSgAJE8 ...
> N: Unpacking packages in group tryton-server/3.8.3-2
> N: 
> N: Processing changes file tryton-server (version 3.8.3-2, arch source
> all) ...
> N: 
> N: Processing source package tryton-server (version 3.8.3-2, arch
> source) ...
> N: 
> N: Processing binary package tryton-server-doc (version 3.8.3-2, arch
> all) ...
> N: 
> N: Processing binary package tryton-server (version 3.8.3-2, arch all)
> ...
> 
> 
> I am running out of ideas why especially the lintian command is failing
> with schroot --run-session. Just now I am unable to reboot this machine,
> but this will be one of the next steps to check. Please let me know what
> I can do to track down further this issue.

thanks a lot for testing the sbuild version in experimental!

The problem here is not with schroot but with sbuild. The version in
experimental decouples the location where the package is built from the machine
where sbuild was started. This in turn means that the machine running sbuild
does not have direct access to anything within the chroot anymore.

What you are seeing here is a remaining bug of this change.

Thanks for bringing it up - I'll take care of it with the next experimental
upload.

Until then, if you don't want to run sbuild with --no-run-lintian, please fall
back to the sbuild version from unstable.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#817132: RM: qgis-plugin-globe qgis-plugin-globe-common -- ROM; No longer built

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove the qgis-plugin-globe & qgis-plugin-globe-common packages
from unstable, they are no longer built for QGIS 2.14 because they don't
support osgEarth 2.7 yet.

Kind Regards,

Bas

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

[Philip Rinn]

Hi all,

just to keep you informed: The ABI breakage is fixed upstream now:

https://github.com/tesseract-ocr/tesseract/commit/7461b617433757105db08b3bb4fca47eee3c96d7

Best,
Philip


signature.asc
Description: PGP signature

Bug#807579: CUDA 7.5 planning

[Graham Inggs]

On 01/03/2016 18:15, Andreas Beckmann wrote:

amd64 should be more or less ready for going to experimental, more
testing would be welcome!
I tried the cuda code samples (see README.Debian), and most built (only
those few that link with -lcudadevrt seem to miss a -lcudart). I didn't
try to actually run even one of them :-)


I built 7.5.18-1 r6291 in an Ubuntu PPA.
I was able to build the reverse-dependencies eztrace-contrib, 
hwloc-contrib and pycuda without modification.


A local build of pycuda on Ubuntu Xenial failed with the following 
error, but it probably just picked up something else installed:


error: Cython does not appear to be installed

I tried a couple of the pycuda examples and they ran successfully, but 
the script to download more examples from the wiki didn't seem to work 
any more.


Ubuntu has starpu-contrib 1.1.5-0.  It build successfully after I 
changed CONTRIB_GCC_VERSION := 5 and adjusted the build-dependencies.

I did not try building with CONTRIB_GCC_VERSION  := 4.9.


Looking at ppc64el now ...


For Ubuntu, I think I will use the no-libcuda1 virtual package for 
ppc64el.  I don't think a Tesla driver package for ppc64el will be 
uploaded in time for the Xenial release.

Bug#817025: Pending fixes for bugs in the fleet package

[pkg-go-maintainers]

tag 817025 + pending
thanks

Some bugs in the fleet package are closed in revision
d8d83e5c33b0c562a55cd643589b651c683f0a38 in branch 'master' by Dmitry
Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/fleet.git/commit/?id=d8d83e5

Commit message:

Switch to vishvananda-netlink, fixes FTBFS (Closes: #817025)

Bug#817133: yaboot: Invalid device

[Risto Suominen]

Package: yaboot
Version: 1.3.17-1

Looks like yaboot does not find its conf file any more.

I'm trying to install (CD) Debian on a PowerMac G5 (7,3). Jessie
(yaboot 1.3.16) works.

Stretch (yaboot 1.3.17) does not. It complains:

cd:-1,\install\yaboot.conf: Unable to open file, Invalid device

Or, on a Mac mini G4:

cd:-1,\install\mac32.conf: Unable to open file, Invalid device

The CD images were downloaded on March 6th 2016.

Bug#814990: phpmyadmin: installation of phpmyadmin has no effect

[Olaf Zaplinski]

/etc/apache2/conf-enabled/phpmyadmin.conf is in place, still no luck.

HOW TO FIX:

1.
a2disconf phpmyadmin.conf

2.
cd /etc/apache2/conf.d
ln -s ../../phpmyadmin/apache.conf phpmyadmin.conf
/etc/init.d/apache2 reload

Can you please fix this?

Bug#366520: [Aptitude-devel] Bug#366520: aptitude: please consider implementing "uninstall on sight" option

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> >Using debfoster, I have some packages like strace or tcpdump marked in
> >a way that the packages are uninstalled whenever debfoster is invoked.
> >This is a very handy way to get rid of packages that tend to get
> >installed on productive systems for debugging while nobody bothers to
> >remove them afterwards.
> >
> >debfoster is going to be removed from Debian,

10 years later, debfoster is still in Debian. :-)

> >losing this
> >functionality. Please consider implementing persistent package states,
> >which survive manual package state changes. That way, I'd like to have
> >tcpdump maked as "to be uninstalled" even if it just was manually
> >installed.
> 
> I don't know if this was possible back in 2006, but nowadays and for
> many years one can mark packages to remove/purge, and then quit
> aptitude, and the state will be saved / "scheduled" -- it persists, as
> requested here.
> 
> The next time that one starts aptitude, it will be marked in the same
> way, and some actions in the command line will have scheduled actions
> into account.

Exactly. And that can also be done from the commandline:

aptitude remove --schedule-only strace tcpdump

So IMHO the solution is to schedule a cron job, e.g. via
/etc/cron.weekly/ which schedules the removal of some packages as
shown above.

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

Bug#817135: jesred: please update links to Squid proxy

[Amos Jeffries]

Package: jesred
Version: 1.2pl1-21
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Depends: squid (>= 3.4)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

In the package Description's. The formal name for squid is "Squid HTTP
caching proxy" and has been for many years, not the ancient "Internet
Object Cache" term. Please use the current official name or "Squid
proxy" if shortened version is appropriate.

Thanks
Amos

Bug#817137: calamaris: please update links to Squid proxy

[Amos Jeffries]

Package: calamaris
Version: 2.99.4.5-1
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

It appears that the version requirement is also long stale on the
existing Suggests:squid.

Please update your package to "Suggests: squid".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817138: education-main-server: please update links to Squid proxy

[Amos Jeffries]

Package: education-main-server
Version: 1.812
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Recommends: squid".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817134: squidguard: please update links to Squid proxy

[Amos Jeffries]

Package: squidguard
Version: 1.5-5
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Recommends: squid (>= 3.4.0)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817136: c-icap: please update links to Squid proxy

[Amos Jeffries]

Package: c-icap
Version: 1:0.4.2-2
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to be "Suggests: squid (>= 3)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817128: lintian: automatically find the .changes/.dsc/.deb files based on debian/{control,changelog}

[Jakub Wilk]

Hi Paul!

* Paul Wise , 2016-03-08, 18:07:
It would be nice if lintian could automatically find the relevant 
.changes/.dsc/.deb files based on debian/{control,changelog}. This 
would make it easier to run lintian from a just-built source tree.


Have you tried running lintian without arguments? (See the "CHECKING 
LAST BUILD" section in the manual page for details.)


--
Jakub Wilk

Bug#817139: sassc: trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in package pysassc 0.9.3-1

[Axel Beckert]

Package: sassc,pysassc
Severity: serious
Version: sassc/3.3.2-3 pysassc/0.9.3-1

Trying to install sassc with pysassc installed causes a file conflict:

Unpacking sassc (3.3.2-3) ...
dpkg: error processing archive /var/cache/apt/archives/sassc_3.3.2-3_amd64.deb 
(--unpack):
 trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in package 
pysassc 0.9.3-1

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

Kernel: Linux 4.2.0-trunk-amd64 (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: sysvinit (via /sbin/init)

Bug#817128: lintian: automatically find the .changes/.dsc/.deb files based on debian/{control,changelog}

[Paul Wise]

On Tue, 2016-03-08 at 13:13 +0100, Jakub Wilk wrote:

> Have you tried running lintian without arguments? (See the "CHECKING 
> LAST BUILD" section in the manual page for details.)

Huh, I could have sworn I tried that already. When was it added?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817139: [Pkg-sass-devel] Bug#817139: sassc: trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in package pysassc 0.9.3-1

[Jonas Smedegaard]

Quoting Axel Beckert (2016-03-08 13:14:54)
> Trying to install sassc with pysassc installed causes a file conflict:
> 
> Unpacking sassc (3.3.2-3) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/sassc_3.3.2-3_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in 
> package pysassc 0.9.3-1

The name "sassc" means "Sass implemented in C".

Since the package name "pysassc" seems to imply "sassc wrapper 
implemented in Python", I believe the proper fix here is for pysassc to 
not provide binary "sassc" but instead "pysassc".

...or simply drop the package pysassc, because there should be no need 
for that wrapper on systems where the real sassc is available.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#816376: [Pkg-owncloud-maintainers] Bug#816376: Bug#816376: Unfit upstream

[David Prévot]

Hi,

Le 08/03/2016 03:03, Jos Poortvliet a écrit :

> The situation is rather sad and frustrating

OK.

> as users who decided to trust the Debian developers and took their packages 
> over ownCloud's provided packages are now stuck on a version which can't 
> trivially be upgraded to either our upstream version or anything else.

The thing is, we were working on a proper upgrade path, but upstream
decided without even looking at it that it was “bad” (to put it mildly).
Because of upstream reaction, we have removed our work in progress, and
now the PR crap (as in words not backed by anything) follows:

> We would love to find a solution for them

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#817040: dpkg-deb -c: sort list by name

[Osamu Aoki]

Hi,

On Tue, Mar 08, 2016 at 01:10:49AM +0100, Guillem Jover wrote:
> I don't think the attached patch does what you intended though? --sort
> only works when packing (i.e. when reading from the filesystem).

Very true.  Excuse me.

Maybe basic command such as dpkg-deb shoudl not filter output through
"sort -k6"  ... but maybe it is OK for debc.

Thanks

Osamu

Bug#817126: grafana: FTBFS when built with dpkg-buildpackage -A (unable to chdir to _build)

[Dmitry Smirnov]

On Tuesday, 8 March 2016 10:02:46 AM AEDT Santiago Vila wrote:
> -O--parallel dh_auto_install -i -O--buildsystem=golang
> -O--builddirectory=_build -O--parallel dh_auto_install: error: unable to
> chdir to _build

This is not a problem in Grafana. I think the error is in Debhelper
buildsystem=golang module (dh-golang). dh_auto_install call fails when
builddirectory do not exist...

-- 
Cheers,
 Dmitry Smirnov.

---

The Santa myth is one of the most effective means ever devised for
intimidating children, eroding their self-esteem, twisting their
behavior, warping their values, and slowing their development of
critical thinking skills.
-- Tom Flynn, "The Trouble with Christmas"


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

Bug#817140: debdelta integration with apt

[Ritesh Raj Sarraf]

Package: debdelta
Version: 0.55
Severity: wishlist
Tags: patch


The following is what seems to be available in my setup. Now, I don't
recollect how this ended up on my machine. But I think this is a good
candidate for README.Debian, in debdelta package ?


rrs@learner:/usr/share/doc/debdelta$ cat /etc/apt/apt.conf.d/02debdelta 
APT::Periodic::Download-Upgradeable-Packages-Debdelta "1";
#  - Use debdelta-upgrade to download updates if available (0=disable)

APT::Periodic::Verbose "1";
#  - Send report mail to root
#  0:  no report (or null string)
#  1:  progress report   (actually any string)
#  2:  + command outputs (remove -qq, remove 2>/dev/null, add -d)
#  3:  + trace on
2016-03-08 / 18:11:59 ♒♒♒  ☺  

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

Versions of packages debdelta depends on:
ii  binutils2.26-5
ii  bzip2   1.0.6-8
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.21-9
ii  python  2.7.11-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages debdelta recommends:
ii  bsdiff   4.3-15
ii  gnupg-agent  2.1.11-6
ii  gnupg2   2.1.11-6
ii  lzma 9.22-2
ii  python-apt   1.1.0~beta1+b1
ii  python-debian0.1.27
ii  xdelta   1.1.3-9.1
ii  xdelta3  3.0.11-dfsg-1
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#817141: handbrake-cli: Using AVStream.codec.time_base is deprecated

[Jerry Quinn]

Package: handbrake-cli
Version: 0.10.2+ds1-2+b1
Severity: normal

Dear Maintainer,

While encoding a video into h.265 in a Matroska container, I see handbrake
printing out this message:

[matroska @ 0x7f56a4307da0] Using AVStream.codec.time_base as a timebase hint
to the muxer is deprecated. Set AVStream.time_base instead.

It would be good to change the API call being made before the deprecated
function disappears.




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

Kernel: Linux 4.1.0-2-amd64 (SMP w/16 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 handbrake-cli depends on:
ii  libass50.13.1-1
ii  libavcodec-ffmpeg567:2.8.4-1+b1
ii  libavformat-ffmpeg56   7:2.8.4-1+b1
ii  libavresample-ffmpeg2  7:2.8.4-1+b1
ii  libavutil-ffmpeg54 7:2.8.4-1+b1
ii  libbluray1 1:0.9.2-2
ii  libc6  2.21-9
ii  libdvdnav4 5.0.3-1
ii  libdvdread45.0.3-1
ii  libmp3lame03.99.5+repack1-9+b1
ii  libsamplerate0 0.1.8-8
ii  libswscale-ffmpeg3 7:2.8.4-1+b1
ii  libtheora0 1.1.1+dfsg.1-7
ii  libvorbis0a1.3.5-3
ii  libvorbisenc2  1.3.5-3
ii  libx264-1482:0.148.2601+gita0cd7d3-3
ii  libx265-79 1.9-3

handbrake-cli recommends no packages.

handbrake-cli suggests no packages.

-- no debconf information

Bug#816376: [Pkg-owncloud-maintainers] Bug#816376: Bug#816376: Unfit upstream

[Jos Poortvliet]

On dinsdag 8 maart 2016 08:37:35 CET David Prévot wrote:
> Hi,
> 
> Le 08/03/2016 03:03, Jos Poortvliet a écrit :
> > The situation is rather sad and frustrating
> 
> OK.
> 
> > as users who decided to trust the Debian developers and took their
> > packages over ownCloud's provided packages are now stuck on a version
> > which can't trivially be upgraded to either our upstream version or
> > anything else.
> The thing is, we were working on a proper upgrade path, but upstream
> decided without even looking at it that it was “bad” (to put it mildly).
> Because of upstream reaction, we have removed our work in progress, and
> 
> now the PR crap (as in words not backed by anything) follows:
> > We would love to find a solution for them

I know that that is how you choose to look at it - and I feel there is no 
value to discuss that.

> Regards
> 
> David


-- 
Disclaimer:
Everything I do and say is based on my view of the world today. I am not 
responsible for changes in the world, nor my view on it. Everything I say is 
meant in a positive and friendly way, unless explicitly stated otherwise.
find me on blog.jospoortvliet.com

Bug#817003: transition: glibc

[Steven Chamberlain]

Hi,

Many architectures will be binNMUd against libc6 2.22, but please on
kfreebsd-* could you binNMU these packages against libc0.1 2.22 instead:

  * p11-kit (breaks sid at the moment)
  * libnss-db

hurd-i386 may also need rebuilds against libc0.3 2.22:

  * (libp11 was binNMUd already)
  * dante
  * libbsd
  * libnss-db

The other one is libc6.1 on alpha, but I guess release team is not
responsible for that.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#807579: CUDA 7.5 planning

[Andreas Beckmann]

On 2016-03-08 12:30, Graham Inggs wrote:
> I was able to build the reverse-dependencies eztrace-contrib,
> hwloc-contrib and pycuda without modification.

Good to know!

>> Looking at ppc64el now ...
> 
> For Ubuntu, I think I will use the no-libcuda1 virtual package for
> ppc64el.  I don't think a Tesla driver package for ppc64el will be
> uploaded in time for the Xenial release.

OK, I added back the virtual package, it's used on Ubuntu only (but
provided everywhere). Untested. Does this work for you?


Andreas

Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Sergey Vojtovich]

Hi Lennart,

I adjusted your patch a bit, it seem to work well for me. Could you please
verify if you're fine with the attached version and it works for you too?

On Mon, Mar 07, 2016 at 04:35:43PM +0100, Lennart Weller wrote:
> On Mon, Mar 07, 2016 at 06:37:49PM +0400, Sergey Vojtovich wrote:
> > Existence of pid-file is a sure sign that there's mysqld running, the only
> > exception is mysqld crash. What do you think about skipping this check?
> > 
> > I'd also suggest to turn things around and check for pid-file first and then
> > just run "MYADMIN flush-logs" allowing it to return error in case of 
> > failure.
> 
> Yep. Switched the order for this one. But mysqladmin does not return 1
> when it fails to connect. Did some additional testing. For now I put it
> back to the way it was in the original logrotate and just check if
> stdout/stderr of the command is null.
> This probably merits a second bug report.
You mean "$($MYADMIN flush-logs)" doesn't return 1? I just tested it on my side
and got exit status 1.

Thanks,
Sergey
diff --git a/debian/mariadb-server-10.0.mysql-server.logrotate 
b/debian/mariadb-server-10.0.mysql-server.logrotate
index 789ad35..a19e9ec 100644
--- a/debian/mariadb-server-10.0.mysql-server.logrotate
+++ b/debian/mariadb-server-10.0.mysql-server.logrotate
@@ -10,18 +10,11 @@
compress
sharedscripts
postrotate
-   test -x /usr/bin/mysqladmin || exit 0
+  test -x /usr/bin/mysqladmin || exit 0
 
-   # If this fails, check debian.conf! 
-   MYADMIN="/usr/bin/mysqladmin 
--defaults-file=/etc/mysql/debian.cnf"
-   if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
- # Really no mysqld or rather a missing debian-sys-maint user?
- # If this occurs and is not a error please report a bug.
- if ps cax | grep -q mysqld; then
-   exit 1
- fi 
-   else
- $MYADMIN flush-logs
-   fi
+  if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` 
]; then
+# If this fails, check debian.conf!
+mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs
+  fi
endscript
 }

Bug#817128: lintian: automatically find the .changes/.dsc/.deb files based on debian/{control,changelog}

[Jakub Wilk]

* Paul Wise , 2016-03-08, 20:31:
Have you tried running lintian without arguments? (See the 
"CHECKING LAST BUILD" section in the manual page for details.)

Huh, I could have sworn I tried that already. When was it added?


In Lintian 2.5.9 (released in June 2012).

--
Jakub Wilk

Bug#807579: CUDA 7.5 planning

[Graham Inggs]

On 08/03/2016 14:47, Andreas Beckmann wrote:

OK, I added back the virtual package, it's used on Ubuntu only (but
provided everywhere). Untested. Does this work for you?


That's great, thank you!

Bug#817035: transition: qwt

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 08 March 2016 09:59:09 Lisandro Damián Nicanor Pérez Meyer wrote:
> We are ready to binNMU qsapecng (if you didn't beat me to that already).
> 
> I still have no news about zygrib.

My bad, zygrib has already been uploaded \o/


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#817142: Add systemd support

[Timo Aaltonen]

Source: opendnssec
Version: 1.4.9-1
Severity: wishlist

Hi

 The attached patch adds support for systemd to opendnssec, which I need
for FreeIPA 4.3.


-- 
t
commit 87783f37bf849b9db6fff7973d46fe12c0c3766f
Author: Timo Aaltonen 
Date:   Tue Mar 8 14:53:54 2016 +0200

Add systemd service files and default config.

diff --git a/debian/changelog b/debian/changelog
index e6d11b4..8da3cb4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+opendnssec (1:1.4.9-2) UNRELEASED; urgency=medium
+
+  * Add systemd service files and default config.
+
+ -- Timo Aaltonen   Tue, 08 Mar 2016 09:24:35 +0200
+
 opendnssec (1:1.4.9-1) unstable; urgency=medium
 
   * Install migrate_1_4_8 SQL scripts into opendnsec-common package
diff --git a/debian/default/opendnssec b/debian/default/opendnssec
new file mode 100644
index 000..1cf67f2
--- /dev/null
+++ b/debian/default/opendnssec
@@ -0,0 +1,2 @@
+ODS_SIGNERD_OPT=""
+ODS_ENFORCERD_OPT=""
diff --git a/debian/opendnssec-common.install b/debian/opendnssec-common.install
index 0eaebf2..bcc8f0d 100644
--- a/debian/opendnssec-common.install
+++ b/debian/opendnssec-common.install
@@ -1,3 +1,4 @@
+debian/default/opendnssec etc/default
 etc/opendnssec/*.xml /usr/share/opendnssec/
 usr/bin/ods-kasp2html
 usr/sbin/ods-control
diff --git a/debian/opendnssec-common.tmpfile b/debian/opendnssec-common.tmpfile
new file mode 100644
index 000..64a2864
--- /dev/null
+++ b/debian/opendnssec-common.tmpfile
@@ -0,0 +1 @@
+d /run/opendnssec 0775 opendnssec opendnssec - -
diff --git a/debian/opendnssec-enforcer.service b/debian/opendnssec-enforcer.service
new file mode 100644
index 000..fb60d14
--- /dev/null
+++ b/debian/opendnssec-enforcer.service
@@ -0,0 +1,12 @@
+[Unit]
+Description=OpenDNSSEC Enforcer daemon
+After=syslog.target network.target
+
+[Service]
+Type=forking
+PIDFile=/var/run/opendnssec/enforcerd.pid
+EnvironmentFile=-/etc/default/opendnssec
+ExecStart=/usr/sbin/ods-enforcerd $ODS_ENFORCERD_OPT
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/opendnssec-signer.service b/debian/opendnssec-signer.service
new file mode 100644
index 000..19e4b34
--- /dev/null
+++ b/debian/opendnssec-signer.service
@@ -0,0 +1,12 @@
+[Unit]
+Description=OpenDNSSEC signer daemon
+After=syslog.target network.target ods-enforcerd
+
+[Service]
+Type=simple
+PIDFile=/var/run/opendnssec/signerd.pid
+EnvironmentFile=-/etc/default/opendnssec
+ExecStart=/usr/sbin/ods-signerd -d $ODS_SIGNERD_OPT
+
+[Install]
+WantedBy=multi-user.target

Bug#817035: transition: qwt

[Lisandro Damián Nicanor Pérez Meyer]

We are ready to binNMU qsapecng (if you didn't beat me to that already).

I still have no news about zygrib.

Thanks!

Lisandro.

-- 
Ud. está viendo a la persona que ven nuestros clientes.
 Leyenda pegada en el espejo de una empresa.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#817035: transition: qwt

[Alastair McKinstry]

On 08/03/2016 13:00, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 08 March 2016 09:59:09 Lisandro Damián Nicanor Pérez Meyer wrote:
>> We are ready to binNMU qsapecng (if you didn't beat me to that already).
>>
>> I still have no news about zygrib.
> My bad, zygrib has already been uploaded \o/
>
Apologies for not informing you sooner.

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#817143: herbstluftwm: panel.sh requires xfonts-base to be installed

[Sebastian Hahn]

Package: herbstluftwm
Version: 0.7.0-1~bpo8+1
Severity: wishlist

Dear Maintainer,

hlwm recommends dzen2 to support the default panel. This is not enough
to make it work, as a required font is missing. Installing xfonts-base
fixes this issue. I'd like to request the addition of a recommendation
of xfonts-base for hlwm.

Cheers
Sebastian

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

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

Versions of packages herbstluftwm depends on:
ii  libc6 2.19-18+deb8u3
ii  libgcc1   1:4.9.2-10
ii  libglib2.0-0  2.42.1-1
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1

Versions of packages herbstluftwm recommends:
ii  dzen2  0.9.5~svn271-4
ii  xterm  312-2

Versions of packages herbstluftwm suggests:
ii  suckless-tools  40-1

-- no debconf information

Bug#817035: transition: qwt

[Alastair McKinstry]

On 07/03/2016 12:43, Lisandro Damián Nicanor Pérez Meyer wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Dear RT: this is a request to transition qwt from experimental to unstable.
>
> As the auto tracker noted this release has an API/ABI breakage without
> upstream doing a proper SONAME bump and so Qt4's libqwt6 is transitioning to
> libqwt6ab1.
>
> It also adds Qt5's libqwt-qt5-6.
>
> So rdeps can either use the Qt4 version or migrate to Qt5.
>
> Current rdeps and their statuses wrt this transition:
>
> - libterralib: it's not marked in the auto tracker because they are mixing 
>   Qt4 and Qt5 and it's probably not using libqwt at all. I already filed a 
> bug 
>   for them.
I'm preparing a -6 upload which will depend on libqwt-qt5-dev for the
transition.
I'm also working on a fuller fix, adding the terraView functionality
(which uses qwt)
but that can wait until after qwt 5 enters testing.

regards
Alastair


> Kinds regards, Lisandro.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
>

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#807377: binutils: build for N32 and MIPS r6

[YunQiang Su]

On Tue, 8 Dec 2015 15:15:03 +0800 YunQiang Su  wrote:
> Package: src:binutils
> Version: 2.25.90.20151125-2
> Control: block -1 by 807340
>
> This patch enable building n32 and {32r6,n32r6,64r6} for mips.
> Please add it when dpkg patch is merged.

I refreshed this patche. See the attachment.

>
> --
> YunQiang Su
diff --git a/debian/control b/debian/control
index fede768..9e749ab 100644
--- a/debian/control
+++ b/debian/control
@@ -325,3 +325,107 @@ Description: GNU binary utilities, for sparc64-linux-gnu 
target
  .
  You don't need this package unless you plan to cross-compile programs
  for sparc64-linux-gnu.
+
+Package: binutils-mips64-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mips64-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mips64-linux-gnuabin32 target, for use in a cross-compilation environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mips64-linux-gnuabin32.
+
+Package: binutils-mips64el-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mips64el-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mips64el-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mips64el-linux-gnuabin32.
+
+Package: binutils-mipsisa32r6-linux-gnu
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa32r6-linux-gnu target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa32r6-linux-gnu target, for use in a cross-compilation environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa32r6-linux-gnu.
+
+Package: binutils-mipsisa32r6el-linux-gnu
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa32r6el-linux-gnu target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa32r6el-linux-gnu target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa32r6el-linux-gnu.
+
+Package: binutils-mipsisa64r6-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6-linux-gnuabin32.
+
+Package: binutils-mipsisa64r6el-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6el-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6el-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6el-linux-gnuabin32.
+
+Package: binutils-mipsisa64r6-linux-gnuabi64
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6-linux-gnuabi64 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6-linux-gnuabi64 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6-linux-gnuabi64.
+
+Package: binutils-mipsisa64r6el-linux-gnuabi64
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6el-linux-gnuabi64 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6el-linux-gnuabi64 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6el-linux-gnuabi64.
diff --git a

Bug#817144: RFS: python-dtcwt/0.10.1+dfsg1-4

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-dtcwt"

* Package name: python-dtcwt
  Version : 0.10.1+dfsg1-4
  Upstream Author : Rich Wareham 
* URL : https://github.com/rjw57/dtcwt
* License : BSD
  Section : science

It builds those binary packages:

  python-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 2
  python-dtcwt-doc - Documentation of the Python implementation of the 
DT-CWT

  python3-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 3

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


  http://mentors.debian.net/package/python-dtcwt

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-dtcwt/python-dtcwt_0.10.1+dfsg1-4.dsc


Successful build logs on debomatic:

  [i386] 
http://debomatic-i386.debian.net/distribution#unstable/python-dtcwt/0.10.1+dfsg1-4/buildlog
  [armhf] 
http://debomatic-armhf.debian.net/distribution#unstable/python-dtcwt/0.10.1+dfsg1-4/buildlog


Changes since the last upload:

  * Clean documentation build and egg-info directories.
  * Add patch fixing runtime failure with Python 3.
File: Use-explicit-integer-division.patch
  * Bump standards version to 3.9.7, no changes required.
  * d/watch: add missing repacksuffix option.

Regards,
Ghislain Vaillant

Bug#661654: merge 661654 661973

[Stéphane Aulery]

retitle 661654 libreoffice-common: consider adding a '--convert-to help' 
feature that would work like "-vo help" in 'mplayer'
forwarded 661654 https://bugs.documentfoundation.org/show_bug.cgi?id=98153
merge 661654 661973
stop
-

Hello,

Upstream replied that the request for documentation in the manpage is not 
maintainable, but the "-vo help" option is a good idea.

Regards,

-- 
Stéphane Aulery

Bug#813585: Confirmed

[Michel Meyers]

I can confirm this to be an issue with 2.5+dfsg-4+b1 and also confirm
that re-compiling it with the upstream patch makes it work correctly.

--- qemu-2.5+dfsg.orig/block.c
+++ qemu-2.5+dfsg/block.c
@@ -2028,7 +2028,7 @@ static void change_parent_backing_link(B
 }
 if (from->blk) {
 blk_set_bs(from->blk, to);
-if (!to->device_list.tqe_prev) {
+if (!to->device_list.tqe_prev || !*to->device_list.tqe_prev) {
 QTAILQ_INSERT_BEFORE(from, to, device_list);
 }
 QTAILQ_REMOVE(&bdrv_states, from, device_list);



- Michel

Bug#800845: autopkgtest: Add support for nested VMs

[Christian Seiler]

On 07.03.2016 10:21, Martin Pitt wrote:
> However, there's still one major issue left: Despite the
> "readonly=on", one can actually mount /dev/vdb1 in the VM and write
> files into it! This sounds like a QEMU bug (running
> 1:2.5+dfsg-5ubuntu4 here), but as long as that exists this is
> dangerous as this alters your pristine base images. I already tried to
> add the "readonly=on" to the "device_add", but that's just an "unknown
> property". Unfortunately this stuff isn't documented very well..

So I just tried this on an Ubuntu Wily box, both with the QEMU from
Wily and with the QEMU from Xenial (only upgraded QEMU + deps, didn't
upgrade the entire OS) - and I really cannot reproduce this.

Host kernel: 4.2.0-30-generic
QEMU: 1:2.3+dfsg-5ubuntu9.2 and 1:2.5+dfsg-5ubuntu4
Image: adt-sid.img as generated per adt-virt-qemu(1) manpage
   instructions with vmdebootstrap (exactly, no changes!)
   Tried both writable to user executing QEMU and not
   writable to user executing QEMU.

My Debian machine with which I tried that earlier had:

Host kernel: 4.4.2-3 (from sid)
QEMU: 1:2.5+dfsg-4~bpo8+1
Image: see above

I consistently get (via adt-run --shell, autopkgtest git master, no
changes) in _any_ of these setups:

mount: /dev/vdb1 is write-protected, mounting read-only

(Now I haven't tried the newest kernel on the Ubuntu side, but I'd
_really_ be surprised if that changed anything - especially since
I did try with a recent kernel on Debian with basically the same
QEMU version.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#767016: cron does start before sssd and therefore authentication fails

[Harald Dunkel]

Attached is a patch. Hope this helps.

Harri
diff -ur old/cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
--- old/cron-3.0pl1/debian/changelog	2016-03-08 14:33:16.0 +0100
+++ cron-3.0pl1/debian/changelog	2016-03-08 14:32:51.976319657 +0100
@@ -1,3 +1,10 @@
+cron (3.0pl1-128.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * make sure cron is started last and stopped first. Closes: #767016
+
+ -- Harald Dunkel   Tue, 08 Mar 2016 14:12:41 +0100
+
 cron (3.0pl1-128) unstable; urgency=medium
 
   * d/cron.service: Use KillMode=process to kill only the daemon.
diff -ur old/cron-3.0pl1/debian/cron.init cron-3.0pl1/debian/cron.init
--- old/cron-3.0pl1/debian/cron.init	2016-03-08 14:33:16.0 +0100
+++ cron-3.0pl1/debian/cron.init	2016-03-08 14:11:38.048543606 +0100
@@ -5,8 +5,8 @@
 # Provides:  cron
 # Required-Start:$remote_fs $syslog $time
 # Required-Stop: $remote_fs $syslog $time
-# Should-Start:  $network $named slapd autofs ypbind nscd nslcd winbind
-# Should-Stop:   $network $named slapd autofs ypbind nscd nslcd winbind
+# Should-Start:  $all
+# Should-Stop:   $all
 # Default-Start: 2 3 4 5
 # Default-Stop:
 # Short-Description: Regular background program processing daemon
diff -ur old/cron-3.0pl1/debian/cron.service cron-3.0pl1/debian/cron.service
--- old/cron-3.0pl1/debian/cron.service	2016-03-08 14:33:16.0 +0100
+++ cron-3.0pl1/debian/cron.service	2016-03-08 14:12:29.118294423 +0100
@@ -7,6 +7,7 @@
 ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
 IgnoreSIGPIPE=false
 KillMode=process
+Type=idle
 
 [Install]
 WantedBy=multi-user.target

Bug#817126: grafana: FTBFS when built with dpkg-buildpackage -A (unable to chdir to _build)

[Santiago Vila]

On Tue, Mar 08, 2016 at 11:41:13PM +1100, Dmitry Smirnov wrote:
> On Tuesday, 8 March 2016 10:02:46 AM AEDT Santiago Vila wrote:
> > -O--parallel dh_auto_install -i -O--buildsystem=golang
> > -O--builddirectory=_build -O--parallel dh_auto_install: error: unable to
> > chdir to _build
> 
> This is not a problem in Grafana. I think the error is in Debhelper
> buildsystem=golang module (dh-golang). dh_auto_install call fails when
> builddirectory do not exist...

This is hardly a problem in debhelper, which is just a tool to
simplify debian/rules. What debhelper does is what you tell it to do,
nothing less and nothing more.

In this case we are using "dpkg-buildpackage -A" so the generic dh rule
does not work for the "build" because there is a specific build-indep target.

So it's not surprising that the build directory does not exist.

If you have to split dh_auto_install into -arch and -indep, go ahead,
but please do not blame debhelper.

Thanks.

Bug#817121: [buildd-tools-devel] Bug#817121: schroot: Failing lintian call via --run-session

[Mathias Behrle]

* Johannes Schauer: " Re: [buildd-tools-devel] Bug#817121: schroot: Failing
  lintian call via --run-session" (Tue, 08 Mar 2016 12:21:18 +0100):

Hi Johannes,

> Control: reassign -1 sbuild 0.68.0-1.0~exp1
> 
> Quoting Mathias Behrle (2016-03-08 10:28:04)
> > I am hit by this error with lintian failing when called in post build
> > chroot by sbuild. Not entirely sure if the assignment to schroot is
> > correct, but seems to me most adequate.
> > 
> > The relevant lines of the sbuild debug log:
> > 
> > ...
> > D: Setting Dummy package path=undef
> > D: Setting Dummy archive directory=undef
> > D: Setting Dummy Release file=undef
> > I: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865 --run-session
> > -q -u mathiasb -p -- lintian tryton-server_3.8.3-2_amd64.changes D: Running
> > command: schroot -d /<> -c sid-amd64-sbuild-IgSZzA-3865
> > --run-session -q -u mathiasb -p -- lintian
> > tryton-server_3.8.3-2_amd64.changes tryton-server_3.8.3-2_amd64.changes is
> > not available D: Setting Lintian Reason=pass
> > 
> > D: Setting Lintian Reason=error
> > D: Setting Lintian Reason=fail
> > E: Lintian run failed (policy violation)
> > ...
> > 
> > Basic information:
> > - I am using overlay in schroot conf
> > - I am aware of #798835 and running sbuild from experimental
> > (0.68.0-1.0~exp1)
> > 
> > For debugging purposes I kept the chroot sessions available by running 
> > $ sbuild --purge=never -D
> > 
> > Indeed the command fails when calling lintian from outside the chroot:
> > 
> > mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> > schroot -d /build/tryton-seriver-g23533 \
> > -c sid-amd64-sbuild-IgSZzA-3865 --run-session -q -u mathiasb \
> > -p -- lintian tryton-server_3.8.3-2_amd64.changes
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LANGUAGE = (unset),
> > LC_ALL = (unset),
> > LANG = "de_DE.utf8"
> >  are supported and installed on your system.
> >  perl: warning: Falling back to the standard
> >  locale ("C").
> > tryton-server_3.8.3-2_amd64.changes is not available
> > 
> > but succeeds with a call to ls:
> > 
> > mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> > schroot -d /build/tryton-server-g23533 -c sid-amd64-sbuild-IgSZzA-3865 \
> > --run-session -q -u mathiasb -p -- ls
> > tryton-server-3.8.3  tryton-server-doc_3.8.3-2_all.deb
> > tryton-server_3.8.3-2.debian.tar.xz  tryton-server_3.8.3-2.dsc
> > tryton-server_3.8.3-2_all.deb  tryton-server_3.8.3-2_amd64.changes
> > tryton-server_3.8.3.orig.tar.gz
> > 
> > also the lintian call succeeds inside the chroot:
> > 
> > mathiasb@monsterix:~/bin/tryton/debian_builder/tmp/tryton-server$
> > schroot -r -c sid-amd64-sbuild-IgSZzA-3865
> > ...
> > (sid-amd64-sbuild)mathiasb@monsterix:/$ cd build/tryton-server-g23533/
> > (sid-amd64-sbuild)mathiasb@monsterix:/build/tryton-server-g23533$
> > lintian -v tryton-server_3.8.3-2_amd64.changes 
> > N: Using profile debian/main.
> > N: Setting up lab in /tmp/temp-lintian-lab-WUBBSgAJE8 ...
> > N: Unpacking packages in group tryton-server/3.8.3-2
> > N: 
> > N: Processing changes file tryton-server (version 3.8.3-2, arch source
> > all) ...
> > N: 
> > N: Processing source package tryton-server (version 3.8.3-2, arch
> > source) ...
> > N: 
> > N: Processing binary package tryton-server-doc (version 3.8.3-2, arch
> > all) ...
> > N: 
> > N: Processing binary package tryton-server (version 3.8.3-2, arch all)
> > ...
> > 
> > 
> > I am running out of ideas why especially the lintian command is failing
> > with schroot --run-session. Just now I am unable to reboot this machine,
> > but this will be one of the next steps to check. Please let me know what
> > I can do to track down further this issue.  
> 
> thanks a lot for testing the sbuild version in experimental!
> 
> The problem here is not with schroot but with sbuild. The version in
> experimental decouples the location where the package is built from the
> machine where sbuild was started. This in turn means that the machine running
> sbuild does not have direct access to anything within the chroot anymore.
> 
> What you are seeing here is a remaining bug of this change.
> 
> Thanks for bringing it up - I'll take care of it with the next experimental
> upload.

There is also another issue with the package from experimental.

I have in my schroot sbuild fstab:
/var/run/var/runnonerw,bind,rslave 0   0
/tmp/tmpnonerw,bind,rslave 0   0

to be able to connect to the gpg agent of the host.

This is also broken (no password challenge when it comes to sign a package) and
is probably due to the same changes.
 
> Until then, if you don't want to run sbuild with --no-run-lintian, please fall
> back to the sbuild version from unstable.
> 
> Thanks!
> 
> cheers, josch

Thanks,
Mathias



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpxyW

Bug#817121: [buildd-tools-devel] Bug#817121: schroot: Failing lintian call via --run-session

[Johannes Schauer]

Hi,

Quoting Mathias Behrle (2016-03-08 14:38:19)
> There is also another issue with the package from experimental.
> 
> I have in my schroot sbuild fstab:
> /var/run/var/runnonerw,bind,rslave 0  
>  0
> /tmp/tmpnonerw,bind,rslave 0   0
> 
> to be able to connect to the gpg agent of the host.
> 
> This is also broken (no password challenge when it comes to sign a package)
> and is probably due to the same changes.

that is correct. The decoupling of the chroot from the host means that there is
no communication between the two without special magic.

I actually never used sbuild to also sign something I'm building. What is the
use case of this? Wouldn't one want to use mergechanges after sbuild is done
building and then debsign manually?

If the feature is still useful, this can be fixed by moving the signing step to
when the relevant files have already been moved from within the build
environment to the host.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#720378: cctools: FTBFS on non-linux

[Steven Chamberlain]

severity 720378 important
user debian-...@lists.debian.org
usertags 720378 + kfreebsd
thanks

Hi,

Sorry, I did not see this bug.  It should have been downgraded because
kfreebsd and hurd are not release architectures.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#797858: devscripts: build-rdeps

[Osamu Aoki]

Hi,

This is one of the important bug with patch.  

This patch should also add dose-ceve (>= 4.0) to debian/control suggest
list and description listing required program.   Wait ... there is no
such package.  I see ceve virtual package suggesting dose-extra.

$ type dose-ceve
dose-ceve is /usr/bin/dose-ceve
$ dpkg -S  dose-ceve
dose-extra: /usr/bin/dose-ceve
dose-extra: /usr/share/man/man1/dose-ceve.1.gz

So some trivial documentation updates are also needed.

Other than that, this looks nice.

Do you have updated patch etc., Johannes?

Osamu

Bug#817147: multipathd is built without systemd support

[Janusz Dziemidowicz]

Package: multipath-tools
Version: 0.5.0+git1.656f8865-5

Recent commit (e91ac62) causes multipathd to be built without systemd
support. This causes multipathd.service unit to fail with timeout,
since it has Type=notify.
The problem is that first an udeb is built, with USE_SYSTEMD=0. Then
the main .deb is built, with USE_SYSTEMD=1, but the second make call
does nothing as the project is already compiled. The result is that
udeb version, without systemd support, is packaged inside .deb

Adding:
$(MAKE) clean
at the end of build-multipath-udeb-stamp target seems to fix the problem.

-- 
Janusz Dziemidowicz

Bug#817146: gdal-bin: ogr2ogr segfault

[Andy Wood]

Package: gdal-bin
Version: 2.0.2+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Running an ogr2ogr command that had been working until the most recent update 
in testing:

ogr2ogr -a_srs WGS84 -f GeoJSON -where "ID=098530" -nln "098530" p098530.json 
argos.xml

   * What was the outcome of this action?

Segfault and error message.
In /var/log/syslog:

kernel: [1918421.641659] ogr2ogr[11691]: segfault at ceb3f0 ip 00ceb3f0 
sp 7fffbd837758 error 15

At command line:

ERROR 1: Type mismatch or improper type of arguments to = operator.
FAILURE: SetAttributeFilter(ID=098530) on layer 'argos_trip' failed.
Segmentation fault


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

Kernel: Linux 4.3.0-1-amd64 (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)

Versions of packages gdal-bin depends on:
ii  libc6   2.21-9
ii  libgcc1 1:5.3.1-10
ii  libgdal20 [gdal-abi-2-0-2]  2.0.2+dfsg-2
ii  libstdc++6  5.3.1-10

gdal-bin recommends no packages.

Versions of packages gdal-bin suggests:
ii  python-gdal  2.0.2+dfsg-2

-- no debconf information

Bug#817145: nmu: p11-kit_0.23.2-3

[James Clarke]

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

nmu p11-kit_0.23.2-3 . kfreebsd-amd64 kfreebsd-i386 . unstable . -m "Rebuild
against libc0.1 2.22"

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Jakub Wilk]

* Dmitry Bogatov , 2016-03-08, 12:01:

[NO DD, can't sponsor]


[DD, but won't sponsor either]


There is nice tool `check-all-the-things'. It reveals


check-all-the-things output greatly depends on which packages you have 
installed, so it would be helpful to say which underlying tools found 
the problems...



* loads of spelling errors in po/


check-all-the-things supports multiple spell-checker and none of them 
are IMO helpful for automated spell-checking all PO files:


* spellintian and codespell assume that the checked text is English; so 
they will found misspelling in the original messages, which should be 
fix elsewhere; and false positives in the translated messages.


* POFileSpell flags every single word in the translated messages if 
there's no dictionary installed for the target language. (Even if you had 
the appropriate dictionaries installed, you probably don't know most of 
the languages enough to discern between true and false positives...)



Speaking of PO files, i18nspector finds some interesting bugs in them:

E: po/uk.po: c-format-string-missing-arguments msgid "`%s' is not a valid regular 
expression: %s": 1 (msgstr) < 2 (msgid)
E: po/zh.po: c-format-string-argument-type-mismatch msgid "Error while processing 
command `%s' (%s line %u): %s": int * (msgstr) != unsigned int (msgid)
E: po/zh.po: c-format-string-missing-arguments msgid "Error: couldn't mark feed read: 
%s": 0 (msgstr) < 1 (msgid)

(plus some other, less severe problems)

--
Jakub Wilk

Bug#100808: Stay blessed!

[Alisa Cepeda]

Dear beloved,

I come openly to you with one intention, a belief that this world can be saved 
if we all add our efforts and spread the wealth across all nations; 
irrespective of race, gender, or origin; to be one family in the Lord and to be 
thankful for every moment we share with one another because it may well be our 
last. Mine is such a tale and my time to go is near; I have been diagnosed with 
Lung cancer and the doctors over here in paris said the cancer has spread 
drastically and chemotherapy is all that can be done. I know my faith is 
sealed, but I strongly believe that even though my time is short; I can still 
make another person's live worth every minute. I have used my final days to 
spread my family's wealth around to welfare homes and individuals but now that 
my health has worsened, I can not do this anymore and need someone who would be 
reliable enough to carry on from where I will stop. You must believe in unity 
and have a strong will to work very hard. I want to better your life and the 
life of others across the world. Beloved, there is a lot I need to share in 
thoughts, kind and opinions. An ear that would hear what I have to share is all 
I need right no; for this reason, if you have a few moment to spare kindly 
reach me via alisacap...@gmail.com. 

I hope this email reaches you well. Stay blessed!

Regards,

Ms Alisa Cepeda

Bug#797858: devscripts: build-rdeps

[Johannes Schauer]

Hi,

Quoting Osamu Aoki (2016-03-08 14:52:48)
> This patch should also add dose-ceve (>= 4.0) to debian/control suggest list
> and description listing required program.   Wait ... there is no such
> package.  I see ceve virtual package suggesting dose-extra.
> 
> $ type dose-ceve
> dose-ceve is /usr/bin/dose-ceve
> $ dpkg -S  dose-ceve
> dose-extra: /usr/bin/dose-ceve
> dose-extra: /usr/share/man/man1/dose-ceve.1.gz
> 
> So some trivial documentation updates are also needed.
> 
> Other than that, this looks nice.
> 
> Do you have updated patch etc., Johannes?

sorry, I don't have time to update my patch right now. I'll be more free after
June. If this bug is still open by then, feel free to ping me again.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#817146: gdal-bin: ogr2ogr segfault

[Bas Couwenberg]

Control: tags -1 moreinfo

Hi Andy,


Running an ogr2ogr command that had been working until the most recent
update in testing:

ogr2ogr -a_srs WGS84 -f GeoJSON -where "ID=098530" -nln "098530"
p098530.json argos.xml


Can you provide the data file(s) to reproduce this issue?

Kind Regards,

Bas