Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

On Mon, 26 Jun 2017 17:37:48 -0400 Antoine Beaupre
 wrote:
> Control: notfound -1 1.13.1~ds1-2
> Control: tags -1 unreproducible
> 
> Similarly: I installed 1.13.1~ds1-2 from sid on stretch and it installs
> fine.
> 
> Any more details on how to reproduce this? Which init system are you
> using? If you are using systemd, what does "systemctl status docker.io"
> say?

Have the same syptoms here (Debian SID amd64):

The fault seems to be "Error starting daemon: error initializing
graphdriver: driver not supported"

Any work-around is appreciated.

Here are the messages:


Setting up docker.io (1.13.1~ds1-2) ...
Job for docker.service failed because the control process exited with
error code.
See "systemctl  status docker.service" and "journalctl  -xe" for details.
invoke-rc.d: initscript docker, action "start" failed.
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; disabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2017-07-11 08:50:15
CEST; 9ms ago
 Docs: https://docs.docker.com
  Process: 7157 ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS
(code=exited, status=1/FAILURE)
 Main PID: 7157 (code=exited, status=1/FAILURE)
Tasks: 19
   Memory: 43.2M
  CPU: 98ms
   CGroup: /system.slice/docker.service

Jul 11 08:50:13 blitz-lx systemd[1]: Starting Docker Application
Container Engine...
Jul 11 08:50:14 blitz-lx dockerd[7157]:
time="2017-07-11T08:50:14.086356811+02:00" level=info
msg="libcontainerd: new containerd process, pid: 7165"
Jul 11 08:50:15 blitz-lx dockerd[7157]: Error starting daemon: error
initializing graphdriver: driver not supported
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Main process
exited, code=exited, status=1/FAILURE
Jul 11 08:50:15 blitz-lx systemd[1]: Failed to start Docker Application
Container Engine.
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Unit entered failed
state.
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Failed with result
'exit-code'.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1




signature.asc
Description: OpenPGP digital signature

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

Just an idea... aufs too old (not matching the kernel version) ?

# uname -a
Linux blitz-lx 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64
GNU/Linux

# dpkg -l '*aufs*'
un  aufs-dev 
 (no description available)
ii  aufs-dkms   4.9+20161219-2 amd64
 DKMS files to build and install aufs
ii  aufs-tools  1:4.1+20161219-1   amd64
 Tools to manage aufs filesystems

# apt-cache policy aufs-dkms
aufs-dkms:
  Installed: 4.9+20161219-2
  Candidate: 4.9+20161219-2
  Version table:
 *** 4.9+20161219-2 500
500 https://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status




signature.asc
Description: OpenPGP digital signature

Bug#849810: patch

[Kunal Mehta]

I see that this was attempted in the 1.8.1-1 version, but it doesn't
exactly work yet:

(sid)km@km-tp:~/projects/debian$ pkg-config --modversion pugixml
Package pugixml was not found in the pkg-config search path.
Perhaps you should add the directory containing `pugixml.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pugixml' found

I did a bit of digging and found the pugixml.pc file in
/usr/lib/x86_64-linux-gnu/pkgconfig/pkgconfig/pugixml.pc

After applying the attached patch, the pugixml.pc file was in its
correct place: /usr/lib/x86_64-linux-gnu/pkgconfig/pugixml.pc

(sid)km@km-tp:~/projects/debian$ pkg-config --modversion pugixml
1.8

:)
From 8fc55741e13e814dc72655a7a3ee5bc8eb6fd461 Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Mon, 10 Jul 2017 23:54:15 -0700
Subject: [PATCH] Fix pkg-config path

---
 debian/libpugixml-dev.install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libpugixml-dev.install b/debian/libpugixml-dev.install
index c0eea37..62e3a24 100755
--- a/debian/libpugixml-dev.install
+++ b/debian/libpugixml-dev.install
@@ -1,2 +1,2 @@
 #!/usr/bin/dh-exec
-usr/lib/pkgconfig/ usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
\ No newline at end of file
+usr/lib/pkgconfig/ usr/lib/${DEB_HOST_MULTIARCH}/
-- 
2.9.4



signature.asc
Description: OpenPGP digital signature

Bug#863981: check_ping uses IPv6 with -4

[Jan Wagner]

Hi Stefan,

thanks for bringing this to our attention.

Am 02.06.2017 um 18:39 schrieb Stefan Bühler:
> check_ping doesn't forward the "-4" option to ping, and ping prefers
> IPv6 now (i.e. probably whatever is configured through gai.ping).
> 
> Giving upstream only allows configuring "ping-command" and
> "ping6-command" (there is no explicit "ping4-command") I suggest adding
> "-4" to the "ping-command" in debian/rules in the meantime.

I guess you have checked /etc/nagios-plugins/config/ping.cfg? There are
explicit commands ending on "_4" which are using "-4" in its command and
so forcing IPv4 tests.

With kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

Here the work-around:

Use a different device driver, you likely use 'aufs'.

In /etc/default/docker change
DOCKER_OPTS="--storage-driver=aufs"
to
DOCKER_OPTS="--storage-driver=devicemapper"
(or whatever driver you like)

Then start apt-get upgrade again to configure docker.io:

apt-get --with-new-pkgs -f upgrade

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#868013: ITP: dh-fortran-mod -- debhelper add-on to handle Fortran '.mod' files

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: dh-fortran-mod
  Version : 1.0
  Upstream Author : Sebastien Villemont 
* URL : 
http://anonscm.debian.org/gitweb/?p=debian-science/packages/dh-fortran-mod.git
* License : GPL3
  Programming Lang: Perl
  Description : debhelper add-on to handle Fortran '.mod' files

 Modules were introduced in the 1990 revision of the Fortran standard. When the
 Fortran compiler processes a source file containing a module, it produces both
 an object file and a '.mod' file. The latter plays a role similar to header
 files in C, since it is needed when compiling other source files which make
 use of the module.
 .
 The '.mod' files are however platform dependent, and their format changes with
 the gfortran version
 .
 This package provides the dh_fortran_mod command, which simplifies th
 inclusion of '.mod' files in binary packages. First, it places the '.mod
 files in the correct platform- and gfortran-dependent location. Second, it
 adds the right dependency information on gfortran version(s).
 .
 Inclusion of dh_fortran_mod in dh sequence is also provided under the name
 'fortran_mod'.
 .
 This package was originally developed by Sebastien Vilemont.

Bug#863399: [Pkg-nagios-devel] Bug#863399: nagios-plugins-standard: missing dependency check_mailq -> FindBin.pm

[Jan Wagner]

Hi Fedor,

thanks for bringing this to our attention.

Am 26.05.2017 um 12:29 schrieb Fedor Piecka:
> Running check_mailq causes an error:
> 
> $ /usr/lib/nagios/plugins/check_mailq -w 5 -c 15 -M postfix
> Can't locate FindBin.pm in @INC (you may need to install the FindBin
> module) (@INC contains: /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2
> /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5
> /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20
> /usr/local/lib/site_perl .) at /usr/lib/nagios/plugins/check_mailq line 34.
> BEGIN failed--compilation aborted at /usr/lib/nagios/plugins/check_mailq
> line 34.
> 
> After issuing "apt-get install libfindbin-libs-perl", the command works:
> 
> $ /usr/lib/nagios/plugins/check_mailq -w 5 -c 15 -M postfix
> OK: postfix mailq reports queue is empty|unsent=0;5;15;0

I guess you are not installing recommended packages? As in
/usr/share/doc/monitoring-plugins-standard/README.Debian.plugins stated
we avoid pulling all the depedencies as this was reported as an issue
many times in the past.
So if your are not switching off installing recommended packages
intentionally, this package should be installed (perl-modules).

With kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#867095: serious

[Rene Engelhard]

severity 867095 serious
severity 867099 serious
thanks

Hi,

"Packages must autobuild without failure on all architectures on which they are 
supported."
has been in the RC policy since ever.

missing or unfulldillable build-dependencies are RC since ever. And also
on arch all, we live in times of _source.changes upload and the "all"
autobuilder.

Regards,

Rene

Bug#867804: cdrom: Stretch netinst CD installs grub config file incorrectly

[Hazel Russman]

On Mon, 10 Jul 2017 17:50:45 +0100
Steve McIntyre  wrote:

> Control: reassign -1 grub-common
> 
> On Mon, Jul 10, 2017 at 05:27:08PM +0100, Steve McIntyre wrote:
> 
> OK, I can see you have lots of OSes installed on your computer. I can
> see os-prober parsing lilo config files from other installations. :-)
> 
> What I *don't* see is any indication of any failures, though. Instead,
> grub-install claims to have succeeded:
> 
> Jul  8 07:42:53 grub-installer: info: Installing grub on '/dev/sda'
> Jul  8 07:42:53 grub-installer: info: grub-install does not support 
> --no-floppy
> Jul  8 07:42:53 grub-installer: info: Running chroot /target grub-install  
> --force "/dev/sda"
> Jul  8 07:42:54 grub-installer: Installing for i386-pc platform.
> Jul  8 07:43:05 grub-installer: Installation finished. No error reported.
> Jul  8 07:43:05 grub-installer: info: grub-install ran successfully
> 
> I'm wondering if *maybe* something has been confused by those lilo
> setups, but I'll admit that I'm not sure what's happening there.
> 
> >>I normally prefer lilo to grub, so I reinstalled lilo from one of my
> >>other Linuxen, but I could do a grub-install in Debian to test out the
> >>grub.cfg file, which I've now renamed. Would you like me to do that?  
> >
> >I'll get back to you...  
> 
> Yes please, that might be very helpful. Run as
> 
>  "grub-install -v /dev/sda"
> 
> and capture the output please?
Fine, I'll do that after I've walked the dog. But in the mean time, here is my 
take on the source of the problem:

Grub did indeed install correctly. I got a normal grub prompt, not a rescue 
prompt, which means that both boot.img and core.img were in their proper 
places. The problem was a misnamed grub.cfg file, and that is not created by 
grub-install but by grub-mkconfig.

I have looked at this script and have found that it creates a file called 
outputfile.new where "outputfile" is the argument to the --output option. It 
switches standard output to this file. Then, if all its daughter scripts have 
exited successfully, it renames outputfile.new to outputfile.

In this case it was obviously given the name grub.cfg, so it created 
grub.cfg.new. It then ran all the sniffer scripts to find my other systems. But 
one of those scripts must have failed so the renaming never took place and the 
file was left as grub.cfg.new. I'll report back again when I've retested grub, 
but in the meantime, I suggest you have a look at grub-mkconfig. Is there 
anything about my system that could have spooked one of those daughter scripts?

-- 
If any members of GCHQ are reading this, shame on you! I fought for your right 
to belong to a trade union and now you are taking away my right to privacy?

H Russman

Bug#868014: mercurial: New upstream version

[Andreas Tscharner]

Package: mercurial
Version: 4.0-1

New upstream version 4.2.2 is available. Please update it.

Best regards
Andreas
--
  ("`-''-/").___..--''"`-._
   `o_ o  )   `-.  ( ).`-.__.`)
   (_Y_.)'  ._   )  `._ `. ``-..-'
 _..`--'_..-_/  /--'_.' .'
(il).-''  (li).'  ((!.-'

Andreas Tscharner   a...@vis.ethz.ch   ICQ-No. 14356454

Bug#868015: knockd does not start after system reboot

[Alexander Tolkachev]

Package: knockd
Version: 0.7-1
Severity: normal

Dear Maintainer,

Issue founded in
https://serverfault.com/questions/859868/how-to-run-knockd-with-debian-9-on-system-boot/861439.
Knockd not starting after system reboot because there is no [Install]
section in service file.

Checked on knockd_0.7-1.
Knockd 0.5-3 starts without problem.

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

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

Versions of packages knockd depends on:
ii  libc6   2.19-18+deb8u7
ii  libpcap0.8  1.6.2-2
ii  logrotate   3.8.7-1+b1
ii  lsb-base4.1+Debian13+nmu1

knockd recommends no packages.

knockd suggests no packages.

-- no debconf information

Bug#862125: fixed upstream

[Rene Engelhard]

tag 862125 + fixed-upstream
thanks

Hi,

Gianfranco just told me:

"2017-07-10 - libfilezilla 0.10.0 released

New features:

Added fz::percent_encode and fz::percent_encode
Added fz::uri and fz::query_string
Added fz::less_insensitive_ascii for case-insensitive strings in maps
Bugfixes and minor changes:

Moved encoding functions from string.hpp to encode.hpp
Use pkg-config instead of cppunit-config to look for cppunit."

Regards,

Rene

Bug#868016: vzdump --all --suspend fails

[Narcis Garcia]

Package: vzdump
Version: 1.2.6-3
Severity: important

When running:
$ sudo vzdump --all --suspend
Fails with:
tar: dev: Cannot rmdir: Directory not empty
(...)

Solution is to comment or remove 3 lines at
/usr/share/perl5/PVE/VZDump/OpenVZ.pm

-if ($snapdir eq $task->{tmpdir} && $snapdir =~ m|^$opts->{dumpdir}/|) {
-$taropts .= " --remove-files"; # try to save space
-}

(lines 353, 354, 355)

Bug#864642: vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes

[Patrick Matthäi]

found #864642 4.9.30-2+deb9u2
thanks

And it still crashes..


Am 22.06.2017 um 14:58 schrieb Patrick Matthäi:
> found #864642 4.9.30-2+deb9u1
> thanks
>
>
> Am 12.06.2017 um 10:02 schrieb Patrick Matthäi:
>> Package: src:linux
>> Version: 4.9.30-1
>> Severity: important
>> File: linux
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where
>> appropriate ***
>>
>> Since updating the kernel from linux-image-4.9.0-2-amd64 (4.9.18-1) to
>> linux-image-4.9.0-3-amd64 (4.9.30-1) all VMs report - just for the
>> "primary" interface this:
>>
>> TCP: ens192: Driver has suspect GRO implementation, TCP performance may
>> be compromised.
>>
>> I can't see any performance impact. This happens on all our vSphere 6.0
>> and 6.5 hosts (running on HPE ProLiant DL 360 G8 - G9 HW / ProLiant ML
>> 350 G9 and so on).
>>
>> Why is this bug important? Because on one VM this also produces a kernel
>> panic after some time (minutes or hours). I just could get the panic
>> attached as screenshot. The only "big" difference between the crashing
>> host and the others may be, that it is also running PM2, NPM, NodeJS and
>> a NFS kernel server.
>>
>> If I boot the VM with 4.9.30-1 and deactivate gro and lro with:
>> ethtool -K ens192 gro off
>> ethtool -K ens192 lro off
>> .. it does not crash.
>>
>> Booting 4.9.18-1 and everything is completly fine ;)
>>
> The VM keeps on crashing after a few hours
>

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#857264: plasma-workspace: xembedsniproxy often segfaults

[Shengjing Zhu]

Package: plasma-workspace
Version: 4:5.8.7-1
Followup-For: Bug #857264

Dear Maintainer,

I got segfault everytime when I boot the system.

dmesg show:

[   15.105626] xembedsniproxy[1599]: segfault at 20 ip 55faee144b7c sp 
7ffd44065bf0 error 4 in xembedsniproxy[55faee139000+14000]

But I can start xembedsniproxy by hand after login.

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.20-1
ii  frameworkintegration 5.28.0-1
ii  gdb-minimal [gdb]7.12-6
ii  iso-codes3.75-1
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.7-1
ii  kded55.28.0-1
ii  kinit5.28.0-1
ii  kio  5.28.0-2
ii  kpackagetool55.28.1-1
ii  libc62.24-12
ii  libcln6  1.3.4-2+b1
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:7.1.0-7
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-2
ii  libkf5activities55.28.0-1
ii  libkf5auth5  5.28.0-2
ii  libkf5baloo5 5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5calendarevents55.28.0-1
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5declarative5   5.28.0-1
ii  libkf5globalaccel-bin5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5idletime5  5.28.0-1
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5js55.28.0-1
ii  libkf5jsembed5   5.28.0-1
ii  libkf5kdelibs4support5   5.28.0-2
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5networkmanagerqt6  5.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5package5   5.28.1-1
ii  libkf5plasma55.28.0-2
ii  libkf5plasmaquick5   5.28.0-2
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-4
ii  libkf5texteditor55.28.0-2
ii  libkf5textwidgets5   5.28.0-1
ii  libkf5wallet-bin 5.28.0-3
ii  libkf5wallet55.28.0-3
ii  libkf5waylandclient5 4:5.28.0-1
ii  libkf5widgetsaddons5 5.28.0-3
ii  libkf5windowsystem5  5.28.0-2
ii  libkf5xmlgui55.28.0-1
ii  libkf5xmlrpcclient5  5.28.0-1
ii  libkscreenlocker55.8.7-1
ii  libksgrd74:5.8.7-1
ii  libkworkspace5-5 4:5.8.7-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libplasma-geolocation-interface5 4:5.8.7-1
ii  libprocesscore7  4:5.8.7-1
ii  libprocessui74:5.8.7-1
ii  libqalculate5v5  0.9.7-9.2
ii  libqt5core5a 5.7.1+dfsg-4
ii  libqt5dbus5  5.7.1+dfsg-4
ii  libqt5gui5   5.7.1+dfsg-4
ii  libqt5network5 

Bug#868017: stretch-pu: package dgit/3.11~deb9

[Ian Jackson]

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

dgit 3.10 has a number of bugs which need to be fixed urgently.  I
considered them RC for buster and uploaded 3.11 to fix them there.
They need to be fixed in stable too.

3.11 has only stable-targeted bugfixes.  I would like to rebuild it
for stretch-p-u as 3.11~deb9, ASAP.


For full details of the changes, please see:

  git clone https://git.dgit.debian.org/dgit
  cd dgit
  git log archive/debian/3.10..archive/debian/3.11

NB that that doesn't contain the proposed changelog entry for
3.11~deb9.  That *is* in the attached combined diff.


The changes I'm here proposing for stable are to fix these bugs (along
with, in many cases, corresponding tests):

#857694 "Died at /usr/bin/dgit line 2196." with .xz files

   This critical bug makes dgit clone and dgit fetch fail for many
   current packages.  It is due to dgit not tolerating the compressor
   dying with SIGPIPE.  That is an expected situation which ought not
   to cause dgit to bomb out.

#867189 combined suite "foo,-security" does not work
#867189 cloning a combined suite deletes the working directory

   Combined suites are an important feature (recommended in
   dgit-user(7) and required by downstream users).  These bugs make
   this feature quite hard to use (although there are workarounds).
   Both fixes are to the combined suite code (so cannot break other
   use cases).  Each fix is a single line, but in the case of #867189
   quite subtle (as discussed in the commit messages).

#865863 Cope with newer git which hates --local outside a working tree

   Newer git than is in stretch breaks "dgit clone" completely.  I
   consider this a serious bug even for stretch because many people -
   especially keen git users - will install a newer git (from Debian
   backports, or from upstream).  The fix is annoyingly textuallly
   large, but conceptually simple.

#867702 Cope with new git-receive-pack which has quarantine feature

   Newer git than is in stretch breaks the backend
   dgit-infrastructure.  See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867702#10
   for discussion.  The workaround is necessary to get the test suite
   to pass on buster, and I would prefer to send to stretch an
   identical package of bugfixes to that I have sent to buster in dgit
   3.11.  The change is confined to dgit-infrastructure; for users
   using the dgit-infrastructure package from stretch, the arguments
   about them maybe wanting newer git apply, again.

#858054 clone fails if git does not create info/ (eg due to templatedir)

   This bug is annoying in this use case and risks breaking with
   future git versions.  The fix is extremely simple and low-risk.

#867603 dgit-badcommit-fixup: does not respect core.sharedRepository

   This causes this script to, in a very common case, leave the shared
   repo with broken permissions which prevent other pushes.  I have
   fixed this in a way that is confined to the prticular script, so
   users of dgit proper (and who aren't affected by the bug which this
   script exists to fix) are not at risk from this change.

   However, an analogous bug affects dgit itself, because dgit also
   manipulates the user's object store via a special-purpose tree,
   private to dgit.  These object store manipulations ought to honour
   core.sharedRepository (and some other options which control the
   object store).

(I have also found a couple of other less-critical issues which ought
to be fixed in stable, but which can be dealt with in a more leisurely
fashion.  I won't discuss those further in this bug submission.)


Thanks for your attention,
Ian.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff --git a/debian/changelog b/debian/changelog
index 392f1291..51e03acc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,36 @@
+dgit (3.11~deb9) stable; urgency=high
+
+  * Rebuild and upload to stretch.
+
+ -- Ian Jackson   Tue, 11 Jul 2017 09:28:15 
+0100
+
+dgit (3.11) unstable; urgency=high
+
+  Important bugfixes to dgit:
+  * Fix rpush+buildinfo: Transfer buildinfos for signing.  Closes:#867693.
+  * Cope if the archive server sends an HTTP redirect,
+by passing -L to curl.  Closes:#867185,#867309.
+  * Cope with newer git which hates --local outside a tree.  Closes:#865863.
+  * rpush: Honour local git config from build host working tree.
+  * Tolerate compressor terminating with SIGPIPE.  Closes:#857694.
+  * Honour more pre-tree git config options in our private trees sharing
+the user's object store.  In particular, core.sharedRepository.
+   

Bug#868009: Immediate disconnect after successful authentication when "UsePrivilegeSeparation sandbox" is used

[Colin Watson]

On Tue, Jul 11, 2017 at 08:43:58AM +0200, Simon Kainz wrote:
> When using the default
> 
> UsePrivilegeSeparation sandbox
> 
> i am unable to connect via SSH.
> 
> This even does not work when i try it locally, eg.
> 
> ssh skainz@127.0.0.1
> 
> 
> SSH fails right after pre-authentication. Systme log tells me, the
> authentication itself works correctly, but i get disconnected afterwards.
> 
> If i set
> 
> UsePrivilegeSeparation yes
> 
> 
> it works.
> 
> 
> Please see the attached ssh -vvv log.

Can you also get an sshd -ddd log from the server side, or at the very
least look at /var/log/auth.log?  The client log is unlikely to be of
much use in tracking this sort of thing down.

Thanks,

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

Bug#867979: aqbanking-tools: aqhbci-tool4 cannot load shared library,libaqhbci.so.24

[Micha Lenk]

Control: tags -1 +moreinfo +unreproducible

Hi Peter,

thank you for your feedback on the Debian packages for AqBanking.

On 07/10/2017 10:08 PM, Peter Zimmerer wrote:

if program aqhbci-tool4 is executed it will fail with error message:

aqhbci-tool4: error while loading shared libraries: libaqhbci.so.24:
cannot open shared object file: No such file or directory

If is sufficient to execute

aqhbci-tool4 --help

to reproduce the issue.


I failed to do so. Here is what I did when I tried to reproduce the issue:


$ sudo apt-get install --no-install-recommends aqbanking-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  mariadb-common
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  libaqbanking-data libaqbanking35 libaqbanking35-plugins libaqebics0 
libaqhbci23 libaqofxconnect7 libgwenhywfar-data libgwenhywfar60 
libktoblzcheck1v5 libxmlsec1 libxmlsec1-gcrypt libxmlsec1-gnutls libxslt1.1

Suggested packages:
  gwenhywfar-tools libchipcard-libgwenhywfar60-plugins 
libgwenhywfar60-dbg ktoblzcheck

The following NEW packages will be installed:
  aqbanking-tools libaqbanking-data libaqbanking35 
libaqbanking35-plugins libaqebics0 libaqhbci23 libaqofxconnect7 
libgwenhywfar-data libgwenhywfar60 libktoblzcheck1v5 libxmlsec1 
libxmlsec1-gcrypt libxmlsec1-gnutls libxslt1.1

0 upgraded, 14 newly installed, 0 to remove and 13 not upgraded.
Need to get 3756 kB of archives.
After this operation, 22.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.de.debian.org/debian stretch/main amd64 
libgwenhywfar-data all 4.15.3-5 [32.5 kB]
Get:2 http://ftp.de.debian.org/debian stretch/main amd64 libgwenhywfar60 
amd64 4.15.3-5+b1 [424 kB]
Get:3 http://ftp.de.debian.org/debian stretch/main amd64 
libaqbanking-data all 5.6.12-1 [1698 kB]
Get:4 http://ftp.de.debian.org/debian stretch/main amd64 libaqbanking35 
amd64 5.6.12-1+b1 [215 kB]
Get:5 http://ftp.de.debian.org/debian stretch/main amd64 libxslt1.1 
amd64 1.1.29-2.1 [233 kB]
Get:6 http://ftp.de.debian.org/debian stretch/main amd64 libxmlsec1 
amd64 1.2.23-0.1 [145 kB]
Get:7 http://ftp.de.debian.org/debian stretch/main amd64 
libxmlsec1-gcrypt amd64 1.2.23-0.1 [63.6 kB]
Get:8 http://ftp.de.debian.org/debian stretch/main amd64 
libxmlsec1-gnutls amd64 1.2.23-0.1 [54.9 kB]
Get:9 http://ftp.de.debian.org/debian stretch/main amd64 libaqebics0 
amd64 5.6.12-1+b1 [128 kB]
Get:10 http://ftp.de.debian.org/debian stretch/main amd64 libaqhbci23 
amd64 5.6.12-1+b1 [280 kB]
Get:11 http://ftp.de.debian.org/debian stretch/main amd64 
libaqofxconnect7 amd64 5.6.12-1+b1 [85.0 kB]
Get:12 http://ftp.de.debian.org/debian stretch/main amd64 
libktoblzcheck1v5 amd64 1.48-2.1+b1 [114 kB]
Get:13 http://ftp.de.debian.org/debian stretch/main amd64 
libaqbanking35-plugins amd64 5.6.12-1+b1 [157 kB]
Get:14 http://ftp.de.debian.org/debian stretch/main amd64 
aqbanking-tools amd64 5.6.12-1+b1 [126 kB]

Fetched 3756 kB in 1s (3669 kB/s)
Selecting previously unselected package libgwenhywfar-data.
(Reading database ... 44199 files and directories currently installed.)
Preparing to unpack .../00-libgwenhywfar-data_4.15.3-5_all.deb ...
Unpacking libgwenhywfar-data (4.15.3-5) ...
Selecting previously unselected package libgwenhywfar60.
Preparing to unpack .../01-libgwenhywfar60_4.15.3-5+b1_amd64.deb ...
Unpacking libgwenhywfar60 (4.15.3-5+b1) ...
Selecting previously unselected package libaqbanking-data.
Preparing to unpack .../02-libaqbanking-data_5.6.12-1_all.deb ...
Unpacking libaqbanking-data (5.6.12-1) ...
Selecting previously unselected package libaqbanking35.
Preparing to unpack .../03-libaqbanking35_5.6.12-1+b1_amd64.deb ...
Unpacking libaqbanking35 (5.6.12-1+b1) ...
Selecting previously unselected package libxslt1.1:amd64.
Preparing to unpack .../04-libxslt1.1_1.1.29-2.1_amd64.deb ...
Unpacking libxslt1.1:amd64 (1.1.29-2.1) ...
Selecting previously unselected package libxmlsec1.
Preparing to unpack .../05-libxmlsec1_1.2.23-0.1_amd64.deb ...
Unpacking libxmlsec1 (1.2.23-0.1) ...
Selecting previously unselected package libxmlsec1-gcrypt.
Preparing to unpack .../06-libxmlsec1-gcrypt_1.2.23-0.1_amd64.deb ...
Unpacking libxmlsec1-gcrypt (1.2.23-0.1) ...
Selecting previously unselected package libxmlsec1-gnutls.
Preparing to unpack .../07-libxmlsec1-gnutls_1.2.23-0.1_amd64.deb ...
Unpacking libxmlsec1-gnutls (1.2.23-0.1) ...
Selecting previously unselected package libaqebics0.
Preparing to unpack .../08-libaqebics0_5.6.12-1+b1_amd64.deb ...
Unpacking libaqebics0 (5.6.12-1+b1) ...
Selecting previously unselected package libaqhbci23.
Preparing to unpack .../09-libaqhbci23_5.6.12-1+b1_amd64.deb ...
Unpacking libaqhbci23 (5.6.12-1+b1) ...
Selecting previously unselected package libaqofxconnect7.
Preparing to unpack .../10-libaqofxconnect7_5.6.12-1+b1_amd64.deb ...
Unpacking libaqofxconnect7 (5.6.

Bug#868018: appstream: AppStream system cache was updated, but problems were found: Metadata files have errors:

[Andreas Beckmann]

Package: appstream
Version: 0.11.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch' via 'buster' to 'sid'.
It installed fine in 'stretch' and upgraded successfully to 'buster',
then the upgrade to 'sid' fails.

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

0m17.2s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmphZCQmo', 
'apt-get', 'update']
0m22.4s DUMP: 
  Get:1 http://ftp.de.debian.org/debian sid InRelease [255 kB]
  Get:2 http://ftp.de.debian.org/debian sid/main amd64 Packages [7550 kB]
  Get:3 http://ftp.de.debian.org/debian sid/main Translation-en [5731 kB]
  Get:4 http://ftp.de.debian.org/debian sid/main amd64 DEP-11 Metadata [3147 kB]
  AppStream system cache was updated, but problems were found: Metadata files 
have errors: 
/var/lib/app-info/yaml/ftp.de.debian.org_debian_dists_sid_main_dep11_Components-amd64.yml.gz
  Fetched 16.7 MB in 4s (4071 kB/s)
  Reading package lists...
  E: Problem executing scripts APT::Update::Post-Invoke-Success 'if 
/usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then 
appstreamcli refresh-cache > /dev/null; fi'
  E: Sub-process returned an error code
0m22.4s ERROR: Command failed (status=100): ['chroot', 
'/srv/piuparts/tmp/tmphZCQmo', 'apt-get', 'update']


cheers,

Andreas


appstream_0.11.1-1.log.gz
Description: application/gzip

Bug#867669: monit summary doesn't detect rxvt as color terminal

[mart...@tildeslash.com]

Hello Alexander,

the problem was fixed in the upstream: 
https://bitbucket.org/tildeslash/monit/commits/cf945190e280948f757646bd1fa7497a7f184434

Best regards,
Martin



> On 8 Jul 2017, at 13:56, Alexander Schier  wrote:
> 
> Package: monit
> Version: 5.20.0-6
> Severity: normal
> 
> Dear Maintainer,
> when running "monit summary" in rxvt with TERM=rxvt-unicode I get a
> plain dumb-terminal output. When running it in the same terminal as
> "TERM=xterm monit summary" I get a nicely formatted table with colors
> indicating the status of the services.
> It seems, that monit needs a longer list of terminals supporting colors
> and/or a switch to force colored output.
> 
> 
> with kind regards,
> Alexander Schier
> 
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages monit depends on:
> ii  libc6  2.24-12
> ii  libpam0g   1.1.8-3.6
> ii  libssl1.1  1.1.0f-3
> ii  lsb-base   9.20161125
> ii  zlib1g 1:1.2.8.dfsg-5
> 
> monit recommends no packages.
> 
> Versions of packages monit suggests:
> ii  postfix [mail-transport-agent]  3.2.2-1
> ii  sysvinit-core   2.88dsf-59.9
> 

Bug#867455: python3-shellescape: missing dependencies

[Steffen Möller]

Well spotted, many thanks! If it is easy for you then I happily see you
uploading your fixed package to the distribution.
Steffen

Bug#868019: corosync: Unexpected restart corosync during upgrade from 2.3.6 to 2.4.2

[Azat Yakupov]

Source: corosync
Version: 2.4.2
Severity: important



-- System Information:
Debian Release: 8.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (600, 'unstable')
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)

During upgrade procedure by using apt-dater (version 0.9.0) was detected that 
some Debian hosts (the role is loadbalacers in the system) need to upgrade 
corosync|2.3.6-3~bpo8+1|u=2.4.2-3~bpo8+1.
Corosync has been restarted automatically and therefore we got a huge impact on 
whole system.
Please have a look on that issue.

Bug#863981: check_ping uses IPv6 with -4

[Stefan Bühler]

Hi Jan,

On 07/11/2017 09:12 AM, Jan Wagner wrote:
> Hi Stefan,
> 
> thanks for bringing this to our attention.
> 
> Am 02.06.2017 um 18:39 schrieb Stefan Bühler:
>> check_ping doesn't forward the "-4" option to ping, and ping prefers
>> IPv6 now (i.e. probably whatever is configured through gai.ping).
>>
>> Giving upstream only allows configuring "ping-command" and
>> "ping6-command" (there is no explicit "ping4-command") I suggest adding
>> "-4" to the "ping-command" in debian/rules in the meantime.
> 
> I guess you have checked /etc/nagios-plugins/config/ping.cfg? There are
> explicit commands ending on "_4" which are using "-4" in its command and
> so forcing IPv4 tests.

You didn't get the issue.  I know very well how to call check_ping with
-4 - I can do that with my local config.  But check_ping -4 DOES NOT
call "ping -4" - it just calls "ping".  The -4 option does *NOTHING*. It
basically is the same as not passing "-6".

Also there is no package providing /etc/nagios-plugins/config/ping.cfg.
Maybe you meant /usr/share/monitoring-plugins/templates-basic/ping.cfg ?
But not really relevant at all.

cheers,
Stefan

Bug#867541: please build ruby binding of grpc

[Steinar H. Gunderson]

On Tue, Jul 11, 2017 at 10:07:58AM +1000, Andrew Pollock wrote:
>> Andrew, please link me to the grpc-packages link/account if possible.
>> It's bad that I can't follow this package from the first hand.
> Sorry, can you please clarify what you're asking for here?

Maintainer: gRPC Package Maintainers 

Presumably he wants to be added to that list.

IIRC there's no way to put non-Googlers on such groups, so you'd have to
migrate to a @googlegroups.com list. (Unless something changed in Groups
after I left Google, of course.) That's probably for the better anyway,
so that you can have a public archive.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#868020: vim-nox: description needs clarifying regarding python support (-python +python3)

[Jonathan Dowland]

Package: vim-nox
Version: 2:8.0.0197-4
Severity: normal

Dear Maintainer,

The vim-nox package description reads (in part):


This package contains a version of vim compiled with support for
scripting with Lua, Perl, Python, Ruby, and Tcl but no GUI.


However, vim-nox is not compiled with Python (2.x) support:


$ vim.nox --version | grep python
+cryptv  +linebreak   -python  +vreplace
+cscope  +lispindent  +python3 +wildignore


Thus, commands like the following will fail in  vimrc


python from powerline.vim import setup as powerline_setup


The package description should probably read "Python 3" rather than "Python".

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.nox
/usr/bin/vim is /usr/bin/vim.nox

-- System Information:
Debian Release: 9.0
 APT prefers stable
 APT policy: (990, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages vim-nox depends on:
ii  libacl1   2.2.52-3+b1
ii  libc6 2.24-11+deb9u1
ii  libgpm2   1.20.4-6.2+b1
ii  liblua5.2-0   5.2.4-1.1+b2
ii  libperl5.24   5.24.1-3
ii  libpython3.5  3.5.3-1
ii  libruby2.32.3.3-1
ii  libselinux1   2.6-3+b1
ii  libtcl8.6 8.6.6+dfsg-1+b1
ii  libtinfo5 6.0+20161126-1
ii  vim-common2:8.0.0197-4
ii  vim-runtime   2:8.0.0197-4

vim-nox recommends no packages.

Versions of packages vim-nox suggests:
pn  cscope   
pn  vim-doc  

-- no debconf information

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ 

Bug#868021: ffcall: diff for NMU version 1.13-0+nmu1

[Frédéric Bonnard]

Package: src:ffcall
Version: 1.10+cvs20100619-4
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared diff for a NMU for ffcall (versioned as 1.13-0+nmu1) in the
attached patch but feel free to use the patch as you want.
The goal was initially to fix the FTBFS impacting mlpcap on ppc64el
https://buildd.debian.org/status/fetch.php?pkg=mlpcap&arch=ppc64el&ver=0.9-16&stamp=1485552538&raw=0

config.log would show :
configure:4214: gcc -o conftest -g -O2 
-fdebug-prefix-map=/build/mlpcap-gmmM7n/mlpcap-0.9=. -fstack-protector-strong 
-Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro conftest.
c -lcallback  -lpcap  >&5
/usr/lib/gcc/powerpc64le-linux-gnu/6/../../../powerpc64le-linux-gnu/libcallback.so:
 undefined reference to `tramp_r'

But this upload could fix other bugs as well.

Looking at ffcal upstream, I see that there a much newer version of ffcall 
namely
1.13 which contains amongst other ppc64el improvements which fixed the build
of mlpcap (tested).
I tried to change the bare minimum of the packaging so that we have something 
close
to 1.10+cvs20100619-4 but still building. Here are the changes I made :
debian/patches : I've updated fix-powerpcspe.patch, and Fix_MIPS_N32_test.patch 
: please
 review them.
 I've disabled ppc64el-elfv2.patch as ppc64el support should be 
good in 1.13.
 I've also commented 0001-fix-callback-on-x86_64.patch as it 
should be
 fixed upstream : 
https://www.bountysource.com/issues/20684153-segfault
debian/rules :   autoreconf failed as is, so I added gnulib-m4 to aclocal path 
and removed
 skipping of libtoolize.
debian/libffcall1.symbols : some symbols seem local (__*) so no need to check 
them I
 think. There were some new additions.
debian/watch :   I updated the repo URL which seemed to not work anymore at all 
(server not found)

I hope that helps, let me know if things need to be improved.

Regards.

diff -baupr ./ffcall-1.10+cvs20100619/debian/changelog 
./ffcall-1.13/debian/changelog
--- ./ffcall-1.10+cvs20100619/debian/changelog  2016-05-18 15:38:55.0 
+
+++ ./ffcall-1.13/debian/changelog  2017-07-10 13:12:33.342511211 +
@@ -1,3 +1,10 @@
+ffcall (1.13-0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+
+ -- Frédéric Bonnard   Mon, 03 Jul 2017 13:00:38 
+
+
 ffcall (1.10+cvs20100619-4) unstable; urgency=medium
 
   [ Fernando Seiti Furusato ]
diff -baupr ./ffcall-1.10+cvs20100619/debian/libffcall1.symbols 
./ffcall-1.13/debian/libffcall1.symbols
--- ./ffcall-1.10+cvs20100619/debian/libffcall1.symbols 2016-05-18 
15:38:55.0 +
+++ ./ffcall-1.13/debian/libffcall1.symbols 2017-07-10 13:16:18.175743648 
+
@@ -1,16 +1,17 @@
 libavcall.so.0 libffcall1 #MINVER#
  __builtin_avcall@Base 1.10+2.41
- __structcpy@Base 1.10+2.41
+ avcall_structcpy@Base 1.13
 libcallback.so.0 libffcall1 #MINVER#
  (arch=alpha arm powerpc armel hppa)__TR_clear_cache@Base 1.10+2.41
+ (arch=ppc64el)__TR_clear_cache@Base 1.13
  (arch=sparc)__TR_clear_cache_2@Base 1.10+2.41
- __structcpy@Base 1.10+2.41
- __va_error1@Base 1.10+2.41
- __va_error2@Base 1.10+2.41
- __va_struct_buffer@Base 1.10+2.41
- __vacall_r@Base 1.10+2.41
+ callback_structcpy@Base 1.13
  alloc_trampoline_r@Base 1.10+2.41
  free_trampoline_r@Base 1.10+2.41
+ get__vacall_r@Base 1.13
+ glthread_once_singlethreaded@Base 1.13
+ glthread_recursive_lock_init_multithreaded@Base 1.13
+ glthread_rwlock_init_for_glibc@Base 1.13
  is_trampoline_r@Base 1.10+2.41
  (arch=hppa ia64)tramp_r@Base 1.10+2.41
  trampoline_r_address@Base 1.10+2.41
Only in ./ffcall-1.10+cvs20100619/debian/patches: 
0001-fix-callback-on-x86_64.patch
diff -baupr ./ffcall-1.10+cvs20100619/debian/patches/Fix_MIPS_N32_test.patch 
./ffcall-1.13/debian/patches/Fix_MIPS_N32_test.patch
--- ./ffcall-1.10+cvs20100619/debian/patches/Fix_MIPS_N32_test.patch
2016-05-18 15:38:55.0 +
+++ ./ffcall-1.13/debian/patches/Fix_MIPS_N32_test.patch2017-07-10 
15:26:44.740188692 +
@@ -2,18 +2,79 @@ Description: Fix MIPS N32 test
 Author: James Cowgill 
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/m4/general.m4
-+++ b/m4/general.m4
-@@ -97,11 +97,8 @@ dnl We should also check for (_MIPS_SZPT
- if test $ffcall_cv_host_mips64 = yes; then
-   host_cpu_abi=mips64
- else
--dnl Strictly speaking, the MIPS ABI (-32 or -n32) is independent from the CPU
--dnl identification (-mips[12] or -mips[34]). But -n32 is commonly used 
together
--dnl with -mips3, and it's easier to test the CPU identification.
-   FFCALL_SET_CPU_ABI([MIPS with n32 ABI], ffcall_cv_host_mipsn32,
--[__mips >= 3], mipsn32, mips)
-+[defined(_ABIN32) && (_MIPS_SIM == _ABIN32)], mipsn32, mips)
- fi
- ;;
- dnl On powerpc64 systems, the C compiler may still be generating 32-bit code.
+Index: ffcall-1.13/gnulib-m4/host-cpu

Bug#868009: Immediate disconnect after successful authentication when "UsePrivilegeSeparation sandbox" is used

[Simon Kainz]

ok, please see the attached file.

I ran it with

/usr/sbin/sshd -p  -ddd -o UsePrivilegeSeparation=sandbox


Thanks,

Simon


Am 2017-07-11 um 10:37 schrieb Colin Watson:
> On Tue, Jul 11, 2017 at 08:43:58AM +0200, Simon Kainz wrote:
>> When using the default
>>
>> UsePrivilegeSeparation sandbox
>>
>> i am unable to connect via SSH.
>>
>> This even does not work when i try it locally, eg.
>>
>> ssh skainz@127.0.0.1
>>
>>
>> SSH fails right after pre-authentication. Systme log tells me, the
>> authentication itself works correctly, but i get disconnected afterwards.
>>
>> If i set
>>
>> UsePrivilegeSeparation yes
>>
>>
>> it works.
>>
>>
>> Please see the attached ssh -vvv log.
> 
> Can you also get an sshd -ddd log from the server side, or at the very
> least look at /var/log/auth.log?  The client log is unlikely to be of
> much use in tracking this sort of thing down.
> 
> Thanks,
> 

-- 
ᘓ Debian Developer
  4096R/ED98D2D344641A6859A0864F1CB4F0F78DECAFE9
  Get my key:  finger skainz/k...@db.debian.org
   http://blog.familiekainz.at/static/gpg/8DECAFE9.asc
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 335
debug2: parse_server_config: config /etc/ssh/sshd_config len 335
debug3: /etc/ssh/sshd_config:32 setting PermitRootLogin yes
debug3: /etc/ssh/sshd_config:61 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:84 setting UsePAM yes
debug3: /etc/ssh/sshd_config:89 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:93 setting PrintMotd no
debug3: /etc/ssh/sshd_config:97 setting UsePrivilegeSeparation yes
debug3: /etc/ssh/sshd_config:113 setting AcceptEnv LANG LC_*
debug3: /etc/ssh/sshd_config:116 setting Subsystem sftp	/usr/lib/openssh/sftp-server
debug3: /etc/ssh/sshd_config:124 setting PasswordAuthentication yes
debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2l  25 May 2017
debug1: private host key #0: ssh-rsa SHA256:8R3rmjx6prPsXuXVjsQjWklRhuFeNq4xCgclpyNDruM
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:13+rX46/c/biytbW03UJHrRg0XFnftrzRxC+XG/Q9SE
debug1: private host key #2: ssh-ed25519 SHA256:uWSj2/e7z/roKFKrzhx2qFhS1Ru73PE40S22oyzkW5c
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]=''
debug1: rexec_argv[3]='-'
debug1: rexec_argv[4]='-o'
debug1: rexec_argv[5]='UsePrivilegeSeparation=sandbox'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port  on 0.0.0.0.
Server listening on 0.0.0.0 port .
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port  on ::.
Server listening on :: port .
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 335
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 129.27.9.27 port 32902 on 37.187.20.171 port 
debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Debian-5
debug1: match: OpenSSH_7.2p2 Debian-5 pat OpenSSH* compat 0x0400
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10
debug1: Enabling compatibility mode for protocol 2.0
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 29958
debug3: preauth child monitor started
debug3: privsep user:group 106:65534 [preauth]
debug1: permanently_set_uid: 106/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug3: receive packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: local server KEXINIT proposal [preauth]
debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth]
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com [preauth]
debug2: ciphers stoc: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com [preauth]
debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [pre

Bug#768030: [htsengine] Different hts_engine versions are not compatible

[dai]

Control: tags -1 + upstream help

We apologize for the delayed response.
If you are still interested in this issue,
would you please help us to fix it?
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#868025: Tryton suite 4.4 blocked in unstable

[Mathias Behrle]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
X-Debbugs-CC: maintain...@debian.tryton.org

Dear release managers,

currently the whole Tryton series 4.4 is stuck in unstable[0]. All Tryton
modules incl. server are marked as valid candidates. 

The only problem is with  

Excuse for tryton-meta

Migration status: BLOCKED: Cannot migrate due to another item, which is
blocked (please check which dependencies are stuck)
22 days old (needed 5 days)
Piuparts tested OK -
https://piuparts.debian.org/sid/source/t/tryton-meta.html
Invalidated by dependency 

which depends on all Tryton modules >=4.4 and thus should be ok?

Could please someone help me to sort out, how to get the packages migrated?

Thanks,
Mathias


NB:
Some Tryton modules (calendar*, party_vcard_dav, webdav) were discontinued and
removed from unstable, but they were also removed from tryton-meta.


[0] https://qa.debian.org/developer.php?login=mbeh...@debian.org



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#868022: reportbug: crashes when non-unicode characters are present in the report

[IOhannes m zmoelnig]

Package: reportbug
Version: 7.1.7
Severity: normal

Dear Maintainer,

while composing a bug-report, i wanted to type the paragraph symbol,
which was displayed with a trailing-space (using vi on a remote system),
which i consequently deleted (thus unknowingly turning the unicode character
into some garbage sequence).

after i finished the bugreport, i proceeded to send, at which point reportbug
crashed with a traceback:

~~~
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2234, in 
main()
  File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 2150, in user_interface
package, severity, mode, charset=charset, tags=tags)
  File "/usr/bin/reportbug", line 182, in handle_editing
editor, charset)
  File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 1064, in 
spawn_editor
newmessage = open(filename).read()
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 912: 
ordinal not in range(128)
~~~

while one can argue that there shouldn't be garbage sequences in the report,
reportbug should under no circumstances crash because of this.
i think the proper response would be to print an error message an re-open the
report so the user can fix it.

luckily I could find the report text in /tmp.
i'm attaching it.

gmasdr
IOhannes

PS: this seems to be somewhat similar to #814454 (although the encoding problem 
happened
at a different stage)


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/noc/.reportbugrc:
reportbug_version "2.18"
mode standard
ui text
realname "IOhannes m zmoelnig"
email "n...@iem.at"

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4.6
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4  4.89-2+deb9u1
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u1
ii  file   1:5.30-1
pn  gir1.2-gtk-3.0 
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-6
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gtkspellcheck  
pn  python3-urwid  
pn  xdg-utils  

Versions of packages python3-reportbug depends on:
ii  apt1.4.6
ii  file   1:5.30-1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- no debconf information
Subject: fusiondirectory: maintainer address broken
Package: fusiondirectory
Version: 1.0.19-1
Severity: serious
Justification: Policy 3.3


the email address of fusiondirectory's maintainer is 
.
Unfortunately this mailinglist rejects mails from non-subscribers with
the following message:

On 2017-07-10 16:37, SYMPA wrote:
> Your message for list 'packages' (attached below) was rejected.
> You are not allowed to send this message for the following reason:
> 
>  Message distribution in the list is restricted to list subscribers.
> If you are subscribed to the list with a different email address, you
> should
> either use that other email address or update your list membership
> with the
> new email address.
> 
> 
> For further information, please contact packages-
> requ...@lists.fusiondirectory.org

this is a direct violation of the Debian policy, which states in Â3.3:
> The email address given in the Maintainer control field must accept
> mail from those role accounts in Debian used to send automated mails
> regarding the package.

please fix this issue.

gfmasdr
IOhannes


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#868023: laptop-mode-tools: error "info task blocked for more than 120 seconds" while using laptop-mode-tools

[Ludovic]

Package: laptop-mode-tools
Version: 1.71-2
Severity: important

Dear Maintainer,


   * What led up to the situation?
 Upgarding Debian 8 to 9 and all packages with it.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 sudo apt-get update -- sudo apt-get upgrade
   * What was the outcome of this action?
 Graphic interface won't work while laptop booting on battery (tty 1 etc.
work).
   * What outcome did you expect instead?
 Using the graphic interface.



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

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

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  psmisc   22.21-2.1+b2
ii  util-linux   2.29.2-1

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.8-1+b1
ii  hdparm  9.51+ds-1
ii  net-tools   1.60+git20161116.90da8a0-1
ii  python-qt4  4.11.4+dfsg-2+b1
ii  sdparm  1.08-1+b1
ii  udev232-25
ii  wireless-tools  30~pre9-12+b1

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.28-1+b1

-- Configuration Files:
/etc/laptop-mode/conf.d/bluetooth.conf changed [not included]
/etc/laptop-mode/conf.d/ethernet.conf changed [not included]
/etc/laptop-mode/conf.d/hal-polling.conf changed [not included]
/etc/laptop-mode/conf.d/wireless-iwl-power.conf changed [not included]
/etc/laptop-mode/laptop-mode.conf changed [not included]

-- no debconf information

Bug#868024: fusiondirectory: maintainer address broken

[IOhannes m zmoelnig]

Package: fusiondirectory
Version: 1.0.19-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

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

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

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

Subject: fusiondirectory: maintainer address broken
Package: fusiondirectory
Version: 1.0.19-1
Severity: serious
Justification: Policy 3.3


the email address of fusiondirectory's maintainer is 
.
Unfortunately this mailinglist rejects mails from non-subscribers with
the following message:

On 2017-07-10 16:37, SYMPA wrote:
> Your message for list 'packages' (attached below) was rejected.
> You are not allowed to send this message for the following reason:
> 
>  Message distribution in the list is restricted to list subscribers.
> If you are subscribed to the list with a different email address, you
> should
> either use that other email address or update your list membership
> with the
> new email address.
> 
> 
> For further information, please contact packages-
> requ...@lists.fusiondirectory.org

this is a direct violation of the Debian policy, which states in 3.3:
> The email address given in the Maintainer control field must accept
> mail from those role accounts in Debian used to send automated mails
> regarding the package.

please fix this issue.

gfmasdr
IOhannes


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fusiondirectory depends on:
ii  apache2 [httpd] 2.4.25-3+deb9u1
ii  fusiondirectory-smarty3-acl-render  1.0.19-1
ii  gettext 0.19.8.1-2
ii  javascript-common   11
ii  libarchive-extract-perl 0.80-1
ii  libcrypt-cbc-perl   2.33-1
ii  libfile-copy-recursive-perl 0.38-1
ii  libjs-prototype 1.7.1-3
ii  libjs-scriptaculous 1.9.0-2
ii  libnet-ldap-perl1:0.6500+dfsg-1
ii  libpath-class-perl  0.37-1
ii  libperl5.24 [libdigest-sha-perl]5.24.1-3
ii  libterm-readkey-perl2.37-1
ii  libxml-twig-perl1:3.50-1
ii  openssl 1.1.0f-3
ii  php 1:7.0+49
ii  php-cas 1.3.3-4
ii  php-curl1:7.0+49
ii  php-fpdf3:1.8.1.dfsg-2
ii  php-gd  1:7.0+49
ii  php-imagick 3.4.3~rc2-2
ii  php-imap1:7.0+49
ii  php-ldap1:7.0+49
ii  php-recode  1:7.0+49
ii  php7.0 [php]7.0.19-1
ii  php7.0-cli [php-cli]7.0.19-1
ii  php7.0-curl [php-curl]  7.0.19-1
ii  php7.0-gd [php-gd]  7.0.19-1
ii  php7.0-imap [php-imap]  7.0.19-1
ii  php7.0-ldap [php-ldap]  7.0.19-1
ii  php7.0-recode [php-recode]  7.0.19-1
ii  schema2ldif 1.2-1
ii  smarty-gettext  1.5.0-2
ii  smarty3 3.1.31+20161214.1.c7d42e4+selfpack1-2

fusiondirectory recommends no packages.

Versions of packages fusiondirectory suggests:
pn  argonaut-server 
ii  fusiondirectory-schema  1.0.19-1
ii  slapd   2.4.44+dfsg-5

-- Configuration Files:
/etc/fusiondirectory/fusiondirectory-apache.conf changed [not included]

-- no debconf information

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fusiondirectory depends on:
ii  apache2 [httpd] 2.4.25-3+deb9u1
ii  fusiondirectory-smarty3-acl-render  1.0.19-1
ii  gettext 0.19.8.1-2
ii  javascript-common   11
ii  libarchive-extract-perl 0.80-1
ii  libcrypt-cbc-perl   2.33-1
ii  libfile-copy-recursive-perl 0.38-1
ii  libjs-prototype 1.7.1-3
ii  libjs-scriptaculous 1.9.0-2
ii  libnet-ldap-perl1:0.6500+dfsg-1
ii  libpath-class-perl  0.37-1
ii  libperl

Bug#868027: wiliki: Unquoted keyword `:full'

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wiliki
Severity: normal
Version: 0.6.2-1

Dear Maintainer,

I noticed wiliki 0.6.2-1 on Stretch produced a warning to Web server's
log for every access.

- 
WARNING: Unquoted keyword `:full' in match pattern: args.  This would likely 
break in future versions of Gauche.  See the ``Keyword and symbol integration'' 
section of the manual for the details" while reading upstream, client: , 
server: , request: "GET / HTTP/1.1", upstream: 
"fastcgi://unix:/var/run/fcgiwrap.socket:", host: ""
- 

gauche is 0.9.5-1.

Regards,
- -- 
Kenshi Muto
km...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Processed by Mailcrypt 3.5.9 

iQIcBAEBCgAGBQJZZJ/qAAoJEB0hyD3EUuD8N2MP/208vSgmo3DJ+DBAaC/hiqm8
M3IYwAxBFc9ruJ3RUbYn9GC4oVvKJs4H0fNBEQyr5NS6yIlsVQQ8aHt7dP0c37L8
5mR/9heOZGVgdjqqTkA6jQYP+LSo7y2ZlU0Q7zMXdQZHpVV1pXiSW5mKBv82Mqsw
5oRWqgtpG2rU6Cr+Ro5URIScMopPo9Gsu2PbNttuzYl7xZKVGisg5v2RvRy/YD7N
h3vdq87rG7MIriIoLzCt3OfcZFUIYgyiXnO60FYIIA3QUTnhPTE0TC/z5iquE+I2
g/75m8GzIDaiJdStvDc5gG3dQ8bjrNOvAyT0Ab4a7vE2apFlUqa8ibu+W2Dkf2mb
63m2B7NIcB7mj/6xDR+5aDFVdea6mH9aUd05+bG8y0Xe545BEfAcI2iqoJUvJTaq
Tjj7ZZ9zjF4291aBMmwWSjrSTwx+urJpnFwLisx1ui/bgNzs1k1qlerFCCqTfrEg
+CB03A69f/wty6v4ujnEt5Zy1BDwQYBxNj+p99jX+3Hpe8cHjM68UuyX21pvOhf6
fmHDNDgI2EHD543jXyoVDhAfP2C6FTks3SlugQxdF15lOrg3tmfBpHhAzEVqeoRR
neB/p9O0bxYS3/Vi3hbshcbmU+C4ulRm17Vvme42K20Cwb3Al7ykVFc3Kf4bpOkY
mniorNX9cf/anBX9jOW6
=/5of
-END PGP SIGNATURE-

Bug#868028: wiliki: Unquoted keyword `:full'

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wiliki
Severity: normal
Version: 0.6.2-1

Dear Maintainer,

I noticed wiliki 0.6.2-1 on Stretch produced a warning to Web server's
log for every access.

- 
WARNING: Unquoted keyword `:full' in match pattern: args.  This would likely 
break in future versions of Gauche.  See the ``Keyword and symbol integration'' 
section of the manual for the details" while reading upstream, client: , 
server: , request: "GET / HTTP/1.1", upstream: 
"fastcgi://unix:/var/run/fcgiwrap.socket:", host: ""
- 

gauche is 0.9.5-1.

Regards,
- -- 
Kenshi Muto
km...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Processed by Mailcrypt 3.5.9 

iQIcBAEBCgAGBQJZZJ/qAAoJEB0hyD3EUuD8N2MP/208vSgmo3DJ+DBAaC/hiqm8
M3IYwAxBFc9ruJ3RUbYn9GC4oVvKJs4H0fNBEQyr5NS6yIlsVQQ8aHt7dP0c37L8
5mR/9heOZGVgdjqqTkA6jQYP+LSo7y2ZlU0Q7zMXdQZHpVV1pXiSW5mKBv82Mqsw
5oRWqgtpG2rU6Cr+Ro5URIScMopPo9Gsu2PbNttuzYl7xZKVGisg5v2RvRy/YD7N
h3vdq87rG7MIriIoLzCt3OfcZFUIYgyiXnO60FYIIA3QUTnhPTE0TC/z5iquE+I2
g/75m8GzIDaiJdStvDc5gG3dQ8bjrNOvAyT0Ab4a7vE2apFlUqa8ibu+W2Dkf2mb
63m2B7NIcB7mj/6xDR+5aDFVdea6mH9aUd05+bG8y0Xe545BEfAcI2iqoJUvJTaq
Tjj7ZZ9zjF4291aBMmwWSjrSTwx+urJpnFwLisx1ui/bgNzs1k1qlerFCCqTfrEg
+CB03A69f/wty6v4ujnEt5Zy1BDwQYBxNj+p99jX+3Hpe8cHjM68UuyX21pvOhf6
fmHDNDgI2EHD543jXyoVDhAfP2C6FTks3SlugQxdF15lOrg3tmfBpHhAzEVqeoRR
neB/p9O0bxYS3/Vi3hbshcbmU+C4ulRm17Vvme42K20Cwb3Al7ykVFc3Kf4bpOkY
mniorNX9cf/anBX9jOW6
=/5of
-END PGP SIGNATURE-

Bug#868029: stretch-pu: package gnats/4.1.0-3+deb9u1

[Andreas Beckmann]

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

gnats-user fails to purge if gnats was installed but has not been
purged, yet. This is triggered by several piuparts tests (currently
ignored, but I want to promote that to a proper failure without working
around it in piuparts).
This will add NEW -dbgsym packages to stretch, I hope that is no
problem.
The patch is trivial, just adding a --ignore-fail-on-non-empty.
The fix (and some more QA changes) was just uploaded to sid.

If this is accepted, I'd like to upload the same change to jessie (with
just s/stretch/jessie/;s/deb9u1/deb8u1/ on the changelog, since stretch
and jessie currently have the same version.


Andreas
diff -Nru gnats-4.1.0/debian/changelog gnats-4.1.0/debian/changelog
--- gnats-4.1.0/debian/changelog	2014-01-09 14:44:49.0 +0100
+++ gnats-4.1.0/debian/changelog	2017-07-11 11:50:23.0 +0200
@@ -1,3 +1,11 @@
+gnats (4.1.0-3+deb9u1) stretch; urgency=medium
+
+  * QA upload.
+  * gnats-user.postrm: Do not fail to purge if /var/lib/gnats/gnats-db is not
+empty.  (Closes: #661015)
+
+ -- Andreas Beckmann   Tue, 11 Jul 2017 11:50:23 +0200
+
 gnats (4.1.0-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru gnats-4.1.0/debian/gnats-user.postrm.in gnats-4.1.0/debian/gnats-user.postrm.in
--- gnats-4.1.0/debian/gnats-user.postrm.in	2012-01-01 10:50:41.0 +0100
+++ gnats-4.1.0/debian/gnats-user.postrm.in	2017-07-11 11:50:23.0 +0200
@@ -22,7 +22,7 @@
 #
 
 if [ "$1" = "purge" ] && [ -d "@GNATSDBDIR@" ]; then
-	rmdir "@GNATSDBDIR@"
+	rmdir --ignore-fail-on-non-empty "@GNATSDBDIR@"
 fi
 ###
 #

Bug#868024: maintainer address broken

[Debian/GNU]

Control: submitter -1 umlae...@debian.org
thanks

On 2017-07-11 12:00, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.

sorry for the mess in this bugreport (i was fighting a crashing reportbug).
for the sake of readability, i repeat the actual bug-report:


the email address of fusiondirectory's maintainer is
.
Unfortunately this mailinglist rejects mails from non-subscribers with
the following message:

On 2017-07-10 16:37, SYMPA wrote:
> Your message for list 'packages' (attached below) was rejected.
> You are not allowed to send this message for the following reason:
>
>  Message distribution in the list is restricted to list subscribers.
> If you are subscribed to the list with a different email address, you
> should
> either use that other email address or update your list membership
> with the
> new email address.
>
>
> For further information, please contact packages-
> requ...@lists.fusiondirectory.org

this is a direct violation of the Debian policy, which states in §3.3:
> The email address given in the Maintainer control field must accept
> mail from those role accounts in Debian used to send automated mails
> regarding the package.

please fix this issue.

gfmasdr
IOhannes

Bug#868025: Tryton suite 4.4 blocked in unstable

[Mathias Behrle]

* Mathias Behrle: " Bug#868025: Tryton suite 4.4 blocked in unstable" (Tue, 11
  Jul 2017 11:53:43 +0200):

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> X-Debbugs-CC: maintain...@debian.tryton.org
> 
> Dear release managers,
> 
> currently the whole Tryton series 4.4 is stuck in unstable[0]. All Tryton
> modules incl. server are marked as valid candidates. 
> 
> The only problem is with  
> 
> Excuse for tryton-meta
> 
> Migration status: BLOCKED: Cannot migrate due to another item, which is
> blocked (please check which dependencies are stuck)
> 22 days old (needed 5 days)
> Piuparts tested OK -
> https://piuparts.debian.org/sid/source/t/tryton-meta.html
> Invalidated by dependency 
> 
> which depends on all Tryton modules >=4.4 and thus should be ok?
> 
> Could please someone help me to sort out, how to get the packages migrated?
> 
> Thanks,
> Mathias
> 
> 
> NB:
> Some Tryton modules (calendar*, party_vcard_dav, webdav) were discontinued and
> removed from unstable, but they were also removed from tryton-meta.
> 
> 
> [0] https://qa.debian.org/developer.php?login=mbeh...@debian.org

I think, I got one/the problem.

Current tryton-meta in testing still refers to the removed modules and is
basically a corrupt package (which I forgot to let remove together with the
discontinued packages). So tryon-meta won't be able to migrate until the old
tryton-meta is out of the way.

I still don't understand, why e.g. tryton-server does not migrate.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpDPyzRhix_8.pgp
Description: Digitale Signatur von OpenPGP

Bug#867402: Debootstrap Error Couldn't retrieve dists/stretch/main/binary-amd64/Packages

[jg]

Hello,

I now made dozens of test installing from snapshot.debian.org  and I get random 
problems.
Most of the time i get a Debootstrap Error that 
dist/stretch/main/binary-amd64/Packages could not be retrieved
but also libacl1, adduser, and others can't be downloaded.

Installing from ftp.de.debian.org always works.

I am now very sure that the problem is that snapshot.debian.org is very 
unreliable.

Can you please assign this bug to "Package: snapshot.debian.org" ?

Thanks

 

Bug#867541: please build ruby binding of grpc

[GCS]

On Tue, Jul 11, 2017 at 11:12 AM, Steinar H. Gunderson  wrote:
> On Tue, Jul 11, 2017 at 10:07:58AM +1000, Andrew Pollock wrote:
>>> Andrew, please link me to the grpc-packages link/account if possible.
>>> It's bad that I can't follow this package from the first hand.
>> Sorry, can you please clarify what you're asking for here?
>
> Maintainer: gRPC Package Maintainers 
>
> Presumably he wants to be added to that list.
 +1, all uploads, bugreports, migration, etc mails go to the email
address specified in the maintainer field. That's why it's usually a
mailing list and anyone can subscribe to it. At the moment I don't get
mails sent to grpc-packages@ and I'm kind of blind about the package.

Laszlo/GCS

Bug#863981: check_ping uses IPv6 with -4

[Jan Wagner]

Dear Stefan,

Am 11.07.17 um 11:07 schrieb Stefan Bühler:
> You didn't get the issue.  I know very well how to call check_ping with
> -4 - I can do that with my local config.  But check_ping -4 DOES NOT
> call "ping -4" - it just calls "ping".  The -4 option does *NOTHING*. It
> basically is the same as not passing "-6".

just adding "-4" to the "ping-command" in debian/rules will solve this
problem but cause others.

<- snip ->
Depends: inetutils-ping (>= 2:1.9-1~) [kfreebsd-any hurd-any],
 iputils-ping [linux-any],
<- snap ->

inetutils-ping and older iputils-ping (when backporting) doesn't support
"ping -4". So this is something that has to be discovered at buildtime I
think.

> Also there is no package providing /etc/nagios-plugins/config/ping.cfg.
> Maybe you meant /usr/share/monitoring-plugins/templates-basic/ping.cfg ?
> But not really relevant at all.

Indeed, but ping.cfg is copied by ucf via maintainers script to
/etc/nagios-plugins/config/.

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#867512: [Pkg-ayatana-devel] Bug#867512: python-ayatana-appindicator: Traceback when trying to import

[Mike Gabriel]

Hi,

On  Fr 07 Jul 2017 00:44:18 CEST, Unit 193 wrote:


Package: python-ayatana-appindicator
Version: 0.5.0-1
Severity: important

Dear Maintainer,

When trying to import ayatana_appindicator I get traceback:


import ayatana_appindicator

Traceback (most recent call last):
  File "", line 1, in 
  File  
"/usr/lib/python2.7/dist-packages/ayatana_appindicator/__init__.py",  
line 27, in 

from _ayatana_appindicator import *
ImportError:  
/usr/lib/python2.7/dist-packages/ayatana_appindicator/_ayatana_appindicator.i386-linux-gnu.so: undefined symbol:  
pyappindicator_functions


this is an upstream issue, but let's continue the discussion here...

I looked today and this is merely a reminder for me... It seems there  
is some namespacing problem in the python2 bindings code:


```
/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H  
-I. -I../../../../bindings/python -I../.. -I../../../../src  
-DG_LOG_DOMAIN=\"ayatana-appindicator-python\"  
-DDATADIR=\"/usr/share\" -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\"  
-pthread -I/usr/include/gtk-2.0  
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include  
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo  
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo  
-I/usr/include/pixman-1 -I/usr/include/libpng16  
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16  
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz  
-I/usr/include/pango-1.0 -I/usr/include/freetype2  
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  
-I/usr/include/pygtk-2.0 -I/usr/include/python2.7  
-I/usr/include/x86_64-linux-gnu/python2.7  -Wdate-time  
-D_FORTIFY_SOURCE=2  -g -O2  
-fdebug-prefix-map=/home/mike/MyDocuments/4projects/arctica-upstream/+++Ayatana+++/libayatana-appindicator=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -c -o ayatana_appindicatormodule.lo  
../../../../bindings/python/ayatana_appindicatormodule.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I.  
-I../../../../bindings/python -I../.. -I../../../../src  
-DG_LOG_DOMAIN=\"ayatana-appindicator-python\"  
-DDATADIR=\"/usr/share\" -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\"  
-pthread -I/usr/include/gtk-2.0  
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include  
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo  
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo  
-I/usr/include/pixman-1 -I/usr/include/libpng16  
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16  
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz  
-I/usr/include/pango-1.0 -I/usr/include/freetype2  
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  
-I/usr/include/pygtk-2.0 -I/usr/include/python2.7  
-I/usr/include/x86_64-linux-gnu/python2.7 -Wdate-time  
-D_FORTIFY_SOURCE=2 -g -O2  
-fdebug-prefix-map=/home/mike/MyDocuments/4projects/arctica-upstream/+++Ayatana+++/libayatana-appindicator=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -c ../../../../bindings/python/ayatana_appindicatormodule.c  -fPIC -DPIC -o  
.libs/ayatana_appindicatormodule.o
../../../../bindings/python/ayatana_appindicatormodule.c: In function  
?init_appindicator?:
../../../../bindings/python/ayatana_appindicatormodule.c:47:3:  
warning: implicit declaration of function  
?_appindicator_add_constants? [-Wimplicit-function-declaration]

   _appindicator_add_constants (m, "APP_INDICATOR_");
   ^~~
libtool: compile:  gcc -DHAVE_CONFIG_H -I.  
-I../../../../bindings/python -I../.. -I../../../../src  
-DG_LOG_DOMAIN=\"ayatana-appindicator-python\"  
-DDATADIR=\"/usr/share\" -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\"  
-pthread -I/usr/include/gtk-2.0  
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include  
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo  
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo  
-I/usr/include/pixman-1 -I/usr/include/libpng16  
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16  
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz  
-I/usr/include/pango-1.0 -I/usr/include/freetype2  
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  
-I/usr/include/pygtk-2.0 -I/usr/include/python2.7  
-I/usr/include/x86_64-linux-gnu/python2.7 -Wdate-time  
-D_FORTIFY_SOURCE=2 -g -O2  
-fdebug-prefix-map=/home/mike/MyDocuments/4projects/arctica-upstream/+++Ayatana+++/libayatana-appindicator=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -c ../../../../bindings/python/ayatana_appindicatormodule.c -o ayatana_appindicatormodule.o >/dev/null  
2>&1

(/usr/bin/python2.7 /usr/share/pygobject/2.0/codegen/codegen.py \
--register /usr/share/pygtk/2.0/defs/gtk-types.defs \
--register /usr/share/pygtk/2.0/defs/gdk-types.defs \
--load-types ../../../../bindings/python/appindicator-arg-types.py \
--override ayatana_appindicator.override \
--prefix pyayatana_appindicator  
../../../../bindings/python/ayatana_appindicator.defs) >  
gen-ayatana_appindicator.c \

 && cp gen-ayatana_appi

Bug#868030: qemu-user-static: Please enable "F - fix binary" flag for binfmt entries

[Ian Campbell]

Package: qemu-user-static
Version: 1:2.8+dfsg-6
Severity: wishlist

Dear Maintainer,

Please consider enabling the "F" flag in the binfmt entries which this package
adds. From https://www.kernel.org/doc/html/v4.12/admin-guide/binfmt-misc.html:

F - fix binary

The usual behaviour of binfmt_misc is to spawn the binary lazily when the
misc format file is invoked. However, this doesn``t work very well in the 
face
of mount namespaces and changeroots, so the F mode opens the binary as soon 
as
the emulation is installed and uses the opened image to spawn the emulator,
meaning it is always available once installed, regardless of how the
environment changes.

This is useful because it avoids the need to bind mount the qemu-user-static
binaries into the container/chroot/whatever.

The documentation entry appears to have been added in Linux v4.8-rc1 so I
pressume the feature was present at some point before then and is in any case
available in the 4.9 kernel used by Stretch, so enabling this in the Buster
onwards versions of this package ought to be reasonable I think.

I'm not sure if this also applies to the qemu-user-binfmt package, that's
dynamically linked and I confess I'm not sure how that works WRT chroots and
such.

Thanks,
Ian.

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

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.6-2

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.19p1-2.1

-- no debconf information

Bug#868031: uim: FTBFS with Qt 5.9: Could not find feature reduce_exports.

[Dmitry Shachnev]

Source: uim
Version: 1:1.8.6+gh20161003.0.d63dadd-2.1
Severity: important
Tags: upstream patch
Forwarded: https://github.com/uim/uim/pull/108
User: debian-qt-...@lists.debian.org
Usertags: qt5.9

Dear maintainer,

uim fails to build with Qt 5.9 (available in experimental):

  (when running qmake):
  Project ERROR: Could not find feature reduce_exports.
  WARNING: target.path is not defined: install target not created

  (later, when running make):
  make  -f Makefile.qmake INSTALL_ROOT= all
  make[4]: Entering directory 
'/<>/uim-1.8.6+gh20161003.0.d63dadd/qt5/immodule'
  make[4]: Makefile.qmake: No such file or directory
  make[4]: *** No rule to make target 'Makefile.qmake'.  Stop.

Full build log is available at:
https://launchpadlibrarian.net/324642605/buildlog_ubuntu-artful-amd64.uim_1%3A1.8.6+gh20161003.0.d63dadd-2ubuntu3%7Eppa1_BUILDING.txt.gz

Patch is available at:
https://github.com/uim/uim/pull/108

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#851937: RFS: farbfeld/2.20170109-1 ITP

[Paride Legovini]

Dear Sean,

Given the unfortunate situation of Dimitry, I'd like to take on where he
left and maintain the farbfeld package.

I'll be happy to appear as co-maintainer with him, or to be the only
maintainer and handle the maintainership back to Dimitry once he's back,
if he will still be interested.

I'm not sure what's the best practice here, so before doing any further
work I'll wait for your opinion.

Thank you,

Paride

Bug#867538: fop: Please implement sidebars floating at the side of the body of the text

[Petter Reinholdtsen]

[Mathieu Malaterre]
> Works in current fop:

Did the PDF you created contain the sidebar text?  I just tested in sid,
and could not find it in my PDF.

-- 
Happy hacking
Petter Reinholdtsen

Bug#867713: transition: gnome-panel 3.24

[Dmitry Shachnev]

On Sun, Jul 09, 2017 at 08:40:17PM +0100, Jonathan Wiltshire wrote:
> On Sun, Jul 09, 2017 at 09:03:07PM +0300, Dmitry Shachnev wrote:
> > * For gnubiff, sensors-applet and workrave you can schedule binNMUs.
>
> Scheduled.

Uim is now accepted and built fine.

So the remaining thing is removing command-runner-applet and old gnome-panel /
gnome-applets binaries.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#868032: python3-apt: InstallProgress doesn't call overridden methods

[Elia Argentieri]

Package: python3-apt
Version: 1.4.0~beta3+b1
Severity: normal

I can't get this to work:

class InstallProgress(apt.progress.base.InstallProgress):
def conffile(self, current, new):
super().conffile(current, new)
print("conffile")

def error(self, pkg, errormsg):
super().error(pkg, errormsg)
print("error")

def processing(self, pkg, stage):
super().processing(pkg, stage)
print("processing")

def dpkg_status_change(self, pkg, status):
super().dpkg_status_change(pkg, status)
print("dpkg_status_change")

def start_update(self):
super().start_update()
print("start_update")

def finish_update(self):
super().finish_update()
print("finish_update")

This is what it shows:

start_update
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 668129 files and directories currently installed.)
Preparing to unpack .../rkhunter_1.4.4-2_all.deb ...
Unpacking rkhunter (1.4.4-2) over (1.4.4-1) ...
Setting up rkhunter (1.4.4-2) ...
Installing new version of config file /etc/rkhunter.conf ...
Processing triggers for man-db (2.7.6.1-2) ...
finish_update



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

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

Versions of packages python3-apt depends on:
ii  libapt-inst2.0 1.5~beta1
ii  libapt-pkg5.0  1.5~beta1
ii  libc6  2.24-12
ii  libgcc11:7.1.0-9
ii  libstdc++6 7.1.0-9
ii  python-apt-common  1.4.0~beta3
ii  python33.5.3-3

Versions of packages python3-apt recommends:
ii  iso-codes3.75-1
ii  lsb-release  9.20161125

Versions of packages python3-apt suggests:
ii  apt  1.5~beta1
pn  python-apt-doc   
pn  python3-apt-dbg  

-- no debconf information

Bug#867895: Re[2]: Bug#867895: e2fsprogs: man ext4: it seems you document "commit" option for ext4 wrong

[Askar Safin]

Documentation/filesystems/ext4.txt contains this:

commit=nrsec(*) Ext4 can be told to sync all its data and metadata
every 'nrsec' seconds. The default value is 5 seconds.
This means that if you lose your power, you will lose
as much as the latest 5 seconds of work (your
filesystem will not be damaged though, thanks to the
journaling)

It seems this is wrong, please, fix it.

Bug#849150: patch proposal

[Frédéric Bonnard]

Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el 

--

Hi,
it just seems that there's too many space taken by different libraries
in the static TLS space. I contacted some people from the toolchain,
especially Alan Modra which seems to confirm that :
"If sagemath is dlopen'ing libraries, one of which is libgomp or has a
dependency on libgomp, and the sagemath executable itself does not load
libgomp at startup, then that would explain the error you're seeing."
Python binary has no direct dependency on libgomp :
$ lddtree /usr/bin/python2.7
python2.7 => /usr/bin/python2.7 (interpreter => /lib64/ld64.so.2)
libpthread.so.0 => /lib/powerpc64le-linux-gnu/libpthread.so.0
ld64.so.2 => /lib64/ld64.so.2
libdl.so.2 => /lib/powerpc64le-linux-gnu/libdl.so.2
libutil.so.1 => /lib/powerpc64le-linux-gnu/libutil.so.1
libz.so.1 => /lib/powerpc64le-linux-gnu/libz.so.1
libm.so.6 => /lib/powerpc64le-linux-gnu/libm.so.6
libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6

And also :
sagemath-7.6/sage# LD_DEBUG=files
PYTHONPATH=/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages
/build/sagemath-wDWVd1/sagemath-7.6/sage/src/bin/sage --docbuild
--no-pdf-links all html
...
 51918: 
file=/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0];  dynamically loaded by python [0]
 51918: 
file=/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0];  generating link map
 51918:   dynamic: 0x3feecae0fb30  base: 0x3feecad6   size: 
0x000bf9c8
 51918: entry: 0x3feecad7c020  phdr: 0x3feecad60040  phnum: 
 7
 51918: 
 51918: 
 51918: file=liblinbox-1.4.2.so.0 [0];  needed by 
/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0]
 51918: file=liblinbox-1.4.2.so.0 [0];  generating link map
 51918:   dynamic: 0x3feecad4f518  base: 0x3feecad0   size: 
0x000513e0
 51918: entry: 0x3feecad14fc0  phdr: 0x3feecad00040  phnum: 
 7
 51918: 
 51918: 
 51918: file=liblinboxsage-1.4.2.so.0 [0];  needed by 
/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0]
 51918: file=liblinboxsage-1.4.2.so.0 [0];  generating link map
 51918:   dynamic: 0x3feecacec368  base: 0x3feecaa7   size: 
0x00280ed0
 51918: entry: 0x3feecab16880  phdr: 0x3feecaa70040  phnum: 
 7
 51918: 
 51918: 
 51918: file=libblas.so.3 [0];  needed by 
/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0]
 51918: file=libblas.so.3 [0];  generating link map
 51918:   dynamic: 0x3feecaa5f5d0  base: 0x3feeca9e   size: 
0x000806e8
 51918: entry: 0x3feeca9ffd40  phdr: 0x3feeca9e0040  phnum: 
 6
 51918: 
 51918: 
 51918: file=liblapack.so.3 [0];  needed by 
/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages/sage/matrix/matrix_modn_dense_float.so
 [0]
 51918: file=liblapack.so.3 [0];  generating link map
 51918:   dynamic: 0x3feeca9cfbd0  base: 0x3feeca3f   size: 
0x005e4098
 51918: entry: 0x3feeca410100  phdr: 0x3feeca3f0040  phnum: 
 6
 51918: 
 51918: 
 51918: file=libgomp.so.1 [0];  needed by 
/usr/lib/powerpc64le-linux-gnu/liblinbox-1.4.2.so.0 [0]
 51918: file=libgomp.so.1 [0];  generating link map
 51918:   dynamic: 0x3feeca3dfcc0  base: 0x3feeca39   size: 
0x000505b0
 51918: entry: 0x3feeca396bc0  phdr: 0x3feeca390040  phnum: 
 7
 51918: 
 51918: 
 51918: file=libopenblas.so.0 [0];  needed by /usr/lib/libblas.so.3 [0]
 51918: file=libopenblas.so.0 [0];  generating link map
 51918:   dynamic: 0x3feeca36f2d0  base: 0x3feec996   size: 
0x00a279e0
 51918: entry: 0x3feec99a88c0  phdr: 0x3feec9960040  phnum: 
 6
...

...
So the failure occurs while importing the python module 
matrix_modn_dense_float.so.
So I propose to preload libgomp which looks good to Alan.

As Ximin explained, this workaround should not be applied on
documentation build only, as the import should trigger the error on the
CLI as well, thus I inserted LD_PRELOAD export in sage-env, for ppc64el
only. So here is a debdiff for you to review.
I hope that will help,

Thanks,

F.
diff -Nru sagemath-7.6/debian/adhoc/sage-env sagemath-7.6/debian/adhoc/sage-env
--- sagemath-7.6/debian/adhoc/sage-env  2017-01-25 15:28:45.0 +
+++ sagemath-7.6/debian/adhoc/sage-env  2017-05-08 13:31:50.00

Bug#866014: Unable to use store

[Reiner Herrmann]

Hi Martin,

On Sat, Jul 01, 2017 at 01:53:41PM +0200, Martin Dosch wrote:
> now I realized that I am unable to open the store and have a look at
> achievements etc.
> It seems like everything using the integrated browser (steamwebhelper)
> stopped working.
> I am not sure if this is also caused by the latest changes in the steam
> profile but running steam without firejail it works as intended.
> 
> I attached the terminal output of "firejail --trace steam" with opening
> steam and trying to open the store.

Sorry for the late reply.
Someone on the upstream bugtracker [0] commented that disabling 'tracelog'
in the steam.profile fixes the store (integrated browser).
I can confirm it, with tracelog disabled the browser is working for me.

Regards,
  Reiner

[0]: https://github.com/netblue30/firejail/issues/1280#issuecomment-312477855


signature.asc
Description: Digital signature

Bug#867728: duplicate of bug#867169

[Matus UHLAR - fantomas]

Hello,

this is duplicate of bug 867169
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867169

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.

Bug#868033: r-cran-xts: xts 0.10-0 is out

[Dirk Eddelbuettel]

Package: r-cran-xts
Version: 0.9-7-1
Severity: normal

The xts package, while being widely used, had not had an upstream update in
several years.  But now it has, and versioned Depends: start to appear.

Hence it would be nice if the package could be updated to 0.10-0.

As a fallback, I could do so in a NMU via the delayed queue in about a week.

Dirk

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

Bug#868034: haproxy: New HAProxy 1.7.8 fixes several bugs

[Yann Cézard]

Package: haproxy
Version: 1.7.5-2
Severity: normal


Dear Maintainer,

Upgrading from Jessie (haproxy 1.5.8-3+deb8u2) to Stretch (1.7.5-2)
leads us to some bad behaviour with some backends.

More specificaly, the use of a websocket was broken by the use of
compression.

A minor workaround was to disable compression for that backend.

This problem was introduced by some earlier patches between 1.5.3 and
1.5.5.
More information on those threads :
https://www.mail-archive.com/haproxy@formilux.org/msg25349.html
 => Inital report with patch for 1.7.3 that later introduced other
  problems
https://www.mail-archive.com/haproxy@formilux.org/msg26621.html
 => Last report with fix in 1.7.8

So the new HAProxy 1.7.8 version has corrected this problem (and others, 
perhaps more important but which didn't impacted us). I have tested with the
sid package version, all is fine.

Is it planned to backport those patches in stretch / stretch-updates ?
Or should we wait for a backport ?

Regards,

Yann


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

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

Versions of packages haproxy depends on:
ii  adduser  3.115
ii  dpkg 1.18.24
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  liblua5.3-0  5.3.3-1
ii  libpcre3 2:8.39-3
ii  libssl1.11.1.0f-3
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

haproxy recommends no packages.

Versions of packages haproxy suggests:
pn  haproxy-doc  
ii  vim-haproxy  1.7.5-2

-- Configuration Files:
/etc/haproxy/haproxy.cfg changed [not included]
/etc/logrotate.d/haproxy changed [not included]
/etc/rsyslog.d/49-haproxy.conf changed [not included]

-- no debconf information

Bug#868035: krb5: [patch]: ldap sasl auth support

[Hideki Yamane]

Package: krb5
Severity: wishlist
Tags: patch

Hi,

 Since 1.3.1, it seems that SASL authentication to the LDAP KDB module
 was supported.
 See https://k5wiki.kerberos.org/wiki/Projects/LDAP_SASL_support

 configure script checks sasl.h, without libsasl2-dev

> checking sasl/sasl.h usability... no
> checking sasl/sasl.h presence... no
> checking for sasl/sasl.h... no
> configure: WARNING: not building LDAP SASL support

 However, with libsasl2-dev as attached patch, it seems that is enabled.

> checking sasl/sasl.h usability... yes
> checking sasl/sasl.h presence... yes
> checking for sasl/sasl.h... yes


 So, could you apply and check it, please?

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
>From 4458369fd73648d32a57c88cf2272ef54b80a764 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Tue, 11 Jul 2017 20:16:36 +0900
Subject: [PATCH] support SASL

---
 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index c663f1ec3..551c7da09 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.15.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control
+- add Build-Depends: libsasl2-dev to support SASL on LDAP 
+
+ -- Hideki Yamane   Tue, 11 Jul 2017 20:16:11 +0900
+
 krb5 (1.15.1-1) unstable; urgency=medium
 
   *  New Upstream Version
diff --git a/debian/control b/debian/control
index 581a3eb2f..20d59be67 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: standard
 Build-Depends: debhelper (>= 10), byacc | bison,
  comerr-dev, docbook-to-man, 
  libkeyutils-dev [linux-any], libldap2-dev ,
- libncurses5-dev, libssl-dev,  ss-dev, 
+ libncurses5-dev, libssl-dev,  ss-dev, libsasl2-dev,
  libverto-dev (>= 0.2.4), pkg-config, dh-systemd
 Build-Depends-Indep: python, python-cheetah, python-lxml, python-sphinx, doxygen, doxygen-latex, texlive-generic-extra
 Standards-Version: 3.9.8
-- 
2.13.2

Bug#862918: libjs-bignumber: New version available upstream: 4.0.2

[Ben Finney]

Control: retitle -1 libjs-bignumber: New version available upstream: 4.0.2

On 20-May-2017, Jonas Smedegaard wrote:
> Quoting Pirate Praveen (2017-05-20 07:57:32)
> > Most likely this was packaged as a dependency of another package
> > and that package no longer needs it.
> 
> Debian packages should be _maintained_, not only packaged. All
> packages, not only topmost ones in dependency trees!

I agree with that. But I also agree with Praveen's point you omitted:


On 20-May-2017, Pirate Praveen wrote:
> node-bignumber is a dependency on node-mysql. Seems newer version of
> node-mysql just work fine with the current node-bignumber. If we
> have to update, we should make sure it does not break node-mysql.


Both of these – incorporate new upstream versions, don't break
dependent packages – are important facets of maintaining a Debian
package.

Sometimes these two important directions conflict. What should be done
if the new upstream version breaks dependent packages without offering
an upgrade path?

-- 
 \   “Only good questions deserve good answers.” —Oscar Wilde, _De |
  `\  Profundis_, 1897 |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#808151: pr submitted

[Michael Biebl]

On Sun, 9 Jul 2017 23:14:17 + Zbigniew
=?utf-8?Q?J=C4=99drzejewski-Szmek?=  wrote:
> https://github.com/systemd/systemd/pull/6316

Frank, would you be willing to test this patch to check if it fixes your
problem?

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



signature.asc
Description: OpenPGP digital signature

Bug#863981: check_ping uses IPv6 with -4

[Stefan Bühler]

Hi Jan,

On 07/11/2017 12:29 PM, Jan Wagner wrote:
> Dear Stefan,
> 
> Am 11.07.17 um 11:07 schrieb Stefan Bühler:
>> You didn't get the issue.  I know very well how to call check_ping with
>> -4 - I can do that with my local config.  But check_ping -4 DOES NOT
>> call "ping -4" - it just calls "ping".  The -4 option does *NOTHING*. It
>> basically is the same as not passing "-6".
> 
> just adding "-4" to the "ping-command" in debian/rules will solve this
> problem but cause others.
> 
> <- snip ->
> Depends: inetutils-ping (>= 2:1.9-1~) [kfreebsd-any hurd-any],
>  iputils-ping [linux-any],
> <- snap ->
> 
> inetutils-ping and older iputils-ping (when backporting) doesn't support
> "ping -4". So this is something that has to be discovered at buildtime I
> think.

That is a problem of course.

Maybe adding a separate "ping4-command" compile time string is an option.

cheers,
Stefan

Bug#867794: python3-pyqt5: App tray icon won't show if show() before systray is available

[Dmitry Shachnev]

Control: reassign -1 libqt5widgets5 5.7.1+dfsg-4
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-61898

Hi Jérôme,

On Sun, Jul 09, 2017 at 10:56:05PM +0200, Jérôme wrote:
> Here's a minified example to reproduce the issue :
>
> [...]
>
> Remove systray applet from panel, launch code, add systray applet. The
> icon does not show up.

This is a bug in Qt, and I can confirm it with Qt 5.9 and C++ code.

If you want to workaround this in your code, do not call show() unless
QSystemTrayIcon.isSystemTrayAvailable() returns True.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#863981: check_ping uses IPv6 with -4

[Jan Wagner]

Hi Stefan,

Am 11.07.17 um 14:11 schrieb Stefan Bühler:
> Maybe adding a separate "ping4-command" compile time string is an option.

the problem is not the string, but the reliable detection (which
hopefully doesn't break in the feature again).

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#868036: im-config: Add Czech language strings to the desktop file

[asciiwolf]

Package: im-config
Version: 0.30-1
Severity: minor

Current im-config desktop file does not contain any strings translated to the 
Czech language. The attached patch adds them.

im-config.desktop.patch
Description: Binary data

Bug#868037: libunwind-dev: broken signal handling on x86_64

[Roman Tsisyk]

Package: libunwind-dev
Version: 1.1-4.1
Severity: important

Dear Maintainer,

The latest version of libunwind8 package available in Debian repository
has significant problems with signal handling. I noted that setcontext()
implementation on x86_64 calls sigprocmask() with random uninitialized values,
which leads to unpredictable behaviour for aplications which uses signals.

Moreover, due to fact that "--enable-cxx-exceptions" is turned on by default,
libunwind may be used (it depends on the link order) by C++ runtime to throw
C++ exceptions. That means that almost all C++ applications linked with
libunwind.so.8 are broken too.

This problem has already been fixed by upstream [1].

[1] git://git.sv.gnu.org/libunwind.git

Could you please update libunwind package in Debian?


commit 29483327bebaf6e0141a9bee8bb99552a63f1583
Author: Dave Watson 
Date:   Wed Nov 30 11:40:20 2016 -0800

x86_64: Use sigprocmask from signal frames

Currently setcontext for x86_64 restores the signal mask, even
though it is never saved anywhere.  This means the signal mask
is often garbage after an unw_resume.

(changed in commit f8a15e9679e59872ca2)

It looks like this was a fix for the Gtest-resume-sig function -
testing if signal masks are restored across signal frames.  The
root issue looks like that x86_64 only uses sigreturn for the exact
signal frame, and not for any decedant frames as well (as i64 does).

Instead, modify Gresume to use sigreturn if *any* frame on the stack
is a signal frame, so that we correct fixup the signal mask and any
sigaltstacks.  The sigreturn os-specific functions are changed slightly
to copy in the saved ucontext structure if we are jumping farther
up the stack.

This should fix sigprocmask reported issues such as

https://github.com/dropbox/pyston/blob/master/libunwind_patches/0002-pyston-stop-x86_64-setcontext-restoring-uninitialize.patch

Tests pass on freebsd, linux



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (990, 'stable'), (600, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, i386

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

Versions of packages libunwind-dev depends on:
ii  libunwind8  1.1-4.1

libunwind-dev recommends no packages.

libunwind-dev suggests no packages.

-- no debconf information

-- 
WBR,
  Roman Tsisyk 
  http://tarantool.org/

Bug#868038: sddm fails to run jwm and maybe others wm (like bug report #821950 with gdm3)

[darthcat]

Package: sddm
Version: 0.14.0-4
Severity: important
Tags: upstream

Dear Maintainer,

This bug report is exactly the same as #821950 (which remains current): sddm
has got the same problem as gdm3, and my screenshot also remains current.

gdm3 and sddm aren't able to correctly run these wm any more. They just run
correctly mainly Gnome, KDE and Xfce.

Please see my former screenshot to know what all this is about.

Best regards.

Philippe



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

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

Versions of packages sddm depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libpam0g  1.1.8-3.6
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5qml55.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libstdc++66.3.0-18
ii  libsystemd0   232-25
ii  libxcb-xkb1   1.12-1
ii  libxcb1   1.12-1
ii  qml-module-qtquick2   5.7.1-2+b2
ii  x11-common1:7.7+19
ii  xserver-xephyr [xserver]  2:1.19.2-1
ii  xserver-xorg [xserver]1:7.7+19

Versions of packages sddm recommends:
ii  libpam-systemd   232-25
ii  sddm-theme-debian-maui [sddm-theme]  0.14.0-4

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.4-1

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#867669: monit summary doesn't detect rxvt as color terminal

[Sergey B Kirpichev]

tag 867669 + upstream fixed-upstream
thanks

On Tue, Jul 11, 2017 at 10:46:04AM +0200, mart...@tildeslash.com wrote:
> the problem was fixed in the upstream: 
> https://bitbucket.org/tildeslash/monit/commits/cf945190e280948f757646bd1fa7497a7f184434

So, this will be fixed with next upload to unstable, I hope.

I don't think that the problem is severe enough to enter
proposed-updates, etc.

> > On 8 Jul 2017, at 13:56, Alexander Schier  wrote:
> > 
> > Package: monit
> > Version: 5.20.0-6
> > Severity: normal
> > 
> > Dear Maintainer,
> > when running "monit summary" in rxvt with TERM=rxvt-unicode I get a
> > plain dumb-terminal output. When running it in the same terminal as
> > "TERM=xterm monit summary" I get a nicely formatted table with colors
> > indicating the status of the services.
> > It seems, that monit needs a longer list of terminals supporting colors
> > and/or a switch to force colored output.
> > 
> > 
> > with kind regards,
> > Alexander Schier
> > 
> > 
> > -- System Information:
> > Debian Release: buster/sid
> >  APT prefers testing
> >  APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: sysvinit (via /sbin/init)
> > 
> > Versions of packages monit depends on:
> > ii  libc6  2.24-12
> > ii  libpam0g   1.1.8-3.6
> > ii  libssl1.1  1.1.0f-3
> > ii  lsb-base   9.20161125
> > ii  zlib1g 1:1.2.8.dfsg-5
> > 
> > monit recommends no packages.
> > 
> > Versions of packages monit suggests:
> > ii  postfix [mail-transport-agent]  3.2.2-1
> > ii  sysvinit-core   2.88dsf-59.9
> > 

Bug#868039: system-config-printer-common: Package gir1.2-gnomekeyring-1.0 recommended only but system-config-printer does not work without it.

[Tomas Safarik]

Package: system-config-printer-common
Version: 1.5.9-2
Severity: normal

Dear Maintainer,

   I installed only necessary (Depends) packages for
   system-config-printer but I was unable to run it. I got following
   error:

$ system-config-printer

** (system-config-printer.py:3342): WARNING **: Error retrieving
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown:
The name org.a11y.Bus was not provided by any .service files
Traceback (most recent call last):
 File "/usr/share/system-config-printer/system-config-printer.py", line
  84, in 
  import jobviewer
 File "/usr/share/system-config-printer/jobviewer.py", line 57,
  in 
gi.require_version('GnomeKeyring', '1.0')
 File "/usr/lib/python3/dist-packages/gi/__init__.py", line
 118, in require_version
   raise ValueError('Namespace %s not available' %
  namespace)
 ValueError: Namespace GnomeKeyring not available* What was the outcome of this 
action?
   * What outcome did you expect instead?

   After installing package gir1.2-gnomekeyring-1.0 it works ok.

   I think that gir1.2-gnomekeyring-1.0 should be in section Depends.

Regards,

Tomas

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

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

Versions of packages system-config-printer-common depends on:
ii  gir1.2-gdkpixbuf-2.0  2.36.5-2
ii  gir1.2-glib-2.0   1.50.0-1+b1
ii  gir1.2-gtk-3.03.22.16-1
ii  gir1.2-notify-0.7 0.7.7-2
ii  gir1.2-pango-1.0  1.40.6-1
ii  python3   3.5.3-3
ii  python3-cairo 1.10.0+dfsg-5+b3
ii  python3-cups  1.9.73-1+b1
ii  python3-cupshelpers   1.5.9-2
ii  python3-dbus  1.2.4-1+b2
ii  python3-gi3.22.0-2+b1
ii  python3-requests  2.12.4-1

Versions of packages system-config-printer-common recommends:
ii  cups-pk-helper  0.2.6-1+b1
ii  gir1.2-gnomekeyring-1.0 3.12.0-1+b2
ii  python3-smbc1.0.15.6-1+b1
ii  system-config-printer-udev  1.5.9-2

Versions of packages system-config-printer-common suggests:
pn  gnome-software  

-- no debconf information

Bug#868040: O: louie -- Python signal dispatching mechanism

[Loïc Minier]

Package: wnpp

Hi,

louie used to be required by another package but should now be ok to
remove from the archive unless someone wants to adopt it.

Best,
-- 
Loïc Minier

Bug#868034: [Pkg-haproxy-maintainers] Bug#868034: haproxy: New HAProxy 1.7.8 fixes several bugs

[Vincent Bernat]

 ❦ 11 juillet 2017 13:46 +0200, Yann Cézard  :

> Upgrading from Jessie (haproxy 1.5.8-3+deb8u2) to Stretch (1.7.5-2)
> leads us to some bad behaviour with some backends.
>
> More specificaly, the use of a websocket was broken by the use of
> compression.
>
> A minor workaround was to disable compression for that backend.
>
> This problem was introduced by some earlier patches between 1.5.3 and
> 1.5.5.
> More information on those threads :
> https://www.mail-archive.com/haproxy@formilux.org/msg25349.html
>  => Inital report with patch for 1.7.3 that later introduced other
>   problems
> https://www.mail-archive.com/haproxy@formilux.org/msg26621.html
>  => Last report with fix in 1.7.8
>
> So the new HAProxy 1.7.8 version has corrected this problem (and others, 
> perhaps more important but which didn't impacted us). I have tested with the
> sid package version, all is fine.
>
> Is it planned to backport those patches in stretch / stretch-updates ?
> Or should we wait for a backport ?

A backport of 1.7.7 has been uploaded and is waiting for approval
(because it's the first backport for stretch). 1.7.8 will be uploaded in
about 2 days.

We may also push some patches in stretch-updates for users not relying
on backports. We need to select them. As there was some regressions in
1.7.6 and 1.7.7, we need to be careful when selecting them.
-- 
He jests at scars who never felt a wound.
-- Shakespeare, "Romeo and Juliet, II. 2"


signature.asc
Description: PGP signature

Bug#868035: krb5: [patch]: ldap sasl auth support

[Sam Hartman]

Thanks for bringing this to my attention.
I'll definitely fix, although I'll end up applying a somewhat different
patch because of the build profiles support included in 1.15.1.  SASL,
like LDAP would create a cycle in stage1 builds.

I expect a new version soon.
I don't have a good test environment for this, so I'm unlikely to check
it myself.

Bug#857842: Fails to build -- test errors

[Harish Sriram]

Hi,

Is this debdiff sufficient to be included or would it need a NMU. Please
help on this.

Regards,
Harish Sriram

Bug#868041: freeradius: jessie-backports available

[Maxime Lareo]

Package: freeradius
Version: 3.0.12+dfsg-5~bpo8+1
Severity: wishlist
User: product...@infomaniak.com
Usertag: infomaniak.com-packaging

Dear Maintainer,

We needed freeradius 3.X on jessie at work, therefore we backported it:

--8<---cut here---start->8---
freeradius (3.0.12+dfsg-5~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * Revert freeradius-dbg package removal
- control: revert removal of freeradius-dbg package
- rules: revert dh_strip options to dh_strip -a --dbg-package
  * control: revert debhelper version dependency to (>=9)
  * rules: remove --fail-missing option from dh_install

 -- Maxime Lareo   Fri, 07 Jul 2017
09:41:13 +0200

--8<---cut here---end--->8---

All the modifications have been made to a Git checkout of the official
Debian repositories, with signed commits and tags. And I can provide
read-only access to such repositories, if someone would like to
integrate the modifications.

Thank you, bye,
Maxime Lareo

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

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

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.12+dfsg-5~bpo8+1
ii  freeradius-config  3.0.12+dfsg-5~bpo8+1
ii  libc6  2.19-18+deb8u9
ii  libcap21:2.24-8
ii  libfreeradius3 3.0.12+dfsg-5~bpo8+1
ii  libgdbm3   1.8.3-13.1
ii  libpam0g   1.1.8-3.1+deb8u2
ii  libpcre3   2:8.35-3.3+deb8u4
ii  libperl5.205.20.2-3+deb8u6
ii  libpython2.7   2.7.9-2+deb8u1
ii  libreadline6   6.3-8+b3
ii  libsqlite3-0   3.8.7.1-1+deb8u2
ii  libssl1.0.01.0.2l-1~bpo8+1
ii  libtalloc2 2.1.2-0+deb8u1
ii  libwbclient0   2:4.2.14+dfsg-0+deb8u6
ii  lsb-base   4.1+Debian13+nmu1

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.12+dfsg-5~bpo8+1

Versions of packages freeradius suggests:
ii  freeradius-krb53.0.12+dfsg-5~bpo8+1
ii  freeradius-ldap3.0.12+dfsg-5~bpo8+1
ii  freeradius-mysql   3.0.12+dfsg-5~bpo8+1
ii  freeradius-postgresql  3.0.12+dfsg-5~bpo8+1
pn  snmp   

-- no debconf information


-- 
Maxime Lareo
Administrateur Systèmes et Réseaux Junior
Infomaniak Network SA




signature.asc
Description: OpenPGP digital signature

Bug#867997: Further thoughts

[Alan Schwartz]

My gut tells me this is a permission issue with the new _apt user, but
again, on another system same hardware and same file ownership for all the
apt-related stuff, all is well. Reinstalling the apt package via dpkg did
not help.

Bug#866194: etcd service fails to start on ppc64le architecture when installing etcd

[Harish Sriram]

Hi,

Is this debdiff sufficient to be included or would it need a NMU. Please
help on this.

Regards,
Harish Sriram

Bug#868043: [vnstat] Version 1.15 changes output units and removes rounding, with no way to configure?

[Roman Mamedov]

Package: vnstat
Version: 1.15-2
Severity: normal

Hello,

Upgrading from Jessie version 1.12 to Stretch version 1.15 changes the output
format of vnstat -h significantly. Now bandwidth values are in a different
unit and no longer rounded to integer. This not only looks worse by adding
extra useless noise to the visual representation, it also broke several scripts
for me which process this output in an automated monitoring and report system.

Previously:

 eth0 13:55 
  ^ t   
  | t  tt   
  |  rt rt rt rt rt rt  tt rt   
  |  rt rt rt rt rt rt rt rtrt rt rtrt rt rt
  |  rt rt rt rt rt rt rt rt rtrtrt rtrtrt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
 -+---> 
  |  14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13

 h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB) 
14   39693559   4220958222   32611864   3322218606   26443418   27074479
15   41173062   4414054823   27608905   2803791407   35113453   37291018
16   42858673   4944113900   30440238   3114062408   37476406   38917220
17   43008290   4612526001   28682376   2951775009   34960298   35353913
18   40935287   4304286302   30669009   3155507910   33981103   34487964
19   40458885   4363524003   31485532   3287089111   38165294   39693801
20   38586455   3993217704   26205215   2701091012   42433494   44623397
21   38848113   3953566905   34302997   3449298813   37786045   38771759

How this looks now in Stretch: 

 eth0 13:54 
  ^t
  |  t  t  t
  |  t rt rt  t 
  |  rt rt rt rt rt  trt t rt   
  |  rt rt rt rt rt rt rt   rt rt rt rt rt rt  t  t 
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt  t   
  |  rt rt rt rt rt rt rt rt rt   t rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
 -+---> 
  |  14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13

 h  rx (MiB)   tx (MiB)  h  rx (MiB)   tx (MiB)  h  rx (MiB)   tx (MiB) 
14   20337.62   21865.6422   15158.41   15718.2506   18301.87   19016.12
15   22071.46   26758.50239935.18   10364.0407   18955.16   20125.97
16   23127.88   27981.0100   11037.72   11407.7208   20806.30   21897.03
17   23204.97   28679.6301   10175.09   10653.7509   17064.68   17680.97
18   20348.89   23030.5802   11361.97   12010.0110   16837.38   18391.96
19   19259.43   21582.4803   17226.79   17677.1611   15989.15   16455.30
20   17598.63   18322.1204   19500.40   19911.9212   14180.97   14585.10
21   16021.17   16941.8805   21891.91   22777.5213   12445.74   13851.71

How to restore the previous output format?

There are RateUnit and UnitMode config variables, both are useless to help with
this issue.

Thanks

-- 
With respect,
Roman

Bug#868042: poedit: Texts become right-aligned after upgrade onto poedit2

[Boyuan Yang]

Package: poedit
Version: 2.0.2-2
Severity: normal
Tags: l10n

I'm not sure what happened to my poedit on Debian Testing (Buster). When I
start it up, all texts in the list would align to the right side, not the left
side.

This never happened when using poedit 1.8.x.

An external screenshot:
  https://ooo.0o0.ooo/2017/07/11/5964d97a73037.png

I tried to start poedit with "LC_ALL=C.UTF-8 poedit" but the problem still
exists.



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

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

Versions of packages poedit depends on:
ii  gettext   0.19.8.1-2+b1
ii  libboost-iostreams1.62.0  1.62.0+dfsg-4+b1
ii  libboost-system1.62.0 1.62.0+dfsg-4+b1
ii  libboost-thread1.62.0 1.62.0+dfsg-4+b1
ii  libc6 2.24-12
ii  libcld2-0 0.0.0-git20150806-5
ii  libcpprest2.9 2.9.1-1
ii  libgcc1   1:7.1.0-9
ii  libglib2.0-0  2.52.3-1
ii  libgtk2.0-0   2.24.31-2
ii  libgtkspell0  2.0.16-1.1
ii  libicu57  57.1-6
ii  liblucene++0v53.0.7-8+b2
ii  libsecret-1-0 0.18.5-3.1
ii  libssl1.1 1.1.0f-3
ii  libstdc++67.1.0-9
ii  libwxbase3.0-0v5  3.0.2+dfsg-4
ii  libwxgtk3.0-0v5   3.0.2+dfsg-4
ii  poedit-common 2.0.2-2

poedit recommends no packages.

poedit suggests no packages.

-- no debconf information

Bug#868041: [Pkg-freeradius-maintainers] Bug#868041: freeradius: jessie-backports available

[Michael Stapelberg]

On Tue, Jul 11, 2017 at 3:52 PM, Maxime Lareo 
wrote:

> Package: freeradius
> Version: 3.0.12+dfsg-5~bpo8+1
> Severity: wishlist
> User: product...@infomaniak.com
> Usertag: infomaniak.com-packaging
>
> Dear Maintainer,
>
> We needed freeradius 3.X on jessie at work, therefore we backported it:
>
> --8<---cut here---start->8---
> freeradius (3.0.12+dfsg-5~bpo8+1) jessie-backports; urgency=medium
>
>   * Rebuild for jessie-backports.
>   * Revert freeradius-dbg package removal
> - control: revert removal of freeradius-dbg package
> - rules: revert dh_strip options to dh_strip -a --dbg-package
>   * control: revert debhelper version dependency to (>=9)
>   * rules: remove --fail-missing option from dh_install
>
>  -- Maxime Lareo   Fri, 07 Jul 2017
> 09:41:13 +0200
>
> --8<---cut here---end--->8---
>
> All the modifications have been made to a Git checkout of the official
> Debian repositories, with signed commits and tags. And I can provide
> read-only access to such repositories, if someone would like to
> integrate the modifications.
>

Please do.


>
> Thank you, bye,
> Maxime Lareo
>
> -- System Information:
> Debian Release: 8.8
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages freeradius depends on:
> ii  freeradius-common  3.0.12+dfsg-5~bpo8+1
> ii  freeradius-config  3.0.12+dfsg-5~bpo8+1
> ii  libc6  2.19-18+deb8u9
> ii  libcap21:2.24-8
> ii  libfreeradius3 3.0.12+dfsg-5~bpo8+1
> ii  libgdbm3   1.8.3-13.1
> ii  libpam0g   1.1.8-3.1+deb8u2
> ii  libpcre3   2:8.35-3.3+deb8u4
> ii  libperl5.205.20.2-3+deb8u6
> ii  libpython2.7   2.7.9-2+deb8u1
> ii  libreadline6   6.3-8+b3
> ii  libsqlite3-0   3.8.7.1-1+deb8u2
> ii  libssl1.0.01.0.2l-1~bpo8+1
> ii  libtalloc2 2.1.2-0+deb8u1
> ii  libwbclient0   2:4.2.14+dfsg-0+deb8u6
> ii  lsb-base   4.1+Debian13+nmu1
>
> Versions of packages freeradius recommends:
> ii  freeradius-utils  3.0.12+dfsg-5~bpo8+1
>
> Versions of packages freeradius suggests:
> ii  freeradius-krb53.0.12+dfsg-5~bpo8+1
> ii  freeradius-ldap3.0.12+dfsg-5~bpo8+1
> ii  freeradius-mysql   3.0.12+dfsg-5~bpo8+1
> ii  freeradius-postgresql  3.0.12+dfsg-5~bpo8+1
> pn  snmp   
>
> -- no debconf information
>
>
> --
> Maxime Lareo
> Administrateur Systèmes et Réseaux Junior
> Infomaniak Network SA
>
>
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-
> freeradius-maintainers
>
>


-- 
Best regards,
Michael

Bug#868044: ITP: vim-airline -- Lean & mean status/tabline for vim that's light as air

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: vim-airline
  Version : 0.8-1
  Upstream Author : Bailey Ling 
* URL : https://github.com/vim-airline/vim-airline
* License : expat
  Programming Lang: vimconfig
  Description : Lean & mean status/tabline for vim that's light as air

 vim-airline provides a themable vim status bar that makes use of the
 powerline font. It's similar to vim-powerline, but is still maintained
 and much simpler since it user pure vim configuration instead of
 scripting languages.
 .
 Some of its features:
 .
  * Tiny core written with extensibility in mind
  * Integrates with a variety of vim plugins
  * Looks good with regular fonts and provides configuration points
so you can use unicode or powerline symbols
  * Optimized for speed; it loads in under a millisecond

Bug#868047: pelican ships non-free files

[Johannes Schauer]

Source: pelican
Version: 3.7.1
Severity: serious
Justification: Policy 2.2.1

The directory pelican/themes/notmyidea/static/images/icons/ is full of
non-free files which need to be removed.

Bug#868034: [Pkg-haproxy-maintainers] Bug#868034: haproxy: New HAProxy 1.7.8 fixes several bugs

[Yann Cézard]

Great, thank you for your fast answer !


On 11/07/2017 15:48, Vincent Bernat wrote:

  ❦ 11 juillet 2017 13:46 +0200, Yann Cézard  :


Upgrading from Jessie (haproxy 1.5.8-3+deb8u2) to Stretch (1.7.5-2)
leads us to some bad behaviour with some backends.

More specificaly, the use of a websocket was broken by the use of
compression.

A minor workaround was to disable compression for that backend.

This problem was introduced by some earlier patches between 1.5.3 and
1.5.5.
More information on those threads :
https://www.mail-archive.com/haproxy@formilux.org/msg25349.html
  => Inital report with patch for 1.7.3 that later introduced other
   problems
https://www.mail-archive.com/haproxy@formilux.org/msg26621.html
  => Last report with fix in 1.7.8

So the new HAProxy 1.7.8 version has corrected this problem (and others,
perhaps more important but which didn't impacted us). I have tested with the
sid package version, all is fine.

Is it planned to backport those patches in stretch / stretch-updates ?
Or should we wait for a backport ?

A backport of 1.7.7 has been uploaded and is waiting for approval
(because it's the first backport for stretch). 1.7.8 will be uploaded in
about 2 days.

We may also push some patches in stretch-updates for users not relying
on backports. We need to select them. As there was some regressions in
1.7.6 and 1.7.7, we need to be careful when selecting them.


--- DISCLAIMER - This message 
and any attachment are proprietary and confidential information and might be 
legally privileged in your country. These elements are intended solely for the 
addressee. Any unauthorized use or disclosure, in whole or in part, is 
prohibited. E-mails are subject to any alteration, change or falsification. The 
sender declines any liability to this message and any attachment. If you are 
not the intended recipient of this message, please delete this message and 
notify immediately the sender. 

Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Jens Kubieziel]

Package: gb
Version: 0.4.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I recently upgraded my system and golang-go was updated to version 1.8. Later I
wanted to execute the command:

`gb build github.com/jteeuwen/go-bindata/go-bindata`

which let to a fatal error. When looking at it with `strace` I found that `gb`
accesses `/usr/libn/go-1.7` which doesn't exist anymore:

user@linux:> strace -e trace=file gb build 
github.com/jteeuwen/go-bindata/go-bindata |& egrep '1\.7'
stat("/usr/lib/go-1.7/src/vendor/github.com/jteeuwen/go-bindata/go-bindata", 
0xc42015a858) = -1 ENOENT (No such file or directory)
stat("/usr/lib/go-1.7/src/github.com/jteeuwen/go-bindata/go-bindata", 
0xc42015a928)
= -1 ENOENT (No such file or directory)
stat("/usr/lib/go-1.7/src/vendor/flag", 0xc42015ae08) = -1 ENOENT (No such file 
or directory)
stat("/usr/lib/go-1.7/src/flag", 0xc42015aed8) = -1 ENOENT (No such file or 
directory)

There are no accesses to something which contains 1.8 even though `dpkg -l`
tells me that all installed golang packages are at 1.8 (1.8.3-1 or 2:1.8~3).

I don't know if it of relevance, but `apt-cache show gb` tells me `Built-Using:
golang-1.7 (= 1.7.4-1), golang-github-pkg-errors (= 0.8.0-1)`.

I would expect that after an update gb automatically uses the right directory.
If go-1.7 is still there, it could use this and if go-1.8 (or something else)
exists, it should use this directory.

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

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

Versions of packages gb depends on:
ii  golang-go  2:1.8~3
ii  libc6  2.24-12

Versions of packages gb recommends:
ii  golang-golang-x-tools  1:0.0~git20170707.0.bce9606b+ds-1

gb suggests no packages.

-- no debconf information

-- 
Jens Kubieziel   http://www.kubieziel.de
Man ist kein Milliardär, wenn man seine Millionen noch zählen kann.
Jean-Paul Getty

Bug#868045: ITP: vim-airline-themes -- official theme collection for vim-airline

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: vim-airline-themes
  Version : git-master
  Upstream Author : Bailey Ling 
* URL : https://github.com/vim-airline/vim-airline-themes
* License : expat
  Programming Lang: vim-config
  Description : official theme collection for vim-airline

Includes the official theme bundle for vim-airline.

vim-airline is a vim extension that provides a themed statusbar
that can make use of the powerline characters.

Bug#868048: calibre: Calibre cannot connect with Kobo reader

[Michele Cane]

Package: calibre
Version: 2.75.1+dfsg-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

the current version in stable does not support the Kobo Aura H2O.

This problem has been fixed upstrem in the release 2.85.1.

It would be nice if the currect package or (or a later version) in unstable 
could migrate to testing for an upload in backports.

I have seen that in collab-maintain the patch to fix the bug #866102, which is 
holding package migration, is already implemented.

Please consider uploading a new version in unstable.

Thanks for mantaining this package.

Best regards

Mike


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

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

Versions of packages calibre depends on:
ii  calibre-bin  2.75.1+dfsg-1
ii  fonts-liberation 1:1.07.4-2
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libjs-mathjax2.7.0-2
ii  poppler-utils0.48.0-2
ii  python-apsw  3.13.0-r1-1
ii  python-beautifulsoup 3.2.1-1
ii  python-chardet   2.3.0-2
ii  python-cherrypy3 3.5.0-2
ii  python-cssselect 1.0.1-1
ii  python-cssutils  1.0-4.1
ii  python-dateutil  2.5.3-2
ii  python-dbus  1.2.4-1+b1
ii  python-feedparser5.1.3-3
ii  python-imaging   4.0.0-4
ii  python-lxml  3.7.1-1
ii  python-markdown  2.6.8-1
ii  python-mechanize 1:0.2.5-3
ii  python-netifaces 0.10.4-0.1+b2
ii  python-pil   4.0.0-4
ii  python-pkg-resources 33.1.1-1
ii  python-pyparsing 2.1.10+dfsg1-1
ii  python-pyqt5 5.7+dfsg-5
ii  python-pyqt5.qtsvg   5.7+dfsg-5
ii  python-pyqt5.qtwebkit5.7+dfsg-5
ii  python-routes2.3.1-2
ii  python2.72.7.13-2
ii  xdg-utils1.1.1-1

Versions of packages calibre recommends:
ii  python-dnspython  1.15.0-1

calibre suggests no packages.

-- no debconf information

Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

[Thorsten Glaser]

tags 826256 = upstream
forwarded 826256 https://sourceware.org/bugzilla/show_bug.cgi?id=21750
thanks

OK, I’ve forwarded this upstream and refreshed the researched data:
https://sourceware.org/bugzilla/show_bug.cgi?id=21750

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#867158: RFS: weresync/1.0.6-1 [ITP]

[Daniel Manila]

Updated the package again, this time built against sid tools, so I fixed a lot 
of miscellaneous issues. I also updated the package to version 1.0.6, which is 
a small
update intended to fix packaging problems with pip, which didn't really affect 
the debian package. (v1.0.7 was also recently released, but has equally little 
affect on the function of the package).

You can get the newest package from this link:

https://mentors.debian.net/debian/pool/main/w/weresync/weresync_1.0.6-1.dsc

Thanks for your interest in this package.

Daniel Manila

Bug#868049: pelican: privacy breach in "notmyidea" theme

[Johannes Schauer]

Source: pelican
Version: 3.7.1-1
Severity: serious
Justification: Policy 2.2.1

The "notmyidea" theme shipped by the pelican package references several
files outside the archive. Specifically:

 - pelican/themes/notmyidea/static/css/main.css imports
   https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz&subset=latin

 - pelican/themes/notmyidea/templates/base.html includes the script
   https://html5shiv.googlecode.com/svn/trunk/html5.js

When using packages from Debian main, the expectation is, that the
software does not breach a user's privacy in its default settings. Thus,
above problems must be fixed if this package should stay in "main".

Thanks!

cheers, josch

Bug#554794: badblocks -c and -n

[Theodore Ts'o]

On Mon, Jul 10, 2017 at 03:19:28PM -0700, Matt Taggart wrote:
> Given the device size increases and RAM/CPU improvements since all these
> things occurred, is there any value to increasing the defaults? Does anyone
> have any data? If not then what tests would be valuable?
> 
> I often run many badblocks instances at once on separate SATA devices (so
> no bus contention), what are the optimal settings for that case?

I have to ask --- ***why*** are you (and other people) running
badblocks in 2017?  Badblocks as a thing started becoming irrelevant
for e2fsprogs's purpose sometime around 2003-2005, when SATA was
introduced, and drive electronics were smart enough that they could be
largely counted upon to do automatic bad block redirection in the
drive.

Also, drives have gotten large enough that no matter what kind of
optimizations we could make to badblocks, the cost benefit ratio of
using badblocks went negative a long, long, ***LONG*** time ago.

As a result, I personally don't do much maintenance to badblocks,
since as I have free time, there are far more important things to
worry about than trying to optimize (or even provide I18N support, or
other crazy things people have asked for) in this program.  As always,
however, patches will always be gratefully accepted for review

   - Ted

P.S.  Yes, I have considered removing badblocks from e2fsprogs
altogether.  The main reason why I haven't is that it's a small (28k),
mostly harmless, and inoffensive binary.  Given the average increase in
bloat of, say, most of the other binaries in Debian, it hasn't even
been worth the effort to deprecate it

Bug#868050: ITP: golang-github-shibukawa-configdir -- Configuration directories handling for Go

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: Diego M. Rodriguez 

* Package name: golang-github-shibukawa-configdir
  Version : 0.0~git20170330.0.e180dbd-1
  Upstream Author : Yoshiki Shibukawa
* URL : https://github.com/shibukawa/configdir
* License : Expat
  Programming Lang: Go
  Description : Configuration directories handling for Go

 configdir is a library for transparently accessing files under configuration
 directories or cache directories regardless of the operative system's
 convention.

Bug#868051: crashes comaining about exact version of git module

[Yaroslav Halchenko]

Package: legit
Version: 0.4.1-1
Severity: grave

$> legit --help
Traceback (most recent call last):
  File "/usr/bin/legit", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3019, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3003, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3032, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 657, 
in _build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 670, 
in _build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 849, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'GitPython==2.1.1' distribution was not 
found and is required by legit

$> apt-cache policy python-git
python-git:
  Installed: 2.1.3-1~nd+1
  Candidate: 2.1.5-1
  Version table:
 2.1.5-1 600
600 http://http.debian.net/debian sid/main amd64 Packages
600 http://http.debian.net/debian sid/main i386 Packages
 *** 2.1.3-1~nd+1 100
100 /var/lib/dpkg/status
 2.1.3-1~nd90+1 500
500 http://neuro.debian.net/debian stretch/main amd64 Packages
500 http://neuro.debian.net/debian stretch/main i386 Packages
 2.1.1-2 100
100 http://http.debian.net/debian stretch/main amd64 Packages
100 http://http.debian.net/debian stretch/main i386 Packages


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages legit depends on:
ii  python2.7.13-2
ii  python-appdirs1.4.0-3
ii  python-args   0.1.0-2
ii  python-clint  0.5.1-1
ii  python-git2.1.3-1~nd+1
ii  python-gitdb  2.0.0-2
ii  python-packaging  16.8-1
ii  python-pkg-resources  33.1.1-1
ii  python-pyparsing  2.1.10+dfsg1-1
ii  python-six1.10.0-3
ii  python-smmap  2.0.1-1
pn  python:any

legit recommends no packages.

legit suggests no packages.

-- no debconf information

Bug#867158: retitle to RFS: weresync/1.0.6-1 [ITP]

[Daniel Manila]

retitle 867158 RFS: weresync/1.0.6-1 [ITP]
stop

New version uploaded so changing title to match.

Bug#867974: libqt5gui5: new-delete-type-mismatch in QOpenGLContext destructor

[Dmitry Shachnev]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-57773
Control: fixed -1 qtbase-opensource-src/5.9.0~beta.3+dfsg-1

Hi Sergey,

On Mon, Jul 10, 2017 at 09:45:36PM +0200, Sergey Sharybin wrote:
> Package: libqt5gui5
> Version: 5.7.1+dfsg-3+b1
> Severity: normal
>
> Dear Maintainer,
>
> When building Qt5 application which uses QOpenGL classes with ASAN support 
> there is
> a new-delete-type-mismatch reported by the ASAN.
>
> In order to reproduce the issue, it is enough to compile 
> threadedqopenglwidget demo
> application with -fsanitize=address, run the application, close all windows. 
> See the
> ASAN report in console after that.
>
> This is likely the same exact issue as reported there:
>
>   https://bugreports.qt.io/browse/QTBUG-57773

Thank you for your report.

We are currently focused on updating Qt from version 5.7 to 5.9, and as this
bug is fixed upstream in 5.9.0 Beta 2, the fix will land soon with that Qt
update.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#757048: Alive ping

[Fabian Wolff]

I am really sorry that this is taking so long, but I am still working
on this. In particular, at the recommendation of the upstream
developers, I have been waiting for version 1.5 of CVC4, which has
finally been released yesterday:

  http://cvc4.cs.stanford.edu/web/2017/07/10/cvc4-1-5-released/

Regards,
Fabian


signature.asc
Description: PGP signature

Bug#755545: [Pkg-libvirt-maintainers] Bug#755545: Add glusterfs/libgfapi

[Dave Sherohman]

>> As finally, glusterfs was integrated to qemu (into qemu-block-extra) on
>> 12/28/2016 which close blocking bugs #775431 and #787112, is the integration
>> of glusterfs to libvirt is possible now ?
>
> Think so. I'll do this in experimental once we have 3.0 in testing
> (don't want to change dependencies that late in the cycle). We want
> recent gluster code anyway so we can enable this in stretch-backports.
>
> Should I forget please ping again ;)

As another user looking for gluster support in libvirt, I'm pinging.
Stretch is now released and showing libvirt0 at version 3.0.0-4, which
appears to cover the things you said you wanted to see in place before
integrating gluster support.

Bug#868052: mupdf: upgrade to 1.11

[Pavel Sofishchenko]

Package: mupdf
Version: 1.9a+ds1-4
Severity: wishlist

Dear maintainer,
please upgrade mupdf to latest 1.11 upstream version.

Bug#669813: Debian bug: mailman: Re: Archives not-->now working (need Require all granted in )

[Michael Paoli]

Most relevant bit found among Debian bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669813#36
The new apache security model requires adding this to the
Directory stanza for mailman:
 Require all granted

But that's not particularly detailed, most notably omits
mention of
/etc/mailman/apache.conf
and the

section within.

Recommended to (mostly) fix mailman 1:2.1.18-2+deb8u1 amd64:

$ diff -U 5 etc/mailman/apache.conf.bug_669813 etc/mailman/apache.conf
--- etc/mailman/apache.conf.bug_669813  2016-09-14 23:05:02.0 -0700
+++ etc/mailman/apache.conf 2017-07-11 07:01:29.116879436 -0700
@@ -26,10 +26,11 @@
 
 Options FollowSymlinks
 AllowOverride None
 Order allow,deny
 Allow from all
+Require all granted
 
 
 AllowOverride None
 Order allow,deny
 Allow from all
$

At least that's the case for Jessie (presently oldstable)
(
Debian GNU/Linux 8.8 (jessie) x86_64
mailman 1:2.1.18-2+deb8u1 amd64
apache2 2.4.10-10+deb8u9 amd64
)

I haven't (at least yet) checked to see if there's patch applied
yet for newer than mailman 1:2.1.18-2+deb8u1 amd64 that may cover
that fix.

In the meantime, for work-around for at least those versions,
in Apache configuration, in addition to (which I added):
Include ../mailman/apache.conf
(or
Include /etc/mailman/apache.conf
or equivalent
)
also add (and if the above is used via Include, use this *after* the above):

Options FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all
Require all granted



From: "Michael Paoli" 
Subject: Archives now working: BALUG-Test list
Date: Tue, 11 Jul 2017 00:36:28 -0700



Archives are now working.
Relevant bit ... I ought (when I get around to it) check if there's
bug filed (it may already be fixed even - but not yet to stable).



The missing bit ... I'd (rather than redundantly copied/maintain) used:
(relative to /etc/apache2):
Include ../mailman/apache.conf
in file sites-available/Include/temp.balug.org
that was almost all well fine and good (I'd reviewed
./mailman/apache.conf earlier).  But it left out one key needed bit,
it has:

Options FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all

but needs:

Options FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all
Require all granted

My relatively simple fix,
add to file
sites-available/Include/temp.balug.org

Options FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all
Require all granted

after:
Include ../mailman/apache.conf
... Apache doesn't seem to care about the same

appearing twice, and seems in that case to just use the latter fine,



So ... /etc/mailman/apache.conf
should have included but failed to include, in it's section:

the line:
Require all granted
So ... I think I'd call that a "bug" - even if it's documentation
errata.  Might be a Debian specific patch needed, as other
distributions and/or Apache may have different defaults on
that security.


https://temp.balug.org/pipermail/balug-test/2017-July/04.html
temp.balug.org will in future be moved to lists.balug.org, so that
will become:
https://lists.balug.org/pipermail/balug-test/2017-July/04.html

Bug#868053: sunpy: FTBFS with python-astropy >= 2

[James Cowgill]

Source: sunpy
Version: 0.7.8-1
Severity: serious
Tags: sid buster

sunpy FTBFS with testsuite when built using python-astropy from unstable:

> python -m pytest sunpy -k "not figure and not online"
> = test session starts 
> ==
> platform linux2 -- Python 2.7.13, pytest-3.0.6, py-1.4.34, pluggy-0.4.0
> rootdir: /<>, inifile: setup.cfg
> collected 618 items / 36 errors
> 
>  ERRORS 
> 
> ___ ERROR collecting sunpy/coordinates/tests/test_frameattributes.py 
> ___
> ImportError while importing test module 
> '/<>/sunpy/coordinates/tests/test_frameattributes.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> sunpy/coordinates/__init__.py:3: in 
> from .frames import *
> sunpy/coordinates/frames.py:17: in 
> from astropy.coordinates import FrameAttribute
> E   ImportError: cannot import name FrameAttribute

James



signature.asc
Description: OpenPGP digital signature

Bug#867974: libqt5gui5: new-delete-type-mismatch in QOpenGLContext destructor

[Sergey Sharybin]

Hi,

Sure it's nice it's fixed in Qt 5.9, but does this mean it will never
be fixed in Debian Stretch (aka, current stable) ?

On Tue, Jul 11, 2017 at 4:30 PM, Dmitry Shachnev  wrote:
> Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-57773
> Control: fixed -1 qtbase-opensource-src/5.9.0~beta.3+dfsg-1
>
> Hi Sergey,
>
> On Mon, Jul 10, 2017 at 09:45:36PM +0200, Sergey Sharybin wrote:
>> Package: libqt5gui5
>> Version: 5.7.1+dfsg-3+b1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> When building Qt5 application which uses QOpenGL classes with ASAN support 
>> there is
>> a new-delete-type-mismatch reported by the ASAN.
>>
>> In order to reproduce the issue, it is enough to compile 
>> threadedqopenglwidget demo
>> application with -fsanitize=address, run the application, close all windows. 
>> See the
>> ASAN report in console after that.
>>
>> This is likely the same exact issue as reported there:
>>
>>   https://bugreports.qt.io/browse/QTBUG-57773
>
> Thank you for your report.
>
> We are currently focused on updating Qt from version 5.7 to 5.9, and as this
> bug is fixed upstream in 5.9.0 Beta 2, the fix will land soon with that Qt
> update.
>
> --
> Dmitry Shachnev



-- 
With best regards, Sergey Sharybin

Bug#868054: stretch-pu: package dwarfutils/20161124-1+deb9u1

[Fabian Wolff]

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

Dear Release Team,

I would like to propose the following changes to the dwarfutils
package in stretch:

  * Add patch 02-fix-CVE-2017-9052.patch to fix CVE-2017-9052 and
CVE-2017-9055 (Closes: #864064).
  * Add patch 03-fix-CVE-2017-9053.patch to fix CVE-2017-9053.
  * Add patch 04-fix-CVE-2017-9054.patch to fix CVE-2017-9054.
  * Add patch 05-fix-CVE-2017-9998.patch to fix CVE-2017-9998
(Closes: #866968).

This update would fix all currently known vulnerabilities in the
dwarfutils package in stretch. All changes have been cherry-picked
from the upstream development repository, and all of them are already
in unstable.

I have attached the debdiff that I would like to apply to the current
version in stable.

Thank you!

Kind regards,
Fabian
diff -Nru dwarfutils-20161124/debian/changelog 
dwarfutils-20161124/debian/changelog
--- dwarfutils-20161124/debian/changelog2016-11-25 14:23:27.0 
+0100
+++ dwarfutils-20161124/debian/changelog2017-07-11 15:33:51.0 
+0200
@@ -1,3 +1,14 @@
+dwarfutils (20161124-1+deb9u1) stable; urgency=medium
+
+  * Add patch 02-fix-CVE-2017-9052.patch to fix CVE-2017-9052 and
+CVE-2017-9055 (Closes: #864064).
+  * Add patch 03-fix-CVE-2017-9053.patch to fix CVE-2017-9053.
+  * Add patch 04-fix-CVE-2017-9054.patch to fix CVE-2017-9054.
+  * Add patch 05-fix-CVE-2017-9998.patch to fix CVE-2017-9998
+(Closes: #866968).
+
+ -- Fabian Wolff   Tue, 11 Jul 2017 15:33:51 +0200
+
 dwarfutils (20161124-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch 
dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch
--- dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch   
1970-01-01 01:00:00.0 +0100
+++ dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch   
2017-07-11 15:33:51.0 +0200
@@ -0,0 +1,31 @@
+Description: Fix CVE-2017-9052 and CVE-2017-9055
+Origin: upstream, 
https://sourceforge.net/p/libdwarf/code/ci/cc37d6917011733d776ae228af4e5d6abe9613c1/
+Bug: https://www.prevanders.net/dwarfbug.html#DW201703-006
+Bug-Debian: https://bugs.debian.org/864064
+Last-Update: 2017-07-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libdwarf/dwarf_form.c
 b/libdwarf/dwarf_form.c
+@@ -934,6 +934,10 @@
+ switch (attr->ar_attribute_form) {
+ 
+ case DW_FORM_data1:
++if (attr->ar_debug_ptr >= section_end) {
++_dwarf_error(dbg, error, DW_DLE_DIE_BAD);
++return DW_DLV_ERROR;
++}
+ *return_sval = (*(Dwarf_Sbyte *) attr->ar_debug_ptr);
+ return DW_DLV_OK;
+ 
+--- a/libdwarf/dwarf_query.c
 b/libdwarf/dwarf_query.c
+@@ -377,7 +377,7 @@
+ }
+ if (_dwarf_reference_outside_section(die,
+ (Dwarf_Small*) info_ptr,
+-(Dwarf_Small*) info_ptr)) {
++((Dwarf_Small*) info_ptr)+1)) {
+ _dwarf_error(dbg, error,DW_DLE_ATTR_OUTSIDE_SECTION);
+ return DW_DLV_ERROR;
+ }
diff -Nru dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch 
dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch
--- dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch   
1970-01-01 01:00:00.0 +0100
+++ dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch   
2017-07-11 15:33:51.0 +0200
@@ -0,0 +1,86 @@
+Description: Fix CVE-2017-9053
+Origin: upstream, 
https://sourceforge.net/p/libdwarf/code/ci/cc37d6917011733d776ae228af4e5d6abe9613c1/
+Bug: https://www.prevanders.net/dwarfbug.html#DW201703-005
+Bug-Debian: https://bugs.debian.org/864064
+Last-Update: 2017-07-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libdwarf/dwarf_loc.c
 b/libdwarf/dwarf_loc.c
+@@ -237,6 +237,10 @@
+ break;
+ 
+ case DW_OP_const1u:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Small *) loc_ptr;
+ loc_ptr = loc_ptr + 1;
+ if (loc_ptr > section_end) {
+@@ -247,6 +251,10 @@
+ break;
+ 
+ case DW_OP_const1s:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Sbyte *) loc_ptr;
+ SIGN_EXTEND(operand1,1);
+ loc_ptr = loc_ptr + 1;
+@@ -372,6 +380,10 @@
+ break;
+ 
+ case DW_OP_pick:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Small *) loc_ptr;
+ loc_ptr = loc_ptr + 1;
+ if (loc_ptr > section_end) {
+@@ -

Bug#867973: jessie-pu: package wordgrinder/0.5.1-1

[David Given]

Unfortunately, that's not feasible --- upstream fixed that bug by reworking
the entire internal document model, and it's all interdependent on the rest
of the changes, so it'd be a major engineering effort to do. I wouldn't be
desireable anyway, as the end result would be a version of the package
which is substantially different from any upstream release of WordGrinder.

Why is it problematic to pushing the stable version into oldstable? It's a
completely trivial build, being *literally* apt-get source && debuild.
Here's the backport I prepared to prove it:

https://mentors.debian.net/package/wordgrinder

What's the user value in keeping 0.5.1 in oldstable rather than just
upgrading to the stable version?

On Tue, 11 Jul 2017 at 00:22 Cyril Brulebois  wrote:

> David Given  (2017-07-10):
> > Well, I actually approached backports, and they firmly told me to come
> > here instead (and even provided instructions)...
> >
> > Okay, so what now? I don't really want a backport anyway; I just want
> > the version that's currently in stable pushed to jessie as well. That
> > version has been in Debian since late 2015, so it's not precisely new;
> > it's not like I'm proposing an unstable version.
> >
> > I do *not* want the package removed from jessie. It turns out there's
> > still a fair number of people who use it, on jessie, and I want to make
> > sure that they're supported.
>
> Then extract targeted patches to fix specific bugs in jessie, and propose
> a smaller debdiff/diffstat than the one Adam pointed out.
>
>
> KiBi.
>
-- 
┌─── http://cowlark.com ───
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Bug#868055: virtualenv'ed python-dbg doesn't work smoothly with gdb (py- commands are gone)

[Yaroslav Halchenko]

Package: python-virtualenv
Version: 15.1.0+ds-1
Severity: normal

Not 100% sure if it is not a python-dbg or gdb issue, but I think it might as
well be virtualenv:

$> virtualenv --python=/usr/bin/python-dbg venv-dbg
Running virtualenv with interpreter /usr/bin/python-dbg
New python executable in /tmp/venv-dbg/bin/python-dbg
Also creating executable in /tmp/venv-dbg/bin/python
[21403 refs]
Installing setuptools, pkg_resources, pip, wheel...done.
[47796 refs]

$> gdb -q -ex 'py-bt' -ex quit /usr/bin/python-dbg
Reading symbols from /usr/bin/python-dbg...done.
Traceback (most recent call first):
Python Exception  No frame is currently selected.:
Error occurred in Python command: No frame is currently selected.

$> gdb -q -ex 'py-bt' -ex quit $PWD/venv-dbg/bin/python-dbg
Reading symbols from /tmp/venv-dbg/bin/python-dbg...done.
Undefined command: "py-bt".  Try "help".


This complicates debugging some extensions etc

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-virtualenv depends on:
ii  python2.7.13-2
ii  python-pip-whl9.0.1-2
ii  python-pkg-resources  33.1.1-1

Versions of packages python-virtualenv recommends:
ii  virtualenv  15.1.0+ds-1

python-virtualenv suggests no packages.

-- no debconf information

Bug#863734: unblock: gnupg2/2.1.18-8

[Daniel Kahn Gillmor]

On Sun 2017-06-25 18:39:34 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2017-06-17 17:36:39 +0100, Adam D. Barratt wrote:
>> Unfortunately we ran out of time to handle this before the release, so
>> converting it to a proto-p-u request.
>
> Thanks for this conversion, Adam.  Please let me know if you need any
> feedback from on it from me or anyone else on the pkg-gnupg-maint team.

ping on https://bugs.debian.org/863734 (sending gnupg2/2.1.18-8 to
stretch proposed-updates) -- please let me know if you need anything
else.

thanks for your work keeping debian healthy!

   --dkg


signature.asc
Description: PGP signature

Bug#864489: [Build-common-hackers] Bug#864489: cdbs: Resolution of bug #811555 breaks fix for bug #715504

[Roman Tsisyk]

> On 06/09/2017 03:16 PM, Jonas Smedegaard wrote:
> > Quoting Alexander Sbitnev (2017-06-09 13:02:32)
> > > During resolution of bug #811555 dh_systemd_enable was moved up to be
> > > before dh_installinit. But probably instead dh_installinit (and now
> > > dh_systemd_enable) should be moved down to be after dh_install.
> > > Atleast tarantool package unable to produce pure systemd startup files
> > > as result of this bug. Current situation is compensated by legacy SysV
> > > init startup files but not on pure systemd setup. Probably mentioned
> > > in #715504 miredo package is also have same problem.
> > Thanks for reporting.
> > 
> > I am no expert in systemd.
> > 
> > Please (you or someone else more knowledgeable than me) provide a patch
> > - or at least a clear description of a single order of execution of all
> > involved parts - which takes these multiple bugreports into account.
> > 
> >   - Jonas
> > 

Any news? The provided fix is quite simple - it just moves
dh_systemd_enable into appropriate place.

-- 
WBR,
  Roman Tsisyk 
  http://tarantool.org/

Bug#868056: libnewt0.52: legacy config files not properly cleaned up.

[Christoph Anton Mitterer]

Package: libnewt0.52
Version: 0.52.20-1+b1
Severity: normal


Hi.

Apparently, up to including version 0.52.15-3, libnewt0.52
created some /etc/alternatives files
from postinst
update-alternatives --install /etc/newt/palette newt-palette 
/etc/newt/palette.original 20
[ -e /usr/share/doc/libnewt0.52 ] || update-alternatives --auto 
newt-palette

but this was silently dropped in the version afterwards (0.52.17-1) and never 
cleaned up
properly since then.
It was not even mentioned in changelog.Debian... o.O

Could you please add proper cleanup code in one of the next versions, so that
people with legacy systems get the old stuff properly cleaned up? :-)

Cheers,
Chris.