Bug#813415: libvigraimpex5v5: soname bump without package name change

[Andreas Metzler]

On 2016-02-13 Daniel Stender  wrote:
> On 13.02.2016 07:52, Andreas Metzler wrote:
[...]
> > Is there something I can do to help? Currently reverse dependencies are
> > broken, due to a binNMU hugin in *testing* will not run at all.

> Thanks for the note and the offer. If you would have suggestions how to make
> Vigra run on the failing archs again, and what might be the background of
> #812850 (fail of test/impex on EXR) that would be very much welcome ...

Hello,

I cannot help a lot there, except for also involving upstream
.

Still, could you please fix the package misnaming issue with high
priority? - It should not wait on a fix for the build-errors.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#807579: [CUDA 7.5] patch version 7, driver is a potential blocker

[lumin]

On Sun, 2016-02-14 at 08:32 +0200, Graham Inggs wrote:
> On 14 February 2016 at 08:22, lumin  wrote:
> > Or is there a way telling {dh_,dpkg-}shlibdeps to ignore libcuda.so.1 ?
> 
> I believe Andreas already worked around this in r6034.
> 
> [1] https://anonscm.debian.org/viewvc/pkg-nvidia?view=revision&revision=6034

Oh wait, take a look at what I have found.

There is NO GeForce driver for ppc64el, but
there is *Tesla* driver for ppc64el !

TESLA DRIVER FOR LINUX POWER8
Version:352.79
Release Date:   2016.2.1
Operating System: Linux POWER8
CUDA Toolkit:   7.5

There is a .run ball for ppc64el:
http://www.nvidia.com/download/driverResults.aspx/98333/en-us
direct download link:
http://us.download.nvidia.com/Ubuntu/352.79/NVIDIA-Linux-ppc64le-352.79.run

These binary blobs are indeed provided:

libcuda.so.352.79   
libnvidia-cfg.so.352.79 
libnvidia-ml.so.352.79  
libnvidia-opencl.so.352.79  
libOpenCL.so.1.0.0  

So let's see how anbe think about this :-)

Bug#781416: manpage should document --jobserver-fds and the jobserver pipe

[Manoj Srivastava]

Could you please provide a pointer to these docs, or any suggested wording you 
might have? That'd save me some work.

  Manoj

On February 13, 2016 10:35:44 PM PST, Josh Triplett  
wrote:
>On Sat, Feb 13, 2016 at 09:51:41PM -0800, Manoj Srivastava wrote:
>> On Sat, Mar 28 2015, Josh Triplett wrote:
>> > Package: make
>> > Version: 4.0-8.1
>> > Severity: wishlist
>> 
>> > The --jobserver-fds option, and the jobserver pipe used to handle
>-j
>> > correctly in recursive make invocations, ought to have
>documentation in
>> > the manpage.
>> 
>> This is not a user facing public interface, so I am not sure
>it
>>  belongs in the manual. Did you have a use for this information?
>
>Yes: trying to build a program that, like gcc's LTO linker, can
>integrate with make's jobserver.  gcc's LTO linker can run multiple
>threads in parallel, and can use make's jobserver pipe to manage how
>many threads it runs at a time.  If you pass -flto=jobserv to gcc, and
>tell make to treat gcc as a sub-make, gcc will respect make's jobserver
>pipe when spawning its threads.
>
>That seems like a really good idea for any program used as part of a
>build process and capable of running multiple parallel threads for
>performance.  And conversely, any other build system capable of
>spawning
>off other programs and running multiple jobs in parallel could follow
>the same convention, to interoperate with make.
>
>So, I wanted to learn how to build a program that could interoperate
>with make like GCC did.  I figured out most of the details, but the
>interface has some subtleties.  For instance, when make spawns a
>sub-make (or any other program launched with '+' and acting like a
>sub-make), the sub-make can always run one "free" job in addition to
>one
>job per byte read from the jobserver pipe, and should not write back a
>byte when that "free" job completes, because the parent make (or some
>ancestor make) will have consumed a byte (or used its free job) to run
>the sub-make.
>
>This kind of subtlety makes the interface worth documenting.  Some
>third-party articles document the jobserver, but make's own manpage
>ought to do so as well.
>
>- Josh Triplett

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Bug#781416: manpage should document --jobserver-fds and the jobserver pipe

[Josh Triplett]

On Sat, Feb 13, 2016 at 09:51:41PM -0800, Manoj Srivastava wrote:
> On Sat, Mar 28 2015, Josh Triplett wrote:
> > Package: make
> > Version: 4.0-8.1
> > Severity: wishlist
> 
> > The --jobserver-fds option, and the jobserver pipe used to handle -j
> > correctly in recursive make invocations, ought to have documentation in
> > the manpage.
> 
> This is not a user facing public interface, so I am not sure it
>  belongs in the manual. Did you have a use for this information?

Yes: trying to build a program that, like gcc's LTO linker, can
integrate with make's jobserver.  gcc's LTO linker can run multiple
threads in parallel, and can use make's jobserver pipe to manage how
many threads it runs at a time.  If you pass -flto=jobserv to gcc, and
tell make to treat gcc as a sub-make, gcc will respect make's jobserver
pipe when spawning its threads.

That seems like a really good idea for any program used as part of a
build process and capable of running multiple parallel threads for
performance.  And conversely, any other build system capable of spawning
off other programs and running multiple jobs in parallel could follow
the same convention, to interoperate with make.

So, I wanted to learn how to build a program that could interoperate
with make like GCC did.  I figured out most of the details, but the
interface has some subtleties.  For instance, when make spawns a
sub-make (or any other program launched with '+' and acting like a
sub-make), the sub-make can always run one "free" job in addition to one
job per byte read from the jobserver pipe, and should not write back a
byte when that "free" job completes, because the parent make (or some
ancestor make) will have consumed a byte (or used its free job) to run
the sub-make.

This kind of subtlety makes the interface worth documenting.  Some
third-party articles document the jobserver, but make's own manpage
ought to do so as well.

- Josh Triplett

Bug#807579: [CUDA 7.5] patch version 7, driver is a potential blocker

[Graham Inggs]

On 14 February 2016 at 08:22, lumin  wrote:
> Or is there a way telling {dh_,dpkg-}shlibdeps to ignore libcuda.so.1 ?

I believe Andreas already worked around this in r6034.

[1] https://anonscm.debian.org/viewvc/pkg-nvidia?view=revision&revision=6034

Bug#807579: control

[lumin]

Control: retitle -1 [CUDA 7.5, patch] bumping CUDA from 7.0 to 7.5

Bug#814684: RFS: ftp-upload/1.5+nmu2 -- put files with FTP from a script [RC, NMU]

[Giovani Augusto Ferreira]

Package: sponsorship-requests
Severity: important

Dear mentors,

  I am looking for a sponsor for a NMU of the package "ftp-upload"

 * Package name: ftp-upload
   Version : 1.5+nmu2
   Upstream Author : Roderick Schertler
 * License : GPL-2+
   Section : net

  It builds those binary packages:

ftp-upload - put files with FTP from a script

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

  http://mentors.debian.net/package/ftp-upload


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

dget -x 
http://mentors.debian.net/debian/pool/main/f/ftp-upload/ftp-upload_1.5+nmu2.dsc


  Changes since the last upload:


  * Non-maintainer upload.
  * Update DH level to 9. (Closes: #800173)
  * debian/compat: created.
  * debian/control:
 - Added the ${misc:Depends} variable to provide the right install
   dependencies.
 - Bumped Standards-Version to 3.9.6.
  * debian/rules: DH_COMPAT flag disabled.



  Regards,
   Giovani Agusto Ferreira

Bug#807579: [CUDA 7.5] patch version 7, driver is a potential blocker

[lumin]

Hi everyone,

This is the v7 patch. Current status:
there's nearly no difference between v6 and v7 patch.

[amd64] several weeks ago it builds. list-missing is checked.
but don't know if ppc64el stuff breaks anything.

[ppc64el] if libcuda.so.1 from nvidia-driver* can be provided for 
  ppc64el, it should be able to pass the build.
  list-missing not checked.


For ppc64el dpkg-shlibdeps requires a `libcuda.so.1` for ppc64el, which means
the nvidia driver for ppc64el should be uploaded before CUDA, in a normal way.

dpkg-shlibdeps: error: couldn't find library libcuda.so.1 needed by 
debian/libcuinj64-7.5/usr/lib/powerpc64le-linux-gnu/libcuinj64.so.7.5.18 (ELF 
format: 'elf64-powerpcle'; RPATH: '')

So should CUDA 7.5 be blocked by nvidia driver for ppc64el ?

NVIDIA provided ppc64el drivers in the CUDA7.5 deb ball,
but NVIDIA doesn't provide it directly on its driver web page.
Besides, the driver version from CUDA7.5 ball is detached with
others...

  nvidia-driver/unstable 352.79-2 amd64

but nvidia-driver for ppc64el in the CUDA ball is 352.39.

How should we continue ?
Or is there a way telling {dh_,dpkg-}shlibdeps to ignore libcuda.so.1 ?

Thanks in advance.


all_in_one.v7.patch.gz
Description: application/gzip

Bug#812342: Applied patch are failing to build

[Thomas Goirand]

Hi,

I tried to apply upstream patches to version 3.6.0, and then the package
couldn't build. Do you have any clue how to fix?

Cheers,

Thomas Goirand (zigo)

Bug#781416: manpage should document --jobserver-fds and the jobserver pipe

[Manoj Srivastava]

On Sat, Mar 28 2015, Josh Triplett wrote:

> Package: make
> Version: 4.0-8.1
> Severity: wishlist

> The --jobserver-fds option, and the jobserver pipe used to handle -j
> correctly in recursive make invocations, ought to have documentation in
> the manpage.

This is not a user facing public interface, so I am not sure it
 belongs in the manual. Did you have a use for this information?

manoj
-- 
Drawing on my fine command of language, I said nothing.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover

[Marko Dimjašević]

On Sat, 2016-02-13 at 17:41 -0700, Marko Dimjašević wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "stp"

Just to clarify this...

With the sponsorship of the ITP's [1] owner I uploaded a first version
of STP back in October last year [2]. The package got rejected a few
days ago, and I fixed issues with it in this submission. I would ask the
owner to sponsor this submission too, but I haven't heard from him since
last year and there was no reply to my emails in the meantime. 

Let me know if someone could directly sponsor the submission or if a
different approach is needed.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789055
[2]
https://web.archive.org/web/20151027054349/https://ftp-master.debian.org/new/stp_2.1.1+dfsg-1.html


-- 
Regards,
Marko
https://dimjasevic.net/marko



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

Bug#777270: make: please make make multiarch:foreign (properly this time)

[Manoj Srivastava]

On Sat, Feb 07 2015, Johannes Schauer wrote:

> Package: make
> Version: 4.0-8.1
> Severity: wishlist
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability

> The question is, how to supply the host architecture to make at run
> time.

> One way would be to add a dependency on dpkg-dev to the make binary
> package and let the make executable call `dpkg-architecture
> -qDEB_HOST_MULTIARCH` at run time.

This would be fine.

> Depending on what you find a reasonable solution I can supply a patch.

That would be much appreciated.

manoj
-- 
Please help keep the world clean: others may wish to use it.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#531695: Also hasn't worked for me for a long while

[Russell Stuart]

I'm using lightdm.  The keyring is used by evolution.  The keyring
password is the same as my login password in /etc/shadow.  I haven't
touched the stuff in /etc/pam.d, and AFAICT it looks fine (ie,
pam_gnome_keyring.so is mentioned everywhere it should be).

I was never able to get to get the keyring to unlock automatically in
Jessie.

A week ago I got a new laptop and did a fresh stretch install and was
hoping the problem would disappear.  The situation is unchanged - when
evolution starts, gcr prompts for keyring password and I have to re-
enter it.

If it would help, I can try to verify I can reproduce this in a kvm
container from a fresh sid install.

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

Bug#813562: Project maintainer here

[Sean Whitton]

Hello,

On Sat, Feb 13, 2016 at 01:35:10AM +, James R Barlow wrote:
> Oh, interesting. By smaller I take it mean the file size was reduced, not
> resampling of images. Any chance you can send me an example input PDF? 
> (Dropbox
> is best.)
> 
> I did increase the JPEG quality that Ghostscript uses when transcoding JPEGs,
> mostly as an added safety margin, but I can make that optional. Maybe that
> affects file size more than I thought.

Turns out the new version doesn't increase the file size \o/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814683: plasma-nm seems to have no support for network-manager-iodine plugin

[Michael Meier]

Package: plasma-nm
Version: 4:5.4.3-1
Severity: normal

I installed the network-manager-iodine plugin, but the plasma-nm does not seem 
to have any support for it.
When I try to add a connection it actually shows me a lot of connection types 
of which the plugin is not even installed, but there seems to be no way to add 
an iodine connection.


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

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

Versions of packages plasma-nm depends on:
ii  libc6   2.21-7
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5dbusaddons5   5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5itemviews55.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5modemmanagerqt6   5.16.0-1
ii  libkf5networkmanagerqt6 5.16.0-1
ii  libkf5notifications55.16.0-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5solid55.16.0-1
ii  libkf5wallet-bin5.16.0-1
ii  libkf5wallet5   5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  libopenconnect5 7.06-2+b2
ii  libqt5core5a5.5.1+dfsg-13
ii  libqt5dbus5 5.5.1+dfsg-13
ii  libqt5gui5  5.5.1+dfsg-13
ii  libqt5network5  5.5.1+dfsg-13
ii  libqt5qml5  5.5.1-3
ii  libqt5widgets5  5.5.1+dfsg-13
ii  libqt5xml5  5.5.1+dfsg-13
ii  libstdc++6  5.3.1-8
ii  mobile-broadband-provider-info  20140317-1
ii  network-manager 1.0.10-2+b1
ii  plasma-framework5.16.0-1
ii  qml-module-org-kde-kcoreaddons  5.16.0-1

plasma-nm recommends no packages.

Versions of packages plasma-nm suggests:
pn  network-manager-openconnect  
ii  network-manager-openvpn  1.0.8-1
ii  network-manager-pptp 1.0.8-2
ii  network-manager-vpnc 1.0.8-1

-- no debconf information

Bug#813256: [fc3bef6] Fix for Bug#813256 committed to git

[Manoj Srivastava]

tags 813256 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 master at Sat, 13 Feb 2016 20:09:18 -0800.

 The fix will be in the next upload. 
=
Really fix C++ comments in C parsers bug.

So, when we applied the upstream patch, it only fixed the skeleton
file, flex.skl, and not the generated files skel.c and scan.c;. Added
a feature branch that fixes the generated files, the need for this
will go away with the next upstream release. I hope. For what it is
worth, the diff in upstream seems to be the same one that was in the
NMU; and I have no explanations for why the -6 would behave diferently
from the NMU. (Closes: #813256).

Signed-off-by: Manoj Srivastava 
=

Bug#813256: [31b78ae] Fix for Bug#813256 committed to git

[Manoj Srivastava]

tags 813256 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 master at Sat, 13 Feb 2016 19:50:08 -0800.

 The fix will be in the next upload. 
=
Really fix C++ comments in C parsers bug.

So, when we applied the upstream patch, it only fixed the skeleton
file, flex.skl, and not the generated files skel.c and scan.c;. Added
a feature branch that fixes the generated files, the need for this
will go away with the next upstream release. I hope. For what it is
worth, the diff in upstream seems to be the same one that was in the
NMU; and I have no explanations for why the -6 would behave diferently
from the NMU. (Closes: #813256).

Signed-off-by: Manoj Srivastava 
=

Bug#755137: Substantive typo in 'flex' manual C99 String Literal

[Manoj Srivastava]

severity 755137 minor
thanks

On Thu, Jul 17 2014, Paul Rolig wrote:

> Package: flex
> Version: 2.5.37


>
> In the example regular expression for C99 String Literal, about 1/3 of the
> way from the left is the set '[0123456]'. Presumably, this is intended to
> match escaped octal numeric literals, in which case the digit '7' should
> also be included in the set.

It is not meant to be the octal numerals. There is a different
 regular expression a little before that which is the proper one to use.

> this same example C99 String Literal example regular expression
> suffers the same omission as above,

This is not a bug.

> and also is truncated on the right
> where it extends beyond the edge of the page. (125 is the page number
> printed at the top of the page, but it is the 132nd page in the PDF
> file.)

The overflows are a bug, indeed, but the info manual is fine. I
 am lowering the severity of this report, but I’ll work the issue.

manoj
-- 
Live long and prosper. Spock, "Amok Time", stardate 3372.7
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#715505: Updated OpenChrome driver available

[Jeffrey Walton]

Also see "Updated OpenChrome driver available",
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814682. It does not
appear to be available in Debian Unstable yet.

Fir the VIA and Unknown Card-Ids (3371|1019|2125), Chipset:
P4M900/VN896/CN896, and Xserver crash, also see
http://bugs.freedesktop.org/show_bug.cgi?id=94130.

Bug#809440: lintian: runtime-test-file-is-not-a-regular-file complains about a symlink to a regular test file

[Christian Seiler]

Control: tags -1 + patch

On Wed, 30 Dec 2015 19:14:15 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
 wrote:
> With python-django 1.9-2 I get those tags:
> I: python-django source: runtime-test-file-is-not-a-regular-file 
> debian/tests/django-admin-py3
> I: python-django source: runtime-test-file-is-not-a-regular-file 
> debian/tests/test-suite-py3
> 
> Both files are symlinks to another script (which is a regular file) in the
> same directory. autopkgtest works perfectly well with such test files...
> thus you should not trigger the tag in this case.
> 
> I'm using a symlink as a way to share a script to be run under two
> different environments. In my case once with Python 2 and once with Python
> 3 (as the -py3 suffix suggests).

I would like to add that I have the same problem with open-iscsi,
where I want to test the package with different init systems, so
I have the regular test (for systemd) and then a symlink with
sysvinit-$name that reboots the test environment after installing
sysvinit before executing the test.

I've attached a patch that allows for relative symlinks. I've
verified that lintian builds successfully (with the full test
suite run, including the new tags) in a clean sid chroot.

Regards,
Christian
From e456103f2dc87fe746b2019fca229e4dd5dbb9d8 Mon Sep 17 00:00:00 2001
From: Christian Seiler 
Date: Sun, 14 Feb 2016 03:36:43 +0100
Subject: [PATCH] Allow relative symlinks for autopkgtest tests

Relative symbolic links to autopkgtest tests should be allowed as long
as they point to regular files. This adds the following tags for
identifying problematic types of symlinks:

 - runtime-test-file-is-absolute-symlink
 - runtime-test-file-is-self-recursive-symlink
 - runtime-test-file-is-broken-symlink
 - runtime-test-file-is-symlink-to-non-regular-file

Closes: #809440
---
 checks/testsuite.desc  | 31 +++-
 checks/testsuite.pm| 33 ++
 .../testsuite-general/debian/debian/tests/control  |  3 ++
 t/tests/testsuite-general/desc |  4 +++
 t/tests/testsuite-general/pre_build| 11 +++-
 t/tests/testsuite-general/tags |  6 
 6 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/checks/testsuite.desc b/checks/testsuite.desc
index 1fad72d..8582205 100644
--- a/checks/testsuite.desc
+++ b/checks/testsuite.desc
@@ -68,7 +68,36 @@ Tag: runtime-test-file-is-not-a-regular-file
 Severity: wishlist
 Certainty: certain
 Info: A runtime test listed by debian/tests/control is not a regular
- file.
+ file or a relative symbolic link to a regular file in the source
+ package.
+Ref: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
+
+Tag: runtime-test-file-is-absolute-symlink
+Severity: wishlist
+Certainty: certain
+Info: A runtime test listed by debian/tests/control is a symbolic
+ link that points to an absolute path.
+Ref: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
+
+Tag: runtime-test-file-is-self-recursive-symlink
+Severity: wishlist
+Certainty: certain
+Info: A runtime test listed by debian/tests/control is a symbolic
+ link that recurses onto itself.
+Ref: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
+
+Tag: runtime-test-file-is-broken-symlink
+Severity: wishlist
+Certainty: certain
+Info: A runtime test listed by debian/tests/control is a broken
+ symbolic link.
+Ref: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
+
+Tag: runtime-test-file-is-symlink-to-non-regular-file
+Severity: wishlist
+Certainty: certain
+Info: A runtime test listed by debian/tests/control is a symbolic
+ link that points to something other than a regular file.
 Ref: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
 
 Tag: syntax-error-in-debian-tests-control
diff --git a/checks/testsuite.pm b/checks/testsuite.pm
index a9de939..feaeaad 100644
--- a/checks/testsuite.pm
+++ b/checks/testsuite.pm
@@ -184,6 +184,39 @@ sub check_test_file {
 if (not defined($index)) {
 tag 'missing-runtime-test-file', $path,
   'paragraph starting at line', $line;
+} elsif ($index->is_symlink) {
+if ($index->link =~ m{^/}) {
+tag 'runtime-test-file-is-absolute-symlink', $path;
+} else {
+my $target = $index->link_normalized;
+if ($target eq $path) {
+tag 'runtime-test-file-is-self-recursive-symlink', $path;
+return;
+}
+my $target_index = $info->index($target);
+my %targets = ($target => 1);
+while (defined($target_index) and $target_index->is_symlink) {
+if ($target_index->link =~ m{^/}

Bug#814682: Updated OpenChrome driver available

[Jeffrey Walton]

Package: xserver-xorg-video-openchrome
Version: 1:0.3.3-2

The current The OpenChrome provided in Debian causes an Xserver crash
on VIA P4M900 chipset. Though its a less popular chipset, its still
used in production for lower end systems, like Netbooks and POS
systems.

The OpenChrome driver is provided in xserver-xorg-video-openchrome. An
updated version of the OpenChrome driver is available from the
freedesktop.org folks, but it is not available in Unstable. The driver
is installed at /usr/lib/xorg/modules/drivers/openchrome_drv.so.

For the freedesktop.org announcement and instruction for obtaining the
updated driver, see "Getting ready to release OpenChrome Version
0.3.4", 
https://lists.freedesktop.org/archives/openchrome-users/2016-February/007234.html.

Related freedesktop.org and downstream bugs due to the driver:

* "Unknown Card-Ids (3371|1019|2125), Chipset: P4M900/VN896/CN896 [and
Xserver crash]", http://bugs.freedesktop.org/show_bug.cgi?id=94130
* "Light Display Manager fails to load [due to Xserver crash]",
http://bugs.launchpad.net/lightdm/+bug/1540774

Also see the following on the debian-x mailing list:

* "Freedesktop and OpenChrome Version 0.3.4",
http://lists.debian.org/debian-x/2016/02/msg00114.html



debian-unstable:/# apt-cache show xserver-xorg-video-openchrome
Package: xserver-xorg-video-openchrome
Version: 1:0.3.3-2
Installed-Size: 546
Maintainer: Debian X Strike Force 
Architecture: amd64
Provides: xorg-driver-video
Depends: libc6 (>= 2.14), libdrm2 (>= 2.3.1), libx11-6 (>=
2:1.4.99.1), libxext6, libxv1, libxvmc1, xorg-video-abi-20,
xserver-xorg-core (>= 2:1.17.99.902)
Description-en: X.Org X server -- VIA display driver
 OpenChrome is a project for the development of free and open-source drivers
 for the VIA UniChrome video chipsets.
 .
 Originally called the 'snapshot' release, since it was a snapshot of an
 experimental branch of the unichrome cvs code, this is a continued development
 of the open source unichrome driver (from http://unichrome.sf.net) which
 also incorporates support for the unichrome-pro chipsets.
 .
 Support for hardware acceleration (XvMC) for all chipsets has subsequently
 been ripped out of the unichrome.sf.net driver. Therefore your only option if
 you wish to make use of the acceleration features of your VIA chip with free
 and open-source drivers is to use this version of the driver.
Description-md5: 11d4a7275218ad33ccc6479463963d83
Homepage: https://www.freedesktop.org/wiki/Openchrome/
Tag: hardware::video, implemented-in::c, role::plugin, use::driver
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-video-openchrome/xserver-xorg-video-openchrome_0.3.3-2_amd64.deb
Size: 199654
MD5sum: ff4710469045b8e878164c3f204557fe
SHA1: d142e843e64059da6581c1c0615eba5046c31cb8
SHA256: 96a60c621021a2f3924e371c7be395eb274bb9725362cd5539fe74b61d3be0cf

Bug#814313: xorg-server: Using systemd and startx, input does not work anymore

[Kei Hibino]

Package: src:xorg-server
Followup-For: Bug #814313

Dear Maintainer,

I was affected with this bug, the same version 2:1.18.1-1.
Input did not work anymore too.

To recover this, I installed downgraded binary packages of xserver (provided in 
jessie, 2:1.16.4-1) which works fine.

I'm not using systemd-sysv, but using sysvinit-core.
I'm not using X login manager, but using startx with xserver-xorg-legacy (when 
using sid xserver binary).

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

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

Bug#796952: english language release notes pdf file is not english (https://www.debian.org/releases/stable/amd64/release-notes.en.pdf)

[Norbert Preining]

Hi Adam,

> I have to admit that I'm not really keen on approving an update which
> consists of "add this tar to the source package". I'm also still not

Understandable.

> sure why the suggestion is to add the changes via such a binary update
> rather than a patch - I appreciate that the changes might be large, but
> that doesn't preclude being able to produce an actual diff.

I can do a patch, that is the easiest part of course, but it will
be huge.

> (Codebases where patches can't be backported also really don't thrill me
> with an SRM hat on, but that's another matter.)

They can, if someone could identify the single patch and try to get
it working in the old code base - which has been severly rewritten
in hthe meantime.

I can try for that, but I have *no* idea when how and if it works out.

All the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#796952: english language release notes pdf file is not english (https://www.debian.org/releases/stable/amd64/release-notes.en.pdf)

[Norbert Preining]

> So, could this bug now be planned to be fixed in 8.4?

I forgot to add - even if we do *NOT* want to fix dvipdfmx, there is
an easy way around, do not use type1 but otf/ttf fonts.

I have advised this to the Russian reporter and done it myself
for all release notes. It is damned easy to choose a different font.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#814681: QNAP TS-219P II: Network transmit data corruption caused by mv643xx_eth TCP segmentation offload

[Robert Schlabbach]

Package: linux-image-4.3.0-0.bpo.1-kirkwood
Version: 4.3.3-7~bpo8+1

This one seems to be a repeat offender (see #764162):

When running a samba server under Debian with the "sendfile = yes" option,
I observe corruption during file transfers from the Debian server to a
Windows 7 PC. Inspection of the corruption reveals that every now and then,
a sequence of 4 bytes is replaced with the destination MAC address.

Sample (Offset: Original Mismatch; M1 through M4 are the first four bytes
of the MAC address of my Windows 7 PC):

0C402D48: 2F M1
0C402D49: C2 M2
0C402D4A: 18 M3
0C402D4B: 3C M4
107ABBDC: 9D M1
107ABBDD: A6 M2
107ABBDE: 97 M3
107ABBDF: 5B M4
1102D860: 7B M1
1102D861: DF M2
1102D862: 5A M3
1102D863: CE M4
17682D48: DA M1
17682D49: 9A M2
17682D4A: 44 M3
17682D4B: 7C M4
1B8AE3C8: 33 M1
1B8AE3C9: FF M2
1B8AE3CA: D2 M3
1B8AE3CB: 17 M4
1CAAD860: 18 M1
1CAAD861: 20 M2
1CAAD862: C7 M3
1CAAD863: 23 M4
1F76CCF8: 76 M1
1F76CCF9: 9E M2
1F76CCFA: 44 M3
1F76CCFB: 79 M4
20EEE3C8: AB M1
20EEE3C9: 40 M2
20EEE3CA: A4 M3
20EEE3CB: A2 M4

The offsets change each time the file is transferred, but the incorrect
values remain the same, it's always the first 4 bytes of my Windows 7 PC
MAC address.

The command suggested in #764162:

sudo ethtool -K eth0 tso off

*fixes* the problem, and the command:

sudo ethtool -K eth0 tso on

makes it reappear most of the time, but sometimes not...?!?

Driver information:

~$ sudo ethtool -i eth0
driver: mv643xx_eth
version: 1.4
firmware-version: N/A
bus-info: platform
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Initial offload settings (with the problem observed):

Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
scatter-gather: on
tx-scatter-gather: on
tcp-segmentation-offload: on
tx-tcp-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
tx-nocache-copy: off


Best Regards,
Robert Schlabbach

Bug#813094: Split braille support into a separate package

[Samuel Thibault]

Didier 'OdyX' Raboud, on Sun 14 Feb 2016 00:06:43 +0100, wrote:
> Le lundi, 1 février 2016, 12.00:53 Yuri D'Elia a écrit :
> > On 01/02/16 11:58, Samuel Thibault wrote:
> > >> The double recommend/suggests is a bit wonky.
> > >> Maybe you should recommend on (liblouis-bin | liblouisutdml-bin).
> > >> 
> > >> I don't know what's the difference in braille support between
> > >> liblouis-bin and liblouisutdml-bin, but if the package is
> > >> recommended I would go for the better one only.
> > > 
> > > The better one is liblouisutdml-bin, which provides better document
> > > parsing than the basic liblouis-bin.
> > > 
> > > The issue is that ubuntu does not have liblouisutdml-bin in main,
> > > only in universe.
> > 
> > Ah, I see now.
> > Then I would simply recommend on (liblouisutdml-bin | liblouis-bin).
> 
> Till, Samuel; does this look like a good-enough compromise ?

With Debian's current habit of installing Recommends, it looks good
enough to me.

Samuel

Bug#813562: Project maintainer here

[James R Barlow]

I'd suggest putting ocrmypdf in a submodule with the Debian things outside.
Then setup tools should pick up tags correctly rather than generating
whatever "git describe" decides to call the current revision in your merged
repo.
On Sat, Feb 13, 2016 at 16:46 Sean Whitton  wrote:

> Hello,
>
> Thank you for your e-mail.
>
> On Sat, Feb 13, 2016 at 01:35:10AM +, James R Barlow wrote:
> > On Fri, 12 Feb 2016 at 17:05 Sean Whitton 
> wrote:
> > I have a non-packaging question that I'd like to take this
> opportunity
> > to ask you: in your changelog entry for 3.2, it's explained that the
> new
> > "lossless reconstruction" feature is disabled by --deskew and
> > --clean-final but otherwise PDF contents are now added to but not
> > modified by OCRmyPDF.  I had observed that OCRmyPDF makes my PDFs
> much
> > smaller without making them any harder to read, presumably by
> changing
> > the content, and I rather liked this feature.  Can I turn it back on?
> > Or was --clean-final doing this and turning that on would be enough?
> > Oh, interesting. By smaller I take it mean the file size was reduced, not
> > resampling of images. Any chance you can send me an example input PDF?
> (Dropbox
> > is best.)
>
> Sure, I'll do that once I can make my 3.2 package build.
>
> > If you build the package around a wheel or tarball obtained from PyPI,
> > setuptools_scm should be able to get the version out. It will fail to
> determine
> > the version from a Github tarball.
>
> I'm trying to build out of git: I have a branch with the Debian control
> files and I merged your 3.2 tag into that.  Do you know how I can make
> setuptools_scm successfully determine the version from that?  How do you
> do your builds during development?
>
> --
> Sean Whitton
>

Bug#814096: neovim: errors reading/writing shada file

[James McCoy]

On Wed, Feb 10, 2016 at 07:27:16PM -0500, James McCoy wrote:
> On Mon, Feb 08, 2016 at 09:37:31AM -0500, D. Stuart Freeman wrote:
> > On first run neovim works as expected, but on subsequent runs starts with
> > error:
> > 
> >  E576: Failed to parse ShaDa file: incomplete msgpack string at 
> > position 81
> > 
> > and exits with error:
> > 
> >  E576: Failed to parse ShaDa file: incomplete msgpack string at 
> > position 81
> >  E136: Did not rename 
> > /home/stuart/.local/share/nvim/shada/main.shada.tmp.a because 
> > /home/stuart/.local/share/nvim/shada/main.shada does not looks like a ShaDa 
> > file
> >  E136: Do not forget to remove 
> > /home/stuart/.local/share/nvim/shada/main.shada.tmp.a or rename it manually 
> > to /home/stuart/.local/share/nvim/shada/main.shada.
> 
> Indeed, this is a known problem when building Neovim against a 1.x
> msgpack-c but running it against a pre-1.x version.  I'll be talking to
> msgpack-c's upstream about this.

FWIW, https://github.com/msgpack/msgpack-c/issues/419 is the discussion.
Depending on the outcome of that, I'll either add an explicit minimum
version to the dependency in Neovim or it will happen automatically
based on changes to msgpack's packaging.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#814616: Galculator — Negative Numbers Divide by Any Number equals an addition

[Mattia Rizzolo]

control: reassign -1 galculator 2.1.4-1

On Sat, Feb 13, 2016 at 02:41:00PM +0100, zer0 divide wrote:
> Package: gcalculator

you lost an 'a' there :)  Reassigning the bug…

> Version: 2.1.4-1
> Severity: important
> 
> Hi, there is a big problem with galculator 2.1.4-1.
> 
> Negative Numbers Divide by Any Number equals "an addition".
> 
> For exemple :
> 
>  * -2/595 = -597
>  * -2/2 = -4
>  * -2/-2 = -4
>  * -2/0 = -2
> 
> 

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#813562: Project maintainer here

[Sean Whitton]

Hello,

Thank you for your e-mail.

On Sat, Feb 13, 2016 at 01:35:10AM +, James R Barlow wrote:
> On Fri, 12 Feb 2016 at 17:05 Sean Whitton  wrote:
> I have a non-packaging question that I'd like to take this opportunity
> to ask you: in your changelog entry for 3.2, it's explained that the new
> "lossless reconstruction" feature is disabled by --deskew and
> --clean-final but otherwise PDF contents are now added to but not
> modified by OCRmyPDF.  I had observed that OCRmyPDF makes my PDFs much
> smaller without making them any harder to read, presumably by changing
> the content, and I rather liked this feature.  Can I turn it back on?
> Or was --clean-final doing this and turning that on would be enough?
> Oh, interesting. By smaller I take it mean the file size was reduced, not
> resampling of images. Any chance you can send me an example input PDF? 
> (Dropbox
> is best.)

Sure, I'll do that once I can make my 3.2 package build.

> If you build the package around a wheel or tarball obtained from PyPI,
> setuptools_scm should be able to get the version out. It will fail to 
> determine
> the version from a Github tarball.

I'm trying to build out of git: I have a branch with the Debian control
files and I merged your 3.2 tag into that.  Do you know how I can make
setuptools_scm successfully determine the version from that?  How do you
do your builds during development?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover

[Marko Dimjašević]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: stp
  Version : 2.1.2+dfsg-1
  Upstream Author : STP developers
* URL : https://stp.github.io/
* License : Expat and others
  Section : science

It builds those binary packages:

  python-stp - Simple theorem prover library bindgings for Python
  stp - Simple theorem prover

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

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


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

  dget -x http://mentors.debian.net/debian/pool/main/s/stp/stp_2.1.2
+dfsg-1.dsc

More information about STP can be obtained from https://stp.github.io/.

Changes since the last upload:

  - new upstream release
  - added copyright for the OutputCheck archive per Thorsten Alteholz's
instructions (ftp-master)


-- 
Kind regards,
Marko Dimjašević
https://dimjasevic.net/marko




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

Bug#814679: velocity: Package rebuilt from source is missing most of its dependencies

[Daniel Schepler]

Source: velocity
Version: 1.7-4
Severity: serious

When I rebuild velocity using pbuilder, the build succeeds; however, the 
result only has a couple dependencies as compared to the set in the official 
package:

# dpkg-deb -I /var/cache/pbuilder/result/velocity_1.7-4_all.deb 
 new debian package, version 2.0.
 size 413580 bytes: control archive=1076 bytes.
  34 bytes, 1 lines  conffiles
1058 bytes,23 lines  control  
 563 bytes, 7 lines  md5sums  
 Package: velocity
 Version: 1.7-4
 Architecture: all
 Maintainer: Debian Java Maintainers 
 Installed-Size: 494
 Depends: libcommons-collections3-java, libcommons-lang-java (>= 2.6)
 Recommends: liboro-java
 Suggests: velocity-doc
 Section: java
 Priority: optional
 Homepage: http://velocity.apache.org/
 Description: Java-based template engine for web application
  Velocity is a Java-based template engine. It permits anyone to use
  the simple yet powerful template language to reference objects
  defined in Java code.
  When Velocity is used for web development, Web designers can work in
  parallel with Java programmers to develop web sites according to the
  Model-View-Controller (MVC) model, meaning that web page designers
  can focus solely on creating a site that looks good, and programmers
  can focus solely on writing top-notch code. Velocity separates Java
  code from the web pages, making the web site more maintainable over
  the long run and providing a viable alternative to Java Server Pages
  (JSPs) or PHP.

(The way I discovered this is in my archive rebuild scripts that dogfood the 
results to build other packages.  Without the dependency of velocity on ant, 
maven-debian-helper no longer indirectly pulls in ant, and I've started seeing 
a few packages that FTBFS because of that.)
-- 
Daniel Schepler

Bug#812922: RFS: classic-theme-restorer/1.4.7-1 [ITP] -- customize the new Iceweasel look

[Sean Whitton]

Dear Adam,

Thank you for your feedback.

On Wed, Feb 10, 2016 at 04:49:24AM +0100, Adam Borowski wrote:
> On Mon, Feb 01, 2016 at 09:58:57PM -0700, Sean Whitton wrote:
> > * Package name: classic-theme-restorer
> 
> In the copyright file, you wrote:
> 
> License: MPL-2.0
>  This Source Code Form is subject to the terms of the Mozilla Public License,
>  v. 2.0. If a copy of the MPL was not distributed with this file,
>  You can obtain one at http://mozilla.org/MPL/2.0/.
> 
> but the text of the MPL is not actually provided.

The full text is now included.  I've retagged in my git repo and
reuploaded to mentors.debian.net.

> Besides, thanks for packaging this!  It's a mandatory extension, no idea
> what Mozilla guys were smoking when they made Australis but it must have
> been something nasty.

Indeed.  For me, the most important feature is the restoration of
tabs-not-on-top which for some reason Mozilla totally removed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#785338: fatal: environment variable XDG_RUNTIME_DIR is not set

[Hector Oron]

On Wed, May 13, 2015 at 12:56:25PM -0400, jsmith wrote:
> Package: weston
> Version: 1.6.0-2+b1

Weston is not responsible to setup XDG_RUNTIME_DIR.
You should be able to set it up in your environment if nothing sets it up for 
you.

Regards,
-- 
  Hector Oron


signature.asc
Description: PGP signature

Bug#785339: weston: running weston blanks screen, and makes system unresponsive when running i386 through vmware player

[Hector Oron]

On Thu, May 14, 2015 at 07:21:51PM -0400, jsmith wrote:
> Package: weston
> Version: 1.6.0-2+b1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?

Could you please provide more information? 

Regards
-- 
  Hector Oron


signature.asc
Description: PGP signature

Bug#814678: cron: No information given about syntax error in /etc/crontab

[teo8...@gmail.com]

Package: cron
Version: 3.0pl1-124
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

Have a syntax error in /etc/crontab

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
see above
   * What was the outcome of this action?
A generic useless non-informative error message is logged 
in /var/log/syslog whih reads more or less (quoting by memory):
Syntax error in /etc/crontab. This file will be ignored

   * What outcome did you expect instead?
The message should at the very least include the exact row and column
 where the syntax error is, and ideally a description of the error
(e.g. "XXX expected" or "invalid YYY")

It's absolutely ridiculous that you have to figure out for yourself where
the error is in potentially thousands of lines.


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


-- Package-specific info:
--- EDITOR:


--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 35880 Jul  3  2012 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 May  3  2013 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Jul  3  2012 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Apr 27  2015 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Dec 20  2014 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 May  3  2013 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 May  3  2013 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 May  3  2013 /etc/cron.weekly


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

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

Versions of packages cron depends on:
ii  adduser 3.113+nmu3
ii  debianutils 4.3.2
ii  dpkg1.16.15
ii  libc6   2.13-38+deb7u6
ii  libpam-runtime  1.1.3-7.1
ii  libpam0g1.1.3-7.1
ii  libselinux1 2.1.9-5
ii  lsb-base4.1+Debian8+deb7u1

Versions of packages cron recommends:
ii  exim4  4.80-7
ii  exim4-daemon-light [mail-transport-agent]  4.80-7

Versions of packages cron suggests:
ii  anacron2.3-19
pn  checksecurity  
ii  logrotate  3.8.1-4

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- Configuration Files:
/etc/crontab changed [not included]

-- no debconf information

Bug#771796: weston: Weston fails with Intel GM45

[Hector Oron]

Hello,

On Tue, Dec 02, 2014 at 09:11:02AM -0500, Anthony Carrico wrote:
> Subject: weston: Weston fails with Intel GM45
> Package: weston
> Version: 1.6.0-2+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> I decided to try Weston. It is just an experiment to see how things are
> coming along. It failed on this
> machine with graphics hardware, but I was able to run it successfully
> with the pixman renderer. I was also able to run successfully with the
> graphics hardware on another machine.
> 
> Here is my graphics card:
> 
> $ glxinfo  | grep 'renderer string'
> OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
> 
> I will paste two runs, the first fails, the second succeeds:

Could you please try latest weston package release from experimental?
Can you reproduce such issue? If so, would you be willing to bring this 
upstream at 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston

Best Regards,
-- 
  Hector Oron


signature.asc
Description: PGP signature

Bug#814677: packages.debian.org: file is found in wrong suite(s)

[Ana Guerrero Lopez]

Package: www.debian.org
Severity: important


Hi,

When I search "ibchecknet" in the "Search the content of packages" available at
https://www.debian.org/distrib/packages with the options:
- paths ending with the keyword
- Distribution: stable
- Architecture: any

I get:

---
You have searched for paths that end with ibchecknet in suite jessie, all
sections, and all architectures. Found 1 results.

FilePackages
/usr/sbin/ibchecknetinfiniband-diags
---

However, the package infiniband-diags from jessie doesn't provide this file as
can be seen at 
https://packages.debian.org/jessie/amd64/infiniband-diags/filelist

I have the same problem if I search in unstable and it works fine (this is,
the file is not found) when searching in testing, and experimental

The binary /usr/sbin/ibchecknet is only provided in the infiniband-diags package
available in oldstable.

Ana

Bug#814676: freerdp: please update to latest upstream head(?)

[Héctor Orón Martínez]

Source: freerdp
Version: 1.1.0~git20140921.1.440916e+dfsg1-5
Severity: wishlist

Hello,

  freerdp project does not seem to have done a release in the recent time, 
however lots of changes seem to have gone into their upstream GIT repository.

  I would be interested in having new upstream release, at least enabling the 
following features:

  - wlfreerdp client (Commited on Oct 13, 2014)
https://github.com/FreeRDP/FreeRDP/pull/2145
  - winpr-makecert tool
https://github.com/FreeRDP/FreeRDP/tree/master/winpr/tools/makecert

  I am planning to enable RDP compositor in Weston (Wayland reference 
compositor) and those tools will be needed.

Best regards

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

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

Bug#810799: libcgi-session-perl: Perl DSA-3441-1 exposes taint bug in CGI::Session::Driver::file

[Peter Thoeny]

Hi Niko and Teodor,

Sorry for the delay in replying, my inbox is not a good place to track bugs.

Please see related TWiki support question at:
http://twiki.org/cgi-bin/view/Support/SID-02145

Here is the TWiki bug number we use to track the taint issue:
http://develop.twiki.org/~twiki/cgi-bin/view/Bugs/Item7721#r1

Please feel free to pitch in there as well.

Regards,
Peter


On Jan 21, 2016, at 12:28 PM, Niko Tyni  wrote:

> On Tue, Jan 19, 2016 at 11:25:47AM +0200, Teodor Milkov wrote:
> 
>> I've just installed libcgi-session-perl 4.48-3, but still my twiki spew the
>> following error:
>> 
>> /Insecure dependency in sysopen while running with -T switch at
>> /usr/share/perl5/CGI/Session/Driver/file.pm line 107. /
> 
> Sorry to hear that. Which version of twiki is that?
> 
> The taint bug in CGI::Session with a test case at
> https://rt.cpan.org/Public/Bug/Display.html?id=80346
> is now fixed, so your problem seems to be a different issue.
> It may well be in twiki itself rather than CGI::Session.
> 
> In the latter case, we will need a short test case for triggering this.
> Twiki itself is not part of Debian, and for my part I'm not particularly
> interested in setting one up and debugging it.
> 
>> I had to apply the following patch to mute it:
> 
>> --- tmp/file.pm 2016-01-19 11:17:45.0 +0200
>> +++ /usr/share/perl5/CGI/Session/Driver/file.pm 2016-01-19
>> 11:11:46.0 +0200
>> @@ -52,6 +52,8 @@
>> return $self->set_error( "_file(): Session ids cannot contain \\ or
>> / chars: $sid" );
>> }
>> 
>> +($sid) = $sid =~ /(.*)/;
>> +
>> return File::Spec->catfile($self->{Directory}, sprintf( $FileName, $sid
>> ));
>> }
> 
> While I'm glad it solved your immediate problem, that looks like a
> band-aid fix for the symptoms. It doesn't fix the root cause. If $sid is
> tainted due to external reasons, it's not the place of CGI::Session to
> untaint it. OTOH, if something in CGI::Session makes it unnecessarily
> tainted (as was the case in the bug we fixed), that's something we
> can fix.
> 
> I'm copying Peter Thoeny, the TWiki author. Peter, would you be willing
> to work with us to try and find the reason for these taint problems? The
> full bug log so far can be found in https://bugs.debian.org/810799
> -- 
> Niko Tyni   nt...@debian.org

--
> Peter Thoeny - Peter09[at]Thoeny.org
> http://bit.ly/MrTWiki - consulting on enterprise collaboration
> http://TWiki.org - is your team already TWiki enabled?
> http://qualityHDR.com - Quality HDR Photography
> Knowledge cannot be managed, it can be discovered and shared
> This e-mail is:   (_) private(_) ask first(x) public

Bug#813094: Split braille support into a separate package

[Till Kamppeter]

I think this is a good idea. It makes one of the two utility packages be 
installed if at least one is available (ex: Ubuntu with only Main) and 
does not error if none is available. And it prefers the better if both 
are available (Debian and Ubuntu with Main and Universe).


Let us go this way.

   Till

Bug#814622: [Python-modules-team] Bug#814622: python3-pytest: modifies shipped files: /usr/bin/py.test-3.[45]

[Brian May]

Andreas Beckmann  writes:

> during a test with piuparts I noticed your package modifies files it
> ships in /usr. This is so wrong, I'm not even bothered to look
> up the part of policy this violates ;-P

>From python3-pytest.postinst:

case "$1" in
configure|abort-upgrade|abort-remove|abort-deconfigure)
# Just in case, recreate all scripts
for version in `py3versions -vi`; do
if [ $version ]; then
cp /usr/bin/py.test-3 /usr/bin/py.test-$version
sed -i "s,#! */usr/bin/python3,#!/usr/bin/python$version," 
"/usr/bin/py.test-$version"
fi
done
;;

This should be done at build time in debian/rules, not at install time.
-- 
Brian May 

Bug#813094: Split braille support into a separate package

[Didier 'OdyX' Raboud]

Le lundi, 1 février 2016, 12.00:53 Yuri D'Elia a écrit :
> On 01/02/16 11:58, Samuel Thibault wrote:
> >> The double recommend/suggests is a bit wonky.
> >> Maybe you should recommend on (liblouis-bin | liblouisutdml-bin).
> >> 
> >> I don't know what's the difference in braille support between
> >> liblouis-bin and liblouisutdml-bin, but if the package is
> >> recommended I would go for the better one only.
> > 
> > The better one is liblouisutdml-bin, which provides better document
> > parsing than the basic liblouis-bin.
> > 
> > The issue is that ubuntu does not have liblouisutdml-bin in main,
> > only in universe.
> 
> Ah, I see now.
> Then I would simply recommend on (liblouisutdml-bin | liblouis-bin).

Till, Samuel; does this look like a good-enough compromise ?

--- a/debian/control
+++ b/debian/control
@@ -76,12 +76,11 @@ Depends: ${shlibs:Depends},
  bc,
  ghostscript (>= 9.02~),
  liblouis-data,
- liblouis-bin,
  imagemagick (>= 6.4~),
  poppler-utils
-Recommends: colord
+Recommends: colord,
+ liblouisutdml-bin | liblouis-bin,
 Suggests: foomatic-db-compressed-ppds | foomatic-db,
- liblouisutdml-bin,
  antiword,
  docx2txt
 Conflicts: ghostscript-cups,


-- 
Cheers,
OdyX

Bug#814394: xserver-xorg-legacy: Fails to start xserver after upgrade to 1.18.1

[Scott Mcdermott]

Julien Cristau on 2016/02/13 +0100 @11:30:30:
> > startx does not longer work after upgrade; `grep EE
> > Xorg.log' shows:
> > 
> >[  1463.840] (EE) systemd-logind: failed to get
> >session: The name org.freedesktop.login1 was not
> >provided by any .service files
> 
> X requires logind ...

It's not supposed to, when using the X wrapper and
needs_root_rights=yes.  There used to be an upstream patch that
even allowed X to start without this, and skip the ioperm check
(it's not actually needed with KMS), which Debian dropped,
because I guess they want to require everyone to use systemd.

However, even with needs_root_rights, startup broke for me
recently as well, I had to install systemd-logind temporarily
until I can switch to a distro which doesn't force me to run
systemd stuff.

Even with systemd-logind installed, you still have to invoke it
on the same tty you run X on, even with needs_root_rights=yes, it
won't change the perms for you.  This, too, worked fine for me up
until a month or so ago.

I think the solution is to just use a distro which does not
require systemd, such as Gentoo.  Debian's X maintainers do not
appear to be interested in making X work without systemd, as it
has for the last 30 years or so...

Bug#814675: Russian language pack missing in Iceweasel after installation Debian from LiveCD

[Strelok]

Package: debian-live
Version: 8.3.0

I'm not sure if this is bug in LiveCD or Iceweasel, but...
1) I'm run Debian installation from
debian-live-8.3.0-amd64-mate-desktop.iso image.
2) I choice Russian language.
3) In result I'm have Debian with Russian interface... But Iceweasel
interface is still English. Because it's don't have Russian (RU)
Language Pack (or any other language pack).

If I'm setup Debian from netinst image, Language Pack is present and
Iceweasel interface become to Russian. Because of this, I'm think this
is bug in LiveCD, not in Iceweasel. And yes, I can simply setup
Russian language pack manually. But it's still bug.

Bug#814672: libgupnp-1.0-dev: arch-dependent file in "Multi-Arch: same" package

[Andreas Henriksson]

Control: tags -1 + moreinfo

Hello Jakub Wilk.

Thanks for your bug report.

On Sat, Feb 13, 2016 at 10:07:26PM +0100, Jakub Wilk wrote:
> Package: libgupnp-1.0-dev
> Version: 0.20.16-1
> User: multiarch-de...@lists.alioth.debian.org
> Usertags: multiarch
> 
> libgupnp-1.0-dev is marked as "Multi-Arch: same", but contents of the
> following file vary with architecture:

It's not obvious to me which part that you consider vary with architecture.
Could you please point it out?


> 
> /usr/share/man/man1/gupnp-binding-tool.1.gz
> 
> An example diff between i386 and mips (after ungzipping) is attached.
> 
> -- 
> Jakub Wilk

> diff -ur 
> libgupnp-1.0-dev_0.20.16-1_i386/usr/share/man/man1/gupnp-binding-tool.1 
> libgupnp-1.0-dev_0.20.16-1_mips/usr/share/man/man1/gupnp-binding-tool.1
> --- libgupnp-1.0-dev_0.20.16-1_i386/usr/share/man/man1/gupnp-binding-tool.1   
> 2016-02-12 20:59:33.0 +0100
> +++ libgupnp-1.0-dev_0.20.16-1_mips/usr/share/man/man1/gupnp-binding-tool.1   
> 2016-02-13 04:13:16.0 +0100
> @@ -2,12 +2,12 @@
>  .\" Title: gupnp-binding-tool
>  .\"Author: [FIXME: author] [see http://docbook.sf.net/el/author]
>  .\" Generator: DocBook XSL Stylesheets v1.79.1 
> -.\"  Date: 02/12/2016
> +.\"  Date: 02/13/2016
>  .\"Manual: Reference
>  .\"Source: GUPnP 0.20.16
>  .\"  Language: English
>  .\"
> -.TH "GUPNP\-BINDING\-TOOL" "1" "02/12/2016" "GUPnP 0\&.20\&.16" "Reference"
> +.TH "GUPNP\-BINDING\-TOOL" "1" "02/13/2016" "GUPnP 0\&.20\&.16" "Reference"
>  .\" -
>  .\" * Define some portability stuff
>  .\" -

Bug#814674: Please, provide map files

[David Prévot]

Package: libjs-es6-shim
Version: 0.34.1+ds-1

Hi,

Thanks for packaging libjs-es6-shim, I missed it when I packaged
owncloud-news. As upstream provides map files, would you please also do
so in the package, so I can get rid of the embedded code copy? It’s easy
to do it with uglifyjs (you’ll need to build-depend on node-source-map):

https://sources.debian.net/src/owncloud-news/7.1.1%2Bdfsg-1/debian/rules/#L30

Thanks in advance.

Regards

David


signature.asc
Description: PGP signature

Bug#814673: fim can't use aa output even though it says it can

[Antoine Beaupré]

Package: fim
Version: 0.5~rc1-1
Severity: normal

i get this trying to use aalib to render images:

$ fim -o aa -R . --sort
Unrecognized display device string "aa" (valid choices are 
[fb|sdl|aa|dumb|imlib2])!
Using the default "dumb" display device instead.

"valid choices are ... aa"??

is aalib support compiled out?

I see the README.Debian says I can compile some of those extensions
(e.g. SDL (X)) those in - but why should I need to do that? Why aren't
they compiled in by default?

I understand why SDL (X) would not, but aalib has its specific
uses. For example I'd love to have an image viewer through SSH
terminals...

Obviously, it works on the framebuffer, which is pretty freaking
awesome already, so thanks for that. :)

A.

PS: i'm thinking of uploading a backport for jessie once this hits
stretch, objections? would you like to do it yourself?

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

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

Versions of packages fim depends on:
ii  libc62.19-18+deb8u2
ii  libdjvulibre21   3.5.25.4-4+b1
ii  libexif120.6.21-2
ii  libgcc1  1:4.9.2-10
ii  libgif4  4.1.6-11+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  libncurses5  5.9+20140913-1+b1
ii  libpng12-0   1.2.50-2+deb8u2
ii  libreadline6 6.3-8+b3
ii  libsdl1.2debian  1.2.15-10+b1
ii  libstdc++6   4.9.2-10
ii  libtiff5 4.0.3-12.3+deb8u1
ii  libtinfo55.9+20140913-1+b1

fim recommends no packages.

fim suggests no packages.

-- no debconf information

Bug#754392: weston: segfault on exit when cms-colord.so is loaded

[Hector Oron]

On Tue, Sep 16, 2014 at 01:10:08PM +0200, Laurent Bigonville wrote:
> Package: weston
> Version: 1.5.93-1.1
> Followup-For: Bug #754392

> Still crashing for me with 1.5.93-1.1

Upstream has a commit for this one:
  2611ebd316056cdd85d75e848813d438cffbf507

which should be available since 1.8.91 release.

Do you still experience this issue with 1.9.0 in Debian?

Regards,
-- 
  Hector Oron


signature.asc
Description: PGP signature

Bug#812513: please add E1M8b.wad to the doom-wad_*.deb package

[Alexandre Detiste]

control: tag -1 pending

Le samedi 13 février 2016, 21:09:35 Fabian Greffrath a écrit :
> Am Samstag, den 13.02.2016, 14:11 +0100 schrieb Alexandre Detiste:
> > The package-size / number of files is not really an issue with GDP-
> > generated
> > packages. Even package with one 30kb text adventure games are ok;
> > they don't put any weight on mirrors infrastructure etc...
> 
> Agreed. Do you mean the WAD could get created separately if you create
> the doom-wad package?

Yup, that's what I just commited.

This way the purpose of doom-wad remains unchanged from what
users have expected for 10 years & doom-e1m8b-wad
gets proper short & long descriptions and copyright file.


"E1M8B" is defenitively more publicized
that level name "Tech Gone Bad", so I sticked with that.
(example: http://doomwadstation.net/Romero/e1m8b/ )


A brand new doom-e1m8b-wad should work with a very old doom-wad just fine;
but currently GDP will always generate boths, unless "-p" argument is used.


Maybe some "--new" argument could be added; but then last major
update version (like "updated: 43") would need to be documented in each .yaml 
file.

"git --log" parsing at build time won't cut it, because there's always a lot of 
refactoring
all the time while the generated packages doesn't change (& are checked with 
diffoscope).



For proper Freedoom support, some runtime code would be needed
to first check for the presence of doom.wad & then failover to freedoomu.wad
when applicable.

It's the same problem as for Compet-N level "The Classic Episode"

main_wads:
  ...
  class_ep.wad:
 name: The Classic Episode (1st Ed.)
 args: -iwad doom.wad -file %s -warp 2 1


> > ...but playing with doom1.wad under prboom+ make it immediately crash
> > after stepping out from the entry gate. freedoomu.wad works fine.
> 
> PWADs should generally not work with the shareware IWAD. PrBoom+ should
> detect that itself, so this is a bug.

Someone on Romero's Twitter (I can't navigate this thing) said it even work
with Chex Quest IWAD ;-)

Greets,



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

Bug#814672: libgupnp-1.0-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Package: libgupnp-1.0-dev
Version: 0.20.16-1
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libgupnp-1.0-dev is marked as "Multi-Arch: same", but contents of the 
following file vary with architecture:


/usr/share/man/man1/gupnp-binding-tool.1.gz

An example diff between i386 and mips (after ungzipping) is attached.

--
Jakub Wilk
diff -ur 
libgupnp-1.0-dev_0.20.16-1_i386/usr/share/man/man1/gupnp-binding-tool.1 
libgupnp-1.0-dev_0.20.16-1_mips/usr/share/man/man1/gupnp-binding-tool.1
--- libgupnp-1.0-dev_0.20.16-1_i386/usr/share/man/man1/gupnp-binding-tool.1 
2016-02-12 20:59:33.0 +0100
+++ libgupnp-1.0-dev_0.20.16-1_mips/usr/share/man/man1/gupnp-binding-tool.1 
2016-02-13 04:13:16.0 +0100
@@ -2,12 +2,12 @@
 .\" Title: gupnp-binding-tool
 .\"Author: [FIXME: author] [see http://docbook.sf.net/el/author]
 .\" Generator: DocBook XSL Stylesheets v1.79.1 
-.\"  Date: 02/12/2016
+.\"  Date: 02/13/2016
 .\"Manual: Reference
 .\"Source: GUPnP 0.20.16
 .\"  Language: English
 .\"
-.TH "GUPNP\-BINDING\-TOOL" "1" "02/12/2016" "GUPnP 0\&.20\&.16" "Reference"
+.TH "GUPNP\-BINDING\-TOOL" "1" "02/13/2016" "GUPnP 0\&.20\&.16" "Reference"
 .\" -
 .\" * Define some portability stuff
 .\" -

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

[Francesco Poli]

Control: found -1 systemd/228-6


On Sun, 29 Nov 2015 01:05:44 +0100 Michael Biebl wrote:

> Am 28.11.2015 um 19:23 schrieb Francesco Poli:
> 
> > Please tell me whether you need any further information in order to
> > investigate. Otherwise, please drop the moreinfo tag.
> 
> So far I don't know yet, how I can reproduce the problem. So I'll keep
> the moreinfo tag.

Hello again,
have you found a way to reproduce the bug?

I have just retried and I was able to reproduce the same exact
misbehavior as originally reported.
As I have previously stated, I was able to regain control of my box by
issuing the "killall -TERM fluxbox" command (I had scheduled such
command with at(1)). However, my X session was lost, unsurprisingly.

I also figured out an unpractical (yet effective) workaround: after
steps 0 through 3 (see my original bug report), instead of logging out
from the TTY2 shell, I followed the steps

  4') press [Ctrl+Alt+F1], in order to switch back to the X session

  5') from within a terminal emulator (such as xterm), figure out the
  PID of the shell running on TTY2 with

  $ ps aux | grep 'tty2.*-bash'

  6') call this PID "PID_OF_TTY2_SHELL"

  7') terminate that shell from within the X session terminal emulator
  with

  $ kill -TERM PID_OF_TTY2_SHELL

  8') go on doing anything you please with your X session


Needless to say, I would love to see this bug properly fixed, instead
of having to rely on unpractical workarounds...

I hope this can happen soon.

Thanks for your time!
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpvbbyXrXBi5.pgp
Description: PGP signature

Bug#814671: libgmp10: please update symbols for nios2

[Helmut Grohne]

Source: gmp
Version: 2:6.0.0+dfsg-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear gmp maintainer,

gmp fails to build from source on nios2 (which is a new architecture
from a Debian point of view). dpkg-gensymbols fails missing a lot of
symbols. This is kinda expected for a new port. As it happens, nios2
behaves exactly the same as mips (and a few other architectures) from a
gmp symbols point of view. Thus

sed -i 's/!mips /!nios2 &/' debian/libgmp10.symbols

can be used to make the gmp build succeed on nios2. Can you apply this
fix?

Helmut

Bug#812648: astroquery: FTBFS - AttributeError: 'Config' object has no attribute '_conftest'

[Vincent Prat]

Hi,

I managed to reproduce the bug.

According to my investigations, it is caused by a change in pytest 
(fails with version 2.8).
The current version of astropy available in Debian does not take this 
change into account (see upstream discussion at 
https://github.com/astropy/astropy/issues/4256) and thus make astroquery 
tests fail.


I managed to get rid of the bug by modifying the offending line (164) in 
/usr/lib/usr/lib/python2.7/dist-packages/astropy/tests/pytest_plugins.py:


-module = self.config._conftest.importconftest(self.fspath)
+module = self.config.pluginmanager._importconftest(self.fspath)

as it is in the file doctest.py of python-pytest (line 172).

Best regards,
Vincent

Bug#814670: login: su - clears XDG_RUNTIME_DIR

[Rafael Cunha de Almeida]

Package: login
Version: 1:4.2-3+deb8u1
Severity: normal

Dear Maintainer,

I have an user which has daemons enabled using systemd --user. If I
login with ssh, then all works well. However, if I try using

su - contos

to login as the user. Then systemctl fails, like so:

$ systemctl status --user contos
Failed to get D-Bus connection: Connection refused

Upon further investigation I found out that systemctl expects the
variable XDG_RUNTIME_DIR to be set. In this particular case, we need it
set to /run/user/1029.

$ XDG_RUNTIME_DIR=/run/user/1029 systemctl status --user contos
● contos.service - blog canto de contos
(.. normal output ..)

If I use su contos (no -), then XDG_RUNTIME_DIR is kept the same as the
previous user (which is also no good).

Since this is set correctly when using ssh but not su, I'm supposing
this is a su bug. However, I admit I do not have a full understanding on
what's going on when you su or ssh to an user.

I also tried to use

sudo login contos

with the same effect. So, as far as I know, using ssh to login with the
user is the only reliable way to work with user's systemctl.

Please, if it is impossible to fix this behavior in jessie, would you at
least give me a reasonable workaround on how to login as a different
user without the need of ssh?

Cheers,
Rafael

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

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

Versions of packages login depends on:
ii  libaudit1   1:2.4-1+b1
ii  libc6   2.19-18+deb8u2
ii  libpam-modules  1.1.8-3.1+deb8u1
ii  libpam-runtime  1.1.8-3.1+deb8u1
ii  libpam0g1.1.8-3.1+deb8u1

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#814669: New upstream release

[David Prévot]

Package: xul-ext-gcontactsync
Version: 2.0.5-1

Hi Michael,

You might have missed it since the UDD-based watch seems broken
currently, but a new release of gContactSync (2.0.9) [0] has been
published a few months ago. Would be nice to have the package updated in
time for Stretch. Even an alpha release (3.0.0a2) could already be
packaged for experimental.

0: https://addons.mozilla.org/thunderbird/addon/gcontactsync/

Regards

David


signature.asc
Description: PGP signature

Bug#814668: installing libglib2.0-0:kfreebsd-i386 on amd64 resets system clock to 1970

[Helmut Grohne]

Package: libglib2.0-0
Version: 2.46.2-3
User: helm...@debian.org
Usertags: rebootstrap

Hi,

I was wondering why my clock is wrong so often. It goes back to 1970
occasionally. After some bisection, I could narrow the issue down to
installing libglib2.0-0. This sounds completely wrong as libglib2.0-0 is
never supposed to change the clock at all. How could it possibly contain
code to do that? So let's look at how to reproduce this:

# dpkg --print-architecture
amd64
# dpkg --add-architecture kfreebsd-i386
# apt-get update
...
# apt-get install libglib2.0-0:kfreebsd-i386
...
Setting up libglib2.0-0:kfreebsd-i386 (2.46.2-3) ...
Segmentation fault
Segmentation fault
Processing triggers for libc-bin (2.21-7) ...
# date
Fri Jan  2 14:37:50 UTC 1970
#

The culprit is in the postinst. There it invokes:

/usr/lib/i386-kfreebsd-gnu/glib-2.0/glib-compile-schemas 
/usr/share/glib-2.0/schemas

Running strace on it reveals:

| execve("/usr/lib/i386-kfreebsd-gnu/glib-2.0/glib-compile-schemas", 
["/usr/lib/i386-kfreebsd-gnu/glib-"..., "/usr/share/glib-2.0/schemas"], [/* 25 
vars */]) = 0
| strace: [ Process PID=16574 runs in 32 bit mode. ]
| getuid()= 0
| stime([139068]) = 0
| getgid()= 0
| times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1963081704
| break() = -1 ENOSYS (Function not implemented)
| getuid()= 0
| access("", W_OK|0x50)   = -1 EINVAL (Invalid argument)
| --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
| +++ killed by SIGSEGV +++

What happens here is that a kfreebsd-i386 binary is run on a linux
kernel. Unfortunately, their syscall interfaces are sufficiently similar
that some syscalls actually are successful in doing what they never
intended: changing the system clock.

I wish I could tell you how to fix this, but I don't know a good way.
Possibly glibc should do something different? In any case, I am
documenting the issue here and I added d-cross@l.d.o to seek ideas
there.

Helmut

Bug#814667: systemd-networkd overrides default kernel net.ipv6.conf.interface.accept_ra

[pdormeau]

Package: systemd
Version: 229-1
Severity: normal

Dear Maintainer,

man systemd.network says:

"IPv6AcceptRouterAdvertisements=
Force the setting of the accept_ra (router advertisements) setting for 
the interface. When unset, the kernel default is used, and router 
advertisements are accepted only when local forwarding is disabled for 
that interface.
When router advertisements are accepted, they will trigger the start of 
the DHCPv6 client if the relevant flags are passed, or if no routers are 
found on the link. Takes a boolean. If true, router advertisements are 
accepted, when false, router advertisements are ignored, independently 
of the local forwarding state."

But although IPv6AcceptRouterAdvertisements is not set, DHCP is not set 
to ipv6, and forwarding is disabled, systemd-networkd overrides default 
kernel (net.ipv6.conf.wlp3s0.accept_ra switched from 1 to 0 after 
systemd-networkd.service starts). Consequently, SLAAC fails.

Setting IPv6AcceptRouterAdvertisements to true or false does not help 
either.

# cat /etc/systemd/network/wlp3s0.network 
[Match]
Name=wlp3s0

[Network]
DHCP=ipv4

[DHCP]
UseDNS=true


# sysctl net.ipv6.conf.wlp3s0.accept_ra=1
net.ipv6.conf.wlp3s0.accept_ra = 1
# sysctl net.ipv6.conf.wlp3s0.forwarding
net.ipv6.conf.wlp3s0.forwarding = 0
# systemctl restart systemd-networkd.service
# sysctl net.ipv6.conf.wlp3s0.accept_ra
net.ipv6.conf.wlp3s0.accept_ra = 0

This does not happen with version 228-6

Best regards

Pascal Dormeau


-- Package-specific info:

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

Kernel: Linux 4.3.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 systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-3
ii  libapparmor12.10-3
ii  libaudit1   1:2.4.5-1
ii  libblkid1   2.27.1-3
ii  libc6   2.21-7
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.6.5-2
ii  libgpg-error0   1.21-1
ii  libkmod222-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-3
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.2.3-3
ii  libselinux1 2.4-3
ii  libsystemd0 229-1
ii  mount   2.27.1-3
ii  util-linux  2.27.1-3

Versions of packages systemd recommends:
ii  dbus1.10.6-1
ii  libpam-systemd  229-1

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

Versions of packages systemd is related to:
ii  udev  229-1

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=volatile
RuntimeMaxUse=50M
ForwardToSyslog=no
ForwardToConsole=yes
TTYPath=/dev/tty12

/etc/systemd/resolved.conf changed:
[Resolve]
DNS=212.27.40.240 2a01:e00::1 212.27.40.241 2a01:e00::2


-- no debconf information

Bug#814556: nvidia-modprobe: Can not build nvidia-modprobe_358.09-1 on Wheezy

[wylda]

> The problem starts here:
> > dpkg-parsechangelog: unknown option `-S'
> 
> so in debian/rules use something like
> 
> DATE  := $(shell dpkg-parsechangelog | sed -nr '/^Date:/s/Date: //p')

Hello Andreas, it really works :c)) Thank you very much for precise and quick 
answer!

Initialy i though, that ":=" is a typo instead of plain "=", but ":=" works 
perfectly ;)


BTW: Is there a plan for getting "nvidia-settings" version up to date with 
"nvidia-driver"
version?

Bug#814666: sysv-rc: update-rc.d prints incomplete usage (missing 'defaults')

[El Topo]

Package: sysv-rc
Version: 2.88dsf-59.2
Severity: minor

Dear Maintainer,

update-rc.d prints incomplete usage for itself.

Here's the output of update-rc.d command:

# update-rc.d --help
update-rc.d: error: --help
usage: update-rc.d [-n] [-f]  remove
   update-rc.d [-n]  disable|enable [S|2|3|4|5]
-n: not really
-f: force

The disable|enable API is not stable and might change in the future.



However, this is copied from update-rc.d's manpage:

SYNOPSIS
   update-rc.d [-n] [-f] name remove

   update-rc.d [-n] name defaults

   update-rc.d [-n] name disable|enable [ S|2|3|4|5 ]




As you can see, "update-rc.d [-n] name defaults" is missing from update-rc.d's
usage.


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

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

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  insserv1.14.0-5.2
ii  startpar   0.59-3
ii  sysvinit-utils 2.88dsf-59.2

Versions of packages sysv-rc recommends:
ii  lsb-base  9.20160110

Versions of packages sysv-rc suggests:
pn  bum  

-- debconf-show failed

Bug#812513: please add E1M8b.wad to the doom-wad_*.deb package

[Fabian Greffrath]

Am Samstag, den 13.02.2016, 14:11 +0100 schrieb Alexandre Detiste:
> The package-size / number of files is not really an issue with GDP-
> generated
> packages. Even package with one 30kb text adventure games are ok;
> they don't put any weight on mirrors infrastructure etc...

Agreed. Do you mean the WAD could get created separately if you create
the doom-wad package?

> e1m8b.wad could even be packaged like doom-wad-shareware;
> the license permit it; but I guess it's not justified;
> I prefer to use ftp-master's time on reviewing new engines (corsix-th 
> in the queue)
> that to review packages with no added-value over GDP-generated ones.

Agreed. I am also against packaging freely available PWAD files for the
Debian archive.

> ...but playing with doom1.wad under prboom+ make it immediately crash
> after stepping out from the entry gate. freedoomu.wad works fine.

PWADs should generally not work with the shareware IWAD. PrBoom+ should
detect that itself, so this is a bug.

 - Fabian


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

Bug#810568: openexr transition

[Emilio Pozuelo Monfort]

On 13/02/16 12:17, Andreas Beckmann wrote:
> On 2016-02-13 12:07, Andreas Beckmann wrote:
>> ben is unsure about the state of about openimageio/mips64el,
>> but I cannot see anything "old" (i.e. /6v5/) in the build log.
> 
> caused by libopenimageio1.5v5 cruft, so
> 
> nmu blender_2.76.b+dfsg0-3 . mips64el . -m "Rebuild against 
> libopenimageio1.6."

All three scheduled.

Emilio

Bug#814660: RFS: propellor/2.15.4-1 -- property-based host configuration management in haskell

[PICCA Frederic-Emmanuel]

Done :)

thanks for your work.

Fred

Bug#814665: Useless in Debian

[David Prévot]

Package: php-auth
Version: 1.6.4-1
Severity: serious
Tag: sid stretch
Control: block -1 by 814664

[Filled as RC by a team member to see it auto-removed from testing if
 nobody disagrees. Please, do downgrade it with an explanation if you
 disagree.]

php-auth is only used by extplorer (removed from testing more than two
years ago), and has not been updated upstream in over five years. “This
package is not maintained” as can be read on the upstream website [0].

0: https://pear.php.net/package/Auth

The only current reverse dependency in testing is roundube-core, but it
is going away (see #814664). Yet, I don’t intend to follow up with an RM
request until extplorer gets also removed (or fixed to not use obsolete
libraries).

Regards

David


signature.asc
Description: PGP signature

Bug#814599: [Bash-completion-devel] Bug#814599: bash-completion: different behavior in /etc/bash_completion.d/ than in /usr/share/bash-completion/completions/

[Martin-Éric Racine]

2016-02-13 21:12 GMT+02:00 Ville Skyttä :
> Yes, things have changed, this is not a bug in bash-completion. Your
> script not being sourced at all from the new location is expected
> because the name of the script is not what it needs to be to work
> properly in that location. In the old, deprecated location everything
> is eagerly loaded at shell startup, pretty much no matter what name
> things are in. Change the name of the script to chlogin or
> chlogin.bash and it will be sourced when needed.

Fair enough.

This detail would need to be added to the error that Lintian throws at
maintainers when their script is still at the old location.

Martin-Éric

Bug#814664: Incorrect hardcoded php-auth and other dependencies

[David Prévot]

Package: roundcube-core
Version: 1.1.4+dfsg.1-1
Severity: important

Hi,

According to composer.json-dist, there shouldn’t be any php-auth
dependency. Instead, it should read something like:

Depends: php-auth-sasl (>= 1.0.6),
 php-net-idna2 (>= 0.1.1),
 php-net-sieve (>= 1.3.4),
 php-mail-mime (>= 1.9.0),
 php-net-smtp (>= 1.4.2),
 php-patchwork-utf8 (>= 1.2.3)
Suggests: php-net-ldap2 (>= 2.1.0),
  php-net-ldap3

pkg-php-tools may be useful to translate those dependencies
automatically, and to keep them up to date.

Since php-auth “is not maintained” [0], we’d like to get read of it
ASAP, thus the important severity.

0: https://pear.php.net/package/Auth

I’ll open a serious bug against php-auth, and block it by this one. You
may wish to update your package before it gets auto-removed.

Regards

David


signature.asc
Description: PGP signature

Bug#814663: RFS: aggressive-indent-mode/1.5-1 -- Emacs minor mode that reindents code after every change

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of my package
aggressive-indent-mode.

* Package name: aggressive-indent-mode
  Version : 1.5-1
  Upstream Author : Artur Malabarba 
* URL : https://github.com/Malabarba/aggressive-indent-mode
* License : GPL-2+
  Section : lisp

Changes since the last upload:

  * New upstream release.
  * Update patch to README.md.
  * Improve package description.
  * Override Lintian pedantic warnings with justifications.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/a/aggressive-indent-mode/aggressive-indent-mode_1.5-1.dsc

Or build it with gbp:

git clone 
https://anonscm.debian.org/git/pkg-emacsen/pkg/aggressive-indent-mode
git checkout debian/1.5-1
git verify-tag debian/1.5-1 # if you have my key
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814625: open-iscsi: broken sanboot setup

[Christian Seiler]

On 02/13/2016 08:14 PM, Ritesh Raj Sarraf wrote:
> Control: reassign -1 multipath-tools
> 
> On Sat, 2016-02-13 at 15:51 +0100, Christian Seiler wrote:
>> Hi Ritesh,
>>
>> On 02/13/2016 03:31 PM, Ritesh Raj Sarraf wrote:
>>> Something in the recent update (log attached) broke my multipath
>>> setup
>>> that comprises of dm-multipath, iscsi, lio target, lvm and more.
>>
>> Your log is weird - it appears you are downgrading from -13 (sid) to
>> -9 (testing)? That isn't supported, and there's a debconf prompt for
>> that (which you apparently accepted).
>>
> 
> 
> Sorry about that. My setup was all broken and I was trying multiple
> things.

I have a non-multipath test setup of open-iscsi that works well
and I even recently upgraded to unstable before I closed the
RC bug I had open to prevent open-iscsi from migrating to testing
to verify that everything works as expected.

> But I don't recollect seeing any debconf prompt during the downgrade.

It's in your log. And it's a critical prompt, so unless you
explicitly use something that dramatically suppresses debconf
prompts it should be shown.

> The issue is weird in that the diff between multipath-tools -2 and -4
> is almost zero. But I can't see much on what would break my setup. :-(

Are you sure it's multipath-tools?

Do you have an image I could try with some instructions on what
LIO configuration you are using? Maybe I could help debug your
issue...

Also: what exactly broke? Your bug doesn't actually specify
what's wrong, beyond the fact that update-initramfs complains
about iscsistart.

Btw. just now I noticed in your log that open-iscsi -13 was
actually installed on your system and still the update-initramfs
error came. Had you perhaps installed an older test package with
-13 that didn't have the fix for the /sbin/iscsistart? It would
be great to see the rest of your log to see what really happened.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#814662: RFS: tweepy/3.5.0-1 [RC]

[Ross Gammon]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: tweepy
   Version : 3.5.0-1
   Upstream Author : Joshua Roesslein 
 * URL : http://www.tweepy.org/
 * License : MIT
   Section : python

It builds these binary packages:

 python-tweepy - Twitter library for Python
 python-tweepy-doc - Documentation for python-tweepy module
 python3-tweepy - Twitter library for Python 3

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

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


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

dget -x
http://mentors.debian.net/debian/pool/main/t/tweepy/tweepy_3.5.0-1.dsc

The Debian packaging can be found here:
https://anonscm.debian.org/cgit/python-modules/packages/tweepy.git

Changes since the last upload:

  * Team upload
  * New upstream release
  * Disable upstream tests (Closes: #804558)
The tests fail as they need internet access
  * Use secure URL for Vcs
  * Make Python 3 package short description unique


Regards,
Ross Gammon



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

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

Bug#814661: emacs24: debian/copyright specifies GPL-3 instead of GPL-3+

[Sean Whitton]

Package: emacs24
Version: 24.5+1-6+b1
Severity: minor

Dear maintainer,

Emacs is licensed under the GNU GPL 3 "or (at your option) any later
version".  But the debian/copyright file says that it is licensed under
the GNU GPL 3 alone.

Thanks.

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 emacs24 depends on:
ii  emacs24-bin-common 24.5+1-6+b1
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-2
ii  libasound2 1.1.0-1
ii  libatk1.0-02.18.0-1
ii  libc6  2.21-7
ii  libcairo-gobject2  1.14.6-1
ii  libcairo2  1.14.6-1
ii  libdbus-1-31.10.6-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.32.3-1.2
ii  libgif75.1.2-0.2
ii  libglib2.0-0   2.46.2-3
ii  libgnutls303.4.8-2
ii  libgomp1   5.3.1-7
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.18.7-1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.4.2-2
ii  libm17n-0  1.7.0-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-7+b1
ii  libmagickwand-6.q16-2  8:6.8.9.9-7+b1
ii  libotf00.9.13-3
ii  libpango-1.0-0 1.38.1-1
ii  libpangocairo-1.0-01.38.1-1
ii  libpng12-0 1.2.54-1
ii  librsvg2-2 2.40.11-2
ii  libselinux12.4-3
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.6-1
ii  libtinfo5  6.0+20151024-2
ii  libx11-6   2:1.6.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.3+dfsg1-1
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.5.0-1
ii  libxrender11:0.9.9-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814625: open-iscsi: broken sanboot setup

[Ritesh Raj Sarraf]

Control: reassign -1 multipath-tools

On Sat, 2016-02-13 at 15:51 +0100, Christian Seiler wrote:
> Hi Ritesh,
> 
> On 02/13/2016 03:31 PM, Ritesh Raj Sarraf wrote:
> > Something in the recent update (log attached) broke my multipath
> > setup
> > that comprises of dm-multipath, iscsi, lio target, lvm and more.
> 
> Your log is weird - it appears you are downgrading from -13 (sid) to
> -9 (testing)? That isn't supported, and there's a debconf prompt for
> that (which you apparently accepted).
> 


Sorry about that. My setup was all broken and I was trying multiple
things.

But I don't recollect seeing any debconf prompt during the downgrade.


The issue is weird in that the diff between multipath-tools -2 and -4
is almost zero. But I can't see much on what would break my setup. :-(


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#814599: [Bash-completion-devel] Bug#814599: bash-completion: different behavior in /etc/bash_completion.d/ than in /usr/share/bash-completion/completions/

[Ville Skyttä]

Yes, things have changed, this is not a bug in bash-completion. Your
script not being sourced at all from the new location is expected
because the name of the script is not what it needs to be to work
properly in that location. In the old, deprecated location everything
is eagerly loaded at shell startup, pretty much no matter what name
things are in. Change the name of the script to chlogin or
chlogin.bash and it will be sourced when needed.

Bug#814660: RFS: propellor/2.15.4-1 -- property-based host configuration management in haskell

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of propellor.

* Package name: propellor
  Version : 2.15.4-1
  Upstream Author : Joey Hess 
* URL : https://propellor.branchable.com/
* License : BSD-2-clause
  Section : admin

Changes since the last upload:

  * New upstream version.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.4-1.dsc

Or build it with gbp:

git clone https://git.spwhitton.name/propellor -b debian
git checkout pristine-tar  # to create this branch locally, so gbp uses 
it
git checkout debian/2.15.4-1
git verify-tag debian/2.15.4-1 # if you have my key
gbp buildpackage -sa

Note to potential sponsor: due to an unorthadox changelog, you must
explicitly pass -sa to either gbp or dpkg-buildpackage in order to
include the *.orig.tar.xz file in your *.changes file.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814659: boinc-client-nvidia-cuda: prepare for CUDA 7.5

[Andreas Beckmann]

Package: boinc-client-nvidia-cuda
Version: 7.6.25+dfsg-1
Severity: normal

Hi,

I'll update to CUDA 7.5 in experimental, soon. This will be available
for amd64 (and probably ppc64el, too), but not for i386 (like 7.0).

Please update the alternative dependencies accordingly. 


Andreas

Bug#810414: closed by Christian Perrier (Bug#810414: fixed in garmin-forerunner-tools 0.10repacked-6)

[Aurelien Jarno]

Big thanks for fixing this bug.
On 2016-02-13 18:21, Debian Bug Tracking System wrote:
> 
> Format: 1.8
> Date: Sat, 13 Feb 2016 19:01:12 +0100
> Source: garmin-forerunner-tools
> Binary: garmin-forerunner-tools
> Architecture: source i386
> Version: 0.10repacked-6
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian running develpment group 
> 
> Changed-By: Christian Perrier 
> Description:
>  garmin-forerunner-tools - retrieve data from Garmin Forerunner/Edge GPS 
> devices
> Closes: 810414
> Changes:
>  garmin-forerunner-tools (0.10repacked-6) unstable; urgency=medium
>  .
>* Switch to libusb-1.0. Thanks to Olaf Meeuwissen for the patch.
>  Closes: #810414

Big thanks for fixing this bug.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#814658: mutt wrongly complains about Unmatched ( or \( in hook regular explession

[Christian Böhme]

Package: mutt
Version: 1.5.23-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Configuring mutt.

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

Writing a configuration file (/the/config/file) containing

send-hook  '~t (ab|cd)$''set my_var = xyz'

at line 123.

   * What was the outcome of this action?

Upon startup, mutt complains

Error in /the/config/file, line 123: '(ab': Unmatched ( or \(

   * What outcome did you expect instead?

Mutt starting up and properly compiling the regular expression.

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

The regular expression has the proper form according to
http://www.mutt.org/doc/devel/manual.html#regexp .  Wrapping
the alternatives in braces such that  ((ab)|(cd))$  did not
help either.

-- Package-specific info:
Mutt 1.5.23 (2014-03-12)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 3.19.7-apple-mbp4.1-gpt-ext4 (x86_64)
ncurses: ncurses 6.0.20151024 (compiled with 5.9)
libidn: 1.32 (compiled with 1.29)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-4) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/xtitles.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features-old/patch-1.5.4.vk.pgp_verbose_mime.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-speci

Bug#814657: ghc: Please add initial platform support for x32

[John Paul Adrian Glaubitz]

Source: ghc
Version: 7.10.3-7
Severity: normal
Tags: patch

Hi!

I recently bootstrapped ghc on x32.

To achieve that, the following changes were necessary:

 * patch rts/Linker.c to use native 64-bit integer instructions on x32
 * build the compiler unregisterised even though x86_64 has a NCG
   which needs some work to support x32 though
 * use integer-simple by default on x32 since integer-gmp currently
   has issues on x32 (sizeof(mp_limb_t) != sizeof(void *) is unsupported)

The first patch is more discussed by upstream in detail in [1], since they
were not sure yet whether the simple patch that I am using is safe not to
break anything on other platforms.

Attaching a debdiff with my changes in any case so that a discussion can
be started.

Cheers,
Adrian

> [1] https://ghc.haskell.org/trac/ghc/ticket/11571

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ghc-7.10.3/debian/patches/series new/ghc-7.10.3/debian/patches/series
--- old/ghc-7.10.3/debian/patches/series   2015-12-18 13:25:32.0 +0100
+++ new/ghc-7.10.3/debian/patches/series   2016-02-10 19:11:01.378870044 +0100
@@ -7,3 +7,4 @@
 cabal-show-detail-direct.patch
 sh4-platform-detection-support.patch
 sparc64-initial-platform-support.patch
+x32-use-native-x86_64-insn.patch
diff -Nru old/ghc-7.10.3/debian/patches/x32-use-native-x86_64-insn.patch new/ghc-7.10.3/debian/patches/x32-use-native-x86_64-insn.patch
--- old/ghc-7.10.3/debian/patches/x32-use-native-x86_64-insn.patch	 1970-01-01 01:00:00.0 +0100
+++ new/ghc-7.10.3/debian/patches/x32-use-native-x86_64-insn.patch	 2016-02-13 19:27:46.250266694 +0100
@@ -0,0 +1,25 @@
+Description: Use native x86_64 instructions on x32
+ This patch enables a few native 64-bit integer instructions
+ on x32 which are available on this architecture despite using
+ 32-bit pointers. These instructions are present on x86_64 but
+ not on x86 and ghc checks the size of (void *) to determine
+ that. This method fails on x32 since despite using 32-bit
+ pointers and hence sizeof(void *) == 4, it still uses the
+ full x86_64 instruction set and software-emulated variants
+ of the aforementioned 64-bit integer instructions are
+ therefore not present in the toolchain which will make ghc
+ fail to build on x32.
+ See: https://ghc.haskell.org/trac/ghc/ticket/11571
+ .
+
+--- ghc-7.10.3.orig/rts/Linker.c
 ghc-7.10.3/rts/Linker.c
+@@ -1432,7 +1432,7 @@ typedef struct _RtsSymbolVal {
+ 
+ 
+ // 64-bit support functions in libgcc.a
+-#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32)
++#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) && !defined(__ILP32__)
+ #define RTS_LIBGCC_SYMBOLS \
+   SymI_NeedsProto(__divdi3)\
+   SymI_NeedsProto(__udivdi3)   \
diff -Nru old/ghc-7.10.3/debian/rules new/ghc-7.10.3/debian/rules
--- old/ghc-7.10.3/debian/rules	  2016-01-05 11:09:35.0 +0100
+++ new/ghc-7.10.3/debian/rules	  2016-02-13 19:33:46.001814498 +0100
@@ -43,6 +43,10 @@
 BUILD_HADDOCK_DOCS=YES
 DEB_HOOGLE_TXT_DIR = /usr/lib/ghc-doc/hoogle/
 
+ifeq (x32,$(DEB_HOST_ARCH))
+  EXTRA_CONFIGURE_FLAGS += --enable-unregisterised
+endif
+
 %:
	dh $@ --with autotools-dev
 
@@ -64,6 +68,9 @@
   echo "SRC_CC_OPTS += -fno-PIE" >> mk/build.mk
   echo "SRC_LD_OPTS += -no-pie" >> mk/build.mk
 endif
+ifeq (x32,$(DEB_HOST_ARCH))
+ echo "INTEGER_LIBRARY = integer-simple" >> mk/build.mk
+endif
 ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 # echo "GhcStage1HcOpts += -DDEBUG" >> mk/build.mk
 # echo "GhcStage2HcOpts += -DDEBUG" >> mk/build.mk

Bug#791924: tracker.d.o: please compact the visualization

[Christophe Siraut]

control: tags -1 patch

Here is a patch for shrinking list items.

Cheers,
Christophe
>From 11d36d66525c464fd336f5edcf48920d99cc0c1e Mon Sep 17 00:00:00 2001
From: Christophe Siraut 
Date: Sat, 13 Feb 2016 19:30:14 +0100
Subject: [PATCH] css: shrink list-group-items (closes: ##791924)

---
 distro_tracker/core/static/css/style.css | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/distro_tracker/core/static/css/style.css b/distro_tracker/core/static/css/style.css
index 7405a77..ae57d41 100644
--- a/distro_tracker/core/static/css/style.css
+++ b/distro_tracker/core/static/css/style.css
@@ -126,13 +126,13 @@
 }
 
 .panel-heading {
-  padding: 5px 5px;
+  padding: 3px 5px 3px 6px;
   margin: -15px -15px 0px;
   font-size: 17.5px;
   font-weight: 500;
   color: #ff;
   background-color: #d70751;
-  border-bottom: 1px solid #dd;
+  border-bottom: 1px solid #f1f1f1;
   border-top-right-radius: 3px;
   border-top-left-radius: 3px;
 }
@@ -173,9 +173,9 @@
 .list-group-item {
   position: relative;
   display: block;
-  padding: 5px 5px 5px 5px;
+  padding: 2px 3px 2px 5px;
   margin-bottom: -1px;
-  border: 1px solid #dd;
+  border: 1px solid #f1f1f1;
 }
 
 .list-group-item > .list-item-key {
-- 
2.7.0

Bug#814656: manpages-posix-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: manpages-posix-dev
Version: 2013a-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  jessie -> sid

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

2m18.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/manpages-posix-dev/changelog.Debian.gz (manpages-posix-dev) != 
/usr/share/doc/manpages-posix/changelog.Debian.gz (manpages-posix)
/usr/share/doc/manpages-posix-dev -> manpages-posix
  /usr/share/doc/manpages-posix-dev/copyright (manpages-posix-dev) != 
/usr/share/doc/manpages-posix/copyright (manpages-posix)
/usr/share/doc/manpages-posix-dev -> manpages-posix


cheers,

Andreas


manpages-posix-dev_2013a-1.log.gz
Description: application/gzip

Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members

[Stefan Lippers-Hollmann]

Hi

On 2016-02-13, Stefan Lippers-Hollmann wrote:
> On 2016-02-13, Stefan Lippers-Hollmann wrote:
[...]
> Apparently I can work around this problem by explicitly disabling
> IPv6AcceptRouterAdvertisements for enp2s0 and enp4s0:
[...]
> $ ip -6 r
> 2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> fe80::/64 dev br0  proto kernel  metric 256  pref medium
> fe80::/64 dev br1  proto kernel  metric 256  pref medium
> fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
> fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
> default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref 
> medium

No, this doesn't actually work - after a couple of minutes the IPv6
addresses and route 'bleed over' to the second bridge (no, there isn't
any connection between br0 and br1, neither any forwarding configured).

$ ip -6 r
2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
2001:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
fd01:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
fe80::/64 dev br0  proto kernel  metric 256  pref medium
fe80::/64 dev br1  proto kernel  metric 256  pref medium
fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br1  proto ra  metric 1024  pref medium

$ ip a
4: br1:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 00:08:54:57:18:2c brd ff:ff:ff:ff:ff:ff
inet 192.168.20.20/24 brd 192.168.20.255 scope global br1
   valid_lft forever preferred_lft forever
inet6 fd01:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr 
noprefixroute 
   valid_lft forever preferred_lft forever
inet6 2001:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr 
noprefixroute 
   valid_lft forever preferred_lft forever
inet6 fe80::208:54ff:fe57:182c/64 scope link 
   valid_lft forever preferred_lft forever
5: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 94:de:80:02:ca:42 brd ff:ff:ff:ff:ff:ff
inet 10.10.20.0/8 brd 10.255.255.255 scope global dynamic br0
   valid_lft 39154sec preferred_lft 39154sec
inet6 fd01:470:1234:10::f14/128 scope global noprefixroute 
   valid_lft forever preferred_lft forever
inet6 fd01:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary 
dynamic 
   valid_lft 600756sec preferred_lft 81756sec
inet6 fd01:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr 
noprefixroute 
   valid_lft forever preferred_lft forever
inet6 2001:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary 
dynamic 
   valid_lft 600756sec preferred_lft 81756sec
inet6 2001:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr 
noprefixroute 
   valid_lft forever preferred_lft forever
inet6 fe80::96de:80ff:fe02:ca42/64 scope link 
   valid_lft forever preferred_lft forever

There is no apparent reason why br1 should have any IPv6 assigned (other 
than fe80::/64). Reverting back to src:systemd 228-6 is so far the only
option to fix my IPv6 connectivity (at least on systems with more than
one bridge configured).

Interesting enough, extending /etc/systemd/network/60-br1.network with
IPv6AcceptRouterAdvertisements=no prevents br0 from getting an IPv6
address as well (unless I systemctl restart systemd-networkd.service,
then it suddenly gets one).

Regards
Stefan Lippers-Hollmann



pgptSLn9vcFEI.pgp
Description: Digitale Signatur von OpenPGP

Bug#814655: haskell-text: Please allow integer-simple on x32

[John Paul Adrian Glaubitz]

Source: haskell-text
Version: 1.2.2.0-1
Severity: normal

Hello!

haskell-text currently fails to build from source on x32 because the package
requires integer-gmp which is currently not available on x32, unfortunately:

configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
--builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/text-1.2.2.0/ --datasubdir=text 
--htmldir=/usr/share/doc/libghc-text-doc/html/ --enable-library-profiling 
-f-integer-simple
hlibrary.setup: At least the following dependencies are missing:
integer-gmp >=0.2
Configuring text-1.2.2.0...
make: *** [configure-ghc-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
/usr/share/cdbs/1/class/hlibrary.mk:142: recipe for target 
'configure-ghc-stamp' failed

While 1.2.2.0 also recently regarding integer-simple support, even using an 
older
version of haskell-text will still result in an FTBFS since the debian/rules
file disables integer-simple support for haskell-text.

Thus, as a work-around, please allow integer-simple on x32 for the time being
with something like:

ifneq (x32,$(DEB_HOST_ARCH))
DEB_SETUP_GHC_CONFIGURE_ARGS = -f-integer-simple
endif

Thanks,
Adrian

> [1] https://github.com/bos/text/issues/138

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#814654: /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

[Rostislav Pehlivanov]

Package: nvidia-driver
Version: 352.79-2
Severity: important

Dear maintainer,

When updating the nvidia-driver package to 352.79-2 from 352.79-1, primusrun 
and optirun
become unusable and return an error:
primus: fatal: Bumblebee daemon reported: error:
[XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission 
denied

I performed a full uninstall of every nvidia related package and upon their 
reinstallation,
the bug still remained.

Earlier today a bug with the same description was submitted (#814630), except 
that it targeted
the package in experimental (the 355 version of the driver). I commented on the 
bug, but the bug
was apparently merged into #813565 and my comment lost.

I am resubmitting this bug with the hopes that the maintainers of the package 
will now know that
the regression exists both in 352.79-2 and 355.

I would also like the experimental and/or unstable branch to target the newest 
short-lived driver
release by the upstream, instead of lagging behind in features compared to the 
newest long-lived
release, however that's just a wish.

Regards,
Rostislav

-- Package-specific info:
uname -a:
Linux moonbase 4.5.0-rc3-youmu #3 SMP Fri Feb 12 00:03:21 GMT 2016 x86_64 
GNU/Linux

/proc/version:
Linux version 4.5.0-rc3-youmu (root@moonbase) (gcc version 6.0.0 20160125 
(experimental) [trunk revision 232803] (Debian 20160125-1) ) #3 SMP Fri Feb 12 
00:03:21 GMT 2016

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake Integrated 
Graphics [8086:191b] (rev 06) (prog-if 00 [VGA controller])
DeviceName:  Onboard IGD
Subsystem: Dell Skylake Integrated Graphics [1028:06e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

dmesg:
[0.328216] vgaarb: setting as boot device: PCI::00:02.0
[0.328219] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.328224] vgaarb: loaded
[0.328226] vgaarb: bridge control possible :00:02.0
[3.728113] [drm] Replacing VGA console driver
[3.741730] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[5.656613] bbswitch: Found integrated VGA device :00:02.0: 
\_SB_.PCI0.GFX0
[5.656618] bbswitch: Found discrete VGA device :01:00.0: 
\_SB_.PCI0.PEG0.PEGP
[   27.742371] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP 
handle
[   27.742465] nouveau :01:00.0: NVIDIA GM107 (1171b0a2)
[   28.960632] vga_switcheroo: enabled

Device node permissions:
crw-rw+ 1 root video 226,   0 Feb 13 17:29 /dev/dri/card0
crw-rw+ 1 root video 226,   1 Feb 13 17:30 /dev/dri/card1
crw-rw  1 root video 226,  64 Feb 13 17:29 /dev/dri/controlD64
crw-rw  1 root video 226,  65 Feb 13 17:30 /dev/dri/controlD65
crw-rw+ 1 root video 226, 128 Feb 13 17:29 /dev/dri/renderD128
crw-rw+ 1 root video 226, 129 Feb 13 17:30 /dev/dri/renderD129
video:x:44:atomnuker

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root25 Feb 13 17:29 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root49 Feb 13 17:28 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root51 Feb 13 17:29 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root48 Feb 13 17:28 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Feb 13 17:28 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Feb 13 17:29 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root48 Feb 13 17:29 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Feb 13 17:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Feb 13 17:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root55 Feb 13 17:28 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root55 Feb 13 17:28 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root57 Feb 13 17:29 
/etc/alternatives/glx-

Bug#814653: pgcharts: unowned directory after purge: /var/log/pgcharts/

[Andreas Beckmann]

Package: pgcharts
Version: 1.0-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned
directories on the system after purge, which is a violation of
policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

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

1m4.7s ERROR: FAIL: Package purging left files on system:
  /var/log/pgcharts/ not owned


cheers,

Andreas


pgcharts_1.0-2.log.gz
Description: application/gzip

Bug#810499: usrmerge: Confuses dpkg-shlibdeps

[Matthias Klumpp]

2016-02-13 18:29 GMT+01:00 Marco d'Itri :
> On Feb 13, Matthias Klumpp  wrote:
>
>> Installing libc6 into /usr/lib solves this issue, as one would expect.
>> Adding some debug code to dpkg-shlibdeps shows this the issue is - as
>> expected - shlibdeps calling dpkg-query on the wrong path in /usr
>> instead of /lib.
> I think that we either install everything in /usr/ (not that I would
> mind, but it would take some time)

We can do that in Tanglu (quite some work, potentially everything
shipping libs in /lib is affected), but I fear in Debian this would
become a much more controversial issue, since it would make the
usrmerge permanent.

> or else dpkg-shlibdeps will have to
> be patched to check both paths.

I tried to come up with a patch, but my Perl-foo is pretty bad,
unfortunately (so nothing which would be suitable for Debian came out
of it) :-/

Bug#814586: hglib tests broken with hg 3.7

[Julien Cristau]

Hi,

against hg 3.7.1, hglib tests fail with

==
ERROR: test_merge_prompt_noninteractive (tests.test-merge.test_merge)
--
Traceback (most recent call last):
  File "/<>/tests/test-merge.py", line 45, in 
test_merge_prompt_noninteractive
self.client.merge(cb=hglib.merge.handlers.noninteractive)
  File "/<>/hglib/client.py", line 1073, in merge
self.rawcommand(args, prompt=prompt)
  File "/<>/hglib/client.py", line 183, in rawcommand
raise error.CommandError(args, ret, out, err)
CommandError: (1, "remote changed a which local deleted\nuse (c)hanged version, 
leave (d)eleted, or leave (u)nresolved? u\n0 files updated, 0 files merged, 0 
files removed, 1 files unresolved\nuse 'hg resolve' to retry unresolved file 
merges or 'hg update -C .' to abandon", '')

--

I guess this is related to the following commit which changed the default
behaviour for hg merge:

changeset:   27166:88d5db4b155c
user:Siddharth Agarwal 
date:Tue Dec 01 09:48:38 2015 -0800
summary: filemerge: default regular prompts to 'leave unresolved' (BC)

What should hglib do in that case?

Thanks,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

Bug#814571: [Python-modules-team] Bug#814571: python-setuptools-whl and python-pip-whl: error when trying to install together

[Barry Warsaw]

On Feb 13, 2016, at 07:27 AM, Ralf Treinen wrote:

>Here is a list of files that are known to be shared by both packages
>(according to the Contents file for sid/amd64, which may be
>slightly out of sync):
>
>  /usr/share/python-wheels/setuptools-20.0-py2.py3-none-any.whl
>
>This bug has been filed against both packages. If you, the maintainers of
>the two packages in question, have agreed on which of the packages will
>resolve the problem please reassign the bug to that package. You may then
>also register in the BTS that the other package is affected by the bug.

It is a bug in setuptools and I forwarded a patch to the maintainer.  I'm
happy to NMU it if preferred.

Bug#814652: browser-plugin-freshplayer-pepperflash: fails to install: update-alternatives: error: error creating symbolic link '/usr/lib/mozilla/plugins/flash-mozilla.so.dpkg-tmp': No such file or dir

[Andreas Beckmann]

Package: browser-plugin-freshplayer-pepperflash
Version: 0.3.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package 
browser-plugin-freshplayer-pepperflash.
  (Reading database ... 
(Reading database ... 9551 files and directories currently installed.)
  Preparing to unpack 
.../browser-plugin-freshplayer-pepperflash_0.3.4-1_amd64.deb ...
  Unpacking browser-plugin-freshplayer-pepperflash (0.3.4-1) ...
  Setting up browser-plugin-freshplayer-pepperflash (0.3.4-1) ...
  update-alternatives: using 
/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so 
to provide /usr/lib/mozilla/plugins/flash-mozilla.so (flash-mozilla.so) in auto 
mode
  update-alternatives: error: error creating symbolic link 
'/usr/lib/mozilla/plugins/flash-mozilla.so.dpkg-tmp': No such file or directory
  dpkg: error processing package browser-plugin-freshplayer-pepperflash 
(--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   browser-plugin-freshplayer-pepperflash

The package must ship all directories where (slave) alternatives will be placed.
Ship them as empty directories, don't create them manually in the maintainer 
scripts.


cheers,

Andreas


browser-plugin-freshplayer-pepperflash_0.3.4-1.log.gz
Description: application/gzip

Bug#814650: python-xattr: No module named cffi

[Ondřej Nový]

Package: python-xattr
Version: 0.7.8-2
Severity: grave
Justification: renders package unusable

Module xattr is not working at all:

$ python -m xattr
/usr/bin/python: No module named cffi; 'xattr' is a package and cannot
be directly executed

After installing "python-cffi" it's working:
$ python -m xattr
/usr/bin/python: No module named xattr.__main__; 'xattr' is a package
and cannot be directly executed

I think this package is missing python-cffi in Depends.

Thanks.

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

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

Versions of packages python-xattr depends on:
ii  libc6 2.21-7
ii  python2.7.11-1
pn  python-cffi-backend-api-9729  
ii  python-pkg-resources  20.0-2
pn  python:any

python-xattr recommends no packages.

python-xattr suggests no packages.

-- no debconf information

Bug#814651: jessie-pu: package sitesummary/0.1.17+deb8u1

[Petter Reinholdtsen]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

The sitesummary package in stable is affected by two RC bugs, one giving
uninstallation problems, the other causing hangs in the postinst.  The
following patch will solve it.  The change is already in unstable and
testing.

diff --git a/debian/changelog b/debian/changelog
index 231a412..e165579 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+sitesummary (0.1.17+deb8u1) jessie; urgency=medium
+
+  * Backport RC fixes from unstable.
+
+  [ Dominik George ]
+  * Fix hanging postinst script (Closes: #785214).
+  * Fix dangling symlink in apache config after removal (Closes: #785215, 
#794606).
+
+ -- Petter Reinholdtsen   Sat, 13 Feb 2016 18:34:24 +0100
+
 sitesummary (0.1.17) unstable; urgency=high
 
   * Fix installation problem when sitesummary is preseeded to update
diff --git a/debian/sitesummary.postinst b/debian/sitesummary.postinst
index 031b9f4..910d81a 100644
--- a/debian/sitesummary.postinst
+++ b/debian/sitesummary.postinst
@@ -41,21 +41,6 @@ EOF
 
 case "$1" in
 configure)
-# Enable it on fresh installations as before Apache 2.4.  Check for
-# cgi.load existence to avoid trying to configure when installed after
-# apache2 is unpacked but not yet configured (bug #760084).
-if [ -z "$2" ] && \
-[ -e /etc/apache2/mods-available/cgi.load ] && \
-[ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
-. /usr/share/apache2/apache2-maintscript-helper
-apache2_invoke enmod cgi.load
-apache2_invoke enconf sitesummary.conf
-fi
-
-# Make sure the cgi script can write to the storage area
-   chown www-data /var/lib/sitesummary/tmpstorage \
-   /var/lib/sitesummary/entries 
-
 # If the config file is missing, check debconf to see if the
 # munin configuration feature should be enabled.  This hidden
 # debconf question allow preseeding during installation.
@@ -82,6 +67,24 @@ case "$1" in
update-rc.d -f sitesummary-client remove >/dev/null 2>&1 || :
fi
 
+# Close debconf file handles before restarting Apache
+db_stop
+
+# Enable it on fresh installations as before Apache 2.4.  Check for
+# cgi.load existence to avoid trying to configure when installed after
+# apache2 is unpacked but not yet configured (bug #760084).
+if [ -z "$2" ] && \
+[ -e /etc/apache2/mods-available/cgi.load ] && \
+[ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
+. /usr/share/apache2/apache2-maintscript-helper
+apache2_invoke enmod cgi.load
+apache2_invoke enconf sitesummary.conf
+fi
+
+# Make sure the cgi script can write to the storage area
+   chown www-data /var/lib/sitesummary/tmpstorage \
+   /var/lib/sitesummary/entries 
+
;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/debian/sitesummary.prerm b/debian/sitesummary.prerm
new file mode 100644
index 000..62eb441
--- /dev/null
+++ b/debian/sitesummary.prerm
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+case "$1" in
+remove)
+# Enable it on fresh installations as before Apache 2.4.  Check for
+# cgi.load existence to avoid trying to configure when installed after
+# apache2 is unpacked but not yet configured (bug #760084).
+if [ -z "$2" ] && \
+[ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
+. /usr/share/apache2/apache2-maintscript-helper
+apache2_invoke disconf sitesummary.conf
+fi
+;;
+*)
+echo "prerm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+exit 0

I would like to update the stable version of sitesummary to fix this bug
affecting Debian Edu.  Are you OK with me uploading a package with this
change?

-- 
Happy hacking
Petter Reinholdtsen

Bug#814649: RM: fonts-wine-development -- NBS; no longer built

[Michael Gilbert]

package: ftp.debian.org
severity: normal

Please remove fonts-wine-development.  It is no longer built by the
source package.

Best wishes,
Mike

Bug#810499: usrmerge: Confuses dpkg-shlibdeps

[Marco d'Itri]

On Feb 13, Matthias Klumpp  wrote:

> Installing libc6 into /usr/lib solves this issue, as one would expect.
> Adding some debug code to dpkg-shlibdeps shows this the issue is - as
> expected - shlibdeps calling dpkg-query on the wrong path in /usr
> instead of /lib.
I think that we either install everything in /usr/ (not that I would 
mind, but it would take some time) or else dpkg-shlibdeps will have to 
be patched to check both paths.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#814648: initrd missing from backport build (Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img)

[Antoine Beaupré]

Package: linux-image-4.3.0-0.bpo.1-amd64
Version: 4.3.3-7~bpo8+1
Severity: normal

This version of the backport seems to fail to install properly:

$ sudo apt install -t jessie-backports linux-image-4.3.0-0.bpo.1-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  linux-doc-4.3 debian-kernel-handbook
The following NEW packages will be installed:
  linux-image-4.3.0-0.bpo.1-amd64
0 upgraded, 1 newly installed, 0 to remove and 210 not upgraded.
Need to get 0 B/35.5 MB of archives.
After this operation, 173 MB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package linux-image-4.3.0-0.bpo.1-amd64.
(Reading database ... 447530 files and directories currently installed.)
Preparing to unpack 
.../linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb ...
Unpacking linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
Setting up linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
cp: cannot stat '/boot/initrd.img-4.3.0-0.bpo.1-amd64': No such file or 
directory
Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img .
dpkg: error processing package linux-image-4.3.0-0.bpo.1-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.3.0-0.bpo.1-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

and indeed, the initrd is not in /boot:

[1012]anarcat@angela:~100$ ls -al /boot/
total 73248K
drwxr-xr-x  5 root root 1024 Feb 13 12:26 .
drwxr-xr-x 26 root root 4096 Feb 13 12:26 ..
-rw-r--r--  1 root root  2676277 Jan 17 16:30 System.map-3.16.0-4-amd64
-rw-r--r--  1 root root  2889500 Dec 15 05:16 System.map-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  2949440 Jan 20 18:17 System.map-4.3.0-0.bpo.1-amd64
-rw-r--r--  1 root root   157726 Jan 17 16:30 config-3.16.0-4-amd64
-rw-r--r--  1 root root   169935 Dec 15 05:16 config-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root   171928 Jan 20 18:17 config-4.3.0-0.bpo.1-amd64
drwxr-xr-x  5 root root 7168 Feb 13 12:24 grub
drwxr-xr-x  2 root root 1024 Sep 24 21:54 images
-rw-r--r--  1 root root 27164630 Jan 23 12:19 initrd.img-3.16.0-4-amd64
-rw-r--r--  1 root root 28134677 Jan 23 12:20 initrd.img-4.2.0-0.bpo.1-amd64
drwx--  2 root root12288 Mar 29  2010 lost+found
-rw-r--r--  1 root root25372 Sep 24 21:50 memdisk
-rw-r--r--  1 root root   182704 Sep 10  2014 memtest86+.bin
-rw-r--r--  1 root root   184840 Sep 10  2014 memtest86+_multiboot.bin
-rw-r--r--  1 root root98964 Mar 10  2015 memtest86.bin
-rw-r--r--  1 root root  3119888 Jan 17 16:27 vmlinuz-3.16.0-4-amd64
-rw-r--r--  1 root root  3480512 Dec 15 05:15 vmlinuz-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  3566064 Jan 20 18:14 vmlinuz-4.3.0-0.bpo.1-amd64

Heck, it's not even in the package itself:

$ dpkg -c 
/var/cache/apt/archives/linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb
  | grep /boot/
drwxr-xr-x root/root 0 2016-01-20 18:17 ./boot/
-rw-r--r-- root/root   2949440 2016-01-20 18:17 
./boot/System.map-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root171928 2016-01-20 18:17 
./boot/config-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root   3566064 2016-01-20 18:14 
./boot/vmlinuz-4.3.0-0.bpo.1-amd64

Something really wrong happened when this backport was built...

a.

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

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

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod18-3
ii  linux-base  3.5

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 recommends:
ii  firmware-linux-free  3.3
ii  irqbalance   1.0.6-3

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-22+deb8u1
pn  linux-doc-4.3   

-- debconf information:
  
linux-image-4.3.0-0.bpo.1-amd64/postinst/depmod-error-initrd-4.3.0-0.bpo.1-amd64:
 false
  
linux-image-4.3.0-0.bpo.1-amd64/prerm/removing-running-kernel-4.3.0-0.bpo.1-amd64:
 true
  linux-image-4.3.0-0.bpo.1-amd64/postinst/mips-initrd-4.3.0-0.bpo.1-amd64:

Bug#785622: Reopening and reassigning to xfce4-settings

[Manolo Díaz]

Dear Maintainer,

I'm reopening this report because of two reasons:

1. Lxqt doesn't trigger this bug, so it must be related to Xfce.
2. xfsettingsd --replace brings back my desktop to life.

Kind regards,
-- 
Manolo Díaz

Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members

[Stefan Lippers-Hollmann]

Hi

On 2016-02-13, Stefan Lippers-Hollmann wrote:
[...]
> $ ip -6 r
> 2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> 2001:470:1234:10::/64 dev enp2s0  proto ra  metric 1024  pref medium
> 2001:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
> 2001:470:1234:10::/64 dev enp4s0  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev enp2s0  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev enp4s0  proto ra  metric 1024  pref medium
> fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
> fe80::/64 dev br0  proto kernel  metric 256  pref medium
> fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
> fe80::/64 dev br1  proto kernel  metric 256  pref medium
> default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref 
> medium
> default via fe80::92f6:52ff:fef6:c88 dev enp2s0  proto ra  metric 1024  pref 
> medium
> default via fe80::92f6:52ff:fef6:c88 dev br1  proto ra  metric 1024  pref 
> medium
> default via fe80::92f6:52ff:fef6:c88 dev enp4s0  proto ra  metric 1024  pref 
> medium

Apparently I can work around this problem by explicitly disabling
IPv6AcceptRouterAdvertisements for enp2s0 and enp4s0:

$ cat /etc/systemd/network/51-enp2s0.network 
[Match]
Name=enp2s0

[Network]
Bridge=br0
IPv6AcceptRouterAdvertisements=no

$ cat /etc/systemd/network/51-enp4s0.network 
[Match]
Name=enp4s0

[Network]
Bridge=br1
IPv6AcceptRouterAdvertisements=no

$ ip -6 r
2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
fe80::/64 dev br0  proto kernel  metric 256  pref medium
fe80::/64 dev br1  proto kernel  metric 256  pref medium
fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref medium

But it does feel weird having to do this explicitly for a lower bridge
member (and yes, I'm also slightly surprised about the (fe80::/64
routes for enp2s0 and enp4s0, but this isn't new).

Regards
Stefan Lippers-Hollmann


pgp3AvEFOvkFh.pgp
Description: Digitale Signatur von OpenPGP

Bug#810499: usrmerge: Confuses dpkg-shlibdeps

[Matthias Klumpp]

Hi!
Installing libc6 into /usr/lib solves this issue, as one would expect.
Adding some debug code to dpkg-shlibdeps shows this the issue is - as
expected - shlibdeps calling dpkg-query on the wrong path in /usr
instead of /lib.

I'll create a clean chroot next to see if the issue can be reproduced
there as well, but so far my older Tanglu and Debian Sid chroots all
exhibit this behavior when being usrmerged.
Cheers,
Matthias

Bug#814647: libutempter0: fails to upgrade from 'jessie': chown: cannot access '/usr/lib/utempter': No such file or directory

[Andreas Beckmann]

Package: libutempter0
Version: 1.1.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails.

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

  Setting up libutempter0:amd64 (1.1.6-2) ...
  The utempter system group isn't used anymore by this package
  chown: cannot access '/usr/lib/utempter': No such file or directory
  dpkg: error processing package libutempter0:amd64 (--configure):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for libc-bin (2.21-7) ...
  Processing triggers for systemd (228-6) ...
  Errors were encountered while processing:
   libutempter0:amd64


cheers,

Andreas


libutempter0_1.1.6-2.log.gz
Description: application/gzip

Bug#814641: ITP: sisu-mojos -- Sisu Maven Plugin

[Christopher Hoskin]

Dear Emmanuel,

sisu-maven-plugin has version 1.1. There is a v1.4, after which the project
moved to Eclipse[0] and was renamed sisu mojos:

http://git.eclipse.org/c/sisu/org.eclipse.sisu.mojos.git/

The visioning appears to have been reset, and the current version is now
0.3.2. Because of this, I thought it was best to create a new package with
the new name?

This is a dependency of XMvn - there was some discussion about using XMvn
in Debian on the debian-java list back in November, so I thought I'd take a
look at it.

Please let me know if you think I should be doing something different?

Thanks.

Christopher

[0] https://github.com/sonatype/sisu-maven-plugin/

On 13 February 2016 at 16:55, Emmanuel Bourg  wrote:

> Hi Christopher,
>
> FYI this plugin is already in Debian, see the sisu-maven-plugin package:
>
> https://tracker.debian.org/pkg/sisu-maven-plugin
>
> Emmanuel Bourg
>

Bug#814646: vlc: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE, /usr/share/bug/PACKAGE

[Andreas Beckmann]

Source: vlc
Version: 2.2.2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libvlccore-dev vlc-plugin-fluidsynth vlc-plugin-jack 
vlc-plugin-notify vlc-plugin-samba vlc-plugin-sdl vlc-plugin-svg 
vlc-plugin-zvbi libvlc5 kde-runtime kde-runtime-dbg

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  jessie -> sid
  jessie -> stretch

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

1m58.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/bug/libvlccore-dev/control (libvlccore-dev) != 
/usr/share/bug/libvlccore8/control (libvlccore8)
/usr/share/bug/libvlccore-dev -> libvlccore8
  /usr/share/bug/libvlccore-dev/presubj (libvlccore-dev) != 
/usr/share/bug/libvlccore8/presubj (libvlccore8)
/usr/share/bug/libvlccore-dev -> libvlccore8
  /usr/share/doc/libvlccore-dev/NEWS.Debian.gz (libvlccore-dev) != 
/usr/share/doc/libvlccore8/NEWS.Debian.gz (libvlccore8)
/usr/share/doc/libvlccore-dev -> libvlccore8
  /usr/share/doc/libvlccore-dev/changelog.Debian.amd64.gz (libvlccore-dev) != 
/usr/share/doc/libvlccore8/changelog.Debian.amd64.gz (libvlccore8)
/usr/share/doc/libvlccore-dev -> libvlccore8
  /usr/share/doc/libvlccore-dev/changelog.Debian.gz (libvlccore-dev) != 
/usr/share/doc/libvlccore8/changelog.Debian.gz (libvlccore8)
/usr/share/doc/libvlccore-dev -> libvlccore8
  /usr/share/doc/libvlccore-dev/changelog.gz (libvlccore-dev) != 
/usr/share/doc/libvlccore8/changelog.gz (libvlccore8)
/usr/share/doc/libvlccore-dev -> libvlccore8
  /usr/share/doc/libvlccore-dev/copyright (libvlccore-dev) != 
/usr/share/doc/libvlccore8/copyright (libvlccore8)
/usr/share/doc/libvlccore-dev -> libvlccore8

3m6.6s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/bug/vlc-plugin-fluidsynth/control (vlc-plugin-fluidsynth) != 
/usr/share/bug/vlc-nox/control (vlc-nox)
/usr/share/bug/vlc-plugin-fluidsynth -> vlc-nox
  /usr/share/bug/vlc-plugin-fluidsynth/presubj (vlc-plugin-fluidsynth) != 
/usr/share/bug/vlc-nox/presubj (vlc-nox)
/usr/share/bug/vlc-plugin-fluidsynth -> vlc-nox

(similarily for all the other vlc-plugin-* packages)

2m9.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libvlc5/NEWS.Debian.gz (libvlc5) != 
/usr/share/doc/libvlccore8/NEWS.Debian.gz (libvlccore8)
/usr/share/doc/libvlc5 -> libvlccore8
  /usr/share/doc/libvlc5/changelog.Debian.gz (libvlc5) != 
/usr/share/doc/libvlccore8/changelog.Debian.gz (libvlccore8)
/usr/share/doc/libvlc5 -> libvlccore8
  /usr/share/doc/libvlc5/changelog.gz (libvlc5) != 
/usr/share/doc/libvlccore8/changelog.gz (libvlccore8)
/usr/share/doc/libvlc5 -> libvlccore8
  /usr/share/doc/libvlc5/copyright (libvlc5) != 
/usr/share/doc/libvlccore8/copyright (libvlccore8)
/usr/share/doc/libvlc5 -> libvlccore8



cheers,

Andreas


libvlccore-dev_2.2.2-3+b1.log.gz
Description: application/gzip


vlc-plugin-fluidsynth_2.2.2-3+b1.log.gz
Description: application/gzip

Bug#552374: quassel-core: Please reconsider the 'wontfix' tag as quassel does support PostgreSQL

[Diederik de Haas]

On Saturday 13 February 2016 16:08:40 Felix Geyer wrote:
> The packaged quassel-core already works fine with Postgres when you install
> libqt5sql5-psql and configure it.
> I'll add Suggests: libqt5sql5-psql to quassel-core to make it easier to find.

Awesome, thanks for the info :-)

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

Bug#813223: gcj-native-helper: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Followup-For: Bug #813223
Control: found -1 2:1.8-56

Hi,

the issue is still present in upgrades from testing (2:1.7-52.1) to sid 
(2:1.8-56):

3m30.0s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/gcj-native-helper/changelog.gz (gcj-native-helper) != 
/usr/share/doc/default-jre-headless/changelog.gz (default-jre-headless)
/usr/share/doc/gcj-native-helper -> default-jdk
/usr/share/doc/default-jdk -> default-jre
/usr/share/doc/default-jre -> default-jre-headless
  /usr/share/doc/gcj-native-helper/copyright (gcj-native-helper) != 
/usr/share/doc/default-jre-headless/copyright (default-jre-headless)
/usr/share/doc/gcj-native-helper -> default-jdk
/usr/share/doc/default-jdk -> default-jre
/usr/share/doc/default-jre -> default-jre-headless


Andreas


gcj-native-helper_2:1.8-56.log.gz
Description: application/gzip