Bug#873286: [gitmagic] The package has more translations

[Paride Desimone]

Package: gitmagic
Version: 20160304-1
Severity: normal
Tags: l10n

--- Please enter the report below this line. ---

Hi,
I saw, in the upstream website, that the package has more translations:
Simplified cCinese, French, German, Italian, Korean, Polish, Brazilian
Portuguese, Russiaa, Spanish, Ukrainian, Vietnamese
What do you think to put it in the next release?



--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-3-686-pae

Debian Release: 9.1
  500 stable  security.debian.org 
  500 stable  httpredir.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#868558: nmu: multiple r-* packages

[Niels Thykier]

Dirk Eddelbuettel:
> [...]
> On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
> | 
> | Dear release team,
> | 

Hi,

Sorry for the slow up take on our part.

> | Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.
> | 
> | "Ask me anything" -- What (if anything) is missing?  How can I help?
> 

Before I schedule these binNMUs, then I need to understand if partial
upgrades will be handled correctly.  Notably, this case suggests that
they will not be.

If someone was to upgrade R and (for the sake of the example) a rebuilt
r-cran-logspline, what will ensure that the rest of the affected R
packages are upgraded (or removed)?


In a regular ABI bump, everything is rebuilt against a new ABI package
and the old one is (eventually) removed.  As I understand it, we are not
doing that here (nor a variant of it), so you would have to use "Breaks"
to ensure this property holds.  But while Breaks on binNMU versions is
possible, it can give you headaches if binNMU versions are not in sync
between architectures.

 * Once the above is clarified/resolved, then we can start binNMUs.

> Setting severity to 'serious' which is what the one for r-base is tagged with
> at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
> 

Generally, most release.d.o bug does not use severity so it does not
really affect anything (except it splits our bug ordering up, and
somebody will probably show up and fix that eventually).

Thanks,
~Niels

Bug#873287: Fails to administer lists whose web interfaces have redirected

[martin f krafft]

Package: listadmin
Version: 2.42-1
Severity: normal

Due to HTTPS hosting requirements, lists.pantsfullofunix.net redirects to
https://pantsfullofunix-net.lists.madduck.net/. Unfortunately, listadmin is
unable to follow the redirection:

fetching data for recl...@lists.pantsfullofunix.net ...
ERROR: fetching http://lists.pantsfullofunix.net/mailman/admindb/reclass
ERROR: 301 Moved Permanently -- skipping list

Could this easily be fixed?

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

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

Versions of packages listadmin depends on:
ii  libcrypt-ssleay-perl   0.73.04-2+b2
ii  libnet-inet6glue-perl  0.603-2
ii  libtext-reform-perl1.20-3
ii  libwww-perl6.15-2

listadmin recommends no packages.

listadmin suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#873288: tack: debian/watch is no longer functional

[Sven Joachim]

Source: tack
Version: 1.07-1
Tags: patch

The watchfile in tack no longer works, the connection times out, see
https://lists.gnu.org/archive/html/bug-ncurses/2017-08/msg7.html.
Attached is a patch that works for me.

diff --git a/debian/watch b/debian/watch
index 37d0f0e..6dea61d 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version = 3
 
-ftp://invisible-island.net/ncurses/tack-(.+)\.tgz
+ftp://ftp.invisible-island.net/ncurses/tack-(.+)\.tgz

Bug#805449: Amplification

[Barak A. Pearlmutter]

I'd like to chime in on this issue. I just did a point update on a
remote server, and got the "must reboot for dbus" message. It is a
royal pain to reboot that particular computer. Moreover, if dbus were
upgraded automatically as a security patch (unattended-upgrades) there
would be no person seeing that little bon-mot.

This behaviour really is unacceptable, and this bug should be elevated
in priority.

One technical solution would be to serialize the state of dbus and do
an orderly handover to an upgraded daemon, as discussed above. I'd
suggest that it might be easier to try to ensure that dbus is
"crashable" or "crash-only", meaning that if the daemon is
unexpectedly terminated with prejudice, it will be restarted
automatically and its clients will all reestablish appropriate
connections. There is a rich literature on such software, and it is in
general a more convenient way to build robust systems. (ref:
https://en.wikipedia.org/wiki/Crash-only_software) Stateless protocols
are an example of this philosophy. However even stateful connections
can be accommodated, by ensuring that clients can reconnect and
re-establish the desired state when necessary.

--Barak Pearlmutter  http://barak.pearlmutter.net

Bug#873289: uscan: pgpmode=previous: fail to match

[Jerome Benoit]

Package: devscripts
Version: 2.17.9
Severity: important

Dear Maintainer,

it appears that when in pgpmode=previous uscan fails to match, at least
in the following example:

--8><--- d/watch
version=4
opts=repack,dversionmangle=s/\+ds$//,repacksuffix=+ds,pgpmode=next \
https://gforge.inria.fr/frs/?group_id=1015 
(?:|.*/)@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian
opts=pgpmode=previous \
https://gforge.inria.fr/frs/?group_id=1015 
(?:|.*/)@PACKAGE@@ANY_VERSION@@SIGNATURE_EXT@ previous
---><8-

then

uscan --no-conf --download-current-version --compression xz --verbose

gives

---8><--
[ ... ]
uscan info: Found the following matching hrefs on the web page (newest first):
  /frs/download.php/file/36271/sollya-6.0.tar.bz2 (6.0) index=6.0-2 matched 
with the download version
  /frs/download.php/latestfile/1349/sollya-6.0.tar.bz2 (6.0) index=6.0-2 
matched with the download version
  /frs/download.php/file/36270/sollya-6.0.tar.gz (6.0) index=6.0-1 matched with 
the download version
  /frs/download.php/latestfile/1349/sollya-6.0.tar.gz (6.0) index=6.0-1 matched 
with the download version
  /frs/download.php/file/36272/sollya-6.0.zip (6.0) index=6.0-0 matched with 
the download version
  /frs/download.php/latestfile/1349/sollya-6.0.zip (6.0) index=6.0-0 matched 
with the download version
  /frs/download.php/file/35959/sollya-5.0.tar.bz2 (5.0) index=5.0-2
  /frs/download.php/latestfile/1349/sollya-5.0.tar.bz2 (5.0) index=5.0-2
[...]
uscan info: Found the following matching hrefs on the web page (newest first):
  /frs/download.php/file/36275/sollya-6.0.tar.bz2.sig (6.0) index=6.0-2
  /frs/download.php/latestfile/1349/sollya-6.0.tar.bz2.sig (6.0) index=6.0-2
  /frs/download.php/file/36274/sollya-6.0.tar.gz.sig (6.0) index=6.0-1
  /frs/download.php/latestfile/1349/sollya-6.0.tar.gz.sig (6.0) index=6.0-1
  /frs/download.php/file/36276/sollya-6.0.zip.sig (6.0) index=6.0-0
  /frs/download.php/latestfile/1349/sollya-6.0.zip.sig (6.0) index=6.0-0
uscan warn: In debian/watch no matching hrefs for version  in watch line
[...]
--><8---

It might be related to #840943 .

hth,
Jerome
-- Package-specific info:

--- /etc/devscripts.conf ---
DEBUILD_PRESERVE_ENVVARS="TMPDIR"
DEBUILD_SET_ENVVAR_TMPDIR=/scratch/tmp

--- ~/.devscripts ---
DEBUILD_LINTIAN_OPTS='--info --display-info --display-experimental 
--show-overrides --pedantic'
DEBCHANGE_TZ=UTC

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

Kernel: Linux 4.9.30-0211-amd64-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-11+deb9u1
ii  libfile-homedir-perl  1.00-1
ii  perl  5.24.1-3+deb9u1
ii  python3   3.5.3-1

Versions of packages devscripts recommends:
ii  apt 1.4.7
ii  at  3.1.20-3
ii  curl7.52.1-5
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.05.28
ii  dput-ng [dput]  1.13
pn  equivs  
ii  fakeroot1.21-3.1
ii  file1:5.30-1
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
pn  libdistro-info-perl 
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.06-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.50.4
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
pn  python3-magic   
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  4.4
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-6+deb9u1
ii  gpgv

Bug#873290: xwayland: freeciv extremely slow, Xwayland using 85% CPU

[Anders Andersson]

Package: xwayland
Version: 2:1.19.3-2
Severity: normal

After upgrading my debian testing, I noticed that freeciv is unplayably slow.
Changing the view takes several seconds while the process Xwayland is shown
taking 85% CPU in 'top'. Previously it was almost instant. Additionally, just
showing a small animated circle around the focused unit is sluggish, also
showing 85% CPU usage.

A similar high CPU usage is shown in the game Battle for Wesnoth, which I think
is using SDL instead of gtk. This is why I report it as an xwayland problem
first, even though it might be a problem with this individual applications.

Some additional possibly relevant information:

freeciv-client-gtk: 2.5.7-2
wesnoth: 1:1.12.6-1
xserver-xorg-video-nouveau: 1:1.0.15-2


Most other applications does not seem to have the same problem. The schematic
drawing in KiCad shows the same high CPU usage but is as sluggish as usual.
Firefox or gimp does not have problems. Gnome is fine.

Note that I have not opted to use xwayland - this is something that has
recently changed for me automatically, so I'm not completely sure about exactly
which package this should be reported on.





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

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

Versions of packages xwayland depends on:
ii  libaudit1   1:2.7.7-1+b2
ii  libbsd0 0.8.6-1
ii  libc6   2.24-14
ii  libdrm2 2.4.82-1
ii  libegl1-mesa [libegl1-x11]  13.0.6-1+b2
ii  libepoxy0   1.3.1-3
ii  libgbm1 13.0.6-1+b2
ii  libgcrypt20 1.7.8-2
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libpixman-1-0   0.34.0-1
ii  libselinux1 2.6-3+b2
ii  libsystemd0 234-2.3
ii  libwayland-client0  1.14.0-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.1-3
ii  libxshmfence1   1.2-1+b2
ii  xserver-common  2:1.19.3-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#823004: gplaycli: sensitive information in config file

[Antonio Ospite]

On Wed, 23 Aug 2017 14:00:55 +0200
Matlink  wrote:

> Well, this issue has been fixed in the github repository since the
> version 0.2.2 of gplaycli. Instead of using email and password for
> credentials, gplaycli will fetch a server to get a token that will be
> used for further authentication. Thus, gplaycli no longer needs to ship
> sensitive informations in the configuration file.
> 
> See https://github.com/matlink/gplaycli
> 
> However, I'm a bit messed up with the debian way to provide .deb
> packages, that's why the debian repo of gplaycli has been abandoned
> quite long time ago. Gplaycli is now at version 0.2.10 and I'll will be
> glad to be helped to update the debian upstream repository.
> 

Someone offered their help in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871828

I'll see if I too can spend some time on gplaycli packaging myself.

Thanks,
   Antonio

-- 
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#871246: libkf5akonadi-dev: std_exception.h includes /usr/include/c++/6/exception

[Dmitry Shachnev]

Control: severity -1 important

Hi Adrian,

On Mon, Aug 07, 2017 at 10:30:18AM +0300, Adrian Bunk wrote:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libkf5mailcommon.html
>
> [...]
>
> $ cat /usr/include/KF5/AkonadiCore/std_exception.h
> #include "/usr/include/c++/6/exception"
>
> It is wrong to use the full path to the location in gcc 6.

My yesterday’s upload picked the GCC 7 version of that file, so the affected
packages should no longer FTBFS; downgrading the severity accordingly.

This file is completely gone in the new upstream version, which Maximiliano
is currently preparing for Debian.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#872406: baresip FTBFS: error: storage size of 'timeout' isn't known

[Steve Langasek]

Package: baresip
Version: 0.5.4-1
Followup-For: Bug #872406
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Hello,

Here is a patch that addresses this in baresip.  This patch has been
uploaded to Ubuntu to fix this build failure there.

Hope that helps,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru baresip-0.5.4/debian/patches/gcc-7-compat.patch 
baresip-0.5.4/debian/patches/gcc-7-compat.patch
--- baresip-0.5.4/debian/patches/gcc-7-compat.patch 1969-12-31 
16:00:00.0 -0800
+++ baresip-0.5.4/debian/patches/gcc-7-compat.patch 2017-08-26 
01:08:50.0 -0700
@@ -0,0 +1,20 @@
+Description: Use -D_GNU_SOURCE for gcc-7 compatibility
+ baresip fails to build with gcc-7 because libdirectfb-dev needs to know
+ the size of struct timespec, which is an opaque type unless we're using
+ GNU extensions, but libre-dev sets -std=c99.  Adjust cflags to enable
+ _GNU_SOURCE.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/872406
+
+Index: baresip-0.5.4/Makefile
+===
+--- baresip-0.5.4.orig/Makefile
 baresip-0.5.4/Makefile
+@@ -49,6 +49,7 @@
+ CFLAGS+= -I. -Iinclude -I$(LIBRE_INC) -I$(SYSROOT)/include
+ CFLAGS+= -I$(LIBREM_PATH)/include
+ CFLAGS+= -I$(SYSROOT)/local/include/rem -I$(SYSROOT)/include/rem
++CFLAGS+= -D_GNU_SOURCE
+ 
+ CXXFLAGS  += -I. -Iinclude -I$(LIBRE_INC)
+ CXXFLAGS  += -I$(LIBREM_PATH)/include
diff -Nru baresip-0.5.4/debian/patches/series 
baresip-0.5.4/debian/patches/series
--- baresip-0.5.4/debian/patches/series 2017-07-03 03:04:40.0 -0700
+++ baresip-0.5.4/debian/patches/series 2017-08-26 01:00:59.0 -0700
@@ -1 +1,2 @@
 2001_drop_libre_so_check.patch
+gcc-7-compat.patch

Bug#873291: sievec: always fails with the same error message and might be broken at all

[Daniel Leidert]

Package: dovecot-sieve
Version: 1:2.2.27-3+deb9u1
Severity: normal

Hello,

I recently updated my system to the new Debian stable.

When I try to check my user .sieve files (~/.dovecot.sieve) after altering
them using:

> sievec -D -c .dovecot.sieve -d -

I get the result:

> doveconf: Fatal: Error in configuration file .dovecot.sieve line 1: Expecting 
> '{'

But the mail system operates normally. Sorting and filtering works. No errors
are reported. Stripping down my .dovecot.sieve to simply contain a "require"
directive or even if I use one the examples given at the dovecot wiki [1] it
always fails and reports the error above. To my knowledge, the scripts also
don't have to start with a '{'.

So it looks to me, that sievec is broken.

[1] https://wiki2.dovecot.org/Pigeonhole/Sieve/Examples

Regards, Daniel


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.41-042stab123.9 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.2.27-3+deb9u1
ii  libc6 2.24-11+deb9u1
ii  ucf   3.0036

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.2.27-3+deb9u1
pn  dovecot-dbg
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.2.27-3+deb9u1
pn  dovecot-ldap   
ii  dovecot-lmtpd  1:2.2.27-3+deb9u1
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.2.27-3+deb9u1
pn  dovecot-sqlite 

-- no debconf information

Bug#831786: dh-exec: breaks dh_install --fail-missing

[Niels Thykier]

Ferenc Wágner:
> On Sun, 09 Oct 2016 08:06:00 + Niels Thykier  wrote:
> 
>> I will have a look at fixing the debhelper side of this, so it becomes
>> less magic.  As it is, I cannot quite grok the proposed solution in
>> dh-exec - which I am pretty sure is no fault of dh-exec itself, but
>> rather an artefact of the entire --fail-missing interface.
> 
> Hi Niels,
> 
> Could you please update this bug with the current best practices or
> plans in light of dh_missing or other advances?
> 

What I can say is that dh_missing exists and is ready to be tested.
Whether it can be used to fix the dh-exec interaction is not entirely
clear to me, but perhaps we can figure that out in this bug now.

The new interface is that:

 * dh_install records what it installs where for all packages (even
   packages not acted on to support -a/-i builds)

 * dh_missing checks the logs from dh_install (among other) and compares
   it with what is present in d/tmp (--sourcedir).
   - dh_missing also responds to d/not-installed and --exclude, which
 can also be used to control what is important to install and what
 is not.

 * If all files in d/tmp are recorded (or excluded), everything is
   presumed to be fine.

 * Caveat: Files can be processed twice!  For packages that do a
   separate -i and -a run under a regular build, the config files will
   be processed twice as dh_install cannot know that the other call will
   happen.

In summary:

 * If dh-exec ensures that all files are properly recorded (even for
   packages that are not acted on) then we are good.
   - this applies to more helpers now as e.g. dh_installman also records
 what files are installed.

 * For packages not acted on, dh_install (et al) will just record the
   file as being installed, but won't actually do anything.
   - For renames, this means that dh-exec can probably just list the
 original source file without doing the rename in the "no-act"
 case.

Future work/known issues:

 * For things that do multiple builds, dh_missing has some problems.
   These are reportedly solvable with the buildlabels prototype in
   experimental.

Thanks,
~Niels

Bug#873292: facter: Bogus output received with interface named 'master'.

[Steve Kemp]

Package: facter
Version: 2.4.6-1
Severity: minor

Dear Maintainer,

Since upgrading a virtual-machine host from jessie to stretch I started
seeing this email every hour, when puppet ran:

To: root
From: root(Cron Daemon)
Cc:
Subject: Cron  /usr/bin/puppet agent --onetime  ..

Command line is not complete. Try option "help"

I eventually tracked this output down to factor, as I could see it when
running `facter --debug`:

root@smaug ~ # facter --debug
Found no suitable resolves of 1 for ec2_metadata
..
value for macaddress_lo is still nil
value for ipaddress_master is still nil
value for ipaddress6_master is still nil
Command line is not complete. Try option "help"
value for netmask_master is still nil
value for ipaddress_skx_mail is still nil

Eventually I tracked this output down to the following function :

   def self.get_bonding_master(interface)

(Which is present in /usr/lib/ruby/vendor_ruby/facter/util/ip.rb)

That runs:

ip link show $interface

On my host that works for most interfaces, but not for master:

root@smaug ~ # ip link show master
Command line is not complete. Try option "help"

To resolve the problem I updated the code of that function from:

ethbond = regex.match(%x{/sbin/ip link show '#{interface}'})

To:

ethbond = regex.match(%x{/sbin/ip link show dev '#{interface}'})

I'm not 100% sure this is a bug, but I think it probably is ..



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

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

Bug#869282: udev: Update breaks Keyboard Configuration

[Michael Biebl]

On Sat, 22 Jul 2017 17:57:30 +0200 "jEsuSdA 8)"  wrote:
> I can confirm that returning back to udev 232, the problem dissapear.

Can you run a git bisect to identify which commit in udev changed the
behaviour?

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



signature.asc
Description: OpenPGP digital signature

Bug#872779: Bug #872779: open-vm-tools unable to manage resolution with wayland

[Raphael Hertzog]

Hi Bernd,

On Fri, 25 Aug 2017, Bernd Zeimetz wrote:
> > In the mean time, it would be great to have this in Debian. I included
> > it in Kali already. Note that you have to add "libudev-dev" and
> > "libdrm-dev" to the Build-Depends to satisfy the requirements of the
> > new plugin.
> 
> a pull request on github would be appreciated then - guess its rather
> easy as you've done the work in kali already.

Done: https://github.com/bzed/pkg-open-vm-tools/pull/11

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#873293: ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:719)

[clayton]

Package: python3-boto
Version: 2.44.0-1
Severity: normal

Suddenly, every time I call cloudwatch.describe_alarms() I am getting an 
exception:

Traceback (most recent call last):
  File "deployCloudFormation.py", line 904, in 
deploy.diagnostics()
  File "deployCloudFormation.py", line 800, in diagnostics
alarmsAllSource = common.AWSiterator( cwSource.describe_alarms )
  File "/usr/lib/python3/dist-packages/boto/ec2/cloudwatch/__init__.py", line 
383, in describe_alarms
[('MetricAlarms', MetricAlarms)])
  File "/usr/lib/python3/dist-packages/boto/connection.py", line 1170, in 
get_list
response = self.make_request(action, params, path, verb)
  File "/usr/lib/python3/dist-packages/boto/connection.py", line 1116, in 
make_request
return self._mexe(http_request)
  File "/usr/lib/python3/dist-packages/boto/connection.py", line 1030, in _mexe
raise ex
  File "/usr/lib/python3/dist-packages/boto/connection.py", line 943, in _mexe
request.body, request.headers)
  File "/usr/lib/python3.5/http/client.py", line 1107, in request
self._send_request(method, url, body, headers)
  File "/usr/lib/python3.5/http/client.py", line 1152, in _send_request
self.endheaders(body)
  File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders
self._send_output(message_body)
  File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
self.send(msg)
  File "/usr/lib/python3.5/http/client.py", line 877, in send
self.connect()
  File "/usr/lib/python3/dist-packages/boto/https_connection.py", line 131, in 
connect
ca_certs=self.ca_certs)
  File "/usr/lib/python3.5/ssl.py", line 1077, in wrap_socket
ciphers=ciphers)
  File "/usr/lib/python3.5/ssl.py", line 760, in __init__
self.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 996, in do_handshake
self._sslobj.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:719)

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

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

Versions of packages python3-boto depends on:
ii  python3   3.5.3-3
ii  python3-requests  2.18.1-1
ii  python3-six   1.10.0-4

python3-boto recommends no packages.

python3-boto suggests no packages.

-- no debconf information

Bug#870513: stretch-pu: package cloud-init/0.7.9-2

[Thomas Goirand]

On 08/06/2017 07:12 PM, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Wed, Aug 02, 2017 at 08:45:57PM +0200, Thomas Goirand wrote:
>> diff -Nru cloud-init-0.7.9/debian/cloud-init.NEWS 
>> cloud-init-0.7.9/debian/cloud-init.NEWS
>> --- cloud-init-0.7.9/debian/cloud-init.NEWS  1970-01-01 01:00:00.0 
>> +0100
>> +++ cloud-init-0.7.9/debian/cloud-init.NEWS  2017-08-02 20:28:11.0 
>> +0200
>> @@ -0,0 +1,8 @@
>> +cloud-init default behavior from upstream is to manage sources.list for 
>> Debian,
>> +adding contrib and non-free by default. This is clearly a bug which we have
>> +fixed. If you need contrib and non-free on your computer running cloud-init,
>> +then please use /etc/apt/sources.list.d facility, instead of the general 
>> file
>> +in /etc/apt/sources.list, as we changed the behavior. Our appologies for 
>> this
>> +change.
>> +
>> + -- Thomas Goirand   Wed, 02 Aug 2017 20:28:11 +0200
> 
> Is NEWS the appropriate place for this, or would README or the changelog be
> better? As it will only be shown when upgrading existing systems, this will
> simply be noise (those systems will already have a sources.list).
> 
> 
> Thanks,

Hi,

I have removed the README.Debian file, and re-uploaded to:
http://sid.gplhost.com/stretch-proposed-updates/cloud-init/

Debdiff attached. Please allow this upload.

Cheers,

Thomas Goirand (zigo)
diff -Nru cloud-init-0.7.9/debian/changelog cloud-init-0.7.9/debian/changelog
--- cloud-init-0.7.9/debian/changelog   2017-02-02 14:23:41.0 +0100
+++ cloud-init-0.7.9/debian/changelog   2017-08-02 20:28:11.0 +0200
@@ -1,3 +1,9 @@
+cloud-init (0.7.9-2+deb9u1) stretch; urgency=medium
+
+  * Remove non-free and contrib from sources.list debian template.
+
+ -- Thomas Goirand   Wed, 02 Aug 2017 20:28:11 +0200
+
 cloud-init (0.7.9-2) unstable; urgency=medium
 
   * Add net-tools as runtime depends (Closes: #853926).
diff -Nru cloud-init-0.7.9/debian/patches/0004-debian-sources.list.patch 
cloud-init-0.7.9/debian/patches/0004-debian-sources.list.patch
--- cloud-init-0.7.9/debian/patches/0004-debian-sources.list.patch  
2017-02-02 14:23:41.0 +0100
+++ cloud-init-0.7.9/debian/patches/0004-debian-sources.list.patch  
2017-08-02 20:28:10.0 +0200
@@ -1,17 +1,39 @@
-From 32dd02b4cce53db2e39a1ba62806f7db5d152095 Mon Sep 17 00:00:00 2001
+From 1351a2fba9e74492e790f184a36a2fff978a8984 Mon Sep 17 00:00:00 2001
 From: Charles Plessy 
 Date: Mon, 21 Nov 2016 19:10:47 +0100
 Subject: debian-sources.list
 
 Forwarded: https://bugs.launchpad.net/cloud-init/+bug/1627293
 ---
- templates/sources.list.debian.tmpl | 6 ++
- 1 file changed, 2 insertions(+), 4 deletions(-)
+ templates/sources.list.debian.tmpl | 18 --
+ 1 file changed, 8 insertions(+), 10 deletions(-)
 
 diff --git a/templates/sources.list.debian.tmpl 
b/templates/sources.list.debian.tmpl
-index c8043f76..f4188c73 100644
+index c8043f76..8b119ad4 100644
 --- a/templates/sources.list.debian.tmpl
 +++ b/templates/sources.list.debian.tmpl
+@@ -10,15 +10,15 @@
+ 
+ # See 
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html
+ # for how to upgrade to newer versions of the distribution.
+-deb {{mirror}} {{codename}} main contrib non-free
+-deb-src {{mirror}} {{codename}} main contrib non-free
++deb {{mirror}} {{codename}} main
++deb-src {{mirror}} {{codename}} main
+ 
+ ## Major bug fix updates produced after the final release of the
+ ## distribution.
+-deb {{security}} {{codename}}/updates main contrib non-free
+-deb-src {{security}} {{codename}}/updates main contrib non-free
+-deb {{mirror}} {{codename}}-updates main contrib non-free
+-deb-src {{mirror}} {{codename}}-updates main contrib non-free
++deb {{security}} {{codename}}/updates main
++deb-src {{security}} {{codename}}/updates main
++deb {{mirror}} {{codename}}-updates main
++deb-src {{mirror}} {{codename}}-updates main
+ 
+ ## Uncomment the following two lines to add software from the 'backports'
+ ## repository.
 @@ -26,7 +26,5 @@ deb-src {{mirror}} {{codename}}-updates main contrib non-free
  ## N.B. software from this repository may not have been tested as
  ## extensively as that contained in the main release, although it includes
diff -Nru cloud-init-0.7.9/debian/README.Debian 
cloud-init-0.7.9/debian/README.Debian
--- cloud-init-0.7.9/debian/README.Debian   2017-02-02 14:23:41.0 
+0100
+++ cloud-init-0.7.9/debian/README.Debian   1970-01-01 01:00:00.0 
+0100
@@ -1,9 +0,0 @@
-cloud-init is a tool for early initialization of servers,
-  usually in a cloud environment.
-
-It can be used to set the hostname, configure SSH and APT repositories,
-  add users, install and configure services, ...
-
-See https://cloudinit.readthedocs.io/en/stable/
-
- -- Nicolas Braud-Santoni , Sat, 24 Sep 2016 
14:13:24 +0200

Bug#873281: closed by Benjamin Kaduk (Re: Bug#873281: krb5: CVE-2017-7562)

[Salvatore Bonaccorso]

Control: notfound -1 1.12.1+dfsg-19

Hi Ben,

On Sat, Aug 26, 2017 at 07:18:03AM +, Debian Bug Tracking System wrote:
> I believe you are mistaken, and the issue was introduced only in commit
> b619ce84470519bea65470be3263cd85fba94f57, which is not in any released
> version of krb5 (and thus not in any version in Debian).

Yes you are right, that was only introduced in 1.16 indeed. Thanks for
the quick response, fixed the information.

Regards,
Salvatore

Bug#873294: mpv: No protocol handler for dvb

[Rob Moss]

Package: mpv
Version: 0.26.0-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 I tried to watch a digital TV broadcast using my USB adaptor.

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

 I ran "mpv 'dvb://Channel Name'

   * What was the outcome of this action?

 No protocol handler found to open URL dvb://Channel Name
 The protocol is either unsupported, or was disabled at compile-time.

   * What outcome did you expect instead?

 That mpv would stream the digital TV channel, as it has previously.

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

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

Versions of packages mpv depends on:
ii  libasound2  1.1.3-5
ii  libass9 1:0.13.7-2
ii  libavcodec577:3.3.3-3
ii  libavdevice57   7:3.3.3-3
ii  libavfilter67:3.3.3-3
ii  libavformat57   7:3.3.3-3
ii  libavutil55 7:3.3.3-3
ii  libbluray2  1:1.0.1.deb1-2
ii  libc6   2.24-14
ii  libcaca00.99.beta19-2+b2
ii  libcdio-cdda1   0.83-4.3+b1
ii  libcdio-paranoia1   0.83-4.3+b1
ii  libcdio13   0.83-4.3+b1
ii  libdrm2 2.4.82-1
ii  libdvdnav4  5.0.3-3
ii  libdvdread4 5.0.3-2
ii  libegl1-mesa [libegl1-x11]  13.0.6-1+b2
ii  libgbm1 13.0.6-1+b2
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libjack-jackd2-0 [libjack-0.125]1.9.10+20150825git1ed50c92~dfsg-5
ii  libjpeg62-turbo 1:1.5.1-2
ii  liblcms2-2  2.8-4
ii  liblua5.2-0 5.2.4-1.1+b2
ii  libpulse0   10.0-2
ii  librubberband2  1.8.1-7
ii  libsdl2-2.0-0   2.0.5+dfsg1-3
ii  libsmbclient2:4.6.7+dfsg-1
ii  libsndio6.1 1.1.0-3
ii  libswresample2  7:3.3.3-3
ii  libswscale4 7:3.3.3-3
ii  libuchardet00.0.6-2
ii  libva-drm1  1.8.3-1
ii  libva-wayland1  1.8.3-1
ii  libva-x11-1 1.8.3-1
ii  libva1  1.8.3-1
ii  libvdpau1   1.1.1-6
ii  libwayland-client0  1.14.0-1
ii  libwayland-cursor0  1.14.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  13.0.6-1+b2
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxkbcommon0   0.7.1-1
ii  libxrandr2  2:1.5.1-1
ii  libxss1 1:1.2.2-1+b2
ii  libxv1  2:1.0.11-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages mpv recommends:
ii  xdg-utils   1.1.1-1
ii  youtube-dl  2017.05.18.1-1

mpv suggests no packages.

-- no debconf information

Bug#873295: function keys not working on debian testing/sid

[Mladen Uzelac]

Package: cinnamon

I was using Debian Stretch cinnamon edition and upgrade it to testing and I
couldn't use function key combination to increase/decrease volume and
brightness.
Also Ctrl+Alt+T wasn't working to run terminal

What is interesting is when I used Mate display those keys were functional.
I noticed that Cinnamon package is the same but some other package caused
it seems it had affected Mate DE.

I even tried to upgrade to sid without success.

And about 2-3 weeks ago I install Debian buster cinnamon from netinstall
and everything was working perfectly.

I am running now Debian Stretch stable with backports and those controls
are working properly.

kind regards, Mladen.

Bug#872636: qtiplot: FTBFS with sip 4.19: 'sipType_QDateTime' was not declared in this scope

[Dmitry Shachnev]

Control: tags -1 +patch

On Sat, Aug 19, 2017 at 06:27:08PM +0300, Dmitry Shachnev wrote:
> Dear maintainer,
>
> qtiplot fails to build with sip 4.19.3 and python-qt4 4.12.1, both of which
> are available in experimental:
>
>   src/scripting/qti.sip: In function ‘int setCellDataHelper(Table*, int, int, 
> PyObject*)’:
>   src/scripting/qti.sip:151:35: error: ‘sipType_QDateTime’ was not declared 
> in this scope
>if (sipCanConvertToType(item, sipType_QDateTime, 0)) {
>  ^
>   src/scripting/qti.sip:167:35: error: ‘sipType_QTime’ was not declared in 
> this scope
>if (sipCanConvertToType(item, sipType_QTime, 0)) {
>  ^

Gentoo has applied this patch to fix the failure:

https://bugs.gentoo.org/show_bug.cgi?id=609280#c1

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#873296: ITP: minetest-mod-xdecor -- Lightweight decoration module for minetest

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: minetest-mod-xdecor
  Version : None
  Upstream Author : Jean-Patrick Guerrero (kilbith)
* URL : https://github.com/minetest-mods/xdecor
* License : GPL-3
  Programming Lang: Lua
  Description : Lightweight decoration module for minetest
 This module adds a bunch of cute cubes as well as various mechanisms to
 the game, like for example Ender chests, cooking recipes, cutting,
 enchanting, a chess board...


There is no version yet : upstream doesn't tag releases -- I opened a
bug report about it ( https://github.com/minetest-mods/xdecor/issues/82
) ; I'll package when either the issue is closed or I get wary and
package a git checkout.

Thanks,

Snark on #debian-games

Bug#873297: libgcrypt20: Add OID for SHA384WithECDSA

[Bartholomew Kwapinski]

Package: libgcrypt20
Version: 1.7.6-2+deb9u1
Severity: important

Dear Maintainer,

importing a certificate with "gpgsm --import" that uses ecdsa-with-SHA384 as 
signature algorithm fails with the error message 

gpgsm: unknown hash algorithm '1.2.840.10045.4.3.3'
gpgsm: self-signed certificate has a BAD signature: General error
gpgsm: basic certificate checks failed - not imported

This bug has been addressed and fixed upstream following the patch note

https://dev.gnupg.org/rCa7bd2cbd3eabda88fb3cac5cbc13c21c97a7b315#7bc618ca

Please implement this patch into libgcrypt20 in Debian Stretch.

Kind regards,
Bart


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

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

Versions of packages libgcrypt20 depends on:
ii  libc6  2.24-11+deb9u1
ii  libgpg-error0  1.26-2

libgcrypt20 recommends no packages.

Versions of packages libgcrypt20 suggests:
pn  rng-tools  

-- no debconf information

Bug#873204: libneon27-gnutls: Certificate verification error: signed using insecure algorithm...

[Emmanuel Fleury]

Hi László,

On 08/25/2017 10:02 PM, László Böszörményi (GCS) wrote:
> 
>> $ gnutls-cli --ca-verification --verbose www.labri.fr
> [...]
>  Please note that here you are checking www instead of webdav and as I
> see, these have different certifications.

My fault, I copied/pasted the wrong one... But, the certificate from
webdav has also a SHA-1 signature.

Sorry, for my mistake.

>  Please don't mix the two things: certificate is valid, but uses an
> insecure algorithm for its signature.

Right, I am new with this topic, so forgive me for my mistake. :)

>  I think you should ask someone who is better with GnuTLS. I can't see
> the reason. :(
> Maybe it's related to the connection ifself? Please see the detailed
> log for a working site:
> $ gnutls-cli-debug www.google.com
> It has TLS 1.0, 1.1 and 1.2 support. For your site:
> $ gnutls-cli-debug webdav.labri.fr
> 
> Fails in the end with:
> Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2
> It seems your site has a problem. Thus I plan to close this bug in
> some days as it's clear that it's not a Neon bug. The error comes from
> GnuTLS and it seems to be right. Maybe your site uses SSLv2 which was
> disabled as it's flawed in a variety of ways.

I agree with your conclusion, I should report the problem to the
administrators of the server.

So, to sum up (if someone run into the same problem):

- The server has valid certificate but uses SHA-1 (which is considered
as insecure since the discovery of new collision methods that might
break the whole scheme).

- It may appear that some other frameworks do not check for SHA-1 usage
in the certificate scheme which will result in a, very confusing,
difference of outcomes depending the tool you are using.

- At the end, the best way to solve the problem is to require the
administrator of the server to stop using SHA-1 in the certificate scheme.

Aside from that, the tool 'gnutls-cli-debug' seems to be very nice to
debug the servers.

Thanks a lot Lázló!

Regards
-- 
Emmanuel Fleury

It is a capital mistake to theorize in advance of the facts.
 -- Sherlock Holmes, The Adventure of the Second Stain (A. Conan Doyle)

Bug#873298: UnicodeEncodeError: 'ascii' codec can't encode character

[Gijs Hillenius]

Package: obnam
Version: 1.22-1
Severity: important

Dear Maintainer,


   * What led up to the situation?

Yesterday's daily backup failed,

output from the terminal:

obnam backup
00h00m27s Backing up: found 3283 files, 1.29 GiB; uploaded: 0 B
/home/gijs/.node-gyp/4.3.1/include/node/openssl/archs/linux-ppc/opensslconf.hTraceback
 (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/obnamlib/app.py", line 228, in 
process_args
cliapp.Application.process_args(self, args)
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 593, in 
process_args
method(args[1:])
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 166, in backup
self.backup_roots(root_urls)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 369, in backup_roots
self.backup_root(root_url, absroots)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 396, in backup_root
for pathname, metadata in self.find_files(absroot):
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 577, in find_files
for pathname, st in self.fs.scan_tree(root, ok=self.can_be_backed_up):
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 337, in 
scan_tree
items = process_dir(filename, metadata, items)
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 324, in 
process_dir
for subname, submeta in list_files(dirname)]
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 304, in 
list_files
pairs = self.listdir2(pathname)
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs_local.py", line 418, in 
listdir2
st = self.lstat(os.path.join(dirname, name))
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs_local.py", line 235, in 
lstat
ctime_sec, ctime_nsec) = obnamlib._obnam.lstat(self.join(pathname))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 
60: ordinal not in range(128)

and leaving the same in the obnam log:

2017-08-25 09:13:58 INFO Backing up /home/gijs/fortunes
2017-08-25 09:13:58 INFO Attempting to unlock client because of error
2017-08-25 09:13:58 INFO Unlocking client luxpondusbufocogitans
2017-08-25 09:13:58 INFO Successfully unlocked
2017-08-25 09:13:58 CRITICAL Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/obnamlib/app.py", line 228, in 
process_args
cliapp.Application.process_args(self, args)
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 593, in 
process_args
method(args[1:])
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 166, in backup
self.backup_roots(root_urls)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 369, in backup_roots
self.backup_root(root_url, absroots)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 396, in backup_root
for pathname, metadata in self.find_files(absroot):
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py", 
line 577, in find_files
for pathname, st in self.fs.scan_tree(root, ok=self.can_be_backed_up):
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 337, in 
scan_tree
items = process_dir(filename, metadata, items)
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 324, in 
process_dir
for subname, submeta in list_files(dirname)]
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs.py", line 304, in 
list_files
pairs = self.listdir2(pathname)
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs_local.py", line 418, in 
listdir2
st = self.lstat(os.path.join(dirname, name))
  File "/usr/lib/python2.7/dist-packages/obnamlib/vfs_local.py", line 235, in 
lstat
ctime_sec, ctime_nsec) = obnamlib._obnam.lstat(self.join(pathname))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 
60: ordinal not in range(128)

I don't immediately see what is the issue, it seems similar to debian
bug 800386, but it's not clear to me which application is causing the
error.


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

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

Versions of packages obnam depends on:
ii  gnupg 2.1.23-2
ii  libc6 2.24-15
ii  python2.7.13-2
ii  python-cliapp 1.20170823-1
ii  python-fuse   2:0.2.1-14
ii  python-larch  1.20151025-1
ii  python-paramiko   2.0.0-1
ii  python-tracing   

Bug#873299: please provide HTML documentation

[Sébastien Villemot]

Source: slime
Version: 2:2.18-1
Severity: normal

Dear Maintainers,

Currently SLIME documentation is provided in PDF and info formats, but not in
HTML, which is the preferred documentation format in Debian (see Policy §12.4).

Fortunately upstream already provides a Makefile rule for building the HTML
manual.

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#873300: please register documentation into doc-base

[Sébastien Villemot]

Source: slime
Version: 2:2.18-1
Severity: normal

Dear Maintainers,

Please register SLIME manual into the doc-base system (the PDF version, and
also the HTML version when it gets packaged, see #873299).

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#873301: RFS: minetest-mod-xdecor/1.0-1 [ITP]

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "minetest-mod-xdecor"

 * Package name: minetest-mod-xdecor
   Version : 1.0-1
   Upstream Author : Jean-Patrick Guerrero (kilbith)
 * URL : https://github.com/minetest-mods/xdecor
 * License : GPL-3
   Section : games

  It builds those binary packages:

minetest-mod-xdecor - Lightweight decoration module for minetest

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

  https://mentors.debian.net/package/minetest-mod-xdecor


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

dget -x
https://mentors.debian.net/debian/pool/main/m/minetest-mod-xdecor/minetest-mod-xdecor_1.0-1.dsc

  It is maintained within the Debian Games Team:
Vcs-Git: https://anonscm.debian.org/git/pkg-games/minetest-mod-xdecor.git
Vcs-Browser:
https://anonscm.debian.org/git/pkg-games/minetest-mod-xdecor.git

Thanks,

Snark on #debian-games

Bug#862868: RFS: shc/3.9.4-4

[Gianfranco Costamagna]

Hello Tong,

On Mon, 24 Jul 2017 22:40:59 +0500 Andrey Rahmatullin  wrote:
> Control: tags -1 + moreinfo
> 
> On Thu, May 18, 2017 at 03:32:48AM +0600, Md Jahidul Hamid wrote:
> >   Changes since the last upload:
> > 
> >   * Fix for infinite loop (Closes: #861180)
> I don't think it's the only change as the last upload is 3.8.9b-1 and this
> version is 3.9.4-4. It seems you've made the packaging from scratch, which
> is wrong by the way, but that still doesn't mean you can drop the old
> changelog entries.
> 
> -- 

somebody (upstream?) is trying to update your package, can you please 
coordinate together?


G.



signature.asc
Description: OpenPGP digital signature

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

[Gianfranco Costamagna]

Hello,


> > Done, the watch file seem to work according to `uscan`, but
> mentors.debian.net says there's a problem. I'm not sure what's wrong.
> 
> Take a look on [1] as an example, your `watch` file is broken
> presumably since you're calling `uupdate` directly.
> 
> [1]https://wiki.debian.org/debian/watch#GitHub
> 

what is the status of this RFS?

G.



signature.asc
Description: OpenPGP digital signature

Bug#848416: closing RFS: pyvtk/0.5.18-1 [ITA]

[Gianfranco Costamagna]

On Fri, 19 May 2017 11:05:32 + (UTC) Gianfranco Costamagna 
 wrote:
> Hi,
> 
> 
> >* Package the thing with this actual bug, but as far as I'm concerned I
> >   consider it as grave, so I'm not really a fan of this idea.
> 
> 
> me neither
> 
> >* Patch the issue myself, as a debian patch, and package the thing with it.
> 
> unmaintainable on the long run
> 
> 
> >* Fork the project (it's BSD 2-Clause license), patch it, and provide it as> 
> >  a personnal work, with credit to the original author.
> 
> 
> if you want to fork, consider that this might be a lot time consuming
> 

ping :)


G.



signature.asc
Description: OpenPGP digital signature

Bug#873265: Updating the manpages Uploaders list

[Dr. Tobias Quathamer]

control: tag -1 pending

Am 25.08.2017 um 23:28 schrieb Mattia Rizzolo:
> Simon Paillard  has not been working on
> the manpages package for quite some time.
> 
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.

Hi Mattia,

I've removed him from the Uploaders list. This will be part of the next
release.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#871987: [Pkg-openssl-devel] Bug#871987: Bug#871987: openvpn

[Kurt Roeckx]

On Sat, Aug 26, 2017 at 02:50:37PM +0800, Gedalya wrote:
> On 08/26/2017 02:58 AM, Kurt Roeckx wrote:
> 
> > openvpn doesn't seem to make use of the
> > SSL_CTX_set_min_proto_version() function yet. I've attached a
> > patch that I didn't even try to compile that I think should do the
> > right thing.
> >
> Thanks for this!
> It now connects fine with the setting 'tls-version-min 1.0'
> Everything seems to work fine, including the 5 other tunnels on this box.

I'm a little confused why you ran into this, it seems that openvpn
is Debian is still linked to the libssl1.0.2, not libssl1.1. Did
you build it yourself?

> Perhaps this would be of interest to OpenVPN upstream?

I'll file a bug about it.


Kurt

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Gianfranco Costamagna]

On Fri, 7 Jul 2017 10:04:49 + (UTC) Gianfranco Costamagna 
 wrote:
> 
> 
> >I'm not sure what you mean.
> >These are dev dependencies, they are used by big-integer developers to 
> >perform various development tasks, but they are not required to simply 
> >use the library so there is no point in packaging them in Debian.
> >And they are *not* embedded in the package, they only appear in 
> >package.json.
> 
> 
> this makes sense, thanks.
> So the review goes to the next step.
> 1) licenses are missing (even if not used in the binary package, the copyright
> should list all the licenses in the source code).
> 2) please use the same copyright as upstream for Debian packaging, this will 
> make
> patch upstreaming possible without having to explicitly relicense them

ping

G.
> 
> G.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#871987: [Pkg-openssl-devel] Bug#871987: Bug#871987: openvpn

[Gedalya]

On 08/26/2017 07:08 PM, Kurt Roeckx wrote:
> On Sat, Aug 26, 2017 at 02:50:37PM +0800, Gedalya wrote:
>> On 08/26/2017 02:58 AM, Kurt Roeckx wrote:
>>
>>> openvpn doesn't seem to make use of the
>>> SSL_CTX_set_min_proto_version() function yet. I've attached a
>>> patch that I didn't even try to compile that I think should do the
>>> right thing.
>>>
>> Thanks for this!
>> It now connects fine with the setting 'tls-version-min 1.0'
>> Everything seems to work fine, including the 5 other tunnels on this box.
> I'm a little confused why you ran into this, it seems that openvpn
> is Debian is still linked to the libssl1.0.2, not libssl1.1. Did
> you build it yourself?
Yes, I did.
OpenVPN and pkcs11-helper build cleanly against libssl1.1 and work fine.
Not sure why new uploads haven't been made already. On my end I just wanted to 
try.

Bug#873275: always segfaults at start due to QSslSocket

[Adrian Bunk]

Control: reopen -1
Control: severity -1 serious
Control: tags -1 - moreinfo
Control: tags -1 confirmed
Control: reassign -1 src:qt4-x11 4:4.8.7+dfsg-12
Control: affects -1 qgis

On Sat, Aug 26, 2017 at 08:45:21AM +0200, Sebastiaan Couwenberg wrote:
> tags 873275 unreproducible
> severity 873275 normal
> thanks
> 
> qgis works fine here.
> 
> On 08/26/2017 03:11 AM, 積丹尼 Dan Jacobson wrote:
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers experimental
> 
> This likely caused your problem, you shouldn't prefer experimental over
> unstable.
>...

This is supposed to work when the dependencies allow it,[1]
and such bug reports can be quite valuable for finding regressions
before they hit a large userbase in unstable.

Likely causes for such problems include for example library ABI changes 
without a corresponding change of the so-name.

Based on the information in the bug it was in this case trivial to 
narrow the regression down to Qt4 in experimental switching to
OpenSSL 1.1 - qgis works for me with Qt4 from stable/unstable
and segfaults as describes by Dan with Qt4 from experimental.

> Kind Regards,
> 
> Bas

cu
Adrian

[1] apt preferring experimental is IMHO not a good idea,
but that doesn't turn bugs into non-bugs

-- 

   "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#873302: openvpn: openssl 1.1 tls version support

[Kurt Roeckx]

Source: openvpn
Version: 2.4.3-4
Severity: important
Tags: patch

Hi,

The attached patch add supports for the new way of setting up the
minimum and maximum supported TLS version in OpenSSL.

This is marked as important because if you switch to openssl 1.1.0
the defaults minimum version in Debian is currently TLS 1.2 and
you can't override it with the options that you're currently using
(and are deprecated).


Kurt

--- src/openvpn/ssl_openssl.c.bak	2017-08-26 13:10:40.333428825 +0200
+++ src/openvpn/ssl_openssl.c	2017-08-26 13:12:05.143672978 +0200
@@ -215,6 +215,19 @@
 #endif
 }
 
+/* convert internal version number to openssl version number */
+static int
+openssl_tls_version(int ver)
+{
+if (ver == TLS_VER_1_0)
+return TLS1_VERSION;
+else if (ver == TLS_VER_1_1)
+return TLS1_1_VERSION;
+else if (ver == TLS_VER_1_2)
+return TLS1_2_VERSION;
+return 0;
+}
+
 void
 tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned int ssl_flags)
 {
@@ -232,6 +245,17 @@
 
 tls_ver_max =
 (ssl_flags >> SSLF_TLS_VERSION_MAX_SHIFT) & SSLF_TLS_VERSION_MAX_MASK;
+
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+if (tls_ver_min <= TLS_VER_UNSPEC)
+{
+SSL_CTX_set_min_proto_version(ctx->ctx, openssl_tls_version(tls_ver_min));
+}
+if (tls_ver_max <= TLS_VER_UNSPEC)
+{
+SSL_CTX_set_max_proto_version(ctx->ctx, openssl_tls_version(tls_ver_max));
+}
+#else /* OPENSSL_VERSION_NUMBER >= 0x1010*/
 if (tls_ver_max <= TLS_VER_UNSPEC)
 {
 tls_ver_max = tls_version_max();
@@ -253,6 +277,7 @@
 sslopt |= SSL_OP_NO_TLSv1_2;
 }
 #endif
+#endif /* OPENSSL_VERSION_NUMBER */
 #ifdef SSL_OP_NO_COMPRESSION
 /* Disable compression - flag not available in OpenSSL 0.9.8 */
 sslopt |= SSL_OP_NO_COMPRESSION;

Bug#872745: [debhelper-devel] Bug#872745: dh_install: now bails for missing files in disabled packages

[Niels Thykier]

Control: tags -1 wishlist

Helmut Grohne:
> Package: debhelper
> Version: 10.7.2
> File: /usr/bin/dh_install
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:gnumach
> 
> I noticed that cross building a gnumach stage1 for hurd-i386 started to
> fail. Sucessful log:
> 
> [...] It seems that gnumach assumes that
> "dh_install -pfoo ..." is a noop (regardless of the files referenced) if
> foo is disabled by a profile. That assumption was broken somewhere from
> debhelper 10.2.5 to 10.7.2.
> 

Turns out that this assumption never worked in general, but only for
dh_install and only by accident.  Recently it would have worked with
more tools that started to integrate with dh_missing (e.g.
dh_installman) until it all "broke" in
60e1f08257c7361bf4730769f37de34141355148.


This is presumably why the package does *not* rely on this for dh_compress:

"""
ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
dh_compress -p$(pkg) boot/gnumach-$(VERSION)-$(MACHINE)
dh_compress -p$(pkg_xen) boot/gnumach-$(VERSION)-xen-$(MACHINE)
ifeq ($(DEB_HOST_ARCH_OS),hurd)
dh_compress -p$(pkg_udeb) boot/gnumach
dh_compress -p$(pkg_xen_udeb) boot/gnumach
endif
dh_compress -p$(pkg_dbg) boot/gnumach-$(VERSION)-$(MACHINE)-dbg
dh_compress -p$(pkg_xen_dbg) boot/gnumach-[...]
endif
"""

> Whether that assumption is a good one is beyond my judgement. Imo, the
> documentation does neither contradict nor support it.  [...]
> 
> Helmut
> 
> [...]

I am all for making packaging easier to get right.  I am considering
whether this is the right approach for it though.  At first glance, the
dh_install part is probably better solved with the buildlabel feature
(currently a prototype in experimental).

Not entirely sure about the dh_compress yet.  At least, the buildlabel
feature is not applicable there.

Thanks,
~Niels

Bug#868082: linux-image-4.11.0-1-686: fails to boot on i386 (Soekris net5501)

[Francesco Poli]

Control: found -1 linux/4.12.6-1


On Mon, 17 Jul 2017 09:59:38 +0200 Francesco Poli wrote:

> On Sun, 16 Jul 2017 22:27:10 +0100 Ben Hutchings wrote:
> 
> [...]
> > If you add 'earlyprintk=ttyS0' to the kernel command line and delete
> > 'quiet', does it log anything?
> 
> Hello Ben,
> thanks for your follow up.
> 
> I have just tried with 'earlyprintk=ttyS0' and without 'quiet', but the
> result seems to be the same:
> 
> Booting a command list
> 
>   Loading Linux 4.11.0-1-686 ...
>   Loading initial ramdisk ...
> 
> and then nothing else.

Hello again,
I tested the new kernel version that has recently migrated to Debian
testing.

Unfortunately, I get the same exact boot failure.

And no useful output on the serial console, even with
'earlyprintk=ttyS0' and without 'quiet':

Booting a command list

  Loading Linux 4.12.0-1-686 ...
  Loading initial ramdisk ...

and then nothing else.


Please note that, after the test, I again booted the machine with the
old Linux 4.9.0-3-686 and noticed "recovering journal" for the root
partition among the boot messages.
Hence, I suppose the root filesystem was mounted in read/write mode
during the failed boot of Linux 4.12.0-1-686.
I don't know whether this piece of information may be useful in order
to pinpoint the issue...

Please let me know, in case you need any further information and/or in
case there's some progress on this bug.

Thanks for your time!

Bye.


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


pgpfUQJZ3OB6J.pgp
Description: PGP signature

Bug#873291: sievec: always fails with the same error message and might be broken at all

[Jelmer Vernooij]

Hi Daniel,

On Sat, Aug 26, 2017 at 10:18:46AM +0200, Daniel Leidert wrote:
> Package: dovecot-sieve
> Version: 1:2.2.27-3+deb9u1
> Severity: normal
> 
> Hello,
> 
> I recently updated my system to the new Debian stable.
> 
> When I try to check my user .sieve files (~/.dovecot.sieve) after altering
> them using:
> 
> > sievec -D -c .dovecot.sieve -d -
> 
> I get the result:
> 
> > doveconf: Fatal: Error in configuration file .dovecot.sieve line 1: 
> > Expecting '{'
> 
> But the mail system operates normally. Sorting and filtering works. No errors
> are reported. Stripping down my .dovecot.sieve to simply contain a "require"
> directive or even if I use one the examples given at the dovecot wiki [1] it
> always fails and reports the error above. To my knowledge, the scripts also
> don't have to start with a '{'.
> 
> So it looks to me, that sievec is broken.
The -c argument is for specifying an alternative dovecot configuration
file (e.g. /etc/dovecot/dovecot.conf), rather than for the actual
sieve file.

You'd want to run:

sievec -D .dovecot.sieve -d -

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#862472: tack: FTBFS: ./tack.h:78:32: error: dereferencing pointer to incomplete type 'TERMINAL {aka struct term}'

[Sven Joachim]

On 2017-07-27 05:06 -0400, Thomas Dickey wrote:

> Debian's package hasn't kept up with any of the other changes in tack.
> Let's see how long it takes for it to be updated to 1.08:
>
> http://invisible-island.net/ncurses/tack/CHANGES.html

Thanks for the new upstream release.  I have prepared a Debian package
at [1], if the maintainer does not respond I will ask for a sponsor.

Cheers,
   Sven


1. https://anonscm.debian.org/git/users/joachim-guest/tack.git/log/?h=nmu

Bug#873303: kvmtool FTBFS with linux-libc-dev >= 4.12

[Adrian Bunk]

Source: kvmtool
Version: 0.20161128-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/kvmtool.html

...
x86/kvm-cpu.c:7:10: fatal error: asm/msr-index.h: No such file or directory
 #include 
  ^
compilation terminated.
Makefile:430: recipe for target 'x86/kvm-cpu.o' failed
make[1]: *** [x86/kvm-cpu.o] Error 1

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

Hi Niels et al,

On 26 August 2017 at 07:22, Niels Thykier wrote:
| Dirk Eddelbuettel:
| > [...]
| > On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
| > | 
| > | Dear release team,
| > | 
| 
| Hi,
| 
| Sorry for the slow up take on our part.

No worries. Releases and Debconfs have a habit of getting in the way :)

So thanks for getting back to me.  It will be good to get to this.
| 
| > | Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.
| > | 
| > | "Ask me anything" -- What (if anything) is missing?  How can I help?
| > 
| 
| Before I schedule these binNMUs, then I need to understand if partial
| upgrades will be handled correctly.  Notably, this case suggests that
| they will not be.

"this case" ?  Can you detail?  I am not following.
 
| If someone was to upgrade R and (for the sake of the example) a rebuilt
| r-cran-logspline, what will ensure that the rest of the affected R
| packages are upgraded (or removed)?

They do not need to as this is NOT an API breakage.  See it rather as a
garden-variety bug on the part of R Core. "They" have an issue affecting a
subset of dyn.loaded modules (not all, just those using .C() or .Fortran())
where the now-required changes messes things up.

This only affects isolotated calls within a package, not across-package
relationships.

It does not require 'dependent rebuilds' as it does not affect other
packages.

In sum, I am _really fairly certain_ that we "just" need these 40+ NMUs.
 
| In a regular ABI bump, everything is rebuilt against a new ABI package
| and the old one is (eventually) removed.  As I understand it, we are not
| doing that here (nor a variant of it), so you would have to use "Breaks"
| to ensure this property holds.  But while Breaks on binNMU versions is
| possible, it can give you headaches if binNMU versions are not in sync
| between architectures.

We _will_ need an ABI nump next spring when real internals change with R as
they gave two or three times in the 15+ years I maintained it.

Not this time.
 
|  * Once the above is clarified/resolved, then we can start binNMUs.

Ok.

I can try to demonstrate the "no we don't" argument by trying to see if I can
recreate the initial bug report on spatial in a testing session, then reinstall
just that (R) package locally (directly from R) where it should work.  I
should have time for that later.  Let me know if it would help.
 
| > Setting severity to 'serious' which is what the one for r-base is tagged 
with
| > at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
| > 
| 
| Generally, most release.d.o bug does not use severity so it does not
| really affect anything (except it splits our bug ordering up, and
| somebody will probably show up and fix that eventually).

Ok. Feel free to set it back.  It was mostly a device to get your attention :)

Best,  Dirk

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

Bug#873249: FTBFS with Java 9: javadoc classpath with maven?

[Emmanuel Bourg]

Hi Chris,

Le 25/08/2017 à 21:41, Chris West a écrit :

> A number of packages seem to be failing to find classes during their
> javadoc build, but they are mostly ant based and I was hoping it was
> just bugs in the build file, not a scary change in the way the javadoc
> tool works. I have no idea what's going on here.

Thanks a lot for the Java 9 FTBFS analysis! I got a quick look at this
javadoc issue, javadoc became more strict wrt to missing class on the
classpath. With Java 8 a warning was displayed, but with Java 9 it's now
an error. The only workaround I've found besides fixing the classpath is
to add the new -Xold javadoc option to revert to the Java 8 behavior.

Do you know how many packages are affected by this issue?

Emmanuel Bourg

Bug#873288: tack: debian/watch is no longer functional

[Sven Joachim]

On 2017-08-26 09:53 +0200, Sven Joachim wrote:

> Source: tack
> Version: 1.07-1
> Tags: patch
>
> The watchfile in tack no longer works, the connection times out, see
> https://lists.gnu.org/archive/html/bug-ncurses/2017-08/msg7.html.
> Attached is a patch that works for me.

Actually it would also be good to check the GPG signature which upstream
provides.  Patch can be found at [1].

Cheers,
   Sven


1. 
https://anonscm.debian.org/git/users/joachim-guest/tack.git/commit/?h=nmu&id=4e883dc2fc54820f5610effde3894e47cbf4c353

Bug#868122: once again update blocked

[Grand T]

Once again update blocked, no window displayed to ask me what I want to do with 
minidlna configuration


I have to finish the update manually 


apt full-upgrade
E: dpkg a été interrompu. Il est nécessaire d'utiliser « dpkg --configure -a » 
pour corriger le problème.
root@debian:/# dpkg --configure -a
Paramétrage de libbinutils:amd64 (2.29-7) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.24-14) ...
Paramétrage de minidlna (1.2.0+dfsg-2) ...
Fichier de configuration « /etc/minidlna.conf »
 ==> Modifié (par vous ou par un script) depuis l'installation.
 ==> Le distributeur du paquet a fourni une version mise à jour.
   Que voulez-vous faire ? Vos options sont les suivantes :
Y ou I  : installer la version du responsable du paquet
N ou O  : garder votre version actuellement installée
  D : afficher les différences entre les versions
  Z : suspendre ce processus pour examiner la situation
 L'action par défaut garde votre version actuelle.
*** minidlna.conf (Y/I/N/O/D/Z) [défaut=N] ?
Traitement des actions différées (« triggers ») pour gnome-menus (3.13.3-9) ...
Traitement des actions différées (« triggers ») pour hicolor-icon-theme 
(0.15-1) ...
Paramétrage de binutils-x86-64-linux-gnu (2.29-7) ...
Paramétrage de binutils (2.29-7) ...
root@debian:/home/guy# apt full-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Bug#873201: openssh-client: command line parsing with -- between option and non-option arguments completely broken

[Colin Watson]

Control: tag -1 fixed-upstream

On Fri, Aug 25, 2017 at 04:57:58PM +, Thorsten Glaser wrote:
> Colin Watson dixit:
> >I have forwarded your report upstream as
> 
> Thanks.
> 
> >https://bugzilla.mindrot.org/show_bug.cgi?id=2766.  If you can, please
> >(if necessary) create an account on that Bugzilla instance and add
> 
> Hm, that bugzilla was not listed on their site either. But for a
> drive-by bugreport I’m not very inclined to create an account
> somewhere which I’ll forget later anyway.

Upstream noted that they in fact fixed this a couple of weeks ago, so
it'll be in 7.6.

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

Bug#873249: FTBFS with Java 9: javadoc classpath with maven?

[solo-debianbugs]

On Sat, Aug 26, 2017 at 12:25:16PM +0200, Emmanuel Bourg wrote:
> With Java 8 a warning was displayed, but with Java 9 it's now
> an error. The only workaround I've found besides fixing the classpath is
>
> Do you know how many packages are affected by this issue?

I'd guess ~4 of the ~50 I looked at, so maybe 30 packages total? I can't
grep up a better answer as many packages fail their build before getting
to the javadoc generation.

This one specifically is weird as it's maven, and maven is probably
supposed to be using the same classpath for the build as for the javadoc
generation. And the main build has succeeded, or we wouldn't be here.

Bug#868779: clang: produces unusable binaries on armv5tel

[Adrian Bunk]

Control: severity -1 serious
Control: tags -1 patch
Control: clone -1 -2 -3 -4 -5
Control: reassign -1 clang-3.8
Control: reassign -2 clang-3.9
Control: reassign -3 clang-4.0
Control: reassign -4 clang-5.0
Control: reassign -5 clang-6.0

On Wed, Jul 19, 2017 at 03:06:23PM +0100, Ian Chard wrote:
> Hi,
> 
> After a bit of digging I found that using the clang option '-march=armv5t'
> fixes this for me.

Thanks for the report and debugging.

The problem is that clang currently takes the default from whatever CPU 
is on the machine thaqt built LLVM, and the Debian buildds are v7:

(stretch_armel-dchroot)bunk@abel:~$ clang-3.8 -dM -E - < /dev/null | grep 
"__ARM_ARCH "
#define __ARM_ARCH 7
(stretch_armel-dchroot)bunk@abel:~$ 

Packages in Debian built with clang (that are thankfully only few)
can also end up violating the armel baseline due to that.

Fix (tested with 3.8):

--- debian/rules.old2017-08-25 22:45:31.957021979 +
+++ debian/rules2017-08-25 22:45:36.251972982 +
@@ -55,6 +55,8 @@
   # 3.8 fails to build, disable the compiler_rt builtins
   # See http://lists.llvm.org/pipermail/llvm-dev/2016-May/099761.html
   CMAKE_EXTRA += -DCOMPILER_RT_BUILD_BUILTINS=OFF
+  # Prevent clang from getting a > v4t default
+  CMAKE_EXTRA += -DLLVM_HOST_TRIPLE=arm-linux-gnueabi
 endif
 
 ifeq ($(shell dpkg --compare-versions $(shell dpkg-query -W -f '$${Version}' 
g++-$(GCC_VERSION)) ge 4.8-20121128-1~ ; echo $$?),0)


> Cheers
> - Ian

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#873308: Please update: FTBFS with Java 9

[Chris West]

Source: rome
Version: 1.0
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9
Tags: fixed-upstream

This package fails to build with default-jdk pointing to openjdk-9-jdk.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

This package is very outdated; upstream fixed this problem (by accident)
in ~2014; it's a trivial issue with an import. Updating also fixes the
build system to be good, and lots of other weirdness around packages
that is probably going to be a problem with something Java 9.

Build log:
find com -name *.java -and -type f -print0 | xargs -s 512000 -0 
/usr/lib/jvm/default-java/bin/javac -g -cp 
/usr/share/java/jdom1.jar:debian/_jh_build.rome -d debian/_jh_build.rome 
-source 1.7 -target 1.7 -encoding ISO8859-1
warning: [options] bootstrap class path not set in conjunction with -source 1.7
com/sun/syndication/feed/synd/SyndFeedImpl.java:643: error: reference to Module 
is ambiguous
public Module getModule(String uri) {


Cheers,
Chris.

Bug#873309: stretch-pu: package request-tracker4/4.4.1-3+deb9u3

[Dominic Hargreaves]

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

A regression was discovered in the latest security patch update for
RT which can cause incorrect UTF-8 encoded passwords to cause an
application error. This is not in itself considered a security
problem.

The attached debdiff applies a patch which has been included in the
official upstream releases including the security fixes.

Thanks for considering!

Dominic.
diff -Nru request-tracker4-4.4.1/debian/changelog request-tracker4-4.4.1/debian/changelog
--- request-tracker4-4.4.1/debian/changelog	2017-07-06 15:10:40.0 +0100
+++ request-tracker4-4.4.1/debian/changelog	2017-08-25 23:53:15.0 +0100
@@ -1,3 +1,10 @@
+request-tracker4 (4.4.1-3+deb9u3) UNRELEASED; urgency=medium
+
+  * Fix regression in previous security release where incorrect
+SHA256 passwords could trigger an error
+
+ -- Dominic Hargreaves   Fri, 25 Aug 2017 23:50:45 +0100
+
 request-tracker4 (4.4.1-3+deb9u2) stretch; urgency=medium
 
   * Handle configuration permissions correctly following
diff -Nru request-tracker4-4.4.1/debian/.git-dpm request-tracker4-4.4.1/debian/.git-dpm
--- request-tracker4-4.4.1/debian/.git-dpm	2017-07-06 11:12:02.0 +0100
+++ request-tracker4-4.4.1/debian/.git-dpm	2017-08-25 23:50:44.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-e272152dd37ff075d41052fbe599fb23040bb426
-e272152dd37ff075d41052fbe599fb23040bb426
+6700f66c21e5baa6b59ef7ac5aed226d9bf96bfb
+6700f66c21e5baa6b59ef7ac5aed226d9bf96bfb
 63ca1094b0eb53bf86eef426b17dc0080a1a1f8e
 63ca1094b0eb53bf86eef426b17dc0080a1a1f8e
 request-tracker4_4.4.1.orig.tar.gz
diff -Nru request-tracker4-4.4.1/debian/patches/is_password_binary.patch request-tracker4-4.4.1/debian/patches/is_password_binary.patch
--- request-tracker4-4.4.1/debian/patches/is_password_binary.patch	1970-01-01 01:00:00.0 +0100
+++ request-tracker4-4.4.1/debian/patches/is_password_binary.patch	2017-08-25 23:50:44.0 +0100
@@ -0,0 +1,78 @@
+From 6700f66c21e5baa6b59ef7ac5aed226d9bf96bfb Mon Sep 17 00:00:00 2001
+From: Shawn M Moore 
+Date: Mon, 10 Jul 2017 11:48:28 -0400
+Subject: Add a "binary" option to opt out of UTF8 encoding
+
+The SHA256 branch of IsPassword generates binary values to compare,
+which may lead to comparing two strings with a different number of
+Unicode characters, even when both strings have 26 octets (since UTF8 is
+a variable-length encoding). This triggers an error in constant_time_eq
+which demands both strings are the same length.
+
+When comparing binary values pass this flag to avoid treating the
+inputs as UTF8.
+
+Patch-Name: is_password_binary.patch
+---
+ lib/RT/User.pm |  2 +-
+ lib/RT/Util.pm | 20 
+ 2 files changed, 17 insertions(+), 5 deletions(-)
+
+diff --git a/lib/RT/User.pm b/lib/RT/User.pm
+index 0e86d44..3ced5ce 100644
+--- a/lib/RT/User.pm
 b/lib/RT/User.pm
+@@ -1110,7 +1110,7 @@ sub IsPassword {
+ my $salt = substr($hash, 0, 4, "");
+ return 0 unless RT::Util::constant_time_eq(
+ substr(Digest::SHA::sha256($salt . Digest::MD5::md5(Encode::encode( "UTF-8", $value))), 0, 26),
+-$hash
++$hash, 1
+ );
+ } elsif (length $stored == 32) {
+ # Hex nonsalted-md5
+diff --git a/lib/RT/Util.pm b/lib/RT/Util.pm
+index 47b1dd2..1a040b9 100644
+--- a/lib/RT/Util.pm
 b/lib/RT/Util.pm
+@@ -166,6 +166,9 @@ The two string arguments B be of equal length. If the lengths differ,
+ this function will call C, as proceeding with execution would create
+ a timing vulnerability. Length is defined by characters, not bytes.
+ 
++Strings that should be treated as binary octets rather than Unicode text
++should pass a true value for the binary flag.
++
+ This code has been tested to do what it claims. Do not change it without
+ thorough statistical timing analysis to validate the changes.
+ 
+@@ -177,7 +180,7 @@ B
+ =cut
+ 
+ sub constant_time_eq {
+-my ($a, $b) = @_;
++my ($a, $b, $binary) = @_;
+ 
+ my $result = 0;
+ 
+@@ -191,9 +194,18 @@ sub constant_time_eq {
+ my $a_char = substr($a, $i, 1);
+ my $b_char = substr($b, $i, 1);
+ 
+-# encode() is set to die on malformed
+-my @a_octets = unpack("C*", encode('UTF-8', $a_char, Encode::FB_CROAK));
+-my @b_octets = unpack("C*", encode('UTF-8', $b_char, Encode::FB_CROAK));
++my (@a_octets, @b_octets);
++
++if ($binary) {
++@a_octets = ord($a_char);
++@b_octets = ord($b_char);
++}
++else {
++# encode() is set to die on malformed
++@a_octets = unpack("C*", encode('UTF-8', $a_char, Encode::FB_CROAK));
++@b_octets = unpack("C*", encode('UTF-8', $b_char, Encode::FB_CROAK));
++}
++
+ die $generic_error if (scalar @a_octets) != (scalar @b_octets);
+ 
+ for (my $j = 0

Bug#802241: please store the hash of the installed .deb and allow to query it

[Julian Andres Klode]

On Sun, Oct 18, 2015 at 06:20:01PM +, Mattia Rizzolo wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: wishlist
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Hi dpkg people,
> 
> in the context of allowing to recreate the same build-environment of a
> past build we would need to know which packages where installed.
> Currently we rely on (pkgname, arch, version) tuples to uniquely
> identify a binary package, but as you can easily imagine this is not
> unique at all, definitly not in the multi distro universe, possibly not
> even across suites.

I also want this for delta debs, to identify local rebuilds being
installed, and prevent delta installation failure in such cases.

> 
> To me it seems that:
> * we are mostly interested in the hash of the whole container: all the
>   use cases highlighted above would require this;
> * If ↑ then the hash can't be pre-computed and stored inside the
>   container.

Practically speaking, for your use case you only need a hash of the
file tree. My proposal for a package id is to use the md5sum of
DEBIAN/md5sums. This can be stored in DEBIAN/control in an id
field and generated at build time. 

We can also use cat DEBIAN/md5sums DEBIAN/control | md5sum (without an
Id field in control) as the ID, and then append that to control. This
means that dependency relations and stuff is included as well. That's
useful for the solver use case; but it's not really relevant for
the reproducible build use case - dependencies on the installed
system, description, etc should not matter for you.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#873310: jessie-pu: package request-tracker4/4.2.8-3+deb8u3

[Dominic Hargreaves]

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

A regression was discovered in the latest security patch update for
RT which can cause incorrect UTF-8 encoded passwords to cause an
application error. This is not in itself considered a security
problem.

The attached debdiff applies a patch which has been included in the
official upstream releases including the security fixes.

Thanks for considering!

Dominic.
diff -Nru request-tracker4-4.2.8/debian/changelog request-tracker4-4.2.8/debian/changelog
--- request-tracker4-4.2.8/debian/changelog	2017-06-10 23:25:15.0 +0100
+++ request-tracker4-4.2.8/debian/changelog	2017-08-26 00:05:00.0 +0100
@@ -1,3 +1,10 @@
+request-tracker4 (4.2.8-3+deb8u3) UNRELEASED; urgency=medium
+
+  * Fix regression in previous security release where incorrect
+SHA256 passwords could trigger an error
+
+ -- Dominic Hargreaves   Sat, 26 Aug 2017 00:04:25 +0100
+
 request-tracker4 (4.2.8-3+deb8u2) jessie-security; urgency=high
 
   * Fix FTBFS due to base.pm changes (Closes: #864302)
diff -Nru request-tracker4-4.2.8/debian/.git-dpm request-tracker4-4.2.8/debian/.git-dpm
--- request-tracker4-4.2.8/debian/.git-dpm	2017-06-10 23:24:20.0 +0100
+++ request-tracker4-4.2.8/debian/.git-dpm	2017-08-26 00:04:21.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-0585d038ba908af5d49c48ddeb1394b2f3579331
-0585d038ba908af5d49c48ddeb1394b2f3579331
+dc3c256430c25518b42020ae1f85924aeb6930c4
+dc3c256430c25518b42020ae1f85924aeb6930c4
 21890d09947710ac3f48ddd306fe5b6a50f5bbe9
 21890d09947710ac3f48ddd306fe5b6a50f5bbe9
 request-tracker4_4.2.8.orig.tar.gz
diff -Nru request-tracker4-4.2.8/debian/patches/is_password_binary.patch request-tracker4-4.2.8/debian/patches/is_password_binary.patch
--- request-tracker4-4.2.8/debian/patches/is_password_binary.patch	1970-01-01 01:00:00.0 +0100
+++ request-tracker4-4.2.8/debian/patches/is_password_binary.patch	2017-08-26 00:04:21.0 +0100
@@ -0,0 +1,78 @@
+From dc3c256430c25518b42020ae1f85924aeb6930c4 Mon Sep 17 00:00:00 2001
+From: Shawn M Moore 
+Date: Mon, 10 Jul 2017 11:48:28 -0400
+Subject: Add a "binary" option to opt out of UTF8 encoding
+
+The SHA256 branch of IsPassword generates binary values to compare,
+which may lead to comparing two strings with a different number of
+Unicode characters, even when both strings have 26 octets (since UTF8 is
+a variable-length encoding). This triggers an error in constant_time_eq
+which demands both strings are the same length.
+
+When comparing binary values pass this flag to avoid treating the
+inputs as UTF8.
+
+Patch-Name: is_password_binary.patch
+---
+ lib/RT/User.pm |  2 +-
+ lib/RT/Util.pm | 20 
+ 2 files changed, 17 insertions(+), 5 deletions(-)
+
+diff --git a/lib/RT/User.pm b/lib/RT/User.pm
+index dba5b6f..e8c0be5 100644
+--- a/lib/RT/User.pm
 b/lib/RT/User.pm
+@@ -1006,7 +1006,7 @@ sub IsPassword {
+ my $salt = substr($hash, 0, 4, "");
+ return 0 unless RT::Util::constant_time_eq(
+ substr(Digest::SHA::sha256($salt . Digest::MD5::md5(Encode::encode( "UTF-8", $value))), 0, 26),
+-$hash
++$hash, 1
+ );
+ } elsif (length $stored == 32) {
+ # Hex nonsalted-md5
+diff --git a/lib/RT/Util.pm b/lib/RT/Util.pm
+index 014f232..86e96ad 100644
+--- a/lib/RT/Util.pm
 b/lib/RT/Util.pm
+@@ -166,6 +166,9 @@ The two string arguments B be of equal length. If the lengths differ,
+ this function will call C, as proceeding with execution would create
+ a timing vulnerability. Length is defined by characters, not bytes.
+ 
++Strings that should be treated as binary octets rather than Unicode text
++should pass a true value for the binary flag.
++
+ This code has been tested to do what it claims. Do not change it without
+ thorough statistical timing analysis to validate the changes.
+ 
+@@ -177,7 +180,7 @@ B
+ =cut
+ 
+ sub constant_time_eq {
+-my ($a, $b) = @_;
++my ($a, $b, $binary) = @_;
+ 
+ my $result = 0;
+ 
+@@ -191,9 +194,18 @@ sub constant_time_eq {
+ my $a_char = substr($a, $i, 1);
+ my $b_char = substr($b, $i, 1);
+ 
+-# encode() is set to die on malformed
+-my @a_octets = unpack("C*", encode('UTF-8', $a_char, Encode::FB_CROAK));
+-my @b_octets = unpack("C*", encode('UTF-8', $b_char, Encode::FB_CROAK));
++my (@a_octets, @b_octets);
++
++if ($binary) {
++@a_octets = ord($a_char);
++@b_octets = ord($b_char);
++}
++else {
++# encode() is set to die on malformed
++@a_octets = unpack("C*", encode('UTF-8', $a_char, Encode::FB_CROAK));
++@b_octets = unpack("C*", encode('UTF-8', $b_char, Encode::FB_CROAK));
++}
++
+ die $generic_error if (scalar @a_octets) != (scalar @b_octets);
+ 
+ for (my $j 

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

So I tried that -- and I cannot currently tickle the bug:

 -- r-cran-spatial (from the initial bug report) was long rebuilt by me
 
 -- r-cran-logspline (which you mentioned) is actually no longer on my
refined (shorter) list, no issues there

 -- r-cran-data.table (on my list) is a false positive, the one grep()
find is actually in commented-out code (but hey, the maintainer is a
slacker too as the package had two updates not reflected yet...)

 -- r-cran-rcurl just works too, there is one .C() call in getCurlInfo()
and it all passes as well.

In short I can NOT currently reproduce the issue on Debian unstable.

So this may be a huge nothingburger (and another reason not to enforce an
API-tag rebuild over 500+ packages).

Dirk

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

Bug#873275: always segfaults at start due to QSslSocket

[Lisandro Damián Nicanor Pérez Meyer]

First of all sorry for the top posting. Actually this is not a bug in qt4,
OpenSSL 1.0 Is getting removed and qt4 *needs* to switch to 1.1. I uploaded
to experimental for people to check, so actually this should be an
important bug against qgis. If necessary I'll explain more with a more
comfortable mail client at hand.

El 26 ago. 2017 8:36 a.m., "Adrian Bunk"  escribió:

Control: reopen -1
Control: severity -1 serious
Control: tags -1 - moreinfo
Control: tags -1 confirmed
Control: reassign -1 src:qt4-x11 4:4.8.7+dfsg-12
Control: affects -1 qgis

On Sat, Aug 26, 2017 at 08:45:21AM +0200, Sebastiaan Couwenberg wrote:
> tags 873275 unreproducible
> severity 873275 normal
> thanks
>
> qgis works fine here.
>
> On 08/26/2017 03:11 AM, 積丹尼 Dan Jacobson wrote:
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers experimental
>
> This likely caused your problem, you shouldn't prefer experimental over
> unstable.
>...

This is supposed to work when the dependencies allow it,[1]
and such bug reports can be quite valuable for finding regressions
before they hit a large userbase in unstable.

Likely causes for such problems include for example library ABI changes
without a corresponding change of the so-name.

Based on the information in the bug it was in this case trivial to
narrow the regression down to Qt4 in experimental switching to
OpenSSL 1.1 - qgis works for me with Qt4 from stable/unstable
and segfaults as describes by Dan with Qt4 from experimental.

> Kind Regards,
>
> Bas

cu
Adrian

[1] apt preferring experimental is IMHO not a good idea,
but that doesn't turn bugs into non-bugs

--

   "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#867733: closed by Dmitry Shachnev (Bug#867733: fixed in pyqt5 5.7+dfsg-6)

[Linus Lüssing]

On Wed, Aug 23, 2017 at 01:37:44PM +0300, Dmitry Shachnev wrote:
> This armhf build bot is currently building Qt WebEngine itself.
> If it succeeds then pyqt5 should be also built soon.
> 
> The mipsel build of python3-pyqt5.qtwebengine is now available.
> 

Thanks a lot, Dmitry - installs just fine now! :-)

Regards, Linus

Bug#873311: mozjs: Please keep out of testing/buster

[Laurent Bigonville]

Source: mozjs
Version: 1.8.5-1.0.0+dfsg-7
Severity: serious
Tags: sid buster

Hi,

mozjs is really old and shouldn't be part of buster.

Please keep this package out of buster.

Regards,

Laurent Bigonville

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

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

Bug#873312: python-simpy3-doc and python-simpy-doc: error when trying to install together

[Ralf Treinen]

Package: python-simpy-doc,python-simpy3-doc
Version: python-simpy-doc/2.3.1+dfsg-1
Version: python-simpy3-doc/3.0.10-2
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2017-08-26
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libjs-jquery.
(Reading database ... 11002 files and directories currently installed.)
Preparing to unpack .../libjs-jquery_3.1.1-2_all.deb ...
Unpacking libjs-jquery (3.1.1-2) ...
Selecting previously unselected package libjs-underscore.
Preparing to unpack .../libjs-underscore_1.8.3~dfsg-1_all.deb ...
Unpacking libjs-underscore (1.8.3~dfsg-1) ...
Selecting previously unselected package libjs-sphinxdoc.
Preparing to unpack .../libjs-sphinxdoc_1.5.6-2_all.deb ...
Unpacking libjs-sphinxdoc (1.5.6-2) ...
Selecting previously unselected package python3.5-doc.
Preparing to unpack .../python3.5-doc_3.5.4-2_all.deb ...
Unpacking python3.5-doc (3.5.4-2) ...
Selecting previously unselected package python3-doc.
Preparing to unpack .../python3-doc_3.5.3-3_all.deb ...
Unpacking python3-doc (3.5.3-3) ...
Selecting previously unselected package python-simpy-doc.
Preparing to unpack .../python-simpy-doc_2.3.1+dfsg-1_all.deb ...
Unpacking python-simpy-doc (2.3.1+dfsg-1) ...
Selecting previously unselected package python-simpy3-doc.
Preparing to unpack .../python-simpy3-doc_3.0.10-2_all.deb ...
Unpacking python-simpy3-doc (3.0.10-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-simpy3-doc_3.0.10-2_all.deb (--unpack):
 trying to overwrite '/usr/share/doc-base/python-simpy', which is also in 
package python-simpy-doc 2.3.1+dfsg-1
Errors were encountered while processing:
 /var/cache/apt/archives/python-simpy3-doc_3.0.10-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/share/doc-base/python-simpy

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.

Bug#873275: always segfaults at start due to QSslSocket

[Adrian Bunk]

On Sat, Aug 26, 2017 at 09:31:01AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> First of all sorry for the top posting. Actually this is not a bug in qt4,
> OpenSSL 1.0 Is getting removed and qt4 *needs* to switch to 1.1.

That's clear.

> I uploaded
> to experimental for people to check, so actually this should be an
> important bug against qgis. If necessary I'll explain more with a more
> comfortable mail client at hand.

The problem as reported by Dan and reproduced by me is:

$ qgis
Warning: QSslSocket: cannot resolve CRYPTO_num_locks
Warning: QSslSocket: cannot resolve CRYPTO_set_id_callback
Warning: QSslSocket: cannot resolve CRYPTO_set_locking_callback
Warning: QSslSocket: cannot resolve sk_free
Warning: QSslSocket: cannot resolve sk_num
Warning: QSslSocket: cannot resolve sk_pop_free
Warning: QSslSocket: cannot resolve sk_value
Warning: QSslSocket: cannot resolve SSL_library_init
Warning: QSslSocket: cannot resolve SSL_load_error_strings
Warning: QSslSocket: cannot resolve X509_get_notAfter
Warning: QSslSocket: cannot resolve X509_get_notBefore
Warning: QSslSocket: cannot resolve SSLv2_client_method
Warning: QSslSocket: cannot resolve SSLv23_client_method
Warning: QSslSocket: cannot resolve SSLv2_server_method
Warning: QSslSocket: cannot resolve SSLv23_server_method
Warning: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
Warning: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
Warning: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
Warning: QSslSocket: cannot resolve SSLeay
Warning: QSslSocket: cannot call unresolved function SSL_library_init
Warning: QSslSocket: cannot call unresolved function SSLv23_client_method
Warning: QSslSocket: cannot call unresolved function sk_num
Warning: QSslSocket: cannot call unresolved function X509_get_notBefore
Warning: QSslSocket: cannot call unresolved function X509_get_notAfter
Segmentation fault


To me this looks like qt4 built with OpenSSL 1.1 trying to use functions 
that were removed in OpenSSL 1.1, example:

  /usr/include/openssl/ssl.h:#define SSLv23_client_methodTLS_client_method


In OpenSSL 1.0.2 this was a proper function, but qt4 trying to load this 
from libssl.so.1.1 cannot work.


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#873313: mnemosyne: "NameError: name 'file' is not defined"

[linus . luessing]

Package: mnemosyne
Version: 2.4-0.1
Severity: normal

Hi,

When trying to start mnemosyne, I'm getting/got the following error
message right at the beginning:

~~
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/bin/mnemosyne", line 229, in 
debug_file=options.debug_file)
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 190, in initialise
Upgrade3(self.component_manager).run()
  File 
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/upgrades/upgrade3.py", 
line 21, in run
file(os.path.join(self.config().config_dir, "config"), "rb")
 NameError: name 'file' is not defined
~~

I tried removing my old "~/.mnemosyne" config folder, but that did not
help. What did help though: Removing "~/.config/mnemosyne.

See the attachment, mnemosyne.tar.xz, for a copy of the
~/.config/mnemosyne causing the crash.

I hadn't used mnemosyne for quite a while. In fact, the configs were
probably from back when I had them on an x86 machine (now it's armhf).

Regards, Linus


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.2.3-00234-g11acd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mnemosyne depends on:
ii  libjs-sphinxdoc 1.5.6-2
ii  libqt5sql5-sqlite   5.9.1+dfsg-9
ii  python3 3.5.3-3
ii  python3-cherrypy3   3.5.0-2
ii  python3-matplotlib  2.0.0+dfsg1-2+b1
ii  python3-pyqt5   5.7+dfsg-6
ii  python3-pyqt5.qtsql 5.7+dfsg-6
ii  python3-pyqt5.qtwebchannel  5.7+dfsg-6
ii  python3-pyqt5.qtwebengine   5.7+dfsg-6
ii  python3-webob   1:1.6.2-2

mnemosyne recommends no packages.

mnemosyne suggests no packages.

-- no debconf information


mnemosyne.tar.xz
Description: application/xz

Bug#873243: pkg-kde-tools: pkgkde-vcs tag do not handle distribution names

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 25 de agosto de 2017 20:31:04 -03 Sandro Knauß wrote:
> Package: pkg-kde-tools
> Version: 0.15.24
> Severity: normal
> Control: tag -1 +patch
> 
> Hey,
> 
> i actually uploading the fixes for jessie and stretch for CVE-2017-9604.
> #869573
> #869574
> #869577
> 
> and therefor I have in the distribution field stretch/jessie and this is
> not handled.
> $pkgkde-vcs tag -s
> pkgkde-vcs: fatal: invalid Debian distribution for tagging - stretch
> 
> or
> $pkgkde-vcs tag -s
> pkgkde-vcs: fatal: invalid Debian distribution for tagging - jessie

Even if we fix pkgkde-tools I *think* we also need to fix the hooks in the 
repo.


-- 
 SlackDeb: velo como un entrenamiento shaolin para geeks,
en vez de meditación y tortura física, abstinencia de internet y sexo
  Horacio Francisco Sebastián "Perrito" Durán Barrionuevo, sobre un
  viaje que Federico "SlackDeb" Peretti estaba planeando con su novia.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#871709: mercurial: CVE-2017-1000115: path traversal via symlink

[Salvatore Bonaccorso]

Hi

On Fri, Aug 25, 2017 at 11:52:45AM -0700, Peter Linss wrote:
> Any chance of getting this fix backported to stretch?

Yes, this is beeing worked on (and as well for jessie).

Regards,
Salvatore

Bug#828522: Reopening

[Lisandro Damián Nicanor Pérez Meyer]

reopen 828522
tag 828522 - patch
thanks

Looking at [bug] it seems that the proposed patch is not enough.

[bug] 

It seems that Qt4 is still wanting to access OpenSSL 1.0's functions.

-- 
Without us [Free Software developers], people would study computer science
and programming without ever having seen a real program in its entirety.
That's like becoming writers without ever having read a complete book.
  Matthias Ettrich, founder of the KDE project.
  http://www.efytimes.com/efytimes/25412/news.htm

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#872406: baresip: diff for NMU version 0.5.4-1.1

[Sebastian Ramacher]

Control: tags 872406 + patch
Control: tags 872406 + pending

Dear maintainer,

I've prepared an NMU for baresip (versioned as 0.5.4-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru baresip-0.5.4/debian/changelog baresip-0.5.4/debian/changelog
--- baresip-0.5.4/debian/changelog	2017-07-03 12:57:00.0 +0200
+++ baresip-0.5.4/debian/changelog	2017-08-26 11:41:57.0 +0200
@@ -1,3 +1,12 @@
+baresip (0.5.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  
+  [ Steve Langasek ]
+  * Build with -D_GNU_SOURCE to fix FTBFS with GCC 7. (Closes: #872406)
+
+ -- Sebastian Ramacher   Sat, 26 Aug 2017 11:41:57 +0200
+
 baresip (0.5.4-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru baresip-0.5.4/debian/patches/gcc-7-compat.patch baresip-0.5.4/debian/patches/gcc-7-compat.patch
--- baresip-0.5.4/debian/patches/gcc-7-compat.patch	1970-01-01 01:00:00.0 +0100
+++ baresip-0.5.4/debian/patches/gcc-7-compat.patch	2017-08-26 11:40:58.0 +0200
@@ -0,0 +1,20 @@
+Description: Use -D_GNU_SOURCE for gcc-7 compatibility
+ baresip fails to build with gcc-7 because libdirectfb-dev needs to know
+ the size of struct timespec, which is an opaque type unless we're using
+ GNU extensions, but libre-dev sets -std=c99.  Adjust cflags to enable
+ _GNU_SOURCE.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/872406
+
+Index: baresip-0.5.4/Makefile
+===
+--- baresip-0.5.4.orig/Makefile
 baresip-0.5.4/Makefile
+@@ -49,6 +49,7 @@
+ CFLAGS+= -I. -Iinclude -I$(LIBRE_INC) -I$(SYSROOT)/include
+ CFLAGS+= -I$(LIBREM_PATH)/include
+ CFLAGS+= -I$(SYSROOT)/local/include/rem -I$(SYSROOT)/include/rem
++CFLAGS+= -D_GNU_SOURCE
+ 
+ CXXFLAGS  += -I. -Iinclude -I$(LIBRE_INC)
+ CXXFLAGS  += -I$(LIBREM_PATH)/include
diff -Nru baresip-0.5.4/debian/patches/series baresip-0.5.4/debian/patches/series
--- baresip-0.5.4/debian/patches/series	2017-07-03 12:04:40.0 +0200
+++ baresip-0.5.4/debian/patches/series	2017-08-26 11:40:58.0 +0200
@@ -1 +1,2 @@
 2001_drop_libre_so_check.patch
+gcc-7-compat.patch


signature.asc
Description: PGP signature

Bug#873314: golang-github-lib-pq-dev: Please package new snapshot

[Simon Ruderich]

Package: golang-github-lib-pq-dev
Version: 0.0~git20151007.0.ffe986a-1
Severity: wishlist

The current version in Debian is quite old and misses important
features like Arrays. Please consider packaging the latest
Git version.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#802241: please store the hash of the installed .deb and allow to query it

[Mattia Rizzolo]

On Sat, Aug 26, 2017 at 02:14:16PM +0200, Julian Andres Klode wrote:
> I also want this for delta debs, to identify local rebuilds being
> installed, and prevent delta installation failure in such cases.

yay another user!

> > To me it seems that:
> > * we are mostly interested in the hash of the whole container: all the
> >   use cases highlighted above would require this;
> > * If ↑ then the hash can't be pre-computed and stored inside the
> >   container.
> 
> Practically speaking, for your use case you only need a hash of the
> file tree. My proposal for a package id is to use the md5sum of
> DEBIAN/md5sums. This can be stored in DEBIAN/control in an id
> field and generated at build time. 

That's not true, as we need the hash also (for example) of all the
maintainer scripts which are not in data.tar (I assume that's what you
meant by "file tree").  Also, we have seen packages where the only
difference is the order of entry in the md5sums file, therefore making
the build not reproducible by our (higher than policy) standards.
We really need the whole container.

> We can also use cat DEBIAN/md5sums DEBIAN/control | md5sum (without an
> Id field in control) as the ID, and then append that to control. This
> means that dependency relations and stuff is included as well. That's
> useful for the solver use case; but it's not really relevant for
> the reproducible build use case - dependencies on the installed
> system, description, etc should not matter for you.

Well, DEBIAN/control contains the dependencies generated during the
package build, and we do are interested in them as well…
In short: we do care about both data.tar and control.tar.  After all, we
do compare the hashes of the final .deb container.


As I saw it when I originally thought of the problem the only sane
solution to this for me would be to have dpkg compute the hash of the
.deb before unpacking it, and store in it's $admindir/status file, but
that makes the installation process very CPU-intensive, to the point
that very probably it's too much to be bareable in many systems.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#870463: lp no longer honours default printers

[Didier 'OdyX' Raboud]

Hi there martin, and thanks for your bugreport,

Le mercredi, 2 août 2017, 10.22:13 h CEST martin f krafft a écrit :
> Possibly related to #867818, /usr/bin/lp no longer honours a default
> printer configured:
> 
>   albatross:~/FOR_FILING% head -1 ~/.cups/lpoptions
>   Default mfc9465cdn
>   albatross:~/FOR_FILING% lp -P 30 2017-08-02-Scans.pdf
>   lp: Error - no default destination available.

I can't reproduce this; it works fine here for me. Let's see from some things 
fixed upstream:
* https://github.com/apple/cups/issues/5072 - Do you happen to use a 
ServerAlias ?
* https://github.com/apple/cups/commit/
c536b6c583abd9ea1b750f15e887b313ed7ad951 maybe ?

Can you rebuild cups with these patches or would you like me to build a 
patched version for you? (I'd probably upload an upstream snapshot to 
experimental then)

Cheers,
OdyX

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

Bug#873295: function keys not working on debian testing/sid

[Stephan Voeth]

Same Problem here after running latest upgrades on testing
(4.12.0-1-amd64 - with two different machines).

On desktop machine the volume keys and terminal shotcut aren't working
(STRG+ALT+T). On thinkpad the brightness can't be adjusted by using the
FN+Keys. But pressing them ist registered by the system (i can set them
at the keyboard settings).

But it probably isn't a bug in cinnamon directly because it wasn't upgraded.
Last upgrade before yesterday was at the 13th.

Bug#873275: always segfaults at start due to QSslSocket

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 26 de agosto de 2017 15:50:14 -03 Adrian Bunk wrote:
> On Sat, Aug 26, 2017 at 09:31:01AM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > First of all sorry for the top posting. Actually this is not a bug in qt4,
> > OpenSSL 1.0 Is getting removed and qt4 *needs* to switch to 1.1.
> 
> That's clear.
> 
> > I uploaded
> > to experimental for people to check, so actually this should be an
> > important bug against qgis. If necessary I'll explain more with a more
> > comfortable mail client at hand.
> 
> The problem as reported by Dan and reproduced by me is:
[snip] 
> To me this looks like qt4 built with OpenSSL 1.1 trying to use functions
> that were removed in OpenSSL 1.1, example:
> 
>   /usr/include/openssl/ssl.h:#define SSLv23_client_method   
> TLS_client_method
> 
> 
> In OpenSSL 1.0.2 this was a proper function, but qt4 trying to load this
> from libssl.so.1.1 cannot work.

Indeed, so the upload did work after all: we now know that the proposed patch 
is not enough.

Sebbastiaan: we might need to remove SSL support in Qt4 I'm afraid. How is the 
qt5 port going?

-- 
En los momentos de crisis, la imaginación es mas importante que el
conocimiento.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#802241: please store the hash of the installed .deb and allow to query it

[Julian Andres Klode]

On Sat, Aug 26, 2017 at 03:16:52PM +0200, Mattia Rizzolo wrote:
> On Sat, Aug 26, 2017 at 02:14:16PM +0200, Julian Andres Klode wrote:
> > I also want this for delta debs, to identify local rebuilds being
> > installed, and prevent delta installation failure in such cases.
> 
> yay another user!
> 
> > > To me it seems that:
> > > * we are mostly interested in the hash of the whole container: all the
> > >   use cases highlighted above would require this;
> > > * If ↑ then the hash can't be pre-computed and stored inside the
> > >   container.
> > 
> > Practically speaking, for your use case you only need a hash of the
> > file tree. My proposal for a package id is to use the md5sum of
> > DEBIAN/md5sums. This can be stored in DEBIAN/control in an id
> > field and generated at build time. 
> 
> That's not true, as we need the hash also (for example) of all the
> maintainer scripts which are not in data.tar (I assume that's what you
> meant by "file tree").  Also, we have seen packages where the only
> difference is the order of entry in the md5sums file, therefore making
> the build not reproducible by our (higher than policy) standards.
> We really need the whole container.

I don't see why you need maintainer scripts. When you are building
a package what you care about is the state you are building in. And
the maintainer scripts are irrelevant in that state. But well, you could
hash them too.

> 
> > We can also use cat DEBIAN/md5sums DEBIAN/control | md5sum (without an
> > Id field in control) as the ID, and then append that to control. This
> > means that dependency relations and stuff is included as well. That's
> > useful for the solver use case; but it's not really relevant for
> > the reproducible build use case - dependencies on the installed
> > system, description, etc should not matter for you.
> 
> Well, DEBIAN/control contains the dependencies generated during the
> package build, and we do are interested in them as well…
> In short: we do care about both data.tar and control.tar.  After all, we
> do compare the hashes of the final .deb container.

I fail to see why you'd be interested in dependencies. Your stated use
case is "allowing to recreate the same build-environment of a past build
we would need to know which packages where installed.". To recreate a 
build environment you do not have to care about dependencies, nor do
you have to care about maintainer scripts (as soon as you involve
upgrades, the result might be different anyway, if you always bootstrap
the exact tree, it might be useful). Because the matter of fact is that
neither maintainer scripts nor dependencies affect how a package is
built (once build-depends are installed).

There's also the question of conffiles. They might affect the environment,
but: The actually installed ones might be different from the ones in the
package (which essentially is the same upgrade problem you have for
maintainer scripts); hence it's not really useful to include them in
the hash (but it does not hurt either).

> As I saw it when I originally thought of the problem the only sane
> solution to this for me would be to have dpkg compute the hash of the
> .deb before unpacking it, and store in it's $admindir/status file, but
> that makes the installation process very CPU-intensive, to the point
> that very probably it's too much to be bareable in many systems.

If you really want everything, the wise choice is to just hash the
entire tree dpkg-deb is packaging up and then add that to the ID
field. You can easily reconstruct the ID by unpacking the package,
removing the ID field from debian/control and rehashing.

Once mtree is in, this also includes stuff like permissions, xattrs.
Then we can also SHA256 everything and use that as an ID.

The only thing not covered by this is the layout of the tar files,
the compression, and the layout of the final ar file. But that's
not really relevant to any of our use cases.

For APT, we specifically need the ID to be in the package and dpkg
not to add any missing IDs, otherwise we cannot rely on the ID as
the installed one might have one but the remote one not.

For deltas, we only care that it has *some* ID, for what it's worth,
it could be a random UUID (but that's not reproducible). I do need
that to be in debian/control, as this will allow us to change the
ID algorithm at any point in time and not require us to recompute
the id when generating the delta.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#676472: cups: please suggest a compatible inet server (for lpd support)

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix
Control: severity -1 wishlist

Hi there Vincent,

Le jeudi, 7 juin 2012, 17.47:59 h CEST Vincent McIntyre a écrit :
> Somehow my system got installed with update-inetd but not inetutils-inetd.
> 
> I wanted to turn on lpd support so installed cups-bsd.
> update-inetd ran without apparrent errors when I did
>   # dpkg-reconfigure cups-bsd
> to enable the lpd server, but there was no inetd.conf file to append to
> and none was created. No error was indicated.
> 
> Once I installed inetutils-inetd and reconfigured cups-bsd again,
> things worked as expected.
> 
> Possibly this is actually a bug in update-inetd but I'll leave that to
> your discretion.

As of 2017, I tend to think that lpd support should disappear for Buster. Iff 
we'd want to keep it, having cups-bsd get a 
Suggests: inetutils-inetd | inet-superserver, update-inetd
_could_ make sense.

I'm not going to investigate more than that; so if someone wants that in 
2017's CUPS, please answer to this bug by saying so and confirming the above 
strategy makes sense.

Cheers,
OdyX

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

Bug#847570: linux-image-4.9.0-rc8-amd64-unsigned: AMDGPU not build with support for GCN1.0 and GCN1.1 VGAs

[xsellier]

Package: linux-image-4.13.0-rc5-amd64
Version: 4.13~rc5-1~exp1
Severity: wishlist
Tags: patch



Dear maintainers,

I have an AMD Radeon R9 290, and I'd like to use the amdgpu driver (= 
vulkan support) without having to recompile the kernel. As Ferdinand 
Pöll told before:



Since 4.9, linux includes experimental support for GCN 1.0 VGAs, but it's not
enabled in the debian builds as well as the support for GCN 1.1 cards (which
isn't new in the kernel anymore). In the kernel build config, you just need to
set CONFIG_DRM_AMDGPU_SI=Y (for GCN1.0-based cards) and CONFIG_DRM_AMDGPU_CIK=Y
(for GCN1.1-based cards). To use amdgpu if it is built into the kernel with the
old gpus users just need to blacklist radeon and upon the next reboot linux
will load amdgpu and users can install amdgpu-pro if they want to or just stick
with the newest free graphics driver.


This option has been enabled by default for GCN 1.0 in other linux 
release like:

- Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1661887)
- SteamOS (https://github.com/ValveSoftware/SteamOS/issues/593)
- Arch (https://wiki.archlinux.org/index.php/AMDGPU#Loading)

Keep up the good work
Regards
Xavier Sellier.

Bug#865649: cups HTTPS issues -- Lack of SHA-2 certificate, weak TLSv1.0 crypto

[Didier Raboud]

Control: tags -1 +upstream
Control: forwarded -1 https://github.com/apple/cups/issues/5037
Control: tags -1 +wontfix # Not going to be a Debian-specific patch

Le vendredi, 23 juin 2017, 09.42:33 h CEST of@protonmail.com a écrit :
> * SHA-1 is officially deprecated for HTTPS certificates, but is still used
> for cups certificate generation.
> * TLSv1.0 is enabled for cups, but TLSv1.0 with CBC / SHA-1 is potentially
> vulnerable to BEAST attacks.

Right. Please see the above link for upstream's discussion. TLSv1.0 is still 
used by plenty of printers apparently, and I don't really fancy diverging from 
upstream on crypto code.

> I suggest two resolutions to correct this, even though it is understood that
> default certificates are self-signed anyway.
> 
> * Generate SHA-2 signed certificates by default. This will lessenthe
> additional browser warnings.

The CUPS server certificates are setup to be ssl-cert's (see symlinking code in 
cups-daemon.postinst, so that's a good suggestion for that to be fixed 
centrally in ssl-cert.

> * Enable only TLSv1.2 for the cups HTTPS interface and disable CBC and SHA-1
> crypto. TLSv1.0 has numerous known, potential security issues with CBC /
> SHA-1 suites. All current web clients support TLSv1.2 and so disabling
> TSLv1.0 should have no negative effect for local Debian users and is likely
> to also have virtually no impact for remote cups users as well accessing the
> cups interface remotely.

That's definitely not a change I'm going to carry alone. Please convince 
upstream and I'll make the Debian CUPS follow that!

Cheers,
OdyX

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

Bug#865598: cups: CUPS server ignores SSL key and certificate setting

[Didier 'OdyX' Raboud]

Control: tags -1 +upstream
Control: tags -1 +wontfix

Le vendredi, 23 juin 2017, 05.13:19 h CEST Drexl Johannes a écrit :
> I've just upgraded to Stretch and noticed CUPS won't use my certificate/key
> files any longer. It seems the options ServerCertificate and ServerKey have
> moved somewhere else (or dropped without upgrade notice), and this isn't
> really documented. CUPS now refuses to use those options alltogether,
> insisting on FQDN.key and FQDN.crt for no apparent reason whatsoever,
> generating the files as soon as one visits the web interface. The possible
> solution to this was to manually symlink the intended certificate/key to
> the hardcoded file names. While this works without (apparent) problems, I
> don't think this should be necessary nor forced upon the user.

ServerCertificate & ServerKey configuration directives' support has been 
dropped 
in CUPS 2.2~b1, so is replaced by ServerKeyChain (in /etc/cups/cups-files.conf) 
which indicates a keychain path (`ssl`, so `/etc/cups/ssl/` by default). The 
auto-generation is controlled by the option CreateSelfSignedCerts, that 
defaults to 'yes'.

Actually, looking at the code, it seems that : cupsSetServerCredentials(…)
is called with ServerName as second argument, without a possibility of that 
getting changed. ServerName is set as the result of gethostname().

All-in-all: 
* the cups.postinst certificate symlinking is not achieving what it wants: the 
symlinks are not used, and CUPS will generate new self-signed certificates on-
demand anyway. We should either stop the symlinking (and defer to CUPS' code) 
or fix it (put ssl-cert's back).
* I certainly agree that this migration away from ServerCertificate and 
ServerKey was suboptimally documented by upstream (and hence by Debian), but 
that's too late. :-/
* The forced certificate name is unfortunate, but of upstream' realm, and I 
don't really fancy forcefully changing that back to 'server.crt', as using the 
hostname is somewhat better, isn't it?

Looking forward to your feedback!

Cheers,
OdyX

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

Bug#865649: cups HTTPS issues -- Lack of SHA-2 certificate, weak TLSv1.0 crypto

[Didier 'OdyX' Raboud]

Le samedi, 26 août 2017, 15.47:20 h CEST Didier Raboud a écrit :
> > * Generate SHA-2 signed certificates by default. This will lessenthe
> > additional browser warnings.
> 
> The CUPS server certificates are setup to be ssl-cert's (see symlinking code
> in cups-daemon.postinst, so that's a good suggestion for that to be fixed
> centrally in ssl-cert.

Oh. As I was explaining bug #865598, I actually noticed that that symlinking 
code was just useless now (it symlinks to `…/server.crt` where CUPS uses
`…/$(gethostname()).crt`).

So the certificate creation indeed happens in CUPS (cups/tls-gnutls.c, line 
184):
>  gnutls_x509_crt_sign(crt, crt, key);

But I stand to my initial position: I'm not going to maintain a non-upstream 
patch queue of crypto code.

Cheers,
OdyX

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

Bug#873316: mawk's hical example has Y2K bug

[Rudolf Polzer]

Package: mawk
Version: 1.3.3-17
Severity: minor

Dear Maintainer,

What led up to the situation?

Discovered the issue when searching Debian Code Search for "19%y".

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

sh /usr/share/doc/mawk/examples/hical

   * What was the outcome of this action?

Current year shown as 1917

   * What outcome did you expect instead?

Current year shown as 2017

Fix suggestion 1: change 19%y to %Y in the script.
Fix suggestion 2: take the fixed version from upstream mawk 1.3.4.

The script has also some more bugs fixed upstream since - its shebang
points at /usr/sh which does not exist, and the echo command needs an
extra -e or the output will contain literal \n instead of line feeds.
All this is fixed upstream.

The issue is still present on sid, 1.3.3-17.

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

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

Versions of packages mawk depends on:
ii  libc6  2.19-18+deb8u10

mawk recommends no packages.

mawk suggests no packages.

-- no debconf information

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[roucaries bastien]

Does node-bn does the same ?

Thanks

On Sat, Aug 26, 2017 at 1:10 PM, Gianfranco Costamagna
 wrote:
> On Fri, 7 Jul 2017 10:04:49 + (UTC) Gianfranco Costamagna 
>  wrote:
>>
>>
>> >I'm not sure what you mean.
>> >These are dev dependencies, they are used by big-integer developers to
>> >perform various development tasks, but they are not required to simply
>> >use the library so there is no point in packaging them in Debian.
>> >And they are *not* embedded in the package, they only appear in
>> >package.json.
>>
>>
>> this makes sense, thanks.
>> So the review goes to the next step.
>> 1) licenses are missing (even if not used in the binary package, the 
>> copyright
>> should list all the licenses in the source code).
>> 2) please use the same copyright as upstream for Debian packaging, this will 
>> make
>> patch upstreaming possible without having to explicitly relicense them
>
> ping
>
> G.
>>
>> G.
>>
>>
>

Bug#873317: ITP: node-md5.js -- node style md5 on pure JavaScript

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-md5.js
  Version : 1.3.4
  Upstream Author : Kirill Fomichev  (https://github.com/fanatid)
* URL : https://github.com/crypto-browserify/md5.js
* License : Expat
  Programming Lang: JavaScript
  Description :  md5 on pure JavaScript

 This module implement md5 on pure javascript for browserify.
 .
 The MD5 algorithm is a widely used hash function producing a 128-bit
hash value. Although  MD5 was initially designed to be used as a
cryptographic hash function, it has been found to suffer from
extensive vulnerabilities. It can still be used as a checksum to
verify data integrity,  but only against unintentional corruption or
to implement hash table.
 .
 Brrowserify is a JavaScript tool that allows developers to write
Node.js-style modules that compile for use in the browser.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#873318: jellyfish does not actually disable parallel building

[Adrian Bunk]

Source: jellyfish
Version: 2.2.6-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jellyfish.html

...
lib/.libs/jsoncpp.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
Makefile:1193: recipe for target 'libjellyfish-2.0.la' failed
make[2]: *** [libjellyfish-2.0.la] Error 1



 jellyfish (2.2.6-2) unstable; urgency=medium
...
   * debhelper 10
   * Parallel builds seem to cause problems - use --no-parallel



%:
dh $@ --with autoreconf,python3 #--parallel



dh compat 10 does default to parallel,
explicit --no-parallel is required.

Bug#871828: gplaycli: new upstream version available

[Matlink]

Yes I would be glad to be helped to package newer versions of gplaycli.

I lack debian package knowledge.


Le 12/08/2017 à 05:15, Andres Salomon a écrit :
> Package: gplaycli
> Severity: wishlist
> Version: 0.2.1-1
>
> There's a newer version of gplaycli available upstream (0.2.9).  It has
> a bunch of authentication improvements.
>
> If you're looking for a co-maintainer, I'd be happy to help out with
> this package.

-- 
Matlink - Sysadmin matlink.fr
Sortez couverts, chiffrez vos mails : https://café-vie-privée.fr/
XMPP/Jabber : matl...@matlink.fr
Clé publique PGP : 0x186BB3CA
Empreinte Off-the-record : 572174BF 6983EA74 91417CA7 705ED899 DE9D05B2



0x186BB3CA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#853446: Patch

[Hilko Bengen]

Control: tag -1 patch

GCC-7 recognizes patches that contain the word "fallthrough" (and some
variants thereof), but not misspellings. This patch fixes that.

Cheers,
-Hilko
Index: http-parser/http_parser.c
===
--- http-parser.orig/http_parser.c
+++ http-parser/http_parser.c
@@ -2092,7 +2092,7 @@ http_parser_parse_url(const char *buf, s
   case s_req_server_with_at:
 found_at = 1;
 
-  /* FALLTROUGH */
+  /* FALLTHROUGH */
   case s_req_server:
 uf = UF_HOST;
 break;

Bug#870463: lp no longer honours default printers

[martin f krafft]

also sprach Didier 'OdyX' Raboud  [2017-08-26 15:20 +0200]:
> >   albatross:~/FOR_FILING% head -1 ~/.cups/lpoptions
> >   Default mfc9465cdn
> >   albatross:~/FOR_FILING% lp -P 30 2017-08-02-Scans.pdf
> >   lp: Error - no default destination available.

I am sorry, I totally forgot about this bug report. The problem was
that the cups-browsed upgrade ended up with new device names, so
obviously the previous one "mfc9465cdn" no longer works. The error
message could be improved, i.e. "Invalid default destination
specified in config file: mfc9465cdn", but other than that, this
isn't really a bug.

What do you want me to do? Take this upstream? Downgrade? Close?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
i'd rather be riding a high speed tractor
with a beer on my lap,
and a six pack of girls next to me.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#818968: Long live Oysttyer

[Thorsten Alteholz]

Hi,

I just wanted to tell everybody that oysttyer just entered unstable.

 Thorsten

Bug#873321: wrk FTBFS with luajit 2.1

[Adrian Bunk]

Source: wrk
Version: 4.0.2-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wrk.html

...
CC src/wrk.c
In file included from /usr/include/pthread.h:21:0,
 from src/wrk.h:5,
 from src/wrk.c:3:
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^~~
In file included from src/wrk.c:3:0:
src/wrk.h:13:10: fatal error: luajit-2.0/lua.h: No such file or directory
 #include 
  ^~
compilation terminated.
Makefile:58: recipe for target 'obj/wrk.o' failed
make[2]: *** [obj/wrk.o] Error 1

Bug#873320: ettercap FTBFS with luajit 2.1

[Adrian Bunk]

Source: ettercap
Version: 1:0.8.2-6
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ettercap.html

...
-- Couldn't find a suitable system-provided version of LuaJIT
CMake Error at cmake/Modules/EttercapLuajit.cmake:30 (message):
  Could not find LUAJIT!
Call Stack (most recent call first):
  CMakeLists.txt:138 (include)


-- Configuring incomplete, errors occurred!

Bug#873319: nginx FTBFS with luajit 2.1

[Adrian Bunk]

Source: nginx
Version: 1.13.3-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nginx.html

...
checking for PCRE JIT support ...checking for PCRE library ... found
 + ngx_nchan_module was configured
adding module in /build/1st/nginx-1.13.3/debian/modules/nginx-lua
checking for Lua library ... not found
checking for Lua library in /usr/local/ ... found
 found
checking for OpenSSL library ...checking for PCRE JIT support ... not found
checking for Lua library in /usr/local/ ... not found
checking for Lua library in /usr/pkg/ ... found
checking for OpenSSL library ... not found
checking for Lua library in /opt/local/ ... not found
checking for Lua library in /usr/local/*/lua51/ ... not found
checking for Lua library in /usr/ ... not found
checking for LuaJIT library in /usr/local/ ... not found
checking for LuaJIT library in /usr/ ... found
 not found
checking for zlib library ...checking for LuaJIT library in /usr/ ... not found
 ./configure: error: ngx_http_lua_module requires the Lua library.
debian/rules:183: recipe for target 'config.arch.extras' failed
make[1]: *** [config.arch.extras] Error 1

Bug#873322: bpfcc FTBFS with luajit 2.1

[Adrian Bunk]

Source: bpfcc
Version: 0.3.0-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bpfcc.html

...
-- Could NOT find LuaJIT (missing: LUAJIT_INCLUDE_DIR) 
CMake Warning at tests/python/CMakeLists.txt:6 (message):
  Recommended test program 'arping' not found


CMake Warning at tests/python/CMakeLists.txt:10 (message):
  Recommended test program 'netperf' not found


CMake Warning at tests/python/CMakeLists.txt:14 (message):
  Recommended test program 'iperf' not found


CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
LUAJIT_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua
   used as include directory in directory /build/1st/bpfcc-0.3.0/src/lua

-- Configuring incomplete, errors occurred!

Bug#873323: lintian -- False positives on copyright-year-in-future

[Thorsten Alteholz]

Package: lintian
Version: 2.5.52
Severity: normal


The license of package oysttyer contains an example, which gives a false 
positive for "copyright-year-in-future":

* If you choose to create and distribute a derivative work based on
   this package, your derivative work must clearly make reference to
   this package, any other packages your work or the original work
   might be based on, and all applicable copyrights, either in your
   documentation, your work's standard human-readable output, or both.
   A suggested method might be

 Contains or is based on the Foo software package.
 Copyright (C) 2112 D. Original Author. All rights reserved.
 http://their.web.site.invalid/

 Thorsten

Bug#873324: minetest FTBFS with luajit 2.1

[Adrian Bunk]

Source: minetest
Version: 0.4.16+repack-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/minetest.html

...
In file included from 
/build/1st/minetest-0.4.16+repack/src/script/common/c_content.cpp:19:0:
/build/1st/minetest-0.4.16+repack/src/script/common/c_content.h:32:10: fatal 
error: lua.h: No such file or directory
 #include 
  ^~~
compilation terminated.
src/CMakeFiles/minetestserver.dir/build.make:161: recipe for target 
'src/CMakeFiles/minetestserver.dir/script/common/c_content.cpp.o' failed
make[3]: *** [src/CMakeFiles/minetestserver.dir/script/common/c_content.cpp.o] 
Error 1

Bug#873325: fastnetmon FTBFS with luajit 2.1

[Adrian Bunk]

Source: fastnetmon
Version: 1.1.3+dfsg-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fastnetmon.html

...
In file included from /build/1st/fastnetmon-1.1.3+dfsg/src/fast_library.cpp:3:0:
/build/1st/fastnetmon-1.1.3+dfsg/src/fast_library.h:28:10: fatal error: 
luajit-2.0/lua.hpp: No such file or directory
 #include 
  ^~~~
compilation terminated.
CMakeFiles/fast_library.dir/build.make:65: recipe for target 
'CMakeFiles/fast_library.dir/fast_library.cpp.o' failed

Bug#873326: sysdig FTBFS with luajit 2.1

[Adrian Bunk]

Source: sysdig
Version: 0.17.0-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sysdig.html

...
-- Could NOT find Lua51 (missing: LUA_LIBRARIES LUA_INCLUDE_DIR) 
CMake Error at CMakeLists.txt:117 (message):
  Couldn't find system LuaJIT or Lua


-- Configuring incomplete, errors occurred!

Bug#873329: love FTBFS with luajit 2.1

[Adrian Bunk]

Source: love
Version: 0.9.1-4
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/love.html

...
In file included from libraries/luasocket/libluasocket/udp.c:12:0:
libraries/luasocket/libluasocket/auxiliar.h:38:61: error: unknown type name 
'luaL_reg'; did you mean 'luaL_Reg'?
 void auxiliar_newclass(lua_State *L, const char *classname, luaL_reg *func);
 ^~~~
 luaL_Reg

Bug#873328: trafficserver FTBFS with luajit 2.1

[Adrian Bunk]

Source: trafficserver
Version: 7.0.0-5
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/trafficserver.html

...
In file included from repl.cc:25:0:
bindings.h:65:67: error: 'luaL_reg' does not name a type; did you mean 
'luaL_ref'?
   static void register_metatable(lua_State *, const char *, const luaL_reg *);
   ^~~~
   luaL_ref
Makefile:716: recipe for target 'repl.lo' failed
make[4]: *** [repl.lo] Error 1

Bug#873327: aegisub FTBFS with luajit 2.1

[Adrian Bunk]

Source: aegisub
Version: 3.2.2+dfsg-3
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/aegisub.html

...
/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.c:2337:24: error: 
array type has incomplete element type 'struct luaL_reg'
 static struct luaL_reg pattreg[] = {
^~~
/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.c:2363:24: error: 
array type has incomplete element type 'struct luaL_reg'
 static struct luaL_reg metapattreg[] = {
^~~
/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.c:2363:24: warning: 
'metapattreg' defined but not used [-Wunused-variable]
/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.c:2337:24: warning: 
'pattreg' defined but not used [-Wunused-variable]
 static struct luaL_reg pattreg[] = {
^~~
Makefile.target:99: recipe for target 
'/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.o' failed
make[1]: *** [/build/1st/aegisub-3.2.2+dfsg/libaegisub/lua/modules/lpeg.o] 
Error 1

Bug#873275: always segfaults at start due to QSslSocket

[Sebastiaan Couwenberg]

On 08/26/2017 03:28 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> On sábado, 26 de agosto de 2017 15:50:14 -03 Adrian Bunk wrote:
>> On Sat, Aug 26, 2017 at 09:31:01AM -0300, Lisandro Damián Nicanor Pérez 
> Meyer wrote:
>>> First of all sorry for the top posting. Actually this is not a bug in qt4,
>>> OpenSSL 1.0 Is getting removed and qt4 *needs* to switch to 1.1.
>>
>> That's clear.
>>
>>> I uploaded
>>> to experimental for people to check, so actually this should be an
>>> important bug against qgis. If necessary I'll explain more with a more
>>> comfortable mail client at hand.
>>
>> The problem as reported by Dan and reproduced by me is:
> [snip] 
>> To me this looks like qt4 built with OpenSSL 1.1 trying to use functions
>> that were removed in OpenSSL 1.1, example:
>>
>>   /usr/include/openssl/ssl.h:#define SSLv23_client_method   
>> TLS_client_method
>>
>>
>> In OpenSSL 1.0.2 this was a proper function, but qt4 trying to load this
>> from libssl.so.1.1 cannot work.
> 
> Indeed, so the upload did work after all: we now know that the proposed patch 
> is not enough.
> 
> Sebastiaan: we might need to remove SSL support in Qt4 I'm afraid. How is the 
> qt5 port going?

Qt5 support will be available in QGIS 3.0.0 due in November this year,
the 3.x release will need some time to mature to a long term release
we'll include in Debian. The QGIS 3.4 LTR is due in November 2018. [0]

We could include QGIS 3.0.0 in Debian in the mean time and switch back
to the LTR releases a year later to not hold up to Qt4 removal too much.
Although I'd rather stick to the LTR releases in Debian.

[0]
http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#873330: stretch-pu: package libosmium/2.11.4-1

[Bas Couwenberg]

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

Upstream has releases a new stable release of libosmium fixing important
bugs which I'd like to propose for inclusion in the next stable update.

Kind Regards,

Bas
diff -Nru libosmium-2.11.3/CHANGELOG.md libosmium-2.11.4/CHANGELOG.md
--- libosmium-2.11.3/CHANGELOG.md   2017-05-03 14:01:48.0 +0200
+++ libosmium-2.11.4/CHANGELOG.md   2017-08-15 15:41:10.0 +0200
@@ -8,6 +8,14 @@
 
 ### Fixed
 
+## [2.11.4] - 2017-08-15
+
+### Fixed
+
+- Output coordinate with value of -2^31 correctly.
+- Buffers larger than 2^32 bytes do now work.
+
+
 ## [2.11.3] - 2017-05-03
 
 ### Fixed
diff -Nru libosmium-2.11.3/CMakeLists.txt libosmium-2.11.4/CMakeLists.txt
--- libosmium-2.11.3/CMakeLists.txt 2017-05-03 14:01:48.0 +0200
+++ libosmium-2.11.4/CMakeLists.txt 2017-08-15 15:41:10.0 +0200
@@ -25,7 +25,7 @@
 
 set(LIBOSMIUM_VERSION_MAJOR 2)
 set(LIBOSMIUM_VERSION_MINOR 11)
-set(LIBOSMIUM_VERSION_PATCH 3)
+set(LIBOSMIUM_VERSION_PATCH 4)
 
 set(LIBOSMIUM_VERSION
 
"${LIBOSMIUM_VERSION_MAJOR}.${LIBOSMIUM_VERSION_MINOR}.${LIBOSMIUM_VERSION_PATCH}")
diff -Nru libosmium-2.11.3/debian/changelog libosmium-2.11.4/debian/changelog
--- libosmium-2.11.3/debian/changelog   2017-05-03 18:44:44.0 +0200
+++ libosmium-2.11.4/debian/changelog   2017-08-26 15:05:22.0 +0200
@@ -1,3 +1,12 @@
+libosmium (2.11.4-1) stretch; urgency=medium
+
+  * New upstream bugfix release.
+- Output coordinate with value of -2^31 correctly.
+- Buffers larger than 2^32 bytes do now work.
+  * Update branch in gbp.conf & Vcs-Git URL.
+
+ -- Bas Couwenberg   Sat, 26 Aug 2017 15:05:22 +0200
+
 libosmium (2.11.3-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru libosmium-2.11.3/debian/control libosmium-2.11.4/debian/control
--- libosmium-2.11.3/debian/control 2017-05-03 18:37:13.0 +0200
+++ libosmium-2.11.4/debian/control 2017-08-26 15:03:43.0 +0200
@@ -19,7 +19,7 @@
zlib1g-dev
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-grass/libosmium.git/
-Vcs-Git: https://anonscm.debian.org/git/pkg-grass/libosmium.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-grass/libosmium.git -b stretch
 Homepage: http://osmcode.org/libosmium/
 
 Package: libosmium2-dev
diff -Nru libosmium-2.11.3/debian/gbp.conf libosmium-2.11.4/debian/gbp.conf
--- libosmium-2.11.3/debian/gbp.conf2017-05-03 18:37:13.0 +0200
+++ libosmium-2.11.4/debian/gbp.conf2017-08-26 15:03:36.0 +0200
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = stretch
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru libosmium-2.11.3/include/osmium/memory/item.hpp 
libosmium-2.11.4/include/osmium/memory/item.hpp
--- libosmium-2.11.3/include/osmium/memory/item.hpp 2017-05-03 
14:01:48.0 +0200
+++ libosmium-2.11.4/include/osmium/memory/item.hpp 2017-08-15 
15:41:10.0 +0200
@@ -62,7 +62,8 @@
 constexpr const item_size_type align_bytes = 8;
 
 inline constexpr std::size_t padded_length(std::size_t length) 
noexcept {
-return (length + align_bytes - 1) & ~(align_bytes - 1);
+return (length + static_cast(align_bytes) - 1) &
+   ~(static_cast(align_bytes) - 1);
 }
 
 /**
diff -Nru libosmium-2.11.3/include/osmium/osm/location.hpp 
libosmium-2.11.4/include/osmium/osm/location.hpp
--- libosmium-2.11.3/include/osmium/osm/location.hpp2017-05-03 
14:01:48.0 +0200
+++ libosmium-2.11.4/include/osmium/osm/location.hpp2017-08-15 
15:41:10.0 +0200
@@ -33,6 +33,7 @@
 
 */
 
+#include 
 #include 
 #include 
 #include 
@@ -198,6 +199,12 @@
 // Convert integer as used by location for coordinates into a string.
 template 
 inline T append_location_coordinate_to_string(T iterator, int32_t 
value) {
+// need to special-case this, because later `value = -value` would 
overflow.
+if (value == std::numeric_limits::min()) {
+static const char minresult[] = "-214.7483648";
+return std::copy_n(minresult, sizeof(minresult) - 1, iterator);
+}
+
 // handle negative values
 if (value < 0) {
 *iterator++ = '-';
diff -Nru libosmium-2.11.3/include/osmium/version.hpp 
libosmium-2.11.4/include/osmium/version.hpp
--- libosmium-2.11.3/include/osmium/version.hpp 2017-05-03 14:01:48.0 
+0200
+++ libosmium-2.11.4/include/osmium/version.hpp 2017-08-15 15:41:10.0 
+0200
@@ -35,8 +35,8 @@
 
 #define LIBOSMIUM_VERSION_MAJOR 2
 #define LIBOSMIUM_VERSION_MINOR 11
-#define LIBOSMIUM_VERSION_PATCH

Bug#862868: RFS: shc/3.9.4-4

[Tong Sun]

Oh, yeah, Md Jahidul Hamid is now the new upstream maintainer, and he has
agreed to do the Debian packaging as well.

See the bug#861180 at the bottom.

Is there anything else that I need to do, Gianfranco?


On Sat, Aug 26, 2017 at 6:50 AM, Gianfranco Costamagna <
locutusofb...@debian.org> wrote:

> Hello Tong,
>
> On Mon, 24 Jul 2017 22:40:59 +0500 Andrey Rahmatullin 
> wrote:
> > Control: tags -1 + moreinfo
> >
> > On Thu, May 18, 2017 at 03:32:48AM +0600, Md Jahidul Hamid wrote:
> > >   Changes since the last upload:
> > >
> > >   * Fix for infinite loop (Closes: #861180)
> > I don't think it's the only change as the last upload is 3.8.9b-1 and
> this
> > version is 3.9.4-4. It seems you've made the packaging from scratch,
> which
> > is wrong by the way, but that still doesn't mean you can drop the old
> > changelog entries.
> >
> > --
>
> somebody (upstream?) is trying to update your package, can you please
> coordinate together?
>
>
> G.
>
>

Bug#872794: i3blocks: [cpu_usage] Handle mpstat output change

[Alok Singh]

On Sat, 26 Aug 2017 at 10:51 Jason Pleau  wrote:

> Hi again.
>
> On 08/21/2017 06:41 AM, Alok Singh wrote:
> > Package: i3blocks
> > Version: 1.4-3+b1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Not sure when this happened but the regexp in cpu_usage cannot parse the
> > output of mpstat anymore. Patch attached.
> >
>
> I investigated, and this is strange, I cannot reproduce your exact issue.
>

My issue was exactly what is described in
https://github.com/vivien/i3blocks/pull/252 After looking at mpstat, I
figured the "Average" line was the one I'd like to be shown in the widget
while the regexp as written would pick the first CPU. This is something
that the github issue above is silent on.

http://sources.debian.net/src/i3blocks/1.4-3/scripts/cpu_usage/#L34


Yes, this is indeed the version I had before I created the patch. I have
inverted the original file and my patched file. So applying the patch would
not change the file. I have attached the fixed patch below. My apologies
for the mistake.


> I will however add a patch that was recently added as a PR upstream (the
> script does not work with newer kernel/mpstat):
> https://github.com/vivien/i3blocks/pull/252


Thank you, that should fix the problem. There is a difference between what
I have done and what upstream has done and I leave it to your judgement if
you'd like to change the regexp to use the "Average" line. Ideally,
upstream should accept this patch.

Thanks muchly for maintaining this package which I am sure has a loyal if
small following :)
-- 
Alok


cpu_usage.patch
Description: Binary data

Bug#873331: RM: llvm-toolchain-3.8 -- ROM; Too many version of llvm-toolchain in unstable

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

In unstable, we have 3.7 (RM #836602), 3.8, 3.9, 4.0, 5.0 (rc phase) & 6.0 
(snapshot)
This is *a bit* too many.

A transition to 4.0 has been proposed in bug #869752

I will fill the bugs to get packages depending on 3.8 updating to 4.0

Sylvestre

Bug#873332: stretch-pu: package pyosmium/2.11.3-1

[Bas Couwenberg]

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

Upstream has released a new stable release of pyosmium fixing important
bugs which I'd like to propose for inclusion in the next stable update.

Kind Regards,

Bas
diff -Nru pyosmium-2.11.1/CHANGELOG.md pyosmium-2.11.3/CHANGELOG.md
--- pyosmium-2.11.1/CHANGELOG.md2017-05-04 23:36:03.0 +0200
+++ pyosmium-2.11.3/CHANGELOG.md2017-08-20 11:18:52.0 +0200
@@ -12,6 +12,27 @@
 
 ### Fixed
 
+## [2.11.3] - 2017-08-20
+
+### Added
+
+### Changed
+
+- updated to latest libosmium 2.11 bugfix release
+
+### Fixed
+
+- handler functions not called when using Reader instead of file
+
+## [2.11.2] - 2017-05-25
+
+### Added
+
+### Changed
+
+### Fixed
+
+- handler functions not called when using replication service (#38)
 
 ## [2.11.1] - 2017-05-04
 
diff -Nru pyosmium-2.11.1/debian/changelog pyosmium-2.11.3/debian/changelog
--- pyosmium-2.11.1/debian/changelog2017-05-05 09:51:21.0 +0200
+++ pyosmium-2.11.3/debian/changelog2017-08-26 15:10:04.0 +0200
@@ -1,3 +1,11 @@
+pyosmium (2.11.3-1) stretch; urgency=medium
+
+  * New upstream bugfix release.
+- handler functions not called when using replication service (#38)
+- handler functions not called when using Reader instead of file
+
+ -- Bas Couwenberg   Sat, 26 Aug 2017 15:10:04 +0200
+
 pyosmium (2.11.1-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru pyosmium-2.11.1/lib/generic_handler.hpp 
pyosmium-2.11.3/lib/generic_handler.hpp
--- pyosmium-2.11.1/lib/generic_handler.hpp 2017-05-04 23:36:03.0 
+0200
+++ pyosmium-2.11.3/lib/generic_handler.hpp 2017-08-20 11:18:52.0 
+0200
@@ -25,6 +25,7 @@
 };
 
 public:
+virtual void apply_start() {};
 // handler functions
 virtual void node(const osmium::Node&) const = 0;
 virtual void way(const osmium::Way&) const = 0;
@@ -163,14 +164,7 @@
 apply_object(osmium::io::File(cbuf, len, cfmt), locations, idx);
 }
 
-private:
-void apply_object(osmium::io::File file, bool locations, const std::string 
&idx)
-{
-osmium::osm_entity_bits::type entities = 
osmium::osm_entity_bits::nothing;
-BaseHandler::pre_handler handler = locations?
-BaseHandler::location_handler
-:BaseHandler::no_handler;
-
+void apply_start() override {
 m_callbacks = osmium::osm_entity_bits::nothing;
 if (hasfunc("node"))
 m_callbacks |= osmium::osm_entity_bits::node;
@@ -182,6 +176,18 @@
 m_callbacks |= osmium::osm_entity_bits::area;
 if (hasfunc("changeset"))
 m_callbacks |= osmium::osm_entity_bits::changeset;
+}
+
+
+private:
+void apply_object(osmium::io::File file, bool locations, const std::string 
&idx)
+{
+osmium::osm_entity_bits::type entities = 
osmium::osm_entity_bits::nothing;
+BaseHandler::pre_handler handler = locations?
+BaseHandler::location_handler
+:BaseHandler::no_handler;
+
+apply_start();
 
 if (m_callbacks & osmium::osm_entity_bits::area)
 {
@@ -202,6 +208,7 @@
 apply(file, entities, handler, idx);
 }
 
+
 bool hasfunc(char const *name) {
 reference_existing_object::apply::type converter;
 PyObject* obj = converter( this );
diff -Nru pyosmium-2.11.1/lib/merged_input.hpp 
pyosmium-2.11.3/lib/merged_input.hpp
--- pyosmium-2.11.1/lib/merged_input.hpp2017-05-04 23:36:03.0 
+0200
+++ pyosmium-2.11.3/lib/merged_input.hpp2017-08-20 11:18:52.0 
+0200
@@ -16,6 +16,7 @@
 class MergeInputReader {
 public:
 void apply(BaseHandler& handler, bool simplify = true) {
+handler.apply_start();
 if (simplify) {
 objects.sort(osmium::object_order_type_id_reverse_version());
 osmium::item_type prev_type = osmium::item_type::undefined;
diff -Nru pyosmium-2.11.1/lib/osmium.cc pyosmium-2.11.3/lib/osmium.cc
--- pyosmium-2.11.1/lib/osmium.cc   2017-05-04 23:36:03.0 +0200
+++ pyosmium-2.11.3/lib/osmium.cc   2017-08-20 11:18:52.0 +0200
@@ -13,11 +13,17 @@
 osmium::apply(rd, h);
 }
 
+template <>
+void apply_reader_simple(osmium::io::Reader &rd, BaseHandler &h) {
+h.apply_start();
+osmium::apply(rd, h);
+}
 
 template 
 void apply_reader_simple_with_location(osmium::io::Reader &rd,
  osmium::handler::NodeLocationsForWays &l,
  BaseHandler &h) {
+h.apply_start();
 osmium::apply(rd, l, h);
 }
 
diff -Nru pyosmium-2.11.1/osmium/version.py pyosmium-2.11.3/osmium/version.py
--- pyosmium-2.11.1/osmium/version.py   2017-05-04 23:36:03.0 +0200
+++ pyosmium-2.11.3/osmium/version.py   2017-08-20 11:18:52.0 +0200
@@ -5,7 +5,7 @