Bug#573254: (no subject)

[Michael Lustfield]

This was reported against 1.3.1, however 1.4.2 is available in oldstable. Can
you confirm if this issue is still present? If so, would you also be able to
also check against the latest git revision (many bug fixes are not released)?

-- 
Michael Lustfield

Bug#943380: perl 'control' autopkgtest fails in testing because libextutils-parsexs-perl not in testing

[Steve Langasek]

Source: perl
Version: 5.30.0-7
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Dear maintainers,

The perl autopkgtest passes in unstable, but consistently fails in testing
and will continue to do so:

autopkgtest [06:39:56]: test control: prove debian/t/control.t
autopkgtest [06:39:56]: test control: [---

#   Failed test 'Breaks for libextutils-parsexs-perl in perl-modules-5.30 
matches Module::CoreList for ExtUtils::ParseXS'
#   at debian/t/control.t line 219.
#  got: '3.40'
# expected: '3.40'
# s/libextutils-parsexs-perl (<< 3.40)/libextutils-parsexs-perl (<< 3.40)/
# s/libextutils-parsexs-perl (= 3.40)/libextutils-parsexs-perl (= 3.40)/
# Looks like you failed 1 test of 452.
debian/t/control.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/452 subtests 
(less 113 skipped subtests: 338 okay)

  (https://ci.debian.net/packages/p/perl/testing/amd64/)

This test fails because debian/t/control.t relies on finding an existing
package in the archive in order to figure out how far to zero-extend the
version number that's provided by the upstream source data, before comparing
with the contents of debian/control.

However, libextutils-parsexs-perl is not in testing /precisely because/ only
an older version is available in the archive which is broken by current perl
(bug #912682).  The test still passes in unstable, but at some point it may
start to fail there also if the libextutils-parsexs-perl is removed from the
archive.

Regardless, this is an unreliable test because it depends on the state of
packages in the archive which are not (test,build,runtime) dependencies of
perl.  It looks like the release team may have overridden this failure once
in order to let perl 5.30.0-7 migrate into testing, but this really ought to
be resolved.

-- 
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#943379: Default to PRNG method?

[Martijn van Brummelen]

Hi Trent,
On 2019-10-24 06:46, Trent W. Buck wrote:

Package: nwipe
Version: 0.26-1
Severity: wishlist

As I understand it:

  1. the default nwipe method is DoD Short.

  2. the DoD Short method is specifically designed for the physical
structure of MFM drives, and
 doesn't really work on other kinds of drives.

  3. they stopped making MFM drives in, like, 1990.

  4. the PRNG method doesn't care about the physical structure of your
 drives, so unless you work for the US government, you should just
 always use PRNG.

If all of those things are true,
can we please change the nwipe default method to PRNG?



Sounds like a good idea for one of the next releases. Thanks!


The idea is to protect people who just run nwipe and
ASSUME the defaults are reasonably sensible.


Kind regards,
Martijn van Brummelen

Bug#943379: Default to PRNG method?

[Trent W. Buck]

Package: nwipe
Version: 0.26-1
Severity: wishlist

As I understand it:

  1. the default nwipe method is DoD Short.

  2. the DoD Short method is specifically designed for the physical structure 
of MFM drives, and
 doesn't really work on other kinds of drives.

  3. they stopped making MFM drives in, like, 1990.

  4. the PRNG method doesn't care about the physical structure of your
 drives, so unless you work for the US government, you should just
 always use PRNG.

If all of those things are true,
can we please change the nwipe default method to PRNG?

The idea is to protect people who just run nwipe and
ASSUME the defaults are reasonably sensible.

Bug#943378: RM: bcfg2 -- RoQA; py2-only; RC buggy; orphaned since ~2 years; no upstream release in ~4 years; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#943377: binutils-mingw-w64 FTCBFS: confuses build vs. host

[Helmut Grohne]

Source: binutils-mingw-w64
Version: 8.5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

binutils-mingw-w64 fails to cross build from source because it confuses
build architecture and host architecture in the ./configure invocation.
Please refer to man dpkg-architecture for a definition of these terms.
In the mean time, please consider applying the attached patch.

Helmut
diff --minimal -Nru binutils-mingw-w64-8.5/debian/changelog 
binutils-mingw-w64-8.5+nmu1/debian/changelog
--- binutils-mingw-w64-8.5/debian/changelog 2019-10-10 13:59:05.0 
+0200
+++ binutils-mingw-w64-8.5+nmu1/debian/changelog2019-10-24 
06:03:50.0 +0200
@@ -1,3 +1,10 @@
+binutils-mingw-w64 (8.5+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 24 Oct 2019 06:03:50 +0200
+
 binutils-mingw-w64 (8.5) unstable; urgency=medium
 
   * Correctly disable silent rules.
diff --minimal -Nru binutils-mingw-w64-8.5/debian/rules 
binutils-mingw-w64-8.5+nmu1/debian/rules
--- binutils-mingw-w64-8.5/debian/rules 2019-08-20 13:43:41.0 +0200
+++ binutils-mingw-w64-8.5+nmu1/debian/rules2019-10-24 06:03:49.0 
+0200
@@ -77,7 +77,7 @@
 override_dh_auto_configure:
set -e; \
for target in $(targets); do \
-   mkdir -p $(build_dir)/$$target && cd $(build_dir)/$$target && 
$(upstream_dir)/configure --build=$(DEB_HOST_GNU_TYPE) --prefix=/usr 
--disable-silent-rules --libdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) 
--libexecdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) --disable-maintainer-mode 
--disable-dependency-tracking --disable-multilib --enable-lto --enable-plugins 
--enable-deterministic-archives --with-system-zlib --target=$$target 
--disable-werror; \
+   mkdir -p $(build_dir)/$$target && cd $(build_dir)/$$target && 
$(upstream_dir)/configure --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE) --prefix=/usr --disable-silent-rules 
--libdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) 
--libexecdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) --disable-maintainer-mode 
--disable-dependency-tracking --disable-multilib --enable-lto --enable-plugins 
--enable-deterministic-archives --with-system-zlib --target=$$target 
--disable-werror; \
done
 
 override_dh_auto_build-arch:

Bug#943376: dh_installman fails on compressed man pages

[Russ Allbery]

Package: debhelper
Version: 12.7
Severity: important

gnubg 1.06.002-2 no longer builds with the latest debhelper, producing the
following error message:

   dh_installman
dh_installman: mv debian/gnubg/usr/share/man/man6/makeweights.6.gz.dh-new 
debian/gnubg/usr/share/man/man6/makeweights.6: No such file or directory
dh_installman: mv debian/gnubg/usr/share/man/man6/bearoffdump.6.gz.dh-new 
debian/gnubg/usr/share/man/man6/bearoffdump.6: No such file or directory
dh_installman: mv debian/gnubg/usr/share/man/man6/makebearoff.6.gz.dh-new 
debian/gnubg/usr/share/man/man6/makebearoff.6: No such file or directory
dh_installman: mv debian/gnubg/usr/share/man/man6/gnubg.6.gz.dh-new 
debian/gnubg/usr/share/man/man6/gnubg.6: No such file or directory
dh_installman: mv debian/gnubg/usr/share/man/man6/makehyper.6.gz.dh-new 
debian/gnubg/usr/share/man/man6/makehyper.6: No such file or directory
dh_installman: Aborting due to earlier error

I strongly suspect that this is a bug introduced in 12.7 with the change
to use man-recode.  The slightly unusual thing about this package is that
the upstream make install logic installs the man pages compressed, so
they're already compressed when dh_installman finds them and it just tries
to convert the character set.  My guess is that the previous man command
used for this handles compressed man pages transparently, but man-recode
does not.

This no longer affects gnubg since I worked around it in debian/rules in
the new version I just uploaded, but I suspect this will make other packages
FTBFS.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.6.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-1
ii  file 1:5.37-5
ii  libdebhelper-perl12.6.1
ii  libdpkg-perl 1.19.7
ii  man-db   2.8.7-3
ii  perl 5.30.0-6
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#943300: xpra: Python2 removal in sid/bullseye

[Dmitry Smirnov]

On Thursday, 24 October 2019 1:19:48 PM AEDT Sandro Tosi wrote:
> > Are you sure this is not a false-positive??
> > Xpra is already fully converted to Python3 and I can't find any
> > references to Python2 whatsoever.
> 
> indeed, my script identified `python-gi-dev` as a python2 package

Ah, what a relief. :) I've thought I've missed something somewhere...

Thanks.

-- 
All the best,
 Dmitry Smirnov.

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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

Bug#943375: Fwd: Processed (with 1 error): forcibly merging 938623 939112

[Sandro Tosi]

Package: bugs.debian.org

as requested, reporting as a bug (ftr i dont see any of those 2 bugs
as archived on their webpages)

-- Forwarded message -
From: Debian Bug Tracking System 
Date: Wed, Oct 23, 2019 at 11:15 PM
Subject: Processed (with 1 error): forcibly merging 938623 939112
To: Sandro Tosi 
Cc: 


Processing commands for cont...@bugs.debian.org:

> forcemerge 938623 939112
Bug #938623 [src:tails-installer] tails-installer: Python2 removal in
sid/bullseye
Bug #939112 [src:tails-installer] tails-installer: Python2 removal in
sid/bullseye -- drop python-distutils-extra build dependency
Failed to forcibly merge 938623: Failure while trying to adjust bugs,
please report this as a bug: Not altering archived bugs; see
unarchive..
 at /usr/local/lib/site_perl/Debbugs/Control.pm line 2133.

> thanks
Stopping processing here.

Please contact me if you need assistance.
--
938623: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938623
939112: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

Ansgar  writes:

>> +In the case of Git, the value must have the following syntax::
>> +
>> + [ " -b "  ] [ "["  "]" ]

> That should be " [" (including a leading space).

Yup, indeed, thanks!

> I suggest something like "If  is not specified, it defaults to `.`
> (or `debian`; see below)".

It's ``.`` (just now verified with the GHC repository).

Revised patch:

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 60edc82..c8f7f78 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -973,11 +973,33 @@ repository where the Debian source package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ " ["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it specifies the relative path to the top of the packaging
+tree (the parent directory of the ``debian`` directory).  If no path
+is specified, it defaults to ``.`` (the top level of the indicated
+repository and branch).
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multple version control

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

Bug#943374: dgit push-source fails and loses a package version number without retries

[Russ Allbery]

Package: dgit
Version: 9.9
Severity: normal

This was unpleasant:

wanderer:~/dvl/debian/gnubg$ dgit --gbp push-source
Format `3.0 (quilt)', need to check/update patch stack
canonical suite name for unstable is sid
gzip: warning: GZIP environment variable is deprecated; use an alias or script
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
dgit view: found cached (commit id a9bc802bb3fcc29b3250bcd79d06861cd1136a3c)
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building gnubg using existing ./gnubg_1.06.002.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building gnubg in gnubg_1.06.002-3.debian.tar.xz
dpkg-source: info: building gnubg in gnubg_1.06.002-3.dsc
changelog will contain changes since 1.06.002-2
dpkg-genchanges: info: not including original source code in upload
Warning: Permanently added the ED25519 host key for IP address '82.195.75.78' 
to the list of known hosts.
last upload to archive: specified git info (debian)
warning: ignoring broken ref refs/remotes/origin/HEAD
warning: ignoring broken ref refs/remotes/origin/HEAD
using existing gnubg_1.06.002.orig.tar.gz
warning: ignoring broken ref refs/remotes/origin/HEAD
warning: ignoring broken ref refs/remotes/origin/HEAD
gzip: warning: GZIP environment variable is deprecated; use an alias or script
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
dgit view: found cached (commit id a9bc802bb3fcc29b3250bcd79d06861cd1136a3c)
Checking that HEAD includes all changes in archive...
Declaring that HEAD includes all changes in 1.06.002-2...
Made pseudo-merge of 1.06.002-2 into dgit view.
warning: ignoring broken ref refs/remotes/origin/HEAD
checking that gnubg_1.06.002-3.dsc corresponds to HEAD
dpkg-source: warning: extracting unsigned source package 
(/home/eagle/dvl/debian/gnubg/../gnubg_1.06.002-3.dsc)
dpkg-source: info: extracting gnubg in gnubg-1.06.002
dpkg-source: info: unpacking gnubg_1.06.002.orig.tar.gz
dpkg-source: info: unpacking gnubg_1.06.002-3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 
0001-Support-finding-databases-in-var-as-well-as-usr.patch
dpkg-source: info: applying 0002-Expand-size-of-buffers-for-eval-messages.patch
../gnubg_1.06.002-3_source.changes already has appropriate .orig(s) (if any)
gpg: Signature made Wed 23 Oct 2019 05:24:46 PM PDT
gpg:using RSA key D73934B49674CF5CCD9AC2787D80315C5736DE75
gpg: Good signature from "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: Signature made Wed 23 Oct 2019 05:24:56 PM PDT
gpg:using RSA key D73934B49674CF5CCD9AC2787D80315C5736DE75
gpg: Good signature from "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
ssh: Could not resolve hostname push.dgit.debian.org: Temporary failure in name 
resolution
dgit: failed command: ssh 'd...@push.dgit.debian.org' ': dgit debian git-check 
gnubg ; set -e; cd /dgit/debian/repos; if test -d gnubg.git; then echo 1; else 
echo 0; fi'

dgit: error: subprocess failed with error exit status 255
! Push failed, while updating the remote git repository - see messages above.
! If you want to try again, you should use a new version number.

The network from which I was trying to do dgit push-source had 20% packet
loss.  If the DNS query had been retried, it probably would have worked.
What I ideally would have liked would be for dgit to pause and prompt me
whether to retry the command or to fail.

In general, this bug is to request that all dgit commands that may fail
transiently after dgit has committed to consuming a version number be
wrapped in something that will prompt whether I want to abort or retry the
command if the command fails.  That will allow me to take steps to fix the
local network, wait for a period of packet loss to pass, retry repeatedly,
etc., rather than having to change the source package and rebuild and then
upload again and hope the same thing doesn't happen.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 dgit depends on:
ii  apt1.8.4
ii  ca-certificates20190110
ii  coreutils  8.30-3+b1
ii  curl   7.66.0-1
ii  

Bug#942064: profphd: autopkgtest failure

[Steve Langasek]

Control: severity -1 grave

Looking at this autopkgtest failure as part of the perl 5.30 transition in
Ubuntu, I see that the prof command as a whole is broken by this obsolete
syntax.

$ prof --help
Can't exec "pp_popcon_cnt": No such file or directory at 
/usr/share/profphd/prof/prof.pl line 15.
The Rost Lab recommends you install the pp-popularity-contest package that 
provides pp_popcon_cnt:

sudo apt-get install pp-popularity-contest
Assigning non-zero to $[ is no longer possible at 
/usr/share/profphd/prof/prof.pl line 139.
$

An autopkgtest regression is already a serious bug that blocks testing
propagation in Debian, and in this case the bug appears to be that the core
functionality of this package is completely unavailable with new perl.  So
I'm raising the severity to 'grave'.

-- 
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#938011: python-pbr: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:43:56 + Matthias Klose  wrote:
> Package: src:python-pbr
> Version: 5.1.3-4
> 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

python-pbr has still plenty of rdeps in unstable:

 apt rdepends python-pbr
python-pbr
Reverse Depends:
 Depends: python-mock (>= 1.3)
 Depends: python-mock (>= 1.3)
 Depends: python-testresources (>= 1.3)
 Depends: python-testtools
 Depends: python-testscenarios
 Depends: python-os-refresh-config (>= 0.6)
 Depends: python-os-apply-config (>= 0.6)
 Depends: python-mox3 (>= 2.0.0)
 Depends: python-fixtures (>= 0.11)

i think the best course of action is to restore it until all of them
have been dropped.

Bug#943373: linux-image-4.19.0-5-amd64: file system corruption in virtual machines

[Nick]

Package: src:linux
Version: 4.19.37-5+deb10u1

Dear Maintainer,

   * What led up to the situation?

   The upgrade of a Xen host from Stretch to Buster.

   * What was the outcome of this action?
   After the upgrade from Stretch to Buster of the host (dom0), several domUs 
developed
   file system errors leading to file system corruption, causing the domUs to 
remount in read-only mode.

   It should be noted that Buster has Xen 4.11, allowing PHV(v2) mode, while 
Stretch has Xen 4.8,
   not allowing that mode. It was decided to switch supported Debian Linux 
domUs from PV mode
   to PVH mode after the upgrade. Xen PVH mode requires at least a Linux 4.11 
domU kernel.
   This requirement was satisfied by the stretch-backports 
linux-image-4.19.0-0.bpo.5-amd64 kernel.
   The domUs were configured to use drbd on lvm2 storage on an HP Smart Array 
P410i controller using the
   'hpsa' driver.
   The domUs were configured with a swap file.
   The domUs were started with the default XEN PV(H) configuration using a 
kernel provided by the hypervisor, e.g.:
   type = 'pvh'
   kernel  = '/boot/vmlinuz-4.19.0-0.bpo.5-amd64'
   ramdisk = '/boot/initrd.img-4.19.0-0.bpo.5-amd64'
   extra   = 'elevator=noop noresume'
   root= '/dev/xvda2 ro'
   disk= 'drbd:volume,xvda2,w'

   The file system corruption developed in a matter of days after starting the 
domUs in PVH mode.
   Output of /sys/block/drbd[n]/queue/scheduler (dom0): none
   Output of /sys/module/scsi_mod/parameters/use_blk_mq (dom0): Y
   The issue occurred only in Stretch domUs that were using the 
stretch-backports
   linux-image-4.19.0-0.bpo.5-amd64 kernel (as opposed to the standard stretch 
4.9 kernel)
   and only in PVH mode.
   No information specific to the issue was found in either the dom0 or domU 
log files nor the dom0 kernel log.
   Information from the domU kernel log (dmesg) was not preserved.

   * What outcome did you expect instead?

   The expected outcome had been that after upgrading the Stretch host
   to Buster, the domUs would run without issues, as before.

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

   After reverting to the 4.9 kernel and PV mode on the domUs, the issue did 
not reoccur on the same (Buster)
   upgraded machine. The issue did not occur again in those domUs, even those 
configured with a swap file.
   As an additional precaution some domUs were reconfigured without a swap 
file, using a swap partition instead.

   The configuration with drbd on lvm2 volumes was maintained, as it had been 
in use without issue for a number of years
   on this machine and similar machines.

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19)

** Command line:
placeholder root=/dev/mapper/host-vg-root ro console=tty0 
console=ttyS1,115200n8 quiet

** Not tainted

** Model information
sys_vendor: HP
product_name: ProLiant DL360 G7
product_version:
chassis_vendor: HP
chassis_version:
bios_vendor: HP
bios_version: P68

** PCI devices:
05:00.0 RAID bus controller [0104]: Hewlett-Packard Company Smart Array G6 
controllers [103c:323a] (rev 01)
Subsystem: Hewlett-Packard Company Smart Array P410i [103c:3245]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: hpsa
Kernel modules: hpsa

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

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

Nick

Bug#943300: xpra: Python2 removal in sid/bullseye

[Sandro Tosi]

> Are you sure this is not a false-positive??
> Xpra is already fully converted to Python3 and I can't find any references to
> Python2 whatsoever.

indeed, my script identified `python-gi-dev` as a python2 package

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

Bug#841238: acpidump: "turbostat" binary silently dropped?

[Al Stone]

Package: acpica-tools
Followup-For: Bug #841238

I am closing this bug since turbostat has been moved to a
different package.  Please install linux-cpupower to install
turbostat.

Bug#941141: codeblocks: Should codeblocks be removed from Debian?

[Olly Betts]

On Wed, Sep 25, 2019 at 12:08:36PM -0400, Scott Talbert wrote:
> I think it's time to remove the codeblocks package:
> 
> * last maintainer upload was over 3 years ago
> * NMU has been unacknowledged for almost 2 years
> * codeblocks is a major release behind upstream
> * There are multiple open bug reports about frequent crashes
> * codeblocks has only one reverse dependency (checked with
>   reverse-depends), a Recommends by education-development
> * The wxWidgets maintainer had to NMU the package during the last
>   wxWidgets transition
> 
> If there are no objections within two weeks, I'll file a bug to remove
> the recommends from education-development and turn this into an RM bug.

It's now been over 4 weeks with no objections.

The testing autoremoval mechanism has since removed codeblocks from
testing.

The wxwidgets3.0-gtk3 transition is almost complete and I'm estimating
we'll be ready to drop the GTK2 flavoured build of wxWidgets by the
end of this month.

I suggest once that happens we should proceed with requesting removal
of codeblocks if we've still had no objections.

I've explicitly Cc-ed the maintainer and active uploader on this message
in case there's been an email delivery problem to them with emails from
the BTS.  This package seems to have an active upstream and a user base
in Debian so I'd much rather see it return to a usable state than remove
it.

Cheers,
Olly

Bug#933266: nettle 3.5.1

[Daniel Kahn Gillmor]

On Wed 2019-10-23 20:27:32 +0200, Niels Möller wrote:
> Daniel Kahn Gillmor  writes:
>
>> any chance that we can get 3.5.1+really3.5.1 into unstable soon?  if
>> not, can you tell me what might be blocking it?
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938959
>
> (I don't know if the requested transition bug exists yet).

thanks for the pointer!

the transition bug appears to be:

   https://bugs.debian.org/941150

The last message there is from pochu, saying "Other than that things are
looking good here, so please go ahead."

Magnus, are you willing to go ahead to move 3.5.1 into unstable?

Thanks,

--dkg


signature.asc
Description: PGP signature

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Daniel Kahn Gillmor]

On Wed 2019-10-23 16:39:24 +0100, Steve McIntyre wrote:
> On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
>> - writing MD5sum in a separate file only used by debian-cd (if present,
>>   otherwise debian-cd should fall back to using Packages), or

Sounds like this is the only option available given the constraints of
deployed systems in the field.

What parts of debian's internal machinery need to be updated to do such
a thing?

> I've started a local branch to update jigdo and jigit/libjte to use
> sha256 some time ago, but -ENOTIME.

Bummer, and i feel for you.

Perhaps we should officially EOL jigdo now, if no one has time to work
on it.

Obviously, we'd continue supporting deployed legacy systems and give
them a chance (one release cycle?) to switch to something that is
actually maintained, but it is doing them no favors to pretend that a
system they're relying on is getting maintenance when no one has time to
work on it.

> As mentioned in IRC yesterday, we will also need some time to update
> clients in the field to be able to upgrade safely. That includes
> Windows binaries (yay!)...

The time to update (or deprecate) deployed clients that depend on md5
for object integrity was something like 8 years ago when RFC 6151 was
published :(

 --dkg


signature.asc
Description: PGP signature

Bug#943372: Can not active scim after Debian testing upgrade on 10 Oct 2019

[gulfstream]

Package: scim
Version: 1.4.18-2.1
Severity: grave


I upgrade my Debian testing just on 10 Oct 2019, and I found that the scim can 
not be used. When I press ctrl+Space, the Chinese input UI can not be actived.

Hope this problem can be resolve soon.


Best regards,
Gulfstream



-- Package-specific info:
Related packages:
ii  libscim8v5:amd64  1.4.18-2.1   amd64library for SCIM 
platform
ii  scim  1.4.18-2.1   amd64smart common input 
method platform
ii  scim-gtk-immodule:amd64   1.4.18-2.1   amd64GTK+ input method 
module, with SCIM as the input backend
ii  scim-im-agent 1.4.18-2.1   amd64IM agent for SCIM 
platform
ii  scim-modules-socket:amd64 1.4.18-2.1   amd64socket modules for SCIM 
platform
ii  scim-pinyin   0.5.92-4 amd64smart pinyin IM engine 
for SCIM platform

Related environment variables:
$XMODIFIERS=@im=ibus
$GTK_IM_MODULE=
$QT_IM_MODULE=ibus

Installed SCIM components:

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN.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 scim depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.1-1
ii  libgtk-3-0   3.24.12-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libscim8v5   1.4.18-2.1
ii  libstdc++6   9.2.1-8
ii  libx11-6 2:1.6.8-1

Versions of packages scim recommends:
ii  im-config [im-switch]  0.43-1
ii  scim-gtk-immodule [scim-gtk-immodule]  1.4.18-2.1
ii  scim-im-agent  1.4.18-2.1

Versions of packages scim suggests:
pn  scim-anthy  
pn  scim-canna  
pn  scim-chewing
pn  scim-hangul 
pn  scim-m17n   
ii  scim-pinyin 0.5.92-4
pn  scim-prime  
pn  scim-skk
pn  scim-tables-additional  
pn  scim-tables-ja  
pn  scim-tables-ko  
pn  scim-tables-zh  
pn  scim-thai   
pn  scim-uim

-- debconf-show failed

Bug#941959: python3-pyqt5.qtwebengine: QWebEngineUrlScheme seems not to be exported

[Norbert Preining]

found 941959 5.12.1-4
reopen 941959
thanks

Hi Dimtry,

thanks for your work on the Qt transition, looks pretty fine as far as I
see.

On Tue, 08 Oct 2019, Dmitry Shachnev wrote:
> Hi Norbert!
> 
> On Tue, Oct 08, 2019 at 01:23:44PM +0900, Norbert Preining wrote:
> > When I try to import QWebEngineUrlScheme I get an error
> > $ python3
> > >>> from PyQt5.QtWebEngineCore import QtWebEngineUrlScheme
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > ImportError: cannot import name 'QtWebEngineUrlScheme' from 
> > 'PyQt5.QtWebEngineCore' 
> > (/usr/lib/python3/dist-packages/PyQt5/QtWebEngineCore.cpython-37m-x86_64-linux-gnu.so)
> >
> > But it seems it should be there since there is also
> > /usr/share/sip/PyQt5/QtWebEngineCore/qwebengineurlscheme.sip
> 
> That class is only available since Qt 5.12, however right now we ship
> Qt 5.11 in sid. So you need to wait until Qt is updated (see #941093).

Now that we hvae Qt 5.12 and new versions of pyqt in sid, it seems that
it still fails to import :-(

from PyQt5.QtWebEngineCore import QWebEngineUrlScheme
ImportError: cannot import name 'QWebEngineUrlScheme' from 
'PyQt5.QtWebEngineCore' 
(/usr/lib/python3/dist-packages/PyQt5/QtWebEngineCore.cpython-37m-x86_64-linux-gnu.so)


Do I miss something here?

All the best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)

[Thorsten Glaser]

Hello Sami and Karel,

you were involved in changing script(1) to use signalfd, which
is apparently Linux-specific but util-linux also is used, at
least in Debian, on other kernels, such as the FreeBSD and Hurd
ones (FSVO “kernel”, for the latter).

I need script(1) available, to get a controlling tty inside a
headless build for example (and because it’s a very basic part
of a Unix system anyway).

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807071
for the full story and help implement a mode in which script(1)
will function on nōn-Linux again (incidentally the code comes from
FreeBSD in the first place).

Thanks in advance,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#937480: pymia: Python2 removal in sid/bullseye

[Sandro Tosi]

> NMU is fine with me, as nearly all the packages in debian-med the
> package is lowNMU, so no delay is necessary.

thanks! I've just reschedule it for acceptance now

> Maybe next time consider to send the diff as merge request on salsa, it
> makes it easier to apply ;)

that's true, but i've been touching so many packages lately, that
trying to follow every team workflow would be tough (also the NMU
gives a bit more of "pressure" on the maintainer if they prefer to
upload the pkg themselves while still getting the bug fixed in case of
maintainer inactivity, which would be a blocker in case of a MR).

Thanks!

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

Bug#943371: helm-org-autoloads.el: easy-menu-add-item errors out

[Aaron M. Ucko]

Package: elpa-helm-org
Version: 1.0-2
Severity: important

At least on my system, helm-org-autoloads.el's call to
easy-menu-add-item errors out per the below backtrace.  When this
error occurs, there is not yet a Tools/Helm submenu, perhaps because
elpa-helm's own call to easy-menu-add-item is in a separate
helm-easymenu.el.

Could you please take a look?

Thanks!



Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
  define-key(nil [menu-bar Tools Helm] ("Helm" keymap "Helm"))
  easy-menu-get-map(nil ("Tools" "Helm") nil)
  easy-menu-add-item(nil ("Tools" "Helm") ("Org" ["Org headlines in org agenda 
files" helm-org-agenda-files-headings t] ["Org headlines in buffer" 
helm-org-in-buffer-headings t]) "Elpa")
  eval-buffer(# nil 
"/usr/share/emacs/site-lisp/elpa/helm-org-1.0/helm-org-autoloads.el" nil t)  ; 
Reading at buffer position 491
  
load-with-code-conversion("/usr/share/emacs/site-lisp/elpa/helm-org-1.0/helm-org-autoloads.el"
 "/usr/share/emacs/site-lisp/elpa/helm-org-1.0/helm-org-autoloads.el" nil t)
  load("/usr/share/emacs/site-lisp/elpa/helm-org-1.0/helm-org-autoloads" nil t)
  package--activate-autoloads-and-load-path(#s(package-desc :name helm-org 
:version (1 0) :summary "Helm for org headlines and keywords completion" :reqs 
((helm (3 3))) :kind nil :archive nil :dir 
"/usr/share/emacs/site-lisp/elpa/helm-org-1.0" :extras ((:url . 
"https://github.com/emacs-helm/helm-org;)) :signed nil))
  package--load-files-for-activation(#s(package-desc :name helm-org :version (1 
0) :summary "Helm for org headlines and keywords completion" :reqs ((helm (3 
3))) :kind nil :archive nil :dir "/usr/share/emacs/site-lisp/elpa/helm-org-1.0" 
:extras ((:url . "https://github.com/emacs-helm/helm-org;)) :signed nil) nil)
  package-activate-1(#s(package-desc :name helm-org :version (1 0) :summary 
"Helm for org headlines and keywords completion" :reqs ((helm (3 3))) :kind nil 
:archive nil :dir "/usr/share/emacs/site-lisp/elpa/helm-org-1.0" :extras ((:url 
. "https://github.com/emacs-helm/helm-org;)) :signed nil) nil deps)
  package-activate(helm-org)
  package-initialize()
  eval-buffer(# nil "/home/amu/.emacs" nil t)  ; Reading at 
buffer position 275
  load-with-code-conversion("/home/amu/.emacs" "/home/amu/.emacs" t t)
  load("~/.emacs" t t)
  #f(compiled-function () #)()
  command-line()
  normal-top-level()

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 elpa-helm-org depends on:
ii  dh-elpa-helper  2.0.2
ii  elpa-helm   3.5.0-2
ii  emacsen-common  3.0.4

Versions of packages elpa-helm-org recommends:
ii  emacs  1:26.1+1-4
ii  emacs-gtk [emacs]  1:26.1+1-4

elpa-helm-org suggests no packages.

-- no debconf information

Bug#943370: linux-image-amd64: Elantech touchpad not working (elan_i2c)

[Jehú Herrera]

Package: linux-image-amd64
Severity: normal
Tags: newcomer

Dear Maintainer,


   * What led up to the situation?
Elan_i2c driver not working
"elan_i2c 6-0015: failed to get resolution: -71"
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Ussing kernel parameter psmouse.elantech_smbus=0 works
   * What was the outcome of this action?
The touchpad worked correctly
   * What outcome did you expect instead?
Nothing



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: sysvinit (via /sbin/init)

Versions of packages linux-image-amd64 depends on:
pn  linux-image-4.19.0-6-amd64  

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.
dmesg | grep elan

sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: assuming hardware 
version 4 (with firmware version 0x5e0f01)
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Synaptics 
capabilities query result 0x70, 0x16, 0x0a.
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Elan sample query 
result 0b, 01, a7
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Trying to set up 
SMBus access
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: SMbus companion 
is not ready yet
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: assuming hardware 
version 4 (with firmware version 0x5e0f01)
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Synaptics 
capabilities query result 0x70, 0x16, 0x0a.
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Elan sample query 
result 0b, 01, a7
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Trying to set up 
SMBus access
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: 9-0015 supply vcc not 
found, using dummy regulator
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-6
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-71
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-71
sep 08 15:03:00 hp-notebook kernel: elan_i2c: probe of 9-0015 failed with error 
-71
dmesg | grep elan

sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: assuming hardware 
version 4 (with firmware version 0x5e0f01)
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Synaptics 
capabilities query result 0x70, 0x16, 0x0a.
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Elan sample query 
result 0b, 01, a7
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: Trying to set up 
SMBus access
sep 08 10:02:39 hp-notebook kernel: psmouse serio1: elantech: SMbus companion 
is not ready yet
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: assuming hardware 
version 4 (with firmware version 0x5e0f01)
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Synaptics 
capabilities query result 0x70, 0x16, 0x0a.
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Elan sample query 
result 0b, 01, a7
sep 08 15:03:00 hp-notebook kernel: psmouse serio1: elantech: Trying to set up 
SMBus access
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: 9-0015 supply vcc not 
found, using dummy regulator
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-6
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-71
sep 08 15:03:00 hp-notebook kernel: elan_i2c 9-0015: failed to get product ID: 
-71
sep 08 15:03:00 hp-notebook kernel: elan_i2c: probe of 9-0015 failed with error 
-71

Bug#679592: swig: missing depends on pike7.6 but refers on rules

[Olly Betts]

Upstream release SWIG 4.0.0 disabled support for Pike:

2019-02-04: wsfulton
[Pike] #1447 Pike has been disabled as a target language in 
SWIG as part of a
clean up to remove target languages that have been 
neglected/not functional.

And now:

$ swig -pike
Target language option -pike (Pike) is no longer supported.

So this bug can be closed once upstream version 4.0.x is packaged.

Cheers,
Olly

Bug#790102: marked as forwarded (subversion fails to build with -Wdate-time in CPPFLAGS)

[Olly Betts]

On Fri, Aug 28, 2015 at 10:27:05PM +, Debian Bug Tracking System wrote:
> I just created a pull request which just adds -Wdate-time as an accepted
> but ignored command line option:
> 
> https://github.com/swig/swig/pull/511

The discussion upstream concluded that SWIG shouldn't be expected to
accept arbitrary CPPFLAGS.  You (Torsten) concurred and closed the
PR.

So I think this Debian bug should also be closed.

Presumably the two affected packages were fixed long ago now -
tracker.d.o shows that both subversion and unbound have different
versions in stable and testing so they clearly can't FTBFS still.

Cheers,
Olly

Bug#943369: numpy: test failures do not fail build

[Michael Hudson-Doyle]

Source: numpy
Version: 1:1.17.2-1
Severity: important
Tags: patch

Dear Maintainer,

Dear Maintainer,

The tests are run during build like this:

python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)"

but numpy.test returns a boolean True/False to indicate whether it
passed or failed, not raising an exception or anything else that would
cause python to exit with a non-zero code. Simple, untested, patch
attached.

Cheers,
mwh

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

Kernel: Linux 5.3.0-18-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
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
>From f7405ec04b68a80cba5d0bc83188a6262e8ada38 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle 
Date: Thu, 24 Oct 2019 12:46:38 +1300
Subject: [PATCH] make sure failing tests fail the build

---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index b4381f5..2c50338 100755
--- a/debian/rules
+++ b/debian/rules
@@ -116,9 +116,9 @@ ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
set -e; for v in $(PY3VERS) ; do \
cd debian ; \
echo "-- running tests for "$$v" plain --" ; \
-   python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)" 
; \
+   python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; 
sys.exit(numpy.test(verbose=5))" ; \
echo "-- running tests for "$$v" debug --" ; \
-   python$$v-dbg -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)" 
; \
+   python$$v-dbg -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; sys.exit(not 
numpy.test(verbose=5))" ; \
cd .. ; \
done
 endif
-- 
2.20.1

Bug#943368: python-numpy: test failures do not fail build

[Michael Hudson-Doyle]

Source: python-numpy
Version: 1:1.16.2-1ubuntu1
Severity: important
Tags: patch

Dear Maintainer,

The tests are run during build like this:

python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)"

but numpy.test returns a boolean True/False to indicate whether it
passed or failed, not raising an exception or anything else that would
cause python to exit with a non-zero code. Simple, untested, patch
attached.

Cheers,
mwh

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

Kernel: Linux 5.3.0-18-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
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
>From f7405ec04b68a80cba5d0bc83188a6262e8ada38 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle 
Date: Thu, 24 Oct 2019 12:46:38 +1300
Subject: [PATCH] make sure failing tests fail the build

---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index b4381f5..2c50338 100755
--- a/debian/rules
+++ b/debian/rules
@@ -116,9 +116,9 @@ ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
set -e; for v in $(PY3VERS) ; do \
cd debian ; \
echo "-- running tests for "$$v" plain --" ; \
-   python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)" 
; \
+   python$$v -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; 
sys.exit(numpy.test(verbose=5))" ; \
echo "-- running tests for "$$v" debug --" ; \
-   python$$v-dbg -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; numpy.test(verbose=5)" 
; \
+   python$$v-dbg -c "import sys ; sys.path.insert(0, 
'./tmp/usr/lib/python3/dist-packages/') ; import numpy; sys.exit(not 
numpy.test(verbose=5))" ; \
cd .. ; \
done
 endif
-- 
2.20.1

Bug#943367: light-locker shows only the cursor on a black screen after unlocking

[Javier Ayres]

Package: light-locker
Version: 1.8.0-3
Severity: important

Dear Maintainer,

I am sporadically running into an issue where light-locker shows the password
prompt normally, but after unlocking I'm left only with a black screen.
I can see and move the cursor and it sometimes changes from an arrow to a hand
(as if it's responding to what's drawn under the black screen), but I
can't do much more. The only solution I've found is going to a TTY (with
CTRL+ALT+F*) and restarting lightdm.

It happens almost every time when unlocking after suspending/hibernating, but
I've also seen it after a normal lock.



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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-2
ii  libdbus-glib-1-2 0.110-4
ii  libglib2.0-0 2.62.1-1
ii  libgtk-3-0   3.24.12-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libsystemd0  242-7
ii  libx11-6 2:1.6.8-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-6

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#943289: tpm2-tools: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Control: forwarded -1 https://github.com/tpm2-software/tpm2-tools/issues/1708

On Wed, Oct 23, 2019 at 02:33:34AM +, mo...@debian.org wrote:
> Source: tpm2-tools
> Version: 3.1.3-2
> 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
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.
[snip]

Add forwarded URL since upstream is aware of the issue.
Williamcroberts writes "I was just testing this and found the same
thing. We already have python3 support" 
(https://github.com/tpm2-software/tpm2-tools/issues/1708#issuecomment-525815007).

I believe the correct course of action is for the Debian tpm2-tools
maintainer to update to a stable 4.x release asap.  If Python 3
support is not satisfactory in that release than upstream can be
contacted, ideally with a friendly "Python 2 will be removed from
Debian on $date" note.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#922586: FTBFS against opencv 4.0.1 (exp)

[Gianfranco Costamagna]

Hello Jose,

On Tue, 19 Feb 2019 00:32:16 +0100 =?UTF-8?Q?Jos=C3=A9_Luis_Blanco=2DClaraco?= 
 wrote:
> Thanks!
> 
> This problem is already solved upstream in the forthcoming mrpt-2.0.0
> version. I'm marking this as "fixed-upstream" in the meanwhile.
> 
> Best,
> 
> On Mon, Feb 18, 2019 at 7:42 AM Mo Zhou  wrote:
> >
> > Source: mrpt
> > Version: 1.5.6-1
> > Severity: important
> >
> > headers have been moved to /usr/include/opencv4/opencv2/* since opencv4
> 

can you please followup with an upload?
the package is going to get kicked out from testing because of this bug soon...

thanks

G.
> 
> 
> -- 
> 
> /**
>  * Jose Luis Blanco-Claraco
>  * Universidad de Almer??a - Departamento de Ingenier??a
>  * [Homepage]( https://w3.ual.es/~jlblanco/ )
>  * [GH profile]( https://github.com/jlblancoc )
>  */
> 
> 

Bug#939297: breezy: Please provide git-remote-bzr program

[Jelmer Vernooij]

On Wed, Oct 23, 2019 at 06:41:11PM +0200, Sven Joachim wrote:
> On 2019-09-03 03:01 +0200, Guillem Jover wrote:
> 
> > Source: breezy
> > Source-Version: 3.0.1-3
> > Severity: wishlist
> >
> > I see upstream contains a git-remote-bzr program, but it's not
> > currently being installed(?). With the removal of the git-remote-bzr
> > binary package, and the transition away from bazaar (and the dummy
> > bzr-git which has stopped providing its own git-remote-bzr) it would
> > be really nice if breeze could ship its variant somewhere. My
> > preference would be to takeover the git-remote-bzr binary package
> > name so that we get a smooth transition (which AFAIR might cause no
> > trip via NEW processing?), and a less confusing package name than
> > the previous bzr-git.
> 
> The patch below creates such a git-remote-bzr package:
> 

> diff --git a/debian/control b/debian/control
> index 01ebb66..0f40571 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -114,3 +114,19 @@ Description: easy to use distributed version control 
> system (documentation)
>   and easily extendable.
>   .
>   This package provides the documentation.
> +
> +Package: git-remote-bzr
> +Architecture: all
> +Multi-Arch: foreign
> +Depends: git,
> + python3-breezy (<= ${source:Version}.1~),
> + python3-breezy (>= ${source:Version}),
> + ${misc:Depends},
> + ${python3:Depends}
> +Suggests: git-doc, brz
> +Replaces: bzr-git (<< 0.6.13+bzr1650+brz1~)
> +Breaks: bzr-git (<< 0.6.13+bzr1650+brz1~)
> +Description: bidirectional bridge between Git and Bazaar
> + This package provides the bzr remote helper, which allows Git to
> + read from and write to Bazaar repositories as though they were remote
> + Git repositories.
> diff --git a/debian/git-remote-bzr.install b/debian/git-remote-bzr.install
> new file mode 100644
> index 000..a7dc8c0
> --- /dev/null
> +++ b/debian/git-remote-bzr.install
> @@ -0,0 +1,4 @@
> +debian/python3-breezy/usr/bin/git-remote-bzrusr/bin
> +debian/python3-breezy/usr/bin/bzr-receive-packusr/bin
> +debian/python3-breezy/usr/bin/bzr-upload-packusr/bin
> +debian/python3-breezy/usr/man/man1/git-remote-bzr.1usr/share/man/man1

> 
> Unfortunately, at least with breezy 3.0.1 it does not actually work. :-(
> Here is what I got trying to clone a random repository:

I don't think I'd really want to ship it in its current form. It works
better in Breezy 3.1, but the performs is pretty terrible since it
processes each revision multiple times.

Jelmer


signature.asc
Description: PGP signature

Bug#896809: #896809: installation-reports: "Select a language" -> DE, but install EN

[Holger Wansing]

Ralf  (2018-04-24)
> I have selected German as the installation language. 
> However, the installation process will continue in English.
> The finished Debian installation is also in English.

Because of the used installation image - an SD-card image:
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/firmware.Lamobo_R1.img.gz
I suspect a localized installation is not supported, due to space limitations.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Ansgar]

> +In the case of Git, the value must have the following syntax::
> +
> + [ " -b "  ] [ "["  "]" ]

That should be " [" (including a leading space).

> +
> +where the portions enclosed in brackets are optional and the portions
> +enclosed in double quotes are literal strings.   indicates
> +the repository.  If the  stanza is present, it names a
> +branch in the indicated repository.  If no branch is specified, the
> +packaging should be on the default branch.  If the  stanza
> +is present, it must be a relative path naming a subdirectory in that
> +repository and branch.  If no path is specified, the ``debian``
> +directory containing the packaging is expected to be at the top level
> +of the indicated repository and branch.

I suggest something like "If  is not specified, it defaults to `.`
(or `debian`; see below)".

> +
> +For example::
> +
> +Vcs-Git: https://example.org/repo -b debian [p/package]
> +
> +indicates a subdirectory named ``p/package`` in the ``debian`` branch
> +of the repository at ``https://example.org/repo``.

I don't understand what  does from just reading this.  When
`p/package` is given, which one of `p/package/debian/control` and
`p/package/control` is supposed to be used?

Ansgar

Bug#942066: filezilla: FTBFS with GCC 9: error: #error You need to use a C++17 compiler.

[Gianfranco Costamagna]

control: fixed -1 3.45.1-1
control: close -1

thanks

G.
On Wed, 09 Oct 2019 21:42:17 +0200 Sven Joachim  wrote:
> Control: retitle -1 filezilla: FTBFS with libfilezilla 0.18.2
> 
> On 2019-10-09 21:06 +0200, Andreas Beckmann wrote:
> 
> > Package: filezilla
> > Version: 3.39.0-2
> > Severity: serious
> > Tags: sid bullseye
> > Justification: fails to build from source (but built successfully in the 
> > past)
> >
> > filezilla FTBFS in sid, probably related to the default compiler being
> > switched from GCC 8 to GCC 9:
> 
> Not really, I think.
> 
> > In file included from /usr/include/libfilezilla/libfilezilla.hpp:4,
> >  from ../../src/include/libfilezilla_engine.h:12,
> >  from ./filezilla.h:1,
> >  from backend.cpp:1:
> > /usr/include/libfilezilla/private/defs.hpp:10:4: error: #error You need to 
> > use a C++17 compiler. Try passing -std=c++17 as compiler flag.
> >10 |   #error You need to use a C++17 compiler. Try passing -std=c++17 
> > as compiler flag.
> >   |^
> 
> That's because libfilezilla is built with -std=c++17.  See #941193.
> 
> Cheers,
>Sven
> 
> 

Bug#855151: #855151: tasksel: should not be Priority: important

[Holger Wansing]

Cyril Brulebois  (2017-02-15):
> Ansgar Burchardt  (2017-02-14):
> > Package: tasksel
> > Version: 3.39
> > 
> > tasksel is currently at Priority: important and thus installed in every
> > installation, including chroots installed via debootstrap.  It doesn't
> > seem a useful package to install in chroots though.
> > 
> > It would be nice if d-i would install tasksel (and maybe remove it at
> > the end of the installation again?) so the priority of the tasksel and
> > tasksel-data packages could be downgraded.
> 
> I think that's indeed a fair topic for the buster release cycle.
> 
> 
> KiBi.

What about this topic?

Should we downgrade tasksel to something like optional now?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)

[Jan Volec]

Awesome, can confirm the 2.0.2+dfsg-6 version works for me again!


Best wishes,

Jan

> Hi Jan, Hi Andreas,
> > both contains the same file, namely 
> >   /usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk
> > and removing it from one of them would fix the issue.
> That is not a bug, but rather a feature that is solving previous bugs [1] and
> [2]
> The issue is that I copied some code from the Debian policy manual [3] and 
> that
> code was wrong:
> The given example is missing closing bracket. I should noticed it before, but
> for some obscure reason it is passing on my computer:if [ upgrade != "$1 || 
> dpkg
> --compare-versions "$2" lt 1.0-2; then
> I've checked it again and I've fixed it. Will upload soon.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823706
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898310
> [3] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html-- 
> Cheers,
> Abou Al Montacir

Bug#943366: please add an error for any (build) dependency or autopkg test dependency on python/python-dev

[Matthias Klose]

Package: lintian

bullseye will ship without the unversioned python binary and packages, details 
at https://lists.debian.org/debian-python/2019/10/msg00082.html.  While we aim 
for removing Python2 entirely, this is probably too ambitious, and we should at 
least remove the unversioned python packages.  Please could lintian generate 
errors messages for any (build) dependency or autopkg test dependency on 
python/python-dev. Maybe even look for python shebangs in binary packages and 
sources?

Bug#941194: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d

[Russ Allbery]

Seconded.  Super-minor punctuation nit below for whoever applies this
patch.

Ansgar  writes:

> ---
>  policy/ch-opersys.rst | 65 ---
>  1 file changed, 12 insertions(+), 53 deletions(-)

> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 1b63064..5a647fd 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts 
> executed by ``init``
>  at boot time and when the init state (or "runlevel") is changed (see
>  ``init(8)``).
>  
> -There are at least two different, yet functionally equivalent, ways of
> -handling these scripts. For the sake of simplicity, this document
> -describes only the symbolic link method. However, it must not be assumed
> -by maintainer scripts that this method is being used, and any automated
> -manipulation of the various runlevel behaviors by maintainer scripts
> -must be performed using ``update-rc.d`` as described below and not by
> -manually installing or removing symlinks. For information on the
> -implementation details of the other method, implemented in the
> -``file-rc`` package, please refer to the documentation of that package.
> -
> -These scripts are referenced by symbolic links in the ``/etc/rcn.d``
> -directories. When changing runlevels, ``init`` looks in the directory
> -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the
> -runlevel that is being changed to, or ``S`` for the boot-up scripts.
> -
> -The names of the links all have the form ``Smmscript`` or ``Kmmscript``
> -where mm is a two-digit number and script is the name of the script
> -(this should be the same as the name of the actual script in
> -``/etc/init.d``).
> -
> -When ``init`` changes runlevel first the targets of the links whose
> -names start with a ``K`` are executed, each with the single argument
> -``stop``, followed by the scripts prefixed with an ``S``, each with the
> -single argument ``start``. (The links are those in the ``/etc/rcn.d``
> -directory corresponding to the new runlevel.) The ``K`` links are
> -responsible for killing services and the ``S`` link for starting
> -services upon entering the runlevel.
> -
> -For example, if we are changing from runlevel 2 to runlevel 3, init will
> -first execute all of the ``K`` prefixed scripts it finds in
> -``/etc/rc3.d``, and then all of the ``S`` prefixed scripts in that
> -directory. The links starting with ``K`` will cause the referred-to file
> -to be executed with an argument of ``stop``, and the ``S`` links with an
> -argument of ``start``.
> -
> -The two-digit number mm is used to determine the order in which to run
> -the scripts: low-numbered links have their scripts run first. For
> -example, the ``K20`` scripts will be executed before the ``K30``
> -scripts. This is used when a certain service must be started before
> -another. For example, the name server ``bind`` might need to be started
> -before the news server ``inn`` so that ``inn`` can set up its access
> -lists. In this case, the script that starts ``bind`` would have a lower
> -number than the script that starts ``inn`` so that it runs first:
> -
> -::
> -
> -/etc/rc2.d/S17bind
> -/etc/rc2.d/S70inn
> -
> -The two runlevels 0 (halt) and 6 (reboot) are slightly different. In
> -these runlevels, the links with an ``S`` prefix are still called after
> -those with a ``K`` prefix, but they too are called with the single
> -argument ``stop``.
> +``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

...and in which order; see the

> +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 manage 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.
>  
>  .. _s-writing-init:
>  
> -- 
> 2.23.0

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

Bug#943365: Mark nasm-mozilla and nodejs-mozilla as unsupported

[Moritz Muehlenhoff]

Package: debian-security-support
Severity: wishlist

These packages are introduced in jessie and stretch as build dependencies
for Firefox/Thunderbird 68, but they are not meant to be used standalone
and are not covered by security support, debian-security-support should
flag them as such if installed.

Cheers,
Moritz

Bug#941194: initscripts: remove some implementation details

[Russ Allbery]

Ansgar  writes:
> Russ Allbery writes:

>> I'm hesitant to remove all discussion of run levels because package
>> maintainers are still responsible for choosing a run level at which to
>> start their service and providing that run level as an argument to
>> update-rc.d.

> No, maintainer scripts call `update-rc.d  defaults`.  There is no
> runlevel involved.  The runlevel is only in the LSB init script magic
> comment.  However those aren't explained anywhere in Policy, even though
> the dependency part was more important than the runlevel part (IMHO)...

Oh, I see, the runlevels are only relevant for the disable and enable
commands, which are never used by packages.

Objection removed entirely.  Thanks!

>> How about, rather than moving it to a footnote, rephrasing it as follows?
>>
>> Except when the package has been removed but not purged, as described
>> above, the ``/etc/init.d`` script should not decide whether or not to
>> start the daemon based on configuration settings (such as settings in
>> ``/etc/default``) or silently exit successfully when the daemon could
>> not be started.

> I think this part isn't that interesting:

>> This causes inconsistent and confusing behavior such
>> as ``service  start`` returning success but not starting the
>> service; services with a dependency on this service starting even
>> though the service isn’t running; and init system status commands
>> claiming that the service was started.

> (It's a rationale, Policy usually doesn't have those.)

The lack of rationales is a bug in Policy.  We should have rationales;
otherwise, years later, it's difficult or impossible to understand what
the motivation was for some requirement.  (See also Chesterton's fence.)

Ideally we'd have some better way of representing them so that you could
enable or disable them when reading Policy if you want just the facts, but
I don't want to leave them out when we have them even though they can be a
bit wordy to include.

>> If the ``/etc/init.d`` script
>> is invoked with the ``start`` or ``restart`` arguments and the service
>> could not or should not be started, it should produce an appropriate
>> error message and exit with a non-zero status.
>>
>> and then moving this whole paragraph into 9.3.2, probably as the
>> second-to-last paragraph?

> Besides that I believe it's fine.

> 9.3.2 still has other interesting parts that I want to change (such as
> suggesting editing /etc/init.d/ is a good way to disable
> services).  For the conffile-disliking person it also contains the
> admission that conffiles are so user-unfriendly on upgrades that there
> are conffiles for conffiles, i.e. /etc/default/* ;-)

Yeah, I think that making init scripts conffiles was, in retrospect, a
mistake, although an understandable one and hard to avoid due to the lack
of any other override mechanism.

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

Bug#943364: buster-pu: package python2.7/2.7.16-2+deb10u1

[Moritz Muehlenhoff]

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

This fixes a number of low severity issues which have popped up since
the initial Buster release. Debdiff below.

Cheers,
Moritz

diff -u python2.7-2.7.16/debian/changelog python2.7-2.7.16/debian/changelog
--- python2.7-2.7.16/debian/changelog
+++ python2.7-2.7.16/debian/changelog
@@ -1,3 +1,14 @@
+python2.7 (2.7.16-2+deb10u1) buster; urgency=medium
+
+  * CVE-2018-20852
+  * CVE-2019-10160
+  * CVE-2019-16056 (Closes: #940901)
+  * CVE-2019-16935
+  * CVE-2019-9740
+  * CVE-2019-9947
+
+ -- Moritz Mühlenhoff   Fri, 11 Oct 2019 00:02:15 +0200
+
 python2.7 (2.7.16-2) unstable; urgency=high
 
   [ Matthias Klose ]
diff -u python2.7-2.7.16/debian/patches/series.in 
python2.7-2.7.16/debian/patches/series.in
--- python2.7-2.7.16/debian/patches/series.in
+++ python2.7-2.7.16/debian/patches/series.in
@@ -75,0 +76,5 @@
+CVE-2018-20852.diff
+CVE-2019-10160.diff
+CVE-2019-16056.diff
+CVE-2019-16935.diff
+CVE-2019-9740_CVE-2019-9947.diff
only in patch2:
unchanged:
--- python2.7-2.7.16.orig/debian/patches/CVE-2018-20852.diff
+++ python2.7-2.7.16/debian/patches/CVE-2018-20852.diff
@@ -0,0 +1,93 @@
+Commit 979daae300916adb399ab5b51410b6ebd0888f13 from the 2.7 branch
+
+diff -Naur python2.7-2.7.16.orig/Lib/cookielib.py 
python2.7-2.7.16/Lib/cookielib.py
+--- python2.7-2.7.16.orig/Lib/cookielib.py 2019-03-02 19:17:42.0 
+0100
 python2.7-2.7.16/Lib/cookielib.py  2019-10-11 15:33:02.648671958 +0200
+@@ -1139,6 +1139,11 @@
+ req_host, erhn = eff_request_host(request)
+ domain = cookie.domain
+ 
++if domain and not domain.startswith("."):
++dotdomain = "." + domain
++else:
++dotdomain = domain
++
+ # strict check of non-domain cookies: Mozilla does this, MSIE5 doesn't
+ if (cookie.version == 0 and
+ (self.strict_ns_domain & self.DomainStrictNonDomain) and
+@@ -1151,7 +1156,7 @@
+ _debug("   effective request-host name %s does not domain-match "
+"RFC 2965 cookie domain %s", erhn, domain)
+ return False
+-if cookie.version == 0 and not ("."+erhn).endswith(domain):
++if cookie.version == 0 and not ("."+erhn).endswith(dotdomain):
+ _debug("   request-host %s does not match Netscape cookie domain "
+"%s", req_host, domain)
+ return False
+@@ -1165,7 +1170,11 @@
+ req_host = "."+req_host
+ if not erhn.startswith("."):
+ erhn = "."+erhn
+-if not (req_host.endswith(domain) or erhn.endswith(domain)):
++if domain and not domain.startswith("."):
++dotdomain = "." + domain
++else:
++dotdomain = domain
++if not (req_host.endswith(dotdomain) or erhn.endswith(dotdomain)):
+ #_debug("   request domain %s does not match cookie domain %s",
+ #   req_host, domain)
+ return False
+diff -Naur python2.7-2.7.16.orig/Lib/test/test_cookielib.py 
python2.7-2.7.16/Lib/test/test_cookielib.py
+--- python2.7-2.7.16.orig/Lib/test/test_cookielib.py   2019-03-02 
19:17:42.0 +0100
 python2.7-2.7.16/Lib/test/test_cookielib.py2019-10-11 
15:33:02.648671958 +0200
+@@ -368,6 +368,7 @@
+ ("http://foo.bar.com/;, ".foo.bar.com", True),
+ ("http://foo.bar.com/;, "foo.bar.com", True),
+ ("http://foo.bar.com/;, ".bar.com", True),
++("http://foo.bar.com/;, "bar.com", True),
+ ("http://foo.bar.com/;, "com", True),
+ ("http://foo.com/;, "rhubarb.foo.com", False),
+ ("http://foo.com/;, ".foo.com", True),
+@@ -378,6 +379,8 @@
+ ("http://foo/;, "foo", True),
+ ("http://foo/;, "foo.local", True),
+ ("http://foo/;, ".local", True),
++("http://barfoo.com;, ".foo.com", False),
++("http://barfoo.com;, "foo.com", False),
+ ]:
+ request = urllib2.Request(url)
+ r = pol.domain_return_ok(domain, request)
+@@ -938,6 +941,33 @@
+ c.add_cookie_header(req)
+ self.assertFalse(req.has_header("Cookie"))
+ 
++c.clear()
++
++pol.set_blocked_domains([])
++req = Request("http://acme.com/;)
++res = FakeResponse(headers, "http://acme.com/;)
++cookies = c.make_cookies(res, req)
++c.extract_cookies(res, req)
++self.assertEqual(len(c), 1)
++
++req = Request("http://acme.com/;)
++c.add_cookie_header(req)
++self.assertTrue(req.has_header("Cookie"))
++
++req = Request("http://badacme.com/;)
++c.add_cookie_header(req)
++self.assertFalse(pol.return_ok(cookies[0], req))
++self.assertFalse(req.has_header("Cookie"))
++
++p = pol.set_blocked_domains(["acme.com"])
++req = Request("http://acme.com/;)
++

Bug#702050: #702050: tasksel: a meta task to install all language tasks ?

[Holger Wansing]

Control: tags -1 + wontfix


Charles Plessy  wrote (2 Mar 2013):
> I just installed all the task--desktop packages on my computer
> using equivs and a Depends field populated by the output of the following
> command, run from the tasks directory of the tasksel package.
> 
> find . -maxdepth 1 -type f | xargs grep -l '^Task:'|
>   xargs grep-dctrl --exact-match -FSection l10n --and -FEnhances desktop 
> -sTask -n |
>   grep -v -e gnome -e kde | sed -e 's/^/ task-/' -e 's/$/,/'
> 
> The good news is that they are all co-installable.  The bad news is that not
> all software are able to pick correctly the appropriate font.  In particular,
> epiphany and chromium now display Chinese characters with Chinese glyphs even
> for texts where the indicated language is Japanese.  Fortunately, iceweasel
> picks the right fonts.
> 
> If it were posssible to tackle such issues after the Wheezy release, then I
> think that it would be worth to give our users the choice to install all
> localisation tasks. [...]

This approach would always be a corner case?
Which (average) user would be wanting all language tasks?

Since there has been no progress for 4 years, I'm tagging this bug as wontfix.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#942839: rust-cbindgen 0.8.7-1~deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942839 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: rust-cbindgen
Version: 0.8.7-1~deb9u1

Explanation: new package to support firefox-esr backports

Bug#942841: cargo 0.35.0-2~deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942841 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: cargo
Version: 0.35.0-2~deb9u1

Explanation: new upstream version, to support firefox-esr backports

Bug#942840: rustc 1.34.2+dfsg1-1~deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942840 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: rustc
Version: 1.34.2+dfsg1-1~deb9u1

Explanation: new upstream version, to support firefox-esr backports

Bug#940715: nodejs-mozilla 8.11.1~dfsg-2~deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940715 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: nodejs-mozilla
Version: 8.11.1~dfsg-2~deb9u1

Explanation: new package to support firefox-esr backports

Bug#942851: perl-modules-5.30: CPAN.pm is insecure by default, no warnings

[Moritz Muehlenhoff]

On Wed, Oct 23, 2019 at 10:20:04PM +0300, Niko Tyni wrote:
> Control: reassign -1 src:perl
> Control: found -1 5.20.2-3
> 
> On Tue, Oct 22, 2019 at 12:36:14PM +0200, Vincent Lefevre wrote:
> > Package: perl-modules-5.30
> > Version: 5.30.0-8
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > 
> > I've just found that CPAN.pm does not check signatures by default:
> > 
> >   'check_sigs' => q[0],
> > 
> > Moreover, it downloads files using http, not https.
> > 
> > The combination of both issues makes it very insecure, with a possible
> > remote attack!
> > 
> > And there are no warnings about that.
> 
> Thanks for your report.
> 
> FWIW this has been the case since forever.
> 
> https://www.cpan.org/SITES.html does not list any https mirrors.
> 
> I'm not at all familiar with this topic but a web search gives
>  https://www.perlmonks.org/?node_id=1158601
> 
> Quoting perlancar there for future reference:
> 
>   PAUSE creates a CHECKSUMS file in author's directory, listing each
>   release file along with its last modified time, size, MD5 and SHA256
>   checksums. The CHECKSUMS file is then signed by PAUSE. A CPAN client
>   can be instructed (e.g. --verify in cpanm) to check the signature of
>   the CHECKSUMS file.
> 
>   A couple of issues: 1) signature verification is not enabled by default
>   in CPAN client (at least in cpanm); 2) most (all?) CPAN mirrors are
>   ftp/http and not https, so during the first installation where the
>   client does not have PAUSE's public key yet, a MITM attack can spoof
>   the CHECKSUMS file as well as the release tarballs without the client
>   being able to detect it. These issues can be fixed in the client:
>   enable --verify by default and bundle the PAUSE public key.
> 
>   Additionally, an author can also sign his distribution using a framework
>   like Module::Signature. This will create a SIGNATURE file in the
>   top-level directory of the distribution which contains the checksums of
>   the files in the distribution. The SIGNATURE is then signed using the
>   author's PGP key. This protects the distribution from being tampered
>   by the server (in this case, PAUSE).
> 
>   A CPAN client can then be instructed (also --verify in cpanm) to check
>   this signature file. The 'cpansign' CLI tool distributed along with
>   Module::Signature can also be used for this purpose. The same issue
>   also exists: verify is not enabled by default. And another issue,
>   code signing by author is not mandatory and as far as I know, only a
>   small percentage of authors do this. And yet another issue, at least
>   when I tried it, tool like 'cpansign' is not strict by default: when
>   it fails to retrieve the required PGP public key, it stills reports
>   "==> Signature verified OK! <=".
> 
> So as I understand this, verifying CHECKSUMS would be the thing to do,
> and setting 'check_sigs' wouldn't really help (only deployed partially
> and no web of trust to the module authors).
> 
> >From a cursory look it looks to me like cpanm from src:cpanminus verifies
> CHECKSUMS if Module::Signature (src:libmodule-signature-perl, bundles a
> recent PAUSE public key) is installed, but CPAN.pm doesn't. But I might
> be wrong.
> 
> I'm copying the security team. Would somebody be interested in digging
> further into this?
> 
> Not touching the severity but given the long standing history this is
> not a high priority item for me.

>From my PoV, people are free to work with upstream to get that fixed, but
there's no I reason to treat this as an RC bug.

Cheers,
Moritz

Bug#941194: initscripts: remove some implementation details

[Ansgar]

Russ Allbery writes:
> I'm hesitant to remove all discussion of run levels because package
> maintainers are still responsible for choosing a run level at which to
> start their service and providing that run level as an argument to
> update-rc.d.

No, maintainer scripts call `update-rc.d  defaults`.  There is no
runlevel involved.  The runlevel is only in the LSB init script magic
comment.  However those aren't explained anywhere in Policy, even though
the dependency part was more important than the runlevel part (IMHO)...

>>> Also the rationale for why `DISABLED=yes` (or similar) fits better
>>> into a footnote than the main text (IMHO).
>
>> I'm inclined to agree with you, but since Russ is keen to reduce the
>> number of footnotes in Policy, it would be good to hear from him here.
>
> I don't like footnotes; if something is important enough to say, I think
> it's usually important enough to put into the main text without making
> people click or jump around to find it.  But I think the current paragraph
> in Policy is poorly worded and not as general or as straightforward as it
> could be, and it's weirdly out of place in the update-rc.d section.
>
> How about, rather than moving it to a footnote, rephrasing it as follows?
>
> Except when the package has been removed but not purged, as described
> above, the ``/etc/init.d`` script should not decide whether or not to
> start the daemon based on configuration settings (such as settings in
> ``/etc/default``) or silently exit successfully when the daemon could
> not be started.

I think this part isn't that interesting:

> This causes inconsistent and confusing behavior such
> as ``service  start`` returning success but not starting the
> service; services with a dependency on this service starting even
> though the service isn’t running; and init system status commands
> claiming that the service was started.

(It's a rationale, Policy usually doesn't have those.)

> If the ``/etc/init.d`` script
> is invoked with the ``start`` or ``restart`` arguments and the service
> could not or should not be started, it should produce an appropriate
> error message and exit with a non-zero status.
>
> and then moving this whole paragraph into 9.3.2, probably as the
> second-to-last paragraph?

Besides that I believe it's fine.

9.3.2 still has other interesting parts that I want to change (such as
suggesting editing /etc/init.d/ is a good way to disable
services).  For the conffile-disliking person it also contains the
admission that conffiles are so user-unfriendly on upgrades that there
are conffiles for conffiles, i.e. /etc/default/* ;-)

Ansgar

Bug#943363: Fix installation of Python 3.8 extensions.

[Matthias Klose]

Package: src:python-gevent
Version: 1.3.7-1
Severity: important
Tags: sid bullseye patch
User: debian-pyt...@lists.debian.org
Usertags: python3.8

Fix installation of Python 3.8 extensions.

http://launchpadlibrarian.net/448139253/python-gevent_1.3.7-1build2_1.3.7-1ubuntu1.diff.gz

Bug#943172: duplicate bug

[Chris Lawrence]

This bug is a duplicate of 937603.


Chris
-- 
Chris Lawrence  - http://blog.lordsutch.com/

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

Control: tags -1 patch

Ian Jackson  writes:

> I found myself trying to implement what I had suggested earlier and
> ran up against the question of what to do about [ ] in optional
> values.

> I decided to use this regexp
> + $vcsgiturl =~ s/\s+\[[^][]*\]//g;
> (I need to strip the information, not use it.)  That hopes paths do
> not contain [ ] but permits (and eats) spaces inside the [ ].

> I'm inclined to think that these questions show that my original
> proposal was not brilliant and that your idea is better.

> HTH.

Here's proposed wording that documents only the already-in-use path
syntax.  (We're probably overdue for introducing ABNF into Policy so that
we can properly specify the syntax of things, but I didn't attempt to do
that here.)

Author: Russ Allbery 
Date:   Wed Oct 23 13:56:06 2019

Add support for paths in Vcs-Git

Closes: #932696

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 60edc82..297f5c3 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -973,11 +973,33 @@ repository where the Debian source package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ "["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it must be a relative path naming a subdirectory in that
+repository and branch.  If no path is specified, the ``debian``
+directory containing the packaging is expected to be at the top level
+of the indicated repository and branch.
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multple version control


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

Bug#404261: #404261: rescue-mode: should support loop-aes and plain dm-crypt encrypted disks

[Holger Wansing]

Control: retitle -1 rescue-mode: should support plain dm-crypt encrypted disks


Retitle bug, since loop-AES is no longer supported by the installer

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#943362: RFS: clamfs/1.1.0-1 [RC] -- user-space anti-virus protected file system

[Krzysztof Burghardt]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: clamfs
   Version : 1.1.0-1
   Upstream Author : Krzysztof Burghardt 
 * URL : https://github.com/burghardt/clamfs
 * License : GPL-2+
 * Vcs : None
   Section : utils

It builds those binary packages:

  clamfs - user-space anti-virus protected file system

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/clamfs/clamfs_1.1.0-1.dsc

Changes since the last upload:

   * New upstream version (closes: #529569, #925653).
   * New maintainer.
   * Format set to 3.0 (quilt).
   * Set debian/compat to 12.
   * Rewritten debian/copyright to be machine readable.
   * debian/control:
 - drop dependency on libcommoncpp2-dev
 - bumped Standards-Version to 4.4.1
 - updated Homepage
   * debian/rules:
 - removed white spaces from line endings
 - replaced dh_clean -k with dh_prep
 - add build-arch and build-indep targets
 - enabled hardening=+all
   * debian/watch:
 - switch to github
 - verify PGP signature

Regards,
Krzysztof Burghardt

Bug#943361: RM: linux-latest -- ROM; binaries taken over by other packages

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

All of the binary packages previously built by src:linux-latest will
now be built by either src:linux or one of the source packages it
produces via the signing service.

This currently isn't true for the various "-rt" meta-packages,
but they should still be removed as PREEMPT_RT isn't available
for Linux 5.3.

Ben.

Bug#943360: python-msg fails its autopkg tests

[Matthias Klose]

Package: src:python-msgpack
Version: 0.5.6-1
Severity: serious
Tags: sid bullseye patch

python-msgpack fails its autopkg tests when it gets rebuilt.

patch at
http://launchpadlibrarian.net/448150811/python-msgpack_0.5.6-1build3_0.5.6-1ubuntu1.diff.gz

Bug#941803: debian-policy: dependencies on font packages

[Stephen Kitt]

On Wed, 23 Oct 2019 12:55:41 -0700, Russ Allbery  wrote:
> Russ Allbery  writes:
> > Stephen Kitt  writes:  
> 
> >> Is the following suitable?  
> 
> > Yup, this looks great.  Seconded.  Once this gets one more second, we'll
> > apply it.  
> 
> And now applied for the next release.

Great, thanks!

Regards,

Stephen


pgpGe53dF3CAD.pgp
Description: OpenPGP digital signature

Bug#690919: #690919: debian-installer: some line are cut of its top in Graphical Install

[Holger Wansing]

Hi Hideki,


could you tell us, what's the status of this bugreport?
It's from 2012, so seven years old.

Is this still an issue in Debian Buster?


Hideki Yamane  wrote:
>  With Graphical Install in Japanese (at least), some lines are not display
>  correctly, top of 1 or 2 dot is cut. 
> 
>  We can surely read it but it look ***much ugly***, not good.


Otherwise, I will close this bug now.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#916470: closed by Al Stone (Bug#916470: fixed in rasdaemon 0.6.4-1)

[sergio]

https://packages.debian.org/sid/rasdaemon

Homepage points to https://pagure.io/packages/rasdaemon
that is "Page not found (404)"


-- 
sergio.

Bug#941835: debian-policy: drop mentioning of legacy manual in package description

[Russ Allbery]

Control: tags -1 pending

Holger Levsen  writes:

> the current package description contains this paragraph:

>  It also replaces the old Packaging Manual; most of the still-relevant
>  content is now included as appendices to the Policy Manual.

> I'm around a long time and I dont remember the old Packaging Manual, so
> I think this paragraph can safely be dropped.

Agreed and done for the next release.

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

Bug#943359: d-e-doc: document requirements to add new translation to a.) git and b.) as a new binary package

[Holger Levsen]

package: src:debian-edu-doc
x-debbugs-cc: debian-...@lists.debian.org

On Wed, Oct 23, 2019 at 08:23:46PM +, Holger Levsen wrote:
> > > Sadly I dont remember what I considered a minimum before, so this
> > > time we should add that number to documentation/common/README.common-
> > > translations :/
> > > 
> > > Maybe 15%?
> > I understand. Both Portugese and Croatian are by far not at 15% yet.
>  
> ok. I will take a note now to mention this requirement somewhere easy to
> find.

^^ that

and maybe we have too many READMEs too:

$ find * |grep README
debian/README
debian/README.source
documentation/debian-edu-stretch/README.debian-edu-stretch-manual-translations
documentation/debian-edu-buster/README.debian-edu-buster-manual-translations
documentation/audacity/README.audacity-manual-translations
documentation/rosegarden/README.rosegarden-manual-translations
documentation/common/README.common-translations
documentation/debian-edu-itil/README.debian-edu-itil-manual-translations


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941194: initscripts: remove some implementation details

[Russ Allbery]

Sean Whitton  writes:
> On Thu 26 Sep 2019 at 09:01AM +02, Ansgar Burchardt wrote:

>> Control: reassign -1 debian-policy
>>
>> The section on initscripts has too much implementation details about
>> /etc/rcn.d; these are better explained by external documentation.

> Are you saying that they are *currently* better explained by actually
> existing external documentation, or that it would be better to have them
> explained by external documentation instead of the Policy Manual?  If
> the former, could you point to that documentation, please?

I agree with removing the discussion of the symlink forest and how it is
managed.  We require use of update-rc.d and prohibits mucking about with
the symlinks.  Given that, I think the symlink forest is an implementation
detail of sysv-rc and we should remove the detailed documentation of it
from Policy and keep only the requirement to use update-rc.d and the
details required to invoke it correctly (which includes some discussion of
run levels).

I'm hesitant to remove all discussion of run levels because package
maintainers are still responsible for choosing a run level at which to
start their service and providing that run level as an argument to
update-rc.d.  I think Policy should include enough details to allow
package maintainers to make that decision.  That said, the current text
doesn't include any useful advice, so I'm okay with removing what
discussion there currently is and then reintroducing some better
documentation later when someone gets a chance to write it.

>> Also the rationale for why `DISABLED=yes` (or similar) fits better
>> into a footnote than the main text (IMHO).

> I'm inclined to agree with you, but since Russ is keen to reduce the
> number of footnotes in Policy, it would be good to hear from him here.

I don't like footnotes; if something is important enough to say, I think
it's usually important enough to put into the main text without making
people click or jump around to find it.  But I think the current paragraph
in Policy is poorly worded and not as general or as straightforward as it
could be, and it's weirdly out of place in the update-rc.d section.

How about, rather than moving it to a footnote, rephrasing it as follows?

Except when the package has been removed but not purged, as described
above, the ``/etc/init.d`` script should not decide whether or not to
start the daemon based on configuration settings (such as settings in
``/etc/default``) or silently exit successfully when the daemon could
not be started.  This causes inconsistent and confusing behavior such
as ``service  start`` returning success but not starting the
service; services with a dependency on this service starting even
though the service isn’t running; and init system status commands
claiming that the service was started.  If the ``/etc/init.d`` script
is invoked with the ``start`` or ``restart`` arguments and the service
could not or should not be started, it should produce an appropriate
error message and exit with a non-zero status.

and then moving this whole paragraph into 9.3.2, probably as the
second-to-last paragraph?

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

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Jean-Marc]

Wed, 23 Oct 2019 16:40:37 +
 wrote :

Hi Mario,

> Internal Use - Confidential
> 
> In 1.3.2-5 the service is disabled by default (and also this issue should be 
> fixed).

Okay.  So, the bug can be closed, I guess.

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpwpc8u5Cvgq.pgp
Description: PGP signature

Bug#942776: nautilus-nextcloud: Please port to python3-nautlius

[Andreas Henriksson]

On Mon, Oct 21, 2019 at 01:20:00PM +0200, Andreas Henriksson wrote:
> Package: nautilus-nextcloud
> Version: 2.6.0-1
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package nautilus-nextcloud 2.6.0-1 depends on the python(2)
> bindings for nautilus.
[...]

It seems the package is already mostly converted to python3. It also
seems the nautilus extension code already supports python3.

Thus solving this bug report should be as easy as just replacing
'python-nautilus' in nautilus-nextcloud package Depends with
'python3-nautilus' in debian/control.

Regards,
Andreas Henriksson

Bug#937759: Team upload?

[Neil Williams]

tag 937759 + patch
thanks

This looks like a trivial fix to drop the Python2 support. I've had a
look and done a quick test build. If you don't have time to do the
upload yourself, would you be open to moving the package into Debian
Python Team maintenance?

Simple patch attached.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/

diffstat for python-flask-httpauth-3.2.4 python-flask-httpauth-3.2.4

 changelog |7 +++
 control   |   20 +++-
 rules |2 +-
 3 files changed, 11 insertions(+), 18 deletions(-)

diff -Nru python-flask-httpauth-3.2.4/debian/changelog python-flask-httpauth-3.2.4/debian/changelog
--- python-flask-httpauth-3.2.4/debian/changelog	2018-10-24 14:27:30.0 +0100
+++ python-flask-httpauth-3.2.4/debian/changelog	2019-10-23 21:10:27.0 +0100
@@ -1,3 +1,10 @@
+python-flask-httpauth (3.2.4-4) unstable; urgency=medium
+
+  * Team upload
+  * Drop Python2 support. (Closes: #937759)
+
+ -- Neil Williams   Wed, 23 Oct 2019 21:10:27 +0100
+
 python-flask-httpauth (3.2.4-3) unstable; urgency=medium
 
   * debian/control: Put the Breaks/Replaces in the proper place; previous
diff -Nru python-flask-httpauth-3.2.4/debian/control python-flask-httpauth-3.2.4/debian/control
--- python-flask-httpauth-3.2.4/debian/control	2018-10-24 14:27:30.0 +0100
+++ python-flask-httpauth-3.2.4/debian/control	2019-10-23 21:10:27.0 +0100
@@ -1,13 +1,11 @@
 Source: python-flask-httpauth
-Maintainer: Martín Ferrari 
+Maintainer: Debian Python Modules Team 
+Uploaders: Martín Ferrari 
 Section: python
 Priority: optional
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-all,
-   python-docutils,
-   python-flask,
-   python-setuptools,
+   python3-docutils,
python3-all,
python3-flask,
python3-setuptools,
@@ -18,18 +16,6 @@
 Homepage: https://github.com/miguelgrinberg/flask-httpauth/
 Testsuite: autopkgtest-pkg-python
 
-Package: python-flask-httpauth
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
-Provides: ${python:Provides},
-Suggests: python-flask-httpauth-doc,
-Description: Basic and Digest HTTP authentication for Flask (Python 2)
- Flask-HTTPAuth is a simple extension that provides Basic and Digest HTTP
- authentication for Flask routes.
- .
- This package installs the library for Python 2.
-
 Package: python3-flask-httpauth
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-flask-httpauth-3.2.4/debian/rules python-flask-httpauth-3.2.4/debian/rules
--- python-flask-httpauth-3.2.4/debian/rules	2018-10-24 14:27:30.0 +0100
+++ python-flask-httpauth-3.2.4/debian/rules	2019-10-23 21:08:50.0 +0100
@@ -3,7 +3,7 @@
 export PYBUILD_NAME = flask-httpauth
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build: export http_proxy=127.0.0.1:9
 override_dh_auto_build: export https_proxy=127.0.0.1:9


pgp0BLvvzX0jk.pgp
Description: OpenPGP digital signature

Bug#942771: nautilus-admin: Please port to python3-nautlius

[Andreas Henriksson]

Control: tags -1 + patch

On Mon, Oct 21, 2019 at 01:19:29PM +0200, Andreas Henriksson wrote:
> Package: nautilus-admin
> Version: 1.1.9-2
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package nautilus-admin 1.1.9-2 depends on the python(2) bindings
> for nautilus.
[...]

The package seems to already contain code that works with python3
so fixing this seems as easy as just replacing 'python-nautilus'
dependency with 'python3-nautilus' in debian/control.

Debdiff attached.

Regards,
Andreas Henriksson
diff -Nru nautilus-admin-1.1.9/debian/changelog 
nautilus-admin-1.1.9/debian/changelog
--- nautilus-admin-1.1.9/debian/changelog   2019-01-29 02:14:28.0 
+0100
+++ nautilus-admin-1.1.9/debian/changelog   2019-10-23 22:08:20.0 
+0200
@@ -1,3 +1,10 @@
+nautilus-admin (1.1.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to python3-nautilus (Closes: #942771)
+
+ -- Andreas Henriksson   Wed, 23 Oct 2019 22:08:20 +0200
+
 nautilus-admin (1.1.9-2) unstable; urgency=medium
 
   * Add more details to debian/upstream/metadata.
diff -Nru nautilus-admin-1.1.9/debian/control 
nautilus-admin-1.1.9/debian/control
--- nautilus-admin-1.1.9/debian/control 2019-01-27 19:53:34.0 +0100
+++ nautilus-admin-1.1.9/debian/control 2019-10-23 22:08:17.0 +0200
@@ -14,7 +14,7 @@
 Depends: gir1.2-gtk-3.0,
  gvfs-backends (>= 1.30),
  nautilus,
- python-nautilus,
+ python3-nautilus,
  ${misc:Depends}
 Recommends: gedit
 Enhances: nautilus

Bug#907727: Empty directory is already present in orig tarball

[Russ Allbery]

Apologies for the long delay in getting back to this bug.  To recap
history briefly since it's been a few months, the original request was to
suppress the tag source-contains-empty-directory if the Debian patch set
explicitly adds a file to that directory, and the example package affected
by this is xfonts-jmk.

Felix Lechner  writes:
> On Sat, Aug 10, 2019 at 4:51 PM Russ Allbery  wrote:

>> I don't think there was anything specific to git-buildpackage there.

> Isn't the whole problem specific to git-buildpackage?

No, the root problem, and the reason why the Lintian tag exists at all, is
that Git cannot represent empty directories and therefore will drop them
if a tree of files that contains an empty directory is imported into Git
and then exported out of Git again.

git-buildpackage is one tool that imports trees of files into Git and
later exports them as part of packaging, but just about any Git-based
packaging tool would the same problem.

See https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F

>> The result is that the patches-applied Debian packaging tree is then
>> representable in Git, which did seem mildly superior to recreating the
>> directory in debian/rules if it had disappeared due to a round trip
>> through Git.

> I would prefer not to add such an obscure patch to 11,000 packages. Is
> it really sufficient to create the directories in d/rules?

Yes, it should be.  I suspect that 99% of the time this causes no
practical issues since the directory isn't used by the build anyway, or
upstream recreates the directory as needed.  That does imply that removing
the tag may make sense.

I do think it's unfortunate that a round trip through Git results in a
different source package than the canonical archive representation, since
it could lead to some weird and obscure failures, but like you I'm dubious
that problem is worth asking people to fix 11,000 packages.

> That is a bug in our tools, not in upstream's delivery. Besides,
> couldn't you patch the upstream build system?

Yes, there are a lot of simple solutions to recreate the directory.

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

Bug#935845: [Pkg-javascript-devel] Bug#935845: not an RC bug; fix is easy: upgrade embedded lodash.cli

[Jonas Smedegaard]

Quoting Paolo Greppi (2019-10-23 21:18:37)
> First, I tripped on this one while testing yarnpkg 1.19.1 from experimental.
> For the record, this is how I found that node-lodash was the culprit:
> 
> node --trace-deprecation /usr/bin/yarnpkg install
> yarn install v1.19.1
> [1/4] Resolving packages...
> (node:29081) [DEP0016] DeprecationWarning: 'root' is deprecated, use 'global'
> at Object. (/usr/share/nodejs/lodash/_createRound.js:6:22)
> at Module._compile (internal/modules/cjs/loader.js:778:30)
> at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
> at Module.load (internal/modules/cjs/loader.js:653:32)
> at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
> at Function.Module._load (internal/modules/cjs/loader.js:585:3)
> at Module.require (internal/modules/cjs/loader.js:692:17)
> at require (internal/modules/cjs/helpers.js:25:18)
> at Object. (/usr/share/nodejs/lodash/ceil.js:1:19)
> at Module._compile (internal/modules/cjs/loader.js:778:30)
> ...
> 
> Second, this should not be an RC bug.
> It's a deprecation **warning**.
> And it could be easily patched out by allowing stderr in the autopkgtest.
> 
> But (and that's the third point) there's no need of that hack, because the 
> actual fix is easier.
> 
> The upstream commit that Jonas pointed to is on a branch (4.17.15-npm) where 
> upstream stores built artifacts ("binaries").
> You can rebuild those binaries locally in this package sources dir with:
> NODE_PATH=. node lodash-cli/bin/lodash modularize exports=node -o modules
> only to find that the generated modules/_createRound.js lacks the root = 
> require statement
> 
> The reason is that the bundled version of lodash-cli is out of date:
> grep version lodash-cli/package.json 
>   "version": "4.17.5",
> 
> if you replace the lodash-cli dir with the current version (which is in sync 
> with lodash itself, 4.17.15) you get the correct file generated.
> 
> So in the future we should keep the bundled lodash-cli in sync with lodash 
> itself.

More importantly: We should track versions!!!

lodash embeds lodash-cli with "ignore" in its watch file.

How many JavaScript packages are packaged that way?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#942779: subliminal-nautilus: Please port to python3-nautlius

[Andreas Henriksson]

On Mon, Oct 21, 2019 at 01:20:24PM +0200, Andreas Henriksson wrote:
> Package: subliminal-nautilus
> Version: 2.0.5-2
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package subliminal-nautilus 2.0.5-2 depends on the python(2)
> bindings for nautilus.
[...]

It seems this package is mostly already ported over to python3, with
python-nautilus being the only exception.

As far as I can tell the code is ready for python3 so hopefully fixing
this bug report should be as easy as replacing 'python-nautilus' with
'python3-nautilus' in the Depends: field in debian/control.

Regards,
Andreas Henriksson

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Anton Avramov]

Hi Guilhem,

Thank you for replying to my request.

On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin,  wrote:

> Hi Anton,
>
> [dropbear package maintainer here.]
>
> On Mon, 21 Oct 2019 at 16:07:11 -0400, Anton Avramov wrote:
> > For a long time now I've maintained servers remotely. One problem that
> > I've faced is what when there is problem booting I lose ability to login
> > remotely and help the person on premises. Further more that person can
> > be not technically capable or comfortable with writing console
> > commands. There are instances where there is not even a keyboard or
> > monitor attached.
>
> Given the scope of this package, I strongly believe it'd make more sense
> to merge it with src:dropbear rather than shipping a separate source
> package.
>

I agree. However I don't know how I can contribute to that.


> > Following dropbear-initramfs package
>
> You seem to suggest that your code takes inspiration from
> dropbear-initramfs,
> but your copyright information doesn't reflect that.
>

Sorry about that! I've tried to change that, but I'm not absolutely certain
I've done it right.


> > that will install dropbear and would have the appropriate initramfs
> > scripts to start it in case the system enters rescue mode.
>
> Why couldn't that be done in dropbear-initramfs instead?  Right now the
> script is run at premount stage, but I guess we could have an option to
> run it at another stage instead.


The only argument I can think of is to give the option to have separate
access for panic and crypt unlock. For example in my scenario I have crypt
unlock on different port with different hostkeys. And in principle I can
give someone the right to unlock the fs, but not login in case of panic
where in that case and admin with higher access should step in.

However the first step would be to
> document the ‘panic’ stage in initramfs-tools(7) (the “boot scripts”
> section of the manual doesn't mention it AFAICT).
>
> > I've tried to keep the package compatible with dropbear-initramfs
> > package.
>
> Depending what you mean by “compatible”, please note that the only
> public interface of that package is the configuration file.  Relying on
> something else would be another argument in favor of integrating this
> into src:dropbear.  Also I didn't review the code but at first glance I
> see similarities, please see §4.13 of the Debian Policy.
>

By compatible I mean they can run together without interfering given they
use different port. Since there are only 2 scripts in initramfs I'm not
sure how would they suppose to share the code if we assume they are
different packages


> Cheers,
> --
> Guilhem.
>

Bug#937504: Team upload?

[Neil Williams]

tag 937504 + patch
thanks

Would you be open to migrating pyparted to Debian Python Modules Team
to fix this bug?

I've done an initial look, it seems that a simple removal of the
python2 support is all that's needed.

A new source-only upload is needed to get 3.11.2-11 into testing
anyway, would it be ok for me to do that upload, changing Maintainer to
Debian Python Modules Team with you in Uploaders?

A simple python3 diff is attached.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/

commit ce7b3d0f004f50cdfd1593be8d427fa040f636f6
Author: Neil Williams 
Date:   Wed Oct 23 20:47:29 2019 +0100

Drop python2 package (Closes: #937504)

Shift across to DPMT maintenance.

diff --git a/debian/changelog b/debian/changelog
index 211e3f8..20431db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pyparted (3.11.2-12) unstable; urgency=medium
+
+  * Team upload
+  * Drop python2 package (Closes: #937504)
+
+ -- Neil Williams   Wed, 23 Oct 2019 20:46:57 +0100
+
 pyparted (3.11.2-11) unstable; urgency=medium
 
   * debian/patches:
diff --git a/debian/control b/debian/control
index d52418e..6d1831c 100644
--- a/debian/control
+++ b/debian/control
@@ -1,14 +1,13 @@
 Source: pyparted
 Section: python
 Priority: optional
-Maintainer: Herbert Parentes Fortes Neto 
+Maintainer: Debian Python Modules Team 
+Uploaders: Herbert Parentes Fortes Neto 
 Build-Depends: debhelper (>= 11),
dh-python,
libparted-dev,
parted,
pkg-config,
-   python-all-dev (>= 2.6.6-13~),
-   python-six,
python3-all-dev,
python3-six
 Standards-Version: 4.3.0
@@ -16,18 +15,6 @@ Homepage: https://github.com/dcantrell/pyparted
 Vcs-Git: https://salsa.debian.org/debian/pyparted.git
 Vcs-Browser: https://salsa.debian.org/debian/pyparted
 
-Package: python-parted
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Provides: ${python:Provides}
-Suggests: python-parted-doc (>= 3.11.1-5)
-Description: Python interface for libparted
- pyparted is a set of Python modules that provide Python programmers an
- interface to libparted (http://www.gnu.org/software/parted), the GNU parted
- library for disk partitioning and file system manipulation.
- .
- This package contains Python extension itself.
-
 Package: python3-parted
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
diff --git a/debian/rules b/debian/rules
index fc5ddc3..252503e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,11 +6,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 %:
-	dh $@ --buildsystem pybuild --with python2,python3
+	dh $@ --buildsystem pybuild --with python3
 
 override_dh_auto_install:
 	dh_auto_install
-	rm -rf debian/python-parted-dbg/usr/lib/python2.7/dist-packages/parted/
 	rm -rf debian/python3-parted-dbg/usr/lib/python3*/dist-packages/parted/
 
 override_dh_clean:


pgphOp24mlK0f.pgp
Description: OpenPGP digital signature

Bug#943358: synaptic: Synaptic 0.84.8 installs packets with "depends on" absent packages

[Сергей Фёдоров]

Package: synaptic
Version: 0.84.8
Severity: normal
Tags: security



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme  0.17-2
ii  libapt-inst2.0  1.8.4
ii  libapt-pkg5.0   1.8.4
ii  libc6   2.29-2
ii  libept1.5.0 1.1+nmu3+b1
ii  libgcc1 1:9.2.1-12
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1
ii  libglib2.0-02.62.1-1
ii  libgtk-3-0  3.24.12-1
ii  libpango-1.0-0  1.42.4-7
ii  libstdc++6  9.2.1-12
ii  libvte-2.91-0   0.58.2-1
ii  libxapian30 1.4.12-1
ii  policykit-1 0.105-26

Versions of packages synaptic recommends:
ii  libgtk3-perl  0.036-1
ii  xdg-utils 1.1.3-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
pn  menu 
pn  software-properties-gtk  
ii  tasksel  3.55

-- no debconf information

Package: qtcreator
Version: 4.10.1-1
Severity: important

"Qtcreator 4.10.1-1" installation requires packages:

  qtbase-abi-5-11-3
  qtdeclarative-abi-5-11-2

but they are not.

Package: calibre
Version: 4.0.0+really3.48.dfsg-1
Severity: important

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

"calibre 4.0.0+really3.48.dfsg-1" installation requires package:

  calibre-bin (>= 4.0.0+really3.48.dfsg-1) (it is)

  and packages are required to install it:

  qtbase-abi-5-11-3
  sip-api-12.6

but the last two packages are not.

I have a Synaptic version of "0.84.8".
Synaptic refused to install the "qtcreator" and "calibre" packages due to lack 
of
packages':

  qtbase-abi-5-11-3
  qtdeclarative-abi-5-11-2

  qtbase-abi-5-11-3
  qtdeclarative-abi-5-11-2

2019-10-22 I sent messages to support packages "calibre" and "qtcreator" about
this.

2019-10-23 I found that the "calibre" and "qtcreator" packages are now installed
in the same version of Synaptic without any messages though missing packages
still missing.

How could that be?

The same problem occur with kernel:

linux-image-4.19.0-5-amd64
Linux 4.19 for 64-bit PCs (signed)
ver. 4.19.37-5

linux-image-5.2.0-3-amd64
Linux 5.2 for 64-bit PCs (signed)
ver. 5.2.17-1+b1

linux-image-5.3.0-1-amd64
Linux 5.3 for 64-bit PCs (signed)
ver. 5.3.7-1  

Bug#937462: Affected package has been fixed

[Neil Williams]

https://tracker.debian.org/news/1073358/subunit-130-4-migrated-to-testing/

subunit has now migrated to testing with the fix for #938577

Is it time for an upload of pyjunitxml?

If you don't have time, is it ok to move this package to Debian Python Team 
maintenance?

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp5TcaIMnl0A.pgp
Description: OpenPGP digital signature

Bug#932534: longrun: diff for NMU version 0.9-22.1

[Boyuan Yang]

Control: tags 932534 + patch
Control: tags 932534 + pending

Dear maintainer,

I've prepared an NMU for longrun (versioned as 0.9-22.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -u longrun-0.9/debian/control longrun-0.9/debian/control
--- longrun-0.9/debian/control
+++ longrun-0.9/debian/control
@@ -1,11 +1,12 @@
 Source: longrun
 Section: utils
-Priority: extra
+Priority: optional
 Maintainer: Uwe Hermann 
-Build-Depends: debhelper (>= 7), groff, bsdmainutils, gettext
-Standards-Version: 3.8.0
-Vcs-Git: git://git.kitenet.net/joey/packages/longrun
-Homepage: ftp://ftp.kernel.org/pub/linux/utils/cpu/crusoe/
+Build-Depends: debhelper (>= 9), groff, bsdmainutils, gettext
+Standards-Version: 4.4.1
+Homepage: https://kernel.org/pub/linux/utils/cpu/crusoe/
+Vcs-Git: https://salsa.debian.org/debian/longrun.git
+Vcs-Browser: https://salsa.debian.org/debian/longrun
 
 Package: longrun
 Architecture: i386
diff -u longrun-0.9/debian/rules longrun-0.9/debian/rules
--- longrun-0.9/debian/rules
+++ longrun-0.9/debian/rules
@@ -5,9 +5,5 @@
-binary-arch: build install
-   dh binary-arch --before dh_installdirs
+override_dh_installdirs:
dh_installdirs etc/apm/event.d etc/acpi/events etc/acpi/actions
install debian/apm.event debian/longrun/etc/apm/event.d/longrun
install -m 0644 debian/acpi.event
debian/longrun/etc/acpi/events/longrun
install debian/acpi.action debian/longrun/etc/acpi/actions/longrun
-   dh binary-arch --remaining
-
-binary: binary-indep binary-arch
diff -u longrun-0.9/debian/changelog longrun-0.9/debian/changelog
--- longrun-0.9/debian/changelog
+++ longrun-0.9/debian/changelog
@@ -1,3 +1,19 @@
+longrun (0.9-22.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Bump Standards-Version to 4.4.1.
++ Bump debhelper compat to v9.
++ Update Vcs-* fields and points to the git packaging repo
+  under Salsa Debian group.
++ Update homepage field and points to the correct website.
+  * debian/rules:
+- Do not use deprecated manual sequence control operations.
+  (Closes: #932534)
:q+
+ -- Boyuan Yang   Wed, 23 Oct 2019 14:58:30 -0400
+
 longrun (0.9-22) unstable; urgency=low
 
   * New maintainer (Closes: #483251).
diff -u longrun-0.9/debian/compat longrun-0.9/debian/compat
--- longrun-0.9/debian/compat
+++ longrun-0.9/debian/compat
@@ -1 +1 @@
-7
+9
only in patch2:
unchanged:
--- longrun-0.9.orig/debian/source/format
+++ longrun-0.9/debian/source/format
@@ -0,0 +1 @@
+1.0


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

Bug#942769: [Pkg-clamav-devel] Bug#942769: clamtk-gnome: Please port to python3-nautlius

[Scott Kitterman]

On Wednesday, October 23, 2019 3:41:37 PM EDT Andreas Henriksson wrote:
> On Mon, Oct 21, 2019 at 01:17:04PM +0200, Andreas Henriksson wrote:
> > Package: clamtk-gnome
> > Version: 6.01-1
> > Severity: important
> > Control: block 937115 by -1
> > User: pkg-gnome-maintain...@lists.alioth.debian.org
> > Usertags: oldlibs python-nautilus
> > 
> > Hello,
> > 
> > Your package clamtk-gnome 6.01-1 depends on the python(2) bindings
> > for nautilus.
> 
> [...]
> 
> It seems python3 is already supported.
> 
> Solving this should hopefully be as easy as switching
> python-nautilus and python dependencies to python3-nautilus and python3.

There's a few other things, but it shouldn't be complex.

Scott K

Bug#906060: Coordinate overflow when rendering

[Olly Betts]

Control: reassign -1 libcairo2

On Wed, Oct 23, 2019 at 02:07:43PM +0200, Simon Richter wrote:
> On Wed, Oct 23, 2019 at 09:45:11AM +1300, Olly Betts wrote:
> 
> > > This is a major showstopper for linking KiCad 5 against GTK3, so this
> > > requires us to keep GTK2 around longer.
> 
> > The debian kicad package has now using the GTK3 flavour of wxwidgets3.0
> > for many months, so has this bug been solved (at least as far as kicad
> > and wxwidgets3.0 are concerned)?
> 
> No, we rewrote the entire rendering engine so we render through wxGLCanvas
> now in most cases, with a fallback where we apply the zoom ourselves before
> rendering through Cairo directly. Hardly an ideal outcome.

Indeed not.

> > If not, I'm very unclear what (as a maintainer of wxwidgets3.0) I'm
> > expected to do given that the problem clearly seem to lie lower down the
> > stack:
> 
> > > Quick debugging has shown that the coordinates given to Cairo still make
> > > sense, even if the zoom level makes them numerically large. As I'd need
> > > significant time to debug into optimized drawing routines, I'd like to 
> > > pass
> > > this on. I suspect that this is mostly an interaction between Cairo and
> > > Pixman, with an overflow happening somewhere in a conversion from double 
> > > to
> > > an integer type.
> 
> In any case it's an upstream problem, either in Cairo or wx, depending on
> whether large zoom levels are supposed to work in Cairo.

I fear that having this assigned to multiple different packages is a
recipe for everybody assuming it's somebody else's problem and nobody
ever doing anything further about it.

The Cairo documentation has no mention of limits on supported zoom
levels:

https://developer.gnome.org/cairo/stable/cairo-Transformations.html#cairo-scale

Therefore I'd say this is a bug in Cairo (either it should support
arbitrary zooming limited only by the ranges of the types, or it should
clearly document the limits on zooming that it supports), and I'm
reassigning to just Cairo on that basis.

(It also seems Cairo really should support this rather than forcing all
callers who want to zoom by arbitrary amounts to work around the
limitation, and if it's too hard to Cairo to do this, I struggle to see
why it's easier for callers to handle it.)

If it's actually a Cairo documentation bug, once that's addressed this
can be assigned back and I can try to convince wx upstream they need to
somehow work around it.

Cheers,
Olly

Bug#943357: mypy, python3-mypy: Both ship /usr/bin/dmypy

[Boyuan Yang]

Package: mypy
Version: 0.730-1
Severity: serious
X-Debbugs-CC: michael.cru...@gmail.com

% LANG=C LC_ALL=C sudo apt install mypy python3-mypy
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  mypy-doc
The following NEW packages will be installed:
  mypy python3-mypy
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/5969 kB of archives.
After this operation, 28.6 MB of additional disk space will be used.
Selecting previously unselected package python3-mypy.
(Reading database ... 655302 files and directories currently installed.)
Preparing to unpack .../python3-mypy_0.740-1_amd64.deb ...
Unpacking python3-mypy (0.740-1) ...
Selecting previously unselected package mypy.
Preparing to unpack .../archives/mypy_0.740-1_all.deb ...
Unpacking mypy (0.740-1) ...
dpkg: error processing archive /var/cache/apt/archives/mypy_0.740-1_all.deb (-
-unpack):
 trying to overwrite '/usr/bin/dmypy', which is also in package python3-mypy
0.740-1
Errors were encountered while processing:
 /var/cache/apt/archives/mypy_0.740-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Regards,
Boyuan Yang


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

Bug#942781: sparkleshare: Please port to python3-nautlius

[Andreas Henriksson]

On Mon, Oct 21, 2019 at 01:20:18PM +0200, Andreas Henriksson wrote:
> Package: sparkleshare
> Version: 3.28+git20190117-1
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package sparkleshare 3.28+git20190117-1 depends on the python(2)
> bindings for nautilus.
[...]


Actually it Recommends (not Depends).

Anyway, I can't find a trace of any python code in sparkleshare
and the RELEASE_NOTES.txt even says for 0.9.4:

- Remove Nautilus extension

I thus suggest the solution for this bug report would be to simply
drop the entire 'Recommends: python, python-nautilus' line from
debian/control.

Regards,
Andreas Henriksson

Bug#941803: debian-policy: dependencies on font packages

[Russ Allbery]

Control: tags -1 pending

Russ Allbery  writes:
> Stephen Kitt  writes:

>> Is the following suitable?

> Yup, this looks great.  Seconded.  Once this gets one more second, we'll
> apply it.

And now applied for the next release.

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

Bug#935845: not an RC bug; fix is easy: upgrade embedded lodash.cli

[Paolo Greppi]

First, I tripped on this one while testing yarnpkg 1.19.1 from experimental.
For the record, this is how I found that node-lodash was the culprit:

node --trace-deprecation /usr/bin/yarnpkg install
yarn install v1.19.1
[1/4] Resolving packages...
(node:29081) [DEP0016] DeprecationWarning: 'root' is deprecated, use 'global'
at Object. (/usr/share/nodejs/lodash/_createRound.js:6:22)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/usr/share/nodejs/lodash/ceil.js:1:19)
at Module._compile (internal/modules/cjs/loader.js:778:30)
...

Second, this should not be an RC bug.
It's a deprecation **warning**.
And it could be easily patched out by allowing stderr in the autopkgtest.

But (and that's the third point) there's no need of that hack, because the 
actual fix is easier.

The upstream commit that Jonas pointed to is on a branch (4.17.15-npm) where 
upstream stores built artifacts ("binaries").
You can rebuild those binaries locally in this package sources dir with:
NODE_PATH=. node lodash-cli/bin/lodash modularize exports=node -o modules
only to find that the generated modules/_createRound.js lacks the root = 
require statement

The reason is that the bundled version of lodash-cli is out of date:
grep version lodash-cli/package.json 
  "version": "4.17.5",

if you replace the lodash-cli dir with the current version (which is in sync 
with lodash itself, 4.17.15) you get the correct file generated.

So in the future we should keep the bundled lodash-cli in sync with lodash 
itself.

Paolo

Bug#942774: nautilus-hide: Please port to python3-nautlius

[Andreas Henriksson]

On Mon, Oct 21, 2019 at 01:19:48PM +0200, Andreas Henriksson wrote:
> Package: nautilus-hide
> Version: 0.2.3-7
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package nautilus-hide 0.2.3-7 depends on the python(2) bindings
> for nautilus.
[...]

Seems like it's possible to just replace python-nautilus with
python3-nautilus in depends.

However I also noticed it seems the extension tries to trigger the F5
key-press using "xdotool". Given GNOME is now Wayland, rather than Xorg,
based this doesn't seem to work anymore (unrelated to python/python3).

Regards,
Andreas Henriksson

Bug#791362: perl: build timezone affects LOCALTIME_{MIN,MAX}

[Niko Tyni]

Control: found -1 5.30.0-8

On Fri, Jul 03, 2015 at 11:16:46PM +0300, Niko Tyni wrote:
> On Mon, May 04, 2015 at 02:28:04PM +0200, Jérémy Bobbio wrote:

> > Another issue that surfaced now that we are doing timezone variations is
> > that LOCALTIME_MIN and LOCALTIME_MAX gets different values depending on
> > the value of the TZ environment variable.
> 
> > The minimum I had on my amd64 system is with TZ=UTC-24, -62167305600.
> > The maximum is with TZ=UTC and is 67768036191590399.
> > 
> > It feels like a bug to have something that can be configured through an
> > environment variable on a running system affect what gets encoded in the
> > binary.
> 
> This feels like a bug to me too, and should be handled separately.
> I'm cloning this and will export TZ=UTC in debian/rules, at least
> for now.

The TZ=UTC part was accidentally dropped in the build system debhelper
conversion for 5.30 packaging. This resulted in a reproducibility
regression that Holger pointed out to me on IRC (thanks!).

I'll re-instate TZ=UTC in 5.30.0-9 or so, but clearly the underlying
issue remains.
-- 
Niko Tyni   nt...@debian.org

Bug#942852: perl-modules-5.30: cpan writes configuration under .local/share/.cpan instead of .cpan

[Niko Tyni]

Control: reassign -1 src:perl 5.30.0-8

On Tue, Oct 22, 2019 at 01:48:56PM +0200, Vincent Lefevre wrote:
> Package: perl-modules-5.30
> Version: 5.30.0-8
> Severity: normal
> 
> When I run "cpan" after purging my configuration, the new
> configuration is written under the .local/share/.cpan directory,
> instead of .cpan as documented in the CPAN(3perl) man page.

It looks like this happens if both libfile-homedir-perl and xdg-user-dirs
are installed, in which case CPAN.pm uses File::HomeDir to look
up the directory, and File::HomeDir assumes you want to follow the
FreeDesktop.org specification.

Assuming this behaviour is deliberate, the CPAN.pm documentation
should probably refer to File::HomeDir or something like that.
-- 
Niko Tyni   nt...@debian.org

Bug#942851: perl-modules-5.30: CPAN.pm is insecure by default, no warnings

[Niko Tyni]

Control: reassign -1 src:perl
Control: found -1 5.20.2-3

On Tue, Oct 22, 2019 at 12:36:14PM +0200, Vincent Lefevre wrote:
> Package: perl-modules-5.30
> Version: 5.30.0-8
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> I've just found that CPAN.pm does not check signatures by default:
> 
>   'check_sigs' => q[0],
> 
> Moreover, it downloads files using http, not https.
> 
> The combination of both issues makes it very insecure, with a possible
> remote attack!
> 
> And there are no warnings about that.

Thanks for your report.

FWIW this has been the case since forever.

https://www.cpan.org/SITES.html does not list any https mirrors.

I'm not at all familiar with this topic but a web search gives
 https://www.perlmonks.org/?node_id=1158601

Quoting perlancar there for future reference:

  PAUSE creates a CHECKSUMS file in author's directory, listing each
  release file along with its last modified time, size, MD5 and SHA256
  checksums. The CHECKSUMS file is then signed by PAUSE. A CPAN client
  can be instructed (e.g. --verify in cpanm) to check the signature of
  the CHECKSUMS file.

  A couple of issues: 1) signature verification is not enabled by default
  in CPAN client (at least in cpanm); 2) most (all?) CPAN mirrors are
  ftp/http and not https, so during the first installation where the
  client does not have PAUSE's public key yet, a MITM attack can spoof
  the CHECKSUMS file as well as the release tarballs without the client
  being able to detect it. These issues can be fixed in the client:
  enable --verify by default and bundle the PAUSE public key.

  Additionally, an author can also sign his distribution using a framework
  like Module::Signature. This will create a SIGNATURE file in the
  top-level directory of the distribution which contains the checksums of
  the files in the distribution. The SIGNATURE is then signed using the
  author's PGP key. This protects the distribution from being tampered
  by the server (in this case, PAUSE).

  A CPAN client can then be instructed (also --verify in cpanm) to check
  this signature file. The 'cpansign' CLI tool distributed along with
  Module::Signature can also be used for this purpose. The same issue
  also exists: verify is not enabled by default. And another issue,
  code signing by author is not mandatory and as far as I know, only a
  small percentage of authors do this. And yet another issue, at least
  when I tried it, tool like 'cpansign' is not strict by default: when
  it fails to retrieve the required PGP public key, it stills reports
  "==> Signature verified OK! <=".

So as I understand this, verifying CHECKSUMS would be the thing to do,
and setting 'check_sigs' wouldn't really help (only deployed partially
and no web of trust to the module authors).

>From a cursory look it looks to me like cpanm from src:cpanminus verifies
CHECKSUMS if Module::Signature (src:libmodule-signature-perl, bundles a
recent PAUSE public key) is installed, but CPAN.pm doesn't. But I might
be wrong.

I'm copying the security team. Would somebody be interested in digging
further into this?

Not touching the severity but given the long standing history this is
not a high priority item for me.
-- 
Niko Tyni   nt...@debian.org

Bug#942769: clamtk-gnome: Please port to python3-nautlius

[Andreas Henriksson]

On Mon, Oct 21, 2019 at 01:17:04PM +0200, Andreas Henriksson wrote:
> Package: clamtk-gnome
> Version: 6.01-1
> Severity: important
> Control: block 937115 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs python-nautilus
> 
> Hello,
> 
> Your package clamtk-gnome 6.01-1 depends on the python(2) bindings
> for nautilus.
[...]

It seems python3 is already supported.

Solving this should hopefully be as easy as switching
python-nautilus and python dependencies to python3-nautilus and python3.

Regards,
Andreas Henriksson

Bug#941803: debian-policy: dependencies on font packages

[Holger Levsen]

On Wed, Oct 23, 2019 at 12:13:00PM -0700, Russ Allbery wrote:
> > From d5895ca185fa1d678a098697d9e1c601c84f45dd Mon Sep 17 00:00:00 2001
> > From: Stephen Kitt 
> > Date: Mon, 7 Oct 2019 21:09:52 +0200
> > Subject: [PATCH] Allow strong dependencies on X font packages
> 
> > The X server shipped in Debian no longer supports remote retrieval of
> > fonts from an X font server, so it no longer makes sense to forbid
> > packages from strongly depending on X font packages. On the contrary,
> > since local fonts are now the only way for an X program to obtain its
> > fonts, packages which require specific fonts to operate should depend
> > on the corresponding font package. (This is already common practice
> > for non-X font packages.)
> 
> > Closes: #941803
> > Signed-off-by: Stephen Kitt 
> > ---
> >  policy/ch-customized-programs.rst | 17 +
> >  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> > diff --git a/policy/ch-customized-programs.rst 
> > b/policy/ch-customized-programs.rst
> > index dbba4fc..dfe6ce4 100644
> > --- a/policy/ch-customized-programs.rst
> > +++ b/policy/ch-customized-programs.rst
> > @@ -380,11 +380,10 @@ themselves.
> >  1.  Fonts of any type supported by the X Window System must be in a
> >  separate binary package from any executables, libraries, or
> >  documentation (except that specific to the fonts shipped, such as
> > -their license information). If one or more of the fonts so packaged
> > -are necessary for proper operation of the package with which they
> > -are associated the font package may be Recommended; if the fonts
> > -merely provide an enhancement, a Suggests relationship may be used.
> > -Packages must not Depend on font packages.  [#]_
> > +their license information). Packages which require one or more of
> > +the fonts thus packaged should Depend on the font package; if the
> > +fonts merely provide an enhancement, a Recommends or Suggests
> > +relationship may be used.  [#]_
> >  
> >  2.  BDF fonts must be converted to PCF fonts with the ``bdftopcf``
> >  utility (available in the ``xfonts-utils`` package, ``gzip``\ ped,
> > @@ -617,9 +616,11 @@ installed in ``/usr/share/man/man6``.
> > Window System, however, must abide by this font policy.
> >  
> >  .. [#]
> > -   This is because the X server may retrieve fonts from the local file
> > -   system or over the network from an X font server; the Debian package
> > -   system is empowered to deal only with the local file system.
> > +   In the past, the X server could retrieve fonts from the local file
> > +   system or over the network from an X font server, so packages were
> > +   forbidden from declaring a Depends relationship with font
> > +   packages. This is no longer the case: the X font server shipped in
> > +   Debian no longer supports remote font retrieval.
> >  
> >  .. [#]
> > Note that this mechanism is not the same as using app-defaults;
 
seconded, thanks.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941803: debian-policy: dependencies on font packages

[Russ Allbery]

Stephen Kitt  writes:

> Is the following suitable?

Yup, this looks great.  Seconded.  Once this gets one more second, we'll
apply it.

> From d5895ca185fa1d678a098697d9e1c601c84f45dd Mon Sep 17 00:00:00 2001
> From: Stephen Kitt 
> Date: Mon, 7 Oct 2019 21:09:52 +0200
> Subject: [PATCH] Allow strong dependencies on X font packages

> The X server shipped in Debian no longer supports remote retrieval of
> fonts from an X font server, so it no longer makes sense to forbid
> packages from strongly depending on X font packages. On the contrary,
> since local fonts are now the only way for an X program to obtain its
> fonts, packages which require specific fonts to operate should depend
> on the corresponding font package. (This is already common practice
> for non-X font packages.)

> Closes: #941803
> Signed-off-by: Stephen Kitt 
> ---
>  policy/ch-customized-programs.rst | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)

> diff --git a/policy/ch-customized-programs.rst 
> b/policy/ch-customized-programs.rst
> index dbba4fc..dfe6ce4 100644
> --- a/policy/ch-customized-programs.rst
> +++ b/policy/ch-customized-programs.rst
> @@ -380,11 +380,10 @@ themselves.
>  1.  Fonts of any type supported by the X Window System must be in a
>  separate binary package from any executables, libraries, or
>  documentation (except that specific to the fonts shipped, such as
> -their license information). If one or more of the fonts so packaged
> -are necessary for proper operation of the package with which they
> -are associated the font package may be Recommended; if the fonts
> -merely provide an enhancement, a Suggests relationship may be used.
> -Packages must not Depend on font packages.  [#]_
> +their license information). Packages which require one or more of
> +the fonts thus packaged should Depend on the font package; if the
> +fonts merely provide an enhancement, a Recommends or Suggests
> +relationship may be used.  [#]_
>  
>  2.  BDF fonts must be converted to PCF fonts with the ``bdftopcf``
>  utility (available in the ``xfonts-utils`` package, ``gzip``\ ped,
> @@ -617,9 +616,11 @@ installed in ``/usr/share/man/man6``.
> Window System, however, must abide by this font policy.
>  
>  .. [#]
> -   This is because the X server may retrieve fonts from the local file
> -   system or over the network from an X font server; the Debian package
> -   system is empowered to deal only with the local file system.
> +   In the past, the X server could retrieve fonts from the local file
> +   system or over the network from an X font server, so packages were
> +   forbidden from declaring a Depends relationship with font
> +   packages. This is no longer the case: the X font server shipped in
> +   Debian no longer supports remote font retrieval.
>  
>  .. [#]
> Note that this mechanism is not the same as using app-defaults;

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

Bug#943356: no login in vm

[jnqnfe]

Package: gnome
Version: 1:3.30+2

Since the upgrade to Gnome 3.34 I no longer get a login prompt in a Sid
install within a VirtualBox VM. All I get is the background and a
cursor.

I reinstated from backup and found that I am forced to hold back the
gnome-desktop3-data package to the 3.30 version (iirc) in order to
prevent the problem surfacing.

I've been holding back from reporting it since for a brief period
during uploading of the 3.34 packages I experienced it on my host
install also which was corrected in the next batch of updates, but the
problem still remains in the VM.

Bug#943354: New upstream release

[Jonny Lamb]

Package: openconnect
Version: 8.02-1
Severity: wishlist

8.0.4 was released a few months ago, and has support for Pulse Connect Secure, 
which is something my company's VPN now requires. It'd be great for the package 
to be updated to at least that version.

Thanks,
-- 
Jonny Lamb

Bug#943355: audio broken

[jnqnfe]

Package: linux-image-amd64
Version: 5.3.7-1

I installed a weeks worth of updates to my Sid install yesterday and
having done so my audio output has been broken.

I'm not at all certain which package to target a bug report at, there
was nothing obvious to me in the set of updates, and it is still broken
even if rebooting into kernel v5.2 where it was fine previously, so
idk. I'm in the early stages of trying to research the dmesg entries
relating to it which seems to be suggesting some sort of config issue
created by an update... :/

dmesg:
[   18.011993] snd_hda_intel :00:1f.3: azx_get_response timeout,
switching to polling mode: last cmd=0x20270503
[   19.020034] snd_hda_intel :00:1f.3: No response from codec,
disabling MSI: last cmd=0x20270503
[   20.024002] snd_hda_intel :00:1f.3: No response from codec,
resetting bus: last cmd=0x20270503
...

Bug#943352: stretch-pu: package python-werkzeug/0.11.15+dfsg1-1

[Ondřej Nový]

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

Hi,

I would like to update python-werkezug in stretch to fix CVE-2019-14806,
see #940935. Uploaded to proposed-updates-new (0.11.15+dfsg1-1+deb9u1),
built and tested on stretch. Debdiff attached.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-werkzeug-0.11.15+dfsg1/debian/changelog 
python-werkzeug-0.11.15+dfsg1/debian/changelog
--- python-werkzeug-0.11.15+dfsg1/debian/changelog  2017-01-02 
11:08:13.0 +0100
+++ python-werkzeug-0.11.15+dfsg1/debian/changelog  2019-10-23 
18:08:38.0 +0200
@@ -1,3 +1,10 @@
+python-werkzeug (0.11.15+dfsg1-1+deb9u1) stretch; urgency=medium
+
+  * Unique debugger PIN in Docker containers
+(Closes: #940935, CVE-2019-14806)
+
+ -- Ondřej Nový   Wed, 23 Oct 2019 18:08:38 +0200
+
 python-werkzeug (0.11.15+dfsg1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-werkzeug-0.11.15+dfsg1/debian/patches/CVE-2019-14806.patch 
python-werkzeug-0.11.15+dfsg1/debian/patches/CVE-2019-14806.patch
--- python-werkzeug-0.11.15+dfsg1/debian/patches/CVE-2019-14806.patch   
1970-01-01 01:00:00.0 +0100
+++ python-werkzeug-0.11.15+dfsg1/debian/patches/CVE-2019-14806.patch   
2019-10-23 17:41:39.0 +0200
@@ -0,0 +1,28 @@
+From 00bc43b1672e662e5e3b8cecd79e67fc968fa246 Mon Sep 17 00:00:00 2001
+From: David Lord 
+Date: Tue, 14 May 2019 13:43:22 -0700
+Subject: [PATCH] unique debugger pin in Docker containers
+Origin: 
https://github.com/pallets/werkzeug/commit/00bc43b1672e662e5e3b8cecd79e67fc968fa246
+
+--- a/werkzeug/debug/__init__.py
 b/werkzeug/debug/__init__.py
+@@ -54,6 +54,19 @@
+ return rv
+ 
+ def _generate():
++# docker containers share the same machine id, get the
++# container id instead
++try:
++with open("/proc/self/cgroup") as f:
++value = f.readline()
++except IOError:
++pass
++else:
++value = value.strip().partition("/docker/")[2]
++
++if value:
++return value
++
+ # Potential sources of secret information on linux.  The machine-id
+ # is stable across boots, the boot id is not
+ for filename in '/etc/machine-id', '/proc/sys/kernel/random/boot_id':
diff -Nru python-werkzeug-0.11.15+dfsg1/debian/patches/series 
python-werkzeug-0.11.15+dfsg1/debian/patches/series
--- python-werkzeug-0.11.15+dfsg1/debian/patches/series 2017-01-02 
11:03:52.0 +0100
+++ python-werkzeug-0.11.15+dfsg1/debian/patches/series 2019-10-23 
18:02:19.0 +0200
@@ -1,2 +1,3 @@
 drop_ubuntu_font.patch
 0002-Use-local-copies-of-object.inv-for-building-document.patch
+CVE-2019-14806.patch

Bug#933266: nettle 3.5.1

[Niels Möller]

Daniel Kahn Gillmor  writes:

> any chance that we can get 3.5.1+really3.5.1 into unstable soon?  if
> not, can you tell me what might be blocking it?

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

(I don't know if the requested transition bug exists yet).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Bug#943344: plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification

[Martin Steigerwald]

Thread on debian-kde-Mailinglist:

Re: Transition of Qt to 5.12.5

https://lists.debian.org/debian-kde/2019/10/msg00033.html

Luca Pedrielli found this initially. I just reported the bug.

Thanks,
-- 
Martin

Bug#941793: nmu: libimobiledevice_1.2.1~git20181030.92c5462-1

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-10-22 at 17:12 +0200, Yves-Alexis Perez wrote:
> Unfortunately, I can't just revert the patch so that means basically reverting
> the whole stuff to the previous snapshot (I'm not too sure how well gbp handle
> that), dropping all the new hardware/software support.
> 
> I'll try that anyway and follow up with the soname bump dance (which likely
> means a trip to NEW with another delay).

Also, the ABI change introduced a new API function, which has been added to
the symbols file. I'm really unsure I can remove a function from the symbol
file without touching the soname itself…

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2wml0ACgkQ3rYcyPpX
RFtEgAf/fjHe5mH98VMhQ1Q7HXc325iBKe36+BrtnsAiaj9QVxC9h+5O1Ew5anSf
4fDafg6M4RzaPqgEoaFOwYM3iy91Ul3jRKVXWGcncyllVf+PFqdsCDAQhidbC3On
3+Fw9TC88qyzLekq/rsvLDPrvkYyPP7/tin9gRAjmiSg5pAVByE++5N4NLW1qAuQ
NtfV6b5qct6Et8yaoTArA6lhlvyZvJFWm+Ii78XBykhQiw8Bj4TomVJYsu8tl8dn
rpx7LkaZaeivgeVBVtPgrN6K62rQHC3cfnt/Rry05923tXuzRhdM6IJQKoKD7AUi
viJAHwyCR5enYvkJOA5POcfcznhvYA==
=ebbe
-END PGP SIGNATURE-

Bug#943351: linux-image-5.2.0-3-amd64: Instability leading to loss of control of the machine (have to power-shutdown)

[Emmanuel Charpentier]

Package: src:linux
Version: 5.2.17-1
Severity: important

Dear Maintainer,

I have intermittent losses of control of my X session, which gives the
following symptoms:
  - mouse appears active (the cursor follows trackpad movements), but can't act
(trackpad taps and trackpad-corners click are ineffective)
  - function keys ineffective (cant't switch to the system console)
  - the processes in the background work normally (e. g. audio/videeo streaming
continues normally, a computation launched in a terminal goes to its end).

This continues up to the time I force a power shutdown (>5s press on the power
button).

The hardware may be relevant : ASUS Zen book flip notebook (a.k. a. UX370U).

Previous attempts to understand this problem showed losses of ACPI devices
(among them the function keys. Successive upgrades of Gnome seem to have dried
up *this* source of instability.

I have a syslog extract of the latest episode, that I'll try to send along the
present report or in an answer to it.

   * What led up to the situation?

Following testing and accepting 5.x kernels

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

Reinstalling the last 4.19.x kernel

   * What was the outcome of this action?

: the system seems to be "more stable".


*** Syslog extract showing what was recorded during the last episode ***
***Attached here because it is only 109 lines long   ***

Oct 23 09:53:13 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:13 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:13 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:13 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:13 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:14 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:14 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:14 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:15 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:16 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:16 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:17 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:17 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:17 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:18 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:18 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:18 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:18 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:19 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: libpng warning: iCCP:
known incorrect sRGB profile
Oct 23 09:53:20 zen-book-flip chromium.desktop[1777]: 

Bug#933266: nettle 3.5.1

[Daniel Kahn Gillmor]

Hi Magnus--

I see that 3.5.1+really3.4.1 and 3.5.1+really3.5.1 are in
unstable and experimental, separately.

any chance that we can get 3.5.1+really3.5.1 into unstable soon?  if
not, can you tell me what might be blocking it?

i'm working on updating rust-nettle-sys (bindings for nettle in Rust),
which explicitly lists 3.5.1 as its target.

If there's a reason to avoid 3.5.1 in debian unstable for now, can you
point me to an explanation?

Thanks for maintaining nettle in debian,

  --dkg


signature.asc
Description: PGP signature

Bug#943350: RFS: nattable/1.5.0+dfsg-1 [ITP] -- high performance SWT data grid

[Vincent Prat]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-j...@lists.debian.org, debian-scie...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "NatTable":

* Package Name  : nattable
  Version               : 1.5.0+dfsg-1
  Upstream author   : NatTable developers 
* URL   : https://www.eclipse.org/nattable/
* License   : Eclipse Public License 1.0
  Programming language  : Java
  Description   : high-performace SWT data grid

NatTable is a powerful and flexible SWT table/grid widget that is built to 
handle very large data sets, real-time updates, dynamic styling, and more.
NatTable is a subproject of Nebula.

This package is a dependency of HDFView.

It builds the following binary package:

  libeclipse-nebula-widgets-nattable-core-java - core java library

To find the package, please visit the following URL:

  https://salsa.debian.org/java-team/nattable

Best regards,
Vincent Prat

Bug#943349: ITP: openxr-sdk-source -- openxr loader, basic API layers, and example code

[李健秋]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee (李健秋) 

* Package name: openxr-sdk-source
  Version : 1.0.0
  Upstream Author : The Khronos Group Inc
* URL : https://github.com/KhronosGroup/OpenXR-SDK-Source
* License : Apache2.0
  Programming Lang: C, C++, Python
  Description : openxr loader, basic API layers, and example code

 This package contains source code and build scripts for implementations
 of the OpenXR loader, validation layers, and code samples.

Bug#943348: open-iscsi: Ask for initiator name during install

[Christopher David Howie]

Package: open-iscsi
Version: 2.0.874-7.1
Severity: wishlist

(I am not sure if this is the correct package to report this to, or if
there is a separate package for the debian-installer component.  Please
reassign as appropriate.)

In the Debian installer, while editing partitions, one has a chance to
connect to iSCSI targets.  However, nowhere does the installer ask for
the iSCSI initiator name during this process.  Some targets require a
specific initiator name to be used (to avoid initiators discovering
devices that aren't relevant to them) and currently, using those targets
during installation requires switching to a secondary VT and manually
editing files.

It would be helpful for the installer to ask if a specific initiator
name is required, and then configure both the installer environment and
the target system to have that name.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.