Bug#833462: openjdk-7-jre-headless does not upgrade : does not find that /proc is mounted

[Erwan David]

On Fri, Aug 05, 2016 at 07:11:44AM CEST, Salvatore Bonaccorso 
 said:
> Control: tags -1 + moreinfo unreproducible
> 
> Hi,
> 
> On Thu, Aug 04, 2016 at 06:38:17PM +0200, Erwan David wrote:
> > Package: openjdk-7-jre-headless
> > Version: 7u111-2.6.7-1~deb8u1
> > Severity: important
> > Tags: security
> >
> > When trying to upgrade openjdk-7-jre I get error :
> >
> > Setting up openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
> > /var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: 19: 
> > /var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: mountpoint: not 
> > found
> > the java command requires a mounted proc fs (/proc).
> 
> This is not reproducible for me, just tested in a Jessie VM:
> 
> root@jessie-amd64:~# apt-get install openjdk-7-jre-headless
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Suggested packages:
>   icedtea-7-jre-jamvm libnss-mdns sun-java6-fonts fonts-dejavu-extra 
> fonts-ipafont-gothic fonts-ipafont-mincho ttf-wqy-microhei ttf-wqy-zenhei 
> fonts-indic
> The following packages will be upgraded:
>   openjdk-7-jre-headless
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 39.4 MB of archives.
> After this operation, 80.9 kB of additional disk space will be used.
> Get:1 http://security.debian.org/ jessie/updates/main openjdk-7-jre-headless 
> amd64 7u111-2.6.7-1~deb8u1 [39.4 MB]
> Fetched 39.4 MB in 0s (41.6 MB/s)
> (Reading database ... 48479 files and directories currently installed.)
> Preparing to unpack .../openjdk-7-jre-headless_7u111-2.6.7-1~deb8u1_amd64.deb 
> ...
> Unpacking openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) over 
> (7u101-2.6.6-2~deb8u1) ...
> Setting up openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
> Processing triggers for libc-bin (2.19-18+deb8u4) ...
> root@jessie-amd64:~#
> 
> > Indeed I do not have the mountpoint command
> 
> How that? /bin/mountpoint is from the initscripts package:
> 
> root@jessie-amd64:~# dpkg -S /bin/mountpoint
> initscripts: /bin/mountpoint
> root@jessie-amd64:~# dpkg-query -W initscripts
> initscripts 2.88dsf-59
> root@jessie-amd64:~#
> 
> Was this accidentially removed from the system?

I don't think so. I have several machines with same problem and

dpkg-query -W initscripts
initscripts   2.88dsf-59.2

dpkg -L initscripts
/.
/sys
/sbin
/sbin/fsck.nfs
/etc
/etc/network
/etc/network/if-up.d
/etc/network/if-up.d/mountnfs
/etc/init.d
/etc/init.d/urandom
/etc/init.d/umountroot
/etc/init.d/umountnfs.sh
/etc/init.d/umountfs
/etc/init.d/skeleton
/etc/init.d/single
/etc/init.d/sendsigs
/etc/init.d/rmnologin
/etc/init.d/reboot
/etc/init.d/rc.local
/etc/init.d/mountnfs.sh
/etc/init.d/mountnfs-bootclean.sh
/etc/init.d/mountkernfs.sh
/etc/init.d/mountdevsubfs.sh
/etc/init.d/mountall.sh
/etc/init.d/mountall-bootclean.sh
/etc/init.d/motd
/etc/init.d/killprocs
/etc/init.d/hostname.sh
/etc/init.d/halt
/etc/init.d/checkroot.sh
/etc/init.d/checkroot-bootclean.sh
/etc/init.d/checkfs.sh
/etc/init.d/bootmisc.sh
/etc/init.d/bootlogs
/etc/default
/etc/default/tmpfs
/etc/default/rcS
/etc/default/halt
/etc/default/devpts
/usr
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/initscripts
/usr/share/man
/usr/share/man/man5
/usr/share/man/man5/tmpfs.5.gz
/usr/share/man/man5/rcS.5.gz
/usr/share/man/man5/halt.5.gz
/usr/share/man/man8
/usr/share/man/man8/fsck.nfs.8.gz
/usr/share/doc
/usr/share/doc/initscripts
/usr/share/doc/initscripts/NEWS.Debian.gz
/usr/share/doc/initscripts/changelog.gz
/usr/share/doc/initscripts/changelog.Debian.gz
/usr/share/doc/initscripts/copyright
/usr/share/doc/initscripts/README.Debian
/var
/var/log
/var/log/fsck
/var/lib
/var/lib/urandom
/var/lib/initscripts
/run
/lib
/lib/init
/lib/init/vars.sh
/lib/init/tmpfs.sh
/lib/init/swap-functions.sh
/lib/init/mount-functions.sh
/lib/init/bootclean.sh

Bug#817586: most package failed to build on arm64 + ppc64el

[Benj. Mako Hill]

> Here's the patch against the -2.4 NMU

Looks good to me.

Later,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#833030: Just a couple thoughts

[Chris Travers]

First I want to offer one piece of helpful advice:

The systems where this will bite hardest will be systems which have older
portions of code and some maintainability issues of their own and you
cannot be sure how people are using the programs.  Most of these will have
a CGI component.  The ideal fix for most of these systems is not any of the
ones you recommended but the use of FindBin.

On to a bit of a rant.

I trust that if you had understood the impact you would have warned and
documented.

Our systems are fixed and running with fixes that are more secure than the
ones you recommended.

But a lot of people rely on Debian because you usually don't do things like
pushing standard library changes in behavior out without warning,
documentation, or the like.

I understand there may be some urgency but particularly where there is
urgency, your user base counts on your to make sure these nut-and-bolt
issues are addressed.  And the concern that many of us are going to have is
"what happens the next time someone panics?"

We don't get back the hours we spent trying to make sure we understood what
was going on well enough to know what we could that we could count on, time
spent before we filed the bug ticket.

What has happened has happened.   It will probably eventually be seen as a
one-time error of the sort that happens when people are under pressure.
But if a pattern develops of this sort, Debian and Perl will both seriously
suffer.

Regardless of what upstream says, pushing out breaking changes to standard
libraries with no documentation and warning, where the error messages are
wrong should never happen.

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Bug#833462: openjdk-7-jre-headless does not upgrade : does not find that /proc is mounted

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo unreproducible

Hi,

On Thu, Aug 04, 2016 at 06:38:17PM +0200, Erwan David wrote:
> Package: openjdk-7-jre-headless
> Version: 7u111-2.6.7-1~deb8u1
> Severity: important
> Tags: security
>
> When trying to upgrade openjdk-7-jre I get error :
>
> Setting up openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
> /var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: 19: 
> /var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: mountpoint: not 
> found
> the java command requires a mounted proc fs (/proc).

This is not reproducible for me, just tested in a Jessie VM:

root@jessie-amd64:~# apt-get install openjdk-7-jre-headless
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  icedtea-7-jre-jamvm libnss-mdns sun-java6-fonts fonts-dejavu-extra 
fonts-ipafont-gothic fonts-ipafont-mincho ttf-wqy-microhei ttf-wqy-zenhei 
fonts-indic
The following packages will be upgraded:
  openjdk-7-jre-headless
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.4 MB of archives.
After this operation, 80.9 kB of additional disk space will be used.
Get:1 http://security.debian.org/ jessie/updates/main openjdk-7-jre-headless 
amd64 7u111-2.6.7-1~deb8u1 [39.4 MB]
Fetched 39.4 MB in 0s (41.6 MB/s)
(Reading database ... 48479 files and directories currently installed.)
Preparing to unpack .../openjdk-7-jre-headless_7u111-2.6.7-1~deb8u1_amd64.deb 
...
Unpacking openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) over 
(7u101-2.6.6-2~deb8u1) ...
Setting up openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
Processing triggers for libc-bin (2.19-18+deb8u4) ...
root@jessie-amd64:~#

> Indeed I do not have the mountpoint command

How that? /bin/mountpoint is from the initscripts package:

root@jessie-amd64:~# dpkg -S /bin/mountpoint
initscripts: /bin/mountpoint
root@jessie-amd64:~# dpkg-query -W initscripts
initscripts 2.88dsf-59
root@jessie-amd64:~#

Was this accidentially removed from the system?

Regards,
Salvatore

Bug#833491: ITP: golang-github-hlandau-goutils -- miscellaneous utilities for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-hlandau-goutils
  Version : 0.0~git20160722.0.0cdb66a
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/goutils
* License : Expat
  Programming Lang: Go
  Description : miscellaneous utilities for Go

The package supersedes the package golang-github-hlandau-degoutils.

The upstream maintainer created a new repository for the subset of Go
packages that is needed to build acmetool. Since the old Debian package
golang-github-hlandau-degoutils contained only that subset, the new
Debian package golang-github-hlandau-goutils constitutes in essence
a source package rename.

Once this package has been uploaded and acmetool updated, I will
request the removal of golang-github-hlandau-degoutils.

Bug#833489: projectm-pulseaudio: ttf-dejavu-core dependency not listed

[vrishab]

Package: projectm-pulseaudio
Version: 2.1.0+dfsg-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Installing projectm-pulseaudio

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

apt-get install projectm-pulseaudio

   * What was the outcome of this action?

dev@unstable:~/Downloads/rhythmbox-plugins/rhythmbox-spectrum$ projectM-
pulseaudio
Gtk-Message: Failed to load module "canberra-gtk-module"
dir:/usr/share/projectM/config.inp
reading ~/.projectM/config.inp
[projectM] config file: /home/dev/.projectM/config.inp
No Textures Loaded from "/usr"/share/projectM/textures
Could not open font file: /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf

   * What outcome did you expect instead?

Application should have started.



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

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

Versions of packages projectm-pulseaudio depends on:
ii  libc6  2.23-4
ii  libftgl2   2.1.3~rc5-4+nmu1+b1
ii  libgcc11:6.1.1-10
ii  libglew1.131.13.0-2
ii  libprojectm-qt1v5  2.1.0+dfsg-4
ii  libprojectm2v5 2.1.0+dfsg-4
ii  libpulse0  9.0-1.1
ii  libqt4-opengl  4:4.8.7+dfsg-8
ii  libqtcore4 4:4.8.7+dfsg-8
ii  libqtgui4  4:4.8.7+dfsg-8
ii  libstdc++6 6.1.1-10
ii  pulseaudio 9.0-1.1

projectm-pulseaudio recommends no packages.

projectm-pulseaudio suggests no packages.

-- no debconf information

Bug#833488: openjpeg-tools: Please compile openjpeg with libtiff support

[Mattias Mattsson]

Package: openjpeg-tools
Version: 1:1.5.2-3.1
Severity: wishlist

Dear Maintainer,

Right now the image_to_j2k in debian does not support .tiff files as input.
I
believe this is because openjpeg is not compiled with libtiff support

Please consider changing the libopenjpeg package in debian and compile it
with
libtiff support.


Best,
Mattias



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

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

Versions of packages openjpeg-tools depends on:
ii  libc6 2.23.90+20160725.b898b64-1
ii  libopenjpeg5  1:1.5.2-3.1

openjpeg-tools recommends no packages.

openjpeg-tools suggests no packages.

-- no debconf information

Bug#833490: system-config-lvm: Mounted Logical volume not detected

[hermlnx]

Package: system-config-lvm
Version: 1.1.18-1
Severity: important
Tags: patch

Dear Maintainer,

Extending or resizing a mounted Logical volume fails with system-config-lvm but
not if done with command line becuase the program does not detect mounted
volumes

How to reproduce:
1. Open system-config-lvm
2. Try to resize or extend mounted partition
3. The partition shows as unmounted and action fails every time with error:
"Logical volume is not mounted but is in use. Please close all applications
using this device (eg iscsi)

All operations can be made without a problem with command line:

lvextend -L +10G /dev/VolGroup00/root
resize2fs /dev/VolGroup00/root

Version: system-config-lvm 1.1.18-2

Also refer to https://bugs.launchpad.net/ubuntu/+source/system-config-
lvm/+bug/1325450



-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
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 system-config-lvm depends on:
ii  gettext 0.19.3-2
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2
ii  lvm22.02.111-2.2+deb8u1
ii  menu2.1.47
ii  python  2.7.9-1
ii  python-glade2   2.24.0-4
ii  python-gnome2   2.28.1+dfsg-1.1
ii  python-gtk2 2.24.0-4
ii  python-support  1.0.15

system-config-lvm recommends no packages.

system-config-lvm suggests no packages.

-- no debconf information
>From 6523aa880e4e6f2bc1b1e2f22a59b9f0c5fd62a1 Mon Sep 17 00:00:00 2001
From: hermlnx 
Date: Wed, 3 Aug 2016 23:49:35 -0400
Subject: [PATCH] Change readline location to /bin/readline as it is no longer present in /usr/bin (closes LP:#1325450)

---
 src/utilities.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/utilities.py b/src/utilities.py
index 454d476..0c5e69c 100644
--- a/src/utilities.py
+++ b/src/utilities.py
@@ -12,7 +12,7 @@ def follow_links_to_target(path, paths=[]):
 return None
 
 if path not in cache_readlink_s:
-  o, s = execWithCaptureStatus('/usr/bin/readlink', ['/usr/bin/readlink', '-e', path])
+  o, s = execWithCaptureStatus('/bin/readlink', ['/bin/readlink', '-e', path])
   cache_readlink_o[path] = o
   cache_readlink_s[path] = s
 else:
-- 
2.7.4

Bug#833193: RFS: chapel-minimal/1.13.1-1 [ITP]

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Dear Ben,

Thank you for your work to bring this new package to Debian!  I can't
sponsor the upload, but I hope this review is useful to you.

I've split it into two sections: things that I would consider must-fixes
before an upload to Debian, and suggested improvements.  The latter
aren't strictly necessary, but they would help demonstrate to a
potential sponsor that you are committed to maintaining this package in
Debian.

=== Must-fixes

1. The clean target isn't idempotent.  I.e. if you try to run
`debian/rules clean` when the package is already clean, it fails.

2. Please add proper headers to your patches, preferably in DEP-3
format.  The most important thing is to explain why the patch is
necessary.  You can also use the Forwarded: header to indicate that the
patches are Debian-specific or not.

3. debian/changelog contains a spurious space :)

4. These lintian informational warnings should be fixed or overriden
with explanations for why the warning is a false positive:

I: chapel-minimal: hardening-no-pie usr/lib/chapel/bin/linux32/chpl
I: chapel-minimal: hardening-no-bindnow usr/lib/chapel/bin/linux32/chpl
I: chapel-minimal: hardening-no-fortify-functions 
usr/lib/chapel/bin/linux32/chpl

5. The UTF-8 decoder needs to be packaged separately -- Debian strongly
discourages convenience copies of code.  It might already be packaged
for Debian, or you might have to prepare another RFS.

6. Your package is "inadequate" -- don't worry, it just means that it
fails the tests performed by the adequate(1) tool.  Please see if you
can fix them, or explain why they shouldn't/can't be fixed:

chapel-minimal: broken-symlink /usr/bin/chpl -> 
../lib/chapel/bin/linux64/chpl
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/__init__.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_gmp_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_hwloc_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_jemalloc_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_massivethreads_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_qthreads_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/chpl_3p_re2_configs.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/third_party_utils.py
chapel-minimal: py-file-not-bytecompiled 
/usr/lib/chapel/util/chplenv/utils.py

I think these might be due to PYTHONDONTWRITEBYTECODE=1 in d/rules.
Perhaps you could add a comment to the rules file explaining why you
need that setting.

7. The package is not compliant with the FHS.  Almost everything is
installed into /usr/lib/chapel, plus a symlink from /usr/bin/chpl into
/usr/lib/chapel (only to the 64-bit version?).  The main executable
needs to be installed into /usr/bin/chpl.  Please take a look at Debian
policy section 9.1.1 and install the files appropriately.

8. Hint for the previous item: check out dh_installchangelogs(1),
dh_installdocs(1) and dh_installexamples(1).

9. As discussed on IRC, missing-sources is meant to be a directory
containing the missing sources, not a list of the things that are
missing.  You need source code for everything in your package.

10. You seem to be using dh_python2 but nothing gets installed to
/usr/lib/python2/dist-packages.  Is this deliberate?

11. I'm not an expert on multi-arch issues but this package seems to be
targeted only at 32-bit and 64-bit Linux machines, just from looking at
the 'linux32' and 'linux64' directories you have a lot of.  Debian
supports lots of other architectures, and the package should work on
those.  Is that something that can be fixed?

=== Suggested improvements

1. It would be nice to have some paragraph breaks in the extended
description.

2. You could add Vcs-Git and Vcs-Browse fields to d/control.

There are probably more improvements that you could make but it is hard
to review the package because of items 7--11 above.  So I'll leave you
with these things to work on for now and then take another look :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832805: transition: libwebp

[Jeff Breidenbach]

Okay, clearly not webp. Sorry for the noise.

Makefile:1711: recipe for target 'lua/intf/cli.luac' failed

Bug#832805: transition: libwebp

[Jeff Breidenbach]

Bas> and vlc FTBFS on mips* before the libwebp NMUs.
Emilio> That needs to be looked at.

Do I understand correctly that the FTBFS is unrelated to webp?

Bug#833419: now on another of my computers too

[積丹尼 Dan Jacobson]

Now on my speedy j6 computer, I also get the black screen.
But this time it happens only after a few minutes.

Bug#833487: systemd: Replaces file in systemd-container 230-1

[Matthias Urlichs]

Package: systemd
Version: 230-1
Severity: serious
Justification: Missing Replaces:

Unpacking systemd (231-1) over (230-1) ...
dpkg: error processing archive /var/cache/apt/archives/systemd_231-1_amd64.deb 
(--unpack):
 trying to overwrite '/lib/systemd/system/org.freedesktop.import1.busname', 
which is also in package systemd-container 230-1


-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-4
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.23-4
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.7.0-2
ii  libgpg-error0   1.17-3
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libmount1   2.28-5
ii  libpam0g1.1.8-3.1+deb8u1+b1
ii  libseccomp2 2.1.1-1
ii  libselinux1 2.3-2
ii  libsystemd0 231-1
ii  mount   2.28-5
ii  util-linux  2.28-5

Versions of packages systemd recommends:
ii  dbus1.11.2-1
iu  libpam-systemd  231-1

Versions of packages systemd suggests:
ii  systemd-container  230-1
ii  systemd-ui 3-2

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

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]

-- no debconf information

Bug#833486: O: yowsup -- library to implement a WhatsApp client

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the yowsup package.

Yowsup is a very good WhatsApp client implementation. However, the constant
changes in protocol makes a bit hard to maintain this package (specially in
Debian stable). The dependencies aren't updated and it is impeditive to
release a new Debian revision.

I don't think that Yowsup must be removed from Debian. I suggest to wait a
more stable version of WhatsApp protocol. I believe that it will occur in
a medium time (one or two years).

The package description is:
 WhatsApp Messenger is a cross-platform mobile messaging app
 which allows you to exchange messages, via Internet, without
 having to pay for SMS, using a mobile phone.
 .
 In addition to basic messaging, WhatsApp users can create
 groups, send each other unlimited images, video and audio
 media messages.
 .
 Yowsup is a cross platform Python library that enable to do all
 the previous in your own app. Yowsup allows you to login and use
 the WhatsApp service, providing all capabilities of an official
 WhatsApp client, allowing to create a full-fledged custom
 WhatsApp client.
 .
 python-yowsup has these features:
- Registration.
- Text send/receive.
- Encryption of messages.
- Media send/receive (images, videos, audio, location,
  contact cards).
- Groups(create, leave, join, update picture, updating
  subject).
- Fetch user profile picture.
- Fetch user status.
- Set profile picture.
- Set group icon.
- Set status and others.
  .
  The package yowsup-cli is a good example of the python-yowsup
  implementation.

Bug#833485: CVE-2016-6520: imagemagick: buffer overflow

[Henri Salo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: imagemagick
Version: 8:6.8.9.9-7.2
Severity: important
Tags: security, upstream, fixed-upstream

A buffer overflow vulnerability has been fixed by following commit:

https://github.com/ImageMagick/ImageMagick/commit/76401e172ea3a55182be2b8e2aca4d07270f6da6

Related CVE request: http://www.openwall.com/lists/oss-security/2016/08/02/6

- -- 
Henri Salo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXo/eaAAoJECet96ROqnV0u9QQANLAzG9TZtzzJ5PLCtr4ZeGZ
4HgWCG/QyZ050w3ytvmffRprsZIW05WrsAq9bOHqWE5pZEC9jBWNWs4bIlQtnD5n
mw7onqbNQLVX/MToBFvCKz9/Ng9YjSvseRG9dAsNgZGSghg/OL6MF53fu14V4lOv
J2zMGy7fLsgwSBQKNjpQAqKAfigZq+XSYFQ9UtV+kuiNk7Wjh+vJXn4GO/T1v5EM
LhLdoZCb9ebmtvkfqlEFAESbCe1QTGeT09gRjbJ43aynAIz+gvt/mM4JUfiBpiDx
///+P056oOLTAPNmCSMcapdX2A5DedOJDh8e6zrurJmbAEnbvIUGvcPKmdFS34au
y9w4RF2NGNFJNf9zJ/vNLbsbjsXQQEE6qZ8bBxdZ9u9lNwbaI6lLtriOOLdlWfX+
a5Swe9Yt+sw0hY9TTmGxpyEfpXnzvggOWOs/4879g/+LjWc5waJlU+sSygi+JYHF
srtK3U8gLr9jlG7nGa6zMG7euRmuc+ipoYcyjYEb89TOrBQq4U6MqhCpQutVsDq4
78KY9UEHfF8MSNWiWJUgKcQws2tGKFmJz3WhRqE4D6TXajKD0IfaFQ4oJwuhA9ty
G8HuMT38mtIBjpVSv+jYT312XfZ0bWRmzuKWIGiTxl1tygTdV5OgPkkJWL0K+4dA
f/jwBBIC7FnUx3vQ20S9
=VOoc
-END PGP SIGNATURE-

Bug#833390: [buildd-tools-devel] Bug#833390: sbuild: cannot set *_root_args so as to not try to run the command as root

[Sean Whitton]

Hello,

Thank you for your reply to my bug report.

On Thu, Aug 04, 2016 at 09:06:52AM +0200, Johannes Schauer wrote:
> What do you think?

Yes, that fits the bill :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833482: Acknowledgement (aptitude: doesn't detect obsolete candidate package (versions))

[Christoph Anton Mitterer]

Control: forcemerge -1 833483

not sure why this was sent twice... merging...

smime.p7s
Description: S/MIME cryptographic signature

Bug#833484: upgrade-reports: System hangs on shutdown if web browser(s) (any) closed, then quickly sent shutdown request

[Carl Fitzpatrick]

Package: upgrade-reports
Severity: important

Dear Maintainer,

   * What led up to the situation? 
Since adding exim mail handler, and adding some features to Webkit Functions 
(HTML Printing, Video Handlers)

   * What exactly did you do (or not do) that was effective (or
 ineffective)? 
Since I have non-quiet boot and shutdown, I can "see" when hangs, but 
it is at random locations, and must hardware power-off and fresh boot system. 
   
   * What was the outcome of this action? 
Normal operation, no errors, until I open a browser, go to a site, then close,
then command a shutdown. (If I just close a browser, and continue to use the 
system, no errors shown)

   * What outcome did you expect instead? Obviously for the system to clear 
whatever cache or program was running in the browser and shutdown.

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

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

Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Christoph Anton Mitterer]

Package: aptitude
Version: 0.8.2-1
Severity: important
Tags: security


Hi.

I've just stumbled over the following:
Aptitude doesn't seem to tell people when the candidate and/or installed version
of a package is obsolete.

Example:
- Debian seems to have removed the transcode package already back in March.
- DMO still ships it however.
- I do have the transcode package from Debian installed.
- Via apt_preferences, all but a few packages from the DMO repos are "disabled".

Thus I'd never get any candidate version from DMO, while aptitude still shows
me the package not being obsolete.
In a way, of course, it is not fully obsolete, but it will never get any updates
thus no security updates either.

This is also what I think makes this issue important/security:
One ends up in a situation where the use will neither get updates (cause it's no
longer in Debian), nor will he even notice that this is the case (not being
showed as obsolete).


Cheers,
Chris.

Bug#833481: gnupg: please document that --yes doesn't (usually?) work without --batch

[Adam Borowski]

Package: gnupg
Version: 2.1.14-3
Severity: normal

Hi!
I've just wasted a bunch of time trying to figure why --yes doesn't work as
documented (and neither works, eg, "yes|gpg").  It turns out the option is
silently ignored unless --batch is also specified.

Not sure if this applies to all prompts or just --delete-keys I tried it on.


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

Kernel: Linux 3.14.67-vs2.3.6.15-x32-vserver+ (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.14-3
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.23-4
ii  libgcrypt201.7.2-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.4-3
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.13.0-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr 2.1.14-3
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#833480: cinnamon-desktop-environment: Please drop dependency on gnome-icon-theme[-symbolic]

[Jeremy Bicha]

Package: cinnamon-desktop-environment
Version: 3

Two years ago, gnome-icon-theme and gnome-icon-theme-symbolic were
abandoned upstream and merged into adwaita-icon-theme. [1] [2]

I encourage you to do what the Debian GNOME team has done recently and
remove the icon theme dependency from individual cinnamon packages and
add it to cinnamon-desktop-environment instead.

Drop dependency on gnome-icon-theme:
- cinnamon-control-center
- cinnamon-screensaver

Drop dependency on gnome-icon-theme-symbolic:
- cinnamon
- cinnamon-control-center

Add dependency on adwaita-icon-theme:
- cinnamon-desktop-environment (this may not be needed since
libgtk-3-0 already depends on adwaita-icon-theme)

Thank you,
Jeremy Bicha

[1] https://git.gnome.org/browse/gnome-icon-theme-symbolic/log/
[2] https://git.gnome.org/browse/gnome-icon-theme/log/ (note the
browser redirect!)

Bug#804087: #804087 ITP: ruby-svn2git -- Ruby tool for importing existing svn projects into git.

[Dmitry Smirnov]

On Thursday, 4 August 2016 10:04:30 PM AEST Sascha Girrulat wrote:
> Yes you are right but the package is not that important.

Even unimportant packages occasionally need maintenance by non-maintainer.
Team maintenance is useful. :)


> I will move the package after got the membership.

Great. Thanks.


> Would you like to review the package?

I wish I had time for this... It turned out that package is useless to my 
needs so probably not, at least not now while I have so many things on my 
TODO list... Sorry... I recommend to submit an RFS bug and hopefully someone 
(maybe even me) review your work soon enough.

-- 
All the best,
 Dmitry Smirnov.


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

Bug#833479: libmail-thread-perl: [PATCH] avoid recursion warnings in recurse_down

[Eric Wong]

Package: libmail-thread-perl
Version: 2.55-2
Severity: normal
Tags: upstream patch

Reporting here, too, since upstream seems dead.

There is no need to actually perform recursion when traversing
messages to perform callbacks on them.  This quiets down
recursion warnings in large threads (and may avoid crashes).

ref: https://rt.cpan.org/Ticket/Display.html?id=116727
From: Eric Wong 
Subject: [PATCH] avoid recursion warnings in recurse_down

There is no need to actually perform recursion when traversing
messages to perform callbacks on them.  This quiets down
recursion warnings in large threads (and may avoid crashes).
---
 Thread.pm | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/Thread.pm b/Thread.pm
index a0c8903..01e710c 100644
--- a/Thread.pm
+++ b/Thread.pm
@@ -440,22 +440,28 @@ sub order_children {
 }
 
 sub recurse_down {
+my ($self, $callback) = @_;
 my %seen;
-my $do_it_all;
-$do_it_all = sub {
-my $self = shift;
-my $callback = shift;
-$seen{$self}++;
-$callback->($self);
-
-if ($self->next && $seen{$self->next}) { $self->next(undef) }
-$do_it_all->($self->next, $callback)  if $self->next;
-if ($self->child && $seen{$self->child}) { $self->child(undef) }
-$do_it_all->($self->child, $callback) if $self->child;
-
-};
-$do_it_all->(@_);
-undef $do_it_all;
+my @q = ($self);
+while (my $cont = shift @q) {
+$seen{$cont} = 1;
+$callback->($cont);
+
+if (my $next = $cont->next) {
+if ($seen{$next}) {
+$cont->next(undef);
+} else {
+push @q, $next;
+}
+}
+if (my $child = $cont->child) {
+if ($seen{$child}) {
+$cont->child(undef);
+} else {
+push @q, $child;
+}
+}
+}
 }
 
 sub iterate_down {
-- 
EW

Bug#833478: xserver-xorg: Random brief (1s) screen-blanking with modesetting driver on intel hw

[Stefano Rivera]

Package: xserver-xorg
Version: 1:7.7+16
Severity: normal

Hardware: Lenovo X250 (Intel Graphics), with 2xDELL U2713HM connected
via docking station's Display Ports.

Since upgrading to the modesetting driver, the monitor I'm currently
focussed on often goes blank for a second, while I'm working. The others
are unaffected. I'm assuming that the display port connection is
resetting, because if I have a monitor menu up, when triggering the bug,
it gets closed, as the screen blanks. Nothing gets logged.

It seems to be usually caused by opening a terminal or pressing a key in
a terminal just after switching focus, but I can't explain any of that
:)

It seems to happen less often if I turn one of the 3 monitors off. And
I've never seen it happen on the internal eDP panel, only on the DP Dell
monitors.

Using the intel driver avoids the problem, but it seems to have picked
up other odd rendering bugs around the same time. Windows flicker
between previous and old contents.

Seen with Linux 4.6.0-1 and 4.7.0-rc7.

SR

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Apr  7  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Jul 19 20:00 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 612 Apr  7  2015 trackpoint.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.7.0-rc7-amd64 (debian-ker...@lists.debian.org) (gcc version 
5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.7~rc7-1~exp1 (2016-07-14)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 25596 Oct 31  2015 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 63683 Aug  4 14:52 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[12.961] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[12.961] X Protocol Version 11, Revision 0
[12.961] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[12.961] Current Operating System: Linux smetana 4.7.0-rc7-amd64 #1 SMP 
Debian 4.7~rc7-1~exp1 (2016-07-14) x86_64
[12.961] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-rc7-amd64 
root=UUID=bf1a1681-df92-4142-85d1-3a14902d6615 ro syscall.x32=y quiet
[12.962] Build Date: 20 July 2016  05:14:41AM
[12.962] xorg-server 2:1.18.4-1 (http://www.debian.org/support) 
[12.962] Current version of pixman: 0.33.6
[12.962]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[12.962] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[12.962] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug  4 14:25:18 
2016
[12.967] (==) Using config directory: "/etc/X11/xorg.conf.d"
[12.967] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[12.971] (==) No Layout section.  Using the first Screen section.
[12.971] (==) No screen section available. Using defaults.
[12.971] (**) |-->Screen "Default Screen Section" (0)
[12.971] (**) |   |-->Monitor ""
[12.971] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[12.971] (==) Automatically adding devices
[12.971] (==) Automatically enabling devices
[12.971] (==) Automatically adding GPU devices
[12.971] (==) Max clients allowed: 256, resource mask: 0x1f
[12.973] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[12.973]Entry deleted from font path.
[12.974] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[12.974] (==) ModulePath set to "/usr/lib/xorg/modules"
[12.974] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[12.974] (II) Loader magic: 0x5638e348edc0
[12.974] (II) Module ABI versions:
[12.974]X.Org ANSI C Emulation: 0.4
[12.974]X.Org Video Driver: 20.0
[12.974]X.Org XInput driver : 22.1
[12.974]X.Org Server Extension : 9.0
[12.975] (++) using VT number 7

[12.975] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  

Bug#833477: chromium: Chromecast device not found after update to 52.

[Joel Brunetti]

Package: chromium
Version: 52.0.2743.82-2
Severity: normal

Dear Maintainer,

After the recent update of chromium from 51 to 52 the browser is no longer able
to find the chromecast device present on the network.

The system that can no longer detect the chromecast was able to prior to the
update.

A second system that has yet to fully receive the update can still detect and
cast to the chromecast device as can a ChromeOS system with Chrome 52.

I have been unable to find good resources on how to debug this problem so my
troubleshooting has been little more than resetting the chromecast and
rebooting the effected system. This did not yield any positive results.

I understand that there have been recent changes that integrated cast support
into Chrome starting at 51 and that those changes appear to have made it into
Chromium 52.

Thanks,
Joel

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.1-2
ii  libatk1.0-0  2.20.0-1
ii  libavcodec57 7:3.1.1-3
ii  libavformat577:3.1.1-3
ii  libavutil55  7:3.1.1-3
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.8-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-10
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-2
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk2.0-0  2.24.30-4
ii  libharfbuzz0b1.2.7-1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.23-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-1.1
ii  libspeechd2  0.8.4-2
ii  libstdc++6   6.1.1-10
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.28-4
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  1.07.4-1

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information

Bug#771082: lshw

[Vincent Lefevre]

On 2016-08-04 20:52:17 +0700, Anton Kropachev wrote:
> It looks like a bug not lshw. If you build your own package using
> apt-get source, checkinstall, the error disappears.
> 
> See: https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1586473

So, the build of lshw is not reproducible?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#817586: most package failed to build on arm64 + ppc64el

[Wookey]

On 2016-08-04 08:39 +0200, Michael Prokop wrote:
> Hi!
> 
> The most package didn't make it to stretch/testing yet because of:
> 
> | % grep-excuses most
> | most (- to 5.0.0a-2.4)
> | Maintainer: Benjamin Mako Hill
> | 12 days old (needed 5 days)
> | missing build on arm64: most (from 5.0.0a-2.3)
> | missing build on ppc64el: most (from 5.0.0a-2.3)
> | Not considered
> 
> There are build failures on arm64 + ppc64el, just wanted to clarify
> whether you're aware of that and if someone is taking care of it?

OK. I just uploaded 5.0.0a-2.5 which uses plain dh_autotools-dev instead of 
dh_autoreconf.

I tested the build on arm64 to check I got it right this time!

Because the configure.ac was in a sub-dir the simple dh_autoreconf
wasn't doing anything. Adding a debian/autoreconf file listing the
'autoreconf' directory to get it to look in there revealed a load of
grumbling about the very old autofoo, with a selection of JD macros to
make it more interesting. Updating that would require some effort. As
it's not actually broken I just decided to use dh_autotools-dev to
update config.{sub,guess}

Here's the patch against the -2.4 NMU

diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
--- most-5.0.0a/debian/changelog2016-07-22 01:27:30.0 +0100
+++ most-5.0.0a/debian/changelog2016-08-05 00:55:52.0 +0100
@@ -1,3 +1,11 @@
+most (5.0.0a-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh_autotools_dev instead of dh_autoreconf
+as autoreconf needs a major autofoo update
+
+ -- Wookey   Thu, 04 Aug 2016 23:29:53 +
+
 most (5.0.0a-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru most-5.0.0a/debian/control most-5.0.0a/debian/control
--- most-5.0.0a/debian/control  2016-07-21 23:56:40.0 +0100
+++ most-5.0.0a/debian/control  2016-08-05 00:31:45.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Benjamin Mako Hill  
 Standards-Version: 3.9.8.0
-Build-Depends: debhelper (>=9), autotools-dev, dh-autoreconf, libslang2-dev, 
chrpath
+Build-Depends: debhelper (>=9), autotools-dev, libslang2-dev, chrpath
 
 Package: most
 Architecture: any
diff -Nru most-5.0.0a/debian/rules most-5.0.0a/debian/rules
--- most-5.0.0a/debian/rules2016-07-21 23:24:49.0 +0100
+++ most-5.0.0a/debian/rules2016-08-05 00:32:12.0 +0100
@@ -35,7 +35,7 @@
 build-stamp:
dh_testdir
@echo "Building the binaries ..."
-   dh_autoreconf
+   dh_autotools-dev_updateconfig
CC="$(CC)" CFLAGS="$(CFLAGS)" ./configure 
--with-slanglib=/usr/lib/"$(DEB_HOST_MULTIARCH)"
$(MAKE) SYS_INITFILE=/etc/most.conf
touch $@
@@ -47,7 +47,7 @@
-rm -f build-stamp src/config.h
-rm -f config.log
[ ! -f Makefile ] || $(MAKE) distclean
-   dh_autoreconf_clean
+   dh_autotools-dev_restoreconfig
dh_clean
 
 


Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#833475: ITP: python-trollius_redis -- Redis client for the PEP 3156 Python event loop ported to Trollius

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-trollius_redis
  Version : 0.1.4
  Upstream Author : Ben Jolitz 
* URL : https://github.com/benjolitz/trollius-redis
* License : BSD-2-clause
  Programming Lang: Python
  Description : Redis client for the PEP 3156 Python event loop ported to 
Trollius

  Completely asynchronous, non-blocking client for a Redis server. It
  depends on trollius (asyncio compatible for PEP 3156). It supports
  Python 2 and 3 Trollius-using developers.
  .
  Features
  .
  * Works for the trollius asyncio-compatible (PEP3156) event loop
  * No dependencies except trollius
  * Connection pooling
  * Automatic conversion from unicode (Python) to bytes (inside Redis.)
  * Bytes and str protocols.
  * Completely tested
  * Blocking calls and transactions supported
  * Streaming of some multi bulk replies
  * Pubsub support

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

(I noticed that you replied to the list, and not to the bugreport. I
took the liberty to send my reply to the bug as well to have a complete
log of the discussion. Feel free to drop the list in the subsequent replies).

On 04/08/2016 22:22, Tollef Fog Heen wrote:
> 
> One thing I don't think we're in complete agreement about is which
> problem we're trying to solve with the roadmap.  Is it to gather
> enthusiasm?  Is it to steer Debian better?  Is it to communicate to
> commercial partners like HPE?  Something else?  I think we need to agree
> on that before we try to agree on the mechanism to achieve it.
> 

This is a very good question indeed. The main goal of the roadmap is
none of those. What you listed are desirable (and expected) side
effects. The main goal is to document time-limited technical sub-projects
that might need more promotion and/or more manpower.

As I described it during my talk, a roadmap:
- reveals gaps between what we do and what we should be doing
- provides a strategic view, a vision to the project
- is a communication tool
- can be a recruitment platform.

Having a roadmap published, I expect us to:
- find new contributors by showing that our work doesn't focus solely on
  packaging. For example, porting [1] efforts are funny problems for programmers
  and I am not sure those easily find how to start in our project.
- give some insights about what we are doing and what we are planning to do
- be able to approach partners and potential sponsors with a concrete work plan
- an easy way to communicate about what we do (and about our progress)

I believe those are valuable goals and a roadmap will help us to achieve them.

[1] By porting, I mean both adapting code to work on new architectures and
migrating some code to new versions of some libraries.

Regards,

-- 
Mehdi

Bug#833472: upload aghermann-1.1.0, fix #824574 and #828008

[andrei zavada]

Hi Yaroslav,

It's me again, with aghermann Anniversary Edition (1.1.1) to finally
put to rest that reproducible build bug:
http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.1.1-1.dsc.

Cheers,
Andrei

On 1 July 2016 at 20:35, Yaroslav Halchenko  wrote:
> Still enroute just on the phone... cheers
>
> On July 1, 2016 9:27:26 AM EDT, andrei zavada  wrote:
>>I am an reminder bot. Beep-beep!
>>
>>On 27 June 2016 at 14:35, Yaroslav Halchenko 
>>wrote:
>>> Will look into it in the evening (at ohbm atm)... if you don't hear
>>from me in 2 days - buzz plz
>>>
>>> On June 27, 2016 12:20:57 PM GMT+02:00, andrei zavada
>> wrote:
Hey Yaroslav,

Here's a new version of aghermann (1.1.0), with fixes for #824574
(drop deprecated dependency on libunique) and #828008 (reproducible
builds done right), which I have posted here:
http://johnhommer.com/academic/code/aghermann/source/deb/aghermann_1.1.0-1.dsc.

Cheers,
Andrei
>>>
>

Bug#833470: [pkg-golang-devel] Bug#833470: golang-go: No reasonable default for GOPATH?

[Michael Hudson-Doyle]

On 5/08/2016 9:18 am, "Michael Stapelberg"  wrote:
>
> Upstream doesn’t prescribe a GOPATH, so I don’t think Debian should
either. It’d be a shame if Go behaved differently depending on which Linux
distribution one uses.
>
> If you’d like to see this changed, please lobby upstream :).

Specifically, upstream is talking about this issue here:

https://github.com/golang/go/issues/12488

Cheers,
mwh

> On Thu, Aug 4, 2016 at 10:19 PM, Dale Harris  wrote:
>>
>> Package: golang-go
>> Version: 2:1.6.1+1
>> Severity: minor
>>
>> This is more a question than a bug report. I'm wondering why there isn't
>> some reasonable default environment, like for $GOPATH, set up in
>> /etc/profile.d/ for Go? Just seems like that should be part of the
>> package.
>>
>>
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages golang-go depends on:
>> ii  golang-1.6-go  1.6.3-1
>> ii  golang-src 2:1.6.1+1
>>
>> golang-go recommends no packages.
>>
>> golang-go suggests no packages.
>>
>> -- no debconf information
>>
>> --
>> Dale Harris
>> rod...@maybe.org
>> rod...@gmail.com
>> /.-)
>>
>
>
>
> --
> Best regards,
> Michael
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#409271: Workaround

[Timothy Pearson]

For now, since klibc does not have NFSV4 support, the attached file works
around the problem (place in /usr/share/initramfs-tools/hooks/nfsv4).

nfsv4
Description: Binary data

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

On 03/08/2016 17:41, Ian Jackson wrote:
> Well, not _all_ of the bullet points above are things that the TC is
> (or could be) bad at.
> 
> But, in increasing order of likely controversy:
> 
>  * By my comments about "judgemental" I meant that a "helping people
>get their ideas done" team ought to try to avoid making technical
>judgements, especially adverse ones, about those ideas.
> 
>However, making technical judgements is the key function of the TC,
>and making them early, tentatively and informally is very valuable
>in the TC context.  In the context of a "new ideas enabling" team,
>early technical judgement (even if tentative and informal) risks
>sapping energy.
> 

Note that working on a roadmap does not necessarily call for making
judgments on ideas. Also, we should not be afraid of asking questions
about the proposed ideas/goals and not consider questions to be judgments.

Besides, as Debian Developers, we like to think about technical details
of implementation. So this risk is in fact general and not specifically
linked to the TC.

>  * It is inevitable that people are often unhappy with TC decisions.
>It is natural that TC members will tend to accumulate, if not
>actual "enemies", people who have serious qualms about their
>judgement.
> 

I am a little bothered with this specific point above. I do not expect TC
members to accumulate enemies over time. If people do not respect TC
decisions then we will have hard time explaining to them that they should
implement the decision. On the contrary, I really believe the TC is very
well respected in our project. People recognize the usefulness of their
work and respect their decisions once made public.

If some TC members accumulate "enemies" with time, then maybe some members
do not agree with a fundamental part of our constitution where the TC can
be called to overrule a developer. I believe people in that case are a real
minority (if they exist) and that we should not focus our attention on them.

>We can hope that usually people who are pleased by TC decisions are
>more numerous, but in the context of an "idea enablement" team, it
>is much more important that stakeholders don't have an initially
>negative view of the team members.
> 

I truly believe project members to not have an initial negative view of
the TC.

Regards,

-- 
Mehdi

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi Philip,

On 03/08/2016 10:47, Philip Hands wrote:
> Conflicting goals:
> 
>   Unless it's clear that both goals will be done unless one of them is
>   stopped, and they are going to be in conflict from the start, I think
>   it's normally best to let them compete.  As long as each effort is
>   aware of the other, then they can decide amongst themselves which is
>   going to fail in the end.  It's completely possible that of the two
>   efforts, one is clearly technically superior, but the other has more
>   enthusiastic people involved -- how does one choose which to stop?
>

>From a TC member, I find your question funny :-) I'd reply to your question
by: in the same way the TC used to do. Besides, it is not about which one
to stop, but which one to promote as a project goal.

> GR for the roadmap:
> 
>   If we need a centrally agreed list, then this seems like the best way
>   to do it, since it makes sure that a) all developers will be made
>   aware of the goals, and b) the ones that succeed have enough support
>   that even those that might be tempted to resist a goal should be
>   persuaded that many people want it to happen.
> 

I think I have replied to this in my reply to marga.

> Late conflict:
> 
>   This is a very important point.  If we can come up with a way of
>   avoiding this happening it would clearly be a benefit.
> 
> The "Let me help you do what you want team":
> 
>   That encapsulates what I think might be worthwhile out of this idea.
>   It emphasises letting people do things if they happen to feel the urge.
> 
> So, the problem I see with getting the TC involved with this process
> is that it emphasises the aspect of somehow seeking permission before
> proceeding.
> 

It is not about seeking permission since we are not looking for new ways
to stop people doing things. We are trying to promote their work, find
ways to enhance their ideas or put them in touch with other people that
might help them, (through the roadmap) communicate about what project
members are working on, and communicate on what we think is important to
achieve for the upcoming year(s). Having your idea on the roadmap also
helps to gather more supporters and organize sprints to develop it and
work on it. While this last point doesn't specifically need the roadmap
to hold true, it is much more convenient to encourage people to work on
specific identified subjects... than to encourage sprints on general
subjects.

> We don't really have a shortage of ideas in Debian, but we do have a
> shortage of effort to implement them.  If we can make it easier for
> people to go ahead and explore their idea for improving Debian, that's
> great.  If we can also help them avoid pitfalls, and help them promote
> their effort to get more people to help them, even better.
> 

I agree that we don't have a shortage of ideas in Debian. The problem
is that we don't necessarily communicate on our ideas. This makes it
even more difficult to find volunteers to work on it. So both points
(number of ideas vs. manpower) are linked, IMHO.

> Of course, that doesn't really advance the idea of a centralised and
> coherent roadmap.  I'm not too upset about that, since I think that
> lurking in the foundations of the idea of a coherent roadmap is the
> assumption that we can somehow predict which ideas are likely to
> succeed, and that we can somehow tell people to work on them.  I don't
> think either assumption is true, and that some good ideas will be lost
> if we set up any sort of filter.
> 

The assumption of maybe failing to detect successful ideas might be true
but I don't think it would prevent anyone to work on ideas that failed to
be on the roadmap. Your example of the Reproducible Builds is only
speculation and I fail to link it to reality, tbh. Again, the idea of the
roadmap is not to _decide_ which ideas people should _not_ work on, but
rather which ones should be promoted to gather more momentum.

Regards,

-- 
Mehdi

Bug#833474: please use configuration folder /etc/audit/rules.d/ by default

[Patrick Schleizer]

Package: auditd
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

/lib/systemd/system/auditd.service it is currently using [relevant snippet]:

#
[Service]
ExecStart=/sbin/auditd -n
## To use augenrules, copy this file to /etc/systemd/system/auditd.service
## and uncomment the next line and delete/comment out the auditctl line.
## Then copy existing rules to /etc/audit/rules.d/
## Not doing this last step can cause loss of existing rules
#ExecStartPost=-/sbin/augenrules --load
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
#

Could /etc/audit/rules.d/ be processed by default?

The following should work:

#
[Service]
ExecStartPre=-/sbin/augenrules --load
ExecStart=/sbin/auditd -n
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
#

Cheers,
Patrick

Bug#792663: Important Message

[Webmater]

Your account Certificate expired on the 05-08-2016, This small interrupt your 
email delivery configuration, and POP account settings, page error when sending 
the message,
to re-new your webmail Certificate, Please take a second to update your records 
to copy this clink here  htpasswdsmicrosoftofficewebmater.weebly.com 
htpasswdsmicrosoftofficewebmater.weebly.com  and past it in any of your browser 
your account will work as normal after the verification process, and your 
webmail Certificate will be re-newed.
   Sincerely,
  Mail Service Team

Bug#833383: ros-std-msgs: split headers and message definitions

[ddomenichelli]

‎Hello Jochen,

> Interesting point, what would be the use case?

These messages definition could be used to generate bindings for other 
programming languages and/or frameworks.
In my specific case, in YARP (another middleware for robotics similar to ROS) 
we have a way to publish/subscribe to ROS publisher and subscribers, and we 
have a tool to generate bindings for ROS messages that do not use ROS libraries 
using the message definition.
We have a very small number of dependencies, and we cannot use the -dev package 
because it depends on many other packages, therefore at the moment we are 
forced to include in each module a copy of the definition of the messages used, 
but that's obviously redundant, and it would be a lot better if they were 
installed somewhere on the system.

> Should we put it into an extra package or in the library?

I'd like to have it in a separate package, with a very small number of 
dependencies.
In an ideal situation I'd like to call from CMake something like this:

 find_package(std_msgs REQUIRED)
 generate_bindings("$std_msgs_MSG_DIR}/std_msgs/String.msg")


Cheers,
 Daniele

Bug#409271: Status?

[Timothy Pearson]

What is the status of this bug report?  NFSv3 is becoming obsolete, and
this bug report is over *9 years* old now!

Bug#833472: aghermann: please make BUILT_BY reproducible (username, hostname)

[Chris Lamb]

andrei zavada wrote:

> I think I'd better rip these defines outright

Perfect :)


Regards,

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

Bug#832798: src:libgit2: Please support https:// protocol by linking to OpenSSL

[Peter Colberg]

Hi Josh,

Julia 0.5.0-rc1 has been released, and not much has happened towards
integrating mbedTLS into libgit2 as an alternative TLS backend [1].

What do you say if the Debian Julia team maintains a libgit2-openssl
variant until alternative TLS backends are available and have matured?
I would like to begin testing julia 0.5 in experimental so that the
package is ready in time for stretch.

Regards,
Peter

[1] https://github.com/libgit2/libgit2/pull/3462

Bug#833472: aghermann: please make BUILT_BY reproducible (username, hostname)

[andrei zavada]

I think I'd better rip these defines outright. Will push 1.1.1 in a few
days.

On 5 Aug 2016 00:27, "Chris Lamb"  wrote:

> Hey,
>
>   +-AC_SUBST(user, [`whoami`@`hostname`])
>   ++BUILT_BY="\"`dpkg-vendor --query vendor`\""
>   ++AC_SUBST(user, [$BUILT_BY])
>
> TIL about dpkg-vendor, thanks! But alas, this means it cannot go upstream
> as it assumes dpkg, etc. Did you consider something like:
>
>   --- a/debian/rules2016-08-04 20:04:58.393277517 +0100
>   --- b/debian/rules2016-08-04 22:14:14.065476092 +0100
>   @@ -2,6 +2,8 @@
># -*- makefile -*-
>
>DPKG_EXPORT_BUILDFLAGS = 1
>   +DEB_CXXFLAGS_MAINT_APPEND = -DBUILT_BY=\\\"aghermann@
> packages.debian.org\\\"
>   +
>include /usr/share/dpkg/buildflags.mk
>
>%:
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#833472: aghermann: please make BUILT_BY reproducible (username, hostname)

[Chris Lamb]

Hey,

  +-AC_SUBST(user, [`whoami`@`hostname`])
  ++BUILT_BY="\"`dpkg-vendor --query vendor`\""
  ++AC_SUBST(user, [$BUILT_BY])

TIL about dpkg-vendor, thanks! But alas, this means it cannot go upstream as it 
assumes dpkg, etc. Did you consider something like:

  --- a/debian/rules2016-08-04 20:04:58.393277517 +0100
  --- b/debian/rules2016-08-04 22:14:14.065476092 +0100
  @@ -2,6 +2,8 @@
   # -*- makefile -*-
 
   DPKG_EXPORT_BUILDFLAGS = 1
  +DEB_CXXFLAGS_MAINT_APPEND = -DBUILT_BY=\\\"agherm...@packages.debian.org\\\"
  +
   include /usr/share/dpkg/buildflags.mk
 
   %:


Regards,

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

Bug#833470: golang-go: No reasonable default for GOPATH?

[Michael Stapelberg]

Upstream doesn’t prescribe a GOPATH, so I don’t think Debian should either.
It’d be a shame if Go behaved differently depending on which Linux
distribution one uses.

If you’d like to see this changed, please lobby upstream :).

On Thu, Aug 4, 2016 at 10:19 PM, Dale Harris  wrote:

> Package: golang-go
> Version: 2:1.6.1+1
> Severity: minor
>
> This is more a question than a bug report. I'm wondering why there isn't
> some reasonable default environment, like for $GOPATH, set up in
> /etc/profile.d/ for Go? Just seems like that should be part of the
> package.
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages golang-go depends on:
> ii  golang-1.6-go  1.6.3-1
> ii  golang-src 2:1.6.1+1
>
> golang-go recommends no packages.
>
> golang-go suggests no packages.
>
> -- no debconf information
>
> --
> Dale Harris
> rod...@maybe.org
> rod...@gmail.com
> /.-)
>
>


-- 
Best regards,
Michael

Bug#771766: debian-goodies: behavior problem with debmany when using -z zenity option.

[Axel Beckert]

Control: notfound -1 0.63
Control: close -1

Hi Kevin,

Kevin C. wrote:
> When using "debmany -z somepackage"  such as: debmany -z debian-goodies .
> If double clicking a filename in the zenity dialog gives an error, but if
> you first just select the filename and click "ok" it works. This
> problem/annoyance seems to have started after an upgrade. I believe it used
> to work fine. When double clicking for example dblob, the Error is this: 
> /usr/bin/debmany: line 382: cd: 
> /usr/share/man/man1/dglob.1.gz|/usr/share/man: 
> No such file or directory
> 
> It seems zenity is returning a | delimited value, when double clicking the
> filename and only returning the file when hitting "ok".

This seems to have been a (now fixed) bug in zenity, not debmany:

* I can no more reproduce this issue.
* There is a zenity bug related to reporting items twice, pipe
  delimited: https://bugs.debian.org/717053
* The bug was found in 3.8.0-1 and fixed in 3.12.1-1. Your reported
  version is inbetween:

> ii  zenity  3.8.0-1ubuntu1

Hence, I'm now closing this bug report. Thanks for the bug report
nevertheless.

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

Bug#761982: Pending fixes for bugs in the fonts-ebgaramond package

[pkg-fonts-devel]

tag 761982 + pending
thanks

Some bugs in the fonts-ebgaramond package are closed in revision
b6c092573afec2e2a90189931e4436118e0f74c9 in branch 'master' by Scott
Howard

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-ebgaramond.git;a=commitdiff;h=b6c0925

Commit message:

* Dropped: drop_sc_fonts.patch, move all SC fonts to
  fonts-ebgaramond-extra (Closes: #761982)
* Build .woff webfonts
  - Build-depends on woff-tools
  - debian/patches/build_web_fonts.patch
* DSV 3.9.8 (no changes)
* Drop build_dir.patch (upstream fixed)

Bug#826814: gpac: OpenJPEG removal

[Emilio Pozuelo Monfort]

On 04/08/16 21:41, James Cowgill wrote:
> Hi,
> 
> On 04/08/16 18:02, Emilio Pozuelo Monfort wrote:
>> On Sat, 23 Jul 2016 13:30:19 +0200 Emilio Pozuelo Monfort  
>> wrote:
>>> On 23/07/16 12:40, James Cowgill wrote:
 Control: forwarded -1 https://github.com/gpac/gpac/issues/592

 On Thu, 2016-07-21 at 19:12 +0200, Emilio Pozuelo Monfort wrote:
> On Thu, 09 Jun 2016 10:30:01 +0200 "Mathieu Malaterre"  
> wrote:
>>
>> This is a continued operation since src:jasper removal for stretch
>> release.
>>
>> src:openjpeg will be removed from Debian for the stretch release
>> (and following that, the archive in general). For more information
>> see: http://bugs.debian.org/826805
>>
>> It has been superseeded by src:openjpeg2
>>
>> Your package uses src:openjpeg, so please either remove the
>> JPEG2000 functionality or move to the new API.
>
> Ping? It looks like your package already uses libjpeg-turbo. Can we
> just drop the openjpeg support? If not, can you forward this
> upstream? This is the last key package still depending on openjpeg,
> and it is going to block its removal from Stretch.

 I've forwarded the bug, but are there any objections to removing
 openjpeg support in the meantime? There doesn't seem to be any users of
 the openjpeg support in other Debian packages at least.
>>>
>>> That'd be good in order to finish the transition. But I don't use gpac.
>>
>> Can that be done?
> 
> Thanks for reminding me, I totally forgot about this. I'll do it in a
> few minutes.

Thanks!

Emilio

Bug#820159: llvm: libfuzzer

[Chris Lamb]

Sylvestre Ledru wrote:

> Uploaded! 

ACCEPTED.


Regards,

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

Bug#833473: ITP: maskprocessor -- high-performance word generator with a per-position configurable charset

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: maskprocessor
  Version : 0.73
  Upstream Author : Jens Steube 
* URL : https://github.com/hashcat/maskprocessor
* License : MIT
  Programming Lang: C
  Description : high-performance word generator with a per-position 
configurable charset

Maskprocessor is a fast word list generator. It enumerates all combinations
from a given user-defined keyspace and outputs the results. Since it supports
different alphabets (which also can be combined) at different positions in the
generation template ('mask'), this approach allows a more fine-tunable
generation of candidates than using 'naive' brute force enumeration of words.
Masks are defined using the description also used in the Hashcat password
recovery utility.

Bug#833472: aghermann: please make BUILT_BY reproducible (username, hostname)

[Daniel Shahaf]

Source: aghermann
Version: 1.1.0-1
Severity: wishlist
Tags: upstream patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username hostname

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that aghermann could not be built reproducibly:


https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/aghermann.html
│   │   │   │   │0x004c5e00 41676865 726d616e 6e20312e 312e3020 
Aghermann 1.1.0 
│   │   │   │   │0x004c5e10 6275696c 74204a75 6e203236 20323031 built 
Jun 26 201
│   │   │   │   │0x004c5e20 36203232 3a31323a 30302062 79207062 6 
22:12:00 by pb
│   │   │   │   │ -  0x004c5e30 75696c64 65723140 70726f66 69746272 
uilder1@profitbr
│   │   │   │   │ -  0x004c5e40 69636b73 2d627569 6c64312d 616d6436 
icks-build1-amd6
│   │   │   │   │ -  0x004c5e50 340a00  4..
│   │   │   │   │ +  0x004c5e30 75696c64 65723240 692d6361 70747572 
uilder2@i-captur
│   │   │   │   │ +  0x004c5e40 652d7468 652d686f 73746e61 6d650a00 
e-the-hostname..

Following up on #828008, a second patch is attached to make BUILT_BY
deterministic.  It's written to accomodate vendor names having embedded
spaces, since deb-origin(5) implies such names are valid.

Cheers,

Daniel


diff --git a/debian/patches/reproducible.patch 
b/debian/patches/reproducible.patch
new file mode 100644
index 000..09f93e6
--- /dev/null
+++ b/debian/patches/reproducible.patch
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+  Eliminate needless, variable information.
+Author: Daniel Shahaf 
+Bug-Debian: https://bugs.debian.org/-1
+Last-Update: 2016-08-04
+Forwarded: not-needed
+
+--- a/configure.ac
 b/configure.ac
+@@ -190,7 +190,8 @@
+ fi
+ 
+ dnl Any private defines
+-AC_SUBST(user, [`whoami`@`hostname`])
++BUILT_BY="\"`dpkg-vendor --query vendor`\""
++AC_SUBST(user, [$BUILT_BY])
+ AC_SUBST(build_date, [`date --utc --date=@${SOURCE_DATE_EPOCH:-$(date +%s)} 
+"%F"`])
+ AC_SUBST(build_datetime, [`date --utc --date=@${SOURCE_DATE_EPOCH:-$(date 
+%s)}`])
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..038ee28
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible.patch

Bug#831672: screen: segfault on digraph

[Axel Beckert]

Hi Jan,

Jan Nordholz wrote:
> Adding a patch suggestion for completeness...

Thanks a lot for the patch. Will prepare an updated package soon.

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

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi gregor,

On 14/07/2016 04:12, gregor herrmann wrote:
> On Mon, 11 Jul 2016 12:39:33 +0200, Margarita Manterola wrote:
> 
> (cc'ing leader@, withstanding the temptation to cc -project in order not to
> hijack the TC specific bug)
> 

FWIW, I am subscribed to -ctte mailing list.

>> Additionally, I suggested that a team (be it the TC or some other team)
>> could gather the list of goals and once a year let the project vote on it
>> through a GR, so that all goals that beat NOTA get approved. This proposal
>> was rejected as being too heavy handed.
> 
> I think this proposal has quite some merits.
> 
> IMO it boils down to what this roadmap and the goals are supposed to be, and
> I have the impression that this is not very clear and/or that there's no real
> consensus about this question.
> 
> My idea is that a roadmap is a document laying out the global direction of
> the project, and act as somewhat binding guidelines for all Debian
> contributors ("something we want to achieve together"); and not just a
> collection of random detailed technical changes.
> 
>> My reason for proposing this was that I feel developers will be more
>> engaged with the goals if they have voted for them than if they come from
>> an external team.
> 
> I agree on this reasoning. If the roadmap should be more than a list of
> "private" projects that can just be ignored, than it needs "buy 
> in"/legitimacy by the project members; and even if GRs are quite heavy-handed
> they're the only tool we have to take decisions as a project and to produce
> this legitimacy.
> 

I believe I replied to this point in my reply to marga in this bug (and also
partly later in this mail). Please let me know if there are other points I
didn't clarify.

>> During the BOF, a bunch of people volunteered to be part of the Roadmap
>> team, even though it was unclear what the Roadmap team should do and how it
>> should do that.
> 
> That was my impression too :)
> 
>> Initally, Mehdi wanted the TC to be the Roadmap team, but given the intent
>> of forming this other Roadmap team during the BOF, I don't know what is
>> currently expected of the TC.
> 
> IMO the TC is the wrong body for a roadmap, as I see it as an arbiter in
> cases of technical disputes, and the goals covered by the roadmap neither
> need to be technical nor controversial per se.
> 

Historically, we mainly used the TC that way indeed. I believe this was due
to a lack of a vision in our project, and the TC could engage in such higher
value tasks and set a direction to the project.

Working (openly) on a list of project goals has also the merits of describing
a context and a direction which helps to avoid some conflicts. So, it is a
pro-active way of solving potential problems.

> In the end, I think that a roadmap for the project lies in the responsibility
> of the DPL, i.e. that it's a genuine leadership task (and indeed it was
> proposed by our DPL already in his platform); of course it seems reasonable
> for Mehdi to seek support in the actual implementation of the process, e.g.
> from a group of people called "Roadmap Team".
> 

Yes, I agree. My reasoning led me to think that the TC is the best body to
handle this in Debian. We obviously disagree on this specific point, but I
am only explaining my reasoning. So I asked the current TC Chair to engage
a discussion with TC members and see if they share this thought. If not, it
will be done elsewhere, a "Roadmap Team". Since we are discussing setting a
direction for the project, I agree that the DPL should be actively working
on it. But there is some administrative and communication work to not
underestimate and I believe a delegated team or a roadmap helpers team would
be of a great help to drive this forward. This is not required if the TC
handles the roadmap though as they already have the constitutional powers to
decide on technical matters.

It is also quite common (elsewhere) to see a Technical Committee deciding on
a program or a roadmap. For conferences, the Technical Committee usually
reviews proposed papers, selects accepts papers, set the conference program,
etc... In companies, a Technical Committee also usually decides on the general
direction that should be implemented.

In my understanding, having the powers the overrule individuals in a project
or decide on technical matters where jurisdictions overlap are only tools to
be able to set a direction, and not the other way around.

It is true that we focused our attention on disputes and how to solve them,
which is a very valuable goal, but IMHO we lost sight on the bigger picture:
what we want to achieve in our project. We are not looking for expertise in
mediation and social problem solving. We want the project to stay relevant,
innovate and spread free software. (Yes, we have many implicit goals and
this is not an exhaustive list of course). Pursuing that goal, we should not
rely on individual project members to shine and share their vision on what
Debian should look 

Bug#833471: network-manager-gnome: Wired interface ( eth0 ) missing in Network Preferences

[vrishab]

Package: network-manager-gnome
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Opened "Software" and tried to install a package.

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

Opened "Software" and tried to install a package.

   * What was the outcome of this action?

"Software" displayed "Go online to check for updates". The system was online
and connected to the internet.

   * What outcome did you expect instead?

"Software" should install the package.



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gnome-shell [polkit-1-auth-agent]3.20.3-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-2
ii  libgtk-3-0   3.20.6-2
ii  libmm-glib0  1.6.0-1
ii  libnm0   1.2.2-2
ii  libnma0  1.2.4-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsecret-1-00.18.5-1
ii  network-manager  1.2.2-2
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-3

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring  3.20.0-2
ii  gnome-shell [notification-daemon]  3.20.3-1
ii  iso-codes  3.69-1
ii  mobile-broadband-provider-info 20151214-0.1
ii  notification-daemon3.20.0-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB

[Gunnar Wolf]

Alessandro Ghedini dijo [Thu, Aug 04, 2016 at 08:19:14PM +0100]:
> On Tue, Aug 02, 2016 at 06:52:39PM +0100, Alessandro Ghedini wrote:
> > and when building the keyrings from the git repository it appears four 
> > times:
> 
> Actually, the two additional keys are there due to the fact that I had the
> system debian-keyring.gpg enabled in gpg.conf. This is the correct output:
> (...)

OK, that solves a *little* bit of the mystery. However, I still have
no clue as to why it appears twice. And FWIW, this happens even
specifying the --no-default-keyring with my own key: It appears only
once in the 2016.07.02 version (from the installed package), but
twice in our working tree:

$ gpg2 --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg 
--list-keys gw...@debian.org
pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2017-07-18]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

0 gwolf@mosca『11』~$ gpg2 --no-default-keyring --keyring 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg --list-keys 
gw...@debian.org
pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2017-07-18]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2016-08-25]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

And I get the same behaviour with GPG 1. Now, trying to understand
some bits... I am surprised at the size difference:

$ ls -lh /usr/share/keyrings/debian-keyring.gpg 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg
-rw-r--r-- 1 gwolf gwolf 36M Jul  8 07:38 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg
-rw-r--r-- 1 root  root  27M Jul  3 03:52 /usr/share/keyrings/debian-keyring.gpg

They should be roughly the same size! Maybe I didn't do some cleanup
when preparing the 2016.07.08 update (for which we did a tree push but
not a package upload)?


signature.asc
Description: Digital signature

Bug#833394: wmweather: URL of data source has changed

[Cristian Ionescu-Idbohrn]

On Wed, 3 Aug 2016, Matthieu Weber wrote:
>
> The URL of the source of the data used by wmweather has changed,
> causing the software to exit immediately upon start.
>
> The fix is trivial, and a patch is included.

Yeah, I thought of that too.  And tested (from strace):

GET /pub/data/observations/metar/decoded/YBRM.TXT HTTP/1.1\r\nHost:
tgftp.nws.noaa.gov\r\nUser-Agent: wmweather 2.4.5\r\nAccept:
*/*\r\n\r\n

HTTP/1.1 404 Not Found\r\nDate: Thu, 04 Aug 2016 19:46:03
GMT\r\nServer: Apache\r\nX-Frame-Options:
SAMEORIGIN\r\nX-Content-Type-Options: nosniff\r\nX-XSS-Protection: 1;
mode=block\r\nVary: Accept-Encoding\r\nContent-Length:
242\r\nContent-Type: text/html; charset=iso-8859-1\r\nSet-Cookie:
NSC_ESNS=10f244c1-39a9-17a3-9678-00e0ed227be8_4120082755_1338136870_043233782597;
Path=/; Expires=Thu, 04-Aug-2016 19:46:18 GMT\r\n\r\n\n\n404 Not
Found\n\nNot Found\nThe requested URL
/pub/data/observations/metar/decoded/YBRM.TXT was not found on this
server.\n\n

`wget' behaves likewise:

wget http://tgftp.nws.noaa.gov/pub/data/observations/metar/decoded/YBRM.TXT
--2016-08-04 21:39:59--
http://tgftp.nws.noaa.gov/pub/data/observations/metar/decoded/YBRM.TXT
Resolving tgftp.nws.noaa.gov (tgftp.nws.noaa.gov)... 140.90.101.79
Connecting to tgftp.nws.noaa.gov
(tgftp.nws.noaa.gov)|140.90.101.79|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2016-08-04 21:40:01 ERROR 404: Not Found.

but managed to get sooomething with `curl' a few minutes ago; not any
more:

curl -qvs
http://tgftp.nws.noaa.gov/pub/data/observations/metar/decoded/YBRM.TXT
*   Trying 140.90.101.79...
* Connected to tgftp.nws.noaa.gov (140.90.101.79) port 80 (#0)
> GET /pub/data/observations/metar/decoded/YBRM.TXT HTTP/1.1
> Host: tgftp.nws.noaa.gov
> User-Agent: curl/7.50.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Thu, 04 Aug 2016 19:52:13 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Vary: Accept-Encoding
< Content-Length: 242
< Content-Type: text/html; charset=iso-8859-1
< Set-Cookie:
NSC_ESNS=1104eaf0-3b1b-17a3-9678-00e0ed227be8_2753958198_0511137557_013169675417;
Path=/; Expires=Thu, 04-Aug-2016 19:52:28 GMT
<


404 Not Found

Not Found
The requested URL /pub/data/observations/metar/decoded/YBRM.TXT was
not found on this server.

* Connection #0 to host tgftp.nws.noaa.gov left intact

`wmfrog' manages to get somthing out, using some other url:

http://weather.noaa.gov/mgetmetar.php?=YBRM

It seems `wmweather' can't handle redirections and there's some fsck
at noaa.gov :(


Cheers,

-- 
Cristian

Bug#833470: golang-go: No reasonable default for GOPATH?

[Dale Harris]

Package: golang-go
Version: 2:1.6.1+1
Severity: minor

This is more a question than a bug report. I'm wondering why there isn't
some reasonable default environment, like for $GOPATH, set up in
/etc/profile.d/ for Go? Just seems like that should be part of the
package. 



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

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

Versions of packages golang-go depends on:
ii  golang-1.6-go  1.6.3-1
ii  golang-src 2:1.6.1+1

golang-go recommends no packages.

golang-go suggests no packages.

-- no debconf information

-- 
Dale Harris   
rod...@maybe.org
rod...@gmail.com
/.-)

Bug#832336: jessie-pu: package systemd/215-17+deb8u5

[Michael Biebl]

Am 03.08.2016 um 22:41 schrieb Julien Cristau:
> On Wed, Aug  3, 2016 at 22:32:16 +0200, Michael Biebl wrote:
> 
>> Am 29.07.2016 um 23:00 schrieb Michael Biebl:
>>> Am 29.07.2016 um 14:00 schrieb Julien Cristau:
 This looks fine in general, I'm just wondering if the effect of bumping
 the util-linux dependency on upgrades from wheezy was considered/tested?
>>>
>>> It was not specifically tested since I didn't expect any breakage
>>> because of it. But I did it now for a basic wheezy system the upgrade to
>>> jessie (with the updated systemd packages) worked fine. The tightened
>>> dep on u-l seems to not cause any issues.
>>>
>>> I've attached the typescript from the wheezy → jessie dist-upgrade.
>>
>> Is that sufficient or do you still have concerns?
>>
> I'm definitely concerned about changing dependencies in the base system
> in stable, yes.  Is the parallel fsck bug that bad?

I would really like to include that fsck fix. Parallel fsck on rotating
disks is bad. It degrades the performance and we had reports from
concerned users, that their disks made very strange noises when the
heads where constantly repositioned.
This doesn't affect SSDs, but I guess HDD are still very common on a
typical server.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#811825: FaCT++ Debian package removal

[Dmitry Tsarkov]

Hi all,

I'm the implementer of the original FaCT++ system. After checking the
project's makefiles I found out that the dependency from the ppl package is
optional. The user might use additional commands to turn on options that
require this package, but by default it is not needed. Could the
dependencies for the Debian package be adjusted to reflect that fact?
Alternatively I can make an intermediate release to completely remove the
offending options.

Thanks for supporting FaCT++ in Debian!

Best regards,
Dmitry.

Bug#804087: #804087 ITP: ruby-svn2git -- Ruby tool for importing existing svn projects into git.

[Sascha Girrulat]

Hi Dmitry,

Am 19.07.2016 um 03:21 schrieb Dmitry Smirnov:
> On Monday, 18 July 2016 1:04:28 PM AEST Sascha Girrulat wrote:
>> Would be ok for me but i am not a member of the pkg-ruby team.
> 
> Have you applied for membership? ;)
i just send a request. The package should be finished now.

> We could publish repository to collab-maint but I think you are not a member 
> of this group either... At the moment nobody except you can commit to package 
> repository and that's not good...
Yes you are right but the package is not that important. I will move the
package after got the membership. Would you like to review the package?

Regards
Sascha




signature.asc
Description: OpenPGP digital signature

Bug#831672: screen: segfault on digraph

[Jan Nordholz]

tags 831672 +patch
thankyou

Adding a patch suggestion for completeness...


Jan
Description: Fixes broken handling of "bind u digraph U+", resulting in a
 SIGSEGV instead of prompting for the remainder. Also fixes an allocation
 inaccuracy I found while debugging this, even though that one looks innocuous.
 See BTS #831672.
Author: Jan C. Nordholz 

--- a/process.c	2016-08-04 21:41:27.0 +0200
+++ b/process.c	2016-08-04 21:42:37.916299040 +0200
@@ -3855,7 +3855,7 @@
   break;
 
 case RC_DIGRAPH:
-  if (argl && argl[0] > 0 && argl[1] > 0)
+  if (argl && argl[0] > 0 && args[1] && argl[1] > 0)
 	{
 	  if (argl[0] != 2)
 	{
@@ -4691,9 +4691,9 @@
   act->argl = 0;
   return;
 }
-  if ((pp = (char **)malloc((unsigned)(argc + 1) * sizeof(char **))) == 0)
+  if ((pp = (char **)malloc((unsigned)(argc + 1) * sizeof(char *))) == 0)
 Panic(0, "%s", strnomem);
-  if ((lp = (int *)malloc((unsigned)(argc) * sizeof(int *))) == 0)
+  if ((lp = (int *)malloc((unsigned)(argc) * sizeof(int))) == 0)
 Panic(0, "%s", strnomem);
   act->nr = nr;
   act->args = pp;

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi marga,

On 11/07/2016 12:39, Margarita Manterola wrote:
> For documentation purposes, I list below my summary of the points that were
> raised during the Roadmap BOF. These items are separate and may not 
> necessarily
> all (or even any) need to be true in the implementation adopted. During the 
> BOF
> there were disagreements on almost all of them.
> 
> a. Proposals could be made using the DEP process
>(http://dep.debian.net/deps/dep0/)
> 
> b. Goals should have owners.
> 

I don't remember any disagreement over a. and b. The main remark about DEPs was
that it could be the tool to implement the roadmap, but it lacks a few things:
1. it is not obvious to measure progress of each DEP
2. the whole process looks abandoned, and nobody is taking care of it. It really
   needs to be managed. Some DEP drivers feel a bit lost because they don't know
   when a DEP should become "ACCEPTED".
3. a roadmap should show a list of subjects people are actively working on. It
  is not clear how to do that with dep.d.n
4. communication about new DEPs (and evolution of the list of DEPs in general)

If 1. and 3. are fixed, DEP could be a perfect _tool_ to implement a roadmap.
Still, we need people to look over ongoing DEPs/goals and fix 2. and 4.

> c. Goals should not be announced unless there's already work going on.
> 
> d. There could be a list of goals (with owners and work under way) and a
>wishlist (things that we consider a good idea, but haven't been started).
> 

IMHO, c. and d. are the same points. The consensus during the BoF was that
there could be very relevant and important ideas, but if there no drivers for
it then it should appear on a different list, which could be something else
than the roadmap.

> e. There should be clear tracking of what's going on with each goal.
> 

My feeling is that there was no disagreement over this specific point. At least,
I don't recall any. Can you refresh my memory? (I may have missed it).

The proposal was to work on S.M.A.R.T goals [1], like we did for Release Goals
in the past.

[1] https://en.wikipedia.org/wiki/SMART_criteria

> Additionally, I suggested that a team (be it the TC or some other team) could
> gather the list of goals and once a year let the project vote on it through a
> GR, so that all goals that beat NOTA get approved. This proposal was rejected 
> as
> being too heavy handed.
> 
> My reason for proposing this was that I feel developers will be more engaged
> with the goals if they have voted for them than if they come from an external
> team. However, as long as we are not forcing people to work on specific things
> (i.e. if the bugs related to the goal are not RC), I'm fine with the goals
> coming from whoever the roadmap team is.
> 

We share the same goal: We want developers to feel more engaged with the goals
and encourage others to work on them. The disagreement was only about the way
to reach it. As you say, the goal of a roadmap is *not* to turn down individual
initiatives. I fear that a vote will be counter-productive if some goals are
voted against.

Additionally, I am not sure how to interpret the results of a vote. What should
happen if the project votes aginst a roadmap with a dozen of goals? Should we
play this game over and over until some list gets through? Similarly, the
outcome will not be very clear if we vote for individual roadmap items (and
when some of them do not receive enough votes). We are not looking for ways to
block initiatives, but to foster innovation and collaborative work.

I guess the idea behind the vote is to give goals some momentum, increase
engagement, gather more supporters, etc And I agree that those points
are very important if we want to publish a project roadmap. I think that votes
are a poor way to achieve that. People will not be convinced about an idea just
because another set of people voted for it. Additionally, votes are not a way
to reach consensus, and that's really what we need for roadmap items (IMHO).

Votes tend to force a win/lose dichotomy and ignores the possibility of building
a compromise. I expect project members to discuss proposed goals and reach
consensus, and not simply block it with a vote because of a disagreement. A vote
may also isolate a minority, which is really not what we are trying to achieve
with the roadmap.

About RC-ness of bugs, it is the Release Team territory. I don't see a reason
to change that... especially, since roadmap goals are not necessarily bound to
a release. The RT is free to block a release waiting for some goal, but it is
their decision.

Saying all that and we forget an important historical data point : Release
Goals were proposed by project members and decided by a team. None of them
required a vote. It was required that a Release Goal should be generally
consensual, and it will be required for Project Goals (as noted in the gobby
"roadmap" document that was drafted during the BoF). Otherwise, it would be
difficult to call them "Project Goals" 

Bug#832323: Not sure who's bug this is

[Neil Muller]

The problem is caused because irker ships a unit with an alias. The
actual unit name is irkerd, and the irker name is managed via a
symlink


This is because when systemd support was added, it was with the
upstream unit name (irkerd), but the system V file was irker, and that
caused it's own set of issues, so the alias was added to solve those.

systemctl enable and disable however, work by managing symlinks, so
they don't handle being called with the alias elegantly. As far as I
can tell, this seems to be the desired behaviour from systemd
upstream.

I suspect the only way to address this is to document the correct unit
name more clearly, although I'm not sure where. I'm open for
suggestions and patches.

Bug#833121: darkradiant: segfaults at start (keep out of stretch)

[Tobias Frost]

Package: darkradiant
Followup-For: Bug #833121
Control: retitle -1 darkradiant: seffaults when python scripting enabled

Filed upstream as http://bugs.thedarkmod.com/view.php?id=4360

-- 
tobi

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

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

Versions of packages darkradiant depends on:
ii  fonts-freefont-ttf 20120503-4
ii  libalut0   1.1.0-5
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-regex1.58.0   1.58.0+dfsg-5.1
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.23-4
ii  libftgl2   2.1.3~rc5-4+nmu1+b1
ii  libgcc11:6.1.1-10
ii  libgl1-mesa-glx [libgl1]   11.2.2-1
ii  libglew1.131.13.0-2
ii  libglu1-mesa [libglu1] 9.0.0-2.1
ii  libjpeg62-turbo1:1.5.0-1
ii  libopenal1 1:1.17.2-1
ii  libpng16-161.6.23-1
ii  libsigc++-2.0-0v5  2.8.0-1
ii  libstdc++6 6.1.1-10
ii  libvorbisfile3 1.3.5-3
ii  libwxbase3.0-0v5   3.0.2+dfsg-2
ii  libwxgtk3.0-0v53.0.2+dfsg-2
ii  libxml22.9.4+dfsg1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages darkradiant recommends:
ii  darkradiant-plugins-darkmod  2.0.4-1

darkradiant suggests no packages.

-- no debconf information

Bug#826814: gpac: OpenJPEG removal

[James Cowgill]

Hi,

On 04/08/16 18:02, Emilio Pozuelo Monfort wrote:
> On Sat, 23 Jul 2016 13:30:19 +0200 Emilio Pozuelo Monfort  
> wrote:
>> On 23/07/16 12:40, James Cowgill wrote:
>>> Control: forwarded -1 https://github.com/gpac/gpac/issues/592
>>>
>>> On Thu, 2016-07-21 at 19:12 +0200, Emilio Pozuelo Monfort wrote:
 On Thu, 09 Jun 2016 10:30:01 +0200 "Mathieu Malaterre"  
 wrote:
>
> This is a continued operation since src:jasper removal for stretch
> release.
>
> src:openjpeg will be removed from Debian for the stretch release
> (and following that, the archive in general). For more information
> see: http://bugs.debian.org/826805
>
> It has been superseeded by src:openjpeg2
>
> Your package uses src:openjpeg, so please either remove the
> JPEG2000 functionality or move to the new API.

 Ping? It looks like your package already uses libjpeg-turbo. Can we
 just drop the openjpeg support? If not, can you forward this
 upstream? This is the last key package still depending on openjpeg,
 and it is going to block its removal from Stretch.
>>>
>>> I've forwarded the bug, but are there any objections to removing
>>> openjpeg support in the meantime? There doesn't seem to be any users of
>>> the openjpeg support in other Debian packages at least.
>>
>> That'd be good in order to finish the transition. But I don't use gpac.
> 
> Can that be done?

Thanks for reminding me, I totally forgot about this. I'll do it in a
few minutes.

James



signature.asc
Description: OpenPGP digital signature

Bug#833405: nvidia-vulkan-icd: Missing conflict: /usr/share/vulkan/icd.d/nvidia_icd.json provided by 2 packages

[Andreas Beckmann]

On 2016-08-04 21:29, Diederik de Haas wrote:
>> I think a simple "Replaces: nvidia-vulkan-icd" on nvidia-vulkan-common
>> should do the trick.
> 
> If it improves the package, then it sounds like a good addition even though 
> this was a user error.

It should have been a Breaks+Replaces: nvidia-vulkan-icd (<= 364.19-1)
Hm, well that's the current version ... so it doen't work properly ;-(
I plan to prepare future SVN branches with versions like -0~svn, to
ensure locally built packages don't use the same version number as the
official uploads later on.


Andreas

Bug#820159: llvm: libfuzzer

[Sylvestre Ledru]

Uploaded! 

Le 4 août 2016 18:08:23 GMT+02:00, Chris Lamb  a écrit :
>> > I wonder if a separate package would be a good idea, simply from
>the
>> > angles of:
>[..]
>> why not :)
>> The lib is 250k
>
>Also, it would keep any bug reports separate. Let me know when you
>upload
>it so I can get it through NEW asap..
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-

Bug#583994: advi: Security bugs in ghostscript

[Ralf Treinen]

Control: reopen -1

Hi,

On Sun, Jul 24, 2016 at 12:00:45AM -0400, Nicolas Braud-Santoni wrote:
> Control: close -1

I do not agree:

> Given that advi is meant purely for previewing and presenting DVIs,
> it is likely called on trusted inputs.

I had a discussion with upstream about this a long time ago. They seem to
think that the fact that advi has "active" in its name makes it absolutely
clear to anybody that advi has the ability to execute any code. I don't
agree with that, it would be easy to add a line in mailcap to use advi
as a viewer for any *.dvi files. We even have a wishlist bug requesting
this for the advi package. There is no reason to believe that any user
will use advi only on trusted dvi files.

> In any case, I do not think it makes sense to keep around a 6 years old
> security bug.

That is not a reason to close a bug.

The default behaviour of gs has been fixed in debian to use -P, however
this bug against advi should be closed only when one has verified the
options used by advi when it calls gs.

-Ralf.

Bug#801959: progress update

[Dieter Adriaenssens]

All debtags for mariadb-related packages have been reviewed.
Once tag suite::mysql is added to debtags (bug #830626) it can be added to
the mariadb and mysql packages.

-- 
Kind regards,

Dieter Adriaenssens

Bug#831069: Closing the bug

[Anton Gladky]

notfound 831069 0.9.8.9-14
tag 831069 +unreproducible
thanks

Hi Lucas,

I am not able to reproduce the bug in current sid
environment, where GCC is 6 by default already.
Thus I am closing the bug.

Best regards

Anton

Bug#833405: nvidia-vulkan-icd: Missing conflict: /usr/share/vulkan/icd.d/nvidia_icd.json provided by 2 packages

[Diederik de Haas]

Hi Luca,

On donderdag 4 augustus 2016 13:35:55 CEST Luca Boccassi wrote:
> Control: severity -1 important
> 
> On Thu, 2016-08-04 at 02:03 +0200, Diederik de Haas wrote:
> > On donderdag 4 augustus 2016 01:52:28 CEST Andreas Beckmann wrote:
> > > are you upgrading from locally built packages that were built from SVN
> > > some time ago?
> > 
> > I am indeed.

It was the build I reported on pkg-nvidia-de...@lists.alioth.debian.org with 
title 'Building newer releases from SVN':
http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2016-July/
013221.html

> To fix your immediate problem running "apt-get install -f" and then
> upgrade again should be sufficient.

I just did an 'aptitude update' and 'aptitude safe-upgrade' and it installed/
configured the packages just fine even though there were no new nvidia/vulkan 
packages with the new updates. Thus I didn't even have to use '-f'

> Given the workaround, and the fact that the packages with that problem
> were never actually uploaded in the repos, I'll downgrade the severity.

I'm also fine with downgrading it more as I now consider this a user error.

> However, I'm happy to add a fix for the next upload to facilitate users
> of locally built packages.

It sounds like a good candidate to add to the wiki on the building from source 
section. Thus severity wishlist sounds fine too ;-)

> I think a simple "Replaces: nvidia-vulkan-icd" on nvidia-vulkan-common
> should do the trick.

If it improves the package, then it sounds like a good addition even though 
this was a user error.

> Kind regards,
> Luca Boccassi

Cheers,
  Diederik

Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB

[Alessandro Ghedini]

On Tue, Aug 02, 2016 at 06:52:39PM +0100, Alessandro Ghedini wrote:
> and when building the keyrings from the git repository it appears four times:
> 
>  % gpg2 --no-default-keyring --keyring output/keyrings/debian-keyring.gpg 
> --list-keys gh...@debian.org
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

Actually, the two additional keys are there due to the fact that I had the
system debian-keyring.gpg enabled in gpg.conf. This is the correct output:

 % gpg2 --no-default-keyring --keyring output/keyrings/debian-keyring.gpg 
--list-keys gh...@debian.org
pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

(the correct key being the first one)

Cheers


signature.asc
Description: PGP signature

Bug#833429: [git-buildpackage/master] import-orig: export version information to postimport hook

[Guido Günther]

tag 833429 pending
thanks

Date:   Thu Aug 4 20:14:03 2016 +0200
Author: Guido Günther 
Commit ID: 51620e95d11152d3a352b60c45abf86b13464010
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=51620e95d11152d3a352b60c45abf86b13464010
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=51620e95d11152d3a352b60c45abf86b13464010

import-orig: export version information to postimport hook

Closes: #833429

A snapshot build including this change will be available at
http://honk.sigxcpu.org:8001/job/git-buildpackage/
  

Bug#830509: #830509: python-gtkspellcheck is outdated -> Up for adoption?

[Ben Wiederhake]

Dear MIA-team,

tl;dr: old maintainer appears inactive, I'd like to initiate the 
MIA-process, take over, and update the package.


it appears to me that the maintainer of "python-gtkspellcheck", namely 
Carlos Miguel Jenkins Pérez  (who receives this 
mail due to the bug-CC), has gone missing in action.


So here's my summary according to the guide [1] for this situation:
- "they just need[ed] a reminder" -> False, as direct contact failed.
- "they just need[ed] a reminder" -> False, as direct contact by 
Maximilian Köhl (upstream author of python-gtkspellcheck) failed.
- "they just need[ed] a reminder" -> False, as opening yet another bug 
failed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830509
- "MIA Scripts" [2] -> I didn't intend to do any of these, although I 
have send the "initial" mails (because I think that's more polite) and 
created the bug (ditto).
- echelon ->  I assume that Carlos Pérez is not a registered DM. 
Neither am I, so 'm not sure.
- "number of packages this maintainer is responsible for" -> 1, only 
python-gtkspellcheck
- "any RC bugs that have been open for ages?" -> Not RC, but an 
"important" one since Feb 2016, and a "normal" one since Sep 2015.
- "whether the packages have been NMUed" -> Yes, once, in order to fix 
some serious issue.  The last NMUer made it clear that he is not 
interested in maintaining the package. [3]
- "Is there any activity of the maintainer outside of Debian?" -> A 
Google search for any activity after 2015 comes up clear [4].  There's 
some activity on GitHub and StackOverflow, though, so I assume/hope he's 
well, and just not interested in python-gtkspellcheck anymore.
- "you need to find and contact the Debian developer who has actually 
uploaded the package" -> not sure how to do that :(


Some context:
I'm primarily interested in seeing the package updated (as reportbug 
depends on it, and I think it's a nice thing).  So if Carlos Pérez can 
do another upload, I'd welcome him back :)
If that doesn't work out (and it looks like it won't), I'd like to take 
over the package (which involves getting Carlos Pérez marked as MIA), 
and upload a newer version of python-gtkspellcheck.


Cheers,
Ben Wiederhake

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa

[2] https://wiki.debian.org/qa.debian.org/MIATeam
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830509#15
[4] 
https://www.google.com/search?q=%2BCarlos+Miguel+Jenkins+%2BP%C3%A9rez+after%3A2015=utf-8=utf-8

Bug#833469: svn-buildpackage: Copy .asc file together with tar

[Kurt Roeckx]

Package: svn-buildpackage
Severity: withlist

Hi,

In my tarballs directory I have both a .tar.gz and .tar.gz.asc.
dpkg-buildpackage now has support for uploading those .asc file if
it's there but svn-buildpackage doesn't copy it to the build-area.


Kurt

Bug#833468: google-android-m2repository-installer: [INTL:pt] Updated Portuguese translation for debconf messages

[Miguel Figueiredo]

Package: google-android-m2repository-installer
Version: 35
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for 
google-android-m2repository-installer's debconf messages.

Translator: Miguel Figueiredo 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .


--
Best regards,


# Portuguese translation for google-android-m2repository-installer package
# Copyright (C) 2016 Miguel Figueiredo 
# This file is distributed under the same license as the google-android-m2repository-installer package.
# Miguel Figueiredo , 2016
#
msgid ""
msgstr ""
"Project-Id-Version: google-android-m2repository-installer\n"
"Report-Msgid-Bugs-To: google-android-m2repository-installer@packages.debian."
"org\n"
"POT-Creation-Date: 2016-07-18 13:32+\n"
"PO-Revision-Date: 2016-08-04 19:30+0100\n"
"Last-Translator: Miguel Figueiredo \\n"
"Language-Team: Portuguese \n"
"Language: Portuguese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Mirror to download packages ?"
msgstr "Mirror de onde descarregar os pacotes ?"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Please select your prefered mirror to download Google's Android packages "
"from."
msgstr ""
"Por favor escolha o seu mirror preferido de onde descarregar os pacotes "
"Android da Google."

Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
control: block -1 by 826715


some questions:


why do not build-depend on the dev package?
I'm talking about "lua-torch-torch7"

also, there is some sadness in the libreadline.so link, are you sure there is 
no better way to fix that?
what about a package split?

cheers,

G.

Bug#833459: RFS: primesieve/5.7.0+ds-1 -- fast prime number generator C/C++ library

[Gianfranco Costamagna]

Hi,

>The description specially ask NOT to attempt to "fix" this.



This is something that the maintainer should be aware of, even if
there is no fix.
The point is that the maintainer is expected to be able to read the tag
and know the possible issues by this warning
>I see that this tag draws too much attention, so the next version of 
>Lintian will not emit it (unless you figure out how to re-enable it).


I think this is an issue, and should be emitted by lintian.
There is no fix right now, and this is true, but it doesn't make it
"less important" to me

>But wait... Why -dev and -dev-common are separate packages in the first 
>place? They are both tiny.


probably the rationale was "multiarch" but now the package seems multiarch-ok,
so merging them seems a good thing to do, you are right :)


>>versioned dev libraries makes me sad, really sad.>
>SONAME bump was an excellent opportunity to fix this.
>
>Now that you sponsored the package, you can only blame yourself for the 
>sadness. :>


lol :-)

while it is true in general, there are specific use cases to have a versioned 
-dev package.
I don't see any rdep in Debian archive, so probably people are using them with 
self-compiled
packages, and in this case having different -dev packages coinstallable can be 
a good thing to do.



as a libpng maintainer, I got bored of fixing the libpng12-dev hardcoded 
dependencies, and I/we ended
up in removing it at the end (probably making the next transition painful).
But when no rdeps are in Debian, I really don't care too much about it.

thanks for the valuable input as usual!
I leave the maintainer to answer to the questions,

Gianfranco

Bug#832975: Pending fixes for bugs in the syncthing package

[Paolo Inaudi]

Good, thanks!

Il 04/ago/2016 17:21,  ha
scritto:

> tag 832975 + pending
> thanks
>
> Some bugs in the syncthing package are closed in revision
> a9ea93d8f5d80efa046ff60e487de13fd5993fc8 in branch 'master' by aviau
>
> The full diff can be seen at
> https://anonscm.debian.org/cgit/pkg-go/packages/syncthing.git/commit/?id=
> a9ea93d
>
> Commit message:
>
> Install systemd user file in proper directory. (Closes: #832975)
>

Bug#833459: RFS: primesieve/5.7.0+ds-1 -- fast prime number generator C/C++ library

[Jakub Wilk]

* Gianfranco Costamagna , 2016-08-04, 16:36:

1) X: primesieve source: maybe-not-arch-all-binnmuable libprimesieve7-dev -> 
libprimesieve7-dev-common

probably not fixable, but I wanted to make you aware


The description specially ask NOT to attempt to "fix" this.

I see that this tag draws too much attention, so the next version of 
Lintian will not emit it (unless you figure out how to re-enable it).


But wait... Why -dev and -dev-common are separate packages in the first 
place? They are both tiny.



2) libprimesieve7-dev

versioned dev libraries makes me sad, really sad.


SONAME bump was an excellent opportunity to fix this.

Now that you sponsored the package, you can only blame yourself for the 
sadness. :>


--
Jakub Wilk

Bug#827582: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
control: block -1 by 826715



please ping back when rundime-deps are in the archive


also you have some lintian issues
X: lua-torch-xlua: package-contains-no-arch-dependent-filesI: lua-torch-xlua: 
extended-description-is-probably-too-short

G.

Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
control: block -1 by 826715


please ping back when dependencies are in the archive

G.

Bug#833467: python-hpack: CVE-2016-6581

[Salvatore Bonaccorso]

Source: python-hpack
Version: 2.2.0-1
Severity: important
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for python-hpack.

CVE-2016-6581[0]:
HPACK Bomb

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6581
[1] https://github.com/python-hyper/hpack/pull/56

Regards,
Salvatore

Bug#775085: xfburn and profile 0x08 (was: no subject)

[Thomas Schmitt]

Hi,

> ** (xfburn:3769): WARNING **: Read-only profile 0x8!

The drive classified the inserted medium as CD-ROM.
Either because it is really a CD-ROM or a closed CD-R or the drive
is mistaken.

> ** (xfburn:3769): WARNING **: [FATAL] 131357: SCSI error on write(32,16): [5 
> 24 00] Illegal request. Invalid field in cdb. (0)

The error message stems from libburn which forwards an error code that
was received from the drive. It happens early on write and is plausible,
given the fact that the drive announces to have a CD-ROM loaded.


Have a nice day :)

Thomas

Bug#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: block -1 826704
control: block -1 826705

control: tags -1 moreinfo
>  This package is the very core part of "Torch", a

>  state-of-the-art machine learning framework.
>  Note, this package requires luajit from experimental,
>  and the basic functionality seems to be working, 
>  but there are still some problems.
>
>  * the test_sharedmem.lua fails and it seems to be an upstream bug
>  * the package complexity far surpassed the assumption of dh-lua,
>so the rules file of this package is somewhat convolved,
>mixing cmake build and the dh-lua build together, but it should
>not be hard to understand. :-)


so please enforce the version and go for experimental, how do you expect to
be able to build it in unstable with experimental toolchain?

also, not needed to specify this
Depends: ${misc:Depends}, ${shlibs:Depends}, luajit | lua5.1,



for the -dev package, because already specified in the library itself.

+SET_TARGET_PROPERTIES(luaT PROPERTIES
+  VERSION   0
+  SOVERSION 0)


do you really want to maintain that downstream? please forward it.

why luaT and TH are not packaged separately? at a first look (not careful at 
all)
they look external dependencies

also, from check-all-the-things:
$ codespell --quiet-level=3


it's all for now
(I'll continue when I get a building package)


G.

Bug#833451: ncbi-blast+: FTBFS with Boost 1.61

[Aaron M. Ucko]

I wrote:

> The Boost.Test wrapper that many of ncbi-blast+'s unit tests use turns
> out to be incompatible with Boost 1.61, which was just uploaded and
> designated the new default.  (The wrapper relies on Boost.Test
> implementation details, which have generally been under flux lately.)

A closer look indicates that it should be possible to address the
immediate problem by simply pulling in an existing upstream fix that
missed the 2.4.0 release branch because it accidentally didn't go in
with the other Boost 1.59+ compatibility fixes:

https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=72392

It will probably also be necessary to take the formal cleanups in

https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=72379

for the patch to be able to apply cleanly.  I'll double check that there
aren't further complications, since I'd previously only tested with
versions up through 1.60.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#832965: shotwell: crash at startup with syslog message

[Markus Dahms]

Hi,

removing the gstreamer1.0-libav package helps as a temporary solution.
Shotwell complains, but runs fine for my photos:

Failed to play the file: couldn't get state.
...

Markus

Bug#833466: openconnect 7.06 fails to parse KMP message with recent Junos VPN

[Hillel Lubman]

Package: openconnect
Version: 7.06-2+b2
Severity: normal

Dear Maintainer,

Openconnect 7.06 became incompatible with new Pulse (Junos) VPN (--juniper
option). It fails to connect to it with such error:

Failed to parse KMP message

See http://lists.infradead.org/pipermail/openconnect-
devel/2016-February/003495.html

This is already fixed in openconnect 7.07 and later. Please package the more
recent version.



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

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

Versions of packages openconnect depends on:
ii  libc62.23-4
ii  libgnutls30  3.5.2-2
ii  libopenconnect5  7.06-2+b2
ii  libproxy1v5  0.4.11-5
ii  libxml2  2.9.4+dfsg1-1
ii  vpnc-scripts 0.1~git20150318-1

openconnect recommends no packages.

openconnect suggests no packages.

-- no debconf information

Bug#833464: O: tomatoes -- tomato smashing game

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I lack the time and interest to further maintain 
it.

Bug#833465: fwknop: FTBFS everywhere: 'GPG_EXE' undeclared

[Santiago Vila]

Package: src:fwknop
Version: 2.6.0-3
Severity: serious
Tags: patch
Owner: sanv...@debian.org

The QA upload I did (2.6.0-3) fails to build everywhere.

This is the error message:

gpgme_funcs.c: In function 'init_gpgme':
gpgme_funcs.c:67:61: error: 'GPG_EXE' undeclared (first use in this function)
 (fko_ctx->gpg_exe != NULL) ? fko_ctx->gpg_exe : GPG_EXE,

I think there are two reasons why this happens:

* gpg is no longer present in the official chroots.
* The package fails to detect gpg2 (which is a dependency for libgpgme).

I believe the attached patch should fix it.

Will make another QA upload to fix this in short.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ override_dh_auto_configure:
 #  mkdir m4
chmod +x ./debian/autogen.sh
./debian/autogen.sh
-   dh_auto_configure -- $(confflags) --with-gpgme
+   dh_auto_configure -- $(confflags) --with-gpgme --with-gpg=/usr/bin/gpg2
 
 override_dh_auto_build:
dh_auto_build

Bug#831184: mumble: FTBFS with GCC 6, seems Ice related

[Chris Knadle]

Jose Gutierrez de la Concha:
> Hi,
> 
> When building an Ice application with C++11/C++14 enabled you need to link
> with libraries with ++11 suffix -lIce++11 instead of -lIce.
> 
> libzeroc-ice3.6 provide C++98 libraries and C++11 libraries with ++11
> suffix and the APIs are slightly different.

I tried this (patch is attached), but this results in an error message
that the linker is unable to find -lIce++11:

-

g++ -c -include release/murmurd -m64 -pipe -g -O2
-fdebug-prefix-map=/build/mumble-1.2.16/src/murmur=.
-fstack-protector-strong -Wformat -Werror=format-security -Wfatal-errors
-fvisibility=hidden -g -std=c++11 -O2 -Wall -W -D_REENTRANT
-DNO_UPDATE_CHECK -DPLUGIN_PATH=/usr/lib/mumble
-DMUMBLE_VERSION=1.2.16-1 -DHAVE_LIMITS_H -DHAVE_ENDIAN_H
-DRESTRICT=__restrict__ -D_FORTIFY_SOURCE=2
-DMUMBLE_VERSION_STRING=1.2.16 -DMURMUR -DUSE_DBUS -DUSE_ICE
-DUSE_BONJOUR -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_XML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtSql -I/usr/include/qt4 -I/usr/include/qt4/QtDBus
-I../../src -I. -I/usr/include/speech-dispatcher -I../bonjour -Irelease
-I/usr/include/avahi-compat-libdns_sd -o release/moc_BonjourServer.o
release/moc_BonjourServer.cpp

g++ -m64 -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -Wl,-O1 -o
../../release/murmurd release/ACL.o release/Group.o release/Channel.o
release/Connection.o release/User.o release/Timer.o release/CryptState.o
release/OSInfo.o release/Net.o release/SSL.o release/Version.o
release/main.o release/Server.o release/ServerUser.o release/ServerDB.o
release/Register.o release/Cert.o release/Messages.o release/Meta.o
release/RPC.o release/UnixMurmur.o release/DBus.o release/MurmurIce.o
release/BonjourServiceRegister.o release/BonjourServer.o
release/Mumble.pb.o release/Murmur.o release/moc_ACL.o
release/moc_Channel.o release/moc_Connection.o release/moc_Server.o
release/moc_ServerUser.o release/moc_Meta.o release/moc_UnixMurmur.o
release/moc_DBus.o release/moc_MurmurIce.o
release/moc_BonjourServiceRegister.o release/moc_BonjourServer.o
-L../../release -L/usr/lib/x86_64-linux-gnu -lprotobuf -lcap -lIce++11
-lIceUtil -lQtDBus -lssl -lcrypto -ldns_sd -lavahi-common -lavahi-client
-lpthread -lQtSql -lQtXml -lQtNetwork -lQtCore

/usr/bin/ld: cannot find -lIce++11

collect2: error: ld returned 1 exit status

Makefile.Release:183: recipe for target '../../release/murmurd' failed

make[4]: *** [../../release/murmurd] Error 1

-

I had a quick look at the documentation for using Ice 3.6 concerning C++
and at the moment it doesn't mention using -lIce++11:


https://doc.zeroc.com/display/Ice36/Using+the+Linux+Binary+Distributions#UsingtheLinuxBinaryDistributions-C++

instead it's suggested to use -L/usr/lib/c++11 for 32-bit and
-L/usr/lib64/c++11 for 64-bit.  The Debian package seems to have this
directory in /usr/lib/x86_64-linux-gnu/c++11.  I tried adding that but
that doesn't seem to help (and I suspect this is redundant as
-L/usr/lib/x86_64-linux-gnu is included):

-

g++ -c -include release/murmurd -m64 -pipe -g -O2
-fdebug-prefix-map=/build/mumble-1.2.16/src/murmur=.
-fstack-protector-strong -Wformat -Werror=format-security -Wfatal-errors
-fvisibility=hidden -g -std=c++11 -O2 -Wall -W -D_REENTRANT
-DNO_UPDATE_CHECK -DPLUGIN_PATH=/usr/lib/mumble
-DMUMBLE_VERSION=1.2.16-1 -DHAVE_LIMITS_H -DHAVE_ENDIAN_H
-DRESTRICT=__restrict__ -D_FORTIFY_SOURCE=2
-DMUMBLE_VERSION_STRING=1.2.16 -DMURMUR -DUSE_DBUS -DUSE_ICE
-DUSE_BONJOUR -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_XML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtSql -I/usr/include/qt4 -I/usr/include/qt4/QtDBus
-I../../src -I. -I/usr/include/speech-dispatcher -I../bonjour -Irelease
-I/usr/include/avahi-compat-libdns_sd -o release/moc_BonjourServer.o
release/moc_BonjourServer.cpp

g++ -m64 -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -Wl,-O1 -o
../../release/murmurd release/ACL.o release/Group.o release/Channel.o
release/Connection.o release/User.o release/Timer.o release/CryptState.o
release/OSInfo.o release/Net.o release/SSL.o release/Version.o
release/main.o release/Server.o release/ServerUser.o release/ServerDB.o
release/Register.o release/Cert.o release/Messages.o release/Meta.o
release/RPC.o release/UnixMurmur.o release/DBus.o release/MurmurIce.o
release/BonjourServiceRegister.o release/BonjourServer.o
release/Mumble.pb.o release/Murmur.o release/moc_ACL.o
release/moc_Channel.o release/moc_Connection.o release/moc_Server.o
release/moc_ServerUser.o release/moc_Meta.o release/moc_UnixMurmur.o
release/moc_DBus.o 

Bug#826814: gpac: OpenJPEG removal

[Emilio Pozuelo Monfort]

On Sat, 23 Jul 2016 13:30:19 +0200 Emilio Pozuelo Monfort  
wrote:
> On 23/07/16 12:40, James Cowgill wrote:
> > Control: forwarded -1 https://github.com/gpac/gpac/issues/592
> > 
> > On Thu, 2016-07-21 at 19:12 +0200, Emilio Pozuelo Monfort wrote:
> >> On Thu, 09 Jun 2016 10:30:01 +0200 "Mathieu Malaterre"  
> >> wrote:
> >>>
> >>> This is a continued operation since src:jasper removal for stretch
> >>> release.
> >>>
> >>> src:openjpeg will be removed from Debian for the stretch release
> >>> (and following that, the archive in general). For more information
> >>> see: http://bugs.debian.org/826805
> >>>
> >>> It has been superseeded by src:openjpeg2
> >>>
> >>> Your package uses src:openjpeg, so please either remove the
> >>> JPEG2000 functionality or move to the new API.
> >>
> >> Ping? It looks like your package already uses libjpeg-turbo. Can we
> >> just drop the openjpeg support? If not, can you forward this
> >> upstream? This is the last key package still depending on openjpeg,
> >> and it is going to block its removal from Stretch.
> > 
> > I've forwarded the bug, but are there any objections to removing
> > openjpeg support in the meantime? There doesn't seem to be any users of
> > the openjpeg support in other Debian packages at least.
> 
> That'd be good in order to finish the transition. But I don't use gpac.

Can that be done?

Cheers,
Emilio

Bug#677570: acl: please add symbols file

[Daniel Kahn Gillmor]

Package: libacl1
Version: 2.2.52-3
Followup-For: Bug #677570

It would really be nice to have the symbols file in libacl.

I generated an even farther-reaching symbols file by pulling all the
versions available on snapshots.debian.org.  I'm attaching it here.

Please include this in libacl.

   --dkg

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

Kernel: Linux 4.7.0-rc7-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 libacl1 depends on:
ii  libattr1  1:2.4.47-2
ii  libc6 2.23-4

libacl1 recommends no packages.

libacl1 suggests no packages.

-- no debconf information
libacl.so.1 libacl1 #MINVER#
 ACL_1.0@ACL_1.0 2.2.23
 ACL_1.1@ACL_1.1 2.2.23
 ACL_1.2@ACL_1.2 2.2.51
 __acl_extended_file@Base 2.2.51
 __acl_from_xattr@Base 2.2.23
 __acl_to_xattr@Base 2.2.23
 acl_add_perm@ACL_1.0 2.2.23
 acl_calc_mask@ACL_1.0 2.2.23
 acl_check@ACL_1.0 2.2.23
 acl_clear_perms@ACL_1.0 2.2.23
 acl_cmp@ACL_1.0 2.2.23
 acl_copy_entry@ACL_1.0 2.2.23
 acl_copy_ext@ACL_1.0 2.2.23
 acl_copy_int@ACL_1.0 2.2.23
 acl_create_entry@ACL_1.0 2.2.23
 acl_delete_def_file@ACL_1.0 2.2.23
 acl_delete_entry@ACL_1.0 2.2.23
 acl_delete_perm@ACL_1.0 2.2.23
 acl_dup@ACL_1.0 2.2.23
 acl_entries@ACL_1.0 2.2.23
 acl_equiv_mode@ACL_1.0 2.2.23
 acl_error@ACL_1.0 2.2.23
 acl_extended_fd@ACL_1.0 2.2.23
 acl_extended_file@ACL_1.0 2.2.23
 acl_extended_file_nofollow@ACL_1.2 2.2.51
 acl_free@ACL_1.0 2.2.23
 acl_from_mode@ACL_1.0 2.2.23
 acl_from_text@ACL_1.0 2.2.23
 acl_get_entry@ACL_1.0 2.2.23
 acl_get_fd@ACL_1.0 2.2.23
 acl_get_file@ACL_1.0 2.2.23
 acl_get_perm@ACL_1.0 2.2.23
 acl_get_permset@ACL_1.0 2.2.23
 acl_get_qualifier@ACL_1.0 2.2.23
 acl_get_tag_type@ACL_1.0 2.2.23
 acl_init@ACL_1.0 2.2.23
 acl_set_fd@ACL_1.0 2.2.23
 acl_set_file@ACL_1.0 2.2.23
 acl_set_permset@ACL_1.0 2.2.23
 acl_set_qualifier@ACL_1.0 2.2.23
 acl_set_tag_type@ACL_1.0 2.2.23
 acl_size@ACL_1.0 2.2.23
 acl_to_any_text@ACL_1.0 2.2.23
 acl_to_text@ACL_1.0 2.2.23
 acl_valid@ACL_1.0 2.2.23
 closed@Base 2.2.47
 head@Base 2.2.47
 high_water_alloc@Base 2.2.23
 next_line@Base 2.2.35
 num_dir_handles@Base 2.2.47
 perm_copy_fd@ACL_1.1 2.2.23
 perm_copy_file@ACL_1.1 2.2.23
 walk_tree@Base 2.2.47

Bug#833462: openjdk-7-jre-headless does not upgrade : does not find that /proc is mounted

[Erwan David]

Package: openjdk-7-jre-headless
Version: 7u111-2.6.7-1~deb8u1
Severity: important
Tags: security

When trying to upgrade openjdk-7-jre I get error :

Setting up openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
/var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: 19: 
/var/lib/dpkg/info/openjdk-7-jre-headless:amd64.postinst: mountpoint: not found
the java command requires a mounted proc fs (/proc).

Indeed I do not have the mountpoint command

Maybe a dependency needs to be restricted on the version number ?

-- System Information:
Debian Release: 8.5
  APT prefers proposed-updates
  APT policy: (1001, 'proposed-updates'), (1001, 'stable'), (600, 'testing'), 
(500, 'stable-updates'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages openjdk-7-jre-headless depends on:
ii  ca-certificates-java  20140324
ii  initscripts   2.88dsf-59
ii  java-common   0.52
ii  libc6 2.19-18+deb8u5
ii  libcups2  2.0.3-10
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-4
ii  libgcc1   1:4.9.2-10
ii  libglib2.0-0  2.48.0-1~bpo8+1
ii  libjpeg62-turbo   1:1.4.1-2
ii  libkrb5-3 1.13.2+dfsg-2
ii  liblcms2-22.6-3+b3
ii  libnss3   2:3.20-1
ii  libpcsclite1  1.8.14-1
ii  libpulse0 7.1-2~bpo8+1
ii  libsctp1  1.0.16+dfsg-2
ii  libstdc++64.9.2-10
ii  multiarch-support 2.19-19
ii  tzdata-java   2016f-0+deb8u1
ii  zlib1g1:1.2.8.dfsg-2+b1

openjdk-7-jre-headless recommends no packages.

Versions of packages openjdk-7-jre-headless suggests:
ii  fonts-dejavu-extra 2.35-1
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  icedtea-7-jre-jamvm
pn  libnss-mdns
pn  sun-java6-fonts
pn  ttf-wqy-microhei | ttf-wqy-zenhei  

-- no debconf information

Bug#833460: O: open-cobol -- cobol compiler

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package.

Bug#833407: Please put adt-virt-* binaries back onto PATH

[Johannes Schauer]

Hi Ian,

Quoting Ian Jackson (2016-08-04 18:20:00)
> > In fact I only noticed this breakage because I wanted to add support for
> > adt-run-* to another tool: piuparts which already comes with lots of code
> > supporting the adt-run-* utilities. Now its broken.
> 
> I think in the rest of this mail you have mistakenly started writing
> adt-run-* instead of adt-virt-* ?

indeed I meant adt-virt-*. Sorry for the confusion.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#833461: roundcube-core

[Adrian Davey]

Package: roundcube-core
Version: 1.2.1+dfsg.1-1
Severity: normal

Dear Maintainer,

roundcube-core cannot be upgraded nor installed from unstable due to a 
dependency on an unknown package


dep: php-pear-core-minimal (>= 1.10.1)
Package not available

Should there be a dependency on a virtual package that either php-pear 
or some new package named php-pear-core-minimal can meet?


Regards,

Adrian

Bug#833463: gkrellm: New upstream version available

[Adrian Bunk]

Package: gkrellm
Version: 2.3.6~rc1-1+b1
Severity: wishlist

GKrellM 2.3.7 is available at
  http://gkrellm.srcbox.net/

Could you package this version?


Thanks in advance

Bug#833407: Please put adt-virt-* binaries back onto PATH

[Ian Jackson]

Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> thanks a lot Ian for making these four points. I could not've put it
> better. I was very happy with the original autopkgtest design as it
> finally gave us a way to abstract container access in a more or less
> unified way and allowed to avoid every tool to re-implement its own
> set of container support.

Right.  That was precisely what I was trying to put an end to.

> I was even thinking of making the
> autopkgtest backend the default (and integrate it such that it would
> be easier to use from the sbuild command line) and drop the custom
> schroot backend in favor of the adt schroot backend and thus
> decrease overall code complexity.

The former would certainly be nice.  I can see why as the maintainer
you would like the latter.

> In fact I only noticed this breakage because I wanted to add support for
> adt-run-* to another tool: piuparts which already comes with lots of code
> supporting the adt-run-* utilities. Now its broken.

I think in the rest of this mail you have mistakenly started writing
adt-run-* instead of adt-virt-* ?

Upstream autopkgtest seems to be deprecating adt-run in favour of a
new command line utility autopkgtest.  But those are both the DEP-8
test runners, which not so many other people are using, and for which
a transition plan with retention of adt-run for compatibility is
promised.

> Another program which is now broken is the reprotest tool which is
> developed in this year's GSoC project for the reproducible builds
> team.
> 
> Other tools that made use of adt-run-* and now have reduced functionality are
> pbuilder, jenkins-debian-glue, reprotest, pkg-perl-tools and debci.
> 
> Using codesearch.debian.net it is not hard to find that others
> depend on specific functionality of your software. Next time you
> remove features, please consult the consumers of these features
> first.

I prefer to attribute this to misunderstanding rather than
carelessness.

I don't think it had been appreciated that the adt-virt-* interface
was intended as, and had been treated as, a public interface, for use
by many other projects.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#831672: screen: segfault on digraph

[Jan Nordholz]

Hi,

the bug exists because screen's "struct action" provides no explicit way
to store the number of arguments, and doing

bind u digraph U+

results in act->args being allocated for two "char *"s (including a
terminating NULL), but act->argl only for one int... by the way, both
allocations I'm talking about (process.c:4698):

  if ((pp = (char **)malloc((unsigned)(argc + 1) * sizeof(char **))) == 0)
Panic(0, "%s", strnomem);
  if ((lp = (int *)malloc((unsigned)(argc) * sizeof(int *))) == 0)
Panic(0, "%s", strnomem);

should have a '*' less in the sizeof(), we're allocating room for ints, not
for pointers.

Anyway, DoAction() finally checks in the RC_DIGRAPH case (process.c:3858):

  if (argl && argl[0] > 0 && argl[1] > 0)

And as argl[] is only one member wide, the final "argl[1]" could be anything;
and apparently on x86 we're just lucky that it's indeed 0. (If it's not, then
the following code will try to dereference args[1], which is the terminating
NULL that was placed earlier.)

Quick fix for users: initialize argl[1] by instead doing

bind u digraph U+ ""

Suggested code fix: RC_DIGRAPH should probably check that args[1] != NULL
before checking argl[1] > 0 (because the latter is meaningless without the
former, as discussed).


Jan
-- 
Jan Nordholz 
Security in Telecommunications 
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
phone: +49 30 8353 58663

Bug#708663: better schroot support to not need sudo

[Johannes Schauer]

Hi,

On Thu, 04 Aug 2016 18:05:37 +0200 Johannes Schauer  wrote:
> current piuparts implements a adt-run backend. Through that, schroot could be
> used without needing superuser privileges. Unfortunately, the latest
> autopkgtest upload removed the adt-run interface. Thus blocking this bug by
> the relevant autopkgtest bug.

sorry, just as in #833407 I mixed adt-run-* and adt-virt-*. I meant to write
adt-virt-* in my message above. Sorry for the confusion.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#833407: Please put adt-virt-* binaries back onto PATH

[Johannes Schauer]

Hi again,

On Thu, 4 Aug 2016 17:20:00 +0100 Ian Jackson  
wrote:
> Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> > Using codesearch.debian.net it is not hard to find that others depend on
> > specific functionality of your software. Next time you remove features,
> > please consult the consumers of these features first.
> 
> I prefer to attribute this to misunderstanding rather than
> carelessness.
> 
> I don't think it had been appreciated that the adt-virt-* interface
> was intended as, and had been treated as, a public interface, for use by many
> other projects.

it might just've been a misunderstanding yes. Sorry, I didn't mean to offend
anybody. I can only explain this part of my previous message being formulated
in the way it was by my current frustration about this feature having vanished.

Thanks for maintaining autopkgtest!

cheers, josch


signature.asc
Description: signature