Bug#892799: libtgvoip: Incomplete debian/copyright?

2018-03-12 Thread Chris Lamb
Source: libtgvoip
Version: 1.0.3-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Nicholas Guriev 

Hi,

I just ACCEPTed libtgvoip from NEW but noticed it was missing 
attribution in debian/copyright for at least common_audio/fft4g.c
which looks like an embedded code copy.

I would also prefer to see some clarification in debian/copyright
about common_audio/signal_processing/spl_sqrt_floor.c.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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



Bug#892798: ruby-crack FTBFS uninitialized constant SafeYAML::Parse::Date::DateTime (NameError)

2018-03-12 Thread Pirate Praveen
Package: ruby-crack
version: 0.4.3-2
Severity: serious

Autopkgtest also fails
https://ci.debian.net/data/packages/unstable/amd64/r/ruby-crack/latest-autopkgtest/log.gz

┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rake
  │
└──┘

RUBYLIB=/<>/debian/ruby-crack/usr/lib/ruby/vendor_ruby:.
GEM_PATH=debian/ruby-crack/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
ruby2.5 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.5 -w -I"lib:test"
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/hash_test.rb"
"test/json_test.rb" "test/parser_test.rb" "test/string_test.rb"
"test/xml_test.rb"
/<>/test/hash_test.rb:10: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/<>/test/hash_test.rb:11: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/<>/test/hash_test.rb:12: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/<>/test/hash_test.rb:22: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/<>/test/hash_test.rb:23: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/<>/test/hash_test.rb:24: warning: ambiguous first
argument; put parentheses or a space even after `/' operator
/usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:22:in `':
uninitialized constant SafeYAML::Parse::Date::DateTime (NameError)
Did you mean?  SafeYAML::Parse::Date::DATE_MATCHER
from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:3:in 
`'
from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:2:in
`'
from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:1:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/vendor_ruby/safe_yaml/load.rb:14:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /<>/lib/crack/json.rb:6:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /<>/lib/crack.rb:6:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /<>/test/test_helper.rb:3:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /<>/test/hash_test.rb:1:in `'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:17:in `block in
'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:5:in `select'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:5:in `'
rake aborted!
Command failed with status (1): [ruby -w -I"lib:test"
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/hash_test.rb"
"test/json_test.rb" "test/parser_test.rb" "test/string_test.rb"
"test/xml_test.rb" ]

Tasks: TOP => default => test
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-crack
returned exit code 1
make: *** [debian/rules:6: binary] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2

Build finished at 2018-03-13T04:58:47Z




signature.asc
Description: OpenPGP digital signature


Bug#892797: sasview: should look for data files in home dir not package dir

2018-03-12 Thread Drew Parsons
Package: sasview
Version: 4.2.0~git20180309-2
Severity: normal

Currently when using the gui interface to open a new data file, the
"Choose a file" dialog window starts from the package directory, 
/usr/lib/python2.7/dist-packages/sas/sasview.

Of course no data files will be found there.  The dialog should be
configured to start from the user's home dir (or recently used, or
somesuch).



-- 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.15.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sasview depends on:
ii  python2.7.14-4
ii  python-numpy  1:1.13.3-2
ii  python-pkg-resources  38.5.2-1
ii  python-sasview4.2.0~git20180309-2

sasview recommends no packages.

Versions of packages sasview suggests:
ii  sasview-doc  4.2.0~git20180309-2

-- no debconf information



Bug#892796: boost1.62: please backport patches from smart_ptr PR/47 for mips r6

2018-03-12 Thread YunQiang Su
Package: src:boost1.62
Version: 1.62.0+dfsg-5

mips r6 changes encoding of some insn, include ll/sc,
if we .set mips2, it will generate old encodings for them.

So we shouldn't use `.set mips2' for r6.

https://github.com/boostorg/smart_ptr/pull/47

-- 
YunQiang Su


Bug#892795: conflicts with libcurl4

2018-03-12 Thread 積丹尼 Dan Jacobson
Package: feh
Version: 2.23.2-1

# aptitude install feh
The following packages have unmet dependencies:
 libcurl4 : Conflicts: libcurl3 but 7.58.0-2 is to be installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) curl [7.58.0-3 (experimental, now)]
2) libcurl4 [7.58.0-3 (experimental, now)]



Bug#815088: cron: sysv init script has "Required-Start: $remote_fs" but systemd service does not

2018-03-12 Thread Sandro Tosi
(not sure to whom this question is directed)

On Mon, Mar 12, 2018 at 7:59 PM, Michael Biebl  wrote:
> On Sun, 1 May 2016 22:32:33 +0200 Christian Kastner  wrote:
> > Control: tag -1 confirmed pending
> >
> > Hi Sandro,
> >
> > On 2016-02-18 16:45, Sandro Tosi wrote:
> > > i just noticed the systemd service for cron doesnt define a depencency on
> > > remote-fs.target , while the sysv init script have the "Required-Start:
> > > $remote_fs". I think that dependency should be added.
> >
> > Thank you for spotting this, I have committed a fix.
>
> Why would a dependency on remote-fs.target be necessary?

because that's the path of least surprise: on wheezy cron depended on
remote_fs, while jessie cron service doesnt, so during that migration
you would have expected cronjobs depending on remote fs to correctly
be executed, but that's a wrong assumption as cron service is happy to
start before NFS shares are mounted, thus failing the jobs depending
on them.

i'm well aware we can add a drop-in in /etc/systemd to add the
dependency, but the point is to have sane defaults and do not surprise
the administrators with an unannounced change of dependencies.

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



Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Georg Faerber
Hi Apollon,

On 18-03-13 00:19:06, Apollon Oikonomopoulos wrote:
> On 23:09 Mon 12 Mar , Georg Faerber wrote:
> > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote:
> > > So, the version of ruby-gettext-setup is pretty outdated and 
> > > predates
> > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules
> > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext
> > > default domain, causing breakage. This has been fixed upstream[1] in
> > > 0.17.
> > > 
> > > We should upgrade ruby-gettext-setup to the latest upstream version.
> > 
> > I could take care of this, tomorrow. Just need someone to sponsor the
> > upload.
> 
> Please do! I'd be glad to sponsor this, ping me when you're ready or
> if you need any help.

I've pushed in git to branch debian/0.30-1. Please especially review
eeff22b6, in particular the changes I've made to
spec/lib/tasks/gettext_rake_spec.rb. 

(This file loads an rake task contained in lib/. I'm not really sure if
I'm happy with my proposed change, however, I've tried various methods
and didn't found anything else working besides this. Reasoning for this
change: Upstreams code doesn't work if specs are run via autopkgtest, as
lib/ is moved away during autopkgtest runs. In case you would like to
change this: Please go ahead.)

Thanks for reviewing,
cheers,
Georg


signature.asc
Description: Digital signature


Bug#860950: steam: crashes on startup

2018-03-12 Thread Michael Gilbert
On Sun, Feb 18, 2018 at 1:04 AM, Clayton wrote:
> [2018-02-18 12:50:27] Cleaning up...
> [2018-02-18 12:50:27] Update complete, launching...
> [2018-02-18 12:50:27] Shutdown tar: This does not look like a tar
> archive xz: (stdin): File format not recognized
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
> find: ‘/home/user/.steam/ubuntu12_32/steam-runtime’: No such file or
> directory

This looks like an incomplete download.  Try backing up your
ubuntu12_32 folder, and execute steam again.

If that works, the script will need to try to clean up after a failed download.

Best wishes,
Mike



Bug#789247: di-netboot-assistant: broken deb.d.o urls

2018-03-12 Thread Matt Taggart

On 03/10/2018 04:22 AM, Andreas B. Mundt wrote:


Hm, the /debian/ should be inserted by the following in
'/etc/di-netboot-assistant/di-netboot-assistant.conf' [1]:

#Download Mirror
# The variable MIRROR_REGEXPS contain a list of space separated sed
# regular expression, to rewrite di-sources.list URLs, to match your
# prefered mirror.  For example:
MIRROR_REGEXPS="s=://deb.debian.org/=://deb.debian.org/debian/="

I was already wondering why not to use the correct URL in
'di-sources.list', but kept that as it works fine for me.  Can you
check if you have the line in 'di-netboot-assistant.conf'?  Perhaps
it's there for historical reasons and we can/should remove it.


Oh...
I had just grabbed the latest di-sources.list to use on an older version 
of the package, I didn't know about that regexp thing in the config file...


It's sort of a nice feature, it makes using a local mirror/proxy easier 
(assuming you know you can use that). But I suspect most mirrors would 
have a debian/ dir and if a user had one that _didn't_ then the regexp 
could be setup the other way to strip it out.


So my vote would be fix the URLs in di-sources.list, comment out 
MIRROR_REGEXP in the conf, change it's regexps to provide an example of 
how it could be used.


I guess the only concern is the existing conffiles that are out there 
and if that would break existing installs. If you changed both sources 
and conf at the same time, hopefully it would be clear. I guess if you 
go that route, wait until one of them needs another change anyway?


--
Matt Taggart
tagg...@debian.org



Bug#892413: nvidia-driver: PRIME Synchronization regression in 390.25 with kernel 4.15, fixed upstream

2018-03-12 Thread Luca Boccassi
On Mon, 2018-03-12 at 18:31 +0100, Andreas Beckmann wrote:
> On 2018-03-12 17:28, Luca Boccassi wrote:
> > Yeah I suspected a new release would have happened soon so I didn't
> > have a look at that yet.
> > 
> > I'll look at 390.42 as soon as possible, and if still necessary,
> > check
> > that patch.
> 
> It still applies ... module build test still running.
> 
> > I don't use PRIME so I can't really say if it was broken or not at
> > the
> > moment.
> 
> Me neither ...
> 
> Andreas

Seems to work fine on my desktop. Ship it :-)

-- 
Kind regards,
Luca Boccassi

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


Bug#869421: RFP: stlink -- STM32 stlink programmer tools

2018-03-12 Thread Luca Boccassi
Control: retitle -1 ITP: stlink -- STM32 stlink programmer tools
Control: owner -1 bl...@debian.org

On Sun, 23 Jul 2017 14:19:23 +0200 cedric  wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: stlink
>   Version : 1.4.0
>   Upstream Author : Jerry Jacobs 
> * URL : https://github.com/texane/stlink
> * License : BSD
>   Programming Lang: C
>   Description : STM32 stlink programmer tools
> 
> Open source version of the STMicroelectronics Stlink Tools,
> can be used to program and debug STM32 MCU boards
> 
> There is no similar tools in debian packages right now.
> Building and debian package generation works fine.
> I use it often.
> Maybe it can be maintained by pkg-electronics team.
> I am not a debian developper but I can help if needed.
> 
> Cedric

Hi,

I intend to upload stlink in the next couple of days. I've sent a few
packaging fixes on Github: https://github.com/texane/stlink/pull/683

-- 
Kind regards,
Luca Boccassi

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


Bug#840119: lowering no-pdiff prio to 99 doesn't help

2018-03-12 Thread sergio

# mv /etc/apt/apt.conf.d/00no-pdiff /etc/apt/apt.conf.d/99no-pdiff

# apt-config dump | grep -i pdiff
Acquire::IndexTargets::deb::Contents-deb::PDiffs "true";
Acquire::IndexTargets::deb::Contents-udeb::PDiffs "true";
Acquire::IndexTargets::deb::Contents-deb-legacy::PDiffs "true";
Acquire::IndexTargets::deb-src::Contents-dsc::PDiffs "true";
Acquire::PDiffs "false";

# apt update
...
Get:13 http://ftp.debian.org/debian sid/main amd64 Contents (deb)
2018-03-12-0220.21.pdiff [2,704 B]
...

-- 
sergio



Bug#883027: flare-engine: new upstream release 0.20

2018-03-12 Thread Manuel A. Fernandez Montecelo
(copying Antoine Musso now)

This e-mail below extends also to Antoine, or anybody else who wants
to collaborate :)





2018-03-13 1:13 GMT+01:00 Manuel A. Fernandez Montecelo
:
> Hi,
>
> 2018-03-12 20:34 GMT+01:00 felipe :
>> Hi.
>>
>> It seems Flare 1.0 was just released with the new Empyrean Campaign.
>>
>> Let me know if you need help packaging the new version.
>
> I asked them when receiving this bug report (bug request in github,
> IIRC), they estimated like 3 months, and here we are :)
>
> Unfortunately at the moment I am a bit busy, so if you could prepare a
> package for the new version it would be great!
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 



-- 
Manuel A. Fernandez Montecelo 



Bug#883027: flare-engine: new upstream release 0.20

2018-03-12 Thread Manuel A. Fernandez Montecelo
Hi,

2018-03-12 20:34 GMT+01:00 felipe :
> Hi.
>
> It seems Flare 1.0 was just released with the new Empyrean Campaign.
>
> Let me know if you need help packaging the new version.

I asked them when receiving this bug report (bug request in github,
IIRC), they estimated like 3 months, and here we are :)

Unfortunately at the moment I am a bit busy, so if you could prepare a
package for the new version it would be great!


Cheers.
-- 
Manuel A. Fernandez Montecelo 



Bug#892793: stretch-pu: package cron/128+deb9u2

2018-03-12 Thread Michael Biebl
Am 13.03.2018 um 00:43 schrieb Javier Fernández-Sanguino Peña:
> +After=remote-fs.target nss-user-lookup.target

Why is the remote-fs.target ordering necessary? That doesn't seem
correct to me.

-- 
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#815088: cron: sysv init script has "Required-Start: $remote_fs" but systemd service does not

2018-03-12 Thread Michael Biebl
On Sun, 1 May 2016 22:32:33 +0200 Christian Kastner  wrote:
> Control: tag -1 confirmed pending
> 
> Hi Sandro,
> 
> On 2016-02-18 16:45, Sandro Tosi wrote:
> > i just noticed the systemd service for cron doesnt define a depencency on
> > remote-fs.target , while the sysv init script have the "Required-Start:
> > $remote_fs". I think that dependency should be added.
> 
> Thank you for spotting this, I have committed a fix.

Why would a dependency on remote-fs.target be necessary?

-- 
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#892793: stretch-pu: package cron/128+deb9u2

2018-03-12 Thread Javier Fernández-Sanguino Peña
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

 Fix bugs in cron that prevents it from working properly in environments
 where centralised user databases are used (e.g. LDAP, Windows AD).

 The changes introduce a dependency in the init.d file (for sssd) and in
 the service unit file to ensure that cron is started after these services
 are operative.

 Please review and, if possible, accept this version for stretch.

 Best regards


 Javier Fernandez-Sanguino




diff -u cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
--- cron-3.0pl1/debian/changelog
+++ cron-3.0pl1/debian/changelog
@@ -1,3 +1,17 @@
+cron (3.0pl1-128+deb9u2) stretch; urgency=medium
+
+  * debian/cron.init: Add sssd to the services that should be started/stopped
+before/after cron
+  * debian/cron.service: Add a dependency on remote-fs.target (Closes: #815088)
+  * debian/cron.service: Add dependency on nss-user-lookup.target in the
+definition which properly fixes the issues when cron is started
+before centralised user repositories are available (e.g. LDAP
+or Active Directory). This should avoid errors in syslog similar to
+the following: "crond[PID]: (CRON) bad username (/etc/cron.d/JOBNAME)"
+(Closes: #767016, #801384, #783665) (LP: #1593317)
+
+ -- Javier Fernández-Sanguino Peña   Sun, 11 Mar 2018 22:32:18 +0100
+
 cron (3.0pl1-128+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload.
diff -u cron-3.0pl1/debian/cron.init cron-3.0pl1/debian/cron.init
--- cron-3.0pl1/debian/cron.init
+++ cron-3.0pl1/debian/cron.init
@@ -5,8 +5,8 @@
 # Provides:  cron
 # Required-Start:$remote_fs $syslog $time
 # Required-Stop: $remote_fs $syslog $time
-# Should-Start:  $network $named slapd autofs ypbind nscd nslcd winbind
-# Should-Stop:   $network $named slapd autofs ypbind nscd nslcd winbind
+# Should-Start:  $network $named slapd autofs ypbind nscd nslcd winbind sssd
+# Should-Stop:   $network $named slapd autofs ypbind nscd nslcd winbind sssd
 # Default-Start: 2 3 4 5
 # Default-Stop:
 # Short-Description: Regular background program processing daemon
diff -u cron-3.0pl1/debian/cron.service cron-3.0pl1/debian/cron.service
--- cron-3.0pl1/debian/cron.service
+++ cron-3.0pl1/debian/cron.service
@@ -1,6 +1,7 @@
 [Unit]
 Description=Regular background program processing daemon
 Documentation=man:cron(8)
+After=remote-fs.target nss-user-lookup.target
 
 [Service]
 EnvironmentFile=-/etc/default/cron


signature.asc
Description: PGP signature


Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

2018-03-12 Thread Francesco Poli
On Mon, 12 Mar 2018 23:45:44 +0100 Michael Biebl wrote:

[...]
> Am 12.03.2018 um 23:16 schrieb Francesco Poli:
[...]
> > I've just performed the test, after commenting out the three above
> > quoted lines.
> > The bug was not triggered.
> 
> Thanks for testing.

Thanks to you for investigating and for asking me to perform the right
test!  ;-)

> 
> > It really seems that the bug is caused by some interaction with
> > clear_console ...
> 
> I'm going to reassing to bash and merge with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342
> 
> I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave
> it up to the respective maintainers to reassign if necessary.

Good.

Looking forward to hearing from the bash Debian package maintainers
and/or from the X Strike Force...


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


pgpKXQK8Albqe.pgp
Description: PGP signature


Bug#892792: apt: Typo in apt 1.5~beta1 changelog

2018-03-12 Thread annadane
Package: apt
Version: 1.6~beta1
Severity: minor

Dear Maintainer,

Paragraph "As for backwards compatibility, the options IssuerCert and 
SslForceVersion
  are not supported anymore, and any specified certificate files must in the
  PEM format (curl might have allowed DER files as well)." should read "must be 
in the PEM format"

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-6-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.15\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.9\.0-6-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::MaxAge "30";
APT::Periodic::MinAge "2";
APT::Periodic::MaxSize "500";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "touch /var/lib/apt/periodic/update-success-stamp 
2>/dev/null || true";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

2018-03-12 Thread Michael Biebl
Am 12.03.2018 um 23:45 schrieb Michael Biebl:
> Am 12.03.2018 um 23:16 schrieb Francesco Poli:

>> It really seems that the bug is caused by some interaction with
>> clear_console ...
> 
> I'm going to reassing to bash and merge with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342
> 
> I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave
> it up to the respective maintainers to reassign if necessary.

I will note, that clear_console is a debian specific addition to bash.


-- 
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#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

2018-03-12 Thread Michael Biebl
Control: reassign -1 bash
Control: forcemerge 791342 -1

Am 12.03.2018 um 23:16 schrieb Francesco Poli:
> On Sun, 11 Mar 2018 20:11:03 +0100 Michael Biebl wrote:
> 
>> Am 11.03.2018 um 19:12 schrieb Francesco Poli:
>>
>>> My ~/.bash_logout is attached, but it's nothing special: it should be
>>> identical to the one provided by the bash package in /etc/skel/
>>
>> Can you comment out / remove the following three lines:
>>
>> if [ "$SHLVL" = 1 ]; then
>> [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
>> fi
>>
>> and then test again, if you still encounter the problem.
> 
> I've just performed the test, after commenting out the three above
> quoted lines.
> The bug was not triggered.

Thanks for testing.

> It really seems that the bug is caused by some interaction with
> clear_console ...

I'm going to reassing to bash and merge with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342

I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave
it up to the respective maintainers to reassign if necessary.

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



signature.asc
Description: OpenPGP digital signature


Bug#874220: stretch update for openni2

2018-03-12 Thread Jochen Sprickerhof

* Adrian Bunk  [2018-03-12 20:52]:

On Mon, Sep 11, 2017 at 09:18:05PM +, Debian Bug Tracking System wrote:

...
 openni2 (2.2.0.33+dfsg-10) unstable; urgency=medium
 .
   * Add patch for arm.
 Thanks to Adrian Bunk (Closes: #874220)
...


Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.


Fell free to fix it :).

Thanks

Jochen


signature.asc
Description: PGP signature


Bug#852856: collaborate

2018-03-12 Thread Jonathan McDowell
On Mon, Mar 12, 2018 at 11:13:10PM +0100, Geert Stappers wrote:
> > I'm not sure that's entirely appropriate. You can perfectly easily add
> > some udev rules to urjtag, rather than expecting openocd to solve the
> > problem for you. It can even be done in a way that means the 2 packages
> > can co-exist. #852856 is a wishlist bug that essentially says "we do the
> > same thing, I'd like to take advantage of the work you've already done
> > rather than maintaining a similar list myself".
> 
> In my words:
> 
> Avoiding duplicate work.
> 
> My plan:
> 
> Applying the patches, become stakeholder of openocd package.
> Working together.

If you want to work together you have to have a discussion. I appreciate
the bug has been languishing without a response but it pre-dates my
involvement with the OpenOCD package and it's not been as high priority
as getting the package up to date with upstream or dealing with security
issues.

On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote:
> On Mon, Mar 12, 2018 at 09:39:29AM +, Jonathan McDowell wrote:
> > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag
> > support, or is one a subset of the other?
> 
> Seen the question, but I don't see where it fits in the discussion
> about a openocd file moving into seperate package.

If one program is a strict subset of the other in terms of supported
adaptors then it may make sense for the program with the larger support
matrix to split a file out so that the other can take advantage of it.
If the 2 programs support different adaptors then I'm not sure of the
benefit; it becomes extra work on both parts to maintain the overlapping
list?

J.

-- 
Avoid GOTOs completely if you can keep the program readable.
This .sig brought to you by the letter L and the number 49
Product of the Republic of HuggieTag



Bug#892004: Please adapt to gnome-settings-daemon 3.28 by March 15

2018-03-12 Thread Joachim Breitner
Hi,

I am unable to do something this week. Could someone else apply the
change and upload the package?

Thanks,
Joachim

Am Samstag, den 10.03.2018, 21:47 -0500 schrieb Jeremy Bicha:
> Please make your upload on or before March 15. Otherwise, we will need
> to NMU your package for the gnome-settings-daemon 3.28 transition.
> 
> On behalf of the Debian GNOME Team,
> Jeremy Bicha
> 
> 
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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


Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Georg Faerber
Hi Apollon,

On 18-03-13 00:19:06, Apollon Oikonomopoulos wrote:
> On 23:09 Mon 12 Mar , Georg Faerber wrote:
> > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote:
> > > So, the version of ruby-gettext-setup is pretty outdated and 
> > > predates
> > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules
> > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext
> > > default domain, causing breakage. This has been fixed upstream[1] in
> > > 0.17.
> > > 
> > > We should upgrade ruby-gettext-setup to the latest upstream version.
> > 
> > I could take care of this, tomorrow. Just need someone to sponsor
> > the upload.
> 
> Please do! I'd be glad to sponsor this, ping me when you're ready or
> if you need any help.

Will do, thanks!

Cheers,
Georg


signature.asc
Description: Digital signature


Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Apollon Oikonomopoulos
Hi Georg,

On 23:09 Mon 12 Mar , Georg Faerber wrote:
> On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote:
> > So, the version of ruby-gettext-setup is pretty outdated and 
> > predates
> > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules
> > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext
> > default domain, causing breakage. This has been fixed upstream[1] in
> > 0.17.
> > 
> > We should upgrade ruby-gettext-setup to the latest upstream version.
> 
> I could take care of this, tomorrow. Just need someone to sponsor the
> upload.

Please do! I'd be glad to sponsor this, ping me when you're ready or if 
you need any help.

Cheers,
Apollon



Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

2018-03-12 Thread Francesco Poli
On Sun, 11 Mar 2018 20:11:03 +0100 Michael Biebl wrote:

> Am 11.03.2018 um 19:12 schrieb Francesco Poli:
> 
> > My ~/.bash_logout is attached, but it's nothing special: it should be
> > identical to the one provided by the bash package in /etc/skel/
> 
> Can you comment out / remove the following three lines:
> 
> if [ "$SHLVL" = 1 ]; then
> [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
> fi
> 
> and then test again, if you still encounter the problem.

I've just performed the test, after commenting out the three above
quoted lines.
The bug was not triggered.

It really seems that the bug is caused by some interaction with
clear_console ...


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


pgpokAgdAsNf5.pgp
Description: PGP signature


Bug#892791: RFP: SLSK -- A backup utility and database for Linux Steam games

2018-03-12 Thread supreme

Package: wnpp

Severity: wishlist

X-Debbugs-CC: debian-de...@lists.debian.org

License: GPLv3

URL: https://github.com/supremesonicbrazil/SLSK

Copyright (C) 2017-2018 Supremist (aka supremesonicbrazil)

Description: Steam Linux Swiss Knife is an open-source program that aims 
to automate the backup and restore of Steam games, their saves and 
configs, centralizing paths in a local and extremely lightweight database.




Bug#892790: cross-toolchain-base-ports: Please add support for riscv64

2018-03-12 Thread Aurelien Jarno
Source: cross-toolchain-base-ports
Version: 18
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org 

Usertags: riscv64

Hello,

We are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V).

Adding this architecture to the cross-toolchain would simplify a lot
the cross-compilation of packages. You will find attached a patch doing
that for cross-toolchain-base-ports. Note that the control file of glibc
has to be patched, as it doesn't provide riscv64 in the architecture
list, due to missing support in dpkg/stable (see bugs #888793 and
#890791).

Thanks,
Aurelien
diff -Nru cross-toolchain-base-ports-18/debian/control 
cross-toolchain-base-ports-18.1/debian/control
--- cross-toolchain-base-ports-18/debian/control
+++ cross-toolchain-base-ports-18.1/debian/control
@@ -25,7 +25,7 @@
   libconfig-auto-perl, libfile-temp-perl, libconfig-auto-perl,
   libfile-homedir-perl, liblocale-gettext-perl, libunwind-dev [amd64 i386 x32]
 Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
-  binutils-alpha-linux-gnu, libc6-alpha-cross, linux-libc-dev-alpha-cross, 
binutils-hppa-linux-gnu, libc6-hppa-cross, linux-libc-dev-hppa-cross, 
binutils-m68k-linux-gnu, libc6-m68k-cross, linux-libc-dev-m68k-cross, 
binutils-mips64-linux-gnuabi64, libc6-mips64-cross, 
linux-libc-dev-mips64-cross, binutils-powerpc64-linux-gnu, libc6-ppc64-cross, 
linux-libc-dev-ppc64-cross, binutils-sh4-linux-gnu, libc6-sh4-cross, 
linux-libc-dev-sh4-cross, binutils-sparc64-linux-gnu, libc6-sparc64-cross, 
linux-libc-dev-sparc64-cross, binutils-powerpc-linux-gnu, libc6-powerpc-cross, 
linux-libc-dev-powerpc-cross, binutils-powerpc-linux-gnuspe, 
libc6-powerpcspe-cross, linux-libc-dev-powerpcspe-cross, 
binutils-mips64-linux-gnuabin32, libc6-mipsn32-cross, 
linux-libc-dev-mipsn32-cross, binutils-mips64el-linux-gnuabin32, 
libc6-mipsn32el-cross, linux-libc-dev-mipsn32el-cross, 
binutils-mipsisa32r6-linux-gnu, libc6-mipsr6-cross, 
linux-libc-dev-mipsr6-cross, binutils-mipsisa32r6el-linux-gnu, 
libc6-mipsr6el-cross, linux-libc-dev-mipsr6el-cross, 
binutils-mipsisa64r6-linux-gnuabin32, libc6-mipsn32r6-cross, 
linux-libc-dev-mipsn32r6-cross, binutils-mipsisa64r6el-linux-gnuabin32, 
libc6-mipsn32r6el-cross, linux-libc-dev-mipsn32r6el-cross, 
binutils-mipsisa64r6-linux-gnuabi64, libc6-mips64r6-cross, 
linux-libc-dev-mips64r6-cross, binutils-mipsisa64r6el-linux-gnuabi64, 
libc6-mips64r6el-cross, linux-libc-dev-mips64r6el-cross,
+  binutils-alpha-linux-gnu, libc6-alpha-cross, linux-libc-dev-alpha-cross, 
binutils-hppa-linux-gnu, libc6-hppa-cross, linux-libc-dev-hppa-cross, 
binutils-m68k-linux-gnu, libc6-m68k-cross, linux-libc-dev-m68k-cross, 
binutils-mips64-linux-gnuabi64, libc6-mips64-cross, 
linux-libc-dev-mips64-cross, binutils-powerpc64-linux-gnu, libc6-ppc64-cross, 
linux-libc-dev-ppc64-cross, binutils-riscv64-linux-gnu, libc6-riscv64-cross, 
linux-libc-dev-riscv64-cross, binutils-sh4-linux-gnu, libc6-sh4-cross, 
linux-libc-dev-sh4-cross, binutils-sparc64-linux-gnu, libc6-sparc64-cross, 
linux-libc-dev-sparc64-cross, binutils-powerpc-linux-gnu, libc6-powerpc-cross, 
linux-libc-dev-powerpc-cross, binutils-powerpc-linux-gnuspe, 
libc6-powerpcspe-cross, linux-libc-dev-powerpcspe-cross, 
binutils-mips64-linux-gnuabin32, libc6-mipsn32-cross, 
linux-libc-dev-mipsn32-cross, binutils-mips64el-linux-gnuabin32, 
libc6-mipsn32el-cross, linux-libc-dev-mipsn32el-cross, 
binutils-mipsisa32r6-linux-gnu, libc6-mipsr6-cross, 
linux-libc-dev-mipsr6-cross, binutils-mipsisa32r6el-linux-gnu, 
libc6-mipsr6el-cross, linux-libc-dev-mipsr6el-cross, 
binutils-mipsisa64r6-linux-gnuabin32, libc6-mipsn32r6-cross, 
linux-libc-dev-mipsn32r6-cross, binutils-mipsisa64r6el-linux-gnuabin32, 
libc6-mipsn32r6el-cross, linux-libc-dev-mipsn32r6el-cross, 
binutils-mipsisa64r6-linux-gnuabi64, libc6-mips64r6-cross, 
linux-libc-dev-mips64r6-cross, binutils-mipsisa64r6el-linux-gnuabi64, 
libc6-mips64r6el-cross, linux-libc-dev-mips64r6el-cross,
   libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
 
 Package: linux-libc-dev-alpha-cross
@@ -88,6 +88,18 @@
  libraries. They are NOT meant to be used to build third-party modules for
  your kernel. Use linux-headers-* packages for that.
 
+Package: linux-libc-dev-riscv64-cross
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}
+Provides: linux-kernel-headers-riscv64-cross, linux-libc-dev-riscv64-dcv1
+Built-Using: ${bu:linux}
+Description: Linux Kernel Headers for development (for cross-compiling)
+ This package provides headers from the Linux kernel.  These headers
+ are used by the installed headers for GNU glibc and other system
+ libraries. They are NOT meant to be used to build third-party modules for
+ your kernel. Use linux-headers-* packages for that.
+
 Package: linux-libc-dev-sh4-cross
 Architecture: all
 Multi-Arch: foreign
@@ -358,6 +370,32 @@
 Built-Using: ${bu:glibc}
 Description: GNU C 

Bug#852856: collaborate

2018-03-12 Thread Geert Stappers
> I'm not sure that's entirely appropriate. You can perfectly easily add
> some udev rules to urjtag, rather than expecting openocd to solve the
> problem for you. It can even be done in a way that means the 2 packages
> can co-exist. #852856 is a wishlist bug that essentially says "we do the
> same thing, I'd like to take advantage of the work you've already done
> rather than maintaining a similar list myself".

In my words:

Avoiding duplicate work.


My plan:

Applying the patches, become stakeholder of openocd package.
Working together.


Groeten
Geert Stappers
-- 
Leven en laten leven



Bug#852856: 1:1 or one a subset of the other

2018-03-12 Thread Geert Stappers
On Mon, Mar 12, 2018 at 09:39:29AM +, Jonathan McDowell wrote:
> Is there a direct 1:1 mapping of devices that OpenOCD and urjtag
> support, or is one a subset of the other?

Seen the question, but I don't see where it fits
in the discussion about a openocd file moving into seperate package.


Groeten
Geert Stappers
-- 
Leven en laten leven



Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Georg Faerber
On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote:
> On 21:04 Mon 12 Mar , Mykola Nikishov wrote:
> > Package: puppet
> > Version: 5.4.0-1
> > Followup-For: Bug #892737
> > 
> > I have librarian-puppet and found out that downgrading it to jessie
> > will fix the problem. Downgrade will remove ruby-puppet-forge and
> > ruby-gettext-setup.
> > 
> > Seems ruby-gettext-setup causes this problem.
> 
> So, the version of ruby-gettext-setup is pretty outdated and predates
> Puppet's i18n system. When pulled in via i18n-enabled Puppet modules
> (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext
> default domain, causing breakage. This has been fixed upstream[1] in
> 0.17.
> 
> We should upgrade ruby-gettext-setup to the latest upstream version.

I could take care of this, tomorrow. Just need someone to sponsor the
upload.

Cheers,
Georg


signature.asc
Description: Digital signature


Bug#892004: Please adapt to gnome-settings-daemon 3.28 by March 15

2018-03-12 Thread Joachim Breitner
Hi,

I am unable to do something this week. Could someone else apply the
change and upload the package?

Thanks,
Joachim

Am Samstag, den 10.03.2018, 21:47 -0500 schrieb Jeremy Bicha:
> Please make your upload on or before March 15. Otherwise, we will need
> to NMU your package for the gnome-settings-daemon 3.28 transition.
> 
> On behalf of the Debian GNOME Team,
> Jeremy Bicha
> 
> 
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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


Bug#873224: Pending fixes for bugs in the sweethome3d package

2018-03-12 Thread pkg-java-maintainers
tag 873224 + pending
thanks

Some bugs in the sweethome3d package are closed in revision
0982915f254a0da748a5ae5f5bd1238b8e3c9e6b in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/sweethome3d.git/commit/?id=0982915

Commit message:

Fixed the build failure with Java 9 (Closes: #873224)



Bug#892789: prelude-manager: New upstream version 4.1.0

2018-03-12 Thread Thomas Andrejak
Source: prelude-manager
Version: 3.1.0-4
Severity: wishlist

prelude-manager 4.1 was released in 2017.

Thanks

Regards



Bug#874155: FTBFS with Java 9: overrides core packages

2018-03-12 Thread Emmanuel Bourg
Control: tag -1 + patch
Control: tag -1 - help

The org.xml.sax classes should be removed from the package. Until that
happens, the build failure can be solved with this patch:

--- a/build.xml
+++ b/build.xml
@@ -4,7 +4,7 @@
 
 
 
-
+
 
 
 



Bug#885204: gnucash: please migrate to guile-2.2

2018-03-12 Thread Dmitry Smirnov
Hi Rob,

On Tuesday, 26 December 2017 9:17:34 AM AEDT Rob Browning wrote:
> I'd like to remove guile-2.0 before the buster release, so please
> migrate to guile-2.2 when you can.

I tried to build Gnucash with "guile-2.2" but "dh_strip" failed as follows:


dh_strip --dbgsym-migration='gnucash-dbg (<< 1:2.6.13~)'
strip: Unable to recognise the format of the input file `debian/gnucash/usr/
lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.2/report.go'
dh_strip: strip --remove-section=.comment --remove-section=.note --strip-
unneeded debian/gnucash/usr/lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/
2.2/report.go returned exit code 1


There is no such problem with "guile-2.0"...

Any ideas what could be done about that?

Thanks.

Regards,
 Dmitry Smirnov.

---

Journalism is printing what someone else does not want printed: everything
else is public relations.
-- George Orwell

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


Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Apollon Oikonomopoulos
Control: reassign -1 ruby-gettext-setup
Control: retitle -1 ruby-gettext-setup: outdated version, hijacks gettext and 
breaks puppet
Control: found -1 0.7-1
Control: tags -1 severity serious

Hi,

On 21:04 Mon 12 Mar , Mykola Nikishov wrote:
> Package: puppet
> Version: 5.4.0-1
> Followup-For: Bug #892737
> 
> I have librarian-puppet and found out that downgrading it to jessie
> will fix the problem. Downgrade will remove ruby-puppet-forge and
> ruby-gettext-setup.
> 
> Seems ruby-gettext-setup causes this problem.

So, the version of ruby-gettext-setup is pretty outdated and predates 
Puppet's i18n system. When pulled in via i18n-enabled Puppet modules 
(e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext 
default domain, causing breakage. This has been fixed upstream[1] in 
0.17.

We should upgrade ruby-gettext-setup to the latest upstream version.

Regards,
Apollon

[1] 
https://github.com/puppetlabs/gettext-setup-gem/commit/0fcb0971faf094b0689bf302b04327a09de41c0e



Bug#892788: e2guardian: Please enable MITM Filtering HTTPS

2018-03-12 Thread Roger Lynn
Package: e2guardian
Version: 3.4.0.3-2
Severity: wishlist

Hi,

Please configure and compile e2guardian with the --enable-sslmitm=yes flag set.
Without this a content filter is not very useful on the modern internet.

Thanks,

Roger

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

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

Versions of packages e2guardian depends on:
ii  adduser 3.115
ii  clamav  0.99.4+dfsg-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libpcre32:8.39-3
ii  libstdc++6  6.3.0-18+deb9u1
ii  perl5.24.1-3+deb9u2
ii  zlib1g  1:1.2.8.dfsg-5

e2guardian recommends no packages.

Versions of packages e2guardian suggests:
ii  clamav-freshclam  0.99.4+dfsg-1+deb9u1
ii  squid 3.5.23-5+deb9u1

-- Configuration Files:
/etc/e2guardian/e2guardian.conf changed:
languagedir = '/usr/share/e2guardian/languages'
language = 'ukenglish'
loglevel = 2
logexceptionhits = 2
logfileformat = 1
dstatlocation = '/var/log/e2guardian/dstats.log'
filterip = 192.168.0.2
filterports = 8080
proxyip = 127.0.0.1
proxyport = 3128
proxytimeout = 20
proxyexchange = 20
pcontimeout = 55
usecustombannedimage = on
custombannedimagefile = '/usr/share/e2guardian/transparent1x1.gif'
usecustombannedflash = on
custombannedflashfile = '/usr/share/e2guardian/blockedflash.swf'
filtergroups = 1
filtergroupslist = '/etc/e2guardian/lists/filtergroupslist'
bannediplist = '/etc/e2guardian/lists/bannediplist'
exceptioniplist = '/etc/e2guardian/lists/exceptioniplist'
showweightedfound = on
urlcachenumber = 1000
urlcacheage = 900
scancleancache = on
phrasefiltermode = 2
preservecase = 0
hexdecodecontent = off
forcequicksearch = off
reverseaddresslookups = on
reverseclientiplookups = on
logclienthostnames = on
prefercachedlists = off
maxcontentfiltersize = 1024
maxcontentramcachescansize = 16384
maxcontentfilecachescansize = 65536
filecachedir = '/tmp'
deletedownloadedtempfiles = on
initialtrickledelay = 20
trickledelay = 10
downloadmanager = '/etc/e2guardian/downloadmanagers/fancy.conf'
downloadmanager = '/etc/e2guardian/downloadmanagers/default.conf'
contentscanner = '/etc/e2guardian/contentscanners/clamdscan.conf'
contentscannertimeout = 60
contentscanexceptions = off
recheckreplacedurls = off
forwardedfor = off
usexforwardedfor = off
logconnectionhandlingerrors = on
logsslerrors = off
logchildprocesshandling = off
maxchildren = 180
minchildren = 20
minsparechildren = 16
preforkchildren = 10
maxsparechildren = 32
maxagechildren = 500
maxips = 0
ipcfilename = '/tmp/.e2guardianipc'
urlipcfilename = '/tmp/.e2guardianurlipc'
ipipcfilename = '/tmp/.e2guardianipipc'
nodaemon = off
nologger = off
logadblocks = off
loguseragent = off
softrestart = off
mailer = '/usr/sbin/sendmail -t'
cacertificatepath = '/etc/e2guardian/ssl/my_rootCA.crt'
caprivatekeypath = '/etc/e2guardian/ssl/private_root.pem'
certprivatekeypath = '/etc/e2guardian/ssl/private_cert.pem'
generatedcertpath = '/var/log/e2guardian/generatedcerts/'

/etc/e2guardian/e2guardianf1.conf changed:
groupmode = 1
groupname = ''
bannedphraselist = '/etc/e2guardian/lists/bannedphraselist'
weightedphraselist = '/etc/e2guardian/lists/weightedphraselist'
exceptionphraselist = '/etc/e2guardian/lists/exceptionphraselist'
bannedsitelist = '/etc/e2guardian/lists/bannedsitelist'
greysitelist = '/etc/e2guardian/lists/greysitelist'
bannedsslsitelist = '/etc/e2guardian/lists/bannedsslsitelist'
greysslsitelist = '/etc/e2guardian/lists/greysslsitelist'
exceptionsitelist = '/etc/e2guardian/lists/exceptionsitelist'
bannedurllist = '/etc/e2guardian/lists/bannedurllist'
greyurllist = '/etc/e2guardian/lists/greyurllist'
exceptionurllist = '/etc/e2guardian/lists/exceptionurllist'
exceptionregexpurllist = '/etc/e2guardian/lists/exceptionregexpurllist'
bannedregexpurllist = '/etc/e2guardian/lists/bannedregexpurllist'
picsfile = '/etc/e2guardian/lists/pics'
contentregexplist = '/etc/e2guardian/lists/contentregexplist'
urlregexplist = '/etc/e2guardian/lists/urlregexplist'
refererexceptionsitelist = '/etc/e2guardian/lists/refererexceptionsitelist'
refererexceptionurllist = '/etc/e2guardian/lists/refererexceptionurllist'
embededreferersitelist = '/etc/e2guardian/lists/embededreferersitelist'
embededrefererurllist = '/etc/e2guardian/lists/embededrefererurllist'
urlredirectregexplist = '/etc/e2guardian/lists/urlredirectregexplist'
!! Not compiled !! authexceptionsitelist = 
'/etc/e2guardian/lists/authexceptionsitelist'
!! Not compiled !! authexceptionurllist = 
'/etc/e2guardian/lists/authexceptionurllist'
blockdownloads = off
exceptionextensionlist = '/etc/e2guardian/lists/exceptionextensionlist'
exceptionmimetypelist = 

Bug#882694: [sysadmin] Signatures on uncompressed archives

2018-03-12 Thread Konstantin Ryabitsev
On 03/08/18 05:15, Uwe Kleine-König wrote:
> Hello,
> 
> I hope to have selected the right contact address for this mail, if not,
> please tell me or forward accordingly.
> 
> The kernel.org archive provides signatures for the software available
> (which is great!). The method to verify these according to
> 
>   
> https://www.kernel.org/category/signatures.html#using-gnupg-to-verify-kernel-signatures
> 
> is to download the .tar.xz and the .tar.sign file, unxz the archive and
> check the signature against the .tar file.
> 
> For one this is inconvenient because most tools don't know
> this scheme. In my case this is tooling from Debian to work with
> upstream archives[1].

I know it's a problem for Debian, but changing this scheme for us would
require significant retooling just as it would for Debian infra. The
major upside of the current approach is that we are free to add new
compressors, recompress existing archives with higher compression
ratios, etc, without needing to re-sign all files.

> But it also has an impact on security: As long as the signature isn't
> verified I have to consider the .tar.xz "untrusted" and the less tools I
> have to make operate on it the better.  This scheme allows an attacker
> that has control over a mirror to provide a .tar.xz that makes unxz do
> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an
> attack idea.

Which is why we provide sha256sums.asc in each directory.

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature


Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

2018-03-12 Thread Emmanuel Bourg
Le 08/03/2018 à 13:29, 殷啟聰 | Kai-Chung Yan a écrit :

> I tried building Maven Dependency Tree 2.2 against Maven 3.x and found that 
> it uses removed APIs, and that patching it would make a huge code change. 
> Maybe someone else would have a better skill than me to do the job, but I 
> simply don't think this is a good or sustainable idea...

It looks like Fedora has already done the job:

https://src.fedoraproject.org/rpms/maven-plugin-bundle/blob/master/f/0001-Port-to-current-maven-dependency-tree.patch

With this patch they build the bundle plugin 3.5.0 with
maven-dependency-tree 3.0.



Bug#892787: python-asyncssh: CVE-2018-7749

2018-03-12 Thread Salvatore Bonaccorso
Source: python-asyncssh
Version: 1.11.1-1
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for python-asyncssh,
although there should be not "servers" implemented in Debian
depending on python3-asyncssh, still chosed an RC severity to have the
fix certain included in next stable release (but expect that 1.12.1
land soon anyhow in unstable).

CVE-2018-7749[0]:
| The SSH server implementation of AsyncSSH before 1.12.1 does not
| properly check whether authentication is completed before processing
| other requests. A customized SSH client can simply skip the
| authentication step.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7749
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7749
[1] 
https://github.com/ronf/asyncssh/commit/c161e26cdc0d41b745b63d9f17b437f073bf7ba4

Regards,
Salvatore



Bug#892786: linux,arm64: please enable modules needed for teres-i OSHW laptop

2018-03-12 Thread Harald Geyer
Source: linux
Version: 4.15.4-1
Severity: wishlist

Hi,

I have the TERES I open hardware laptop from olimex
https://www.olimex.com/Products/DIY-Laptop/
running with buster, but I had to recompile the kernel to get all
the modules necessary to have a useable system.

Mainlineing the devicetree file for the teres is work in progress,
(see: https://lkml.org/lkml/2018/3/12/653 ) but most of the missing
bit's in the kernel config are needed for all Allwinner A64 based
boards anyway - many of which already have upstream support.

Please enable the following configuration symbols for arm64 builds:

1) Relevant to all A64 based systems and other SoCs using the AXP803
PMIC:
at least:
CONFIG_MFD_AXP20X=y
CONFIG_MFD_AXP20X_RSB=y
CONFIG_REGULATOR_AXP20X=m
CONFIG_INPUT_AXP20X_PEK=m

(note about builtin vs. module: This is the combination I tested. It should
be possible to have everything as modules so long as mkinitramfs puts
them into the initrd. In theory we also need the regulator module in the
initrd to power up the supply chain of the MMC hosts. In practice MMCs
are already powered up by the boot loader, but we need at least the mfd
part of the pmic driver, to get the kernel probing the devices.

You might want to draw the line between builtin and module drivers in a
saner way. I can test your configuration, once you have made up your mind.)

probably also (untested yet, but will be demanded in the future obviously):
CONFIG_PINCTRL_AXP209=m
CONFIG_CHARGER_AXP20X=m
CONFIG_BATTERY_AXP20X=m
CONFIG_AXP20X_POWER=m
CONFIG_AXP288_FUEL_GAUGE=m
CONFIG_AXP20X_ADC=m
CONFIG_AXP288_ADC=m

2) Relevant to A64 based systems, driver available since long and likely
going to be enabled by default in upstream devicetrees starting with 4.17:
CONFIG_SUNXI_WATCHDOG=m

3) Relevant at least to A64 based systems with backlight. Probably at the
moment only the teres-i laptop:
CONFIG_PWM_SUN4I=m
CONFIG_BACKLIGHT_PWM=m

4) Maybe not relevant at the moment, but might be a sane default to include
anyway:
CONFIG_LEDS_PWM=m


BTW, as you might have inferred from my message, I'm a bit unsure how
you decide which drivers to enable. Do you have a script, that scan's the
device trees for required drivers (if so it clearly failed to find the
drivers listed in (1)), or do you rely solely on users speaking up when
something is missing? Any hints on how to efficiently report missing
drivers or upcoming upstream changes would be appreciated.


Thanks for your consideration,
Harald



Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Apollon Oikonomopoulos
Control: tags -1 - unreproducible moreinfo

On 21:04 Mon 12 Mar , Mykola Nikishov wrote:
> Package: puppet
> Version: 5.4.0-1
> Followup-For: Bug #892737
> 
> I have librarian-puppet and found out that downgrading it to jessie
> will fix the problem. Downgrade will remove ruby-puppet-forge and
> ruby-gettext-setup.
> 
> Seems ruby-gettext-setup causes this problem.

Okay, it's actually ruby-semantic-puppet that resets the default text 
domain. Thanks for your feedback!

Regards,
Apollon



Bug#892785: zaqar-ui FTBFS: ImportError: No module named openstack_dashboard.test.settings

2018-03-12 Thread Adrian Bunk
Source: zaqar-ui
Version: 1.0.0~rc1-2
Severity: serious
Tags: buster sid

Some recent change in unstable makes zaqar-ui FTBFS:

https://tests.reproducible-builds.org/debian/history/zaqar-ui.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zaqar-ui.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/zaqar-ui-1.0.0~rc1'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
bash run_tests.sh -N --no-pep8
Running Zaqar UI tests
Traceback (most recent call last):
  File "/build/1st/zaqar-ui-1.0.0~rc1/manage.py", line 23, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 364, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 308, in execute
settings.INSTALLED_APPS
  File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 56, in 
__getattr__
self._setup(name)
  File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 41, in 
_setup
self._wrapped = Settings(settings_module)
  File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 110, in 
__init__
mod = importlib.import_module(self.SETTINGS_MODULE)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named openstack_dashboard.test.settings
Tests failed.
make[1]: *** [debian/rules:10: override_dh_auto_test] Error 1



Bug#892784: zaqar FTBFS: test failures

2018-03-12 Thread Adrian Bunk
Source: zaqar
Version: 6.0.0-1
Severity: serious

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

...
==
FAIL: 
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_2___
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_2___
--
_StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: 
action "queue_create", body {"queue_name": "skittle"}.}}}

Traceback (most recent call last):
  File 
"/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py",
 line 50, in setUp
self.assertEqual(201, resp['headers']['status'])
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 204


==
FAIL: 
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_4__fail_
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_4__fail_
--
_StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: 
action "queue_create", body {"queue_name": "skittle"}.}}}

Traceback (most recent call last):
  File 
"/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py",
 line 50, in setUp
self.assertEqual(201, resp['headers']['status'])
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 204


==
FAIL: 
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_get_claim_nonexistent_queue
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_get_claim_nonexistent_queue
--
_StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: 
action "queue_create", body {"queue_name": "skittle"}.}}}

Traceback (most recent call last):
  File 
"/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py",
 line 50, in setUp
self.assertEqual(201, resp['headers']['status'])
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 204


==
FAIL: 
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_3__
zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_3__
--
_StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: 
action "queue_create", body {"queue_name": "skittle"}.}}}

Traceback (most recent call last):
  File 
"/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py",
 line 50, in setUp
self.assertEqual(201, resp['headers']['status'])
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 204


==
FAIL: 
zaqar.tests.unit.transport.websocket.v2.test_messages.MessagesBaseTest.test_post_invalid_ttl
zaqar.tests.unit.transport.websocket.v2.test_messages.MessagesBaseTest.test_post_invalid_ttl
--
_StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: 
action "queue_create", body {"queue_name": "kitkat"}.}}}

Traceback (most recent call last):
  File 
"/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_messages.py",
 line 56, in setUp
self.assertEqual(201, resp['headers']['status'])
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 204



Bug#892783: watcher FTBFS: test failures

2018-03-12 Thread Adrian Bunk
Source: watcher
Version: 1.4.1-3
Severity: serious

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

...
==
FAIL: watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_cached
watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_cached
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "watcher/tests/common/test_clients.py", line 218, in 
test_clients_gnocchi_cached
gnocchi = osc.gnocchi()
  File "watcher/common/exception.py", line 46, in wrapped
return func(*args, **kw)
  File "watcher/common/clients.py", line 115, in gnocchi
session=self.session)
  File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in 
Client
return client_class(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'interface'


==
FAIL: 
watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_endpoint
watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_endpoint
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "watcher/tests/common/test_clients.py", line 211, in 
test_clients_gnocchi_diff_endpoint
osc.gnocchi()
  File "watcher/common/exception.py", line 46, in wrapped
return func(*args, **kw)
  File "watcher/common/clients.py", line 115, in gnocchi
session=self.session)
  File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in 
Client
return client_class(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'interface'


==
FAIL: 
watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_vers
watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_vers
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "watcher/tests/common/test_clients.py", line 202, in 
test_clients_gnocchi_diff_vers
osc.gnocchi()
  File "watcher/common/exception.py", line 46, in wrapped
return func(*args, **kw)
  File "watcher/common/clients.py", line 115, in gnocchi
session=self.session)
  File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in 
Client
return client_class(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'interface'


==
FAIL: watcher.tests.common.test_service.TestService.test_build_topic_handler
watcher.tests.common.test_service.TestService.test_build_topic_handler
--
_StringException: Traceback (most recent call last):
  File "watcher/tests/common/test_service.py", line 94, in 
test_build_topic_handler
dummy_service = service.Service(DummyManager)
  File "watcher/common/service.py", line 204, in __init__
self.conductor_topic, self.conductor_endpoints)
  File "watcher/common/service.py", line 249, in build_topic_handler
access_policy=access_policy)
  File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 
208, in get_rpc_server
access_policy)
  File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", 
line 161, in __init__
raise TypeError("%s: endpoint=%s" % (errmsg, ep))
TypeError: 'target' is a reserved Endpoint attribute used for namespace and 
version filtering.  It must be of type oslo_messaging.Target. Do not define an 
Endpoint method named 'target': endpoint=


==
FAIL: watcher.tests.common.test_service.TestService.test_init_service
watcher.tests.common.test_service.TestService.test_init_service
--
_StringException: Traceback (most recent call last):
  File "watcher/tests/common/test_service.py", line 101, in test_init_service
dummy_service = service.Service(DummyManager)
  File "watcher/common/service.py", line 204, in __init__
self.conductor_topic, self.conductor_endpoints)
  File "watcher/common/service.py", line 249, in build_topic_handler
access_policy=access_policy)
  File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 
208, in get_rpc_server
access_policy)
  File 

Bug#884923: abiword: CVE-2017-17529

2018-03-12 Thread Salvatore Bonaccorso
Jeremy,

On Sun, Mar 11, 2018 at 08:45:42AM -0400, Jeremy Bicha wrote:
> On Sun, Mar 11, 2018 at 8:40 AM, Salvatore Bonaccorso  
> wrote:
> > Is abiword upstream still active?
> 
> Yes.
> 
> https://bugzilla.abisource.com/
> 
> Here's a git mirror of their svn repo. The git mirror is sometimes a
> bit out of date.
> https://github.com/AbiWord/abiword/commits/trunk

Thanks, indeed for the pointer.

Can you forward the issue to upstream?

Regards,
Salvatore



Bug#891511: ip route flush all does not work any more

2018-03-12 Thread Stephen Hemminger
On Mon, 12 Mar 2018 19:48:33 +
Luca Boccassi  wrote:

> On Mon, 2018-03-05 at 08:51 -0800, Stephen Hemminger wrote:
> > On Sun, 04 Mar 2018 22:07:37 +
> > Luca Boccassi  wrote:
> > 
> > > On Mon, 26 Feb 2018 12:05:05 +0100 Wolfgang Walter  > > @stw
> > > m.de> wrote:
> > > > Package: iproute2
> > > > Version: 4.15.0-2
> > > >  
> > > > Hello,
> > > >  
> > > > after upgrading iproute2 from 4.14.1-2 to 4.15.0-2
> > > >  
> > > >     ip route flush all
> > > >  
> > > > seems not to work any more. It does not remove all ipv4 routes
> > > > from  
> > > 
> > > the main 
> > > > table as it did before. Downgrading to 4.14.1-2 fixes the
> > > > problem.
> > > >  
> > > > Basically 4.15.0-2 removes the default route, but other routes
> > > > are  
> > > 
> > > not 
> > > > removed.
> > > >  
> > > > What still works is
> > > >  
> > > >     ip route flush table main 
> > > >  
> > > >  
> > > > Another thing which changed is that
> > > >  
> > > >     ip route ls all
> > > >  
> > > > now does not show anything but the default route whereas it used
> > > > to  
> > > 
> > > show all 
> > > > routes of the main table.  
> > > 
> > > Hi,
> > > 
> > > Yes can confirm, it's easily reproduced.
> > > 
> > > Stephen, do you know if is this a known change in behaviour?
> > > 
> > > With 4.14.0:
> > > 
> > > $ ip route ls all
> > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 
> > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > > metric 600 
> > > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > > 192.168.122.1 linkdown
> > > 
> > > With 4.15.0:
> > > 
> > > $ ip route ls all
> > > default via 192.168.1.1 dev wlp2s0 proto static metric 600
> > > 
> > > Further tests with 4.15.0:
> > > 
> > > $ ip route ls table main
> > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 
> > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > > metric 600 
> > > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > > 192.168.122.1 linkdown 
> > > $ sudo ip route flush all
> > > $ ip route ls all
> > > $ ip route ls table main
> > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > > metric 600 
> > > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > > 192.168.122.1 linkdown 
> > > 
> > > $ sudo ip route add default via 192.168.1.1
> > > $ ip route ls table main
> > > default via 192.168.1.1 dev wlp2s0 
> > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > > metric 600 
> > > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > > 192.168.122.1 linkdown 
> > > $ ip route ls all
> > > default via 192.168.1.1 dev wlp2s0 
> > > $ sudo ip route flush table main
> > > $ ip route ls all
> > > $ ip route ls table main
> > 
> > Is it a kernel or iproute issue? Should be bisectable.
> 
> Hi Stephen,
> 
> It was caused by this commit:
> 
> commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2
> Author: Alexander Zubkov 
> Date:   Sun Dec 17 12:09:00 2017 +0100
> 
> iproute: "list/flush/save default" selected all of the routes
> 
> When running "ip route list default" and not specifying address family,
> one will get all of the routes instead of just default only. The same
> is for "exact default" and "match default".
> 
> It behaves in such a way because default route with unspecified family
> has the same all-zeroes value like no prefix specified at all. Thus
> following code blindly ignores the fact, that prefix was actually
> specified.
> 
> This patch adds the flag PREFIXLEN_SPECIFIED to the default route too.
> And then checks its value when filtering routes.
> 
> 
> 
> Looking at the message, it looks like it might have been intentional?
> But it looks like a backward-incompatible change to me
> 

My expectation is that:
  # ip route flush
is for flushing all routes. And the patch in question was for
  # ip route flush default

The issue is that default means 0/0 (or::/0) which is also a wildcard for 
flushing
all.  Right now I am going to revert the original patch since it was only
because ip didn't do what one  user expected; not the same as breaking everyone 
else.



pgprhkwai_wBZ.pgp
Description: OpenPGP digital signature


Bug#890954: upload 65.0.3325.146-2

2018-03-12 Thread 積丹尼 Dan Jacobson
Please upload 65.0.3325.146-2 to experimental so we can test. Thanks.



Bug#886326: stretch-pu: package zssh/1.5c.debian.1-3.2+deb9u1

2018-03-12 Thread Adrian Bunk
On Sat, Feb 10, 2018 at 07:20:51PM +0800, Boyuan Yang wrote:
>...
> As described in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769366#61 , Current
> version
> of zssh in Debian Stretch (on amd64 architecture, versioned
> 1.5c.debian.1-3.2+b4) suffers from
> RC bug #769366. I had little idea why this happened because a
> no-change rebuild on Debian
> Stretch would make zssh fully functional.
>...
> How does a rebuild solve it? I have no idea currently: It Just Works™.
> I could have digged into
> the problem but the time to be spent would not be efficient when a
> simple rebuild solves it.
> 
> I think those described above should make a stretch-pu for zssh reasonable.

What actually fixed zssh in 1.5c.debian.1-4 is the following:
  * Bump debhelper compat to v10.

After looking at the #388036 fix I tried v9 instead,
and as expected this gave me a broken package,

An actual fix would be something like:

diff -Nru zssh-1.5c.debian.1/debian/control zssh-1.5c.debian.1/debian/control
--- zssh-1.5c.debian.1/debian/control   2014-07-21 11:30:52.0 +0300
+++ zssh-1.5c.debian.1/debian/control   2018-03-12 22:33:59.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Ben Wong 
-Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libncurses5-dev, 
libreadline-dev, autoconf, quilt
+Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libncurses5-dev, 
libreadline-dev, autoconf, quilt, dh-autoreconf
 Standards-Version: 3.7.2
 
 Package: zssh
diff -Nru zssh-1.5c.debian.1/debian/rules zssh-1.5c.debian.1/debian/rules
--- zssh-1.5c.debian.1/debian/rules 2014-07-21 11:27:39.0 +0300
+++ zssh-1.5c.debian.1/debian/rules 2018-03-12 22:08:24.0 +0200
@@ -2,6 +2,7 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 include /usr/share/cdbs/1/rules/patchsys-quilt.mk
 
 DEB_INSTALL_DOCS_ALL += FAQ


> Regards,
> Boyuan Yang

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#892781: iselect: prefers slcurses over ncurses

2018-03-12 Thread Sven Joachim
Control: tags -1 + patch

On 2018-03-12 21:12 +0100, Sven Joachim wrote:

> Source: iselect
> Version: 1.4.0-3
>
> If libslang2-dev is installed on the build system, iselect's configure
> script selects slcurses (slang's curses emulation) rather than ncurses,
> which is not really desirable.  Here is the relevant output:
>
> ,
> | CHECK: Curses Environment
> | checking for additional include dir... none particular
> | checking for additional library dir... none particular
> | checking for grep that handles long lines and -e... /bin/grep
> | checking for egrep... /bin/grep -E
> | checking for ANSI C header files... yes
> | checking for sys/types.h... yes
> | checking for sys/stat.h... yes
> | checking for stdlib.h... yes
> | checking for string.h... yes
> | checking for memory.h... yes
> | checking for strings.h... yes
> | checking for inttypes.h... yes
> | checking for stdint.h... yes
> | checking for unistd.h... yes
> | checking ncurses/ncurses.h usability... no
> | checking ncurses/ncurses.h presence... no
> | checking for ncurses/ncurses.h... no
> | checking for initscr in -lncurses... yes
> | checking slcurses.h usability... yes
> | checking slcurses.h presence... yes
> | checking for slcurses.h... yes
> | checking for SLcurses_initscr in -lslang... yes
> | checking which Curses to use... S-Lang Curses
> `
>
> There is no ncurses/ncurses.h in Debian.

The fix-ncurses-include-path.diff already took care of that for the
header files in iselect, I have amended it to also correct the path in
configure.in, which was enough to persuade "configure" to select ncurses
rather than slcurses. :-)

,
| CHECK: Curses Environment
| checking for additional include dir... none particular
| checking for additional library dir... none particular
| checking for grep that handles long lines and -e... /bin/grep
| checking for egrep... /bin/grep -E
| checking for ANSI C header files... yes
| checking for sys/types.h... yes
| checking for sys/stat.h... yes
| checking for stdlib.h... yes
| checking for string.h... yes
| checking for memory.h... yes
| checking for strings.h... yes
| checking for inttypes.h... yes
| checking for stdint.h... yes
| checking for unistd.h... yes
| checking ncurses.h usability... yes
| checking ncurses.h presence... yes
| checking for ncurses.h... yes
| checking for initscr in -lncurses... yes
| checking slcurses.h usability... yes
| checking slcurses.h presence... yes
| checking for slcurses.h... yes
| checking for SLcurses_initscr in -lslang... yes
| checking which Curses to use... GNU NCurses
`

Cheers,
   Sven

>From 4f1bc112817ccd00e456ab49d5ae6cec69f4 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 12 Mar 2018 21:24:21 +0100
Subject: [PATCH] Also fix the path to ncurses.h in configure.in

There is no ncurses/ncurses.h in Debian, and if libslang2-dev is
installed on the build system, configure would prefer slcurses over
ncurses.
---
 debian/patches/fix-ncurses-include-path.diff | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/debian/patches/fix-ncurses-include-path.diff b/debian/patches/fix-ncurses-include-path.diff
index 4429533..7ef8e7a 100644
--- a/debian/patches/fix-ncurses-include-path.diff
+++ b/debian/patches/fix-ncurses-include-path.diff
@@ -22,3 +22,14 @@ Fixes the include path for the ncurses header files.
  #endif
  #ifdef USE_SLCURSES
  #include 
+--- iselect-1.3.1.orig/configure.in
 iselect-1.3.1/configure.in
+@@ -61,7 +61,7 @@ x="none particular"
+ )dnl
+ AC_MSG_RESULT([$x])
+ 
+-AC_CHECK_HEADER(ncurses/ncurses.h, HAVE_NCURSES_HEADER=YES, HAVE_NCURSES_HEADER=NO)
++AC_CHECK_HEADER(ncurses.h, HAVE_NCURSES_HEADER=YES, HAVE_NCURSES_HEADER=NO)
+ AC_CHECK_LIB(ncurses, initscr, HAVE_NCURSES_LIB=YES, HAVE_NCURSES_LIB=NO)
+ AC_CHECK_HEADER(slcurses.h, HAVE_SLCURSES_HEADER=YES, HAVE_SLCURSES_HEADER=NO)
+ OLIBS=$LIBS
-- 
2.16.2



Bug#892766: CVE-2017-15422

2018-03-12 Thread Salvatore Bonaccorso
Control: tags 892766 + upstream fixed-upstream

Hi Moritz, hi Laszlo,

On Mon, Mar 12, 2018 at 07:54:37PM +0100, Moritz Muehlenhoff wrote:
> Source: icu
> Severity: grave
> Tags: security
> 
> Hi Laszlo,
> https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html
> refers to a ICU vulnerability, but there's little information what 
> fixes/fixed that.
> 
> Could you reach out to upstream whether they've been in touch with them so 
> that
> we can pinpoint this a specific task/commit?

The upstream issue is now accessible, at
https://bugs.chromium.org/p/chromium/issues/detail?id=774382 which
refers to the interger overflow related to the persian calendar
integer overflow, leading to oob read. The comment #16 indicates which
change fixed the bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=774382#c16 which
in turns would be integrated in the following upstream change:
https://ssl.icu-project.org/trac/changeset/40654

Regards,
Salvatore



Bug#892372: proftpd-mod-msg FTBFS with proftpd 1.3.6-1

2018-03-12 Thread Hilmar Preuße
On 09.03.2018 16:35, Francesco P. Lovergine wrote:
> On Thu, Mar 08, 2018 at 05:27:10PM +0200, Adrian Bunk wrote:

Hi,

>> mod_msg.c:56:3: error: #error "mod_msg requires Controls support
>> (--enable-ctrls)"
>> # error "mod_msg requires Controls support (--enable-ctrls)"
>>   ^
>>
> 
> This is another trivial fix, just s/USE_CTRLS/PR_USE_CTRLS/ in source.
> 
Sorry, was not that easy. I'll contact tj directly; this module is not
on github.

Hilmar
-- 
#206401 http://counter.li.org



Bug#892373: [INFO] Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1

2018-03-12 Thread Hilmar Preuße
On 10.03.2018 08:44, Francesco Paolo Lovergine wrote:

Hi Francesco,

> Nave a look onto  Castaglia's github repo
> 
I've updated the git repo to 0.3, attached is the new orig.tar.gz.

Hilmar
-- 
#206401 http://counter.li.org


proftpd-mod-fsync_0.3.orig.tar.gz
Description: application/gzip


Bug#892371: proftpd-mod-vroot FTBFS with proftpd 1.3.6-1

2018-03-12 Thread Hilmar Preuße
On 09.03.2018 16:19, Francesco P. Lovergine wrote:
> On Thu, Mar 08, 2018 at 05:25:20PM +0200, Adrian Bunk wrote:

Hi Francesco,

>> mod_vroot.c: In function 'vroot_pre_pass':
>> mod_vroot.c:1651:7: error: 'pr_fs_t {aka struct fs_rec}' has no member
>> named 'creat'; did you mean 'read'?
>>   fs->creat = vroot_creat;
>>   ^
>>
> 
> This is fixed in 0.9.7, better upgrading.
> 
I've pulled the two patches from github fixing this bug. They are in our
git, feel free to upload. The new version does not bring many
improvement IMHO, so this can be delayed.

Hilmar
-- 
#206401 http://counter.li.org



Bug#892781: iselect: prefers slcurses over ncurses

2018-03-12 Thread Sven Joachim
Source: iselect
Version: 1.4.0-3

If libslang2-dev is installed on the build system, iselect's configure
script selects slcurses (slang's curses emulation) rather than ncurses,
which is not really desirable.  Here is the relevant output:

,
| CHECK: Curses Environment
| checking for additional include dir... none particular
| checking for additional library dir... none particular
| checking for grep that handles long lines and -e... /bin/grep
| checking for egrep... /bin/grep -E
| checking for ANSI C header files... yes
| checking for sys/types.h... yes
| checking for sys/stat.h... yes
| checking for stdlib.h... yes
| checking for string.h... yes
| checking for memory.h... yes
| checking for strings.h... yes
| checking for inttypes.h... yes
| checking for stdint.h... yes
| checking for unistd.h... yes
| checking ncurses/ncurses.h usability... no
| checking ncurses/ncurses.h presence... no
| checking for ncurses/ncurses.h... no
| checking for initscr in -lncurses... yes
| checking slcurses.h usability... yes
| checking slcurses.h presence... yes
| checking for slcurses.h... yes
| checking for SLcurses_initscr in -lslang... yes
| checking which Curses to use... S-Lang Curses
`

There is no ncurses/ncurses.h in Debian.


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

Kernel: Linux 4.15.9-nouveau (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)



Bug#892525: cups-daemon: Cannot print with HPLIP backend

2018-03-12 Thread Brian Potkin
Hello intrigeri, thank you for caring about the printing system.


On Sat 10 Mar 2018 at 08:50:45 +0100, intrig...@debian.org wrote:

> Package: cups-daemon
> Version: 2.2.6-5
> Severity: normal
> 
> Hi,
> 
> for now this bug report is mostly a note to myself (and to whoever
> wants to help investigating/fixing this problem).

I don't know how much help I will be but I'll give it a try.

> A few days ago on an up-to-date sid system I was unable to print with
> the HPLIP backend. In the Journal I saw:
> 
>   /hpfax[4306]: [4306]: error: Failed to create /var/spool/cups/tmp/.hplip
> 
> I don't know yet if this issue is AppArmor-related and will
> investigate once I have access to that printer again in a few days.
> /usr/lib/cups/backend/hpfax is supposed to be confined under the
> third_party child profile which allows any "file" operation so in
> theory AppArmor cannot trigger the above log line.

Firstly: not being able to print and the error message may not be
linked.

Secondly: there is Debian bug report #789286:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789286

but it is not choc-a-bloc full of detail; the bug submitter wasn't
pressed for details on any inability to print.

Thirdly: LP #1490321 doesn't really lead anywhere:

  https://bugs.launchpad.net/hplip/+bug/1490321

Fourthly: FWIW, I'd guess AppArmor need not be involved. (But that is
for you to decide).

You should not need access to the printer. The wiki has details but it
is only necessary in most cases to set up a print queue:

 lpadmin -p test -v file:/dev/null -E -m 

Then

 lp -d test 

and look at the error_log.

Get the printer's PPD from 'lpinfo -m'.

> (Probably unrelated, on cupsd startup I see:
> 
>   audit[14628]: AVC apparmor="DENIED" operation="capable"
>   profile="/usr/sbin/cupsd" pid=14628 comm="cupsd" capability=12
>   capname="net_admin"
> 
> I'll file a dedicated bug (+patch) for that one once I've confirmed
> it's orthogonal to the HPLIP issue.)

Not seen that.

Cheers,

Brian.



Bug#892782: CVE-2018-7728 / CVE-2018-7729 / CVE-2018-7730 / CVE-2018-7731

2018-03-12 Thread Moritz Muehlenhoff
Package: libexempi3
Severity: important
Tags: security

There's a few denial of service bugs in exempi, please see
https://security-tracker.debian.org/tracker/CVE-2018-7728
https://security-tracker.debian.org/tracker/CVE-2018-7729
https://security-tracker.debian.org/tracker/CVE-2018-7730
https://security-tracker.debian.org/tracker/CVE-2018-7731

Cheers,
Moritz



Bug#892780: Several security issues

2018-03-12 Thread Moritz Muehlenhoff
Source: cimg
Severity: important
Tags: security

Please see these links for details and patches:
https://security-tracker.debian.org/tracker/CVE-2018-7641
https://security-tracker.debian.org/tracker/CVE-2018-7640
https://security-tracker.debian.org/tracker/CVE-2018-7639
https://security-tracker.debian.org/tracker/CVE-2018-7638
https://security-tracker.debian.org/tracker/CVE-2018-7637
https://security-tracker.debian.org/tracker/CVE-2018-7589
https://security-tracker.debian.org/tracker/CVE-2018-7588

And then there's 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7587   
where the upstream isn't clear, it would be great if you
could clarify with upstream on the status.

Cheers,
Moritz



Bug#892779: libu2f-udev: Please support non-systemd

2018-03-12 Thread Robbie Harwood
Package: libu2f-udev
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

The provided udev rules don't work if the system isn't running systemd.
Instead, we have to do something like:

ATTRS{idVendor}=="1050", GROUP="plugdev", MODE="0660"
ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", GROUP="plugdev", 
MODE="0660"

I'm not sure this is the best solution, but feature parity should be possible
here.

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

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

-- no debconf information



Bug#892778: phppgadmin: php need to recompile PHP using the --with-pgsql configure option

2018-03-12 Thread Christoph Berg
Control: tags -1 moreinfo

Re: Norbert Schulz 2018-03-12 
<152088427690.5326.6930878930288703978.report...@gondor.heim>
> after istallation and configuration of phppgadmin the call of 
> http:///phppgadmin gives the following
> information/(error) 'Your PHP installation does not support PostgreSQL. You 
> need to recompile PHP using the --with-pgsql configure 
> option.'

Hi,

this isn't phppgadmin's fault. Most likely, the php-pgsql module
hasn't been enabled in your PHP installation.

Christoph



Bug#892778: phppgadmin: php need to recompile PHP using the --with-pgsql configure option

2018-03-12 Thread Norbert Schulz
Package: phppgadmin
Version: 5.1+ds-2
Severity: normal

Dear Maintainer,

after istallation and configuration of phppgadmin the call of 
http:///phppgadmin gives the following
information/(error) 'Your PHP installation does not support PostgreSQL. You 
need to recompile PHP using the --with-pgsql configure 
option.'


Best regards
Norbert


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.9.0-6-marvell
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 phppgadmin depends on:
ii  dpkg1.18.24
ii  libapache2-mod-php  1:7.0+49
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.27-0+deb9u1
ii  libjs-jquery3.1.1-2
ii  libphp-adodb5.20.9-1
ii  php 1:7.0+49
ii  php-pgsql   1:7.0+49
ii  php7.0 [php]7.0.27-0+deb9u1
ii  php7.0-pgsql [php-pgsql]7.0.27-0+deb9u1

Versions of packages phppgadmin recommends:
ii  apache2 [httpd]  2.4.25-3+deb9u3

Versions of packages phppgadmin suggests:
ii  postgresql  9.6+181+deb9u1
pn  postgresql-doc  
pn  slony1-bin  

-- Configuration Files:
/etc/apache2/conf-available/phppgadmin.conf changed:
Alias /phppgadmin /usr/share/phppgadmin


DirectoryIndex index.php

AllowOverride None
Require all granted

  php_flag magic_quotes_gpc Off
  php_flag track_vars On
  #php_value include_path .


  

  AddType application/x-httpd-php .php
  Action application/x-httpd-php /cgi-bin/php


  AddType application/x-httpd-php .php
  Action application/x-httpd-php /cgi-bin/php

  



/etc/phppgadmin/config.inc.php changed:
http://www.postgresql.org/docs/%s/interactive/';

// Configuration for ajax scripts
// Time in seconds. If set to 0, refreshing data using ajax will be 
disabled (locks and activity pages)
$conf['ajax_refresh'] = 3;
/** Plugins management
 * Add plugin names to the following array to activate them
 * Example:
 *   $conf['plugins'] = array(
 * 'Example',
 * 'Slony'
 *   );
 */
$conf['plugins'] = array();
/*
 * Don't modify anything below this line *
 */
$conf['version'] = 19;
?>


-- no debconf information



Bug#891511: ip route flush all does not work any more

2018-03-12 Thread Luca Boccassi
On Mon, 2018-03-05 at 08:51 -0800, Stephen Hemminger wrote:
> On Sun, 04 Mar 2018 22:07:37 +
> Luca Boccassi  wrote:
> 
> > On Mon, 26 Feb 2018 12:05:05 +0100 Wolfgang Walter  > @stw
> > m.de> wrote:
> > > Package: iproute2
> > > Version: 4.15.0-2
> > >  
> > > Hello,
> > >  
> > > after upgrading iproute2 from 4.14.1-2 to 4.15.0-2
> > >  
> > >   ip route flush all
> > >  
> > > seems not to work any more. It does not remove all ipv4 routes
> > > from  
> > 
> > the main 
> > > table as it did before. Downgrading to 4.14.1-2 fixes the
> > > problem.
> > >  
> > > Basically 4.15.0-2 removes the default route, but other routes
> > > are  
> > 
> > not 
> > > removed.
> > >  
> > > What still works is
> > >  
> > >   ip route flush table main 
> > >  
> > >  
> > > Another thing which changed is that
> > >  
> > >   ip route ls all
> > >  
> > > now does not show anything but the default route whereas it used
> > > to  
> > 
> > show all 
> > > routes of the main table.  
> > 
> > Hi,
> > 
> > Yes can confirm, it's easily reproduced.
> > 
> > Stephen, do you know if is this a known change in behaviour?
> > 
> > With 4.14.0:
> > 
> > $ ip route ls all
> > default via 192.168.1.1 dev wlp2s0 proto static metric 600 
> > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > metric 600 
> > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > 192.168.122.1 linkdown
> > 
> > With 4.15.0:
> > 
> > $ ip route ls all
> > default via 192.168.1.1 dev wlp2s0 proto static metric 600
> > 
> > Further tests with 4.15.0:
> > 
> > $ ip route ls table main
> > default via 192.168.1.1 dev wlp2s0 proto static metric 600 
> > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > metric 600 
> > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > 192.168.122.1 linkdown 
> > $ sudo ip route flush all
> > $ ip route ls all
> > $ ip route ls table main
> > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > metric 600 
> > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > 192.168.122.1 linkdown 
> > 
> > $ sudo ip route add default via 192.168.1.1
> > $ ip route ls table main
> > default via 192.168.1.1 dev wlp2s0 
> > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
> > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5
> > metric 600 
> > 192.168.122.0/24 dev virbr0 proto kernel scope link src
> > 192.168.122.1 linkdown 
> > $ ip route ls all
> > default via 192.168.1.1 dev wlp2s0 
> > $ sudo ip route flush table main
> > $ ip route ls all
> > $ ip route ls table main
> 
> Is it a kernel or iproute issue? Should be bisectable.

Hi Stephen,

It was caused by this commit:

commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2
Author: Alexander Zubkov 
Date:   Sun Dec 17 12:09:00 2017 +0100

iproute: "list/flush/save default" selected all of the routes

When running "ip route list default" and not specifying address family,
one will get all of the routes instead of just default only. The same
is for "exact default" and "match default".

It behaves in such a way because default route with unspecified family
has the same all-zeroes value like no prefix specified at all. Thus
following code blindly ignores the fact, that prefix was actually
specified.

This patch adds the flag PREFIXLEN_SPECIFIED to the default route too.
And then checks its value when filtering routes.



Looking at the message, it looks like it might have been intentional?
But it looks like a backward-incompatible change to me

-- 
Kind regards,
Luca Boccassi

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


Bug#885823: evolution-rss: raising severity of gconf dependency bug

2018-03-12 Thread Jeremy Bicha
Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part
of this process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please
consider requesting that your package be removed from Debian to help us
complete this goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#883027: flare-engine: new upstream release 0.20

2018-03-12 Thread felipe
Hi.

It seems Flare 1.0 was just released with the new Empyrean Campaign.

Let me know if you need help packaging the new version.

On Wed, 29 Nov 2017 00:38:27 +0100 "Manuel A. Fernandez Montecelo" 
 wrote:
> Hi,
> 
> 2017-11-29 0:23 GMT+01:00 Antoine Musso :
> > Package: flare-engine
> > Version: 0.19-3
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > Upstream has released a new version 0.20 in August 2015.
> >
> > https://github.com/clintbellanger/flare-engine/releases
> 
> Thanks for the suggestion.  At the time they recommended to not update
> to 0.20, to wait for 1.0, but I cannot find the reference now.
> 
> They even have "Download 0.19" in the website, and conflicting views
> on "what will happen next":
> 
>   http://flarerpg.org/blog/20140116
> 
> So I've been eagerly awaiting for something more recent than 0.20 for
> a while, and thought about asking them.
> 
> It would be great if you could ask them for the current plan, since
> 0.20 is too old by now, if we refresh probably we want something more
> recent.  If not, I will try to remember in the next weeks -- quite
> busy now.
> 
> 
> Cheers.
> -- 
> Manuel A. Fernandez Montecelo 
> 
> 



Bug#892777: RFP: libjs-strophe.vcard -- strophe.js plugin which implements XEP-0054 VCard-temp

2018-03-12 Thread W. Martin Borgert

Package: wnpp
Severity: wishlist

* Package name: libjs-strophejs.vcard
  Version : 0.0.1
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-vcard
* License : MIT
  Programming Lang: JavaScript
  Description : strophe.js plugin which implements XEP-0054 VCard-temp

Dependency for converse.js (#807275).



Bug#892776: RFP: libjs-strophe.register -- Strophe.js plugin for in-band registration (XEP-0077)

2018-03-12 Thread W. Martin Borgert

Package: wnpp
Severity: wishlist

* Package name: libjs-strophejs.register
  Version : 0.0.1
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-register
* License : MIT
  Programming Lang: JavaScript
  Description : Strophe.js plugin for in-band registration (XEP-0077)

Dependency for converse.js (#807275).



Bug#892775: RFP: libjs-strophe.ping -- strophe.js plugin to provide XMPP Ping (XEP-0199)

2018-03-12 Thread W. Martin Borgert

Package: wnpp
Severity: wishlist

* Package name: libjs-strophejs.ping
  Version : 0.0.2
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-ping
* License : MIT
  Programming Lang: JavaScript
  Description : strophe.js plugin to provide XMPP Ping (XEP-0199)

Dependency for converse.js (#807275).



Bug#892774: stretch-pu: package canna/3.7p3-14~deb9u1

2018-03-12 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

   * Make cannakill a symlink to catdic, fixing the file conflict
 between canna-dbgsym and canna-utils-dbgsym. (Closes: #868541)
diff -Nru canna-3.7p3/debian/canna.install canna-3.7p3/debian/canna.install
--- canna-3.7p3/debian/canna.install2012-01-25 07:57:21.0 +0200
+++ canna-3.7p3/debian/canna.install2017-07-16 16:59:14.0 +0300
@@ -33,7 +33,6 @@
 var/lib/canna/dic/canna/software.ctd
 var/lib/canna/dic/canna/suffix.ctd
 usr/bin/canlisp
-usr/bin/cannakill
 usr/bin/crfreq
 usr/bin/crxdic
 usr/bin/crxgram
diff -Nru canna-3.7p3/debian/changelog canna-3.7p3/debian/changelog
--- canna-3.7p3/debian/changelog2015-10-05 12:19:37.0 +0300
+++ canna-3.7p3/debian/changelog2018-03-12 21:07:48.0 +0200
@@ -1,3 +1,19 @@
+canna (3.7p3-14~deb9u1) unstable; urgency=medium
+
+  * QA upload.
+  * Rebuild for stretch.
+
+ -- Adrian Bunk   Mon, 12 Mar 2018 21:07:48 +0200
+
+canna (3.7p3-14) unstable; urgency=medium
+
+  * QA upload.
+  * Make cannakill a symlink to catdic, fixing the file conflict
+between canna-dbgsym and canna-utils-dbgsym. (Closes: #868541)
+  * Add the missing lsb-base dependency to canna.
+
+ -- Adrian Bunk   Sun, 16 Jul 2017 16:59:14 +0300
+
 canna (3.7p3-13.1) unstable; urgency=medium
 
   * Non-maintainer upload to fix FTBFS.
diff -Nru canna-3.7p3/debian/control canna-3.7p3/debian/control
--- canna-3.7p3/debian/control  2015-10-05 12:11:44.0 +0300
+++ canna-3.7p3/debian/control  2017-07-16 16:59:14.0 +0300
@@ -12,7 +12,7 @@
 
 Package: canna
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, adduser (>= 3.34), canna-utils
+Depends: lsb-base, ${misc:Depends}, ${shlibs:Depends}, adduser (>= 3.34), 
canna-utils
 Suggests: canna-shion
 Description: input system for Japanese - server and dictionary
  Canna provides a unified user interface for Japanese input. It is based
diff -Nru canna-3.7p3/debian/links canna-3.7p3/debian/links
--- canna-3.7p3/debian/links2012-11-25 15:01:57.0 +0200
+++ canna-3.7p3/debian/links2017-07-16 16:59:14.0 +0300
@@ -1 +1,2 @@
-usr/bin/cannakill usr/bin/syncdic
+usr/bin/catdic usr/bin/syncdic
+usr/bin/catdic usr/bin/cannakill
diff -Nru canna-3.7p3/debian/rules canna-3.7p3/debian/rules
--- canna-3.7p3/debian/rules2013-06-08 22:15:37.0 +0300
+++ canna-3.7p3/debian/rules2017-07-16 16:59:14.0 +0300
@@ -59,8 +59,6 @@
(cd $(CURDIR)/debian/tmp/usr/bin/ && \
rm -f cpdic lsdic mkdic mvdic rmdic syncdic \
addwords delwords cannakill)
-   cp $(CURDIR)/debian/tmp/usr/bin/catdic \
-   $(CURDIR)/debian/tmp/usr/bin/cannakill
install -d -m 755 $(CURDIR)/debian/tmp/etc/canna/dics.dir.d
install -m 644 $(CURDIR)/debian/tmp/var/lib/canna/dic/canna/dics.dir \
$(CURDIR)/debian/tmp/etc/canna/dics.dir.d/00canna.dics.dir


Bug#892773: RFP: libjs-strophe.disco -- strophe.js plugin for XEP-0030 Service Discovery

2018-03-12 Thread W. Martin Borgert

Package: wnpp
Severity: wishlist

* Package name: libjs-strophejs.disco
  Version : 0.0.2
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-disco
* License : MIT
  Programming Lang: JavaScript
  Description : strophe.js plugin for XEP-0030 Service Discovery

Dependency for converse.js (#807275).



Bug#892772: live-boot: do_netsetup fails to detect ip address with ifconfig

2018-03-12 Thread Luca Boccassi
Package: live-boot
Version: 1:20170213
Severity: normal
Tags: patch

Dear Maintainer,

The do_netsetup function in components/9990-networking.sh parses
ifconfig to check if an IP address has been assigned. But the pattern
matching does not work anymore on Stretch, so it always fails.

I have opened a Merge Request on Salsa [1] with a fix from Sameer, a
colleague of mine at $work.

Thank you!

-- 
Kind regards,
Luca Boccassi

[1] https://salsa.debian.org/live-team/live-boot/merge_requests/3

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


Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'

2018-03-12 Thread Mykola Nikishov
Package: puppet
Version: 5.4.0-1
Followup-For: Bug #892737

I have librarian-puppet and found out that downgrading it to jessie
will fix the problem. Downgrade will remove ruby-puppet-forge and
ruby-gettext-setup.

Seems ruby-gettext-setup causes this problem.

--8<---cut here---start->8---
librarian-puppet:
  Installed: 2.2.3-1
  Candidate: 2.2.3-1
  Version table:
 2.2.3-2 70
 60 tor+http://deb.debian.org/debian testing/main amd64 Packages
 70 tor+http://deb.debian.org/debian unstable/main amd64 Packages
 *** 2.2.3-1 500
500 tor+http://deb.debian.org/debian stable/main amd64 Packages
100 /var/lib/dpkg/status
 1.0.3-1 40
 40 tor+http://deb.debian.org/debian jessie/main amd64 Packages
 40 tor+http://deb.debian.org/debian oldstable/main amd64 Packages
--8<---cut here---end--->8---

-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (70, 'unstable'), (60, 
'testing'), (50, 'experimental'), (40, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages puppet depends on:
ii  adduser  3.117
ii  facter   3.10.0-3
ii  hiera3.2.0-2
ii  init-system-helpers  1.51
ii  lsb-base 9.20170808
ii  ruby 1:2.3.3
ii  ruby-augeas  1:0.5.0-3+b5
ii  ruby-deep-merge  1.1.1-1
ii  ruby-shadow  2.5.0-1

Versions of packages puppet recommends:
pn  debconf-utils  
ii  lsb-release9.20170808
ii  ruby-selinux   2.7-2+b1

Versions of packages puppet suggests:
pn  ruby-hocon  
pn  ruby-rrd

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

-- no debconf information



Bug#892771: RM: libgksu -- RoM; RoQA; unmaintained, security-sensitive

2018-03-12 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libg...@packages.debian.org

Please remove libgksu.

See explanation at the related RM bug for gksu:
https://bugs.debian.org/892768

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#892770: RM: dolibarr/3.5.5+dfsg1-1+deb8u1

2018-03-12 Thread Moritz Muehlenhoff
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Same as #892024 for stretch, please also remove from jessie.

Cheers,
Moritz



Bug#890254: stretch update for gf2x

2018-03-12 Thread Adrian Bunk
On Mon, Feb 12, 2018 at 05:51:03PM +, Debian Bug Tracking System wrote:
>...
>  gf2x (1.2-4) unstable; urgency=medium
>  .
>* Team upload.
>* Actually disable HW-specific code also on i386. (Closes: #890254)
>...

Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.

Thanks
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#892769: apcupsd: Exclusionary language in configuration files

2018-03-12 Thread Autumn Mahoney
Package: apcupsd
Version: 3.14.14-0.3
Severity: minor
Tags: upstream

Can we get rid of the "We send an email message to root to notify him" language 
in the following configuration files?

/etc/apcupsd/changeme
/etc/apcupsd/commfailure
/etc/apcupsd/commok
/etc/apcupsd/offbattery
/etc/apcupsd/onbattery

I know the language is inherited from upstream, but it's jarring to see, every 
time I set up a new server, that the root user is assumed to be a "him".

Furthermore, referencing "root" is less relevant now since Debian has replaced 
direct references to "root" in those files with a variable lookup for $SYSADMIN 
that is defined in /etc/apcupsd/apccontrol. Perhaps something more accurate 
(and automatically more gender neutral!) that encourages people to modify the 
$SYSADMIN variable in apccontrol rather than directly editing the referencing 
files, like:

"An email notification is sent to the $SYSADMIN email address defined in 
/etc/apcupsd/apccontrol."


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

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

Versions of packages apcupsd depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libusb-0.1-4 2:0.1.12-30
ii  libwrap0 7.6.q-26

Versions of packages apcupsd recommends:
ii  apcupsd-doc3.14.14-0.3
ii  mailutils [mailx]  1:3.1.1-1

Versions of packages apcupsd suggests:
pn  apcupsd-cgi  
ii  udev 232-25+deb9u1

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

-- no debconf information



Bug#892768: RM: gksu -- RoM; RoQA; unmaintained

2018-03-12 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: network-con...@packages.debian.org

gksu has been deprecated for years. The intent of gksu is to allow
running apps with elevated privileges but the recommended way to do
that is for the app developer to use PolicyKit to request elevated
privileges for the specific actions that need done instead of for the
whole app to run as root.

For the next major stable release of Debian (codenamed Buster), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not even work.

gksu is unmaintained (last upload 2014) and is considered a security
vulnerability.

Therefore, please remove it.

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#892766: CVE-2017-15422

2018-03-12 Thread Moritz Muehlenhoff
Source: icu
Severity: grave
Tags: security

Hi Laszlo,
https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html
refers to a ICU vulnerability, but there's little information what fixes/fixed 
that.

Could you reach out to upstream whether they've been in touch with them so that
we can pinpoint this a specific task/commit?

Cheers,
Moritz



Bug#892767: RM: network-config -- RoQA; unmaintained; depends on gksu

2018-03-12 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: network-con...@packages.debian.org

Please remove network-config from Debian.

It is the last thing keeping gksu in Debian unstable. The Debian GNOME
team wants gksu removed since it is unmaintained and there are better
ways (PolicyKit) to do security-sensitive actions.

network-config's last upstream release was 10 years ago.

network-config was orphaned in 2015 and then adopted by a Debian
contributor. Since that initial upload, there have been no more
uploads of the package.

network-config was removed from Testing 6 months ago because of the
gksu issue (bug originally filed almost 2 years ago). I emailed the
Debian maintainer December 31 warning him about my intent to remove
this package from Debian. I sent a follow-up two weeks later and again
today. I received no response.

https://bugs.debian.org/780195 Orphaned
https://bugs.debian.org/822603 RC bug

Thanks,
Jeremy Bicha



Bug#874220: stretch update for openni2

2018-03-12 Thread Adrian Bunk
On Mon, Sep 11, 2017 at 09:18:05PM +, Debian Bug Tracking System wrote:
>...
>  openni2 (2.2.0.33+dfsg-10) unstable; urgency=medium
>  .
>* Add patch for arm.
>  Thanks to Adrian Bunk (Closes: #874220)
>...

Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.

Thanks
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#822603: Remove network-config from Debian?

2018-03-12 Thread Jeremy Bicha
I am filing a removal bug now. Please reply immediately if you object.

Thanks,
Jeremy Bicha

On Tue, Jan 16, 2018 at 10:16 PM, Jeremy Bicha  wrote:
> On Sun, Dec 31, 2017 at 7:21 PM, Jeremy Bicha  wrote:
>> Hi,
>>
>> network-config was removed from Debian Testing because it depends on
>> gksu [1]. The Debian GNOME team would like to remove gksu from Debian
>> Unstable too but we need to fix or remove the reverse depends first.
>>
>> Can I file a Debian removal bug for network-config now?
>>
>> [1] https://bugs.debian.org/822603
>>
>> Thanks,
>> Jeremy Bicha
>
> network-config is now the last thing in Debian depending on gksu. The
> Debian GNOME team wants to remove gksu since it is deprecated and no
> longer maintained. Because network-config has already been removed
> from Debian Testing since July for this issue and there has been no
> response from the Debian maintainer for this package, I intend to
> request that network-config be removed from Debian soon. It can be
> reintroduced to Debian if this bug is fixed.
>
> Thanks
> Jeremy Bicha



Bug#848315: ITP: node-cheerio -- Server-side jQuery implementation

2018-03-12 Thread W. Martin Borgert

Hi,

node-domutils is in stable now.
Do you still need a sponsor?

Cheers



Bug#892765: aegisub: use lua or luajit

2018-03-12 Thread Frédéric Bonnard
Package: src:aegisub
Version: 3.2.2+dfsg-3

--

Dear maintainer,

at the moment both liblua5.1-0-dev and libluajit-5.1-dev are required to
build. I think one or the other exclusively should be enough.
The best being to require first libluajit-5.1-dev if available and
fallback on liblua5.1-0-dev.
This way, aegisub will benefit from luajit's speed if possible but will
build on more architectures as well thanks to lua's portability.
Here is a patch for this.
Also, right now, liblua5.1-0-dev is never used as pkg-config will only
point to luajit which should be fixed I guess even if you're not
interested in the patch.
Last but not least, ppc64el's support in luajit is unsure in the
long term, so with the patch, we ensure to be able to still have aegisub
on this architecture even if luajit drops ppc64el support.
Thanks,

Regards.
F.


pgpogZFmf6X5o.pgp
Description: PGP signature
diff -Nru aegisub-3.2.2+dfsg/debian/control aegisub-3.2.2+dfsg/debian/control
--- aegisub-3.2.2+dfsg/debian/control   2015-09-18 22:31:15.0 +
+++ aegisub-3.2.2+dfsg/debian/control   2015-09-18 22:30:12.0 +
@@ -22,8 +22,7 @@
libglu1-mesa-dev | libglu-dev,
libhunspell-dev,
libicu-dev,
-   liblua5.1-0-dev,
-   libluajit-5.1-dev,
+   libluajit-5.1-dev | liblua5.1-0-dev,
libpulse-dev,
libwxgtk3.0-dev,
lua5.1
diff -Nru 
aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch 
aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch
--- aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch 
2015-09-18 22:31:15.0 +
+++ aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch 
2015-09-18 22:30:12.0 +
@@ -20,7 +20,7 @@
  CFLAGS_LIBASS  = @LIBASS_CFLAGS@
  CFLAGS_LIBPULSE= @LIBPULSE_CFLAGS@
 -CFLAGS_LUA = -I$(TOP)vendor/luajit/include
-+CFLAGS_LUA = `pkg-config --cflags luajit`
++CFLAGS_LUA = `pkg-config --cflags luajit` `pkg-config --cflags lua51`
  CFLAGS_OPENAL  = @OPENAL_CFLAGS@
  CFLAGS_OSS = @OSS_CFLAGS@
  CFLAGS_PORTAUDIO   = @PORTAUDIO_CFLAGS@
@@ -29,7 +29,7 @@
  LIBS_LIBASS= @LIBASS_LIBS@
  LIBS_LIBPULSE  = @LIBPULSE_LIBS@
 -LIBS_LUA   = $(TOP)vendor/luajit/src/libluajit.a
-+LIBS_LUA   = `pkg-config --libs luajit`
++LIBS_LUA   = `pkg-config --libs luajit` `pkg-config --libs lua51`
  LIBS_OPENAL= @OPENAL_LIBS@
  LIBS_PORTAUDIO = @PORTAUDIO_LIBS@
  LIBS_PTHREAD   = @PTHREAD_LIBS@
@@ -43,10 +43,10 @@
 -$(d)auto4_lua_assfile.o_FLAGS   := -I$(TOP)vendor/luajit/include
 -$(d)auto4_lua_dialog.o_FLAGS:= -I$(TOP)vendor/luajit/include
 -$(d)auto4_lua_progresssink.o_FLAGS  := -I$(TOP)vendor/luajit/include
-+$(d)auto4_lua.o_FLAGS   := `pkg-config --cflags luajit`
-+$(d)auto4_lua_assfile.o_FLAGS   := `pkg-config --cflags luajit`
-+$(d)auto4_lua_dialog.o_FLAGS:= `pkg-config --cflags luajit`
-+$(d)auto4_lua_progresssink.o_FLAGS  := `pkg-config --cflags luajit`
++$(d)auto4_lua.o_FLAGS   := `pkg-config --cflags luajit` 
`pkg-config --cflags lua51`
++$(d)auto4_lua_assfile.o_FLAGS   := `pkg-config --cflags luajit` 
`pkg-config --cflags lua51`
++$(d)auto4_lua_dialog.o_FLAGS:= `pkg-config --cflags luajit` 
`pkg-config --cflags lua51`
++$(d)auto4_lua_progresssink.o_FLAGS  := `pkg-config --cflags luajit` 
`pkg-config --cflags lua51`
  
  $(src_OBJ): $(d)libresrc/bitmap.h $(d)libresrc/default_config.h
  


pgp_fm3ypk_Ex.pgp
Description: PGP signature


Bug#892764: stretch-pu: package i3-wm/4.13-1

2018-03-12 Thread Michael Stapelberg
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I would like to apply the attached update to the i3-wm package to satisfy a user
request (#891919) for a backported upstream fix to address a crash when using
window marks and restarting i3 in-place.

Please let me know how to proceed. Thanks!

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/12 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)
diff -Nru i3-wm-4.13/debian/changelog i3-wm-4.13/debian/changelog
--- i3-wm-4.13/debian/changelog 2016-11-08 19:02:16.0 +0100
+++ i3-wm-4.13/debian/changelog 2018-03-12 19:16:41.0 +0100
@@ -1,3 +1,9 @@
+i3-wm (4.13-2) stable; urgency=medium
+
+  * cherry-pick patch to “fix crash upon restart when using marks” (Closes: 
#891919)
+
+ -- Michael Stapelberg   Mon, 12 Mar 2018 19:16:41 +0100
+
 i3-wm (4.13-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch 
i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch
--- i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch  1970-01-01 
01:00:00.0 +0100
+++ i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch  2018-03-12 
19:16:07.0 +0100
@@ -0,0 +1,112 @@
+Description: fix crash upon restart when using marks
+Forwarded: not-needed
+Origin: vendor, 
https://github.com/i3/i3/pull/2779/commits/a5d959cde44e88bffa23a93bdd174b07f280f0e9
+Author: hwangcc23 
+Bug-Debian: 891919
+
+---
+
+From a5d959cde44e88bffa23a93bdd174b07f280f0e9 Mon Sep 17 00:00:00 2001
+From: 
+Date: Sun, 21 May 2017 14:34:29 +0800
+Subject: [PATCH] Fix the i3 crash caused by mark + restart commands
+
+This patch fixes the issue #2511(https://github.com/i3/i3/issues/2511).
+
+1). Memorize the marks, but only call con_mark once the container has finished 
parsing. (Credit: This is @Airblader's patch.)
+
+2). Add a test case 267-regress-mark-restart.t for regression test to check if 
mark and restart command crash i3.
+---
+ src/load_layout.c  | 19 +--
+ testcases/t/267-regress-mark-restart.t | 30 ++
+ 2 files changed, 47 insertions(+), 2 deletions(-)
+ create mode 100644 testcases/t/267-regress-mark-restart.t
+
+diff --git a/src/load_layout.c b/src/load_layout.c
+index f6f045d26..632c6ec76 100644
+--- a/src/load_layout.c
 b/src/load_layout.c
+@@ -29,6 +29,8 @@ static bool parsing_focus;
+ static bool parsing_marks;
+ struct Match *current_swallow;
+ static bool swallow_is_empty;
++static int num_marks;
++static char **marks;
+ 
+ /* This list is used for reordering the focus stack after parsing the 'focus'
+  * array. */
+@@ -148,6 +150,16 @@ static int json_end_map(void *ctx) {
+ floating_check_size(json_node);
+ }
+ 
++if (num_marks > 0) {
++for (int i = 0; i < num_marks; i++) {
++con_mark(json_node, marks[i], MM_ADD);
++free(marks[i]);
++}
++
++free(marks);
++num_marks = 0;
++}
++
+ LOG("attaching\n");
+ con_attach(json_node, json_node->parent, true);
+ LOG("Creating window\n");
+@@ -230,8 +242,10 @@ static int json_key(void *ctx, const unsigned char *val, 
size_t len) {
+ if (strcasecmp(last_key, "focus") == 0)
+ parsing_focus = true;
+ 
+-if (strcasecmp(last_key, "marks") == 0)
++if (strcasecmp(last_key, "marks") == 0) {
++num_marks = 0;
+ parsing_marks = true;
++}
+ 
+ return 1;
+ }
+@@ -261,7 +275,8 @@ static int json_string(void *ctx, const unsigned char 
*val, size_t len) {
+ char *mark;
+ sasprintf(, "%.*s", (int)len, val);
+ 
+-con_mark(json_node, mark, MM_ADD);
++marks = srealloc(marks, (++num_marks) * sizeof(char *));
++marks[num_marks - 1] = sstrdup(mark);
+ } else {
+ if (strcasecmp(last_key, "name") == 0) {
+ json_node->name = scalloc(len + 1, 1);
+diff --git a/testcases/t/267-regress-mark-restart.t 
b/testcases/t/267-regress-mark-restart.t
+new file mode 100644
+index 0..220d765b7
+--- /dev/null
 b/testcases/t/267-regress-mark-restart.t
+@@ -0,0 +1,30 @@
++#!perl
++# vim:ts=4:sw=4:expandtab
++#
++# Please read the following documents before working on tests:
++# • http://build.i3wm.org/docs/testsuite.html
++#   (or docs/testsuite)
++#
++# • http://build.i3wm.org/docs/lib-i3test.html
++#   (alternatively: perldoc ./testcases/lib/i3test.pm)
++#
++# • 

Bug#892762: zlib: rename stage1 profile to nobiarch

2018-03-12 Thread Helmut Grohne
Source: zlib
Version: 1:1.2.8.dfsg-5
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

zlib uses the profile "stage1" for disabling multilib packages and thus
easing architecture bootstrap.

We noticed that "stage1" is a bad profile name, because it says nothing.
It says "this is connected to bootstrapping somehow", but nothing more.
Thus we started getting rid of "stage*" profiles and want to use
descriptive profile names. What happens here is that multilib packages
are disabled and that has a name (originally coined in the gcc
packaging) "nobiarch". The "nobiarch" profile is already used by glibc
and ncurses. It also is documented[1]. (The only other packages building
multilibby stuff are blcr and readline.) Thus it would add consistency
if zlib was using the same profile.

Please consider applying the attached patch.

Helmut

[1] https://wiki.debian.org/BuildProfileSpec
diff --minimal -Nru zlib-1.2.8.dfsg/debian/changelog 
zlib-1.2.8.dfsg/debian/changelog
--- zlib-1.2.8.dfsg/debian/changelog2017-01-29 18:22:23.0 +0100
+++ zlib-1.2.8.dfsg/debian/changelog2018-03-12 18:37:53.0 +0100
@@ -1,3 +1,10 @@
+zlib (1:1.2.8.dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename profile stage1 to nobiarch. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 12 Mar 2018 18:37:53 +0100
+
 zlib (1:1.2.8.dfsg-5) unstable; urgency=low
 
   * Add loud warnings to the descriptions of all the multilib packages
diff --minimal -Nru zlib-1.2.8.dfsg/debian/control 
zlib-1.2.8.dfsg/debian/control
--- zlib-1.2.8.dfsg/debian/control  2017-01-29 18:22:23.0 +0100
+++ zlib-1.2.8.dfsg/debian/control  2018-03-12 18:37:51.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Mark Brown 
 Standards-Version: 3.9.8
 Homepage: http://zlib.net/
-Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) [mips 
mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 
sparc s390x] , dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) [mips 
mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 
sparc s390x] , dpkg-dev (>= 1.16.1)
 
 Package: zlib1g
 Architecture: any
@@ -54,7 +54,7 @@
 
 Package: lib64z1
 Architecture: sparc s390 i386 powerpc mips mipsel
-Build-Profiles: 
+Build-Profiles: 
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: amd64-libs (<< 1.4)
 Description: compression library - 64 bit runtime
@@ -65,7 +65,7 @@
 Package: lib64z1-dev
 Section: libdevel
 Architecture: sparc s390 i386 powerpc mips mipsel
-Build-Profiles: 
+Build-Profiles: 
 Depends: lib64z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), 
lib64c-dev, ${misc:Depends}
 Replaces: amd64-libs-dev (<< 1.4)
 Provides: lib64z-dev
@@ -80,7 +80,7 @@
 
 Package: lib32z1
 Architecture: amd64 ppc64 kfreebsd-amd64 s390x
-Build-Profiles: 
+Build-Profiles: 
 Conflicts: libc6-i386 (<= 2.9-18)
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: ia32-libs (<< 1.5)
@@ -92,7 +92,7 @@
 Package: lib32z1-dev
 Section: libdevel
 Architecture: amd64 ppc64 kfreebsd-amd64 s390x
-Build-Profiles: 
+Build-Profiles: 
 Conflicts: libc6-i386 (<= 2.9-18)
 Depends: lib32z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), 
lib32c-dev, ${misc:Depends}
 Provides: lib32z-dev
@@ -108,7 +108,7 @@
 
 Package: libn32z1
 Architecture: mips mipsel
-Build-Profiles: 
+Build-Profiles: 
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: compression library - n32 runtime
  zlib is a library implementing the deflate compression method found
@@ -118,7 +118,7 @@
 Package: libn32z1-dev
 Section: libdevel
 Architecture: mips mipsel
-Build-Profiles: 
+Build-Profiles: 
 Depends: libn32z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), 
libn32c-dev, ${misc:Depends}
 Provides: libn32z-dev
 Description: compression library - n32 - DO NOT USE EXCEPT FOR PACKAGING
diff --minimal -Nru zlib-1.2.8.dfsg/debian/rules zlib-1.2.8.dfsg/debian/rules
--- zlib-1.2.8.dfsg/debian/rules2017-01-29 18:22:17.0 +0100
+++ zlib-1.2.8.dfsg/debian/rules2018-03-12 18:37:49.0 +0100
@@ -34,7 +34,7 @@
CFLAGS += -O3
 endif
 
-ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
+ifeq (,$(filter nobiarch,$(DEB_BUILD_PROFILES)))
 
 32-ARCHS=amd64 ppc64 kfreebsd-amd64 s390x
 64-ARCHS=s390 sparc i386 powerpc mips mipsel
@@ -71,7 +71,7 @@
 mn32=-mabi=n32
 endif
 
-endif # !stage1
+endif # !nobiarch
 
 UNALIGNED_ARCHS=i386 amd64 kfreebsd-i386 kfreebsd-amd64 hurd-i386 lpia
 ifneq (,$(findstring $(DEB_HOST_ARCH), $(UNALIGNED_ARCHS)))
@@ -198,7 +198,7 @@
dh_compress -s
dh_fixperms -s
dh_makeshlibs -pzlib1g -V"zlib1g (>= 1:1.2.3.3.dfsg-1)" 
--add-udeb=zlib1g-udeb
-ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
+ifeq (,$(filter nobiarch,$(DEB_BUILD_PROFILES)))
 ifneq (,$(findstring $(DEB_HOST_ARCH), $(32-ARCHS)))
dh_makeshlibs -plib32z1 

Bug#892763: libpandoc-wrapper-perl should not use the stage1 profile

2018-03-12 Thread Helmut Grohne
Source: libpandoc-wrapper-perl
Version: 0.6.1-1
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libpandoc-wrapper-perl should not use the profile name "stage1". The
reasoning can be found in a similar bug report against
libpandoc-elements-perl (bug number pending). Please consider applying
the attached patch.

Helmut
diff --minimal -Nru libpandoc-wrapper-perl-0.6.1/debian/changelog 
libpandoc-wrapper-perl-0.6.1/debian/changelog
--- libpandoc-wrapper-perl-0.6.1/debian/changelog   2017-10-28 
03:32:14.0 +0200
+++ libpandoc-wrapper-perl-0.6.1/debian/changelog   2018-03-12 
19:00:25.0 +0100
@@ -1,3 +1,10 @@
+libpandoc-wrapper-perl (0.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch stage1 profile to nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 12 Mar 2018 19:00:25 +0100
+
 libpandoc-wrapper-perl (0.6.1-1) unstable; urgency=medium
 
   [ upstream ]
diff --minimal -Nru libpandoc-wrapper-perl-0.6.1/debian/control 
libpandoc-wrapper-perl-0.6.1/debian/control
--- libpandoc-wrapper-perl-0.6.1/debian/control 2017-10-28 03:30:07.0 
+0200
+++ libpandoc-wrapper-perl-0.6.1/debian/control 2018-03-12 19:00:10.0 
+0100
@@ -7,10 +7,10 @@
  libmodule-build-tiny-perl,
  perl,
 # tests
- libcapture-tiny-perl ,
- libpath-tiny-perl ,
- libpandoc-elements-perl ,
- libtest-exception-perl ,
+ libcapture-tiny-perl ,
+ libpath-tiny-perl ,
+ libpandoc-elements-perl ,
+ libtest-exception-perl ,
 # runtime
  libfile-which-perl,
  libipc-run3-perl,


Bug#892761: libpandoc-elements-perl should not use the stage1 profile

2018-03-12 Thread Helmut Grohne
Source: libpandoc-elements-perl
Version: 0.33-2
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

I noticed that libpandoc-elements-perl uses the "stage1" profile. We
want to get rid of "stage*" profiles, because they are meaningless
beyond "something with bootstrapping". In this case, it seems that the
relevant dependencies are concerned with running a build-time test
suite. We already have a documented[1] profile for that called
"nocheck". When using it, one must also add "nocheck" to
DEB_BUILD_OPTIONS which seems to be required here as well, but it is
documented for the "nocheck" profile. Using the standard profile removes
the need for checking whether "stage1" can be used safely, because
"nocheck" requires that binary artifacts don't change. Please consider
switching the profile in use.

Helmut

[1] https://wiki.debian.org/BuildProfileSpec
diff --minimal -Nru libpandoc-elements-perl-0.33/debian/changelog 
libpandoc-elements-perl-0.33/debian/changelog
--- libpandoc-elements-perl-0.33/debian/changelog   2017-08-28 
19:52:28.0 +0200
+++ libpandoc-elements-perl-0.33/debian/changelog   2018-03-12 
18:54:19.0 +0100
@@ -1,3 +1,10 @@
+libpandoc-elements-perl (0.33-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use nocheck profile for test dependencies. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 12 Mar 2018 18:54:19 +0100
+
 libpandoc-elements-perl (0.33-2) unstable; urgency=medium
 
   * Modernize Vcs-Browser field: Use git (not cgit) in path.
diff --minimal -Nru libpandoc-elements-perl-0.33/debian/control 
libpandoc-elements-perl-0.33/debian/control
--- libpandoc-elements-perl-0.33/debian/control 2017-08-28 19:49:33.0 
+0200
+++ libpandoc-elements-perl-0.33/debian/control 2018-03-12 18:54:17.0 
+0100
@@ -6,9 +6,9 @@
  libmodule-build-tiny-perl,
  perl,
 # tests
- libtest-exception-perl ,
- libtest-output-perl ,
- libtest-deep-perl ,
+ libtest-exception-perl ,
+ libtest-output-perl ,
+ libtest-deep-perl ,
 # runtime
  libhash-multivalue-perl,
  libipc-run3-perl,


Bug#886328: live-boot: Please use /run/live instead of /lib/live/mount

2018-03-12 Thread Luca Boccassi
On Fri, 23 Feb 2018 19:24:45 +0100 Raphael Hertzog 
wrote:
> Hello,
> 
> On Fri, 05 Jan 2018, intrigeri wrote:
> > Benjamin Drung:
> > > Therefore move /lib/live/mount to /run/live and skip the
intermedia
> > > /live mount points. This reduces code and complexity.
> > 
> > As someone who had to repeatedly bang his head against exactly this
> > part of the live-boot code (last time earlier this week), I can
only
> > agree with the proposed simplification idea. I didn't do a full
code
> > review though.
> 
> I'm not familiar enough with this part either and I am unlikely to
find
> any obvious mistake. But I committed the patch anyway
> 
> It would be nice if we could test the live-boot in git before I
upload
> it.
> 
> Benjamin, did you test your changes with persistence enabled?
> 
> To whoever is following, please test and report back. Thank you.

Hi,

I understand and appreciate the intent to simplify things - and by
itself, I like the idea to move things to /run - but unfortunately
changing mount points locations will break existing scripts.

That is certainly the case for myself at $work - we have a lot of
scripts to deal with installing images, I've tested it, and
they all break due to this change. In my case it's a derivative with
proprietary bits, so I understand if that is treated as less important.
But would it be possible to make this change optional, please? Or
maybe have  a backward-compatible symlinks?

-- 
Kind regards,
Luca Boccassi

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


Bug#880047: stretch update for postgrey

2018-03-12 Thread Adrian Bunk
On Sat, Nov 25, 2017 at 10:36:10AM +, Debian Bug Tracking System wrote:
>...
>  postgrey (1.36-5) unstable; urgency=medium
>  .
>* debian/postgrey.init: create /var/run/postgrey if it
>  does not exist, patch provided by Laurent Bigonville .
>  (Closes: 756813, 880047)
>...

Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.

An open question would be whether #867201 should then also be fixed
in stretch, I've added Julien to the Cc.

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#879198: Guide to installing

2018-03-12 Thread Jeronimo Pellegrini
The following document:

https://gist.github.com/gelim/a840a99d15cb765cb7b65105b72f00c4

is a guide to installing plain ShareLaTeX (without Docker).
Basically, the author shows how to get the source for the
Docker image and make the installation from it on a Ubuntu
system. This would perhaps help a Debian packager.

Note that this installation method is not supported by
the upstream authors of ShareLaTeX (they only support
installation of the Docker image provided by them).

J.



Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

2018-03-12 Thread Luca Boccassi
On Sun, 2018-03-11 at 19:05 +0100, Thomas Schmitt wrote:
> Hi,
> 
> i managed to build a live-build ISO.
> Its /boot/grub/efi.img contains
>   /efi/boot/bootia32.efi
>   /efi/boot/bootx64.efi
> which both show by "strings" the embedded configuration with
>   search --file --set=root /.disk/info
> The ISO 9660 filesystem contains a file
>   /.disk/info
> 
> So the riddle is why this does not get into effect with that
> particular
> EFI implementation, and why a grub.cfg in the EFI System Partition
> solves the problem.
> 
> Does a debian-cd ISO boot properly on that EFI ?
> E.g.
>   https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.
> 4.0-amd64-netinst.iso
> 
> 
> I meanwhile found out that the efi.img of debian-cd stems from
> debian-cd_info.tar.gz created by
>    https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build
> /util/efi-image
> and that its grub-mkimage run needs no -c option because it has an -m
> option
> with a grub.cfg file in the "memdisk" tarball. It's quite the same
> tarball
> as created by live-build in
>    https://salsa.debian.org/bluca/live-build/blob/master/scripts/buil
> d/efi-image
> 
> So it might be that debian-cd is affected as well.
> If not, then differences between both ISOs might give hints about the
> cause.
> 
> 
> Have a nice day :)
> 
> Thomas

I am not sure why that EFI firmware is so picky - I'll try to find time
and test a vanilla Debian image.

Nevertheless, adding that grub.cfg file is necessary when using Secure
Boot - the monolithic grub EFI image does not contain that string. It
is built by this script in the grub2 repository:

https://salsa.debian.org/grub-team/grub/blob/master/debian/build-efi-images

Using that image is necessary with Secure Boot as that's what gets
signed. Ubuntu has the same workaround in place.

-- 
Kind regards,
Luca Boccassi

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


Bug#892413: nvidia-driver: PRIME Synchronization regression in 390.25 with kernel 4.15, fixed upstream

2018-03-12 Thread Andreas Beckmann
On 2018-03-12 17:28, Luca Boccassi wrote:
> Yeah I suspected a new release would have happened soon so I didn't
> have a look at that yet.
> 
> I'll look at 390.42 as soon as possible, and if still necessary, check
> that patch.

It still applies ... module build test still running.

> I don't use PRIME so I can't really say if it was broken or not at the
> moment.

Me neither ...

Andreas



Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

2018-03-12 Thread Chris Lamb
tags 796285 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b880cc522da37da97f8292fccadcd96e0432f372


Regards,

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



Bug#826629: Fwd: [PATCH v5] Fix loading of module radeonfb on PowerMac

2018-03-12 Thread Mathieu Malaterre
Control: tags -1 upstream confirmed pending


-- Forwarded message --


On Tuesday, February 13, 2018 07:03:16 PM Mathieu Malaterre wrote:
> When the linux kernel is build with (typical kernel ship with Debian
> installer):
>
> CONFIG_FB=y
> CONFIG_FB_OF=y
> CONFIG_VT_HW_CONSOLE_BINDING=y
> CONFIG_FB_RADEON=m
>
> The offb driver takes precedence over module radeonfb. It is then
> impossible to load the module, error reported is:
>
> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> 0x9800-0x9fff pref]
> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>
> This patch reproduce the behavior of the module radeon, so as to make it
> possible to load radeonfb when offb is first loaded, see
> commit a56f7428d753 ("drm/radeon: Add early unregister of firmware fb's").
>
> Signed-off-by: Mathieu Malaterre 
> Link: https://bugs.debian.org/826629#57
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
> Suggested-by: Lennart Sorensen 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Benjamin Herrenschmidt 
> Cc: Tomi Valkeinen 

Patch queued for 4.17, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Bug#873160: python-pymad: pymad in stretch decodes to noise

2018-03-12 Thread Adrian Bunk
On Wed, Aug 30, 2017 at 11:19:22AM +1000, Jamie Wilkinson wrote:
> Bug 873673 contains the request to the release team.

Did you make any progress preparing a 0.9-1+deb9u1 as advised by the 
release team?

Thanks
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#892483: Moving to pkg-security

2018-03-12 Thread Alexander Kulak


Preparing the package in pkg-security team.

--
Alexander Kulak



Bug#892759: rpm can't handle packages built with zstd payloads

2018-03-12 Thread Neal Gompa
Package: rpm
Version: 4.14.0+dfsg1-2
Severity: important

Dear Maintainer,

RPM v4.14 introduces support for packages compressed with zstd, and 
distributions are
starting to consider/use it. However, for Debian to be able to be useful for 
building
packages targeting these distributions, RPM needs to have zstd support enabled.

Please enable zstd support so that packages using zstd will work on Debian.

Thanks in advance.

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

Kernel: Linux 4.15.4-300.fc27.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rpm depends on:
ii  debugedit 4.14.0+dfsg1-2
ii  libc6 2.27-1
ii  libelf1   0.170-0.3
ii  libpopt0  1.16-10+b2
ii  librpm8   4.14.0+dfsg1-2
ii  librpmbuild8  4.14.0+dfsg1-2
ii  librpmio8 4.14.0+dfsg1-2
ii  librpmsign8   4.14.0+dfsg1-2
ii  perl  5.26.1-5
ii  rpm-common4.14.0+dfsg1-2
ii  rpm2cpio  4.14.0+dfsg1-2

rpm recommends no packages.

Versions of packages rpm suggests:
pn  alien 
pn  elfutils  
pn  python
pn  rpm-i18n  
pn  rpm2html  
pn  rpmlint   

-- no debconf information



Bug#892760: antlr3: FTBFS with Java 9

2018-03-12 Thread Emmanuel Bourg
Package: antlr3
Version: 3.5.2-8
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

antlr3 fails to build with Java 9:

[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] ANTLR 3 Master build control POM ... SUCCESS [  0.570 s]
[INFO] ANTLR 3 Runtime  SUCCESS [  4.100 s]
[INFO] ANTLR 3 Tool ... SUCCESS [  6.755 s]
[INFO] ANTLR 3 Maven plugin ... SUCCESS [  1.580 s]
[INFO] ANTLR 3 gUnit .. FAILURE [  1.392 s]
[INFO] ANTLR 3 gUnit Maven plugin . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 14.708 s
[INFO] Finished at: 2018-03-12T17:41:21+01:00
[INFO] Final Memory: 12M/42M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (default-cli) on 
project gunit: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - 
./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:30:
 error: package org.antlr.gunit.swingui.parsers does not exist
[ERROR] import org.antlr.gunit.swingui.parsers.ANTLRv3Lexer;
[ERROR]   ^
[ERROR] 
./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:31:
 error: package org.antlr.gunit.swingui.parsers does not exist
[ERROR] import org.antlr.gunit.swingui.parsers.ANTLRv3Parser;
[ERROR]   ^
[ERROR] 
./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:32:
 error: package org.antlr.gunit.swingui.parsers does not exist
[ERROR] import org.antlr.gunit.swingui.parsers.StGUnitLexer;
[ERROR]   ^
[ERROR] 
./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:33:
 error: package org.antlr.gunit.swingui.parsers does not exist
[ERROR] import org.antlr.gunit.swingui.parsers.StGUnitParser;
[ERROR]   ^
[ERROR]
[ERROR] Command line was: /usr/lib/jvm/java-9-openjdk-amd64/bin/javadoc 
@options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in './antlr3/gunit/target/apidocs' 
dir.



Bug#874134: Pending fixes for bugs in the swt-gtk package

2018-03-12 Thread pkg-java-maintainers
tag 874134 + pending
thanks

Some bugs in the swt-gtk package are closed in revision
f1a431eebedc536a65c8d5df1b1c29d7d95fc673 in branch '  master-4.3' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/swt-gtk.git/commit/?id=f1a431e

Commit message:

Fixed the build failure with Java 9 (Closes: #874134)



  1   2   3   >