Bug#893843: please enable nbd applet

[Michael Tokarev]

Package: busybox
Version: 1:1.27.2-2
Severity: wishlist

Please enable NBD applet for regular deb configuration. It costs almost
nothing but it is useful for our environment for booting over network.

Thanks!

/mjt

Bug#893842: openfst FTCBFS: python build dependency not installable

[Helmut Grohne]

Source: openfst
Version: 1.6.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

openfst fails to cross build from source, because its Build-Depends:
python requests a host architecture python, which fails installation.
What it really needs is a runnable python interpreter (i.e. build
architecture) though. We can achieve that by annotating the dependency
:any. After doing so, openfst cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru openfst-1.6.3/debian/changelog 
openfst-1.6.3/debian/changelog
--- openfst-1.6.3/debian/changelog  2017-08-30 22:30:48.0 +0200
+++ openfst-1.6.3/debian/changelog  2018-03-23 06:10:12.0 +0100
@@ -1,3 +1,10 @@
+openfst (1.6.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate python build dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 06:10:12 +0100
+
 openfst (1.6.3-2) unstable; urgency=medium
 
   * Disable compilation optimizations for the test suite on kfreebsd-i386
diff --minimal -Nru openfst-1.6.3/debian/control openfst-1.6.3/debian/control
--- openfst-1.6.3/debian/control2017-08-30 22:30:48.0 +0200
+++ openfst-1.6.3/debian/control2018-03-23 06:10:09.0 +0100
@@ -12,7 +12,7 @@
  debhelper (>= 9~),
  dpkg-dev (>= 1.16.1~),
  zlib1g-dev,
- python,
+ python:any,
  bash-completion
 Standards-Version: 4.0.1
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/openfst.git

Bug#893841: nodejs FTCBFS: unsatisiable cross Build-Depends: binutils

[Helmut Grohne]

Source: nodejs
Version: 8.10.0~dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nodejs Build-Depends on binutils. That dependency is not necessary,
because build-essential already Depends on binutils. It also is actively
harmful for cross building, because the Build-Depends request
binutils:$DEB_HOST_ARCH, which conflicts with binutils:$DEB_BUILD_ARCH.
If you want to keep a dependency on binutils (e.g. for adding a version
constraint), please use "binutils-for-host". In the absence of such a
need, please apply the attached patch. After doing so, nodejs will still
fail to cross build, because its gyp dependency also is unsatisfiable.
I'll look into whether we can fix that in the gyp package. So please
close this bug when dropping the binutils dependency.

Helmut
diff --minimal -Nru nodejs-8.10.0~dfsg/debian/changelog 
nodejs-8.10.0~dfsg/debian/changelog
--- nodejs-8.10.0~dfsg/debian/changelog 2018-03-16 10:25:24.0 +0100
+++ nodejs-8.10.0~dfsg/debian/changelog 2018-03-23 06:14:49.0 +0100
@@ -1,3 +1,10 @@
+nodejs (8.10.0~dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop binutils from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 06:14:49 +0100
+
 nodejs (8.10.0~dfsg-1) experimental; urgency=medium
 
   * New upstream version 8.10.0~dfsg
diff --minimal -Nru nodejs-8.10.0~dfsg/debian/control 
nodejs-8.10.0~dfsg/debian/control
--- nodejs-8.10.0~dfsg/debian/control   2018-03-16 00:03:47.0 +0100
+++ nodejs-8.10.0~dfsg/debian/control   2018-03-23 06:14:47.0 +0100
@@ -7,7 +7,6 @@
 Build-Depends: cdbs,
  debhelper (>=9.20160114),
  dh-buildinfo,
- binutils,
  openssl (>= 1.0.2),
  pkg-config,
  bash-completion,

Bug#868220: ifupdown should support vlan-aware bridges

[Joerg Dorchain]

On Thu, Mar 22, 2018 at 11:44:43PM +0100, Santiago Garcia Mantinan wrote:
> 
> I've also thinked about this because bridge-utils is basically dead upstream
> while iproute2 is integrating more and more stuff, so having the bridge
> support on ifupdown and depending on iproute2 instead of bridge-utils may be
> the way to go.

That is fine with me.
> 
> If you agree with this we'll have to talk on how we do this.

To my understanding it is basically translating the the hook scripts that
call brctl now to corresponding call to ip. While at it, adding
vlan-awareness ;-)

Again, having a look at what ifupdown2 does exeactly could help.

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#893840: RM: plasma-discover [hurd-i386 kfreebsd-i386 kfreebsd-amd64] -- ROM; RoQA: Long-term FTBFS that is not going to get better

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

For quite some time now the package hasn't built on these archs and there is
no prospect of it getting better.  May as well clear up a bit of cruft.

Scott K

Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

[Cyril Brulebois]

Hallo Norbert,

Norbert  (2018-03-22):
> I tested your systemd-build from
>   https://people.debian.org/~kibi/systemd/
> 
> The problem is resolved with your patched version. :-)

Thanks for confirming.

> I urge the package maintainers to introduce this new build really fast
> into stretch. I could imagine, this affects a whole bunch of people:
> 
> My ISP hands out unmanageable cable router/modems to it's customers.
> These devices do not provide a default MTU in their RAs.
> Therefore I have no chance of handling such a scenario other than
> patching systemd-networkd.

FWIW, users can always download the old packages (232-25+deb9u1) from
snapshot.d.o:

  http://snapshot.debian.org/package/systemd/232-25%2Bdeb9u1/


Michael/systemd maintainers, I think we should go forward with the
upload to p-u; anything I can do to help?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#893517: Installation of gcc-8 made clang-6 unusable

[Matthias Klose]

Control: severity -1 important

I'm surprised that clang picks up the headers of a non-default compiler. It
shouldn't do that.

Bug#893200: TC Chair election

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sat, Mar 17, 2018 at 10:25:28AM +0100]:
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===

I vote:

D > A > B = C = E = F > G > H

Thanks!


signature.asc
Description: PGP signature

Bug#893702: Please stop build-depending on pdftk

[Matthias Klose]

On 23.03.2018 00:08, Chris Lamb wrote:
> tags 893702 - patch
> thanks
> 
> Hi Matthias,
> 
>> pdftk still still depends on GCJ, and is likely to be removed when gcj is
>> removed. Please stop build-depending on pdftk.
> 
> We build-depend on pdftk because we actually use it to compare files,
> so unfortunately simply dropping it from the Build-Depends is not a
> sufficient patch.

Another package suggested pyPDF as an alternative. I didn't look if that's
feasable for diffoscope as well. There's also a pdftk port to OpenJDK mentioned
in one of the pdftk bugs, but that doesn't yet look very mature.

Bug#888703: Certbot version 0.21 required to interoperate with LetsEncrypt

[Harlan Lieberman-Berg]

fixed 888703 0.21.1-1
block 888703 by 887399
thanks

On Mon, 29 Jan 2018 07:47:34 +1030 John Pearson  wrote:
> My report suggested upgrading to certbot 0.20 would fix the issue;
> closer reading indicates that version 0.21 is required.

Hello!

So, while this is technically fixed in sid, I'd like to leave this bug open
for now as we try to get stable updated.  This is a bit of a reach, but,
hopefully we'll get some traction on it.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Andrew Caudwell]

Hi,

On Sat, Mar 17, 2018 at 9:31 AM, Guus Sliepen  wrote:

> tags 892861 + wontfix
> thanks
>
> On Wed, Mar 14, 2018 at 10:48:33AM +1300, Andrew Caudwell wrote:
>
> > The packaged version of GLM, 0.9.9~a2 is an alpha (the current release
> is still
> > 0.9.8.5) and removes the default initialization of vector, matrix and
> > quaternion types. Because of this code written against any earlier
> versions of
> > GLM may now have uninitialized value bugs introduced by this change
> (e.g. where
> > GLM types are member variables of a class) or now behave differently
> (mat4()
> > previously gave you an identity matrix, now this gives you a zero'd
> matrix).
> > Several issues have been raised upstream (including by myself) to re-add
> > initialization or at least make it optional.
> > Additionally the requirement in this version to define
> GLM_ENABLE_EXPERIMENTAL
> [...]
> > to use simple functions like length2() has broken multiple packages. I
> have put
> > off fixing this since making it compile just exposes the user to the
> > uninitialized value bugs. Unfortunately this has now meant my gource and
> > logstalgia debian packages have been removed from debian since they don't
> > complile with this GLM version.
>
> I believe these are intentional changes by the author of GLM. I expect
> that GLM 1.0.0 will be released before the next release of Debian, and
> any packages that depend on GLM should instead be fixed to handle the
> new behavior.
>

The upstream author hasn't commented on these issues yet so there's no
reason to assume they will leave things in the current state without at
least providing at least a work around to the initialization issue.

>
> Unless I am mistaken, projects depending on GLM can just #define
> GLM_ENABLE_EXPERIMENTAL and provide explicit default initializers, which
> will be backwards compatible with older versions of GLM.
>

Fixing the default initializers issue requires a thorough code review and
probably debugging with valgrind to find these cases (-Wuninitialized won't
find these) which I think is an unreasonable burden on maintainers.

Other distros such as Redhat, Gentoo and Arch Linux have continued to
package the current release 0.9.8.5 with a fix for the GCC 7.3 issue (which
only requires changing an == to >=):

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/glm

Ubuntu 18.04 has imported the current Debian unstable libglm-dev package
which has made resolving this issue more urgent in my view.

My current work around is to embed the patched version of 0.9.8.5 and
provide a --with-glm option for distros that have a compatible version of
the library.

Ideally I would like to be able to use the Debian libglm-dev package so I
hope you reconsider.

Cheers

Andrew



>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
>

Bug#888165: [DRE-maint] Bug#888165: ruby-puppet-syntax: FTBFS on ruby2.5: OpenSSL::ASN1::ASN1Error: oid exists

[Paul Wise]

Control: reassign -1 puppet 4.10.4-2
Control: fixed -1 puppet/5.4.0-1

On Wed, 21 Mar 2018 19:00:07 +0100 Georg Faerber wrote:

> This was due to the use of OpenSSL 1.1.0. puppet upstream fixed this on
> 2018/01/17 [1], and released puppet 5.3.4 on 2018/01/26 [2], including
> this fix. Debian unstable / testing currently ships 5.4.0-2 [3],
> uploaded on 2018/03/13. Therefore, closing and marking as done.

Since this was a bug in puppet, it should be reassigned there.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893839: sqwebmail: the group and owner for /var/cache/sqwebmail are incorrect

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: normal

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (which is based on debian 
stretch), I noticed messages like the following in /var/log/mail.log:
"Jan 31 12:30:56 vserver sqwebmaild: maildircache: Cache create failure - unable
to create file /var/cache/sqwebmail/210754/gr/greg."

I found that the default group and owner for /var/cache/sqwebmail was courier 
and courier respectively. Changing the group and owner to bin and bin 
respectively resolved this for me.


-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
* sqwebmail/install-www: symlink
  sqwebmail/dictionary: default

Bug#891599: gdm3: Greeter doesn't allow control of network-manager connections even when member of netdev group

[Matthew Gabeler-Lee]

Package: gdm3
Version: 3.22.3-3+deb9u1
Followup-For: Bug #891599

This actually looks like it might be a bug in gnome-shell, and still present
in 3.28.  This silly-looking(?) bit of logic is present there in
js/ui/status/network.js:

_sessionUpdated() {
let sensitive = !Main.sessionMode.isLocked && 
!Main.sessionMode.isGreeter;
this.menu.setSensitive(sensitive);
},

I.e. it looks like it's hard coding things to not allow interaction from the
greeter, no matter what permissions you might or might not have set.

Bug#893838: sqwebmail: default sendit.sh script doesn't work with postfix

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: important

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (which is based on debian 
stretch), I found that users can't send mail when using the sqwebmail 
interface. When a message is composed, and the send button is chosen, an error 
similar to the following appears:
"sendmail: fatal: g...@gregn.net(1000): Recipient addresses must be specified on
+the command line or via the -t option"
I am using postfix as my MTA. The problem is caused by the 
/usr/lib/courier/sqwebmail/sendit.sh script. The default invocation of sendmail 
doesn't work with postfix. For postfix users, the end of the sendit.sh script 
should read:
"exec /usr/sbin/sendmail -OI -t -f "$1"
# exec /usr/sbin/sendmail $DSN -f "$1""

The first invocation needs to be uncommented, and the second needs to be 
commented out. I would suggest that when the package is installed or upgraded, 
the user should be advised to look at the /usr/lib/courier/sqwebmail/sendit.sh 
script, and edit it as necessary. Ideally, it would be nice if debconf detected 
which MTA is installed, and automagicly adjusted sendit.sh to match what the 
sendmail binary of the MTA expects.


-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
  sqwebmail/dictionary: default
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
* sqwebmail/install-www: symlink

Bug#893837: python-apt: FTBFS on all architectures (missing build-dep python3-distutils-extra?)

[Boyuan Yang]

Source: python-apt
Version: 1.6.0~rc1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

python-apt 1.6.0~rc1 FTBFS on every architectures.

Buildd logs indicate that a build-dependency (python3-distutils-extra) is
likely to be missing:

dh clean --with python2,python3,sphinxdoc
   dh_auto_clean
python2.7-dbg setup.py clean -a
running clean
'build/lib.linux-x86_64-2.7-pydebug' does not exist -- can't clean it
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
python3.6-dbg setup.py clean -a
Traceback (most recent call last):
  File "setup.py", line 9, in 
from distutils.core import setup, Extension
ModuleNotFoundError: No module named 'distutils'

--
Regards,
Boyuan Yang



-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (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=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#890115: Info received (Bug#890115: xl2tpd: uncompatible configure with ppp)

[Samir Hussain]

refrog2000, did a simplified configuration help?

Bug#893836: kdelibs4support: FTBFS on all architectures; missing symbols

[Boyuan Yang]

Source: kdelibs4support
Version: 5.44.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

kdelibs4support FTBFS on all architectures (except "all"):

https://buildd.debian.org/status/package.php?p=kdelibs4support

Some symbols are missing:

+#MISSING: 5.44.0-1# _ZTSN5KMenu12KMenuPrivateE@Base 4.96.0
  _ZTSN5Solid10Networking8NotifierE@Base 4.99.0
  _ZTSN5Solid15PowerManagement8NotifierE@Base 4.99.0
  _ZTSN6KParts7FactoryE@Base 4.96.0
@@ -4204,7 +4204,7 @@
  _ZTVN3KIO11MetaInfoJobE@Base 4.96.0
  _ZTVN3KIO14PasswordDialogE@Base 4.96.0
  _ZTVN3KIO9NetAccessE@Base 4.96.0
- _ZTVN5KMenu12KMenuPrivateE@Base 4.96.0
+#MISSING: 5.44.0-1# _ZTVN5KMenu12KMenuPrivateE@Base 4.96.0
  _ZTVN5Solid10Networking8NotifierE@Base 4.99.0
  _ZTVN5Solid15PowerManagement8NotifierE@Base 4.99.0
  _ZTVN6KParts7FactoryE@Base 4.96.0
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:7: binary-arch] Error 2

--
Regards,
Boyuan Yang



-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (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=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#893257:

[David Loyall]

After a reboot and ensuring that the guest was not running, I was able
to conclude the dpkg operation.

sebboh@truth:~$ sudo apt-get install bugreport
E: dpkg was interrupted, you must manually run 'sudo dpkg
--configure -a' to correct the problem.
sebboh@truth:~$ sudo dpkg --configure -a
Setting up systemd (236-1) ...
Processing triggers for man-db (2.7.6.1-4) ...
Setting up apt-cacher-ng (3.1-1) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/apt-cacher-ng.service →
/lib/systemd/system/apt-cacher-ng.service.
Processing triggers for systemd (236-1) ...
sebboh@truth:~$

That's all I know for now.  bugreport follows.

Cheers,
--Dave

Subject: Re: libvirt-daemon-system (bpo) upgrade hard freezes system
Followup-For: Bug #893257
Package: libvirt-daemon-system
Version: 4.1.0-2

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.116
ii  debconf [debconf-2.0]  1.5.65
ii  gettext-base   0.19.8.1-4
ii  iptables   1.6.1-2+b1
ii  libacl12.2.52-3+b1
ii  libapparmor1   2.11.1-4
ii  libaudit1  1:2.8.2-1
ii  libblkid1  2.30.2-0.1
ii  libc6  2.26-2
ii  libcap-ng0 0.7.7-3.1+b1
ii  libdbus-1-31.12.2-1
ii  libdevmapper1.02.1 2:1.02.145-4.1
ii  libgnutls303.5.16-1
ii  libnl-3-2003.2.27-2
ii  libnl-route-3-200  3.2.27-2
ii  libnuma1   2.0.11-2.1
ii  libselinux12.7-2
ii  libvirt-clients4.1.0-2
ii  libvirt-daemon 4.1.0-2
ii  libvirt0   4.1.0-2
ii  libxml22.9.4+dfsg1-5.2
ii  libyajl2   2.1.0-2+b3
ii  logrotate  3.11.0-0.1
ii  lsb-base   9.20170808
ii  policykit-10.105-18

Versions of packages libvirt-daemon-system recommends:
pn  bridge-utils  
ii  dmidecode 3.1-1
ii  dnsmasq-base  2.78-3
ii  ebtables  2.0.10.4-3.5+b1
ii  iproute2  4.13.0-1
pn  parted

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
pn  nfs-common  
pn  pm-utils
pn  radvd   
ii  systemd 236-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml changed:


  b7ead4b0-10ac-4fcf-a0ad-7feae6f4618c
  


/etc/libvirt/nwfilter/allow-dhcp-server.xml changed:


  b2356554-33cc-4cfe-bd23-d86b77cf6912
  

  
  

  


/etc/libvirt/nwfilter/allow-dhcp.xml changed:


  34b110c1-e911-4c38-b037-44de8913d59d
  

  
  

  


/etc/libvirt/nwfilter/allow-incoming-ipv4.xml changed:


  2c62a6e4-5f0c-420f-9fa9-15e21aa6b7b2
  


/etc/libvirt/nwfilter/allow-ipv4.xml changed:


  69fc2290-7af6-44f6-ac09-936d8eb1b959
  


/etc/libvirt/nwfilter/clean-traffic.xml changed:


  b7d6cd03-bfa0-4f93-81af-fb786c428e9c
  
  
  

  
  
  
  

  
  
  


/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml changed:


  6e8615f0-3637-4229-9c5e-546bb52cebf7
  

  
  


/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml changed:


  43ebfc31-ca44-4dea-936e-b2f7349d9276
  

  
  


/etc/libvirt/nwfilter/no-arp-spoofing.xml changed:


  6bad362c-d5c1-4ea9-b42f-1b4fc9f4ba8c
  
  


/etc/libvirt/nwfilter/no-ip-multicast.xml changed:


  c6b605ec-a9e0-4afa-9e9d-21219ce17e02
  

  


/etc/libvirt/nwfilter/no-ip-spoofing.xml changed:


  5cfe6bd8-ffda-4bf5-85cd-1a7caa41e758
  

  
  

  
  


/etc/libvirt/nwfilter/no-mac-broadcast.xml changed:


  c4bddf82-d6a1-41df-be2d-fc77b39fc3eb
  

  


/etc/libvirt/nwfilter/no-mac-spoofing.xml changed:


  6e7a4433-951c-4db5-8ab5-f207acc5bf5c
  

  
  

  


/etc/libvirt/nwfilter/no-other-l2-traffic.xml changed:


  c62645b5-ba97-4a0d-adf0-dca57e1692b6
  


/etc/libvirt/nwfilter/no-other-rarp-traffic.xml changed:


  1ae86cfb-2ca1-485d-a617-6e3f137ab51e
  


/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml changed:


  ec48a012-4d37-462a-81c2-19cbdc55aa33
  

  
  

  


/etc/libvirt/nwfilter/qemu-announce-self.xml changed:


  3526c0fb-4558-4818-9195-ace5ad3fde0d
  

  
  
  


/etc/libvirt/qemu/networks/default.xml changed:


  default
  907a9b43-0dbe-40e8-b57d-f2e026d436d1
  
  
  
  

  

  



-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#893835: ruby-factory-bot: Fix watch file, once upstream clarified release policy

[Georg Faerber]

Source: ruby-factoy-bot
Tags: confirmed upstream
Forwarded: https://github.com/thoughtbot/factory_bot/issues/1108

The watch file currently hardcodes the upstream version, because the
release policy is at least confusing, currently. See the linked upstream
issue for details. This should be fixed once the situation got
clarified.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#893834: [cpio] Empty man page

[grac...@mail.ru]

Package: cpio
Version: 2.11+dfsg-5ubuntu1

File

/usr/share/man/man1/cpio.1.gz

contain only list
of command line options.
It is a bug, because man page
must contain description
of each command line option.

Bug#893833: openjdk-10: Please drop obsolete patch hotspot-disable-jvmtihtml.diff

[John Paul Adrian Glaubitz]

Source: openjdk-10
Version: 10~46-2
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

The patch hotspot-disable-jvmtihtml.diff doesn't apply anymore,
please remove it completely. It also seems we don't need it
anymore at all, but I am checking openjdk-10 (and -11) on m68k
now to see whether we need another patch. I will open another bug
report for that if necessary.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff 
new/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff
--- old/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff  
2017-11-19 14:58:26.0 +0100
+++ new/openjdk-10-10~46/debian/patches/hotspot-disable-jvmtihtml.diff  
1970-01-01 01:00:00.0 +0100
@@ -1,10 +0,0 @@
 a/src/hotspot/make/gensrc/GensrcJvmti.gmk.orig 2017-05-11 
14:11:42.0 +0200
-+++ b/src/hotspot/make/gensrc/GensrcJvmti.gmk  2017-06-06 16:38:26.990673621 
+0200
-@@ -103,7 +103,6 @@
- -PARAM interface jvmti -PARAM trace Trace))
- $(eval $(call SetupJvmtiGeneration, jvmtiEnv.hpp, jvmtiHpp.xsl))
- $(eval $(call SetupJvmtiGeneration, jvmti.h, jvmtiH.xsl))
--$(eval $(call SetupJvmtiGeneration, jvmti.html, jvmti.xsl))
- $(eval $(call SetupJvmtiGeneration, jvmtiEnvStub.cpp, jvmtiEnv.xsl))
- 
- JVMTI_BC_SRCDIR := $(HOTSPOT_TOPDIR)/src/share/vm/interpreter
diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules
--- old/openjdk-10-10~46/debian/rules   2018-03-15 14:31:57.0 +0100
+++ new/openjdk-10-10~46/debian/rules   2018-03-23 00:50:01.171199985 +0100
@@ -365,11 +365,6 @@
alpha-float-const.diff
 endif
 
-ifneq (,$(filter $(DEB_HOST_ARCH), m68k))
-  COMMON_PATCHES += \
-   hotspot-disable-jvmtihtml.diff
-endif
-
 ifneq (,$(filter $(DEB_HOST_ARCH), kfreebsd-amd64 kfreebsd-i386))
   COMMON_PATCHES += \
kfreebsd-support-jdk.diff \

Bug#893832: override: jekyll:web/optional

[Georg Faerber]

Package: ftp.debian.org

Hi,

As per #832227: Please override the section of jekyll, it should be
'web' instead of 'ruby'. This change was pushed to git [1] and uploaded
shortly after.

Thanks,
cheers,
Georg


[1] 
https://salsa.debian.org/ruby-team/jekyll/commit/0d648552bf68b412b3708ba6e83f942abce055fa


signature.asc
Description: Digital signature

Bug#893153: Pending fixes for bugs in the geronimo-interceptor-3.0-spec package

[pkg-java-maintainers]

tag 893153 + pending
thanks

Some bugs in the geronimo-interceptor-3.0-spec package are closed in
revision 8f03436839dd216e5dd1c4e94501a885d18ce84b in branch 'master'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/geronimo-interceptor-3.0-spec.git/commit/?id=8f03436

Commit message:

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

Bug#889732: libconfig-model-dpkg-perl: Does not recognize Salsa platform in Vcs field

[gregor herrmann]

On Thu, 22 Mar 2018 17:04:06 +0100, Andreas Tille wrote:

> > For debian med this looks pretty straight-forward:
> > if: $maintainer =~ /debian-med-packaging/
> > then: https://salsa.debian.org/med-team/$pkgname.git
> > 
> > Correct?
> 
> I'm afraid there are two or three exceptions but most probably we need
> to fix these exceptions manually since these are rather considered as
> bugs in our VCS repositories.  So yes, that's correct. 

Thanks.

Good news: I've added the computed values for Debian-Med and
Debian-Science in git.
Bad news: That's not enough; AFAICS cme fix doesn't change existing
values, and besides that anonscm and friends are still considered
valid.
Even worse news: Trying to rip out anonscm and other alioth URLs is
beyond my understanding of Config::Model, I can only trigger huge
amounts of test failures.

I'm afraid that's a case for Dominique alone ...
  
> > For the R team I'm not so sure. I looked at some packages, and 7 or 8
> > of 10 had
> > $maintainer =~ debian-science-maintainers
> > but I've also seen other values in Maintainers.
> > Is there some unique value in debian/source to filter on?
> > 
> > The URLs seem to be https://salsa.debian.org/r-pkg-team/$pkgname.git
> 
> I think you could filter for
> 
>( $pkgname =~ /^r-cran-.*/ || $pkgname =~ /^r-bioc-.*/ ) && Vcs-fields 
> "exists"
> 
> I'm not sure about the latter.  Dirk Eddelbüttel does not maintain his
> packages in Vcs and I do not know his plans to do so.  It might be
> irrelevant since I doubt he is using cme.  I'm CCing debian-r list for
> review - may be Dirk can pronounce whether he considers it helpful if
> cme would insert Vcs fields also for his packages.  This would simplify
> migrating his packages easily to Salsa by using cme in case he might
> decide to do this.

Ok, let's wait and see.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Die Tontauben: shine


signature.asc
Description: Digital Signature

Bug#598434: bind9: Improve detection and handling of recursive 'include' statements in configuration files

[Bernhard Schmidt]

Control: tags -1 upstream

On Tue, Sep 28, 2010 at 11:15:28PM +0200, Javier Fernández-Sanguino Peña wrote:

> Currently, bind9 does not try to take any precaution when handling 'include'
> statements in the config files. It will happily accept even an include
> statement in a file pointing to itself which is, obviously, something that
> leads nowhere. For example, see attached named.conf.local, which bind9 tries
> to chew even if it doesn't make sense.

Thanks for submitting this patch.

Upstream has recently introduced a public Gitlab instance at
https://gitlab.isc.org where patches / feature-requests can be
submitted. We don't want to add more Debian patches, but if this issue
is still relevant please submit it upstream for inclusion.

Bernhard

Bug#883286: Please ship a python3-gps package

[Bernd Zeimetz]

That's not all and not the problem. The real one is that scons in Debian does 
not support python 3 due to a broken Debian patch. Opened a bug already... 

Am 22. März 2018 22:41:56 MEZ schrieb Paride Legovini :
>On 21/03/2018 21.19, Bernd Zeimetz wrote:
>> Hi,
>> 
>> 
>> On 03/20/2018 12:05 PM, Paride Legovini wrote:
>>> On Fri, 1 Dec 2017 13:03:05 -0600 Richard Laager
> wrote:
 Please consider shipping a python3-gps package, either in addition
>to or
 instead of python-gps. I don't know how much work that will be, so
>I
 understand that it might be a while.
>>>
>>> The Python code in gpsd is compatible with both Python2 and Python3,
>>> as stated in the header of the Python files:
>>>
>>> # This code runs compatibly under Python 2 and 3.x for x >= 2.
>>>
>>> I believe a python3-gps package will be almost identical to
>python-gps.
>> 
>> thats all true, but the SConstruct file in 3.17 just does not work
>with
>> python3. I could create a hand hacked package, but I'm not keen on
>doing
>> that.
>
>Have a look at this commit:
>
>http://deb.li/3KWUA
>
>If patching it is this simple, then I think it's worth doing so.
>
>Paride

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#890419: [PATCH] Fix boostrapping libvirt LXC containers

[Lubomir Rintel]

One more patch, to make debootstrap work in case the container has a
separate userns, but not netns.

This makes debootstrap work with virt-install with this branch [1],
making it rather convenient to install a Debian container with virt-
install:

virt-install \
--debug \
--connect lxc:/// \
--name debian \
--memory 512 \
--idmap 
uid_start=0,uid_target=100,uid_count=65536,gid_start=0,gid_target=100,gid_count=65536
 \
--filesystem /var/lib/libvirt/filesystems/debian,/ \
--location http://ftp.us.debian.org/debian/dists/testing/

[1] https://github.com/lkundrak/virt-manager/tree/lr/lxc-installFrom f2524081ad9b9b10ab6b4d1b50f3f55cdc3c9375 Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Tue, 20 Mar 2018 22:20:34 +0100
Subject: [PATCH 4/4] Unshare the net namespace in LXC namespace

If we're running without privnet but with a idmap we are CAP_SYS_ADMIN
in the userns but not in the netns and therefore mounting a new sysfs
instance is not allowed (since [7dc5dbc879bd sysfs: Restrict mounting
sysfs] in kernel 3.11).
---
 debootstrap | 4 
 1 file changed, 4 insertions(+)

diff --git a/debootstrap b/debootstrap
index fcdb20f..86d489a 100755
--- a/debootstrap
+++ b/debootstrap
@@ -468,6 +468,10 @@ else
 	CHROOT_CMD="chroot $TARGET"
 fi
 
+if grep -q container=lxc-libvirt /proc/1/environ; then
+	CHROOT_CMD="unshare --net $CHROOT_CMD"
+fi
+
 if [ -z "$SHA_SIZE" ]; then
 	SHA_SIZE=256
 fi
-- 
2.14.3

Bug#893831: libnitrokey: symbols adjustments to support build with -O3

[Steve Langasek]

Package: libnitrokey
Version: 3.2-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi Scott,

libnitrokey 3.2-1 fails to build on ppc4el in Ubuntu because the symbols
files don't match.  This is because Ubuntu builds its ppc64el port with -O3
by default, and some C++ symbols are removed when building with higher
optimization levels.

The attached patch makes the symbols file work when building with either -O2
or -O3 (at least on ppc64el).  Please consider including this in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libnitrokey-3.2/debian/libnitrokey3.symbols 
libnitrokey-3.2/debian/libnitrokey3.symbols
--- libnitrokey-3.2/debian/libnitrokey3.symbols 2018-01-16 18:18:41.0 
-0800
+++ libnitrokey-3.2/debian/libnitrokey3.symbols 2018-03-22 16:07:47.0 
-0700
@@ -109,7 +109,7 @@
  _ZN32LongOperationInProgressExceptionD0Ev@Base 3.1
  _ZN32LongOperationInProgressExceptionD1Ev@Base 3.1
  _ZN32LongOperationInProgressExceptionD2Ev@Base 3.1
- _ZN8nitrokey11vector_copyIA20_hhEEvRT_RSt6vectorIT0_SaIS5_EE@Base 3.1
+ 
(optional=templinst)_ZN8nitrokey11vector_copyIA20_hhEEvRT_RSt6vectorIT0_SaIS5_EE@Base
 3.1
  _ZN8nitrokey15NitrokeyManager10disconnectEv@Base 3.1
  _ZN8nitrokey15NitrokeyManager10erase_slotEhPKc@Base 3.1
  _ZN8nitrokey15NitrokeyManager10get_statusEv@Base 3.1
@@ -455,7 +455,7 @@
  
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceIN8nitrokey6device7Stick20ESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 3.1
  
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceIN8nitrokey6device7Stick20ESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 3.1
  
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceIN8nitrokey6device7Stick20ESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 3.1
- _ZNSt5mutex4lockEv@Base 3.1
+ (optional)_ZNSt5mutex4lockEv@Base 3.1
  
(optional=templinst)_ZNSt6vectorISt10shared_ptrIN8nitrokey6device6DeviceEESaIS4_EED1Ev@Base
 3.1
  
(optional=templinst)_ZNSt6vectorISt10shared_ptrIN8nitrokey6device6DeviceEESaIS4_EED2Ev@Base
 3.1
  
(optional=templinst)_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@Base
 3.1

Bug#887635: dms binary-any FTBFS

[Steve Langasek]

Package: dms
Version: 1.0.8.1-1
Followup-For: Bug #887635
User: ubuntu-de...@lists.ubuntu.com
Usertags: bionic ubuntu-patch

Please find attached a patch that fixes this build failure, to ensure that
dh_sphinxdoc is only called when dms-doc is among the packages being built.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dms-1.0.8.1/debian/rules dms-1.0.8.1/debian/rules
--- dms-1.0.8.1/debian/rules2018-01-15 19:22:30.0 -0800
+++ dms-1.0.8.1/debian/rules2018-03-22 15:55:06.0 -0700
@@ -49,8 +49,10 @@
find . -type d -name '__pycache__' | xargs rm -rf 
 
 override_dh_sphinxdoc:
-   dh_sphinxdoc -X searchtools.js -X translations.js
-   dh_sphinxdoc /usr/share/doc/dms-doc/html/
+ifneq (,$(filter $(shell dh_listpackages),dms-doc))
+   dh_sphinxdoc -X searchtools.js -X translations.js
+   dh_sphinxdoc /usr/share/doc/dms-doc/html/
+endif
 
 %:
dh $@ --with sphinxdoc

Bug#868220: ifupdown should support vlan-aware bridges

[Santiago Garcia Mantinan]

Hi!

> It looks to me like iproute2 now provides a superset of vconfig and
> brctl, so yes, perhaps it should all be configured using iproute2.
> However, the bridge support for ifupdown currently lives in the
> bridge-utils package, so that's why I've reassigned the bug there. But
> if there is a desire to move the ifupdown integration scripts to the
> ifupdown package, I'd not be opposed to that.

I've also thinked about this because bridge-utils is basically dead upstream
while iproute2 is integrating more and more stuff, so having the bridge
support on ifupdown and depending on iproute2 instead of bridge-utils may be
the way to go.

If you agree with this we'll have to talk on how we do this.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#884095: flag to force file types

[Hans-Christoph Steiner]

Chris Lamb:
> Hi Hans,
> 
>> It would be literally impossible to auto-detect since a Janus APK is
>> both a valid DEX file (starting with the bytes "dex") and […]
> 
> Oh dear, I got a little lost in the weeds of Janus/APK/ZIP here..
> 
> Could you excuse my pedanticness and ask for direct links to files,
> what you are seeing and what you are expecting?  That would immediately
> clarify a few questions and avoid a lengthy back-and-forth :)
> 
> 
> Best wishes,

https://www.androidpolice.com/wp-content/uploads/janus-poc/HelloWorld-Janus.apk

Or create your own:
https://github.com/odensc/janus

.hc

Bug#893830: sqwebmail cgi can't access sqwebmail.sock

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (based on debian stretch), I 
found that accessing the sqwebmail CGI resulted in a page which displayed a 
system unavailable message.
It turns out the problem was that the sqwebmail CGI couldn't access the unix 
domain sqwebmail.sock socket. This is because the permissions on 
/var/lib/courier are 750 by default. Changing the permissions on 
/var/lib/courier to 755 resolves this issue.

-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
  sqwebmail/dictionary: default
* sqwebmail/install-www: symlink

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Markus Koschany]

Am 22.03.2018 um 20:52 schrieb Felix Natter:
> Markus Koschany  writes:
> 
>> Package: freeplane
>> X-Debbugs-CC: t...@security.debian.org
>> X-Debbugs-CC: fnat...@gmx.net
>> Severity: important
>> Tags: security
>>
>> Hi,
> 
> hello Markus,
> 
>> the following vulnerability was published for freeplane. Apparently only
>> stretch/jessie/wheezy might be affected.
> 
> Thank you for paying attention to this, I completely overlooked this!


Thanks for your reply!

> 
>> @Felix
>> Can you tell us more about this vulnerability? There only seems to be a
>> reference in freeplane's wiki.
> 
> I think it is very well explained here:
> https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
> 
> In short: External identities are "includes" for XML documents that can
> be specified in DTDs.
> 
> Here is the commit that should fix it:
> https://github.com/freeplane/freeplane/commit/a5dce7f9f

That's what we were looking for.

[...]


> I can confirm that the the fix is in 1.5.20 and 1.6.1, so it's true that
> wheezy, jessie and stretch are affected.
> 
> Shall I add the patch in git branches from the debian/X tags here?
> https://anonscm.debian.org/cgit/pkg-java/freeplane.git
> Or did you want to do this, Markus?

Please prepare updates for Jessie and Stretch if time permits and I will
upload the fix either as a security update, provided the security team
agrees, or as a point-update. I will take care of Wheezy myself.

> 
> I will read more about security updates on the weekend.
> 
> Cheers and Best Regards,

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#893257: Encountered same issue in sid.

[David Loyall]

Hello.

I'm using debian sid (from debian-installer daily build less than six
months old) and I encountered a very similar problem.  I am using
libvirt/qemu/kvm.

I was running `sudo apt-get dist-upgrade` in the guest and `sudo
apt-get install apt-cacher-ng` on the host.

Below my signature are some simple terminal logs.  I'll have to wait
an hour and a half to reboot the host machine.

When I reboot the machine, what information should I collect?  I know
how to run reportbug without arguments.  What else?

Cheers,
--Dave

host:

sebboh@truth:~$ sudo apt-get install apt-cacher-ng
[sudo] password for sebboh:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  doc-base avahi-daemon
The following NEW packages will be installed:
  apt-cacher-ng
0 upgraded, 1 newly installed, 0 to remove and 652 not upgraded.
Need to get 525 kB of archives.
After this operation, 1,435 kB of additional disk space will be used.
Get:1 http://debian.uchicago.edu/debian sid/main amd64
apt-cacher-ng amd64 3.1-1 [525 kB]
Fetched 525 kB in 0s (708 kB/s)
Preconfiguring packages ...
Selecting previously unselected package apt-cacher-ng.
(Reading database ... 94471 files and directories currently installed.)
Preparing to unpack .../apt-cacher-ng_3.1-1_amd64.deb ...
Unpacking apt-cacher-ng (3.1-1) ...
Processing triggers for systemd (236-1) ...
Failed to reload daemon: Connection reset by peer
Connection to truth closed.

guest:

sebboh@tiny:~$ sudo apt-get upgrade; sudo apt-get dist-upgrade
[sudo] password for sebboh:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  linux-image-amd64
The following packages will be upgraded:
  bsdutils fdisk gcc-8-base libapparmor1 libblkid1 libcryptsetup12
libfdisk1 libgcc1 libgpg-error0 libmount1 libnewt0.52 libpam-systemd
libsmartcols1 libstdc++6 libsystemd0 libudev1 libuuid1
  libx11-6 libx11-data mount systemd systemd-sysv udev util-linux
util-linux-locales whiptail
26 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 10.3 MB of archives.
After this operation, 32.8 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://debian.gtisc.gatech.edu/debian sid/main amd64
bsdutils amd64 1:2.31.1-0.5 [117 kB]
Get:2 http://debian.gtisc.gatech.edu/debian sid/main amd64
libuuid1 amd64 2.31.1-0.5 [76.8 kB]
Get:3 http://debian.gtisc.gatech.edu/debian sid/main amd64
libblkid1 amd64 2.31.1-0.5 [183 kB]
Get:4 http://debian.gtisc.gatech.edu/debian sid/main amd64
libfdisk1 amd64 2.31.1-0.5 [224 kB]
Get:5 http://debian.gtisc.gatech.edu/debian sid/main amd64
libmount1 amd64 2.31.1-0.5 [196 kB]
Get:6 http://debian.gtisc.gatech.edu/debian sid/main amd64
libsmartcols1 amd64 2.31.1-0.5 [141 kB]
Get:7 http://debian.gtisc.gatech.edu/debian sid/main amd64 fdisk
amd64 2.31.1-0.5 [166 kB]
Get:8 http://debian.gtisc.gatech.edu/debian sid/main amd64
util-linux amd64 2.31.1-0.5 [957 kB]
Get:9 http://debian.gtisc.gatech.edu/debian sid/main amd64
systemd-sysv amd64 238-3 [87.4 kB]
Get:10 http://debian.gtisc.gatech.edu/debian sid/main amd64
libpam-systemd amd64 238-3 [186 kB]
Get:11 http://debian.gtisc.gatech.edu/debian sid/main amd64
libsystemd0 amd64 238-3 [284 kB]
Get:12 http://debian.gtisc.gatech.edu/debian sid/main amd64
systemd amd64 238-3 [3,058 kB]
Get:13 http://debian.gtisc.gatech.edu/debian sid/main amd64 udev
amd64 238-3 [1,183 kB]
Get:14 http://debian.gtisc.gatech.edu/debian sid/main amd64
libudev1 amd64 238-3 [129 kB]
Get:15 http://debian.gtisc.gatech.edu/debian sid/main amd64
libapparmor1 amd64 2.12-4 [85.0 kB]
Get:16 http://debian.gtisc.gatech.edu/debian sid/main amd64
libgpg-error0 amd64 1.28-2 [126 kB]
Get:17 http://debian.gtisc.gatech.edu/debian sid/main amd64
libcryptsetup12 amd64 2:2.0.2-1 [170 kB]
Get:18 http://debian.gtisc.gatech.edu/debian sid/main amd64 mount
amd64 2.31.1-0.5 [166 kB]
Get:19 http://debian.gtisc.gatech.edu/debian sid/main amd64
gcc-8-base amd64 8-20180321-1 [183 kB]
Get:20 http://debian.gtisc.gatech.edu/debian sid/main amd64
libstdc++6 amd64 8-20180321-1 [396 kB]
Get:21 http://debian.gtisc.gatech.edu/debian sid/main amd64
libgcc1 amd64 1:8-20180321-1 [40.8 kB]
Get:22 http://debian.gtisc.gatech.edu/debian sid/main amd64
libnewt0.52 amd64 0.52.20-4 [72.8 kB]
Get:23 http://debian.gtisc.gatech.edu/debian sid/main amd64
whiptail amd64 0.52.20-4 [39.2 kB]
Get:24 http://debian.gtisc.gatech.edu/debian sid/main amd64
libx11-data all 2:1.6.5-1 [292 kB]
Get:25 http://debian.gtisc.gatech.edu/debian sid/main amd64
libx11-6 amd64 2:1.6.5-1 [749 kB]
Get:26 http://debian.gtisc.gatech.edu/debian sid/main amd64
util-linux-locales all 2.31.1-0.5 

Bug#886874: pacapt FTBFS: a2x: ERROR: "xmllint" --nonet --noout --valid "/build/1st/pacapt-2.3.14/debian/pacapt.1.xml" returned non-zero exit status 4

[Steve Langasek]

Package: pacapt
Version: 2.3.14-1
Followup-For: Bug #886874
User: ubuntu-de...@lists.ubuntu.com
Usertags: bionic ubuntu-patch

This is a matter of two missing build-dependencies.  Please find attached a
patch to fix this bug.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pacapt-2.3.14/debian/control pacapt-2.3.14/debian/control
--- pacapt-2.3.14/debian/control2018-01-09 23:07:30.0 -0800
+++ pacapt-2.3.14/debian/control2018-03-22 15:13:43.0 -0700
@@ -4,6 +4,8 @@
 Maintainer: ChangZhuo Chen (陳昌倬) 
 Build-Depends: debhelper (>= 11),
asciidoc-base,
+   docbook-xml,
+   xsltproc
 Standards-Version: 4.1.3
 Homepage: https://github.com/icy/pacapt
 Vcs-Git: https://salsa.debian.org/debian/pacapt.git

Bug#893656: transition: theano 0.9 -> 1.0 - please update lasagne

[Stephen Sinclair]

I was waiting for Lasagne to do a release, but I can take a look at it
soon. I'll try to do it tomorrow.


On Thu, Mar 22, 2018 at 6:41 PM, Rebecca N. Palmer 
wrote:

> lasagne - 3 test failures; fixed upstream by
>> https://github.com/Lasagne/Lasagne/pull/836
>>
> Latest upstream (37ca134; only packaging change was to drop
> remove-deprecated.patch) doesn't have these failures.  There is a warning
> that cuda_convnet is no longer available with Theano 1.0, but that has
> another dependency (pybuild2) that was never in Debian anyway.
>
> pyopencl - FTBFS for unrelated reasons (#893050); the theano-using code
>> appears to be build/test scripts (pyopencl/compyte/gen*, test*) we never
>> actually run
>>
> Builds after applying the path in #893050; 7 tests fail or crash (in
> Python 2, 6 also in Python 3), but they do this with or without Theano.
>
> sympy - build hangs at mkdir -p _build/logo (with mkdir using a full CPU
>> core?!), probably unrelated as it also happens without *-theano installed
>>
> This hang is because faketime doesn't work well with cowbuilder --login,
> i.e. nothing to do with sympy itself.  Running the testsuite with new
> Theano succeeds.
>
> Hence, it appears that updating lasagne is the only change required to
> work with Theano 1.0, but testing on CUDA-capable hardware would still be
> preferable.
>
>

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Luca Boccassi]

On Thu, 2018-03-22 at 14:36 +, Michael Schaller wrote:
> > How would the switch-at-boot mechanism work?
> 
> The basic idea for the switch-at-boot mechanism is that it would
> check the
> version of the loaded NVIDIA kernel module
> (/sys/module/nvidia/version) on
> boot and then select the matching user space version (via
> update-alternatives) before anything attempts to use it.

I see. Perhaps a systemd unit with the appropriate precedences set so
that it runs before X starts? And $something-$something for Sys-V I
guess :-)

> > Seeing your email address domain - any chance your company could
> > use
> > its gargantuan soft-power to get Nvidia to publish the specs for
> > the
> > missing parts of Nouveau (reclocking, power managerment, etc)? That
> > would solve all our problems once and for all :-P
> 
> I wished but that sounds like deep lawyer cat territory and I very
> much
> prefer to work on a technical solution. ;-)

Was worth a try :-) I must admit that lately, looking at the AMD camp
with their in-tree kernel drivers and first-class support for Mesa for
userspace, I am green with envy (ha!)

> I've just asked though if the version lock between the NVIDIA kernel
> modules and user-space components really needs to be so strict. Let's
> see
> how that goes...

It would be good to know, but we'd need strong guarantees - otherwise
it's nasty regressions waiting to happen, given the very minimal debug-
ability.

-- 
Kind regards,
Luca Boccassi

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

Bug#880675: (no subject)

[Sylvain Lesage]

HI,

thanks for your answer, I will collect references in order to fill the
ticket in CLDR.

Bug#893418: Corrupted package names in by_vote.gz

[Bill Allombert]

On Sun, Mar 18, 2018 at 07:17:17PM +0100, Enrico Zini wrote:
> Package: popularity-contest
> Version: 1.66
> Severity: normal
> 
> Hello,
> 
> thanks for maintaining popcon. This seems related to #833695:
> 
> $ curl -s https://popcon.debian.org/by_vote.gz | zgrep -e ' li[^b-z]'
> 53022 liana-zabbix   1 1 0 0 0 (Not in 
> sid)
> 95984 li 1 0 0 0 1 (Not in 
> sid)
> 95985 li-apt-source  2 0 0 0 2 (Not in 
> sid)
> 95986 li-duply-dhbackup  1 0 1 0 0 (Not in 
> sid)
> 95987 li01 0 0 0 1 (Not in 
> sid)
> 95988 li0SsjEPOPULARITY-CONTEST-01 0 0 0 1 (Not in 
> sid)
> 95989 li0Suiimanaenns5   1 0 0 0 1 (Not in 
> sid)
> 95991 li5yolibpolkit-qt5-1-1 1 0 0 0 1 (Not in 
> sid)
> 95992 li sid)
> 95993 liLES> sid)
> 95994 liLES>a.0  1 0 0 0 1 (Not in 
> sid)
> 95995 lia-plCki  1 0 0 0 1 (Not in 
> sid)
> 95996 liaaloader0d   1 0 0 0 1 (Not in 
> sid)



> Would it be possible to discard server-side any package whose name is
> not compliant with policy?

Possible, yes. However:

1) Name like li0SsjEPOPULARITY-CONTEST-0 is compliant with policy but is
certainly due to corruption.

2) Users might have packages with names that are not compliant with
policy and we should know about them.

So I do not think the server should do it blindly. It is probably better
to do it client-side.

On the other hand, I am all for avoiding corruption in the first place,
but with the level of traffic it is difficult.

In any case I have just removed a common cause of corruption
(unterminated reports).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

[Ian Jackson]

Philip Hands :
> You'll be pleased to note that the original bug in this case has now
> been closed as a result of a newly uploaded package version:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#101
> 
> Thanks to all involved for bringing this to a successful resolution,
> at which point the TC bug becomes moot, so I'm closing it now.

Oh, excellent.  Thanks in particular to Mathieu Trudel-Lapierre for
uploading the new upstream version (with the appropriate policy
patch).

Ian.

Bug#893656: transition: theano 0.9 -> 1.0 - please update lasagne

[Rebecca N. Palmer]

lasagne - 3 test failures; fixed upstream by 
https://github.com/Lasagne/Lasagne/pull/836
Latest upstream (37ca134; only packaging change was to drop 
remove-deprecated.patch) doesn't have these failures.  There is a 
warning that cuda_convnet is no longer available with Theano 1.0, but 
that has another dependency (pybuild2) that was never in Debian anyway.



pyopencl - FTBFS for unrelated reasons (#893050); the theano-using code appears 
to be build/test scripts (pyopencl/compyte/gen*, test*) we never actually run
Builds after applying the path in #893050; 7 tests fail or crash (in 
Python 2, 6 also in Python 3), but they do this with or without Theano.



sympy - build hangs at mkdir -p _build/logo (with mkdir using a full CPU 
core?!), probably unrelated as it also happens without *-theano installed
This hang is because faketime doesn't work well with cowbuilder --login, 
i.e. nothing to do with sympy itself.  Running the testsuite with new 
Theano succeeds.


Hence, it appears that updating lasagne is the only change required to 
work with Theano 1.0, but testing on CUDA-capable hardware would still 
be preferable.

Bug#893606: ntpsec: Please build with --enable-leap-smear

[Paride Legovini]

On 20/03/2018 20.50, Richard Laager wrote:
> On 03/20/2018 06:31 AM, Paride Legovini wrote:
>> Please build NTPsec with --enable-leap-smear, which allows compatibility
>> with the Google NTP servers [1]
> 
> I'm asking upstream for confirmation that this is compatible:
> https://lists.ntpsec.org/pipermail/devel/2018-March/006074.html
> 
> I'm concerned that NTPsec's behavior might be to smear over the interval
> _before_ the leap second, as opposed to _centered on_ the leap second
> (which is what Google does).
> 
> If you're just consuming time from Google's servers, you don't need leap
> smearing in your client ntpd. You just point it at smeared servers (and
> only smeared servers) and disable the leap file. Are you intending on
> running your own servers and then have clients sync from a mix of you
> and Google? Or are you intending on running your own servers and having
> clients sync from you only, but you want time consistent with Google and
> similar?

I intend to run my own stratum 1 servers and in the end I think I won't
do any smearing. If for some reason you prefer to leave the option
disabled feel free to close this bug report.

Paride

Bug#893829: linux-image-4.9.0-6-amd64: hv_netvsc stuk in loop if setting both channels and mtu

[Yorick de Wid]

Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

If both the MTU and channels are set using ethtool the Microsoft Hyper-V 
network drivers crashes.
The network driver gets stuck in a loop and causes one or more kernel threads 
to consume all
processing power. In turn, this sometimes triggers a CPU soft lockup. Microsoft 
already fixed
the issue and pushed the patch upstream. The patch has been tested and solves 
the issue for this
Debian and kernel version. The kernel module should be updated to include the 
patch.

Thanks,
Y.

-- Package-specific info:
** Version:
Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 
root=UUID=88905bff-0987-4bbb-8008-7559257d30db ro quiet

** Not tainted

** Kernel log:
[1.435836] input: Microsoft Vmbus HID-compliant Mouse as 
/devices/0006:045E:0621.0001/input/input0
[1.435891] hid 0006:045E:0621.0001: input:  HID v0.01 Mouse 
[Microsoft Vmbus HID-compliant Mouse] on 
[1.436768] SCSI subsystem initialized
[1.437787] hv_vmbus: registering driver hv_storvsc
[1.439078] hv_vmbus: registering driver hv_netvsc
[1.439763] scsi host0: storvsc_host_t
[1.441200] hv_netvsc: hv_netvsc channel opened successfully
[1.444720] scsi 0:0:0:0: Direct-Access Msft Virtual Disk 1.0  
PQ: 0 ANSI: 5
[1.448314] hv_netvsc 16e56bf6-b65b-4cf1-ab9b-7b633777ea52: Send section 
size: 6144, Section count:2560
[1.448900] hv_netvsc 16e56bf6-b65b-4cf1-ab9b-7b633777ea52: Device MAC 
00:15:5d:03:a9:2d link state up
[1.450100] hv_netvsc: hv_netvsc channel opened successfully
[1.456672] hv_netvsc b1f72f74-0803-431e-9888-903c8114fad3: Send section 
size: 6144, Section count:2560
[1.456792] hv_netvsc b1f72f74-0803-431e-9888-903c8114fad3: Device MAC 
00:15:5d:03:a9:2f link state down
[1.457487] hv_netvsc: hv_netvsc channel opened successfully
[1.460473] scsi 0:0:0:1: CD-ROMMsft Virtual DVD-ROM  1.0  
PQ: 0 ANSI: 0
[1.463332] hv_netvsc ddf31567-ff1d-4c49-9154-fa861273de9a: Send section 
size: 6144, Section count:2560
[1.463512] hv_netvsc ddf31567-ff1d-4c49-9154-fa861273de9a: Device MAC 
00:15:5d:03:a9:30 link state up
[1.479138] sr 0:0:0:1: [sr0] scsi-1 drive
[1.479138] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.479264] sr 0:0:0:1: Attached scsi CD-ROM sr0
[1.480155] sd 0:0:0:0: [sda] 266338304 512-byte logical blocks: (136 GB/127 
GiB)
[1.480157] sd 0:0:0:0: [sda] 4096-byte physical blocks
[1.481055] sd 0:0:0:0: [sda] Write Protect is off
[1.481057] sd 0:0:0:0: [sda] Mode Sense: 0f 00 00 00
[1.481267] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.492431]  sda: sda1 sda2 sda3
[1.493562] sd 0:0:0:0: [sda] Attached SCSI disk
[1.518009] random: fast init done
[1.558079] PM: Starting manual resume from disk
[1.558081] PM: Hibernation image partition 8:3 present
[1.558082] PM: Looking for hibernation image.
[1.558586] PM: Image not found (code -22)
[1.558587] PM: Hibernation image not present or could not be loaded.
[2.026673] EXT4-fs: Warning: mounting with data=journal disables delayed 
allocation and O_DIRECT support!
[2.036601] EXT4-fs (sda2): mounted filesystem with journalled data mode. 
Opts: (null)
[2.222932] ip_tables: (C) 2000-2006 Netfilter Core Team
[2.269485] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[2.269528] systemd[1]: Detected virtualization microsoft.
[2.269531] systemd[1]: Detected architecture x86-64.
[2.271095] systemd[1]: Set hostname to .
[2.574704] systemd[1]: Listening on udev Control Socket.
[2.574784] systemd[1]: Listening on Journal Audit Socket.
[2.574816] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[2.574847] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[2.574865] systemd[1]: Listening on udev Kernel Socket.
[2.574889] systemd[1]: Listening on Journal Socket (/dev/log).
[2.700162] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[2.746669] systemd-journald[221]: Received request to flush runtime journal 
from PID 1
[2.918130] input: PC Speaker as /devices/platform/pcspkr/input/input1
[2.919047] EFI Variables Facility v0.08 2004-May-17
[2.923692] pstore: using zlib compression
[2.923695] pstore: Registered efi as persistent store backend
[2.926211] hv_utils: Registering HyperV Utility Driver
[2.926212] hv_vmbus: registering driver hv_util
[2.927993] hv_utils: Using TimeSync version 4.0
[2.932101] hv_vmbus: registering driver hyperv_keyboard
[

Bug#893673: Pending fixes for bugs in the clirr package

[pkg-java-maintainers]

tag 893673 + pending
thanks

Some bugs in the clirr package are closed in revision
3ed710029160b04f1e34b9ff1e49ff9a72841641 in branch 'master' by
Emmanuel Bourg

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

Commit message:

Restored the wrapper script (Closes: #893673)

Bug#883286: Please ship a python3-gps package

[Paride Legovini]

On 21/03/2018 21.19, Bernd Zeimetz wrote:
> Hi,
> 
> 
> On 03/20/2018 12:05 PM, Paride Legovini wrote:
>> On Fri, 1 Dec 2017 13:03:05 -0600 Richard Laager  wrote:
>>> Please consider shipping a python3-gps package, either in addition to or
>>> instead of python-gps. I don't know how much work that will be, so I
>>> understand that it might be a while.
>>
>> The Python code in gpsd is compatible with both Python2 and Python3,
>> as stated in the header of the Python files:
>>
>> # This code runs compatibly under Python 2 and 3.x for x >= 2.
>>
>> I believe a python3-gps package will be almost identical to python-gps.
> 
> thats all true, but the SConstruct file in 3.17 just does not work with
> python3. I could create a hand hacked package, but I'm not keen on doing
> that.

Have a look at this commit:

http://deb.li/3KWUA

If patching it is this simple, then I think it's worth doing so.

Paride

Bug#893801: libicu60: Please consider splitting out layout engine shared library

[Dimitri John Ledkov]

Sorry I made a mistake, this is a corrected debdiff, that correctly
specifies Breaks for openttd on the libicu60 package.

On 22 March 2018 at 14:57, Dimitri John Ledkov  wrote:
> Package: libicu60
> Version: 60.2-3ubuntu1
> Severity: normal
> Tags: patch
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Dear Maintainer,
>
> Normally, libicu60 ships all the related icu shared libraries which
> are quite closely inter dependant. Together, they are quite minimal in
> their dependencies, and may packages use them.
>
> However, libiculx.so.60, is not. It alone depends on libicu-le-hb0 ->
> libharfbuzz0b, libfreetype6, libglib2.0-0, libgraphite2-3 which is not
> that minimal anymore.
>
> Furthermore libicu-le-hb0 has circular dependency back onto libicu60,
> which is suboptimal from bootstrapping / cross-building point of view.
>
> Please consider splitting libiculx.so.60 out of the libicu60 package,
> into a standalone one.
>
> I believe the attached patch should do it.
>
> On Ubuntu, I am considering uploading such a package split, as it
> would ensure that minimal Ubuntu chroots can be quite a bit smaller.
>
> Regards,
>
> Dimitri.
>
> -BEGIN PGP SIGNATURE-
>
> iQFEBAEBCgAuFiEEdzyZ69ChEXIhenw/ysLYuc0spfkFAlqzxFIQHHhub3hAdWJ1
> bnR1LmNvbQAKCRDKwti5zSyl+QOSB/0Qhy0WxW/FiFHGCVYWGvX56UCnGz+z04qP
> AaCpDBNmA9jLRlWELNzUsBqLcz6XLrqMUs0Ujjijv6zbMETkGTdgUsQMVJ1tEeyN
> lMTQmSBZiIfZZqRYqhCmnFOO0Pc2HTEw3I9Tfmvggo8PJ5GEi6LKRyn5VSGgCH9N
> 8LLhBJdKNt/ALCGLiLPgHZA2dIeBAl4FMwyY9KA8FTNPxXxi65/CA1F03u0wuR71
> QjW5n/JP1WnoBdeIh/0GcGw7YbjAad/EsWUC6NdmUO6WukhJC2TDgUajXehLygtK
> 4jl5EODmWOXZfAIPfLliwO45YFGMPV7M3077SQjLabF1tfCmbCxy
> =MCFq
> -END PGP SIGNATURE-



-- 
Regards,

Dimitri.


corrected-iculx-split.debdiff
Description: Binary data

Bug#825488: ci.debian.net: Please run tests for contrib packages too

[Paul Gevers]

On Wed, 21 Sep 2016 16:33:07 +0200 Petter Reinholdtsen 
wrote:
> [Antonio Terceiro 2016-07-07]
> > debci needs code changes to make the automatically generated testbeds
> > actually include contrib in sources.list. I have the beginnings of
> > that stashed locally, but it's not ready yet. If you want to work on
> > it I can send you the current patch.
> 
> Did you get any further?  As I mentioned earlier, I would love to see
> the current draft.

Using the new and fresh API¹, I requested a DD key and submitted
zfs-linux for testing. The results are available², it fails.

So, albeit not automatically in the ci.d.n framework yet, you as a DD
can at least trigger the tests (e.g. after uploading).

Paul

¹ https://ci.debian.net/doc/file.API.html
² https://ci.debian.net/packages/z/zfs-linux/unstable/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#893828: nmu: unintended ruby dependencies

[Sven Joachim]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Some packages built from the libprelude and redland-bindings sources
have gained spurious dependencies on ruby due to #892131.  They should
be rebuilt with gem2deb 0.38.1, which on some architectures is not yet
available.


nmu libprelude_4.1.0-4 . ANY . unstable . -m "Rebuild with fixed gem2deb (see 
#892131)."
dw libprelude_4.1.0-4 . ANY . -m 'gem2deb (>= 0.38.1)'

nmu redland-bindings_1.0.17.1+dfsg-1.3 . ANY -alpha -hppa -hurd-i386 
-kfreebsd-amd64 -kfreebsd-i386 -mipsel -powerpcspe . unstable . -m "Rebuild 
with fixed gem2deb (see #892131)."
dw redland-bindings_1.0.17.1+dfsg-1.3 . ANY . -m 'gem2deb (>= 0.38.1)'

Bug#875914: autopkgtest: support Conflicts: in debian/tests/control

[Martin Pitt]

Hello Paul,

Paul Gevers [2018-03-22 21:42 +0100]:
> Others may have more knowledge on this, but I don't think autopkgtest
> has the knowledge of the installed packages in the testbed. At least I
> think not until it actually starts up the testbed and asks.

Right, it does that. But that already happens anyway when it installs the test
dependencies, so in principle it could also call apt-get purge on the test
conflicts afterwards. It's just riddled with a number of potential traps (see
my other reply).

> And when autopkgtest is there, you can as well do that yourself, and even try
> to remove the conflicting package if you know what you are doing. (Add a
> breaks-testbed restriction)!

This is true, the test can of course do all these checks and apt invocations,
and decide by itself what to do when a conflicted package is installed (like,
skip the test, skip part of it, remove it).
So this at least should not be a blocker for anyone, just maybe less
convenient than the declaration.

Martin


signature.asc
Description: PGP signature

Bug#880675: Patch

[Aurelien Jarno]

Hi,

On 2018-03-22 12:43, Sylvain Lesage wrote:
> tag 880675 patch
> 
> Hello,
> 
> here is a better patch, kindly proposed by Niv.
> 
> ---
> commit 16820f7f107201a31f7bdb957b86d7fadf8c2f29 (HEAD -> sid)
> Author: Niv Sardi 
> Date:   Thu Mar 22 12:22:05 2018 -0300
> 
> change LC_PAPER to en_US in es_BO local
> 
> i18n defaults to A4 paper, that class of paper is imposible to find
> in Bolivia,
> the de-facto standard is 'letter' or en_US 279x216
> 

Unfortunately this doesn't match the CLDR database, which clearly says
that Bolivia uses A4 [1]. The CLDR database is now used as a reference
by upstream, to avoid conflicting reports. Could you please try to
report an issue against CLDR (see the bug button on the page)? If the
change is accepted, we'll add the patch on the Debian side.

Aurelien

[1] https://unicode.org/cldr/charts/dev/supplemental/territory_information.html

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

Bug#875914: autopkgtest: support Conflicts: in debian/tests/control

[Martin Pitt]

Hello Daniel,

Daniel Kahn Gillmor [2018-03-21 10:12 +]:
> afaict, the autopkgtest spec doesn't say that all
> implementations/backends will start from a minimal environment.

This is by intent, as it should not conceptually be limited to the
standardized minimal testbeds, for several reasons:

 * It's reasonable to run an autotest (manually) on an existing machine, even a
   full desktop. Both the null and the ssh runner support this well.

 * It not all that easy to define what "minimal" precisely is. E. g. just
   "Priority: required" (more or less debootstrap) works for a schroot, but is
   usually not enough for a container and by far not enough for a VM.

 * Often really minimal testbeds are also impractical. E. g. cloud images (or
   Ubuntu's official LXC images even) often carry a lot of packages that are
   undesirable for an official CI system (as they are too big), but are
   nevertheless practical for developer usage as they are readily and easily
   available.

> does this help explain why an explicit conflicts would be useful in
> avoiding false negatives?

I do agree that this is legitimate in some corner cases. The actual need just
didn't occur very often so far, so it hasn't been a priority to actually
implement this. Furthermore this isn't actually that simple: If autopkgtest
detects that a conflicted package is installed, it certainly shouldn't just
fail or skip the test, as that would be rather pointless. It needs to actually
try and remove the packages; but this has significantly harder corner cases
than installing new packages; for example:

 - What if another package depends on the conflicted package, but has other
   alternatives? How do you pick a different one? Or should you remove that 
package as well?

 - What happens if you conflict to an essential/required package? (I think in
   this case the test should actually fail as "invalid test").

 - What happens if you conflict to a non-required package which is nevertheless
   required for your test environment? (e. g. your network driver or
   network-manager or openssh-server)

A naïve implementation coudl just leave all these questions to "apt purge -y",
and fail the test if that fails. Maybe this is even good enough for the use
cases that you have in mind?

For these reasons autopkgtest has never uninstalled packages so far, but
provides a new testbed if a subsequent test has fewer test dependencies than
its predecessor. Again, I'm not saying that it's impossible or undesirable,
just that there are quite a number of traps.

Thanks,

Martin


signature.asc
Description: PGP signature

Bug#893517: Installation of gcc-8 made clang-6 unusable.

[Roman Lebedev]

reassign 893517 gcc-8
found 893517 8-20180319-1
forwarded 893517 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040
forwarded 893517 https://bugs.llvm.org/show_bug.cgi?id=36869
notfound clang-6.0 1:6.0-1
thanks.

On Mon, Mar 19, 2018 at 7:30 PM, Roman Lebedev  wrote:
> Package: clang-6.0
> Version: 1:6.0-1
> Severity: serious
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> $ cat test.cpp
> #include 
> $ clang++-6.0 -c test.cpp
> In file included from test.cpp:1:
> In file included from 
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/ostream:38:
> In file included from 
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/ios:42:
> In file included from 
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/ios_base.h:41:
> In file included from 
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/locale_classes.h:40:
> In file included from 
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/string:48:
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:545:9:
>  error: redefinition of '__not_overloaded<_Tp, _Up>'
> struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
>^~
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:531:9:
>  note: previous definition is here
> struct __not_overloaded<_Tp, _Up, __void_t<
>^
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:608:9:
>  error: redefinition of '__not_overloaded<_Tp, _Up>'
> struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
>^~
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:594:9:
>  note: previous definition is here
> struct __not_overloaded<_Tp, _Up, __void_t<
>^
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:671:9:
>  error: redefinition of '__not_overloaded<_Tp, _Up>'
> struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
>^~
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:657:9:
>  note: previous definition is here
> struct __not_overloaded<_Tp, _Up, __void_t<
>^
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:734:9:
>  error: redefinition of '__not_overloaded<_Tp, _Up>'
> struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
>^~
> /usr/bin/../lib64/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:720:9:
>  note: previous definition is here
> struct __not_overloaded<_Tp, _Up, __void_t<
>^
> 4 errors generated.
>
>
> Strangely, clang-5 still works.
> But clang-7 fails too.
>
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages clang-6.0 depends on:
> ii  binutils 2.30-8
> ii  libc62.27-2
> ii  libc6-dev2.27-2
> ii  libclang-common-6.0-dev  1:6.0-1
> ii  libclang1-6.01:6.0-1
> ii  libgcc-7-dev 7.3.0-12
> ii  libgcc1  1:8-20180319-1
> ii  libjsoncpp1  1.7.4-3
> ii  libllvm6.0   1:6.0-1
> ii  libobjc-7-dev7.3.0-12
> ii  libstdc++-7-dev  7.3.0-12
> ii  libstdc++6   8-20180319-1
>
> Versions of packages clang-6.0 recommends:
> ii  libomp-dev6.0-1
> ii  llvm-6.0-dev  1:6.0-1
> ii  python2.7.14-4
>
> Versions of packages clang-6.0 suggests:
> pn  clang-6.0-doc  
> pn  gnustep
> pn  gnustep-devel  
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAlqv5aYACgkQCDw+u0oW
> ieABKxAAhombUUuICiB93PXBM8fZpsDyFrpMbFpd8JHCuNkRSXs9oNgRoLogWEMF
> j+f+VDk8QYQt35C4rxCdVDqdm/4JYeV9wKlW0dIlmmPzQgPn819QwA5Y44qh492n
> 576n5GSFf/6UpoDLGbKaEqa3ayPCmMKRh2cMrW2939BV823enc/AMA3x7UU4Nzcp
> zivn/oJfbvs5pQYOzg/IikUEiB4cxpajFtQ88V3W56mVe66Go+/GZkJwLpl8ZbYk
> JOYyICIKXES1dNfCvHZv5v2ZADDDsQ/l+iR8paDZ4NVbaL7QANGttHtHv8uXa2NU
> YkG2WZ5I2zw0sgmNxINJk5OuNb4I2m7MiYoZqfU4nSZ9FTnv8MFD6KhGLF4PmBYf
> cc6LJY7GBkhMb8xU9UrUHHl8y2Q3H6vcbJPMYK3JcntLzfGVPmjlXrk2w8WWodR1
> 

Bug#893827: ITP: bioSyntax -- Syntax highlighting for computational biology

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

Package name: biosyntax
URL: https://biosyntax.org/
License: GPL-3
Description: Syntax Highlighting for Computational Biology (gedit)
 Syntax highlighting for computational biology to bring you intuitively close
 to your data. BioSyntax supports .sam, .flagstat, .vcf, .fasta, .fastq, .faidx
 , .clustal, .pdb, .gtf, .bed files & more.

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/biosyntax.git/

Bug#893825: reportbug --mh does not work with mmh

[Sandro Tosi]

thanks; you attached a patch, which seems more targetting dput-ng -
did you prepare a patch for this bug too and you attached the wrong
file?

Bug#893826: mirror submission for mirror.larbob.org

[Larkin Nickle]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.larbob.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Larkin Nickle 
Country: US United States
Location: United States
Comment: Can use https or http (neither is forced, https secured w/ 
letsencrypt), syncs hourly with ftpsync-cron




Trace Url: http://mirror.larbob.org/debian/project/trace/
Trace Url: http://mirror.larbob.org/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.larbob.org/debian/project/trace/mirror.larbob.org

Bug#893825: reportbug --mh does not work with mmh

[KAction]

Package: reportbug
Version: 7.1.10
Severity: normal

reportbug(1) assumes, that /usr/bin/mh/comp supports -file option, which
comp(1mh) from bin:mmh does not.

Please consider using -form option instead {is it supported by nmh} or
manually creating message at $(mhpath +drafts b) and calling $EDITOR.
>From c097349b42099784319f3f7a3836ad7de74a0d83 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 22 Mar 2018 23:06:49 +0300
Subject: [PATCH] Make bin:dput-ng recommend py3 version of paramiko

Since dput-ng is written in Python3, there is no use from extra Python2
library. python3-paramiko is needed for `scp` method, which, although
considered deprecated by dput-ng, is recommended by
debomatic-*.debian.net services.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 55d3455..bf38540 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,7 @@ Depends:
  ${python3:Depends},
 Recommends:
  bash-completion,
- python-paramiko,
+ python3-paramiko,
 Description: next generation Debian package upload tool
  dput-ng is a Debian package upload tool which provides an easy to use
  interface to Debian (like) package archive hosting facilities. It allows

Bug#875914: autopkgtest: support Conflicts: in debian/tests/control

[Paul Gevers]

Control: tags -1 -moreinfo

Hi Daniel,

On 21-03-18 11:12, Daniel Kahn Gillmor wrote:
> afaict, the autopkgtest spec doesn't say that all
> implementations/backends will start from a minimal environment.  And
> some users want to run autopkgtest locally in some schroot that might
> have other packages already installed.

Ack.

> furthermore, there are some "minimal environments" (e.g. "standard
> install") which contain packages that might be conflict with some
> obscure tests (e.g. a network management daemon with a normal use case
> that needs testing that doesn't work when ifupdown is present).
> 
> does this help explain why an explicit conflicts would be useful in
> avoiding false negatives?

Others may have more knowledge on this, but I don't think autopkgtest
has the knowledge of the installed packages in the testbed. At least I
think not until it actually starts up the testbed and asks. And when
autopkgtest is there, you can as well do that yourself, and even try to
remove the conflicting package if you know what you are doing. (Add a
breaks-testbed restriction)!

So if my statement is true and autokpgtest needs to interrogate the
testbed, than I don't think this feature will come any time soon.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893824: dput-ng: bin:dput-ng recommends python-paramiko

[KAction]

Package: dput-ng
Version: 1.18
Severity: normal

Should be python3-paramiko instead. Patch attached.
>From c097349b42099784319f3f7a3836ad7de74a0d83 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 22 Mar 2018 23:06:49 +0300
Subject: [PATCH] Make bin:dput-ng recommend py3 version of paramiko

Since dput-ng is written in Python3, there is no use from extra Python2
library. python3-paramiko is needed for `scp` method, which, although
considered deprecated by dput-ng, is recommended by
debomatic-*.debian.net services.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 55d3455..bf38540 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,7 @@ Depends:
  ${python3:Depends},
 Recommends:
  bash-completion,
- python-paramiko,
+ python3-paramiko,
 Description: next generation Debian package upload tool
  dput-ng is a Debian package upload tool which provides an easy to use
  interface to Debian (like) package archive hosting facilities. It allows

Bug#893823: ruby-minitest-shared-description FTBFS with Ruby 2.5

[Adrian Bunk]

Source: ruby-minitest-shared-description
Version: 1.0.0-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-minitest-shared-description.html

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

RUBYLIB=/build/1st/ruby-minitest-shared-description-1.0.0/debian/ruby-minitest-shared-description/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-minitest-shared-description/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 debian/ruby-tests.rb
/usr/bin/ruby2.5 -I lib -rubygems ./spec/minitest-shared_description_spec.rb
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
rake aborted!
Command failed with status (1): [/usr/bin/ruby2.5 -I lib -rubygems ./spec/m...]
/build/1st/ruby-minitest-shared-description-1.0.0/Rakefile:15:in `block in '
Tasks: TOP => spec
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-minitest-shared-description-1.0.0/debian/ruby-minitest-shared-description
 returned exit code 1
make: *** [debian/rules:6: binary] Error 1

Bug#893821: ruby-shindo FTBFS with Ruby 2.5

[Adrian Bunk]

Source: ruby-shindo
Version: 0.3.8-1
Severity: serious
Tags: buster sid

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

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

RUBYLIB=/build/1st/ruby-shindo-0.3.8/debian/ruby-shindo/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-shindo/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 debian/ruby-tests.rb
  
  Shindo build errors (build_error)
another + returns true
  
  tag
negative -negative
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "+ is tested"
expected "" to include "+ is tested"
  - includes "skipped (negative)"
expected "" to include "skipped (negative)"
  $?.exitstatus - returns 0
expected => 0
returned => 1
positive +positive
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "+ is tested"
expected "" to include "+ is tested"
  - includes "skipped"
expected "" to include "skipped"
  $?.exitstatus - returns 0
expected => 0
returned => 1
  
  basics
+ returns false
+ raises StandardError
+ returns true
  
  bin
exception
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "- exception"
expected "" to include "- exception"
  $?.exitstatus + returns 1
failure
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "- failure"
expected "" to include "- failure"
  $?.exitstatus + returns 1
pending
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "# test implicit pending"
expected "" to include "# test implicit pending"
  - includes "# test explicit pending"
expected "" to include "# test explicit pending"
  - includes "# tests explicit pending"
expected "" to include "# tests explicit pending"
  $?.exitstatus - returns 0
expected => 0
returned => 1
success
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
  - includes "+ success"
expected "" to include "+ success"
  - includes "inline tests"
expected "" to include "inline tests"
  - includes "+ returns false"
expected "" to include "+ returns false"
  $?.exitstatus - returns 0
expected => 0
returned => 1
  
  16 failed, 6 succeeded in 20.775533539 seconds
  
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-shindo-0.3.8/debian/ruby-shindo returned exit code 1
make: *** [debian/rules:17: binary] Error 1

Bug#893822: ruby-pygments.rb FTBFS with Ruby 2.5

[Adrian Bunk]

Source: ruby-pygments.rb
Version: 1.2.0-1
Severity: serious

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

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

RUBYLIB=/build/1st/ruby-pygments.rb-1.2.0/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-pygments.rb/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 debian/ruby-tests.rb
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- ubygems (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
rake aborted!
Command failed with status (1)

Tasks: TOP => default => test
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-pygments.rb-1.2.0/debian/ruby-pygments.rb returned exit code 1
make[1]: *** [debian/rules:18: override_dh_auto_install] Error 1

Bug#893376: Pending fixes for bugs in the mina package

[pkg-java-maintainers]

tag 893376 + pending
thanks

Some bugs in the mina package are closed in revision
ae0124b2ab38894ac268213688a6e1f2dab1cec7 in branch 'master' by
Emmanuel Bourg

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

Commit message:

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

Bug#889732: libconfig-model-dpkg-perl: Does not recognize Salsa platform in Vcs field

[Andreas Tille]

I forgot

   if: $maintainer =~ /debian-science-maintainers@/
   then: https://salsa.debian.org/science-team/$pkgname.git

That is true for a large majority of Debian Science packages and will
fail for a few packages in fenics (and may be two or three other
subdirs).  I have no idea whether we need to care for those and as
far as I checked some examples these are converted anyway like

  Vcs-Git: https://salsa.debian.org/science-team/fenics/ufl.git
  Vcs-Browser: https://salsa.debian.org/science-team/fenics/ufl

Kind regards

Andreas.

On Thu, Mar 22, 2018 at 05:04:06PM +0100, Andreas Tille wrote:
> Hi Gregor,
> 
> On Thu, Mar 22, 2018 at 04:37:02PM +0100, gregor herrmann wrote:
> > > Currently we have for Vcs-Git:
> > > 
> > >   'formula' => '  $maintainer =~ /pkg-perl/   
> > >  ? "https://salsa.debian.org/perl-team/modules/packages/$pkgname.git;
> > > : $maintainer =~ /pkg-ruby-extras/ ? 
> > > "https://salsa.debian.org/ruby-team/$pkgname.git;
> > > : $maintainer =~ /pkg-javascript/ ? 
> > > "https://salsa.debian.org/js-team/$pkgname.git;
> > > :\'\' ;',
> > > 
> > > (And the same for Vcs-Browser minus the trailing .git)
> > > 
> > > So for the med-team and the r-pkg-team we would need a string for the
> > > maintainer address, and the base git URL at salsa.
> > 
> > This part is still open, and I'm happy to add the missing runes for
> > med-team and r-pkg-team; I just need confirmation for the values.
> > 
> > I took a quick look today:
> > 
> > For debian med this looks pretty straight-forward:
> > if: $maintainer =~ /debian-med-packaging/
> > then: https://salsa.debian.org/med-team/$pkgname.git
> > 
> > Correct?
> 
> I'm afraid there are two or three exceptions but most probably we need
> to fix these exceptions manually since these are rather considered as
> bugs in our VCS repositories.  So yes, that's correct. 
>  
> > For the R team I'm not so sure. I looked at some packages, and 7 or 8
> > of 10 had
> > $maintainer =~ debian-science-maintainers
> > but I've also seen other values in Maintainers.
> > Is there some unique value in debian/source to filter on?
> > 
> > The URLs seem to be https://salsa.debian.org/r-pkg-team/$pkgname.git
> 
> I think you could filter for
> 
>( $pkgname =~ /^r-cran-.*/ || $pkgname =~ /^r-bioc-.*/ ) && Vcs-fields 
> "exists"
> 
> I'm not sure about the latter.  Dirk Eddelbüttel does not maintain his
> packages in Vcs and I do not know his plans to do so.  It might be
> irrelevant since I doubt he is using cme.  I'm CCing debian-r list for
> review - may be Dirk can pronounce whether he considers it helpful if
> cme would insert Vcs fields also for his packages.  This would simplify
> migrating his packages easily to Salsa by using cme in case he might
> decide to do this.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#893820: ITP: golang-github-patrickmn-go-cache -- in-memory key:value store/cache (similar to Memcached)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-patrickmn-go-cache
  Version : 2.1.0-1
  Upstream Author : Patrick Mylund Nielsen
* URL : https://github.com/patrickmn/go-cache
* License : Expat
  Programming Lang: Go
  Description : in-memory key:value store/cache (similar to Memcached)

 go-cache is an in-memory key:value store/cache similar
 to memcached that is suitable for applications running on a single
 machine. Its major advantage is that, being essentially a thread-safe
 map[string]interface{} with expiration times, it doesn't need to serialize
 or transmit its contents over the network.


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#893379: Pending fixes for bugs in the naga package

[pkg-java-maintainers]

tag 893379 + pending
thanks

Some bugs in the naga package are closed in revision
f9ca1b802717209878c888a59ec71c10d925b020 in branch 'master' by
Emmanuel Bourg

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

Commit message:

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

Bug#893819: systemd-shim: logind does not create a session, because systemd-shim does not create /init.scope like systemd does

[Tobias Hoffmann]

Package: systemd-shim
Version: 10-3
Severity: important

Preface:
Some software begins to depends on an existing logind-session.
These sessions are created + tracked via libpam-systemd, which makes
an dbus call to systemd-logind.

systemd-shim it here to support logind, which replaces consolekit
(AFAIUI) on systems where systemd is not the init process (i.e. pid 1).

Problem:
In auth.log:
  login[6880]: pam_systemd(login:session): Failed to create session: No such 
device or address

The message belongs to -ENXIO, which is emitted here:
  https://github.com/systemd/systemd/blob/master/src/basic/cgroup-util.c#L1458

Result:
$ loginctl
   SESSIONUID USER SEAT TTY

   0 sessions listed.

Expected result:
$ loginctl
  [... some sessions ...]

Root cause:
$ systemd-cgls
Control group /:
-.slice
├─   1 init [2]
├─1630 /lib/systemd/systemd-udevd --daemon
├─3661 /sbin/rpcbind -w
[...]

$ cat /proc/1/cgroup# or some other pid
4:name=systemd:/
[...]

But since systemd 226 (AFAICT), all pids are moved (by systemd as init)
into the /init.scope cgroup.
In the systemd-shim case, systemd-logind still expects pid 1 and the pid
of the login process to be in a such named cgroup - but fails, because
everything is in the root slice (-.slice) and "nothing comes after the /".

Evidence:
$ mkdir /sys/fs/cgroup/systemd/init.scope
$ echo 1 > /sys/fs/cgroup/systemd/init.scope/tasks
  # ... move login process (kdm/mingetty/...) there, too ...
  # e.g. by respawning mingetty on a particular tty, e.g. tty4
$ systemd-cgls  # or: cat  /proc/$PID/cgroup
  [... those two processes are indeed now in the new cgroup ...]

Now login on that tty4, so that the login process is
(resp. will be spawned in) the /init.scope cgroup.

$ loginctl
   [...]
   1 sessions listed.

Required action:
systemd-shim has to adjust the cgroups (using cgmanager?) accordingly
for systemd-logind (and thus pam-logind) to succeed.

Thank you.


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

Kernel: Linux 4.16.0-rc6 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd-shim depends on:
ii  cgmanager 0.41-2
ii  libc6 2.27-2
ii  libglib2.0-0  2.53.4-3

systemd-shim recommends no packages.

Versions of packages systemd-shim suggests:
ii  pm-utils  1.4.1-9

-- no debconf information

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Felix Natter]

Markus Koschany  writes:

> Package: freeplane
> X-Debbugs-CC: t...@security.debian.org
> X-Debbugs-CC: fnat...@gmx.net
> Severity: important
> Tags: security
>
> Hi,

hello Markus,

> the following vulnerability was published for freeplane. Apparently only
> stretch/jessie/wheezy might be affected.

Thank you for paying attention to this, I completely overlooked this!

> @Felix
> Can you tell us more about this vulnerability? There only seems to be a
> reference in freeplane's wiki.

I think it is very well explained here:
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

In short: External identities are "includes" for XML documents that can
be specified in DTDs.

Here is the commit that should fix it:
https://github.com/freeplane/freeplane/commit/a5dce7f9f

> https://www.freeplane.org/wiki/index.php/XML_External_Entity_vulnerability_in_map_parser
>
> CVE-2018-169[0]:
> | FreePlane version 1.5.9 and earlier contains a XML External Entity
> | (XXE) vulnerability in XML Parser in mindmap loader that can result in
> | stealing data from victim's machine. This attack appears to require
> | the vicim to open a specially crafted mind map file. This
> | vulnerability appears to have been fixed in 1.6+.
>
> 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-169
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-169
>
> Please adjust the affected versions in the BTS as needed.

I can confirm that the the fix is in 1.5.20 and 1.6.1, so it's true that
wheezy, jessie and stretch are affected.

Shall I add the patch in git branches from the debian/X tags here?
https://anonscm.debian.org/cgit/pkg-java/freeplane.git
Or did you want to do this, Markus?

I will read more about security updates on the weekend.

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#752467: python-virtualenv: no command "virtualenv"

[Marvin Renich]

* Simon McVittie  [180322 13:21]:
> [Please try to use a Subject line that will remind other developers which
> bug you're talking about when mails from it are seen out of context. I've
> retrieved the title from the original bug report.]

Oops, sorry!  I did see this and intended to fix it, but forgot.

> On Thu, 22 Mar 2018 at 12:41:33 -0400, Marvin Renich wrote:
> > I just ran into this issue.  I am installing OctoPrint from source on a
> > BeagleBone Black, and OctoPrint uses python2, and I would rather not
> > install python3 if I can avoid it.
> 
> Python 2 is no longer security-supported after 2020 (and that's about
> halfway through the expected support lifetime of buster), so in the
> buster timescale, Python 3 should really be preferred.

I agree.

> In a space-constrained environment, you can install python-virtualenv
> and run "python -m virtualenv ARGS" as a substitute for "virtualenv ARGS".
> Does that help?

Well, yes, except for lack of documentation.  Being an experienced
programmer, but relatively new to Python, I did not think of (and would
not have thought of) this until after downloading the virtualenv_*.deb
file and dissecting it.  Once I had done that, several one-time
solutions were evident.

In fact, I believe that even if I were an experienced Python programmer,
I would need to look at /usr/bin/virtualenv to know that is it simply a
cover for invoking the module with arguments.

> > My (strong) opinion is that the correct solution should involve a single
> > /usr/bin/virtualenv command that works correctly with both python2 and
> > python3.
> 
> For commands where the user neither knows nor cares how the command
> is implemented because it doesn't matter, like the tappy command from
> src:tap.py, having a single command is absolutely fine.
> 
> For commands where the version of Python used for the implementation
> matters, like python[3]-coverage and pyflakes[3], I'm not so sure about
> this reasoning.

Sure.

> virtualenv is somewhere between those extremes, because
> it has a -p/--python option, but the default if that option is not given
> is to use the same Python version used for virtualenv itself.
> 
> If I understand correctly, the script that you assert should exist
> has these semantics when run without the -p/--python option:
> 
> * Please set up a virtual environment to run Python code
> * After running this command, the virtual environment will be suitable
>   for running either Python 2 code or Python 3 code but probably not
>   both, and I can't know which
> 
> which don't seem amazingly useful? It would seem better for there to be
> a predictable default, so that at least within Debian, virtualenv does
> something consistent; and Python 2 is going to reach the end of its
> security support before buster does, so for buster, that default should
> probably be Python 3.

Okay, I see your point.  However this only makes a difference if you
have both versions of Python installed.  It is more like:

* Please set up a virtual environment to run Python code
* If only one version of Python is installed, use that.
* If more than one version is installed, in the absence of a
  command-line option to indicate otherwise (-p in this case),
  always use the preferred version (python3).

This seems perfectly useful and useable to me.

In fact, the current situation, where virtualenv depends on, and only
uses, the python3 module, is broken.  If my apt configuration installed
recommeds by default, installing python-virtualenv would have installed
python3 and python3-virtualenv.  virtualenv would have then set up a
python3 environment for OctoPrint (without me realizing it), and
OctoPrint would be broken and I would have had a much harder time
figuring out what was wrong.

The current Python naming convention, IIUC, is to use python for the
python2 interpreter, python3 for the python3 interpreter, and use
python-* and python3-* for package names for modules for the respective
versions.  I see that the python[3]-coverage and pyflakes[3] packages
(according to the pkg description) include version-specific commands.
It seems to me that maybe the correct solution for virtualenv is to have
separate virtualenv and virtualenv3 packages for the respective
versions, or simply remove virtualenv as a separate package and have the
py[3]-virtenv packages provide differently-named virtualenv commands.

The more I think about it, the more I like the latter solution.  What
was the reasoning for splitting the command into its own package?  With
the pyflakes and py-coverage precedents, it doesn't seem like users
should expect virtualenv to create a python3 environment by default, but
might reasonably expect there to be a virtualenv3 command that does.

Is it planned to include python2 in buster, in spite of the impending
end of support?  Certainly, if buster will ship with python2, the
virtualenv and python[3]-virtualenv packages should work the way 

Bug#893818: ITP: golang-github-okzk-sdnotify -- systemd's service notification protocol (sd_notify)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-okzk-sdnotify
  Version : 0.0~git20160804.ed8ca10-1
  Upstream Author : okzk
* URL : https://github.com/okzk/sdnotify
* License : Expat
  Programming Lang: Go
  Description : systemd's service notification protocol (sd_notify)

 Go implementation of systemd's service notification protocol
 (sd_notify)


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#893817: salt-minion does not start: AttributeError: type object 'IOLoop' has no attribute 'initialized'

[Thomas Bechtold]

Package: salt-minion
Version: 2017.7.4+dfsg1-1
Severity: important

Dear Maintainer,

I tried to (re)start salt-minion and got:

● salt-minion.service - The Salt Minion
   Loaded: loaded (/lib/systemd/system/salt-minion.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Thu 2018-03-22 20:24:27 CET; 2min 
25s ago
 Docs: man:salt-minion(1)
   file:///usr/share/doc/salt/html/contents.html
   https://docs.saltstack.com/en/latest/contents.html
  Process: 2224 ExecStart=/usr/bin/salt-minion (code=exited, status=1/FAILURE)
 Main PID: 2224 (code=exited, status=1/FAILURE)

Mär 22 20:24:27 palme salt-minion[2224]: self.prepare()
Mär 22 20:24:27 palme salt-minion[2224]:   File 
"/usr/lib/python3/dist-packages/salt/cli/daemons.py", line 317, in prepare
Mär 22 20:24:27 palme salt-minion[2224]: self.minion = 
salt.minion.MinionManager(self.config)
Mär 22 20:24:27 palme salt-minion[2224]:   File 
"/usr/lib/python3/dist-packages/salt/minion.py", line 802, in __init__
Mär 22 20:24:27 palme salt-minion[2224]: zmq.eventloop.ioloop.install()
Mär 22 20:24:27 palme salt-minion[2224]:   File 
"/usr/lib/python3/dist-packages/zmq/eventloop/ioloop.py", line 210, in install
Mär 22 20:24:27 palme salt-minion[2224]: assert (not 
ioloop.IOLoop.initialized()) or \
Mär 22 20:24:27 palme salt-minion[2224]: AttributeError: type object 'IOLoop' 
has no attribute 'initialized'
Mär 22 20:24:27 palme systemd[1]: salt-minion.service: Main process exited, 
code=exited, status=1/FAILURE
Mär 22 20:24:27 palme systemd[1]: salt-minion.service: Failed with result 
'exit-code'.

Looks like this is a problem with python-tornado(I have python-tornado 5.0.0-1 
installed) and salt is incompatible with tornado-5.0[1].

[1] https://github.com/saltstack/salt/issues/46340


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

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

Versions of packages salt-minion depends on:
ii  bsdmainutils 11.1.2
ii  dctrl-tools  2.24-2+b1
ii  lsb-base 9.20170808
ii  python3  3.6.4-1
ii  python3-crypto   2.6.1-8
ii  python3-systemd  234-1
ii  python3-zmq  16.0.2-2+b1
ii  salt-common  2017.7.4+dfsg1-1

Versions of packages salt-minion recommends:
pn  debconf-utils  
ii  dmidecode  3.1-1
ii  e2fsprogs  1.44.0-1
pn  sfdisk 

Versions of packages salt-minion suggests:
pn  python3-augeas  

-- no debconf information

Bug#893816: debian-maintainers: Plasma problems after updating unstable branch

[Antti]

Package: debian-maintainers
Severity: normal

Dear Maintainer,

   * What led up to the situation?

apt-get update && apt-get upgrade or smth

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

Well, nothing, really. Xfce works, which is nice. Plasma does not work 
- complains about missing a theme at the login and Plasma is not even 
selectable atm. Oh, well...

-- System Information:
Debian Release: unstable
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#893125: RM: calligra -- ROM; manual decruft needed

[Pino Toscano]

reopen 893125
thanks

In data mercoledì 21 marzo 2018 18:35:41 CET, Scott Kitterman ha scritto:
> On Fri, 16 Mar 2018 18:15:40 +0100 Pino Toscano  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Hi,
> > 
> > please decruft the old sources and binaries of src:calligra, as they
> > do not seem to be cleaned automatically:
> > $ rmadison -s unstable calligra
> > calligra   | 1:2.9.11+dfsg1-1 | unstable   | source, all
> > calligra   | 1:3.0.1+dfsg-2   | unstable   | source, all
> > calligra   | 1:3.1.0+dfsg-2   | unstable   | source, all
> > 
> > It looks like this prevents calligra 1:3.1.0+dfsg-2 to migrate to
> > testing...
> 
> I've gone ahead and removed all the arch specific binaries that were holding 
> the older versions in the archive, so they should be automatically decrufted 
> now, but they were all on non-release archs, so I don't think that's your 
> problem.

Apparently not:

* source package calligra version 1:3.1.0+dfsg-2 no longer builds
  binary package(s): braindump
  on amd64,arm64,armel,armhf,i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x
  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by calligra)" -s unstable -a 
amd64,arm64,armel,armhf,i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x -p -R 
-b braindump
  - No dependency problem found

> I'm not an expert on reading britney output, but it looks to me like calligra 
> is likely entangled with the libpoppler transition and that's a better place 
> to look for the hold up.

Hm poppler migrated to testing 9 days ago, so I don't think that's the
actual issue; even reading the britney log, it refers to libpoppler72,
which was the old SONAME, while the build logs clearly show libpoppler73
as both installed and dependency.

So maybe really removing all of calligra 1:3.0.1+dfsg-2 (source + all
the binaries) will help...

-- 
Pino Toscano

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

Bug#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly

[Sebastian Dröge]

forwarded 893813 
thanks

On Thu, 2018-03-22 at 19:05 +0100, Thorsten Glaser wrote:
> [...]
> 
> Please report that upstream.

Thanks, done: https://bugzilla.gnome.org/show_bug.cgi?id=794605

Feel free to NMU for this change, but I expect there to be more similar
problems elsewhere.

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

Bug#893815: too old to support lts-11.1

[Joey Hess]

Package: haskell-stack
Version: 1.5.1-1
Severity: normal

joey@darkstar:~/src/git-annex>stack setup
Downloaded lts-11.1 build plan.
AesonException "Error in 
$.packages.cassava.constraints.flags['bytestring--lt-0_10_4']: Invalid flag 
name: \"bytestring--lt-0_10_4\""

https://github.com/futurice/haskell-mega-repo/issues/457
Newer versions of stack fix this.

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

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

Versions of packages haskell-stack depends on:
ii  ca-certificates  20170717
ii  gcc  4:7.3.0-1
ii  libc62.27-2
ii  libffi6  3.2.1-8
ii  libgmp-dev   2:6.1.2+dfsg-3
ii  libgmp10 2:6.1.2+dfsg-3
ii  libsqlite3-0 3.22.0-2
ii  libyaml-0-2  0.1.7-2
ii  make 4.2.1-1
ii  xz-utils 5.2.2-1.3
ii  zlib1g   1:1.2.8.dfsg-5

haskell-stack recommends no packages.

haskell-stack suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#893814: keyboard-configuration: Set the default XKB model to nokiarx51 for Nokia N900 devices

[David Derby]

Package: keyboard-configuration
Version: 1.180
Severity: normal
Tags: patch

Dear Maintainer,

When installing Debian on the Nokia N900, the keyboard-configuration
package does not automatically configure the built-in keyboard in
/etc/default/keyboard.  The xkb-data package already provides XKB
configuration data for this device under the XKB model "nokiarx51".

Please find attached a patch for the keyboard-configuration config
script which will detect the Nokia N900 hardware and set XKBMODEL to
"nokiarx51".

I have tested this on the Nokia N900 itself and also on one other ARM
device to ensure that it falls back and configures the default XKBMODEL
as expected.

I would appreciate your comments.

Kind regards,

David


*** ~/console-setup/n900-xkbmodel.patch
diff -ru a/console-setup-1.180/debian/keyboard-configuration.config 
b/console-setup-1.180/debian/keyboard-configuration.config
--- a/console-setup-1.180/debian/keyboard-configuration.config  2018-03-20 
12:26:54.560520833 -0500
+++ b/console-setup-1.180/debian/keyboard-configuration.config  2018-03-20 
12:52:12.156520833 -0500
@@ -272,6 +272,7 @@
 # ppc/cell pc  "platform: Cell"
 # ppc/{bbox,mbx,ppc64,82xx,8xx} Not yet supported by Debian
 
+# arm*/n900nokiarx51   "Hardware.*: Nokia RX-51 board"
 # arm/*pc  (refered to as 'arm' only)
 
 guess_arch () {
@@ -284,7 +285,7 @@
 
 arch=`dpkg --print-architecture`
 
-if [ "$arch" = 'powerpc' -o "$arch" = 'm68k' ]; then
+if [ "$arch" = powerpc ] || [ "$arch" = m68k ] || [ "$arch" = armhf ] || [ 
"$arch" = armel ]; then
if [ "$arch" = powerpc ]; then
line=`sed -n 's/^platform.*: *//p' /proc/cpuinfo`
if [ "$line" = PS3 ] || [ "$line" = Cell ]; then
@@ -304,6 +305,14 @@
return 0
fi
subarch=`echo $line|tr A-Z a-z`
+   elif [ "$arch" = armhf ] || [ "$arch" = armel ]; then
+   line=`sed -n 's/^Hardware.*: *//p' /proc/cpuinfo`
+   if [ "$line" = 'Nokia RX-51 board' ]; then
+   subarch=n900
+   else
+   echo unknown
+   return 0
+   fi
fi
case "$subarch" in
*amiga*)
@@ -404,6 +413,10 @@
XKBMODEL=pc105
model_priority=medium
;;
+arm*/n900)
+   XKBMODEL=nokiarx51
+   model_priority=medium
+   ;;
 arm*)
XKBMODEL=pc105
model_priority=medium

Bug#893563: whiptail has priority important

[Sven Joachim]

On 2018-03-22 10:57 +, Alastair McKinstry wrote:

> On 21/03/2018 20:17, Sven Joachim wrote:
>> The problem is that debconf uses whiptail as its default frontend, but
>> does _not_ depend on it, so that it does not need to be installed in
>> build chroots which normally use the "noninteractive" debconf frontend.
>>
>> For a usable debconf, you really need whiptail or dialog (or one of the
>> graphical frontends, but those have many additional dependencies and
>> require X).  See debconf(7).
> Interesting corner case. Wouldn't setting Recommends: whiptail | dialog
> on debconf fix this ?

Unfortunately it would not.  Being part of the base system, debconf is
installed by debootstrap, and debootstrap's simplistic resolver
completely ignores Recommends.

Cheers,
   Sven

Bug#893050: (no subject)

[Rebecca N. Palmer]

Control: tags -1 patch

Looks like the problem is the "-i pythonX.Y" at 
https://sources.debian.org/src/pyopencl/2018.1.1-1/debian/rules/#L38 : 
that's not valid input to pybuild, and (probably since pybuild commit 
https://anonscm.debian.org/cgit/dh-python/dh-python.git/commit/?id=fa7caff4ee252280f7abfc413a7426155e8865ff 
) causes it to put the wrong path-to-just-built-package in PYTHONPATH.


Removing this makes it build, but I'm not sure whether it works. 
(Several test failures, but they might well be "trying to test something 
my hardware can't do".  Also, 'make tests' doesn't work without 
https://git.tiker.net/pyopencl.git/commit/92e26e6338ca687ea6d18fa9748f804314e8a12e 
)

Bug#893661: gthumb: Memory leakage

[Herbert Fortes]

Hi Patrick,

> Package: gthumb
> Version: 3:3.4.4.1-5
> Severity: important
> 
> Dear Maintainer,
> 
> I'm using gthumb 3.4.4.1 which is the version available in the current Debian
> Stable repositories. It seems to have a big memory leak: From the moment I 
> open
> the program, every picture I watch seems to stay loaded in the RAM until it's
> full and then, the whole system becomes extremely slow.
> 
> The only way I found to avoid this is to keep an eye on the system monitor and
> close gthumb once in a while before the RAM usage reaches 100%. It seems like
> there's been issues like that in the past:
> 
> https://mail.gnome.org/archives/gthumb-list/2017-April/msg0.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810054
> 

The Debian stable missed the release with some
"fixed minor memory leaks" for too little.

There is a new upstream version - 3.6.1 (this month).
I will put it in Debian Sid this weekend. Then we 
have to wait about 10 days in Debian Testing. Total
15 days waiting (5 - Sid + 10 Testing).

Before the end of April it should be available by 
backports[0]. It is a good moment to do that.

[0] - https://backports.debian.org/



Regards,
Herbert

Bug#893702: Please stop build-depending on pdftk

[Vagrant Cascadian]

Control: affects 892539 diffoscope

On 2018-03-21, Matthias Klose wrote:
> pdftk still still depends on GCJ, and is likely to be removed when gcj is
> removed. Please stop build-depending on pdftk.

FWIW, there's a reference to a fork of pdftk that doesn't require gcj:

  https://bugs.debian.org/892539


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#893559: version solaar_0.9.2+git20170921+dfsg-1_all.deb from experimental: same issue

[Alf]

Her the debug info from experimental version started from command line:

$ solaar -d
18:14:31,875 INFO [MainThread] root: language de_DE (UTF-8),
translations path None
18:14:31,936 INFO [MainThread] solaar.upower: connected to system
dbus, watching for suspend/resume events
18:14:31,963 INFO [MainThread] solaar.ui.notify: starting desktop
notifications
18:14:32,009 INFO [MainThread] solaar.listener: starting receiver
listening threads
18:14:32,012 INFO [MainThread] solaar.listener: receiver event add
DeviceInfo(path=u'/dev/hidraw2', vendor_id=u'046d', product_id=u'c52b',
serial=u'', release='1203', manufacturer='Logitech', product='USB
Receiver', interface=2, driver=u'logitech-djreceiver')
18:14:32,015 INFO [ReceiverListener:hidraw2]
logitech_receiver.listener: started with
 (14)
18:14:32,015 INFO [ReceiverListener:hidraw2] solaar.listener:
: notifications listener has started (14)
18:14:32,019 INFO [ReceiverListener:hidraw2]
logitech_receiver.receiver: :
receiver notifications enabled => ('wireless', 'software present')
18:14:32,023 INFO [ReceiverListener:hidraw2] solaar.listener:
status_changed : present, Keine
gekoppelten Geräte. (0)
18:14:32,025 INFO [ReceiverListener:hidraw2]
logitech_receiver.receiver: : found
new device 1 (1028)
18:14:32,025 INFO [ReceiverListener:hidraw2] solaar.listener:
Notification(1,41,04,122810) triggered new device
 (mouse)
18:14:32,043 INFO [ReceiverListener:hidraw2] solaar.listener:
status_changed : present, 1 paired
device. (0)

(solaar:2429): Gdk-CRITICAL **: 18:14:32.051:
gdk_window_thaw_toplevel_updates: assertion
'window->update_and_descendants_freeze_count > 0' failed
18:14:32,051ERROR [ReceiverListener:hidraw2] logitech_receiver.base:
write failed, assuming handle 14 no longer available
18:14:32,052ERROR [ReceiverListener:hidraw2]
logitech_receiver.listener: processing Notification(1,41,04,122810)
Traceback (most recent call last):
  File "/usr/share/solaar/lib/logitech_receiver/listener.py", line 185,
in run
self._notifications_callback(n)
  File "/usr/share/solaar/lib/solaar/listener.py", line 207, in
_notifications_handler
_notifications.process(dev, n)
  File "/usr/share/solaar/lib/logitech_receiver/notifications.py", line
54, in process
return _process_device_notification(device, status, notification)
  File "/usr/share/solaar/lib/logitech_receiver/notifications.py", line
97, in _process_device_notification
return _process_hidpp10_notification(device, status, n)
  File "/usr/share/solaar/lib/logitech_receiver/notifications.py", line
175, in _process_hidpp10_notification
status.changed(active=link_established)
  File "/usr/share/solaar/lib/logitech_receiver/status.py", line 253, in
changed
self[KEYS.NOTIFICATION_FLAGS] = d.enable_notifications()
  File "/usr/share/solaar/lib/logitech_receiver/receiver.py", line 274,
in enable_notifications
flag_bits = _hidpp10.get_notification_flags(self)
  File "/usr/share/solaar/lib/logitech_receiver/hidpp10.py", line 310,
in get_notification_flags
flags = read_register(device, REGISTERS.notifications)
  File "/usr/share/solaar/lib/logitech_receiver/hidpp10.py", line 142,
in read_register
return device.request(request_id, *params)
  File "/usr/share/solaar/lib/logitech_receiver/receiver.py", line 281,
in request
return _base.request(self.receiver.handle, self.number, request_id,
*params)
  File "/usr/share/solaar/lib/logitech_receiver/base.py", line 340, in
request
write(ihandle, devnumber, request_data)
  File "/usr/share/solaar/lib/logitech_receiver/base.py", line 171, in write
raise NoReceiver(reason=reason)
NoReceiver: {'reason': OSError(32, 'Daten\xc3\xbcbergabe unterbrochen
(broken pipe)')}
18:14:32,052ERROR [ReceiverListener:hidraw2] logitech_receiver.base:
read failed, assuming handle 14 no longer available
18:14:32,052  WARNING [ReceiverListener:hidraw2]
logitech_receiver.listener: receiver disconnected
18:14:32,052 INFO [ReceiverListener:hidraw2] solaar.listener:
: notifications listener has stopped

Bug#893163: caja-dropbox: Seeing this problem too

[Rogério Brito]

Package: caja-dropbox
Version: 1.20.0-2
Followup-For: Bug #893163

Hi.

I also have this problem. Contrary to what Martin Wimpress said at
https://github.com/mate-desktop/caja-dropbox/issues/27#issuecomment-373908072,
I have the exact problem described by the original poster here on Debian,
with my system as up-to-date as possible.

Just for the record, I'm not using any indicator applet (to be sure, I
always get confused between this indicator vs. notification thing).

Also, I'm not sure if the workaround suggested at
https://github.com/mate-desktop/caja-dropbox/issues/27#issuecomment-373982493
is supposed to fix things only for those people using the indicator applet
or to everybody, but I just did the following at a terminal and the dropdown
menus continue with the same problem:

export XDG_DESKTOP_SESSION=Unity
caja-dropbox start

Should I do anything else?


Thanks in advance,

Rogério Brito.

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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 caja-dropbox depends on:
ii  dbus-x11 1.12.6-2
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libcaja-extension1   1.20.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.56.0-2
ii  libgtk-3-0   3.22.29-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  policykit-1  0.105-18
ii  procps   2:3.3.12-4
ii  python   2.7.14-4
ii  python-gpg   1.10.0-2
ii  python-gtk2  2.24.0-5.1+b1

caja-dropbox recommends no packages.

Versions of packages caja-dropbox suggests:
ii  caja  1.20.0-2

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#893037: Add support for diffing docker-format containers

[Juliana Oliveira]

Hi Jonathan and Lamby,

AFAIK, docker /images/ can be exported to tarballs. Not sure how human
readable they are, but diffoscope can definitely work. (:

On Thu, 15 Mar 2018 22:52:40 + Chris Lamb  wrote:
> tags 893037 + moreinfo
> thanks
>
> Hi Jonathan,
>
> Thank you very much for the idea and wishlist bug.
>
> > It would be nice if diffoscope could diff against docker containers
available
> > on the local system.
>
> Could you briefly elaborate on what you mean here? I have a bunch of
> directories under /var/lib/docker/containers -- are you wanting to
> diffoscope two of these, or...? diffoscope basically works on "paths",
> you see.
>
>
> Best wishes,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org / chris-lamb.co.uk
> `-
>
>

-- 

Juliana

Bug#752467: python-virtualenv: no command "virtualenv"

[Simon McVittie]

[Please try to use a Subject line that will remind other developers which
bug you're talking about when mails from it are seen out of context. I've
retrieved the title from the original bug report.]

On Thu, 22 Mar 2018 at 12:41:33 -0400, Marvin Renich wrote:
> I just ran into this issue.  I am installing OctoPrint from source on a
> BeagleBone Black, and OctoPrint uses python2, and I would rather not
> install python3 if I can avoid it.

Python 2 is no longer security-supported after 2020 (and that's about
halfway through the expected support lifetime of buster), so in the
buster timescale, Python 3 should really be preferred.

In a space-constrained environment, you can install python-virtualenv
and run "python -m virtualenv ARGS" as a substitute for "virtualenv ARGS".
Does that help?

> My (strong) opinion is that the correct solution should involve a single
> /usr/bin/virtualenv command that works correctly with both python2 and
> python3.

For commands where the user neither knows nor cares how the command
is implemented because it doesn't matter, like the tappy command from
src:tap.py, having a single command is absolutely fine.

For commands where the version of Python used for the implementation
matters, like python[3]-coverage and pyflakes[3], I'm not so sure about
this reasoning. virtualenv is somewhere between those extremes, because
it has a -p/--python option, but the default if that option is not given
is to use the same Python version used for virtualenv itself.

If I understand correctly, the script that you assert should exist
has these semantics when run without the -p/--python option:

* Please set up a virtual environment to run Python code
* After running this command, the virtual environment will be suitable
  for running either Python 2 code or Python 3 code but probably not
  both, and I can't know which

which don't seem amazingly useful? It would seem better for there to be
a predictable default, so that at least within Debian, virtualenv does
something consistent; and Python 2 is going to reach the end of its
security support before buster does, so for buster, that default should
probably be Python 3.

smcv

Bug#893811: prosody-modules: please package new snapshot

[W. Martin Borgert]

Package: prosody-modules
Version: 0.0~hg20170929.c53cc1ae4788+dfsg-3
Severity: wishlist

Many problems in various modules shipped in the Debian package
have been fixed by upstream.

Bug#893702: Please stop build-depending on pdftk

[Holger Levsen]

control: severity -1 important
thanks

On Wed, Mar 21, 2018 at 08:38:31PM +0800, Matthias Klose wrote:
> pdftk still still depends on GCJ, and is likely to be removed when gcj is
> removed. Please stop build-depending on pdftk.

thanks for warning us, Matthias! I'm lowering the severity until gcj has
been removed.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#890791: stretch-pu: package dpkg/1.18.25

[Manuel A. Fernandez Montecelo]

Hi,

2018-03-20 7:33 GMT+01:00 Karsten Merker :
> On Wed, Feb 28, 2018 at 06:45:49PM +, Adam D. Barratt wrote:
>>
>> We've been discussing this amongst the SRMs and are quite wary of a
>> dpkg update this close to the p-u freeze. We appreciate that the
>> changes individually seem self-contained but would like to have an
>> update of such a key package able to be tested more than is feasible in
>> the time available.
>> [...]
>> We understand that this is inconvenient for the riscv porters, so are
>> exploring whether it would be possible to have the dak support made
>> available via p-u after the upcoming point release.
>
> Hello,
>
> I wanted to kindly ask whether there are any news on this topic
> and whether there is anything that the RISC-V porters can do
> to help.

I pinged Guillem today, basically he's waiting for an ack of the
.debdiff before uploading to proposed-updates.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#880675: Patch

[Sylvain Lesage]

tag 880675 patch

Hello,

here is a better patch, kindly proposed by Niv.

---
commit 16820f7f107201a31f7bdb957b86d7fadf8c2f29 (HEAD -> sid)
Author: Niv Sardi 
Date:   Thu Mar 22 12:22:05 2018 -0300

change LC_PAPER to en_US in es_BO local

i18n defaults to A4 paper, that class of paper is imposible to find
in Bolivia,
the de-facto standard is 'letter' or en_US 279x216

Signed-off-by: Niv Sardi 

diff --git a/debian/patches/localedata/local-es_BO.diff
b/debian/patches/localedata/local-es_BO.diff
new file mode 100644
index ..c140e045
--- /dev/null
+++ b/debian/patches/localedata/local-es_BO.diff
@@ -0,0 +1,23 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## local-es_BO.dpatch by Niv Sardi 
+##
+# DP: Description: Change default LC_PAPER for Bolivian spanish
+# DP: Related bugs: #880675
+# DP: Dpatch author: Niv Sardi
+# DP: Patch author: Sylvain Lesage
+# DP: Upstream status: Not Submitted
+# DP: Date: 2018-03-22
+
+@DPATCH@
+diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git'
'--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr'
glibc~/localedata/locales/es_BO glibc/localedata/locales/es_BO
+--- glibc~/localedata/locales/es_BO2018-03-22 12:12:39.0 -0300
 glibc/localedata/locales/es_BO 2018-03-22 12:13:00.457409044 -0300
+@@ -125,7 +125,7 @@
+ END LC_TIME
+
+ LC_PAPER
+-copy "i18n"
++copy "en_US"
+ END LC_PAPER
+
+ LC_TELEPHONE
diff --git a/debian/patches/series b/debian/patches/series
index 854ee4bf..2753b3b8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -17,6 +17,7 @@ localedata/fo_FO-date_fmt.diff
 localedata/locales_CH.diff
 localedata/locales-fr.diff
 localedata/locale-en_DK.diff
+localedata/locale-es_BO.diff
 localedata/locale-csb_PL.diff
 localedata/locale-zh_TW.diff
 localedata/locale-se_NO.diff

Bug#885720: prosody-modules: Please add mod_omemo_all_access

[W. Martin Borgert]

This bug is a merge of two requests by accident.
After testing mod_munin, I conclude, that it is not very useful.
So let's just track mod_omemo_all_access with this bug report.

Bug#893810: ci.debian.net: log URL in RSS feed doesn't point to a valid file anymore

[Paul Gevers]

Package: debci
Version: 1.8
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since the recent rewrite, the link under "autopkgtest log" in the RSS feed of
packages doesn't point to the log anymore.

E.g. I get
https://ci.debian.net/data/packages/unstable/amd64/f/fpc/48064.autopkgtest.log.gz
while I find the log here:
https://ci.debian.net/data/autopkgtest/unstable/amd64/f/fpc/48064/log.gz

Paul

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

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

Versions of packages debci depends on:
ii  adduser   3.117
ii  amqp-tools0.8.0-1+b3
ii  bsdmainutils  11.1.2
ii  curl  7.58.0-2
ii  dctrl-tools   2.24-2+b1
ii  debootstrap   1.0.93
ii  devscripts2.18.1
ii  fonts-font-awesome4.7.0~dfsg-3
ii  jq1.5+dfsg-2
ii  libjs-bootstrap   3.3.7+dfsg-2
ii  libjs-jquery  3.2.1-1
ii  libjs-jquery-flot 0.8.3+dfsg-1
ii  patchutils0.3.4-2
ii  ruby  1:2.5.0
ii  ruby-activerecord 2:4.2.9-4
ii  ruby-bunny2.6.1-2
ii  ruby-pg   0.19.0-2
ii  ruby-sinatra  1.4.8-1
ii  ruby-sinatra-contrib  1.4.7-1
ii  ruby-sqlite3  1.3.13-1+b1
ii  ruby-thor 0.19.4-1
ii  sudo  1.8.21p2-3

Versions of packages debci recommends:
ii  chrony [time-daemon]  3.2-5
ii  moreutils 0.60-1

Versions of packages debci suggests:
ii  apt-cacher-ng  3.1-1

- -- Configuration Files:
/etc/sudoers.d/debci [Errno 13] Permission denied: '/etc/sudoers.d/debci'

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqz3wMACgkQnFyZ6wW9
dQqmmwf6AlK9JfmbstJQIZgEhSzXndQBDWXVKsxyLik4NbOxCJJELtKn9r6vpqBZ
xwgLdKUTlufwW8gjaCZrvGQpO3evh6TvbcjkGPI+RHnIbr8Yqz8deTNQbUDDNq0n
/RaDYpqFgtoaVUOa4FL3pziNxfTSWys9Ov+QdN6IZvwQpiLzDkw/Xo7HeHbqQYUw
Xi4m1POMJzIKDapSP2BX7bxhqPx0/xYphXj/ZCl6Vy0FCFU2Z3aE/kCgp5GqnFnf
xgZnXV0EwSUC8XtAYKJhftlQHqCIwObcP8dv+8SCPknfrnuiSAL16z+ejkhDloZH
+aesfv4A7M282RCHbkJVHNsIkCTs/A==
=CJFC
-END PGP SIGNATURE-

Bug#752467: (no subject)

[Marvin Renich]

Control: tags -1 patch

[I'm now subscribed to this bug; no need to CC me.]

On Tue, 18 Nov 2014 01:59:18 +0200 Stefano Rivera  wrote:
> Hi Barry (2014.11.17_22:53:01_+0200)
> > The question still remains: how best to upgrade people who have
> > /usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they 
> > now
> > get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
> > was an attempt at that, but clearly it's not good enough.
> 
> Taking a step back, I think the only way to reliably do this is to have
> virtualenv be Python2 for jessie, and change it to Python 3 in stretch.
> 
> so:
> python-virtualenv Depends virtualenv
> virtualenv Depends python-virtualenv (ick a loop. Avoidable?)
> 
> and in stretch:
> virtualenv Depends python3-virtualenv
> 
> By then, anybody using virtualenv has had the virtualenv package
> installed.

I just ran into this issue.  I am installing OctoPrint from source on a
BeagleBone Black, and OctoPrint uses python2, and I would rather not
install python3 if I can avoid it.

My (strong) opinion is that the correct solution should involve a single
/usr/bin/virtualenv command that works correctly with both python2 and
python3.  I have attached such a script (only tested with python2) based
on Brian May's suggestion to use the trick from django-admin.

Once this is done, the dependencies sort themselves out very nicely:

python-virtualenv Recommends: virtualenv
python3-virtualenv Recommends: virtualenv
virtualenv Depends: python3-virtualenv (>= someversion) | python-virtualenv (>= 
someversion)

virtualenv should not depend on python or python3; this will happen
transitively from the python{,3}-virtualenv dependencies.

A Depends is the correct dependency in virtualenv, because it is useless
and doesn't function unless one of the modules is installed.

A Recommends is the correct dependency in python*-virtualenv because
either can by used as a python module without the virtualenv command,
but a user would normally have the command installed as well.

Anyone with a default apt configuration (i.e. installs Recommends by
default) will upgrade correctly.  Those (like me) who don't install
Recommends by default should be looking for new Recommends when
upgrading and should be able to handle the situation.

I believe that replacing the current /usr/bin/virtualenv with the
attached script and adjusting the dependencies as described above will
allow closing this bug, and I see no downsides.

...Marvin

#!/bin/sh
# EASY-INSTALL-ENTRY-SCRIPT: 'virtualenv==15.1.0','console_scripts','virtualenv'
shell_code=''' '
# shell code
if command -v python3 > /dev/null && test -e 
/usr/lib/python3/dist-packages/virtualenv.py
then
exec python3 "$0" "$@"
elif command -v python2.7 > /dev/null && test -e 
/usr/lib/python2.7/dist-packages/virtualenv.py
then
exec python2.7 "$0" "$@"
else
echo "Cannot find installed version of python-virtualenv or 
python3-virtualenv." >&2
exit 1
fi

python_code='''
# python code
# ONLY use DOUBLE quotes <"> after this line
__requires__ = "virtualenv==15.1.0"
import re
import sys
from pkg_resources import load_entry_point

if __name__ == "__main__":
sys.argv[0] = re.sub(r"(-script\.pyw?|\.exe)?$", "", sys.argv[0])
sys.exit(
load_entry_point("virtualenv==15.1.0", "console_scripts", 
"virtualenv")()
)

# End of Python code. Do not modify this line. #'

Bug#880771: Fwd: Re: Cross-compiling libdwarf

[David Anderson]

On 03/21/2018 11:46 AM, Helmut Grohne wrote:
> If you ask me, don't embed. Just don't do it. Also don't ship compiled
> code (e.g. generated configure scripts). But that's just me.

I will skip embedding. And stick with AC_PATH_PROG.

To do cross-build of just libdwarf, I am pondering the idea of   two step:
  create empty directories stage1, stage2.
  cd stage1
  /a/b/libdwarf/configure --enable-stage1
  cd    ../stage2
  /a/b/libdwarf/configure --enable-stage2=../stage1 ...

What the  GNU Autoconf  (copyright 2004) book calls Canadian Cross for
stage2.
I'm not sure this
will actually be workable ... or acceptable to most people.
Does it appear acceptable?

DavidA.

-- 
Don't worry about people stealing your ideas.
If your ideas are any good, you'll have to 
ram them down people's throats. -- Howard Aiken

Bug#893809: screengrab: It's not possible to set a systemwide config

[robert]

Package: screengrab
Version: 1.97-2
Severity: normal
Tags: upstream

Dear Maintainer,

I want to set a system wide config under "/etc/xdg/screengrab/screengrab.conf",
and if I delete the "~/.config/screengrab" folder, or I add a new user there
are some default settings, which always apply.

In my experience this to work for other applications, or I am doing something
wrong?

Regards,
Robert



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

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

Versions of packages screengrab depends on:
ii  libc62.27-2
ii  libgcc1  1:8-20180312-2
ii  libkf5windowsystem5  5.42.0-2
ii  libqt5core5a 5.9.2+dfsg-12
ii  libqt5dbus5  5.9.2+dfsg-12
ii  libqt5gui5   5.9.2+dfsg-12
ii  libqt5network5   5.9.2+dfsg-12
ii  libqt5widgets5   5.9.2+dfsg-12
ii  libqt5x11extras5 5.9.2-1
ii  libqt5xdg3   3.1.0-5
ii  libstdc++6   8-20180312-2
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb-xfixes0   1.13-1

screengrab recommends no packages.

screengrab suggests no packages.

-- no debconf information

*** /etc/xdg/screengrab/screengrab.conf
[Display]
showTrayIcon=false

Bug#893808: libquazip: symbols adjustments to support build with -O3

[Steve Langasek]

Package: libquazip
Version: 0.7.3-5
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

libquazip 0.7.3-5 fails to build on ppc64el in Ubuntu because the symbols
files don't match.  This is because Ubuntu builds its ppc64el port with -O3
by default, and some C++ symbols are added or removed when building with
higher optimization levels.

The attached patch makes the symbols file work when building with either -O2
or -O3 (at least on ppc64el).  Please consider including this in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libquazip-0.7.3/debian/libquazip1.symbols 
libquazip-0.7.3/debian/libquazip1.symbols
--- libquazip-0.7.3/debian/libquazip1.symbols   2018-03-04 12:02:42.0 
-0800
+++ libquazip-0.7.3/debian/libquazip1.symbols   2018-03-22 09:25:48.0 
-0700
@@ -39,6 +39,8 @@
  _ZN10JlCompress12extractFilesER6QuaZipRK11QStringListRK7QString@Base 0.7.3
  _ZN10JlCompress13compressFilesE7QString11QStringList@Base 0.7.3
  
_ZN10JlCompress14compressSubDirEP6QuaZip7QStringS2_b6QFlagsIN4QDir6FilterEE@Base
 0.7.3
+ (optional)_ZN10QByteArrayD1Ev@Base 0.7.3-5
+ (optional)_ZN10QByteArrayD2Ev@Base 0.7.3-5
  _ZN10QuaAdler325resetEv@Base 0.7.3
  _ZN10QuaAdler325valueEv@Base 0.7.3
  _ZN10QuaAdler326updateERK10QByteArray@Base 0.7.3
@@ -135,8 +137,8 @@
  _ZN18QSharedDataPointerI16QuaZipDirPrivateED2Ev@Base 0.7.3
  _ZN18QuaGzipFilePrivate4openERK7QStringPKc@Base 0.7.3
  _ZN18QuaGzipFilePrivate4openEiPKc@Base 0.7.3
- 
_ZN18QuaGzipFilePrivate4openI7QStringEEbT_6QFlagsIN9QIODevice12OpenModeFlagEERS1_@Base
 0.7.3
- 
_ZN18QuaGzipFilePrivate4openIiEEbT_6QFlagsIN9QIODevice12OpenModeFlagEER7QString@Base
 0.7.3
+ 
(optional)_ZN18QuaGzipFilePrivate4openI7QStringEEbT_6QFlagsIN9QIODevice12OpenModeFlagEERS1_@Base
 0.7.3
+ 
(optional)_ZN18QuaGzipFilePrivate4openIiEEbT_6QFlagsIN9QIODevice12OpenModeFlagEER7QString@Base
 0.7.3
  _ZN19QuaZIODevicePrivate7doFlushER7QString@Base 0.7.3
  _ZN19QuaZIODevicePrivateC1EP9QIODevice@Base 0.7.3
  _ZN19QuaZIODevicePrivateC2EP9QIODevice@Base 0.7.3
@@ -149,20 +151,30 @@
  _ZN23QuaZipDirRestoreCurrentD2Ev@Base 0.7.3
  _ZN5QHashI7QString15QHashDummyValueE11deleteNode2EPN9QHashData4NodeE@Base 
0.7.3
  _ZN5QHashI7QString15QHashDummyValueE13duplicateNodeEPN9QHashData4NodeEPv@Base 
0.7.3
+ (optional)_ZN5QHashI7QString15QHashDummyValueED1Ev@Base 0.7.3
+ (optional)_ZN5QHashI7QString15QHashDummyValueED2Ev@Base 0.7.3
  _ZN5QHashI7QString16unz64_file_pos_sE11deleteNode2EPN9QHashData4NodeE@Base 
0.7.3
  
_ZN5QHashI7QString16unz64_file_pos_sE13duplicateNodeEPN9QHashData4NodeEPv@Base 
0.7.3
  _ZN5QListI14QuaZipFileInfoE13detach_helperEi@Base 0.7.3
- _ZN5QListI14QuaZipFileInfoE18detach_helper_growEii@Base 0.7.3
- _ZN5QListI14QuaZipFileInfoE5clearEv@Base 0.7.3
+ (optional)_ZN5QListI14QuaZipFileInfoE18detach_helper_growEii@Base 0.7.3
+ (optional)_ZN5QListI14QuaZipFileInfoE5clearEv@Base 0.7.3
  _ZN5QListI14QuaZipFileInfoE6appendERKS0_@Base 0.7.3
+ (optional)_ZN5QListI14QuaZipFileInfoED1Ev@Base 0.7.3
+ (optional)_ZN5QListI14QuaZipFileInfoED2Ev@Base 0.7.3
  _ZN5QListI16QuaZipFileInfo64E13detach_helperEi@Base 0.7.3
- _ZN5QListI16QuaZipFileInfo64E18detach_helper_growEii@Base 0.7.3
+ (optional)_ZN5QListI16QuaZipFileInfo64E18detach_helper_growEii@Base 0.7.3
  _ZN5QListI16QuaZipFileInfo64E6appendERKS0_@Base 0.7.3
+ (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3
+ (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3
  _ZN5QListI7QStringE13detach_helperEi@Base 0.7.3
  _ZN5QListI7QStringE18detach_helper_growEii@Base 0.7.3
- _ZN5QListI7QStringE5clearEv@Base 0.7.3
+ (optional)_ZN5QListI7QStringE5clearEv@Base 0.7.3
  _ZN5QListI7QStringE6appendERKS0_@Base 0.7.3
+ (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3
+ (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3
  _ZN5QListI9QFileInfoE13detach_helperEi@Base 0.7.3
+ (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3
+ (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3
  _ZN6QuaZip10getUnzFileEv@Base 0.7.3
  _ZN6QuaZip10getZipFileEv@Base 0.7.3
  _ZN6QuaZip10setCommentERK7QString@Base 0.7.3
@@ -190,6 +202,8 @@
  _ZN6QuaZipC2Ev@Base 0.7.3
  _ZN6QuaZipD1Ev@Base 0.7.3
  _ZN6QuaZipD2Ev@Base 0.7.3
+ (optional)_ZN7QStringD1Ev@Base 0.7.3
+ (optional)_ZN7QStringD2Ev@Base 0.7.3
  _ZN8QuaCrc325resetEv@Base 0.7.3
  _ZN8QuaCrc325valueEv@Base 0.7.3
  _ZN8QuaCrc326updateERK10QByteArray@Base 0.7.3
@@ -235,9 +249,9 @@
  _ZNK12QuaZIODevice12isSequentialEv@Base 0.7.3
  _ZNK12QuaZIODevice14bytesAvailableEv@Base 0.7.3
  _ZNK12QuaZIODevice5atEndEv@Base 0.7.3
- _ZNK13QuaZipPrivate15getFileInfoListI14QuaZipFileInfoEEbP5QListIT_E@Base 0.7.3
- _ZNK13QuaZipPrivate15getFileInfoListI16QuaZipFileInfo64EEbP5QListIT_E@Base 
0.7.3
- 

Bug#887304: linux-image-4.14.0-0.bpo.2-amd64: Error crypto/algapi.c:348 and a long system boot.

[Salvatore Bonaccorso]

Hi,

On Wed, Mar 21, 2018 at 10:56:57AM -0400, LeJacq, Jean Pierre wrote:
> I've tested the following two kernels from sid on a stretch system and they 
> both DO NOT exhibit this bug:
> 
>   linux-image-4.15.0-1-amd64
>   linux-image-4.15.0-2-amd64
> 
> Instead of the kernel null pointer exception, I see the following in the boot 
> log:
> 
>   kernel: usb 1-7: New USB device found, idVendor=8087, idProduct=0a2b
>   kernel: usb 1-7: New USB device strings: Mfr=0, Product=0, 
> SerialNumber=0
>   kernel: alg: ecdh: test failed on vector 3, err=-14
>   kernel: Bluetooth: Core ver 2.22
> 
> My bluetooth devices now work while they didn't with the 4.14.0 kernels.

Looking at the traces you posted, this might be the same issue as
#886556 and fixed with 4.14.17-1?

Regards,
Salvatore

Bug#893764: eom gets out of memory while checking out an svg image

[John Scott]

Package: eom
Version: 1.20.0-1
Followup-For: Bug #893764

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am able to reproduce on my system as well, though it took a
couple of tries. I've included a backtrace.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 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 eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  eom-common   1.20.0-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libexempi3   2.4.5-1
ii  libexif120.6.21-4
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libgirepository-1.0-11.54.1-4
ii  libgl1-mesa-glx  17.3.6-1
ii  libglib2.0-0 2.56.0-2
ii  libgtk-3-0   3.22.29-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  libmate-desktop-2-17 1.20.0-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpeas-1.0-01.22.0-2
ii  librsvg2-2   2.40.20-2
ii  librsvg2-common  2.40.20-2
ii  libstartup-notification0 0.12-5
ii  libx11-6 2:1.6.4-3
ii  libxml2  2.9.4+dfsg1-6.1
ii  mate-desktop-common  1.20.0-1
ii  shared-mime-info 1.9-2
ii  zlib1g   1:1.2.8.dfsg-5

eom recommends no packages.

eom suggests no packages.

- -- no debconf information

*** /home/john/Downloads/backtrace.txt
#0  0x728e2370 in __memset_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:188
#1  0x74574021 in memset (__len=, __ch=0, 
__dest=)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71
#2  0x74574021 in _cairo_xlib_surface_create_similar_shm 
(other=, format=CAIRO_FORMAT_ARGB32, width=100140, height=4) 
at ../../../../src/cairo-xlib-surface-shm.c:1188
#3  0x74540dd3 in INT_cairo_surface_create_similar_image 
(other=, format=CAIRO_FORMAT_ARGB32, width=100140, height=4) 
at ../../../../src/cairo-surface.c:595
#4  0x74540fc0 in cairo_surface_create_similar (other=0x55f03670, 
content=content@entry=CAIRO_CONTENT_COLOR_ALPHA, width=width@entry=100140, 
height=height@entry=4) at ../../../../src/cairo-surface.c:518
#5  0x74dd8126 in rsvg_cairo_push_render_stack (ctx=) at 
rsvg-cairo-draw.c:867
#6  0x74dd8126 in rsvg_cairo_push_discrete_layer (ctx=) 
at rsvg-cairo-draw.c:903
#7  0x74dcbf03 in _rsvg_node_draw_children (self=0x7fffd4590e30, 
ctx=0x560db390, dominate=0)
at rsvg-structure.c:66
#8  0x74dcc3b3 in rsvg_node_draw (dominate=0, ctx=0x560db390, 
self=) at rsvg-structure.c:54
#9  0x74dcc3b3 in rsvg_node_svg_draw (self=0x7fffd4008740, 
ctx=0x560db390, dominate=)
at rsvg-structure.c:311
#10 0x74d8 in rsvg_node_draw (self=, 
ctx=ctx@entry=0x560db390, dominate=dominate@entry=0)
at rsvg-structure.c:54
#11 0x74dd9af9 in rsvg_handle_render_cairo_sub (handle=0x55c1af30 
[RsvgHandle], cr=cr@entry=0x55cf0be0, id=id@entry=0x0) at 
rsvg-cairo-render.c:248
#12 0x74dd9b27 in rsvg_handle_render_cairo (handle=, 
cr=cr@entry=0x55cf0be0)
at rsvg-cairo-render.c:270
#13 0x5558fb66 in display_draw (widget=, 
cr=0x55cf0be0, data=)
at eom-scroll-view.c:1307
#14 0x76e9d047 in _gtk_marshal_BOOLEAN__BOXEDv 
(closure=closure@entry=0x55b0c940, 
return_value=return_value@entry=0x7fffcac0, 
instance=instance@entry=0x55c4e0f0, args=args@entry=0x7fffcb90, 
marshal_data=marshal_data@entry=0x0, n_params=n_params@entry=1, 
param_types=0x55943100) at ../../../../gtk/gtkmarshalers.c:128
#15 0x76fe56eb in gtk_widget_draw_marshallerv (closure=0x55b0c940, 
return_value=0x7fffcac0, instance=0x55c
4e0f0, args=0x7fffcb90, marshal_data=0x0, n_params=1, 
param_types=0x55943100) at ../../../../gtk/gtkwidget.c:973
#16 0x736ed1a6 

Bug#893807: ITP: libudis86 -- Disassembler Library for x86 and x86-64

[Robert Haist]

Package: wnpp
Severity: wishlist
Owner: Robert Haist 

* Package name: libudis86
  Version : 1.7.2
  Upstream Author : Vivek Thampi 
* URL : http://udis86.sourceforge.net
* License : BSD 2-Clause
  Programming Lang: C
  Description : Disassembler Library for x86 and x86-64

Udis86 is a disassembler for the x86 and x86-64 class of instruction set
architectures. It consists of a C library called libudis86 which
provides a clean and simple interface to decode a stream of raw binary
data, and to inspect the disassembled instructions in a structured
manner.

A lot of debian packages and even the linux kernel seem to reference this
library[1]. I need it as dependency for pev and libpe.

[1]https://codesearch.debian.net/search?q=udis86.h=1

Bug#893702: Please stop build-depending on pdftk

[Chris Lamb]

tags 893702 - patch
thanks

Hi Matthias,

> pdftk still still depends on GCJ, and is likely to be removed when gcj is
> removed. Please stop build-depending on pdftk.

We build-depend on pdftk because we actually use it to compare files,
so unfortunately simply dropping it from the Build-Depends is not a
sufficient patch.

It's in Build-Depends for the testsuite run; it's also in Recommends.
ACK the underlying issue regarding it's removal, naturally. What is
the timeline on this, out of interest?


Best wishes,

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

Bug#893806: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.9-1
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2780

Hi,

the following vulnerability was published for tiff.

CVE-2018-8905[0]:
| In LibTIFF 4.0.9, a heap-based buffer overflow occurs in the function
| LZWDecodeCompat in tif_lzw.c via a crafted TIFF file, as demonstrated
| by tiff2ps.

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-8905
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8905
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2780

Please adjust the affected versions in the BTS as needed.  There is a
poc file attached to the upstream bug [1] which can be used to verify
a fix; the poc might not trigger but still the issue might be present
in other versions than 4.0.9. There is not upstream commit yet which
might help pinpointing then the issue.

Regards,
Salvatore

Bug#893059: Fix upstream

[Fardale]

This problem has been fix upstream by this commit https://github.com/
janikrabe/oidentd/commit/1465ef7015260ee9068f92865bf355dddf47409a
and this commit https://github.com/janikrabe/oidentd/commit/
e290df88f1435255732db0f0bb03d8ce45dcd9a8 allow the parameter to be specify in 
any order.

-- 
Fardale