Bug#948116: RFS: zope.hookable/5.0.0-1 [QA] -- Hookable object support

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zope.hookable"

 * Package name: zope.hookable
   Version : 5.0.0-1
   Upstream Author : Zope Corporation and Contributors 


 * URL : https://pypi.python.org/pypi/zope.hookable
 * License : Zope-2.1
 * Vcs : None
   Section : zope

It builds those binary packages:

  python3-zope.hookable - Hookable object support

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


  https://mentors.debian.net/package/zope.hookable

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zope.hookable/zope.hookable_5.0.0-1.dsc


Changes since the last upload:

   * QA upload.
   * New upstream release
   * d/control
 - Change to debhelper-compat
 - Bump to debhelper 12
 - Update to Standards-Version 4.4.1
 - Add Root-Requires-Root: no
 - Change priority from extra to optional
 - Use secure URI on homepage.
 - Added more info in extended-section.
   * d/watch
 - Use Secure URI.
   * d/copyright
 - Use secure URI.
   * d/rules
 - Add hardening=+all

Regards,
Håvard

Bug#618900: I NEED AN IMMEDIATE RESPONSE FROM YOU

[Dr Haruna Bello]

  I am Dr Haruna Bello

I NEED AN IMMEDIATE RESPONSE FROM YOU

I have a Geniue business transaction of 18.5 Million Us Dollars to do with
You
Hence You Co-operate with me I am assured you that within (7) seven
banking working days, this said amount will enter your given Bank
account with immediate alacrity. If you agree to my business proposal,
further details of the transfer will be forwarded to you as soon as I
receive your wiliness to join hand with me.
Am awaiting your urgent response with this informations
Name:...
Sex:...
Age:...
Occupation:
Address:...
Tel/ Fax:...
State:.
Country Of origin:..


Have a nice day!!

Bug#945920: Random Chromium crashes

[David Booss]

I'm not at all sure if this is the right way to do it, but I was able to 
build using the enable-tracing.patch from Eloston by commenting out the 
public_configs lines containing zlib_config in 
third_party/perfetto/gn/BUILD.gn


Right now I am typing into my webmail client using Chromium from that 
build. I had to install libevent-2.1-6 before installing the Chromium 
packages. I installed the debug symbols and am running it under gdb so 
if it crashes I will report back with some output.

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Giovanni Mascellani]

Hi,

Il 03/01/20 22:07, Adrian Bunk ha scritto:
> Dimitri already agreed in a private discussion that this change was bogus.
> 
> Are there any objections against an NMU reverting the bogus Python 2
> removal in boost1.67?

Totally agree that there is no reason to remote Python 2 support from
boost1.67. Please do the NMU.

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



signature.asc
Description: OpenPGP digital signature

Bug#946648: Chromium randomly crashes in the latest version.; crashes within a few minutes

[Jürgen Göricke]

Dear Maintainer,

where do we go from here with this bug of crashes?
A new version is already available and could be rolled out.

https://chromium.googlesource.com/chromium/src.git/+/refs/tags/79.0.3945.112

It would be nice if we, the community could test the new version.
This could close 2 bug reports at once.

Best regards


pgp0CGN5FFf5q.pgp
Description: Digitale Signatur von OpenPGP

Bug#948114: 3.26.4 available since Nov 12, 2019

[crvi c]

sid@unstable:~/source/git/crvi/totem-pl-parser$ git log

commit ea7238580d0d94a439295eb92890f6229a51c382 (HEAD -> master, tag:
V_3_26_4, origin/master, origin/HEAD)
Author: Bastien Nocera 
Date:   Tue Nov 12 16:07:37 2019 +0100

3.26.4

Bug#948115: Revise init script Policy based on GR result

[Russ Allbery]

Package: debian-policy
Version: 4.4.1.2
Severity: important

Per recent (non-BTS) discussion, this patch is a first draft at
reconciling Policy with the recent GR result.  Summary of changes:

* Change section headings and anchors to reflect the more general topic
* Add recommended naming convention for service units
* Encourage including an init script if there is no service unit
* Describe including an init script alongside a service unit as optional
* Recommend appropriate naming of an init script alongside a service unit
* Remove recommendation to include an init script
* Use init script rather than initscript consistently
* Move some things around that belong more naturally in other sections
* Be consistent about saying update-rc.d is a requirement
* Remove the section on alternate init systems, which is now not relevant

Policy itself has no links to the previous anchors.  This might
break external links; let me know if you feel like that's a larger
issue than I thought it was and we can look at keeping the old
(but pretty wildly inaccurate) anchors.

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 4551196..47d9fe4 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -315,46 +315,53 @@ set to this value.
 The Debian autobuilders set HOME to ``/nonexistent`` so that packages
 which try to write to a home directory will fail to build.
 
-.. _s-sysvinit:
+.. _s-services:
 
-System run levels and ``init.d`` scripts
-
+Starting system services
+
 
-.. _s-etc-init.d:
+.. _s-services-intro:
 
 Introduction
 
 
-The ``/etc/init.d`` directory contains the scripts executed by ``init``
-at boot time and when the init state (or "runlevel") is changed (see
-:manpage:`init(8)`).
-
-``systemd`` uses dependency information contained within the init
-scripts and symlinks in ``/etc/rcn.d`` to decide which scripts to run
-and in which order. The ``sysv-rc`` runlevel system uses symlinks in
-``/etc/rcn.d`` to decide which scripts to run and in which order; see
-the ``README.runlevels`` file shipped with ``sysv-rc`` for
-implementation details. Other alternatives might exist.
-
-Maintainer scripts must use ``update-rc.d`` as described below to
-interact with the service manager for requests such as enabling or
-disabling services. They should use ``invoke-rc.d`` as described below
-to invoke initscripts for requests such as starting and stopping
-service.
+Packages that include system services should include ``systemd`` service
+units to start or stop those services.  See :manpage:`systemd.service(5)`
+for details on the syntax of a service unit file.  In the common case that
+a package includes a single system service, the service unit should have
+the same name as the package plus the ``.service`` extension.
+
+If the package does not include a service unit (if, for example, no one
+has yet written one), including an init script, as described below, to
+start the service is encouraged.
+
+Packages including a service unit may optionally include an init script to
+support other init systems.  In this case, the init script should have the
+same name as the ``systemd`` service unit so that ``systemd`` will ignore
+it and use the service unit instead.  Packages may also support other init
+systems by including configuration in the native format of those init
+systems.
+
+If a service unit is not present, ``systemd`` uses dependency information
+contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
+which scripts to run and in which order.  The ``sysv-rc`` runlevel system
+for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
+scripts to run and in which order at boot time and when the init state (or
+"runlevel") is changed.  See the ``README.runlevels`` file shipped with
+``sysv-rc`` for implementation details.  Other alternatives might exist.
+
+The sections below describe how to write those scripts and configure those
+symlinks.
 
 .. _s-writing-init:
 
 Writing the scripts
 ~~~
 
-Packages that include system services should include ``systemd`` service
-units to start or stop those services.  See :manpage:`systemd.service(5)`.
-
-To support other init systems, packages that include daemons for system
-services should place scripts in ``/etc/init.d`` to start or stop those
-services at boot time or during a change of runlevel. These scripts should
-be named ``/etc/init.d/package``, and they should accept one argument,
-saying what to do:
+Init scripts are placed in ``/etc/init.d``.  In the common case that a
+package starts a single service, they should be named
+``/etc/init.d/package``.  They should accept one argument, saying what to
+do:
 
 ``start``
 start the service,
@@ -381,10 +388,9 @@ saying what to do:
 ``status``
 report the current status of the service
 
-The ``start``, ``stop``, ``restart``, and ``force-reload`` options
-should be supporte

Bug#948089: gkrellm-thinkbat FTCBFS: builds for the build architecture

[Adam Sloboda]

Hello,

Thanks for the patch.  Unfortunately this package was sponsored so
there is nothing I can do about it, personally.

If there is anyone who can, feel free to NMU or adopt the package.

-Adam

Bug#948114: libtotem-plparser18: Upgrade package to version 3.26.4

[crvi]

Package: libtotem-plparser18
Version: 3.26.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Cannot build git totem package

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

Build git totem

   * What was the outcome of this action?

sid@unstable:~/source/git/crvi/totem$ meson build
The Meson build system
Version: 0.52.1
Source dir: /home/sid/source/git/crvi/totem
Build dir: /home/sid/source/git/crvi/totem/build
Build type: native build
Project name: totem
Project version: 3.34.0
C compiler for the host machine: cc (gcc 9.2.1 "cc (Debian 9.2.1-21) 9.2.1
20191130")
C linker for the host machine: GNU ld.bfd 2.33.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -fno-strict-aliasing: YES
Compiler for C supports arguments -Wcast-align: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Werror=format=2: YES
Compiler for C supports arguments -Werror=implicit-function-declaration: YES
Compiler for C supports arguments -Werror=init-self: YES
Compiler for C supports arguments -Werror=missing-include-dirs: YES
Compiler for C supports arguments -Werror=missing-prototypes: YES
Compiler for C supports arguments -Werror=pointer-arith: YES
Compiler for C supports arguments -Werror=return-type: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Found pkg-config: /usr/bin/pkg-config (0.29)
Run-time dependency glib-2.0 found: YES 2.62.4
Run-time dependency gobject-2.0 found: YES 2.62.4
Run-time dependency gio-2.0 found: YES 2.62.4
Run-time dependency gtk+-3.0 found: YES 3.24.13
Run-time dependency gstreamer-1.0 found: YES 1.16.2
Run-time dependency gstreamer-tag-1.0 found: YES 1.16.2
Run-time dependency gstreamer-video-1.0 found: YES 1.16.2
Run-time dependency gstreamer-pbutils-1.0 found: YES 1.16.2
Run-time dependency libpeas-1.0 found: YES 1.22.0
Run-time dependency libpeas-gtk-1.0 found: YES 1.22.0
Dependency totem-plparser found: NO found '3.26.3' but need: '>= 3.26.4'
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency totem-plparser found: NO

meson.build:143:0: ERROR: Invalid version of dependency, need 'totem-plparser'
['>= 3.26.4'] found '3.26.3'.

A full log can be found at /home/sid/source/git/crvi/totem/build/meson-
logs/meson-log.txt


   * What outcome did you expect instead?

Successfull build



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

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

Versions of packages libtotem-plparser18 depends on:
ii  libarchive13  3.4.0-1+b1
ii  libc6 2.29-7
ii  libgcrypt20   1.8.5-3
ii  libglib2.0-0  2.62.4-1
ii  libquvi-0.9-0.9.3 0.9.3-1.3
ii  libtotem-plparser-common  3.26.3-1
ii  libxml2   2.9.4+dfsg1-8

libtotem-plparser18 recommends no packages.

libtotem-plparser18 suggests no packages.

-- no debconf information

Bug#948113: ITP: golang-github-checkpoint-restore-go-criu -- CRIU bindings for Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:runc
Control: block 930440 by -1

   Package name: golang-github-checkpoint-restore-go-criu
Version: 3.11
License: Apache-2.0 and GPL-2
URL: https://github.com/checkpoint-restore/go-criu
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-checkpoint-restore-go-criu
Description: CRIU bindings for Golang
 Golang bindings for CRIU. The code is based on the Golang-based PHaul
 implementation from the CRIU repository.
 .
 Golang bindings provide an easy way to use the CRIU RPC calls from Golang
 without the need to set up all the infrastructure to make the actual RPC
 connection to CRIU.


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

Bug#947653: csv2latex FTCBFS: strips with the wrong strip

[Benoît Rouits]

Ok, thank you Helmut.

As I am also the upstream dev of csv2latex. After reflection, I
eventually found 'strip' being useless now. So, instead of making a
patch in the debian/patches, I released csv2latex-0.22 (upstream) with
Makefile fixed (no strip at all), so that it is simpler for everyone.

I just uploaded the Debian source package on :
https://mentors.debian.net/package/csv2latex

Hopefully, I know a mentor that will almost certainly upload the package
in unstable in a few hours or days.

Thank you again for your bug report!
I let you close bug #947653 when you want (reason: fixed upstream)...
 Benoît

Le 02/01/2020 à 20:08, Helmut Grohne a écrit :
> Hi Benoît,
> 
> On Sun, Dec 29, 2019 at 05:57:51PM +0100, Benoît Rouits wrote:
>> Unfortunately, i cannot sign the new source package due to your
>> changelog entry. What is the best way to integrate your patch then ?
>> May i change the debian changelog entry with my own message or is there
>> a better way to integrate your patch (maybe you should sign the source
>> package) ?
> 
> Of course you should change the changelog entry. It is still unreleased.
> You can use "dch -r" to update the release. Doing so will also change
> the final email address to yours. Alternatively, you can edit the text
> yourself or only apply the non-changelog portion of my patch and
> manually add your changelog. Whatever fits your workflow.
> 
> Helmut
> 



signature.asc
Description: OpenPGP digital signature

Bug#948112: python3-pyqt5: Unstable python3-pyqt5 Is Not Installable With libqt5qui5-gles Installed

[Ron Lovell]

Package: python3-pyqt5
Version: 5.13.2+dfsg-1
Severity: important

Currently in Sid the python3-pyqt5 package has deps:
libqt5gui5 (>= 5.1.0)
libqt5gui5 (>= 5.12.2) | libqt5qui5-gles (>= 5.12.2)

I recently performed the tranition from libqt5gui5 to the -gles variant
just to try it out. I had to remove python3-pyqt5 and and its dependents
(e.g. python3-qtconsole). I expected it might take a while to complete
the ongoing transition, and in fact in the transition tracking web
page pyqt5 still shows as in progress (or whatever orange means). But
after looking over the transition Bug #919218, especially the comments
about a similar dependency in libqt5quick5, I'm wondering if there's
going to be a resolution soon for python3-pyqt5.  If so, I can wait. If
not, I need to go back to libqt5gui5 so I can have jupyter qtconsole.

If I'm just being too impatient (we did just celebrate the holidays),
my apologies.


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

Kernel: Linux 5.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.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 python3-pyqt5 depends on:
ii  libc6 2.29-7
ii  libgcc1   1:9.2.1-21
ii  libpython3.7  3.7.6-1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-5
ii  libqt5dbus5   5.12.5+dfsg-5
pn  libqt5designer5   
ii  libqt5gui5-gles   5.12.5+dfsg-1
pn  libqt5help5   
ii  libqt5network55.12.5+dfsg-5
pn  libqt5printsupport5   
pn  libqt5test5   
ii  libqt5widgets55.12.5+dfsg-5
pn  libqt5xml5
ii  libstdc++69.2.1-21
ii  python3   3.7.5-3
pn  sip-py3api-12.7   

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

NOTE: I have libqt5gui5-gles 5.12.5+dfsg-1 installed.

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sean Whitton  writes:

> Let's definitely reconsider those 'must' requirements in response to
> this work, but let's not commit ourselves to the idea that it's always a
> bug for the Release Team's conception of an RC bug, and Policy 'must'
> requirements, to disagree.

> The Release Team's conception of RC bugs, and the text of Policy, are
> generated and updated by different processes, for different purposes.  I
> think Debian benefits from that diversity of normative processes, and it
> would harm that to try too hard to keep the output of the two processes
> in perfect sync.

Yes, that's put better than I put it.  Thank you.  I was too focused on
the fact that I suspect we'll find some musts that are too aggressive, but
indeed, allowing these things to differ is part of why I'm proposing
explicit language to allow the Release Team to downgrade requirements to
recommendations.

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

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Russ Allbery  writes:

> I agree, but let's also fix existing incorrect wording.  I reviewed
> every instance of may and optional in Policy, and I think this larger
> diff will make wording (mostly) consistent.  I've tried not to change
> the sense of any of these Policy statements (even though a few are
> questionable and should probably be revisited).

Here is an updated version of this patch, including the upgrading
checklist entry.  I tried using a word diff, but I think the line diff is
more readable and easier to understand.  I at least found it easier to
understand the wording changes in that format (maybe this is just my long
familiarity with reviewing line diffs).

I think this is ready for seconds, assuming that one agrees with the three
places that I made semantic changes (/usr/lib64, init-system-helpers, and
deciding on encouraged for debian/missing-sources).

Most of this diff is changing normative "may not" phrasings to "must not"
or some other equivalent, and changing other uses of "may" to "could" or
other wordings.

This retains the statement about the release team's role in changing the
severity of Policy requirements, since I think that was the outcome of the
side conversation.  I'll work on an appendix accumulating all Policy
requirements in a separate patch.

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index b8ba081..e37ebee 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -329,8 +329,8 @@ management tools.
 the user doesn't select anything else. It doesn't include many large
 applications.
 
-No two packages that both have a priority of ``standard`` or higher
-may conflict with each other.
+Two packages that both have a priority of ``standard`` or higher must
+not conflict with each other.
 
 ``optional``
 This is the default priority for the majority of the archive. Unless
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 74a1690..f1e518e 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts 
must provide
 the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
 
 All packages which supply an instance of a common command name (or, in
-general, filename) should generally use ``update-alternatives``, so that
-they may be installed together. If ``update-alternatives`` is not used,
+general, filename) should generally use ``update-alternatives`` so that
+they can be installed together. If ``update-alternatives`` is not used,
 then each package must use ``Conflicts`` to ensure that other packages
 are removed. (In this case, it may be appropriate to specify a conflict
 against earlier versions of something that previously did not use
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 0d7a3e9..8d43130 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, 
architectures,
 files or anything else) or version numbers, or between the characters of
 multi-character version relationships.
 
-The presence and purpose of a field, and the syntax of its value may
+The presence and purpose of a field, and the syntax of its value, may
 differ between types of control files.
 
 Field names are not case-sensitive, but it is usual to capitalize the
@@ -553,7 +553,7 @@ The three components here are:
 ``epoch``
 This is a single (generally small) unsigned integer. It may be
 omitted, in which case zero is assumed. If it is omitted then the
-``upstream_version`` may not contain any colons.
+``upstream_version`` must not contain any colons.
 
 Epochs can help when the upstream version numbering scheme
 changes, but they must be used with care.  You should not change
@@ -572,19 +572,19 @@ The three components here are:
 respect to the ``upstream_version`` is described below. The
 ``upstream_version`` portion of the version number is mandatory.
 
-The ``upstream_version`` may contain only alphanumerics [#]_ and
+The ``upstream_version`` must contain only alphanumerics [#]_ and
 the characters ``.`` ``+`` ``-`` ``~`` (full stop, plus, hyphen,
 tilde) and should start with a digit. If there is no
 ``debian_revision`` then hyphens are not allowed.
 
 ``debian_revision``
 This part of the version number specifies the version of the Debian
-package based on the upstream version. It may contain only
+package based on the upstream version. It must contain only
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
 It is optional; if it isn't present then the ``upstream_version``
-may not contain a hyphen. This format represents the case where a
+must not contain a hyphen. This format represents the case where a
 piece of software was written specifically t

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sean Whitton  writes:
> On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote:

>>  is being used.) You must not include the ``/etc/rcn.d`` directories
>> -themselves in the archive either. (Only the ``sysvinit`` package may do
>> -so.)
>> +themselves in the archive either. (Only the ``init-system-helpers``
>> +package may do so.)

> Likewise, isn't this a semantic change?

This is, but I think it's a bookkeeping change.  Those directories are in
init-system-helpers rather than sysvinit in the archive right now, and
that clearly shouldn't be a policy violation.

Ideally it should probably be in a separate commit, but in looking at this
again I also want to change "may do so" to "is permitted to do so."  I can
break it out if needed, but I'd rather commit it as part of this set of
changes (and will document it separately in debian/changelog; I don't
think it warrants adding to upgrading-checklist since it only affects one
set of maintainers who already know).

>> @@ -797,14 +798,13 @@ the upstream tarball.  In order to satisfy the DFSG 
>> for packages in
>>  2. include a copy of the sources in the ``debian/missing-sources``
>> directory.
>>
>> -There is an optional convention to organise the contents of
>> -``debian/missing-sources`` in the following way.  For a sourceless
>> -file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
>> -where the source of ``foo`` has extension ``baz``, the source is to be
>> -located at ``debian/missing-sources/bar/foo.baz``.  For example,
>> -according to this convention, the C source code of an executable
>> -``checksum/util`` is to be located at
>> -``debian/missing-sources/checksum/util.c``.
>> +Package maintainers are encouraged to use the following convention to
>> +organize the contents of ``debian/missing-sources``: for a sourceless file
>> +``foo`` in the subdirectory ``bar`` of the upstream tarball, where the
>> +source of ``foo`` has extension ``baz``, the source is to be located at
>> +``debian/missing-sources/bar/foo.baz``. For example, according to this
>> +convention, the C source code of an executable ``checksum/util`` would be
>> +located at ``debian/missing-sources/checksum/util.c``.

> I don't think this should be strengthened to something Policy
> encourages, or if it should, we should discuss it in a separate bug.  So
> I'd like to suggest using none of the magic words in this paragraph,
> just starting it with "There is a convention to organise ..."

I think this is a change where the distinction between optional and
encouraged is valuable and this would have been written as encouraged if
we had that concept.  There's not much point in a convention unless we
advise maintainers to follow it, and that seems like an appropriate use of
Policy advice.

Does that make sense?  I can revise it if you don't like it after that
explanation, but it feels perfect for "encourage."

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

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Joshua Hudson]

> Is there actually a pulseaudio daemon running?

yup.

> Where?

Not sure what this is supposed to mean.

> Is it managed by systemd?

I dunno how starting it at login is supposed to work.

client.conf:

autospawn = no

Ok this makes absolutely no sense at all. The problem went away when I
took ethernet device configuration away from systemd by masking off
all the networking stuff and sticking ifup -a & into /sbin/init. This
does make system boot a _lot_ faster.

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

[nurupo]

Since the VAAPI patch is originally taken from Arch Linux, it might be
worth while to check if they had any issues with it on Chromium 79.
Looking at the comments and changes in
https://aur.archlinux.org/packages/chromium-vaapi it looks like they
did, and they have fixed those issues by updating the patches and
requiring a specially patched libva-vdpau-driver for Nvidia GPUs.

Bug#926216: debootstrap: Add dpkgopt

[Josh Triplett]

On Tue, 2 Apr 2019 12:52:25 +0200 Cyril Brulebois  wrote:
> Hideki Yamane  (2019-04-02):
> > package: debootstrap
> > severity: wishlist
> > 
> >  mmdebstrap has aptopt and dpkgopt option to manage apt and dpkg via
> >  passing some options to it, put conf file to 
> > /etc/apt/apt.conf.d/99mmdebstrap
> >  and /etc/dpkg/dpkg.cfg.d/99mmdebstrap. I think it's worth to add such
> >  option to debootstrap, especially dpkgopt to reduce image size via
> >  "--dpkgopt='path-exclude=/usr/share/man/*' \
> >   --dpkgopt='path-exclude=/usr/share/locale/*' \
> >   --dpkgopt='path-exclude=/usr/share/doc/*' \" for minimize it.
> 
> Looks like a job for localepurge, rather than for debootstrap…

The dpkg --path-exclude options completely supersede localepurge. They
avoid unpacking the files in the first place, rather than extracting
them and then deleting them.

Please consider adding support for this.

Bug#948111: apt: document “requested hashsum is not available” and others

[Thorsten Glaser]

Package: apt
Version: 1.8.4
Severity: important

I’ve just run into this:

tglase@tglase-nb:/tmp $ apt-get source prevent-ruby
Reading package lists... Done
Picking 'mirabilos-support' as source package instead of 'prevent-ruby'
Skipping download of file 'mirabilos-support_61.tar.gz' as requested hashsum is 
not available for authentication
Need to get 772 B of source archives.
Get:1 http://www.mirbsd.org/~tg/Debs sid/wtf mirabilos-support 61 (dsc) [772 B]
Fetched 772 B in 0s (3400 B/s)

I need the source package. Sure, I can get it some other way, but this
is rather unfriendly, especially as neither apt.conf(5), apt-get(8),
apt-secure(8), apt-transport-http(8) and apt(8) document how to override
this setting for this one invocation.

(The repository has all hashes, but the .dsc doesn’t, as it’s generated
on sarge and then symlinked into all later distributions.)

The documentation situation of several things in APT is absolutely
underwhelming already anyway, see for example #850839 (different
problem but also qualifies) and especially the catastrophic situa‐
tion around #929248/#879786/#931566. It would behoove to document
ALL command line options, and thus, all possible values for -o as
well.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.3\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "co

Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Will Dyson]

I just ran into this issue.

I took a packet capture of the DHCP conversation to debug it, and found
that the DHCP server was responding with a DHCP NAK packet with  "address
in use" as the message. And indeed, my system is sending the DHCP REQUEST
with a request for a specific address (which is already in use).

Rather than trying again without requesting the previous address, the
internal DHCP client seems to just give up and no IPv4 address is assigned.
I do have an IPv6 address, so NetworkManager considers the connection UP,
not sure what happens if no global IPv6 address can be assigned.

I can force this issue to happen by locating the internal client lease file
at /var/lib/NetworkManager/internal-$GUID-$IFACE.lease and setting the
ADDRESS to something my DHCP server will NAK. Removing the file (or setting
the address to one not already in use) fixes it.

-- 
Will Dyson

Bug#947630: lintian still gives E: statically-linked-binary for golang project's binary

[Felix Lechner]

Hi Tong,

On Fri, Jan 3, 2020 at 5:16 PM Tong Sun
 wrote:
>
> - if only building binary, then the error will show.

This is a legitimate bug. Thank you for reporting it. The bug will be
closed when the issue is fixed.

Thank you for helping to make Lintian better.

Kind regards
Felix Lechner

Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64

[Ximin Luo]

Source: z3
Version: 4.8.7-2
Severity: important
Tags: patch

Dear Maintainer,

Please apply the attached patch to fix the FTBFS on riscv64.

Since this is a dependency of libllvm9, we need this in order to port rustc to 
riscv64.

Please see also the attached patch to support cross-compiling which I needed in
order to test that the first patch works. You can repeat the build yourself 
with an
sbuild invocation like:

/usr/bin/sbuild --no-arch-all \
  --add-depends=libstdc++6:riscv64 \
  --add-depends=libc6:riscv64 \
  --host=riscv64 \
  --extra-repository="deb http://ftp.ports.debian.org/debian-ports/ sid main" \
  ./z3_4.8.7-2.1.dsc

X

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 83ce6c6b26e8686b9d4786e82a5b82eabec23dec Mon Sep 17 00:00:00 2001
From: Ximin Luo 
Date: Sat, 4 Jan 2020 00:32:15 +
Subject: [PATCH 1/3] Link to -latomic on riscv64, fixes FTBFS

---
 debian/control | 7 ---
 debian/rules   | 6 ++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index c7e4636..5a86bef 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,10 @@ Uploaders: Fabian Wolff ,
Michael Tautschnig 
 Build-Depends: debhelper-compat (= 12),
dh-python, python3,
-   javahelper [!hppa !hurd-i386 !m68k !sh4],
-   default-jdk [!hppa !hurd-i386 !m68k !sh4],
-   ocaml-nox, dh-ocaml, ocaml-findlib, libzarith-ocaml-dev
+   javahelper [!hppa !hurd-i386 !m68k !sh4 !riscv64],
+   default-jdk [!hppa !hurd-i386 !m68k !sh4 !riscv64],
+   ocaml-nox, dh-ocaml, ocaml-findlib, libzarith-ocaml-dev,
+   libatomic1 [riscv64],
 Standards-Version: 4.4.1
 Homepage: https://github.com/Z3Prover/z3
 Vcs-Git: https://salsa.debian.org/pkg-llvm-team/z3.git
diff --git a/debian/rules b/debian/rules
index 31167b0..ae26173 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,8 @@
 # Uncomment this to turn on verbose mode.
 # export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CXXFLAGS_MAINT_APPEND = -fPIC
 
@@ -29,6 +31,10 @@ override_dh_auto_configure:
python3 scripts/mk_make.py --python 
--pypkgdir=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages --ml 
--prefix=$(CURDIR)/debian/tmp/usr; \
fi
sed -i 's/^SLINK_FLAGS=/SLINK_FLAGS=$$(LDFLAGS) -fPIC /' build/config.mk
+ifneq (,$(filter $(DEB_HOST_ARCH), riscv64))
+   sed -i 's/^LINK_EXTRA_FLAGS=/LINK_EXTRA_FLAGS=-latomic /' 
build/config.mk
+   sed -i 's/^SLINK_EXTRA_FLAGS=/SLINK_EXTRA_FLAGS=-latomic /' 
build/config.mk
+endif
echo 'libz3$$(SO_EXT): SLINK_FLAGS += -Wl,-soname,libz3.so.4' >> 
build/Makefile
printf '%%:\n\t$$(MAKE) -C build $$@\n' > Makefile
printf '\nall:\n\t$$(MAKE) -C build $$@\n' >> Makefile
-- 
2.24.1

>From 445f59f3818d68d7995bb387a67a2920f01e5787 Mon Sep 17 00:00:00 2001
From: Ximin Luo 
Date: Sat, 4 Jan 2020 01:07:50 +
Subject: [PATCH 2/3] support cross-compiling

---
 debian/control |  5 +++--
 debian/rules   | 50 +-
 2 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/debian/control b/debian/control
index 5a86bef..7e69bb9 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,10 @@ Maintainer: LLVM Packaging Team 

 Uploaders: Fabian Wolff ,
Michael Tautschnig 
 Build-Depends: debhelper-compat (= 12),
-   dh-python, python3,
+   dh-python, python3:any,
javahelper [!hppa !hurd-i386 !m68k !sh4 !riscv64],
default-jdk [!hppa !hurd-i386 !m68k !sh4 !riscv64],
-   ocaml-nox, dh-ocaml, ocaml-findlib, libzarith-ocaml-dev,
+   ocaml-nox , dh-ocaml , ocaml-findlib , 
libzarith-ocaml-dev ,
libatomic1 [riscv64],
 Standards-Version: 4.4.1
 Homepage: https://github.com/Z3Prover/z3
@@ -79,6 +79,7 @@ Package: libz3-ocaml-dev
 Section: ocaml
 Architecture: any
 Depends: libz3-dev (= ${binary:Version}), ${misc:Depends}, ${ocaml:Depends}, 
${shlibs:Depends}
+Build-Profiles: 
 Recommends: ocaml-findlib
 Description: theorem prover from Microsoft Research - OCaml bindings
  Z3 is a state-of-the art theorem prover from Microsoft Research. See the z3
diff --git a/debian/rules b/debian/rules
index ae26173..6dfb755 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,26 +10,38 @@ export DEB_CXXFLAGS_MAINT_APPEND = -fPIC
 
 DEB_HO

Bug#948110: Please provide options to exclude files from installed image

[Josh Triplett]

Package: debootstrap
Version: 1.0.116
Severity: wishlist

Please consider providing options to exclude files from the installed
image using --path-exclude (and keep them that way via dpkg
configuration in the bootstrapped system). That would make it easier to
install a small system image that (for instance) excludes documentation
or locales.

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

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

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.17-3

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#914569: beets: zsh completion broken

[Clint Adams]

On Wed, Dec 25, 2019 at 08:57:03AM +0200, Stefano Rivera wrote:
> Control: tag -1 +moreinfo +unreproducible
> 
> Hi Clint (2018.11.25_05:15:04_+0200)
> > % beet import ../
> > _beet:zregexparse:4: invalid regex : )
> > (with zsh 5.6.2-3)
> 
> Works for me, with zsh 5.7.1-1+b1.
> 
> Something changed in zsh? Or something unusual about the directory you
> were in?

Could you perform a successful beet completion and then paste the output of
`which _beet`. so I can contrast the zregexparse line against

zregexparse -c _ra_p1 _ra_p2 "$_ra_line" $'/[^\0]##\0/' $'(' $'(' 
$'/-c\0/' $'/[^\0]##\0/' $':_ra_comp $\'file:file:_files\'' $'|' $'/-v\0/' $'|' 
$'/-l\0/' $'/[^\0]##\0/' $':_ra_comp $\'file:file:_files\'' $'|' $'/-h\0/' $'|' 
$'/-d\0/' $'/[^\0]##\0/' $':_ra_comp $\'dir:directory:_dirs\'' $'|' $'/[]/' 
$':_ra_comp $\'options:global options:(( -c:path to 
configuration file -v:print debugging information 
-l:library database file to use -h:show this 
help message and exit -d:destination music directory 
))\'' $')' $'#' $')' $')'

Bug#947630: lintian still gives E: statically-linked-binary for golang project's binary

[Tong Sun]

On Fri, Jan 3, 2020 at 3:24 AM Felix Lechner  wrote:
>
> Hi Tong,
>
> On Thu, Jan 2, 2020 at 8:56 PM Tong Sun
>  wrote:
> >
> > Hold on, I just upload the source file, you meant the binary file?
> > Can I do that?
>
> If you upload easygen_4.1.0-1_amd64.changes to mentors, I can run my
> development version against it.
>
> Dput/Dupload will automatically include any sources or installation
> packages (deb) that might have triggered the tag. According to this
> commit, both debs and source must be present for the tag to trigger:
>
> 
> https://salsa.debian.org/lintian/lintian/commit/e59e44ec0d648b66b30ab52c08f3def9224c7373

Hi Felix,

I didn't get what you were talking about the first time I read above,
and only after I asked almost the same question again, did I fully
understand it, when you replied:

> You can build a full package with 'debuild -sa'.

Sorry about that, I never take such "detour" before as I always build
either source or the binary package. Hope that I hadn't wore your
patient off.

Now I don't need to upload the easygen's _amd64.changes file anymore,
because when I run `lintian -EvIL +pedantic` against it myself, I
don't see the `statically-linked-binary` error any more myself either.

So here is the summary of the situation,

- as you put before, both debs and source must be present for the tag
to trigger. I.e., when only building the source AND the binary file,
the `statically-linked-binary` error will not show.
- if only building binary, then the error will show.

I.e., feel free to close it, if you think it is no longer a problem.
i.e., we can overlook the building binary case.

Thanks

Bug#948108: unrar corrupts filenames given as arguments

[Marc Lehmann]

Package: unrar
Version: 1:5.6.6-2
Severity: normal

Dear Maintainer,

when passing certain (archive) filenames to unrar, unrar will corrupt them
and not be able to open them. The peculiar way this corruption occurs
hints at possible security issues.

Example:

   strace -feexecve,stat perl -e 'system "unrar", "x", "x\x92.rar"'

Outputs, among other things:

   [pid  9326] execve("/bin/unrar", ["unrar", "x", "x\222.rar"], 0x557679f0 
/* 112 vars */) = 0
   [pid  9326] stat("x\222.ra", 0x7ffef1d0) = -1 ENOENT (No such file or 
directory)
   Cannot open x�.ra

(the later filename is written like this):

   [pid  9390] write(2, "x", 1x)= 1
   [pid  9390] write(2, "\357\277\276", 3�) = 3
   [pid  9390] write(2, "\356\202\222", 3) = 3
   [pid  9390] write(2, ".", 1.)= 1
   [pid  9390] write(2, "r", 1r)= 1
   [pid  9390] write(2, "a", 1a)= 1
   [pid  9390] write(2, "\nN", 2

So somehow the \x92 character gets replaced, but also the trailing "r" (from 
rar) is removed.

This happened in a utf-8 based locale (en_DK.UTF-8), which is probably
related.

Obviously, unrar should not mangle filenames, as filenames are
octet-strings, not locale-encoded.

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

Kernel: Linux 5.4.7-050407-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 unrar depends on:
ii  libc6   2.28-10
ii  libgcc1 1:9.2.1-15
ii  libstdc++6  8.3.0-6

unrar recommends no packages.

unrar suggests no packages.

-- no debconf information

Bug#948107: linux-image-4.19.0-6-amd64: unable to make backup link of './boot/System.map-4.19.0-6-amd64' before installing new version: Operation not permitted

[Andy Bennett]

Package: src:linux
Version: 4.19.67-2+deb10u1
Severity: important

Dear Maintainer,

  * What led up to the situation?

I upgraded from Jessie to Stretch and then from Stretch to Buster. The
kernel upgrades worked fine. I then added the security and updates repos
to apt and tried to upgrade the kernel. That kernel upgraded failed as
below.

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

-
$ sudo apt-get update
Hit:1 http://deb.debian.org/debian buster InRelease
Hit:2 http://deb.debian.org/debian buster-updates InRelease 
   
Hit:3 http://deb.debian.org/debian buster-backports InRelease   
   
Get:4 http://debug.mirrors.debian.org/debian-debug buster-debug InRelease 
[26.8 kB] 
Hit:5 http://security.debian.org buster/updates InRelease   
   
Get:6 http://debug.mirrors.debian.org/debian-debug buster-backports-debug 
InRelease [43.0 kB]
Get:7 http://debug.mirrors.debian.org/debian-debug buster-debug/main amd64 
Packages [3,112 kB]
Get:8 http://debug.mirrors.debian.org/debian-debug buster-debug/main i386 
Packages [3,074 kB]
Get:9 http://debug.mirrors.debian.org/debian-debug buster-debug/main 
Translation-en [570 B]
Get:10 http://debug.mirrors.debian.org/debian-debug buster-debug/contrib 
amd64 Packages [19.9 kB]
Get:11 http://debug.mirrors.debian.org/debian-debug buster-debug/contrib 
i386 Packages [15.4 kB]
Get:12 http://debug.mirrors.debian.org/debian-debug buster-debug/non-free 
amd64 Packages [22.3 kB]
Get:13 http://debug.mirrors.debian.org/debian-debug buster-debug/non-free 
i386 Packages [15.8 kB]
Get:14 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/main i386 Packages [92.2 kB]
Get:15 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/main amd64 Packages [92.0 kB]
Get:16 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/contrib amd64 Packages [2,212 B]
Get:17 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/contrib i386 Packages [2,232 B]
Get:18 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/non-free i386 Packages [604 B]
Get:19 http://debug.mirrors.debian.org/debian-debug 
buster-backports-debug/non-free amd64 Packages [604 B]
Fetched 6,519 kB in 2s (3,154 kB/s) 
Reading package lists... Done


$ sudo apt-get upgrade
[sudo] password for andyjpb: 
Sorry, try again.
[sudo] password for andyjpb: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done

Calculating upgrade... Done
The following packages will be upgraded:
 linux-image-4.19.0-6-amd64
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 48.0 MB of archives.
After this operation, 43.0 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://security.debian.org buster/updates/main amd64 
linux-image-4.19.0-6-amd64 amd64 4.19.67-2+deb10u2 [48.0 MB]
Fetched 48.0 MB in 6s (8,235 kB/s) 
Reading changelogs... Done

(Reading database ... 274923 files and directories currently installed.)
Preparing to unpack 
.../linux-image-4.19.0-6-amd64_4.19.67-2+deb10u2_amd64.deb ...
Unpacking linux-image-4.19.0-6-amd64 (4.19.67-2+deb10u2) over 
(4.19.67-2+deb10u1) ...
dpkg: error processing archive 
/var/cache/apt/archives/linux-image-4.19.0-6-amd64_4.19.67-2+deb10u2_amd64.deb 
(--unpack):
unable to make backup link of './boot/System.map-4.19.0-6-amd64' before 
installing new version: Operation not permitted

dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-4.19.0-6-amd64_4.19.67-2+deb10u2_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
-


  * What was the outcome of this action?

The install of the kernel package failed. I had this problem when
installing the kernel from the security and update repos after upgrading
from Jessie to Stretch and  when installing the kernel from the security
and update repos after upgrading from Stretch to Buster. However, I
didn't have this problem when upgrading kernels in Jessie or when
dist-upgrading between Debian releases.

  * What outcome did you expect instead?

For the kernel to be installed. /boot has been on a FAT partition for
the whole lifetime of this machine and has never presented a problem in
the past or during upgrades between Debian releases.


I have successfully installed the linux-image-5.3.0-0.bpo.2-amd64 kernel
package from buster-backports but apt-get upgrade still wants to upgrade
the linux-image-4.19.0-6-amd64 as it is still installed.



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20HRCTO1WW
product_version: ThinkPad X1 Carbon 5th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1MET31W (1.16 )
board_vendo

Bug#930764: 3.0.8-6+deb10u3 on Buster

[Andy Bennett]

Hi,

I am seeing this with 3.0.8-6+deb10u3. Will an update eventually trickle 
through?



Thanks!

Best wishes,
@ndy

--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF

Bug#878777: noweb: diff for NMU version 2.11b-11.1

[Nicolas Boulenguez]

Dear maintainer,

I've prepared an NMU for noweb (versioned as 2.11b-11.1).
The changes are attached as a series of patches based on 2.11b-11.
Only one is specific to this bug, and some others are quite intrusive,
so I would like your opinion about them before uploading anything.

Regards.


noweb.tar.gz
Description: application/gzip

Bug#947928: rdesktop crash with segmentation error

[Bernhard Übelacker]

Hello Antonio,
could you please add to which windows version you
were trying to connect.

Maybe you could also try to start it that way:
catchsegv rdesktop ...

Even better would be if you could install debug symbols like
described in [1] and systemd-coredump.
Then after an application crashed you should receive a
backtrace at the end of this command:
journalctl --no-pager

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Kind regards,
Bernhard

Bug#948026: GIMP 2.10.8-2 still fails to open EPS files;

[Bernhard Übelacker]

Short addition:
this upstream issue seems to match better:
   https://gitlab.gnome.org/GNOME/gimp/issues/3630

Which got fixed in branches master and gimp-2-10
by these upstream commits:
   
https://gitlab.gnome.org/GNOME/gimp/commit/bbcc7ca5f55e62404bd69bf2e5b198039ad3f568
   
https://gitlab.gnome.org/GNOME/gimp/commit/2f2067a5aacae176f5aaf828e15bd4463879062a

Kind regards,
Bernhard

Bug#918506: Installation fails with "This account is currently not available." when debian-spamd has no login shell

[Noah Meyerhans]

On Sat, Jan 05, 2019 at 07:58:45AM +0100, debian-bugreports...@sethdepot.org 
wrote:
> 
> Instead I worked around this issue with the following change in the
> postinst script /var/lib/dpkg/info/spamassassin.postinst
>   Line 38
>   su - $OWNER -c "sa-update \
>  --gpghomedir /var/lib/spamassassin/sa-update-keys \
>  --import /usr/share/spamassassin/GPG.KEY"
> Replace: "su - $OWNER -c " --> "sudo -u $OWNER sh -c"
> 
> sudo does work with disabled accounts, su doesn't

Probably better to use start-stop-daemon, as the daily cron job does,
rather than take the extra dependency on sudo.  But yes, this seems like
a reasonable fix.

I assume you haven't noticed any other issues with spamassassin when
running with its shell set to /usr/sbin/nologin?

noah

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

On 02.01.20 16:39, Daniel Reichelt wrote:
> With 7e63df224aa45a8b541cd63a870594454aba7526 applied, this happens 9
> out of 10 times.

Actually, that's crap.

I noticed a ton of running x11vnc processes and re-tried ~debu10 with
7e63df224aa45a8b541cd63a870594454aba7526 applied.

Result: just the error message about "unknown encoding", so nothing
notably different than w/o said additional patch. (Although the
different behaviour when other x11vnc processes are lingering
is…"interesting"…it's not pertinent to the regression itself.)



signature.asc
Description: OpenPGP digital signature

Bug#948026: GIMP 2.10.8-2 still fails to open EPS files;

[Bernhard Übelacker]

Control: tags -1 + patch upstream


Dear Maintainer,
I tried to have a look at this crash and I guess I found the reason.

The plugin calls into libgs.so.9 by gsapi_new_instance/psapi_new_instance.
Unfortunately the instance pointer is given to that function
uninitialized. But documentation states that it has to be NULL [1].

Building a gimp package with attached patch makes the import
not crash any longer.

Upstream seems to track this issue in [2].

Kind regards,
Bernhard


[1] https://www.ghostscript.com/doc/current/API.htm#new_instance
[2] https://gitlab.gnome.org/GNOME/gimp/issues/3636



Thread 1 "file-ps" received signal SIGSEGV, Segmentation fault.
gs_lib_ctx_init (ctx=ctx@entry=0x7fea95643559 <__libc_read+89>, 
mem=mem@entry=0x559c0c831c00) at ./base/gslibctx.c:175
175 gx_monitor_enter((gx_monitor_t *)(pio->core->monitor));
(gdb) bt
#0  0x7fea95999ab8 in gs_lib_ctx_init (ctx=ctx@entry=0x7fea95643559 
<__libc_read+89>, mem=mem@entry=0x559c0c831c00) at ./base/gslibctx.c:175
#1  0x7fea959956b1 in gs_malloc_init_with_context (ctx=0x7fea95643559 
<__libc_read+89>) at ./base/gsmalloc.c:597
#2  0x7fea95a45622 in psapi_new_instance (pinstance=0x7ffd709dfe88, 
caller_handle=0x0) at ./psi/psapi.c:92
#3  0x559c0c2774ca in ps_open (filename=0x559c0c61b8e0 
"/usr/share/doc/hp2xx/hp-tests/pages.2.eps", llx=, 
lly=, urx=, ury=, 
is_epsf=0x7ffd709e0304, loadopt=0x559c0c281080 ) at file-ps.c:1760
#4  0x559c0c278074 in load_image (filename=0x559c0c61b8e0 
"/usr/share/doc/hp2xx/hp-tests/pages.2.eps", error=0x7ffd709e03f8) at 
file-ps.c:1077
#5  0x559c0c27958c in run (name=, nparams=, 
param=0x559c0c61bf70, nreturn_vals=0x7ffd709e0484, return_vals=) 
at file-ps.c:847
#6  0x7fea96f3560c in gimp_proc_run (proc_run=) at 
gimp.c:2439
#7  0x7fea96f3560c in gimp_loop () at gimp.c:2264
#8  0x7fea96f3560c in gimp_main (info=, argc=, argv=) at gimp.c:671
#9  0x7fea9549309b in __libc_start_main (main=0x559c0c274b80 , 
argc=6, argv=0x7ffd709e0688, init=, fini=, 
rtld_fini=, stack_end=0x7ffd709e0678) at ../csu/libc-start.c:308
#10 0x559c0c274bca in _start () at file-ps.c:589
Description: Avoid crash in gsapi_new_instance by initializing instance pointer
 Ghostscript documentation requires the handle pointer to be initialized
 which is given to gsapi_new_instance.
 https://www.ghostscript.com/doc/current/API.htm#new_instance

Author: Bernhard Übelacker 
Bug: https://gitlab.gnome.org/GNOME/gimp/issues/3636
Bug-Debian: https://bugs.debian.org/948026
Forwarded: no
Last-Update: 2020-01-03

--- gimp-2.10.8.orig/plug-ins/common/file-ps.c
+++ gimp-2.10.8/plug-ins/common/file-ps.c
@@ -1757,6 +1757,7 @@ ps_open (const gchar  *filename,
   }
 #endif
 
+  instance = NULL;
   code = gsapi_new_instance (&instance, NULL);
   if (code == 0) {
 code = gsapi_init_with_args (instance, cmdA->len - 1, pcmdA);

# Buster/stable amd64 qemu VM 2020-01-03


apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg sddm openbox xterm psmisc mc strace 
gdb gdbserver gimp hp2xx gimp-dbgsym libgimp2.0-dbgsym ghostscript-dbg
apt build-dep gimp



mkdir /home/benutzer/source/gimp/orig -p
cd/home/benutzer/source/gimp/orig
apt source gimp
cd

mkdir /home/benutzer/source/ghostscript/orig -p
cd/home/benutzer/source/ghostscript/orig
apt source ghostscript
cd




export DISPLAY=:0
export LANG=C


# ulimit -c unlimited
# unfortunately somehow disables gimp the core dump production ...


# mv /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps /file-ps.real
# (echo "#\!/bin/sh"; echo "exec /usr/bin/gdbserver localhost:5 
/file-ps.real") > /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps
# chmod +x /usr/lib/gimp/2.0/plug-ins/file-ps/file-ps
# gimp /usr/share/doc/hp2xx/hp-tests/pages.2.eps
# gdb -q
# target remote localhost:5
# does not work too


# gdb -q --args gimp /usr/share/doc/hp2xx/hp-tests/pages.2.eps
# set width 0
# set pagination off
# set follow-fork-mode child
# run
# not working too



benutzer@debian:~$ gimp --stack-trace-mode=always 
/usr/share/doc/hp2xx/hp-tests/pages.2.eps

(gimp:10927): Gtk-WARNING **: 23:12:08.841: Unable to locate theme engine in 
module_path: "pixmap",
...
gimp_device_info_set_device: trying to set GdkDevice 'VirtualPS/2 VMware 
VMMouse' on GimpDeviceInfo which already has a device

(file-ps:10952): Gtk-WARNING **: 23:12:10.118: Unable to locate theme engine in 
module_path: "pixmap",
...
/usr/lib/gimp/2.0/plug-ins/file-ps/file-ps: fatal error: Segmentation fault
26  ../sysdeps/unix/sysv/linux/read.c: No such file or directory.

# Stack traces obtained from PID 10952 - Thread 10952 #

[New LWP 10953]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffe3ce3cbd0, fd=9) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame 
* 1Thread 0x7f2d19c0b0c0 (LWP 10952) "file-ps" __libc_read (nbytes=256

Bug#948106: Please switch to enchant-2 instead of enchant

[Laurent Bigonville]

Source: webkit2gtk
Version: 2.26.2-1
Severity: wishlist
Control: block 947979 by -1

Hi,

enchant-2 is now in debian unstable, please switch from enchant to
enchant-2 (libenchant-dev -> libenchant-2-dev)

enchant is old and no longer maintained upstream.

Kind regrads,

Laurent Bigonville

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#947979: enchant-2: Consider requesting a transition for enchant1->2

[Laurent Bigonville]

On Thu, 02 Jan 2020 15:10:24 -0800 Boyuan Yang  wrote:

> Since enchant 1.x is not really maintained by upstream, it might be
> reasonable to request a (manual) transition from enchant1 to enchant2
> after enchant-2 enters Testing.
>
> This issue might not be suitable to be submitted as a bug against
> enchant-2 package; please feel free to properly reassign it. At least
> this will make the maintainers for both enchant and enchant-2 to be
> aware of it.

FTR, the NEWS entry for version 2 was stating:

2.0.0 (August 4, 2017)
--

The major version number has been incremented owing to API/ABI changes, but
in practice upgrading from 1.6.x should be easy.

Previously-deprecated APIs have been removed.

The little-used enchant_broker_get/set_param calls have been removed.

Some trivial API changes have been made to fix otherwise-unavoidable
compilation warnings both in libenchant and in application code. This is
strictly an ABI change (although the ABI may not actually have changed,
depending on the platform).

The provider API has been changed slightly: enchant_get_user_language is now
a documented public API (before it was marked private, but it has in fact
been exported for some years). enchant_get_user_config_dirs is now
enchant_get_user_config_dir, and returns only a single directory.

The plethora of configuration options previously available has been
rationalised and documented. In particular, support for relocation (so that
Enchant, or an application of which it is part, can be installed anywhere in
a filing system) has been rewritten and documented (see INSTALL).

The Myspell backend has been renamed to Hunspell to match the upstream
project. Users with their own enchant.ordering files will need to change
“myspell” to “hunspell”.

I'll request to add a tracker for the transition, note that several
packages (gnome-builder, webkit2gtk, evolution, geary,...) already
support enchant-2, the only change is in the build-dependencies

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Ben Caradoc-Davies]

On Fri, 03 Jan 2020 16:23:14 -0500 Calum McConnell 
 wrote:

I was unfortunate enough to have the oppoiste order of installs: the
four packages, and then URE.  That meant URE's install failed, and I
was left with apt complaining about a broken system.  To get out of it,
I used dpkg -r to get rid of the offending four packages, and then
installed ure.  Of course, then apt began moaning that libreoffice-
java-common was broken, but I removed that and the packages I had
depending on it.
Obviously I would like them back, but libreoffice is working just fine
without them.  
Just wanted to put my workarround up here in case anybody else had the

same bad luck as me.


Thanks very much, Calum. I was able to repair my system with:

dpkg -r libjuh-java libjurt-java libridl-java libunoloader-java

followed by:

apt --fix-broken install

LibreOffice then seems to work normally. I did not have 
libreoffice-java-common installed. I note that the four removed packages 
are recommends for ure; these were not installed by "apt --fix-broken 
install". Plain installation would likely attempt to install the 
conflicting recommended packages for most users (and fail).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#948105: Remove build dep on libuhttpmock-dev

[Moritz Muehlenhoff]

Source: libgdata
Severity: important

In #917104 uhttpmock has been filed for removal, but libgdata still
uses it.

Cheers,
Moritz

Bug#936753: ispell-lt: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

Matthias Klose wrote:
> Package: src:ispell-lt
> Version: 1.2.1-8
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

I prepared an update, which is available at https://people.debian.org/~jmm/
which partly switches to a tool provided by myspell-tools.

Given I don't speak Lithuanian, I'm looking for some testing by a
native speaker before upload.

I'm adding Martynas and Andrius as the two people listed as translation
coordinators for the website to CC, could anyone of you give this a
quick testing, please?

Cheers,
Moritz

Bug#947984: libvirt-daemon-driver-lxc: internal error: Unable to find 'devices' cgroups controller mount in cgroup2 / unified hierarchy

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream upstream

I verified that libvirt 5.10 fixes this problem as

[root@localhost ~]# lxc-create -n fedora31test -t download -- -d
fedora -r 31 -a amd64

[root@localhost ~]# virt-install --memory 2048  --connect lxc:/
--os-variant fedora31 --filesystem /var/lib/lxc/fedora31test/rootfs,/
--network none   --transient --import --name fedora31test

worked just fine.

Bug#947936: chrony: Does (still) not start properly on boot on buster

[Vincent Blut]

Hi Santiago,

On 2020-01-02T13:38+0100, Santiago Vila wrote:

Package: chrony
Version: 3.4-4
Severity: important

Dear maintainer:

Apparently, installing chrony does not ensure at all that it will work.

Google has moved from ntp in Debian 9 to chrony in Debian 10 for their
default Debian GCE images, and I discovered this on a lot of GCE
instances having a clock several minutes off.

The problem I found is very similar to the one described here:

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


Indeed, it sounds pretty similar.


I believe the best summary of the problem was made by Michael Biebl
here:

https://github.com/systemd/systemd/issues/7104#issuecomment-471329392

Quoting Michael:

As it stands, the current practice of having systemd-timesyncd.service
enabled by default (in Debian) and alternative implementations like
chrony or ntpd declare Conflicts=systemd-timesyncd.service in their
service file does not work reliably.



AFAIK, this has been fixed on the systemd side in version 241-3 by
dropping the "Conflicts" systemd had on chrony or ntpd.


Exact, the Debian systemd maintainers reintroduced the following drop-in 
file in version 241-3:


$ cat 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

It prevents systemd-timesyncd from starting if one of the above
executables is present on the system.


Unfortunately, AFAIK, conflicts are bi-directional, so apparently the
problem will persist in buster as far as chrony still has conflicts
in the systemd unit file.


What do you mean by “conflicts are bi-directional”?

Also, conflicting with systemd-timesyncd doesn’t seem to cause any issue 
on most systems (well, I hope ;-), so we should be cautious about 
incriminating “Conflicts= systemd-timesyncd.service” use as the root 
cause.


Would you please tell me how things go when removing 
“ConditionFileIsExecutable=!/usr/sbin/chronyd” from the 
systemd-timesyncd service unit? Does that make chrony happy?



Thanks.


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#948104: buster-pu: package python3.7/3.7.3-2+deb10u1

[Moritz Muehlenhoff]

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

Similar to the python2.7 update which landed in Buster 10.2. Debdiff
below. All these are fixed in bullseye/sid (but none had a dedicated
bug)

Cheers,
Moritz

diff -Nru python3.7-3.7.3/debian/changelog python3.7-3.7.3/debian/changelog
--- python3.7-3.7.3/debian/changelog2019-04-03 07:39:12.0 +0200
+++ python3.7-3.7.3/debian/changelog2019-12-20 18:01:46.0 +0100
@@ -1,3 +1,14 @@
+python3.7 (3.7.3-2+deb10u1) buster; urgency=medium
+
+  * CVE-2019-9740
+  * CVE-2019-9947
+  * CVE-2019-9948
+  * CVE-2019-10160
+  * CVE-2019-16056
+  * CVE-2019-16935
+
+ -- Moritz Mühlenhoff   Fri, 20 Dec 2019 19:57:59 +0100
+
 python3.7 (3.7.3-2) unstable; urgency=medium
 
   * d/p/arm-alignment.diff: Don't allow unaligned memory accesses in the
diff -Nru python3.7-3.7.3/debian/patches/CVE-2019-10160-1.diff 
python3.7-3.7.3/debian/patches/CVE-2019-10160-1.diff
--- python3.7-3.7.3/debian/patches/CVE-2019-10160-1.diff1970-01-01 
01:00:00.0 +0100
+++ python3.7-3.7.3/debian/patches/CVE-2019-10160-1.diff2019-12-20 
17:57:53.0 +0100
@@ -0,0 +1,59 @@
+From 4d723e76e1ad17e9e7d5e828e59bb47e76f2174b Mon Sep 17 00:00:00 2001
+From: "Miss Islington (bot)"
+ <31488909+miss-isling...@users.noreply.github.com>
+Date: Tue, 30 Apr 2019 05:21:02 -0700
+Subject: [PATCH] bpo-36742: Fixes handling of pre-normalization characters in
+ urlsplit() (GH-13017)
+
+(cherry picked from commit d537ab0ff9767ef024f26246899728f0116b1ec3)
+
+Co-authored-by: Steve Dower 
+---
+ Lib/test/test_urlparse.py |  6 ++
+ Lib/urllib/parse.py   | 11 +++
+ .../Security/2019-04-29-15-34-59.bpo-36742.QCUY0i.rst |  1 +
+ 3 files changed, 14 insertions(+), 4 deletions(-)
+ create mode 100644 
Misc/NEWS.d/next/Security/2019-04-29-15-34-59.bpo-36742.QCUY0i.rst
+
+diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
+index e6638aee2244..c26235449461 100644
+--- a/Lib/test/test_urlparse.py
 b/Lib/test/test_urlparse.py
+@@ -1001,6 +1001,12 @@ def test_urlsplit_normalization(self):
+ self.assertIn('\u2100', denorm_chars)
+ self.assertIn('\uFF03', denorm_chars)
+ 
++# bpo-36742: Verify port separators are ignored when they
++# existed prior to decomposition
++urllib.parse.urlsplit('http://\u30d5\u309a:80')
++with self.assertRaises(ValueError):
++urllib.parse.urlsplit('http://\u30d5\u309a\ufe1380')
++
+ for scheme in ["http", "https", "ftp"]:
+ for c in denorm_chars:
+ url = "{}://netloc{}false.netloc/path".format(scheme, c)
+diff --git a/Lib/urllib/parse.py b/Lib/urllib/parse.py
+index 1eec26e0f1f3..f5b3487ea9d6 100644
+--- a/Lib/urllib/parse.py
 b/Lib/urllib/parse.py
+@@ -397,13 +397,16 @@ def _checknetloc(netloc):
+ # looking for characters like \u2100 that expand to 'a/c'
+ # IDNA uses NFKC equivalence, so normalize for this check
+ import unicodedata
+-netloc2 = unicodedata.normalize('NFKC', netloc)
+-if netloc == netloc2:
++n = netloc.rpartition('@')[2] # ignore anything to the left of '@'
++n = n.replace(':', '')# ignore characters already included
++n = n.replace('#', '')# but not the surrounding text
++n = n.replace('?', '')
++netloc2 = unicodedata.normalize('NFKC', n)
++if n == netloc2:
+ return
+-_, _, netloc = netloc.rpartition('@') # anything to the left of '@' is 
okay
+ for c in '/?#@:':
+ if c in netloc2:
+-raise ValueError("netloc '" + netloc2 + "' contains invalid " +
++raise ValueError("netloc '" + netloc + "' contains invalid " +
+  "characters under NFKC normalization")
+ 
+ def urlsplit(url, scheme='', allow_fragments=True):
diff -Nru python3.7-3.7.3/debian/patches/CVE-2019-10160-2.diff 
python3.7-3.7.3/debian/patches/CVE-2019-10160-2.diff
--- python3.7-3.7.3/debian/patches/CVE-2019-10160-2.diff1970-01-01 
01:00:00.0 +0100
+++ python3.7-3.7.3/debian/patches/CVE-2019-10160-2.diff2019-12-20 
17:57:53.0 +0100
@@ -0,0 +1,54 @@
+From 250b62acc59921d399f0db47db3b462cd6037e09 Mon Sep 17 00:00:00 2001
+From: "Miss Islington (bot)"
+ <31488909+miss-isling...@users.noreply.github.com>
+Date: Tue, 4 Jun 2019 09:15:13 -0700
+Subject: [PATCH] bpo-36742: Corrects fix to handle decomposition in usernames
+ (GH-13812)
+
+(cherry picked from commit 8d0ef0b5edeae52960c7ed05ae8a12388324f87e)
+
+Co-authored-by: Steve Dower 
+---
+ Lib/test/test_urlparse.py | 11 ++-
+ Lib/urllib/parse.py   |  6 +++---
+ 2 files changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
+index c26235449461..68f633ca3a7d 100644
+--- a/Lib/test/test_urlparse.py
 b/Lib/test/test_urlparse.py
+@@ -1008,11 +100

Bug#948103: libsixel: Multiple security issues

[Moritz Muehlenhoff]

Source: libsixel
Severity: important
Tags: security

Please see https://github.com/saitoha/libsixel/releases/tag/v1.8.5

Cheers,
Moritz

Bug#948102: libvirt-clients: seems to depend libvirt-daemon-system

[Ryutaroh Matsumoto]

Package: libvirt-clients
Version: 5.6.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

virsh is completely unusable without libvirt-daemon-system as

root@debian:~# virsh uri
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such 
file or directory

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages libvirt-clients depends on:
ii  libapparmor12.13.3-7
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-21
ii  libreadline88.0-3
ii  libselinux1 3.0-1
ii  libvirt05.6.0-3
ii  libxml2 2.9.4+dfsg1-8
ii  sensible-utils  0.0.12+nmu1

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
ii  libvirt-daemon  5.6.0-3

-- no debconf information

Bug#948101: virtinst: seems to depend on libvirt-daemon-system

[Ryutaroh Matsumoto]

Package: virtinst
Version: 1:2.2.1-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Without installing libvirt-daemon-system, virt-installer is completely unusable 
as

root@debian:~# virt-install --install fedora29 --unattended
ERRORFailed to connect socket to '/var/run/libvirt/libvirt-sock': No such 
file or directory

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages virtinst depends on:
ii  e2fsprogs 1.45.4-1
ii  genisoimage   9:1.1.11-3+b2
ii  gir1.2-libosinfo-1.0  1.6.0-1
ii  python3   3.7.5-3
ii  python3-distutils 3.8.0-1
ii  python3-gi3.34.0-3
ii  python3-libvirt   5.6.0-1
ii  python3-libxml2   2.9.4+dfsg1-8
ii  python3-requests  2.22.0-2

Versions of packages virtinst recommends:
ii  qemu-utils   1:4.1-3
ii  virt-viewer  7.0-2

virtinst suggests no packages.

-- no debconf information

Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

[John Scott]

>> If you still need me to test with different desktop environments: which o ne
>> would you suggest? I'd prefer one that is easy to install AND remove after 
>> the test.
> I don't know other wayland-based desktops than gnome, so I leave this
> question to others :)
It's not easy to add or remove because it might pull in a lot of big packages, 
but KDE Plasma has fair support for Wayland provided by by plasma-workspace-
wayland.

You're probably looking for Weston which is much smaller.
You can try it by installing the weston package, going to a TTY 
(e.g. Ctrl+Alt+F3), log in, and type weston-launch. Then you should be able to 
open a terminal emulator and start other applications if you want to.
When you're done you can close Weston with Ctrl+Alt+Backspace and try 
Ctrl+Alt+F1 through F7 until you get back to GNOME/GDM again.


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

Bug#948098: RM: blogilo -- FTBFS, uninstallable, abandoned upstream

[John Scott]

Control: reassign -1 ftp.debian.org

On Friday, January 3, 2020 4:20:00 PM EST you wrote:
> Unstable, or testing? The former is FTP team's balliwick, not Release.
Unstable. Thanks for the quick catch!

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

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Calum McConnell]

I was unfortunate enough to have the oppoiste order of installs: the
four packages, and then URE.  That meant URE's install failed, and I
was left with apt complaining about a broken system.  To get out of it,
I used dpkg -r to get rid of the offending four packages, and then
installed ure.  Of course, then apt began moaning that libreoffice-
java-common was broken, but I removed that and the packages I had
depending on it.

Obviously I would like them back, but libreoffice is working just fine
without them.  

Just wanted to put my workarround up here in case anybody else had the
same bad luck as me.

Bug#946142: [PATCH] log files for visibility by dh_missing (Closes: #946142)

[David Bremner]

Daniel Kahn Gillmor  writes:

> These changes are inspired by the recommendations in "Logging helpers
> and dh_missing" in /usr/share/doc/debhelper/PROGRAMMING.gz, and
> derived from the source of dh_installman and dh_installinfo.
>
> (The weird extraction of the file list from @action is idiosyncratic
> to dh_elpa, afaict)
>

I guess you mean @actions? I had to read this a few times to understand
that you meant something along the lines of "the list of source files is
reverse engineered from the code just below" rather than "Hell is other
people's code". I does seem a bit fragile, but I don't see an obviously
better way to do it. It is a pity log_installed_files can only be called
once.

> Signed-off-by: Daniel Kahn Gillmor 
> --- dh_elpa | 7 +-- 1 file changed, 5 insertions(+), 2
>  deletions(-)
>
> diff --git a/dh_elpa b/dh_elpa index 0d3739d..982ac7b 100755 ---
> a/dh_elpa +++ b/dh_elpa @@ -210,10 +210,11 @@ if ($dh{BYTECOMPILE}) {
> }
>  
>  PACKAGE: -foreach my $package (@{$dh{DOPACKAGES}}) { +foreach my
> $package (getpackages()) {

I guess it should probably be documented that this is a change needed by
dh_missing.

>  
>my $tmp=tmpdir($package);
>my $file=pkgfile($package,"elpa");
> +  my $skip_install = process_pkg($package) ? 0 : 1;

same here.

>  
>my $varname="ELPA_NAME_${package}";
>my $elpapkg = $ENV{$varname} || $ENV{ELPA_NAME};
> @@ -265,7 +266,9 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
>  push @actions, map { {"src" => $_} } @ARGV;
>}
>  
> -  next PACKAGE if (scalar(@actions) == 0);
> +  log_installed_files($package, map { @{$_->{src}} } @actions);
> +
> +  next PACKAGE if ($skip_install or (scalar(@actions) == 0));
>  
>my $pkg_file;
>my $cwd = getcwd();
> -- 
> 2.24.0

Bug#708192: racket: Empty report from the profile collection with stripped binary

[David Bremner]

diogo...@gmail.com (Diogo F. S. Ramos) writes:

> David Bremner  writes:
>
>>> STRIPPED
>>>   size: 4408K
>>>   startup time (`$ racket -e 42'): 500ms
>>> UNSTRIPPED
>>>   size: 10254K
>>>   startup time (`$ racket -e 42'): 298ms
>>>
>> It would be interesting to start both from a cold cache, e.g. by
>> running
>>
>> echo 3 | sudo tee /proc/sys/vm/drop_caches 
>>
>> beforehand
>
> Here are the new results, both from cold cache for the first trial, for
> 10 trials:
>
> STRIPPED
>   startup time (`$ racket -e 42'): 633ms
> UNSTRIPPED
>   startup time (`$ racket -e 42'): 385ms

I'm running the newly uploaded racket 7.5 and it seems profiling is
working fine with the default (stripped) build. To be honest I'm not
sure when profiling started working, bug I guess we can close
the bug now? 

d

Bug#948100: RFS: filezilla/3.46.3-1 -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "filezilla"

 * Package name: filezilla
   Version : 3.46.3-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

  https://mentors.debian.net/package/filezilla

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.46.3-1.dsc

Changes since the last upload:

   * Team Upload
   * New upstream version 3.46.3

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas







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

Bug#948098: RM: blogilo -- FTBFS, uninstallable, abandoned upstream

[Adam D. Barratt]

On Fri, 2020-01-03 at 16:05 -0500, John Scott wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> X-Debbugs-CC: debian-qt-...@lists.debian.org, he...@debian.org
> 
> Please remove Blogilo from unstable.

Unstable, or testing? The former is FTP team's balliwick, not Release.

> It's been broken since Oct. 2018 when it 
> couldn't be built for a KDE PIM transition and its dependencies are 
> unsatisfiable. At the bug [1] Sandro Knauß wrote
> > blogilo in is dead by upstream since 17.08. and pino made it
> > compiling for
> > 17.12. But now with 18.08 there are more issues get it compiling. I
> > filed a
> > bug against blogilo that it can't be compiled with new 18.08
> > [#908869].
> > I recommend to delete blogilo from testing. Do I need to file a own
> > RM
> > request or is [#908869] enough for you to delete it from testing?
> This question went unanswered and seemed to have been forgotten, so
> I'm filing 
> this bug and CC'ing them for their awareness. 
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909288#51

Bug#648459: schroot doesn't mount /home submount into the chroot

[Steve Langasek]

Control: tags -1 - wontfix

This was originally marked wontfix in response to a presumed kernel bug
affecting autofs, 8 years ago.  I don't know if that bug has been fixed, but
in the intervening time, use of rbind has been extensive, autofs has
diminished in significance (I certainly don't believe systemd uses autofs
today?), and this package has been orphaned; so I think this needs to be
revisited.

-- 
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 Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#948099: RFS: libfilezilla/0.19.3-1 -- build high-performing platform-independent programs (development)

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla"

 * Package name: libfilezilla
   Version : 0.19.3-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs
(development)
  libfilezilla0 - build high-performing platform-independent programs
(runtime lib)

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

  https://mentors.debian.net/package/libfilezilla

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.19.3-1.dsc

Changes since the last upload:

   * Team upload
   * New upstream version 0.19.3

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas







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

Bug#783587: Still present in buster

[Konstantinos Poulios]

This is an easy fix to a very annoying issue. Attaching (almost) the same
fix as proposed in the original report with some screenshots demonstrating
it.

Easy fix to apply to
/usr/lib/x86_64-linux-gnu/nemiver/plugins/dbgperspective/ui/openfiledialog.ui

Best regards
Kostas


openfiledialog_orig.ui
Description: application/designer


openfiledialog_modified.ui
Description: application/designer

Bug#947270: RFS: libfilezilla/0.19.3-1 -- build high-performing platform-independent programs (development

[Phil Wyett]

On Fri, 2020-01-03 at 20:55 +0100, Tobias Frost wrote:
> Hi Adam,
> 
> On Thu, vDec 26, 2019 at 04:53:32AM +0100, Adam Borowski wrote:
> > On Mon, Dec 23, 2019 at 09:19:20PM +, Phil Wyett wrote:
> > > Package: sponsorship-requests
> > > Dear mentors,
> > > 
> > > I am looking for a sponsor for my package "libfilezilla"
> > >  * Package name: libfilezilla
> > >Version : 0.19.3-1
> > >  * Vcs : https://salsa.debian.org/debian/libfilezilla
> > > Changes since the last upload:
> > > 
> > >* Team upload
> > >* New upstream version 0.19.3
> > 
> > Hi!
> > You've marked the package as "team upload", yet:
> >  * it's not currently marked as team maintained
> >+ although Gianfranco does some "team uploads"
> >  * you're not in its "Uploaders" field
> >  * you have no prior history with this package
> >  * the package is actively maintained
> > 
> > Thus: have you talked to Adrien or Gianfranco?  Sorry for the doubt,
> > but
> > quite a few well-meaning contributors try such uncoordinated uploads
> > --
> > in Debian parlance, "hijacks".  Thus, I'm asking to verify.
> 
> The package is in the Debian namespace on salsa; it is thus
> collaboratively maintained [1]
> Thus a team upload is be perfectly in order and not a hijack.
> 

Hi Tobias,

I think Adam was most concerned because I had not touched this package
in Debian before and that concerned him. I have been an uploader in
fedora, yes and worked with upstream for this release as the putty
portion of the previous i.e. filezilla 3.46.2 was a bad tarball and
hench the .3.

I am uploading again to mentors and hope we can all work as one to get
the latest out to users for libfilezilla and filezilla.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#948098: RM: blogilo -- FTBFS, uninstallable, abandoned upstream

[John Scott]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-CC: debian-qt-...@lists.debian.org, he...@debian.org

Please remove Blogilo from unstable. It's been broken since Oct. 2018 when it 
couldn't be built for a KDE PIM transition and its dependencies are 
unsatisfiable. At the bug [1] Sandro Knauß wrote
> blogilo in is dead by upstream since 17.08. and pino made it compiling for
> 17.12. But now with 18.08 there are more issues get it compiling. I filed a
> bug against blogilo that it can't be compiled with new 18.08 [#908869].

> I recommend to delete blogilo from testing. Do I need to file a own RM
> request or is [#908869] enough for you to delete it from testing?
This question went unanswered and seemed to have been forgotten, so I'm filing 
this bug and CC'ing them for their awareness. 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909288#51

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

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Adrian Bunk]

Control: reopen -1
Control: reassign -1 libboost-python1.67.0 1.67.0-14
Control: retitle -1 libboost-python1.67.0 must not drop the Python 2.7 library

When a library package renames or drops a library it has to be removed.
In practice this will happen in the boost case with the transition
to 1.71.

One real-world problem is that right now upgrading in a stable 
installation to the libboost-python1.67.0 package in unstable
would cause runtime breakage in stable, and it would be even
worse if the broken boost would enter testing.

Dimitri already agreed in a private discussion that this change was bogus.

Are there any objections against an NMU reverting the bogus Python 2
removal in boost1.67?

cu
Adrian

Bug#948096: Build and ship flasher_stub for ESP8266

[Faidon Liambotis]

Package: esptool
Version: 2.6+dfsg-1
Severity: normal

esptool in Debian currently strips the flasher stub code, which limits
the usefulness of the software significantly (e.g. flashing doesn't
work). The reasoning stated in README.Debian is:
  The binary stub code has been purged [...] due to DFSG as that code
  statically links to Espressif SDK libraries which are under license
  limitation of using with Espressif systems only and/or are distributed
  with no source code.

This made sense at the time it was written. A while ago, I raised this
with upstream¹ and back in October they merged a change² which removed
the dependency on the SDKs, and thus resolving those pesky license
incompatibilities.

A working toolchain is still required, however. Thanks to the awesome
efforts of Jonathan (Cc'ed) this is now close to being a reality! There
are many parts to it, but the required parts for building the stub for
the ESP8266 are:
  * GCC/binutils, available in Debian (even buster) with
gcc-xtensa-lx106 and binutils-xtensa-lx106;
  * A working libc. Espressif's SDK includes a patched newlib. Instead
of that, we can use picolibc, which as of v1.3 (released upstream
three days ago, and with a package in NEW³) supports ESP8266.

Between those two, removing the -Werror from upstream's Makefile⁴ and a
small patch to build the code only for the ESP8266 and not the ESP32, I
managed to build a stub and include it (manually) in the source. I'm
happy to report that I just tested it on a D1 Mini Pro board and it
works!

The Debian package will require some d/rules mechanics + esptool.py
patches to fully implement this (and on a per-chip basis), and it's
still not going to provide a solution for the ESP32, but... progress :)

Hopefully picolibc will pass through NEW soon; as soon as that happens,
please include support for building and shipping the stub in the Debian
package. I'll try to provide some patches if I find the time, but please
don't wait for me :)

Regards,
Faidon

1: https://github.com/espressif/esptool/issues/458
2: 
https://github.com/espressif/esptool/commit/6a5cb2debed15b19f3fca52d6580e2f2189f7a5e
3: https://ftp-master.debian.org/new/picolibc_1.3-1.html
4: https://github.com/espressif/esptool/issues/499

Bug#948097: libbio-db-hts-perl: autopkgtest failure: Can't locate Bio/SeqFeature/Lite.pm in @INC

[Paul Gevers]

Source: libbio-db-hts-perl
Version: 3.01-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of libbio-db-hts-perl you added an autopkgtest to
libbio-db-hts-perl, great. However, it fails. I copied some of the
output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libbio-db-hts-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libb/libbio-db-hts-perl/3632505/log.gz

1..22
# Base class package "Bio::SeqFeature::Lite" is empty.
# (Perhaps you need to 'use' the module which defines that
package first,
# or make that module available in @INC (@INC contains:
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
/usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
/usr/share/perl/5.30 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base).
#  at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/AlignWrapper.pm line 457.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/AlignWrapper.pm line 457.
not ok 1 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/AlignWrapper.pm exited
successfully
# Can't locate Bio/SeqFeature/Lite.pm in @INC (you may need to
install the Bio::SeqFeature::Lite module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS.pm line 1360.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS.pm line 1360.
# Compilation failed in require at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Query.pm line 56.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Query.pm line 56.
# Compilation failed in require at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Alignment.pm line 457.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Alignment.pm line 457.
not ok 2 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Alignment.pm exited
successfully
ok 3 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Constants.pm exited
successfully
ok 4 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Faidx.pm exited successfully
ok 5 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/FetchIterator.pm exited
successfully
ok 6 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Kseq/Record.pm exited
successfully
# Can't locate Bio/SeqFeature/Lite.pm in @INC (you may need to
install the Bio::SeqFeature::Lite module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS.pm line 1360.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS.pm line 1360.
# Compilation failed in require at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Kseq.pm line 71.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Kseq.pm line 71.
not ok 7 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Kseq.pm exited successfully
ok 8 - /usr/bin/perl -wc
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/Pileup.pm exited
successfully
# Base class package "Bio::SeqFeature::Lite" is empty.
# (Perhaps you need to 'use' the module which defines that
package first,
# or make that module available in @INC (@INC contains:
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
/usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
/usr/share/perl/5.30 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base).
#  at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/AlignWrapper.pm line 457.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/AlignWrapper.pm line 457.
# Compilation failed in require at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/PileupWrapper.pm line 49.
# BEGIN failed--compilation aborted at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/DB/HTS/PileupWrapper.pm line 49.
  

Bug#948095: node-kind-of: CVE-2019-20149

[Salvatore Bonaccorso]

Source: node-kind-of
Version: 6.0.2+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/jonschlinkert/kind-of/issues/30

Hi,

The following vulnerability was published for node-kind-of.

CVE-2019-20149[0]:
| ctorName in index.js in kind-of v6.0.2 allows external user input to
| overwrite certain internal attributes via a conflicting name, as
| demonstrated by 'constructor': {'name':'Symbol'}. Hence, a crafted
| payload can overwrite this builtin attribute to manipulate the type
| detection result.

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-2019-20149
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20149
[1] https://github.com/jonschlinkert/kind-of/issues/30
[2] https://github.com/jonschlinkert/kind-of/pull/31

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#948094: pd-fftease FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: pd-fftease
Version: 2.5.2.git20121005-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-fftease fails to cross build from source, because it strips with the
build architecture strip during make install. Beyond breaking cross
compilation, this braks DEB_BUILD_OPTIONS=nostrip as well as generation
of -dbgsym packages. It is best to defer stripping to dh_strip. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru pd-fftease-2.5.2.git20121005/debian/changelog 
pd-fftease-2.5.2.git20121005/debian/changelog
--- pd-fftease-2.5.2.git20121005/debian/changelog   2018-02-01 
23:03:51.0 +0100
+++ pd-fftease-2.5.2.git20121005/debian/changelog   2020-01-03 
21:33:43.0 +0100
@@ -1,3 +1,10 @@
+pd-fftease (2.5.2.git20121005-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 Jan 2020 21:33:43 +0100
+
 pd-fftease (2.5.2.git20121005-2) unstable; urgency=medium
 
   * Removed acknowledgements from long description
diff --minimal -Nru pd-fftease-2.5.2.git20121005/debian/rules 
pd-fftease-2.5.2.git20121005/debian/rules
--- pd-fftease-2.5.2.git20121005/debian/rules   2018-02-01 23:03:51.0 
+0100
+++ pd-fftease-2.5.2.git20121005/debian/rules   2020-01-03 21:33:42.0 
+0100
@@ -21,7 +21,7 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # clean up included example scripts
find $(CURDIR)/debian/*/$(pkglibdir) -name "*.pl" -exec \
chmod +x {} +

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Package: schroot
Followup-For: Bug #947919
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Attached is an updated patch which implements source chroots 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 Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru schroot-1.6.10/debian/control schroot-1.6.10/debian/control
--- schroot-1.6.10/debian/control   2018-09-01 00:25:59.0 -0700
+++ schroot-1.6.10/debian/control   2019-12-30 21:59:11.0 -0800
@@ -54,7 +54,7 @@
  sbuild (<< 0.62.6),
 # We need the --find option of update-binfmts
  binfmt-support (<< 2.0.1)
-Suggests: debootstrap, lvm2, btrfs-tools, aufs-tools | unionfs-fuse, 
qemu-user-static
+Suggests: debootstrap, lvm2, btrfs-tools, zfsutils-linux, aufs-tools | 
unionfs-fuse, qemu-user-static
 Description: Execute commands in a chroot environment
  schroot allows users to execute commands or interactive shells in
  different chroots.  Any number of named chroots may be created, and
@@ -67,7 +67,7 @@
  Several different types of chroot are supported, including normal
  directories in the filesystem, and also block devices.  Sessions,
  persistent chroots created on the fly from files (tar with optional
- compression) and Btrfs and LVM snapshots are also supported.
+ compression) and Btrfs, ZFS, and LVM snapshots are also supported.
  .
  schroot supports kernel personalities, allowing the programs run
  inside the chroot to have a different personality.  For example,
@@ -76,7 +76,7 @@
  .
  schroot also integrates with sbuild, to allow building packages with
  all supported chroot types, including session-managed chroot types
- such as Btrfs and LVM snapshots.
+ such as Btrfs, ZFS, and LVM snapshots.
  .
  schroot shares most of its options with dchroot, but offers vastly
  more functionality.
diff -Nru schroot-1.6.10/debian/patches/series 
schroot-1.6.10/debian/patches/series
--- schroot-1.6.10/debian/patches/series2018-09-01 00:25:59.0 
-0700
+++ schroot-1.6.10/debian/patches/series2019-12-30 21:59:11.0 
-0800
@@ -13,3 +13,4 @@
 update_czech_schroot_translation.patch
 update_french_schroot_manpage_translation_2018.patch
 update_german_schroot_manpage_translation_2018.patch
+zfs-snapshot-support.patch
diff -Nru schroot-1.6.10/debian/patches/zfs-snapshot-support.patch 
schroot-1.6.10/debian/patches/zfs-snapshot-support.patch
--- schroot-1.6.10/debian/patches/zfs-snapshot-support.patch1969-12-31 
16:00:00.0 -0800
+++ schroot-1.6.10/debian/patches/zfs-snapshot-support.patch2019-12-30 
21:59:11.0 -0800
@@ -0,0 +1,1189 @@
+Description: add support for a zfs-snapshot backend.
+Author: Steve Langasek 
+Last-Update: 2020-01-03
+
+Index: schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+===
+--- /dev/null
 schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+@@ -0,0 +1,304 @@
++/* Copyright © 2005-2009  Roger Leigh 
++ * Copyright © 2019   Steve Langasek 
++ *
++ * schroot 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, either version 3 of the License, or
++ * (at your option) any later version.
++ *
++ * schroot 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, see
++ * .
++ *
++ */
++
++#include 
++
++#include "sbuild-chroot-zfs-snapshot.h"
++#include "sbuild-chroot-facet-session.h"
++#include "sbuild-chroot-facet-session-clonable.h"
++#include "sbuild-chroot-facet-source-clonable.h"
++#include "sbuild-chroot-facet-source.h"
++#include "sbuild-chroot-facet-mountable.h"
++#include "sbuild-format-detail.h"
++
++#include 
++#include 
++
++#include 
++
++using std::endl;
++using boost::format;
++using namespace sbuild;
++
++chroot_zfs_snapshot::chroot_zfs_snapshot ():
++  chroot(),
++  dataset(),
++  clone_name(),
++  snapshot_name(),
++  snapshot_options()
++{
++  add_facet(chroot_facet_source_clonable::create());
++  add_facet(chroot_facet_mountable::create());
++}
++
++chroot_zfs_snapshot::chroot_zfs_snapshot (const chroot_zfs_snapshot& rhs):
++  chroot(rhs),
++  dataset(rhs.dataset),
++  clone_name(rhs.clone_name),
++  snapshot_name(rhs.snapshot_name),
++  snapshot_options(rhs.snapshot_options)
++{
++}
++
++chroot_zfs_snapshot::~chroot_zfs_snapshot ()
++{
++}

Bug#948092: RM: htslib, delly, fastqtl, kallisto, libtabixpp, qtltools, rsem, samtools, segemehl, shapeit4, stringtie, stacks [s390x] -- ROM; upstream htslib broke s390x and is holding up several tran

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Dear ftp.debian.org people,

htslib FTBFS on big-endian systems
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947462 and this is
blocking the following transitions: auto-htslib, python2-rm, python3.8,
and auto-pbbam

I propose we delete the affected s390x packages for now and when/if
upstream has fixed their code for big endian systems then we can upload
the fixed versions later.

Thanks in advance

Bug#948093: hyphy: autopkgtest regression: Duplicate analysis keyword

[Paul Gevers]

Source: hyphy
Version: 2.5.1+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of hyphy the autopkgtest of hyphy fails in testing
when that autopkgtest is run with the binary packages of hyphy from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
hyphy  from testing2.5.1+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=hyphy

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hyphy/3845632/log.gz

autopkgtest [19:16:26]: test run-unit-tests: [---
Error:
Duplicate analysis keyword (not case sensitive) in {CLST, Apply
clustering methods for phylogeny reconstruction (UPGMA,WPGMA,complete or
minimal linkage) to nucleotide, protein and codon data, using MLE of
pairwise distances with user-selectable models. These methods produce
trees with global molecular clock., ClusterAnalysis.bf}

Check errors.log for execution error details.
autopkgtest [19:16:26]: test run-unit-tests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946022: gitlab-workhorse: diff for NMU version 8.16.0+debian-1.1

[Adrian Bunk]

On Wed, Jan 01, 2020 at 05:54:59PM +0530, Pirate Praveen wrote:
> On Tue, 31 Dec 2019 11:14:19 +0200 Adrian Bunk  wrote:
> > I've prepared an NMU for gitlab-workhorse (versioned as 8.16.0+debian-1.1)
> > and uploaded it to DELAYED/14. Please feel free to tell me if I should
> > cancel it.
> 
> Thanks for the fixes, I have uploaded a fixed version (8.16.0+debian-2).
> Though it introduced an autopkgtest regression because netstat is provided
> by net-tools package (there is no netstat package). I have fixed the
> regression in 8.18.0+debian-1.

Sorry for that, and thanks for correcting my mistake.

cu
Adrian

Bug#947936: chrony: Does (still) not start properly on boot on buster

[Michael Biebl]

Am 03.01.20 um 18:06 schrieb Santiago Vila:
> reassign 947936 chrony,systemd
> thanks
> 
> I am unsure at this point where is exactly the problem.
> 
> I have several test instances at GCE (running buster) where chrony
> does not start even if it's enabled.
> 
> By trial and error I managed to make chrony to start again
> properly if I do this:
> 
> journalctl --rotate
> init 6
> 
> So the natural question would be: What kind of bug in systemd can make
> it not to start a service at all when there is a "bad" journal?

Can you provide instructions how this issue can be reproduced?

systemd in buster (and testing/sid) ships
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
which will prevent systemd-timesyncd from being started if chrony is
installed.
I'm running chrony here (with systemd-timesyncd being enabled) and it
works as expected.





signature.asc
Description: OpenPGP digital signature

Bug#850096: Make git snapshot? (2011 → 2016)

[Sylvain Beucler]

Hi,

On 26/12/2019 01:13, Jacob Nevins wrote:
> In 2017, Sylvain Beucler wrote:
>> it's best to bug upstream into making a proper release, this would
>> benefit to everybody.
> There's now been an upstream release: 2019.1 (and 2019.1.1 shortly
> afterward).
> 
> 

Thanks for your interest. I saw the news, but I haven't got the time to
perform a full license re-check on all the gargoyle sub-projects yet.

Cheers!
Sylvain

Bug#948091: fonts-noto: Update fonts-noto to the latest upstream

[Mystic-Mirage]

Package: fonts-noto
Version: 20181227-1
Severity: wishlist

Dear Maintainer,

Can I ask you to update the fonts-noto package for Debian from the latest 
upstream?

Recently an annoying bug was fixed which affects a lot of users with the 
Cyrillic-based writing systems: Ukrainian, Belarusian, Serbian (Cyrillic), 
Macedonian, etc.

See more info here https://github.com/googlefonts/noto-fonts/issues/1051 and 
here https://github.com/googlefonts/noto-source/pull/125.

I really want this fix to be included in the next upcoming Debian release and 
also Ubuntu LTS.

Best regards,
Alex

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.13.1-2+b1  amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.1-2 amd64FreeType 2 font engine, shared 
library files
ii  libxft2:amd64  2.3.2-2  amd64FreeType-based font drawing 
library for X

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

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

Versions of packages fonts-noto depends on:
ii  fonts-noto-core  20181227-1

Versions of packages fonts-noto recommends:
ii  fonts-noto-cjk  1:20190410+repack1-2
ii  fonts-noto-cjk-extra1:20190410+repack1-2
ii  fonts-noto-color-emoji  0~20180810-1
ii  fonts-noto-extra20181227-1
ii  fonts-noto-mono 20181227-1
ii  fonts-noto-ui-core  20181227-1
ii  fonts-noto-ui-extra 20181227-1
ii  fonts-noto-unhinted 20181227-1

fonts-noto suggests no packages.

-- no debconf information

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank  wrote:
>
> Hi Marco
>
> On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > On Jan 03, Sudip Mukherjee  wrote:
> > > Do we package libbpf from their github repo independent of the kernel
> > > update? Then we will need to remove the libbpf building bits from the
> > > Debian kernel source and create a separate package for libbpf.
> > This is what some of the upstream libbpf developers requested us to do.
>
> What I don't understand is, if the kernel git tree is the primary
> location for this library, why should we use an external copy?
>
> What are the benefits of doing so?

The only benefit will be that we will be able to update the libraries
irrespective of kernel update. libbpf v0.0.6 has been released in
December but we will not be able to move to that version. The
userspace application using this library is deprived of the benefit of
the fixes that v0.0.6 brings.


-- 
Regards
Sudip

Bug#948090: src2tex FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: src2tex
Version: 2.12h-9
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

src2tex fails to cross build from source, because make install strips
with the build architecture strip. Beyond breaking cross compilation,
this also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of
-dbgsym packages. Surprisingly, make install does nothing else. In
particular, it doesn't install anything. So the easiest way to defer
stripping to dh_strip is simply skipping make install. Please consider
applying the attached patch.

Helmut
diff -u src2tex-2.12h/debian/changelog src2tex-2.12h/debian/changelog
--- src2tex-2.12h/debian/changelog
+++ src2tex-2.12h/debian/changelog
@@ -1,3 +1,10 @@
+src2tex (2.12h-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 Jan 2020 21:22:16 +0100
+
 src2tex (2.12h-9) unstable; urgency=medium
 
   * Recommend texlive instead of tetex-bin which is no longer available
diff -u src2tex-2.12h/debian/rules src2tex-2.12h/debian/rules
--- src2tex-2.12h/debian/rules
+++ src2tex-2.12h/debian/rules
@@ -3,0 +4,2 @@
+
+override_dh_auto_install:

Bug#948089: gkrellm-thinkbat FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: gkrellm-thinkbat
Version: 0.2.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellm-thinkbat fails to cross build from source, because it builds for
the build architecture. dh_auto_build can be used to pass cross tools to
make, but the Makefile still hard codes pkg-config. It also uses a build
architecture strip via install -s. Doing so also breaks generation of
-dbgsym packages as well as DEB_BUILD_OPTIONS=nostrip. It is best to
defer all stripping to dh_strip. The attached patch fixes all mentioned
issues. Please consider applying it.

Helmut
diff -u gkrellm-thinkbat-0.2.2/Makefile gkrellm-thinkbat-0.2.2/Makefile
--- gkrellm-thinkbat-0.2.2/Makefile
+++ gkrellm-thinkbat-0.2.2/Makefile
@@ -1,8 +1,10 @@
 VERSION = 0.2.2
 CC = gcc
 CFLAGS = -I. -Wall -pedantic -O2
-INCLUDE = `pkg-config gtk+-2.0 --cflags` -fPIC -DVERSION=\"$(VERSION)\"
+PKG_CONFIG ?= pkg-config
+INCLUDE = `$(PKG_CONFIG) gtk+-2.0 --cflags` -fPIC -DVERSION=\"$(VERSION)\"
 LFLAGS = -shared -lm
+INSTALL ?= install
 INSTALLDIR = $(DESTDIR)/usr/lib/gkrellm2/plugins/
 
 
@@ -22,8 +24,8 @@
rm -f *.o gkrellm-thinkbat.so
 
 install : gkrellm-thinkbat.so
-   install -d $(INSTALLDIR)
-   install -c -s -m 644 gkrellm-thinkbat.so $(INSTALLDIR)
+   $(INSTALL) -d $(INSTALLDIR)
+   $(INSTALL) -c -s -m 644 gkrellm-thinkbat.so $(INSTALLDIR)
 
 dist :
rm -rf gkrellm-thinkbat-$(VERSION)
diff -u gkrellm-thinkbat-0.2.2/debian/rules gkrellm-thinkbat-0.2.2/debian/rules
--- gkrellm-thinkbat-0.2.2/debian/rules
+++ gkrellm-thinkbat-0.2.2/debian/rules
@@ -22,7 +22,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch $@
 
 clean:
@@ -37,7 +37,7 @@
dh_testroot
dh_clean -k 
dh_installdirs
-   $(MAKE) DESTDIR=$(CURDIR)/debian/gkrellm-thinkbat install
+   dh_auto_install -- INSTALL='install --strip-program=true'
 
 # Build architecture-independent files here.
 binary-indep: build install
diff -u gkrellm-thinkbat-0.2.2/debian/changelog 
gkrellm-thinkbat-0.2.2/debian/changelog
--- gkrellm-thinkbat-0.2.2/debian/changelog
+++ gkrellm-thinkbat-0.2.2/debian/changelog
@@ -1,3 +1,13 @@
+gkrellm-thinkbat (0.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make pkg-config and install substitutable.
++ Defer stripping to dh_strip by passing a non-stripping install.
+
+ -- Helmut Grohne   Fri, 03 Jan 2020 19:05:48 +0100
+
 gkrellm-thinkbat (0.2.2-1) unstable; urgency=low
 
   * Initial release (Closes: #470831)

Bug#948088: buster-pu: reject package from NEW queue libsoldout/1.4-3

[Sven Hoexter]

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

Hi,
I made a mistake and uploaded libsoldout/1.4-3 to stable instead of
unstable. Please reject the package from the pu NEW queue.

I'm sorry. :(

Sven

Bug#947270: RFS: libfilezilla/0.19.3-1 -- build high-performing platform-independent programs (development

[Tobias Frost]

Hi Adam,

On Thu, vDec 26, 2019 at 04:53:32AM +0100, Adam Borowski wrote:
> On Mon, Dec 23, 2019 at 09:19:20PM +, Phil Wyett wrote:
> > Package: sponsorship-requests
> 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "libfilezilla"
> 
> >  * Package name: libfilezilla
> >Version : 0.19.3-1
> >  * Vcs : https://salsa.debian.org/debian/libfilezilla
> 
> > Changes since the last upload:
> > 
> >* Team upload
> >* New upstream version 0.19.3
> 
> Hi!
> You've marked the package as "team upload", yet:
>  * it's not currently marked as team maintained
>+ although Gianfranco does some "team uploads"
>  * you're not in its "Uploaders" field
>  * you have no prior history with this package
>  * the package is actively maintained
> 
> Thus: have you talked to Adrien or Gianfranco?  Sorry for the doubt, but
> quite a few well-meaning contributors try such uncoordinated uploads --
> in Debian parlance, "hijacks".  Thus, I'm asking to verify.

The package is in the Debian namespace on salsa; it is thus collaboratively 
maintained [1]
Thus a team upload is be perfectly in order and not a hijack.

-- 
tobi

[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group


signature.asc
Description: PGP signature

Bug#948041: impossible to update libbpf without updating the kernel

[Bastian Blank]

Hi Marco

On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> On Jan 03, Sudip Mukherjee  wrote:
> > Do we package libbpf from their github repo independent of the kernel
> > update? Then we will need to remove the libbpf building bits from the
> > Debian kernel source and create a separate package for libbpf.
> This is what some of the upstream libbpf developers requested us to do.

What I don't understand is, if the kernel git tree is the primary
location for this library, why should we use an external copy?

What are the benefits of doing so?

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty

Bug#947911: sqlgrey daemon does not stop when requested

[Antonin Kral]

* Karl O. Pinc  [2020-01-03 20:45] wrote:
> On Fri, 3 Jan 2020 20:12:00 +0100
> Antonin Kral  wrote:
> 
> > thank you for your report (and really appreciate the patch). 
> 
> I did not check to see if there's any other "actions" that
> need a similar fix.  (I know that "start" works.  :)

:) No issues, I've extended your proposal to the others as well (like 
restart for example).

Thank you, Antonin

Bug#947911: sqlgrey daemon does not stop when requested

[Karl O. Pinc]

On Fri, 3 Jan 2020 20:12:00 +0100
Antonin Kral  wrote:

> thank you for your report (and really appreciate the patch). 

I did not check to see if there's any other "actions" that
need a similar fix.  (I know that "start" works.  :)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Felipe Sateler]

On Fri, Jan 3, 2020 at 12:16 AM Joshua Hudson  wrote:

> > Does `journalctl --user-unit pulseaudio.service` have anything to say?
>
> Says "daemon already running" quite a few times.
>
> > You can set the debug flags on daemon.conf to force it to verbose mode.
>
> Spectacular:
>
> E: [pulseaudio] pid.c: Daemon already running.
> E: [pulseaudio] main.c: pa_pid_file_create() failed.
>

Is there actually a pulseaudio daemon running? Where? Is it managed by
systemd?


You didn't attach your client.conf

-- 

Saludos,
Felipe Sateler

Bug#948086: package fftw3 does not install cmake config files

[KESTENER Pierre]

Package: fftw3
Version: 3.3.8-2

Besides actual library binaries, building package fftw3 produces some package 
config files (*.pc) and some cmake files (*.cmake) but only the pkg-config 
files are installed.

I suggest a minor modification to install the cmake files too:
in libfftw3-dev.install, just add the following line:
usr/lib/*/cmake/fftw3/*.cmake

in libfftw3-dev.dirs, add
usr/lib/cmake/fftw3

Best regards.

Bug#948087: aufs build depends on the removed linux-kbuild-5.2

[Adrian Bunk]

Source: aufs
Version: 5.2+20190909-1.1
Severity: serious
Tags: ftbfs

linux-kbuild-5.4 is now in unstable.

Bug#948085: jengelman-shadow build depends on openjdk-8-jdk-headless

[Adrian Bunk]

Source: jengelman-shadow
Version: 4.0.3-1
Severity: serious

jengelman-shadow build depends on openjdk-8-jdk-headless
that is not in buster and will not be in bullseye.

If possible default-jdk-headless should be uised instead.

Bug#948084: backblaze-b2 build depends on the removed yapf package

[Adrian Bunk]

Source: backblaze-b2
Version: 1.3.8-2
Severity: serious
Tags: ftbfs

yapf (0.28.0-2) unstable; urgency=medium
...
  [ Sandro Tosi ]
  * Drop python2 support; Closes: #938863

 -- Sandro Tosi   Wed, 06 Nov 2019 10:33:29 -0500

Bug#948083: libbio-db-embl-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Andreas Beckmann]

Package: libbio-db-embl-perl
Version: 1.7.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libbio-db-embl-perl_1.7.4-1_all.deb ...
  Unpacking libbio-db-embl-perl (1.7.4-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libbio-db-embl-perl_1.7.4-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man3/Bio::DB::EMBL.3pm.gz', which is 
also in package libbio-perl-perl 1.7.2-3
  Errors were encountered while processing:
   /var/cache/apt/archives/libbio-db-embl-perl_1.7.4-1_all.deb


cheers,

Andreas


libbio-perl-perl=1.7.2-3_libbio-db-embl-perl=1.7.4-1.log.gz
Description: application/gzip

Bug#948082: bioperl-run build depends on and recommends the removed blast2 transitional package

[Adrian Bunk]

Source: bioperl-run
Version: 1.7.3-1
Severity: serious
Tags: ftbfs
Control: affects -1 bioperl-run

bioperl-run build depends on and recommends the removed
blast2 transitional package.

Bug#948080: python-cogent build depends on and recommends the removed blast2 transitional package

[Adrian Bunk]

Source: python-cogent
Version: 1.9-14
Severity: serious
Tags: bullseye sid
Control: affects -1 python-cogent

python-cogent build depends on and recommends the removed
blast2 transitional package.

Bug#948081: pynast build depends on and recommends the removed blast2 transitional package

[Adrian Bunk]

Source: pynast
Version: 1.2.2-4
Severity: serious
Tags: bullseye sid ftbfs
Control: affects -1 pynast

pynast build depends on and recommends the removed
blast2 transitional package.

Bug#947630: Package easygen was rejected

[Felix Lechner]

Hi Tong,

On Fri, Jan 3, 2020 at 10:48 AM Tong Sun
 wrote:
>
> E.g.,  I just uploaded  the binary package, not the source. is it telling me 
> that I should upload the source package as well?

You can build a full package with 'debuild -sa'.

> Rejecting incomplete upload.

Is it rejecting the *.changes file that triggered the tag, i.e. did
the changes file that triggered the tag *not* include the source?

Kind regards

Felix Lechner

Bug#947911: sqlgrey daemon does not stop when requested

[Antonin Kral]

Hi Karl,

thank you for your report (and really appreciate the patch). I will 
upload the updated version shortly.

Best,

Antonin

* Karl O. Pinc  [2020-01-02 00:54] wrote:
> Package: sqlgrey
> Version: 1:1.8.0-1
> Severity: serious
> Tags: patch
> Justification: Policy 9.3.2
> 
> Hello,
> 
> /etc/init.d/sqlgrey does not stop the sqlgrey daemon.  (Policy
> seems to say that being able to stop is required, so I've marked
> the bug serious.)
> 
> The problem is that start-stop-daemon --pidfile is no longer
> sufficient to stop a daemon when the pidfile is written as
> a non-priviliged user.  So the daemon is not stopped.
> (As of start-stop-daemon version 1.19.3.)
> 
> The attached patch adds "--user sqlgrey" to the start-stop-daemon
> command, which is enough that the command stops the daemon.
> 
> Regards,
> Karl
> 
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sqlgrey depends on:
> ii  adduser   3.118
> pn  libdate-calc-perl 
> pn  libdbd-pg-perl | libdbd-mysql-perl | libdbd-sqlite3-perl  
> pn  libnet-server-perl
> ii  perl  5.28.1-6
> 
> Versions of packages sqlgrey recommends:
> pn  libdbd-pg-perl  
> ii  postfix 3.4.7-0+deb10u1
> 
> sqlgrey suggests no packages.

> --- sqlgrey   2020-01-01 17:23:16.952002224 -0600
> +++ sqlgrey.new   2020-01-01 17:35:18.719746141 -0600
> @@ -48,7 +48,8 @@
>   ;;
>stop)
>   echo -n "Stopping $DESC: $NAME"
> - start-stop-daemon --stop --quiet --pidfile $PIDFILE --oknodo
> + start-stop-daemon --stop --quiet \
> +   --user sqlgrey --pidfile $PIDFILE --oknodo
>  rm -f $PIDFILE
>   echo "."
>   ;;

Bug#947723: Devede: dropping python-scour from Build Depends

[Ross Gammon]

Hi,

Further to Jonas's suggestion, I found this in the changelog for scour:

scour (0.37-2) unstable; urgency=medium

  [ Jeremy Bicha ]
  * Add Provides: dh-sequence-scour.
Packages can now Build-Depend on dh-sequence-scour
instead of scour and then drop "--with scour" from debian/rules
(Requires debhelper 12)

  [ Martin Pitt ]
  * Bump Standards-Version to 4.3.0. No changes necessary.
  * Move to debhelper compat level 12.

 -- Martin Pitt https://launchpad.net/~pitti>>  Sun, 13 Jan 
2019 12:01:02 +

So build-depending on dh-sequence-scour and dropping "--with scour" from 
debian/rules would seem to be the best option. Devede is already using 
debhelper-compat (= 12).


Regards,

Ross

Bug#948079: skip-systemd-native-flag-missing-pre-depends triggers too frequently

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.53
Severity: normal

The fixer for skip-systemd-native-flag-missing-pre-depends triggers too easily,
even for packages that aren't even using the flag.

It's been disabled for the moment.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-4
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.3
ii  lintian2.43.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#948078: autoconf-archive: please apply patch to fix boost_python library link

[Gianfranco Costamagna]

control: tags -1 patch pending

Hello, since this is delaying boost transition, and blocking 3 RC bug fixes, I 
uploaded it in deferred/5

let me know if I can speed it up, or feel free to delete it if you don't like 
the change

G.

On Fri, 3 Jan 2020 19:35:20 +0100 Gianfranco Costamagna 
 wrote:
> Source: autoconf-archive
> Version: 20190106-2
> Severity: serious
> 
> Hello, esys-particle is FTBFS with python3, because the following:
> dh_auto_configure -- $(extra_flags) 
> --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH) 
> --with-boost-python='boost_python$(PY3VER)'
> 
> 
> tanslates the build into a "boost_python37" link line
> 
> checking whether boost_python37 is the correct library... yes
> 
> /bin/bash ../libtool  --tag=CXX   --mode=link mpicxx  -Wall -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -release 2.3.4  -L/usr/lib/i386-linux-gnu 
> -lboost_system -lpython3.7m -Wl,-z,relro -Wl,-z,now -o libFoundation.la 
> -rpath /usr/lib/i386-linux-gnu libFoundation_la-console.lo 
> libFoundation_la-Counter.lo libFoundation_la-Matrix3.lo 
> libFoundation_la-Quaternion.lo libFoundation_la-vec3.lo 
> libFoundation_la-Timer.lo libFoundation_la-StringUtil.lo 
> libFoundation_la-realdist.lo libFoundation_la-PathSearcher.lo 
> libFoundation_la-Runnable.lo libFoundation_la-PathUtil.lo 
> libFoundation_la-Rng.lo libFoundation_la-BoundingSphere.lo 
> libFoundation_la-BoundingBox.lo libFoundation_la-cube_eq.lo 
> -lboost_filesystem boost_python37 -lpython3.7m -lmpi++ -lmpi 
> 
> note the missing "-l" on python, while it is there for the filesystem link.
> 
> The following patch fixes the issue, and I would like to NMU it ASAP if you 
> agree.
> 
> Author: Gianfranco Costamagna 
> Last-Update: 2020-01-03
> 
> --- autoconf-archive-20190106.orig/m4/ax_boost_python.m4
> +++ autoconf-archive-20190106/m4/ax_boost_python.m4
> @@ -109,7 +109,7 @@ if test "$ac_cv_boost_python" = "yes"; t
>  BOOST_PYTHON_MODULE(test) { throw "Boost::Python test."; }]], [])],
>  [AS_VAR_SET([ax_Lib], [yes])],
>  [AS_VAR_SET([ax_Lib], [no])])])
> -AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=$ax_lib break], [])
> +AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=-l$ax_lib break], [])
>  AS_VAR_POPDEF([ax_Lib])dnl
>done
>AC_SUBST(BOOST_PYTHON_LIB)
> 
> 
> It looks like just an obvious typo, I'll upstream the fix soon.
> 
> G.
diff -Nru autoconf-archive-20190106/debian/changelog 
autoconf-archive-20190106/debian/changelog
--- autoconf-archive-20190106/debian/changelog  2019-09-03 20:44:43.0 
+0200
+++ autoconf-archive-20190106/debian/changelog  2020-01-03 19:46:30.0 
+0100
@@ -1,3 +1,12 @@
+autoconf-archive (20190106-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/0001-ax_boost_python.m4-fix-missing-l-parameter-
+resulting.patch: Upstream proposed fix for python boost wrong linking
+Closes: #948078
+
+ -- Gianfranco Costamagna   Fri, 03 Jan 2020 
19:46:30 +0100
+
 autoconf-archive (20190106-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
autoconf-archive-20190106/debian/patches/0001-ax_boost_python.m4-fix-missing-l-parameter-resulting.patch
 
autoconf-archive-20190106/debian/patches/0001-ax_boost_python.m4-fix-missing-l-parameter-resulting.patch
--- 
autoconf-archive-20190106/debian/patches/0001-ax_boost_python.m4-fix-missing-l-parameter-resulting.patch
1970-01-01 01:00:00.0 +0100
+++ 
autoconf-archive-20190106/debian/patches/0001-ax_boost_python.m4-fix-missing-l-parameter-resulting.patch
2020-01-03 19:46:30.0 +0100
@@ -0,0 +1,45 @@
+From 596a3bb21e9084a751117d47018ddd2943f92bb5 Mon Sep 17 00:00:00 2001
+From: Gianfranco Costamagna 
+Date: Fri, 3 Jan 2020 19:36:53 +0100
+Subject: [PATCH] ax_boost_python.m4: fix missing "-l" parameter, resulting
+ into a link failure when used.
+
+configuring a project with something like:
+--with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH) 
--with-boost-python='boost_python3.7'
+
+tanslates the build into a "boost_python37" link line
+
+checking whether boost_python37 is the correct library... yes
+
+/bin/bash ../libtool  --tag=CXX   --mode=link mpicxx  -Wall -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -release 2.3.4  -L/usr/lib/i386-linux-gnu 
-lboost_system -lpython3.7m -Wl,-z,relro -Wl,-z,now -o libFoundation.la -rpath 
/usr/lib/i386-linux-gnu libFoundation_la-console.lo libFoundation_la-Counter.lo 
libFoundation_la-Matrix3.lo libFoundation_la-Quaternion.lo 
libFoundation_la-vec3.lo libFoundation_la-Timer.lo 
libFoundation_la-StringUtil.lo libFoundation_la-realdist.lo 
libFoundation_la-PathSearcher.lo libFoundation_la-Runnable.lo 
libFoundation_la-PathUtil.lo libFoundation_la-Rng.lo 
libFoundation_la-BoundingSphere.lo libFoundation_la-BoundingBox.lo 
libFoundation_la-cube_eq.lo -lboost_filesystem boost_python37 -lpython3.7m 
-lmpi++ -lmpi
+
+note the missing "-l" on python, wh

Bug#938692: trace-summary: diff for NMU version 0.89-1.1

[Adrian Bunk]

Control: tags 938692 + pending

Dear maintainer,

I've prepared an NMU for trace-summary (versioned as 0.89-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru trace-summary-0.89/debian/changelog trace-summary-0.89/debian/changelog
--- trace-summary-0.89/debian/changelog	2019-09-04 09:14:47.0 +0300
+++ trace-summary-0.89/debian/changelog	2020-01-03 20:21:59.0 +0200
@@ -1,3 +1,12 @@
+trace-summary (0.89-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+
+  [ Scott Kitterman ]
+  * Switch to python3 (Closes: #938692)
+
+ -- Adrian Bunk   Fri, 03 Jan 2020 20:21:59 +0200
+
 trace-summary (0.89-1) unstable; urgency=medium
 
   * New upstream version 0.89
diff -Nru trace-summary-0.89/debian/control trace-summary-0.89/debian/control
--- trace-summary-0.89/debian/control	2019-04-21 17:05:35.0 +0300
+++ trace-summary-0.89/debian/control	2020-01-03 20:21:35.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python | python-all | python-dev | python-all-dev
+   python3-all
 Standards-Version: 4.3.0
 Homepage: https://www.bro.org/sphinx/components/trace-summary/README.html
 Vcs-Git: https://salsa.debian.org/bro-team/trace-summary.git
@@ -13,8 +13,8 @@
 Package: trace-summary
 Architecture: all
 Depends: ${misc:Depends},
- ${python:Depends},
- python-subnettree
+ ${python3:Depends},
+ python3-subnettree
 Description: tool for generating break-downs of network traffic
  trace-summary is a Python script that generates break-downs of network
  traffic, including lists of the top hosts, protocols, ports,
diff -Nru trace-summary-0.89/debian/rules trace-summary-0.89/debian/rules
--- trace-summary-0.89/debian/rules	2018-12-22 00:51:02.0 +0200
+++ trace-summary-0.89/debian/rules	2020-01-03 20:21:35.0 +0200
@@ -4,6 +4,9 @@
 include /usr/share/dpkg/default.mk
 
 %:
-	dh $@ --with=python2
+	dh $@ --with=python3
+
+override_dh_python3:
+	dh_python3 --shebang=/usr/bin/python3
 
 override_dh_auto_build override_dh_auto_test:

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

On Fri, Jan 3, 2020 at 6:15 PM Marco d'Itri  wrote:
>
> On Jan 03, Sudip Mukherjee  wrote:
>
> > Do we package libbpf from their github repo independent of the kernel
> > update? Then we will need to remove the libbpf building bits from the
> > Debian kernel source and create a separate package for libbpf.
> This is what some of the upstream libbpf developers requested us to do.

great. I guess there is no other bug report for this request and we
can use this bug to track that activity. I am not sure if the
kernel-team is aware of the request and if they agree with that. I
have added Ben in the upstream discussion for his comment.

I will do an initial packaging over the weekend unless you have
already done this or want to do the same.


-- 
Regards
Sudip

Bug#948078: autoconf-archive: please apply patch to fix boost_python library link

[Gianfranco Costamagna]

Source: autoconf-archive
Version: 20190106-2
Severity: serious

Hello, esys-particle is FTBFS with python3, because the following:
dh_auto_configure -- $(extra_flags) 
--with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH) 
--with-boost-python='boost_python$(PY3VER)'


tanslates the build into a "boost_python37" link line

checking whether boost_python37 is the correct library... yes

/bin/bash ../libtool  --tag=CXX   --mode=link mpicxx  -Wall -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -release 2.3.4  -L/usr/lib/i386-linux-gnu 
-lboost_system -lpython3.7m -Wl,-z,relro -Wl,-z,now -o libFoundation.la -rpath 
/usr/lib/i386-linux-gnu libFoundation_la-console.lo libFoundation_la-Counter.lo 
libFoundation_la-Matrix3.lo libFoundation_la-Quaternion.lo 
libFoundation_la-vec3.lo libFoundation_la-Timer.lo 
libFoundation_la-StringUtil.lo libFoundation_la-realdist.lo 
libFoundation_la-PathSearcher.lo libFoundation_la-Runnable.lo 
libFoundation_la-PathUtil.lo libFoundation_la-Rng.lo 
libFoundation_la-BoundingSphere.lo libFoundation_la-BoundingBox.lo 
libFoundation_la-cube_eq.lo -lboost_filesystem boost_python37 -lpython3.7m 
-lmpi++ -lmpi 

note the missing "-l" on python, while it is there for the filesystem link.

The following patch fixes the issue, and I would like to NMU it ASAP if you 
agree.

Author: Gianfranco Costamagna 
Last-Update: 2020-01-03

--- autoconf-archive-20190106.orig/m4/ax_boost_python.m4
+++ autoconf-archive-20190106/m4/ax_boost_python.m4
@@ -109,7 +109,7 @@ if test "$ac_cv_boost_python" = "yes"; t
 BOOST_PYTHON_MODULE(test) { throw "Boost::Python test."; }]], [])],
 [AS_VAR_SET([ax_Lib], [yes])],
 [AS_VAR_SET([ax_Lib], [no])])])
-AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=$ax_lib break], [])
+AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=-l$ax_lib break], [])
 AS_VAR_POPDEF([ax_Lib])dnl
   done
   AC_SUBST(BOOST_PYTHON_LIB)


It looks like just an obvious typo, I'll upstream the fix soon.

G.
Author: Gianfranco Costamagna 
Last-Update: 2020-01-03

--- autoconf-archive-20190106.orig/m4/ax_boost_python.m4
+++ autoconf-archive-20190106/m4/ax_boost_python.m4
@@ -109,7 +109,7 @@ if test "$ac_cv_boost_python" = "yes"; t
 BOOST_PYTHON_MODULE(test) { throw "Boost::Python test."; }]], [])],
 [AS_VAR_SET([ax_Lib], [yes])],
 [AS_VAR_SET([ax_Lib], [no])])])
-AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=$ax_lib break], [])
+AS_VAR_IF([ax_Lib], [yes], [BOOST_PYTHON_LIB=-l$ax_lib break], [])
 AS_VAR_POPDEF([ax_Lib])dnl
   done
   AC_SUBST(BOOST_PYTHON_LIB)

Bug#947423: kallisto ftbfs with htslib 1.10.2

[Andreas Tille]

Control: tags -1 unreproducible

Hi Paul,

I've build kallisto in an unstable pbuilder chroot without any problems.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Rene Engelhard]

Hi,

On Fri, Jan 03, 2020 at 06:00:49PM +, Christopher Obbard wrote:
> On Fri, 3 Jan 2020 at 17:52, Rene Engelhard  wrote:
> >
> > Hi,
> >
> > On Fri, Jan 03, 2020 at 06:36:56PM +0100, Rene Engelhard wrote:
> > > > The following additional packages will be installed:
> > > >libjuh-java libjurt-java libridl-java libunoloader-java
> > > > The following NEW packages will be installed:
> > > >libjuh-java libjurt-java libridl-java libunoloader-java
> > [...]
> >
> > I wonder how you got into this. Looks you didn't upgrade to 6.4 yet
> > before so that it does flag libjuh-java libjurt-java libridl-java
> > libunoloader-java as *additional* packages?
> 
> those four depends appear to be coming from the upgrade of
> libreoffice-java-common

Yes, but from libreoffice-java-common 6.3.x -> 6.4.x and that only
because libreoffice-java-common gained explicit dependencies on them
since they "obviously" are needed for the Java stuff :-)

(They formerly were in "ure", and are supposed to be moved to the extra
packages - they "survived" in ure which gives us this mess.)

> libreoffice has been upgraded to the latest version

If you mean the actual "libreoffice" package. That has no contents and
is empty and it doesn't force any version except for libreoffice-core
(which I don't remember the rationale for, but there must have been
some). So it can usually be ignored ;-)

> the dist-upgrade won't work until the four packages are installed,
> which won't happen because they conflict with ure... which is required
> by most of the libreoffice suite :-)

True... :-)

Regards,

Rene
> 

Bug#939581: firefox: problem seems to be solved with 69.0.2-1

[Sanjoy Mahajan]

I'm now using firefox 69.0.2-1 (amd64), and the problem seems to have
solved itself (or maybe Mozilla noticed and fixed it?).  That is, the
print dialog now selects (by highlighting in blue) my CUPS default
printer as its default printer.

-Sanjoy

Bug#948077: possible licensing issues

[Jelmer Vernooij]

Package: php-smbclient
Severity: serious
Usertags: license-violation

php-smbclient links against both libsmbclient (which is GPLv3) and php
(licensed under the PHP3.01 license).

According to both the FSF
(https://www.gnu.org/licenses/license-list.en.html#PHP-3.01) and the
guidance from the ftp-masters (https://ftp-master.debian.org/php-license.html)
these licenses are incompatible.

Bug#948041: impossible to update libbpf without updating the kernel

[Marco d'Itri]

On Jan 03, Sudip Mukherjee  wrote:

> Do we package libbpf from their github repo independent of the kernel
> update? Then we will need to remove the libbpf building bits from the
> Debian kernel source and create a separate package for libbpf.
This is what some of the upstream libbpf developers requested us to do.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#948076: possible licensing issues

[Jelmer Vernooij]

Package: php-smbclient
Severity: serious
Usertags: license-violation

php-smbclient links against both libsmbclient (which is GPLv3) and php
(licensed under the PHP3.01 license).

According to both the FSF
(https://www.gnu.org/licenses/license-list.en.html#PHP-3.01) and the
guidance from the ftp-masters (https://ftp-master.debian.org/php-license.html)
these licenses are incompatible.