Bug#797793: samtools update seems to breaks even more tests

[Andreas Tille]

Hi,

other uploaders of pysam in CC: When building htseq with current pysam
in unstable I get:

...
All 26 tests passed.

Doctest of tss.rst:
**
File "../doc/tss.rst", line 211, in tss.rst
Failed example:
for almnt in sortedbamfile[ window ]:
print almnt   #doctest:+ELLIPSIS +NORMALIZE_WHITESPACE
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
  File "", line 1, in 
for almnt in sortedbamfile[ window ]:
  File "/build/htseq-0.6.1p1/build/lib.linux-x86_64-2.7/HTSeq/__init__.py", 
line 976, in __getitem__
if not self.sf._hasIndex():
AttributeError: 'pysam.csamfile.Samfile' object has no attribute '_hasIndex'
**
File "../doc/tss.rst", line 220, in tss.rst
Failed example:
almnt.iv.length = fragmentsize
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
  File "", line 1, in 
almnt.iv.length = fragmentsize
AttributeError: 'NoneType' object has no attribute 'length'
**
File "../doc/tss.rst", line 221, in tss.rst
Failed example:
almnt
Expected:

Got:


...

NameError: name 'start_in_window' is not defined
**
1 items had failures:
   6 of  37 in tss.rst
***Test Failed*** 6 failures.
6 of 37 tests failed.


Any idea how to fix this.  Htslib upstream is unresponsive even to less
hard issues.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#740912: apt-file: list command produces no output

[Niels Thykier]

Control: tags -1 moreinfo unreproducible

On Sun, 16 Mar 2014 11:52:55 +0100 Niels Thykier  wrote:
> On 2014-03-06 07:46, Daniel Bolton wrote:
> > Package: apt-file
> > Version: 2.5.2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Commands of the format `apt-file list [valid package name]` produce no
> > output and exit with 0. I also tried the -x option (remembering an older
> > bug) with identical results.
> > 
> > 
> > [...]
> 
> Hi,
> 
> Have you run "apt-file update" to ensure that your cache is up to date?
> 
> Regarding the return of exit 0 (on failure), then that is reported as
> #505222.  It is an backwards incompatible change, so I have been
> deferring it for a while.
> 
> FTR, what is the name of the package(s) you have been trying?
> 
> ~Niels
> 

Hi,

We still have not heard from you on this bug and are unable to reproduce
the issue without additional information.

Thanks,
~Niels

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Sebastian Dröge]

On Sa, 2015-12-05 at 16:28 +0100, Soeren D. Schulze wrote:
> Am 12.11.2015 um 15:02 schrieb Sebastian Dröge:
> > On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote:
> > > Hello,
> > > 
> > > the problem does not seem to occur any more with
> > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1.
> > > 
> > > Do you have any specific packages for me to test?
> > 
> > Just a normal jessie installation without installing things from
> > other sources, including sid :) It is definitely fixed since gst-
> > plugins-bad 1.5.X, it's just not clear if the actual bug also
> > exists in jessie or not (and if it doesn't, the fix will also have
> > no effect for people who mix their packages with ones from other
> > sources).
> 
> Hello,
> 
> it is not fixed, alas.  The following SIGSEGV backtrace is with 
> gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1.  Such 
> crashes are rarer, but they do occur:

Hi,

this is a different bug than the stack corruption related to the faad
plugin though. It looks like broken error handling in iceweasel:
https://github.com/mozilla/gecko-dev/blob/GECKO3840esr_2015102720_RELBRANCH/dom/media/gstreamer/GStreamerReader.cpp#L1464

This line here should check if mapping actually succeeds. Apparently it
doesn't (for whatever reason which might be another bug), as in the
next stack frame all field in frame are 0.


Do you have, by any chance, gstreamer1.0-vaapi installed?

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

Bug#798167: camitk: depends on vtk 5

[Andreas Tille]

Hi Emmanuel and Nicolas,

I hope you realised the bug reported in Debian saying:

> your package depends on vtk 5.x, which should not be in stretch.  Please
> switch to vtk 6.x or drop the dependency.

It would be great if you could adapt camitk and release a new version.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#807150: gubbins: FTBFS on i386: Invalid ALN file for multiple lines per seq

[Andreas Tille]

Hi Andrew,

I hereby forward a build issue on i386 architecture.

Kind regards

   Andreas.

On Sat, Dec 05, 2015 at 10:30:32PM -0500, Aaron M. Ucko wrote:
> Source: gubbins
> Version: 1.4.3-1
> Severity: important
> Justification: fails to build from source
> 
> The i386 build of gubbins failed:
> 
>   FAIL: run_all_tests
>   
>   Testsuite summary for gubbins 1.4.3
>   
>   # TOTAL: 1
>   # PASS:  0
>   # SKIP:  0
>   # XFAIL: 0
>   # FAIL:  1
>   # XPASS: 0
>   # ERROR: 0
>   
>   See src/test-suite.log
> 
> I was able to reproduce the error in an i386 chroot, yielding the following
> details:
> 
>   FAIL: run_all_tests
>   ===
>   
>   Running suite(s): Creating_SNP_Sites
>Parsing a phylip file
>Parsing a vcf file
>checking branch sequences
>Checking the gubbins functionality
>snp_searching
>   94%: Checks: 39, Failures: 2, Errors: 0
>   
> ../tests/check_snp_sites.c:73:F:snp_sites:valid_alignment_with_multiple_lines_per_sequence:0:
>  Invalid ALN file for multiple lines per seq
>   ../tests/check_snp_sites.c:85:F:snp_sites:two_sequences:0: Invalid ALN file 
> for multiple lines per seq
>   FAIL run_all_tests (exit status: 1)
> 
> Could you please take a look?
> 
> Thanks!
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#807154: texlive-lang-english: ltx-help.el under emacs site-lisp

[Kevin Ryde]

Package: texlive-lang-english
Version: 2015.20151016-1
Severity: wishlist
Tags: patch
File: /usr/share/doc/texlive-doc/latex/latex2e-help-texinfo/ltx-help.el.gz

It'd be good if ltx-help.el was installed to
/usr/share/emacs/site-lisp/ltx-help.el so that it's ready for use in
emacs.  A symlink to or from the tex directory would be ok, but not
gzipped please as xemacs won't load .el.gz.

Present ltx-help.el has trouble on current latex2e.info but Karl
accepted a fix from me so this will be for the latexrefman svn
ltx-help.el, or next release.

I suggest also file debian/texlive-lang-english.emacsen-startup below
which dh_installemacsen can install to
/etc/emacs/site-start.d/50texlive-lang-english.el giving an autoload for
M-x latex-help.

(None of this creates a dependency on emacs, just makes it ready to use
if you do have emacs.)

;;; 50texlive-lang-english.el -- debian emacs setups for texlive-lang-english

(if (not (file-exists-p "/usr/share/emacs/site-lisp/ltx-help.el"))
(message "texlive-lang-english removed but not purged, skipping setup")

  ;; Per autoload cookie on latex-help in ltx-help.el.
  (autoload 'latex-help "ltx-help"
"Try to find info entry about LaTeX entity CMD." t))


-- System Information:
Debian Release: stretch/sid
Architecture: i386 (i686)

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

Versions of packages texlive-lang-english depends on:
ii  tex-common6.04
ii  texlive-base  2015.20151116-1

texlive-lang-english recommends no packages.

texlive-lang-english suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.18.3
ii  ucf   3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20151126

Versions of packages texlive-lang-english is related to:
ii  tex-common6.04
ii  texlive-binaries  2015.20150524.37493-7

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:

Bug#806532: [Letsencrypt-devel] Bug#806532: FTBFS on jessie

[Francois Marier]

On 2015-11-28 at 15:57:20, Daniel Pocock wrote:
> dh clean --with python2 --buildsystem=pybuild
>dh_testdir -O--buildsystem=pybuild
>dh_auto_clean -O--buildsystem=pybuild
> I: pybuild base:170: python2.7 setup.py clean
> Converting the Git log into ChangeLog format... Traceback (most recent
> call last):
>   File "setup.py", line 39, in run_gitlog_to_changelog
> subprocess.check_call(args, stdout=output)
>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> 
> Error (see above for a traceback): unable to run gitlog-to-changelog
> 
> Maybe this program is not installed on your system. You can download it
> from:
> 
> 
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=build-aux/gitlog-to-changelog
> 
> Note: if you have problems with the infamous shell+Perl crap in the
> first lines
> of that file, you can replace it with a simple shebang line such as
> "#! /usr/bin/perl".
> E: pybuild pybuild:256: clean: plugin distutils failed with: exit
> code=1: python2.7 setup.py clean
> dh_auto_clean: pybuild --clean -i python{version} -p 2.7 --dir .
> returned exit code 13
> debian/rules:9: recipe for target 'clean' failed
> make: *** [clean] Error 13
> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
> status 2

That's weird. I would think that a problem like that would also affect sid.
But looking into it, I was able to build it just fine on jessie without
applying your patch.

Are you sure you're trying this on a clean and up-to-date jessie system?

Francois

-- 
http://fmarier.org/

Bug#783393: initramfs-tools: Missing crypto-components in initramfs when explicitly requested

[Ben Hutchings]

Control: reassign -1 cryptsetup
Control: severity -1 wishlist

On Sun, 26 Apr 2015 19:38:05 +0200 Ondrej Zajicek  
wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: important
> 
> The /usr/sbin/mkinitramfs tool does not propagate CRYPTSETUP option to
> /usr/share/initramfs-tools/hooks/cryptroot, therefore the option does not
> work and in setting which depends on explicit enabling (instead of
> autodetection) of cryptroot the crypto-components are not included in
> initramfs, which leads to unbootable system.
[...]

The CRYPTSETUP variable is an undocumented feature in cryptsetup, and
not the responsibility of initramfs-tools.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#805306: [pkg-bacula-devel] Bug#805306: Would be nice to have a bacula-fd-legacy...

[Anthony DeRobertis]

On 12/05/2015 11:46 AM, Carsten Leonhardt wrote:

Hi,


I confess I don't know how much work it'd be, but it'd be nice to keep
around the older version of the file daemon as a separate package.


if I were to prepare such a package, I'd want to base it on 5.2.13. And
of course I'd want it have all the applicable improvements that the
current packages with version 7.0.5+dfsg-4 have seen. That would mean
reevaluating the ~70 changes I commited in the meantime.

Then I'd have to keep supporting it, probably until 2020 (end of
possible jessie LTS).

I would prefer to prepare packages for 7.x for jessie-backports, which
would solve the problem from another angle.


(sorry if this reads a little funny, I realized I'd buried the important 
bit and just moved it to the top)


If I can find some time (or get the OK to do it at work) to help by 
going through the changes between Jessie and sid, and prepare a 5.2.13 
file daemon only package, would that help? Also, I'd suggest *not* 
supporting it in Stretch-LTS—it's a transitional package to make 
upgrading Bacula easier. The two years of non-LTS Stretch ought to be 
enough time to transition.


(end moved paragraph)

I'm not sure how weird my deployment is, but right now I have at least 
thirty machines and some VMs being backed up by two Bacula directors in 
a disk-to-disk-to-tape config. That, I imagine, puts me on the smaller 
side of "real" deployments. Thankfully it's an entirely open-source 
stack, no weird proprietary software to run, e.g., tape robots. I have 
two machines that run Stretch—a workstation and a test box—maybe will 
gain another VM soon (one which probably won't even be worth backing up, 
as it'll just be a build host).


Those clients run versions of Debian back to, well, way too old (yeah 
for proprietary stuff). We have a bunch on Squeeze LTS and Wheezy. A few 
on Jessie.


All of this works, and has been tested repeatedly. Upgrading to a major 
new version of Bacula is, well, somewhat scary. Especially since the 
director and storage daemon boxes aren't running Jessie.


For now, I've just the reinstalled 5.x file daemon (from Jessie) on the 
Stretch boxes. At home, I'll certainly use the backport once its 
available, but at work... it's very hard to justify risking a 
fully-working, tested backup setup.

Bug#807004: initramfs-tools: Breaks when installing kdump-tools with bcache rootfs

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 03 Dec 2015 17:29:11 -0700 Neil Mayhew  wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: important
> Tags: patch
> 
> I have /dev/bcache0 as my rootfs. When upgrading kdump-tools, the
> postinst fails because /etc/kernel/postinst.d/kdump-tools returns an
> error. When I run this manually, I get:
> 
> kdump-tools: Generating /var/lib/kdump/initrd.img-4.2.0-1-amd64
> mkinitramfs: for device /dev/bcache0 missing bcache /sys/block/ entry
> mkinitramfs: workaround is MODULES=most
> mkinitramfs: Error please report the bug
> 
> The "missing bcache /sys/block/ entry" message comes from
> dep_add_modules_mount in /usr/share/initramfs-tools/hook-functions
> 
> The problem is that the "classical block device" case strips the numeric
> suffix from the device name, but this is needed for the entry in
> /sys/block.
[...]

The code to convert to a whole-disk device name is really not necessary
as both whole-disk and partition devices can be looked up under
/sys/class/block.  I intend to remove it, making the special case for
bcache unnecessary.

However, I don't understand how this is sufficient to support bcache.
We still need to discover the underlying devices of the bcache device,
don't we?

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#807152: dh-python: pybuild enforces https?_proxy even for localhost

[Harlan Lieberman-Berg]

Package: dh-python
Version: 2.20151103
Severity: normal

gDear Maintainer,

First, pybuild is awesome. <3

I found a bug in the handling of http_proxy and https_proxy.  https?_proxy is
set to "localhost:9" to make sure that build processes (and tests) don't make
external requests which would be a violation of policy.

However, localhost is not exempted.  As a result, requests to a local server as
part of testing will likely fail if the https?_proxy arguments are honored.

pybuild should pass the environment variable no_proxy="localhost" to permit
local requests.

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

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

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.3

-- no debconf information
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#795103: freedombox-setup: Patch to count wireless interfaces during network setup

[Sunil Mohan Adapa]

Package: freedombox-setup
Version: 0.6
Followup-For: Bug #795103

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When there is only one wired interface, we always configure it as
'internal' interface.  This happens even when there are wireless
interfaces available.  This patch changes that behavior.  When at least
one wireless interface is available, we will configure the single wired
interface as 'external'.

Currently, during first boot, we don't have this case hitting because of
lack of proprietary-firmware-free wireless interfaces.  However in
future, this is a common case for FreedomBox devices to have one wired
interface and one wireless interface.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWY8BHAAoJEDbDYUQMm8lxzuMP/1nanwVTbZVaxJ41N2JklvME
2bWaZ9s8AOuh0QQPcGsSVGXcIy6VVizoEDjBsrM8h0yITwUqcbwHYgfRxww4/loK
9vdRgqujVQy559ijSaObZsXl1sr9opezDHmtDIfKpfKueJU0bFqaE2A926VYNWeP
Dg7H7bcxxX7F+6v3P55mK23R2KUn5euWdV7/6bv82BaN0dSBTSGWfM4rPHowpRai
tXISw8zFiHdREAB5GMytS+EvMTaIgrsCoyLtRgKQKq2aiR5n2SDhyNCvbrnxhdut
ZwP0Wco+FHN98fVdLHoyq+SMZro/59xL3J0ESAm24cBkGhOaKOi/ZAvprQKBwsMb
Mb6x6SO1A0DemTq21ICKfh/l8AXXUE/OfWm5/5E5kbMPdbj6ejOLNyUEpO5Imc/v
buteoA44KB8q2fRPlfHa/gEkFUPN5f2MuBLjumRuz/z1sGeY4emvgaWk/3WvCNFC
CPixdD+d7MTVXmCtlCA7uzoT6JbjnS3ht9x5+ktJ4JEEKdvamzqzVcZ4HwU5nf5d
NNQFD1gRS99y5/Tf8QXBUo/sGkb8wSdqcjGNW1hsDTHaWKPMAJiqJ1MTQHKpFcfU
hY06Oeu+20HMi/aiRi+M2AommWvPnH5CXLAc+blbkqveuzNlME1/s8B/HsTBpR1F
tU/EbFn+248OsVP9xOsM
=3+kU
-END PGP SIGNATURE-
>From ef62d3090b739908c4a9c013a1808c37516edd31 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Sun, 6 Dec 2015 10:13:47 +0530
Subject: [PATCH] Consider wireless when configuring wired ifaces

When there is only one wired interface, we always configure it as
'internal' interface.  This happens even when there are wireless
interfaces available.  This patch changes that behavior.  When at least
one wireless interface is available, we will configure the single wired
interface as 'external'.

Currently, during first boot, we don't have this case hitting because of
lack of proprietary-firmware-free wireless interfaces.  However in
future, this is a common case for FreedomBox devices to have one wired
interface and one wireless interface.
---
 first-run.d/05_network | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/first-run.d/05_network b/first-run.d/05_network
index 9808715..c9d6162 100755
--- a/first-run.d/05_network
+++ b/first-run.d/05_network
@@ -10,6 +10,7 @@ function get-interfaces {
 NO_OF_WIRED_IFACES=$(echo $WIRED_IFACES | wc -w)
 
 WIRELESS_IFACES=$(nmcli --terse --fields type,device device | grep "^wifi:" | cut -d: -f2 | sort)
+NO_OF_WIRELESS_IFACES=$(echo $WIRELESS_IFACES | wc -w)
 }
 
 function configure-regular-interface {
@@ -77,7 +78,15 @@ function multi-wired-setup {
 
 function one-wired-setup {
 interface="$1"
-configure-regular-interface "$interface" internal
+
+case $NO_OF_WIRELESS_IFACES in
+"0")
+configure-regular-interface "$interface" internal
+;;
+*)
+configure-regular-interface "$interface" external
+;;
+esac
 }
 
 function wireless-setup {
-- 
2.6.1

Bug#793027: Missing QuoVadis "G3" Root CAs (in Wheezy)

[Michael Shuler]

Control: tags -1 + pending

I'm preparing uploads for stable/oldstable proposed-updates, so
Wheezy/Jessie will get the current Mozilla CA bundle v2.5, which
includes the referenced QuoVadis certs.

http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/log/?h=debian-wheezy

-- 
Kind regards,
Michael

Bug#807151: ninja-build: ninja-mode.el buffer local comment-start

[Kevin Ryde]

Package: ninja-build
Version: 1.5.1-0.1
Severity: normal
Tags: patch
File: /usr/share/emacs/site-lisp/ninja-mode.el

ninja-mode.el has

(setq comment-start "#")

which sets the comment-start string globally (affecting all buffers
without their own setting).  A major mode usually should be buffer-local

(set (make-local-variable 'comment-start) "#")


-- System Information:
Debian Release: stretch/sid
Architecture: i386 (i686)

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

Versions of packages ninja-build depends on:
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-27
ii  libstdc++6  5.2.1-27

ninja-build recommends no packages.

ninja-build suggests no packages.

-- no debconf information

Bug#791352: [PATCH] Added tracefs (Debian bug 791352)

[Francois Marier]

---
 systems/Linux/2/gen_mounts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/systems/Linux/2/gen_mounts b/systems/Linux/2/gen_mounts
index dd5efdf..4f8a1df 100755
--- a/systems/Linux/2/gen_mounts
+++ b/systems/Linux/2/gen_mounts
@@ -69,6 +69,7 @@
 # Linux/2/gen_mounts - 22/11/2015 - Fix typo in sshfs definition (Debian bug 
7680867)
 # - Added aufs (Debian bug 781171)
 # - Added fuse.s3fs (Debian bug 799753)
+# Linux/2/gen_mounts - 05/12/2015 - Added tracefs (Debian bug 791352)
 
#--
 #
 
@@ -210,6 +211,7 @@ localfs()
   [ "$1" = "vmblock" ] && LOCAL=1   # Vmware filesystem
   [ "$1" = "debugfs" ] && LOCAL=1   # Debugging filesystem see 
 # 
http://lwn.net/Articles/115405/
+  [ "$1" = "tracefs" ] && LOCAL=1
   [ "$1" = "configfs" ] && LOCAL=1
   [ "$1" = "davfs" ] && LOCAL=1
   [ "$1" = "pstore" ] && LOCAL=1# Platform dependen persisten 
storage
-- 
2.6.2

Bug#779618: dash: printf doesn't handle malformed format string

[Gioele Barabucci]

Control: tags -1 - moreinfo

Sorry for the noise, I misunderstood the bug report. The format
specification is wrong and your proposed patch would make the dash
recognize it as such.

Regards,

-- 
Gioele Barabucci 

Bug#807150: gubbins: FTBFS on i386: Invalid ALN file for multiple lines per seq

[Aaron M. Ucko]

Source: gubbins
Version: 1.4.3-1
Severity: important
Justification: fails to build from source

The i386 build of gubbins failed:

  FAIL: run_all_tests
  
  Testsuite summary for gubbins 1.4.3
  
  # TOTAL: 1
  # PASS:  0
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  1
  # XPASS: 0
  # ERROR: 0
  
  See src/test-suite.log

I was able to reproduce the error in an i386 chroot, yielding the following
details:

  FAIL: run_all_tests
  ===
  
  Running suite(s): Creating_SNP_Sites
   Parsing a phylip file
   Parsing a vcf file
   checking branch sequences
   Checking the gubbins functionality
   snp_searching
  94%: Checks: 39, Failures: 2, Errors: 0
  
../tests/check_snp_sites.c:73:F:snp_sites:valid_alignment_with_multiple_lines_per_sequence:0:
 Invalid ALN file for multiple lines per seq
  ../tests/check_snp_sites.c:85:F:snp_sites:two_sequences:0: Invalid ALN file 
for multiple lines per seq
  FAIL run_all_tests (exit status: 1)

Could you please take a look?

Thanks!

Bug#795091: More info

[Michael Myers]

mrm@hilbert:~$ raco pkg install frog
Resolving "frog" via http://download.racket-lang.org/releases/6.2/catalog/
Resolving "frog" via http://pkgs.racket-lang.org
Downloading
https://github.com/greghendershott/frog/tarball/9812ed29d7194f71aaa7b0c655ab3e262248244e
The following uninstalled packages are listed as dependencies of frog:
   find-parent-dir
   markdown
   rackjure
Would you like to install these dependencies? [Y/n/a/c/?] Y
Resolving "find-parent-dir" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "find-parent-dir" via http://pkgs.racket-lang.org
Resolving "markdown" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "markdown" via http://pkgs.racket-lang.org
Resolving "rackjure" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "rackjure" via http://pkgs.racket-lang.org
Downloading
https://github.com/samth/find-parent-dir/tarball/e78d0277447d81934847166e8024edc5adea4b1c
Downloading
https://github.com/greghendershott/markdown/tarball/4bb2d152d580d71348f4837d30bf01bdbc347415
Downloading
https://github.com/greghendershott/rackjure/tarball/948557c44dd93136e4172c40fda4e4120c9b656d
The following uninstalled packages are listed as dependencies of markdown:
   parsack
   sexp-diff
Would you like to install these dependencies? [Y/n/a/c/?] Y
Resolving "parsack" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "parsack" via http://pkgs.racket-lang.org
Resolving "sexp-diff" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "sexp-diff" via http://pkgs.racket-lang.org
Downloading
https://github.com/stchang/parsack/tarball/b45f0f5ed5f8dd3f1ccebaaec3204b27032843c6
Downloading
https://github.com/stamourv/sexp-diff/tarball/5b5034c7e6b930002870877e8e1eb1e6d69ae0b4
The following uninstalled packages are listed as dependencies of rackjure:
   threading
Would you like to install these dependencies? [Y/n/a/c/?] Y
Resolving "threading" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "threading" via http://pkgs.racket-lang.org
Downloading
https://github.com/lexi-lambda/threading/tarball/e51278992ce3433be29156615bdf3fabc4975bea
The following uninstalled packages are listed as dependencies of threading:
   cover
   cover-coveralls
Would you like to install these dependencies? [Y/n/a/c/?] Y
Resolving "cover" via http://download.racket-lang.org/releases/6.2/catalog/
Resolving "cover" via http://pkgs.racket-lang.org
Resolving "cover-coveralls" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "cover-coveralls" via http://pkgs.racket-lang.org
Downloading
https://github.com/florence/cover/tarball/b54f664bd1e2a9f42878b6f7812110e49cb58e08
Downloading
https://github.com/rpless/cover-coveralls/tarball/e539c553c594dd957672140b37b168a2ab9c7a9d
The following uninstalled packages are listed as dependencies of cover:
   custom-load
Would you like to install these dependencies? [Y/n/a/c/?] Y
Resolving "custom-load" via
http://download.racket-lang.org/releases/6.2/catalog/
Resolving "custom-load" via http://pkgs.racket-lang.org
Downloading
https://github.com/rmculpepper/custom-load/tarball/97e19b38d0a738aa66a131b259d67c8474edea2d
The following uninstalled packages were listed as dependencies
and they were installed:
 dependencies of frog:
   find-parent-dir
   markdown
   rackjure
 dependencies of markdown:
   parsack
   sexp-diff
 dependencies of rackjure:
   threading
 dependencies of threading:
   cover
   cover-coveralls
 dependencies of cover:
   custom-load
raco setup: version: 6.2 [3m]
raco setup: installation name: 6.2
raco setup: variants: 3m
raco setup: main collects: /usr/share/racket/collects
raco setup: collects paths:
raco setup:   /home/mrm/.racket/6.2/collects
raco setup:   /usr/share/racket/collects
raco setup: main pkgs: /usr/share/racket/pkgs
raco setup: pkgs paths:
raco setup:   /usr/share/racket/pkgs
raco setup:   /home/mrm/.racket/6.2/pkgs
raco setup: links files:
raco setup:   /usr/share/racket/links.rktd
raco setup:   /home/mrm/.racket/6.2/links.rktd
raco setup: main docs: /usr/share/doc/racket
raco setup: --- updating info-domain tables ---
raco setup: updating: /home/mrm/.racket/6.2/share/info-cache.rktd
raco setup: --- pre-installing collections ---
raco setup: --- installing foreign libraries ---
raco setup: --- installing shared files ---
raco setup: --- compiling collections ---
raco setup: --- parallel build using 4 jobs ---
raco setup: 3 making: /cover-coveralls/cover
raco setup: 2 making: /cover/cover
raco setup: 1 making: /custom-load (custom-load)
raco setup: 0 making: /find-parent-dir/find-parent-dir
raco setup: 1 making: /custom-load/private
raco setup: 0 making: /frog/example
raco setup: 0 making: /frog/example/_src
raco setup: 0 making: /frog/example/_src/posts
raco setup: 0 making: /frog/example/_src/subdir
raco setup: 0 making: /frog/example/css
raco setup: 0 making: /frog/example/fonts
raco setup: 0 making: /frog/example/img
raco setup: 0 making: /frog/example/js
raco s

Bug#807149: infinipath-psm: FTBFS: Unsupported architecture i686

[Aaron M. Ucko]

Source: infinipath-psm
Version: 3.3+7.g05f6f14.open-1
Severity: important
Justification: fails to build from source

infinipath-psm's debian/control file claims

Architecture: amd64 i386

but the i386 build fails:

make[1]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
/usr/bin/make INSTALL_PREFIX=/usr libdir=/usr/lib/i386-linux-gnu 
PSM_HAVE_SCIF=0 USE_PSM_UUID=0 arch=i686  distclean
make[2]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
Makefile:97: *** Unsupported architecture i686.  Stop.

Please address this discrepancy one way or another.

Thanks!

Bug#783410: Please add support for fsck.mode= parameters as known by systemd-fsck

[Ben Hutchings]

On Sun, 15 Nov 2015 10:09:34 +0100 Laurent Bigonville  wrote:
[...]
> Please find a patch that should fix this bug (not tested). The patch 
> also fixes #792557.

Thanks, but again please add the Developer's Certificate of Origin.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#807148: glx-diversions: ffmpeg looks for libGL.so.1 while glx-diversions offers only libGL.so

[Xinyue Lu]

Package: glx-diversions
Version: 0.7.1
Severity: important

Dear Maintainer,


I've noticed that my ffmpeg doesn't work and reporting missing shared
library libGL.so.1.

The libgl1-mesa-glx is correctly installed, but the files libGL.so.1
does not appear in the right place.

I believe libGL.so.1 is included in the package above, but somehow
it's moved by another package.

So I start removing packages by guessing, and when I removed
glx-diversions (and it's dependencies), the files went back.

When the shared library went back, I can use ffmpeg without any problems.

I'd expect to have not only libGL.so linked to the correct version,
but also libGL.so.1, etc. At least this should not break other
packages such as ffmpeg.

Reproduce steps: (best effort guess)

1. Install `glx-diversions` and `ffmpeg` with apt
2. Execute `ffmpeg`
3. Read `ffmpeg: error while loading shared libraries: libGL.so.1:
cannot open shared object file: No such file or directory`


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

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

Bug#807147: RM: starpu-contrib [i386] -- ROM; CUBLAS/CUDA gone in i386

[Scott Kitterman]

On December 5, 2015 8:55:39 PM EST, Samuel Thibault  
wrote:
>Package: ftp.debian.org
>Severity: normal
>
>Hello,
>
>CUBLAS is no more in i386, and CUDA will be gone in newer versions.  As
>a consequence, please remove starpu-contrib on i386. eztrace-contrib
>and
>hwloc-contrib should be removed on i386 too, should I submit other bugs
>for them?

Yes.  One bug per package please.

Scott K

Bug#806239: Updating ca-certificates through stable-updates

[Michael Shuler]

On 12/05/2015 04:25 PM, Philipp Kern wrote:
>> Could I perhaps convince you to file this (kind of) request as a pu bug?
>>  They are much easier for us to track than mails to the mailing list.
>>   I appreciate that you might have been sending this mail to avoid the
>> pu-bug.  Unfortunately, we often end up forgetting the mail on our TODO
>> list if it is not listed in the bug tracker.
> 
> There's that and it helps to look at the debdiff to see what the actual
> changes are. Cert updates are likely to be much easier on us than
> packaging/script updates.

I'll go ahead and get the packages built and open up a pu bug with the
debdiffs. Thanks!

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#602331: plymouth does not allow to enter maintenance shell

[Ben Hutchings]

On Sun, 15 Nov 2015 13:12:07 +0100 Laurent Bigonville  wrote:
[...]
> I think we could split that in two different issues, I've cloned this 
> bug, see: #805155
> 
> The attached patch is calling the new "panic" scripts just before 
> dropping to a shell, this can be then used by plymouth package to ensure 
> the plymouth daemon is killed/the splash hidden

Looks good, but could you re-send with a Developer's Certificate of
Origin (Signed-off-by line)?

Ben.
 
-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#807145: unmatched ) on cs2cs man page

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending

Hi Dan,

Thanks for the patch, I've applied in in git and forwarded it upstream.
It will be included in the next upload.

Kind Regards,

Bas

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

Bug#807097: [Python-modules-team] Bug#807097: python-django: Undeclared removal of previously supported features causes crashes

[Brian May]

Raphael Hertzog  writes:

> This one is actually documented, add_to_builtins has never been a public
> API.
>
> https://docs.djangoproject.com/en/1.9/releases/1.9/#django-template-base-add-to-builtins-is-removed

I thought this was removed in Django 1.8 - I remember as it caused me
significant problems at the time.

In my commit message from April I reference the following upstream bug:
https://code.djangoproject.com/ticket/17085

So I don't think you can blame this one on Django 1.9.
-- 
Brian May 

Bug#807146: ITP: koji -- RPM-based build system

[Marek Marczykowski-Górecki]

On Sun, Dec 06, 2015 at 01:59:07AM +, Mattia Rizzolo wrote:
> this package already has an ITP, it's already packaged and already
> sitting in the NEW queue [1].
> The funny part is that the work on it has been done during the
> reproducible summit the last week :)
> 
> And even more interesting, is that your name is on the d/changelog and
> in several git commits!! ;)

Yes, had problems with reportbug tool before (it tries to download all
(?) bugs status in one HTTP request and gets HTTP 500...) and haven't
noticed that Ximin already done that. 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


pgpywHvq9kIrq.pgp
Description: PGP signature

Bug#807146: ITP: koji -- RPM-based build system

[James McCoy]

On Sun, Dec 06, 2015 at 02:42:09AM +0100, Marek Marczykowski-Górecki wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Marek Marczykowski-Górecki" 
> 
> * Package name: koji
>   Version : 1.10.0

Ximin filed an ITP (#806953) a few days ago.

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

Bug#807146: ITP: koji -- RPM-based build system

[Mattia Rizzolo]

control: merge 806953 -1

On Sun, Dec 06, 2015 at 02:42:09AM +0100, Marek Marczykowski-Górecki wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Marek Marczykowski-Górecki" 
> 
> * Package name: koji
>   Version : 1.10.0
>   Upstream Author : Mike McLean ,
> Dennis Gregorovic ,
> Mike Bonnet ,
> Jesse Keating 
> * URL : https://fedorahosted.org/koji/
> * License : LGPL
>   Programming Lang: Python
>   Description : RPM-based build system
> 
> The Fedora Project uses Koji for their build system, as do several other
> projects.
> 
> Koji's goal is to provide a flexible, secure, and reproducible way to build
> software.
> 
> Key features:
> 
> The package required to plug Fedora packages into reproducible build testing
> infrastructure.

this package already has an ITP, it's already packaged and already
sitting in the NEW queue [1].
The funny part is that the work on it has been done during the
reproducible summit the last week :)

And even more interesting, is that your name is on the d/changelog and
in several git commits!! ;)

[1] https://ftp-master.debian.org/new/koji_1.10.0-1.html

-- 
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#807147: RM: starpu-contrib [i386] -- ROM; CUBLAS/CUDA gone in i386

[Samuel Thibault]

Package: ftp.debian.org
Severity: normal

Hello,

CUBLAS is no more in i386, and CUDA will be gone in newer versions.  As
a consequence, please remove starpu-contrib on i386. eztrace-contrib and
hwloc-contrib should be removed on i386 too, should I submit other bugs
for them?

Thanks,
Samuel

Bug#503840: ash: "." not recognising "--" as the end-of-options

[Gioele Barabucci]

Control: tags -1 patch fixed-upstream

This problem is solved by the patch proposed in message #34. That patch
has been applied upstream in the commit
12ad48bb31b003eb6d3106478b7760a031969a36.

The fix is available on the git repo but it is not part of dash 0.5.8,
the latest upstream release.

Regards,

-- 
Gioele Barabucci 

Bug#807146: ITP: koji -- RPM-based build system

[Marek Marczykowski-Górecki]

Package: wnpp
Severity: wishlist
Owner: "Marek Marczykowski-Górecki" 

* Package name: koji
  Version : 1.10.0
  Upstream Author : Mike McLean ,
Dennis Gregorovic ,
Mike Bonnet ,
Jesse Keating 
* URL : https://fedorahosted.org/koji/
* License : LGPL
  Programming Lang: Python
  Description : RPM-based build system

The Fedora Project uses Koji for their build system, as do several other
projects.

Koji's goal is to provide a flexible, secure, and reproducible way to build
software.

Key features:
 -  New buildroot for each build
 -  Robust XML-RPC APIs for easy integration with other tools
 -  Web interface with SSL and Kerberos authentication
 -  Thin, portable command line client
 -  Users can create local buildroots
 -  Buildroot contents are tracked in the database
 -  Versioned data

The package required to plug Fedora packages into reproducible build testing
infrastructure.

Bug#807145: unmatched ) on cs2cs man page

[積丹尼 Dan Jacobson]

--- cs2cs.1 2015-12-06 09:34:47.187366246 +0800
+++ cs2cs.1.NEW 2015-12-06 09:38:07.938903684 +0800
@@ -116,7 +116,7 @@
 .B +args
 run-line arguments are associated with cartographic parameters
 and usage varies with projection and for a complete description see
-.I "Cartographic Projection Procedures for the UNIX Environment\(emA User's 
Manual" )
+.I "Cartographic Projection Procedures for the UNIX Environment\(emA User's 
Manual"
 and supplementary documentation for Release 4.
 .PP
 The \fIcs2cs\fR program requires two coordinate system definitions.  The

Bug#755632: [Python-modules-team] Bug#807101: python-django-voting: Too loose dependency on python-django

[Brian May]

Valentin Lorentz  writes:

> python-django-voting 0.2-1 (the current version in Sid) is not
> compatible with python-django 1.9-1 (the current version in Sid), but
> the dependency specification does not mention this incompatibility: it
> only requires: “python-django (>= 1.0)”.

This is somewhat a confusing report. python-django-voting in unstable
must be compatible with the python-django in unstable or it will not be
installable. Changing the depends to disallow it being installed with
Django 1.9 is not going to magically mean that the package is not
broken.

There is already a serious bug report against python-django-voting, for
Django 1.7 compatability. See #755632

Unfortunately it seems nobody in the python-modules-team is currently
interested in fixing it. I also note that upstream hasn't had a release
since 2012 either. So maybe the package should get dropped from
unstable?

As there is already a bug report that covers the issues on this package,
I will close #807101.

Regards
-- 
Brian May 

Bug#807145: unmatched ) on cs2cs man page

[Sebastiaan Couwenberg]

On 05-12-15 23:27, 積丹尼 Dan Jacobson wrote:
> Unmatched ):

Can you send a patch for this and the other instances?

Kind Regards,

Bas

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

Bug#807076: I accept the final solution, but then it doesn't install anything

[積丹尼 Dan Jacobson]

> "MAFM" == Manuel A Fernandez Montecelo  
> writes:

MAFM> dependencies, it decides to not install python-samba either.  It does a
MAFM> suboptimal job at communicating this, though.

Yes it should at least say "oops, I can't do that either, sorry I didn't
figure it out before presenting it to you as an option."

Bug#379227: dash: echo truncates at \0

[Gioele Barabucci]

Control: tags -1 fixed-upstream

This problem is solved by the patch proposed in message #25. That patch
has been applied upstream in the commit
d6c0e1e2ffbf7913ab69d51cc794d48d41c8fcb1.

The fix is not part of dash 0.5.8, the latest upstream release.

Regards,

-- 
Gioele Barabucci 

Bug#806773: RFS: normaliz/3.0.0+ds-3 [FTBFS fix]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mattia:

On 06/12/15 01:13, Mattia Rizzolo wrote:
> Control: owner -1 !
> Control: tags -1 + moreinfo
> 
> On Tue, Dec 01, 2015 at 06:06:01AM +0100, Jerome Benoit wrote:
>> I am looking for a sponsor for the package normaliz [1] that
>> I am maintaining on behalf of the Debian Science-Team.
> 
> I'll happily sponsor it, but before that, is there a reason you're not
> asking this to the debian-sciance team? (of which I'm part of)

No reason at all, or clumsyness if any: I post something here:

https://wiki.debian.org/DebianPureBlends/SoB

> 
>> [1] https://anonscm.debian.org/cgit/debian-science/packages/normaliz.git
> 
> The commits on that repository looks weird: almost like you do the work,
> build a .dsc, and then import it to the git repo :S

Let say that I am getting more and more familiar with the packaging process
which is not that complex but ask time to get a good overwhole picture and 
practice.
May be my habit to use quilt is becoming obsolete.

Having said that, I hope that my packages are not that bad.

Jerome
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWY4OQAAoJEIC/w4IMSybjY5IH/3oq/9rmDft01UqiMNP0xm2f
vn2Yqx0cr52oBlZ/ybDtOJZEi0/TwPChJUscz1li5PZ+reym1CFDqLyow/1x+FhH
af7gMNSNwd1FxAocyzSufLGwhO08KMs0/j1lTzudaxyHaZ7Y4ohr0jtRv70dt8k6
yF9DjxtwUi6xGrkuDR42ymJLPh5xkHsSf5EXoqw01d4fBjFhufuhZm9LEu0Pj6BC
My4XnnLcGUUY5A+333XHgnQ94gXd+AMCjLBT9XSMDP5iho77ShARD8F+8l624bTk
2zYyimZyB17l8PM6Rl95ihOl0ICdMxf7TQQDz07u2diDofC8Tz9zcAM5tqLk/Ac=
=ed75
-END PGP SIGNATURE-

Bug#807128: gcc-5-base: Differing changelog.Debian.gz between :i386 and :amd64

[James McCoy]

On Sat, Dec 05, 2015 at 08:37:15PM +0100, Matthias Klose wrote:
> no binNMU please.

Why?  Are you planning to do a sourceful upload?  If not, that would
resolve the installability issues that people are going to encounter.

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

Bug#807076: I accept the final solution, but then it doesn't install anything

[Manuel A. Fernandez Montecelo]

Hi,

2015-12-05 00:25 積丹尼 Dan Jacobson:

Package: aptitude
Version: 0.7.4-2
File: /usr/bin/aptitude-curses

I accept the final solution, but then it doesn't install anything.

# aptitude full-upgrade
The following NEW packages will be installed:
 libhdb9-heimdal{a} (D: samba)  python-crypto{a} (D: python-samba)
 python-dnspython{a} (D: samba)  python-ldb{a} (D: python-samba)
 python-ntdb{a} (D: python-samba, D: samba)
 python-samba{a} (D: samba, D: samba-common-bin)
 python-tdb{a} (D: python-samba)
 samba{a} (D: python-samba, D: samba-common-bin, D: samba-libs)
 samba-common{a} (D: samba, D: samba-common-bin)
 samba-common-bin{a} (D: samba, R: samba-common)
 samba-dsdb-modules{a} (D: samba)  tdb-tools{a} (D: samba)
The following packages will be upgraded:
 libsmbclient  samba-libs{b} (D: libldb1)  xserver-xorg-core
The following packages are RECOMMENDED but will NOT be installed:
 attr (R: samba)  samba-vfs-modules (R: samba)
The following packages are SUGGESTED but will NOT be installed:
 bind9 (S: samba)  bind9utils (S: samba)  ctdb (S: samba)
 heimdal-clients (S: samba-common-bin)  ldb-tools (S: samba)
 python-crypto-dbg (S: python-crypto)
 python-crypto-doc (S: python-crypto)  smbldap-tools (S: samba)
 winbind (S: samba)
3 packages upgraded, 12 newly installed, 0 to remove and 3 not upgraded.
Need to get 12.7 MB/12.9 MB of archives. After unpacking 29.6 MB will be used.
The following packages have unmet dependencies:
samba-libs : Depends: libldb1 (< 2:1.1.22~) but 2:1.1.23-1 is installed.
xserver-xorg-video-vesa : Depends: xorg-video-abi-19 which is a virtual 
package, provided by:
- xserver-xorg-core, but 2:1.18.0-1 is to 
be installed.
xserver-xorg-video-fbdev : Depends: xorg-video-abi-19 which is a virtual 
package, provided by:
 - xserver-xorg-core, but 2:1.18.0-1 is to 
be installed.
xserver-xorg-input-synaptics : Depends: xorg-input-abi-21 which is a virtual 
package, provided by:
 - xserver-xorg-core, but 2:1.18.0-1 is 
to be installed.
xserver-xorg-input-mouse : Depends: xorg-input-abi-21 which is a virtual 
package, provided by:
 - xserver-xorg-core, but 2:1.18.0-1 is to 
be installed.
xserver-xorg-video-intel : Depends: xorg-video-abi-19 which is a virtual 
package, provided by:
 - xserver-xorg-core, but 2:1.18.0-1 is to 
be installed.
xserver-xorg-input-evdev : Depends: xorg-input-abi-21 which is a virtual 
package, provided by:
 - xserver-xorg-core, but 2:1.18.0-1 is to 
be installed.
xserver-xorg-input-kbd : Depends: xorg-input-abi-21 which is a virtual package, 
provided by:
   - xserver-xorg-core, but 2:1.18.0-1 is to be 
installed.
The following actions will resolve these dependencies:
[...]
The following actions will resolve these dependencies:

Install the following packages:
1) python-samba [2:4.1.21+dfsg-2+b2 (unstable)]

Keep the following packages at their current version:
2) libsmbclient [2:4.1.21+dfsg-2+b2 (now, unstable)]
3) samba [Not Installed]
4) samba-common-bin [Not Installed]
5) samba-dsdb-modules [Not Installed]
6) samba-libs [2:4.1.21+dfsg-2+b2 (now, unstable)]
7) xserver-xorg-core [2:1.17.3-2 (now, unstable)]



Accept this solution? [Y/n/q/?] Y
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

Current status: 0 (+0) broken, 6 (+0) upgradable, 49948 (+0) new.


I suppose that this is because:

 python-samba{a} (D: samba, D: samba-common-bin)

and since it's not going to install samba nor samba-common-bin in the
end, and python-samba is only automatically installed and has no
dependencies, it decides to not install python-samba either.  It does a
suboptimal job at communicating this, though.


More in general, I suppose that for the full-upgrade to work, libldb1
would have to be downgraded (if possible at all with the current state
of the repositories.  Maybe if you continued asking for solutions it
would reach that one eventually?

 samba-libs : Depends: libldb1 (< 2:1.1.22~) but 2:1.1.23-1 is installed.

I guess that the situation is similar with the xorg stuff, they are
trying to be installed with incompatible versions.

xserver-xorg-core from experimental provides the virtual packages
xorg-input-abi-20 and -22, but not -19/-21 which is what packages like
xserver-xorg-input-mouse need (-21 in this case).  I am not sure why
there are no versions of the packages in experimental depending on that
version, perhaps the maintainers intend to upload them in the near
future, or perhaps xserver-xorg-core was uploaded as an experiment for
other purposes.

Since you have default release experimental (according to the
attachment), or pinned to that effect, it

Bug#807142: jessie-pu: package linux-tools/3.16.7-ckt20-1

[Ben Hutchings]

On Sat, 2015-12-05 at 23:27 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2015-12-05 at 22:47 +, Ben Hutchings wrote:
> > This version of linux-tools adds a new binary package (hyperv-daemons)
> > containing programs built from the previously-unused tools/hv
> > directory.  This will improve support for running Debian as a Hyper-V
> > guest.  Many upstream bug fixes to these programs are applied as
> > patches.
> > 
> > It also includes some bug fixes to the perf tool and the module
> > building tools from the 3.16-ckt stable branch. as listed in the
> > changelog.
> 
> Thanks for the formal report for this.
> 
> For the record, this is currently in NEW, waiting for ftp-master to
> process it. (It was originally held at our request while we reviewed the
> diff, but I indicated on IRC that I was happy for it to be processed a
> few days ago.)

I missed that.  Thanks for reviewing.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#806945: Installation of PDF/PS/DVI and HTML files

[Chet Ramey]

On 12/4/15 4:24 AM, Ludovic Courtès wrote:
> Greg Wooledge  skribis:
> 
>> On Thu, Dec 03, 2015 at 01:08:13PM +0200, Ludovic Courtès wrote:
>>> Given that the GCS suggests installing only the Info version of the
>>> manual by default (info "(standards) Standard Targets")
>>
>>> What do you think?
>>
>> I think that's a stupid suggestion.  The de facto standard for "make"
>> followed "make install" on a Unix-like system is to install man pages.
>> If there's an info page, I have no objection to installing that as well,
>> but to omit the standard man pages by default is ridiculous.
> 
> Agreed; apologies for being unclear.
> 
> As Mathieu wrote, I am of course fine installing man and Info manuals by
> default, like GNU packages generally do.
> 
> The suggestion I make is to not install PDF/PS/DVI and HTML files by
> default.  

Again, only the HTML files are installed by `make install'.  The sticking
point here appears to be installing the HTML files, which you can suppress
by running `make install' with htmldir set to the empty string.  Is that
what you're saying?

> This would comply with the GCS and user expectations, and also
> sidestep the bit-for-bit reproducibility issues that generating those
> PDF/PS/DVI/HTML files entails.

So the problem is once again the build and not the install?  Since the
build version appears in the version string, and that changes each time
the binary is rebuilt, bit-by-bit reproducibility is not going to be
generally possible.

However, if it's the build, if something changes when you run make, it
implies that one of the source files changed or that the target did not
exist.  bash-4.4, unlike bash-4.3, will ship with the generated
documentation (look at the bash-4.4-beta distribution, for example).
Given that, under what circumstances would the generated documentation
need to be rebuilt by this `reproducible builds' effort?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bug#806773: RFS: normaliz/3.0.0+ds-3 [FTBFS fix]

[Mattia Rizzolo]

Control: owner -1 !
Control: tags -1 + moreinfo

On Tue, Dec 01, 2015 at 06:06:01AM +0100, Jerome Benoit wrote:
> I am looking for a sponsor for the package normaliz [1] that
> I am maintaining on behalf of the Debian Science-Team.

I'll happily sponsor it, but before that, is there a reason you're not
asking this to the debian-sciance team? (of which I'm part of)

> [1] https://anonscm.debian.org/cgit/debian-science/packages/normaliz.git

The commits on that repository looks weird: almost like you do the work,
build a .dsc, and then import it to the git repo :S

-- 
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#807145: unmatched ) on cs2cs man page

[積丹尼 Dan Jacobson]

Package: proj-bin
Version: 4.9.2-1
Severity: minor
File: /usr/share/man/man1/cs2cs.1.gz

Unmatched ):

   The +args run-line arguments are associated with  cartographic  parame-
   ters  and  usage  varies with projection and for a complete description
   see Cartographic Projection  Procedures  for  the  UNIX  Environment--A
   User's Manual ) and supplementary documentation for Release 4.

Bug#806595: aptitude: Changelog download throws warning: "W: Can't drop privileges for downloading as file '/tmp/aptitude-root.15442:qGi6mn/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA' couldn't b

[Manuel A. Fernandez Montecelo]

Hi,

2015-11-29 13:29 Axel Beckert:

Package: aptitude
Version: 0.7.4-2

Hi,

on the commandline as well in the TUI, aptitude throws a warning when
trying to download and display a changelog as root as well as user:

As root:

# aptitude changelog apt > /dev/null
W: Can't drop privileges for downloading as file 
'/tmp/aptitude-root.15442:qGi6mn/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA'
 couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
#


That's because libapt attempts to drop privileges and perform operations
as "_apt" user, but since the directory is owned by root, it cannot drop
them (otherwise it would fail to write) and emits the warning.

So


As user:

% aptitude changelog apt > /dev/null
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
W: chmod 0700 of directory /var/cache/apt/archives/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)


I suppose that as normal user, libapt doesn't do the check mentioned
above (perhaps because uid!=root and assumes that it's "_apt").

In my system, both dirs' permissions are 700 and owned by _apt:root, it
doesn't emit any error and changelog works fine, no warnings.



It is though able to display the changelog in all cases I tested.


Yes, specially in the case of root it shouldn't stop from actually
showing the changelog.  It's just a warning that will not drop the
privileges, to avoid failing with the operation.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807142: jessie-pu: package linux-tools/3.16.7-ckt20-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2015-12-05 at 22:47 +, Ben Hutchings wrote:
> This version of linux-tools adds a new binary package (hyperv-daemons)
> containing programs built from the previously-unused tools/hv
> directory.  This will improve support for running Debian as a Hyper-V
> guest.  Many upstream bug fixes to these programs are applied as
> patches.
> 
> It also includes some bug fixes to the perf tool and the module
> building tools from the 3.16-ckt stable branch. as listed in the
> changelog.

Thanks for the formal report for this.

For the record, this is currently in NEW, waiting for ftp-master to
process it. (It was originally held at our request while we reviewed the
diff, but I indicated on IRC that I was happy for it to be processed a
few days ago.)

Regards,

Adam

Bug#807144: Undeclared dependency to `debianutils (which)' in apt-key

[Mingye Wang (Arthur2e5)]

Package: apt
Version: 1.1.3

In apt's `apt-key` script (cmdline/apt-key.in), there are multiple calls
to the external program `which`, which is often supplied by the
`debianutils` package on Debianish systems.

However, apt's control file (debian/control) doesn't claim it to be
dependent on the package. `apt remove debianutils` also doesn't prepare
to remove `apt`, so there aren't any indirect dependencies either.

A fast check on the script itself indicates that all `which` calls are
used to determine the existence of certain commands like gpg, gpg2 and
wget, and the output is discarded. Therefore, replacing all those
`which` with `type` (XSI) or `command -v` (POSIX) is perfectly fine and
dash-compatible. This also gives a trivial performance boost due to
reduced calls to external programs.

-- 
Regards,

Arthur2e5 (0x222D7BDA)



signature.asc
Description: OpenPGP digital signature

Bug#589644: bwbar overflows with some GBit/sec

[Carsten Otto]

Hi,

there hasn't been any update to this bug and bwbar in general in the
past five years. Julien, could you please comment on this?

Best regards,
-- 
Dr. Carsten Otto
http://verify.rwth-aachen.de/otto/


signature.asc
Description: Digital signature

Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Carl Myers]

I got my system working.  I repeated the chroot experiment from above, confirmed
that this time the initrd contained cryptsetup and the other necessary tools (it
did), and I was able to then run the grub installer.

Since in the past when I did this it didn't work, I was trying to think of
something different to try, so I tried making a symlink with a "more expected"
name:


ln -s /dev/nvme0 /dev/sdb
grub-install /dev/sdb


I dunno if just running "grub-install" would have been enough, or if it worked
specifically because I faked it out with a symlink like this, but after that I
rebooted and grub seems to be installed correctly and is able to boot into
debian.  I'm happy my machine works now but I'm sorry I wasn't able to confirm
the fix for you - whatever has been donein grub-installer 1.128 has improved the
problem but not totally fixed it - hopefully these details will help you figure
out the remaining problems (possibly with the package that provides
grub-install, if it is differnet from grub-installer?  otherwise some other code
path in there...)

Thanks!
-Carl

-- 
Carl Myers 
PGP Key ID 3537595B
PGP Key fingerprint 9365 0FAF 721B 992A 0A20  1E0D C795 2955 3537 595B



signature.asc
Description: Digital signature

Bug#807143: Iceweasel user-agent prevents usage with chase.com; works with Firefox user-agent

[Josh Triplett]

Package: iceweasel
Version: 42.0-1
Severity: important

Some time ago, Chase Bank (https://www.chase.com/) started generating
warnings about using an out-of-date browser, despite using a version of
Iceweasel based on the latest upstream Firefox.  As of recently, they
now completely reject logins from a browser using the Iceweasel
User-Agent.  Changing the User-Agent to the corresponding Firefox
User-Agent (dropping the Iceweasel/42.0 token) allows logging in.

Yes, this is a stupid thing for Chase to do.  However, a quick check on
Alexa confirms that Chase is the 116th most popular site on the web.

Between this and the privacy concerns about browser fingerprinting (e.g.
Panopticlick), versus the little-to-no value provided by including this
token, is there any reason *not* to remove the Iceweasel token from the
User-Agent string and match the upstream Firefox User-Agent?

-- Addons package information
ii  gnome-shell3.18.3-2 amd64graphical shell for the GNOME des
ii  iceweasel  42.0-1   amd64Web browser based on Firefox
ii  rhythmbox-plug 3.2.1-1  amd64plugins for rhythmbox music playe
ii  xul-ext-adbloc 2.6.10+dfsg- all  advertisement blocking extension 
ii  xul-ext-https- 5.1.1-2  all  extension to force the use of HTT
ii  xul-ext-itsall 1.9.2-1  all  extension to edit textareas using

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-3
ii  libcairo2 1.14.4-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.0-3
ii  libgdk-pixbuf2.0-02.32.2-1
ii  libglib2.0-0  2.46.2-1
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.9.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.0-3
ii  libvpx2   1.4.0-4
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.10-4+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.6.1-1
ii  gstreamer1.0-plugins-good  1.6.1-1

Versions of packages iceweasel suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-4
pn  mozplugger 

-- no debconf information

Bug#807142: jessie-pu: package linux-tools/3.16.7-ckt20-1

[Ben Hutchings]

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

This version of linux-tools adds a new binary package (hyperv-daemons)
containing programs built from the previously-unused tools/hv
directory.  This will improve support for running Debian as a Hyper-V
guest.  Many upstream bug fixes to these programs are applied as
patches.

It also includes some bug fixes to the perf tool and the module
building tools from the 3.16-ckt stable branch. as listed in the
changelog.

Finally, the rules and control file have been updated to work with the
kernel team's git repository.

The debdiff is below.  I've excluded upstream changes to these files
which I believe are unused in this source package:

- arch/*/Makefile
- arch/*/include/asm/cacheflush.h
- arch/*/include/asm/elf.h
- arch/*/include/asm/kvm*.h
- arch/*/include/asm/mmu_context.h
- arch/*/include/asm/pgtable*.h
- arch/*/include/asm/ptrace.h
- arch/*/include/asm/suspend.h
- arch/*/include/asm/thread_info.h
- arch/arc/**
- arch/arm/include/asm/tls.h
- arch/arm/include/asm/unistd.h
- arch/arm/include/asm/xen/page.h
- arch/arm64/include/asm/arch_timer.h
- arch/arm64/include/asm/compat.h
- arch/arm64/include/asm/cputype.h
- arch/arm64/include/asm/hw_breakpoint.h
- arch/arm64/include/asm/hwcap.h
- arch/arm64/include/asm/tlbflush.h
- arch/m68k/**
- arch/metag/**
- arch/mips/include/asm/asm-eva.h
- arch/mips/include/asm/asmmacro.h
- arch/mips/include/asm/eva.h
- arch/mips/include/asm/ftrace.h
- arch/mips/include/asm/mach-**
- arch/mips/include/asm/mipsregs.h
- arch/mips/include/asm/r4kcache.h
- arch/mips/include/asm/reg.h
- arch/mips/include/asm/stackframe.h
- arch/mips/include/asm/syscall.h
- arch/mips/include/asm/uaccess.h
- arch/parisc/**
- arch/powerpc/include/asm/iommu.h
- arch/powerpc/include/asm/machdep.h
- arch/powerpc/include/asm/pte-hash64-64k.h
- arch/powerpc/include/asm/reg.h
- arch/powerpc/include/asm/rtas.h
- arch/powerpc/include/asm/spinlock.h
- arch/sh/**
- arch/sparc/**
- arch/unicore32/**
- arch/x86/include/asm/desc.h
- arch/x86/include/asm/efi.h
- arch/x86/include/asm/fixmap.h
- arch/x86/include/asm/fpu-internal.h
- arch/x86/include/asm/mmu.h
- arch/x86/include/asm/mwait.h
- arch/x86/include/asm/page_*_types.h
- arch/x86/include/asm/preempt.h
- arch/x86/include/asm/pvclock.h
- arch/x86/include/asm/segment.h
- arch/x86/include/asm/traps.h
- arch/x86/include/asm/vga.h
- arch/x86/include/asm/vsyscall.h
- arch/x86/include/asm/xen/page.h
- arch/xtensa/**
- include/acpi/**
- include/asm-generic/preempt.h
- include/asm-generic/sections.h
- include/drm/**
- include/dt-bindings/**
- include/kvm/**
- include/linux/acpi.h
- include/linux/audit.h
- include/linux/bitops.h
- include/linux/blkdev.h
- include/linux/blk_types.h
- include/linux/bootmem.h
- include/linux/buffer_head.h
- include/linux/capability.h
- include/linux/ccp.h
- include/linux/clk-provider.h
- include/linux/clocksource.h
- include/linux/cpuidle.h
- include/linux/crash_dump.h
- include/linux/cred.h
- include/linux/crypto.h
- include/linux/dcache.h
- include/linux/device-mapper.h
- include/linux/efi.h
- include/linux/etherdevice.h
- include/linux/fs.h
- include/linux/fsl_devices.h
- include/linux/fsnotify*.h
- include/linux/fsnotify.h
- include/linux/ftrace.h
- include/linux/hid.h
- include/linux/hugetlb.h
- include/linux/if_vlan.h
- include/linux/iio/*
- include/linux/inetdevice.h
- include/linux/jbd2.h
- include/linux/jhash.h
- include/linux/jiffies.h
- include/linux/kernel_stat.h
- include/linux/kernfs.h
- include/linux/kgdb.h
- include/linux/khugepaged.h
- include/linux/libata.h
- include/linux/memory.h
- include/linux/mm.h
- include/linux/mount.h
- include/linux/mtd/*
- include/linux/netdevice.h
- include/linux/netlink.h
- include/linux/nfs_*.h
- include/linux/nilfs2_fs.h
- include/linux/of.h
- include/linux/oom.h
- include/linux/pagemap.h
- include/linux/pci.h
- include/linux/pci_ids.h
- include/linux/perf_event.h
- include/linux/power/charger-manager.h
- include/linux/preempt*.h
- include/linux/pstore_ram.h
- include/linux/quota*.h
- include/linux/ring_buffer.h
- include/linux/rmap.h
- include/linux/sched/rt.h
- include/linux/sched.h
- include/linux/seq_file.h
- include/linux/seqlock.h
- include/linux/skbuff.h
- include/linux/string.h
- include/linux/sunrpc/*
- include/linux/swapops.h
- include/linux/sysctl.h
- include/linux/sysfs.h
- include/linux/time.h
- include/linux/tpm.h
- include/linux/uio.h
- include/linux/usb/*
- include/linux/usb*.h
- include/linux/user_namespace.h
- include/linux/vga_switcheroo.h
- include/linux/workqueue.h
- include/linux/writeback.h
- include/media/*
- include/net/*
- include/scsi/*
- include/sound/*
- include/target/*
- include/trace/*
- include/uapi/drm/*
- include/xen/**
- tools/power/**
- tools/testing/**

The upload is currently in the NEW queue rather than the p-u queue,
due to the new binary package.

Ben.

diff -Nru linux-tools-3.16/arch/arm/include/uapi/asm/unistd.h 
linux-tools-3.16.7-ckt

Bug#807141: Cannot install

[Steve M. Robbins]

Package: gcc-5-base
Version: 5.3.0-3
Severity: important

Trying to update today results in ...

Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
dpkg: error processing archive 
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz', 
which is different from other instances of package gcc-5-base:i386
Errors were encountered while processing:
 /var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)




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

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

Bug#807140: jessie-pu: package madfuload/1.2-4+deb8u1

[Andreas Beckmann]

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

madfuload FTBFS in jessie due to automake 1.14. Switching from
'autoreconf -f' to 'autoreconf -fi' is sufficient to install the missing
file.

(Note to self: package in non-free, no autobuilding support, needs
binary upload for i386 and amd64)


Andreas
diff -u madfuload-1.2/debian/rules madfuload-1.2/debian/rules
--- madfuload-1.2/debian/rules
+++ madfuload-1.2/debian/rules
@@ -5,3 +5,3 @@
 override_dh_auto_configure:
-	autoreconf -f
+	autoreconf -fi
 	dh_auto_configure -- --with-udev=/lib/udev
diff -u madfuload-1.2/debian/changelog madfuload-1.2/debian/changelog
--- madfuload-1.2/debian/changelog
+++ madfuload-1.2/debian/changelog
@@ -1,3 +1,10 @@
+madfuload (1.2-4+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Use autoreconf -fi to fix FTBFS with automake 1.14.  (Closes: #793190)
+
+ -- Andreas Beckmann   Sat, 05 Dec 2015 23:19:42 +0100
+
 madfuload (1.2-4) unstable; urgency=low
 
   * Imported changes from Ubuntu 1.2-2ubuntu3~karmic~ppa2 (Closes: #547336,

Bug#807139: scrot: Provide with a way to prevent screenshots from being overwriten

[Sophoklis Goumas]

Package: scrot
Version: 0.8-17
Severity: wishlist

Hello.

I have assigned the PrtScr key on my window manager
to the following bind:
scrot -q -z 'scrot_%Y%m%d_%H%M%S.png -e 'mv $f ~/Desktop'
which works absolutely fine.

However if there are more than one screenshots made
in the same second the file are being overwriten and
only the last one will remain.

There should be:
- an option to prevent/allow files to be overwritten
- if the option is set to not to overwrite files,
  a increment number could be appended to the file.

Sophoklis

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

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

Versions of packages scrot depends on:
ii  giblib11.2.4-10
ii  libc6  2.19-22
ii  libimlib2  1.4.7-1
ii  libx11-6   2:1.6.3-1

scrot recommends no packages.

scrot suggests no packages.

-- no debconf information

Bug#806239: Updating ca-certificates through stable-updates

[Philipp Kern]

> Could I perhaps convince you to file this (kind of) request as a pu bug?
>  They are much easier for us to track than mails to the mailing list.
>   I appreciate that you might have been sending this mail to avoid the
> pu-bug.  Unfortunately, we often end up forgetting the mail on our TODO
> list if it is not listed in the bug tracker.

There's that and it helps to look at the debdiff to see what the actual
changes are. Cert updates are likely to be much easier on us than
packaging/script updates.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Bug#778736: (no subject)

[Mauro Sacchetto]

it strikes me that after more than one year versione 2.0.3 is not yet ready 
for Debian, while it's in all other major Linux distros

Bug#807138: golang: gccgo triggers ar warning message when invoked as "go -compiler=gccgo"

[Eric Cooper]

Package: golang
Version: 2:1.5.1-4
Severity: normal
Tags: upstream patch

Whenever gccgo is used via the /usr/bin/go command, it calls "ar cru ...",
which causes this warning:
$ go build -compiler=gccgo
# github.com/ecc1/primes
ar: `u' modifier ignored since `D' is the default (see `U')

Details:
$ go build -x -compiler=gccgo
WORK=/tmp/go-build529072590
mkdir -p $WORK/github.com/ecc1/primes/_obj/
mkdir -p $WORK/github.com/ecc1/primes/_obj/exe/
cd /home/ecc/go/src/github.com/ecc1/primes
/usr/bin/gccgo -I $WORK -c -g -m64 
-fgo-relative-import-path=_/home/ecc/go/src/github.com/ecc1/primes -o 
$WORK/github.com/ecc1/primes/_obj/_go_.o ./primes.go
ar cru $WORK/github.com/ecc1/libprimes.a 
$WORK/github.com/ecc1/primes/_obj/_go_.o
# github.com/ecc1/primes
ar: `u' modifier ignored since `D' is the default (see `U')
cd .
/usr/bin/gccgo -o $WORK/github.com/ecc1/primes/_obj/exe/a.out 
$WORK/github.com/ecc1/primes/_obj/_go_.o -Wl,-( -m64 -Wl,-)
mv $WORK/github.com/ecc1/primes/_obj/exe/a.out primes

The attached patch simply uses "ar cr" instead.  The extra I/O for
unchanged archive members is probably negligible.

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

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

Versions of packages gccgo depends on:
ii  cpp  4:5.2.1-8
ii  gcc  4:5.2.1-8
ii  gccgo-5  5.2.1-23

gccgo recommends no packages.

Versions of packages gccgo suggests:
pn  gccgo-multilib  

-- no debconf information

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

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

Versions of packages golang depends on:
ii  golang-doc  2:1.5.1-4
ii  golang-go   2:1.5.1-4
ii  golang-src  2:1.5.1-4

golang recommends no packages.

golang suggests no packages.

-- no debconf information
--- src/cmd/go/build.go~	2015-09-08 21:24:01.0 -0400
+++ src/cmd/go/build.go	2015-12-05 14:08:48.360369642 -0500
@@ -2448,7 +2448,7 @@
 	for _, f := range ofiles {
 		absOfiles = append(absOfiles, mkAbs(objDir, f))
 	}
-	return b.run(p.Dir, p.ImportPath, nil, "ar", "cru", mkAbs(objDir, afile), absOfiles)
+	return b.run(p.Dir, p.ImportPath, nil, "ar", "cr", mkAbs(objDir, afile), absOfiles)
 }
 
 func (tools gccgoToolchain) ld(b *builder, root *action, out string, allactions []*action, mainpkg string, ofiles []string) error {

Bug#806945: Fwd: Re: Installation of PDF/PS/DVI and HTML files

[Chet Ramey]

--- Begin Message ---
On 12/3/15 6:05 AM, Ludovic Courtès wrote:
> Hello,
> 
> Akira of Debian noticed that ‘make all’ rebuilds and install
> PDF/PS/DVI/HTML documentation by default, which prevents default Bash
> builds from being bit-reproducible¹.

This isn't completely accurate, since `make all' doesn't install anything.
So is it the building in the build directory or the installation not
being minimal enough that is the problem?

> 
> Given that the GCS suggests installing only the Info version of the
> manual by default (info "(standards) Standard Targets"), what about a
> change along the lines of the patch below?

That's not quite what it says.  It suggests that the `install' target
install the info file, but leaves other files up to the discretion of
the package maintainer.


> --- a/doc/Makefile.in
> +++ b/doc/Makefile.in
> @@ -146,9 +146,9 @@ BASHREF_FILES = $(srcdir)/bashref.texi $(srcdir)/fdl.texi 
> $(srcdir)/version.texi
>   ${RM} $@
>   -${DVIPS} $<
>  
> -all: ps info dvi text html
> +all: info
>  nodvi: ps info text html
> -everything: all pdf
> +everything: all pdf dvi text html
>  
>  PSFILES = bash.ps bashbug.ps article.ps builtins.ps rbash.ps 
>  DVIFILES = bashref.dvi bashref.ps

So the problem is that bash builds too much by default?  And it's the build
output that needs to be bit-for-bit reproducible?  In general, this is
impossible, since the version string changes with each new `build version'.

This patch doesn't have anything to do with the install target, which
installs the info file, man pages, and html files by default.  (And if you
don't want the html files installed, run make install with `htmldir' set
to the empty string.)


> In addition, the ‘install’ rule in doc/Makefile.in would need to be
> split in ‘install-info’, ‘install-pdf’, etc. (as explained in the GCS),
> with ‘install’ depending only on ‘install-info’.

Again, that's not quite what the coding standards say.  The standards say
to make sure to install the info file when you run `make install', using
the `install-info' program to do so.

> What do you think?

It's hard to say, since the proposed patch has little to do with the
subject of the message.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
--- End Message ---

Bug#807137: libosmocore: FTBFS (big-endian): smscb test fails (+ others on sparc64)

[Aaron M. Ucko]

Source: libosmocore
Version: 0.9.0-1
Severity: important
Justification: fails to build from source

Builds of libosmocore for the three big-endian architectures attempted
so far (powerpc, s390x, and sparc64) all failed with test suite errors
of the form

  7. testsuite.at:45: testing smscb ...
  ./testsuite.at:48: $abs_top_builddir/tests/smscb/smscb_test
  --- expout2015-12-05 15:51:53.395182322 +
  +++ /«PKGBUILDDIR»/tests/testsuite.dir/at-groups/7/stdout 2015-12-05 
15:51:53.463182812 +
  @@ -1,4 +1,4 @@
  -(srl) GS: 1 MSG_CODE: 1 UPDATE: 0
  +(srl) GS: 0 MSG_CODE: 256 UPDATE: 1
   (msg) msg_id: 1293
  -(dcs) group: 1 language: 0
  +(dcs) group: 0 language: 1
   (pge) page total: 1 current: 1
  7. testsuite.at:45: 7. smscb (testsuite.at:45): FAILED (testsuite.at:48)

(with only the timestamp varying).

Three additional tests failed on sparc64, as detailed at

https://buildd.debian.org/status/fetch.php?pkg=libosmocore&arch=sparc64&ver=0.9.0-1&stamp=1449335905

Please look into all of these failures, particularly the smscb one;
sparc64 isn't a release architecture, but fixing the build there would
still be good.

Thanks!

Bug#807136: golang: FTBFS due to new binutils relocations

[Eric Cooper]

Package: golang
Version: 2:1.5.1-4
Severity: normal
Tags: upstream patch

Building golang fails with these errors:

...
# cmd/trace
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
# cmd/pprof
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
# cmd/go
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
/build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
relocation type 42; compiled without -fpic?
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
runtime/cgo(.text): unexpected relocation type 298
debian/rules:62: recipe for target 'override_dh_auto_build-arch' failed
make[1]: *** [override_dh_auto_build-arch] Error 2
make[1]: Leaving directory '/build/golang-1.5.1'
debian/rules:15: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

The problem is fixed upstream here:

https://github.com/golang/go/commit/914db9f060b1fd3eb1f74d48f3bd46a73d4ae9c7

but that commit does not apply cleanly to the current Debian version.
I've attached an equivalent patch that does, but I didn't manage to
preserve the original author, date, etc.  Please use the original
metadata from the github commit if you decide to apply this.

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

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

Versions of packages golang depends on:
ii  golang-doc  2:1.5.1-4
ii  golang-go   2:1.5.1-4
ii  golang-src  2:1.5.1-4

golang recommends no packages.

golang suggests no packages.

-- no debconf information
>From 716b8354f9fba9e67543c07c91438fa382046023 Mon Sep 17 00:00:00 2001
From: Eric Cooper 
Date: Sat, 5 Dec 2015 15:19:25 -0500
Subject: [PATCH 3/3] The GNU binutils recently picked up support for new
 386/amd64 relocations. Add support for them in the Go linker when doing an
 internal link.

The 386 relocation R_386_GOT32X was proposed in
https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I .  It can
be treated as identical to the R_386_GOT32 relocation.

The amd64 relocations R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were
proposed in
https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0 .  They
can both be treated as identical to the R_X86_64_GOTPCREL relocation.

The purpose of the new relocations is to permit additional linker
relaxations in some cases.  We do not attempt to support those cases.

While we're at it, remove the unused and in some cases out of date
_COUNT names from ld/elf.go.

Fixes #13114.

Change-Id: I34ef07f6fcd00cdd2996038ecf46bb77a49e968b
Reviewed-on: https://go-review.googlesource.com/16529
Reviewed-by: Minux Ma 
Signed-off-by: Eric Cooper 
---
 src/cmd/link/internal/amd64/asm.go |   2 +-
 src/cmd/link/internal/ld/elf.go| 141 +
 src/cmd/link/internal/ld/ldelf.go  |   3 +
 src/cmd/link/internal/x86/asm.go   |   2 +-
 4 files changed, 86 insertions(+), 62 deletions(-)

diff --git a/src/cmd/link/internal/amd64/asm.go b/src/cmd/link/internal/amd64/asm.go
index 74ec9dd..4eb2092 100644
--- a/src/cmd/link/internal/amd64/asm.go
+++ b/src/cmd/link/internal/amd64/asm.go
@@ -141,7 +141,7 @@ func adddynrel(s *ld.LSym, r *ld.Reloc) {
 
 		return
 
-	case 256 + ld.R_X86_64_GOTPCREL:
+	case 256 + ld.R_X86_64_GOTPCREL, 256 + ld.R_X86_64_GOTPCRELX, 256 + ld.R_X86_64_REX_GOTPCRELX:
 		if targ.Type != obj.SDYNIMPORT {
 			// have symbol
 			if r.Off >= 2 && s.P[r.Off-2] == 0x8b {
diff --git a/src/cmd/link/internal/ld/elf.go b/src/cmd/link/internal/ld/elf.go
index 508f055..66ac543 100644
--- a/sr

Bug#726492: debian-edu: Task files are specifying a lot of not existing / renamed packages

[Andreas Tille]

Hi,

it seems nobody has minded seriously to maintain debian-edu tasks.  Any 
volunteer?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#807128: gcc-5-base: Differing changelog.Debian.gz between :i386 and :amd64

[cosimo]

On 05/12/2015 20:37, Matthias Klose wrote:
> no binNMU please.
>
> On 05.12.2015 19:25, James McCoy wrote:
>> Control: reassign -1 release.debian.org
>> Control: retitle -1 nmu: gcc-5_5.3.0-3
>> Control: user release.debian@packages.debian.org
>> Control: usertag -1 binnmu
>>
>> nmu gcc-5_5.3.0-3 . amd64 . unstable . -m "Rebuild to fix M-A
>> installability"
>>
>> On Sat, Dec 05, 2015 at 01:00:20PM -0500, James McCoy wrote:
>>> Unpacking gcc-5-base:amd64 (5.3.0-3) over (5.2.1-27) ...
>>> Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
>>> Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
>>> dpkg: error processing archive
>>> /var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
>>>   trying to overwrite shared
>>> '/usr/share/doc/gcc-5-base/changelog.Debian.gz', which is different
>>> from other instances of package gcc-5-base:i386
>>>
>>> The :amd64 package (built on the buildd) has unstable as the target
>>> distribution in the changelog, but the (maintainer built) :i386 package
>>> has experimental, thus causing the mismatch between the two.
>>
>> Where :i386 and :amd64 were built is reversed, but the end result is the
>> same.
>>
>> Cheers,
>>
>
Same thing here:

Preconfiguring packages ...
(Reading database ... 160353 files and directories currently installed.)
Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
dpkg: error processing archive
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
 trying to overwrite shared
'/usr/share/doc/gcc-5-base/changelog.Debian.gz', which is different from
other instances of package gcc-5-base:i386
Errors were encountered while processing:
 /var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
dpkg: dependency problems prevent configuration of libgcc1:i386:
 libgcc1:i386 depends on gcc-5-base (= 5.3.0-3); however:
  Version of gcc-5-base:i386 on system is 5.2.1-27.

dpkg: error processing package libgcc1:i386 (--configure):
 dependency problems - leaving unconfigured
dpkg: error processing package gcc-5-base:amd64 (--configure):
 package gcc-5-base:amd64 5.3.0-3 cannot be configured because
gcc-5-base:i386 is at a different version (5.2.1-27)
dpkg: dependency problems prevent configuration of libgcc1:amd64:
 libgcc1:amd64 depends on gcc-5-base (= 5.3.0-3); however:
  Package gcc-5-base:amd64 is not configured yet.

dpkg: error processing package libgcc1:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libgcc1:i386
 gcc-5-base:amd64
 libgcc1:amd64




signature.asc
Description: OpenPGP digital signature

Bug#805202: gramps: FTBFS - fix is pending

[Ross Gammon]

Control: tags -1 pending

Hi,

I was expecting this issue as I had a preview of a similar failure in
Ubuntu when Python 3.5 is the default.

I had been waiting for Django 1.8, and now we have Django 1.9 and the
failure still exists.

As the Django webapp in Gramps is not yet enabled (not used), the
simplest thing to do is to exclude nose from looking in that directory
for now.

Regards,

Ross

Bug#798963: Could you explain the showstopper for libvtk-java

[Anton Gladky]

Hi Andreas,

it just needs to be enabled and tested, whether it works [1].
Autopkgtest could also help to solve the problem.

[1]
https://anonscm.debian.org/cgit/debian-science/packages/vtk6.git/commit/?id=8a2823684eea7732f5f51f42902cf5ecd826e3ca

Best regards

Anton

2015-12-05 18:10 GMT+01:00 Andreas Tille :
>
> some packages in Debian Med depend from libvtk-java version 6.x.  Is
> there any chance to get libvtk-java back and how can I help with this?

Bug#807133: gcc-5-base: Fails to install on multiarch.

[Simon McVittie]

On Sat, 05 Dec 2015 at 18:51:15 -0200, felipe wrote:
> Fails to build on multiarch. 

Sorry, but this isn't specific enough to be a useful bug report.

Is this the same bug described in
,
with the error message
"trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz',
which is different from other instances of package gcc-5-base:something"?
If it is, there's a workaround described there.

S

Bug#807135: krb5-kdc: systemd overrides configured log settings

[Elana Hashman]

Package: krb5-kdc
Version: 1.12.1+dfsg-19+deb8u1
Severity: normal

Hi again!

I configured Kerberos to log to some specific locations:

(from /etc/krb5.conf:)
...
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5.log

However, these logs are empty. I discovered that everything from 
krb5-kdc and kadmin is getting dumped into auth.log, which is not what I 
want.


I took a look at another jessie system that is using the same version of 
krb5-kdc but is not using systemd, and found that all the logs get filed 
into the correct places with the same config parameters.


Hence, I think that systemd/journalctl is overriding the 
software-defined settings. I'm not super experienced with systemd; I'm 
running it with all the Debian default settings.


Do you know if it's possible to fix this?

- e


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

Kernel: Linux 3.16.0-4-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 krb5-kdc depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  krb5-config2.3
ii  krb5-user  1.12.1+dfsg-19+deb8u1
ii  libc6  2.19-18+deb8u1
ii  libcomerr2 1.42.12-1.1
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u1
ii  libgssrpc4 1.12.1+dfsg-19+deb8u1
ii  libk5crypto3   1.12.1+dfsg-19+deb8u1
ii  libkadm5clnt-mit9  1.12.1+dfsg-19+deb8u1
ii  libkadm5srv-mit9   1.12.1+dfsg-19+deb8u1
ii  libkdb5-7  1.12.1+dfsg-19+deb8u1
ii  libkeyutils1   1.5.9-5+b1
ii  libkrb5-3  1.12.1+dfsg-19+deb8u1
ii  libkrb5support01.12.1+dfsg-19+deb8u1
ii  libverto-libev10.2.4-2
ii  libverto1  0.2.4-2
ii  lsb-base   4.1+Debian13+nmu1

krb5-kdc recommends no packages.

Versions of packages krb5-kdc suggests:
ii  krb5-admin-server  1.12.1+dfsg-19+deb8u1
pn  krb5-kdc-ldap  
ii  xinetd [inet-superserver]  1:2.3.15-3

-- debconf information:
  krb5-kdc/debconf: true
  krb5-kdc/purge_data_too: false

Bug#807081: Does not set TCP_NODELAY on X11 forward

[paul . szabo]

Sorry, I was wrong... sshd sets TCP_NODELAY correctly: not on the
listening socket, but after accept().
What it does not set is IPTOS_LOWDELAY ... but maybe that is not
useful anyway.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#807134: laptop-mode-tools: battery level polling kills udevd

[Tomas Ebenlendr]

Package: laptop-mode-tools
Version: 1.68-3
Severity: normal
Tags: patch upstream

Laptop_mode spawns lm-polling-daemon within the same process group as itself
when AC is plugged out. Laptop_mode is launched in process group of
systemd-udevd on my system. When AC is plugged in later, laptop_mode
kills all processes in group where lm-polling-daemon is found, i.e.,
it kills udevd and itself as well.

I use battery level polling to trigger custom actions when battery is
low, but not yet critical.

The solution proposed in patch is to spawn lm-polling-daemon in its own
process group, using /usr/bin/setsid wrapper from util-linux package.


--- /usr/sbin/laptop_mode   2015-09-03 13:10:48.0 +0200
+++ modified/laptop_mode2015-12-05 21:41:16.873037703 +0100
@@ -1148,7 +1148,7 @@
log "VERBOSE" "On battery and there was no 
polling daemon yet, starting the polling daemon."
 
# If there is no polling daemon, we start one.
-   
/usr/share/laptop-mode-tools/module-helpers/lm-polling-daemon < /dev/null > 
/dev/null 2> /dev/null &
+   setsid 
/usr/share/laptop-mode-tools/module-helpers/lm-polling-daemon < /dev/null > 
/dev/null 2> /dev/null &
fi
else
log "VERBOSE" "Lock acquisition on descriptor 7 failed 
with pid $$";

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

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

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.24
ii  lsb-base 9.20150917
ii  psmisc   22.21-2.1
ii  util-linux   2.27.1-1

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.2-1
ii  hdparm  9.43-2
ii  net-tools   1.60+git20150829.73cef8a-1
ii  python-qt4  4.11.4+dfsg-1+b2
ii  sdparm  1.08-1
ii  udev228-2
ii  wireless-tools  30~pre9-8

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.25-1
ii  apmd   3.2.2-15

-- Configuration Files:
/etc/laptop-mode/conf.d/auto-hibernate.conf changed:
DEBUG=0
ENABLE_AUTO_HIBERNATION=1
HIBERNATE_COMMAND=/usr/sbin/hibernate-disk
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=3
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=0

/etc/laptop-mode/conf.d/battery-level-polling.conf changed:
DEBUG=0
CONTROL_BATTERY_LEVEL_POLLING=1
BLACKLIST_IN_FLOCK=1

/etc/laptop-mode/conf.d/cpufreq.conf changed:
DEBUG=0
CONTROL_CPU_FREQUENCY=0
BATT_CPU_MAXFREQ=fastest
BATT_CPU_MINFREQ=slowest
BATT_CPU_GOVERNOR=ondemand
BATT_CPU_IGNORE_NICE_LOAD=1
LM_AC_CPU_MAXFREQ=fastest
LM_AC_CPU_MINFREQ=slowest
LM_AC_CPU_GOVERNOR=ondemand
LM_AC_CPU_IGNORE_NICE_LOAD=1
NOLM_AC_CPU_MAXFREQ=fastest
NOLM_AC_CPU_MINFREQ=slowest
NOLM_AC_CPU_GOVERNOR=ondemand
NOLM_AC_CPU_IGNORE_NICE_LOAD=0
CONTROL_CPU_THROTTLING=0
BATT_CPU_THROTTLING=medium
LM_AC_CPU_THROTTLING=medium
NOLM_AC_CPU_THROTTLING=minimum

/etc/laptop-mode/conf.d/dpms-standby.conf changed:
DEBUG=0
CONTROL_DPMS_STANDBY=1
BATT_DPMS_STANDBY=300
LM_AC_DPMS_STANDBY=1200
NOLM_AC_DPMS_STANDBY=1200

/etc/laptop-mode/conf.d/ethernet.conf changed:
DEBUG=0
CONTROL_ETHERNET=0
BATT_THROTTLE_ETHERNET=0
LM_AC_THROTTLE_ETHERNET=0
NOLM_AC_THROTTLE_ETHERNET=0
THROTTLE_SPEED="slowest"
DISABLE_WAKEUP_ON_LAN=1
ETHERNET_DEVICES="eth0"
DISABLE_ETHERNET_ON_BATTERY=0

/etc/laptop-mode/conf.d/usb-autosuspend.conf changed:
DEBUG=0
CONTROL_USB_AUTOSUSPEND=0
AUTOSUSPEND_USE_WHITELIST=1
AUTOSUSPEND_USBID_BLACKLIST=""
AUTOSUSPEND_USBTYPE_BLACKLIST=""
AUTOSUSPEND_USBID_WHITELIST=""
AUTOSUSPEND_USBTYPE_WHITELIST=""
BATT_SUSPEND_USB=0
LM_AC_SUSPEND_USB=0
NOLM_AC_SUSPEND_USB=0
AUTOSUSPEND_TIMEOUT=2

/etc/laptop-mode/laptop-mode.conf changed:
ENABLE_LAPTOP_MODE_TOOLS=1
VERBOSE_OUTPUT=1
LOG_TO_SYSLOG=1
DEBUG=0
ENABLE_LAPTOP_MODE_ON_BATTERY=1
ENABLE_LAPTOP_MODE_ON_AC=0
ENABLE_LAPTOP_MODE_WHEN_LID_CLOSED=0
ENABLE_AUTO_MODULES=1
MINIMUM_BATTERY_CHARGE_PERCENT=3
DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1
DISABLE_BATTERY_ALARM_CHECK=0
HD="/dev/disk/by-id/ata-ST320LT007-9ZV142_W0Q66HJ9"
PARTITIONS="auto /dev/mapper/* /dev/dm-*"
ASSUME_SCSI_IS_SATA=1
LM_BATT_MAX_LOST_WORK_SECONDS=600
LM_AC_MAX_LOST_WORK_SECONDS=360
CONTROL_READAHEAD=1
LM_READAHEAD=3072
NOLM_READAHEAD=128
CONTROL_NOATIME=0
USE_RELATIME=1
CONTROL_HD_IDLE_TIMEOUT=1
LM_AC_HD_IDLE_TIMEOUT_SECONDS=20
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200
CONTROL_HD_POWERMGMT="auto"
BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254
NOLM_AC_HD_POWERMGMT=254
CONTROL_HD_WRITECACHE=0
NOLM_AC_HD_WRITECACHE=1
NOLM_BATT_HD_WRITECACHE=0
LM_HD_WRITECACHE=0
CONTROL_MOUNT_OPTIONS=1
LM_DIRTY_RATIO=60
NOLM_DIRT

Bug#807097: python-django: Undeclared removal of previously supported features causes crashes

[Raphael Hertzog]

On Sat, 05 Dec 2015, Neil Williams wrote:
> http://paste.debian.net/341382/

So this one is fairly obvious, I already replied that it's
django.template.base.Origin that you should have used in the first place
since where the code actually is... relying on the fact that it was
also imported in django.template is not very future-proof (when not
documented).

> http://paste.debian.net/341383/

This one is actually documented, add_to_builtins has never been a public
API.

https://docs.djangoproject.com/en/1.9/releases/1.9/#django-template-base-add-to-builtins-is-removed

So what's left on your grave bug report?

Nothing except vitriol against the fact that it was uploaded a bit
hastily. Please take that somewhere else... or express it in a less
confrontional way.

Please close this bug unless you are able to show us a real problem.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#806243: [libminc] Test issues when building on mipsel architecture (#66)

[James Cowgill]

On Sat, 2015-12-05 at 18:21 +0100, Andreas Tille wrote:
> Hi,
> 
> I'm just forwarding this mail from upstream.  From my perspective it is
> possibly not a bug in libminc but rather a problem of certain mips
> hardware. 

I haven't looked at this build failure in particular, but I do know the
FPUs on the Loongson machines are a little suspect (giving _almost_
correct answers to _most_ things) so I would not be surprised if this
was a hardware problem.

> I wonder in how far this is a serious bug of libminc and should be
> downgraded to important (at maximum).

Since libminc has never successfully built on mipsel, this bug
shouldn't have been serious in the first place (regardless of what was
causing it).

James

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

Bug#807131: gcc-5-base amd64+i386 not coinstallable because of changelog.Debian.gz mismatch

[Ben Caradoc-Davies]

Workaround is to force overwrite, fix, and then resume the dist-upgrade:

dpkg -i --force-overwrite 
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb
dpkg -i --force-overwrite 
/var/cache/apt/archives/gcc-5-base_5.3.0-3_amd64.deb

apt-get install -f
apt-get dist-upgrade

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#807133: gcc-5-base: Fails to install on multiarch.

[felipe]

Package: gcc-5-base
Severity: important

Fails to build on multiarch. 


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

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

Bug#807132: unbound-control breaks systemctl stop/start

[Rudy Broersma]

Package: unbound
Version: 1.5.6-1
Severity: important

Dear Maintainer,

On our machine with Debian Stretch with all updates (as of 2015/12/05) we 
noticed
that sometimes unbound failed to start. I believe this has something to do
with unbound-control and systemctl.

eg.:

# Normal situation:

root@nscache1:~# systemctl status unbound.service
● unbound.service
   Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (running) since Fri 2015-12-04 17:10:37 CET; 1 day 4h ago
 Docs: man:systemd-sysv-generator(8)
  Process: 8864 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 8901 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)
   CGroup: /system.slice/unbound.service
   └─8911 /usr/sbin/unbound

# Now we stop unbound using unbound-control:

root@nscache1:~# unbound-control stop
ok

# We check its status. Notice the "active (exited)":

root@nscache1:~# systemctl status unbound.service
● unbound.service
   Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (exited) since Fri 2015-12-04 17:10:37 CET; 1 day 4h ago
 Docs: man:systemd-sysv-generator(8)
  Process: 8864 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 8901 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)

# We now start it again using systemctl (in our case, this is done by Puppet)
# but the issue also occurs when doing manual start using systemctl:

root@nscache1:~# systemctl start unbound.service

# And we check its status. As can be shown, the service is still "active 
(exited)"
# and is indeed _NOT_ running. This is where I believe there is a bug. The 
service
# should have started by now.

root@nscache1:~# systemctl status unbound.service
● unbound.service
   Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (exited) since Fri 2015-12-04 17:10:37 CET; 1 day 4h ago
 Docs: man:systemd-sysv-generator(8)
  Process: 8864 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 8901 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)

# To resolve the issue, we stop the service:

root@nscache1:~# systemctl stop unbound.service

# And check its status: (which is now the correct status: inactive dead)

root@nscache1:~# systemctl status unbound.service 
● unbound.service
   Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: inactive (dead) since Sat 2015-12-05 21:20:56 CET; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 29497 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 8901 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)

# We can now start the service again using systemctl (again, in our case this 
is done
# by puppet

root@nscache1:~# systemctl start unbound.service   

# And check its status:

root@nscache1:~# ps -aux | grep unbound
unbound  29521 26.8  3.3 140640 34352 ?Ssl  21:21   0:01 
/usr/sbin/unbound

root@nscache1:~# systemctl status unbound.service
● unbound.service
   Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (running) since Sat 2015-12-05 21:21:04 CET; 3min 12s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 29497 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 29511 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)
   CGroup: /system.slice/unbound.service
   └─29521 /usr/sbin/unbound

 * Outcome in our test case:
   - Systemctl is unable to start unbound when it wasn't stopped by systemctl
 but by unbound-control.
   
 * Expected outcome:
   
   - Systemctl to start unbound, regardless of how it was stopped.


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

Kernel: Linux 4.2.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 unbound depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.19-22
ii  libevent-2.0-5  2.0.21-stable-2+b1
ii  libfstrm0   0.2.0-1
ii  libprotobuf-c1  1.1.1-1
ii  libpython2.72.7.10-5+b1
ii  libssl1.0.2 1.0.2d-3
ii  open

Bug#704467: Updated patch

[Carsten Schoenert]

Hello Thorsten,

On Sun, Jan 18, 2015 at 08:50:39PM +0100, Torsten Landschoff wrote:
> Am 2015-01-18 14:07, schrieb Michael Meskes:
> >Here's an updated patch against the current version. Torsten is there any
> >reason why this is not applied?
> 
> No specific reason. Sorry, this should be fixed for a long time.
> I just applied the patch to a local git repository only to notice that I
> can't push it to git.debian.org because I can't access my private key as my
> desktop system is offline due to renovation in our flat. :-(

any news on this?
In a few days this bug reports hit the age of three years! and not even
a new version with this patch in experimental if unsure the patch is
doing the right thing.

In days there IPv6 is comming more and more popular I'd like to use a
DNS updater that is support IPv6 in a easy way. I'm using the patched
version on two of my local diskless stations and it works well.

Regards
Carsten

Bug#807131: gcc-5-base amd64+i386 not coinstallable because of changelog.Debian.gz mismatch

[Ben Caradoc-Davies]

Package: gcc-5-base
Version: 5.3.0-3
Severity: important

Dear Maintainer,

a conflict between changelog.Debian.gz on i386 and amd64 breaks multiarch. Note
also that libstdc++6 depends on gcc-5-base so removing one arch breaks all C++
applications for that arch.

Result of "apt-get dist-upgrade":

[...]
Preparing to unpack .../gcc-5-base_5.3.0-3_amd64.deb ...
De-configuring gcc-5-base:i386 (5.2.1-27) ...
Unpacking gcc-5-base:amd64 (5.3.0-3) over (5.2.1-27) ...
Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
dpkg: error processing archive
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz',
which is different from other instances of package gcc-5-base:i386
[...]

Kind regards,
Ben.



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

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

Bug#807130: grub-common: provide better 915resolution integration

[Thorsten Glaser]

Package: grub-common
Version: 2.02~beta2-32
Severity: wishlist

Common wisdom is to create a file /etc/grub.d/01_915resolution
with the appropriate content, e.g.:

echo insmod 915resolution
echo 915resolution 54 1024 600

However, nowadays, /etc/grub.d/00_header already initialises
the graphics mode, so this is too late.

I’m trying (haven’t yet rebooted) to move it to 00_915resolution,
but anything coming before a file called 00_header may be suspect
(and, in fact, the 915resolution module may be not even accessible
by that point), and creating a file myself to run 915resolution
also is… not exactly declarative, so a better integration for such
things would probably be welcome by many users?

(Of course it’d be even better if those eeepc had a standardised
resolution, but… it was a gift, so I better not complain.)

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,noatime,errors=remount-ro,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-ST9250315AS_5VC6X73E
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_915resolution ###
insmod 915resolution
915resolution 54 1024 600
### END /etc/grub.d/00_915resolution ###

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
68f0cece-7bc7-4c33-81ec-dff7d2bad5a0
else
  search --no-floppy --fs-uuid --set=root 68f0cece-7bc7-4c33-81ec-dff7d2bad5a0
fi
if loadfont /usr/share/grub/FixedMisc.pf2 ; then
  set gfxmode=1024x600
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux, with Linux 4.2.0-1-686-pae' --class debian --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.2.0-1-686-pae-advanced-68f0cece-7bc7-4c33-81ec-dff7d2bad5a0' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
68f0cece-7bc7-4c33-81ec-dff7d2bad5a0
else
  search --no-floppy --fs-uuid --set=root 
68f0cece-7bc7-4c33-81ec-dff7d2bad5a0
fi
echo'Loading Linux 4.2.0-1-686-pae ...'
linux   /boot/vmlinuz-4.2.0-1-686-pae 
root=UUID=68f0cece-7bc7-4c33-81ec-dff7d2bad5a0 ro acpi_osi=Linux 
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.2.0-1-686-pae
}
menuentry 'Debian GNU/Linux, with Linux 4.2.0-1-686-pae (sysvinit)' --class 
debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.2.0-1-686-pae-init-sysvinit-68f0cece-7bc7-4c33-81ec-dff7d2bad5a0' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search 

Bug#806895: packagekit: proxy vars set to uninitialized memory content

[Matthias Klumpp]

2015-12-02 16:37 GMT+01:00 Raphael Geissert :
> Source: packagekit
> Version: 1.0.1-2
> Tags: patch upstream
>
> Hi,
>
> Whenever the proxy configuration can not be found in the PackageKit.db
> the proxy variables of PkBackendJob are left uninitialized. Moreover,
> aptcc's AptIntf::init comes later down on the line and unconditionally
> sets http_proxy and ftp_proxy, therefore setting them to whatever the
> string processing functions get to read from memory.
>
> The latter seems to have been fixed in 1.0.11, but from a quick look
> it appears that the former bug is still present.

While your patch definitely fixes an issue (that function should
return TRUE if we don't have proxy data), I wonder why your patch
fixes the data corruption.
PkBackendJob is a GObject class, and all pointers defined in their
private struct are by default initialized to NULL. So, the proxy
variables should already be NULL, and applying your patch shouldn't
actually fix this issue, unless there is a compiler bug.
Can you maybe check if the PkBackendJob prxy variables are really not
initialized to NULL by default? If so, I wonder why, since if the
mechanism would in general be broken, we would see a lot more errors,
since many classes in PK assume this behavior (and actually, all libs
using GObject do, in one way or another).

Cheers,
Matthias

Bug#767173: gnome-shell: Display freezes but mouse stays operational

[pkr]

Package: gnome-shell
Version: 3.14.4-1~deb8u1
Followup-For: Bug #767173

Running on Gnome 3.14.1 and systemd 215-17

(VGA: nVidia GeForce 8600M GS ; issue appeared both with nouveau drivers as
well as current NVIDIA-Linux-x86_64-340.96 proprietary driver installed.)


Have to confirm the issue appears following steps reported in Message #20
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767173#20 .

Also, Alt+Tab occasionally repoduces the same issue, if actioned in similar
conditions.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-back  0.22.0-1
ii  evolution-data-server3.12.9~git20141128.5242b0-2+deb8u2
ii  gir1.2-accountsservice-1.0   0.6.37-3+b1
ii  gir1.2-atspi-2.0 2.14.0-1
ii  gir1.2-caribou-1.0   0.4.15-1
ii  gir1.2-clutter-1.0   1.20.0-1
ii  gir1.2-freedesktop   1.42.0-2.2
ii  gir1.2-gcr-3 3.14.0-2
ii  gir1.2-gdesktopenums-3.0 3.14.1-1
ii  gir1.2-gdm3  3.14.1-7
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.42.0-2.2
ii  gir1.2-gnomebluetooth-1.03.14.0-2
ii  gir1.2-gnomedesktop-3.0  3.14.1-1
ii  gir1.2-gtk-3.0   3.14.5-1+deb8u1
ii  gir1.2-ibus-1.0  1.5.9-1
ii  gir1.2-mutter-3.03.14.4-1~deb8u1
ii  gir1.2-networkmanager-1.00.9.10.0-7
ii  gir1.2-nmgtk-1.0 0.9.10.0-2
ii  gir1.2-pango-1.0 1.36.8-3
ii  gir1.2-polkit-1.00.105-8
ii  gir1.2-soup-2.4  2.48.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1
ii  gir1.2-telepathylogger-0.2   0.8.1-1
ii  gir1.2-upowerglib-1.00.99.1-3.2
ii  gjs  1.42.0-1
ii  gnome-backgrounds3.14.1-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.14.2-3
ii  gnome-shell-common   3.14.4-1~deb8u1
ii  gnome-themes-standard3.14.2.2-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libatk-bridge2.0-0   2.14.0-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u1
ii  libcairo21.14.0-2.1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.20.0-1
ii  libcogl-pango20  1.18.2-3
ii  libcogl201.18.2-3
ii  libcroco30.6.8-3+b1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-16   3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-183.12.9~git20141128.5242b0-2+deb8u2
ii  libgcr-base-3-1  3.14.0-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u3
ii  libgirepository-1.0-11.42.0-2.2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1
ii  libglib2.0-0 2.42.1-1
ii  libgstreamer1.0-01.4.4-2
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libical1a1.0-1.3
ii  libjson-glib-1.0-0   1.0.2-1
ii  libmozjs-24-024.2.0-2
ii  libmutter0e  3.14.4-1~deb8u1
ii  libnm-glib4  0.9.10.0-7
ii  libnm-util2  0.9.10.0-7
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-agent-1-0  0.105-8
ii  libpolkit-gobject-1-00.105-8
ii  libpulse-mainloop-glib0  5.0-13
ii  libpulse05.0-13
ii  libsecret-1-00.18-1+b1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  215-17+deb8u2
ii  libtelepathy-glib0   0.24.1-1
ii  libx11-6 2:1.6.2-3
ii  libxfixes3   1:5.0.1-2+b2
ii  mutter   3.14.4-1~deb8u1
ii  python   2.7.9-1
ii  telepathy-mission-control-5  1

Bug#804621: ITP: liblightify -- library to control OSRAM LIGHTIFY products

[Tobias Frost]

Package: wnpp
Followup-For: Bug #804621
Owner: Tobias Frost 

Package is now in NEW.

Tobi

Bug#807128: gcc-5-base: Differing changelog.Debian.gz between :i386 and :amd64

[Matthias Klose]

no binNMU please.

On 05.12.2015 19:25, James McCoy wrote:

Control: reassign -1 release.debian.org
Control: retitle -1 nmu: gcc-5_5.3.0-3
Control: user release.debian@packages.debian.org
Control: usertag -1 binnmu

nmu gcc-5_5.3.0-3 . amd64 . unstable . -m "Rebuild to fix M-A installability"

On Sat, Dec 05, 2015 at 01:00:20PM -0500, James McCoy wrote:

Unpacking gcc-5-base:amd64 (5.3.0-3) over (5.2.1-27) ...
Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
dpkg: error processing archive 
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
  trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz', 
which is different from other instances of package gcc-5-base:i386

The :amd64 package (built on the buildd) has unstable as the target
distribution in the changelog, but the (maintainer built) :i386 package
has experimental, thus causing the mismatch between the two.


Where :i386 and :amd64 were built is reversed, but the end result is the
same.

Cheers,

Bug#806252: jessie-pu: package nvidia-graphics-drivers/340.96-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2015-11-25 at 21:24 +0100, Andreas Beckmann wrote:
> next nvidia package in non-free to be updated for CVE-2015-7869.
> 
> Annotated changelog:
> 
> +nvidia-graphics-drivers (340.96-1) jessie; urgency=medium
> 
> uncommon version for the benefit of shorter version numbers in
> nvidia-graphics-modules, sid has an initial upload of 340.96 as
> 340.96-2.
> 
> +  * New upstream legacy 340xx branch release 340.96 (2015-11-16).
> +* Fixed CVE-2015-7869: Unsanitized User Mode Input.  (Closes: #805917)
> +  * Merge changes from 304.131-1.
> +  * Add xorg-video-abi-20 as alternative dependency.
> +  * conftest.h:
> +- Implement new conftest.sh functions hlist_for_each_entry,
> +  of_parse_phandle, for_each_online_node, node_end_pfn (358.09).
> +- Update conftest.sh function scatterlist for logic reversal in
> +  304.131/340.96/352.63, support both ways.

Please go ahead.

Regards,

Adam

Bug#804208: jessie-pu: package fuse-exfat/1.1.0-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2015-11-06 at 08:54 +0100, Sven Hoexter wrote:
> since exfat-utils and fuse-exfat share the same code base, but are released
> as seperate source packages, I've now prepared updates for fuse-exfat as well
> to fix the issues found by The Fuzzing Project.
> 
> Changes:
>  fuse-exfat (1.1.0-2+deb8u1) jessie; urgency=medium
>  .
>* Add the fix for https://github.com/relan/exfat/issues/5 found
>  and reported by The Fuzzing Project. Check sector and cluster size.
>* Add the fix for https://github.com/relan/exfat/issues/6 found
>  and reported by The Fuzzing Project. Detect infinite loop.

Please go ahead.

Regards,

Adam

Bug#802356: Any news about this bug?

[Markus Koschany]

Am 05.12.2015 um 18:12 schrieb Andreas Tille:
> Hi,
> 
> I just noticed that the reverse depends of this package are removed from
> testing.  As you know I tried to help in resolving this bug but I was
> running out of ideas and contacting upstream was also not helpful.
> 
> Any news about this?
> 

Hi Andreas,

I am currently working on getting a newer version of bouncycastle into
unstable. This will fix all outstanding bugs in this package. Some
upgrading of reverse-dependencies is also needed. As soon as this is
done, I will take a look at svnclient.

Regards,

Markus







signature.asc
Description: OpenPGP digital signature

Bug#803490: jessie-pu: package pdns/3.4.1-4+deb8u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2015-10-30 at 16:05 +0100, Christian Hofstaedtler wrote:
> there's a bug affecting pdns in stable (jessie): #798773
> 
> Upgrading -to- the jessie version from wheezy works fine, but
> subsequent upgrades in jessie fail if users don't strip the config
> file of comments.
> 
> This is quite bad for security updates, so please consider the
> attached debdiff.

Please go ahead.

Regards,

Adam

Bug#803199: jessie-pu: package gnupg/1.4.18-7

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-10-27 at 17:16 -0400, Daniel Kahn Gillmor wrote:
> https://bugs.debian.org/787046 shows a reasonable patch from noodles
> (imported from GnuPG upstream) that makes gnupg 1.4.x behave sensibly
> when previously unknown key types are encountered.
> 
> since Curve25519 keys are becoming more visible, we need gpg to at
> least ignore them cleanly.  This patch has already been included
> upstream and is in debian testing and stable without any bad
> consequences.

I assume you meant unstable there. :-)

Please go ahead.

Regards,

Adam

Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Carl Myers]

So, I have some bad news - the issue may not be completely fixed.  Or, I might
have missed something.  I tried to build an iso by following the steps to check
out the debian-install stuff[1] but found that the build_all target did not make
the netinst ISO as I expected.

I next found some directions for altering an existing iso, so I grabbed the net
inst and followed the rough directions here[2].  I found I had to modify the
directions to generate an efi compatible CD with these here[3].  The directions
didn't seem to work due to genisoimage not recognizing all the arguments, so as
per the workaround here[4] I had to grab a copy of the genisoimage binary from
the ubuntu package.

To modify the image, I rsync'd it to a new directory, then deleted the
grub-installer 1.127 package and replaced it with a copy of 1.128.  I updated
the md5sums.txt file and the "Packages.gz" file (leaving everything the same
except updating the verison, the path to the package, and the hashes).

I then redid the install - and it WORKED!  Got no grub error.  Unfortunately,
when I rebooted after the install, I still have the problem where it drops me
into a simple grub command line, and fails to boot the rest of the way.  Either
something is messed up in my boot loader that a fresh install did not fix, or
the fix in the grub-installer package alone is not enough (although it
definitely is working better since it doesn't get errors during install
anymore).

-Carl



[1] http://d-i.alioth.debian.org/doc/internals/ch04.html#id321776
[2] 
https://debmintux.wordpress.com/2010/07/21/howto-create-a-custom-debian-installer-netinstall-iso/
[3] 
http://askubuntu.com/questions/457528/how-do-i-create-an-efi-bootable-iso-of-a-customized-version-of-ubuntu
[4] https://stackoverflow.com/questions/31831268/genisoimage-and-uefi
-- 
Carl Myers 
PGP Key ID 3537595B
PGP Key fingerprint 9365 0FAF 721B 992A 0A20  1E0D C795 2955 3537 595B



signature.asc
Description: Digital signature

Bug#806243: [MINC-development] Bug#806243: libminc: FTBFS on mipsel

[Robert D. Vincent]

Steve et al,

I used an emulated mipsel environment using some other distributions (found
here: https://people.debian.org/~aurel32/qemu/mipsel/) - the bug was not
reproducible. I am in the process of building a QEMU environment for a more
recent release ("sid" from 20151023), I will try that as soon as possible.

-bert

On Sat, Dec 5, 2015 at 1:16 PM, Steve M. Robbins  wrote:

> Hi,
>
> [Adding minc-development as follow-up to previous email;
>
> http://www.bic.mni.mcgill.ca/pipermail/minc-development/2015-November/001223.html
> ]
>
>
> On December 4, 2015 08:25:09 PM Jurica Stanojkovic wrote:
> >  User: debian-m...@lists.debian.org
> >
> > Hello,
> >
> > I have tried to build package libminc_2.3.00-2 for mipsel and mips64el on
> > diferent build boards: netlogic-xlp, cavium and loongson-3a. This package
> > FTBFS only on loongson-3a (lemote).
> > On other build machines package was built from source successfully.
>
> That's interesting.  I have been able to reproduce the failure on the
> Debian's
> mipsel machine 'etler' which is longsoon.  I know Bert was trying to bring
> up
> a mipsel machine to test; not sure how far he got.  (Incidentally, Bert: I
> was
> working with the 'develop' branch as of Nov 19 and the failure persists.)
>
> Jurica: is everything else the same between your good/bad environments,
> specifically: libc, compiler, and libnetcdf?  I mean: I assume they are
> both
> running 'sid', but are the specific versions of each package the same?
>
> If all that is the same -- could it be something in the hardware?  The
> failing
> code is basically arithmetic mapping a double-value into another type, e.g.
> integer (of different sizes).  The failing test is for the mapping of
> -2*FLT_MAX, which should map to the low end of the output range but instead
> maps to the high end.  Is there anything different in the hardware that
> would
> maybe round things differently?
>
> Thanks,
> -Steve
>
> ___
> MINC-development mailing list
> minc-developm...@bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
>

Bug#791794: UUID not found for root

[Cyril Brulebois]

Hi,

Ian Campbell  (2015-12-05):
> I've not seen any complaints so far, the fix has been in Stretch for
> about three weeks now.

Thanks for the prod; pu filed accordingly: #807129.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#807129: jessie-pu: package flash-kernel/3.35+deb8u2

[Cyril Brulebois]

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

[ X-D-Cc: debian-b...@lists.debian.org ]

Hi,

We'd like to fix #791794 in stable, that is a possible hang when a given
script is running under d-i. The fix widens the DEBIAN_FRONTEND check to
avoid waiting for Ctrl-C (initially only when non-interactive is used,
now if any debconf frontend is in use). The fix reached testing some
weeks ago, and Ian is rather confident. See the few mails under this:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791794#105

Changelog entry:
| flash-kernel (3.35+deb8u2) stable; urgency=medium
| 
|   [ Ian Campbell ]
|   * Avoid waiting for Ctrl-C if any debconf frontend is in use, not just
| non-interactive. (Closes: #791794)
| 
|  -- Cyril Brulebois   Sat, 05 Dec 2015 19:16:33 +0100

Thanks for your time.

Mraw,
KiBi.
diff -Nru flash-kernel-3.35+deb8u1/debian/changelog flash-kernel-3.35+deb8u2/debian/changelog
--- flash-kernel-3.35+deb8u1/debian/changelog	2015-06-17 09:22:41.0 +0200
+++ flash-kernel-3.35+deb8u2/debian/changelog	2015-12-05 19:16:35.0 +0100
@@ -1,3 +1,11 @@
+flash-kernel (3.35+deb8u2) stable; urgency=medium
+
+  [ Ian Campbell ]
+  * Avoid waiting for Ctrl-C if any debconf frontend is in use, not just
+non-interactive. (Closes: #791794)
+
+ -- Cyril Brulebois   Sat, 05 Dec 2015 19:16:33 +0100
+
 flash-kernel (3.35+deb8u1) stable; urgency=medium
 
   * Combine i.MX53 QSB and LOCO board entries, they are the same thing and the
diff -Nru flash-kernel-3.35+deb8u1/initramfs-tools/hooks/flash_kernel_set_root flash-kernel-3.35+deb8u2/initramfs-tools/hooks/flash_kernel_set_root
--- flash-kernel-3.35+deb8u1/initramfs-tools/hooks/flash_kernel_set_root	2015-06-17 09:22:41.0 +0200
+++ flash-kernel-3.35+deb8u2/initramfs-tools/hooks/flash_kernel_set_root	2015-12-05 19:15:53.0 +0100
@@ -34,7 +34,7 @@
 	# If debconf appears to be running then it is important that
 	# we do not block on stdin since this would hang the
 	# installer.
-	if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" = "noninteractive" ]; then
+	if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" ]; then
 		echo "Unable to abort; system will probably be broken!" >&2
 	else
 		echo "Press Ctrl-C to abort build, or Enter to continue" >&2

Bug#807128: gcc-5-base: Differing changelog.Debian.gz between :i386 and :amd64

[James McCoy]

Control: reassign -1 release.debian.org
Control: retitle -1 nmu: gcc-5_5.3.0-3
Control: user release.debian@packages.debian.org
Control: usertag -1 binnmu

nmu gcc-5_5.3.0-3 . amd64 . unstable . -m "Rebuild to fix M-A installability"

On Sat, Dec 05, 2015 at 01:00:20PM -0500, James McCoy wrote:
> Unpacking gcc-5-base:amd64 (5.3.0-3) over (5.2.1-27) ...
> Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
> Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
>  trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz', 
> which is different from other instances of package gcc-5-base:i386
> 
> The :amd64 package (built on the buildd) has unstable as the target
> distribution in the changelog, but the (maintainer built) :i386 package
> has experimental, thus causing the mismatch between the two.

Where :i386 and :amd64 were built is reversed, but the end result is the
same.

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

Bug#806243: libminc: FTBFS on mipsel

[Steve M. Robbins]

Hi,

[Adding minc-development as follow-up to previous email; 
http://www.bic.mni.mcgill.ca/pipermail/minc-development/2015-November/001223.html
 ]


On December 4, 2015 08:25:09 PM Jurica Stanojkovic wrote:
>  User: debian-m...@lists.debian.org
> 
> Hello,
> 
> I have tried to build package libminc_2.3.00-2 for mipsel and mips64el on
> diferent build boards: netlogic-xlp, cavium and loongson-3a. This package
> FTBFS only on loongson-3a (lemote).
> On other build machines package was built from source successfully.

That's interesting.  I have been able to reproduce the failure on the Debian's  
mipsel machine 'etler' which is longsoon.  I know Bert was trying to bring up 
a mipsel machine to test; not sure how far he got.  (Incidentally, Bert: I was 
working with the 'develop' branch as of Nov 19 and the failure persists.)

Jurica: is everything else the same between your good/bad environments, 
specifically: libc, compiler, and libnetcdf?  I mean: I assume they are both 
running 'sid', but are the specific versions of each package the same?

If all that is the same -- could it be something in the hardware?  The failing 
code is basically arithmetic mapping a double-value into another type, e.g. 
integer (of different sizes).  The failing test is for the mapping of 
-2*FLT_MAX, which should map to the low end of the output range but instead 
maps to the high end.  Is there anything different in the hardware that would 
maybe round things differently?  

Thanks,
-Steve


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

Bug#807086: perl/experimental: FTBFS: cpan/podlators/t/devise-date failure

[Russ Allbery]

Niko Tyni  writes:

> Turns out the backported SOURCE_DATE_EPOCH support from podlators-4.00
> doesn't itself survive being build with SOURCE_DATE_EPOCH (or
> POD_MAN_DATE, for that matter) set. Patch attached.

Doh.  Thanks.  :)  I'll kick out a new version, probably this weekend.

-- 
Russ Allbery (r...@debian.org)   

Bug#807111: libperl-apireference-perl: Make the stored data reproducible between builds

[Niko Tyni]

On Sat, Dec 05, 2015 at 05:32:13PM +0100, Axel Beckert wrote:
> Niko Tyni wrote:
> > This module recently switched to using Sereal::Encoder instead of
> > Data::Dumper to store pre-parsed data. The stored data representation
> > now varies between builds.  The attached patch fixes this, rendering
> > the build reproducible again.

> >my $dump = Sereal::Encoder->new({
> > +canonical  => 1,

> I wonder if it's wise to patch the module itself in such a permanent
> way instead of maybe adding a switch and setting canonical=1 only
> during the build or the running of the test suite.
> 
> Maybe users of that module won't be happy if canonical=1 is hardcoded
> that way, e.g. for (guessed) performance reasons as the above likely
> includes sorting which always has an performance impact at some scale.

This code path is in a private function that is only used during the
build (by Perl::APIReference::Generator) to serialize API documentation
structures inline into the module in a __DATA__ section, to avoid parsing
perlapi.pod files at runtime.

I doubt the canonical representation is much slower to decode, but that
phase (API documentation lookups) doesn't seem like a performance critical
thing to me.

A hypothetical performance critical subclass of
Perl::APIReference::Generator might suffer, but IMO this is very
contrived.

The old Data-Dumper based implementation used to set
$Data::Dumper::Sortkeys, so the loss of reproducibility is a regression.

I've also forwarded the patch upstream, so the author can protest
if he judges this loss of performance unacceptable.

I hope this addresses your concerns.
-- 
Niko Tyni   nt...@debian.org

Bug#796872: vim: E676 saving a buftype=nofile buffer

[James McCoy]

On Sat, Dec 05, 2015 at 09:57:27AM +, Daniel Shahaf wrote:
> James McCoy wrote on Fri, Dec 04, 2015 at 23:33:22 -0500:
> > On Tue, Aug 25, 2015 at 08:57:27AM +, Daniel Shahaf wrote:
> > >* What was the outcome of this action?
> > > 
> > > "E676: No matching autocommands for acwrite buffer"
> > > 
> > >* What outcome did you expect instead?
> > > 
> > > "E382: Cannot write, 'buftype' option is set"
> > 
> > Hmm.  I think :saveas should be successful here, but the 'nofile'
> > setting should be transfered to the alternate buffer that gets created.
> > “:saveas foo” should really act like a short-cut for “:w foo” and “:e
> > foo”.

Hmm, that's not the mail I meant to send out ... Oh, I was messing
around with :saveas in Vim while composing the mail and continued
editing in the wrong buffer.

> I neglected to mention that ":w foobar" at that point gives E382; that's
> why I named that particular error as "what I expected to see".  So, more
> explicitly, what I "expected" was that :saveas would fail the same way
> :w fails at that point.

Yeah, my intended mail mentioned that.  I'll just include that below for
my final thoughts:

“:write foobar” is successful in a 'nofile' buffer and that's
essentially what “:saveas foobar” is doing, except it's also "switching"
you to that file.  The implementation detail of just renaming the
current buffer to the new filename is what seems to lead to this
problem.

It seems like “:saveas foobar” should do one of two things:

1.  Act like “:write foobar”, “:earlier 1f” (if buffer is modified),
“:edit foobar”.  This preserves whatever buffer-specific options
were set on the original buffer, while giving you the file foobar
with the modifications that had been made.
2.  Move the value of 'buftype' (and possibly other options) to the
newly created alternate buffer, which now represents the same "file"
the original buffer was displaying, sans the unsaved modifications.

However, 1 would has user visible side effects and is a change in
behavior.

2 appears at first blush to be easy to implement, but the trouble is
that the alternate buffer isn't loaded until the user switches to it.
Any options set on it before then will be wiped out when it actually
gets loaded.

It's trivial to get E382 reported, but that just doesn't seem right to
me. :)

And in further experimentation, that also breaks other behavior.

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

Bug#807128: gcc-5-base: Differing changelog.Debian.gz between :i386 and :amd64

[James McCoy]

Package: gcc-5-base
Version: 5.3.0-3
Severity: serious

Unpacking gcc-5-base:amd64 (5.3.0-3) over (5.2.1-27) ...
Preparing to unpack .../gcc-5-base_5.3.0-3_i386.deb ...
Unpacking gcc-5-base:i386 (5.3.0-3) over (5.2.1-27) ...
dpkg: error processing archive 
/var/cache/apt/archives/gcc-5-base_5.3.0-3_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/gcc-5-base/changelog.Debian.gz', 
which is different from other instances of package gcc-5-base:i386

The :amd64 package (built on the buildd) has unstable as the target
distribution in the changelog, but the (maintainer built) :i386 package
has experimental, thus causing the mismatch between the two.

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

Kernel: Linux 4.2.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)

Bug#807113: [pkg-go] Bug#807113: golang-golang-x-net-dev and golang-golang-x-crypto-dev: error when trying to install together

[Tianon Gravi]

On 5 December 2015 at 05:45, Ralf Treinen  wrote:
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:

This whole mess was my fault. :(  (See #807002 for more details.)

I've just now uploaded src:golang-golang-x-net-dev version
1:0.0+git20150817.66f0418-1 which fixes the problem on the net side,
and src:golang-go.crypto version 1:0.0~git20151201.0.7b85b09-2 is
already through binNEW to fix this on the crypto side.

I'll plan to close this bug as soon as my net upload is accepted for
the archive.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#807127: wireshark: license tab is empty, missing COPYING file

[Andrey Skvortsov]

Package: wireshark
Version: 2.0.0+g9a73b82-1
Severity: normal

Dear Maintainer,

to reproduce the bug
1. run wireshark,
2. select menu "Help->About",
3. switch to "License" tab.
4. There is no license


If wireshark is run from terminal. It's possible to see error message about
that problem:

"QIODevice::read (QFile, "/usr/share/wireshark/COPYING"): device not open"

I expect to see the license there.



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

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

Versions of packages wireshark depends on:
ii  wireshark-qt  2.0.0+g9a73b82-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

Bug#806243: [libminc] Test issues when building on mipsel architecture (#66)

[Andreas Tille]

Hi,

I'm just forwarding this mail from upstream.  From my perspective it is
possibly not a bug in libminc but rather a problem of certain mips
hardware.  I wonder in how far this is a serious bug of libminc and
should be downgraded to important (at maximum).

Kind regards

   Andreas.

On Sat, Dec 05, 2015 at 09:01:29AM -0800, Robert D Vincent wrote:
> I do not have access to any physical MIPS hardware, and the emulated system I 
> use does not exhibit the problem. I am trying to build an emulated system 
> using a more recent version of the OS to see if that has an impact, Is there 
> any way I can get remote access to a physical system of the right kind? Or, 
> failing that, does anyone have an emulated system that exhibits the problem?
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/BIC-MNI/libminc/issues/66#issuecomment-162223456

-- 
http://fam-tille.de

Bug#807126: Should Suggest: python-networkx-doc

[Yuri D'Elia]

Package: python3-networkx
Version: 1.9+dfsg1-1
Severity: minor

It would be nice if networkx suggested it's own documentation.
Thanks!

Bug#775118: [PATCH] Fix postinst

[Guido Günther]

Hi,
can we get a fixed version into at least experimental please? The bug is
already open since agx. I'm also happy to NMU.
Cheers,
 -- Guido