Bug#841785: Please package the SVN version of pianobooster

[Antonio Ospite]

Package: pianobooster
Followup-For: Bug #841785

Dear Maintainer,

first of all, thanks for updating pianobooster.

May I ask where the 0.6.7 upstream version comes from?
Was it picked up arbitrarily just to be greater than 0.6.4?

If so, what about something like "0.6.4.0+svn156-1" for the debian
package instead?

It reflects the last stable upstream release number (modulo the trailing
.0), it is still less than a possible new 0.6.5 upstream release, and
it's still greater than the last debian version in _testing_.

  $ dpkg --compare-versions "0.6.4.0+svn156-1" lt "0.6.5-1" && echo "true"
  $ dpkg --compare-versions "0.6.4.0+svn156-1" gt "0.6.4.0-1" && echo "true"

Just an idea.

Ciao ciao,
   Antonio

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

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

Versions of packages pianobooster depends on:
ii  libasound21.1.2-1
ii  libc6 2.24-5
ii  libgcc1   1:6.2.0-13
ii  libgl1-mesa-glx [libgl1]  12.0.4-2
ii  libqt4-opengl 4:4.8.7+dfsg-11
ii  libqt4-xml4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libstdc++66.2.0-13

Versions of packages pianobooster recommends:
ii  fluidsynth  1.1.6-3+b1
ii  timidity2.13.2-40.5

Versions of packages pianobooster suggests:
pn  pianobooster-dbg  

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

Quoting HW42 (2016-11-17 05:10:00)
> After discussing this in the irc meeting yesterday I propose that:
> 
>  - we keep it as a separate tool.
>  - put it in a git repo under
>https://anonscm.debian.org/git/reproducible/
>  - We have more than enough DDs who are willing to sponsor uploads, so
>having it in the Debian archive is no problem.
>  - we mainly maintain this as a group. I will try to especially keep an
>eye on it.
> 
> Since you have done all the work so far the final decision is obviously
> up to you.
> 
> If the above is fine with you I will prepare packaging it during the next
> week (I also have a few improvements planed).

please go ahead.

I'll make sure that sbuild adds a facility to receive a full binNMU changelog
entry from the user.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#844539: Please revert DN related behaviour change introduced in 3.5.6

[Guido Günther]

On Wed, Nov 16, 2016 at 06:54:41PM +0100, Guido Günther wrote:
> Package: libgnutls30
> Version: 3.5.6-4
> Severity: normal
> 
> Hi,
> 3.5.6 introuced a behaviour change that breaks libvirt. See
> 
> https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008224.html
> 
> and look for  "FAIL: virnettlssessiontest".
> 
> The upstream discussion is here:
> 
> https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008224.html
> 
> and it seems this will be reverted. Please revert that change in Debian
> too so it unbreaks libvirt.

The upstream commit for this seems to be:

70bf8475bb0ab178fe36ee4c601a6cfec8e70a3f

Cheers,
 -- Guido

> Cheers and thanks for maintaining gnutls in Debian,
>  -- Guido
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
> (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libgnutls30 depends on:
> ii  libc62.24-5
> ii  libgmp10 2:6.1.1+dfsg-1
> ii  libhogweed4  3.3-1
> ii  libidn11 1.33-1
> ii  libnettle6   3.3-1
> ii  libp11-kit0  0.23.2-5
> ii  libtasn1-6   4.9-4
> ii  zlib1g   1:1.2.8.dfsg-2+b3
> 
> libgnutls30 recommends no packages.
> 
> Versions of packages libgnutls30 suggests:
> ii  gnutls-bin  3.5.5-6
> 
> -- no debconf information

Bug#784044: [pkg-lxc-devel] Bug#784044: Patches for opensuse 42.1

[Evgeni Golov]

Hi,

Thanks for the patch. I originally only tested my upstream patch with 13.1. 
will see that this also gets included upstream.

Greets

On November 17, 2016 7:57:17 AM GMT+01:00, Benda Xu  wrote:
>Hi,
>
>After applying the obs-build patch in
>https://github.com/lxc/lxc/pull/1260, the attached patch allows
>openSUSE
>42.1 to be bootstrapped on Debian.
>
>Yours,
>Benda
>
>
>
>
>
>___
>Pkg-lxc-devel mailing list
>pkg-lxc-de...@lists.alioth.debian.org
>https://lists.alioth.debian.org/mailman/listinfo/pkg-lxc-devel

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

Bug#812342: systemd stop sequence stucks

[Vincenzo Demasi]

Hello,

I've noticed that the stop sequence of the rabbitmq-server hangs.

After some inspections I've tried the changes suggested by Alexey
and they works quite well. Now the service can stop without
problems.

If you apply this changes to the rabbitmq-server.service file, please,
don't forget to add the socat package to the dependencies,
because it is required for the proposed solution.

Best regards

-- 
Vincenzo Demasi

Bug#840039: ITA: httpbin -- HTTP request and response service

[Adrian Bunk]

On Wed, Nov 16, 2016 at 07:54:57PM -0400, Luis Alfredo da Silva wrote:
> How can I proceed with this package, it belongs to a team

The uploader inside the team has given it up for adoption.

You can adopt this package to maintain it yourself without
the team.

Or you can ask the team Python Applications Packaging Team 
 whether you
can maintain it inside the team (I would expect the answer
would be "yes", but please ask first).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#784044: Patches for opensuse 42.1

[Benda Xu]

Hi,

After applying the obs-build patch in
https://github.com/lxc/lxc/pull/1260, the attached patch allows openSUSE
42.1 to be bootstrapped on Debian.

Yours,
Benda

1. openSUSE forbids root login. chpasswd may not work from missing PAM modules.
2. during bootstrap zypper need to import archive keys without checking.
3. dependency of iproute2 could not be resolved during bootstrap.

Index: templates/lxc-opensuse
===
--- templates.orig/lxc-opensuse
+++ templates/lxc-opensuse
@@ -116,7 +116,6 @@ EOF
 touch $rootfs/etc/sysconfig/kernel
 
 echo "Please change root-password !"
-echo "root:root" | chpasswd -R $rootfs
 
 return 0
 }
@@ -150,7 +149,7 @@ download_opensuse()
 else
 zypper --quiet --root $cache/partial-$arch-packages --non-interactive ar http://download.opensuse.org/update/$DISTRO/ update || return 1
 fi
-	zypper --quiet --root $cache/partial-$arch-packages --non-interactive --gpg-auto-import-keys update || return 1
+zypper --quiet --root $cache/partial-$arch-packages --non-interactive --gpg-auto-import-keys --no-gpg-checks update || return 1
 zypper --root $cache/partial-$arch-packages --non-interactive in --auto-agree-with-licenses --download-only zypper lxc patterns-openSUSE-base bash iputils sed tar rsyslog || return 1
 cat > $cache/partial-$arch-packages/opensuse.conf << EOF
 Preinstall: aaa_base bash coreutils diffutils
@@ -188,12 +187,6 @@ EOF
 echo "Support: dhcpcd" >> $cache/partial-$arch-packages/opensuse.conf
 fi
 
-# Leap doesn't seem to have iproute2 utils installed
-if [ $DISTRO == "leap/42.1" ]
-then
-echo "Support: net-tools iproute2" >> $cache/partial-$arch-packages/opensuse.conf
-fi
-
 if [ "$arch" = "i686" ]; then
 mkdir -p $cache/partial-$arch-packages/var/cache/zypp/packages/repo-oss/suse/i686/
 for i in "$cache/partial-$arch-packages/var/cache/zypp/packages/repo-oss/suse/i586/*" ; do

Bug#844486: gnuplot-qt: Mismatch between the program and library build versions with GNUTERM=wxt

[Anton Gladky]

Hi Olly,

thanks for your opinion! From my point of view, wxwidgets3.0
should be binNMUed together with all rdeps. Because even a
minor source upload of wxwidges3.0t will start this process anyway
but in uncoordinated mode.

Cheers

Anton

2016-11-17 2:36 GMT+01:00 Olly Betts :
> However, if you want to eliminate this warning message and are going to
> binNMU wxwidgets3.0 to that end, you will also need to binNMU any of its
> rdeps which haven't been built with the newer compiler ABI, or else
> you're just going to swap around which rdeps issue this warning.
>
> Cheers,
> Olly

Bug#844582: ITP: python-sparkpost -- Super-mega-official Python package for using the SparkPost API

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-sparkpost
  Version : 1.3.2
  Upstream Author : SparkPost 
* URL : https://github.com/SparkPost/python-sparkpost
* License : Apache 2.0
  Programming Lang: Python
  Description : SparkPost Python API client

 Super-mega-official Python package for using the SparkPost API.
 .
 Python and Python-Django integration with SparkPost's email transmission
 API.

This package is needed to run tests for Anymail:

 https://pypi.python.org/pypi/django-anymail/0.6.1

which I also intend to package.

Since this package is only useful to interact with SparkPost's proprietary
system, I plan to upload it to Contrib.

I plan to maintain this within the Debian Python Modules Team.

Bug#844185: RFS: fvwm/2.6.7-1 [ITA] -- f? virtual window manager

[Jaimos Skriletz]

On Wed, Nov 16, 2016 at 6:57 PM, Axel Beckert  wrote:
> Hi Jaimos,
>

Hi Axel, thanks for responding and looking at my package.

> I've had a short review of your changes and only found a few minor
> nitpicks so far:
>

They were informative and helping me learn, I have updated the package
following their advice.

>> - New features and bug fixes. For a full list between 2.6.5 and 2.6.7
>>   see /usr/share/doc/fvwm/NEWS.gz
>
> Since the upstream NEWS file is defacto a changelog, it wouldn't be
> bad if the upstream NEWS file would be installed as
> /usr/share/doc/fvwm/changelog.gz

The NEWS file is now used as the changelog.

>>   * Upstream moved from cvs to git. Updated watch file.
>
> Please use https://github.com/fvwmorg/fvwm/releases instead of
> https://github.com/fvwmorg/fvwm/tags in debian/watch. (May need some
> additional tweaking.) Otherwise you would download a Git snapshot of
> the tagged commit instead of the real released tar ball.

Updated. I somehow got fixated on tags due to the old releases being
there, thanks for pointing out releases was far easier to use.

> All the Lintian hardening warnings could be fixed by just adding this
> line to debian/rules (e.g. after the DH_VERBOSE line):
>
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all

Updated

> From the debdiff between the current and your source package:
>
>  %:
> -   dh $@ --with autoreconf
> +   dh $@
>
> Why have you removed "--with autoreconf" while keeping the
> Build-Depends on dh-autoreconf? This change is also not mentioned in
> the debian/changelog entry.
>

Thanks for noticing this,

I had a build problem on the first trial release due to script relying
on .git causing the autoreconf build to fail and removed that to build
from provided files. Upstream fixed it, but after focusing on other
aspects of the package I had forgotten I had done that.

> My suggestion to solve this is to leave debian/rules as it is now,
> remove the build-dependency on dh-autoreconf and use debhelper compat
> level 10 instead (which implies --with autoreconf and --parallel) --
> and mention that in the debian/changelog.
>
> As far as I can see, you can also safely drop the build-dependency on
> autotools-dev as its not used directly and debhelper depends on it
> (and on dh-autoreconf) nowadays. At least it still builds fine in
> pbuilder (without these two build-dependencies, and with debhelper
> compat level 10).
>

Updated. Changed compat to level 10 and the debhelper depends as well,
then dropped the depends and was able to get it to build in pbuilder
as well.

> Despite those are all rather minor issues, I'd be happy if you could
> come up with an updated source package addressing most of these issues
> (at least the debian/watch and missing debian/changelog items).

Done. I have done all the above and also figured out how to get more
output from lintian. fixed some additional spelling errors that were
found as well.

You can find the updated files in the same location
http://fvwmforums.org/fvwm-2.6.7/

Thanks again,

jaimos

Bug#844581: libxml2: CVE-2016-9318

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.4+dfsg1-2.1
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=772726

Hi,

the following vulnerability was published for libxml2.

CVE-2016-9318[0]:
| libxml2 2.9.4 and earlier, as used in XMLSec 1.2.23 and earlier and
| other products, does not offer a flag directly indicating that the
| current document may be read but other files may not be opened, which
| makes it easier for remote attackers to conduct XML External Entity
| (XXE) attacks via a crafted document.

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-9318
[1] https://bugzilla.gnome.org/show_bug.cgi?id=772726

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#844580: pygresql: New upstream version available

[Kamaraju Kusumanchi]

Source: pygresql
Version: 1:4.0-3.1
Severity: wishlist

Dear Maintainer,

The current version of pygresql in Debian Unstable is 1:4.0-3.1 which is very
old. The upstream has recently released
5.0.2 [1]. Could you please package it?

Even though there is another package in Debian, psycopg2, that provides similar
functionality as that of pygresql, it would be nice to have the latter as an
alternative.

Note: Loren Dvid initially requested this on debian-user [2]. I am filing the
bug report on his behalf.

[1] - http://www.pygresql.org/contents/changelog.html
[2] - https://lists.debian.org/debian-user/2016/11/msg00314.html



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

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

Bug#843454: ITP: docker-credential-helpers -- native store to keep Docker credentials, safe

[Jason Pleau]

Hi Felipe,

2016-11-16 17:40 GMT-05:00 Felipe Sateler :
> Hi Jason
>
> On Sun, 6 Nov 2016 13:16:58 -0500 Jason Pleau  wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jason Pleau 
>>
>> * Package name: docker-credential-helpers
>>   Version : 0.3.0
>>   Upstream Author : David Calavera 
>> * URL : https://github.com/docker/docker-credential-helpers/
>> * License : MIT
>>   Programming Lang: Go / C
>>   Description : native store to keep Docker credentials safe
>>
>> docker-credential-helpers provides a Linux executable to store Docker
>> credentials. (It also has one for OSX and Windows, but those won't be
>> built nor used in Debian).
>>
>> It is a dependency of an upcoming python package
>> "dockerpy-creds", which is needed to update python-docker to its latest
>> upstream version.
>
>
> Have you done some work yet on this? If so, could you push it to
> collab-maint so I can take a look?

Not yet, I scheduled some time saturday to work on it and hopefully
finalize it, I will keep you updated :)

Thanks !

>
> Saludos
>

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[HW42]

Johannes Schauer:
> Hi,
> 
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer  wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer  wrote:
>>> But then on IRC, HW42 suggested to approach this problem differently.
>>> Instead of integrating the functionality of figuring out the right
>>> repositories to reproduce the contents of a buildinfo file into sbuild,
>>> write a tool that can drive any package builder (like pbuilder).
> 
> there seems to be a conceptual problem with such an approach.
> 
> For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
> How does one best pass such a multi-line value via command line options? Would
> the best way to pass the changelog entry via the .buildinfo file? And if
> pbuilder and sbuild then already are parsing the .buildinfo file, would it not
> be better for the debrebuild machinery to be implemented by either in the 
> first
> place?

Since this is somewhat relevant to the discussion in the other part of
this thread: I don't think this is a conceptual problem. Sure it could
be nicer if we don't had binNMUs, but I see no real problem in passing
it via cmd line option or via a plain file. I would anyway modify
debrebuild to be able to call sbuild/pbuiler/etc. directly and then you
are able to use a tempfile cleanly.



signature.asc
Description: OpenPGP digital signature

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[HW42]

Johannes Schauer:
> Hi all,
> 
> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer  wrote:
>> I was thinking about this issue again and thought that instead of creating a
>> wrapper for sbuild which then uses a chroot-setup hook to install the
>> dependencies, what I should instead do is to let sbuild itself accept
>> .buildinfo files and then do the right thing like:
>>
>>  - use snapshot.d.o to retrieve the right timestamps needed to gather all
>>packages
>>  - mangle the build dependencies such that the source package now depends on
>>the exact right package versions and let the resolver figure out the rest
>>(thanks Benjamin for that idea)
>>  - check whether the generated binaries produce the same checksum as given in
>>the supplied buildinfo file
>>
>> But then on IRC, HW42 suggested to approach this problem differently. Instead
>> of integrating the functionality of figuring out the right repositories to
>> reproduce the contents of a buildinfo file into sbuild, write a tool that can
>> drive any package builder (like pbuilder).
>>
>> I now wrote such a script.
> 
> now that libdpkg-perl comes with support for .buildinfo files, I improved the
> script (new version attached) with the following changes:
> 
>  - don't use DateTime::Format::Strptime but Time::Piece instead (which is a
>perl core module)
>  - don't use CTRL_INDEX_SRC but CTRL_FILE_BUILDINFO now that dpkg supports
>.buildinfo files
>  - Dpkg::Compression::FileHandle as it is not needed
>  - the .dsc file name is no longer part of the .buildinfo file, so assemble 
> the
>.dsc file name from the package name and version using 
> Dpkg::Source::Package
>  - use the information from the Environment field
>  - instead of splitting Installed-Build-Depends manually, use
>Dpkg::Deps::deps_parse
>  - instead of using [trusted=yes], retrieve the gpg key of the reproducible
>builds repository and verify its fingerprint
>  - set Binary::apt-get::Acquire::AllowInsecureRepositories to false so that
>apt-get fails to update repositories it cannot authenticate
>  - use Dpkg::Vendor to retrieve the keyring filenames
> 
> Thanks to Guillem Jover for the code review!

After discussing this in the irc meeting yesterday I propose that:

 - we keep it as a separate tool.
 - put it in a git repo under
   https://anonscm.debian.org/git/reproducible/
 - We have more than enough DDs who are willing to sponsor uploads, so
   having it in the Debian archive is no problem.
 - we mainly maintain this as a group. I will try to especially keep an
   eye on it.

Since you have done all the work so far the final decision is obviously
up to you.

If the above is fine with you I will prepare packaging it during the next
week (I also have a few improvements planed).



signature.asc
Description: OpenPGP digital signature

Bug#844579: console-setup: CyrAsia font missing Kazakh letter

[Baurzhan Muftakhidinov]

Package: console-setup

Version: 1.153

Dear maintainers,

Recently I loaded CyrAsia font in console, and have noticed
that it misses one Kazakh letter:

Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
ұ U+04B1 Cyrillic Small Letter Straight U with Stroke

I checked these codes in
https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontsets/CyrAsia.256

Could you please add these to CyrAsia font definition?

Thanks,

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Matthew Gabeler-Lee]

fixed 842952 50.0-1
thanks

On 11/03/2016 10:24 AM, Sylvestre Ledru wrote:
> In the future, please report a bug per issue and create a meta bug to
> keep track of them.
>
> It makes the life of the maintainer harder. 

Sorry for that.

Having just installed 50.0-1, both the annoyances I mentioned seem to be
fixed.  The addressbar issue may have been fixed by another package
upgrade in between, I'm not sure.  The black bars issue was definitely
fixed just by installing the new version of firefox.

The widget size issue that ano...@users.sourceforge.net reported is
still present, but as you note that shouldn't be lumped into this, and
it doesn't bother me too much, so I'm marking this fixed ... assuming my
noob interaction with the control address doesn't go wrong ;)

Bug#844578: logrotate: Upstream has moved to GitHub

[陳昌倬]

Package: logrotate
Version: 3.8.7-2
Severity: wishlist

Hi,

Upstream has moved logrotate to GitHub [0], so debian/watch needed to be
updated.

[0] https://github.com/logrotate/logrotate 



-- Package-specific info:
Contents of /etc/logrotate.d
total 80
-rw-r--r-- 1 root root 433 Sep 29 18:03 apache2
-rw-r--r-- 1 root root 173 Sep  3 02:26 apt
-rw-r--r-- 1 root root 181 Jun 17 17:28 cups-daemon
-rw-r--r-- 1 root root 107 Nov 22  2015 dbconfig-common
-rw-r--r-- 1 root root 232 Jun 10  2015 dpkg
-rw-r--r-- 1 root root 146 Mar  3  2016 exim4-base
-rw-r--r-- 1 root root 126 Mar  3  2016 exim4-paniclog
-rw-r--r-- 1 root root 140 Dec 13  2014 firebird2.5
-rw-r--r-- 1 root root 165 Sep  9 22:51 libvirtd
-rw-r--r-- 1 root root 164 Sep  9 22:51 libvirtd.libxl
-rw-r--r-- 1 root root 162 Sep  9 22:51 libvirtd.lxc
-rw-r--r-- 1 root root 163 Sep  9 22:51 libvirtd.qemu
-rw-r--r-- 1 root root 162 Sep  9 22:51 libvirtd.uml
-rw-r--r-- 1 root root  94 Dec  4  2015 ppp
-rw-r--r-- 1 root root 515 Jan 28  2016 rsyslog
-rw-r--r-- 1 root root 513 Mar 19  2011 speech-dispatcher
-rw-r--r-- 1 root root 227 May  3  2015 sphinxsearch
-rw-r--r-- 1 root root 178 Aug  7  2014 ufw
-rw-r--r-- 1 root root 145 Jul 26 14:07 unicorn
-rw-r--r-- 1 root root 100 Dec 31  2014 yum


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

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

Versions of packages logrotate depends on:
ii  anacron 2.3-23
ii  base-passwd 3.5.41
ii  cron [cron-daemon]  3.0pl1-128
ii  libacl1 2.2.52-3
ii  libc6   2.24-5
ii  libpopt01.16-10
ii  libselinux1 2.6-3

Versions of packages logrotate recommends:
pn  mailx  

logrotate suggests no packages.

-- no debconf information

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#844577: RFS: openldap/2.4.44+dfsg-1 [RC]

[Ryan Tandy]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor to upload an updated openldap package. The 
package can be found on alioth:


http://pkg-openldap.alioth.debian.org/2.4.44/openldap_2.4.44+dfsg-1.dsc
http://pkg-openldap.alioth.debian.org/2.4.44/openldap_2.4.44+dfsg-1_amd64.changes

(Sorry for the unconventional hosting. mentors.d.n apparently doesn't 
like me this week.)


Changes since the last upload can be seen in the .changes linked above. 
The git repository can also be found on alioth:


https://anonscm.debian.org/git/pkg-openldap/openldap.git

This is an interim upload, to unblock the removal of openslp (#815364) 
and heimdal (#836885) from stretch. It also fixes another RC bug: 
#330695. I intend to make another upload later to improve the upgrade 
handling (automate additional cases and provide more helpful messaging) 
and hopefully fix additional bugs.


Thanks for considering,
Ryan


signature.asc
Description: Digital signature

Bug#844576: gitlab: Pipeline status is always pending if no build fail

[Zhang Jingqiang]

Package: gitlab
Version: 8.13.3+dfsg1-2
Severity: important

Hello,
After upgrade to 8.13.3, Pipeline doesn't work like before.
The problem is, only builds in the first stage run,
if they fail, then the pipeline status changed to fail,
if they success, build in following stages will not run,
and if no builds following, pipeline status will always be pending.

The problem just make CI broken, so I mark this bug as important.

Thanks

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

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

Bug#844519: Stretch Alpha 8 Installation Failure

[Michael Owen]

On Wed, 16 Nov 2016 15:20:47 +0100 Cyril Brulebois  wrote:
> Hi Michael,
>
> Michael Owen  (2016-11-16):
> > Package: installation-reports
> >
> > Stretch Alpha 8 Installation Failure
> >
> > Boot method: netinst, both Alpha 8 and Daily Build
> > Image version: Alpha 8
> > Date: Multiple times, multiple machines, multiple drives
> >
> > Machine: Gigabyte GA-G31M-ES2K
> > Dell Inspiron 3847
> > Processor: Intel Core2 Duo 7800 (Gigabyte)
> > Intel i3 4th Generation (Dell)
> > Memory: 4 GB DDR2 (Gigabyte)
> > 8 GB DDR3 (Dell)
> > Partitions: sda1 full drive, sda5 (Gigabyte)
> > sda1 and sda5 (Dell)
> > (multiple configurations testing, including full drive single
> > partition)
> >
> > Output of lspci -knn (or lspci -nn):
> >
> > Base System Installation Checklist:
> > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> >
> > Initial boot: [O]
> > Detect network card: [O]
> > Configure network: [O]
> > Detect CD: [O]
> > Load installer modules: [O]
> > Detect hard drives: [O]
> > Partition hard drives: [O]
> > Install base system: [E]
> > Clock/timezone setup: [O]
> > User/password setup: [O]
> > Install tasks: [ ]
> > Install boot loader: [ ]
> > Overall install: [E]
> >
> > Comments/Problems:
> > Installation fails on base system install with the following error
message:
> > /lib/partman/choose_partition/60partition_tree/do_option: line 88
> > then it states
> > /lib/partman/active_choices/copy/choices: not found
> > then it states
> > debootstrap error 127
> >
> >  > and ideas you had during the initial install.>
> >
> > I get the identical error on both machines and in all possible
> > configurations. The two copies of netinst were full download of
> > netinst and a daily obtained with jigdo with good checksum.
> > The only thing in common between the machines is both have Intel
> > processors with Intel graphics but the Dell is much later version.
>
> Dailies are going to hit #844458 I suppose.
>
Hi Cyril
Yep, I got a hybrid CD 2 times, before all the files were distributed. I
downloaded again and found differences in the file, mainly in the
installer Readme "Archive: unstable" now shows "Archive: stable". So it
must have taken a while for the files to distribute. My hybrid netinst
had "Debian 9" in the upper right corner. That's gone now.

Thanks,
Mike

Bug#844575: motion: Upgrade from 3.4.1 to 4.0 made video poor and blocky

[J Mo]

Package: motion
Version: 4.0-1
Severity: normal

This is an bug for posterity. I've already fixed the issue myself.

After upgrading from binary version 3.4.1 to 4.0, I noticed that my
video capture was blocky and very poor quality. There was no change in
my configuration prior or during this upgrade.

After playing with settings, I noticed that if I commented out 
"ffmpeg_variable_bitrate 2", the issue went away and quality was once again 
good. The default for ffmpeg_variable_bitrate is 0. Playing with this setting 
didn't seem to have any effect on video quality, other than making it bad. I 
suspect this knob has been broken somewhere.

FYI I have "ffmpeg_video_codec mpeg4" set.

My ffmpeg installation was also upgraded at the same time, so this may
simply be an issue in ffmpeg and not have anything to do with motion.

Feel free to close after reading.



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

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

Versions of packages motion depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  libavcodec57   10:3.2-dmo1
ii  libavformat57  10:3.2-dmo1
ii  libavutil5510:3.2-dmo1
ii  libc6  2.24-5
ii  libjpeg62-turbo1:1.5.1-2
ii  libmariadbclient18 10.0.28-1
ii  libpq5 9.6.1-2
ii  libsqlite3-0   3.15.1-1
ii  libswscale410:3.2-dmo1
ii  lsb-base   9.20161101
ii  zlib1g 1:1.2.8.dfsg-2+b3

Versions of packages motion recommends:
ii  ffmpeg  10:3.2-dmo1

Versions of packages motion suggests:
pn  default-mysql-client  
pn  postgresql-client 

-- Configuration Files:
/etc/default/motion changed [not included]
/etc/motion/motion.conf changed [not included]

-- debconf information excluded

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On 2016, നവംബർ 16 9:22:03 PM IST, Philip Hands  wrote:
>Pirate Praveen  writes:
>Is this exception request again for a version of the package that is
>still missing source that is being processed upstream with Jison?
>
>Namely:
>
>  https://github.com/wycats/handlebars.js/blob/v1.3.0/src/handlebars.l
>
>as mentioned in #830987, which you closed with the move to non-free,
>but
>which would need to be reopened if the package moved back to main.
>
>I note that you have resolutely ignored questions about the issue of
>this missing source since July, no matter whether asked in various bug
>reports, or on the lists, or directly by members of the technical
>committee when the subject was before us.
>
>I would suggest that it would be reasonable for the Release Managers to
>refuse any exception until a sensible answer is provided.

Response is packaging jison, which is now available in main.

Bug#844486: gnuplot-qt: Mismatch between the program and library build versions with GNUTERM=wxt

[Olly Betts]

On Wed, Nov 16, 2016 at 08:14:00PM +0100, Anton Gladky wrote:
> block 844486 by 844526
> thanks
> 
> wxwidget should be binnmued to fix the bug properly.

I don't believe there's actually any real bug here, let alone an RC one.

GCC makes small fixes to obscure corner cases of the C++ ABI from time
to time and (not unreasonably) bumps the ABI version each time.  It used
to be the case that GCC defaulted to the old ABI version in this case,
but more recently they seem to make the new ABI version the default
instead.

In upstream wxWidgets, if the compile-time ABI and run-time ABI don't
match, then you get an error and the app won't run, which is just not
helpful.  In Debian we reduce that error to a warning - in practice I've
never seen an actual problem due to this, but leaving the warning there
means that this at least gets flagged as a potential issue.

However, if you want to eliminate this warning message and are going to
binNMU wxwidgets3.0 to that end, you will also need to binNMU any of its
rdeps which haven't been built with the newer compiler ABI, or else
you're just going to swap around which rdeps issue this warning.

Cheers,
Olly

Bug#844185: RFS: fvwm/2.6.7-1 [ITA] -- f? virtual window manager

[Axel Beckert]

Hi Jaimos,

Jaimos Skriletz wrote:
> I am looking to update and maintain the latest release of fvwm in
> Debian. I have created a source package for review

Thanks!

> along with have had a short correspondence with the current
> maintainer, sharing my work with him. The current maintainer said he
> no longer uses fvwm and if I'm willing to take responsibility I am
> welcomed to.
> 
> I have shared my work with the maintainer but besides that one short
> email, he has not gotten back to me.

Vincent: I assume you are aware of this sponsoring request and are
fine with the adoption of Debian's fvwm package.

I've had a short review of your changes and only found a few minor
nitpicks so far:

> - New features and bug fixes. For a full list between 2.6.5 and 2.6.7
>   see /usr/share/doc/fvwm/NEWS.gz

Since the upstream NEWS file is defacto a changelog, it wouldn't be
bad if the upstream NEWS file would be installed as
/usr/share/doc/fvwm/changelog.gz

This can be achieved by removing NEWS from debian/fvwm.docs and adding
the following override to debian/rules:

override_dh_installchangelogs:
dh_installchangelogs NEWS

Would fix the (pedantic-level) lintian warning no-upstream-changelog.

>   * Upstream moved from cvs to git. Updated watch file.

Please use https://github.com/fvwmorg/fvwm/releases instead of
https://github.com/fvwmorg/fvwm/tags in debian/watch. (May need some
additional tweaking.) Otherwise you would download a Git snapshot of
the tagged commit instead of the real released tar ball.

Compare:

→ md5sum 2.6.7.tar.gz fvwm_2.6.7.orig.tar.gz fvwm-2.6.7.tar.gz
9fa7c3968a8872a228ce186d5bce8cc1  2.6.7.tar.gz← 
https://github.com/fvwmorg/fvwm/archive/2.6.7.tar.gz
56ab83b0afa211729fce4a4d6fc57e8e  fvwm_2.6.7.orig.tar.gz  ← 
http://fvwmforums.org/fvwm-2.6.7/fvwm_2.6.7.orig.tar.gz
56ab83b0afa211729fce4a4d6fc57e8e  fvwm-2.6.7.tar.gz   ← 
https://github.com/fvwmorg/fvwm/releases/download/2.6.7/fvwm-2.6.7.tar.gz

All the Lintian hardening warnings could be fixed by just adding this
line to debian/rules (e.g. after the DH_VERBOSE line):

export DEB_BUILD_MAINT_OPTIONS=hardening=+all

>From the debdiff between the current and your source package:

 %:
-   dh $@ --with autoreconf
+   dh $@

Why have you removed "--with autoreconf" while keeping the
Build-Depends on dh-autoreconf? This change is also not mentioned in
the debian/changelog entry.

My suggestion to solve this is to leave debian/rules as it is now,
remove the build-dependency on dh-autoreconf and use debhelper compat
level 10 instead (which implies --with autoreconf and --parallel) --
and mention that in the debian/changelog.

As far as I can see, you can also safely drop the build-dependency on
autotools-dev as its not used directly and debhelper depends on it
(and on dh-autoreconf) nowadays. At least it still builds fine in
pbuilder (without these two build-dependencies, and with debhelper
compat level 10).

Despite those are all rather minor issues, I'd be happy if you could
come up with an updated source package addressing most of these issues
(at least the debian/watch and missing debian/changelog items).

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#844261: [Pkg-dns-devel] Bug#844261: does not correctly transfer zone - drops at least some RRSIGs

[Ondřej Surý]

This has now been fixed in git master and it will be part of any future
release.

Also please note that we found that knot dns has transfered all records
successfully, it just
didn't dump all of them to the zonefile.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Mon, Nov 14, 2016, at 14:22, Peter Palfrader wrote:
> severity 844261 minor
> thanks
> 
> On Mon, 14 Nov 2016, Ondřej Surý wrote:
> 
> > while I pretty much agree that Knot DNS should not be dropping the
> > RRSIGs, could you
> > try resigning the zone correctly and trying again?
> > 
> > ondrej@komorebi:/tmp/knot-failed-xfr$ ldns-verify-zone ax.txt 
> > Error: no signatures for sl.bilke.org.  SOA
> > Error: Bogus DNSSEC signature for sl.bilke.org. DNSKEY
> > There were errors in the zone
> > 
> > ondrej@komorebi:/tmp/knot-failed-xfr$ /usr/sbin/dnssec-verify -o
> > sl.bilke.org ax.txt 
> > Loading zone 'sl.bilke.org' from file 'ax.txt'
> > dnssec-verify: fatal: SOA is not signed (keys offline or inactive?)
> 
> Interesting, thanks a lot for pointing in the right direction.  It turns
> out, the zone was signed by the zone owner using a bind inline signing
> with only partial access to the rolling key material.
> 
> I still think the diagnostics on knot's part could be improved also.
> So, it shouldn't drop some of the RRSIGs, and/or maybe it should log
> when it doesn't like the zone?
> 
> Cheers,
> weasel
> -- 
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/

Bug#844372: This is serious.

[VDR User]

It seems the problem is due to the following line in
/etc/syslog-ng/syslog-ng.conf:

@include "`scl-root`/system/tty10.conf"

Changing this line to the following fixes the problem:

@include "/usr/share/syslog-ng/include/scl/system/tty10.conf"

While trying to investigate this problem, I did notice this:

WARNING: Configuration file format is too old, syslog-ng is running in
compatibility mode Please update it to use the syslog-ng 3.8 format at
your time of convenience, compatibility mode can operate less
efficiently in some cases. To upgrade the configuration, please review
the warnings about incompatible changes printed by syslog-ng, and once
completed change the @version header at the top of the configuration
file.;

The syslog-ng.conf shows it's version 3.7. Perhaps other files are
outdated as well for syslog-ng 3.8+ and that's why `scl-root` fails to
translate to /usr/share/syslog-ng/include/scl?

Bug#844574: RFA: hexchat -- IRC client for X based on X-Chat 2

[Jesse Rhodes]

Package: wnpp
Severity: normal

I request an adopter for the hexchat package.

My life situation is very different than it was when I first started
maintaining hexchat. Despite a few efforts to keep it going anyway, I have
determined that I don't have enough time to devote to this and do it
properly. 

Upstream is very cooperative and helpful - main contact is TingPing in the
#hexchat channel on Freenode. And I am reachable by email/around on IRC enough
to make the transition smooth and help you get familiarized. 

Thanks. This is a good program with a pretty wide userbase and it should
stay in the archive. 

sney

The package description is:
 HexChat is a graphical IRC client with a GTK+ GUI. Features include Python
 and Perl scripting support, a plugin API, multiple server/channel windows,
 spell checking, multiple authentication methods including SASL,
 and customizable notifications. For more information on IRC,
 see http://irchelp.org/.

Bug#844573: link-grammar: FTBFS (cannot find -lncurses)

[Santiago Vila]

Package: src:link-grammar
Version: 5.3.11-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>'
dh_autoreconf --as-needed
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'

[... snipped ...]

build:

BUILD SUCCESSFUL
Total time: 1 second
make[3]: Leaving directory '/<>/bindings/java'
Making all in ocaml
make[3]: Entering directory '/<>/bindings/ocaml'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/<>/bindings/ocaml'
Making all in python
make[3]: Entering directory '/<>/bindings/python'
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ 
-DPACKAGE_NAME=\"link-grammar\" -DPACKAGE_TARNAME=\"link-grammar\" 
-DPACKAGE_VERSION=\"5.3.11\" -DPACKAGE_STRING=\"link-grammar\ 5.3.11\" 
-DPACKAGE_BUGREPORT=\"link-gram...@googlegroups.com\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"link-grammar\" -DVERSION=\"5.3.11\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 
-DHAVE_STRNDUP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 
-DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_PRCTL=1 
-DHAVE_LOCALE_T_IN_LOCALE_H=1 -DHAVE_MKLIT=1 -DHAVE_LIBSTDC__=1 
-DHAVE_HUNSPELL=1 -DHUNSPELL_DICT_DIR=\"/usr/share/myspell/dicts\" 
-DHAVE_EDITLINE=1 -DHAVE_WIDECHAR_EDITLINE=1 -DHAVE_REGEXEC=1 
-DHAVE_PYTHON=\"2.7\" -DHAVE_MAYBE_UNINITIALIZED=1 -I.   
-I/usr/include/python2.7 -I../.. -I../.. -Wdate-t
 ime -D_FORTIFY_SOURCE=2 -DUSE_PTHREADS=1 -DUSE_SAT_SOLVER=1  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -Wall -std=c++11 -c -o 
../../bindings/python/_clinkgrammar_la-lg_python_wrap.lo `test -f 
'../../bindings/python/lg_python_wrap.cc' || echo 
'./'`../../bindings/python/lg_python_wrap.cc
libtool: compile:  g++ -DPACKAGE_NAME=\"link-grammar\" 
-DPACKAGE_TARNAME=\"link-grammar\" -DPACKAGE_VERSION=\"5.3.11\" 
"-DPACKAGE_STRING=\"link-grammar 5.3.11\"" 
-DPACKAGE_BUGREPORT=\"link-gram...@googlegroups.com\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"link-grammar\" -DVERSION=\"5.3.11\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 
-DHAVE_STRNDUP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 
-DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_PRCTL=1 
-DHAVE_LOCALE_T_IN_LOCALE_H=1 -DHAVE_MKLIT=1 -DHAVE_LIBSTDC__=1 
-DHAVE_HUNSPELL=1 -DHUNSPELL_DICT_DIR=\"/usr/share/myspell/dicts\" 
-DHAVE_EDITLINE=1 -DHAVE_WIDECHAR_EDITLINE=1 -DHAVE_REGEXEC=1 
-DHAVE_PYTHON=\"2.7\" -DHAVE_MAYBE_UNINITIALIZED=1 -I. -I/usr/include/python2.7 
-I../.. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_PTHR
 EADS=1 -DUSE_SAT_SOLVER=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -Wall -std=c++11 
-c ../../bindings/python/lg_python_wrap.cc  -fPIC -DPIC -o 
../../bindings/python/.libs/_clinkgrammar_la-lg_python_wrap.o
/bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -Wall -std=c++11 -version-info 8:11:3   -module 
-no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--as-needed -o 
_clinkgrammar.la -rpath /usr/lib/python2.7/dist-packages/linkgrammar 
../../bindings/python/_clinkgrammar_la-lg_python_wrap.lo  
../../link-grammar/liblink-grammar.la -L/usr/lib -lpython2.7 -lstdc++ 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/6/crtbeginS.o  
../../bindings/python/.libs/_clinkgrammar_la-lg_python_wrap.o   -Wl,-rpath 
-Wl,/<>/link-grammar/.libs -Wl,--as-needed 
../../link-grammar/.libs/liblink-grammar.so -L/usr/lib -lpython2.7 
-L/usr/lib/gcc/x86_64-linux-gnu/6 
-L/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/6/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/6/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/crtn.o  -g -O2 

Bug#844571: uncertainties: FTBFS randomly (ERROR: Comparison between function derivatives and numerical derivatives)

[Santiago Vila]

Package: src:uncertainties
Version: 2.4.4-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
==
ERROR: Comparison between function derivatives and numerical derivatives.
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/<>/uncertainties/test_umath.py", line 40, in 
test_fixed_derivatives_math_funcs
test_uncertainties.compare_derivatives(func, numerical_derivatives)
  File "/<>/uncertainties/test_uncertainties.py", line 203, in 
compare_derivatives
fixed_deriv_value, num_deriv_value))
DerivativesDiffer: Derivative #0 of function 'cos' may be wrong: at args = 
[-0.00015531348313757576+/-0], value obtained = 0.0001553134825132, while 
numerical approximation = 0.0001439137242899.
 >> begin captured stdout << -
Testing acos at [0.3515705140294627+/-0], arg #0
Testing acosh at [1.21383500642085+/-0], arg #0
Testing asin at [0.2751865361039778+/-0], arg #0
Testing asinh at [1.848245081819893+/-0], arg #0
Testing atan at [0.5694583185549367+/-0], arg #0
Testing atan2 at [-0.4649913075928138+/-0, 0.396898674765+/-0], arg #0
Testing atan2 at [-0.4649913075928138+/-0, 0.396898674765+/-0], arg #1
Testing atanh at [0.02193641824821002+/-0], arg #0
Testing copysign at [-1.3339747776292108+/-0, 1.4083966105684347+/-0], arg #0
Testing copysign at [-1.3339747776292108+/-0, 1.4083966105684347+/-0], arg #1
Testing cos at [-0.00015531348313757576+/-0], arg #0

- >> end captured stdout << --

--
Ran 54 tests in 1.396s

FAILED (errors=1)
E: pybuild pybuild:276: test: plugin custom failed with: exit code=1: cd 
uncertainties; nosetests
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned 
exit code 13
debian/rules:21: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This happens randomly. Sometimes it fails. Sometimes it does not.
But it's easy to trigger if the build is attempted enough times.

I attach two build logs in which this test failed.

Thanks.

uncertainties_2.4.4-1_amd64-20161112T050834Z.gz
Description: application/gzip


uncertainties_2.4.4-1_amd64-20161117T000619Z.gz
Description: application/gzip

Bug#844572: uncertainties: FTBFS randomly (FAIL: Full comparison to a Monte-Carlo calculation)

[Santiago Vila]

Package: src:uncertainties
Version: 2.4.4-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
==
FAIL: Full comparison to a Monte-Carlo calculation.
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/<>/uncertainties/test_umath.py", line 177, in 
test_monte_carlo_comparison
% (covariances_samples, covariances_this_module)
AssertionError: The covariance matrices do not coincide between the Monte-Carlo 
simulation and the direct calculation:
* Monte-Carlo:
[[  9.99611355e-05   1.34661091e-08   3.20307739e-04]
 [  1.34661091e-08   9.95636755e-07  -3.20894019e-05]
 [  3.20307739e-04  -3.20894019e-05   2.16969297e-03]]
* Direct calculation:
[[  1.e-04   0.e+00   3.17312046e-04]
 [  0.e+00   1.e-06  -3.37427446e-05]
 [  3.17312046e-04  -3.37427446e-05   2.14544216e-03]]

--
Ran 54 tests in 2.074s

FAILED (failures=1)
E: pybuild pybuild:276: test: plugin custom failed with: exit code=1: cd 
uncertainties; nosetests
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned 
exit code 13
debian/rules:21: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This happens randomly. Sometimes it fails. Sometimes it does not.
But it's easy to trigger if the build is attempted enough times.

I attach three build logs in which this test failed.

Thanks.

uncertainties_2.4.4-1_amd64-20161107T023353Z.gz
Description: application/gzip


uncertainties_2.4.4-1_amd64-20161117T000107Z.gz
Description: application/gzip


uncertainties_2.4.4-1_amd64-20161117T000521Z.gz
Description: application/gzip

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

While icedtea-web 1.6.2 does fixes a few bugs, this is not one of those.

Alain did reply to me in private saying that he was still seeing the
issue with the new icedtea-web and that downgrading to 7u111-2.6.7-1
got applets working again. So this is definitely a regression. Alain
also pointed me to a page with good applets to test this, the "Simple
upload" applet fails to run on the affected version:
http://demo.element-it.com/Examples/JavaPowUpload/index.htm

Meanwhile a new IcedTea release was out on experimental
(7u121-2.6.8-1), I tested it and I can confirm there is no regression
in it. It might take a while for a backport to show up, if you are
affected by this I recommend downgrading OpenJDK 7 as a workaround.


For future reference the actual error for the "Simple upload" applet is:

java.security.AccessControlException: access denied
("java.util.PropertyPermission" "java.net.preferIPv4Stack" "read")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:685)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1298)
at java.lang.System.getProperty(System.java:708)
at com.elementit.JavaPowUpload.Manager.init(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

java.security.AccessControlException: access denied
("java.util.PropertyPermission" "java.net.preferIPv4Stack" "read")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:685)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1298)
at java.lang.System.getProperty(System.java:708)
at com.elementit.JavaPowUpload.Manager.init(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

Bug#844570: dgit cross-filesystem dsc import fails.

[peter green]

Package: dgit
Version: 2.11

When I try to import a dsc on another filesystem dgit fails with an 
"invalid cross-device link" error.


It seems that dgit first creates symlinks in the parent directory of the 
git repo pointing at the dsc and associated files (which succeeds). Then 
it tries to create a hardlink to the target of the symlink (which fails).

Bug#790241: 0.9.1 is out

[Andrii Senkovych]

Hi Paolo,

I'm going to prepare and upload 0.8.14 (both master and slave) based
on the old git repositories asap. This is to assure that if it's not
possible to prepare 0.9.x for stretch then we'll at least have the
last of the previous major version thus we'll won't break the people's
setup badly. I hope to fix most of the issues in the BTS with this
release.

Once this is done I'll gladly switch to working on 0.9.x. Here are
some points you could have missed:

 - in addition to the "buildbot" and "buildbot-worker" Python packages
upstream now ships its web interface in the separate package called
"buildbot-www" that is built into standard Python module with nodejs
and friends;
 - "buildbot-www" also has modular architecture and provides some
plugins out of the box;
 - additional plugins can be developed using package called
"buildbot-pkg" that is available in the upstream repository as well.

As for your points: I agree on every point though this won't be too
easy. Perhaps we should start by providing binary packages for master
and worker in experimental and then grow the number of packages.

-- 
Best regards, Andrii Senkovych

2016-11-14 15:14 GMT+02:00 Paolo Greppi :
> Hi and thanks for the suggestion.
>
> While I wait for my *-guest account to join collab-main and somebody to
> pick up the RFP for RAMLfications I have noticed that:
>
> - upstream has renamed the buildslave component "worker", also on pypi:
> https://pypi.python.org/pypi/buildbot-worker
>
> - the upstream git repo https://github.com/buildbot/buildbot has the
> code for both the master component (which matches the Debian buildbot
> package) and the worker component (which matches the Debian
> buildbot-slave package)
>
> therefore I **think** that:
>
> - we should rename the buildbot-slave package to buildbot-worker
>
> - we should generate both buildbot and buildbot-worker binary packages
> from the same source package "buildbot"
>
> - we can forget about the tarballs on pypi; debian/watch should point to
> the https://github.com/buildbot/buildbot/tags
>
> -  the packaging for 0.9.1 should start from a fresh git repo; reusing
> https://github.com/buildbot/debian-buildbot and
> https://github.com/buildbot/debian-buildbot-slave is possible by
> manually transferring the files / patches, but the upstream branch will
> be radically different
>
> what do you think ?
>
> Paolo
>
> On 10/11/2016 13:54, Andrii Senkovych wrote:
>> Hi Paolo,
>>
>> I think collab-maint is the right place for it. Also, what did you use
>> as an upstream source? Was it pip URL or the repo on github? I think
>> we should move to the github repo because buildbot-www package is
>> already a build artifact produced by build procedures from github
>> repo. That's where nodejs and friends come in. Granted, buildbot as a
>> standalone pip package does not need nodejs to be built.
>>
>> Info on collab-maint and collaborative maintenance of the package:
>> https://wiki.debian.org/Alioth/Git

Bug#844480: notmuch-emacs-mua not available

[David Bremner]

Vagrant Cascadian  writes:

> Package: notmuch-emacs
> Version: 0.23.1-1
> Severity: wishlist
>
> The notmuch-emacs-mua man page is shipped in "notmuch" but the actual
> notmuch-emacs-mua is not shipped in any package, as far as I can tell.
>
> I haven't yet used notmuch-emacs-mua, but it seems like it might be
> useful, if for no other purpose than making it simpler to use reportbug
> to file more notmuch related bugs.
>
> At a quick glance, the biggest dependency notmuch-emacs-mua relies on is
> bash.
>
>

Hi Vagrant;

Yes, we've got a little polishing to do, and plan to install
notmuch-emacs-mua properly as of 0.24 upstream.

d

Bug#844420: FTBFS: tests fail on hosts without network access

[Aurelien Jarno]

On 2016-11-16 09:48, Ximin Luo wrote:
> Aurelien Jarno:
> > On 2016-11-15 16:00, Ximin Luo wrote:
> >> Package: glibc
> >> Version: 2.24-5
> >> Severity: important
> >> Tags: upstream patch
> >> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826
> >>
> >> Dear Maintainer,
> >>
> >> posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
> >> tests.reproducible-builds.org:
> >>
> >> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz
> >>
> >> The attached patch should fix this; I gave a more detailed description in 
> >> the upstream bug report.
> > 
> > Hum, I am not sure it is the correct way to fix that. I think that
> > libnss_files should be able to resolve entries from /etc/hosts when the
> > query is relative, but also when it is fully qualified. This is how
> > libnss_dns behaves.
> > 
> 
> Looks like I was wrong before about getaddrinfo bypassing /etc/hosts, and it 
> does indeed look at /etc/hosts.
> 
> $ sudo -u sbuild getent hosts localhost
> 127.0.0.1   profitbricks-build17-amd64.debian.net 
> profitbricks-build17-amd64 localhost
> $ sudo -u sbuild getent hosts localhost.
> # no results
> 
> However if you change "localhost" in /etc/hosts to "localhost." then the 
> above results would be reversed.
> 
> What do you think the full behaviour should be?

I think that it should returns 127.0.0.1 for both 'localhost' and
'localhost.'

> > Also note that technically the glibc doesn't require network access,
> > just a DNS server able to resolve 'localhost.'
> > 
> 
> So how do you want to fix this? glibc doesn't currently build-depend on a 
> name server, and I assume you wouldn't want to do that. Can you give me some 
> hints on what to patch, to fix libnss_files?

My point about that, is that a package should build without network
access. Now I am not sure it actually means without even a nameserver.

Anyway I don't know that part of the code a lot, but the fix has
probably to be done in nss/nss_files/files-hosts.c.

Aurelien

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

Bug#844375: mu4e: can no longer store org-mode links

[Norbert Preining]

> Installed 0.9.17-1 and my problem has gone away.

Thanks for the confirmation!

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#840039: ITA: httpbin -- HTTP request and response service

[Luis Alfredo da Silva]

How can I proceed with this package, it belongs to a team

Bug#844560: check for config file existence is wrong

[Mattia Rizzolo]

On Wed, 16 Nov 2016, 10:36 p.m. Ian Jackson, <
ijack...@chiark.greenend.org.uk> wrote:

> Package: pbuilder
> Version: 0.226.1
>
> zealot:~> pbuilder dumpconfig --configfile /dev/null
> E: Config file /dev/null does not exist
> zealot:~>
>
> If it just tried to source it, rather than (presumably) pre-checking
> it with "test", it would say something like this:
>


It does a regular
if [ -f "$RCFILE" ]; then
. "$RCFILE"
else
echo "W: $RCFILE does not exist" >&2
fi

Which fails for non-regular files like /dev/null is.

zealot:~> bash -c '. /dev/enoent'
> bash: /dev/enoent: No such file or directory
> zealot:~>
>
> I think that would probably be preferable...
>

Do you mean that probably the message should takr into account that a
reason for failure of that test could be something different than enonet?

If that the problem it could prably be solved imho in a nicer way by
nesting another if in the else branch to check for simple existence (by [
-e $file ]) and print a proper message if the file exists but it's not
regular, and keep the current message only for the real enoent case.

Bug#844569: [Python-modules-team] Bug#844569: ipython-notebook -> jupyter ?

[Sandro Tosi]

On Wed, Nov 16, 2016 at 6:23 PM, Yaroslav Halchenko
 wrote:
> Unfortunately it seems
> that python notebook support for jupyter is simply not present?!  (thus marked
> at normal severity)

i'd say we have to way for
https://ftp-master.debian.org/new/jupyter-notebook_4.2.3-1.html

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#843784: #844478 - 7u111 seems to break Juniper VPN via JavaWS, may break all the latter

[Shaddy Baddah]

Hi,

I raised https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844478
describing the same problem as this bug. That one can probably be
closed.

On Thu, 10 Nov 2016 20:10:40 -0200 Tiago Daitx 
 wrote:

> Hi Alain,
>
> Please try out the deb files @
> https://keybase.pub/tdaitx/icedtea-web-1.6.2/ and let me know if they
> do solve the problem.
>
> If they don't, I would need you to point me to a public online applet
> that was known to work on the older openjdk version and is now failing
> on the new one, otherwise I'm stuck as I have no way to reproduce the
> issue.

If I have time, I'll try this too. See if it helps.

--
Regards,
Shaddy

Bug#844339: [Pkg-libvirt-maintainers] Bug#844339: patch for sid

[Mauricio Faria de Oliveira]

On 11/16/2016 05:42 PM, Guido Günther wrote:

No, you need to use getent or similar since the user/group might not be in
/etc/{passwd,group} (e.g. ldap).


Oh, right.
Thanks for this; getent turned out to be a very good option;
no group changes required.


--
Mauricio Faria de Oliveira
IBM Linux Technology Center

Bug#844478: duplicate of #843784, please close *was 7u111 seems to break Juniper VPN via JavaWS, may break all the latter*

[Shaddy Baddah]

Hi,

My bug navigating skills are not up to scratch, and after raising this
bug I've noticed that 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843784

appears to describe the same bug.

You can safely close.

--
Regards,
Shaddy

Bug#844549: network-console broken: no screen to be resumed matching sh

[Martin Michlmayr]

* Samuel Thibault  [2016-11-16 23:03]:
> But AIUI the intent was to have screen in ssh connections too.

I'm not sure what the intent was.  I assume you're right because Roger
didn't exclude screen from the network-console images.  Personally,
I'm not sure I see the point of screen in that case because you can
always open a second SSH connection and open a terminal, but I don't
have strong feelings either way if there's an advantage of having
screen in such cases.

> I'm also thinking that we perhaps want to add -x when resuming a
> session, so that somebody can connect trough ssh several times ?

Yes because right now I get this when I open a 2nd connection:

debug1: Sending env LC_COLLATE = C
There is a screen on:
1356.network(11/16/16 23:24:12) (Attached)

Apart from this, the patch works for me.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#844568: jack: complains about missing dependency and dies

[Giacomo Boffi]

Package: jack
Version: 3.1.1+cvs20050801-29.1
Severity: important

Dear Maintainer,

/usr/bin/jack imports * from jack_globals,
jack_globals imports eyeD3 from jack_init.
jack_init imports eyeD3 from eyeD3

at this point, an exception is raised because the API exposed
by the python-eyed3 has changed

1. the module is named eyed3 and not eyeD3
2. no eyeD3/eyed3 name is exported by eyed3

jack_init catches this exception, prints

Please install the eyeD3 module available from http://eyed3.nicfit.net/

calls sys.exit(1) and jack dies.

For the record, the module published at http://eyed3.nicfit.net is the module
distributed by debian.  It seems that jack needs an older version of the
eyed3 module.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages jack depends on:
ii  cdparanoia   3.10.2+debian-11
ii  lame 3.99.5+repack1-9+b1
ii  libc62.24-5
ii  libncursesw5 6.0+20160917-1
ii  libtinfo56.0+20160917-1
ii  python   2.7.11-2
ii  python-cddb  1.4-5.3
ii  python-eyed3 0.7.9-2
ii  python-pyvorbis  1.5-4
pn  python:any   

jack recommends no packages.

jack suggests no packages.

-- no debconf information

Bug#844569: ipython-notebook -> jupyter ?

[Yaroslav Halchenko]

Package: jupyter-core
Version: 4.2.0-2
Severity: normal

It might be that it is just the RTFM and that I was stuck using good old
ipython-notebook for too long...  but now that it is gone, I was expecting
jupyter package(s) to provide a replacement/transition.  Unfortunately it seems
that python notebook support for jupyter is simply not present?!  (thus marked
at normal severity)

I think I have installed all possibly relevant piece of jupyter:

$> dpkg -l *jupyter*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  jupyter-client 4.4.0-2  all  Jupyter protocol 
client APIs (tools)
ii  jupyter-core   4.2.0-2  all  Core common 
functionality of Jupyter projects (to
ii  jupyter-nbformat   4.1.0-2  all  Jupyter notebook 
format (tools)
ii  python-jupyter-client  4.4.0-2  all  Jupyter protocol 
client APIs (Python 2)
ii  python-jupyter-core4.2.0-2  all  Core common 
functionality of Jupyter projects for
ii  python3-jupyter-client 4.4.0-2  all  Jupyter protocol 
client APIs (Python 3)
ii  python3-jupyter-core   4.2.0-2  all  Core common 
functionality of Jupyter projects for

but still can't follow a basic instruction (e.g. from
http://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/execute.html)
to run

$> jupyter notebook
jupyter: 'notebook' is not a Jupyter command

am I missing something?


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

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

Versions of packages jupyter-core depends on:
ii  python3-jupyter-core  4.2.0-2
pn  python3:any   

jupyter-core recommends no packages.

jupyter-core suggests no packages.

-- no debconf information

Bug#844375: mu4e: can no longer store org-mode links

[Olaf Meeuwissen]

Norbert Preining writes:

>> A pre-release for 0.9.18 was made available 10 days ago ;-)
>
> Indeed, uploading in a second ... ;-)

Installed 0.9.17-1 and my problem has gone away.

Thanks!
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#821974: comgt: Build arch:all+arch:any but is missing build-{arch,indep} targets

[Andreas "Jimmy" Gredler]

On 11/11/2016 03:31 PM, Christoph Biedl wrote:
> Andreas "Jimmy" Gredler wrote...
> 
>> Thank you for the patch. I will review the package to see if I can
>> change it to dh-* in time or if it would be better to upload it with the
>> patch only.
> 
> Any progress on this? comgt has fallen out of testing in the meantime,
> I was glad if it could return in due course.

Hi,

The package is almost done but I'm also reviewing if the patches
mentioned in the other reports should be included or go to upstream.

Best,
Jimmy

Bug#844566: qemu-system-x86: ipv6 and dns is broken with netdev user

[Manuel Traut]

Hi,

i see the same effect with latest qemu from upstream.
The bugreport for upstream qemu is here:

https://bugs.launchpad.net/qemu/+bug/1642421

Regards,

  Manuel

Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2

[Adrian Bunk]

On Wed, Nov 16, 2016 at 11:05:13PM +0100, Stefan Fritsch wrote:
>...
> BTW, I am pretty sure that support for enhanced master secret and chacha20 
> will appear for openssl 1.0.2 before the release of stretch+1, if only 
> because 
> redhat needs it for its long support cycles. Back-porting that to stretch in 
> a 
> year or so in a stable-point-release would IMHO be the best option.

At least for ChaCha20 there are patches available for OpenSSL 1.0.2 that 
are already being used elsewhere.

> When 
> Apache httpd 2.4 came out, I was also quite disappointed that it could not be 
> included in squeeze, but mod_perl was not ready at the time and it would not 
> have made any sense to include an inofficial forward-port of mod_perl to 2.4 
> in 
> Debian. In the same way, I don't think it is a good idea to include lots of 
> patches for openssl 1.1, with little testing.
> 
> Cheers,
> Stefan

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#787734: libstdc++ breaks dynamic unloading

[Matthias Klose]

Control: tags -1 + moreinfo

Zefram, please could you update the issue with both using the gcc-6 packages
from unstable, and the gcc-7 packages from experimental?

Thanks, Matthias

Bug#844567: snapshot.debian.org: binary package information should state

[shirish शिरीष]

Package: snapshot.debian.org
Severity: normal

Dear Maintainer,
As can be seen in the picture, it doesn't tell/share which checksum is
being used/generated for comparison analysis. I had to run sha512sum -
384 - 256 - 224 - 1 to realize that the checksum is generated by
sha1sum. This information should be on the page itself. Please fix
this.


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

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

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#843454: ITP: docker-credential-helpers -- native store to keep Docker credentials, safe

[Felipe Sateler]

Hi Jason

On Sun, 6 Nov 2016 13:16:58 -0500 Jason Pleau  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jason Pleau 
>
> * Package name: docker-credential-helpers
>   Version : 0.3.0
>   Upstream Author : David Calavera 
> * URL : https://github.com/docker/docker-credential-helpers/
> * License : MIT
>   Programming Lang: Go / C
>   Description : native store to keep Docker credentials safe
>
> docker-credential-helpers provides a Linux executable to store Docker
> credentials. (It also has one for OSX and Windows, but those won't be
> built nor used in Debian).
>
> It is a dependency of an upcoming python package
> "dockerpy-creds", which is needed to update python-docker to its latest
> upstream version.


Have you done some work yet on this? If so, could you push it to
collab-maint so I can take a look?

Saludos

Bug#844515: [pkg-go] Bug#844515: packer: FTBFS on s390x (go install -v -p 1 died with signal 4)

[Daniel Stender]

... found it, #844258 (golang-go: go SIGILL on s390x)

True, zemlinsky (builder) is z10, zelenka (porterbox) z13.

Thanks for the hint,
DS

On 16.11.2016 20:05, Michael Hudson-Doyle wrote:
> This is the "golang for s390x only works on z196+, not z10" thing. The
> right fix is probably to not build golang on Debian, sadly.
> 
> On 17 November 2016 at 01:40, Daniel Stender 
> wrote:
> 
>> Package: packer
>> Version: 0.10.1+dfsg-1
>> Severity: serious
>> Justification: fails to build from source (but built successfully in the
>> past)
>>
>> Packer currently (recently 0.10.2+dfsg-1) fails to build on s390x:
>>
>> 
>>dh_auto_build -O--buildsystem=golang
>> cd obj-s390x-linux-gnu
>> go install -v -p 1
>> dh_auto_build: go install -v -p 1 died with signal 4
>> cd /<>/packer-0.10.2+dfsg
>> debian/rules:6: recipe for target 'build' failed
>> make: *** [build] Error 255
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>> 
>>
>> This is a regression from 0.10.1+dfsg-1 [1] (the build on 2016-10-16 [2]
>> failed
>> for a dependency reason which is solved in the meanwhile, see #841605 [3]).
>>
>> [1] https://buildd.debian.org/status/logs.php?pkg=packer=s390x
>>
>> [2] https://buildd.debian.org/status/fetch.php?pkg=packer;
>> arch=s390x=0.10.1%2Bdfsg-1=1476596269
>>
>> [3] https://bugs.debian.org/841605 (packer: FTBFS: src/
>> github.com/Azure/go-autorest/autorest/azure/token.go:140: undefined:
>> jwt.MapClaims)
>>
>> I can reproduce this locally in a qemu-chroot for Sbuild, however a test
>> build on
>> the zelenka porterbox succeeded:
>>
>> 
>> {...}
>> dpkg-deb: building package 'golang-github-mitchellh-packer-dev' in
>> '../golang-github-mitchellh-packer-dev_0.10.2+dfsg-1_all.deb'.
>> dpkg-deb: building package 'packer' in '../packer_0.10.2+dfsg-1_
>> s390x.deb'.
>>  dpkg-genbuildinfo
>> dpkg-genbuildinfo: warning: File::FcntlLock not available; using flock
>> which is not NFS-safe
>>  dpkg-genchanges  >../packer_0.10.2+dfsg-1_s390x.changes
>> dpkg-genchanges: info: including full source code in upload
>>  dpkg-source --after-build packer-0.10.2+dfsg
>> dpkg-buildpackage: info: full upload (original source is included)
>> (sid_s390x-dchroot)stender@zelenka:~/sandbox/packer-0.10.2+dfsg$
>> 
>>
>> Thanks for hints,
>> DS
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing'), (1, 'experimental')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.7.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 packer depends on:
>> ii  libc6  2.24-5
>>
>> Versions of packages packer recommends:
>> pn  docker.io  
>> ii  qemu   1:2.7+dfsg-3+b1
>>
>> Versions of packages packer suggests:
>> ii  ansible  2.1.1.0-1
>> pn  chef 
>>
>> -- no debconf information
>>
>> ___
>> Pkg-go-maintainers mailing list
>> pkg-go-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>>
> 


-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
LPIC-1 (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/

Bug#833283: Looks like it's happened again

[Nigel Horne]

Setting up syslog-ng-core (3.8.1-5) ...
Job for syslog-ng.service failed because the control process exited with 
error code.

See "systemctl status syslog-ng.service" and "journalctl -xe" for details.
invoke-rc.d: initscript syslog-ng, action "restart" failed.
● syslog-ng.service - System Logger Daemon
   Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled; 
vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Wed 
2016-11-16 17:15:37 EST; 12ms ago

 Docs: man:syslog-ng(8)
  Process: 20017 ExecStart=/usr/sbin/syslog-ng -F $SYSLOGNG_OPTS 
(code=exited, status=1/FAILURE)

 Main PID: 20017 (code=exited, status=1/FAILURE)
   Status: "Starting up... (Wed Nov 16 17:15:37 2016"

Nov 16 17:15:37 compaq systemd[1]: Failed to start System Logger Daemon.
Nov 16 17:15:37 compaq systemd[1]: syslog-ng.service: Unit entered 
failed state.
Nov 16 17:15:37 compaq systemd[1]: syslog-ng.service: Failed with result 
'e…de'.

Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package syslog-ng-core (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of syslog-ng-mod-redis:
 syslog-ng-mod-redis depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-redis (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of syslog-ng-mod-python:
 syslog-ng-mod-python depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-python (--configure):
 dependency problems - leaving unconfigured
Setting up gtk-update-icon-cache (3.22.3-2) ...
Setting up dpkg-dev (1.18.14) ...
Processing triggers for libc-bin (2.24-5) ...
dpkg: dependency problems prevent configuration of syslog-ng-mod-smtp:
 syslog-ng-mod-smtp depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-smtp (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of syslog-ng-mod-geoip:
 syslog-ng-mod-geoip depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-geoip (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of syslog-ng-mod-amqp:
 syslog-ng-mod-amqp depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-amqp (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.7.5-1) ...
dpkg: dependency problems prevent configuration of syslog-ng-mod-sql:
 syslog-ng-mod-sql depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-sql (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of syslog-ng-mod-json:
 syslog-ng-mod-json depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-json (--configure):
 dependency problems - leaving unconfigured
Setting up liblua5.1-0:amd64 (5.1.5-8.1+b2) ...
Setting up libnfs8:amd64 (1.11.0-2) ...
dpkg: dependency problems prevent configuration of syslog-ng:
 syslog-ng depends on syslog-ng-core (>= 3.8.1); however:
  Package syslog-ng-core is not configured yet.
 syslog-ng depends on syslog-ng-mod-sql; however:
  Package syslog-ng-mod-sql is not configured yet.
 syslog-ng depends on syslog-ng-mod-json; however:
  Package syslog-ng-mod-json is not configured yet.

dpkg: error processing package syslog-ng (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of syslog-ng-mod-stomp:
 syslog-ng-mod-stomp depends on syslog-ng-abi-3.8-0; however:
  Package syslog-ng-abi-3.8-0 is not installed.
  Package syslog-ng-core which provides syslog-ng-abi-3.8-0 is not 
configured yet.


dpkg: error processing package syslog-ng-mod-stomp (--configure):
 dependency problems - leaving unconfigured
Processing triggers for fontconfig (2.11.0-6.7) ...
dpkg: dependency problems prevent 

Bug#844564: Typo

[Chris Leick]

Hi,

in this translation file, I've marked a typo in the original template with 
FIXME.

Regards,
Chris

Bug#844476: apt: "apt autoremove --purge" reports different status (# of pkgs to upgrade) than "apt upgrade"

[Daniel Kahn Gillmor]

On Wed 2016-11-16 22:42:04 +0900, David Kalnischkies wrote:
> On Wed, Nov 16, 2016 at 02:40:59PM +0900, Daniel Kahn Gillmor wrote:
>> weird that it says "1 not upgraded" in response to "apt autoremove"
>> but "0 not upgraded" in response to "apt upgrade", eh?
>
> I smell Multi-Arch:same version-screw. The way we tell the resolver to
> not travel down this road is by reseting the candidate version – but
> that means it has no chance to know later on that that package was
> "upgradeable"…
>
> The usual resolver debug flags could be interesting:
> -o Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1
>
> Please also save your /var/lib/dpkg/status and /var/lib/apt/lists/
> somewhere as resolver things are highly state dependent and disappear
> usually within a few mirror updates.
>
> And as you have a new enough apt version, lets run apt with
> -o Dir::Log::solver=/tmp/edsp.log.xz
> also as that should collect all relevant information of system state for
> the resolver in one still big but at least highly compressed file
> I might want to have later if my guess from above is completely wrong.

which commands did you want me to run with these options?

  --dkg


signature.asc
Description: PGP signature

Bug#844566: qemu-system-x86: ipv6 and dns is broken with netdev user

[Manuel Traut]

Package: qemu-system-x86
Version: 1:2.7+dfsg-3+b1
Severity: important
Tags: ipv6

Dear Maintainer,

dhcp inside qemu returns an ipv6 address as dns-server. However this is not
working. If i replace it with the ipv4 address '10.0.0.2' dns is working
again. I would expect that the qemu emulated dhcp server responds either an
ipv4 configuration that is working or its dns server/forwarder listens on the
ipv6 address returned by the emulated dhcp server.

I started qemu with the following command:

qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device
virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0
-no-reboot -netdev user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588
-m 1024 -usb -nographic -smp 4

buildenv.img is a debian jessie amd64 installation.

Inside qemu the network is configured to use dhcp:

$ cat /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet dhcp

$ ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 52:54:00:12:34:56
  inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
  inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
  inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:10 errors:0 dropped:0 overruns:0 frame:0
  TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3215 (3.1 KiB)  TX bytes:3638 (3.5 KiB)

$ cat /etc/resolv.conf
nameserver fec0::3

$ arp google.de
google.de: Host name lookup failure

$ strace -f arp google.de
...
socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, 
"fec0::3", _addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)= 0
...

$ echo nameserver 10.0.0.2 > /etc/resolv.conf

$ arp google.de
google.de (216.58.208.35) -- no entry

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

Kernel: Linux 4.8.6 (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 qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20161027.b991c67-1
ii  libaio1 0.3.110-3
ii  libasound2  1.1.2-1
ii  libbluetooth3   5.43-1
ii  libbrlapi0.65.4-2
ii  libc6   2.24-5
ii  libcacard0  1:2.5.0-2
ii  libfdt1 1.4.0+dfsg-2
ii  libgcc1 1:6.2.0-13
ii  libglib2.0-02.50.2-1
ii  libgnutls30 3.5.6-4
ii  libjpeg62-turbo 1:1.5.1-2
ii  libncurses5 6.0+20160917-1
ii  libnettle6  3.3-1
ii  libpixman-1-0   0.34.0-1
ii  libpng16-16 1.6.26-1
ii  libpulse0   9.0-5
ii  libsasl2-2  2.1.27~72-g88d82a3+dfsg-1
ii  libsdl1.2debian 1.2.15+dfsg1-4
ii  libseccomp2 2.3.1-2
ii  libspice-server10.12.8-1
ii  libtinfo5   6.0+20160917-1
ii  libusb-1.0-02:1.0.21-1
ii  libusbredirparser1  0.7.1-1
ii  libuuid12.29-1
ii  libvdeplug2 2.3.2+r586-2+b1
ii  libx11-62:1.6.3-1
ii  libxen-4.8  4.8.0~rc5-1
ii  libxenstore3.0  4.8.0~rc5-1
ii  qemu-system-common  1:2.7+dfsg-3+b1
ii  seabios 1.9.3-2
ii  zlib1g  1:1.2.8.dfsg-2+b3

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.7+dfsg-3+b1

Versions of packages qemu-system-x86 suggests:
ii  kmod  23-1
ii  ovmf  0~20160813.de74668f-2
pn  qemu-block-extra  
pn  samba 
ii  sgabios   0.0~svn8-3
pn  vde2  

-- no debconf information

Bug#844565: RFS: node-husl/6.0.1+dfsg-1 [ITP]

[Ross Gammon]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "node-husl"

* Package name: node-husl
  Version : 6.0.1+dfsg-1
  Upstream Author : Alexei Boronine 
* URL : http://www.husl-colors.org/
* License : Expat
  Section : web

It builds these binary packages:

libjs-husl - Human-friendly HSL - Javascript
node-husl  - Human-friendly HSL - NodeJS

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

https://mentors.debian.net/package/node-husl


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

dget -x https://mentors.debian.net/debian/pool/main/n/node-husl/node-
husl_6.0.1+dfsg-1.dsc

Debian packaging can be found here:
https://anonscm.debian.org/cgit/pkg-javascript/node-husl.git

Changes since the last upload:

  * Initial release (Closes: #844230)


Regards,
Ross Gammon



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

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

Bug#844220: exim4: fails to install: user mail was not found

[Holger Levsen]

Hi,

On Tue, Nov 15, 2016 at 09:56:53PM +0100, Michael Biebl wrote:
> Am 15.11.2016 um 21:31 schrieb Michael Biebl:
> > On Tue, 15 Nov 2016 13:38:59 + Holger Levsen 
> > wrote:
> >> reassign 844220 usrmerge
> >> thanks
> >>
> >> Hi Marco,
> >>
> >> to summarize this bug: upon running these jenkins jobs with debootstrap
> >> from jessie-backports (which defaults to /usr-merged), several jobs
> >> testing installations in a sid chroot failed. The symptom was that there
> >> was no mail user when exim4 was configured…
> >>
> > 
> > I can't reproduce the problem.

thanks for trying and reporting here, Michael!

> > # getent passwd mail
> > mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
> > 
> > works just fine in a usr-merged system.
> > 
> > I also can't reproduce the installation failure of exim4 (tried in
> > chroot created with the new debootstrap).

how strange…

> > Fwiw, the new d-i alpha8 uses the new deboostrap as well and exim4 is
> > typically installed as part of the system installation.
> > 
> > I just tried a stretch alpha8 installation. Worked fine as well.
> > 
> > Can you attach the exim4 generated config file?
> > What does
> > # getent passwd mail
> > say in your jenkins build chroot?
> > 
> 
> I have to add, that I'm running sid on this particular system and I
> created the chroots with debootstrap from sid. Not sure if that makes a
> difference.

it should not, but oh well…

> Holger, can you specify how we can re-create the exact environment that
> is used on jenkins.d.n so we have a chance of reproducing the issue.

just debootstrap+pbuilder really…

sadly I dont have much time atm to try to reproduce manually, so if
noone else can I would suggest downgrading this bug to normal and
unreproducible and maybe I'll find the time to properly debug or the bug
comes back when /usr-merged comes back as a default…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844564: congress: [INTL:de] Initial German debconf translation

[Chris Leick]

Package: congress
Version: 4.0.0+dfsg1-2
Severity: wishlist
Tags: l10n patch


Hi,

please find attached the updated german debconf translation of congress.

Kind regards,
Chris

de.po.gz
Description: application/gzip

Bug#844397: Please add option to gbp-dch to create a signed tag for the --commit result

[Michael Stapelberg]

On Tue, Nov 15, 2016 at 12:48 PM, Guido Günther  wrote:

> Hi Michael,
> On Tue, Nov 15, 2016 at 09:54:02AM +0100, Michael Stapelberg wrote:
> > Package: git-buildpackage
> > Version: 0.8.6
> > Severity: wishlist
> >
> > gbp-dch -R --commit is very convenient in that it not only creates the
> > changelog entry but also commits it to git. The next step, which I
> > currently need to do manually, is to create a signed tag, e.g.:
> >
> >   git tag -s -m "upload 1.0-2 to unstable" debian/1.0-2
>
> You can already do that with "gbp buildpackge --git-tag-only" but …
>

Thanks for the hint! That indeed works as expected.


>
> >
> > It would be nice if gbp-dch had a --tag option, which would do this
> > automatically for me :).
>
> … it's perfectly o.k. to have "gbp dch" create the same tags as well.
>
> Given some other work I have to do for stretch this is currently quiet
> low on the priority list though.
>
> Cheers,
>  -- Guido
>



-- 
Best regards,
Michael

Bug#844254: Easy fix

[Hilko Bengen]

Control: tag -1 patch

The problem is that the configure script is looking for the wrong symbol
in libssl. Something like this

-   AC_CHECK_LIB(ssl, SSL_library_init, [
+   AC_CHECK_LIB(ssl, SSL_new, [

causes the build to work again.

Looking for SSL_library_init seems to be a somewhat common pattern, by
the way.

Cheers,
-Hilko

Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2

[Stefan Fritsch]

Hi,

[I have trimmed the cc list a bit]

On Wednesday, 16 November 2016 20:36:49 CET Kurt Roeckx wrote:
> On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > Stefan Fritsch  writes:
> > > I must admit that I did not think of php when doing that change, sorry.
> > > 
> > > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and
> > > there have been some indications that shibboleth won't be switching to
> > > openssl 1.1 for stretch. See
> > > https://lists.debian.org/debian-release/2016/11/msg00024.html> 
> > It turns out that Shibboleth will be okay if Apache goes to 1.1.  The
> > Shibboleth code that goes into Apache is isolated from the OpenSSL use
> > inside Shibboleth, so we can keep building Shibboleth against 1.0 and
> > Apache can go to 1.1 and all the pieces are happy.  (The OpenSSL work is
> > done in a separate daemon, shibd, that the Apache module talks to.)
> 
> So I looked at apache2-dev to see why it depends on libssl-dev.
> The only thing I can find is that mod_ssl_openssl.h provides some
> hooks, and you actually get SSL_CTX * and SSL * in there. But
> nothing in Debian seems to include that file.

That header was created for mod_ssl_ct which provides support for certificate 
transparency. It's quite new and likely that nothing else uses the header. It 
would probably be acceptable to remove the dependency in apache2-dev on 
libssl-dev and add a caveat to the README.Debian. I could also not install the 
header, or put it into a separate new package that depends on libssl-dev. 

That would be one alternative. Another would be to switch apache2 to openssl 
1.1. I have explained why I don't want to  this. But it's not impossible. The 
release team has announced that they will decide soon if they want the 
transition to go ahead or not. I will reconsider depending on what they write.

BTW, I am pretty sure that support for enhanced master secret and chacha20 
will appear for openssl 1.0.2 before the release of stretch+1, if only because 
redhat needs it for its long support cycles. Back-porting that to stretch in a 
year or so in a stable-point-release would IMHO be the best option. When 
Apache httpd 2.4 came out, I was also quite disappointed that it could not be 
included in squeeze, but mod_perl was not ready at the time and it would not 
have made any sense to include an inofficial forward-port of mod_perl to 2.4 in 
Debian. In the same way, I don't think it is a good idea to include lots of 
patches for openssl 1.1, with little testing.

Cheers,
Stefan

Bug#844549: network-console broken: no screen to be resumed matching sh

[Samuel Thibault]

Hello,

Martin Michlmayr, on Wed 16 Nov 2016 12:07:07 -0800, wrote:
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.

But AIUI the intent was to have screen in ssh connections too.

We could have the case where d-i is first started with the serial
console, running through screen, and enable the network console, which
we'd also want to run through screen.

I'd thus say that we rather want the attached changes, to have one
screen session per terminal type.

I'm also thinking that we perhaps want to add -x when resuming a
session, so that somebody can connect trough ssh several times ?

Samuel
diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..2549e29 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -14,11 +14,11 @@ else
if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
-   SCREEN_OPT=""
+   SCREEN_OPT="-S $TERM_TYPE"
[ -n "$TERM_UTF8" ] &&
SCREEN_OPT="$SCREEN_OPT -U"
-   [ -d /var/run/screen/S-root -a -e /var/run/screen/S-root/* ] &&
-   SCREEN_OPT="-r" # If GNU/screen is already 
started, just resume it
+   [ -d /var/run/screen/S-root -a -e 
/var/run/screen/S-root/*.$TERM_TYPE ] &&
+   SCREEN_OPT="-r $TERM_TYPE"  # If GNU/screen 
is already started, just resume it
set +e
$screen_bin $SCREEN_OPT sh -c 'printf "\033k%s\033\\" installer 
; /lib/debian-installer/menu'
EXIT=$?

Bug#844563: ITP: maxima-sage -- Computer algebra system for SageMath

[Tobias Hansen]

Package: wnpp
Owner: Tobias Hansen 
Severity: wishlist

* Package name: maxima-sage
  Version : 5.35.1
  Upstream Author : James Amundson 
* URL : http://maxima.sourceforge.net/
* License : GPL
  Programming Lang: Common Lisp
  Description : Computer algebra system for SageMath

 Maxima is a fully symbolic computation program.  It is full featured
 doing symbolic manipulation of polynomials, matrices, rational
 functions, integration, Todd-coxeter methods for finite group
 analysis, graphing, multiple precision floating point computation.
 It has a symbolic source level debugger for maxima code.  Maxima is
 based on the original Macsyma developed at MIT in the 1970s.  It is
 quite reliable, and has good garbage collection, and no memory leaks.
 It comes with hundreds of self tests.
 .
 The maxima-sage packages are meant to be used together with SageMath.
 They contain the version of Maxima that works together with the
 SageMath version in Debian and use ECL instead of GCL as Lisp compiler.
 To use Maxima by itself, the more complete and up-to-date maxima
 package is recommended.

There are several reasons why SageMath cannot use Debian's maxima
package at the moment and this second package maxima-sage is needed:

 1. Version mismatch

 SageMath 7.4 uses Maxima 5.35.1, while the maxima package in Debian is
constantly updated to follow new upstream versions. Currently the
version of maxima in Debian is 5.38.1. It is not trivial to update
SageMath to a new Maxima version, as this ticket for the Maxima 5.38.1
update shows:

 https://trac.sagemath.org/ticket/18920

 2. Lisp compiler

 The maxima package in Debian uses only GCL as common lisp compiler,
while SageMath uses ECL. SageMath cannot use the GCL version, since the
preferred interface to Maxima is via an ECL fasl library. The
possibility of adding an ECL version of Maxima to the maxima package was
discussed in

 https://bugs.debian.org/779804

This maxima-sage package is coinstallable with the maxima packages in
Debian.

Bug#487300: debconf: preseeding values for questions with template of other name (from dbconfig-common)

[Vaclav Ovsik]

Package: debconf
Version: 1.5.59
Followup-For: Bug #487300

I work on scripts for unattended installing OpenStack instance for
testing (work-in-progress) and I use debconf preseeding using
debconf-set-selections.
https://anonscm.debian.org/cgit/users/zito-guest/setup-openstack.git/
Packages use dbconfig-common for database setup. The first such package
in sequence is keystone in script os-controller-install.
Before installing keystone I feed debconf-set-selections with e.g.

  keystonekeystone/database-type  select  mysql

this creates following record in config.dat file

  Name: keystone/database-type
  Template: keystone/database-type
  Value: mysql
  Owners: keystone
  Flags: seen

and record in templates.dat file:

  Name: keystone/database-type
  Description: Dummy template
  Extended_description: This is a fake template used to pre-seed the debconf 
database. If you are seeing this, something is probably wrong.
  Type: select
  Owners: keystone/database-type


After installing keystone, records are transformed into:

config.dat contains:

  Name: keystone/database-type
  Template: dbconfig-common/database-type
  Value: mysql
  Owners: keystone
  Flags: seen
  Variables:
   database_types = sqlite3, mysql
   dbvendor = MySQL
   pkg = keystone
  
templates.dat contains:

  Name: dbconfig-common/database-type
  Choices: ${database_types}
  Description: Database type to be used by ${pkg}:
  ...
  Type: select 
  Owners: dbconfig-common/database-type, keystone/database-type 


So far so good, But because some values are removed from debconf database by
postinst maintainer script (e.g. password of database admin) I need to preseed
some values with keystone installed again so I can do unattended package
removal. This second preseeding doesn't affect record in config.dat
(because value is the same), but debconf-set-selections creates one more
time "Dummy template". After purging the package keystone, this dummy
value left in templates db.

This dummy template (orphaned) now breaks the next try to preseed values
again, because debconf-set-selections fails:

  error: Cannot find a question for keystone/database-type

Dummy template must be removed, to preseed values again.
Hope this helps a bit.
Cheers
-- 
Zito

Bug#844562: ITP: sagemath -- SageMath: Open Source Mathematical Software

[Tobias Hansen]

Package: wnpp
Owner: Tobias Hansen 
Severity: wishlist

* Package name: sagemath
  Version : 7.4
  Upstream Author : William Stein 
* URL : http://www.sagemath.org/
* License : GPL
  Programming Lang: Python, C, C++, Cython
  Description : SageMath: Open Source Mathematical Software

SageMath is a free open-source mathematics software system licensed
under the GPL. It builds on top of many existing open-source packages:
NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more.
Access their combined power through a common, Python-based language or
directly via interfaces or wrappers.

Mission: Creating a viable free open source alternative to Magma, Maple,
Mathematica and Matlab.

Packaging SageMath for Debian is a large project and we are on a tight
schedule, trying to upload it in time for stretch. We still could need
help with fixing RC bugs of dependencies of SageMath (to make sure
everything migrates to testing before the soft freeze). Also, some of
the remaining components we are packaging have javascript dependencies
that need to be packaged. If you want to help out with one of these or
other things, see the list of tasks on [1] or drop by on our mailing
list [2].

[1] https://wiki.debian.org/DebianScience/Sage
[2] https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath

Bug#820044: Cloning a blocking bug overwrites rather than appending to the blocked list

[Don Armstrong]

On Wed, 16 Nov 2016, James Clarke wrote:
> Please find attached a patch which should fix this. This now matches the
> call in set_merge which adds to the block list.

Thanks James! (This is exactly the patch which I just worked on.)


-- 
Don Armstrong  https://www.donarmstrong.com

To steal ideas from one person is plagiarism; to steal from many is
research.
 -- Steven Wright

Bug#844561: claws-mail-python-plugin: Missing dependency on python-gtk2

[Barry Warsaw]

Package: claws-mail-python-plugin
Version: 3.14.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I was debugging a failure of the Claws Mail Python plugin on Ubuntu
17.04.  See LP: #1640217

https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/1640217

What I found out through gdb tracing the loading of the plugin is that
it tries to "import gtk", which means it imports that package's
__init__.py.  However by default, claws-mail-python-plugin doesn't
depend on python-gtk2 (which is the package that owns that file), so
the import fails, and thus the loading of the plugin fails.

Given the reverse-depends on python-gtk2, I might not be normally
obvious that the dependency is missing, but it may not already be
installed on a fresh or minimal installation.

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlgs060ACgkQEm61Y6dL
Br/kzQ//URKh0ioNTc7TvgQ1fvjR3FKHkbDHmCCzk9V89qQZrdyHfYK81hRwX2Qx
WyCn0Nv/u1ow/YQt2zCZgKpeaoFCA5i0AwfpKbzeM8Njp69AGdsHKePZk0hqSwf2
Ih63STMoHcE9xexi8zhQPnyXgnoPK9T9z0IRJ25qVBwDAK8pSWCJtfhu6whN7Zev
XchqmTQJuuupaDRzb9LLtLuReO26xJwav4PB4qYhA1EJG0IZlaFr7fTZGAwxDUe9
ODIn+t3hFprMMLBxOw4i19ftvAyIWt3DMnJ3tDb0eN7SZVkobxoZdPltN8Sgnv22
dzAdob9Wua2f2sgV8XodYsE7oOVb4wRT8t4TNgavppaPSGsQg/Foh6y1TTBjVhYk
dBfw9iSo6Ui0iTxT/rwYbX7Mcgl4q8sv5e5zu1Q14rifnJs5K8uOqS2oMKOzXkki
8/vkNi2nZk1m1pmRMe3XQNYT7keQ5R/ufJh7BWXhkHWh6m/fWLwAzISxAN1AhqtE
jtKHAwSiRkh56ioElLW5eto6GKLCvKoux1VAISlgtdhuKySYcx9+D64l2/ecOQU5
a4WZ6tDcG01puVdwUKU/SovtXMKlJv9CWTUjFTrW5YAyt6f86jwZZrYlXcdiKkyg
d/4HDq7YJmeeW5poWsb0prbZa4whHie6JfMPAaiKzIXBHG9Txhs=
=a/V1
-END PGP SIGNATURE-

Bug#830399: Info received (Bug#830399: Info received (python-jedi: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13))

[PICCA Frederic-Emmanuel]

looking at the upstream repository,it seems that there is plenty of py3 fixes 
since the last release 0.9.0

so maybe it would be better to not run the unit test for the python3 now.

Another solution is to take the HEAD of python-jedi, as explain by the 
upstream[1] and see if it pass the unit tests

What is your opinion ?

https://github.com/davidhalter/jedi/issues/808

Bug#844549: network-console broken: no screen to be resumed matching sh

[Martin Michlmayr]

* Ben Hutchings  [2016-11-16 21:15]:
> >     rm -f $font
> > -   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> > +   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> 
> This makes the comparison with 'serial' redundant; the condition will
> be equivalent to:
> 
> [ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]
> 
> Is that really what we want?

Oh, good point.

I think that's what we want but I'm not sure.  Maybe Roger can
comment.  In his old code, there was also a $NETBOOT_SCREEN variable
which afaict wasn't set set anywhere.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#822575: linux-4.1: UEFI root-fb vs. cirrusfb

[Ben Hutchings]

On Tue, 2016-11-15 at 17:10 +0100, Philipp Hahn wrote:
> Hello David,
> 
> Am 15.11.2016 um 15:57 schrieb David Herrmann:
> > > > On Fri, Oct 28, 2016 at 2:24 PM, Philipp Hahn  
> > > > wrote:
> > > while experimenting with UEFI and secure-boot I stumbled into the issue
> > > "cirrusdrmfb broken with simplefb" associated with your name:
> > > 
> > > 
> > > I'm using a Debian based linux-4.1.38 kernel, which has
> > > > # zgrep -E 'CONFIG_X86_SYSFB|CONFIG_FB_SIMPLE' /boot/config-`uname -r`
> > > > CONFIG_X86_SYSFB=y
> > > > CONFIG_FB_SIMPLE=y
> > > 
> > > I found that SUSE bug
> > > > > > , where Takashi 
> > > > > > Iwai
> > > finally disabled those options.
> > > 
> > > I also checked Debians latest linux-4.7 kernel in Debian-sid, which
> > > still has this setting. So my questions are:
> > > 1, should Debian disable those options for x86?
> > > 2. What would Debian loose?
> > > 3. or is that issue fixed otherwise in newer kernels?
> > 
> > Right now CONFIG_X86_SYSFB should remain disabled. Once the SimpleDRM
> > driver is upstream, there will be infrastructure to do the hw
> > handover. Right now, it breaks if you hand over hw from one driver to
> > another.
> 
> @David: Thank you for your feedback.
> 
> @Debian: Please disable CONFIG_X86_SYSFB in Debian for all next builds -
> maybe except arch=arm.

Thanks, I've committed this change for the next uploads to unstable and
stable.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.



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

Bug#844560: check for config file existence is wrong

[Ian Jackson]

Package: pbuilder
Version: 0.226.1

zealot:~> pbuilder dumpconfig --configfile /dev/null
E: Config file /dev/null does not exist
zealot:~>

If it just tried to source it, rather than (presumably) pre-checking
it with "test", it would say something like this:

zealot:~> bash -c '. /dev/enoent'
bash: /dev/enoent: No such file or directory
zealot:~>

I think that would probably be preferable...

Thanks,
Ian.

Bug#838858: firmware-amd-graphics: missing SI/CI smc firmware files

[Jan Riechers]

Package: firmware-amd-graphics
Version: 20160824-1
Followup-For: Bug #838858

Dear Maintainer,

Missing firmwares issue also occurs on stretch/testing, after upgrade.



-- 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/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)

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#830399: Info received (python-jedi: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13)

[PICCA Frederic-Emmanuel]

I just apply this patch and the import test PASS.

I took only a part of the upstream patch

but now I get this 

I: pybuild base:184: cd /<>/.pybuild/pythonX.Y_3.5/build; 
python3.5 -m pytest test
= test session starts ==
platform linux -- Python 3.5.2+, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
rootdir: /<>, inifile: pytest.ini
collected 257 items / 1 errors

 ERRORS 
 ERROR collecting .pybuild/pythonX.Y_3.5/build/test/test_integration.py 
test/conftest.py:59: in pytest_generate_tests
cases = list(run.collect_dir_tests(base_dir, test_files))
test/run.py:293: in collect_dir_tests
source = open(path).read()
/usr/lib/python3.5/encodings/ascii.py:26: in decode
return codecs.ascii_decode(input, self.errors)[0]
E   UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 331: 
ordinal not in range(128)
!!! Interrupted: 1 errors during collection 
=== 1 error in 4.38 seconds Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 python-jedi (0.9.0-1) unstable; urgency=medium
 .
   * New upstream release
   * debian/watch: use pypi.debian.net redirector
Author: Piotr Ożarowski 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2016-11-16

--- python-jedi-0.9.0.orig/test/test_integration_import.py
+++ python-jedi-0.9.0/test/test_integration_import.py
@@ -18,22 +18,22 @@ def test_goto_definition_on_import():
 def test_complete_on_empty_import():
 assert Script("from datetime import").completions()[0].name == 'import'
 # should just list the files in the directory
-assert 10 < len(Script("from .", path='').completions()) < 30
+assert 10 < len(Script("from .", path='whatever.py').completions()) < 30
 
 # Global import
-assert len(Script("from . import", 1, 5, '').completions()) > 30
+assert len(Script("from . import", 1, 5, 'whatever.py').completions()) > 30
 # relative import
-assert 10 < len(Script("from . import", 1, 6, '').completions()) < 30
+assert 10 < len(Script("from . import", 1, 6, 'whatever.py').completions()) < 30
 
 # Global import
-assert len(Script("from . import classes", 1, 5, '').completions()) > 30
+assert len(Script("from . import classes", 1, 5, 'whatever.py').completions()) > 30
 # relative import
-assert 10 < len(Script("from . import classes", 1, 6, '').completions()) < 30
+assert 10 < len(Script("from . import classes", 1, 6, 'whatever.py').completions()) < 30
 
 wanted = set(['ImportError', 'import', 'ImportWarning'])
 assert set([c.name for c in Script("import").completions()]) == wanted
 if not is_py26:  # python 2.6 doesn't always come with a library `import*`.
-assert len(Script("import import", path='').completions()) > 0
+assert len(Script("import import", path='whatever.py').completions()) > 0
 
 # 111
 assert Script("from datetime import").completions()[0].name == 'import'

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Vincent Danjean]

Le 14/11/2016 à 10:38, Christoph Berg a écrit :
> Re: Helmut Grohne 2016-11-06 <20161106131613.7tukuhsijohhs...@alf.mars>
>> | Unknown file type: '2d3e9992648837b6a4a8a5b819e6da8e 4791 devel optional 
>> binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo', assuming 
>> source format...
> 
> There's a workaround which is helpfully also pointed out by reprepro
> itself. Append the following to conf/incoming:
> 
> Permit: unused_files
> Cleanup: unused_files

This workaround only works with the "processincoming" command.
If you use the "include" command, the conf/incoming file is not used at all...

> Of course a proper fix would be very welcome :)

Yes ;-)

  Regards,
Vincent

> Christoph
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#843397: python-rdflib-jsonld: Requires python-rdflib 4.2.1 to work properly with schema.org contexts

[Andreas Tille]

On Wed, Nov 16, 2016 at 04:50:56PM +0100, chrysn wrote:
> On Wed, Nov 16, 2016 at 04:45:52PM +0100, Andreas Tille wrote:
> > Yes - if you tell me exactly what Git URL to clone and what branch is
> > the Debian branch to build.
> 
> git clone git+ssh://git.debian.org/git/collab-maint/rdflib.git -b debian
> 
> sorry, I thought you already had a current checkout.

I get lots of

...
dpkg-source: error: cannot represent change to 
build/src/test/w3c/nt/literal_ascii_boundaries.nt: binary file contents changed
dpkg-source: error: add build/src/test/w3c/nt/literal_ascii_boundaries.nt in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: warning: newly created empty file 
'build/src/test/w3c/nt/nt-syntax-file-01.nt' will not be represented in diff
dpkg-source: error: cannot represent change to 
build/src/test/w3c/trig/LITERAL1_all_controls.trig: binary file contents changed
dpkg-source: error: add build/src/test/w3c/trig/LITERAL1_all_controls.trig in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
build/src/test/w3c/trig/LITERAL1_ascii_boundaries.trig: binary file contents 
changed
dpkg-source: error: add build/src/test/w3c/trig/LITERAL1_ascii_boundaries.trig 
in debian/source/include-binaries if you want to store the modified binary in 
the debian tarball
dpkg-source: error: cannot represent change to 
build/src/test/w3c/trig/LITERAL2_ascii_boundaries.trig: binary file contents 
changed
dpkg-source: error: add build/src/test/w3c/trig/LITERAL2_ascii_boundaries.trig 
in debian/source/include-binaries if you want to store the modified binary in 
the debian tarball
dpkg-source: error: cannot represent change to 
build/src/test/w3c/trig/LITERAL_LONG1_ascii_boundaries.trig: binary file 
contents changed
dpkg-source: error: add 
build/src/test/w3c/trig/LITERAL_LONG1_ascii_boundaries.trig in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
build/src/test/w3c/trig/LITERAL_LONG2_ascii_boundaries.trig: binary file 
contents changed
dpkg-source: error: add 
build/src/test/w3c/trig/LITERAL_LONG2_ascii_boundaries.trig in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: warning: file 
rdflib-4.2.1/build/src/test/w3c/trig/blankNodePropertyList_as_object.trig has 
no final newline (either original or modified version)
dpkg-source: warning: file 
rdflib-4.2.1/build/src/test/w3c/trig/collection_object.trig has no final 
newline (either original or modified version)
dpkg-source: warning: file 
rdflib-4.2.1/build/src/test/w3c/trig/literal_with_CARRIAGE_RETURN.trig has no 
final newline (either original or modified version)
dpkg-source: warning: file 
rdflib-4.2.1/build/src/test/w3c/trig/literal_with_LINE_FEED.trig has no final 
newline (either original or modified version)
...

messages when trying to build :-(

Kind regards

Andreas.


-- 
http://fam-tille.de

Bug#835675: [nmu] debdiff

[intrigeri]

hi,

u:
> built and tested the binary. Looks good!

Thanks! I've verified that this does fix the FTBFS, uploaded after
adding missing info to debian/changelog. Here is the corresponding
updated debdiff.

Cheers!
-- 
intrigeri

diff -Nru seahorse-nautilus-3.11.92/debian/changelog seahorse-nautilus-3.11.92/debian/changelog
--- seahorse-nautilus-3.11.92/debian/changelog	2014-09-15 21:35:21.0 +0200
+++ seahorse-nautilus-3.11.92/debian/changelog	2016-11-16 21:31:26.0 +0100
@@ -1,3 +1,13 @@
+seahorse-nautilus (3.11.92-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * gpg21.patch: new patch, fixes FTBFS by supporting GnuPG 2.1;
+Thanks to Adrian Bunk  for providing a patch.
+(Closes: #835675)
+  * Really remove add-correct-flag-for-reaping-the-progress-child.patch.
+
+ -- Ulrike Uhlig   Wed, 16 Nov 2016 21:31:26 +0100
+
 seahorse-nautilus (3.11.92-1) unstable; urgency=medium
 
   [ Clément Hermann (nodens) ]
diff -Nru seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
--- seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch	2014-03-23 00:20:50.0 +0100
+++ seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch	1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From: Stef Walter 
-Date: Fri, 16 Aug 2013 17:24:11 +
-Subject: Add correct flag for reaping the progress child
-Origin: https://git.gnome.org/browse/seahorse-nautilus/commit/?id=c41f07cf5785b2d755b85f20bf0546c6ce2ebb02
-
-This fixes the WARNING about ECHILD that comes from some versions
-of glib. The WARNING was removed in later versions of glib, but this
-is also a good fix.
-
-https://bugzilla.gnome.org/show_bug.cgi?id=697895

-diff --git a/tool/seahorse-tool-progress.c b/tool/seahorse-tool-progress.c
-index 613e82f..c039118 100644
 a/tool/seahorse-tool-progress.c
-+++ b/tool/seahorse-tool-progress.c
-@@ -217,7 +217,7 @@ seahorse_tool_progress_start (const gchar *title)
- argv[2] = (gchar *)title;
- argv[3] = NULL;
- 
--ret = g_spawn_async_with_pipes (NULL, argv, NULL, G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH,
-+ret = g_spawn_async_with_pipes (NULL, argv, NULL, G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD,
- NULL, NULL, _pid, _fd, NULL, NULL, );
- 
- if (!ret) {
---
-cgit v0.9.2
diff -Nru seahorse-nautilus-3.11.92/debian/patches/gpg21.patch seahorse-nautilus-3.11.92/debian/patches/gpg21.patch
--- seahorse-nautilus-3.11.92/debian/patches/gpg21.patch	1970-01-01 01:00:00.0 +0100
+++ seahorse-nautilus-3.11.92/debian/patches/gpg21.patch	2016-11-16 21:31:26.0 +0100
@@ -0,0 +1,29 @@
+Description: Accept GnuPG 2.1
+ This is the minimum change to fix the build,
+ upstream fixed this as part of a bigger change in 3.18
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/835675
+Forwarded: not-needed
+
+--- seahorse-nautilus-3.11.92.orig/configure.ac
 seahorse-nautilus-3.11.92/configure.ac
+@@ -57,7 +57,7 @@ AC_ARG_ENABLE(gpg-check,
+ 	DO_CHECK=$enableval, DO_CHECK=yes)
+ 
+ if test	"$DO_CHECK" = "yes"; then
+-	accepted_versions="1.2 1.4 2.0"
++	accepted_versions="1.2 1.4 2.0 2.1"
+ 	AC_PATH_PROGS(GNUPG, [gpg gpg2], no)
+ 	ok="no"
+ 	if test "$GNUPG" != "no"; then
+--- seahorse-nautilus-3.11.92.orig/configure
 seahorse-nautilus-3.11.92/configure
+@@ -14879,7 +14891,7 @@ fi
+ 
+ 
+ if test	"$DO_CHECK" = "yes"; then
+-	accepted_versions="1.2 1.4 2.0"
++	accepted_versions="1.2 1.4 2.0 2.1"
+ 	for ac_prog in gpg gpg2
+ do
+   # Extract the first word of "$ac_prog", so it can be a program name with args.
diff -Nru seahorse-nautilus-3.11.92/debian/patches/series seahorse-nautilus-3.11.92/debian/patches/series
--- seahorse-nautilus-3.11.92/debian/patches/series	2014-09-15 21:31:16.0 +0200
+++ seahorse-nautilus-3.11.92/debian/patches/series	2016-11-16 21:31:26.0 +0100
@@ -0,0 +1 @@
+gpg21.patch

Bug#834766: obsolete now

[Holger Levsen]

Hi,

#834524 is fixed in stretch by now and the fix for #834766 (available in 
piuparts.git branch develop and deployed on piuparts.d.o) is just a workaround, 
so I guess I can just revert this workaround again…

leaving this open as a reminder to do so.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#835675: [nmu] debdiff

[u]

Hi,

built and tested the binary. Looks good!

Cheers!
u.
diff -Nru seahorse-nautilus-3.11.92/debian/changelog 
seahorse-nautilus-3.11.92/debian/changelog
--- seahorse-nautilus-3.11.92/debian/changelog  2014-09-15 21:35:21.0 
+0200
+++ seahorse-nautilus-3.11.92/debian/changelog  2016-11-16 21:34:02.0 
+0100
@@ -1,3 +1,10 @@
+seahorse-nautilus (3.11.92-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Really remove add-correct-flag-for-reaping-the-progress-child.patch.
+
+ -- Ulrike Uhlig   Wed, 16 Nov 2016 21:31:26 +0100
+
 seahorse-nautilus (3.11.92-1) unstable; urgency=medium
 
   [ Clément Hermann (nodens) ]
diff -Nru 
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
 
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
--- 
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
  2014-03-23 00:20:50.0 +0100
+++ 
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
  1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From: Stef Walter 
-Date: Fri, 16 Aug 2013 17:24:11 +
-Subject: Add correct flag for reaping the progress child
-Origin: 
https://git.gnome.org/browse/seahorse-nautilus/commit/?id=c41f07cf5785b2d755b85f20bf0546c6ce2ebb02
-
-This fixes the WARNING about ECHILD that comes from some versions
-of glib. The WARNING was removed in later versions of glib, but this
-is also a good fix.
-
-https://bugzilla.gnome.org/show_bug.cgi?id=697895

-diff --git a/tool/seahorse-tool-progress.c b/tool/seahorse-tool-progress.c
-index 613e82f..c039118 100644
 a/tool/seahorse-tool-progress.c
-+++ b/tool/seahorse-tool-progress.c
-@@ -217,7 +217,7 @@ seahorse_tool_progress_start (const gchar *title)
- argv[2] = (gchar *)title;
- argv[3] = NULL;
- 
--ret = g_spawn_async_with_pipes (NULL, argv, NULL, 
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH,
-+ret = g_spawn_async_with_pipes (NULL, argv, NULL, 
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD,
- NULL, NULL, _pid, _fd, 
NULL, NULL, );
- 
- if (!ret) {
---
-cgit v0.9.2
diff -Nru seahorse-nautilus-3.11.92/debian/patches/gpg21.patch 
seahorse-nautilus-3.11.92/debian/patches/gpg21.patch
--- seahorse-nautilus-3.11.92/debian/patches/gpg21.patch1970-01-01 
01:00:00.0 +0100
+++ seahorse-nautilus-3.11.92/debian/patches/gpg21.patch2016-11-16 
21:30:02.0 +0100
@@ -0,0 +1,29 @@
+Description: Accept GnuPG 2.1
+ This is the minimum change to fix the build,
+ upstream fixed this as part of a bigger change in 3.18
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/835675
+Forwarded: not-needed
+
+--- seahorse-nautilus-3.11.92.orig/configure.ac
 seahorse-nautilus-3.11.92/configure.ac
+@@ -57,7 +57,7 @@ AC_ARG_ENABLE(gpg-check,
+   DO_CHECK=$enableval, DO_CHECK=yes)
+ 
+ if test   "$DO_CHECK" = "yes"; then
+-  accepted_versions="1.2 1.4 2.0"
++  accepted_versions="1.2 1.4 2.0 2.1"
+   AC_PATH_PROGS(GNUPG, [gpg gpg2], no)
+   ok="no"
+   if test "$GNUPG" != "no"; then
+--- seahorse-nautilus-3.11.92.orig/configure
 seahorse-nautilus-3.11.92/configure
+@@ -14879,7 +14891,7 @@ fi
+ 
+ 
+ if test   "$DO_CHECK" = "yes"; then
+-  accepted_versions="1.2 1.4 2.0"
++  accepted_versions="1.2 1.4 2.0 2.1"
+   for ac_prog in gpg gpg2
+ do
+   # Extract the first word of "$ac_prog", so it can be a program name with 
args.
diff -Nru seahorse-nautilus-3.11.92/debian/patches/series 
seahorse-nautilus-3.11.92/debian/patches/series
--- seahorse-nautilus-3.11.92/debian/patches/series 2014-09-15 
21:31:16.0 +0200
+++ seahorse-nautilus-3.11.92/debian/patches/series 2016-11-16 
21:30:02.0 +0100
@@ -0,0 +1 @@
+gpg21.patch

Bug#844295: [Pkg-xfce-devel] Bug#844295: Bug#844295: [lightdm] "FAILED to start Light Desktop Manager" errors after dpkg-reconfigure lightdm and choosing another desktop manager

[Yves-Alexis Perez]

On Mon, 2016-11-14 at 16:38 +0100, Laura Arjona Reina wrote:
> I'm not sure which is the better step to do now, though: reasigning this 
> bug report to kdm? or closing this and creating a new bug report against 
> kdm?

yes, please reassign to kdm, so they'll have the history and all the debug you
already did :)

Regards,
-- 
Yves-Alexis

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

Bug#844527: [Pkg-xfce-devel] Bug#844527: xfwm4: Windows without a titlebar raise on click even when "raise on click" option is disabled.

[Yves-Alexis Perez]

Version: 4.11.1-1

On Wed, 2016-11-16 at 15:56 +, Matthew Wakeling wrote:
> Package: xfwm4
> Version: 4.10.1-3
> Severity: normal
> 
> Dear Maintainer,
> 
> The current debian stable version of xfwm4 raises windows on click that do
> not have a titlebar, even when the "raise on click" option is disabled.
> 
> To reproduce, disable "raise on click", then open a terminal window, and
> don't maximise it. Run xeyes (the quickest and easiest way to get a
> titlebar-less window), and overlap the two windows. Note that to raise the
> terminal window, you have to click in the titlebar, but to raise the xeyes
> window you can click anywhere in it.
> 
> This is particularly a problem for Chromium windows, that are naturally
> titlebar-less.
> 
> Correcting this problem does not remove the ability to raise titlebar-less
> windows, because you can still Alt-click or click on the taskbar.
> 
Hi,

for what it's worth, it seems that the raise on click behavior works fine
(with chromium) on 4.12.3. I don't have a stable box at hand to test on.
-- 
Yves-Alexis

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

Bug#844559: emacs: hard lockup in shell-script-mode when file has no final newline

[Eric Cooper]

Package: emacs
Version: 46.1
Severity: normal

When I visit the following file (which ends after "bar" without a newline):

cut here
#!/bin/sh

if foo; then
barcut here

If I move to the "if foo" line, Emacs gets into a 100% busy,
uninterruptible state.  If I visit it literally, or change the mode to
text or fundamental, the problem doesn't occur.

It also doesn't occur if the "bar" line is already indented.

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

Kernel: Linux 4.7.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs24  24.5+1-7

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#844549: network-console broken: no screen to be resumed matching sh

[Ben Hutchings]

On Wed, 2016-11-16 at 12:07 -0800, Martin Michlmayr wrote:
> Package: rootskel
> Version: 1.119
> Severity: serious
> Tags: patch
> 
> Several users have reported to me that the network-console images are
> broken.
> 
> Commit ec6d3c3d79 (Move screen support) moved the screen support
> around and also changed the logic of when screen is used.
> Unfortunately, that change broke all network-console images which now
> lead to:
> 
> installer@192.168.0.102's password:
> There is no screen to be resumed matching sh.
> Connection to 192.168.0.102 closed.
> 
> This is because d-i is already running in screen on the serial console but
> it's active and can't be resumed.
> 
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.
> 
> Samuel, Roger, does that look correct?
> 
> diff --git a/src/lib/debian-installer.d/S70menu 
> b/src/lib/debian-installer.d/S70menu
> index 7b35fac..14cad7f 100644
> --- a/src/lib/debian-installer.d/S70menu
> +++ b/src/lib/debian-installer.d/S70menu
> @@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
> && [ -n "$TERM_FRAME
>   set -e
>  else
>   rm -f $font
> - if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then
> + if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then

This makes the comparison with 'serial' redundant; the condition will
be equivalent to:

[ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]

Is that really what we want?

Ben.

>   # there's GNU/screen binary, run menu in it.
> >     # call this script again with in GNU/screen, possibly in UTF-8 
> > mode
> >     SCREEN_OPT=""
> 
-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.


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

Bug#844558: gdcm: FTBFS on mipsel

[Adrian Bunk]

Control: reassign -1 binutils
Control: forcemerge 844357 -1
Control: affects 844357 src:gdcm

On Wed, Nov 16, 2016 at 09:38:05PM +0100, Bas Couwenberg wrote:
> Source: gdcm
> Version: 2.6.6-2
> Severity: serious
> Justification: makes the package in question unusable or mostly so
> 
> Dear Maintainer,
> 
> gdcm 2.6.6-2 FTBFS on mipsel and this seems to block the poppler
> migration to testing.
> 
> If the build cannot be fixed, please request partial removal of gdcm and
> its reverse dependencies from mipsel.

/usr/lib/mipsel-linux-gnu/libvtkRenderingOpenGL-6.3.so.6.3.0: undefined 
reference to `glLoadMatrixd'

This is #844357

> Kind Regards,
> 
> Bas

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844425: ipmitool: segfault fwum upgrade / statically allocated buffer

[Jörg Frings-Fürst]

forwarded 844424 https://sourceforge.net/p/ipmitool/bugs/475/
thanks


Hello Florian,

thank you for spending your time helping to make Debian better with
this bug report.

For the next weeks I have to much work at my job. So I think it is
faster to forward your bug to upstream.

If I have some free time I take a look on it too.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#844514: mosh: major issues with queued control sequences

[Keith Winstein]

Hello Dominik,

Mosh, OpenSSH, and TELNET all just literally convey these characters from
the client to the pty. None of these programs try to interpret sequences
like "Ctrl-A n" or "ESC #". (To double-check, I have just tested ESC #
using "mosh localhost" and I could not see any difference in the behavior
with or without Mosh.)

I am not sure if you have identified a problem with screen and the timing
of its input, but I do not think this report describes a Mosh bug.

If you disagree, please consider opening a bug report with replication
instructions at the upstream GitHub: https://github.com/mobile-shell/mosh

Thank you,
Keith

On Wed, Nov 16, 2016 at 4:24 AM, Dominik George  wrote:

> Package: mosh
> Version: 1.2.6-1+b1
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I have trouble using mosh together with screen and even a normal shell
> because mosh does not handle control sequences correctly.
>
> Two example:
>
>   Ctrl-A n  for switching to the next screen inside GNU screen works
>   under normal circumstances, but when the connection gets bad and
>   mosh starts queueing and predicting things, once the connection comes
>   back, ^An is written to the shell verbatim, making the behaviour
>   wrong and non-deterministic and even leading to data corruption
>   if unnoticed.
>
>   Escape sequences, like  Esc #  for terminating the current shell
>   input line and prefixing it with a #, do not work at all.
>
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.10
> ii  libc6   2.24-5
> ii  libgcc1 1:6.2.0-10
> ii  libprotobuf10   3.0.0-7
> ii  libssl1.0.2 1.0.2j-1
> ii  libstdc++6  6.2.0-10
> ii  libtinfo5   6.0+20160917-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.3p1-2
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> Versions of packages mosh recommends:
> ii  libio-socket-ip-perl  0.37-1
> ii  perl-base [libio-socket-ip-perl]  5.24.1~rc3-3
>
> mosh suggests no packages.
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQJhBAEBCABLBQJYLFAAMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
> cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
> MOMP/i/hkXApBtJh6XQIPpgn+OCmQJ+0XU+KaAQs2/DHWZ3Hq8ECkL7wF8ZXB9RS
> gtMyDcLvCo7WTp6FWdAosZ3ScITn/gq99r+u74wKUdowPbVwykvnJDZZVDmE1JS6
> 3+EJujCBUMI6A8SldgtfDal9KCbVK+rOYayAf//lIoAkP32kT+Xy6vhCTuCRFcUB
> zHXGuYG0g0JeEjS8o01vsyDc9mrWamKId7gaHme3wNXWuUTILaxVC93O5XauBtYW
> VNjq9wNof/fR9lHAcTR1bSV2X+7mRUyRtmrznZ/H/ikw/0j/+V68HiYT0JE9hS1O
> bEo3nFlkOKAOk/zcMoYMdzM8pzQOXGQ72SymaEwb7H6R2R2rHHPTjhQtuByagHq8
> yvY58sQnmAhQ+UUK8d8JYJdBFxwVt6uVxrv6iYLhSM41tNsMzcQRUZcu9XfvDPaL
> XK6A2d/gdMRROYDExJQ0wontaaRqnPGPYbg/YLd/NrGuJsz5Ot3l2XqIFJF3tY8w
> ksac7cKThYS0SjdsJhtC/I657t2Acz8HNeSInJXX3s3seVuS3rqhLI0rfuJYeC8a
> jFTXfST0PQCAeXz41enan8DuewVlm+HFYfRd4+7L+fEJgLzTfUhZ0wI6Ua5KOToU
> Q6H9Hyo1mknfcvGTDghNfWNrOVr+uecLr/mRvrxGNnhSq4Jg
> =Av/J
> -END PGP SIGNATURE-
>

Bug#821114: WhatsApp

[neelamsingh1256 9468372356]

Bug#844558: gdcm: FTBFS on mipsel

[Bas Couwenberg]

Source: gdcm
Version: 2.6.6-2
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

gdcm 2.6.6-2 FTBFS on mipsel and this seems to block the poppler
migration to testing.

If the build cannot be fixed, please request partial removal of gdcm and
its reverse dependencies from mipsel.

Kind Regards,

Bas

Bug#843948: duck: [PATCH] Add exception for Emacs M-x shell (no colors)

[Simon Kainz]

Hello,

and thanks for your suggestion, but i probably don't understand you
completely.

You wrote, when running duck inside emacs M-x shell, "...output looks
garbled": Does this mean you see the escape codes literally printed on
screen? Or do you have issues with the colors themselves?

I tried to detect if duck outputs to a terminal or a pipe, and supress
the color when piping.

I just tried it out in Emacs 24.4.1, inside X as well as on the console,
and I have no garbled output.

I am very happy to implement this, but if possible, i would like to fix
this in a more generic way, and not for Emacs only, so i would like to
do the following:

Inside M-x shell, the TERM variable is set to "dumb". I think it might
be more correct if I use this as an indicator wether it's ok to show
colors or not.

I just tried it and it now behaves as git status/git log.

What do you think about that? This would also be more graceful, if e.g
running M-x term, which also has $INSIDE_EMACS set, but *is* capable of
handling colors correctly.

Please share your thoughts.

Thanks, Simon


Am 2016-11-11 um 05:46 schrieb Jari Aalto:
> Package: duck
> Version: 0.10
> Severity: wishlist
> Tags: patch
> 
> By default program enables color. However if run inside standard Emacs
> M-x shell, the color cored are not interpreted and the output looks
> garbled.
> 
> Please consider applying the following patch which adds exception for
> Emacs.
> 
> Consideration not to enable colors by default
> ---
> 
> (1) In general, it might be considered that programs wouldn't use
> colors by default. It's quite impossible to select correct colors for
> various terminals considering that user may have chosen their own
> default backgrounds and foregrounds -- thus the program's choices may
> not play well with the users' selected colors.
> 
> (2) Typically features are enabled by request.
> 
> E.g in git(1) colors are enabled explicitly.
> 



signature.asc
Description: OpenPGP digital signature

Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2

[Kurt Roeckx]

On Wed, Nov 16, 2016 at 10:26:48PM +0200, Adrian Bunk wrote:
> On Wed, Nov 16, 2016 at 08:36:49PM +0100, Kurt Roeckx wrote:
> > On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > > Stefan Fritsch  writes:
> > > 
> > > > I must admit that I did not think of php when doing that change, sorry. 
> > > 
> > > > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and 
> > > > there 
> > > > have been some indications that shibboleth won't be switching to 
> > > > openssl 1.1 
> > > > for stretch. See 
> > > > https://lists.debian.org/debian-release/2016/11/msg00024.html
> > > 
> > > It turns out that Shibboleth will be okay if Apache goes to 1.1.  The
> > > Shibboleth code that goes into Apache is isolated from the OpenSSL use
> > > inside Shibboleth, so we can keep building Shibboleth against 1.0 and
> > > Apache can go to 1.1 and all the pieces are happy.  (The OpenSSL work is
> > > done in a separate daemon, shibd, that the Apache module talks to.)
> > 
> > So I looked at apache2-dev to see why it depends on libssl-dev.
> > The only thing I can find is that mod_ssl_openssl.h provides some
> > hooks, and you actually get SSL_CTX * and SSL * in there. But
> > nothing in Debian seems to include that file.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828330#16
> 
> Where is that dependency on the same OpenSSL version coming from?

Like I just said, it exposes the SSL_CTX * and SSL *, and you need
to use them with the same version that created them.


Kurt

Bug#844556: openjpeg2: CVE-2016-9117

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/860

Hi,

the following vulnerability was published for openjpeg2.

CVE-2016-9117[0]:
| NULL Pointer Access in function imagetopnm of convert.c(jp2):1289 in
| OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a
| crafted j2k file.

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-9117
[1] https://github.com/uclouvain/openjpeg/issues/860

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#844557: openjpeg2: CVE-2016-9118

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/861

Hi,

the following vulnerability was published for openjpeg2.

CVE-2016-9118[0]:
| Heap Buffer Overflow (WRITE of size 4) in function pnmtoimage of
| convert.c:1719 in OpenJPEG 2.1.2.

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-9118
[1] https://github.com/uclouvain/openjpeg/issues/861

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#698527: Already fixed in oldstable

[Francesco Poli]

On Wed, 16 Nov 2016 14:07:39 +0200 Adrian Bunk wrote:

[...]
> On Sat, Oct 29, 2016 at 06:13:21PM +0200, Francesco Poli wrote:
> > On Mon, 17 Oct 2016 22:59:06 +0200 Francesco Poli wrote:
[...]
> > > ElmerGUI is included in the experimental package (elmerfem/7.0.svn.6034
> > > +dfsg-2): it's not clear to me how the OpenSSL linking issue was solved.
> > > I cannot find any explanation in the changelog: could someone please
> > > clarify?
> > > 
> > > Please let me know.
> > > Thanks for your time!
> > 
> > Ping?
> 
> Thanks a lot for noticing, and apologies for the late reply.

You're welcome. And no problems for the delay...

> 
> I completely missed that the more recent version in experimental
> is not fixed, reopening.

OK, thank you!

Please address the remaining issue (that is to say: the link with
OpenSSL).
I hope this may be done soon.

Bye and thanks for your time!


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


pgpbFb1u5UMBk.pgp
Description: PGP signature

Bug#844551: openjpeg2: CVE-2016-9112

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/855

Hi,

the following vulnerability was published for openjpeg2.

CVE-2016-9112[0]:
| Floating Point Exception (aka FPE or divide by zero) in
| opj_pi_next_cprl function in openjp2/pi.c:523 in OpenJPEG 2.1.2.

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-9112
[1] https://github.com/uclouvain/openjpeg/issues/855

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#844359: enigmail doesn't recognize /usr/bin/gpg or /usr/bin/gpg2 as valid

[Daniel Kahn Gillmor]

Version: 2:1.9.6-2

On Tue 2016-11-15 05:11:28 +0900, Paul Gevers wrote:
> On my up-to-date stretch setup, enigmail was suddendly broken today. Suddenly
> enigmail shows me a pop-up:
>
> Enigmail: Error in accessing Enigmail service In order to use Enigmail, GnuPG 
> is required. If you did not install GnuPG yet, the easiest way to do this is 
> using the "Setup Wizard" button below.
>
> When I follow the wizard, taking the default answers, it ends with:
>
> Enigmail requires GnuPG for doing the cryptographic work. The wizard tried to 
> locate the GnuPG executable, but it could not be found.
> Please locate GnuPG using the Browse button.
>
> When I point it at either gpg or gpg2 it complains:
> The file you specified is not a GnuPG executable. Please specify a different 
> file.

This is an upstream bug, and it should be fixed with 1.9.6-2.  thanks
for your report!

--dkg


signature.asc
Description: PGP signature

Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2

[Adrian Bunk]

On Wed, Nov 16, 2016 at 08:36:49PM +0100, Kurt Roeckx wrote:
> On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > Stefan Fritsch  writes:
> > 
> > > I must admit that I did not think of php when doing that change, sorry. 
> > 
> > > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and 
> > > there 
> > > have been some indications that shibboleth won't be switching to openssl 
> > > 1.1 
> > > for stretch. See 
> > > https://lists.debian.org/debian-release/2016/11/msg00024.html
> > 
> > It turns out that Shibboleth will be okay if Apache goes to 1.1.  The
> > Shibboleth code that goes into Apache is isolated from the OpenSSL use
> > inside Shibboleth, so we can keep building Shibboleth against 1.0 and
> > Apache can go to 1.1 and all the pieces are happy.  (The OpenSSL work is
> > done in a separate daemon, shibd, that the Apache module talks to.)
> 
> So I looked at apache2-dev to see why it depends on libssl-dev.
> The only thing I can find is that mod_ssl_openssl.h provides some
> hooks, and you actually get SSL_CTX * and SSL * in there. But
> nothing in Debian seems to include that file.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828330#16

Where is that dependency on the same OpenSSL version coming from?

> Kurt

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844552: openjpeg2: CVE-2016-9113

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/856

Hi,

the following vulnerability was published for openjpeg2.

CVE-2016-9113[0]:
| There is a NULL pointer dereference in function imagetobmp of
| convertbmp.c:980 of OpenJPEG 2.1.2. image-comps[0].data is not
| assigned a value after initialization(NULL). Impact is Denial of
| Service.

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-9113
[1] https://github.com/uclouvain/openjpeg/issues/856

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#844555: openjpeg2: CVE-2016-9116

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/859

Hi,

the following vulnerability was published for openjpeg2.

CVE-2016-9116[0]:
| NULL Pointer Access in function imagetopnm of convert.c:2226(jp2) in
| OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a
| crafted j2k file.

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-9116
[1] https://github.com/uclouvain/openjpeg/issues/859

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore