Bug#974739: gnome-passwordsafe: Gnome-passwordsafe fails to open

[Henry-Nicolas Tourneur]

No problem, thanks for your feedback, it's appreciated.

Best regards,

-- 
Henry-Nicolas Tourneur
mxid: @hntourne:matrix.nilux.be

Le jeudi 19 novembre 2020 à 21:39 +0100, il a écrit :
> You are right. I completely forgot about that old pykeepass installation with
> pip.
> pip uninstall pykeepass solved the problem. Gnome-passwordsafe works very well
> now.
> My apologies for the confusion and thank you very much.
> 
> 
> On Sat, 14 Nov 2020 19:38:30 +0100 Henry-Nicolas Tourneur 
> wrote:
> > Thanks for the bug report.
> > 
> > From the stack trace you provided, it appears that you are not using the
> > Debian
> > distributed release of pykeepass but something installed from elsewhere (I
> > presume via pip). See this line: the path is local for user "il" not the
> > system
> > path which should be /usr/lib/python3/dist-packages/pykeepass
> > 
> > from pykeepass.exceptions import (
> > ImportError: cannot import name 'CredentialsError' from
> > 'pykeepass.exceptions'
> > (/home/il/.local/lib/python3.8/site-packages/pykeepass/exceptions.py)
> > 
> > 
> > There has been an unexpected change in the release 3.2.1 of pykeepass that
> > introduced some new exceptions. The version of gnome-passwordsafe packaged
> > in
> > Debian requires on pykeepass >= 3.2.1 so that those exceptions exists.
> > 
> > I presume your locally installed version of pykeepass is older than 3.2.1.
> > Can you please make sure that you are using the Debian package for pykeepass
> > and
> > let me know if this problem persists?
> > 
> > Best regards,
> > 
> > 
> > -- 
> > Henry-Nicolas Tourneur
> > mxid: @hntourne:matrix.nilux.be
> > 
> > 
> > 

Bug#975297: buster-pu: package tor/3.5.12-1

[Peter Palfrader]

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

Hi!

Stable currently has Tor 0.3.5.10.

Upstream released 0.3.5.11 and 0.3.5.12 since, which bring some security
fixes, update the list of fallback directory servers, and a few things
more.

See https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.5.12
for a full list.

I would like to build and upload packages for tor 3.5.12.

Please ack?
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#975296: spl-dkms: Unable to locate dkms.conf file

[Kyle Robbertze]

Package: spl-dkms
Version: 0.7.12-2+deb10u1
Severity: important

Dear Maintainer,

spl-dkms on stable curently causes linux-image-4.19.0-11-amd64 to fail
to configure with the following error:

Setting up linux-image-4.19.0-11-amd64 (4.19.146-1) ...
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-11-amd64
/etc/kernel/postinst.d/dkms:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/spl/0.6.5.9/source/dkms.conf does not exist.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-4.19.0-11-amd64 (--configure):
 installed linux-image-4.19.0-11-amd64 package post-installation script
subprocess returned error exit status 1

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

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

Versions of packages spl-dkms depends on:
ii  dkms  2.6.1-4
ii  file  1:5.35-4+deb10u1
ii  libc6-dev [libc-dev]  2.28-10
ii  libelf-dev0.176-1.1
ii  lsb-release   10.2019051400

spl-dkms recommends no packages.

Versions of packages spl-dkms suggests:
ii  linux-libc-dev  4.19.152-1
ii  spl 0.7.12-2+deb10u1

-- no debconf information

Bug#973038: update on ppc64el QEMU autopkgtest

[Ryutaroh Matsumoto]

Summary: After building a ppc64el QEMU testbed, I met a similar symptom to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40

From: Simon McVittie 
Subject: Re: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI
Date: Sun, 15 Nov 2020 18:49:36 +
> * #926945 (ppc64el UEFI)
>   - needs a small PReP partition for the firmware
>   - needs a special flag on that partition, with a vmdb2 patch that hasn't
> been reviewed or merged yet

As vmdb2 for ppc64el is not ready, I wrote a custom script to build a
QEMU autopkg testbed with GPT partitioning at

https://github.com/emojifreak/qemu-arm-image-builder/blob/main/README.md#build-gpt-autopkgtest-qemu-debiansh

The built testbed works fine for amd64 architecture, and for arm64 it reproduces
the same symptom as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40

So I assume the script is OK... The built testbed for ppc64el is placed at
http://153.240.174.134:64193/tmp/autopkgtest-sid-ppc64el.qcow2
(300 MB qcow2 file with 25 GB disk image)

Since qemu-system-ppc64le does not have any serial port, we have to modify
autopkgtest-virt-qemu to give serial ports to VM, as the first attachment
(diff is against "apt-get source autopkgtest/sid"), which is similar to the one 
required
for arm64 architecture.

Then I consistently got
autopkgtest-virt-qemu: DBG: execute-timeout: 
/tmp/autopkgtest-qemu.z8ii9cut/runcmd true
autopkgtest-virt-qemu: DBG: can connect to autopkgtest sh in VM
autopkgtest-virt-qemu: DBG: determine_normal_user: no uid in [1000,5] 
available

which is strange as /etc/passwd in the testbed has

debci:x:106:65534::/home/debci:/bin/sh
user:x:1000:1000::/home/user:/bin/sh

The full log is attached as the second attachment.

I think I identified what are required for vmdb2 to handle ppc64el GPT 
partition.
I will send my view to bts #973467

Best regards, Ryutaroh
--- autopkgtest-5.15/virt/autopkgtest-virt-qemu 2020-10-27 05:27:25.0 
+0900
+++ /usr/bin/autopkgtest-virt-qemu  2020-11-20 12:20:54.356207762 +0900
@@ -577,12 +577,34 @@
 '-net', 'user' + nic_opt,
 '-object', 'rng-random,filename=/dev/urandom,id=rng0', '-device', 
'virtio-rng-pci,rng=rng0,id=rng-device0',
 '-monitor', 'unix:%s/monitor,server,nowait' % workdir,
-'-serial', 'unix:%s/ttyS0,server,nowait' % workdir,
-'-serial', 'unix:%s/ttyS1,server,nowait' % workdir,
 '-virtfs',
 
'local,id=autopkgtest,path=%s,security_model=none,mount_tag=autopkgtest' % 
shareddir,
 '-drive', 'file=%s,cache=unsafe,if=virtio,index=0,format=qcow2' % 
overlay]
 
+if 'qemu-system-aarch64' in args.qemu_command or 'qemu-system-arm' in 
args.qemu_command or "arm" in os.uname()[4] or "aarch64" == os.uname()[4]:
+argv.append('-machine')
+argv.append('virt')
+argv.append('-cpu')
+argv.append('max')
+argv.append('-chardev')
+argv.append('socket,id=ttyS0,path=%s/ttyS0,server,nowait' % workdir)
+argv.append('-chardev')
+argv.append('socket,id=ttyS1,path=%s/ttyS1,server,nowait' % workdir)
+argv.append('-device')
+argv.append('pci-serial-2x,chardev1=ttyS0,chardev2=ttyS1')
+elif 'qemu-system-ppc64' in args.qemu_command:
+argv.append('-chardev')
+argv.append('socket,id=ttyS0,path=%s/ttyS0,server,nowait' % workdir)
+argv.append('-chardev')
+argv.append('socket,id=ttyS1,path=%s/ttyS1,server,nowait' % workdir)
+argv.append('-device')
+argv.append('pci-serial-2x,chardev1=ttyS0,chardev2=ttyS1')
+else:
+argv.append('-serial')
+argv.append('unix:%s/ttyS0,server,nowait' % workdir)
+argv.append('-serial')
+argv.append('unix:%s/ttyS1,server,nowait' % workdir)
+
 if args.efi:
 code = None
 data = None
@@ -597,14 +619,18 @@
 elif 'qemu-system-arm' in args.qemu_command:
 code = '/usr/share/AAVMF/AAVMF32_CODE.fd'
 data = '/usr/share/AAVMF/AAVMF32_VARS.fd'
+elif 'qemu-system-ppc64' in args.qemu_command:
+code = '/dev/null'
+data = '/dev/null'
 else:
 VirtSubproc.bomb('Unknown architecture for EFI boot')
 
-shutil.copy(data, '%s/efivars.fd' % workdir)
-argv.append('-drive')
-argv.append('if=pflash,format=raw,read-only,file=' + code)
-argv.append('-drive')
-argv.append('if=pflash,format=raw,file=%s/efivars.fd' % workdir)
+if not 'qemu-system-ppc64' in args.qemu_command:
+shutil.copy(data, '%s/efivars.fd' % workdir)
+argv.append('-drive')
+argv.append('if=pflash,format=raw,read-only,file=' + code)
+argv.append('-drive')
+argv.append('if=pflash,format=raw,file=%s/efivars.fd' % workdir)
 
 for i, image in enumerate(args.image[1:]):
 # TODO: Ideally we would specify format= for these rather than
autopkgtest [15:54:3

Bug#975295: RFS: dde-qt5integration/5.1.0.5-1~exp1 -- Qt5 theme integration for Deepin application

[Arun Kumar Pariyar]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dde-qt5integration":

 * Package name: dde-qt5integration
   Version : 5.1.0.5-1~exp1
   Upstream Author : https://github.com/linuxdeepin/qt5integration/issues
 * URL : https://github.com/linuxdeepin/qt5integration
 * License : BSD-3-Clause, LGPL-2.1 or LGPL-3, and 
Qt-LGPL-exception-1.1, GPL-3+, LGPL-3 or GPL-2+
 * Vcs : https://salsa.debian.org/pkg-deepin-team/dde-qt5integration
   Section : libs

It builds those binary packages:

  dde-qt5integration - Qt5 theme integration for Deepin application

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

  https://mentors.debian.net/package/dde-qt5integration/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dde-qt5integration/dde-qt5integration_5.1.0.5-1~exp1.dsc

Changes since the last upload:

 dde-qt5integration (5.1.0.5-1~exp1) experimental; urgency=medium
 .
   [ Arun Kumar Pariyar ]
   * New upstream release 5.1.0.5.
   * debian/control:
 + Add libdtkgui-dev to Build-Depends.
 + Add qt5dxcb-plugin | dde-qt5dxcb-plugin in binary package Depends.
 + Add Arun Kumar Pariyar to Uploaders.
 + Declare compatible with libdtkwidget-dev (>=5)~.
   * debian/copyright: Update license information.
   * debian/patches: Drop patches, no longer required.
   * debian/rules: Add CHANGELOG.md to override_dh_installchangelogs.
 .
   [ Boyuan Yang ]
   * debian/control: Declare compatible with libdtkwidget-dev (>=5)~.

Regards,
--
  Arun Kumar Pariyar



OpenPGP_0x4B542AF704F74516.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975294: RFS: deepin-qt5dxcb-plugin/5.0.17+ds.1-1~exp1 -- Qt platform theme integration plugin for DDE

[Arun Kumar Pariyar]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "deepin-qt5dxcb-plugin":

 * Package name: deepin-qt5dxcb-plugin
   Version : 5.0.17+ds.1-1~exp1
   Upstream Author : https://github.com/linuxdeepin/qt5platform-plugins/issues
 * URL : https://github.com/linuxdeepin/qt5platform-plugins
 * License : HPND-sell-variant, LGPL-3 or GPL-2+ or GPL-3+, GPL-3+, 
Expat and MIT-open-group
 * Vcs : 
https://salsa.debian.org/pkg-deepin-team/deepin-qt5dxcb-plugin
   Section : libs

It builds those binary packages:

  dde-qt5xcb-plugin - Qt platform theme integration plugin for DDE

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

  https://mentors.debian.net/package/deepin-qt5dxcb-plugin/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-qt5dxcb-plugin/deepin-qt5dxcb-plugin_5.0.17+ds.1-1~exp1.dsc

Changes since the last upload:

 deepin-qt5dxcb-plugin (5.0.17+ds.1-1~exp1) experimental; urgency=medium
 .
   [ Dmitry Shachnev ]
   * debian/patches: Add a patch for Qt 5.14.2 support.
 .
   [ Arun Kumar Pariyar ]
   * New upstream release 5.0.17.
   * debian/control:
 + Bump Standards-Version to 4.5.0.
 + Bump debhelper-compat to v13.
 + Add Arun Kumar Pariyar to Uploaders.
 + Replace qt5dxcb-plugin with dde-qt5xcb-plugin.
   * debian/patches:
 + Add patch for Qt 5.15.1 support.
 + Drop patch libqt5xcbqpa-dev-Add-support-for-Qt-5.12.5
   as its already patched by upstream.
   * debian/copyright: Update license information.
   * debia/README.source: Update that wayland support was dropped.

Regards,
--
  Arun Kumar Pariyar



OpenPGP_0x4B542AF704F74516.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975293: RFS: dde-qt-dbus-factory/5.2.0.29-1~exp1 -- Qt DBus interface library for Deepin software (shared library)

[Arun Kumar Pariyar]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dde-qt-dbus-factory":

 * Package name: dde-qt-dbus-factory
   Version : 5.2.0.29-1~exp1
   Upstream Author : https://github.com/linuxdeepin/dde-qt-dbus-factory/issues
 * URL : https://github.com/linuxdeepin/dde-qt-dbus-factory
 * License : LGPL-2.1 or LGPL-3, GPL-3+, LGPL-2.1+
 * Vcs : 
https://salsa.debian.org/pkg-deepin-team/dde-qt-dbus-factory
   Section : devel

It builds those binary packages:

  libdframeworkdbus2 - Qt DBus interface library for Deepin software (shared 
library)
  libdframeworkdbus-dev - Qt DBus interface library for Deepin software 
(development files)

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

  https://mentors.debian.net/package/dde-qt-dbus-factory/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dde-qt-dbus-factory/dde-qt-dbus-factory_5.2.0.29-1~exp1.dsc

Changes since the last upload:

 dde-qt-dbus-factory (5.2.0.29-1~exp1) experimental; urgency=medium
 .
   [ Arun Kumar Pariyar ]
   * New upstream release 5.2.0.29.
   * debian/copyright: Update copyright info.
   * debian/patches: Add patch to use relative path
 in python generate_code.
 .
   [ Tu Qinggang ]
   * debian/control:
 + Add Tu Qinggang to the uploader list.

Regards,
--
  Arun Kumar Pariyar



OpenPGP_0x4B542AF704F74516.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975119: RFS: cglm/0.7.9-1 -- Optimized OpenGL Mathematics library for C

[Jordan Justen]

On 2020-11-19 01:01:28, Leon Marz wrote:
> 
>  cglm (0.7.9-1) unstable; urgency=medium
>  .
>* New upstream release
>* Bump Standards-Version to 4.5.1

This Standards-Version is not yet recognized by lintian. You can
verify this with lintian, and it is also shown in the lintian section
on mentors:

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

The debian sid package page also lists 4.5.0:

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


signature.asc
Description: signature

Bug#975292: RFS: dtkwidget/5.2.2.10-1~exp1 -- Deepin Tool Kit Widget library utilities

[Arun Kumar Pariyar]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dtkwidget
   Version : 5.2.2.10-1~exp1
   Upstream Author : https://github.com/linuxdeepin/dtkwidget/issues
 * URL : https://github.com/linuxdeepin/dtkwidget
 * License : GPL-2+, LGPL-3+, GPL-3+
 * Vcs : https://salsa.debian.org/pkg-deepin-team/dtkwidget
   Section : libs

It builds those binary packages:

  libdtkwidget5-bin - Deepin Tool Kit Widget library utilities
  libdtkwidget5 - Deepin Tool Kit Widget library
  libdtkwidget-dev - Deepin Tool Kit Widget library (development files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dtkwidget/dtkwidget_5.2.2.10-1~exp1.dsc

Changes since the last upload:

 dtkwidget (5.2.2.10-1~exp1) experimental; urgency=medium
 .
   [ Hu Feng ]
   * New upstream release 5.2.2.10.
   * debian/control
 + Add Hu Feng to the uploaders list.
 + Add libcups2-dev to Build-Depends.
 + Add libcups2-dev to Depends in libdtkwidget-dev package.
 + Add libdframeworkdbus2 to Depends in libdtkwidget5 package.
 + Delete libdframeworkdbus-dev (>= 1.0~) in Build-Depends.
 + Delete librsvg2-dev in Build-Depends
 .
   [ Arun Kumar Pariyar ]
   * debian/copyright: Update license information.

Regards,
--
  Arun Kumar Pariyar



OpenPGP_0x4B542AF704F74516.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#936805: kodi: Python2 removal in sid/bullseye

[Vasyl Gello]

Control: fixed -1 19.0~alpha3+dfsg1-1
Control: close -1

Dear colleagues,

19.0 Alpha3 is fully compatible with Python3 and I expect Beta1 to be uploaded 
to unstable as tgere will be no API changes by upsrream as promised.
Closing this bug manually because I forgot mentionung it in a changelog at a 
time of upload.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#975291: postgresql-common: pg_upgradecluster ignores conf.d files

[Matt Cain]

Package: postgresql-common
Version: 223.pgdg100+1
Severity: normal

pg_createcluster has an option to include this line in postgresql.conf:
include_dir = 'conf.d'

pg_upgradecluster doesn't copy the files in conf.d to the new cluster

I needed to copy the files manually after the upgrade and restart the
cluster.

this is similar / related to bug #960789


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
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 postgresql-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  lsb-base  10.2019051400
ii  perl  5.28.1-6+deb10u1
ii  postgresql-client-common  223.pgdg100+1
ii  ssl-cert  1.0.39
ii  ucf   3.0038+nmu1

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.44.5-1+deb10u3
ii  logrotate  3.14.0-4

Versions of packages postgresql-common suggests:
pn  libjson-perl  

-- Configuration Files:
/etc/apt/apt.conf.d/01autoremove-postgresql changed:
// NO NOT EDIT!
// File maintained by /usr/share/postgresql-common/pg_updateaptconfig.
//
// Mark all PostgreSQL packages as NeverAutoRemove for which PostgreSQL
// clusters exist. This is especially important when the "postgresql" meta
// package changes its dependencies to a new version, which might otherwise
// trigger the old postgresql-NN package to be automatically removed, rendering
// the old database cluster inaccessible.
APT
{
  NeverAutoRemove
  {
"^postgresql.*-13";
  };
};


-- debconf information:
  postgresql-common/catversion-bump:
  postgresql-common/obsolete-major:
  postgresql-common/ssl: true

Bug#975290: tweeper: report an error when an Instagram/Facebook/etc account doesn't exist

[Paul Wise]

Package: tweeper
Version: 1.4.2-1
Severity: important
When I try to download the RSS for an Instagram account that does not
exist, tweeper just returns an empty RSS feed and exits with success.

When I try to download the RSS for a Facebook account that does not
exist, tweeper prints a "Page not found" feed and exits with success.

I assume that there are similar issues with all of supported sites.

Instead it should return an error on stderr and exit with a failure,
for each of the different websites that are supported.

This change is essential for RSS readers like Liferea where the error
would show up in the Liferea GUI, otherwise folks in this situation
will not notice the error and only investigate when they seem to think
that they are missing some posts from some feeds.

   $ tweeper https://www.instagram.com/asfddasdfasdfasdfasdf/ ; echo $?
   
   https://instagram.com";>
 
   Tweeper
   Instagram / 
   https://instagram.com/
   
 
   
   0
   
   $ tweeper https://www.facebook.com/asfddasdfasdfasdfasdf/ ; echo $?
   
   https://facebook.com";>
 
   Tweeper
   Page not found | Facebook
   
   
   
 Page not found | Facebook
 
 
   
 
   
   0
   
-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tweeper depends on:
ii  php-cli  2:7.4+76
ii  php-common   2:76
ii  php-curl 2:7.4+76
ii  php-symfony-property-access  4.4.14+dfsg-1
ii  php-symfony-serializer   4.4.14+dfsg-1
ii  php-xml  2:7.4+76
ii  php7.4-cli [php-cli] 7.4.11-1
ii  php7.4-curl [php-curl]   7.4.11-1
ii  php7.4-json [php-json]   7.4.11-1
ii  php7.4-xml [php-xml] 7.4.11-1

tweeper recommends no packages.

Versions of packages tweeper suggests:
pn  libapache2-mod-php | php-cgi  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#975029:

[Nick Black]

I will get with upstream and submit a patch to bring them up to speed with
the 2.0 api. At that point, the package ought be buildable in unstable
against libnotcurses1, and will also build from libnotcurses2. Thanks for
the heads-up!

-- 
nick black 
to make an apple pie from scratch, one need first invent a universe.

Bug#975288: audacious: new upstream 4.0.5

[Jonatan Nyberg]

Package: audacious
Version: 4.0.5
Severity: Normal

Please consider to upgrade to the current upstream version (4.0.5).

Regards
Jonatan

Bug#971515: Status as of last tech-ctte meeting

[Elana Hashman]

On Wed, Nov 18, 2020 at 11:36:09AM -0600, Gunnar Wolf wrote:
> ...
> I'm pasting here a bit of the discussion that happened later during
> the meeting: having this discussion K8S-specific, Elana mentioned that
> "that is a big part of the tension. sometimes, you have an upstream
> where the authors are less resourced and responsive than the
> downstream. this case is almost certainly the opposite".

To better illustrate this quote, I agreed to provide more context on the
scale of the Kubernetes project.

Kubernetes is a very large and active project. It has about 600
members,[0] 1000 voters,[1] 100 committers (which I define as members of
the milestone-maintainers team),[2] and over 50,000 contributors.[3] The
project has its own security[4] and release teams,[5] and the release
team includes a software licensing team. I am a SIG Chair and milestone
maintainer in the upstream Kubernetes project, which is comparable to
being a team lead and uploading developer in Debian.

As such, the scale of Kubernetes is similar to that of Debian itself.
Kubernetes as an upstream project is much better resourced than the
single downstream maintainer in Debian.

[0]: https://github.com/orgs/kubernetes/people
[1]: 
https://github.com/kubernetes/community/blob/8bdeb0a4d6e7a3fc9afdb874aa2cefa2ba88bc9c/events/elections/2020/voters.md
[2]: 
https://github.com/kubernetes/org/blob/adc0166a081ec7a613ebc8422d9676ff4035fc31/config/kubernetes/sig-release/teams.yaml#L17-L141
[3]: https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1
[4]: https://github.com/kubernetes/security
[5]: https://github.com/kubernetes/community/tree/master/sig-release

> At this point, we found some friction as to _what_ we are discussing
> on: Is this bug specifically on Kubernetes, which should be taken as a
> special case? Or would we try to rule as the Technical Committee on
> vendoring in general in the Debian ecosystem? Elana repeated her
> assurance that the Kubernetes team is thorough in their
> freeness-checking and security practices; I insisted on "not
> discussing about K8S, but about a bundling practice to which K8S
> subscribes".

The scope of the bug as submitted is limited to the Kubernetes package.
I think it is better to try to limit our decision to that scope, as
Kubernetes is not comparable to a single-maintainer Golang project that
might have a similar number of vendored dependencies.

The resourcing and scale of the Kubernetes project gives us better
assurances that upstream has done due diligence for dependency
management. I don't think we could assume this for an arbitrary package.

Per yesterday's TC discussion,[6] I think it makes sense to handle
Kubernetes with consideration to its size and importance to users,
similar to how we special-case Firefox.

- e

[6]: 
http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-11-18-17.58.html


signature.asc
Description: PGP signature

Bug#975287: RFP: rust-clippy -- lints to catch common mistakes and improve Rust code

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: rust-clippy
  Version : 1.47.0
  Upstream Author : The Rust Project Developers
* URL : https://github.com/rust-lang/rust-clippy
* License : Apache-2.0 OR MIT
  Programming Lang: Rust
  Description : lints to catch common mistakes and improve Rust code

A collection of lints to catch common mistakes and improve your Rust code.

There are over 400 lints included in this crate!

Lints are divided into categories, each with a default lint level. You can 
choose how much Clippy is supposed to annoy help you by changing the lint level 
by category.

The lint list also contains "restriction lints", which are for things which are 
usually not considered "bad", but may be useful to turn on in specific cases. 
These should be used very selectively, if at all.

Bug#975286: RM: node-fn.name -- ROM; not needed

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal

Hello,

I am maintaining node-fn.name inside JavaScript team, and I would like
to request its removal:

* The package can be drop-in replaced with node-fn-name, which is better
maintained upstream;
* No reverse dependencies.

Thanks,
Andrius



signature.asc
Description: OpenPGP digital signature

Bug#975277: postgis: autopkgtests missing "skippable" keyword

[Sebastiaan Couwenberg]

Control: tags -1 pending
Control: fixed -1 postgis/3.1.0~alpha1+dfsg-1~exp5

This was already fixed in the experimental branch, the fix for unstable
will be uploaded soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Elana Hashman]

On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote:
> 
> On Wed, 18 Nov 2020 at 23:33, Josh Triplett  wrote:
> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> > Even if someone else offers to shoulder some of that load, that does not
> > eliminate the maintenance burden; in some cases, it may not even reduce
> > the maintenance burden.
> 
> Thank you for this.  This puts into very straightforward words a
> feeling I've had for ages but couldn't word well.
> 
> In many projects I maintain outside Debian, I very frequently see this
> belief that if someone else contributes the work to make something
> possible (or it is otherwise perceived as "trivial" work), that
> there's no work for the maintainer, when it actually *does* increase
> the maintenance burden, often in ways the contributor cannot or will
> not see (or in some extreme cases, refuses to).

I caution folks from speculating too much on the maintainer's
motivations and reasoning while they haven't yet had a chance to share
their perspective on the bug. :)

From what I can see reading through both #964139 and #960780, no
technical rationale has been given for why the script was removed, only
a statement that the removal was intentional.[0]

It would be much appreciated if Michael Biebl or another maintainer from
the Utopia team could add some context here.

- e

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62


signature.asc
Description: PGP signature

Bug#969319: wifi cannot connect after combined suspend & gateway reboot

[Andrew Zaborowski]

Hi,
NM's master branch has changes related to IWD hidden SSID support and
there's a possibility that it's working reliably.  Unfortunately the
changes didn't make it into the upcoming 1.28.0 so they'll probably
only be in 1.30.0 which may be a long time off.

Best regards

Bug#975282: RFP: obs-v4l2sink -- OBS Studio plugin providing output capabilities to a Video4Linux2 device

[gregor herrmann]

On Fri, 20 Nov 2020 02:34:43 +0100, Martin wrote:

> * Package name: obs-v4l2sink
>   Version : 0.1.0 (or git master)
>   Upstream Author : Han-Tai Chen (CatxFish)
> * URL : https://github.com/CatxFish/obs-v4l2sink
> * License : GPL2+
>   Programming Lang: C++
>   Description : OBS Studio plugin providing output capabilities to a 
> Video4Linux2 device

Cf. #960342

TL;DR: obs-v4l2sink upstream is inactive but the functionality is
(already available in the Windows version and) about to be included
in the Linux version.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Paul Wise]

On Fri, 2020-11-20 at 03:14 +0100, Jonas Smedegaard wrote:

For fonts where large coverage is a priority I think we should
ideally list explicitly all languages that are _fully_ covered. Fonts
covering more languages than reasonable to list in a package
description
should then be split into one package per (large coverage) language
group.

I guess that works in the cases where the font files themselves are
already split up into language groups, but does that happen often?

For large lists of languages, perhaps joining them into one paragraph
rather than one per line would be a good idea to save space but still
allow for searches to work.

Because someone interested in displaying glyphs for a specific
language is not really helped to be informed that "lots of lanugages
are
covered" and only slightly better to know that "languages in your
language
family is covered".

This is reminding me of Fedora's work on adding font name, language and
script metadata to their package manager, so something like this works:

rpm install "font:name:Jetbrains Mono" font:language:dk

IIRC appstream is what that morphed into and it looks like the Debian
appstream metadata contains per-locale coverage information as well as
font names for each font package in Debian. I'm not sure how to use
appstreamcli to find a font using this data though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#975285: ITP: deepin-repair-tools -- Deepin system repair tools

[hufeng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-de...@lists.debian.org


* Package name : deepin-repair-tools
  Version  : 5.0.1
  Upstream Author  : 石博文 
* URL  : https://github.com/linuxdeepin/deepin-repair-tools
  License  : GPL-3+
  Programming Lang : C++
  Description  : Deepin system repair tools

Deepin Repair Tools is a useful tools for system repair and clean.
.
It is part of Deepin software and DDE (Deepin Desktop Environment).
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#975284: calibre: crashes on start

[Hor Jiun Shyong]

Subject: calibre: crashes on start
Package: calibre
Version: 5.5.0+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
After upgrading to version 5.5.0+dfsg-1,  calibre crashes on start.

Error logs:
$calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 509, in main
app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 122, in init_qt
app = Application(args, override_program_name=override,
windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 885, in __init__
from calibre_extensions import progress_indicator
ImportError: /usr/lib/calibre/calibre/plugins/progress_indicator.so:
undefined symbol: _Py_FatalErrorFunc


*** End of the template


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

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

Versions of packages calibre depends on:
ii  calibre-bin  5.5.0+dfsg-1+b1
ii  dpkg 1.20.5
ii  fonts-liberation 1:1.07.4-11
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  libjpeg-turbo-progs  1:2.0.5-1.1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils20.09.0-3
ii  python3  3.8.6-1
ii  python3-apsw 3.32.2-r1-1+b1
ii  python3-bs4  4.9.3-1
ii  python3-chardet  3.0.4-7
ii  python3-chm  0.8.6-2+b2
ii  python3-css-parser   1.0.4-2
ii  python3-cssselect1.1.0+ds-1
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-4
ii  python3-dbus 1.2.16-4
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b2
ii  python3-html5lib 1.1-2
ii  python3-lxml 4.6.1-1
ii  python3-markdown 3.3.3-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  0.6.2-1+b1
ii  python3-netifaces0.10.9-0.2+b2
ii  python3-pil  8.0.1-1
ii  python3-pkg-resources50.3.0-1
ii  python3-pygments 2.3.1+dfsg-4
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.1+dfsg-2+b2
ii  python3-pyqt5.qtsvg  5.15.1+dfsg-2+b2
ii  python3-pyqt5.qtwebengine5.15.1-1+b1
ii  python3-regex0.1.20200714-1+b1
ii  python3-routes   2.4.1-2
ii  python3-zeroconf 0.26.1-1
ii  xdg-utils1.1.3-2

Versions of packages calibre recommends:
ii  python3-dnspython  2.0.0-1
ii  udisks22.9.1-2

Versions of packages calibre suggests:
pn  python3-openssl   
pn  python3-unrardll  

-- no debconf information

Bug#975283: ITP: dde-printer -- Deepin system repair tools

[hufeng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-de...@lists.debian.org


* Package name : dde-printer
  Version  : 5.0.1
  Upstream Author  : 石博文 
* URL  : https://github.com/linuxdeepin/dde-printer
  License  : GPL-3+
  Programming Lang : C++
  Description  : Deepin system repair tools

Deepin Repair Tools is a useful tools for system repair & clean.
.
It is part of Deepin software and DDE (Deepin Desktop Environment).
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#974797: pocl: Please upgrade to llvm-toolchain-11

[Rebecca N. Palmer]

(libgpuarray maintainer)

This isn't testable in a qemu-armhf chroot, as pocl doesn't work there.

Do all the non-clblas tests pass?  (This can be checked by uninstalling 
libclblas-dev then running the tests - this will "error" the clblas 
tests but should at least not crash them.)


On 19/11/2020 14:39, Andreas Beckmann wrote:

It terminates with a segmentation fault in LLVM.


This is potentially an *LLVM* bug, as invalid input source code 
shouldn't crash the compiler, but that's less clear-cut when the 
compiler is being called as a library.


If it is, it doesn't seem to be known: there are no upstream LLVM bugs 
with this backtrace.



The CL kernel is a piece of generated source code created by the
(simplified) stack: python - libgpuarray - libclblas before it gets
handed over to pocl. While I managed to extract the CL kernel source, I


That's as expected.  Can you post this kernel source here?


#0  getEmissionKind () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/include/llvm/IR/DebugInfoMetadata.h:1244
#1  initialize () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LexicalScopes.cpp:53


Did you have libllvm10-dbgsym installed?  If not, does installing that 
give a more detailed backtrace?  (I suspect an invalid 'this', given 
that the crashing line accesses only a class member.)

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Jonas Smedegaard]

Quoting Paul Wise (2020-11-20 02:43:52)
> On Thu, Nov 19, 2020 at 6:54 PM Jonas Smedegaard wrote:
> 
> > I would indeed not use raw listings of more than 50 entries, but 
> > would try find ways to summarize the information most sensibly.
> 
> Would it be useful to (automatically) group large lists of languages 
> into families?
> 
> https://en.wikipedia.org/wiki/Language_family 
> https://en.wikipedia.org/wiki/List_of_language_families

I don't think listing language families really helps.

For fonts where large coverage is a priority I think we should ideally 
list explicitly all languages that are _fully_ covered. Fonts covering 
more languages than reasonable to list in a package description should 
then be split into one package per (large coverage) language group.

Because someone interested in displaying glyphs for a specific language 
is not really helped to be informed that "lots of lanugages are covered" 
and only slightly better to know that "languages in your language family 
is covered".

I still remember the mess in the 90's where danish ligatures were often 
missing even from commercial fonts, and would love if we could provide 
actually useful information about coverage.


 - 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#972477: #972477: mirror submission for mirror.bizflycloud.vn

[Trang Nguyen]

Hi,

I have just added tracefile matching my site name mirror.bizflycloud.vn 
and re-submit the mirror.


Please re-check mirror in this bug.

Thanks and regards.

---

Trang Nguyen

BizFly Cloud - Vietnam

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Paul Wise]

On Thu, Nov 19, 2020 at 6:54 PM Jonas Smedegaard wrote:

> I would indeed not use raw listings of more than 50 entries, but would
> try find ways to summarize the information most sensibly.

Would it be useful to (automatically) group large lists of languages
into families?

https://en.wikipedia.org/wiki/Language_family
https://en.wikipedia.org/wiki/List_of_language_families

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#975247: tracker.debian.org: displays deleted source package, when current binary package comes from another src pkg

[Paul Wise]

On Thu, Nov 19, 2020 at 2:51 PM Mattia Rizzolo wrote:

> remember that tracker is source-based
...
> supports package lookup prefixed with src: or bin:
...
> I would honestly oppose "hiding" and old source package

I think that makes this a wontfix bug, any further thoughts?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#975282: RFP: obs-v4l2sink -- OBS Studio plugin providing output capabilities to a Video4Linux2 device

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Multimedia Maintainers 

* Package name: obs-v4l2sink
  Version : 0.1.0 (or git master)
  Upstream Author : Han-Tai Chen (CatxFish)
* URL : https://github.com/CatxFish/obs-v4l2sink
* License : GPL2+
  Programming Lang: C++
  Description : OBS Studio plugin providing output capabilities to a 
Video4Linux2 device

>From README.md:

An OBS Studio plugin that provides output capabilities to a
Video4Linux2 device. It is basically a Linux version of obs-virtual-cam,
but only contains the video sink part. You can use it with
v4l2loopback to achieve cross-program video transfer between OBS
Studio and third party software supporting Video4Linux2, e.g. to present an OBS
session in proprietary browser-based conferencing systems by selecting the OBS
session as a webcam.

Bug#975281: mirror submission for mirror.bizflycloud.vn

[Nguyen Trang]

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

Submission-Type: new
Site: mirror.bizflycloud.vn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Nguyen Trang 
Country: VN Vietnam
Location: Vietnam
Sponsor: BizFly Cloud https://bizflycloud.vn/




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

Bug#975003: mount refuses to mount cifs from fstab with Unknown mount option "symfollow"

[Adam Williamson]

I think this has been reported and fixed in util-linux:
https://github.com/karelzak/util-linux/issues/1193
Updating Fedora to the util-linux with that fix backported seems to fix
the issue for me.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Bug#975230: [pkg-go] Bug#975230: golang-pault-go-ykpiv: FTBFS: src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be allocated in Go; it is incomplete (or unallocatable)

[Tianon Gravi]

On Thu, 19 Nov 2020 at 02:01, Lucas Nussbaum  wrote:
> > src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be 
> > allocated in Go; it is incomplete (or unallocatable)
> > src/pault.ag/go/ykpiv/ykpiv.go:569:11: _Ctype_struct_ykpiv_state can't be 
> > allocated in Go; it is incomplete (or unallocatable)

Looks like this was fixed upstream in
https://github.com/go-piv/go-ykpiv/pull/36, and a new release tagged
as 1.3.2, so Someone™ just needs to bump the package to 1.3.2 (and
probably do a quick "ratt" on it to make sure the revdeps still build
fine, but I imagine that's not a problem).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#975206: zurl: FTBFS: Error: need libzmq >= 2.0!

[Jan Niehusmann]

Control: reassign -1 libzmq3-dev 4.3.3-3
Control: forcemerge 975151 -1

This FTBFS was caused by a missing dependency in libzmq3-dev 4.3.3-3,
which was already fixed in libzmq3-dev 4.3.3-4.

On Thu, Nov 19, 2020 at 10:57:00AM +0100, Lucas Nussbaum wrote:
> Source: zurl
> Version: 1.11.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
[...]
> > Checking for Qt >= 5.2.0 ... yes
> > Checking for libzmq >= 2.0 ...
> >  * [pkg-config libzmq --exists]
> >  * returned: 1
> >  -> no
> > 
> > Error: need libzmq >= 2.0!

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Tianon Gravi]

(Going to leave my own opinions on the underlying discussion here
aside, but wanted to highlight/echo this bit:)

On Wed, 18 Nov 2020 at 23:33, Josh Triplett  wrote:
> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that package.
> Even if someone else offers to shoulder some of that load, that does not
> eliminate the maintenance burden; in some cases, it may not even reduce
> the maintenance burden.

Thank you for this.  This puts into very straightforward words a
feeling I've had for ages but couldn't word well.

In many projects I maintain outside Debian, I very frequently see this
belief that if someone else contributes the work to make something
possible (or it is otherwise perceived as "trivial" work), that
there's no work for the maintainer, when it actually *does* increase
the maintenance burden, often in ways the contributor cannot or will
not see (or in some extreme cases, refuses to).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#975280: ITP: prometheus-mqtt-exporter -- Prometheus exporter for metrics sent via MQTT topics

[Martina Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martina Ferrari 

* Package name: prometheus-mqtt-exporter
  Version : 0.1.4-1
  Upstream Author : Christoph Petrausch
* URL : https://github.com/hikhvar/mqtt2prometheus
* License : Expat
  Programming Lang: Go
  Description : Prometheus exporter for metrics sent via MQTT topics

 This exporter translates from MQTT topics to prometheus metrics, allowing
 small/IoT devices that can't be polled directly to be monitored.
 .
 Clients push metrics as abritrary JSON messages via MQTT to an MQTT Broker.
 This exporter subscribes to the broker and publish the received messages as
 prometheus metrics.
 .
 While the upstream project is called `mqtt2prometheus`, the Debian packaging
 uses the name `prometheus-mqtt-exporter` for consistency with other exporters.

Bug#724711: insighttoolkit4: Please add arm64 to the architecture list

[Wookey]

Source: insighttoolkit4
Followup-For: Bug #724711

I recently discovered that graviton cannot build on x86 because of an
indirect build-dependency on libinsighttoolkit4-dev, which is only
built for x86. I was just going to ask for other architectures to be
enabled, as it is debian policy to enable all arches and fix issues as
and when. But then I found this bug from 7 years ago and it seems that
this is not just an oversight.

As Ed has already discovered 5 years ago, this package already builds
on arm64. There is at least one test failure, but that is not a good
reason to not build the package. If builds are attempted then everyone
can see the status and the logs and can fix issues in either the tests
or the code as required.

You said back in 2013 that build failures on non-x86 arches prevented
the package entering testing. That does not make much sense, because
build failures only prevent migration if the package has previously
built succesfully on that architecture. Arches where it has never
worked should not matter for the purposes of migrating. Perhaps there
was an arch where it worked once but stopped at some point? 2013
predates arm64 so enabling that now should not cause a migration
problem.

So, can you please enable arm64 builds too, and if there are any
problematic tests we will investigate and work out if the test or the
code needs fixing. People need this package, and we should be building
it for them.

I would encourage you to enable other arches too, for the reasons
given above (at least 64-bit arches) but maybe try arm64 first and see
how it goes.

Cheers

--
Wookey

Bug#975273: RFP: nethack-vulture -- Isometric tiles interface for NetHack

[John Doe]

Package: wnpp
Severity: wishlist

* Package name: nethack-vulture
  Version : ?
  Upstream Author : ?
* URL : https://github.com/DanielT/Vulture
* License : Nethack General Public License
  Programming Lang: C++
  Description : Isometric tiles interface for NetHack

This is one of the best-looking GUIs for NetHack. I seem to remember it was in
Debian before, could not find any information about why it was removed, hope to
see it available again.

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Christian Kastner]

Hi Ryutaroh,

On 11/18/20 5:45 AM, Ryutaroh Matsumoto wrote:
> I made the attached patch against the latest upstream git source
> as attached. I also add "patch" tag to this bts.
> As far as I tested, the patch seems working well.
> I also added bind-mount of /proc and /dev/pts as recent version of
> grub seems to use them.

It's great to see progress with vmdb2 getting support for more
architectures, thank you for looking into this!

I haven't tested this version yet, but looking at the patch, I'd like to
two (minor) observations:

  * You could enhance the new "arch" field of the grub plugin by not
defaulting to amd64, but to the native host architecture. You can
get this using

subprocess.check_call(['dpkg', '--print-architecture'])

  * Instead of the generic Exception, you could raise
NotImplementedException when an unsupported architecture is
encountered

By the way, it would be really nice to eventually have example commands
for creating images in the documentation somewhere. Perhaps Lars is open
to extending README.md, or the manual, with some examples for other
architectures?

Best,
Christian

Bug#975279: mirror submission for mirror.lagoon.nc

[Tech]

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

Submission-Type: new
Site: mirror.lagoon.nc
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Tech 
Country: NC New Caledonia
Location: Noumea
Sponsor: OFFRATEL/LAGOON https://www.lagoon.nc/
Comment: Hi,
 
 i corrected the issues mentioned in the bug #971342
 Thanks for pointing that out.
 Regards




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

Bug#971515: Status as of last tech-ctte meeting

[Josh Triplett]

On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote:
> There are a lot of fascinating edge cases and precedents and philosophical
> questions about the function of a distribution here, and I think they
> rightfully attract a lot of energy, but I'm worried this is at the cost of
> losing sight of the core functionality provided by Debian.  Because that
> functionality is currently working, the people who are benefiting from it
> don't know to weigh in.
[...]
> As a Debian developer, I appreciate the arguments about vendoring and the
> desire to maintain Go libraries and the pride that we take in our work of
> really understanding software and packaging it properly.
> 
> However, as a Debian *user* of the kubernetes-client, I have to say that I
> do not care in the slightest.  The older, unvendored kubernetes-client
> package worked great.  The new, heavily vendored kubernetes-client package
> works great.  Both do exactly what I want, and I don't care at all, as a
> user, which is in Debian.  But if the package were removed from Debian, I
> would be really unhappy.  And if Helm and Argo CD were packaged for
> Debian, I would be much happier, so if unvendoring them is the obstacle,
> as a user I'm opposed to unvendoring!
> 
> I want to push back a bit against the feeling that some things are
> ill-suited for how Debian has historically packaged software and therefore
> maybe Debian isn't the place for them, and we should instead ask people to
> manage them outside of Debian (but somehow make this easy).
> 
> First, while I appreciate and cheer Phil and Sean's optimism, there have
> been a lot of plans in Debian historically to make something that isn't a
> package easy to build and install, and they have basically never worked.
> The way Debian makes something easy to build and install is by making it a
> package.  That's what our entire project is designed around, and I'm
> dubious that we're going to be able to reproduce those properties with
> something that isn't a package.
> 
> Second, the point of Debian at the end of the day is that I can install it
> on a computer and use it to get things done.  The details we're discussing
> here are important and work towards making Debian maintainable and
> sustainable and to ensure that a quality bar has been met in terms of
> security and legality and licensing, but I think it's important that they
> are also means to an end and the end is not security and licensing per se.
> We're not making a random collection of relatively secure software; we're
> giving people programs that they can run while keeping them secure.  We're
> not just a classification system for what software is free; we're giving
> people software they can use while ensuring that all of it is free.  I
> think it's worth occasionally stepping back and dwelling on that thought
> for a moment and making sure we're picking the right strategy for meeting
> our quality bar that allows us to still achieve the mission.
> 
> This is particularly true for something like vendoring or the avoidance of
> vendoring, which is not a core mission.  It's not in the social contract,
> and it's not a DFSG principle.  It's a hard-won and very valuable piece of
> experience with how best to sustainably make a distribution... but one
> that was hard-won in the era of C programs and shared libraries and that
> has generalized admirably to Perl and Python.  It may generalize to other
> languages and other mechanisms for distributing software.  It may not!  If
> it doesn't, that's significant because it's such a deeply-engrained part
> of our culture, but it's *not* a breach of our fundamental project goals.
> We can consider new approaches here without becoming untethered, and
> indeed may be able to achieve our primary goal *better* by expanding the
> scope of software that we can include in the distribution and that can
> therefore just work.
> 
> I think there's a bit of a crisis of confidence in Debian because of how
> much larger the free software ecosystem is now than it was when the
> project started, how far away from doing everything through a distribution
> a lot of developers have moved, and how many resources are flooding into
> other areas that we have difficulty keeping pace with.  One of the natural
> reactions to that crisis of confidence is to pull back from these new and
> difficult and unfamiliar areas and decrease scope to the things we know
> we're really good at: packaging primarily C, C++, Perl, and Python code.
> And that is a valid strategy; it's okay to just keep being very good at
> something one is already very good at.  But I think in the long term that
> means Debian becomes something much different than it historically has
> been.  It means Debian would become a base on which other people would
> build things, rather than a comprehensive collection of tools that covers
> all the incidental things you need from a computer, and where people need
> only reach outside of Debian for t

Bug#911428: New Customer Request...

[Dr Henrik Rawlings]

 - This mail is in HTML. Some elements may be ommited in plain text. -

Hello, Kindly confirm if you can ship to Australia and New Zealand.
Thanks
CEO
Dr Henrik Rawlings

© 2020
Henrik
Group Ltd. All Rights Reserved.



sent from my iPad

Bug#946251: Tests are failing since postgresql-common 208

[Christoph Berg]

> The test is failing because the Debian PostgreSQL environment has
> already moved to 12, but this package is still only available for 11,
> so some parts required to test it have already moved to 12.
> 
> I'm working on moving pg_config into the dependency cone of
> the postgresql-XX server package so it would be present whenever
> something depending on postgresql-XX would be tested.

This change has long happened, so I'm closing this bug now.

Christoph

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton  
wrote:
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > First, as a point of order (for which some authoritative guidance from
> > the Secretary, CCed, would potentially prove useful): while the
> > technical committee is empowered to handle various types of disputes (up
> > to and including overruling an individual developer if necessary), I do
> > not believe it falls within the scope of the technical committee to
> > override a decision already decided by a project-wide GR, or to
> > "interpret" the text of a GR issuing a nontechnical policy document in
> > ways that may undermine the decision made in that GR and document.  Any
> > interpretation of the text of the GR would need to be based on the text
> > and intent of the GR. (Intent could include discussion at the time, but
> > would notably include the text of other options that did not prevail, as
> > well as the status quo at the time that motivated a GR to change.)
> > Changing that intent would require either another GR, or (per specific
> > provisions included in the winning GR option) consensus among the
> > project, not a TC ruling.
> >
> > Concretely, the GR explicitly acted by "Using its power under
> > Constitution section 4.1 (5)", which is the power to "Issue, supersede
> > and withdraw nontechnical policy documents and statements.". The
> > Technical Committee does not have such "nontechnical policy documents
> > and statements" within its ambit. Any interpretation of 'what it means
> > to "support the efforts of developers" working on support for
> > alternative init systems' would thus be an interpretation of such a
> > nontechnical policy document.
> >
> > Thus, I would suggest that the technical committee should decline to
> > rule on any matters already decided by the GR. This does not preclude
> > the TC from offering advice, or potentially facilitating dispute
> > resolution if asked to do so, or even as a *last resort* overruling a
> > developer on a specific technical matter (if doing so does not go
> > against the GR), but I don't believe it's within the scope of the TC to
> > relitigate the GR to mandate support for alternative init systems. Any
> > potential ruling here would need to avoid attempting to supersede the
> > GR.
[...]
> In our dispute resolution role, the TC is empowered to decide upon the
> two things about the contents of the network-manager package that we
> have been asked to decide upon, as a matter of last resort.  No-one
> disputes that we can do this.

(I agree with this paragraph, in case there was any doubt about that.)

> We have also been invited to rule that "Similar init-compatibility
> changes should not be blocked by package maintainers unless they are
> defective on their own merits".  Essentially we are being invited to
> generalise the decision that we make about the network-manager package
> to say that it would apply to similar cases.
> 
> We might decide that the reasons we have for whatever decision we make
> about the network-manager package do not generalise, and so we may
> decline the invitation to make any more general ruling.
> 
> But if we do think the reasons generalise, then we can generalise our
> ruling without stepping outside of our dispute resolution role.  For
> example, we might say "if another CTTE bug was filed about the contents
> of a package which was similar to this one in the following respects
> ... then we would expect to issue the same ruling as we have here,
> because we believe that our reasons for this ruling would apply to all
> packages which are similar in the previously stated respects."
> 
> Clearly we would not want to say anything which we thought contravened
> the GR.  However, I do not think there is any reason to think that
> resolving this dispute would necessarily involve the TC interacting with
> the GR in a way that the constitution does not permit.  We are being
> asked to decide about one package, and being invited to generalise in a
> way that falls within the scope of our dispute resolution role.

It would certainly be *possible* for the TC to suggest that it would
systematically rule in favor of, to use these two issues as examples,
including init scripts and alternative dependencies despite the
maintainer not wishing to maintain them. What I'm suggesting is that,
given that the slate of GR options included possibilities that would
have required maintainers to do so by policy, and the developers
declined to enact such a policy, it would be *especially* unfortunate if
the common practice became to either systematically escalate to the TC
or use the threat of such to effectively enforce a different policy.

The GR encouraged people on all sides to collaborate in this area, not
to pick a side and do everything possible to undermine the other side.
It seems as though the current path thus far has been to present one
option, and when that option was declined, seek enforcement from the 

Bug#975278: ruby-asciidoctor-pdf: ruby-rouge should we introduced as a suggested package

[Salman Mohammadi]

Package: ruby-asciidoctor-pdf
Version: 1.5.0~alpha.17.dev-5
Severity: normal

Dear Maintainer,

The package `ruby-rouge` can enhance ruby-asciidoctor-pdf by using
`:source-highlighter: rouge` in the source code of the asciidoc file.

So it should be introduced a suggested package.


Cheers, Salman

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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

Versions of packages ruby-asciidoctor-pdf depends on:
ii ruby 1:2.5.1
ii ruby-asciidoctor 2.0.10-2~bpo10+1
ii ruby-concurrent 1.0.5-3
ii ruby-prawn 2.2.0+dfsg-1
ii ruby-prawn-icon 2.3.0-4
ii ruby-prawn-svg 0.28.0-3
ii ruby-prawn-table 0.2.2-1
ii ruby-safe-yaml 1.0.4-2
ii ruby-thread-safe 0.3.6-1
ii ruby-treetop 1.6.8-1

ruby-asciidoctor-pdf recommends no packages.

ruby-asciidoctor-pdf suggests no packages.

-- no debconf information

Bug#975075:

[Josh Triplett]

[I have consolidated responses to multiple bits of quoted text here, in
an effort to consolidate responses to variations on the same points, in
the hopes that doing so will avoid proliferating variations on a common
theme.

Also, the title of this bug itself presumes a disputed point of view.]

On Thu, 19 Nov 2020 11:40:20 + Ian Jackson 
 wrote:
> Josh Triplett writes:
> > I do not believe it falls within the scope of the technical
> > committee to override a decision already decided by a project-wide
> > GR,
> 
> No-one is asking the TC to override the GR.  In fact, Matthew is
> asking the TC to *implement* the GR.

> > One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
> > in large part, to settle with finality many ongoing case-by-case
> > disputes about alternative init system support,
> 
> I think that was the aim of the proponent.  Unfortunately, the winning
> option did not support that desire.

That is an adverse interpretation that I do not believe is supported by
either the text of the GR or the intentions of those voting for it.

I would also like to make the observation that, both during the voting
for the GR *and* shortly after the GR, people opposed to this GR
repeatedly stated that the winning option would allow package
maintainers to decline to support alternative init systems if they did
not wish to support a proposed change; some of those opposed to this GR
outcome even suggested that it would make systemd effectively mandatory.
(This has not turned out to be the case, in practice.) I find it
interesting that that was the stated interpretation used to oppose the
GR and subsequently bemoan the outcome, but yet now an alternative
interpretation surfaces that would paint the outcome as though there
were a *mandate* for maintainers to always support alternative init
systems.

To be clear: I don't believe the intent of the GR was for all package
maintainers to *systematically* remove init scripts or alternative init
support, and I don't believe that's what happened here. If I believed
that there was some ill intent here to destroy alternative init systems
(rather than simply a desire to avoid expending time and energy on
them), I would not look favorably on that. I also don't believe that the
intent of the GR was to *force* maintainers to merge alternative init
support. Given the evident desire of some package maintainers to avoid
expending effort in ongoing maintenance of support for alternative init
systems, it would have been desirable to seek alternatives that remove
that burden from the package maintainer, and shift it to those working
on alternative init systems. Instead, it appears that the moment a
package maintainer declined the solution that would be the least work
for those working on alternative init systems, the matter was escalated
to the TC rather than seeking alternatives.

To the extent the TC wishes to solve the more general problem rather
than the specific case, I would propose that honoring the intent of the
GR would be to request potential solutions that appropriately
compartmentalize the work of maintaining alterntive init support to
remove it entirely from the package maintainer. The TC does not do
detailed design work to generate alternatives that were not put before
it, but it would certainly be within the remit of the TC to request that
others do so, and to evaluate such alternatives if a consensus cannot be
reached. But as far as I can tell, there was *no* apparent effort to
propose any such alternatives; the matter was simply taken to the TC
once the first proposal was declined.

This is *not* as simple as "just merge the init script and Depends
change". It has also included other ongoing work each time a new
compatibility issue arises. Past evidence suggests that this has proven
to be a source of ongoing maintainer burden, despite claims to the
contrary.

> > or to "interpret" the text of a GR issuing a nontechnical policy
> > document in ways that may undermine the decision made in that GR and
> > document.
> 
> Obviously the TC ought not to undermine the GR.  What counts as
> undermining the GR and what counts as implementing appears to be a
> matter of debate.

So it would unfortunately seem. One would have hoped we were all debated
out after the GR, and that the GR could stand as evidence of the outcome
of that debate.

As stated in my previous mail, the *least* favored option in the GR vote
was "Further Discussion", and yet here we are, having Further
Discussion.

> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> 
> This is true of course.  But that is the key role of the maintainer.
> As recognised in the GR text.

The maintainer is also empowered to decide whether or not to include any
given change, if they deem the cost/benefit tradeoff inappropriate.

> > The GR encouraged developers to work with each other; it did not
> > *mandate* d

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton  
wrote:
> Hello,
> 
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > I'd also like to address one other issue here. It would be easy to
> > hypothesize, at this point, that some additional communication (or more
> > verbose communication) from the maintainer might have helped here.
> > However, I would express doubt that any more verbose version of "no"
> > (e.g. a long-form explanation about undesired additional maintenance
> > burden) would have led to any less escalation. I think the situation
> > would still have ended up here, no matter how much time or energy was
> > expended in writing responses.
> >
> > That seems particularly likely given the adversarial NMU directly
> > attempting to override an active package maintainer's decision, which
> > escalated the situation further. (Such adversarial NMUs have occurred in
> > regard to alternative init support in the past, as well.) And I don't
> > think anyone can reasonably suggest that they thought the change was
> > made unintentionally (given that it was explicitly mentioned in the
> > changelog), which makes the NMU a rather hostile escalation.
> >
> > I would ask anyone on the TC who feels that more verbose answers were
> > desirable whether they think a more verbose answer would have had any
> > effect on the outcome or subsequent escalations.
> 
> Assuming for a moment that the TC does not decline to rule, it is going
> to be very hard for us to make a good decision if we lack more detailed
> input from the package maintainer.

I'm not suggesting otherwise; I'm only asking the TC to refrain from
suggesting that further communication alone, prior to this point, would
have averted this situation. The original request makes such
implications, so they may potentially have formed part of what the TC
ruled on. (The TC does sometimes issue similar suggestions as part of
its rulings, in what I think is generally a *good* practice of
encouraging people to work things out and giving them guidance on how to
do so.)

> We can speculate as to whether the dispute would have proceeded better
> or worse with more verbose messages from Michael before now, but it
> would be beside the point.

Thank you; that fully addresses this particular point.

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

[Romain Francoise]

Hi Adam,

On Thu, Nov 19, 2020 at 9:31 PM Adam D. Barratt
 wrote:
> Please go ahead.

Thanks, uploaded.

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Marco d'Itri]

On Nov 19, Sven Joachim  wrote:

> I am not one of them, but AFAICS that would introduce a fatal circular
> dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
> configured before it can be unpacked, but libcrypt1 depends on libc6 so
> it cannot be configured before libc6 is at least unpacked.
Good point, you are right. :-(
Then we are up to plan B, which is a bit more complex but should still 
be approachable:

  Another option might be to have the new libc6 Conflict with old versions
  of Essential:yes packages that need libcrypt1, forcing those Essential:yes
  packages to get upgraded first. A quick check based on libcrypt1 reverse
  dependencies in sid shows perl-base, login and util-linux. I'm not sure
  if this list is exhaustive, though.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#974969: The "-full-screen" option causes guest display to overflow outside the host screen

[bakhelit]

After, further testing (basically 2 days of reading all QEMU docs and 
changelogs I found and messing around with various QEMU options:) I was 
able to solve my problems with the "-full-screen" option.


The solution was to add the following option to my QEMU command:

-display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on

The important bit that solved the display overflowing behavior is the 
"zoom-to-fit=on" suboption. This lets my VM to have the screen 
resolution I configure in it (e.g. 1920x1080) and when not in full 
screen mode it zooms the VM display to fit any QEMU window size without 
changing the screen resolution inside my VM. Although, the 
"-full-screen" option should probably work correctly on its own, so my 
solution is just a workaround.


Also, remember the problem with "-soundhw hda" option, which prevented 
VM from starting with QEMU version from Debian Backports 
(5.0-14~bpo10+1)? It seems to occur in a different way also in QEMU 
version from Debian Stable (3.1+dfsg-8+deb10u8). In QEMU version 
3.1+dfsg-8+deb10u8 my VM can start with the "-soundhw hda" option, but 
unfortunatelly the VM cannot produce any usable sound. I noticed there 
is already bug 949111 for this, so I described the details I observed in 
that bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949111#15).


Finally, the initial delay on VM start is still there and it still 
shortens after repeated VM starts.


Taken together, I guess QEMU is now usable enough for me on Debian 10, 
but it could be better if at least some of the problems I described are 
fixed properly.


Anyway, here is my QEMU test command (updated with the display 
overflowing workaround) if someone wants to try reproduce and debug the 
problems I described (it is single line in case email reformats it):


QEMU_PA_SERVER='/run/user/1000/pulse/native' QEMU_AUDIO_DRV='pa' 
qemu-system-x86_64 -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on 
-full-screen -enable-kvm -machine type=q35,accel=kvm -soundhw hda 
-netdev user,id=vnet -device e1000,netdev=vnet -cpu host -smp cores=2 -m 
2048 -drive file=DISK.raw,format=raw,index=0,media=disk -drive 
file=IMAGE.iso,index=2,media=cdrom


Regards
Bakhelit

Bug#975277: postgis: autopkgtests missing "skippable" keyword

[Gianfranco Costamagna]

Source: postgis
Version: 3.0.2+dfsg-4
Severity: serious
tags: patch


Hello, doing exit 77 helps in marking some tests as skippable,
but we need to add a Restriction: skippable too to let autopkgtests understand 
that this is intentional.

Restrictions: allow-stderr, skippable


Thanks for adding the restriction

Gianfranco

Bug#975276: qemu: CVE-2020-25723

[Salvatore Bonaccorso]

Source: qemu
Version: 1:5.1+dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2020-25723[0]:
| assertion failure through usb_packet_unmap() in hw/usb/hcd-ehci.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25723
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25723
[1] 
https://git.qemu.org/?p=qemu.git;a=commit;h=2fdb42d840400d58f2e706ecca82c142b97bcbd6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#975275: ceph: CVE-2020-25660: CEPHX_V2 replay attack protection lost

[Salvatore Bonaccorso]

Source: ceph
Version: 14.2.9-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ceph.

CVE-2020-25660[0]:
| cephx authentication protocol does not verify ceph clients correctly

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25660
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25660
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1890354

Regards,
Salvatore

Bug#972360: src:zeromq3: Wrong dependency on libpgm-5.2-0 for hppa and x32

[Luca Boccassi]

On Sun, 18 Oct 2020 14:24:04 +0200  wrote:
> Hi,
> 
> On Fri, Oct 16, 2020 at 10:21 PM Vasyl Gello 
wrote:
> > building kodi on x32 breaks on the following unsatisfiable
dependency:
> >
> > libpgm-5.2-0 (>= 5.1.116~dfsg) [hppa, x32].
> >
> > There is libpgm-5.3-0 already built for x32 but control file for
zeromq3
> > still lists that old pinned version.
>  This might look strange, but somewhat expected. Please note that
> while Debian supports twenty two architectures, these are divided
into
> two parts: primary (supported) and secondary (ports) architectures.
> Both hppa and x32 fall into the latter category.
> When a library transition happens, most often just the primary
> architectures are waited to build the new dependent library version.
> That's why when the applications binNMUed those might still build
with
> the old library version. This happened with hppa and x32 for libpgm.
> I've asked the x32 buildd admin to reschedule the binNMU. Going to
> close this bug report when that happens.
> I don't think I can do much about the hppa zeromq3 self-test failure.
> All I know is that until 4.2.5 it was working correctly. Then 4.3.1
> changed something and the self-testing started to work sporadically.
> With 4.3.3 it always fails on hppa. This means only the old libpgm
> dependent zeromq3 is available on that architecture. I put the
> upstream maintainer in Cc and he might look into it.
> 
> Regards,
> Laszlo/GCS

I think it was just one of the timing related failures, which should go
away with 4.3.3-4. I think this can be closed.

-- 
Kind regards,
Luca Boccassi

Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua

[Santiago Ruano Rincón]

El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió:
> El 19/11/20 a las 16:45, Jakub Ružička escribió:
> > On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote:
> > > El 09/11/20 a las 13:31, Jakub Ružička escribió:
> > >> Package: wnpp
> > >> Severity: wishlist
> > >> Owner: Jakub Ružička 
> > >>
> > >> * Package name: lua-binaryheap
> > >>   Version : 0.4
> > >>   Upstream Author : Thijs Schreijer 
> > >> * URL : https://github.com/Tieske/binaryheap.lua
> > >> * License : MIT
> > >>   Programming Lang: lua
> > >>   Description : binary heap implementation in lua
> > >>
> > >> binaryheap.lua is a binary heap (binary tree) implementaion in lua.
> > >>
> > > ...
> > >
> > > Jakub, thanks for packaging lua-binaryheap.
> > Thanks for fast respone, Santiago :)
> > >
> > > Two lintian "major" comments from your current repo:
> > >
> > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released 
> > > 2016-04-06) (current is 4.5.0)
> > > W: lua-binaryheap source: 
> > > package-uses-deprecated-debhelper-compat-version 9
> > >
> > > Do you have any reason for that standards-version and
> > > debhelper-compat-version?
> > Upstream packages support older distros including ubuntu xenial so it's
> > just a leftover - I've updated these to current.
> > >
> > > These other lintian minor warnings could be easily fixed:
> > >
> > > I: lua-binaryheap: capitalization-error-in-description lua Lua
> > > I: lua-binaryheap source: debian-watch-file-is-missing
> > > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git
> > >
> > > Could you please consider them?
> > I've fixed all of them except debian-watch-file-is-missing because
> > upstream is using one the weirdest version tag scheme I've witnessed
> > (version_0v4) and I'm not familiar with watch files enough to solve this
> > efficiently.
> 
> Great, thanks!
> I'll upload it later this evening.
...

Before uploading a wanted to take a look at the debian/watch file.
Attached you can find a work-in-progress version. I cannot work more on
it today. There is still an error after downloading the file. Would you
like to fix it?  (c.f. man uscan)

Cheers,

 -- S
version=4
opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./"
 \
  https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz


signature.asc
Description: PGP signature

Bug#975183: rsyslog: FTBFS: configure: error: Package requirements (libczmq >= 4.0.0) were not met

[Michael Biebl]

Am Donnerstag, den 19.11.2020, 18:00 +0100 schrieb László Böszörményi
(GCS):
> Version: 4.3.3-4
> 
> On Thu, Nov 19, 2020 at 1:27 PM Michael Biebl 
> wrote:
> > Am Donnerstag, den 19.11.2020, 10:45 +0100 schrieb Lucas Nussbaum:
> > > 
> > > > checking for libczmq >= 4.0.0... no
> > > > configure: error: Package requirements (libczmq >= 4.0.0) were
> > > > not
> > > > met
> > > > 
> > > > Package 'libbsd', required by 'libzmq', not found
> > It's a bug in libzmq3-dev, which lists libbsd as a dependency in
> > libczmq.pc.
>  Indeed, I broke it. Fix is uploaded and built on all architectures.
> Sorry for the inconvenience.


No worries and thanks for the quick fix!

Michael


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

Bug#964512: openzwave-controlpanel: FTBFS with invalid type conversion

[Gianfranco Costamagna]

control: tags -1 patch pending

Uploaded

G.

On Wed, 8 Jul 2020 11:27:57 -0400 Nicolas Mora  wrote:
> Hello,
> 
> On Wed, 08 Jul 2020 11:22:18 +0200 Andreas Beckmann  wrote:
> > 
> > openzwave-controlpanel recently started to FTBFS with
> > 
> 
> libmicrohttpd has recent API changes. The attached patch file should fix
> the ftbfs with libmicrohttpd 0.9.71. It also fixes a gcc warning with
> uninitialized value.
> 
> /Nicolas
diff -Nru openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
--- openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
2017-08-20 00:32:25.0 +0200
+++ openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
2020-11-19 22:01:52.0 +0100
@@ -1,3 +1,11 @@
+openzwave-controlpanel (0.2a+git20161006.a390f35-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Nicolas Mora to fix a build failure with recent 
libmicrohttpd
+Closes: #964512
+
+ -- Gianfranco Costamagna   Thu, 19 Nov 2020 
22:01:52 +0100
+
 openzwave-controlpanel (0.2a+git20161006.a390f35-2) unstable; urgency=medium
 
   * Append CPPFLAGS to CFLAGS to enable FORTIFY hardening.
diff -Nru 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch
--- 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch   
1970-01-01 01:00:00.0 +0100
+++ 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch   
2020-11-19 22:01:12.0 +0100
@@ -0,0 +1,136 @@
+Index: openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
+===
+--- openzwave-controlpanel-0.2a+git20161006.a390f35.orig/webserver.cpp
 openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
+@@ -100,11 +100,11 @@ extern int debug;
+  * web_send_data
+  * Send internal HTML string
+  */
+-static int web_send_data (struct MHD_Connection *connection, const char *data,
++static enum MHD_Result web_send_data (struct MHD_Connection *connection, 
const char *data,
+   const int code, bool free, bool copy, const char *ct)
+ {
+   struct MHD_Response *response;
+-  int ret;
++  enum MHD_Result ret;
+ 
+   if (!copy && ! free)
+   response = MHD_create_response_from_buffer(strlen(data), (void 
*) data, MHD_RESPMEM_PERSISTENT);
+@@ -148,14 +148,14 @@ void web_close_file (void *cls)
+  * web_send_file
+  * Read files and send them out
+  */
+-int web_send_file (struct MHD_Connection *conn, const char *filename, const 
int code, const bool unl)
++enum MHD_Result web_send_file (struct MHD_Connection *conn, const char 
*filename, const int code, const bool unl)
+ {
+   struct stat buf;
+   FILE *fp;
+   struct MHD_Response *response;
+   const char *p;
+   const char *ct = NULL;
+-  int ret;
++  enum MHD_Result ret;
+ 
+   if ((p = strchr(filename, '.')) != NULL) {
+   p++;
+@@ -540,7 +540,7 @@ const char *Webserver::SendSceneResponse
+   char *fn;
+   int cnt;
+   int i;
+-  uint8 sid;
++  uint8 sid = 0;
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+   TiXmlElement* scenesElement = new TiXmlElement("scenes");
+@@ -644,7 +644,7 @@ const char *Webserver::SendSceneResponse
+  * Process poll request from client and return
+  * data as xml.
+  */
+-int Webserver::SendPollResponse (struct MHD_Connection *conn)
++enum MHD_Result Webserver::SendPollResponse (struct MHD_Connection *conn)
+ {
+   TiXmlDocument doc;
+   struct stat buf;
+@@ -657,7 +657,7 @@ int Webserver::SendPollResponse (struct
+   char fntemp[32];
+   char *fn;
+   FILE *fp;
+-  int32 ret;
++  enum MHD_Result ret;
+ 
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+@@ -811,14 +811,14 @@ int Webserver::SendPollResponse (struct
+  * Process request for Device List from client and return
+  * data as xml.
+  */
+-int Webserver::SendDeviceListResponse (struct MHD_Connection *conn)
++enum MHD_Result Webserver::SendDeviceListResponse (struct MHD_Connection 
*conn)
+ {
+   TiXmlDocument doc;
+   char str[16];
+   int32 i, j;
+   char fntemp[32];
+   char *fn;
+-  int32 ret;
++  enum MHD_Result ret;
+ 
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+@@ -981,7 +981,7 @@ void web_controller_update (Driver::Cont
+  * Handle the post of the updated data
+  */
+ 
+-int web_config_post (void *cls, enum MHD_ValueKind kind, const char *key, 
const char *filename,
++enum MHD_Result web_config_post (void *cls, enum MHD_ValueKind kind, const 
char *key, const char *filename,
+   const char *content_type, c

Bug#974739: gnome-passwordsafe: Gnome-passwordsafe fails to open

[il]

You are right. I completely forgot about that old pykeepass installation with 
pip.
pip uninstall pykeepass solved the problem. Gnome-passwordsafe works very well 
now.
My apologies for the confusion and thank you very much.


On Sat, 14 Nov 2020 19:38:30 +0100 Henry-Nicolas Tourneur  
wrote:
> Thanks for the bug report.
> 
> From the stack trace you provided, it appears that you are not using the 
> Debian
> distributed release of pykeepass but something installed from elsewhere (I
> presume via pip). See this line: the path is local for user "il" not the 
> system
> path which should be /usr/lib/python3/dist-packages/pykeepass
> 
> from pykeepass.exceptions import (
> ImportError: cannot import name 'CredentialsError' from 'pykeepass.exceptions'
> (/home/il/.local/lib/python3.8/site-packages/pykeepass/exceptions.py)
> 
> 
> There has been an unexpected change in the release 3.2.1 of pykeepass that
> introduced some new exceptions. The version of gnome-passwordsafe packaged in
> Debian requires on pykeepass >= 3.2.1 so that those exceptions exists.
> 
> I presume your locally installed version of pykeepass is older than 3.2.1.
> Can you please make sure that you are using the Debian package for pykeepass 
> and
> let me know if this problem persists?
> 
> Best regards,
> 
> 
> -- 
> Henry-Nicolas Tourneur
> mxid: @hntourne:matrix.nilux.be
> 
> 
> 

Bug#975274: RM: tarantool [arm64 armhf] -- RoQA; no longer builds on arm

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 972669 by -1

See #972669 for background.

Bug#974695: buster-pu: package libxml2/2.9.4+dfsg1-7+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-11-13 at 22:33 +0100, Moritz Muehlenhoff wrote:
> This fixes a few low severity security fixes affecting libxml2,
> I've tested the package on a buster system with a few rdeps.
> 

Please go ahead.

Regards,

Adam

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-11-07 at 12:45 +, Romain Francoise wrote:
> I am seeking permission to upload a new version of tcpdump to
> stable-proposed-updates to address CVE-2020-8037 (bug #973877).
> 

Please go ahead.

Regards,

Adam

Bug#973706: buster-pu: package lttng-modules/2.10.8-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-11-03 at 11:51 -0500, Michael Jeanson wrote:
> The attached diff fixes a build failure of the dkms modules on the
> 4.19.0-11 buster linux kernel. This was reported at:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972321
> 

Please go ahead.

Regards,

Adam

Bug#949111: Qemu soundhw hda is broken

[bakhelit]

I can confirm that the "-soundhw hda" option is still broken in 
3.1+dfsg-8+deb10u8. When playing a movie or a song with VLC Media Player 
inside a guest (running Debian 10) one can hear very short bits of audio 
from time to time as Teran McKinney describes.


Also, when I open Pulse Audio Volume Control in my host Debian 10 
system, I can see in the "Playback" tab that the stream for QEMU very 
frequently appears and disappears - as if it was activated and 
immediately deactivated in some kind of broken loop. This is why one can 
probably hear those short bits of audio from the guest (= when the 
stream is active it all works). The GUI monitoring for PulseAudio used 
in my test is provided by "pavucontrol" package in Debian.


Regards
Bakhelit

Bug#972903: buster-pu: package node-pathval/1.1.0-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-10-26 at 04:49 +0100, Xavier Guimard wrote:
> node-pathval is vulnerable to a prototype pollution (CVE-2020-7751,
> #972895)
> 

Please go ahead.

Regards,

Adam

Bug#931068: zenity: Window icon is not displayed under Wayland

[Yvan Masson]

On Tue, 25 Jun 2019 17:00:15 +0100 Simon McVittie  wrote:

On Tue, 25 Jun 2019 at 15:47:13 +0200, Yvan Masson wrote:
> Window icon (which can be chosen with --window-icon) does not work when
> using Wayland, but works using Gnome.

Wayland is a protocol, not an implementation.

What is the environment in which this doesn't work for you? Is it Weston,
or GNOME Shell 3.30 in Wayland mode, or KDE in Wayland mode, or Sway,
or something else?

What is the environment in which this does work for you? Is it GNOME Shell
3.30 in Wayland mode, or GNOME Shell 3.30 in Xorg mode, or something else?

The results I get are:

- GNOME Shell 3.30 in Xorg mode: chosen icon appears in top bar and dash
  (sidebar in overview)
- GNOME Shell 3.30 in Wayland mode: a "broken image" icon appears instead

smcv


Hi,

I am really embarrassed, I just realized that I forgot to reply…

The results you describe are exactly what I experienced. The issue is 
still here with zenity 3.32.0-6 and Gnome 3.38.1-2.


As you suggested, I checked with another desktop environment, KDE 
Wayland (using KDE Neon: plasma-desktop 
4:5.20.3-0xneon+20.04+focal+build16 and zenity 3.32.0-5): the issue is 
exactly the same. It works on X11 but not on Wayland.


Do you want me to report this upstream?

Regards,
Yvan

Bug#972183: libjpeg-turbo 1.5.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972183 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libjpeg-turbo
Version: 1.5.2-2+deb10u1

Explanation: fix denial of service [CVE-2018-1152], buffer over read 
[CVE-2018-14498], possible remote code execution [CVE-2019-2201], buffer over 
read [CVE-2020-13790]

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> First, as a point of order (for which some authoritative guidance from
> the Secretary, CCed, would potentially prove useful): while the
> technical committee is empowered to handle various types of disputes (up
> to and including overruling an individual developer if necessary), I do
> not believe it falls within the scope of the technical committee to
> override a decision already decided by a project-wide GR, or to
> "interpret" the text of a GR issuing a nontechnical policy document in
> ways that may undermine the decision made in that GR and document.  Any
> interpretation of the text of the GR would need to be based on the text
> and intent of the GR. (Intent could include discussion at the time, but
> would notably include the text of other options that did not prevail, as
> well as the status quo at the time that motivated a GR to change.)
> Changing that intent would require either another GR, or (per specific
> provisions included in the winning GR option) consensus among the
> project, not a TC ruling.
>
> Concretely, the GR explicitly acted by "Using its power under
> Constitution section 4.1 (5)", which is the power to "Issue, supersede
> and withdraw nontechnical policy documents and statements.". The
> Technical Committee does not have such "nontechnical policy documents
> and statements" within its ambit. Any interpretation of 'what it means
> to "support the efforts of developers" working on support for
> alternative init systems' would thus be an interpretation of such a
> nontechnical policy document.
>
> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR. This does not preclude
> the TC from offering advice, or potentially facilitating dispute
> resolution if asked to do so, or even as a *last resort* overruling a
> developer on a specific technical matter (if doing so does not go
> against the GR), but I don't believe it's within the scope of the TC to
> relitigate the GR to mandate support for alternative init systems. Any
> potential ruling here would need to avoid attempting to supersede the
> GR.

I have been thinking about this procedural issue and in the end I think
that it is moot.  Let me explain how things seem to me.

In our dispute resolution role, the TC is empowered to decide upon the
two things about the contents of the network-manager package that we
have been asked to decide upon, as a matter of last resort.  No-one
disputes that we can do this.

We have also been invited to rule that "Similar init-compatibility
changes should not be blocked by package maintainers unless they are
defective on their own merits".  Essentially we are being invited to
generalise the decision that we make about the network-manager package
to say that it would apply to similar cases.

We might decide that the reasons we have for whatever decision we make
about the network-manager package do not generalise, and so we may
decline the invitation to make any more general ruling.

But if we do think the reasons generalise, then we can generalise our
ruling without stepping outside of our dispute resolution role.  For
example, we might say "if another CTTE bug was filed about the contents
of a package which was similar to this one in the following respects
... then we would expect to issue the same ruling as we have here,
because we believe that our reasons for this ruling would apply to all
packages which are similar in the previously stated respects."

Clearly we would not want to say anything which we thought contravened
the GR.  However, I do not think there is any reason to think that
resolving this dispute would necessarily involve the TC interacting with
the GR in a way that the constitution does not permit.  We are being
asked to decide about one package, and being invited to generalise in a
way that falls within the scope of our dispute resolution role.

-- 
Sean Whitton

Bug#975267: freecad: FTBFS against boost_1.74

[Tobias Frost]

Control: tags -1 patch fixed-upstream

https://github.com/FreeCAD/FreeCAD/pull/3571

Bug#975272: osinfo-db: Indicate support for virtio in RHEL 8.0 and later

[Benjamin Moody]

Package: osinfo-db
Version: 0.20181120-1+deb10u1
Severity: normal

Dear Maintainer,

When creating a virtual machine using virt-manager, it prompts me to
select the operating system, and tries to select appropriate hardware,
based on what libosinfo knows about what devices are supported.

The consequence of this is that if I select "rhel-7.6" or
"rhel-7-unknown" as the OS, virt-manager will select virtio disk and
network devices.

However, if I select "rhel-8.0" or "rhel-8-unknown" or "rhel-unknown",
then virt-manager will select less efficient virtual devices (IDE disk
drive and e1000 network card.)

(It also won't include a virtual RNG device, which is arguably a bug
in virt-manager - I think adding a virtual RNG should be harmless for
OSes that don't support it, so it should be included unconditionally.)

It'd be possible to fix this and similar issues by constantly updating
the stable version of osinfo-db as new OSes are released.  However, it
would be wise to be more future-proof by default.  For OSes that are
*not yet released* (as RHEL 8.0 was not yet released at the time
osinfo-db was uploaded for Debian 10), in the absence of other
information, it seems best to assume they will support the same
hardware as the previous version.

(In particular, for RHEL, it seems unlikely that RHEL 9 will drop
support for the virtio devices that are provided by qemu in RHEL 8,
and so forth.)

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

Kernel: Linux 4.19.152-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: 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)

-- no debconf information

Bug#975271: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 659: invalid start byte

[Davide Prina]

Package: piglit
Version: 0~git20200212-f4710c51b-1
Severity: normal
X-Debbugs-Cc: davide.pr...@gmail.com

Hi,

$ piglit run sanity results/sanity
Traceback (most recent call last):
  File "/usr/bin/piglit", line 178, in 
main()
  File "/usr/bin/piglit", line 174, in main
sys.exit(runner(args))
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/exceptions.py", line 52, in 
_inner
func(*args, **kwargs)
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/programs/run.py", line 362, 
in run
backend.initialize(_create_metadata(
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/programs/run.py", line 268, 
in _create_metadata
metadata['info']['system'] = core.collect_system_info()
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/core.py", line 182, in 
collect_system_info
result[name] = out.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 659: 
invalid start byte


I try to find the invalid character (I have modified the
/usr/lib/x86_64-linux-gnu/piglit/framework/core.py to print all the out
to a file; but I report here the output before those modifications)
and I found that clinfo print a line with strange characters,
characters that you don't see if you call clinfo from the command line,
but you can see if you redirect the clinfo output to a file:
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   P�|�%V

I look with and hex editor and I found that the string is

20 50 AD 7C EC 25 56 0A 20

This is a very strange output for clinfo, but I think that piglit will
need to work correctly

Ciao
Davide


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

Kernel: Linux 5.9.1-dp-20201024 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piglit depends on:
ii  libc62.31-4
ii  libegl1  1.3.2-1
ii  libgcc-s110.2.0-16
ii  libgl1   1.3.2-1
ii  libstdc++6   10.2.0-16
ii  libwaffle-1-01.6.1-3
ii  libx11-6 2:1.6.12-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.13-1
ii  python3  3.8.6-1
ii  python3-mako 1.1.3+ds1-1
ii  python3-six  1.15.0-2

Versions of packages piglit recommends:
ii  waffle-utils  1.6.1-3

piglit suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/x86_64-linux-gnu/piglit/framework/core.py (from 
piglit package)

Bug#972814: pcaudiolib 1.1-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972814 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: pcaudiolib
Version: 1.1-3+deb10u1

Explanation: cap cancellation latency to 10ms

Bug#972839: systemd 241-7~deb10u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972839 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: systemd
Version: 241-7~deb10u5

Explanation: basic/cap-list: parse/print numerical capabilities; recognise new 
capabilities from Linux kernel 5.8; networkd: do not generate MAC for bridge 
device

Bug#972115: sqlite3 3.27.2-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972115 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: sqlite3
Version: 3.27.2-3+deb10u1

Explanation: fix division by zero [CVE-2019-16168], NULL pointer dereference 
[CVE-2019-19923], mishandling of NULL pathname during an update of a ZIP 
archive [CVE-2019-19925], mishandling of embedded NULs in filenames 
[CVE-2019-19959], possible crash with stacking unwinding [CVE-2019-20218], 
integer overflow [CVE-2020-13434], segmentation fault [CVE-2020-13435], 
use-after-free issue [CVE-2020-13630], NULL pointer dereference 
[CVE-2020-13632], heap overflow [CVE-2020-15358]

Bug#972351: ros-ros-comm 1.14.3+ds1-5+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972351 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ros-ros-comm
Version: 1.14.3+ds1-5+deb10u2

Explanation: fix integer overflow [CVE-2020-16124]

Bug#975270: rdiff-backup: Can't talk to the version from buster

[Kurt Roeckx]

Package: rdiff-backup
Version: 2.0.5-1
Severity: important

Hi,

I recently found out that my backup has broken for months. It
seems that the version from testing doesn't want to talk to the
version from stable/buster.

It gives the following error:
Exception 'object.__new__(X): X is not a type object (classobj)' raised of 
class '':
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 278, in 
take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 355, 
in Server
self.get_response(-1)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 315, 
in get_response
try: req_num, object = self._get()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 241, 
in _get
if format_string == "o": result = cPickle.loads(data)
  File "/usr/lib/python2.7/copy_reg.py", line 48, in _reconstructor
obj = object.__new__(cls)

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 30, in 
rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 278, in 
take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 355, 
in Server
self.get_response(-1)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 315, 
in get_response
try: req_num, object = self._get()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 241, 
in _get
if format_string == "o": result = cPickle.loads(data)
  File "/usr/lib/python2.7/copy_reg.py", line 48, in _reconstructor
obj = object.__new__(cls)
TypeError: object.__new__(X): X is not a type object (classobj)
Fatal Error: Truncated header string (problem probably originated remotely)

Couldn't start up the remote connection by executing

ssh -C X rdiff-backup --server

Remember that, under the default settings, rdiff-backup must be
installed in the PATH on the remote system.  See the man page for more
information on this.  This message may also be displayed if the remote
version of rdiff-backup is quite different from the local version (2.0.5).



If I downgrade to the local version 1.2.8-7, which is also the
remote version, things work.


Kurt

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Sven Joachim]

On 2020-11-19 19:47 +0100, Marco d'Itri wrote:

> On Nov 16, Niko Tyni  wrote:
>
>> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
>> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
>> is fully installed.
> I think that Niko is right, so I would like to know the opinion of the
> glibc maintainers.

I am not one of them, but AFAICS that would introduce a fatal circular
dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
configured before it can be unpacked, but libcrypt1 depends on libc6 so
it cannot be configured before libc6 is at least unpacked.

Cheers,
   Sven

Bug#975037: recoll: watchfile broken

[Jean-Francois Dockes]

The url is now:
https://www.lesbonscomptes.com/recoll/pages/download.html
instead of
https://www.lesbonscomptes.com/recoll/download.html

J.F.

Tobias Frost writes:
 > Package: recoll
 > Severity: normal
 > 
 > Dear Maintainer,
 > 
 > tracker.d.o says "404" on the watch file, so it seems to be broken…
 > 
 > 
 > --
 > tobi

Bug#975269: buster-pu: package linux/TBD - arm64 stolen time support

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: no...@debian.org

There are two parts to the proposed changes:

1. Support in arm64 KVM code for reporting stolen time to guests.
2. Support in arm64 paravirtualised guest code for requesting stolen
   time from the hypervisor and reporting it to user-space.

I think part 1 is not suitable for a stable update, but part 2 might
be.

[ Reason ]

Noah Meyerhans wrote in bug #969443:
> When used in virtual machine environments, Linux on amd64 is able to report
> "steal time" to the guest.  This functionality has been supported by Linux
> on amd64 for years, but was only added to arm64 with Linux 5.5.
> 
> As Debian and arm64 are increasingly used in virtual environments, including
> cloud environments, the ability to report steal time is increasingly
> important for system monitoring and performance analysis.  Thus, I'd like to
> request that CPU steal time accounting support for arm64 be backported to
> buster, if possible.

[ Impact ]

Without this, it's difficult to determine when VM performance is being
affected by stolen time.

[ Tests ]

Noah has tested the changes (at least part 2) in an arm64 KVM
environment with steal time reporting, presumably AWS EC2.

[ Risks ]

There is a potential to regress VM host and/or guest support on arm64
and armhf, depending on which part(s) are applied.

[ Changes ]

1. * KVM: arm64: Document PV-time interface
   * KVM: arm/arm64: Factor out hypercall handling from PSCI
   * KVM: arm64: Implement PV_TIME_FEATURES call
   * KVM: Implement kvm_put_guest()
   * KVM: arm64: Support stolen time reporting via shared
   * KVM: Allow kvm_device_ops to be const
   * KVM: arm64: Provide VCPU attributes for stolen time
2. * arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
   * arm/arm64: Provide a wrapper for SMCCC 1.1 calls
   * arm/arm64: Make use of the SMCCC 1.1 wrapper
   * arm64: Retrieve stolen time as paravirtualized guest

The actual patches are visible at
.

Ben.

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

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

Bug#959422: 959422: Info received (Bug#959422: [20200502] ftp.nluug.nl: out-of-date)

[Julien Cristau]

Control: retitle -1 [20201119] ftp.nluug.nl: out-of-date

On Mon, May 04, 2020 at 02:44:09PM +0200, Mike Hulsman wrote:
> Hi,
> 
> I fixed the problem by changing to another source.
> In the mirror report I see 2 valid syncs.
> 
Hi Mike,

it looks like ftp.nluug is behind once again, see
https://mirror-master.debian.org/status/mirror-info/ftp.nluug.nl.html

Cheers,
Julien

Bug#975268: gazebo: FTBFS against boost_1.74

[Anton Gladky]

Package: gazebo
Version: 11.1.0+dfsg-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[100%] Built target MisalignmentPlugin
/<>/plugins/SimpleTrackedVehiclePlugin.cc:35:7: error: 
redefinition of ‘class std::hash >’
   35 | class hash> {
   

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/gazebo_11.1.0+dfsg-3_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+2xX0RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYCXQ/9HlLnRGwg5Hrh98zxSXo4Z8oxnv9dzxHL
UI5kKDj9aLIGOdkR6Q1gwThPu7642d6isb50E5YW5+H9gJld6hs/S8LjOr640PP0
A9r2CcdFQLExrF6XIHFxlMGVK9hQEHWLNogZE71W4kXbM21KKnEEcl8xYXL8/4ly
oGHS3n6F7tl3tAUjdxZUYJR0Ilss2mGxUfq0S0XgC+1rQZ0bIR3N+IrditwKhkB1
yZ60uxQ9JCNwHc195dZOdORavOwZNqtvSG9ahI0MZ2y3N1xzwvIM11WSRgJMMeoj
poVAjz+mYu0zt8rmiyVX0Syk7UvxCPjUTf0eNZk7AvHR/baTYi6BEu1CTAMB9rF4
2jDz1D141n03zgu1stbgBJL1GQ8W593dseqPmjo2QUjaxbz2wXszaevbgsI3EdXH
USkh57uoJL16ZPNcbtokeyvHdHBGfD/Cj/MGJTzPQCDd6G6QUb6LdGzY3lH8MLC6
Vvf1eM/FKj75Gk0/y3i6Q+VnMluUn/Q3Gm8da/2G7PjHxpxAV6GUwTBS4crw88R1
Kb8yNffSXUWkQPe2b4D7KoKU/mYbL60/mAi6WJPMB+db3LU5dYnCKQZtgYjtBsLt
aiYaZdxXOQZP7nIrGdR5ygJtXmtlO8/kBsmXN5u4s+S0+xF+D8dzdQ/erc454ZAN
+npIio6v5ls=
=ISg2
-END PGP SIGNATURE-

Bug#975016: OpenJDK 15 support state for Bullseye

[Adrian Bunk]

On Thu, Nov 19, 2020 at 07:47:14PM +0100, Moritz Mühlenhoff wrote:
> On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote:
> > I think nobody wants to switch default-jdk to 17 or even not ship
> > 11 at all any more or stop supporting it during bullseye’s lifetime.
> > Maybe that also was too implicit?
> 
> Exactly, the supported Java release for the entire Bullseye lifetime will
> be 11 (which packages will build-depend on and what's provided by
> default-jdk.
> 
> The idea is to include 15/16 so that later on when 17 is ready, 17
> can be made available in addition via backports (since at some point
> later in the bullseye lifecycle might be software one wants to run
> which requires 17 as the next LTS.

17 can be in unstable before the release of bullseye.

If this is then eligible for testing migration except for the freeze,
it would enter testing in the first migration after the release.
With slight bending of the rules someone with ftp powers could then
copy the sources+binaries from bookworm/testing to bullseye-backports.

Slightly less bending of the rules and only marginally more effort would 
be to build ~bpo11+1 binaries for all bullseye release architectures
in unstable before the release of bullseye.

Either option sounds better to me than shipping 15 or 16 in a stable
release solely for bootstrapping 17 in backports.

> Cheers,
> Moritz

cu
Adrian

Bug#973416: mirror submission for uk.mirrors.clouvider.net

[Julien Cristau]

Control: tag -1 moreinfo

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,
Julien

On Fri, Oct 30, 2020 at 11:19:22AM +, Maciej Kupiec wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: uk.mirrors.clouvider.net
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: Maciej Kupiec 
> Country: GB United Kingdom
> Location: London
> Sponsor: Clouvider https://www.clouvider.co.uk
> Comment: Hello,
>  I'm Maciej from Clouvider Limited. We've setup 6 debian mirrors in:
>  London, UK
>  Amsterdam, NL
>  Frankfurt, DE
>  New York, US
>  Atlanta, US
>  Los Angeles, US
>  
>  All of them got 10gb/s connection.
>  
>  Kind regards,
>  Maciej Kupiec
> 
> 
> 
> 
> Trace Url: http://uk.mirrors.clouvider.net/debian/project/trace/
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/uk.mirrors.clouvider.net
> 

Bug#975267: freecad: FTBFS against boost_1.74

[Anton Gladky]

Package: freecad
Version: 0.18.4+dfsg2-5
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[ 55%] Building CXX object 
src/Gui/CMakeFiles/FreeCADGui.dir/DAGView/DAGRectItem.cpp.o
cd /<>/debian/build-py3/src/Gui && /usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_ATOMIC_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK 
-DBOOST_THREAD_DYN_LINK -DBUILD_ADDONMGR -DCMAKE_BUILD_TYPE=\"RelWithDebInfo\" 
-DFreeCADGui_EXPORTS -DHAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB 
-DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB -DQT_XML_LIB 
-DSPNAV_FOUND -D_OCC64 -I/<>/debian/build-py3 
-I/<>/debian/build-py3/src -I/<>/src 
-I/<>/src/Gui -I/<>/src/Gui/Quarter 
-I/<>/debian/build-py3/src/Gui -I/<>/src/Gui/.. 
-I/<>/debian/build-py3/src/Gui/.. 
-I/<>/debian/build-py3/src/Gui/Language 
-I/<>/debian/build-py3/src/Gui/propertyeditor 
-I/<>/debian/build-py3/src/Gui/TaskView 
-I/<>/debian/build-py3/src/Gui/Quarter 
-I/<>/debian/build-py3/src/Gui/DAGView -I/usr/include/eigen3 
-I/usr/include/python3.8 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtUiTools -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -Wall -Wextra -Wno-write-strings -Wall 
-DHAVE_SWIG=1 -fpermissive -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11 -D_OCC64 -O2 -g -DNDEBUG -fPIC -pthread 
-I/usr/include/hdf5/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -fPIC -o 
CMakeFiles/FreeCADGui.dir/DAGView/DAGRectItem.cpp.o -c 
/<>/src/Gui/DAGView/DAGRectItem.cpp
/<>/src/Gui/DAGView/DAGView.cpp: In constructor 
‘Gui::DAG::View::View(QWidget*)’:
/<>/src/Gui/DAGView/DAGView.cpp:55:100: error: ‘_1’ was not 
declared in this scope
   55 |   
Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
 this, _1));

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/freecad_0.18.4+dfsg2-5_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+2w44RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYJ6A//TtEh7bUmrOuoqRkEDlzjcdKlem+QHEt8
F4R53dGULzAZ37aYX5leTEK8dgc0Hu2gSlOaFJD7IltfvSPM3FOoa2hdWGVboBaF
6oeY17VxtKUr3vLi+rt7Tkb29ta/iuTXm1FB+pj2FhmzwjuG1LQ7c4mVNrFHF1Fu
cArzsdF0y9D9t2ulWMw6Dc3i2VYAMlVIweUev1b3dy+qEzUX+262wwOsPGipA6zf
qPBJrZjMaolqIUjISXirux2KfWwUBQ78XJKhPUM3XfIYxi4ePiB2yu3UhrSANsUg
Kj9bE/ITW3tpLjTzCliFwElNdXMhT/PihxTRshaSGyvc9ff97Bfv2QqoguhQIQtj
zxpY3330gRTfCu+LcMHk0KNNUmA5/dxNvbVFhsAbtwbXgvfD52l5v0V3UDmyalZO
UE/fwuwrzfKNWTNLOAfuY4ANUSN88oNoO2ijUiMGI0zUriW1FXGcVhyhKXApuGEB
uKxWHx4uqV23l1tDmFJq67lqC3+/VNcpADthw9p2phy7LILdgRDAeEckUCRTRLp+
yIREdDPWcUYrYM5CEIri21pRkSqHiXGnVIG6w2VjTRvx1eNuAp6DtecGP2VZLzXm
OFkI2iF8LucyjhpPX+DTTLa0vrFPygP3L+y62MPlXOEJGxPGK5DulkO7Uh2ULFzE
ZauSByO74pw=
=bYr7
-END PGP SIGNATURE-

Bug#975250: clarify gathering together of copyright information

[Russ Allbery]

Marc Haber  writes:

> But what if file A says

> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts

> and file B has:

> |  Copyright 2010 Angela Watts

> Can this be gathered together to:

> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts

I'm fairly sure the answer in practice is yes.  I've been uploading
packages like this for some time without any issues, and I would be very
surprised if ftp-master would object.

I think we may need to be a bit more verbose in explaining how copyright
statements can be coalesced to make this clear.  Some GNU projects use
wording like this:

   For any copyright year range specified as - in this file, the
   range specifies every single year in that closed interval.

and maybe we should import something like that into our specification as
well as say explicitly that you're allowed to coalesce copyright
statements from multiple files into a single copyright notice as long as
all of the listed authors and years are covered.

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

Bug#975208: Bug#975210: Bug#975214: Bug#975210: libowl-directsemantics-perl: FTBFS: test failed

[gregor herrmann]

On Thu, 19 Nov 2020 19:57:31 +0100, Jonas Smedegaard wrote:

> Can you point to specific examples of packages vendoring Scalar::Util 
> for me to learn from, Gregor?

Not sure if we have packages with specifically inc/Scalar/Util
but a general recipe, used in lots of packages, is at

https://perl-team.pages.debian.net/policy.html#Embedded_third-party_modules_in_inc%2F

and should work for this case as well.

(Summary: move inc/ away before dh_auto_configure and back after
dh_auto_clean.)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#963392: [Help] r-cran-bayestestr: autopkgtest regression

[Dirk Eddelbuettel]

On 19 November 2020 at 19:07, Andreas Tille wrote:
| Control: tags 972074 pending
| Control: block 972074 by 963392
| 
| On Thu, Nov 19, 2020 at 07:53:06AM -0600, Dirk Eddelbuettel wrote:
| > | 
| > | I do not have the slightest idea what this might mean.
| > 
| > ABI/API slippage in the stack. An interface changed but a package didn't 
recompile.
| 
| It seems it is caused by r-cran-rstanarm which in turn has a test
| suite issue itself:

[...]

| > CRAN Package Check Results for Package bayestestR
| > Last updated on 2020-11-19 13:50:51 CET.
| > 
| > Flavor  Version TinstallTcheck  Ttotal  Status  Flags
| > r-devel-linux-x86_64-debian-clang   0.7.5   12.67   406.54  419.21  OK  
| > r-devel-linux-x86_64-debian-gcc 0.7.5   8.37295.67  304.04  
OK  
| > r-devel-linux-x86_64-fedora-clang   0.7.5   498.86  OK  
| > r-devel-linux-x86_64-fedora-gcc 0.7.5   487.49  
OK  
| > r-devel-windows-ix86+x86_64 0.7.5   16.00   636.00  652.00  OK  
| > r-patched-linux-x86_64  0.7.5   12.72   388.61  401.33  
OK  
| > r-patched-solaris-x86   0.7.5   725.40  
OK  
| > r-release-linux-x86_64  0.7.5   12.04   390.98  403.02  
OK  
| > r-release-macos-x86_64  0.7.5   
OK  
| > r-release-windows-ix86+x86_64   0.7.5   13.00   652.00  665.00  
OK  
| > r-oldrel-macos-x86_64   0.7.5   
OK  
| > r-oldrel-windows-ix86+x86_640.7.5   11.00   500.00  511.00  
OK
| 
| Not sure what information this table should provide to us.  The fact

It makes it fairly obvious that you should not contact upstream -- because
there is no issue in the upstream code.

| that things are running on those other systems is great but does not
| answer why it is not running for us. 

Exactly. It's most-likely a self-inflicted wound.  

FWIW I see that myself too when I do reverse depenency tests for Rcpp or
related packages. rstanarm is a complicated package. You could consider not
installing it for the autopkgtests for this package.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#975250: clarify gathering together of copyright information

[Sean Whitton]

Hello,

On Thu 19 Nov 2020 at 05:07PM +01, Marc Haber wrote:

> /usr/share/doc/debian-policy/copyright-format-1.0.txt.gz says
>
> |The Copyright field collects all relevant copyright notices for the files
> |of this paragraph. Not all copyright notices may apply to every 
> individual
> |file, and years of publication for one copyright holder may be gathered
> |together. For example, if file A has:
> |
> |  Copyright 2008 John Smith
> |  Copyright 2009 Angela Watts
> |
> |and file B has:
> |
> |  Copyright 2010 Angela Watts
> |
> |a single paragraph may still be used for both files. The Copyright field
> |for that paragraph would contain:
> |
> |  Copyright 2008 John Smith
> |  Copyright 2009, 2010 Angela Watts
>
> But what if file A says
>
> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts
>
> and file B has:
>
> |  Copyright 2010 Angela Watts
>
> Can this be gathered together to:
>
> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts
>
> or does it have to be
>
> |  Copyright 2008 John Smith
> |  Copyright 2009, 2005-2015 Angela Watts
>
> ?

The former.  If you'd like to propose a patch making this clearer we
could get it applied.

-- 
Sean Whitton

Bug#975266: CVE-2020-27616

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-27616:
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06080.html

Cheers,
Moritz

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#975265: CVE-2020-27616

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-27616:
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06080.h
https://www.openwall.com/lists/oss-security/2020/11/03/2

Cheers,
Moritz

Bug#975208: Bug#975210: Bug#975214: Bug#975210: libowl-directsemantics-perl: FTBFS: test failed

[Jonas Smedegaard]

Quoting gregor herrmann (2020-11-19 18:40:21)
> On Thu, 19 Nov 2020 12:28:53 +0100, gregor herrmann wrote:
> 
> > So this might be more of a problem in the recently updated 
> > libtype-tiny-perl (with or without involvement of perl 5.32, as 
> > Scalar::Util is dual-lifed).
> 
> As noted by Niko on IRC, the actual problem seems to be an ancient 
> Scalar::Util in inc/.
> 
> Now a proper fix would probably be to (convert to package from cdbs to 
> debhelper and) move inc/ away and back in d/rules (like we do for 
> other packages) and build-depend on the vendored modules; a 
> quick&dirty fix, tested with librdf-closure-perl, seems to work:
> 
> #v+
> --- a/debian/rules
> +++ b/debian/rules
> @@ -47,3 +47,6 @@ CDBS_BUILD_DEPENDS +=, $(deps), $(deps-test)
>  CDBS_DEPENDS_$(pkg) = $(deps)
> 
>  DEB_INSTALL_EXAMPLES_$(pkg) = examples/*
> +
> +clean::
> +   $(RM) -rv $(CURDIR)/inc/Scalar
> #v-

Thanks for the analysis, Niko and Gregor.

I hope to find time later tonight or tomorrow to convert these packages 
to use short-form dh sequencer.

Can you point to specific examples of packages vendoring Scalar::Util 
for me to learn from, Gregor?


 - 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#975264: RM: oidua -- RoQA; Dead upstream, unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove oidua. It's dead upstream, depends on Python 2 (dropped from 
testing
for almost a year) and the last maintainer upload was in 2016 (without any 
followup
to the RC bugs)

Cheers,
Moritz

Bug#975263: RM: py-asterisk -- RoQA; unmaintained, RC-buggy, no rdeps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove py-asterisk. The last maintainer upload was in 2014, there are no 
reverse deps,
it depends on Python 2 and has been dropped from testing for almost a year now.

Cheers,
Moritz

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Jonas Smedegaard]

Quoting Romain Porte (2020-11-19 18:07:15)
> 2020-11-19 00:43 CET, Jonas Smedegaard:
> > I sure hope you had fun diving into this - and that I did not 
> > mislead you when suggesting to explore this.
> 
> I�sure did, it allowed me to learn how the substitution system and 
> dh_gencontrol work. It is just the result that I find disappointing in 
> the end.
> 
> > There must be code out there to automate the task of inspecting 
> > language coverage, but I have not yet found anything useful to 
> > package for Debian.  That would be nice, and I would certainly use 
> > it for package description of Noto fonts.
> 
> Would you not be concerned about introducing 145 lines listing the 
> languages in the long description? I think "long" should be "long 
> enough", not "exhaustive".
> 
> > >   List of supported scripts:
> > >- Default
> > >- Latin
> > >- Latin/Azeri
> > >- Latin/Catalan
> > >- Latin/Crimean
> > >- Latin/Kazakh
> > >- Latin/Moldavian
> > >- Latin/Romanian
> > >- Latin/Tatar
> > >- Latin/Turkish
> 
> Is this addition in the package's long decription worthwhile to you, 
> and if so, should I merge the proposed patch?
> 
> I see in the noto fonts package that the long description contains:
> 
> > The name "Noto" is short for "No Tofu",
> > describing the aim of covering all living Unicode scripts
> > (currently 65 are covered, at least partly.
> 
> Which is different from what I came with. I would be *happier* to 
> follow what noto currently does by piping in a `| wc -l` to mention 
> " scripts covered" instead of "list of supported scripts".
> 
> Do you agree with this approach? Or do you want to take my patch and 
> apply it to the noto fonts instead aswell? ;)

I would indeed not use raw listings of more than 50 entries, but would 
try find ways to summarize the information most sensibly.

With current tools, I do find it most sensible to do as I did for the 
Noto font families.  I am no authority here, but if you agree then sure, 
I do encourage you to try mimick that same style for jetbrains font.

What I mean by stating that I would "certainly use" more accurate 
language coverage analysis tools is that they could help replace that 
annoying trailing "at least partly" remark with more accurate facts.


 - 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#973655: distro-info-data 0.41+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 973655 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: distro-info-data
Version: 0.41+deb10u3

Explanation: add Ubuntu 21.04, Hirsute Hippo

Bug#972651: fastd 18-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972651 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fastd
Version: 18-3+deb10u1

Explanation: fix memory leak when receiving too many invalid packets 
[CVE-2020-27638]

Bug#971685: fish 3.0.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971685 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fish
Version: 3.0.2-2+deb10u1

Explanation: ensure TTY options are restored on exit

Bug#975016: OpenJDK 15 support state for Bullseye

[Moritz Mühlenhoff]

On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote:
> I think nobody wants to switch default-jdk to 17 or even not ship
> 11 at all any more or stop supporting it during bullseye’s lifetime.
> Maybe that also was too implicit?

Exactly, the supported Java release for the entire Bullseye lifetime will
be 11 (which packages will build-depend on and what's provided by
default-jdk.

The idea is to include 15/16 so that later on when 17 is ready, 17
can be made available in addition via backports (since at some point
later in the bullseye lifecycle might be software one wants to run
which requires 17 as the next LTS.

Cheers,
Moritz