Bug#956187: firejail-profiles: Updated profile for Microsoft Teams for Linux

[Patrik Flykt]

Package: firejail-profiles
Version: 0.9.62-3
Severity: important
Tags: patch

Dear Maintainer,

Microsoft Teams for Linux has been updated with a packagad desktop
version of their program which can be downloaded when visiting
https://teams.microsoft.com. The new Teams Debian package comes with
a renamed application 'teams' and uses a few more standard command
line tools. To support the new version, I created a new
'teams.profile' to match the name of the binary and allows access
to the new helper programs that package is using.

I don't know if the current teams-for-linux will still work, if not
that one could be retired and all of the profile information updated
to a profile using the name of the new binary.

The new teams.profile is:
---
include teams-for-linux.profile

whitelist ${HOME}/.config/teams
whitelist ${HOME}/.config/Microsoft/Microsoft Teams

private-bin teams,readlink,dirname,mkdir,nohup
---

Please test,

Patrik



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

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

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.62-3

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information

Bug#923895: RFP -> ITP

[merkys]

control: retitle -1 ITP: node-cuint -- C-like unsigned integers for Javascript
control: owner -1 !

Hello,

I am interested in packaging cuint as a dependency of xxhashjs.
The packaging will take place in salsa [1].

Best,
Andrius

[1] https://salsa.debian.org/js-team/node-cuint

Bug#956186: libconvert-asn1-perl: CVE-2013-7488: allows remote attackers to cause an infinite loop via unexpected input

[Salvatore Bonaccorso]

Source: libconvert-asn1-perl
Version: 0.27-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/gbarr/perl-Convert-ASN1/issues/14

Hi,

The following vulnerability was published for libconvert-asn1-perl.

CVE-2013-7488[0]:
| perl-Convert-ASN1 (aka the Convert::ASN1 module for Perl) through 0.27
| allows remote attackers to cause an infinite loop via unexpected
| input.


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-2013-7488
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7488
[1] https://github.com/gbarr/perl-Convert-ASN1/issues/14

Regards,
Salvatore

Bug#946853: Upgrade to ACE 6.5.8

[Johnny Willemsen]

Hi,

Not a problem, years ago I asked several times whether people could
assist me with the process to be allowed to upgrade ACE as part of the
release procedure. Currently I upload the packages to github/vanderbilt
but also provide them to OpenSuSE Build service, vcpkg, homebrew. Adding
an upload to debian wouldn't take much long but I have no idea how to be
able to do that currently, maybe someone could contact me directly at
jwillem...@remedy.nl to discuss that.

Johnny

On 4/7/20 11:43 PM, Sudip Mukherjee wrote:
> On Tue, Apr 07, 2020 at 01:57:44PM +0200, Johnny Willemsen wrote:
>> Hi,
>>
>> Would help everyone when someone could upgrade ACE to 6.5.8, the most
>> recent micro
> I can have a look at the upgrade, but I am not allowed to do that as NMU.
> It might be better if the maintainer does it. And also, there is another
> pending RC bug #899440, I can not do NMU for that. :(
>
> Though I will suggest that we upload the NMU first and unblock ivtools,
> which is failing due to ACE, #954637.
>
> --
> Regards
> Sudip

Bug#829380: Orthanc 1.2.0

[Sébastien Jodogne]

Hello,

Sorry for having overlooked this issue.

I have migrated Karsten's instructions into the "README.Debian" file of
the "orthanc" package:
https://salsa.debian.org/med-team/orthanc/-/commit/9f004236c6190a4b3137d358b8de9d0cae498f90

HTH,
Sébastien-


On 7/04/20 23:22, Karsten Hilbert wrote:
> On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:
> 
>> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
>>> On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
>>>
 Sorry, my mistake: Preventing Orthanc from starting after an upgrade of the
 database schema was on my TODO list... it is not implemented yet. I have
 just added an issue on the upstream bug tracker to avoid forgetting it:
 https://bitbucket.org/sjodogne/orthanc/issues/29

 This feature will be part of forthcoming 1.2.1 release.
>>>
>>> Thanks a lot for confirming. I will test when 1.2.1 is out
>>> and provide a script users can run updating the database
>>> schema if needed.
>>
>> Hello Karsten,
>>
>> Debian stable now has version 1.5.6 [1] and the upstream bug report is
>> marked as resolved [2].  Is a separate update script still needed?  If
>> not, can this bug report be closed?
> 
> A separate script is never needed because Orthanc itself can
> upgrade it's database -- if manually invoked in the right
> environment.
> 
> The (attached) script makes it a lot easier for users to do
> so and it proves (on my machine) that the surprising behaviour
> (Orthanc being started after a run with --upgrade) is fixed.
> 
> So, the bug can be closed, regardless of the attached script
> -- but the attached script is useful to users whenever
> another database upgrade comes along (which there will,
> eventually).
> 
> Best,
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
> 

Bug#956185: Unable to change password

[navaneeth]

Package: gnome-control-center
Version: 1:3.36.1-1
Severity: normal

Unable to change password via gnome-control-center. No matter what
gibberish I type in as the new password, password security check
blocks it saying "Try to avoid common words" (see attached image).
This might be an error in a dependency, something related to
dictionary check. But I'm not sure which one. Also, the same behaviour
can be seen in seahorse. Although, there the error is not blocking,
but just a warning.

Bug#956184: RFP: python3-sphinx-better-theme -- modified version of the default Sphinx theme

[Scott Kitterman]

Package: wnpp
Severity: wishlist

* Package name: python3-sphinx-better-theme
  Version : 0.1.5
  Upstream Author : Steve Johnson 
* URL : https://pypi.org/project/sphinx-better-theme
* License : Expat
  Programming Lang: Python
  Description : modified version of the default Sphinx theme

This theme is now used by psycopg2 for its documentation, so it would be
nice to see it in Debian so we could use it (instead of patching to use
the default Sphinx Theme.

 sphinx-better-theme is an update to the default Sphinx theme with the
 following goals:
 .
  - Remove frivolous colors, especially hard-coded ones
  - Improve readability by limiting width and using more whitespace
  - Encourage visual customization through CSS, not themeconf
Use semantic markup

Bug#956158: override: debian-multimedia

[Sean Whitton]

Hello,

On Tue 07 Apr 2020 at 06:30PM -04, Sandro Tosi wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Hello,
> a few more override updates:

Done these.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#951964: gkrellm-tz: diff for NMU version 0.8-1.1

[Andreas Jimmy Gredler]

> On Apr 6, 2020, at 2:37 AM, Adrian Bunk  wrote:
> 
> Control: tags 951964 + patch
> Control: tags 951964 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for gkrellm-tz (versioned as 0.8-1.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should cancel it.

Hi Adrian,

Thank you so much for taking care of this. Unfortunately I won’t be able to 
maintain this package anymore and was looking into the process of handing it 
over. Please let me know if you would be interested in maintaining it yourself. 
It did not require a lot of work in the past as there were not many releases. 
Otherwise I guess will file an RFA or O request.
Thanks again.

Best,
Jimmy

Bug#925540: qhull: add libqhullcpp to installed libraries

[Jochen Sprickerhof]

Hi Barak,

* Barak A. Pearlmutter  [2020-04-07 23:07]:

But, now that I've seen it, looks great. I'm going to just upload to
unstable. (Hence the term, right?)


No, it has a differen Soname due to a different ABI. We need to go 
through experimental and request a transition with the release team, 
see:


https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Cheers Jochen


signature.asc
Description: PGP signature

Bug#956183: transition: libwmf

[Yangfl]

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

libwmf is released with package split, and old-style config script
dropped with pkg-config file introduced. There are three packages
needing patches against `libwmf-config':

  wv
  gimp
  abiword

and two packages which should only require binNMU:

  graphicsmagick
  imagemagick

I didn't do a test rebuild of these packages, because full rebuild
would take too long time. The new version of libwmf should not have
any API/ABI breakage, so I don't expect any ftbfs.

https://release.debian.org/transitions/html/auto-libwmf.html

Bug#956182: gnome-boxes: Can't connect to any {VM} since upgrade to version 3.36.x

[Adrian Immanuel Kiess]

Package: gnome-boxes
Version: 3.36.2-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Upgrading gnome-boxes to version 3.36
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt dist-upgrade
   * What was the outcome of this action?
 gnome-boxes can't connect to any virtual machine on localhosts system:///
   * What outcome did you expect instead?
 Working application

currently in Debian/testing gnome-boxes is seriously broken. Today's update to
3.36.2 didnt fixed the issue.

One can't connect to any virtual machine's full window session. The application
say's "Can't connect". The preview of the virtual machine is correctly
displayed and I am able to start and stop a virtual machine.

Sincerely,

Adrian Kiess





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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
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 gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-ba  0.36.0-1
ii  gconf-gsettings-backend [gsettings-ba  3.2.6-6
ii  genisoimage9:1.1.11-3.1
ii  libarchive13   3.4.0-2
ii  libc6  2.30-4
ii  libcairo2  1.16.0-4
ii  libfreerdp2-2  2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-3
ii  libglib2.0-0   2.64.1-1
ii  libgtk-3-0 3.24.14-1
ii  libgtk-vnc-2.0-0   1.0.0-1
ii  libgudev-1.0-0 233-1
ii  libosinfo-1.0-01.7.1-1
ii  libosinfo-bin  1.7.1-1
ii  libpango-1.0-0 1.42.4-8
ii  libsecret-1-0  0.20.2-1
ii  libsoup2.4-1   2.70.0-1
ii  libspice-client-glib-2.0-8 0.37-2
ii  libspice-client-gtk-3.0-5  0.37-2
ii  libtracker-sparql-2.0-02.3.4-1
ii  libusb-1.0-0   2:1.0.23-2
ii  libvirt-daemon 6.0.0-5
ii  libvirt-glib-1.0-0 3.0.0-1
ii  libvte-2.91-0  0.60.1-1
ii  libwebkit2gtk-4.0-37   2.28.0-2
ii  libwinpr2-22.0.0~git20190204.1.2693389a+dfsg1-2
ii  libxml22.9.10+dfsg-4
ii  tracker2.3.4-1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:4.2-3

gnome-boxes suggests no packages.

-- no debconf information

Bug#956034: nvidia-legacy-340xx-driver: Fails to build with kernel 5.5

[jim_p]

Package: nvidia-legacy-340xx-driver
Followup-For: Bug #956034

Thank you for updating/patching the package so quickly! Everything works great
now.

However, I also get this message in dmesg and I wonder if it is something I
should worry about

[8.473415] resource sanity check: requesting [mem 0x000c-0x000f],
which spans more than PCI Bus :00 [mem 0x000c-0x000d window]
[8.473566] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs




-- Package-specific info:
uname -a:
Linux mitsos 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) x86_64 GNU/Linux

/proc/version:
Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 9.3.0 (Debian 9.3.0-8) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.319397] Console: colour VGA+ 80x25
[0.750422] pci :01:00.0: vgaarb: setting as boot VGA device
[0.750422] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.750422] pci :01:00.0: vgaarb: bridge control possible
[0.750422] vgaarb: loaded
[0.933511] Linux agpgart interface v0.103
[3.276226] nvidia: loading out-of-tree module taints kernel.
[3.276237] nvidia: module license 'NVIDIA' taints kernel.
[3.323889] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.331884] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.331897] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[3.656855] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[4.900251] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17
[4.900378] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input18
[4.900475] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24
[4.900572] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25
[8.473566] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Apr  8 07:13 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Apr  8 07:14 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Apr  8 07:14 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Apr  8 07:13 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan  5 09:29 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jan  5 09:29 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   54 Jan  5 09:29 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Jan  5 09:29 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   25 Jan  5 09:29 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan  5 09:29 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan  5 09:29 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jan  5 09:29 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jan  5 09:29 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jan  5 09:29 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Jan  5 09:29 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Jan  5 09:27 /etc/alternatives/nvidia -> 
/usr/li

Bug#941951: ITA: tpm2-pk11

[Seunghun Han]

On Mon, 7 Oct 2019 20:33:07 + "proc...@riseup.net"
 wrote:
> Package: wnpp
> X-Debbugs-CC: whonix-de...@whonix.org
>
> * Package name: tpm2-pk11
> Version : ?
> Upstream Author : Iwan Timmer
> * URL   : https://github.com/irtimmer/tpm2-pk11
> * License : BSD 2-Clause "Simplified" License
> Programming Lang:   C
> Description  :  PKCS#11 Module for TPM 2.0
>

Dear Maintainer,

I would like to adopt this package.

Best Regards,

Seunghun

Bug#956181: zlib: provide minizip binary packages

[Michael Gilbert]

package: src:zlib
severity: wishlist
tags: patch

I've been maintaining minizip as a separate source package for the
last few years.  It has become clear that the version included in
zlib/contrib is a more definitive upstream (zlib upstream has done
updates in recent years, minizip upstream has not), so it would make
more sense to provide minizip as part of src:zlib [0].

A few years ago, you were concerned about minizip's ABI changing too
much [1].  That does not seem to have happened.  I diffed minizip 1.1
with the version in zlib/contrib.  The meaningful changes are small
and there is no ABI difference.

Anyway, here is a patch for src:zlib that adds minizip binary
packages.  Please let me know what you think.

Best wishes,
Mike

[0] http://bugs.debian.org/843617
[1] http://bugs.debian.org/574978
diff -Nru zlib-1.2.11.dfsg/debian/changelog zlib-1.2.11.dfsg/debian/changelog
--- zlib-1.2.11.dfsg/debian/changelog	2020-02-24 16:07:12.0 -0500
+++ zlib-1.2.11.dfsg/debian/changelog	2020-04-07 21:50:15.0 -0400
@@ -1,3 +1,9 @@
+zlib (1:1.2.11.dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Build minizip packages.
+
+ -- Michael Gilbert   Wed, 08 Apr 2020 01:50:15 +
+
 zlib (1:1.2.11.dfsg-2) unstable; urgency=low
 
   * Acknowledge previous NMUs (closes: #949388).
diff -Nru zlib-1.2.11.dfsg/debian/control zlib-1.2.11.dfsg/debian/control
--- zlib-1.2.11.dfsg/debian/control	2020-02-24 16:07:12.0 -0500
+++ zlib-1.2.11.dfsg/debian/control	2020-04-07 21:50:15.0 -0400
@@ -4,7 +4,7 @@
 Maintainer: Mark Brown 
 Standards-Version: 3.9.8
 Homepage: http://zlib.net/
-Build-Depends: debhelper (>= 8.1.3~), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 8.1.3~), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1), autoconf
 
 Package: zlib1g
 Architecture: any
@@ -118,3 +118,50 @@
  This package should ONLY be used for building packages, users who do
  not need to build packages should use multiarch to install the relevant
  runtime.
+
+Package: minizip
+Section: utils
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Replaces:
+ zlib-bin,
+Conflicts:
+ zlib-bin,
+Description: compression library - minizip tools
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip and miniunzip tools.
+
+Package: libminizip1
+Architecture: any
+Multi-Arch: same
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: compression library - minizip library
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip library.
+
+Package: libminizip-dev
+Architecture: any
+Multi-Arch: same
+Section: libdevel
+Depends:
+ ${misc:Depends},
+ libminizip1 (= ${binary:Version})
+Replaces:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Breaks:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Description: compression library - minizip development files
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes development support files for the minizip library.
diff -Nru zlib-1.2.11.dfsg/debian/libminizip-dev.install zlib-1.2.11.dfsg/debian/libminizip-dev.install
--- zlib-1.2.11.dfsg/debian/libminizip-dev.install	1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip-dev.install	2020-04-07 21:50:15.0 -0400
@@ -0,0 +1,4 @@
+usr/include/minizip
+usr/lib/*/libminizip.a
+usr/lib/*/libminizip.so
+usr/lib/*/pkgconfig/minizip.pc
diff -Nru zlib-1.2.11.dfsg/debian/libminizip1.install zlib-1.2.11.dfsg/debian/libminizip1.install
--- zlib-1.2.11.dfsg/debian/libminizip1.install	1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip1.install	2020-04-07 21:50:15.0 -0400
@@ -0,0 +1 @@
+usr/lib/*/libminizip.so.*
diff -Nru zlib-1.2.11.dfsg/debian/libminizip1.symbols zlib-1.2.11.dfsg/debian/libminizip1.symbols
--- zlib-1.2.11.dfsg/debian/libminizip1.symbols	1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip1.symbols	2020-04-07 21:50:15.0 -0400
@@ -0,0 +1,68 @@
+libminizip.so.1 libminizip1 #MINVER#
+ LoadCentralDirectoryRecord@Base 1.1
+ Write_EndOfCentralDirectoryRecord@Base 1.1
+ Write_GlobalComment@Base 1.1
+ Write_LocalFileHeader@Base 1.1
+ Write_Zip64EndOfCentralDirectoryLocator@Base 1.1
+ Write_Zip64EndOfCentralDirectoryRecord@Base 1.1
+ call_zopen64@Base 1.1
+ call_zseek64@Base 1.1
+ call_ztell64@Base 1.1
+ fill_fopen64_filefunc@Base 1.1
+ fill_fopen_filefunc@Base 1.1
+ fill_

Bug#955276: [PATCH] audacious-plugins: Missing OpenMPT plugin

[Jonathan Rubenstein]

I've created a Salsa merge request for your convenience:
https://salsa.debian.org/multimedia-team/audacious-plugins/-/merge_requests/1

Thank you for all of your hard work!

Bug#956180: Xwayland: random crash (SIGABRT) during GNOME login: wl_drm@4: error 0: authenicate failed

[Paul Wise]

Package: xwayland
Version: 2:1.20.8-2
Severity: normal
File: /usr/bin/Xwayland
Usertags: crash

After a reboot because of a GPU hang with the nouveau drivers, GDM
started up fine but my initial login failed because Xwayland crashed
with SIGABRT and this message: wl_drm@4: error 0: authenicate failed

I have included the relevant parts of the systemd journal and a full
backtrace for the crash below. I have no way of reproducing this issue.
If additional information is needed the core dump will be available for
one week before it is automatically deleted. If the info provided is
not useful, please close this bug report.

Apr 07 21:38:52 chianamo systemd[1948]: Started GNOME Session Manager (session: 
gnome).
Apr 07 21:38:52 chianamo systemd[1948]: Reached target GNOME Session Manager is 
ready.
Apr 07 21:38:52 chianamo systemd[1948]: Starting GNOME Shell on Wayland...
Apr 07 21:38:52 chianamo gnome-shell[2438]: libEGL warning: Not allowed to 
force software rendering when API explicitly selects a hardware device.
Apr 07 21:38:53 chianamo gnome-shell[2438]: WL: error in client communication 
(pid 2438)
Apr 07 21:38:53 chianamo gnome-shell[2499]: (EE)
Apr 07 21:38:53 chianamo gnome-shell[2499]: Fatal server error:
Apr 07 21:38:53 chianamo gnome-shell[2499]: (EE) wl_drm@4: error 0: authenicate 
failed
Apr 07 21:38:53 chianamo gnome-shell[2499]: (EE)
Apr 07 21:38:53 chianamo systemd[1]: Started Session c2 of user pabs.
Apr 07 21:38:53 chianamo gnome-shell[2438]: X Wayland crashed; exiting
Apr 07 21:38:53 chianamo su[2510]: pam_unix(su:session): session closed for 
user pabs
Apr 07 21:38:53 chianamo systemd[1]: session-c2.scope: Succeeded.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-shell-wayland.service: Failed 
with result 'protocol'.
Apr 07 21:38:53 chianamo systemd[1948]: Failed to start GNOME Shell on Wayland.
Apr 07 21:38:53 chianamo systemd[1948]: Dependency failed for GNOME Shell on 
Wayland.
Apr 07 21:38:53 chianamo systemd[1948]: Dependency failed for GNOME Wayland 
Session.
Apr 07 21:38:53 chianamo systemd[1948]: Dependency failed for GNOME Wayland 
Session (session: gnome).
Apr 07 21:38:53 chianamo systemd[1948]: gnome-session-wayland@gnome.target: Job 
gnome-session-wayland@gnome.target/start failed with result 'dependency'.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-session-wayland.target: Job 
gnome-session-wayland.target/start failed with result 'dependency'.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-session-wayland.target: 
Triggering OnFailure= dependencies.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-shell-wayland.target: Job 
gnome-shell-wayland.target/start failed with result 'dependency'.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-shell-wayland.service: Triggering 
OnFailure= dependencies.
Apr 07 21:38:53 chianamo systemd[1948]: Condition check resulted in Disable 
GNOME Shell extensions after failure being skipped.
Apr 07 21:38:53 chianamo systemd[1948]: Stopped target GNOME Session Manager is 
ready.
Apr 07 21:38:53 chianamo systemd[1948]: Stopping GNOME Session Manager 
(session: gnome)...
Apr 07 21:38:53 chianamo systemd[1948]: gnome-session-manager@gnome.service: 
Succeeded.
Apr 07 21:38:53 chianamo systemd[1948]: Stopped GNOME Session Manager (session: 
gnome).
Apr 07 21:38:53 chianamo systemd[1948]: Stopped target Tasks to be run before 
GNOME Session starts.
Apr 07 21:38:53 chianamo systemd[1948]: Stopped target Session services which 
should run early before the graphical session is brought up.
Apr 07 21:38:53 chianamo systemd[1948]: Reached target Shutdown running GNOME 
Session.
Apr 07 21:38:53 chianamo systemd[1948]: Stopping Monitor Session leader for 
GNOME Session...
Apr 07 21:38:53 chianamo systemd[1948]: Starting Restart DBus after GNOME 
Session shutdown...
Apr 07 21:38:53 chianamo systemd[1948]: Stopped target Shutdown running GNOME 
Session.
Apr 07 21:38:53 chianamo systemd[1948]: Reached target Shutdown running GNOME 
Session.
Apr 07 21:38:53 chianamo systemd[1948]: Stopped target Shutdown running GNOME 
Session.
Apr 07 21:38:53 chianamo systemd[1948]: Started Restart DBus after GNOME 
Session shutdown.
Apr 07 21:38:53 chianamo systemd[1948]: gnome-session-monitor.service: 
Succeeded.
Apr 07 21:38:53 chianamo systemd[1948]: Stopped Monitor Session leader for 
GNOME Session.
Apr 07 21:38:53 chianamo gdm-password][1941]: pam_unix(gdm-password:session): 
session closed for user pabs
Apr 07 21:38:53 chianamo gdm3[1638]: GdmDisplay: Session never registered, 
failing

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply 
all bt full' --core 
/var/crash/1000/2499-1000-1000-6-1586266733-chianamo--usr-bin-Xwayland.core 
/usr/bin/Xwayland
[New LWP 2499]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/Xwayland :0 -rootless -noreset -accessx -core 
-auth /run/user/1000/.mu'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise 

Bug#956179: libspice-client-gtk-3.0-5: Mouse cursor invisible in virt-manager on Wayland

[SuperCat]

Package: libspice-client-gtk-3.0-5
Version: 0.35-2
Severity: normal

Once clicking into the spice-gtk widget in virt-manager, the mouse
cursor becomes invisible on the whole window (not just the VM itself)
- this includes the virt-manager main window if it's open. Clicking on
something that triggers a new cursor shape like the window bar for
dragging restores the cursor.

This problem only exists on Wayland environment.

This bug is already fixed by upstream and no longer exists in 0.37-2
(bullseye/testing).

Upstream bug report: https://gitlab.freedesktop.org/spice/spice-gtk/issues/83

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

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

Versions of packages libspice-client-gtk-3.0-5 depends on:
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libepoxy0   1.5.3-0.1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libpangocairo-1.0-0 1.42.4-7~deb10u1
ii  libspice-client-glib-2.0-8  0.35-2
ii  libx11-62:1.6.7-1

libspice-client-gtk-3.0-5 recommends no packages.

libspice-client-gtk-3.0-5 suggests no packages.

-- no debconf information

Bug#956177: fail2ban: daemon startup should not access /root/.local

[Russell Coker]

Package: fail2ban
Version: 0.11.1-1
Severity: normal

type=AVC msg=audit(1586313861.749:37): avc:  denied  { search } for  pid=704 
comm="fail2ban-server" name=".local" dev="sdb2" ino=31516 
scontext=system_u:system_r:fail2ban_t:s0 
tcontext=unconfined_u:object_r:xdg_data_t:s0 tclass=dir permissive=0

Above is a SE Linux audit message generated by fail2ban starting on system
boot.  It is trying to access /root/.local which is inappropriate for a daemon.
No system configuration should be under /root/ and any daemon which accesses
that could give unexpected results.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages fail2ban depends on:
ii  lsb-base  11.1.0
ii  python3   3.8.2-2

Versions of packages fail2ban recommends:
ii  iptables   1.8.4-3
pn  python3-pyinotify  
pn  python3-systemd
ii  whois  5.5.6

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1
ii  monit1:5.26.0-4
ii  rsyslog [system-log-daemon]  8.2002.0-2
pn  sqlite3  

-- Configuration Files:
/etc/fail2ban/paths-debian.conf changed [not included]

-- no debconf information

Bug#956178: libjna-jni libjnidispatch.system.so has build directory in soname

[Bart Massey]

Package: libjna-jni
Version: 4.5.2-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

Placed the following in /etc/ld.so.conf.d/java-jni.conf

/usr/lib/x86_64-linux-gnu/jni
/usr/lib/jni

and ran ldconfig, which reported

ldconfig: Can't link 
/usr/lib/x86_64-linux-gnu/jni//build/libjna-java-ayrlgf/libjna-java-4.5.2/build/native-linux-x86-64/libjnidispatch.system.so
 to libjnidispatch.system.so

This didn't seem right, so after some tracking down
discovered that the Makefile was borked.

Attached is a tested patch that resolves the problem by
removing the build path from the library soname.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (400, 'oldoldstable'), (400, 'experimental'), 
(400, 'testing'), (400, 'stable'), (400, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libjna-jni depends on:
ii  libc62.30-4
ii  libffi7  3.3-4

libjna-jni recommends no packages.

libjna-jni suggests no packages.

-- no debconf information

--- native/Makefile.dist2020-04-07 19:57:15.443971156 -0700
+++ native/Makefile 2020-04-07 19:57:44.708059780 -0700
@@ -268,10 +268,10 @@
 PCFLAGS+=-fPIC
 CDEFINES+=-DHAVE_PROTECTION
 ifeq ($(DYNAMIC_LIBFFI),true)
-LDFLAGS+=-Wl,-soname,$@
+LDFLAGS+=-Wl,-soname,$(F@)
 else
 # Ensure we bind to local libffi symbols
-LDFLAGS+=-Wl,-soname,$@,-Bsymbolic
+LDFLAGS+=-Wl,-soname,$(F@),-Bsymbolic
 endif
 endif
 

Bug#956176: tracker-miner-fs: random crash: SIGABRT: free(): double free detected in tcache 2

[Paul Wise]

Package: tracker-miner-fs
Version: 2.3.3-1
Severity: normal
File: /usr/libexec/tracker-miner-fs
Usertags: crash

I got a random SIGABRT crash in tracker-miner-fs. It looks like glibc
detected a double free() bug and terminated the program. Based on the
timing and analysis of my systemd journal, I think it happened during a
GNOME login where Xwayland crashed during login so I got logged out
during login. It seems like tracker-miner-fs recieved a SIGTERM before
its startup procedure was completed and this triggered some sort of bug
that lead to the issue. I have no way of reproducing this issue. If the
below backtrace is not useful, please close this bug report. The core
dump will be available for one week before it is automatically deleted.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply 
all bt full' --core 
/var/crash/1000/2380-1000-1000-6-1586266735-chianamo--usr-libexec-tracker-miner-fs.core
 /usr/libexec/tracker-miner-fs
[New LWP 2380]
[New LWP 2401]
[New LWP 2402]
[New LWP 2488]
[New LWP 2399]
[New LWP 2492]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/libexec/tracker-miner-fs'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7faf1baf2200 (LWP 2380))]
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7faf1e83b55b in __GI_abort () at abort.c:79
#2  0x7faf1e894008 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7faf1e9a0f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7faf1e89b3aa in malloc_printerr (str=str@entry=0x7faf1e9a2b90 
"free(): double free detected in tcache 2") at malloc.c:5339
#4  0x7faf1e89d1ed in _int_free (av=0x7faf1e9d2b80 , 
p=0x5586f6769840, have_lock=0) at malloc.c:4201
#5  0x5586f4accbf9 in miner_files_finalize (object=0x5586f675b1f0 
[TrackerMinerFiles]) at ../src/miners/fs/tracker-miner-files.c:882
#6  0x7faf1ecac09e in g_object_unref (_object=) at 
../../../gobject/gobject.c:3499
#7  g_object_unref (_object=0x5586f675b1f0) at ../../../gobject/gobject.c:3391
#8  0x7faf1ecaee51 in g_object_set_valist 
(object=object@entry=0x5586f675b1f0 [TrackerMinerFiles], 
first_property_name=first_property_name@entry=0x7faf1ef2758d "progress", 
var_args=var_args@entry=0x7ffd005418b0) at ../../../gobject/gobject.c:2449
#9  0x7faf1ecaf9ac in g_object_set (_object=_object@entry=0x5586f675b1f0, 
first_property_name=first_property_name@entry=0x7faf1ef2758d "progress") at 
../../../gobject/gobject.c:2612
#10 0x7faf1ef1308b in file_notifier_directory_finished (notifier=, directory=0x5586f69f3160, directories_found=0, 
directories_ignored=, files_found=0, files_ignored=, user_data=0x5586f675b1f0) at 
../src/libtracker-miner/tracker-miner-fs.c:2281
#11 0x7faf1df45ccd in ffi_call_unix64 () at ../src/x86/unix64.S:101
#12 0x7faf1df4525a in ffi_call_int (cif=0x7ffd00541c40, fn=0x7faf1ef13000 
, rvalue=, avalue=, closure=) at ../src/x86/ffi64.c:669
#13 0x7faf1eca7cae in g_cclosure_marshal_generic_va 
(closure=0x5586f6894000, return_value=0x0, instance=, 
args_list=, marshal_data=, n_params=5, 
param_types=0x5586f6894820) at ../../../gobject/gclosure.c:1614
#14 0x7faf1eca7206 in _g_closure_invoke_va (closure=0x5586f6894000, 
return_value=0x0, instance=0x5586f6790320, args=0x7ffd00541ee0, n_params=5, 
param_types=0x5586f6894820) at ../../../gobject/gclosure.c:873
#15 0x7faf1ecc58d4 in g_signal_emit_valist (instance=0x5586f6790320, 
signal_id=, detail=0, var_args=var_args@entry=0x7ffd00541ee0) at 
../../../gobject/gsignal.c:3407
#16 0x7faf1ecc5edf in g_signal_emit 
(instance=instance@entry=0x5586f6790320, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3554
#17 0x7faf1ef1841b in finish_current_directory (notifier=0x5586f6790320 
[TrackerFileNotifier], interrupted=1) at 
../src/libtracker-miner/tracker-file-notifier.c:687
#18 0x7faf1eca918e in g_cclosure_marshal_VOID__BOOLEANv (closure=, return_value=, instance=, args=, marshal_data=, n_params=, 
param_types=0x5586f69a82d0) at ../../../gobject/gmarshal.c:272
#19 0x7faf1eca7206 in _g_closure_invoke_va (closure=0x5586f69a8380, 
return_value=0x0, instance=0x5586f69fcba0, args=0x7ffd00542250, n_params=1, 
param_types=0x5586f69a82d0) at ../../../gobject/gclosure.c:873
#20 0x7faf1ecc58d4 in g_signal_emit_valist (instance=0x5586f69fcba0, 
signal_id=, detail=0, var_args=var_args@entry=0x7ffd00542250) at 
../../../gobject/gsignal.c:3407
#21 0x7faf1ecc5edf in g_signal_emit (instance=, 
signal_id=, detail=detail@entry=0) at 
../../../gobject/gsignal.c:3554
#22 0x7faf1ef207b4 in tracker_crawler_stop (crawler=) at 
../src/libtracker-miner/tracker-crawler.c:1132
#23 0x7faf1ef19379 in tracker_file_notifier_stop (

Bug#956174: Patch

[Jonas Zeiger]

This is the patch I use to workaround the issue:

diff -Naur a/btrfs-progs-5.4.1/debian/local/btrfs.local-premount 
b/btrfs-progs-5.4.1/debian/local/btrfs.local-premount
--- a/btrfs-progs-5.4.1/debian/local/btrfs.local-premount	2020-01-09 
17:49:59.0 +0100
+++ b/btrfs-progs-5.4.1/debian/local/btrfs.local-premount	2020-04-08 
04:19:49.719861972 +0200

@@ -18,7 +18,7 @@

 if [ -x /bin/btrfs ]
 then
-   modprobe btrfs
+   modprobe btrfs || true
# If asked to be quiet, show only errors
[ "${quiet}" = "y" ] && exec >/dev/null
/bin/btrfs device scan

Bug#956175: while removing apparmor, virgin /etc/apparmor.d/local/usr.bin.man missed

[積丹尼 Dan Jacobson]

Package: apparmor
Version: 2.13.4-1
Severity: minor

Purging configuration files for apparmor (2.13.4-1) ...
dpkg: warning: while removing apparmor, directory '/etc/apparmor.d/local' not 
empty so not removed
$ find /etc/apparmor.d/local
/etc/apparmor.d/local
/etc/apparmor.d/local/usr.bin.man
$ cat /etc/apparmor.d/local/usr.bin.man
# Site-specific additions and overrides for usr.bin.man.
# For more details, please see /etc/apparmor.d/local/README.

Bug#956174: initramfs fails to call "btrfs dev scan" when btrfs is a builtin not a module

[Jonas Zeiger]

Package: btrfs-progs
Version: 5.4.1-2

When booting a kernel with BTRFS builtin (not as module) the initramfs
fails to correctly 
chttps://talpidae.net/roundcube/?_task=mail&_action=compose&_id=804132815e8d2a15ae439#all 
the required "btrfs dev scan".


That is due to the call to "modprobe btrfs" failing and thus cancelling
the premount script early without properly discovering the devices.

I would suggest changing
btrfs-progs-5.4.1-2/debian/btrfs-progs/usr/share/initramfs-tools/scripts/local-premount/btrfs
line 21 as follows:

-modprobe btrfs
+modprobe btrfs || true

This will ensure compatibility with custom kernels and still report an
error in case the module is not present (when btrfs device scan is 
called).


Thank you!

Bug#956173: linux: please enable HighDPI font FONT_TER16x32

[Christoph Anton Mitterer]

Source: linux
Version: 5.5.13-2
Severity: wishlist


Hi.

Since quite a while now Linux seems to support a font for HighDPI
displays.

It woudl just need to be enabled:
CONFIG_FONT_TER16x32

Seems it will be auto-selected when appropriate:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dfd19a5004eff03755967086aa04254c3d91b8ec


Thanks,
Chris

Bug#956172: gnome-tweaks: Passing an extension UUID to gnome-shell-extension-prefs is no longer supported in 3.36.1

[Simon McVittie]

Package: gnome-tweaks
Version: 3.34.0-3
Severity: important
Forwarded: https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/283
Tags: bullseye sid upstream
Control: block 954422 by -1

GNOME Shell 3.36.x (currently in experimental, but should be heading to
unstable soon) has a new gnome-shell-extension-prefs package that separates
out the extension preferences app. It's also available as a Flatpak.

gnome-tweaks used to be the place to configure extensions, so it should
probably have a Recommends on gnome-shell-extension-prefs.

The shell extensions tweak group has:

def _on_configure_clicked(self, btn, uuid):
execute_subprocess(['gnome-shell-extension-prefs', uuid], block=False)

which will not work since GNOME Shell 3.36.1, because the way extension
preferences work has been redone to accommodate the g-s-extension-prefs
app being installed via Flatpak or similar.

One way to solve this would be to remove the extensions support (upstream
#272, !50).

Or, if the extensions support is still desired, the new way to load an
extension's prefs seems to be a D-Bus call:

Gio.DBus.session.call(
'org.gnome.Shell.Extensions',
'/org/gnome/Shell/Extensions',
'org.gnome.Shell.Extensions',
'OpenExtensionPrefs',
new GLib.Variant('(ssa{sv})', [uuid, parentWindow, options]),
null,
Gio.DBusCallFlags.NONE,
-1,
null);

(That's Javascript code from GNOME Shell, but the equivalent Python code
should be fairly similar.)

smcv

Bug#956171: gnome-shell-extension-system-monitor: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-system-monitor
Version: 38-2
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: 
https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues/567

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible. From the upstream issue above it seems the answer is "no,
but a branch is available".

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

Thanks,
smcv

Bug#956170: gnome-shell-extension-show-ip: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-show-ip
Version: 8-5
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension launches
gnome-shell-extension-prefs.desktop, which is now named
org.gnome.Extensions.desktop as a result of upstream changes.

Thanks,
smcv

Bug#956169: gnome-shell-extension-multi-monitors: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-multi-monitors
Version: 19-1
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: https://github.com/spin83/multi-monitors-add-on/issues/111

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible. From the upstream issue above it seems the answer is "no,
but patches are in progress".

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

   Util.spawn(["gnome-shell-extension-prefs", "multi-monitors-add-on@spin83"]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956168: gnome-shell-arc-menu please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-arc-menu
Version: 38.3-dev-2
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: https://github.com/lexruee/Arc-Menu/issues/7

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawnCommandLine('gnome-shell-extension-prefs arc-m...@linxgem33.com');

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956167: gnome-shell-mailnag: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 3.28.0-0.1
Severity: importan
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: https://github.com/pulb/mailnag-gnome-shell/issues/66

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(['gnome-shell-extension-prefs', 'mail...@pulb.github.com']);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956166: gnome-shell-extension-easyscreencast: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-easyscreencast
Version: 1.0.2+git20191008-1
Severity: importan
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: https://github.com/EasyScreenCast/EasyScreenCast/issues/247

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Main.Util.trySpawnCommandLine('gnome-shell-extension-prefs  
easyscreenc...@iacopodeenosee.gmail.com');

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#945189: O: python-blosc -- Python 3 bindings for the Blosc meta-compressor

[Emmanuel Arias]

Hi

I would like to adopt this package.


Cheers,

Emmanuel

Bug#956165: gnome-shell-extension-workspaces-to-dock: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-workspaces-to-dock
Version: 52-1
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: https://github.com/passingthru67/workspaces-to-dock/issues/189

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible. From the upstream issue linked above, it seems the answer
is "no, but there's a branch that might be".

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(["gnome-shell-extension-prefs", Me.metadata.uuid]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956164: gnome-shell-extension-weather: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0~20170402.git34506a6-2
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: 
https://gitlab.com/jenslody/gnome-shell-extension-openweather/-/issues/260

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(["gnome-shell-extension-prefs", 
"openweather-extens...@jenslody.de"]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956163: gnome-shell-extension-dashtodock: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-dashtodock
Version: 67-1
Severity: important
Tags: bullseye sid
Control: block 954422 by -1
Forwarded: https://github.com/micheleg/dash-to-dock/pull/1097

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible. It looks as though the answer is "no" at the moment: see
the Github pull request above for current progress.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(["gnome-shell-extension-prefs", Me.metadata.uuid]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

update: I've just tried adding --prefix=/boot/grub to the grub-mkimage
command in binary_iso (which should really be done in binary_grub-pc)
that generates the core_img file that becomes part of grub_eltorito,
and success!

So now that I know how fundamentally to fix the problems, I'll follow
up soon with patches.

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sean Whitton]

Hello,

On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:

>> +The copyright information for files in a package must be copied
>> +verbatim into ``/usr/share/doc/package/copyright``, when
>   ^ Shouldn't this and other instances
> of "package" be marked as replaceable text?

Possibly, though that's an issue with the existing Policy text not this
patch -- perhaps I should just find and replace after applying the patch
from this bug?

> I'm assuming the entire list is supposed to hold at the same time? If
> so perhaps adding an «and» here would make this completely unambiguous.

Hmm, thanks for the feedback, but I don't think "a; b; and c" is
ambiguous in English, and "a; and b; and c" would be an irregular usage.

If this really does need clarification it would be better to add "all of
the following" or something before the list.

> I'm don't think abbreviating debian/ as d/ is appropriate in policy?
> (Personally I fint it annoying also on debian/changelog, because then
> you need to search using multiple variants of the filenames, but meh. :)

Thanks for catching this error -- fixed in my local git branch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sean Whitton]

Hello,

On Tue 07 Apr 2020 at 08:03PM -04, Scott Kitterman wrote:

> On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote:
>> > +#. the distribution license for those files requires that copyright
>> > +   information be included in all copies and/or binary distributions;
>>
>> I'm assuming the entire list is supposed to hold at the same time? If
>> so perhaps adding an «and» here would make this completely unambiguous.
>
> Actually I think it would be the opposite.  If we had:

I think Guillem means adding an 'and' after the semicolon.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#956162: gnome-shell-extension-dash-to-panel: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-dash-to-panel
Version: 31-1
Severity: important
Tags: bullseye sid
Control: block 954422 by -1
Forwarded: https://github.com/home-sweet-gnome/dash-to-panel/issues/936

GNOME Shell 3.36.x is currently in experimental, and should hopefully be
heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(["gnome-shell-extension-prefs", Me.metadata.uuid]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Scott Kitterman]

On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote:
> > +#. the distribution license for those files requires that copyright
> > +   information be included in all copies and/or binary distributions;
> 
> I'm assuming the entire list is supposed to hold at the same time? If
> so perhaps adding an «and» here would make this completely unambiguous.

Actually I think it would be the opposite.  If we had:

> +   information be included in all copies and binary distributions;

then I can see people claiming that since $LICENSE didn't explicitly require 
copyright information in both copies and binaries, they didn't have to do it.

Keep in mind the example license text that I used to frame this part of the 
proposed change:

> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.

I think what you are proposing would produce the opposite of the desired 
policy.  If you don't like and/or, then I think or is better:

> +   information be included in all copies or binary distributions;

Scott K

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

Bug#936612: gimp-plugin-registry: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:18:51 + Matthias Klose  wrote:
> Package: src:gimp-plugin-registry
> Version: 9.20180625
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

Hey Bernd,
i just opened https://github.com/bzed/gimp-plugin-registry/pull/3 to
port the script packaging-helper.py to python 3. This will help with
py2removal as gimp-plugin-registry is one of the only 2 dependencies
on python-debian.  I tested all the cli switches of the script and
they work as intended.

it would be great if you could merge it and release the package soon.

Thanks,
Sandro

Bug#956161: openmpi: FTBFS on hppa - mpi java bindings are enabled

[John David Anglin]

Source: openmpi
Version: 4.03-3
Severity: normal

Dear Maintainer,

Build fails here:

*** Java MPI bindings
checking --with-jdk-bindir value... not found
configure: WARNING: Directory /usr/lib/jvm/default-java/bin not found
configure: error: Cannot continue

The package is configured with "--with-jdk-dir=/usr/lib/jvm/default-java 
--enable-mpi-java".

The NO_JAVA_ARCH define in debian/rules is not effective:
NO_JAVA_ARCH:= hppa hurd-i386 ia64

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=openmpi&arch=hppa&ver=4.0.3-3&stamp=1586273969&raw=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

[brian m. carlson]

On 2020-04-07 at 13:45:20, Daiki Ueno wrote:
> "brian m. carlson"  writes:
> 
> > First, the code to verify the integrity hash is done with memcmp.  This
> > is not safe against timing attacks, so an attacker can tamper with the
> > data and determine how much of the hash matches based on the amount of
> > time it takes[0].  This comparison should be done in a constant-time
> > way.
> >
> > [0] This can be a problem with an untrusted container with the user's
> > home directory mounted in it.  There's documentation for VS Code that
> > tells people how to do exactly this, so it's clearly a common situation.
> 
> Could you elaborate which document you are referring to?  I'm wondering
> how it can be a problem provided that VS Code and gnome-keyring-daemon
> are running as a separate process.  I believe that both snap and flatpak
> provide a process isolation mechanism.

The document at [0] provides documentation on how to mount your home
directory into containers.  It is well known that people download
containers using Docker that are not audited and may contain malware[1].

[2] is an example of a cross-VM cryptographic timing attack, which can
also be applied across processes.  Other timing attacks are known even
across networks.

It is, in general, not safe to assume that any timing attack is
unexploitable.

> > This was originally reported to the Debian Security Team on February 3,
> > but they were unable to issue a CVE, so I reported it to the GNOME
> > Security Team on February 4.  The response was the gnome-keyring team is
> > "aware of those issues" but they "don't think those issues are severe
> > enough to urge an immediate fix" and plan to address them at an
> > unspecified point in the future.
> 
> It's a bit disappointing that you didn't quote the full response with
> the additional context.  Here it goes, for reference:

I believe my report substantially mentioned the relevant points, which
are that

* you are aware of the issues;
* you don't see the issues as warranting an immediate fix; and
* you are working on a plan to address them in gnome-keyring, but the
  point at which they will be fixed is not presently specified.

It was my intention to fairly and accurately present the substance of
your comments as relevant to the bug report without quoting the full
email.  I didn't wish to include the full contents of a private
discussion, some of which would not have even made sense without
additional email context that was not relevant to the bug report.

My response stated my position, which is that letting security
vulnerabilities linger unfixed long term is not in the public interest.
I appreciate that fixing this may be nontrivial, but a prompt and timely
security response is essential.  If I discovered the vulnerabilities,
others probably have, too, and users deserve secure software.

[0] https://code.visualstudio.com/docs/remote/containers
[1] https://www.theregister.co.uk/2017/07/28/malware_docker_containers/
[2] 
https://blog.cryptographyengineering.com/2012/10/27/attack-of-week-cross-vm-timing-attacks/
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Guillem Jover]

Hi!

On Sun, 2020-04-05 at 17:54:01 -0700, Sean Whitton wrote:
> Here's a patch for seconding, and for the FTP Team to approve.  Thanks
> to Scott for prompting the "all copies" amendation.

> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index b8ba081..4217dd4 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -184,15 +184,32 @@ Copyright considerations
>  
[…]
> +The copyright information for files in a package must be copied
> +verbatim into ``/usr/share/doc/package/copyright``, when
  ^ Shouldn't this and other instances
of "package" be marked as replaceable text?

> +
> +#. the distribution license for those files requires that copyright
> +   information be included in all copies and/or binary distributions;

I'm assuming the entire list is supposed to hold at the same time? If
so perhaps adding an «and» here would make this completely unambiguous.

> +#. the files are shipped in the binary package, either in source or
> +   compiled form; and
> +
> +#. the form in which the files are present in the binary package does
> +   not include a plain text version of their copyright notices.
> +
> +Thus, the copyright information for files in the source package which
> +are only part of its build process, such as autotools files, need not
> +be included in ``/usr/share/doc/package/copyright``, because those
> +files do not get installed into the binary package.  Similarly, plain
> +text files which include their own copyright information and are
> +installed into the binary package unmodified need not have that
> +copyright information copied into ``/usr/share/doc/package/copyright``
> +
> +However, the copyright notices for any files which are compiled into
> +the object code shipped in the binary package must all be included in
> +d/copyright when the license requires that copyright information be

I'm don't think abbreviating debian/ as d/ is appropriate in policy?
(Personally I fint it annoying also on debian/changelog, because then
you need to search using multiple variants of the filenames, but meh. :)

Thanks,
Guillem

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

update:

1) from my notes, in fact I'd gone back as far as v5.0 confirming the
presence of the grub-pc failure.

2) I've noticed the presence of the fixed path '/live/vmlinuz' in
binary_grub-efi, and with a hack to have this replaced with the long
name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the
problem, so that explains how the EFI stuff ends up checking that fixed
/live/vmlinuz' path and presents an alternate opportunity for a fix. It
seems the author of the EFI live-build functionality only tested it
with syslinux.

Bug#956160: strip-nondeterminism: Support zip-based OpenJDK symbol file (ct.sym)

[Emmanuel Bourg]

Source: strip-nondeterminism
Version: 1.6.3-2
Severity: normal

Hi,

openjdk-11-jre-headless installs a zip file named ct.sym that doesn't seem
to be normalized by strip-nondeterminism:

  /usr/lib/jvm/java-11-openjdk-amd64/lib/ct.sym

Would it be possible to handle it please?

Thank you,

Emmanuel Bourg

Bug#774330: ntfs-3g: Input/output error when accessing files in mounted partition

[Mauro Meloni]

I've experienced similar errors with ntfs-3g on Buster, while trying to read a 
Windows 10 partition. Were you trying to read a Win10 partition, too?

According to the ArchLinux Wiki about ntfs-3g [1], it may be related to "NTFS 
Reparse Points", that is: system compression, deduplicated files, or OneDrive 
files.
There's a NTFS-3G plugin for reading "system compressed" files [2], but TBH I 
haven't tested it, and according to bug 845162 it is not in Debian yet [3].

 [1] https://wiki.archlinux.org/index.php/NTFS-3G#Compressed_files
[2] https://github.com/ebiggers/ntfs-3g-system-compression[3] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845162

On Tue, 16 Jul 2019 15:48:30 +0200 (CEST) raphael.jo...@free.fr wrote:> The 
problem is back in Buster (can mount filesystem but get I/O Errors).
> Version of ntfs-3g is 2017.3.23AR.3-3.
>

Bug#956159: Package depends on python-glade2 python-gtk2, which are no longer in sid

[積丹尼 Dan Jacobson]

Package: wicd-gtk
Severity: critical
Version: 1.7.4+tb2-6

Package depends on python-glade2 python-gtk2, which are no longer in sid.

Bug#956158: override: debian-multimedia

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
a few more override updates:

multimedia-ambisonics: Override says misc - optional, .deb says metapackages - 
optional
multimedia-djing: Override says misc - optional, .deb says metapackages - 
optional
multimedia-ladi: Override says misc - optional, .deb says metapackages - 
optional
multimedia-devel: Override says misc - optional, .deb says metapackages - 
optional
multimedia-jack: Override says misc - optional, .deb says metapackages - 
optional
multimedia-firewire: Override says misc - optional, .deb says metapackages - 
optional
multimedia-audio-plugins: Override says misc - optional, .deb says metapackages 
- optional
multimedia-drums: Override says misc - optional, .deb says metapackages - 
optional
multimedia-samplers: Override says misc - optional, .deb says metapackages - 
optional
multimedia-recording: Override says misc - optional, .deb says metapackages - 
optional
multimedia-soundsynthesis: Override says misc - optional, .deb says 
metapackages - optional
multimedia-graphics: Override says misc - optional, .deb says metapackages - 
optional
multimedia-players: Override says misc - optional, .deb says metapackages - 
optional
multimedia-midi: Override says misc - optional, .deb says metapackages - 
optional
multimedia-guitar: Override says misc - optional, .deb says metapackages - 
optional
multimedia-video: Override says misc - optional, .deb says metapackages - 
optional
multimedia-mixing: Override says misc - optional, .deb says metapackages - 
optional
multimedia-looping: Override says misc - optional, .deb says metapackages - 
optional
multimedia-musiciantools: Override says misc - optional, .deb says metapackages 
- optional

can you update the override for those packages to `metapackages` section?

thanks!

Bug#925540: qhull: add libqhullcpp to installed libraries

[Barak A. Pearlmutter]

Had not noticed that, thanks!

Next time, do feel free to 0-day NMU, pushing to the shared repo.

But, now that I've seen it, looks great. I'm going to just upload to
unstable. (Hence the term, right?)

Cheers,

--Barak.

Bug#956157: libfontconfig1: FcFreeTypeQueryAll leaks FT_MM_Var data.

[Ben Wagner]

Package: libfontconfig1
Version: 2.13.1-2+b1
Severity: normal
Tags: patch

Request that upstream commits

e2f9f28aed1470a07c33a57940d68b6a3cbe235b [0]
61573ad5f7c4dd0860d613d99d0086433240eb75 [1]

(which are in 2.13.92 and later) be patched into libfontconfig1 2.13.1-3 .
These fix several leaks when a variable font is used with FontConfig. Locally
these changes applied cleanly to the fontconfig 2.13.1-3 source package and
fixes ASAN reports.


[0]
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/e2f9f28aed1470a07c33a57940d68b6a3cbe235b
[1]
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/61573ad5f7c4dd0860d613d99d0086433240eb75



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

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

Versions of packages libfontconfig1 depends on:
ii  fontconfig-config  2.13.1-2
ii  libc6  2.30-4
ii  libexpat1  2.2.9-1
ii  libfreetype6   2.10.1-2
ii  libuuid1   2.34-0.1

libfontconfig1 recommends no packages.

libfontconfig1 suggests no packages.

-- no debconf information

Bug#955964: wmauda: Depends on deprecated dbus-glib

[Doug Torrance]

Control: -1 by 955910

On Sun, Apr 5, 2020 at 10:24 AM  wrote:

> dbus-glib is a deprecated D-Bus library with some significant design
> flaws, and is essentially unmaintained. I would like to minimize its
> use, and eventually remove it from Debian. There will not be a
> version that fixes its design flaws, because that would be a major
> compatibility break, and any user of dbus-glib who is willing to port
> their application to a newer, incompatible version should instead be
> porting their application to a better D-Bus implementation such as
> GDBus.
>
> For most purposes, the recommended replacement for dbus-glib is the
> GDBus family of APIs in GLib, found in . This does not add
> an additional dependency, because dbus-glib already depends on a
> sufficiently new version of GLib. A porting guide is available in the
> GLib documentation:
> . Practical
> examples of porting from dbus-glib to GDBus can be found in the git
> history of most older GNOME applications.
>
> Alternatives to GDBus, with different design emphasis and trade-offs,
> include sd-bus (systemd's D-Bus implementation), QtDBus (Qt's D-Bus
> API), and libdbus (the low-level reference D-Bus implementation).
> Please contact the D-Bus mailing list 
> if you are unsure which D-Bus implementation is most suitable for a
> particular package.
>
> Some libraries expose dbus-glib as part of their API/ABI, in which
> case removing the deprecated dependency requires breaking API/ABI
> (telepathy-glib is a good example). For these libraries, maintainers
> should talk to the dependent library's upstream developers about
> whether the dependent library should break API/ABI and switch to
> GDBus, or whether the dependent library should itself be deprecated.
>
> In a few cases, the package uses the reference D-Bus library libdbus
> for all D-Bus-related APIs, and only uses dbus-glib as a way to
> connect libdbus to the GLib main loop: if the only functions
> referenced from dbus-glib are dbus_connection_setup_with_g_main() and
> dbus_server_setup_with_g_main(), then you are in this situation. The
> recommended replacement in this case is to bundle the dbus-gmain
> branch from the dbus-glib git repository, for example as a `git
> subtree` or `git submodule`. For example, dbus-python's GLib
> integration now works like this. See
>  .md> for more details.


It looks like wmauda only uses dbus-glib because libaudclient uses
dbus-glib, so I'm blocking this bug by the corresponding bug for that
package.

And according to their website [1], libaudclient is no longer actively
maintained.  It hasn't been uploaded to Debian since 2014, so I'm not very
confident that we're going to see a fix lol.

Doug

[1]  https://www.audacious-media-player.org/download

Bug#946853: Upgrade to ACE 6.5.8

[Sudip Mukherjee]

On Tue, Apr 07, 2020 at 01:57:44PM +0200, Johnny Willemsen wrote:
> Hi,
> 
> Would help everyone when someone could upgrade ACE to 6.5.8, the most
> recent micro

I can have a look at the upgrade, but I am not allowed to do that as NMU.
It might be better if the maintainer does it. And also, there is another
pending RC bug #899440, I can not do NMU for that. :(

Though I will suggest that we upload the NMU first and unblock ivtools,
which is failing due to ACE, #954637.

--
Regards
Sudip

Bug#954637: ivtools: FTBFS: os_stropts.h:56:17: fatal error: stropts.h: No such file or directory

[Sudip Mukherjee]

On Tue, Apr 7, 2020 at 10:14 PM Barak A. Pearlmutter
 wrote:
>
> Great. I was about to look at doing an ACE NMU, so that's good to hear.
>
> Turns out there is a new upstream version of the ACE libraries. Not sure if 
> the ACE team is actually active or planning to upgrade. Might be a good idea 
> to give them a ping.

Not sure if they are active. Check #899440. Also, I have added the
mentioned ACE Uploaders in my nmu bug mail, lets see if there is any
response to that.


-- 
Regards
Sudip

Bug#936981: mailnag: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:25:27AM +, Matthias Klose wrote:
> Package: src:mailnag
> Version: 1.2.1-1.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi Vincent,
the recently released 2.0.0 release is ported to Python 3.

Cheers,
Moritz

Bug#956156: RM: lavapdu -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove lavapdu. There hasn't been an upload since 2015, it depends on
Python 2 and the former upstream repository now redirects to
https://github.com/mattface/pdudaemon (which is ported to Python 3 and
available as src:pdudaemon)

Cheers,
Moritz

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:

> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> > On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> >
> > > Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
> > > the
> > > database schema was on my TODO list... it is not implemented yet. I have
> > > just added an issue on the upstream bug tracker to avoid forgetting it:
> > > https://bitbucket.org/sjodogne/orthanc/issues/29
> > >
> > > This feature will be part of forthcoming 1.2.1 release.
> >
> > Thanks a lot for confirming. I will test when 1.2.1 is out
> > and provide a script users can run updating the database
> > schema if needed.
>
> Hello Karsten,
>
> Debian stable now has version 1.5.6 [1] and the upstream bug report is
> marked as resolved [2].  Is a separate update script still needed?  If
> not, can this bug report be closed?

A separate script is never needed because Orthanc itself can
upgrade it's database -- if manually invoked in the right
environment.

The (attached) script makes it a lot easier for users to do
so and it proves (on my machine) that the surprising behaviour
(Orthanc being started after a run with --upgrade) is fixed.

So, the bug can be closed, regardless of the attached script
-- but the attached script is useful to users whenever
another database upgrade comes along (which there will,
eventually).

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
#!/bin/bash

#-
# GPLv2 or later, Karsten Hilbert

#set -x

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace /etc/orthanc/"
ORTHANC_BINARY=`which Orthanc`


echo "Stopping Orthanc server..."
echo "#---" &> ${LOGFILE}
systemctl stop orthanc.service &>> ${LOGFILE}
RESULT=$?
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
sleep 1s
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot stop Orthanc, please inspect the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Attempting database upgrade..."
echo "#---" &>> ${LOGFILE}
echo "Running <${ORTHANC_BINARY} ${ARGS}>" >> ${LOGFILE}
sudo -u orthanc ${ORTHANC_BINARY} ${ARGS} &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
cat ${ORTHANC_LOG} &>> ${LOGFILE}
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Upgrade failed, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Restarting Orthanc server..."
sleep 1s
echo "#---" &>> ${LOGFILE}
systemctl start orthanc.service &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot restart Orthanc, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo ""
echo "Seems successful..."
echo "Log: ${LOGFILE}"
echo ""
systemctl status orthanc.service

#-

Bug#815164: Hi

[Thoon]

--
I will like to discuss a partnership deal with you. Please allow me to give you 
a brief picture of what I have in mind by replying this email

Best Regards,
Yan

thoony...@gmail.com

Bug#956155: buster-pu: package corosync-qdevice/3.0.0-4+deb10u1

[Valentin Vidic]

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

Due to missing Default-Start runlevels, corosync-qdevice cannot be
enabled after installation:

# systemctl enable corosync-qdevice
Synchronizing state of corosync-qdevice.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable corosync-qdevice
update-rc.d: error: corosync-qdevice Default-Start contains no runlevels, 
aborting.


diff -Nru corosync-qdevice-3.0.0/debian/changelog 
corosync-qdevice-3.0.0/debian/changelog
--- corosync-qdevice-3.0.0/debian/changelog 2019-02-04 00:33:24.0 
+0100
+++ corosync-qdevice-3.0.0/debian/changelog 2020-04-07 23:10:01.0 
+0200
@@ -1,3 +1,9 @@
+corosync-qdevice (3.0.0-4+deb10u1) buster; urgency=medium
+
+  * [8de35d1] Set Default-Start runlevels for corosync-qdevice (Closes: 
#932346)
+
+ -- Valentin Vidic   Tue, 07 Apr 2020 23:10:01 +0200
+
 corosync-qdevice (3.0.0-4) unstable; urgency=medium
 
   * [c680521] Revert "Require pacemaker for qdevice autopkgtest"
diff -Nru corosync-qdevice-3.0.0/debian/corosync-qdevice.init 
corosync-qdevice-3.0.0/debian/corosync-qdevice.init
--- corosync-qdevice-3.0.0/debian/corosync-qdevice.init 2019-01-03 
09:18:31.0 +0100
+++ corosync-qdevice-3.0.0/debian/corosync-qdevice.init 2020-04-07 
22:52:15.0 +0200
@@ -7,7 +7,7 @@
 # Provides:corosync-qdevice
 # Required-Start:  $remote_fs $syslog corosync
 # Required-Stop:   $remote_fs $syslog corosync
-# Default-Start:   
+# Default-Start:   2 3 4 5
 # Default-Stop:0 1 6
 # Short-Description:   Corosync Qdevice daemon
 # Description: Starts and stops Corosync Qdevice daemon.

Bug#954362: ncmpc documentation should be split out

[Daniel Kahn Gillmor]

Hi Kaliko--

Thanks for your thoughtful and detailed reply!

On Tue 2020-04-07 16:18:57 +0200, kaliko wrote:
> Here are my propositions.
>
>  * Keep ncmpc-lyrics a separated package
>
> Either
>   1) Move ${sphinxdoc:Depends} to Recommends (as suggested by Daniel)
>   2) Disable HTML build altogether ("html_manual=false" build option)
>
> I'm in favor of 2). Actually the html documentation is nothing more than the 
> html
> version of the man page. As Daniel mentioned ncmpc targets lightweight 
> (non-graphical)
> environment (and advanced users), the regular manual is enough IMHO.

This all looks reasonable to me.  I'm assuming that if you go with (2)
you'd drop sphinxdoc:Depends entirely, reducing the footprint of the
dependencies even further.

Many thanks for maintaining ncmpc in debian.  I've been using it for
years and it Just Works™ -- i haven't had to worry about it or fiddle
with it or anything.  Very much appreciated to have something nice to
use, simple and functional in easy reach!

   --dkg


signature.asc
Description: PGP signature

Bug#954637: ivtools: FTBFS: os_stropts.h:56:17: fatal error: stropts.h: No such file or directory

[Barak A. Pearlmutter]

Great. I was about to look at doing an ACE NMU, so that's good to hear.

Turns out there is a new upstream version of the ACE libraries. Not sure if
the ACE team is actually active or planning to upgrade. Might be a good
idea to give them a ping.

Cheers,

--Barak.

Bug#956153: ITP: fierce -- Domain DNS scanner

[Marcos Fouces]

Package: wnpp
Severity: wishlist
Owner: Marcos Fouces 

* Package name: fierce
  Version : 1.4.0
  Upstream Author : Mschwager 
* URL : https://github.com/mschwager/fierce
* License : GPL
  Programming Lang: Python
  Description : Domain DNS scanner

 Fierce is a semi-lightweight scanner that helps locate non-contiguous
 IP space and hostnames against specified domains. It's really meant as
 a pre-cursor to nmap, unicornscan, nessus, nikto, etc, since all of
 those require that you already know what IP space you are looking for.
 This does not perform exploitation and does not scan the whole internet
 indiscriminately. It is meant specifically to locate likely targets both
 inside and outside a corporate network.
 Because it uses DNS primarily you will often find mis-configured networks
 that leak internal address space. That's especially useful in targeted
malware.
 Originally written by RSnake along with others at http://ha.ckers.org/.
 This is simply a conversion to Python 3 to simplify and modernize the
codebase.

Bug#955456: bitshuffle: diff for NMU version 0.3.5-3.1

[Thorsten Alteholz]

Hi Gilles,

On Tue, 7 Apr 2020, Gilles Filippini wrote:

I've prepared an NMU for bitshuffle (versioned as 0.3.5-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.


oh, great, thanks a lot for taking care of this issue.

  Thorsten

Bug#956154: openjdk-11: Make the copyright date reproducible

[Emmanuel Bourg]

Source: openjdk-11
Version: 11.0.7+9-1
Severity: normal

The makefile of OpenJDK computes the current year to be used in the copyright
templates. By default the year is derived from the current date and this makes
the build non reproducible. There is a --with-copyright-year configure option
to override this date, it can be used to enforce a reproducible date:


diff --git a/debian/rules b/debian/rules
index a8fc578..326b274 100755
--- a/debian/rules
+++ b/debian/rules
@@ -451,6 +451,7 @@ COMMON_CONFIGURE_ARGS += \
--with-pcsclite=system \
--disable-warnings-as-errors \
--disable-javac-server \
+   --with-copyright-year=$(shell dpkg-parsechangelog -STimestamp | date 
--utc +%Y) \

 ifneq (,$(filter $(distrel),precise))
   # building with a GCC from a PPA ...

Bug#955276: [PATCH] audacious-plugins: Missing OpenMPT plugin

[Jonathan Rubenstein]

In my original patch, I placed the added Build-Dependency naïvely next 
to libmodplug instead of alphabetically.


I made sure to test build this fixed patch from a clean unstable VM, and 
the resulting package has the OpenMPT plugin included.


Here is the fixed patch:

--- a/debian/control    2020-04-07 14:29:22.0 -0400
+++ b/debian/control    2020-04-07 14:30:25.090277399 -0400
@@ -35,6 +35,7 @@
  libneon27-gnutls-dev (>= 0.26),
  libnotify-dev,
  libogg-dev (>= 1.0),
+ libopenmpt-dev (>= 0.2),
  libpulse-dev (>= 0.9) [linux-any],
  libsamplerate0-dev (>= 0.0.15),
  libsdl2-dev,

Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax

[Bernhard Übelacker]

Dear Maintainer,
I tried to extract from the submitter's dmesg line the
source location of the crash.

I assume it happened here [1], with
variable s containing an invalid pointer:

0x77f5bb90 in update_rx_timing at t38_gateway.c:2244

2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
2243 {
2244 if (s->core.samples_to_timeout > 0)
2245 {

https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244


Maybe it is of some help.
But a proper backtrace like described in following link would probably
be way better: https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard


From submitter:
[14509242.948899] asterisk[27070]: segfault at 2c7b4 ip 7f9a52389b90 sp 
7f9a23d8a4f8 error 4 in libspandsp.so.2.0.0[7f9a5234d000+56000]
[14509242.948908] Code: 00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 
e8 33 ef ff ff eb e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 
8c 2c 00 00 85 c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a


# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

"error 4"==0: no page found, 0: read access, 1: user-mode access












# Buster/stable amd64 qemu VM 2020-04-07

apt update
apt dist-upgrade

apt install systemd-coredump gdb asterisk asterisk-dbgsym libspandsp2-dbgsym



echo -n "find /b ..., ..., 0x" && \
echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb 
e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85 c0 
7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q
set width 0
set pagination off
file /usr/sbin/asterisk
set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
b main
run
dele 1
info share

find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00, 
0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff, 
0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87, 
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c, 
0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a

b * (0x77f5bb66 + 42)
info b
disassemble /r 0x77f5bb66, 0x77f5bb66 + 62

set max-value-size 10



#




benutzer@debian:~$ echo -n "find /b ..., ..., 0x" && \
> echo "00 00 00 00 00 5b c3 0f 1f 00 e9 1b fd ff ff 0f 1f 00 e8 33 ef ff ff eb 
> e2 90 e9 2b ef ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <8b> 87 8c 2c 00 00 85 
> c0 7e 0c 29 f0 89 87 8c 2c 00 00 85 c0 7e 0a" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x00, 0x00, 0x00, 0x00, 0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00, 
0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 0x00, 0xe8, 0x33, 0xef, 0xff, 0xff, 
0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 
0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 
0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 
0x7e, 0x0a

benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/asterisk
Reading symbols from /usr/sbin/asterisk...Reading symbols from 
/usr/lib/debug/.build-id/23/f49a19a60d0fecbf537ba0f24d2f05792ccf44.debug...done.
done.
(gdb) set environment LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
(gdb) b main
Breakpoint 1 at 0x42e40: file asterisk.c, line 3488.
(gdb) run
Starting program: /usr/sbin/asterisk 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffe5d8) at asterisk.c:3488
3488asterisk.c: Datei oder Verzeichnis nicht gefunden.
(gdb) dele 1
(gdb) info share
FromTo  Syms Read   Shared Object Library
...
0x77f20520  0x77f7473f  Yes 
/usr/lib/x86_64-linux-gnu/libspandsp.so.2.0.0
...
(*): Shared library is missing debugging information.
(gdb) find /b 0x77f20520, 0x77f7473f, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x5b, 0xc3, 0x0f, 0x1f, 0x00, 0xe9, 0x1b, 0xfd, 0xff, 0xff, 0x0f, 0x1f, 
0x00, 0xe8, 0x33, 0xef, 0xff, 0xff, 0xeb, 0xe2, 0x90, 0xe9, 0x2b, 0xef, 0xff, 
0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8b, 
0x87, 0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0c, 0x29, 0xf0, 0x89, 0x87, 
0x8c, 0x2c, 0x00, 0x00, 0x85, 0xc0, 0x7e, 0x0a
0x77f5bb66 
1 pattern found.
(gdb) b * (0x77f5bb66 + 42)
Breakpoint 2 at 0x77f5bb90: file t38_gateway.c, line 2244.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77f5bb90 in update_rx_timing at 
t38_gateway.c:2244
(gdb) disassemble /r 0x77f5bb66, 0x77f5bb66 + 62
Dump of assembler code from 0x77f5bb66 to 0x77f5bba4:
   0x77f5bb66 :00 00   
add%al,(%rax)
   0x77f5bb68 :00 00   
add

Bug#956152: rabbitmq-server: fails to install reliably on arm64

[Paul Gevers]

Package: rabbitmq-server
Version: 3.7.18-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky breaks
Control: affects -1 mcollective

Dear maintainer(s),

As can be seen in the autopkgtests of mcollective [1], rabbitmq-server
fails to reliably install on arm64 as it often fails to start.

Paul

[1] https://ci.debian.net/packages/m/mcollective/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/m/mcollective/4853115/log.gz

Setting up rabbitmq-server (3.7.18-1) ...
Adding group `rabbitmq' (GID 109) ...
Done.
Adding system user `rabbitmq' (UID 107) ...
Adding new user `rabbitmq' (UID 107) with group `rabbitmq' ...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
Not creating home directory `/var/lib/rabbitmq'.
Created symlink
/etc/systemd/system/multi-user.target.wants/rabbitmq-server.service →
/lib/systemd/system/rabbitmq-server.service.
Job for rabbitmq-server.service failed because the control process
exited with error code.
See "systemctl status rabbitmq-server.service" and "journalctl -xe" for
details.
invoke-rc.d: initscript rabbitmq-server, action "start" failed.
● rabbitmq-server.service - RabbitMQ Messaging Server
 Loaded: loaded (/lib/systemd/system/rabbitmq-server.service;
enabled; vendor preset: enabled)
 Active: activating (auto-restart) (Result: exit-code) since Mon
2020-04-06 20:55:24 UTC; 7ms ago
Process: 2726 ExecStart=/usr/sbin/rabbitmq-server (code=exited,
status=1/FAILURE)
   Main PID: 2726 (code=exited, status=1/FAILURE)
dpkg: error processing package rabbitmq-server (--configure):
 installed rabbitmq-server package post-installation script subprocess
returned error exit status 1
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on rabbitmq-server; however:
  Package rabbitmq-server is not configured yet.

dpkg: error processing package autopkgtest-satdep (--configure):
 dependency problems - leaving unconfigured



signature.asc
Description: OpenPGP digital signature

Bug#956151: Lintian: not connecting Maintainer and Changelog name with an umlaut

[Christian Göttsche]

Package: lintian
Version: 2.63.0

Dear Maintainers,

Since version 2.63.0 (including 2.64.0) Lintian does not connect my
name between maintainer and changelog.
So I am getting changelog-should-mention-nmu and
source-nmu-has-incorrect-version-number warnings.

Best regards,
Christian Göttsche

Bug#956151: Lintian: not connecting Maintainer and Changelog name with an umlaut

[Chris Lamb]

Christian Göttsche wrote:

> Since version 2.63.0 (including 2.64.0) Lintian does not connect my
> name between maintainer and changelog.

I think this is a regression from:

  
https://salsa.debian.org/lintian/lintian/commit/6a568fd4b7459f6d4d02306fbc413e687592393a


Regards,

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

Bug#956150: catimg: Package not updating with upstream

[John Allbritten]

Package: catimg
Version: 2.5.0-1+b1
Severity: normal

Dear Maintainer,

`catimg` has a new version upstream, 2.6.0, but the package within
Debian's repos has not updated in over a year. The new release adds a CLI 
option that I require. On the package tracker, it says there
was a problem "while searching for a new upstream version", and cites an
error 429: too many requests on the upstream URL on GitHub. I am not
sure how to resolve this problem but wish for the `catimg` package to be
updated to reflect the new version upstream.


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

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

Versions of packages catimg depends on:
ii  libc6  2.30-4

catimg recommends no packages.

catimg suggests no packages.

-- no debconf information

Bug#956149: cclib-data: FTBFS with python3.8: ModuleNotFoundError: No module named 'pybel'

[Andreas Beckmann]

Source: cclib-data
Version: 1.6.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

cclib-data FTBFS in bullseye and sid:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd /build/cclib-data-1.6.2/.pybuild/cpython3_3.8/build; 
python3.8 -m pytest test
ImportError while loading conftest 
'/build/cclib-data-1.6.2/.pybuild/cpython3_3.8/build/test/conftest.py'.
test/conftest.py:10: in 
from test.test_data import (
test/test_data.py:18: in 
import cclib
/usr/lib/python3/dist-packages/cclib/__init__.py:28: in 
from cclib import parser
/usr/lib/python3/dist-packages/cclib/parser/__init__.py:37: in 
from cclib.io.ccio import ccopen
/usr/lib/python3/dist-packages/cclib/io/__init__.py:11: in 
from cclib.io.cjsonwriter import CJSON as CJSONWriter
/usr/lib/python3/dist-packages/cclib/io/cjsonwriter.py:14: in 
from cclib.io import filewriter
/usr/lib/python3/dist-packages/cclib/io/filewriter.py:30: in 
import pybel as pb
E   ModuleNotFoundError: No module named 'pybel'
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=4: cd 
/build/cclib-data-1.6.2/.pybuild/cpython3_3.8/build; python3.8 -m pytest test
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
returned exit code 13
make: *** [debian/rules:8: binary] Error 25


Andreas


cclib-data_1.6.2-1.log.gz
Description: application/gzip

Bug#956148: python3-virtualenv: Broken venv/bin/pip when using Python 2.7

[Sajith Sasidharan]

Package: python3-virtualenv
Version: 20.0.16-1
Severity: normal

I need to use Python 2.7, but it seems that I can't use Debian's
virtualenv 20.0.16, because venv/bin/pip fails in the following
manner:

$ mkdir /tmp/py
$ cd /tmp/py
$ virtualenv --python=python2.7 venv
$ ./venv/bin/pip
Traceback (most recent call last):
  File "./venv/bin/pip", line 5, in 
from pip._internal.cli.main import main
  File "/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/cli/main.py", 
line 10, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/cli/autocompletion.py", 
line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/cli/main_parser.py", 
line 7, in 
from pip._internal.cli import cmdoptions
  File 
"/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/cli/cmdoptions.py", 
line 25, in 
from pip._internal.locations import USER_CACHE_DIR, get_src_prefix
  File "/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/locations.py", 
line 20, in 
from pip._internal.utils.compat import WINDOWS
  File 
"/tmp/py/venv/lib/python2.7/site-packages/pip/_internal/utils/compat.py", line 
29, in 
import ipaddr as ipaddress  # type: ignore
ImportError: No module named ipaddr

This doesn't seem to happen with Python 3.


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

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

Versions of packages python3-virtualenv depends on:
ii  python-pip-whl  20.0.2-4
ii  python3 3.8.2-2
ii  python3-appdirs 1.4.3-2.1
ii  python3-distlib 0.3.0-1
ii  python3-distutils   3.8.2-2
ii  python3-filelock3.0.12-2
ii  python3-importlib-metadata  1.5.0-1
ii  python3-pkg-resources   44.0.0-1
ii  python3-six 1.14.0-2

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- no debconf information

--
"the lyf so short, the craft so long to lerne."
 -- Chaucer.

Bug#956147: gnome-shell-xrdesktop: Please update for GNOME 3.36 transition

[Simon McVittie]

Source: gnome-shell-xrdesktop
Severity: important
Control: block 954422 by -1
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

GNOME Shell is tightly coupled to corresponding versions of mutter
and gjs, so I don't think it's going to be realistic to support the
versions of gnome-shell and gnome-shell-xrdesktop diverging.

The GNOME team is close to being ready to upload GNOME 3.36 versions
of mutter, gnome-shell and gjs to unstable, which will make
gnome-shell-xrdesktop uninstallable and unbuildable.

To prepare for this, please update gnome-shell-xrdesktop in experimental
to version 3.36.x, and either be ready to upload it to unstable when asked
or give the GNOME team permission to NMU it into unstable. (I don't think
any of us have VR hardware, so we'd have to do this untested.)

Alternatively, if you'd prefer, we could ask the release team to remove
gnome-shell-xrdesktop from testing until a 3.36-based version is available.

Thanks,
smcv

Bug#956146: lintian: check for rules enabling --as-needed

[Andreas Beckmann]

Package: lintian
Version: 2.63.0
Severity: wishlist

Hi,

if I understood correctly, the bullseye toolchain defaults to linking
with --as-needed. Therefore it should no longer be neccessary to inject
-Wl,--as-needed into the build process, allowing d/rules to be further
minimized.

Some common ways of adding --as-needed that I found in the (possibly
ancient) rules files on my local hard disk:

export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
(may include further flags)
(may be quoted, spaced, wrapped)
(may use :=)

dh_autoreconf --as-needed

LDFLAGS += -Wl,--as-needed
(may include further flags)
(may be quoted, spaced, wrapped)
(may use =, :=, export)

dh_auto_configure -- -DCMAKE_EXE_LINKER_FLAGS="-Wl,--as-needed"

$(MAKE) -C ... ... CC='$(CC) $(CPPFLAGS) $(CFLAGS) -Wall 
-Wl,--as-needed $(LDFLAGS)' ...


Andreas

Bug#956144: virtualenv: caching of debian wheels breaks pip-installed virtualenv

[Anthony Sottile]

I failed to include the error message in the report, sorry was a little
rushed

here's the output of the last command:

```
root@378c3ad9bbf3:/# venv2/bin/pip install astpretty
Traceback (most recent call last):
  File "venv2/bin/pip", line 5, in 
from pip._internal.cli.main import main
  File "/venv2/lib/python3.8/site-packages/pip/_internal/cli/main.py", line
10, in 
from pip._internal.cli.autocompletion import autocomplete
  File
"/venv2/lib/python3.8/site-packages/pip/_internal/cli/autocompletion.py",
line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File
"/venv2/lib/python3.8/site-packages/pip/_internal/cli/main_parser.py", line
7, in 
from pip._internal.cli import cmdoptions
  File
"/venv2/lib/python3.8/site-packages/pip/_internal/cli/cmdoptions.py", line
24, in 
from pip._internal.exceptions import CommandError
  File "/venv2/lib/python3.8/site-packages/pip/_internal/exceptions.py",
line 10, in 
from pip._vendor.six import iteritems
ModuleNotFoundError: No module named 'pip._vendor.six'
```

On Tue, Apr 7, 2020 at 12:51 PM Anthony Sottile 
wrote:

> Package: virtualenv
> Version: 20.0.16-1
> Severity: normal
> Tags: patch
>
> Reproduction:
>
> ```bash
> apt update && apt install -y --no-install-recommends virtualenv
> virtualenv venv
> venv/bin/pip install virtualenv
> venv/bin/virtualenv venv2
> venv2/bin/pip install astpretty
> ```
>
> This was originally reported here:
> https://github.com/pre-commit/pre-commit/issues/1383
>
> The root cause is virtualenv's appdata cache is poisoned by the debian
> patched
> wheels which results in all invocations by unpatched virtualenv failing by
> using debian's cache.  My proposal is to separate debian's cache from the
> normal name to prevent this collision.  Here's a patch to the installed
> code
> which fixes this issue:
>
> ```diff
> ---
> /usr/lib/python3/dist-packages/virtualenv/seed/via_app_data/via_app_data.py.old
>2020-04-07 19:41:09.613187290 +
> +++
> /usr/lib/python3/dist-packages/virtualenv/seed/via_app_data/via_app_data.py2020-04-07
> 19:41:17.601187290 +
> @@ -18,7 +18,7 @@
>  def __init__(self, options):
>  super(FromAppData, self).__init__(options)
>  self.symlinks = options.symlink_app_data
> -self.base_cache = self.app_data / "seed-app-data" / "v1.0.1"
> +self.base_cache = self.app_data / "seed-app-data" /
> "v1.0.1.debian"
>
>  @classmethod
>  def add_parser_arguments(cls, parser, interpreter, app_data):
> ```
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-91-generic (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
>
> Versions of packages virtualenv depends on:
> ii  python3-virtualenv  20.0.16-1
>
> virtualenv recommends no packages.
>
> virtualenv suggests no packages.
>
> -- no debconf information
>

Bug#956145: qemu: CVE-2020-11102

[Salvatore Bonaccorso]

Source: qemu
Version: 1:4.2-3
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for qemu.

CVE-2020-11102[0]:
| hw/net/tulip.c in QEMU 4.2.0 has a buffer overflow during the copying
| of tx/rx buffers because the frame size is not validated against the
| r/w data length.

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-11102
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11102
[1] https://www.openwall.com/lists/oss-security/2020/04/06/1

Regards,
Salvatore

Bug#956144: virtualenv: caching of debian wheels breaks pip-installed virtualenv

[Anthony Sottile]

Package: virtualenv
Version: 20.0.16-1
Severity: normal
Tags: patch

Reproduction:

```bash
apt update && apt install -y --no-install-recommends virtualenv
virtualenv venv
venv/bin/pip install virtualenv
venv/bin/virtualenv venv2
venv2/bin/pip install astpretty
```

This was originally reported here: 
https://github.com/pre-commit/pre-commit/issues/1383

The root cause is virtualenv's appdata cache is poisoned by the debian patched
wheels which results in all invocations by unpatched virtualenv failing by
using debian's cache.  My proposal is to separate debian's cache from the
normal name to prevent this collision.  Here's a patch to the installed code
which fixes this issue:

```diff
--- 
/usr/lib/python3/dist-packages/virtualenv/seed/via_app_data/via_app_data.py.old 
2020-04-07 19:41:09.613187290 +
+++ 
/usr/lib/python3/dist-packages/virtualenv/seed/via_app_data/via_app_data.py2020-04-07
 19:41:17.601187290 +
@@ -18,7 +18,7 @@
 def __init__(self, options):
 super(FromAppData, self).__init__(options)
 self.symlinks = options.symlink_app_data
-self.base_cache = self.app_data / "seed-app-data" / "v1.0.1"
+self.base_cache = self.app_data / "seed-app-data" / "v1.0.1.debian"
 
 @classmethod
 def add_parser_arguments(cls, parser, interpreter, app_data):
```


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

Kernel: Linux 4.15.0-91-generic (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages virtualenv depends on:
ii  python3-virtualenv  20.0.16-1

virtualenv recommends no packages.

virtualenv suggests no packages.

-- no debconf information

Bug#956013: Fails to install

[David Prévot]

Le 07/04/2020 à 09:30, Dr. Tobias Quathamer a écrit :
> Am 06.04.20 um 20:13 schrieb David Prévot:
>> Anyway, you could simply upload a manpages-fr-extra update providing the
>> dummy package instead of adding it in manpages-l10n (and be bugged by
>> version handling and NEW processing) if you want this issue resolved
>> quickly.
> 
> Right, thanks for this hint. I'm currently uploading a new package for
> manpages-l10n with hopefully correct Breaks/Replaces.

Great. I assume you’ve already re-read the Policy stanza on that matter
(which is really explicit for once ;).

https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages

> David, if you agree, I'll upload manpages-fr-extra as a dummy
> transitional package afterwards.

Wonderful, thank you.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#955456: bitshuffle: diff for NMU version 0.3.5-3.1

[Gilles Filippini]

Control: tags 955456 + pending


Dear maintainer,

_g.

I've prepared an NMU for bitshuffle (versioned as 0.3.5-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru bitshuffle-0.3.5/debian/changelog bitshuffle-0.3.5/debian/changelog
--- bitshuffle-0.3.5/debian/changelog   2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/changelog   2020-04-07 20:50:47.0 +0200
@@ -1,3 +1,21 @@
+bitshuffle (0.3.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Drew Parsons , Gilles Filippini  ]
+  * Closes: #955456
+- fix-deprecated.patch: fix test_h5filter.py and test_h5plugin.py
+  to open files with flag 'w' when required
+- Build-Depends: python3-h5py-mpi to force using the mpi flavour
+  of h5py
+- override_dh_auto_test:
+  - Run the tests via mpirun so that h5py knows it has to invoke its
+mpi implementation
+  - Launch the tests for each python version separately to permit MPI
+initialization at each run
+
+ -- Gilles Filippini   Tue, 07 Apr 2020 20:50:47 +0200
+
 bitshuffle (0.3.5-3) unstable; urgency=medium
 
   * don't use -march=native when building the package
diff -Nru bitshuffle-0.3.5/debian/control bitshuffle-0.3.5/debian/control
--- bitshuffle-0.3.5/debian/control 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/control 2020-04-06 14:46:51.0 +0200
@@ -11,7 +11,7 @@
 #  , libopenmpi-dev
, openmpi-bin
, python3-setuptools
-   , python3-h5py
+   , python3-h5py-mpi
 , quilt
 , cmake
, pkg-config
diff -Nru bitshuffle-0.3.5/debian/patches/fix-deprecated.patch 
bitshuffle-0.3.5/debian/patches/fix-deprecated.patch
--- bitshuffle-0.3.5/debian/patches/fix-deprecated.patch1970-01-01 
01:00:00.0 +0100
+++ bitshuffle-0.3.5/debian/patches/fix-deprecated.patch2020-04-06 
14:46:44.0 +0200
@@ -0,0 +1,53 @@
+Index: bitshuffle-0.3.5/bitshuffle/tests/test_h5filter.py
+===
+--- bitshuffle-0.3.5.orig/bitshuffle/tests/test_h5filter.py
 bitshuffle-0.3.5/bitshuffle/tests/test_h5filter.py
+@@ -23,7 +23,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008, 32000),
+ filter_flags=(h5z.FLAG_MANDATORY, h5z.FLAG_MANDATORY),
+@@ -43,7 +43,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008, 32000),
+ filter_flags=(h5z.FLAG_MANDATORY, h5z.FLAG_MANDATORY),
+@@ -65,7 +65,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008,),
+ filter_flags=(h5z.FLAG_MANDATORY,),
+Index: bitshuffle-0.3.5/bitshuffle/tests/test_h5plugin.py
+===
+--- bitshuffle-0.3.5.orig/bitshuffle/tests/test_h5plugin.py
 bitshuffle-0.3.5/bitshuffle/tests/test_h5plugin.py
+@@ -34,7 +34,7 @@ class TestFilterPlugins(unittest.TestCas
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ tid = h5t.py_create(dtype, logical=1)
+ sid = h5s.create_simple(shape, shape)
+ #
+@@ -72,7 +72,7 @@ class TestFilterPlugins(unittest.TestCas
+ #return
+ ## Does not appear to be supported by h5py.
+ #fname = "tmp_test_h5py_hl.h5"
+-#f = h5py.File(fname)
++#f = h5py.File(fname, 'w')
+ #f.create_dataset("range", np.arange(1024, dtype=np.int64),
+ #compression=32008)
+ 
diff -Nru bitshuffle-0.3.5/debian/patches/series 
bitshuffle-0.3.5/debian/patches/series
--- bitshuffle-0.3.5/debian/patches/series  2019-12-01 19:03:38.0 
+0100
+++ bitshuffle-0.3.5/debian/patches/series  2020-04-06 14:46:44.0 
+0200
@@ -1,2 +1,3 @@
 hdf5-old-api.patch
 change-build-flags.patch
+fix-deprecated.patch
diff -Nru bitshuffle-0.3.5/debian/rules bitshuffle-0.3.5/debian/rules
--- bitshuffle-0.3.5/debian/rules   2019-08-20 19:29:38.0 +0200
+++ bitshuffle-0.3.5/debian/rules   2020-04-06 14:46:58.0 +0200
@@ -24,5 +24,11 @@
 %:
dh $@ --with python3 --buildsystem

Bug#956143: ITP: python-enmerkar -- Utilities for using Babel in Django

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-enmerkar
  Version : 0.7.1
  Upstream Author : Christopher Grebs 
* URL : https://github.com/Zegocover/enmerkar
* License : BSD
  Programming Lang: Python
  Description : Utilities for using Babel in Django

 This package contains various utilities for integration of Babel into the
 Django web framework:
  * A message extraction plugin for Django templates.
  * A middleware class that adds the Babel Locale object to requests.
  * A set of template tags for date and number formatting.

This is a new (build-)dependency of Horizon, the OpenStack dashboard.

Bug#956013: Fails to install

[Dr. Tobias Quathamer]

Am 06.04.20 um 20:13 schrieb David Prévot:
> Anyway, you could simply upload a manpages-fr-extra update providing the
> dummy package instead of adding it in manpages-l10n (and be bugged by
> version handling and NEW processing) if you want this issue resolved
> quickly.

Right, thanks for this hint. I'm currently uploading a new package for
manpages-l10n with hopefully correct Breaks/Replaces.

David, if you agree, I'll upload manpages-fr-extra as a dummy
transitional package afterwards.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#951007: gradle: please update gradle-javascript for libsimple-http-java 6.0.1

[Sudip Mukherjee]

On Sun, Feb 09, 2020 at 09:43:24AM -0800, tony mancill wrote:
> Source: gradle
> Severity: wishlist
> 
> This bug is for coordination/tracking...  Sudip Mukherjee has been kind
> enough to update simple-http to modern version that has been uploaded to
> experimental.  Now we need to update gradle-javascript to be able to
> find simple.jar.

For records, copying from a mail I sent to Tony about this:

I managed to take a look and iiuc, I think we have a problem.
gradle depends on gradle to build itself. So, when I try to build
gradle with new simple-http, old gradle is not finding simple.jar and
is failing. I checked upstream gradle and they have not updated
simple-http version and I think they might have also faced the same
problem and could not update.
I think the only solution is to modify simple-http so that it creates
a temporary simple.jar and then we can build gradle to use with new
jar files and then we can remove the temporary simple.jar in a next
release of simple-http.

And then from another subsequent mail:

I did manage to add some hack to
create a single jar file but gradle still failed to build. It seems
only a single jar is not enough, the updated simple-http has also
removed some class and gradle is using them like
org.simpleframework.http.resource.FileContext or
org.simpleframework.http.core.ContainerServer and gradle is using
these classes. :(
I checked upstream gradle and that also is using these classes.
https://github.com/ngallagher/simpleframework/issues/15 was already
opened for ContainerServer.
I guess we can not use updated libsimple-http-java until upstream
gradle also refactor their code and start using the new lib.


--
Regards
Sudip

Bug#956121: Blank screen on 2nd display using wayland

[Simon McVittie]

On Tue, 07 Apr 2020 at 17:43:25 +0200, Pierre Cheynier wrote:
> When upgrading mutter from 3.34.3-1 to 3.34.4-1 (testing), my second
> screen (eDP / 3440x1440) is completely white, the second one show
> glitches and freezes during a few tens sec. probably while trying to
> sync the other one before aborting.

Is this reproducible by upgrading/downgrading only libmutter-5-0 and
closely-related packages, without altering anything else?

Are you able to test this with mutter and gnome-shell 3.36.x from
experimental? We're close to uploading those to unstable.

> HW setup: i915
> 
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> processor Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro
> K2000M] (rev a1)

You appear to have a dual-GPU system. Is the NVIDIA device completely
disabled, or are they both active via some sort of dual-GPU arrangement
like Bumblebee?

Do you have the proprietary NVIDIA drivers installed? (I'm guessing you
don't, because reportbug would have told us about the non-free module.)

> Anything relevant that would help troubleshooting the issue?

systemd journal entries during GNOME Shell startup and around the time
you reproduce a bug are usually useful, particularly for hardware-related
things like this.

(Or during mutter startup and around the time you reproduce a bug, if
you are genuinely using the standalone mutter executable - which is not
really recommended, but should in principle work.)

Looking at the commits between 3.34.3 and 3.34.4,
"renderer-native: Fix memory leak in secondary GPU update" and
"kms-impl-simple: Handle mode set race conditions gracefully" look
potentially relevant as things that might have caused a regression,
but I'm just guessing really.

smcv

Bug#956142: ceph: CVE-2020-1760

[Salvatore Bonaccorso]

Source: ceph
Version: 14.2.8-2
Severity: important
Tags: security upstream
Control: found -1 12.2.11+dfsg1-2.1
Control: found -1 10.2.11-2

Hi,

The following vulnerability was published for ceph.

CVE-2020-1760[0]:
| header-splitting in RGW GetObject has a possible XSS

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-1760
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1760
[1] https://www.openwall.com/lists/oss-security/2020/04/07/1

Regards,
Salvatore

Bug#956141: anbox: please document the need and location of android images

[Andres Salomon]

Package: anbox
Version: 0.0~git20191115-1+b1
Severity: wishlist

It wasn't clear after installing the anbox package how to actually get 
it to work. The README.Debian describes the commands to run, but 
doesn't mention anything about the need to download an android rootfs 
image. I found instructions by googling 
(https://github.com/anbox/anbox/issues/179) for an image to download 
and other instructions saying to rename it to android.img and sticking 
it into /var/lib/anbox.


The debian package should really describe this process, though. The 
official anbox documentation tells you to use snapd, and the snapd 
installation seems to automatically grab an android image.

Bug#956139: ceph: CVE-2020-1759

[Salvatore Bonaccorso]

Source: ceph
Version: 14.2.8-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for ceph.

CVE-2020-1759[0]:
|ceph: secure mode of msgr2 breaks both confidentiality and integrity
|aspects for long-lived sessions

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-1759
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1759
[1] https://www.openwall.com/lists/oss-security/2020/04/07/2

Regards,
Salvatore

Bug#956140: xtail: wrong licensing for packaging

[Joao Eriberto Mota Filho]

Package: xtail
Version: 2.1-6
Severity: normal

The original packaging (2001) used BSD as licensing for xtail[1] (for upstream
source code). Before 1.0 format[2], when a packaging licensing was not declared,
the same license for the upstream was considered for packaging.

[1] 
https://salsa.debian.org/debian/xtail/-/commit/957108b1ffab7b61f53adde13d7d5a8caec036ba
[2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

In 2.1-6 revision the upstream changed the licensing to a public domain like
(Unlicense[3][4]). This change was applied in 2.1-6 revision (all right) but the
packaging license was also changed, now for GPL-2+[3] without any asking for
permission for previous holders (Roderick Schertler and Joao Eriberto Mota
Filho). Other consideration is that GPL-2+ is incompatible with the upstream
licensing (BSD and public domain).

[3] 
https://salsa.debian.org/debian/xtail/-/commit/8f5f4a547ba413bb3fdc8bc9d028c652a9ee3708
[4] https://www.unicom.com/sw/license

Conclusion: the packaging licensing should be reverted to BSD.

Regards,

Eriberto

Bug#956138: fonts-fork-awesome: New upstream version available

[Michele Cane]

Package: fonts-fork-awesome
Version: 1.1.5+ds1-2
Severity: wishlist

Dear Maintainer,

the uspream version 1.1.7 is available. Could you please consider packaging it.

Thanks in advance.

Best regards

Mike

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

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

-- no debconf information

Bug#954157: test-depends outside main prohibited

[Rebecca N. Palmer]

On 07/04/2020 18:55, Paul Gevers wrote:

However, you can change the phrasing. E.g.:

For Debian, the ftp-master have ruled that tests must not execute code
they download. In particular, tests must not use external repositories
to depend on software (as opposed to data) that is not in Debian.
However, currently there is nothing preventing this.


Fine by me.


Do we have a link to point at?


https://ftp-master.debian.org/REJECT-FAQ.html Non-Main II or this bug.

Bug#956137: ITP: golang-github-jackpal-go-nat-pmp -- A Go language client for the NAT-PMP internet protocol for port mapping and discovering the external IP address of a firewall.

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-jackpal-go-nat-pmp
  Version : 1.0.2-1
  Upstream Author : Jack Palevich
* URL : https://github.com/jackpal/go-nat-pmp
* License : TODO
  Programming Lang: Go
  Description : A Go language client for the NAT-PMP internet
protocol for port mapping and discovering the external IP address of a
firewall.

This is needed for Syncthing.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#956136: nanopolish: FTBFS (undefined references)

[Bas Couwenberg]

Source: nanopolish
Version: 0.12.1-1
Severity: serious
Tags: ftbfs
Justification: makes the package in question unusable or mostly so
Control: block 954654 by -1

Dear Maintainer,

Your packages fails to build in unstable:

 /usr/bin/ld: /tmp/nanopolish.HEB8tw.ltrans12.ltrans.o: in function 
`populate_maps_from_fastq(OutputHandles&, std::__cxx11::basic_string, std::allocator > const&, 
std::unordered_map, 
std::allocator >, std::__cxx11::basic_string, std::allocator >, 
std::hash, 
std::allocator > >, std::equal_to, std::allocator > >, 
std::allocator, std::allocator > const, 
std::__cxx11::basic_string, std::allocator > 
> > >&, std::unordered_map, std::allocator >, std::vector >, std::hash, std::allocator > >, 
std::equal_to, 
std::allocator > >, 
std::allocator, std::allocator > const, std::vector > > > >&, sam_hdr_t*, mm_mapopt_t, mm_idx_t*) [clone 
._omp_fn.0]':
 ./src/nanopolish_call_methylation.cpp:536: undefined reference to `mm_map'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:551: undefined reference to 
`mm_write_sam'
 /usr/bin/ld: /tmp/nanopolish.HEB8tw.ltrans12.ltrans.o: in function 
`run_watch_mode(__faidx_t const*)':
 ./src/nanopolish_call_methylation.cpp:668: undefined reference to `mm_verbose'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:669: undefined reference to 
`mm_set_opt'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:674: undefined reference to 
`mm_idx_reader_open'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:677: undefined reference to 
`mm_idx_reader_read'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:678: undefined reference to 
`mm_mapopt_update'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:681: undefined reference to 
`mm_idx_reader_read'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:758: undefined reference to 
`mm_idx_destroy'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:759: undefined reference to 
`mm_idx_reader_close'
 /usr/bin/ld: ./src/nanopolish_call_methylation.cpp:520: undefined reference to 
`mm_tbuf_init'
 /usr/bin/ld: 
/tmp/nanopolish.HEB8tw.ltrans12.ltrans.o:./src/nanopolish_call_methylation.cpp:577:
 undefined reference to `mm_tbuf_destroy'
 collect2: error: ld returned 1 exit status
 make[1]: *** [Makefile:165: nanopolish] Error 1

https://buildd.debian.org/status/fetch.php?pkg=nanopolish&arch=amd64&ver=0.12.1-1&stamp=1586252670&raw=0

Kind Regards,

Bas

Bug#954157: test-depends outside main prohibited

[Paul Gevers]

Hi Rebecca,

On 07-04-2020 16:00, Rebecca N. Palmer wrote:
> Then we should change the documentation to state the actual policy...

But this document is the autopkgtest specification, not a policy.

> --- a/doc/README.package-tests.rst
> +++ b/doc/README.package-tests.rst
> @@ -435,6 +435,10 @@ services and thus their testing should actually
> cover those too, to
>  ensure that the distribution package keeps working with their
>  corresponding web service.
> 
> +In Debian, tests are not allowed to execute code they download.
> +In particular, tests must not use external repositories to depend on
> +software (as opposed to data) that is not in Debian.
> +
>  Debian's production CI infrastructure allows unrestricted network
>  access, in Ubuntu's infrastructure access to sites other than
>  `*.ubuntu.com` and `*.launchpad.net` happens via a proxy (limited to

So, I don't agree with this change, at least not with the current
wording. The autopkgtest package is not meant and shouldn't be used to
document the ftp-master policy. However, you can change the phrasing. E.g.:

For Debian, the ftp-master have ruled that tests must not execute code
they download. In particular, tests must not use external repositories
to depend on software (as opposed to data) that is not in Debian.
However, currently there is nothing preventing this.

Do we have a link to point at?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#956135: blueman v. 2.0.8-1

[pham...@bluewin.ch]

Package: blueman 
Version: v. 2.0.8-1
Bug Description :
Hello, I'm using my new bluetooth headphones on Linux Debian 10 Buster (Sony 
WH-1000XM3).
When I link it to my laptop everything works perfectly the first time (although 
I unfortunately do not seem to benefit from the LDAC codec for which I bought 
this headset, it works satisfactorily in A2DP Sink). If I turn off this headset 
and I want to reuse it later, the connection is made but instead of being of 
good quality (A2DP Sink) it is done in SBS (HSP / HFP) which is of very poor 
quality. I am very unhappy with the result...
Is there a way to force the connection in A2DP Sink or to deactivate the codec 
SBS (HSP / HFP) which I do not use and thus to force the connection in A2DP 
mode Sink ? Is it possible to use the LDAC codec from Sony which is available 
for free for Android phones which is based on Linux ?
I'm on Debian 10 Buster x64 Bits, Desktop environment Cinnamon 3.8, BlueZ is on 
v. 5.50-1.2~deb10u1
Best regards.
Philippe

Bug#955977: openldap: No manual page for module 'pw-argon2'

[Ryan Tandy]

Thanks again! Let's try and fast-track these into upstream, and then I 
can just import the latest version of the whole thing...

Bug#956134: lintian: Do not warn about missing python3-all build-depends when there is python3-all-{dev,dbg}

[Dmitry Shachnev]

Package: lintian
Version: 2.64.0

Dear Maintainer,

For pyqt5 package, lintian emits a warning
runtime-test-file-uses-supported-python-versions-without-python-all-build-depends.

Indeed this package does not build-depend on python3-all explicitly, but it
build-depends on python3-all-dev and python3-all-dbg, both of which imply
python3-all.

Please do not emit this warning in such cases.

The same applies to autopkgtests: when you fix #954868, please allow for the
test to depend on python3-all-dbg.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#956133: RM: forg -- RoQA; Dead upstream, depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove forg. It's dead upstream, depends on Python 2 and hasn't seen
a maintainer upload since 2006.

Cheers,
Moritz

Bug#938614: Unlikely to be ported

[Moritz Mühlenhoff]

On Fri, Mar 27, 2020 at 07:26:54PM +, jel...@debian.org wrote:
> On Fri, Mar 27, 2020 at 07:45:20PM +0100, Moritz Mühlenhoff wrote:
> > On Mon, Nov 11, 2019 at 12:44:45PM +, Jelmer Vernooij wrote:
> > > FWIW it looks unlikely that upstream will migrate to Python 3 in the
> > > near future; see e.g.
> > > https://github.com/syncthing/syncthing-gtk/pull/475
> > 
> > Let's remove it for now, then? This blocks a number of Py2 removals
> > at this point.
> That sounds reasonable to me, if this is blocking other packages now.
> 
> I was hoping for movement upstream, but that does not seem to be
> happening.
> 
> Happy for you to file a removal request, or I can do it when I have a
> free moment this weekend.

Ack, I've just filed an RM bug and CCed you.

Cheers,
Moritz

Bug#956129: RM: syncthing-gtk -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove syncthing-gtk. It depends on Python 2 and no Py3 is
foreseeable. Jelmer (CCed) acked the removal in #938614.

Cheers,
Moritz

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Package: live-build
Version: 1:20191221

As mentioned previously in work on an MR, testing images built with
grub (grub-pc and grub-efi) instead of syslinux, I've found that they
are non-bootable, at least with ISO images and in the VM I used.

 - If you use `--bootloaders=grub-pc` on an otherwise default config,
booting the image in a VM (BIOS based) results in a blinking underline
in the top left of a black screen.
 - If you use `--bootloaders=grub-pc,grub-efi` then you get the same
for grub-pc using the VM in BIOS mode of course, and an error regarding
a missing '/live/vmlinuz' in EFI mode (again on an otherwise black
screen).
 - I have not bothered trying `--bootloaders=grub-efi` only, but expect
no difference.
 - I have not bothered trying grub-legacy.

Investigating, there are definitely two parts to this problem. I have
identified one issue, for which I will craft a patch in due course; the
other I do not yet know the cause of. I'm submitting this to ensure
that the problem is documented, until such time as it is completely
solved.

The one issue that I have identified (as I'd previously guessed at) is
that the syslinux script takes responsibility for creating copies of
the kernel files with short filenames. When syslinux is not used, the
kernel files with short filenames (/live/vmlinuz and /live/initrd.img)
do not exist. I have confirmed with a modified image that when the
short filename copies of the kernel files are present, the issue in EFI
mode goes away. So one part of the solution is to move the creation of
the short filename files out of the syslinux script to something used
in all (or more) cases. (Since I cannot see any reference to the
filename/path in creation of the ISO, I presume /live/vmlinuz and
/live/initrd.img paths are hard coded into the grub EFI binaries, so
this is therefore the only solution, not just probably the ideal one
anyway).

This does not however solve the problem with BIOS mode (i.e. grub-pc).
I do not know the cause of the failure here. Hence I felt it
appropriate to get a bug report created.

Note that I have previous made some effort to try to try to locate the
point at which grub-pc last worked, if it ever did, but only got as far
as confirming that this is not a problem introduced by any of my recent
work. It predates that, if grub-pc support ever actually worked at all
(I would not be surprised if it has always been broken).

Again, all my testing has been with ISO images. I've not tried any
others.