Bug#895898: [Pkg-libvirt-maintainers] Bug#895898: virt-install adds "method=" boot parameter, which is copied to Grub config

[Guido Günther]

Hi,
On Tue, Apr 17, 2018 at 01:55:33PM +0200, Raphaël Halimi wrote:
> Package: virtinst
> Version: 1:1.4.0-5
> Severity: minor
> 
> Hi,
> 
> I'm trying to fully automatically install virtual machines by means of a
> preseed file. I set "--location" to the desired URL and add some
> parameters to "--extra-args" to ask debian-installer to run an automated
> installation, tell it where to fetch the preseed file, and add some
> parameters that I want copied to the installed system's boot
> configuration (for example "elevator=noop").
> 
> This works almost perfectly, but there one slight problem: for a reason
> I don't understand, virt-install adds "method= option>" to the kernel parameters (qemu's "-append" option), *after* the
> contents of "--extra-args".
> 
> As stated in its documentation, debian-installer will copy most kernel
> parameters found after "--" or "---" to the installed system's boot
> configuration (eg. in /etc/default/grub), filtering the ones it thinks
> are destined to itself; so if the "--extra-args" option contains "--" or
> "---", the "method=..." argument ends up being copied in
> /etc/default/grub, which of course is not desired. Obviously,
> debian-installer filter doesn't catch it.
> 
> Now, I'm not sure what would be the correct fix for this. I see two
> possibilities:
> 
> - the conservative (and simple) one: modify virt-install to add
> "method=..." *before* the contents of "--extra-args", so that if the
> latter contains "--" or "---", "method=..." will be positioned before
> those, and won't be copied to the installed system's boot configuration.
> 
> - the risky one: modify virt-install to not add "method=..." at all;
> after re-reading debian-installer's documentation, I didn't see this
> parameter mentioned anywhere. Come to think of it, this shouldn't be
> needed: virt-install already fetches the kernel and initrd, and passes
> them to the VM, so I can't see why debian-installer should need to know
> how they were fetched.
> 
> If the second suggestion is totally wrong, and debian-installer does
> know (and thus, sometimes need) "method=..." (it should be documented,
> then !), maybe the bug should be reassigned to debian-installer, and ask
> to add "method=..." to the list of filtered parameters, to prevent it to
> be passed to Grub.
> 
> I tried to find by myself where the "-append" option is constructed, to
> provide a patch for the first fix, but I don't know much python and
> couldn't understand the scripts. If you give me a hint about this, I'll
> be glad to (try to) help.
> 

Check _kernelFetchHelper where it adds the method arg. I doubt this is
needed at all on Debian but rather a leftover of other distros.
 -- Guido

> Regards,
> 
> -- 
> Raphaël Halimi
> 




> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#895971: virtualbox-ext-pack: Unroutable maintainer address

[Scott Kitterman]

Package: virtualbox-ext-pack
Version: 5.2.10-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

After a recent upload, the FTP team received this error:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pkg-virtualbox-de...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

Policy 3.3 requires a working email address for the package maintainer.  This
may be an issue with the recent migration of alioth lists to a new host.

Scott K

Bug#895970: virtualbox: Unroutable maintainer address

[Scott Kitterman]

Package: virtualbox
Version: 5.2.10-dfsg-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

After a recent upload, the FTP team received this error:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pkg-virtualbox-de...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

Policy 3.3 requires a working email address for the package maintainer.  This
may be an issue with the recent migration of alioth lists to a new host.

Scott K

Bug#895951: jenkins.debian.net: reproducible Debian: Correct parsing of diffoscope version since recent update of PyPI.org

[Mattia Rizzolo]

On Tue, Apr 17, 2018 at 08:03:41PM +0100, Chris Lamb wrote:
> Attached is the following:
> 
>   commit f8d976951e4728b4a34ac8e04bd50d6e59b82634
>   Author: Chris Lamb 
>   Date:   Tue Apr 17 20:02:41 2018 +0100
>   
>   reproducible Debian: Correct parsing of diffoscope version since recent 
> update of PyPI.org
>   
>bin/diffoscope_distribution_test.sh | 4 ++--
>1 file changed, 2 insertions(+), 2 deletions(-)

Thanks, applied!

> - curl https://pypi.python.org/pypi/diffoscope/ -o $TMPPYPI
> - DIFFOSCOPE_IN_PYPI=$(grep "" $TMPPYPI | cut -d ">" -f2- | cut -d 
> ":" -f1 |cut -d " " -f2)
> + curl https://pypi.org/project/diffoscope/ -o $TMPPYPI
> + DIFFOSCOPE_IN_PYPI=$(sed -ne 's@.*diffoscope \([0-9][0-9]*\).*@\1@gp' 
> $TMPPYPI)

Anyhow, I wonder if it wouldn't be cleaner to use pypi's API instead…
Maybe for the next time this regex breaks :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#895968: keep position when zooming

[積丹尼 Dan Jacobson]

Package: xli
Version: 1.17.0+20061110-5
Severity: wishlist

When using > and < to zoom,
please keep our position.
Don't just place us at the top left from scratch.

Bug#895692: ejabberd: Does not use IPv6 for PostgreSQL and LDAP

[Philipp Huebner]

Hi,

On Sat, 14 Apr 2018 20:00:16 +0200 Dominik George > ejabberd 18.01 fails
hard when one of the SQL or LDAP hosts does not
> have an A record and is IPv6 only. Providing an IPv6 address directly in
> the configuration also fails. It looks like ejabberd does simply not
> support AF_INET6 for its client sockets.

could you please supply corresponding logs?

If you have the rather recent
ERL_OPTIONS="-env ERL_CRASH_DUMP_BYTES 0"
in /etc/default/ejabberd, please reset that to
ERL_OPTIONS="" to create crash dumps from the next occurrence on.

Then please post your error.log, ejabberd.log, crash.log and at least
one of the crash dumps.

In case you have configured "hide_sensitive_log_data: false" you might
want to filter/anonymize certain aspects from the logs beforehand.


Also, have you tried configuring IPv6 addresses directly instead of 
records to rule out wonky DNS?


Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#895967: python3-flask-socketio: Traceback on import

[Sebastian Silva]

Package: python3-flask-socketio
Version: 2.9.0-1
Severity: important

Dear Maintainer,

I was trying to use this package but it fails on import missing some
dependency.

>>> import flask_socketio
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/flask_socketio/__init__.py", line 16, in

import socketio
ModuleNotFoundError: No module named 'socketio'



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

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

Bug#895008: Kicad 5 RC build

[Carsten Schoenert]

Hello Julien,

On Wed, Apr 18, 2018 at 09:33:06AM +1000, Julien Goodwin wrote:
> I'd like to try the RC of kicad5 that's mentioned in #40, but that
> directory doesn't include the various data packages for kicad-libraries,
> do you have a build of those?

yes of course. Due the size of the (still growing) libraries we split
out those and add adjust the Recommends for the kicad package. So if you
install kicad from experimental you might need to extend the package
list to get libraries for symbols, footprint, templates and 3d models
also installed.
Due the default that Recommends will be also installed I guess that's
not really needed, kicad is recommending kiacd-libraries and this is
depending on kiacd-{footprints,symbols,templates}. The package
kicad-packages3d is 'just' a Suggests and not really needed for PCB
design, thus this package need to be installed by a dedicated extend of
the install command.

The wiki page for KiCad holds some extra information about the
relationship between the packages and also about the package names. (I
know, the site isn't fully up2date currently.)

https://wiki.debian.org/KiCad

Regards
Carsten

Bug#895943: transition: perl 5.26.2

[Niko Tyni]

On Tue, Apr 17, 2018 at 06:44:50PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 17/04/18 18:38, Niko Tyni wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi,
> > 
> > perl 5.26.2-1 in experimental. It is binary compatible with 5.26.0 and
> > 5.26.1 and therefore Provides all of perlapi-5.26.0, perlapi-5.26.1
> > and perlapi-5.26.2.  However, as usual, four packages will need binNMUs
> > once it enters unstable due to their strict versioned dependencies on
> > the current perl version:
> > 
> >  libpar-packer-perl
> >  libdevel-cover-perl
> >  libclass-xsaccessor-perl
> >  libcommon-sense-perl
> > 
> > These binNMUs will need the 'extra-depends' wanna-build feature to make
> > sure the new perl is pulled in.
> > 
> > Please let us know if/when it's OK to upload.
> 
> Please go ahead.

Thanks, uploaded last night.
-- 
Niko

Bug#895463: keyutils FTBFS: Can't Determine Endianness

[Steve Langasek]

Package: keyutils
Followup-For: Bug #895463
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Christian,

This bug is reproducible in Ubuntu, and I tracked it down to the change to
build /bin/bash with -fPIE, which changes the 'file' signature for
/proc/$$/exe (aka /bin/bash) to no longer report that it is an "[LM]SB
executable".

I have uploaded the attached patch to Ubuntu, which makes keyutils'
endianness detection portable to systems which build with -fPIE.  Please
consider including it in Debian as well.

-- 
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 keyutils-1.5.9/debian/patches/endianness-and-PIE.patch 
keyutils-1.5.9/debian/patches/endianness-and-PIE.patch
--- keyutils-1.5.9/debian/patches/endianness-and-PIE.patch  1969-12-31 
16:00:00.0 -0800
+++ keyutils-1.5.9/debian/patches/endianness-and-PIE.patch  2018-04-17 
21:21:12.0 -0700
@@ -0,0 +1,24 @@
+Description: fix regexp match against `file /proc/$$/exe` for -fPIE bash
+ Now that bash is built with PIE enabled, keyutils' check for endianness
+ fails because file no longer returns "executable", but instead returns
+ "shared object".  Update our regexps to be portable.
+Author: Steve Langasek 
+Last-Modified: 2018-04-17
+
+Index: keyutils-1.5.9/tests/toolbox.inc.sh
+===
+--- keyutils-1.5.9.orig/tests/toolbox.inc.sh
 keyutils-1.5.9/tests/toolbox.inc.sh
+@@ -19,10 +19,10 @@
+ echo === $OUTPUTFILE ===
+ 
+ endian=`file -L /proc/$$/exe`
+-if expr "$endian" : '.* MSB executable.*' >&/dev/null
++if expr "$endian" : '.* MSB \(executable\|shared object\).*' >&/dev/null
+ then
+ endian=BE
+-elif expr "$endian" : '.* LSB executable.*' >&/dev/null
++elif expr "$endian" : '.* LSB \(executable\|shared object\).*' >&/dev/null
+ then
+ endian=LE
+ else
diff -Nru keyutils-1.5.9/debian/patches/series 
keyutils-1.5.9/debian/patches/series
--- keyutils-1.5.9/debian/patches/series2017-11-21 08:14:40.0 
-0800
+++ keyutils-1.5.9/debian/patches/series2018-04-17 21:18:02.0 
-0700
@@ -16,3 +16,4 @@
 Make-build-reproducible.patch
 Drop-tests-requiring-CONFIG_BIG_KEYS.patch
 Adjust-tests-for-3.18-kernel-change.patch
+endianness-and-PIE.patch

Bug#895940: RFS: python-dataclasses/0.5-1 [ITP]

[Sergio Durigan Junior]

Control: tags -1 + moreinfo

On Tuesday, April 17 2018, Joel Cross wrote:

>   Dear mentors,
>
>   I am looking for a sponsor for my package "python-dataclasses"
>
>  * Package name: python-dataclasses
>Version : 0.5-1
>Upstream Author : Eric V. Smith 
>  * URL : https://github.com/ericvsmith/dataclasses
>  * License : MIT
>Section : python
>
>   It builds those binary packages:
>
> python3-dataclasses - Python dataclasses backport from 3.7
>
>   To access further information about this package, please visit the following
> URL:
>
>   https://mentors.debian.net/package/python-dataclasses
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/p/python-
> dataclasses/python-dataclasses_0.5-1.dsc
>
>   More information about Python dataclasses can be obtained from
> https://www.python.org/dev/peps/pep-0557.

Hi, Joel,

Thanks for the interest!  I briefly looked at the package and noticed a
few things worth fixing/addressing.  Keep in mind this is a
non-exhaustive list; there may be other issues, but I think it's a good
idea to put the package in a good shape first.

1) This package (and other Python packages you've submitted for
sponsorship) can be packaged together with the Debian Python team.
Unless you have a reason not to do that, this is the recommended way to
do Python packaging.  A good starting point to know more about the team
is  and
.

2) Your package is not using the latest debhelper (v11), the latest
Standards-Version (4.1.4.1), doesn't provide Vcs-* links (in other
words, where is the package repository?), d/compat is "10" (should be
"11").  If you're going to package under the Debian Python team, please
look at the specific instructions on how to fill the
Maintainer/Uploaders fields.

3) As mentioned above, you did not provide any git repository where we
can find your package.  It is extremely important that you do that, and
I strongly recommend following the "git-buildpackage" workflow.  You can
create a guest user account on https://salsa.debian.org and create a
repository there, if you need.  Eventually (when the package is
accepted) this repository will be moved to either the Debian namespace
or the Debian Python Team namespace, depending on what you choose to do.

4) d/copyright mentions "MIT", but that's a generic name that covers
many types of licenses.  Judging by the license text you used there, the
license name should be "Expat".

*However...*

5) I don't see any copyright notice on the upstream project whatsoever.
Actually, the only notice I see (in the file "pep-0557.rst") mentions:

  Copyright
  =

  This document has been placed in the public domain.

But I understand that this notice only applies to the file itself, not
to the whole project.  Which begs the question: where did you see that
the project is licensed under Expat?

/me looks once more...

Ah!  Found it.  It's listed in the "setup.py" file.  Hmm...  I wonder if
that's a problem, because no other file contains any kind of copyright
notice, and there's no LICENSE file.  I'd definitely file a bug against
upstream asking them to clarify this, but I honestly don't know if
ftp-master will accept the package as is.  Maybe there's some
precedence, but I'm short on time right now and can't really dive into
the archives to find something.  Perhaps someone more knowledgeable can
chime in?


All right, I'll stop the review for now.  I'll keep an eye on any
updates here, and will be happy to upload the package once we sort
everything out.

Cheers,

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


signature.asc
Description: PGP signature

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Steven Shiau]

On 4/14/2018 PM 09:12, Bastian Blank wrote:

Please make sure your DNS infrastructure is robust enough.  Until then
this server is no suitable candidate for ftp.*.debian.org.  I'm sorry
about missing this fact in the first place.

Hi Bastian,
Our DNS admin has made some changes, as showing in the following. Does 
that meet the requirement? Thank you very much.


~$ dig nchc.org.tw ns

; <<>> DiG 9.10.3-P4-Debian <<>> nchc.org.tw ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60488
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nchc.org.tw.   IN  NS

;; ANSWER SECTION:
NCHC.org.tw.    43200   IN  NS  ns1.NCHC.org.tw.
NCHC.org.tw.    43200   IN  NS  ns4.NCHC.org.tw.
NCHC.org.tw.    43200   IN  NS  ns2.NCHC.org.tw.
NCHC.org.tw.    43200   IN  NS  ns3.NCHC.org.tw.

;; ADDITIONAL SECTION:
ns1.NCHC.org.tw.    43200   IN  A   140.110.16.1
ns2.NCHC.org.tw.    43200   IN  A   140.110.4.1
ns3.NCHC.org.tw.    43200   IN  A   140.110.96.2
ns4.NCHC.org.tw.    43200   IN  A   140.110.143.75
ns1.NCHC.org.tw.    43200   IN      2001:e10:2000:10::1
ns2.NCHC.org.tw.    43200   IN      2001:e10:2000:4::1

;; Query time: 0 msec
;; SERVER: 140.110.16.1#53(140.110.16.1)
;; WHEN: Wed Apr 18 11:35:04 CST 2018
;; MSG SIZE  rcvd: 237

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

[Arnaud Fontaine]

Hi,

[Cc'ing the ITP FTR]

I have  almost finished preparing emacs-snapshot  and temporarily pushed
it there, so  please have a look when  you have some time as  I may have
messed things around ;-):
  https://salsa.debian.org/arnau/deb-emacs

I have a few questions though:

  * bin_priority (for update-alternatives): I  think it would make sense
to have  an higher one for  emacs-snapshot, what about a  number big
enough so it doesn't clash with future stable release (such as 999)?

  * Currently emacs-snapshot version is:
2:MMDD--g-1

Considering  that this  is not  really the  LATEST_AVAILABLE_TAG but
MASTER_COMMIT_ID at  the time of  packaging and in order  to shorten
the version  which is  currently rather long,  MASTER_COMMIT_ID only
should be  enough, isn't it?

This would mean  having something like this after  bumping the epoch
and where the first '-1' is only  in case of we upload two different
Git snapshots on the same day:
3:MMDD-1+git-1

What do you think?

  * I put  myself as Maintainer, and  Rob and Dima as  Uploaders, but if
either Rob or Dima wish to be in the Maintainer field, please let me
know as either is fine to me.

  * I was  thinking about having  deb-emacs repository for  both emacs25
and emacs-snapshot in  collab-maint Git (as emacs.git)  instead of a
user repository. What do you think?

  * Rob: I  have made several  changes to  emacs25 branch, feel  free to
merge them if they look fine to you:
https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master

And some packaging questions I will add to debian/README.source:

  * Dima is using gbp-pq  and Rob git-dpm. In order to  keep it as close
as  possible to  emacs25 packaging,  I have  been using  git-dpm.  I
don't really well both of them as  this is the first time I use them
so I have absolutely no opinion on this. Dima: is that ok?

Rob:  I  ran the  following  command  after importing  patches  from
emacs25  and merging  them with  the ones  from emacs-snapshot  from
Dima:
$ git-dpm init --record-patch-name 
../emacs-snapshot_20180414-1+git836dce6.orig.tar.xz 
deb/emacs-snapshot/d/sid/upstream

However,  I'm  not so  familiar  with  git-dpm,  so would  you  mind
explaining how you use it for emacs25?

  * Rob: I followed your naming scheme for branches and tags, thus:
+ Branches:
  deb/emacs-snapshot/d/sid/master
  deb/emacs-snapshot/d/sid/upstream
+ Tags:
  deb/emacs-snapshot/v/upstream/20180414-1+git836dce6

  * Rob: Could you please explain  how you remove non-DFSG documentation
(such as emacs.texi) from the Git repository?

  * Here is what I have been using to create a new upstream release from
deb/emacs-snapshot/d/sid/master branch:

$ git tag -s -m "Upstream tagged for Debian version 20180414-1+git836dce6." 
deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 
deb/emacs-snapshot/d/sid/upstream
$ gbp buildpackage --git-builder=/bin/true 
--git-upstream-tree=deb/emacs-snapshot/v/upstream/20180414-1+git836dce6
  =>  Thanks to  debian/gbp.conf  I added,  this will  automatically
 generate  the tarball  with pristine-tar.  If that's  ok, maybe
 debian/gbp.conf should be added to emacs25 branch too?

Cheers,
-- 
Arnaud


signature.asc
Description: PGP signature

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[Paul Wise]

On Wed, Apr 18, 2018 at 2:00 AM, Giovanni Mascellani wrote:

> Detachtty was removed from Debian because it was dead upstream. Now the
> upstream development has been resumed by another developer, so it is
> sensible to repackage it.

Please note the extra steps required when reintroducing packages:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#889530: acm FTBFS with gdbm 1.14.1-2

[Markus Koschany]

Control: tags -1 pending

Dear maintainer,

I've uploaded a new revision of acm versioned as 5.0-29.2 to fix Debian
bug #889530.

In addition I switched to compat level 11 because compat level 6 is
deprecated and will lead to another RC bug in the near future.
Furthermore I ensured that the -dbgsym package is built correctly and
format-not-a-string-literal errors were fixed as well. The rest were
some cosmetic changes like removing trailing whitespace and ordering
some lines.

The game builds fine again but I noticed the black screen and even a
segmentation fault which seems related to #765815.

Please find attached the debdiff.

Regards,

Markus
diff -u acm-5.0/debian/acm.dirs acm-5.0/debian/acm.dirs
--- acm-5.0/debian/acm.dirs
+++ acm-5.0/debian/acm.dirs
@@ -9 +8,0 @@
-
diff -u acm-5.0/debian/changelog acm-5.0/debian/changelog
--- acm-5.0/debian/changelog
+++ acm-5.0/debian/changelog
@@ -1,3 +1,17 @@
+acm (5.0-29.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on libgdbm-compat-dev and fix the FTBFS with newer gdbm
+versions. (Closes: #889530)
+  * wrap-and-sort -sa.
+  * Switch to compat level 11 (was 6).
+  * d/rules: Use the correct dpkg buildflag variable CFLAGS instead of
+DEBCFLAGS. This will also ensure that the -dbgsym package is created
+correctly.
+  * Fix error "format-not-a-string-literal".
+
+ -- Markus Koschany   Wed, 18 Apr 2018 03:18:08 +0200
+
 acm (5.0-29.1) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -63,7 +77,7 @@
   * Update to standards-version 3.8.2.
   * Replaced build-dependency on x-dev with x11proto-core-dev
 (closes: #515356).
-  * Bump debian/compat to 6 and build-depends on debhelper.
+  * Bump debian/compat to 6 and build-depends on debhelper.
   * Now refer to GPL-2 common licence, not the GPL.
   * Adjust copyright notice in debian/copyright to add dates.
 
@@ -100,7 +114,7 @@
   * Applied patch from Mohammed Adnène Trojette:
   * Correct copyright file to show original source (closes: #372495).
   * Bump standards-version to 3.7.2 (no changes needed).
-  * Added PostScript version of acmdoc.rtf (HTML conversion lost images) 
+  * Added PostScript version of acmdoc.rtf (HTML conversion lost images)
 (closes: #372496).
 
  -- Phil Brooke   Sat, 10 Jun 2006 14:01:11 +0100
@@ -124,7 +138,7 @@
 
 acm (5.0-19) unstable; urgency=low
 
-  * Applied patch from Andreas Jochens to fix dis/sdbm/util.c so that 
+  * Applied patch from Andreas Jochens to fix dis/sdbm/util.c so that
 acm builds with amd64/gcc-3.4 (Closes: #280272).
 
  -- Phil Brooke   Thu, 11 Nov 2004 18:50:05 +
@@ -146,7 +160,7 @@
 
 acm (5.0-16) unstable; urgency=low
 
-  * Adding missing includes to prevent `assignment makes pointer from 
+  * Adding missing includes to prevent `assignment makes pointer from
 integer without a cast' warnings that are fatal on ia64
 (Closes: #226558).
   * Cleaned up similar warnings from audio.c.
@@ -237,7 +251,7 @@
 acm (5.0-6) unstable; urgency=low
 
   * Folding in suggested changes to audio code from Giuseppe Borzi'.
-  * Added -dis-silent switch.  
+  * Added -dis-silent switch.
   * More comments added to README.Debian.
 
  -- Phil Brooke   Tue, 16 Jul 2002 13:20:25 +0100
diff -u acm-5.0/debian/compat acm-5.0/debian/compat
--- acm-5.0/debian/compat
+++ acm-5.0/debian/compat
@@ -1 +1 @@
-6
+11
diff -u acm-5.0/debian/control acm-5.0/debian/control
--- acm-5.0/debian/control
+++ acm-5.0/debian/control
@@ -2,12 +2,23 @@
 Section: games
 Priority: optional
 Maintainer: Phil Brooke 
-Build-Depends: debhelper (>> 6.0.0), libx11-dev, libxext-dev, 
x11proto-core-dev, libgdbm-dev, libaudio-dev, libelfg0-dev [hurd-i386], 
sharutils
+Build-Depends:
+ debhelper (>= 11),
+ libaudio-dev,
+ libelfg0-dev [hurd-i386],
+ libgdbm-compat-dev,
+ libgdbm-dev,
+ libx11-dev,
+ libxext-dev,
+ sharutils,
+ x11proto-core-dev
 Standards-Version: 3.9.6
 
 Package: acm
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends}
 Description: Multi-player classic aerial combat simulation
  A multiplayer aerial combat simulation. Players engage in air to air
  combat against one another using heat seeking missiles and cannons.
@@ -25,2 +35,0 @@
-
-
diff -u acm-5.0/debian/copyright acm-5.0/debian/copyright
--- acm-5.0/debian/copyright
+++ acm-5.0/debian/copyright
@@ -9,14 +9,14 @@
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; version 2 dated June, 1991.
-  
+
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
-  
+
   You should have received a copy of the GNU General Public License
-  along with this program;  if not, write to the 
+  along with th

Bug#887107: [Debian-l10n-devel] https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23 - too much packages to add to the ignore_list

[Nicolas François]

Hi Laura,

2018-04-17 16:39 GMT-07:00 Laura Arjona Reina :
> Unable to open /srv/mirrors/debian//pool/main/g/gcc-5/gcc-5_5.5.0.orig.tar.gz
at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
> read() on closed filehandle GEN3287 at /srv/i18n.debian.org//dl10n/
git/lib/Debian/Pkg/Tar.pm line 176.
> Failed to read 
> `/srv/mirrors/debian//pool/main/g/gcc-5/gcc-5_5.5.0.orig.tar.gz':
Bad file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
> 'x' outside of string in unpack at /srv/i18n.debian.org//dl10n/
git/lib/Debian/Pkg/Tar.pm line 368.

> I am sorry but I'm giving up adding packages as exception, we have a
> long list already and we're only in letter "g".
>
> I've had a look at the code but frankly I have no idea about how to
> solve this problem :(

Can you try adding
$text = undef;
after the line 178 in
https://salsa.debian.org/l10n-team/dl10n/blob/master/lib/Debian/Pkg/Tar.pm

You will still have the error messages (Unable to open..., read() on closed
filehandle..., Failed to read...) but I hope this will avoid the crash ('x'
outside of string in unpack...)
(sorry, I could not test).

Note: The tools were designed at a time when CPU and disk were limited
(there might have been more diversity in the packaging formats). This may
not be the case now, and if somebody is interested in a (major) rewrite, it
might be easier to just extract each source packages using dpkg-source (+
heuristic to apply patches) than to do this in-memory extract and patch
mechanism.

Regards,
-- 
Nekral

Bug#895966: libvirt-daemon: Should suggest/recommend/depend systemd-container (redo #822581)

[Matthew Gabeler-Lee]

Package: libvirt-daemon
Version: 3.0.0-4+deb9u3
Severity: normal

This is a followup to #822581, which has been archived and thus I can't seem
to reopen it, and direct mail to the maintainer also bounced (bad ipv6
config somewhere in the path it seems).

After a long time of not being able to make sense of why I was having
problems, and the maintainer not, I think I was able to track down the issue
via some thinking and some UTSL.  I think another detail of the issue is
that the problem may only manifest on package upgrades, and that removing
but not *purging* systemd-container might mask the issue as well.

The mail I tried to send as a followup to #822581 follows:

On Thu, 14 Sep 2017, Guido Günther wrote:

> On Sun, Jul 31, 2016 at 08:21:22PM +0200, Guido Günther wrote:
>> I just tried to reproduce with 2.1.0-rc1 and I can't reproduce this. Are
>> you still seeing this with recent versions? If so please provide logs
>> (the containers log and libvirtds log would be a start).
>
> Closing since things work here and there was no submitter feedback for
> over a year.

I'm not having exactly the same problem as before, but I am still seeing 
that systemd-container is needed for proper operation of libvirt for lxc 
guests.  Without it I'm having problems with it tracking running guests 
across restarts.  I'm finding that there end up with two copies of the 
guest running, but only one of them does libvirt know about.  This 
causes all kinds of hyper-bizarro confusion within the guest -- there's 
two copies of systemd, of rsyslog, cron, etc., all working from the same 
system image.  But the one systemd doesn't know about has lost its 
network connectivity, so I generally can't do much other than just kill 
it.

I think a bit of UTSL has allowed me to track down the root of this 
problem and its connection to the systemd-container package.

When the lxc driver starts up, it tries to reconnect to the running 
guests -- check the Reconnect methods in lxc_process.c, called initially 
from the lxcStateInitialize method in lxc_driver.c

The Reconnect methods /seem/ to be at least partly dependent upon 
virSystemdGetMachineNameByPID (also in lxc_process.c), at least when 
running under systemd (which of course is the norm in Debian).

That method is in turn dependent on the org.freedesktop.machine1 DBus 
service.

And that service is only available if systemd-container is installed.

Extra fun: the dbus service file is a conf file, so a normal apt remove 
systemd-container won't remove it, which seems like it could confuse 
testing this issue.

-- 
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
 -- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/12 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 depends on:
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.27-3
ii  libcap-ng0  0.7.7-3+b1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdevmapper1.02.1  2:1.02.137-2
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.8-5+deb9u3
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libparted2  3.2-17
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1+b2
ii  librados2   10.2.5-7.2
ii  librbd1 10.2.5-7.2
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b3
ii  libssh2-1   1.7.0-1
ii  libudev1232-25+deb9u2
ii  libvirt03.0.0-4+deb9u3
ii  libxen-4.8  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  libxenstore3.0  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-2.2+deb9u2
ii  netcat-openbsd  1.130-3
ii  qemu1:2.8+dfsg-6+deb9u3
ii  qemu-kvm1:2.8+dfsg-6+deb9u3

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  3.0.0-4+deb9u3
pn  numad  

-- no debconf information

Bug#895965: FTBFS: needs to be patched for newer persistent

[Clint Adams]

Source: haskell-esqueleto
Version: 2.5.3-2
Severity: serious
Forwarded: https://github.com/bitemyapp/esqueleto/issues/80

.

Bug#895964: par.1: Minor correction to the manual

[Bjarni Ingi Gislason]

Package: par
Version: 1.52-3+b2
Severity: minor
Tags: patch

Dear Maintainer,

  Let macro "LP" come before macro "RS"

  Change ".BI" to ".B" for one argument

  Request ".ps" does not accept any scale indicator

  Change "." to ".\&" when the period does not end a sentence
  
  Change "!" to "!\&" when the exclamation mark does not end a sentence

  Delete a repeated word "a".

***

More explicit explanations:

Input file is par.1

mandoc: par.1:73:2: WARNING: skipping paragraph macro: LP empty
mandoc: par.1:1053:2: WARNING: skipping paragraph macro: LP empty
mandoc: par.1:1091:2: WARNING: skipping paragraph macro: LP empty

###

Test nr. 2:

Enable and fix warnings from 'test-groff'.

:1148 (macro BI): only 1 argument, but more are expected
:1153 (macro BI): only 1 argument, but more are expected
:1160: backtrace: macro 'VS'
troff: :1184: warning: only 'z' and 'u' scale indicators valid in this 
context

chk_manuals: Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z 


#

Test nr. 15:

Change the name of a macro for two fonts (e.g., BR and IR) to one
letter, if there is only one argument.
Add the second argument if needed.  It is sometimes part of the first
one.

1148:.BI E
1153:.BI E

#

Test nr. 23:

Move a full stop (period) and a comma outside of a quoted text, if it is
at the end of the quote and does not end a quoted sentence.

1756:amc> Par should not mistake "." for a suffix.
1770:amc> should not mistake "." for a suffix.

#

Test nr. 26:

Find a repeated word

! 301 --> a

#

Test nr. 28:

Wrong distance between sentences or protect the indicator.

1) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) and "info groff".

Or

2) Adjust space between sentences (two spaces),

3) or protect the indicator by adding "\&" after it.

The "indicator" is an "end-of-sentence character" (.!?).

1236:features of an editor, such as the ! commands of
1260:\*Q\fB**\fP\*U (star star). If you need to supply

Test nr. 30:

Surround a block of comments with the macros ".ig" and "..".
The .\" (\#) at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust length of lines.

NO PATCH

1:.\"*
2:.\"* par.1 *
3:.\"* for Par 1.52  *
4:.\"* Copyright 2001 by *
5:.\"* Adam M. Costello  *
6:.\"*
7:.\"
8:.\" This is nroff -man (or troff -man) code.
9:.\"

#

  The patch:

--- par.1   2007-08-27 06:10:44.0 +
+++ par.1.new   2018-04-17 22:09:19.0 +
@@ -69,8 +69,8 @@ section).
 .LP
 Each output paragraph is generated from the
 corresponding input paragraph as follows:
-.RS
 .LP
+.RS
 .IT 1) An optional prefix and/or suffix
 is removed from each input line.
 .IT 2) The remainder is divided into
@@ -298,7 +298,7 @@ bodiless for some
 .IP "order \fIk\fP bodiless line"
 There is no such thing as an order 0 bodiless line.  Suppose
 .I S
-is a a contiguous subsequence of a segment (see below)
+is a contiguous subsequence of a segment (see below)
 containing at least two lines, containing no order
 .IR k \-1
 bodiless lines, bounded above and below by order
@@ -1049,8 +1049,8 @@ be the fallback suflen of the IP.  The
 characters which are prepended to the
 .IR i th
 line are chosen as follows:
-.RS
 .LP
+.RS
 .IT 1) If
 .I i
 <=
@@ -1087,8 +1087,8 @@ Then to each line is appended
 characters.  The characters which are appended to the
 .IR i th
 line are chosen as follows:
-.RS
 .LP
+.RS
 .IT 1) If
 .I i
 <=
@@ -1145,19 +1145,19 @@ or environment variable syntax are accom
 the same usage message that the help option produces.
 .LP
 Unless the option
-.BI E
+.B E
 is set, trying to print an error message would be
 futile if an error resulted from an output function, so
 .B par
 doesn't bother doing any error checking on output functions if
-.BI E
+.B E
 is 0.
 .SH EXAMPLES
 .de VS
 .RS -.5i
 .LP
 .nf
-.ps -1p
+.ps -1
 .vs -2p
 .ft CW
 ..
@@ -1233,7 +1233,7 @@ are clearly more eye-pleasing.
 .LP
 .B par
 is most useful in conjunction with the text-filtering
-features of an editor, such as the ! commands of
+features of an editor, such as the !\& commands of
 .BR vi .
 You may wish to add the following lines to your
 .B .exrc
@@ -1257,7 +1257,7 @@ following the ctrl-V, plus one at the en
 To reformat a simple paragraph delimited by blank lines in
 .BR vi ,
 you can put the cursor anywhere in it and type
-\*Q\fB**\fP\*U (star star). If you need to supply
+\*Q\fB**\fP\*U (star star).  If you need to supply
 arguments to par, you can type \*Q\fB*\ \fP\*U
 (star space) instead, then type the arguments.
 .LP
@@ -1753,7 +1753,7 @@ Before:
 amc>
 amc> Par still pays attention to body characters.
 amc> Par should not mistake "Par" for part of the prefix.
-amc> Par should not mistake "." for a suffix.
+amc> Par should not mistake ".\&" for a suffix.
 .VE
 .LP
 After
@@ -1767,7 +1767,7 @@ Aft

Bug#895963: diffstat.1: Minor corrections to the manual

[Bjarni Ingi Gislason]

Package: diffstat
Version: 1.61-1+b1
Severity: minor
Tags: patch

Dear Maintainer,

Input file is diffstat.1

Test nr. 2:

Enable and fix warnings from 'test-groff'.

:82 (macro BI): only 1 argument, but more are expected
:89 (macro BI): only 1 argument, but more are expected
:185 (macro BI): only 1 argument, but more are expected

chk_manuals: Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z 

  and

Test nr. 15:

Change the name of a macro for two fonts (e.g., BR and IR) to one
letter, if there is only one argument.
Add the second argument if needed.  It is sometimes part of the first
one.

82:.BI \-d
89:.BI \-E
185:.BI \-s

#

Test nr. 20:

Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them
  or
add the italic corrections.
[1] man-pages(7)

87:redirect standard error to \fIfile\fR.
150:redirect standard output to \fIfile\fR.

#

Test nr. 27:

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause.

diffstat.1: line 30 length 84
diffstat.1: line 195length 85
diffstat.1: line 204length 87
diffstat.1: line 251length 82

#

Test nr. 30:

Surround a block of comments with the macros ".ig" and "..".
The .\" (\#) at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust length of lines.

NO PATCH

1:.\"*
2:.\" Copyright 1994-2014,2016 by Thomas E. Dickey  
 *
3:.\" All Rights Reserved.  
 *
4:.\"   
 *
5:.\" Permission to use, copy, modify, and distribute this software and its 
 *
6:.\" documentation for any purpose and without fee is hereby granted, provided 
 *
7:.\" that the above copyright notice appear in all copies and that both that   
 *
8:.\" copyright notice and this permission notice appear in supporting  
 *
9:.\" documentation, and that the name of the above listed copyright holder(s)  
 *
10:.\" not be used in advertising or publicity pertaining to distribution of 
the  *
11:.\" software without specific, written prior permission. 
  *
12:.\"  
  *
13:.\" THE ABOVE LISTED COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD 
  *
14:.\" TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
AND  *
15:.\" FITNESS, IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT HOLDER(S) BE 
LIABLE  *
16:.\" FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  *
17:.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  *
18:.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
OR *
19:.\" IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.  
  *
20:.\"*
21:.\" $Id: diffstat.1,v 1.35 2016/01/14 09:39:26 tom Exp $

#

Test nr. 40:

Add a comma before "and", "or", or "nor" if a series contains three or
more words

34:If the input filename ends with .bz2, .gz, .lzma, .z or .Z,
56:These are shown in the histogram as "+", "\-" and "!" characters.
195:changed lines found in the differences for each file: inserted, deleted and 
modified.

#

  Patch:

--- diffstat.1  2018-04-17 23:46:52.0 +
+++ diffstat.1.new  2018-04-17 23:03:20.0 +
@@ -27,11 +27,12 @@
 .SH DESCRIPTION
 This program reads the output of \fBdiff\fP and displays a histogram
 of the insertions, deletions, and modifications per-file.
-\fBDiffstat\fP is a program that is useful for reviewing large, complex patch 
files.
+\fBDiffstat\fP is a program that is useful for reviewing large,
+complex patch files.
 It reads from one or more input files which contain output from \fBdiff\fP,
 producing a histogram of the total lines changed for each file referenced.
 .PP
-If the input filename ends with .bz2, .gz, .lzma, .z or .Z,
+If the input filename ends with .bz2, .gz, .lzma, .z, or .Z,
 \fBdiffstat\fP will read the
 uncompressed data via a pipe from the corresponding program.
 It also can infer the compression type from files piped via the standard input.
@@ -53,7 +54,7 @@ not good for much, but simple to generat
 tell which files are compared, and then counts the markers in the
 first column that denote the type of change (insertion, deletion
 or modification).
-These are shown in the histogram as "+", "\-" and "!" characters.
+These are shown in the histogram as "+", "\-", and "!" characters.
 .PP
 If no filename is given on the command line,
 \fBdiffstat\fP reads the differences from the standard input.
@@ -79,14 +80,15 @@ to obtain the total number of lines in e
 The rema

Bug#731802: [PATCH] Fix second-stage failure within systemd-nspawn and it also bring another fix on lxc

[Hideki Yamane]

Here's a patch for both bugs, just check under /proc.


>From df9ee36d23141a08834c7f4c778e4b01424bbab6 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Tue, 17 Apr 2018 23:46:16 +0900
Subject: [PATCH] Fix second-stage failure within systemd-nspawn (Closes:
 #840372)

And it also bring another fix on lxc (Closes: #731802)
---
 functions | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/functions b/functions
index 005b007..eb70d72 100644
--- a/functions
+++ b/functions
@@ -1133,12 +1133,16 @@ setup_proc () {
umount_on_exit /proc
umount_on_exit /proc/bus/usb
umount "$TARGET/proc" 2>/dev/null || true
-   in_target mount -t proc proc /proc
-   if [ -d "$TARGET/sys" ] && \
-  grep -q '[[:space:]]sysfs' /proc/filesystems 2>/dev/null; 
then
-   umount_on_exit /sys
-   umount "$TARGET/sys" 2>/dev/null || true
-   in_target mount -t sysfs sysfs /sys
+   # if systemd-nspawn is used at second-stage, it already treats 
/proc and so on
+   # and also fix failure on lxc environment
+   if [ ! -n "$(ls -A /proc)" ]; then
+   in_target mount -t proc proc /proc
+   if [ -d "$TARGET/sys" ] && \
+  grep -q '[[:space:]]sysfs' /proc/filesystems 
2>/dev/null; then
+   umount_on_exit /sys
+   umount "$TARGET/sys" 2>/dev/null || true
+   in_target mount -t sysfs sysfs /sys
+   fi
fi
on_exit clear_mtab
;;
-- 
2.17.0

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[積丹尼 Dan Jacobson]

OK, I get it. So just like saying
Depends: x, x
or
Depends: x
Depends: x
twice is so ridiculous that it doesn't need to be explicitly mentioned as bad.

Bug#895962: kio: http.so resource leak causing background CPU usage

[Julien Goodwin]

Package: kio
Version: 5.44.0-2
Severity: normal


http.so seems to have some form of resource leak, leading to constant
background CPU use. This occurs for processes launched for both akregator
& choqok, stracing affect http.so processes shows constant:

ppoll([{fd=4, events=POLLIN}], 1, {tv_sec=0, tv_nsec=100}, NULL, 8) = 0 
(Timeout)
write(3, "\1\0\0\0\0\0\0\0", 8)

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

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

Versions of packages kio depends on:
ii  libacl1   2.2.52-3+b1
ii  libc6 2.27-3
ii  libgcc1   1:8-20180402-1
ii  libgssapi-krb5-2  1.16-2
ii  libkf5archive55.44.0-1
ii  libkf5auth5   5.44.0-1
ii  libkf5codecs5 5.44.0-1
ii  libkf5completion5 5.44.0-1
ii  libkf5configcore5 5.44.0-1
ii  libkf5configwidgets5  5.44.0-1
ii  libkf5coreaddons5 5.44.0-1
ii  libkf5dbusaddons5 5.44.0-1
ii  libkf5doctools5   5.44.0-1
ii  libkf5i18n5   5.44.0-1
ii  libkf5itemviews5  5.44.0-1
ii  libkf5kiocore55.44.0-2
ii  libkf5kiontlm55.44.0-2
ii  libkf5kiowidgets5 5.44.0-2
ii  libkf5notifications5  5.44.0-1
ii  libkf5service-bin 5.44.0-1
ii  libkf5service55.44.0-1
ii  libkf5solid5  5.44.0-1
ii  libkf5textwidgets55.44.0-1
ii  libkf5wallet-bin  5.44.0-1
ii  libkf5wallet5 5.44.0-1
ii  libkf5widgetsaddons5  5.44.0-1
ii  libkf5windowsystem5   5.44.0-1
ii  libqt5core5a  5.10.1+dfsg-5
ii  libqt5dbus5   5.10.1+dfsg-5
ii  libqt5gui55.10.1+dfsg-5
ii  libqt5network55.10.1+dfsg-5
ii  libqt5script5 5.10.1+dfsg-2
ii  libqt5widgets55.10.1+dfsg-5
ii  libqt5x11extras5  5.10.1-2
ii  libqt5xml55.10.1+dfsg-5
ii  libstdc++68-20180402-1
ii  libxml2   2.9.4+dfsg1-6.1
ii  libxslt1.11.1.29-5

kio recommends no packages.

kio suggests no packages.

-- no debconf information

Bug#895008: Kicad 5 RC build

[Julien Goodwin]

I'd like to try the RC of kicad5 that's mentioned in #40, but that
directory doesn't include the various data packages for kicad-libraries,
do you have a build of those?

FYI testing has now received a new set of KDE & QT packages, so
downgrading is not really practical any more.

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23 - too much packages to add to the ignore_list

[Laura Arjona Reina]

Hello again

El 18/04/18 a las 01:00, Laura Arjona Reina escribió:
> Hello
> After running the gen-material script several times adding as exceptions
> the packages that were producing errors, I don't know if it makes sense
> to go on this way. It seems that en each run, one or two new packages
> produce errors.

Indeed, this is the last error log:

---
cat /srv/i18n.debian.org/log/gen-material/gen-material.20180417-2241.err
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/fr.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_fr.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/ru.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_ru.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/oc.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_oc.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/da.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_da.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/lt.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_lt.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/s...@latin.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2...@latin.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/gl.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_gl.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/sr.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_sr.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/nb.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_nb.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/zh_CN.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_zh_CN.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/hu.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_hu.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/eu.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_eu.po.gz":
No such file or directory
Cannot run: gzip -9f -c
"/srv/i18n.debian.org//tmp/gen-material/gcab/po/cs.po" >
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/g/gcab/po/gcab_1.1-2_cs.po.gz":
No such file or directory
Unable to open
/srv/mirrors/debian//pool/main/g/gcc-3.3/gcc-3.3_3.3.6ds1.orig.tar.gz at
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Unable to open
/srv/mirrors/debian//pool/main/g/gcc-5/gcc-5_5.5.0.orig.tar.gz at
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Unable to open
/srv/mirrors/debian//pool/main/g/gcc-5/gcc-5_5.5.0.orig.tar.gz at
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN3287 at
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.
Failed to read
`/srv/mirrors/debian//pool/main/g/gcc-5/gcc-5_5.5.0.orig.tar.gz': Bad
file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
'x' outside of string in unpack at
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 368.
---

I am sorry but I'm giving up adding packages as exception, we have a
long list already and we're only in letter "g".

I've had a look at the code but frankly I have no idea about how to
solve this problem :(

Regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#895893: Bug#895945: gqrx-sdr is not starting due to missing libvolk.so.1.3

[A. Maitland Bottoms]

You seem to be unlucky and encountered some race condition as
libvolk1.4, gnuradio 3.7.12.0 and the rebuild of gqrx-sdr against
gnuradio 3.7.12 transitioned from unstable to testing.

I did need to fix the desktop mime install and iterate on gnuradio
uploads, which I think got the libvolk auto-transition logic out of
sync.

But today I see your bugs, but I get home and update my testing box, I
see a consistent set of packages updating, and it left me with a
working gqrx. So, I am unable to reproduce what you saw.

I do hope a quick update and upgrade of your testing box brings you
back to a working setup.

At this time Debian's gnuradio is a bit ahead of upstream stable
releases, as I have included Qt5 patches from gnuradio development in
order to meet Debian's goal for Buster to remove Qt4. Since it may be a
while yet before a gnuradio 3.8 release, it seems useful to backport
3.7.12.0 for stable Debian users.

gqrx update coming soon, thanks to Alex for making things better.

-Maitland

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Hi,

Dimitri John Ledkov  (2018-04-17):
> First, I apologize for not responding to this email earlier, as I have
> missed it in my mailbox.

It's a mail from hours ago, so there's no apology needed.

> Secondly, my work has been blocked by this NEW processing too for
> btrfs-progs. I'm not aware as to which Helmut's work was blocked,
> could you please elaborate what Helmut is blocked on? And/or how can
> libzstd/me help to unblock Helmut? -> is that about patches for
> crossbuilding that are part of

[sentenced cut in the middle but] Yes, Helmut works quite a lot on
crossbuilding and commits sitting in git master looked like what he was
alluding to.

> Now to respond to your main inquiry. I find the tone of above message
> unacceptable. It reads accusational to me, rather than inquisitive.
> 
> It would have been much better to state:
> "I notice that a call to dh_makeshlibs does not pass the -V flag as it
> is custom for many libraries. Why have you not specified a minimum
> required version in this case?"

I suppose that's a fair way to word it. But I did mean to point out that
packages having an impact on the installer should be reviewed by the
installer team, at least for their initial addition; as I tried to make
people aware a few times already (dda@, talks, replies to threads where
udeb additions were mentioned, etc.); since that simple and natural
process wasn't followed here, I did point that out.

> It also feels like you (or others who were made aware of this lack of
> -V) possibly wanted to make this a bug report, and follow-on out of
> band events made it seem like it was felt that it is RC buggy and
> shouldn't clear NEW and/or migrate to testing if passed NEW. In that
> case  a new bug report should have been opened, with above request at
> an RC priority.

I didn't comment on the fact it should get accepted or rejected from
NEW. People pointed me to the udeb addition that probably get some input
from me, so I've briefly looked at it and spotted that issue.

> However, it is good to point out at this time, that udeb version of
> libraries do not currently ship or use symbols files at all to
> generate dependencies.
> But also note that since libzstd1-udeb is a brand new package, any
> version of thereof would correctly and strictly satisfy any udeb
> package that gains a dependency on it. There are no linking or
> dependency bugs in above libzstd1, nor udeb edition of the binary
> packages.

I'm not sure why stashing a -V there once and for all to be future-proof
wouldn't be adequate or desireable. People can argue all they like about
whether the package is RC buggy in this specific revision, but it seems
rather pointless, I really do care about mid/long-term maintenance. I
have enough on my plate to not want to monitor such packages closely,
and open a specific bug report in their next revision…

> This is no different to some other library udebs, e.g. liblzo2-2-udeb

That's another perfect example why udeb additions should get reviewed:
we would have noticed another buggy package, and its bugginess might not
have been copied over to another package.

> Personally, I find it odd to have minimum -V arg version dependencies
> for udebs only, when symbols are present for the deb edition of the
> library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
> btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
> immense amount of pain, when rebuilding packages locally, mixing &
> matching packages when debugging issues in d-i, and does not at all
> correctly generate private dependencies for udebs that use e.g.
> @GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
> 2.28) style dependency instead. I'm not sure where/how .symbols should
> be used or shipped, to start generate genuinely correct version
> dependencies for udebs across the board. Debhelper? Dpkg?

I have done my share part of performing local builds and various
combinations of udebs, and I never experienced this “immense amount of
pain”.

Are you volunteering to introduce separate symbols support for udebs to
all the required components and to maintain it over time?

> Based on all of the above, I believe libzstd1, and libzstd1-udeb are
> both policy complaint as previously uploaded.

I like the typo.

> If you are still concerned about minimum version dependencies which
> are generated by packages that build/link/gain dependency on libzstd1
> and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
> open a new (or clone this) bug report against libzstd for
> consideration. I also welcome references from the Debian Policy to
> educate myself further about library dependencies, and if and how,
> this package is not policy complaint and pointers on how to best fix
> it.

I'm not sure what the issue is with talking to the debian installer team
when you're touching udeb packages and trusting their assessment?

If someone wants to drive an effort to make -V a must for udebs in
policy, that'

Bug#895473: ca-certificates: Post-install script subprocess return error exit status 3 while upgrading

[Brian Murray]

In Ubuntu I encounter this issue when upgrading ca-certificates from
20170717~16.04.1 (Ubuntu 16.04) to 20180409 (Ubuntu 18.04) when the
package python-ubuntu-sso-client (only available in Ubuntu 16.04) is
also installed. The python-ubuntu-sso-client package put
"/etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem" on disk. Here's the
error:

Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
rehash: skipping duplicate certificate in Go_Daddy_Class_2_CA.pem
dpkg: error processing package ca-certificates (--configure):
 subprocess installed post-installation script returned error exit
status 1
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Errors were encountered while processing:
 ca-certificates
E: Sub-process /usr/bin/dpkg returned an error code (1)

(xenial-amd64)root@impulse:/home/bdmurray/source-trees/ubuntu-release-upgrader#
update-ca-certificates --fresh
Clearing symlinks in /etc/ssl/certs...
done.
Updating certificates in /etc/ssl/certs...
rehash: skipping duplicate certificate in Go_Daddy_Class_2_CA.pem
(xenial-amd64)root@impulse:/home/bdmurray/source-trees/ubuntu-release-upgrader#
echo $?
1

Perhaps that'll help recreating the issue.

The Ubuntu bug report is at http://launchpad.net/bugs/1764848.

--
Brian Murray @ubuntu.com

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23 - too much packages to add to the ignore_list

[Laura Arjona Reina]

Hello
After running the gen-material script several times adding as exceptions
the packages that were producing errors, I don't know if it makes sense
to go on this way. It seems that en each run, one or two new packages
produce errors.

I believe some errors are being produced due to this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748716
l10n scripts should not look at upstream debian/ of source/format 3.0
(quilt) packages

And others in problems in this script:

https://salsa.debian.org/l10n-team/dl10n/blob/master/lib/Debian/Pkg/Tar.pm

If anybody with Perl skills can give a hand, it's appreciated.

OTOH, I don't know if this bug should be reasigned to the dl10n package.
I see there are other bugs there and even some patches, but I don't know
if the dl10n package uses a different repo as source. The version
uploaded to sid and the version in
https://salsa.debian.org/l10n-team/dl10n are not the same; I don't know
if this is just because the contents of the dl10n repo have not been
uploaded to sid recently.

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#895961: debian-www: doc-debian package description links to invalid page

[annadane]

Package: debian-www
Severity: normal

Dear Maintainer,

https://packages.debian.org/sid/doc-debian (not just Sid, of course) links to 
ftp://ftp.debian.org/debian/doc/ - ftp is likely deprecated and it should 
instead link to http://ftp.debian.org/debian/doc/

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

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

Bug#895960: numactl: diff for NMU version 2.0.11-2.2

[dann frazier]

Package: numactl
Version: 2.0.11-2.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for numactl (versioned as 2.0.11-2.2) and
uploaded it to DELAYED/100. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru numactl-2.0.11/debian/changelog numactl-2.0.11/debian/changelog
--- numactl-2.0.11/debian/changelog	2016-12-21 11:27:02.0 -0700
+++ numactl-2.0.11/debian/changelog	2018-04-17 16:11:23.0 -0600
@@ -1,3 +1,24 @@
+numactl (2.0.11-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/Allow-building-on-ARM-systems.patch:
+- add __arm__ to avoid failure due to missing syscalls.
+- return -1 and set errno to ENOSYS on migrate_pages function
+  if __NR_migrate_pages is undefined, thanks Uwe Kleine-König
+  and Tiago Stürmer Daitx. Closes: #796802. LP: #1711478.
+  * Install memhog and migspeed. Closes: #882873. Thanks Manoj Iyer.
+  * debian/control: Correct project Homepage link. Closes: #894825.
+  * Bump Standards-Version to 4.1.4:
+- libnuma-dev is now Priority: optional (extra is deprecated).
+  * debian/patches/Add-NAME-section-to-numastat-manpage.patch: Add
+"NAME" section to manpage for proper parsing by commands like apropos
+and whatis.
+  * debian/numactl.docs: The upstream changelog is already installed
+as /usr/share/doc/numactl/changelog.gz, no need to install another
+copy.
+
+ -- dann frazier   Tue, 17 Apr 2018 16:11:23 -0600
+
 numactl (2.0.11-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru numactl-2.0.11/debian/control numactl-2.0.11/debian/control
--- numactl-2.0.11/debian/control	2016-12-21 10:45:09.0 -0700
+++ numactl-2.0.11/debian/control	2018-04-17 15:41:58.0 -0600
@@ -9,7 +9,7 @@
  dh-autoreconf,
  debhelper,
  dh-buildinfo, dh-autoreconf, debhelper (>= 9.20160114~)
-Homepage: http://oss.sgi.com/projects/libnuma/
+Homepage: https://github.com/numactl/numactl
 
 Package: numactl
 Multi-Arch: foreign
@@ -33,7 +33,7 @@
 
 Package: libnuma-dev
 Section: libdevel
-Priority: extra
+Priority: optional
 Multi-Arch: same
 Depends: ${misc:Depends}, libnuma1 (= ${binary:Version}), libc6-dev | libc-dev
 Architecture: linux-any
diff -Nru numactl-2.0.11/debian/numactl.docs numactl-2.0.11/debian/numactl.docs
--- numactl-2.0.11/debian/numactl.docs	2016-12-21 09:02:06.0 -0700
+++ numactl-2.0.11/debian/numactl.docs	2018-04-17 15:54:36.0 -0600
@@ -1,2 +1 @@
-CHANGES
 DESIGN
diff -Nru numactl-2.0.11/debian/numactl.install numactl-2.0.11/debian/numactl.install
--- numactl-2.0.11/debian/numactl.install	2016-12-21 09:02:06.0 -0700
+++ numactl-2.0.11/debian/numactl.install	2018-04-17 15:32:58.0 -0600
@@ -1,3 +1,5 @@
 debian/tmp/usr/bin/numactl
 debian/tmp/usr/bin/numastat
-debian/tmp/usr/bin/migratepages
\ No newline at end of file
+debian/tmp/usr/bin/memhog
+debian/tmp/usr/bin/migratepages
+debian/tmp/usr/bin/migspeed
diff -Nru numactl-2.0.11/debian/numactl.manpages numactl-2.0.11/debian/numactl.manpages
--- numactl-2.0.11/debian/numactl.manpages	2016-12-21 09:02:06.0 -0700
+++ numactl-2.0.11/debian/numactl.manpages	2018-04-17 15:39:35.0 -0600
@@ -1,3 +1,4 @@
 numactl.8
 numastat.8
-migratepages.8
\ No newline at end of file
+migratepages.8
+migspeed.8
diff -Nru numactl-2.0.11/debian/patches/Add-NAME-section-to-numastat-manpage.patch numactl-2.0.11/debian/patches/Add-NAME-section-to-numastat-manpage.patch
--- numactl-2.0.11/debian/patches/Add-NAME-section-to-numastat-manpage.patch	1969-12-31 17:00:00.0 -0700
+++ numactl-2.0.11/debian/patches/Add-NAME-section-to-numastat-manpage.patch	2018-04-17 16:11:23.0 -0600
@@ -0,0 +1,22 @@
+Description: Add "NAME" section to numastat manpage
+ The numastat manpage is missing a "NAME" section, which appears to be due
+ to a typo. This causes problems with commands like apropos and whatis.
+ .
+ Discovered by lintian(1):
+   https://lintian.debian.org/tags/manpage-has-bad-whatis-entry.html
+Author: dann frazier 
+Origin: upstream, https://github.com/numactl/numactl/commit/3a70a21b38371d1f0533bf6f23cba2baae029238
+Last-Update: 2018-04-17
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: numactl-2.0.11/numastat.8
+===
+--- numactl-2.0.11.orig/numastat.8
 numactl-2.0.11/numastat.8
+@@ -1,5 +1,5 @@
+ .TH "numastat" "8" "1.0.0" "Bill Gray" "Administration"
+-.SH "numastat"
++.SH NAME
+ .LP
+ \fBnumastat\fP \- Show per-NUMA-node memory statistics for processes and the operating system
+ .SH "SYNTAX"
diff -Nru numactl-2.0.11/debian/patches/Allow-building-on-ARM-systems.patch numactl-2.0.11/debian/patches/Allow-building-on-ARM-systems.patch
--- numactl-2.0.11/debian/patches/Allow-building-on-ARM-systems.patch	1969-12-31 17:00:00.0 -0700
+++ numactl-2.0.11/debian/patches/Allow-building-on-ARM-systems.patch	2018-04-17 16:11:23.0 -0600
@@ -0,0 

Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp

[Sebastian Andrzej Siewior]

Package: libnet-ssleay-perl
Version: 1.85-1
Severity: important

There is openssl 1.1.1-pre4 in experimental right now and
libnet-ssleay-perl fails the testsuite with it. I was playing with it
for the last month or so and already figured out a few things. This is
t/local/07_sslecho.t I refer here to.

The SSL_read() and SSL_write() wrapper need to handle a possible retry.
The man-page for both function [0] says that it might need to be retried
with the same arguments. With the following hunk:

diff --git a/SSLeay.xs b/SSLeay.xs
--- a/SSLeay.xs
+++ b/SSLeay.xs
@@ -1999,7 +1999,17 @@ SSL_read(s,max=32768)
int got;
 PPCODE:
New(0, buf, max, char);
-   got = SSL_read(s, buf, max);
+
+   do {
+   int err;
+
+   got = SSL_read(s, buf, max);
+   if (got > 0)
+   break;
+   err = SSL_get_error(s, got);
+   if (err != SSL_ERROR_WANT_READ)
+   break;
+   } while (1);
 
/* If in list context, return 2-item list:
 *   first return value:  data gotten, or undef on error (got<0)
@@ -2051,10 +2061,20 @@ SSL_write(s,buf)
  SSL *   s
  PREINIT:
  STRLEN len;
+ int err;
+ int ret;
  INPUT:
  char *  buf = SvPV( ST(1), len);
  CODE:
- RETVAL = SSL_write (s, buf, (int)len);
+ do {
+ret = SSL_write (s, buf, (int)len);
+if (ret > 0)
+break;
+err = SSL_get_error(s, ret);
+if (err != SSL_ERROR_WANT_WRITE)
+break;
+ } while (1);
+ RETVAL = ret;
  OUTPUT:
  RETVAL
 
@@ -2083,8 +2103,20 @@ SSL_write_partial(s,from,count,buf)
  if (len < 0) {
croak("from beyound end of buffer");
RETVAL = -1;
- } else
-   RETVAL = SSL_write (s, &(buf[from]), (count<=len)?count:len);
+ } else {
+int ret;
+int err;
+
+do {
+ret = SSL_write (s, &(buf[from]), (count<=len)?count:len);
+if (ret > 0)
+break;
+err = SSL_get_error(s, ret);
+if (err != SSL_ERROR_WANT_WRITE)
+break;
+} while (1);
+RETVAL = ret;
+ }
  OUTPUT:
  RETVAL

I was able to let the test-suite continue a little further. As per
upstream [1] this was always the case it worked by coincidence before.

The next thing is that step 24 within 07_sslecho.t blocks forever. As it
turns out one side does "shutdown $s, 2;" (around line 170) while the
other does a read+write operation. In "older" openssl is seems to just
work but in the newer one SIGPIPE is received and this seems to
stall/block the test case. By adding:

index 5e16b04b55ea..c60afccc0051 100644
--- a/t/local/07_sslecho.t
+++ b/t/local/07_sslecho.t
@@ -14,6 +14,7 @@ BEGIN {
 }
 
 plan tests => 78;
+$SIG{'PIPE'} = 'IGNORE';
 
 my $sock;
 my $pid;
(
 
it does not stall anymore but complains about the return value from
write:

ok 21 - get_cipher
ok 22 - get_shared_ciphers
ok 23 - ssl_read_all
not ok 24 - ssl_write_all
#   Failed test 'ssl_write_all'
#   at t/local/07_sslecho.t line 88.
ok 25 - new

This should be okay since the other side never reads anything and just
shutdowns the socket.

Could you please take a look and forward it upstream?

[0] https://manpages.debian.org/stretch/libssl-doc/SSL_read.3ssl.en.html#WARNING
[1] https://github.com/openssl/openssl/issues/5637#issuecomment-381364019

Sebastian

Bug#895958: Remove rnc-mode

[oldtechaa]

Package: rnc-mode
Severity: normal

Dear Maintainer,

rnc-mode is obsolete. The upstream website no longer exists, the only
versions ever released were beta, and the latest version released was in
2002. [1] Popcon shows 1 Vote user of 27 Inst users and the latest bugs in
this package are inactive, including an RC bug that blocked it for at least
stretch. Could we please remove this package?

oldtechaa

[1] https://web.archive.org/web/20100213005937/http://www.pantor
.com/download.html

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 17 April 2018 at 19:01, Cyril Brulebois  wrote:
> Dimitri John Ledkov  (2018-01-15):
>> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
>> > Hi,
>> >
>> > Cyril Brulebois  (2018-01-12):
>> >> Your package is no longer installable (along with its rev-dep
>> >> partman-btrfs) because it now depends on libzstd1, which isn't
>> >> a udeb.
>> >
>> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
>> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
>> > build just fine, without the libzstd1 dependency. As far as I can tell,
>> > there's no absolute need for this feature in d-i, and we could consider
>> > building the udeb without zstd support, instead of requesting the addition
>> > of a libzstd1-udeb. What do you think?
>> >
>>
>> That's an oversight on my part. From the recovery point of view, it
>> would be desired to have zstd compression support built-into
>> btrfs-progs-udeb such that one can use d-i recovery mode to
>> backup/restore btrfs filesystems with zstd compression.
>
> Your unreviewed addition of udeb as seen in NEW (currently holding back
> Helmut's work as noticed on #debian-ftp) is broken. It's missing a
> version.
>
> Repeating the same request and piece of advice (since 2012 or so):
> please get udeb-related things reviewed by debian-boot@/me?
>
> Thanks already.

First, I apologize for not responding to this email earlier, as I have
missed it in my mailbox.

Secondly, my work has been blocked by this NEW processing too for
btrfs-progs. I'm not aware as to which Helmut's work was blocked,
could you please elaborate what Helmut is blocked on? And/or how can
libzstd/me help to unblock Helmut? -> is that about patches for
crossbuilding that are part of

Now to respond to your main inquiry. I find the tone of above message
unacceptable. It reads accusational to me, rather than inquisitive.

It would have been much better to state:
"I notice that a call to dh_makeshlibs does not pass the -V flag as it
is custom for many libraries. Why have you not specified a minimum
required version in this case?"

It also feels like you (or others who were made aware of this lack of
-V) possibly wanted to make this a bug report, and follow-on out of
band events made it seem like it was felt that it is RC buggy and
shouldn't clear NEW and/or migrate to testing if passed NEW. In that
case  a new bug report should have been opened, with above request at
an RC priority.

I hope above is an adequate description, of the technical question you
are alluding to.

The proposed update that got rejected from NEW had
```
override_dh_makeshlibs:
dh_makeshlibs -plibzstd1 --add-udeb=libzstd1-udeb
```
(I hope this is enough context from said upload, for more details see
tree at 
https://salsa.debian.org/med-team/libzstd/tree/50c4849ef0ea5d79d7d5f84fd0a46b6404a413eb)

Note, that libzstd1 provides a symbols file, therefore packages that
link against it, normally get the correct minimum version dependency
based on the symbols file.
Therefore lack of -V flag is irrelevant for the actual dependencies
generated on packages that link/depend on libzstd1.

However, it is good to point out at this time, that udeb version of
libraries do not currently ship or use symbols files at all to
generate dependencies.
But also note that since libzstd1-udeb is a brand new package, any
version of thereof would correctly and strictly satisfy any udeb
package that gains a dependency on it. There are no linking or
dependency bugs in above libzstd1, nor udeb edition of the binary
packages.

This is no different to some other library udebs, e.g. liblzo2-2-udeb

Personally, I find it odd to have minimum -V arg version dependencies
for udebs only, when symbols are present for the deb edition of the
library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
immense amount of pain, when rebuilding packages locally, mixing &
matching packages when debugging issues in d-i, and does not at all
correctly generate private dependencies for udebs that use e.g.
@GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
2.28) style dependency instead. I'm not sure where/how .symbols should
be used or shipped, to start generate genuinely correct version
dependencies for udebs across the board. Debhelper? Dpkg?

Based on all of the above, I believe libzstd1, and libzstd1-udeb are
both policy complaint as previously uploaded.

If you are still concerned about minimum version dependencies which
are generated by packages that build/link/gain dependency on libzstd1
and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
open a new (or clone this) bug report against libzstd for
consideration. I also welcome references from the Debian Policy to
educate myself further about library dependencies, and if and how,
this package is not policy complaint and pointers on how to best fix
it.

-- 
Regards,

Dimitri.

Bug#895827: libopenmpi-dev: broken symlink: libpmix.so, and not installed libpmix.so.2.1.1

[John Paul Adrian Glaubitz]

Package: libopenmpi-dev
Version: 3.0.1-5
Followup-For: Bug #895827
User: debian-...@lists.debian.org
Usertags: m68k

It seems this revert broke openmpi on multiple platforms:

checking if user requested external PMIx 
support(/usr/lib/m68k-linux-gnu/pmix)... yes
checking --with-external-pmix value... not found
configure: WARNING: Directory /usr/lib/m68k-linux-gnu/pmix/include not found
configure: error: Cannot continue
tail -v -n \+0 config.log

Can you disable PMIx for the affected architectures?

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

Bug#893269: Pending fixes for bugs in the libproxool-java package

[pkg-java-maintainers]

tag 893269 + pending
thanks

Some bugs in the libproxool-java package are closed in revision
af1201b304707af8f4e6c8e31379d8a66159329b in branch 'master' by
Emmanuel Bourg

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

Commit message:

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

Bug#893770: libgnomecanvas will be adopted

[Gert Wollny]

Control: severity -1 important 

In light of #895249 I downgrade the bug severity. Autoremove will still
happen since src:libgnomecanvas still has a few RC bugs.

Best,
Gert

Bug#832049: python-parsley: please update to 1.3

[Thomas Andrejak]

Hello

Is it possible to go forward on this ?

If you need, I can help you

Thanks

Regards

On Thu, 21 Jul 2016 19:13:45 + Mattia Rizzolo  wrote:
> control: reassign -1 src:parsley 1.2-1
>
> On Thu, Jul 21, 2016 at 02:42:18PM -0400, Matthew Haughton wrote:
> > Source: python-parsley
>
> there is no source package with this name, I suppose you wanted
> 'parsley' instead ('python-parsley' is the name of the binary produced).
>
> reassigning accordingly.
>
> > Current package is out of date. Version 1.3 was released September 9, 2015.
> >
> > Note that the new version claims support for Python 3 which may
> > requires packaging updates.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#895957: xdelta3: clean up packaging

[Jeremy Bicha]

Source: xdelta3
Version: 3.0.11-dfsg-1
Tags: patch buster sid

I'm attaching a patch to modernize and clean up the packaging.

Thanks,
Jeremy Bicha
From 45e669e8f7d0fac8acc0a6b3d1c1268c596488aa Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Tue, 17 Apr 2018 17:32:27 -0400
Subject: [PATCH] Clean up packaging

Switch from cdbs to dh
Build with all hardening flags
Run build tests
Drop unused packaging files
Bump debhelper compat to 11
Bump Standards-Version to 4.1.4
---
 debian/compat  |   2 +-
 debian/control |   5 +-
 debian/control_px3 |  14 -
 debian/patches/CVE-2014-9765.patch | 165 -
 debian/patches/Q_not_u | 561 -
 debian/patches/fix_lzma_test.patch |  25 --
 debian/patches/printf_uint64   |  40 --
 debian/patches/regtest_size_t  |  11 -
 debian/python-xdelta3.examples |   1 -
 debian/python-xdelta3.substvars|   1 -
 debian/rules   |  11 +-
 11 files changed, 12 insertions(+), 824 deletions(-)
 delete mode 100644 debian/control_px3
 delete mode 100644 debian/patches/CVE-2014-9765.patch
 delete mode 100644 debian/patches/Q_not_u
 delete mode 100644 debian/patches/fix_lzma_test.patch
 delete mode 100644 debian/patches/printf_uint64
 delete mode 100644 debian/patches/regtest_size_t
 delete mode 100644 debian/python-xdelta3.examples
 delete mode 100644 debian/python-xdelta3.substvars

diff --git a/debian/compat b/debian/compat
index 7ed6ff8..b4de394 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-5
+11
diff --git a/debian/control b/debian/control
index 5068a84..9214cce 100644
--- a/debian/control
+++ b/debian/control
@@ -1,10 +1,9 @@
 Source: xdelta3
 Section: utils
 Priority: optional
-XS-Python-Version: all
 Maintainer: A Mennucc1 
-Build-Depends: cdbs, debhelper, liblzma-dev
-Standards-Version: 3.9.6.0
+Build-Depends: debhelper (>= 11), liblzma-dev
+Standards-Version: 4.1.4
 
 Package: xdelta3
 Architecture: any
diff --git a/debian/control_px3 b/debian/control_px3
deleted file mode 100644
index 3e23336..000
--- a/debian/control_px3
+++ /dev/null
@@ -1,14 +0,0 @@
-Package: python-xdelta3
-Architecture: any
-Section: python
-Depends:  ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Description: Xdelta3 python module
- Xdelta3 is a set of tools designed to compute changes between
- binary files.  These changes (delta files) are similar to the output of the
- "diff" program, in that they may be used to store and transmit only the
- changes between files.  The "delta files" that Xdelta3 manages are
- stored in RFC3284 (VCDIFF) format. 
- .
- This is the python module.
-
diff --git a/debian/patches/CVE-2014-9765.patch b/debian/patches/CVE-2014-9765.patch
deleted file mode 100644
index 0a2df2c..000
--- a/debian/patches/CVE-2014-9765.patch
+++ /dev/null
@@ -1,165 +0,0 @@
-Description: CVE-2014-9765: buffer overflow in main_get_appheader
-Origin: upstream, https://github.com/jmacd/xdelta/commit/969e65d3a5d70442f5bafd726bcef47a0b48edd8
-Bug-Debian: https://bugs.debian.org/814067
-Forwarded: not-needed
-Author: Josh MacDonald 
-Reviewed-by: Salvatore Bonaccorso 
-Last-Update: 2016-02-10
-Applied-Upstream: 3.0.9
-

- xdelta3-main.h |  5 ++--
- xdelta3-test.h | 83 +++---
- 2 files changed, 83 insertions(+), 5 deletions(-)
-
-diff --git a/xdelta3-main.h b/xdelta3-main.h
-index 090b7d9..5146b38 100644
 a/xdelta3-main.h
-+++ b/xdelta3-main.h
-@@ -2810,14 +2810,15 @@ main_get_appheader (xd3_stream *stream, main_file *ifile,
- 
-   if (appheadsz > 0)
- {
-+  const int kMaxArgs = 4;
-   char *start = (char*)apphead;
-   char *slash;
-   int   place = 0;
--  char *parsed[4];
-+  char *parsed[kMaxArgs];
- 
-   memset (parsed, 0, sizeof (parsed));
- 
--  while ((slash = strchr (start, '/')) != NULL)
-+  while ((slash = strchr (start, '/')) != NULL && place < (kMaxArgs-1))
- 	{
- 	  *slash = 0;
- 	  parsed[place++] = start;
-diff --git a/xdelta3-test.h b/xdelta3-test.h
-index e9848b6..dd45528 100644
 a/xdelta3-test.h
-+++ b/xdelta3-test.h
-@@ -166,7 +166,7 @@ static int do_cmd (xd3_stream *stream, const char *buf)
- 	{
- 	  stream->msg = "abnormal command termination";
- 	}
--  return XD3_INTERNAL;
-+  return ret;
- }
-   return 0;
- }
-@@ -429,12 +429,12 @@ test_compare_files (const char* tgt, const char *rec)
- }
- 
- static int
--test_save_copy (const char *origname)
-+test_copy_to (const char *from, const char *to)
- {
-   char buf[TESTBUFSIZE];
-   int ret;
- 
--  snprintf_func (buf, TESTBUFSIZE, "cp -f %s %s", origname, TEST_COPY_FILE);
-+  snprintf_func (buf, TESTBUFSIZE, "cp -f %s %s", from, to);
- 
-   if ((ret = system (buf)) != 0)
- {
-@@ -445,6 +445,12 @@ test_save_copy (const char *origname)
- }
- 
- static int
-+test_save_copy (const char *origname)
-+{
-+  return test_copy_to(origname, TEST_COPY_

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[Russ Allbery]

Sean Whitton  writes:

> Could you explain why you think this is needed, please?  What problems
> could be caused by a package being listed in more than one field, and
> what problems could be caused by forbidding that?

Particularly since this won't even appear in the binary package because
dpkg-gencontrol will filter out the duplicate dependency.

Thus Pre-Depends, Depends, Recommends and Suggests are simplified in
this order by removing dependencies which are known to be true
according to the stronger dependencies already parsed.  It will also
remove any self-dependency (in fact it will remove any dependency
which evaluates to true given the current version of the package as
installed).

So this is purely a nit in the debian/control file in the source package.
I think this is Lintian's role, not Policy.

-- 
Russ Allbery (r...@debian.org)   

Bug#895956: light-locker should not turn on the display when locking

[Vincent Lefevre]

Package: light-locker
Version: 1.8.0-1
Severity: normal

When the display is off while screen locking occurs, light-locker
unnecessarily turns on the display. For instance, with:

  sleep 1 && xset dpms force off && light-locker-command -l

the "xset dpms force off" turns off the display, but light-locker
turns it on again.

Ideally, light-locker itself should turn off the display when
locking.

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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  libc62.27-3
ii  libcairo21.14.10-1
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  libpango-1.0-0   1.42.1-1
ii  libpangocairo-1.0-0  1.42.1-1
ii  libsystemd0  238-4
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.2-1+b2
ii  lightdm  1.18.3-4

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#893240: Pending fixes for bugs in the libhibernate3-java package

[pkg-java-maintainers]

tag 893240 + pending
thanks

Some bugs in the libhibernate3-java package are closed in revision
c9efed7050bc7b39305e25177a176694ede8a29e in branch 'master' by
Emmanuel Bourg

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

Commit message:

Removed the -java-doc package to work around the build failure with Java 9 
(Closes: #893240)

Bug#889383: Pending fixes for bugs in the libhibernate3-java package

[pkg-java-maintainers]

tag 889383 + pending
thanks

Some bugs in the libhibernate3-java package are closed in revision
63318f6540c7a32cd8758e6a7ec80eace12a6cfd in branch 'master' by
Emmanuel Bourg

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

Commit message:

Removed Damien Raude-Morvan from the uploaders (Closes: #889383)

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Inaki Malerba:
> Hi Ximin
>> More generally, I'd argue that build programs shouldn't fail simply when 
>> LC_ALL is unrecognised, for example gcc works perfectly fine.
>>
>> $ LC_ALL=ououi gcc -c /dev/null 2>/dev/null; echo $?
>> 0
> 
> Totally agree.
> Normally, it should fallback to a known config, but, as you can see in
> the following example, the problem it's not exactly that the LC_ALL is
> unrecognized but the LC itself.
> A similar problem happens with Sphinx.
> 
> Sorry if that's not what you meant.
> 
> ```
> # LC_ALL=kk_KZ.RK1048 help2man
> Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
> 
> # LC_ALL=bleble help2man
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> [..]
Well, this detail does not change my main point. Why should any program 
silently accept LC_ALL=oeuieoui (and print warnings, that's fine) but blow up 
when running LC_ALL=kk_KZ.X? It should at most print a warning, not crash. 
Try it yourself:

$ LC_ALL=kk_KZ.XX gcc -c /dev/null 2>/dev/null; echo $?
0

BTW help2man seems to work fine on my Debian testing+unstable system with both 
LC_ALL=kk_KZ.RK1048 and LC_ALL=kk_KZ.XX and perl 5.26.1-5; I can't 
reproduce the behaviour you're describing.

I'd suggest to go with the solution that I suggested, i.e. keep filing those 
bugs you're filing for buggy programs (the fix is to ignore unknown encodings 
parsed from LC_ALL) and:

Ximin Luo:
> In the meantime you could add an option that lets you configure the locales 
> that reprotest sets, so that your local builds using old buggy programs don't 
> crash. (IMO they *should* crash in tests.r-b.org's official test suites.) See 
> `man reprotest` section VARIATIONS, you could add one for locales.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#895955: openjdk-10: Please backport build fixes for sparc64

[John Paul Adrian Glaubitz]

Source: openjdk-10
Version: 10~46-5
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

The attached debdiff adds a patch which fixes the build
openjdk-10 on sparc64. The patch includes the two changes
from upstream:

 * 8201616: Hotspot crashes on linux-sparc after 8189941
 * 8201480: ISA/CPU feature detection code crashes on linux-sparc

--- openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+++ openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
@@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcont
 }
 
 inline static bool checkPollingPage(address pc, address fault, address* stub) {
-  if (fault == os::get_polling_page()) {
+  if (os::is_poll_address(fault)) {
 *stub = SharedRuntime::get_poll_stub(pc);
 return true;
   }
--- 
openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
+++ openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
@@ -56,7 +56,7 @@ public:
 }
   }
 
-  ~CPUinfo() { os::free((void*)_string); }
+  ~CPUinfo() { free((void*)_string); }
 
   const char* value() const { return _string; }

Please consider including the patch for the next upload.

Thanks,
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/series 
new/openjdk-10-10~46/debian/patches/series
--- old/openjdk-10-10~46/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ new/openjdk-10-10~46/debian/patches/series  2018-04-17 22:44:49.015596334 
+0200
@@ -0,0 +1 @@
+sparc-fixes.diff
diff -Nru old/openjdk-10-10~46/debian/patches/sparc-fixes.diff 
new/openjdk-10-10~46/debian/patches/sparc-fixes.diff
--- old/openjdk-10-10~46/debian/patches/sparc-fixes.diff1970-01-01 
01:00:00.0 +0100
+++ new/openjdk-10-10~46/debian/patches/sparc-fixes.diff2018-04-17 
22:46:55.344492711 +0200
@@ -0,0 +1,28 @@
+Description: Backport two fixes for linux-sparc
+ 8201616: Hotspot crashes on linux-sparc after 8189941
+ 8201480: ISA/CPU feature detection code crashes on linux-sparc
+Author: John Paul Adrian Glaubitz 
+Last-Update: 2018-04-17
+
+--- openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
 openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+@@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcont
+ }
+ 
+ inline static bool checkPollingPage(address pc, address fault, address* stub) 
{
+-  if (fault == os::get_polling_page()) {
++  if (os::is_poll_address(fault)) {
+ *stub = SharedRuntime::get_poll_stub(pc);
+ return true;
+   }
+--- 
openjdk-10-10~46.orig/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
 openjdk-10-10~46/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
+@@ -56,7 +56,7 @@ public:
+ }
+   }
+ 
+-  ~CPUinfo() { os::free((void*)_string); }
++  ~CPUinfo() { free((void*)_string); }
+ 
+   const char* value() const { return _string; }
+ 
diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules
--- old/openjdk-10-10~46/debian/rules   2018-04-15 03:06:41.0 +0200
+++ new/openjdk-10-10~46/debian/rules   2018-04-17 22:47:10.841091851 +0200
@@ -330,6 +330,7 @@
docs-build-workaround.diff \
hotspot-ia64.diff \
8198649.diff \
+   sparc-fixes.diff \
 
 ifeq ($(derivative),Ubuntu)
   COMMON_PATCHES += \

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Inaki Malerba]

Hi Ximin
> More generally, I'd argue that build programs shouldn't fail simply when 
> LC_ALL is unrecognised, for example gcc works perfectly fine.
>
> $ LC_ALL=ououi gcc -c /dev/null 2>/dev/null; echo $?
> 0

Totally agree.
Normally, it should fallback to a known config, but, as you can see in
the following example, the problem it's not exactly that the LC_ALL is
unrecognized but the LC itself.
A similar problem happens with Sphinx.


Sorry if that's not what you meant.



```
# LC_ALL=kk_KZ.RK1048 help2man
Unknown encoding 'RK1048' at /usr/bin/help2man line 56.

# LC_ALL=bleble help2man
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = "bleble",
    LANG = (unset)
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
`help2man' generates a man page out of `--help' and `--version' output.

Usage: help2man [OPTION]... EXECUTABLE

 -n, --name=STRING   description for the NAME paragraph
 -s, --section=SECTION   section number for manual page (1, 6, 8)
 -m, --manual=TEXT   name of manual (User Commands, ...)
 -S, --source=TEXT   source of program (FSF, Debian, ...)
 -L, --locale=STRING select locale (default "C")
 -i, --include=FILE  include material from `FILE'
 -I, --opt-include=FILE  include material from `FILE' if it exists
 -o, --output=FILE   send output to `FILE'
 -p, --info-page=TEXT    name of Texinfo manual
 -N, --no-info   suppress pointer to Texinfo manual
 -l, --libtool   exclude the `lt-' from the program name
 --help  print this help, then exit
 --version   print version number, then exit

EXECUTABLE should accept `--help' and `--version' options and produce
output on
stdout although alternatives may be specified using:

 -h, --help-option=STRING help option string
 -v, --version-option=STRING  version option string
 --version-string=STRING  version string
 --no-discard-stderr  include stderr when parsing option output

Report bugs to .
```

-- 
- ina



signature.asc
Description: OpenPGP digital signature

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[Bill Allombert]

On Wed, Apr 18, 2018 at 04:21:47AM +0800, 積丹尼 Dan Jacobson wrote:
> BA> As I see it, it is not a bug, but a quality of implementation issue
> BA> that could be flagged by lintian, but does not need to appear in policy.
> 
> BA> Most of the time it will be an oversight or caused by a change in
> BA> external dependencies, so it is worthwhile to notify the maintainer,
> BA> but does not need to be in policy.
> 
> If I am a policeman, do I notify people about things that don't violate
> the law? What if the person who I notify asks me "did I violate any
> laws?" What am I to answer? "I don't know"?

Lintian is not a policeman, more like the helpful person that knock to
your window to tell you your left-rear tyre is flat.

> Can I answer "No you are not. I am just telling you anyway."

Yes, you can.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#858938: kopete: Please migrate to openssl1.1 in buster

[Pino Toscano]

In data martedì 17 aprile 2018 20:46:24 CEST, Emilio Pozuelo Monfort ha scritto:
> ¡Hola Lisandro!
> 
> On 25/02/18 17:40, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Hi Emilio!
> > 
> > El 25 feb. 2018 7:00 a.m., "Emilio Pozuelo Monfort" 
> > escribió:
> > 
> > Hi,
> > 
> > On Thu, 12 Oct 2017 23:44:27 +0200 Sebastian Andrzej Siewior
> >  wrote:
> >> this is a remainder about the openssl transition [0]. We really want to
> >> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> >> of this bug to serious in a month. Please react before that happens.
> > It looks like kopete only wants openssl for jingle support in XMPP. Can you
> > temporarily disable that, and forward this bug upstream so they add support
> > for
> > openssl 1.1?
> > 
> > 
> > I haven't checked, but maybe it depends on qt itself. If that's the case
> > then waiting upon qt 5.10 might be the best thing here. We are not that far
> > from asking a transition for it.
> > 
> > Of course If that's not the case then it's a possibility.
> 
> Now that we have Qt 5.10 in sid, can you check if kopete can be built with
> OpenSSL 1.1? Otherwise, disabling jingle could solve this for the time being.

The version of openssl used to build Qt is irrelevant for the jingle
code that uses openssl directly; nobody did anything about that, so the
status is the same as before.

If the openssl maintainers want to get rid of openssl 1.0, why don't
they *cooperate* with *upstream* communities on the migration to the
newer version of openssl? That would certainly help, and surely way
more than useless "please migrate, ktnxbye" nagging.

-- 
Pino Toscano

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

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[Bill Allombert]

On Wed, Apr 18, 2018 at 02:54:02AM +0800, 積丹尼 Dan Jacobson wrote:
> SW> Could you explain why you think this is needed, please?  What problems
> SW> could be caused by a package being listed in more than one field, and
> SW> what problems could be caused by forbidding that?
> 
> Please have your policy say if it is OK to drive on the right side of
> the road or the left side of the road or both or neither or that it
> hasn't been decided yet or something, anything. Thanks.

As I see it, it is not a bug, but a quality of implementation issue
that could be flagged by lintian, but does not need to appear in policy.

Most of the time it will be an oversight or caused by a change in
external dependencies, so it is worthwhile to notify the maintainer,
but does not need to be in policy.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[積丹尼 Dan Jacobson]

BA> As I see it, it is not a bug, but a quality of implementation issue
BA> that could be flagged by lintian, but does not need to appear in policy.

BA> Most of the time it will be an oversight or caused by a change in
BA> external dependencies, so it is worthwhile to notify the maintainer,
BA> but does not need to be in policy.

If I am a policeman, do I notify people about things that don't violate
the law? What if the person who I notify asks me "did I violate any
laws?" What am I to answer? "I don't know"?

Can I answer "No you are not. I am just telling you anyway."

I can't even say that, because I don't know.

Bug#895934: [PATCH 1/1] flash-kernel: add Rockchip RK3288 Tinker Board

[Karsten Merker]

Control: tag 895934 pending

On Tue, Apr 17, 2018 at 05:41:51PM +0200, Heinrich Schuchardt wrote:
> Package: flash-kernel
> Version: 3.94
> Severity: wishlist
> Tags: patch
> 
> Add database entry for the Tinker Board.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  db/all.db | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/db/all.db b/db/all.db
> index 28d40b1..ff92e17 100644
> --- a/db/all.db
> +++ b/db/all.db
> @@ -412,6 +412,13 @@ Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
>  
> +Machine: Rockchip RK3288 Tinker Board
> +Kernel-Flavors: armp armmp-lpae
> +DTB-Id: rk3288-tinker.dtb
> +Boot-Script-Path: /boot/boot.scr
> +U-Boot-Script-Name: bootscr.uboot-generic
> +Required-Packages: u-boot-tools
> +
>  Machine: Firefly-RK3399 Board
>  Kernel-Flavors: arm64
>  DTB-Id: rk3399-firefly.dtb

Hello,

I've committed the patch to the flash-kernel git repository with
two tiny changes:

- I've fixed a typo in the kernel-flavors line (s/armp/armmp/).

- I've moved the entry to another position as we (at least
  nominally) sort the entries by the "Machine" field and not by
  the "DTB-Id" field.

I'll probably upload the package sometime on the upcoming
weekend.

Regards,
Karsten
--  
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#895954: stunnel4: autopkgtest fails since perl 5.26.1-6

[Paul Gevers]

Source: stunnel4
Version: 3:5.44-1
Severity: normal
User: debian...@lists.debian.org
Usertags: needs-update

Since the upload of perl version 5.26.1-6, your autopkgtest¹ fails with
the error copied below.

The perl update was a security one, so the package migrated already to
testing. As I don't have the insight into your package, this may
indicate your package is broken now. If that is the case, I suggest to
raise the severity of this bug.

Paul

¹ https://ci.debian.net/packages/s/stunnel4


autopkgtest [12:38:28]: test command2:  - - - - - - - - - - results - -
- - - - - - - -
command2 FAIL non-zero exit status 1
autopkgtest [12:38:28]: test command2:  - - - - - - - - - - stderr - - -
- - - - - - -


=== Some tests failed; here are all the logs...



=== logs/012_verify_chain.log

2018.04.17 12:38:00 LOG7[ui]: Clients allowed=500
2018.04.17 12:38:00 LOG5[ui]: stunnel 5.44 on x86_64-pc-linux-gnu platform
2018.04.17 12:38:00 LOG5[ui]: Compiled with OpenSSL 1.1.0g  2 Nov 2017
2018.04.17 12:38:00 LOG5[ui]: Running  with OpenSSL 1.1.0h  27 Mar 2018
2018.04.17 12:38:00 LOG5[ui]: Threading:PTHREAD
Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
2018.04.17 12:38:00 LOG7[ui]: errno: (*__errno_location ())
2018.04.17 12:38:00 LOG5[ui]: Reading configuration from descriptor 0
2018.04.17 12:38:00 LOG5[ui]: UTF-8 byte order mark not detected
2018.04.17 12:38:00 LOG5[ui]: FIPS mode disabled
2018.04.17 12:38:00 LOG7[ui]: Compression disabled
2018.04.17 12:38:00 LOG7[ui]: PRNG seeded successfully
2018.04.17 12:38:00 LOG6[ui]: Initializing service [https client]
2018.04.17 12:38:00 LOG7[ui]: Ciphers: HIGH:!DH:!aNULL:!SSLv2
2018.04.17 12:38:00 LOG7[ui]: TLS options: 0x02020004 (+0x0200,
-0x)
2018.04.17 12:38:00 LOG7[ui]: No certificate or private key specified
2018.04.17 12:38:00 LOG4[ui]: Service [https client] uses "verifyChain"
without subject checks
2018.04.17 12:38:00 LOG4[ui]: Use "checkHost" or "checkIP" to restrict
trusted certificates
2018.04.17 12:38:00 LOG6[ui]: Initializing service [https server]
2018.04.17 12:38:00 LOG7[ui]: Ciphers: HIGH:!DH:!aNULL:!SSLv2
2018.04.17 12:38:00 LOG7[ui]: TLS options: 0x02024004 (+0x02004000,
-0x)
2018.04.17 12:38:00 LOG6[ui]: Loading certificate from file:
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG6[ui]: Certificate loaded from file:
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG6[ui]: Loading private key from file:
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG4[ui]: Insecure file permissions on
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG6[ui]: Private key loaded from file:
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG7[ui]: Private key check succeeded
2018.04.17 12:38:00 LOG7[ui]: DH initialization
2018.04.17 12:38:00 LOG7[ui]: Could not load DH parameters from
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/certs/server_cert.pem
2018.04.17 12:38:00 LOG6[ui]: Using dynamic DH parameters
2018.04.17 12:38:00 LOG7[ui]: ECDH initialization
2018.04.17 12:38:00 LOG7[ui]: ECDH initialized with curve prime256v1
2018.04.17 12:38:00 LOG5[ui]: Configuration successful
2018.04.17 12:38:00 LOG7[ui]: Binding service [https client]
2018.04.17 12:38:00 LOG7[ui]: Listening file descriptor created (FD=6)
2018.04.17 12:38:00 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2018.04.17 12:38:00 LOG7[ui]: Service [https client] (FD=6) bound to
127.0.0.1:8080
2018.04.17 12:38:00 LOG7[ui]: Binding service [https server]
2018.04.17 12:38:00 LOG7[ui]: Listening file descriptor created (FD=7)
2018.04.17 12:38:00 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2018.04.17 12:38:00 LOG7[ui]: Service [https server] (FD=7) bound to
127.0.0.1:4433
2018.04.17 12:38:00 LOG7[main]: Created pid file
/tmp/autopkgtest-lxc.00fedn44/downtmp/build.7z2/src/tests/logs/stunnel.pid
2018.04.17 12:38:00 LOG7[cron]: Cron thread initialized
2018.04.17 12:38:00 LOG7[main]: Found 1 ready file descriptor(s)
2018.04.17 12:38:00 LOG7[main]: FD=4 events=0x2001 revents=0x0
2018.04.17 12:38:00 LOG7[main]: FD=6 events=0x2001 revents=0x1
2018.04.17 12:38:00 LOG7[main]: FD=7 events=0x2001 revents=0x0
2018.04.17 12:38:00 LOG7[main]: Service [https client] accepted (FD=3)
from 127.0.0.1:58918
2018.04.17 12:38:00 LOG7[0]: Service [https client] started
2018.04.17 12:38:00 LOG7[0]: Option TCP_NODELAY set on local socket
2018.04.17 12:38:00 LOG5[0]: Service [https client] accepted connection
from 127.0.0.1:58918
2018.04.17 12:38:00 LOG6[0]: s_connect: connecting 127.0.0.1:4433
2018.04.17 12:38:00 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:4433:
waiting 10 seconds
2018.04.17 12:38:00 LOG7[main]: Found 1 ready file descriptor(s)
2018.04.17 12:38:00 LOG5[0]: s_connect: connected 127.0.0.1:44

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[Giovanni Mascellani]

Hi,

Il 17/04/2018 21:37, kact...@gnu.org ha scritto:
> How does it compare to dtach?

I didn't know about dtach. It seems to be fairly similar, as a matter of
facts. Maybe an additional feature in detachtty is that it can directly
call ssh for you, but nothing really big.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles

Bug#895953: lintian: check that shlibs-version >= higher-version-symbols-file

[Emilio Pozuelo Monfort]

Package: lintian
Version: 2.5.82
Severity: wishlist

Hi,

It would be good to check that the version in a shlibs file doesn't
fall behind wrt the version in the .symbols file. E.g. one may have
a call to
dh_makeshlibs -plibfoo1 -V"1.0" -- -c4

updated when the 1.0 version got packaged, as it may have introduced
new symbols. Then, on an update to 1.1, new symbols may have been
introduced, and the maintainer would have updated the .symbols file
with the new symbols at version 1.1, but may have forgotten to update
the version in the dh_makeshlibs -V option (which ends up in the shlibs
file).

This is specially important for udebs, as they use the shlibs even
when .symbols files exist.

Another option would be for dh_makeshlibs to automatically use a
higher version if there's a higher one in the .symbols file. Not
sure we want to go that way though.

tl;dr: check if the shlibs CONTROL file in a .deb has a high enough
version as compared to MAX(versions in symbols CONTROL file)

Cheers,
Emilio

Bug#895952: FTBFS: incompatible with terminal-progress-bar 0.2

[Clint Adams]

Source: haskell-bytestring-progress
Version: 1.0.9-1
Severity: serious
Forwarded: https://github.com/acw/bytestring-progress/issues/9

.

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[KAction]

[2018-04-17 20:00] Giovanni Mascellani 
> [...]
>
> Detachtty lets you run interactive programs non-interactively, and connect
> to them over the network when you do need to interact with them. It is
> somewhat similar to screen, but it is less feature-rich, therefore
> lighter and with less dependencies. It allows to connect to programs
> running on remote hosts by mean of secure SSH connections.
> 
> Detachtty was removed from Debian because it was dead upstream. Now the
> upstream development has been resumed by another developer, so it is
> sensible to repackage it.

How does it compare to dtach?

Bug#895848: RFS: inotify-tools/3.14-5

[KAction]

[2018-04-16 21:49] Sean Whitton 
> control: tag -1 +moreinfo
> control: owner -1 !
> 
> On Mon, Apr 16, 2018 at 10:25:01PM +0300, Dmitry Bogatov wrote:
> > 
> > I am looking for a sponsor for my package "inotify-tools"
> [...]
> 
> Looks like you need to update your symbols file.

Yes. Did it.  7c6c6bea1edbec1683dd9e5a5ee524819dcd053d

Bug#895949: lintian: warn about packages with udebs but no udeb line in shlibs

[Emilio Pozuelo Monfort]

On 17/04/18 21:21, Chris Lamb wrote:
> Hi Emilio,
> 
> Disclaimer: I'm not a shared library expert, let alone a shlibs
> one! However, as I understand it, we need to look for:
> 
>   * A "libfooX" & "libfooX-udeb" pair …
> 
>   * That both ship a "libBar.so.X"
> 
>   * libfooX's shlibs control file does not contain a line starting
> with "udeb: libBar X libfooX-udeb"...
> 
> (At a first approximation anyway...)

Yes, but libfooX may be named differently (i.e. it's not always a s/-udeb$//),
and there may be several non-udebs affected.

So I'd approach this in this way (in pseudocode):

for each shared library in the -udeb
there is a deb package with that library, and
its shlibs contains a udeb line for that shared lib

That would match your libfoo1 and libfoo1-udeb, but also something like
libpango1.0-udeb shipping shared libraries from libpango-1.0-0,
libpangocairo-1.0-0, libpangoxft-1.0-0 and libpangoft2-1.0-0. In that case, each
one of those debs needs a udeb: fine for the libraries that the udeb ships.

Hope that's clear. If not, please let me know.

Thanks,
Emilio

Bug#895801: kicad: assert failure with new wxPython version

[Willem van den Akker]

Hi,

Installed 5.0-rc1 and runs without a problem.
Perhaps the bug original can be tagged 'Won't fix' instead of fixed?

/Willem


On Mon, 2018-04-16 at 13:38 +0200, Carsten Schoenert wrote:
> On Mon, Apr 16, 2018 at 12:19:04PM +0200, Willem van den Akker wrote:
> > Ah,
> > 
> > It is stated fixed :)
> 
> Please check allways first for existing bug reports before open a new
> one :) , it cost time to get the reports managed, time that will not be
> available to work on packaging mostly.
> And kicad is no heavy package with a hugh amout of unhandled issues.
> 
> > If will wait for RC2 and hope it will be soon available in testing.
> 
> You can right now use the version from experimental, no real need to
> wait for RC2. RC2 can come next weekend or in four weeks. For Debian we
> need to figure out how we can handle we issues with GTK3 in context to
> wxWidgets/wxpython. So we may need to exclude the action plugin support
> and switch back to GTK2 bindings.
> 
> Regards
> Carsten
> 

Bug#895949: lintian: warn about packages with udebs but no udeb line in shlibs

[Chris Lamb]

Hi Emilio,

Disclaimer: I'm not a shared library expert, let alone a shlibs
one! However, as I understand it, we need to look for:

  * A "libfooX" & "libfooX-udeb" pair …

  * That both ship a "libBar.so.X"

  * libfooX's shlibs control file does not contain a line starting
with "udeb: libBar X libfooX-udeb"...

(At a first approximation anyway...)


Regards,

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

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Inaki Malerba:
> Hi Chris!
> 
> Thanks for the answer.
> 
> On 17/04/18 13:18, Chris Lamb wrote:
>> Could you expand the commit message on this patch to include the
>> reason why beyond "causes trouble"?
> 
> I've done some research about the root problem but couldn't find much
> more than it's a relatively new encoding.
> My guess is that it's still not supported by some platforms. I found
> some threads about its inclusion to python[1] and glibc[2].
> 
> I agree that it might seem like it was added on purpose, but rather than
> checking for changes on the build, it makes the build tools fail.
> 
> If you know somebody that might know more about the nature of this
> problem, or why it was chosen, would you cc him/her, please? Maybe
> that's better than changing it.
> 
> 
> 
> 1. https://bugs.python.org/issue22682
> 2. https://lists.debian.org/debian-glibc/2004/06/msg00080.html
> 

I added this in commit 8b18046b6e96628cba2e2ce6011766ef964a71a9 specifically to 
test for things like #847596.

More generally, I'd argue that build programs shouldn't fail simply when LC_ALL 
is unrecognised, for example gcc works perfectly fine.

$ LC_ALL=ououi gcc -c /dev/null 2>/dev/null; echo $?
0

Since LC_ALL is meant to be an override anyways, programs should just fall back 
on the pre-existing locale settings if it's unrecognised. In other words, if 
any build programs crash, that would be the "ideal fix", and they should be 
patched to behave like that.

In the meantime you could add an option that lets you configure the locales 
that reprotest sets, so that your local builds using old buggy programs don't 
crash. (IMO they *should* crash in tests.r-b.org's official test suites.) See 
`man reprotest` section VARIATIONS, you could add one for locales.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#895865: dxf2gcode: Infinite spin attempting to load DXF file

[Sebastian Kuzminsky]

I can't reproduce this bug with the attached DXF file.  When I run 
"dxf2gcode top.dxf" it thinks about it for about 17 seconds, then loads 
successfully.  This is on a fairly beefy amd64 machine with lots of CPUs 
and RAM, and a max clock frequency of 3.5 GHz.


After loading the file, dxf2gcode does pop up a warning window that says 
"Length of some Elements too short!  Length must be greater than 
tolerance.  Skipped Geometries"


Please try giving it more time to finish and see if that makes it load 
the file successfully.


--
Sebastian Kuzminsky

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Ludovic Rousseau]

Le 16/04/2018 à 01:45, Luke Faraone a écrit :

On Sun, Apr 15, 2018 at 7:39 PM, Ludovic Rousseau
 wrote:

The problem is with the call to
udev_device_get_parent_with_subsystem_devtype()
https://salsa.debian.org/rousseau/PCSC/blob/master/src/hotplug_libudev.c#L338

Maybe USB-C ports are different than "normal" USB.


Yeah, attaching USB-C devices always generates xhci / pcieport spew in
dmesg. (enclosed for curiosity)


Also please generate a "udevadm monitor" log.
Start "udevadm monitor --property" (no need to be root)
Plug the reader
Unplug the reader
and send me the output.


Attached.


Thanks.
I was not expecting so much events just for one device.

I should receive a Yubikey 4 (USB-C) in the next few days. It will be much 
simpler for me to debug.
I may ask you to test some patches.

Bye


--
 Dr. Ludovic Rousseau

Bug#895951: jenkins.debian.net: reproducible Debian: Correct parsing of diffoscope version since recent update of PyPI.org

[Chris Lamb]

Package: jenkins.debian.net
Severity: wishlist
Tags: patch

Hi,

Attached is the following:

  commit f8d976951e4728b4a34ac8e04bd50d6e59b82634
  Author: Chris Lamb 
  Date:   Tue Apr 17 20:02:41 2018 +0100
  
  reproducible Debian: Correct parsing of diffoscope version since recent 
update of PyPI.org
  
   bin/diffoscope_distribution_test.sh | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
>From f8d976951e4728b4a34ac8e04bd50d6e59b82634 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Tue, 17 Apr 2018 20:02:41 +0100
Subject: [PATCH] reproducible Debian: Correct parsing of diffoscope version
 since recent update of PyPI.org

---
 bin/diffoscope_distribution_test.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bin/diffoscope_distribution_test.sh b/bin/diffoscope_distribution_test.sh
index a80050da..17d367ab 100755
--- a/bin/diffoscope_distribution_test.sh
+++ b/bin/diffoscope_distribution_test.sh
@@ -19,8 +19,8 @@ send_irc_warning() {
 check_pypi() {
 	TMPPYPI=$(mktemp -t diffoscope-distribution-)
 	# the following two lines are a bit fragile…
-	curl https://pypi.python.org/pypi/diffoscope/ -o $TMPPYPI
-	DIFFOSCOPE_IN_PYPI=$(grep "" $TMPPYPI | cut -d ">" -f2- | cut -d ":" -f1 |cut -d " " -f2)
+	curl https://pypi.org/project/diffoscope/ -o $TMPPYPI
+	DIFFOSCOPE_IN_PYPI=$(sed -ne 's@.*diffoscope \([0-9][0-9]*\).*@\1@gp' $TMPPYPI)
 	rm -f $TMPPYPI > /dev/null
 	echo
 	echo
-- 
2.17.0

Bug#858938: kopete: Please migrate to openssl1.1 in buster

[Lisandro Damián Nicanor Pérez Meyer]

Hi Emilio, Pino, Maxy!

I'm CCing Pboth Pino and Maxy because they are the ones following the
KDE parts of the team (I normally do just Qt stuff).


On 17 April 2018 at 15:46, Emilio Pozuelo Monfort  wrote:
> ¡Hola Lisandro!
>
[snip]

> Now that we have Qt 5.10 in sid, can you check if kopete can be built with
> OpenSSL 1.1? Otherwise, disabling jingle could solve this for the time being.

Kopete using kf5/Qt5 is in experimental, but I don't know it's status.
Kopete in unstable/testing is still using Qt4.

Maybe Pino and/or Maxy can help here.

Cheers!

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

Bug#895862: dxf2gcode: Crashes "UnboundLocalError: local variable 'entities' referenced before assignment"

[Sebastian Kuzminsky]

Thanks for the bug report, and especially for the DXF file to reproduce 
it.  The DXF has no "entities" section, which is what caused the crash.


I've forwarded the bug report and the dxf to upstream, along with a 
patch that I believe fixes the problem.  I'll release a bugfix version 
of the debian package soon.


--
Sebastian Kuzminsky

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[積丹尼 Dan Jacobson]

SW> Could you explain why you think this is needed, please?  What problems
SW> could be caused by a package being listed in more than one field, and
SW> what problems could be caused by forbidding that?

Please have your policy say if it is OK to drive on the right side of
the road or the left side of the road or both or neither or that it
hasn't been decided yet or something, anything. Thanks.

Bug#895950: freeipa: CVE-2017-12169: Password hash disclosure via 'System: Read Stage Users' permission

[Salvatore Bonaccorso]

Source: freeipa
Version: 4.3.1-1
Severity: normal
Tags: security upstream

Hi,

The following vulnerability was published for freeipa.

CVE-2017-12169[0]:
| It was found that FreeIPA 4.2.0 and later could disclose password
| hashes to users having the 'System: Read Stage Users' permission. A
| remote, authenticated attacker could potentially use this flaw to
| disclose the password hashes belonging to Stage Users. This security
| issue does not result in disclosure of password hashes belonging to
| active standard users. NOTE: some developers feel that this report is
| a suggestion for a design change to Stage User activation, not a
| statement of a vulnerability.

Initially this issue was disputed as beeing valid, was confirmed that
the issue is valid, although as low imapct security flaw.

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-2017-12169
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12169
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1487697

Regards,
Salvatore

Bug#828451: netty fix released, netty-tcnative patch accepted

[Emilio Pozuelo Monfort]

On Wed, 24 Jan 2018 11:07:19 + deb...@fau.xxx wrote:
> Upstream have accepted both patches. netty 4.1.20 has been released,
> which will run against a patched netty-tcnative. There hasn't been a
> netty-tcnative release.

There's a new netty-tcnative release, 2.0.8. Is that incompatible with the
current version of netty, or why can't we update to that? Sorry, I'm not
familiar with netty, just looking at this as I'd like to get rid of openssl1.0
for buster.

Emilio

Bug#858938: kopete: Please migrate to openssl1.1 in buster

[Emilio Pozuelo Monfort]

¡Hola Lisandro!

On 25/02/18 17:40, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi Emilio!
> 
> El 25 feb. 2018 7:00 a.m., "Emilio Pozuelo Monfort" 
> escribió:
> 
> Hi,
> 
> On Thu, 12 Oct 2017 23:44:27 +0200 Sebastian Andrzej Siewior
>  wrote:
>> this is a remainder about the openssl transition [0]. We really want to
>> remove libssl1.0-dev from unstable for Buster. I will raise the severity
>> of this bug to serious in a month. Please react before that happens.
> It looks like kopete only wants openssl for jingle support in XMPP. Can you
> temporarily disable that, and forward this bug upstream so they add support
> for
> openssl 1.1?
> 
> 
> I haven't checked, but maybe it depends on qt itself. If that's the case
> then waiting upon qt 5.10 might be the best thing here. We are not that far
> from asking a transition for it.
> 
> Of course If that's not the case then it's a possibility.

Now that we have Qt 5.10 in sid, can you check if kopete can be built with
OpenSSL 1.1? Otherwise, disabling jingle could solve this for the time being.

Thanks,
Emilio

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Karsten Merker]

On Mon, Apr 09, 2018 at 09:35:29PM +0200, Karsten Merker wrote:

> attached is an updated packaging patch adding support for the
> RISC-V architecture to nspr package version 2:4.19-1.  The
> original patch that had been submitted to this bug had been for
> package version 2:4.18-1 and doesn't apply cleanly on version
> 2:4.19-1.
> 
> In addition to the updated packaging patch I have also attached
> a "bare" patch directly against upstream.

Hello,

upstream has reviewed the patch and accepted it for inclusion
into the upstream NSPR mercurial repository:

  https://hg.mozilla.org/projects/nspr/rev/f47871e2aeb1

It would be great if you could upload a new version of the Debian
nspr 2:4.19 package with the patch included.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#848864: libtool: diff for NMU version 2.4.6-2.1

[Andreas Boll]

Control: tags 848864 + pending

Dear maintainer,

I've prepared an NMU for libtool (versioned as 2.4.6-2.1) and uploaded
it to DELAYED/10. This NMU restores most of the original performance
of libtool 2.4.2. Please feel free to tell me if I should delay it
longer.

Thanks,
Andreas
diff -Nru libtool-2.4.6/debian/changelog libtool-2.4.6/debian/changelog
--- libtool-2.4.6/debian/changelog	2016-08-20 14:34:31.0 +0200
+++ libtool-2.4.6/debian/changelog	2018-04-17 19:50:37.0 +0200
@@ -1,3 +1,14 @@
+libtool (2.4.6-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Mitigate exessive sed forking (Closes: #848864):
+- Add 0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch
+- Add 0011-libtool-optimizing-options-parser-hooks.patch
+- Add 0012-funclib-refactor-quoting-methods-a-bit.patch
+- Refresh 0020-libtool-fix-GCC-clang-linking-with-fsanitize.patch
+
+ -- Andreas Boll   Tue, 17 Apr 2018 19:50:37 +0200
+
 libtool (2.4.6-2) unstable; urgency=medium
 
   * Don't show the debain version in --version, just in --help
diff -Nru libtool-2.4.6/debian/patches/0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch libtool-2.4.6/debian/patches/0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch
--- libtool-2.4.6/debian/patches/0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch	1970-01-01 01:00:00.0 +0100
+++ libtool-2.4.6/debian/patches/0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch	2018-01-19 11:28:13.0 +0100
@@ -0,0 +1,235 @@
+From 32f0df9835ac15ac17e04be57c368172c3ad1d19 Mon Sep 17 00:00:00 2001
+From: Pavel Raiskup 
+Date: Sun, 4 Oct 2015 21:55:03 +0200
+Subject: [PATCH] libtool: mitigate the $sed_quote_subst slowdown
+
+When it is reasonably possible, use shell implementation for
+quoting.
+
+References:
+http://lists.gnu.org/archive/html/libtool/2015-03/msg5.html
+http://lists.gnu.org/archive/html/libtool/2015-02/msg0.html
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20006
+
+* gl/build-aux/funclib.sh (func_quote): New function that can be
+used as substitution for '$SED $sed_quote_subst' call.
+* build-aux/ltmain.in (func_emit_wrapper): Use func_quote instead
+of '$SED $sed_quote_subst'.
+(func_mode_link): Likewise.
+* NEWS: Document.
+* bootstrap: Sync with funclib.sh.
+---
+ NEWS|  3 +++
+ bootstrap   | 61 +++--
+ build-aux/ltmain.in | 10 
+ gl/build-aux/funclib.sh | 61 +++--
+ 4 files changed, 117 insertions(+), 18 deletions(-)
+
+diff --git a/bootstrap b/bootstrap
+index c179f51d..fe9e9cac 100755
+--- a/bootstrap
 b/bootstrap
+@@ -230,7 +230,7 @@ vc_ignore=
+ 
+ # Source required external libraries:
+ # Set a version string for this script.
+-scriptversion=2015-01-20.17; # UTC
++scriptversion=2015-10-04.22; # UTC
+ 
+ # General shell script boiler plate, and helper functions.
+ # Written by Gary V. Vaughan, 2004
+@@ -1257,6 +1257,57 @@ func_relative_path ()
+ }
+ 
+ 
++# func_quote ARG
++# --
++# Aesthetically quote one ARG, store the result into $func_quote_result.  Note
++# that we keep attention to performance here (so far O(N) complexity as long as
++# func_append is O(1)).
++func_quote ()
++{
++$debug_cmd
++
++func_quote_result=$1
++
++case $func_quote_result in
++  *[\\\`\"\$]*)
++case $func_quote_result in
++  *'*'*|*'['*)
++func_quote_result=`$ECHO "$func_quote_result" | $SED "$sed_quote_subst"`
++return 0
++;;
++esac
++
++func_quote_old_IFS=$IFS
++for _G_char in '\' '`' '"' '$'
++do
++  # STATE($1) PREV($2) SEPARATOR($3)
++  set start "" ""
++  func_quote_result=dummy"$_G_char$func_quote_result$_G_char"dummy
++  IFS=$_G_char
++  for _G_part in $func_quote_result
++  do
++case $1 in
++quote)
++  func_append func_quote_result "$3$2"
++  set quote "$_G_part" "\\$_G_char"
++  ;;
++start)
++  set first "" ""
++  func_quote_result=
++  ;;
++first)
++  set quote "$_G_part" ""
++  ;;
++esac
++  done
++  IFS=$func_quote_old_IFS
++done
++;;
++  *) ;;
++esac
++}
++
++
+ # func_quote_for_eval ARG...
+ # --
+ # Aesthetically quote ARGs to be evaled later.
+@@ -1273,12 +1324,8 @@ func_quote_for_eval ()
+ func_quote_for_eval_unquoted_result=
+ func_quote_for_eval_result=
+ while test 0 -lt $#; do
+-  case $1 in
+-*[\\\`\"\$]*)
+-	  _G_unquoted_arg=`printf '%s\n' "$1" |$SED "$sed_quote_subst"` ;;
+-*)
+-  _G_unquoted_arg=$1 ;;
+-  esac
++  func_quote "$1"
++  _G_unquoted_arg=$func_quote_result
+   if test -n "$func_quote_for_eval_unquoted_result"; then
+ 	func_a

Bug#895949: lintian: warn about packages with udebs but no udeb line in shlibs

[Emilio Pozuelo Monfort]

Package: lintian
Version: 2.5.82
Severity: wishlist

Hi,

(d-i's RM / debian-boot@ Cc'ed.)

A package that builds a udeb and ships a shared library ought to include that
udeb in the respective shared libraries' shlibs. This is achieved by passing
the --add-udeb option to dh_makeshlibs. A broken package could look like this:

 Package: libxft2
 Source: xft

contents:
-rw-r--r-- root/root 89544 2018-04-17 20:11 
./usr/lib/x86_64-linux-gnu/libXft.so.2.3.2

shlibs:
libXft 2 libxft2 (>> 2.1.1)

And the respective udeb:

 Package: libxft2-udeb
 Source: xft

contents:
-rw-r--r-- root/root 89416 2018-04-17 20:11 ./usr/lib/libXft.so.2.3.2
lrwxrwxrwx root/root 0 2018-04-17 20:11 ./usr/lib/libXft.so.2 -> 
libXft.so.2.3.2

This is broken because udebs that depend on libXft.so.2 will gain a dependency
on libxft2 rather than libxft2-udeb, making that udeb uninstallable. To fix 
that,
with the --add-udeb=libxft2-udeb option, libxft2's shlibs would look like this:

libXft 2 libxft2 (>> 2.1.1)
udeb: libXft 2 libxft2-udeb (>> 2.1.1)

Note that the deb and the udeb don't need to match 1:1. There may be several
debs with different shared libraries, and one udeb with all of them. In that
case, for each library in the udeb, the corresponding package that ships it
in a deb needs to have an appropriate udeb line. See src:pango1.0 for an
example.

A lintian error could save some problems in d-i by preventing these problems
(that error could be turned into an archive auto-reject).

Cheers,
Emilio

Bug#833144: mpich: MPICH compiled with BCLR causes problems with valgrind

[Adrian Bunk]

On Mon, Dec 18, 2017 at 11:36:52AM +0200, Adrian Bunk wrote:
> Control: block 876908 by -1
> 
> On Mon, Aug 01, 2016 at 06:09:47PM +0200, Anton Gladky wrote:
> >...
> > thanks for bugreport. We will consider to drop blcr-support in
> > Debian-builds.
> >...
> 
> Any updates on this?
> 
> As explained in #876908, the kernel part blcr does not even compile with
> the kernels in jessie and later.

ping


Thanks
Adrian

-- 

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

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
Owner: Giovanni Mascellani 

* Package name: detachtty
  Version : 11.0.0
  Upstream Author : Massimiliano Ghilardi
  
* URL : https://github.com/cosmos72/detachtty
* License : GPL-2+
  Programming Lang: C
  Description : Utility to connect to detached interactive programs

Detachtty lets you run interactive programs non-interactively, and connect
to them over the network when you do need to interact with them. It is
somewhat similar to screen, but it is less feature-rich, therefore
lighter and with less dependencies. It allows to connect to programs
running on remote hosts by mean of secure SSH connections.

Detachtty was removed from Debian because it was dead upstream. Now the
upstream development has been resumed by another developer, so it is
sensible to repackage it.

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Chris Lamb]

Hi Inaki,

> If you know somebody that might know more about the nature of this
> problem, or why it was chosen, would you cc him/her, please? Maybe
> that's better than changing it.

Well, I would simply check `git blame` or `git log -p` generally on
that file. :)


Regards,

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

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Dimitri John Ledkov  (2018-01-15):
> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
> > Hi,
> >
> > Cyril Brulebois  (2018-01-12):
> >> Your package is no longer installable (along with its rev-dep
> >> partman-btrfs) because it now depends on libzstd1, which isn't
> >> a udeb.
> >
> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
> > build just fine, without the libzstd1 dependency. As far as I can tell,
> > there's no absolute need for this feature in d-i, and we could consider
> > building the udeb without zstd support, instead of requesting the addition
> > of a libzstd1-udeb. What do you think?
> >
> 
> That's an oversight on my part. From the recovery point of view, it
> would be desired to have zstd compression support built-into
> btrfs-progs-udeb such that one can use d-i recovery mode to
> backup/restore btrfs filesystems with zstd compression.

Your unreviewed addition of udeb as seen in NEW (currently holding back
Helmut's work as noticed on #debian-ftp) is broken. It's missing a
version.

Repeating the same request and piece of advice (since 2012 or so):
please get udeb-related things reviewed by debian-boot@/me?

Thanks already.


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


signature.asc
Description: PGP signature

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Inaki Malerba]

Hi Chris!

Thanks for the answer.

On 17/04/18 13:18, Chris Lamb wrote:
> Could you expand the commit message on this patch to include the
> reason why beyond "causes trouble"?

I've done some research about the root problem but couldn't find much
more than it's a relatively new encoding.
My guess is that it's still not supported by some platforms. I found
some threads about its inclusion to python[1] and glibc[2].

I agree that it might seem like it was added on purpose, but rather than
checking for changes on the build, it makes the build tools fail.

If you know somebody that might know more about the nature of this
problem, or why it was chosen, would you cc him/her, please? Maybe
that's better than changing it.



1. https://bugs.python.org/issue22682
2. https://lists.debian.org/debian-glibc/2004/06/msg00080.html


Saludos!

-- 
- ina



signature.asc
Description: OpenPGP digital signature

Bug#895946: rake: LoadError from Get::Ext::RakeBuilder trying to find rake

[Martin Dorey]

Package: rake
Version: 10.5.0-2
Severity: normal

Dear Maintainer,

Installing a gem that contains mkrf_conf, for example the three year old "beta"
of unf, causes rubygems/ext/builder.rb to take its RakeBuilder code path,
rather than, for example, the ExtConfBuilder path that the last "release" 
version
of unf uses.  This RakeBuilder path, at least in Stretch's rubygems, doesn't 
work
with Debian's rake package, even 12.3.1-1 from Buster, failing like this:

martind@balance:/tmp$ sudo gem install --no-ri --no-rdoc --prerelease unf
Fetching: unf-0.2.0.beta2.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing unf:
ERROR: Failed to build gem native extension.

current directory: /newvar/lib/gems/2.3.0/gems/unf-0.2.0.beta2/ext
/usr/bin/ruby2.3 mkrf_conf.rb

current directory: /newvar/lib/gems/2.3.0/gems/unf-0.2.0.beta2/ext
/usr/bin/ruby2.3 -rubygems 
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake 
RUBYARCHDIR=/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2 
RUBYLIBDIR=/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2
/usr/bin/ruby2.3: No such file or directory -- 
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake (LoadError)

rake failed, exit code 1

Gem files will remain installed in /var/lib/gems/2.3.0/gems/unf-0.2.0.beta2 for 
inspection.
Results logged to 
/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2/gem_make.out
martind@balance:/tmp$ 

The RakeBuilder code path, visible early in:

https://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/rake_builder.rb

... tries to run rake from Gem.bin_path("rake", "rake").  That's:

martind@balance:~$ ruby -we 'puts(Gem.bin_path("rake", "rake"))'
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake
martind@balance:~$ 

But the rake package only installs the binary as /usr/bin/rake.
That (upstream) source reveals a work-around: setting an environment variable,
"rake", to point to /usr/bin/rake.
That works for me.
Installing a later rake gem, with sudo gem install rake, as promoted by eg:

https://askubuntu.com/questions/872399/error-failed-to-build-gem-native-extension-when-trying-to-download-rubocop

... works too, but presumably the Debian package should work.
Perhaps you'd rather tackle this as an issue with the rubygems package.
It was just my guess that it would be less intrusive to tackle in rake.


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 
'oldstable-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rake depends on:
ii  ruby  1:2.3.3
ii  ruby1.8 [ruby-interpreter]1.8.7.358-7.1+deb7u5
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u7
ii  ruby2.1 [ruby-interpreter]2.1.5-2+deb8u3

Versions of packages rake recommends:
ii  zip  3.0-11+b1

rake suggests no packages.

-- no debconf information

Bug#895947: new upstream (5.0)

[Daniel Baumann]

Package: fonts-font-awesome
Severity: wishlist

Hi,

it would be nice if you could upgrade font-awesome to the current
upstream version (5.0.x).

Regards,
Daniel

Bug#895928: ITP: python-base58 -- base58 encode/decode for Python

[Daniele Nicolodi]

On 4/17/18 8:57 AM, Joel Cross wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joel Cross 
> 
> * Package name: python-base58
>   Version : 0.2.5
>   Upstream Author : David Keijser 
> * URL : https://github.com/keis/base58
> * License : MIT
>   Programming Lang: Python
>   Description : base58 encode/decode for Python
> 
> This package contains the following functions, in a form compatible with that
> used by the bitcoin network:
> - b58encode
> - b58decode
> - b58encode_check
> - b58decode_check

Hi Joel,

I had a look at this Python package a while ago, and I was very
surprised to find that its interface does not match the one of the
functions in the base64 standard library module in the use of strings vs
bytes.  I had to introduce some wrappers to make it sane in that regard.

I see in the upstream repository some commits that suggest that this has
been fixed (breaking the API probably).  However, nothing that hints
that a release has been made after that.

It would be nice to have the fixed version in Debian and to avoid API
breakage, at least once the Python package enters the Debian archive.

Cheers,
Dan

Bug#895913: please upgrade to new upstream version

[Christoph Biedl]

tags 895913 confirmed
thanks

Gürkan Myczko wrote...

> Please upgrade to the newer version 5.33

Yepp, it's on radar. Allow me a days the most to sort out a few issues
under the hood.

Christoph


signature.asc
Description: PGP signature

Bug#895945: gqrx-sdr is not starting due to missing libvolk.so.1.3

[Hans-J. Ullrich]

Package: gqrx-sdr
Version: 2.9-2
Severity: important

Dear Maintainer,

I found another thing for gqrx in debian/testing, which inhibits it to start. 

Description:

Gqrx is searching for libvolk.so.1.3, but it can not find it.

I examined, and made sure, libvolk1.3 is installed, so it is libvolk1.4. 
However, due to the installation of libvolk1.4, there is no entry for 
libvolk.so.1.3 below /usr/lib.

The physical installation of both libs (libvolk1.3 and libvolk1.4) is below 
/usr/lib/i386-linux-gnu/. 

Solution: 

Just add a symlink named "libvolk.so.1.3" pointing either to libvolk.so.1.3.1 
or libvolk.so.1.4.1 (both are working). I believve, the searched name in gqrx 
binary is hardcoded, so it MUST be the mentioned name.

This fix is easy to make, but there is still the segfault I sent in another 
bugreport.

Hope this helps.

Best regards

Hans





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

Kernel: Linux 4.15.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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

Versions of packages gqrx-sdr depends on:
ii  libboost-program-options1.62.0  1.62.0+dfsg-5
ii  libboost-system1.62.0   1.62.0+dfsg-5
ii  libc6   2.27-3
ii  libgcc1 1:8-20180402-1
ii  libgnuradio-analog3.7.113.7.11-8
ii  libgnuradio-audio3.7.11 3.7.11-8
ii  libgnuradio-blocks3.7.113.7.11-8
ii  libgnuradio-digital3.7.11   3.7.11-8
ii  libgnuradio-fft3.7.11   3.7.11-8
ii  libgnuradio-filter3.7.113.7.11-8
ii  libgnuradio-osmosdr0.1.40.1.4-14+b2
ii  libgnuradio-pmt3.7.11   3.7.11-8
ii  libgnuradio-runtime3.7.11   3.7.11-8
ii  liblog4cpp5v5   1.1.1-3
ii  libpulse0   11.1-5
ii  libqt5core5a5.10.1+dfsg-5
ii  libqt5gui5  5.10.1+dfsg-5
ii  libqt5network5  5.10.1+dfsg-5
ii  libqt5svg5  5.10.1-2
ii  libqt5widgets5  5.10.1+dfsg-5
ii  libstdc++6  8-20180402-1
ii  libvolk1.3  1.3.1-1
ii  pulseaudio  11.1-5

gqrx-sdr recommends no packages.

gqrx-sdr suggests no packages.

-- no debconf information

Bug#895944: biboumi: Please allow listening on ident in systemd service file

[Dominik George]

Source: biboumi
Version: 7.2-2
Severity: wishlist

Biboumi can act as identd, in order to allow the IRC server to identify
users on a connection. If run as biboumi user, this user needs the
correct capabilities set to listen on port 113.

The following setting under the Service section of the systemd service
file enables that:

AmbientCapabilities=CAP_NET_BIND_SERVICE

Please consider adding it in the package.

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

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

Bug#895852: chrony FTCBFS: configures for the build architecture

[Vincent Blut]

Control: tags -1 pending

Hi,

On Mon, Apr 16, 2018 at 10:20:27PM +0200, Helmut Grohne wrote:

Source: chrony
Version: 3.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

chrony fails to cross build from source, because it uses the build
architecture compiler. The configure script expects cross builders to
supply a CC variable and feed uname results via --host-*. Since the
Debian package is only built for linux-any, We can pass
--host-system=Linux and ignore the other values as they are not relevant
on Linux.


I do intend to provide support for kFreeBSD in Buster though.

The attached patch implements that and makes chrony cross buildable.  
Please consider applying it.


Will do. Thanks a lot Helmut!


Helmut


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#895932: [thunderbird] Configured font size ignored for Multipart messages

[Kevin Steen]

Dear Carsten

On 17/04/18 16:49, Carsten Schoenert wrote:


care to push this upstream?
It would ne nice if you can create a entry in the bugzilla issue
tracker from Mozilla and provide back the URL for the bug report?
Thanks!


Upstream bug reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1447408

It appears this is not a bug, just a complicated font-setting dialog. 
UTF-8 messages are shown in a different font to ISO-8859-1/us-ascii 
messages.


For the benefit of anyone else coming across this - the solution is to 
change the font for the 'Latin' option, and then choose the 'Other 
Writing systems' and change the font again.


I'd recommend closing this bug - the redesign of the dialog will be a 
whole new bug report.


-Kevin

Bug#895943: transition: perl 5.26.2

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 17/04/18 18:38, Niko Tyni wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> perl 5.26.2-1 in experimental. It is binary compatible with 5.26.0 and
> 5.26.1 and therefore Provides all of perlapi-5.26.0, perlapi-5.26.1
> and perlapi-5.26.2.  However, as usual, four packages will need binNMUs
> once it enters unstable due to their strict versioned dependencies on
> the current perl version:
> 
>  libpar-packer-perl
>  libdevel-cover-perl
>  libclass-xsaccessor-perl
>  libcommon-sense-perl
> 
> These binNMUs will need the 'extra-depends' wanna-build feature to make
> sure the new perl is pulled in.
> 
> Please let us know if/when it's OK to upload.

Please go ahead.

Cheers,
Emilio

Bug#895943: transition: perl 5.26.2

[Niko Tyni]

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

Hi,

perl 5.26.2-1 in experimental. It is binary compatible with 5.26.0 and
5.26.1 and therefore Provides all of perlapi-5.26.0, perlapi-5.26.1
and perlapi-5.26.2.  However, as usual, four packages will need binNMUs
once it enters unstable due to their strict versioned dependencies on
the current perl version:

 libpar-packer-perl
 libdevel-cover-perl
 libclass-xsaccessor-perl
 libcommon-sense-perl

These binNMUs will need the 'extra-depends' wanna-build feature to make
sure the new perl is pulled in.

Please let us know if/when it's OK to upload.

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.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

Bug#891334: libglib-object-introspection-perl: Does not recommend or depend on libxml-libxml-perl for perli11ndoc

[gregor herrmann]

On Tue, 17 Apr 2018 10:41:47 -0400, oldtechaa wrote:

> The Debian policy section you linked to says a bug regarding an application
> with no manpage may be forwarded to upstream. Is that a good idea in this
> case? That way a manpage could be created upstream (by me if necessary) and
> then everyone who uses upstream would also have a manpage.

It would be awesome if you could create a patch for the
documentation/POD/manpage and send it upstream. As you say, that way
everyone would profit from it.
 
> In the meantime, here's a patch that adds the package Suggests.

Thanks, applied in git.
 

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: Ludwig Hirsch: Rebekka und ich


signature.asc
Description: Digital Signature

Bug#891339: libglib-object-introspection-perl: Documentation should make a note that the base library devel packages must be installed

[gregor herrmann]

On Tue, 17 Apr 2018 10:23:46 -0400, oldtechaa wrote:

> Here's a patch for debian/control that should fix this. It seems like it
> could be made clearer. If you have any thoughts on this, I can change it.

Thanks!
Applied in git.
 
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: Ludwig Hirsch: Rebekka und ich


signature.asc
Description: Digital Signature

Bug#879970: qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets segfault at startup

[Thorsten Glaser]

affects 895375 src:qtwebsockets-opensource-src
affects 895375 src:qtscript-opensource-src
affects 895375 src:qtgraphicaleffects-opensource-src
thanks

Aaron M. Ucko dixit:

>Builds of qtwebsockets-opensource-src for sparc64 and x32 (admittedly
>not release architectures) have been failing lately, with
>tst_qmlwebsockets segfaulting before even printing the usual "Start
>testing" banner, per the following excerpts from (respectively)

I’ve reported 895375 based on this problem, although only checked
on x32 since that’s my desktop machine at the workplace; a local
build failt the same way.

If anyone knowledgeable about the inner workings of Qt could please
have a look…

Thanks in advance,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#895942: RFS: python-base58/0.2.5-1 [ITP]

[Joel Cross]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "python-base58"

 * Package name: python-base58
   Version : 0.2.5-1
   Upstream Author : David Keijser 
 * URL : https://github.com/keis/base58
 * License : MIT
   Section : python

  It builds those binary packages:

python3-base58 - base58 encode/decode for Python

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

  https://mentors.debian.net/package/python-base58


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

dget -x https://mentors.debian.net/debian/pool/main/p/python-base58/python-
base58_0.2.5-1.dsc

  More information about base58 can be obtained from
https://github.com/keis/base58/.

  Regards,
   Joel Cross



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

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

Bug#895941: qtmultimedia-opensource-src: FTBFS on x32: XDG_RUNTIME_DIR points to non-existing path '/run/user/114'; followed by segfault

[Thorsten Glaser]

Source: qtmultimedia-opensource-src
Version: 5.10.1-2
Severity: important
Justification: FTBFS on non-release architecture

Excerpt from the build log:

* Finished testing of tst_QAudioNamespace *
make[4]: Leaving directory '/<>/tests/auto/unit/qaudionamespace'
cd qcamera/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/tests/auto/unit/qcamera/qcamera.pro 'QMAKE_CFLAGS_RELEASE=-g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
'QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr QT_BUILD_PARTS+=tests ) && make -f Makefile check
make[4]: Entering directory 
'/<>/tests/auto/unit/qdeclarativemultimediaglobal'
/<>/tests/auto/unit/qdeclarativemultimediaglobal/target_wrapper.sh 
 ./tst_qdeclarativemultimediaglobal
QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/114', 
please create it with 0700 permissions.
Makefile:468: recipe for target 'check' failed
make[4]: *** [check] Segmentation fault
make[4]: Leaving directory 
'/<>/tests/auto/unit/qdeclarativemultimediaglobal'
Makefile.multimediaqml:466: recipe for target 
'sub-qdeclarativemultimediaglobal-check' failed
make[3]: *** [sub-qdeclarativemultimediaglobal-check] Error 2
Makefile:399: recipe for target 'sub-multimediaqml-pro-check' failed

Full log:
https://buildd.debian.org/status/fetch.php?pkg=qtmultimedia-opensource-src&arch=x32&ver=5.10.1-2&stamp=1523251402&raw=0

This may or may not be related to #879967 and effectively #895375.

Bug#895940: RFS: python-dataclasses/0.5-1 [ITP]

[Joel Cross]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "python-dataclasses"

 * Package name: python-dataclasses
   Version : 0.5-1
   Upstream Author : Eric V. Smith 
 * URL : https://github.com/ericvsmith/dataclasses
 * License : MIT
   Section : python

  It builds those binary packages:

python3-dataclasses - Python dataclasses backport from 3.7

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

  https://mentors.debian.net/package/python-dataclasses


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

dget -x https://mentors.debian.net/debian/pool/main/p/python-
dataclasses/python-dataclasses_0.5-1.dsc

  More information about Python dataclasses can be obtained from
https://www.python.org/dev/peps/pep-0557.

  Regards,
   Joel Cross



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

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

Bug#895939: qtwebsockets-opensource-src: FTBFS on hurd-i386: the requested timeout (5000 ms) was too short, 5150 ms would have been sufficient this time

[Thorsten Glaser]

Source: qtwebsockets-opensource-src
Version: 5.10.1-2
Severity: important
Justification: FTBFS but on non-release architecture

https://buildd.debian.org/status/fetch.php?pkg=qtwebsockets-opensource-src&arch=hurd-i386&ver=5.10.1-2&stamp=1523796345&raw=0

FAIL!  : tst_QWebSocket::tst_errorString() QTestLib: This test case check 
("errorSpy.count())) == (1)))") failed because the requested timeout (5000 
ms) was too short, 5150 ms would have been sufficient this time.

In general, Hurd systems are somewhat slower, plus, as far as I’m
informed, the buildd is somewhat old and slow hardware because it
doesn’t run on too new hardware either.

Since we have even slower architectures (like m68k, perhaps sh4)
please don’t use too tight timeouts.

Thanks,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Chris Lamb]

Hi Inaki!

> Anyway, here's a proposal to change it to another encoding which I
> already tested.

First, thanks for the patch!

Could you expand the commit message on this patch to include the
reason why beyond "causes trouble"?

I ask because I see that the help2man maintainer has provided some
more details re. Perl/locale support:

  https://bugs.debian.org/894126#10

… and we should probably quote them instead of leaving it so
vague. I might also be tempted to add a comment to the code itself
for the same reason; I suggest you try it and see how it looks/reads
in context - it is difficult to tell in the abstract.

Hm, whilst I think of it, is there any possibility this locale was
chosen *deliberately* because it's broken? Alas I'm not an expert
in this code at all..  (Ximin?)


Regards,

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

Bug#895889: [pkg-go] Bug#895889: golang-github-weaveworks-mesh: new version causes regression in prometheus-alertmanager

[Paul Gevers]

Hi Martín,

On 17-04-18 17:35, Martín Ferrari wrote:
> I did not notice the update of mesh would break the current alertmanager
> in testing.

Not in testing *yet* (that is the purpose of this bug), but it would
break it if allowed to migrate.

> I did the upload yesterday in preparation for a new upload
> of the alertmanager, so this FTBFS will be solved as soon as I am finished.

From the fundamental point of tracking dependencies and such,
golang-github-weaveworks-mesh needs an appropriate Breaks:
prometheus-alertmanager (< $the_next_version) or something along those
lines.

> Sadly, the golang ecosystem is very immature and has not yet learned
> about API stability or even releases...

Ack. (So from the practical point of view, I am not sure if the Breaks
is worth the effort, but I leave you to judge that).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[Sean Whitton]

control: tag -1 +moreinfo

Hello Dan,

On Wed, Dec 30, 2015 at 10:05:08AM +0800, 積丹尼 Dan Jacobson wrote:
> On
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
> please add an explicit statement:
> 
> A package listed in Depends must not also be listed in Suggests or
> Recommends.
> 
> Or
> 
> A package listed in Depends may also be listed in Suggests or
> Recommends.

Could you explain why you think this is needed, please?  What problems
could be caused by a package being listed in more than one field, and
what problems could be caused by forbidding that?

Semantically, it seems we should allow things like this:

Depends: foo (>= 2)
Recommends: foo (>= 3)

but I don't yet see why Policy needs to say anything about it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#895938: pypy-lib: ships the pypy-cffi pydist-override file in the wrong place

[Nicolas Dandrimont]

Package: pypy-lib
Version: 5.10.0+dfsg-3+b1
Severity: normal
Tags: patch

Hi,

pypy-lib ships a pydist override file for its built-in cffi module in
/usr/share/dh-python/dist/pypy/pypy-cffi. However, dh-python looks for those
files in /usr/share/pypy/dist/.

This makes builds of packages depending on cffi warn with:

  I: dh_pypy pydist:220: Cannot find package that provides cffi. Please add
  package that provides it to Build-Depends or add "cffi pypy-cffi" line to
  debian/pypydist-overrides or add proper dependency to Depends by hand and 
ignore
  this info.

and, of course, the cffi backend version machinery is ignored.

As far as I can tell, the /usr/share/dh-python/dist path seems to be for
pydist-overrides shipped by dh-python directly.

The (untested) attached patch might do the right thing.

Thanks for considering,

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

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

Versions of packages pypy-lib depends on:
ii  dpkg  1.19.0.5

pypy-lib recommends no packages.

pypy-lib suggests no packages.

-- no debconf information
>From 0ef3df76767debdc3b0445019ab66049d2f1396a Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont 
Date: Tue, 17 Apr 2018 18:13:21 +0200
Subject: [PATCH] Fix pypydist-override path

---
 debian/scripts/gen-backend-versions.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/scripts/gen-backend-versions.py 
b/debian/scripts/gen-backend-versions.py
index 36cdc37b..9dd5fa80 100755
--- a/debian/scripts/gen-backend-versions.py
+++ b/debian/scripts/gen-backend-versions.py
@@ -66,7 +66,7 @@ with codecs.open('debian/pypy-lib.substvars', 'a', 
encoding='UTF-8') as f:
 with codecs.open('debian/pypy.substvars', 'a', encoding='UTF-8') as f:
 f.write('pypy-abi={}\n'.format(pypy_abi()))
 
-path = 'debian/pypy-lib/usr/share/dh-python/dist/pypy'
+path = 'debian/pypy-lib/usr/share/pypy/dist'
 os.makedirs(path)
 with codecs.open(os.path.join(path, 'pypy-cffi'), 'w', encoding='UTF-8') as f:
 f.write('cffi pypy-cffi-backend-api-min (<= {target}), '
-- 
2.17.0

Bug#895937: digikam: database upgrade from schema 8 to 9 fails

[tv.deb...@googlemail.com]

Package: digikam
Version: 4:5.9.0-1
Severity: important

Dear Digikam Maintainer,


   * What led up to the situation?

Upgrading to latest Unstable Digikam version

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

No workaround tried as Digikam exits immediately after database 
migration fails.


Error messages is as follow:

"
digikam.general: AlbumWatch use QFileSystemWatcher
digikam.general: Database Parameters:
   Type: "QMYSQL"
   DB Core Name: "digikamdb"
   DB Thumbs Name:   "digikam_thumbsdb"
   DB Face Name: "digikam_faces"
   Connect Options:  ""
   Host Name:"localhost"
   Host port:3306
   Internal Server:  false
   Internal Server Path: ""
   Internal Server Serv Cmd: ""
   Internal Server Init Cmd: ""
   Username: "digikam"
   Password: ""

digikam.dbengine: Loading SQL code from config file 
"/usr/share/digikam/database/dbconfig.xml"

digikam.dbengine: Checking XML version ID => expected:  3  found:  3
digikam.coredb: Core database: running schema update
digikam.coredb: Core database: have a structure version  8
digikam.coredb: Core database: makeUpdates  8  to  9
digikam.dbengine: Failure executing query:
 ""
Error messages: "QMYSQL: Unable to execute query" "Illegal mix of 
collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for 
operation '='" 1267 2

Bound values:  ()
digikam.dbengine: Error while executing DBAction [ 
"UpdateSchemaFromV7ToV9" ] Statement [ "CALL 
drop_index_if_exists('AlbumRoots', 'identifier');" ]

digikam.coredb: Core database: schema update to V 9 failed!
digikam.coredb: Core database: cannot process schema initialization
KMemoryInfo: Platform identified :  "LINUX"
KMemoryInfo: TotalRam:  16826564608
digikam.general: Allowing a cache size of 200 MB
QThreadStorage: Thread 0x7f10cf629bc0 exited after QThreadStorage 11 
destroyed

"
Connecting to Mariadb Digikam databases as user "digikam" works, 
checking databases (mysqlcheck) reports no error.


Thank you for your time.

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-rc1-deb64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages digikam depends on:
ii  digikam-data  4:5.9.0-1
ii  digikam-private-libs  4:5.9.0-1
ii  kipi-plugins  4:5.9.0-1
ii  libc6 2.27-3
ii  libgcc1   1:8-20180414-1
ii  libkf5configcore5 5.44.0-1
ii  libkf5coreaddons5 5.44.0-1
ii  libkf5filemetadata3   5.44.0-1
ii  libkf5i18n5   5.44.0-1
ii  libqt5core5a  5.10.1+dfsg-5
ii  libqt5gui55.10.1+dfsg-5
ii  libqt5sql55.10.1+dfsg-5
ii  libqt5sql5-mysql  5.10.1+dfsg-5
ii  libqt5sql5-sqlite 5.10.1+dfsg-5
ii  libqt5widgets55.10.1+dfsg-5
ii  libstdc++68-20180414-1
ii  perl  5.26.1-6

Versions of packages digikam recommends:
ii  chromium [www-browser]  66.0.3359.26-2
ii  ffmpegthumbs4:17.08.3-1
ii  firefox [www-browser]   59.0.2-1
ii  google-chrome-stable [www-browser]  65.0.3325.181-1
ii  konqueror [www-browser] 4:17.08.3-2
ii  lynx [www-browser]  2.8.9dev17-1

Versions of packages digikam suggests:
pn  digikam-doc 
ii  systemsettings  4:5.12.4-1

-- no debconf information