Bug#990066: unblock: distcc/3.3.2-10+deb10u1

[Christian Marillat]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: maril...@debian.org

Please unblock package distcc

The Debian script update-distcc-symlinks who generate gcc/clang symlinks in
/usr/lib/distcc doesn't work with gcc cross compiler and clang.

This bug has been "fixed" in 3.3.2-6 by installing the upstream python
script, but I reverted to the Debian perl script in 3.3.2-8 to not depends
on python3 without reopening/fixing bug #919704

The updated code come from the unstable package (Fixed in 3.3.3-1).

[ Impact ]
Users can't use distcc with clang and gcc cross compiler.

[ Tests ]
The same code is in unstable since august 2019 without problem.

[ Risks ]
No risk.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock distcc/3.3.2-10+deb10u1



distcc_3.3.2-10+deb10u1.debdiff
Description: Binary data

Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1

[Hideki Yamane]

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

Please unblock package squid-deb-proxy

[ Reason ]
 squid-deb-proxy needs its apparmor profile to work.

[ Impact ]
 squid-deb-proxy does not work on bullseye
 (There's a alternative, so not grave for all users).

[ Tests ]
 Tested on KVM bullseye environment, it does not work well without
 this changes as the bug report says, and patched system works fine.

[ Risks ]
 None, IMHO.
  - It's leaf package
  - Its change does not affect its behavior, it's just for apparmor and
does not affect other package, too.
  - Code is trivial one

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock squid-deb-proxy/0.8.15+nmu1
diff -Nru squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 
squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy
--- squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 
1970-01-01 09:00:00.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy
2021-06-14 23:38:09.0 +0900
@@ -0,0 +1,6 @@
+# vim:syntax=apparmor
+
+/etc/squid-deb-proxy/** r,
+/var/log/squid-deb-proxy/* rw,
+/run/squid-deb-proxy.pid rwk,
+/var/cache/squid-deb-proxy/** rw,
diff -Nru squid-deb-proxy-0.8.15/debian/changelog 
squid-deb-proxy-0.8.15+nmu1/debian/changelog
--- squid-deb-proxy-0.8.15/debian/changelog 2020-01-19 03:00:55.0 
+0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/changelog2021-06-14 
23:41:11.0 +0900
@@ -1,3 +1,10 @@
+squid-deb-proxy (0.8.15+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add apparmor profiles to work (Closes: #932501)
+
+ -- Hideki Yamane   Mon, 14 Jun 2021 23:41:11 +0900
+
 squid-deb-proxy (0.8.15) unstable; urgency=medium
 
   [ Graham Cantin ]
diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs 
squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs
--- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs  2020-01-10 
19:02:40.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs 2021-06-14 
23:40:40.0 +0900
@@ -1,2 +1,3 @@
 etc/resolvconf/update-libc.d
+etc/apparmor.d/abstractions/squid-deb-proxy
 var/log/squid-deb-proxy
diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 
squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install
--- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install   2020-01-10 
19:02:40.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install  2021-06-14 
23:40:21.0 +0900
@@ -1,3 +1,4 @@
 ../update-libc.d etc/resolvconf/
 etc/squid-deb-proxy
 init-common.sh usr/share/squid-deb-proxy/
+../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/

Bug#990064: python-script FTCBFS: missing Build-Depends: libpython3-all-dev

[Helmut Grohne]

Source: python-scrypt
Version: 0.8.0-0.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pythons-script fails to cross build from source, because it misses the
host architecture python libraries. It only depends on
python3-all-dev:any, which is correct for the build architecture parts,
but one also needs libpython3-all-dev. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru python-scrypt-0.8.0/debian/changelog 
python-scrypt-0.8.0/debian/changelog
--- python-scrypt-0.8.0/debian/changelog2019-12-07 19:57:05.0 
+0100
+++ python-scrypt-0.8.0/debian/changelog2021-06-19 07:39:22.0 
+0200
@@ -1,3 +1,10 @@
+python-scrypt (0.8.0-0.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missing Build-Depends: libpython3-all-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 19 Jun 2021 07:39:22 +0200
+
 python-scrypt (0.8.0-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru python-scrypt-0.8.0/debian/control 
python-scrypt-0.8.0/debian/control
--- python-scrypt-0.8.0/debian/control  2019-12-07 19:56:10.0 +0100
+++ python-scrypt-0.8.0/debian/control  2021-06-19 07:39:21.0 +0200
@@ -6,6 +6,7 @@
  debhelper-compat (= 12),
  dh-python,
  libssl-dev,
+ libpython3-all-dev,
  python3-all-dev:any,
  python3-setuptools,
 Standards-Version: 4.4.1

Bug#988618: unblock: kodi-pvr-iptvsimple/7.6.5+ds1-1

[Vasyl Gello]

Control: tag -1 -moreinfo

Hi Sebastian!

Hope this one can be unblocked, too :)
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#988616: Acknowledgement (unblock: kodi-inputstream-ffmpegdirect/1.21.3+ds1-1)

[Vasyl Gello]

Control: tag -1 -moreinfo

Hi Sebastian!

Dropping moreinfo tag since bullseye branch with picked fixes in in Salsa for a 
week.

Cheers!

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#983146: 983146 RFS: bung/3.0.7-2 [ITP] -- backup next generation

[Charles]

Thanks tobi, I appreciate the guidance

bung/3.0.7-2 is now at https://mentors.debian.net/package/bung (3.0.7-2 
is signed, 3.0.7-1 was not)

Bug#990063: ruby2.7: rdoc2.7 man page gives incorrect info about --help-output

[FPacifica]

Package: ruby2.7
Version: 2.7.3-2
Severity: normal

Dear Maintainer,

Trying to generate ruby2.7 html documentation for local use.  The man
page rdoc2.7(1) states:

  Available output formatters: chm, html, ri, xml

   For information on where the output goes, use:
   rdoc --help-output

However when rdoc2.7 --help-output is run it gives the error:

option --help-output is deprecated: support discontinued

Also the man page is does not explain how to generate html
documentation and the ruby2.7-doc package, unlike other Debian -doc
packages, does not actually provide any documentation in
/usr/share/doc/ruby2.7 other than the changelog and copyright.


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

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

Versions of packages ruby2.7 depends on:
ii  libc6 2.31-12
ii  libruby2.72.7.3-2
ii  rubygems-integration  1.18

Versions of packages ruby2.7 recommends:
ii  fonts-lato2.0-2.1
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7

ruby2.7 suggests no packages.

-- no debconf information

Bug#989491: libxstream-java: CVE-2021-29505

[Hideki Yamane]

On Sat, 05 Jun 2021 09:29:20 +0200 Salvatore Bonaccorso  
wrote:
> Source: libxstream-java
> Version: 1.4.15-2

 Let's check it with buster version, then.
 Here's a patch for it, it lacks some blacklist items from current
 unstable version but it should be so if sticks to a minimum.

 Anyway, could you review it, please




libstream-java.debdiff
Description: Binary data

Bug#990055: qemu-system-x86: Cannot set PCI slot 2 for Intel IGD Passthrough using Xen

[Chuck Zmudzinski]

Package: qemu-system-x86
Version: 6.0+dfsg-1~exp0 and 5.2+dfsg-10
Severity: normal
Tags: patch upstream

Dear Maintainer,

I find that when using qemu with a Windows Xen HVM DomU and also passing 
through the Intel integrated graphics device (IGD) to the Windows Xen HVM DomU, 
it is much more reliable if the Intel IGD is at PCI slot 2 in the HVM DomU. 
When using the ancient qemu-xen-traditional device model provided by the Xen 
project, the Intel IGD always grabs slot 2 when it is passed through to the Xen 
HVM DomU using the gfx_passthru option in xl.cfg, but not when using what the 
Xen project refers to as the upstream qemu device model, which is the device 
model provided by the qemu-system-x86 package. Intel says the IGD device needs 
to be at PCI slot 2 and but it will be at a different slot when using the qemu 
version provided by the qemu-system-x86 package.

One problem that occurs is that Windows sometimes reports code 43 errors in the 
Windows Device Manager when the Intel IGD is not set to PCI slot 2, and this 
prevents IGD passthrough from working because the Windows code 43 error causes 
Windows to disable the affected device. Other times, the screen is a little 
fuzzy at first but it usually clears up later.

I investigated and found out how the ancient qemu-xen-traditional model ensures 
the IGD grabs PCI slot 2, it is by patching the hw/pci/pci.c file, but the 
patch in qemu-xen-traditional is not appropriate for this version of qemu 
because unlike qemu-xen-traditional, this version is designed to support more 
configuratons than with Xen.

I was able to develop a patch that causes the Intel IGD to grab slot 2 with 
these versions of qemu when qemu is running with xen as the accelerator and 
when using the xenlight (xl/libxl) toolstack to build the Xen HVM. The patch is 
designed to only affect Xen HVMs with IGD passthrough, that is, when using the 
xenlight toolstack and setting gfx_passthru to '1' or 'igd' in the Xen HVM 
DomU's xl.cfg file.

The following patch is for the 6.0+dfsg-1~exp0 package, but it also applies to 
the 5.2+dfsg-10 package also with some fuzz. I used it as the last patch in the 
series of patches in debian/patches, and it works well. It uses CONFIG_DEVICES 
to only compile on platforms with CONFIG_XEN_IGD_PASSTHROUGH set by the meson 
build system, and it also checks and only applies at runtime if the 
gfx_passthru option is set, and all the patch is in the xen part of the qemu 
code.

-Start of Patch

--- a/hw/i386/xen/xen-hvm.c 2021-04-29 13:18:58.0 -0400
+++ b/hw/i386/xen/xen-hvm.c 2021-06-18 09:44:58.0 -0400
@@ -9,6 +9,7 @@
  */
 
 #include "qemu/osdep.h"
+#include CONFIG_DEVICES
 #include "qemu/units.h"
 
 #include "cpu.h"
@@ -38,6 +39,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_IGD_PASSTHROUGH
+#include "hw/pci/pci_bus.h"
+#include "hw/xen/xen_pt.h"
+#endif
+
 //#define DEBUG_XEN_HVM
 
 #ifdef DEBUG_XEN_HVM
@@ -1530,6 +1536,21 @@
 exit(1);
 }
 
+#ifdef CONFIG_XEN_IGD_PASSTHROUGH
+/* Reserve pci slot 2 for the Intel IGD */
+void xen_hvm_reserve_igd_slot(PCIBus *pci_bus)
+{
+DPRINTF("Checking if igd-passthrough is set...\n");
+if (xen_igd_gfx_pt_enabled()) {
+DPRINTF("Reserving PCI slot 0x02 for IGD...\n");
+pci_bus->slot_reserved_mask = XEN_IGD_PCI_SLOT;
+}
+else {
+DPRINTF("IGD passthrough is not set\n");
+}
+}
+#endif
+
 void destroy_hvm_domain(bool reboot)
 {
 xc_interface *xc_handle;
--- a/hw/i386/pc_piix.c 2021-06-18 09:39:56.0 -0400
+++ b/hw/i386/pc_piix.c 2021-06-18 09:49:15.0 -0400
@@ -208,6 +208,13 @@
   pci_memory, ram_memory);
 pcms->bus = pci_bus;
 
+#ifdef CONFIG_XEN_IGD_PASSTHROUGH
+/* This function checks if igd-passthru is enabled and 
+ * if so, reserve slot 2 for it on the PCI Bus */
+if (xen_enabled()) {
+xen_hvm_reserve_igd_slot(pci_bus);
+}
+#endif
 piix3 = piix3_create(pci_bus, &isa_bus);
 piix3->pic = x86ms->gsi;
 piix3_devfn = piix3->dev.devfn;
--- a/include/hw/xen/xen-x86.h  2021-04-29 13:18:58.0 -0400
+++ b/include/hw/xen/xen-x86.h  2021-06-18 09:54:05.0 -0400
@@ -12,4 +12,8 @@
 
 void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory);
 
+#ifdef CONFIG_XEN_IGD_PASSTHROUGH
+void xen_hvm_reserve_igd_slot(PCIBus *pci_bus);
+#endif
+
 #endif /* QEMU_HW_XEN_X86_H */
--- a/hw/xen/xen_pt.c   2021-04-29 13:18:58.0 -0400
+++ b/hw/xen/xen_pt.c   2021-06-18 10:07:42.0 -0400
@@ -53,6 +53,7 @@
  */
 
 #include "qemu/osdep.h"
+#include CONFIG_DEVICES
 #include "qapi/error.h"
 #include 
 
@@ -65,6 +66,10 @@
 #include "xen_pt.h"
 #include "qemu/range.h"
 #include "exec/address-spaces.h"
+#ifdef CONFIG_XEN_IGD_PASSTHROUGH
+#include "hw/pci/pci_bus.h"
+static void xen_pt_clear_igd_slot(DeviceState *qdev, Error **errp);
+#endif
 
 static bool has_igd_gfx_passthru;
 

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

Control: tags 982270 pending

On 2021-06-18, Vagrant Cascadian wrote:
> On 2021-06-01, Vagrant Cascadian wrote:
>> On 2021-06-01, Rick Thomas wrote:
>>> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
>>> show up in the installer at [1] ?  I'd love to test it!
>> ...
>>> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>>
>> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
>> should also have it.
>>
>> I only tested it outside of debian-installer (e.g. upgrading kernel on
>> an already installed system), so it is also possible that more modules
>> are needed in one of the kernel udebs used by the installer, or that
>> you're experiencing a different issue from the one that was fixed. I'll
>> try to test debian-installer on Cubox-i4pro to see if I still have an
>> issue.
>
> Just tested d-i daily[1] on a Cubox-I4pro, and it definitely fails to
> find the network card.

And same behavior on a wandboard quad...

> Same hardware, same kernel finds it just fine on an already installed
> system... so this most likely means we need to add more modules to one
> of the kernel .udebs.

What's more confusing, is the ethernet is CONFIG_FEC which is enabled as
a built-in, but still needs gpio-mxc to actually function!

Pushed a fix to git:

  
https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988689: ITP: 7zip -- 7-Zip file archiver

[yokota]

Hello, Dylan.

> I started to work on 7zip [1] before realizing you already started a
> package of it.
> Are you still working on it? Should we combine our efforts to finish
> the package?

Thanks for pickup my code.
Please publish 7zip package.

Yes, I still working on 7zip code to add some other feature, but you
can finish the package.

--
YOKOTA

Bug#990053: yowsup-cli: Fails to registrate: missing autkey

[Scorpion2185]

Package: yowsup-cli
Version: 2.5.7-4
Severity: normal
Tags: upstream

Dear Maintainer,

This is the error:
yowsup-cli registration --requestcode sms  --phone X --cc XX
yowsup-cli  v2.0.15
yowsup  v2.5.7
[...]
INFO:yowsup.common.http.warequest:b'{"login":"XXX","status":"fail","reason":"missing_param","param":"authkey"}\n'
status: b'fail'
reason: b'missing_param'
param: b'authkey'
login: b'XX'

I found an issue on github: https://github.com/tgalal/yowsup/issues/2985.

On testing (bullseye version: 3.2.3-2) I have this error: old version.



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

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

Versions of packages yowsup-cli depends on:
ii  python3   3.7.3-1
ii  python3-axolotl   0.1.42-1
ii  python3-dateutil  2.7.3-3
ii  python3-libxml2   2.9.4+dfsg1-7+deb10u1
ii  python3-yowsup2.5.7-4

yowsup-cli recommends no packages.

yowsup-cli suggests no packages.

-- no debconf information

Bug#990062: /usr/bin/mogrify-im6.q16: IO error writing tag data when processing tiff file

[Brian May]

Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: important
File: /usr/bin/mogrify-im6.q16


$ mogrify -verbose -write /dev/null 
/home/brian/photos/images/orig/1990/04/01/flood001.tif
/home/brian/photos/images/orig/1990/04/01/flood001.tif TIFF 6639x3984 
6639x3984+0+0 8-bit TrueColor sRGB 75.6736MiB 0.080u 0:00.713
/home/brian/photos/images/orig/1990/04/01/flood001.tif=>/dev/null TIFF 
6639x3984 6639x3984+0+0 8-bit TrueColor sRGB 0.050u 0:00.046
/home/brian/photos/images/orig/1990/04/01/flood001.tif=>/dev/null TIFF 
6639x3984 6639x3984+0+0 8-bit TrueColor sRGB 0.040u 0:00.045
mogrify-im6.q16: IO error writing tag data. `TIFFWriteDirectoryTagData' @ 
error/tiff.c/TIFFErrors/606.

Doing a Google search, I get this result from 2016. Not sure if it is
the same issue or not.

https://github.com/dlemstra/Magick.NET/issues/26


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.31-12
ii  libmagickcore-6.q16-6  8:6.9.11.60+dfsg-1.3
ii  libmagickwand-6.q16-6  8:6.9.11.60+dfsg-1.3

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.53.3~dfsg-7
ii  libmagickcore-6.q16-6-extra  8:6.9.11.60+dfsg-1.3
ii  netpbm   2:10.0-15.4

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace   
pn  cups-bsd | lpr | lprng  
ii  curl7.74.0-1.2
pn  enscript
ii  ffmpeg  7:4.3.2-0+deb11u2
ii  gimp2.10.22-4
pn  gnuplot 
pn  grads   
ii  graphviz2.42.2-5
ii  groff-base  1.22.4-6
pn  hp2xx   
pn  html2ps 
pn  imagemagick-doc 
pn  libwmf-bin  
ii  mplayer 2:1.4+ds1-1
pn  povray  
pn  radiance
ii  sane-utils  1.0.31-4
pn  texlive-base-bin
pn  transfig
pn  ufraw-batch 
ii  xdg-utils   1.1.3-4.1

-- debconf-show failed

Bug#916191: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable to authenticate a client via SASL GSSAPI

[Lucas Castro]

Hello, I was trying this bug,

I guess there is no bug right here.

On Tue, 11 Dec 2018 10:28:39 +0500 Igor Goldenberg 
 wrote:> Package: postfix


> Version: 3.1.8-0+deb9u1
> Severity: important
> File: /usr/lib/postfix/sbin/smtpd
>
> Dear Maintainer,
>
> after upgrading Debian from 8/jessie to 9/stretch I've started to
> receive periodical errors while client tries to send an email with
> authentication via Kerberos/GSSAPI via Postfix.
>
> The MUA is a Thunderbird 60.2.1 on Windows Server 2016 in AD domain.
> Thunderbird setted up to use STARTTLS with Kerberos / GSSAPI
> authentication method. Sometimes client got Kerberos error (ticket
> Kerberos/GSSAPI was not received by SMTP server) in the MUA and in the
> log I can see:
>
> Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: SASL authentication 
failure: Requested identity not authenticated identity
> Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: 
unknown[192.168.1.3]: SASL GSSAPI authentication failed: authentication 
failure

>
> About 4-5% of total authenticaions has such error (~20 of total ~500 in
> a day). If user in the Thunderbird close error window and try to send
> an email again it usually sends successfully. It's non needed to relog on
> the windows server or restart a mail client, just do another try.
>
> Kerberos authentication also used in the Cyrus IMAP server on the same
> Debian host and there are no any errors with Kerberos at all. So I think
> something wrong on the Postfix side.
>
> Here is the SASL source code where this error ("Requested identity not
> authenticated identity") rises.
>
> File lib/common.c, begining from line 2625:
>
> static int
> _sasl_proxy_policy(sasl_conn_t *conn,
> void *context __attribute__((unused)),
> const char *requested_user, unsigned rlen,
> const char *auth_identity, unsigned alen,
> const char *def_realm __attribute__((unused)),
> unsigned urlen __attribute__((unused)),
> struct propctx *propctx __attribute__((unused)))
> {
> if (!conn)
> return SASL_BADPARAM;
>
> if (!requested_user || *requested_user == '\0')

> return SASL_OK;

Over here you can check if the client (MUA) not send a user 
(request_user), it just return SASL_OK.


mutt as example,

    set smtp_url = 'smtp://postfix00.zw.local:25/'

if set  just as above, no request_user exist.

but instead of that it is set

    set smtp_url = 'smtp://u...@postfix00.zw.local:25/'

so the authentication will get into next step.

>
> if (!auth_identity || !requested_user || rlen != alen ||
> (memcmp(auth_identity, requested_user, rlen) != 0)) {
> sasl_seterror(conn, 0,
> "Requested identity not authenticated identity");
> RETURN(conn, SASL_BADAUTH);
> }
>
> return SASL_OK;

> }

So if the request user at smtp_url differ from sasl authenticated user 
it stops and return error.


>

> I think Postfix incorrectly use or 'auth_identity' or 'requested_user'


I really make up this setup and test both situation.

I think it's good to set this "bug" as not a bug.

--
Lucas Castro

Bug#990029: konsole: Application and global menu

[Norbert Preining]

On Fri, 18 Jun 2021, Stefano Callegari wrote:
> when restore the konsole at startup from previous session, disappear the
> application menu either in title bar (the burger icon) or in the panel bar
> (simply empty).

I can neither understand nor reproduce this. It seems you are using a
different DE than plasma.

Could you provide screenshots, please.

Best

Norbert

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

Bug#989777: Re: Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Salut Vincent,

I have found this way of doing things without having tested it yet, maybe it 
will allow Debian 11 to be compatible with my Wifi / Bluetooth card without 
having to install a future 5.11 kernel from backports ??

If you could get basic compatibility with the 5.10 kernel for bluetooth in 
addition to wifi, that would be really good.

Best regards.

Philippe


https://askubuntu.com/questions/1326386/ubuntu-20-04-lts-driver-intel-wi-fi-6e-ax210-160mhz


I actually managed to make the AX210 run in Ubuntu 18.04 LTS with Linux Kernel 
4.15! Here's what I did:

Install the "backport-iwlwifi-dkms" package (sudo apt install 
backport-iwlwifi-dkms)
Unfortunately, the iwlwifi sources in this package are too old and only support 
pre-production AX210, so:
Grab the up-to-date backport-iwlwifi sources from Intel's github repository: 
git clone https://github.com/intel/backport-iwlwifi.git
Now go to /usr/src, there's a subdirectory with the old sources from step 1 
there (backport-iwlwifi-7906)
Copy the new sources to a new directory, e.g. sudo cp -a 
/whereever/you/cloned/to/backport-iwlwifi/iwlwifi-stack-dev 
backport-iwlwifi-8000
Copy the file "dkms.conf" from the old sources directory to the new sources 
directory and edit the second line to change the PACKAGE_VERSION from 7906 to 
8000
Remove the bad dkms module that was installed with the package in step 1: sudo 
dkms remove backport-iwlwifi/7906 --all
Add the updated dkms module with the version just created: sudo dkms add 
backport-iwlwifi/8000
Build and install the updated dkms modules: sudo dkms install 
backport-iwlwifi/8000
Now the driver is ready, but you still need to get the firmware for the chip:

Clone the linux-firmware repository: git clone 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Pick out the firmware files you need and copy them to /lib/firmware. If you're 
not sure which firmware you need, just boot with the new driver and check dmesg 
for messages from iwl: dmesg | grep iwl - the firmware files it was looking for 
will be named there.
PITFALL: The AX210 also needs an additional "pnvm" file, which is also found in 
the repository, but not quite well mentioned by the driver. If it is missing, 
it'll spray a ton of error messages.
For my Intel AX210 module, I ended up adding these files to /lib/firmware:

-rw-r--r-- 1 root root 1413868 Jun  3 18:27 iwlwifi-ty-a0-gf-a0-59.ucode
-rw-r--r-- 1 root root 1455104 Jun  3 18:27 iwlwifi-ty-a0-gf-a0-62.ucode
-rw-r--r-- 1 root root 1460012 Jun  3 18:27 iwlwifi-ty-a0-gf-a0-63.ucode
-rw-r--r-- 1 root root   27456 Jun  3 18:46 iwlwifi-ty-a0-gf-a0.pnvm
And it is up and running!

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

Control: tags 982270 confirmed

On 2021-06-01, Vagrant Cascadian wrote:
> On 2021-06-01, Rick Thomas wrote:
>> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
>> show up in the installer at [1] ?  I'd love to test it!
> ...
>> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>
> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
> should also have it.
>
> I only tested it outside of debian-installer (e.g. upgrading kernel on
> an already installed system), so it is also possible that more modules
> are needed in one of the kernel udebs used by the installer, or that
> you're experiencing a different issue from the one that was fixed. I'll
> try to test debian-installer on Cubox-i4pro to see if I still have an
> issue.

Just tested d-i daily[1] on a Cubox-I4pro, and it definitely fails to
find the network card.

Same hardware, same kernel finds it just fine on an already installed
system... so this most likely means we need to add more modules to one
of the kernel .udebs.

[1] 
https://d-i.debian.org/daily-images/armhf/20210618-00:15/netboot/SD-card-images/

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#990061: RM: libgaminggear -- ROM; depends on deprecated GTK 2 and obsolete

[Pierre-Elliott Bécue]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

I packaged libgaminggear because I was expecting to package roccat
tools.

But roccat tools contains roccat licensed materials, and despite my
attempts to contact them, I never got any license allowing us to upload
this to nonfree, si it never approached debian at all.

Now, libgaminggear depends on GTK 2 which is obsolete.

I'd like to have libgaminggear removed from unstable and testing, as I
think it's of no real use anymore.

Thanks in advance,

Bug#990060: installation-reports

[dhorse]

Package: installation-reports

Boot method: DVD rom from ISO
Image https://cdimage.debian.org/cdimage/bullseye_di_rc2/amd64/iso-dvd/
Date: 6/4/21

Machine: 

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

Hi Sebastian,

On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> Thanks for this detailed analysis. That actually means that the symbol
> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> version requirement for all symbols that works with SSLChannelInfo. From
> your description, at least the version for SSL_GetChannelInfo would need
> to be bumped. If thunderbird would then be built against a libnss3
> version with a fixed symbol files, it would pick up tight enought
> dependencies.
> 
> So ideally the bug against thunderbird would be reassigned to libnss3
> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> thunderbird to pick up the correct depedencies.

Good point.  Fixing the libnss3 symbol file sounds like the right fix to
me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
the proposed fix.

> But since that version of libnss3 is not in bullseye, the rebuild would
> not be abile to migrate. Ideally libnss3 would be reverted to the
> version in bullseye to avoid this issue. Otherwise I can schedule
> binNMUs of thunderbird in tpu, but that means that we would need to do
> that for any thunderbird upload that we want in bullseye until the
> release. That is suboptimal - it's more work with less testing.

That may be tricky.  firefox 88.0.1-1 in unstable depends on
libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
version between 2:3.63 and 2:3.65, I believe that would solve the issue
without breaking firefox.  (2:3.63-1 is the only suitable version
in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
discuss.

Thanks,
Kevin

P.S. My apologies for not following your suggestion to reassign #989839
to libnss3.  I thought we might need separate issues for better
granularity over the different parts of the issue.  I hope it doesn't
end up causing more confusion or hassle.

Bug#990054: developers-reference: Please replace words about freenode irc network

[Holger Levsen]

On Fri, Jun 18, 2021 at 04:56:25PM -0400, Boyuan Yang wrote:
> According to
> https://lists.debian.org/debian-devel-announce/2021/06/msg2.html ,
> Debian's presence on Freenode has ceased. However,
> https://www.debian.org/doc/manuals/developers-reference/resources.html#irc-channels
> still mentions freenode IRC network and provides link to external freenode
> documentation. Please consider updating the content and possibly provide
> pointers to https://libera.chat/ .

ack, patches or better commits welcome. developers-reference is free to push
for all Debian developers. 

that said, cc:ing urbec who has a more or less ready patch somewhere...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Encryption is like pregnancy. Either something is end to end encrypted or it's
not.  If there are backdoors,  they will be open to anyone eventually and thus
encryption with backdoors is like there's no encryption at all.
 Privacy and thus encryption are human rights.


signature.asc
Description: PGP signature

Bug#990048: dhelp cron.monthly job using invalid syntax for xargs

[Mark Nipper]

Package: dhelp
Version: 0.6.26
Severity: normal

Just got this today from one of my systems:
---
/etc/cron.monthly/dhelp:
xargs: warning: options --max-args and --max-lines/-l are mutually exclusive, 
ignoring previous --max-args value

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dhelp depends on:
ii  doc-base0.11.1
ii  ghostscript 9.53.3~dfsg-7
ii  libcgi-pm-perl  4.51-1
ii  libdata-page-perl   2.03-1
ii  libhtml-parser-perl 3.75-1+b1
ii  liblocale-gettext-perl  1.07-4+b1
ii  libtemplate-perl2.27-1+b3
ii  liburi-perl 5.08-1
ii  perl5.32.1-4
ii  poppler-utils   20.09.0-3.1
ii  ruby1:2.7+2
ii  ruby-debian 0.3.10+b4
ii  ruby-gettext3.3.3-2
ii  sensible-utils  0.0.14
ii  swish++ 6.1.5-5
ii  ucf 3.0043

dhelp recommends no packages.

Versions of packages dhelp suggests:
ii  catdvi  0.14-12.1+b1
ii  elinks [www-browser]0.13.2-1+b1
ii  firefox [www-browser]   89.0-2
ii  google-chrome-stable [www-browser]  91.0.4472.114-1
ii  info2www1.2.2.9-24.1
ii  man2html1.6g-14
ii  nginx-core [httpd-cgi]  1.18.0-6.1
ii  nginx-full [httpd-cgi]  1.18.0-6.1

-- no debconf information

Bug#990059: libnss3: Please consider reverting to version in bullseye

[Kevin Locke]

Package: libnss3
Version: 2:3.67-1
Severity: normal
X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 


Dear Maintainer,

Thunderbird 1:78.11.0-1 in bullseye is unable to establish some (all?)
TLS connections, as discussed in Bug #989839 and on debian-release.[1]
To fix the issue, thunderbird needs to be rebuilt against a version of
libnss3-dev compatible with the version of libnss3 in bullseye.
Sebastian Ramacher suggested that libnss3 could be reverted to the
version in bullseye to facilitate this and avoid the need for all
subsequent thunderbird uploads to go through t-p-u until the release.[2]

I'm opening this issue to propose the idea to you.  Thoughts?

Thanks for considering,
Kevin

[1]: https://lists.debian.org/debian-release/2021/06/msg00570.html
[2]: https://lists.debian.org/debian-release/2021/06/msg00597.html

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

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

Versions of packages libnss3 depends on:
ii  libc6 2.31-12
ii  libnspr4  2:4.29-1
ii  libsqlite3-0  3.34.1-3

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information

Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes

[Kevin Locke]

Package: libnss3
Version: 2:3.67-1
Severity: serious
Tags: patch
Justification: Policy 8.6.3.3
X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 


Dear Maintainer,

Thunderbird 1:78.11.0-1 in testing is unable to establish some (all?)
TLS connections when run with libnss3 2:3.61-1, because it was built
with libnss3-dev 2:3.66-1.  The issue occurs because the size of
SSLChannelInfo increased between NSS 3.61 and 3.66 (due to the addition
of PRBool isFIPS).  SSL_GetChannelInfo takes both a pointer to and size
of SSLChannelInfo as arguments.  If the size is greater than the size it
expects, it returns SECFailure, causing the connection to fail.  See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839#48 for details.

The issue is being discussed on debian-release, where Sebastian Ramacher
pointed out that the libnss3 symbol file should bump the minimum version
requirement for all symbols that works with SSLChannelInfo.[1]  I agree.
As far as I can tell, SSL_GetChannelInfo is the only such symbol.  I
believe it should be bumped to 2:3.66 for package 2:3.67 and bumped in
future versions whenever the size of SSLChannelInfo changes.  I've
attached a patch to do so.

Thanks for considering,
Kevin

[1]: https://lists.debian.org/debian-release/2021/06/msg00597.html

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

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

Versions of packages libnss3 depends on:
ii  libc6 2.31-12
ii  libnspr4  2:4.29-1
ii  libsqlite3-0  3.34.1-3

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information
>From eaffc616b99dd2be285ade5df072cfa1e30924fe Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Fri, 18 Jun 2021 14:41:27 -0600
Subject: [PATCH] libnss3.symbols: bump SSL_GetChannelInfo to 2:3.66

PRBool isFIPS was added to SSLChannelInfo in NSS 3.66, causing its size
to increase.  Since SSL_GetChannelInfo is called with
sizeof(SSLChannelInfo) and returns SECFailure when called with a larger
size than it expects, it creates a version incompatibility where
programs compiled with NSS >= 3.66 do not function correction when
loaded with NSS < 3.66, as in #989839 for thunderbird.

To avoid breakage, bump the version of SSL_GetChannelInfo, as suggested
by Sebastian Ramacher in
https://lists.debian.org/debian-release/2021/06/msg00597.html

Signed-off-by: Kevin Locke 
---
 debian/libnss3.symbols | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libnss3.symbols b/debian/libnss3.symbols
index 5213379c..2bb7294a 100644
--- a/debian/libnss3.symbols
+++ b/debian/libnss3.symbols
@@ -154,5 +154,5 @@ libssl3.so libnss3 #MINVER#
  (symver)NSS_3.4 2:3.13.4-2~
  (symver)NSS_3.7.4 2:3.13.4-2~
  SSL_GetCipherSuiteInfo@NSS_3.4 2:3.44.0
- SSL_GetChannelInfo@NSS_3.4 2:3.34
+ SSL_GetChannelInfo@NSS_3.4 2:3.66
  SSL_GetPreliminaryChannelInfo@NSS_3.21 2:3.44.0
-- 
2.30.2

Bug#990057: ITP: libm2k -- A C++ library for interfacing with the ADALM2000

[A. Maitland Bottoms]

Package: wnpp
Severity: wishlist
Owner: A. Maitland Bottoms 

* Package name: libm2k
  Version : 0.4.0
  Upstream Author : Analog Devices Inc.
* URL : https://wiki.analog.com/university/tools/m2k/libm2k/libm2k
* License : LGPL 2.1+
  Description : A C++ library for interfacing with the ADALM2000

The ADALM2000 is one of the Analog Devices Advanced/Active Learning
Modules. It is a USB peripheral device that provides several functions:
analog-in: oscilloscope and voltmeter
analog-out: signal generator
digital: logic analyzer and pattern generator
power-supply

In addition to the C++, there is also a Python module built using swig,
and Sphinx and Doxygen documentation.

Releases are handled via github at
https://github.com/analogdevicesinc/libm2k

This package is a pre-requisite for the Scopy software oscilloscope
and signal analysis toolset application and for the gr-m2k gnuradio
blocks package.

Bug#990056: help system files are missing

[someone]

Package: fontmatrix
Version: 0.9.99-2



builtin help system files are missing.


I found the source package file
fontmatrix-0.9.99/debian/files

is missing the line 
/usr/share/fontmatrix/help

doing a package with only this change,
I found the help systems is functional


thanks,

Bug#990044: closed by Colin Watson (Re: Bug#990044: error: symbol 'grub_file_filters' not found)

[Stefan Nitz]

Dear Colin,

On 18.06.21 19:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the grub2 package:

#990044: error: symbol 'grub_file_filters' not found

It has been closed by Colin Watson .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Colin Watson 
 by
replying to this email.


Great! Thank you for you very fast response!
That was it, I've only tried before
grub-install /dev/sda


best regards
Stefan

Bug#990054: developers-reference: Please replace words about freenode irc network

[Boyuan Yang]

Package: developers-reference
Severity: normal

Hi,

According to
https://lists.debian.org/debian-devel-announce/2021/06/msg2.html ,
Debian's presence on Freenode has ceased. However,
https://www.debian.org/doc/manuals/developers-reference/resources.html#irc-channels
still mentions freenode IRC network and provides link to external freenode
documentation. Please consider updating the content and possibly provide
pointers to https://libera.chat/ .

Thanks,
Boyuan Yang


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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Sebastian Ramacher]

Hi Kevin

On 2021-06-18 10:48:05 -0600, Kevin Locke wrote:
> On 2021-06-17 22:32:46 +0200, Sebastian Ramacher wrote:
> > On 2021-06-17 19:54:51, Carsten Schoenert wrote:
> >> Unfortunately rather also quickly I got some bug reports about
> >> Thunderbird isn't correctly working in testing/bullseye, but has before
> >> in version 1:78.10.0-1.
> >> 
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839
> >> 
> >> [...]
> >> 
> >> But how to proceed right now?
> >> 
> >> I see two possible options.
> >> 
> >> 1. Unblock nss 2:3.67-1
> >>But I've no idea if Mike has his reasons for not requesting an
> >>unblock. But I also can't think of any.
> >> 
> >> 2. Rebuild the thunderbird package and use the internal shipped nss
> >>source which is at 3.51.1.
> >>I expect this will get needed any way for bullseye once the next ESR
> >>circle is starting as and usually MZLA will use then the most recent
> >>available nss version within the shipped source.
> >> 
> >> What for opinions the RT is seeing?
> > 
> > Please correct me if I get anything wrong: thunderbird requires nss3 >=
> > 3.51.1 (which it includes). It was built against 3.67 and fails to run
> > with 3.66. Would it work correctly if built against nss3 3.66 (which would
> > also satisfy the version requirement)?
> > 
> > If not, is nss3 in bullseye broken? Of yes, did 3.67 break its ABI? Or
> > is it simply a matter of an incorrectly produce dependency which is not
> > high enough?
> 
> Forgive me for butting in to the conversation, but I think I can provide
> some useful information:  I believe the issue is that the size of
> SSLChannelInfo increases between some NSS versions (NSS 3.54 added
> pskType, NSS 3.60 added echAccepted, NSS 3.66 added isFIPS).
> SSL_GetChannelInfo takes both a pointer to and size of SSLChannelInfo as
> arguments.  If the size is greater than the size it expects, it returns
> SECFailure.  This means SSL_GetChannelInfo fails when the caller was
> compiled with a more recent version of libnss3 than the version it is
> loaded with and the size of SSLChannelInfo changed between the versions.
> SSL_GetChannelInfo succeeds when the caller was compiled with any lower
> version than the version it is loaded with.  This causes issues when
> thunderbird 1:78.11.0-1 (built with libnss3-dev 2:3.66-1) is run with
> libnss3 2:3.61-1 currently in testing.
> 
> I don't think libnss3 2:3.61-1 is broken.  I think thunderbird needs to
> be compiled against libnss3-dev <= 3.65 to run with 3.61, or it needs to
> be run with libnss3 >= 3.66.
> 
> To avoid issues going forward, I would suggest that thunderbird needs a
> tighter versioned dependency on libnss3.  It may make sense for
> thunderbird to depend on libnss3 >= the version of libnss3-dev it was
> compiled against.  (Which is a bit conservative, since the size of
> SSLChannelInfo doesn't change in every version, but would require less
> work than tracking version compatibility.)  Just an idea.  I'd defer to
> Carsten's judgement on how best to handle it.

Thanks for this detailed analysis. That actually means that the symbol
file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
version requirement for all symbols that works with SSLChannelInfo. From
your description, at least the version for SSL_GetChannelInfo would need
to be bumped. If thunderbird would then be built against a libnss3
version with a fixed symbol files, it would pick up tight enought
dependencies.

So ideally the bug against thunderbird would be reassigned to libnss3
2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
thunderbird to pick up the correct depedencies.

But since that version of libnss3 is not in bullseye, the rebuild would
not be abile to migrate. Ideally libnss3 would be reverted to the
version in bullseye to avoid this issue. Otherwise I can schedule
binNMUs of thunderbird in tpu, but that means that we would need to do
that for any thunderbird upload that we want in bullseye until the
release. That is suboptimal - it's more work with less testing.

Cheers

> 
> Cheers,
> Kevin
> 
> [SSL_GetChannelInfo]: 
> https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988214: Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1

[Paul Gevers]

Hi Utkarsh

On 06-06-2021 06:14, Paul Gevers wrote:
> I am hoping it's possible to just downgrade the *dependency* in rails
> only, such that the upload can happen via unstable. There is no "direct
> bullseye" route. Or do you expect you'll have to make (lots) of changes
> to rails to match the right ruby-marcel package? If that's the case,
> than ruby-marcel/unstable isn't a drop in replacement for
> ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need
> a versioned Breaks for reverse dependent packages (ruby-activestorage),
> but I'm not seeing that.

Did your experimenting (as discussed on IRC last week) yield anything?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989916: unblock: gcc-mingw-w64/24.2

[Stephen Kitt]

Control: tags -1 - moreinfo

Hi Graham,

On Wed, 16 Jun 2021 11:55:48 +0200, Graham Inggs  wrote:
> There's a typo in your changelog, the bug number should be #989862:
> 
> +gcc-mingw-w64 (24.2) unstable; urgency=medium
> +
> +  * Fix gcov handling: we need to tell GCC that we have headers, without
> +telling it where, and then we need to correct its default assumption
> +about where they are. Closes: #989682. LP: #1883933, #1920988.
> +
> + -- Stephen Kitt   Sat, 12 Jun 2021 18:54:10 +0200

Oops, nice catch, thanks!

> Other than that, please go ahead and upload to unstable, and remove
> the moreinfo tag once it has built.

Done, and it’s built on all the release architectures.

Regards,

Stephen


pgpedbCYPMI5U.pgp
Description: OpenPGP digital signature

Bug#989836: Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-7.1

[Graham Inggs]

uwsgi's testing excuses [1] currently shows (amd64 only for clarity):

migrating uwsgi-core/2.0.19.1-7.1/amd64 to testing makes
uwsgi-plugin-luajit/2.0.19.1+5+0.0.6/amd64 uninstallable
migrating uwsgi-core/2.0.19.1-7.1/amd64 to testing makes
uwsgi-plugin-mongo/2.0.19.1+5+0.0.7/amd64 uninstallable
migrating uwsgi-core/2.0.19.1-7.1/amd64 to testing makes
uwsgi-plugin-php/2.0.19.1+7+0.0.12/amd64 uninstallable

This is due to the way in which the uwsgi-abi-XXX Provides / Depends
are generated [2]:

# the equivalent of "uwsgi-core --dot-h | md5sum" at runtime
abi = $(firstword $(shell echo | cat uwsgi.h - | md5sum))

I have scheduled binNMUs for uwsgi-plugin-luajit, uwsgi-plugin-mongo
and uwsgi-plugin-php.
Let's see if that gets uwsgi into a migratable state.


[1] https://qa.debian.org/excuses.php?package=uwsgi
[2] 
https://salsa.debian.org/uwsgi-team/uwsgi/-/blob/debian/latest/debian/rules#L28

Bug#990052: Drop @types/jest, replaced by @jest/types

[Pirate Praveen]

Package: jest
Version: 26.6.3+repack+~cs64.44.39-3
Severity: important

@types/jest is now obsolete as jest itself provides type definitions in 
@jest/types module (already shipped in the package). When using 
@types/jest, it results in error finding dependencies, for example in 
node-memfs with fs-monkey as component.

Bug#990051: xfce4-sensors-plugin tries to run hddtemp, complains when it cannot find it.

[Charles Curley]

Package: xfce4-sensors-plugin
Version: 1.3.0-3
Severity: normal
X-Debbugs-Cc: charlescur...@charlescurley.com

Dear Maintainer,

I did a new installation of Debian Bullseye, with xfce4. Upon "apt upgrade", I 
got an email from the hddtemp package as follows:

--
hddtemp (0.3-beta15-54) unstable; urgency=medium

  hddtemp has been dead upstream for many years and is therefore in a minimal
  maintenance mode. It will be shipped in the Debian Bullseye release, but
  will not be present in the Debian Bookworm release.

  Nowadays the 'drivetemp' kernel module is a better alternative. It uses the
  Linux Hardware Monitoring kernel API (hwmon), so the temperature is returned
  the same way and using the same tools as other sensors.

  Loading this module is as easy as creating a file in the /etc/modules-load.d
  directory:

echo drivetemp > /etc/modules-load.d/drivetemp.conf

 -- Aurelien Jarno   Tue, 02 Feb 2021 20:27:44 +0100
--

This lead me to "apt purge hddtemp" and go with the drivetemp module. It 
appears that xfce4-sensors-plugin finds the drivetemp data. The program sensor 
also appears to get it:

--
charles@orca:~$ sensors
thinkpad-isa-
...
drivetemp-scsi-2-0
Adapter: SCSI adapter
temp1:+37.0°C  (low  =  +0.0°C, high = +70.0°C)
   (crit low =  +0.0°C, crit = +70.0°C)
   (lowest = +29.0°C, highest = +40.0°C)

charles@orca:~$ 
--

However, and this is the gist of this bug, when loading after logging in, 
something (xfce4-sensors-plugin??) tries to load hddtemp. This, of course, 
fails. The failure results in a notification that the attempt to load hddtemp 
failed. Well, doh!

Could you (or upstream?) please make attempting to load hddtemp conditional on 
its being present and executable?

Thank you.


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages xfce4-sensors-plugin depends on:
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsensors5  1:3.6.0-7
ii  libx11-6 2:1.7.1-1
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxnvctrl0  460.56-1

Versions of packages xfce4-sensors-plugin recommends:
pn  hddtemp 
ii  lm-sensors  1:3.6.0-7

Versions of packages xfce4-sensors-plugin suggests:
pn  xsensors  

-- no debconf information

Bug#990050: use Encode qw(encode)

[積丹尼 Dan Jacobson]

Package: libhtml-parser-perl
Version: 3.76-1
File: /usr/share/doc/libhtml-parser-perl/examples/htext

You need to say
use Encode qw(encode);
else the program will die.

(Also if the file is already utf8, it will be double encoded...)

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

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 16 mai 2021 19:03:11 +0200, a ecrit:
> Gregor Zattler, le dim. 16 mai 2021 18:50:42 +0200, a ecrit:
> > * Samuel Thibault  [13. Mai. 2021]:
> > > Kurt Roeckx, le jeu. 19 nov. 2020 20:40:05 +0100, a ecrit:
> > >> I recently found out that my backup has broken for months.
> > >
> > > Not for month, but this does break my backups now that I try to upgrade
> > > some machines, and I don't have another solution than to either
> > > downgrade the package, or upgrade all my machines at the same time (!?)
> > > to get my backups working again.
> > 
> > the rdiff-backup project provides a helpful document
> > regarding this:
> > 
> > https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/migration.md
> > 
> > providing this document in the NEWS.Debian file might be
> > enough in order to close this bug?
> 
> Perhaps we could have a buster-backports package, so that before
> upgrading machines to bullseye, we first just upgrade rdiff-backup on
> all buster machines?

I have uploaded it to buster-backports, it's now in so people can
pre-upgrade. I'd however probably still be important to ship a
NEWS.Debian entry to let people about about the incompatibility issue.

Samuel

Bug#990049: unblock: guile-3.0/3.0.5-4

[Rob Browning]

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

unblock guile-3.0/3.0.5-4

Please unblock package guile-3.0.

[ Reason ]

The (only) changes between -2 and -4 fix a significant bug that can
cause packages that depend on libguile to crash unpredictably:

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

See also:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284#33
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284#58

I'd thought that -4 had migrated a while ago, I was clearly mistaken.

[ Impact ]

Programs in packages that link against libguile can crash
unpredictably.

[ Tests ]

I don't know of any tests that exercise this problem directly, but
the problem was reproducible (see the links above) and the changes
between -2 and -4 were added to fix it.



guile-3.0_3.0.5-2-to-4.debdiff
Description: guile-3.0_3.0.5-2-to-4.debdiff

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#990047: timeshift: Not possible to browse content of snapshot via the gui

[Ludovic Poujol]

Package: timeshift
Version: 20.11.1-1
Severity: important

Dear Maintainer,

By using timeshift GUI (timeshift-gtk), it's not possible to browse
the content of the snapshot.

Steps to reproduce :

* Configure timeshift (I'm using BTRFS Snapshot)
* Create a snapshot
* Select the snapshot and click on the "Browse" button, to see the 
content of the snapshot


-> Nothing happen while I expected to be able to see the files and 
directories of the snapshot.



I catched the following error message when I started the program from 
gnome-terminal right after clicking on the "Browse" button


[6516:0618/191255.550851:FATAL:electron_main_delegate.cc(263)] Running 
as root

without --no-sandbox is not supported. See https://crbug.com/638180.
Trace/breakpoint trap


Good day,

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages timeshift depends on:
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libjson-glib-1.0-0   1.6.2-1
ii  libvte-2.91-00.62.3-1
ii  psmisc   23.4-2
ii  rsync3.2.3-4

timeshift recommends no packages.

--
Ludovic Poujol
Tel (Silence/Signal) : +33 6 25 34 21 10
Matrix : @lpou...@aime.lesmatric.es

Bug#990046: iperf3: ufw profile

[Nicholas Guriev]

Package: iperf3
Version: 3.9-1
Severity: wishlist

Dear Maintainer,

Please, provide a ufw profile for the iperf application. It would be
nice to have out-of-box configuration.

mymedia@aster:~$ cat /etc/ufw/applications.d/iperf3
[iperf3]
title=iperf3
description=Rewritten network performance measurement tool
ports=5201


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

Kernel: Linux 5.11.0-18-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iperf3 depends on:
ii  libc6  2.33-0ubuntu5
ii  libiperf0  3.9-1

iperf3 recommends no packages.

iperf3 suggests no packages.



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

Bug#990045: iperf: ufw profile

[Nicholas Guriev]

Package: iperf
Version: 2.0.13+dfsg1-1build1
Severity: wishlist

Dear Maintainer,

Please, provide a ufw profile for the iperf application. It would be
handy to have an out-of-box config.

mymedia@aster:~$ cat /etc/ufw/applications.d/iperf
[iperf]
title=iperf
description=Network performance measurement tool
ports=5001


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

Kernel: Linux 5.11.0-18-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iperf depends on:
ii  libc6   2.33-0ubuntu5
ii  libgcc-s1   11.1.0-1ubuntu1~21.04
ii  libstdc++6  11.1.0-1ubuntu1~21.04

iperf recommends no packages.

iperf suggests no packages.



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

Bug#990044: error: symbol 'grub_file_filters' not found

[Stefan Nitz]

Package: grub2
Version: 2.02+dfsg1-20+deb10u3
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?
full upgrade to testing 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Install grub2/testing 2.04-18 amd64 

   * What was the outcome of this action?
Grub stop in rescue mode, message:
error: symbol 'grub_file_filters' not found

   * What outcome did you expect instead?
loading the kernel

To start again, install 2.02+dfsg1-20+deb10u3, > u4 do not work

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sdb2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sdb1 /boot ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/_dev_dm_0 /home/nitz ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2R8J1MBA04065
(hd1)   /dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_172843424862
#(hd2)  /dev/disk/by-id/lvm-pv-uuid-Vty9C5-u24G-nx3B-Appj-UhSr-wQZj-LtfXc7
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="Debian GNU/Linux, mit Xen-Hypervisor"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd1,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 
--hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2  
31010fdb-7e31-49df-bbce-b9fc3d11930d
else
  search --no-floppy --fs-uuid --set=root 31010fdb-7e31-49df-bbce-b9fc3d11930d
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd1,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 
--hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2  
31010fdb-7e31-49df-bbce-b9fc3d11930d
else
  search --no-floppy --fs-uuid --set=root 31010fdb-7e31-49df-bbce-b9fc3d11930d
fi
insmod png
if background_image /usr/share/desktop-base/homeworld-theme/grub/grub-4x3.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-31010fdb-7e31-49df-bbce-b9fc3d11930d' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
21ec0055-1c79-4010-a7b8-421818b40973
else
  search --no-floppy --fs-uuid --set=root 
21ec0055-1c79-4010-a7b8-421818b40973
fi
echo'Linux 5.10.0-7-amd64 wird geladen …'
linux   /vmlinuz-5.10.0-7-amd64 
root=UUID=31010fdb-7e31-49df-bbce-b9fc3d11930d ro  quiet
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-5.10.0-7-amd64
}
submenu 'Erweiterte Optionen für Debian GNU/Lin

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

On 2021-06-17 22:32:46 +0200, Sebastian Ramacher wrote:
> On 2021-06-17 19:54:51, Carsten Schoenert wrote:
>> Unfortunately rather also quickly I got some bug reports about
>> Thunderbird isn't correctly working in testing/bullseye, but has before
>> in version 1:78.10.0-1.
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839
>> 
>> [...]
>> 
>> But how to proceed right now?
>> 
>> I see two possible options.
>> 
>> 1. Unblock nss 2:3.67-1
>>But I've no idea if Mike has his reasons for not requesting an
>>unblock. But I also can't think of any.
>> 
>> 2. Rebuild the thunderbird package and use the internal shipped nss
>>source which is at 3.51.1.
>>I expect this will get needed any way for bullseye once the next ESR
>>circle is starting as and usually MZLA will use then the most recent
>>available nss version within the shipped source.
>> 
>> What for opinions the RT is seeing?
> 
> Please correct me if I get anything wrong: thunderbird requires nss3 >=
> 3.51.1 (which it includes). It was built against 3.67 and fails to run
> with 3.66. Would it work correctly if built against nss3 3.66 (which would
> also satisfy the version requirement)?
> 
> If not, is nss3 in bullseye broken? Of yes, did 3.67 break its ABI? Or
> is it simply a matter of an incorrectly produce dependency which is not
> high enough?

Forgive me for butting in to the conversation, but I think I can provide
some useful information:  I believe the issue is that the size of
SSLChannelInfo increases between some NSS versions (NSS 3.54 added
pskType, NSS 3.60 added echAccepted, NSS 3.66 added isFIPS).
SSL_GetChannelInfo takes both a pointer to and size of SSLChannelInfo as
arguments.  If the size is greater than the size it expects, it returns
SECFailure.  This means SSL_GetChannelInfo fails when the caller was
compiled with a more recent version of libnss3 than the version it is
loaded with and the size of SSLChannelInfo changed between the versions.
SSL_GetChannelInfo succeeds when the caller was compiled with any lower
version than the version it is loaded with.  This causes issues when
thunderbird 1:78.11.0-1 (built with libnss3-dev 2:3.66-1) is run with
libnss3 2:3.61-1 currently in testing.

I don't think libnss3 2:3.61-1 is broken.  I think thunderbird needs to
be compiled against libnss3-dev <= 3.65 to run with 3.61, or it needs to
be run with libnss3 >= 3.66.

To avoid issues going forward, I would suggest that thunderbird needs a
tighter versioned dependency on libnss3.  It may make sense for
thunderbird to depend on libnss3 >= the version of libnss3-dev it was
compiled against.  (Which is a bit conservative, since the size of
SSLChannelInfo doesn't change in every version, but would require less
work than tracking version compatibility.)  Just an idea.  I'd defer to
Carsten's judgement on how best to handle it.

Cheers,
Kevin

[SSL_GetChannelInfo]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13

Bug#969110: gemrb: New upstream release 0.8.7

[felipe]

A new version has just been uploaded!

GemRB v0.9.0 (2021-06-18):
  New features:
- basic resolution independence
- python3 support
- arbitrary window dragging support
- improved debug console
- subtitle support for BIK videos

  Improved features:
- window management, drawing and input handling
- performance: SDL2 video playback, general and text rendering
- smoother movement animations, demo
- bugfixes


Would be really nice to have this updated to unstable at least, considering the 
next freeze.

Bug#990042: libnet-amazon-perl: Net::Amazon broken with Amazon API changes?

[gregor herrmann]

Package: libnet-amazon-perl
Version: 0.62-1
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have a script which uses Net::Amazon, and which I run once every
other year. The last attempt ended with no search results but just an
error message of "Gone".

The same can be seen when entering the URL from t/024signature.t in a
browser:
https://webservices.amazon.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=YOUR_AMZN_TOKEN&Operation=ItemSearch&Keywords=Bubl%C3%A9&SearchIndex=Music&ResponseGroup=ItemAttributes,Offers&Version=2009-03-31&Timestamp=2009-06-02T16:31:39Z

leads to a status of "410 Gone" and a content saying

"Gone

The requested resource
/onca/xml
is no longer available on this server and there is no forwarding address. 
Please remove all references to this resource."


A very brief web search indicates that this API endpoint is retired.
Which would make Net::Amazon disfunctional …


Notes:
- - tested with 0.62-2.1 but this most probably applies back to 0.62-1
- - I'll forward the bug upstream once I get a bug number
  Currently there's no issue yet at
  https://rt.cpan.org/Public/Dist/Display.html?Name=Net-Amazon
  or
  https://github.com/boumenot/p5-Net-Amazon/issues
- - If Net::Amazon is indeed disfunctional we either need a fix quickly
  or it shouldn't be in the bullseye release
- - libnet-amazon-perl has no reverse dependencies
- - popcon: vote: 3 + old: 509
- - I think it was my first Debian package of a Perl module, back in 2006 :)
- - I'll look into XML::Amazon soon


Cheers,
gregor


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libnet-amazon-perl depends on:
ii  libhttp-message-perl  6.29-1
ii  liblog-log4perl-perl  1.54-1
ii  liburi-perl   5.08-1
ii  libwww-perl   6.53-1
ii  libxml-simple-perl2.25-1
ii  perl  5.32.1-4

Versions of packages libnet-amazon-perl recommends:
pn  libcache-perl  

libnet-amazon-perl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmDMxDhfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZVFQ//V1NYgOfGVmEHdf2MCjgIW8wqKRk678iR5vGt2IOLAslR9lMxkR9A71AI
1LY0THUnA/dLQgq7DyNYjzvdppCikD5Lz+XGCeSySsdMgM5/JQLeqPXX8L7YmLGx
Bl+rF1U5BKoixl6C11LVTWHzj45J1aj3pzoFQqq9Lqb2kx9bt1JtE6QQXFl9A+HR
hTGTddsSMKcEAke14W0S2Fty3ULcCDLqB2C50OUKSLIOSN19vpMlPN/8CTgybMQL
rQFI2qqlEnFY0UODuiDx0AxBP9wzszw5R4Jw3uK50GL7F/RTA1lAwJ/xy8FBoUSd
HPGhw0+NKz4+NlOktlS2NICbFjhVhkaiYj+sIsmgumm1kXpqUlTO+Ydd/RaCJyMy
c3bJ4p2pmKSZtDTpsZ7TcesX1uWILcv8IqAqkM27u4nd/zsH/zCQ3cyifbUGOlff
zLk7touZPNxQBTUY+DN1dESxZtPnGPd+YUxzrjPySAhaOeIgwwnwiQ2Pt8fOWbWK
oz5sH1DwS0TLJfgVd741JX37KeQc3jyCDptdjQ2rRHZkl1Lz7+YZFZE2CzsW/9zJ
lG8V4YB7H5cgLgseW7xWxWj7vJDs/Hyo6qt9kXttIuilMkDGfZ4Ke1Wq6HiBUYNq
jh/xH2gm1p8hCEmS4Qn/GAE51JoIgV6Is+tozZvvyqmNPWJVcsQ=
=8Gia
-END PGP SIGNATURE-

Bug#990041: dehydrated: Incorrect filename for example domains.txt in README.Debian

[Ben Harris]

Package: dehydrated
Version: 0.7.0-2
Severity: minor

Dear Maintainer,

In /usr/share/dehydrated/README.Debian, there is the following sentence
about domains.txt:


An example for a domain.txt can be found at
/usr/share/doc/dehydrated/examples/domains.txt.example.


This has two errors.  A trivial one is that "domain.txt" should read
"domains.txt", since that's the name of the file that dehydrated looks
for.

The second error is that "domains.txt.example" should read simply
"domains.txt", since the package contains
/usr/share/doc/dehydrated/examples/domains.txt but not
/usr/share/doc/dehydrated/examples/domains.txt.example.

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

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

Versions of packages dehydrated depends on:
ii  ca-certificates  20210119
ii  curl 7.74.0-1.2
ii  openssl  1.1.1k-1

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/18/21 5:19 PM, Andreas Beckmann wrote:
> On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:
>> I'm increasingly in favor of removing the Breaks from gdal-data, the
>> attached procedure works for me in buster chroot.
> 
>> There is much less need for gdal-data breaking libgdal20 for us than
>> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
>> that use gdal in the maintainer scripts that would be using the old gdal
>> on their removal. So there shouldn't be any actual expected breakage.
> 
> Do you have some ideas what could break by installing gdal-data 3.x in
> buster?

qgis crssync is a likely candidate, prior to PROJ 6 it relied more more
heavily on the projection data included in gdal.

Other than that I don't know. You'd have to grep through the sources to
find the functions using those files, and then search through reverse
dependencies for use of those functions.

> I.e. on a partial upgrade. (Could someone run autopkgtests in
> buster with the proposed gdal-data?)

Many of the gdal rdeps don't have autopkgtests, and the most prominents
ones don't.

>> This change is minimal, doesn't require NEW packages, nor introduces
>> divergence from upstream (as when the files would be moved to
>> u/s/gdal/ in libgdal28), hence it's my preferred solution.
> 
> That's a bad upstream decision, but as you described them, they don't
> care about upgrade paths :-(

PostGIS upstream are the ones who don't particular care about
distribution upgrades. GDAL upstream is actually quite good (and
responsible for the bulk of the work that went into PROJ 6).

>> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
>> changes from the debdiff to unstable.
> 
> Sounds fine to me.

If the RMs are onboard as well, then let's not waste any more time on
alternatives.

Kind Regards,

Bas

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

Bug#990023: The daily apt-listbugs.timer runs hourly instead

[Francesco Poli]

On Thu, 17 Jun 2021 23:01:25 -0400 nurupo wrote:

> In my syslog I see apt-listbugs.service running every hour, claiming
> it runs a *daily* job:
[...]

Hello nurupo,
thanks for your bug report!

In fact, it's a [duplicate] of another, previously filed, bug report.

[duplicate]: 

The two bug reports have already been merged (thank you, Paul!).

Please read the log of the [duplicate] bug report, for all the details
on this matter.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpUVT7xm7uGp.pgp
Description: PGP signature

Bug#990040: ITP: ignition-utils -- A component of Ignition Robotics, provides general purpose classes and functions designed for robotic applications

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-utils
  Version : 1.0.0
  Upstream Author : Open Robotics
* URL : http://ignitionrobotics.org/libraries/utils
* License : Apache2
  Programming Lang: C, C++
  Description : A component of Ignition Robotics, provides general purpose 
classes and functions designed for robotic applications

Ignition Utils : Classes and functions for robot applications
provides a wide range of functionality, including:
 - A helper class to implement the PIMPL pattern
 - A command line parsing utility
 - Macros to suppress warnings

Bug#988689: ITP: 7zip -- 7-Zip file archiver

[Dylan Aïssi]

Hi,

I started to work on 7zip [1] before realizing you already started a
package of it.
Are you still working on it? Should we combine our efforts to finish
the package?

Best,
Dylan

[1] https://salsa.debian.org/debian/7zip

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Andreas Beckmann]

On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:

I'm increasingly in favor of removing the Breaks from gdal-data, the
attached procedure works for me in buster chroot.



There is much less need for gdal-data breaking libgdal20 for us than
there is in the UbuntuGIS PPA use case. I'm not aware of any packages
that use gdal in the maintainer scripts that would be using the old gdal
on their removal. So there shouldn't be any actual expected breakage.


Do you have some ideas what could break by installing gdal-data 3.x in 
buster? I.e. on a partial upgrade. (Could someone run autopkgtests in 
buster with the proposed gdal-data?)
If there are applications known to be broken, we could add versioned 
Breaks against them to the new gdal-data.


The following files are removed:

 2/usr/share/gdal/compdcs.csv   |only
 2/usr/share/gdal/coordinate_axis.csv   |only
 2/usr/share/gdal/datum_shift.csv   |only
 2/usr/share/gdal/ellipsoid.csv |only
 2/usr/share/gdal/esri_Wisconsin_extra.wkt  |only
 2/usr/share/gdal/esri_epsg.wkt |only
 2/usr/share/gdal/esri_extra.wkt|only
 2/usr/share/gdal/gcs.csv   |only
 2/usr/share/gdal/gcs.override.csv  |only
 2/usr/share/gdal/gdal_datum.csv|only
 2/usr/share/gdal/geoccs.csv|only
 2/usr/share/gdal/pcs.csv   |only
 2/usr/share/gdal/pcs.override.csv  |only
 2/usr/share/gdal/prime_meridian.csv|only
 2/usr/share/gdal/projop_wparm.csv  |only
 2/usr/share/gdal/unit_of_measure.csv   |only
 2/usr/share/gdal/vertcs.csv|only
 2/usr/share/gdal/vertcs.override.csv   |only

these are modified:

 3/usr/share/gdal/epsg.wkt  |1
 3/usr/share/gdal/gdalvrt.xsd   |  150 +++
 3/usr/share/gdal/header.dxf|  106 --
 3/usr/share/gdal/nitf_spec.xml |  538 -
 3/usr/share/gdal/nitf_spec.xsd |9
 3/usr/share/gdal/ogrvrt.xsd|5
 3/usr/share/gdal/osmconf.ini   |   19
 3/usr/share/gdal/pds4_template.xml |   14
 3/usr/share/gdal/plscenesconf.json |  255 ++
 3/usr/share/gdal/ruian_vf_ob_v1.gfs|2
 3/usr/share/gdal/ruian_vf_v1.gfs   |2
 3/usr/share/gdal/s57objectclasses.csv  |6
 3/usr/share/gdal/trailer.dxf   |  382 +

and these are new and should not cause any harm

 3/usr/share/gdal/gdalmdiminfo_output.schema.json   |only
 3/usr/share/gdal/pdfcomposition.xsd|only
 3/usr/share/gdal/template_tiles.mapml  |only
 3/usr/share/gdal/tms_LINZAntarticaMapTileGrid.json |only
 3/usr/share/gdal/tms_MapML_APSTILE.json|only
 3/usr/share/gdal/tms_MapML_CBMTILE.json|only
 3/usr/share/gdal/tms_NZTM2000.json |only
 3/usr/share/gdal/vicar.json|only
 39 files changed, 1352 insertions(+), 137 deletions(-)



This change is minimal, doesn't require NEW packages, nor introduces
divergence from upstream (as when the files would be moved to
u/s/gdal/ in libgdal28), hence it's my preferred solution.


That's a bad upstream decision, but as you described them, they don't 
care about upgrade paths :-(



If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
changes from the debdiff to unstable.


Sounds fine to me.

Andreas

Bug#938924: zziplib: Python2 removal in sid/bullseye

[Lukas Märdian]

Hi!


> This has been fixed in 0.13.71, with that version it's just a matter
> of switching the build dep to python3.

Yes. But this is quite a version bump: Last update was a few years ago, 
the old Debian git repo does not exist anymore and the zzip project 
switched its build system from automake to cmake.


I started packaging the latest 0.13.72 release here: 
https://github.com/slyon/zziplib-debian


A refresh of the patches and double-check of the test system still needs 
to be done. But if somebody already wants to do a brief review, I'd 
appreciate any comments!


I've now updated the package to have it properly tested and 
refreshed/dropped the patches. Also, I moved the project to Salsa:


  https://salsa.debian.org/slyon/zzip

I'm now looking for review & sponsoring.

My dfsg tarball can be found here (removing some Windows binaries from 
the source, as documented in debian/copyright): 
http://people.ubuntu.com/~slyon/zzip/


Regards,
  Lukas

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian]

> On Jun 18, 2021, at 8:59 PM, Tobias Frost  wrote:
> 
> On Fri, Jun 18, 2021 at 10:59:18AM +, Paul Wise wrote:
>> On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:
>> 
>>> I suggest to read [1] and all linked documents, and recreate the package.
>>> You'll find dh_make(1) from the package dh-make useful to generate boiler 
>>> plate
>>> templates for the debian directory. Those templates needs to be hand-edited
>>> afterwards, many of them wont be needed: you'd rm them… To get hints, you 
>>> may
>>> take a look a similar packages as well
>> 
>> The packages generated by stdeb are usually much closer to a final
>> package than those generated by dh-make, so I would suggest to fix the
>> existing packaging instead of starting from scratch.
> 
> I've just ran dh_make on it and did an diff: IMGO dh_make did a far
> better job than that from the dsc of that RFS. However, that is my bikeshed 
> color.
> 
>> 


Thank you for your attention and suggestions, I will fix these problems and 
recreate the package. Have a good day !

Regards,
--
fenix

Bug#990039: Use build-depends-indep for the elpa requirement

[Sebastien Bacher]

Package: gettext
Version: 0.21-4
Tags: patch

The Build-Depends is only useful to build an arch all binary so moving
to build-depends-indep, also using the dh sequence simplify the rules.
The patch is currently used in Ubuntu where it was added to fix the
build on i386 (the Ubuntu/i386 archive is a partial one and emacs isn't
built there) but the change should also make sense for Debian

Thanks for considering

diff -Nru gettext-0.21/debian/changelog gettext-0.21/debian/changelog
--- gettext-0.21/debian/changelog	2021-02-02 22:35:00.0 +0100
+++ gettext-0.21/debian/changelog	2021-06-18 16:34:44.0 +0200
@@ -1,3 +1,13 @@
+gettext (0.21-5) UNRELEASED; urgency=medium
+
+  * debian/control, 
+debian/rules:
+- Move dh-elpa to Build-Depends-Indep and change it to dh-sequence-elpa,
+  thus allowing the removal of explicit "--with elpa" options in
+  debian/rules
+
+ -- Sebastien Bacher   Fri, 18 Jun 2021 16:34:44 +0200
+
 gettext (0.21-4) unstable; urgency=medium
 
   * Drop versioned build-dependency on g++ as it holds in stable.
diff -Nru gettext-0.21/debian/control gettext-0.21/debian/control
--- gettext-0.21/debian/control	2021-02-02 21:00:00.0 +0100
+++ gettext-0.21/debian/control	2021-06-18 16:34:23.0 +0200
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 4.5.1
-Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), dh-elpa, bison, file, help2man, xz-utils, default-jdk , maven-repo-helper , libunistring-dev, libxml2-dev, groff
+Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), bison, file, help2man, xz-utils, default-jdk , maven-repo-helper , libunistring-dev, libxml2-dev, groff
+Build-Depends-Indep: dh-sequence-elpa
 Homepage: https://www.gnu.org/software/gettext/
 Rules-Requires-Root: no
 
diff -Nru gettext-0.21/debian/rules gettext-0.21/debian/rules
--- gettext-0.21/debian/rules	2021-02-02 21:00:00.0 +0100
+++ gettext-0.21/debian/rules	2021-06-18 16:34:04.0 +0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with elpa $(WITH_MAVEN)
+	dh $@ $(WITH_MAVEN)
 
 
 #

Bug#990033: RFS: r-cran-mathjaxr

[Torrance, Douglas]

Control: tags -1 pending

I've finished packaging mathjaxr, which lets R package authors use MathJax for 
displaying math in html documentation.  I patched it to use the Debian 
libjs-mathjax package instead of upstream's embedded copy of MathJax.

Would anyone be able to review/sponsor?
https://salsa.debian.org/r-pkg-team/r-cran-mathjaxr

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#990038: RM: debian-installer-10-netboot-* [all] -- RoM; NBS; old binaries

[Cyril Brulebois]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-b...@lists.debian.org, debian-rele...@lists.debian.org

(Filing manually since reportbug seems not to like me much today.)

Hi,

Please remove all debian-installer-10-netboot-* binaries, previously
built by src:debian-installer-netboot-images. They show up during
point release preps as “propups” while we've switched to producing
debian-installer-11-netboot-* binaries a while back. Apparently, they
aren't caught by cruft-report due to being Architecture: all packages.


kibi@coccia:~$ dak rm -Rn -b debian-installer-10-netboot-amd64 
debian-installer-10-netboot-arm64 debian-installer-10-netboot-armel 
debian-installer-10-netboot-armhf debian-installer-10-netboot-i386 
debian-installer-10-netboot-mips debian-installer-10-netboot-mips64el 
debian-installer-10-netboot-mipsel debian-installer-10-netboot-ppc64el
Will remove the following packages from unstable:

debian-installer-10-netboot-amd64 | 20190702+deb10u9 | all
debian-installer-10-netboot-arm64 | 20190702+deb10u9 | all
debian-installer-10-netboot-armel | 20190702+deb10u9 | all
debian-installer-10-netboot-armhf | 20190702+deb10u9 | all
debian-installer-10-netboot-i386 | 20190702+deb10u9 | all
debian-installer-10-netboot-mips | 20190702+deb10u9 | all
debian-installer-10-netboot-mips64el | 20190702+deb10u9 | all
debian-installer-10-netboot-mipsel | 20190702+deb10u9 | all
debian-installer-10-netboot-ppc64el | 20190702+deb10u9 | all

Maintainer: Debian Install System Team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Thanks for your time.

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


signature.asc
Description: PGP signature

Bug#987441: Krita

[Andreas Plassmann]

Ich bin so begeistert von Bullsey bis Debian 11 .

Debian ist das beste Linux und es gibt nichts besseres.

Ich Liebe mein Debian und das Sie nicht wie Cannonical und andere so 
vorangehen.


Ich bin echt Dankbar und bin das ganze von Bullseye mitgegangebn. Das 
einzige Problem ist wenn ich die Workstation in den Standby geführt habe 
und möchte ihn wieder aufwecken. Das ist das einzige Problem.


Bei mir läuft Gnome.

Danke Liebe Debian Leute auf der ganzen Welt. He wir sind die echten und 
besten und das ist Debian.


Gruß

Andreas

On 18.06.21 09:56, Lothar Oelkers wrote:

Moin,
bin begeistert von bullseye.
Einzig Krita startet nicht nach korrekter Installation.
Nach apt remove qt5dxcd-plugin funktionieren alle Anwendungen.
Niemand vermisst das Paket.
Gruß
Lothar

Bug#990037: unblock: kid3/3.8.5-2

[Patrick Matthäi]

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

Please unblock package kid3. It fixes the fucked-up manpages about the whole
packaging and simplifies it by just installing all manpage stuff to the 
kid3-core
package. The old behaviour was required in the past, but it is obsolete and
simplified by upstream since a longer time, but it wasn't adopted to the 
packaging.

diff -Naur 3.8.5-1/debian/changelog 3.8.5-2/debian/changelog
--- 3.8.5-1/debian/changelog2021-02-01 11:45:07.735498453 +0100
+++ 3.8.5-2/debian/changelog2021-06-18 15:59:46.355258057 +0200
@@ -1,3 +1,11 @@
+kid3 (3.8.5-2) unstable; urgency=medium
+
+  * Cleanup manpage installing. The old method is obsolet and buggy. All
+manpages are now installed to the kid3-core package.
+Closes: #990018
+
+ -- Patrick Matthäi   Fri, 18 Jun 2021 15:56:17 +0200
+
 kid3 (3.8.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Naur 3.8.5-1/debian/kid3-cli.install 3.8.5-2/debian/kid3-cli.install
--- 3.8.5-1/debian/kid3-cli.install 2021-02-01 11:45:07.835497918 +0100
+++ 3.8.5-2/debian/kid3-cli.install 2021-06-18 15:59:46.351258076 +0200
@@ -1 +1 @@
-/usr/bin/kid3-cli
+usr/bin/kid3-cli
diff -Naur 3.8.5-1/debian/kid3-cli.manpages 3.8.5-2/debian/kid3-cli.manpages
--- 3.8.5-1/debian/kid3-cli.manpages2021-02-01 11:45:07.771498261 +0100
+++ 3.8.5-2/debian/kid3-cli.manpages1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-deb/kid3-cli.1
-deb/kid3-cli.de.1
diff -Naur 3.8.5-1/debian/kid3-core.install 3.8.5-2/debian/kid3-core.install
--- 3.8.5-1/debian/kid3-core.install2021-02-01 11:45:07.735498453 +0100
+++ 3.8.5-2/debian/kid3-core.install2021-06-18 15:59:46.355258057 +0200
@@ -1,4 +1,10 @@
-/usr/lib/kid3/*
-/usr/share/dbus-1/interfaces/org.kde.Kid3.xml
-/usr/share/kid3/translations/*
-/usr/share/kid3/qml/script/*
+usr/lib/kid3/*
+usr/share/dbus-1/interfaces/org.kde.Kid3.xml
+usr/share/kid3/translations/*
+usr/share/kid3/qml/script/*
+usr/share/man/*/man1/kid3-cli.1.gz
+usr/share/man/*/man1/kid3-qt.1.gz
+usr/share/man/*/man1/kid3.1.gz
+usr/share/man/man1/kid3-cli.1.gz
+usr/share/man/man1/kid3-qt.1.gz
+usr/share/man/man1/kid3.1.gz
diff -Naur 3.8.5-1/debian/kid3.install 3.8.5-2/debian/kid3.install
--- 3.8.5-1/debian/kid3.install 2021-02-01 11:45:07.791498153 +0100
+++ 3.8.5-2/debian/kid3.install 2021-06-18 15:59:46.287258395 +0200
@@ -1,6 +1,6 @@
-/usr/bin/kid3
-/usr/share/icons/hicolor/*/apps/kid3.*
-/usr/share/applications/org.kde.kid3.desktop
-/usr/share/metainfo/org.kde.kid3.appdata.xml
-/usr/share/doc/HTML/*/kid3/*
-/usr/share/kxmlgui5/kid3/kid3ui.rc
+usr/bin/kid3
+usr/share/icons/hicolor/*/apps/kid3.*
+usr/share/applications/org.kde.kid3.desktop
+usr/share/metainfo/org.kde.kid3.appdata.xml
+usr/share/doc/HTML/*/kid3/*
+usr/share/kxmlgui5/kid3/kid3ui.rc
diff -Naur 3.8.5-1/debian/kid3.manpages 3.8.5-2/debian/kid3.manpages
--- 3.8.5-1/debian/kid3.manpages2021-02-01 11:45:07.719498539 +0100
+++ 3.8.5-2/debian/kid3.manpages1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-deb/kid3.1
-deb/kid3.de.1
diff -Naur 3.8.5-1/debian/kid3-qt.install 3.8.5-2/debian/kid3-qt.install
--- 3.8.5-1/debian/kid3-qt.install  2021-02-01 11:45:07.947497319 +0100
+++ 3.8.5-2/debian/kid3-qt.install  2021-06-18 15:59:46.351258076 +0200
@@ -1,5 +1,5 @@
-/usr/bin/kid3-qt
-/usr/share/doc/kid3-qt/*
-/usr/share/applications/org.kde.kid3-qt.desktop
-/usr/share/metainfo/org.kde.kid3-qt.appdata.xml
-/usr/share/icons/hicolor/*/apps/kid3-qt.*
+usr/bin/kid3-qt
+usr/share/doc/kid3-qt/*
+usr/share/applications/org.kde.kid3-qt.desktop
+usr/share/metainfo/org.kde.kid3-qt.appdata.xml
+usr/share/icons/hicolor/*/apps/kid3-qt.*
diff -Naur 3.8.5-1/debian/kid3-qt.manpages 3.8.5-2/debian/kid3-qt.manpages
--- 3.8.5-1/debian/kid3-qt.manpages 2021-02-01 11:45:07.855497812 +0100
+++ 3.8.5-2/debian/kid3-qt.manpages 1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-deb/kid3-qt.1
-deb/kid3-qt.de.1
diff -Naur 3.8.5-1/debian/not-installed 3.8.5-2/debian/not-installed
--- 3.8.5-1/debian/not-installed2021-02-01 11:45:07.927497426 +0100
+++ 3.8.5-2/debian/not-installed1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-usr/share/man/pt/man1/kid3-cli.1.gz
-usr/share/man/pt/man1/kid3.1.gz
-usr/share/man/pt/man1/kid3-qt.1.gz
-usr/share/man/man1/kid3-cli.1.gz
-usr/share/man/man1/kid3.1.gz
-usr/share/man/man1/kid3-qt.1.gz
-usr/share/man/ca/man1/kid3-cli.1.gz
-usr/share/man/ca/man1/kid3.1.gz
-usr/share/man/ca/man1/kid3-qt.1.gz
-usr/share/man/nl/man1/kid3-cli.1.gz
-usr/share/man/nl/man1/kid3.1.gz
-usr/share/man/nl/man1/kid3-qt.1.gz
-usr/share/man/it/man1/kid3-cli.1.gz
-usr/share/man/it/man1/kid3.1.gz
-usr/share/man/it/man1/kid3-qt.1.gz
-usr/share/man/sv/man1/kid3-cli.1.gz
-usr/share/man/sv/man1/kid3.1.gz
-usr/share/man/sv/man1/kid3-qt.1.gz
-usr/share/man/de/man1/kid3-cli.1.gz
-usr/share/man/de/man1/kid3.1.gz
-usr/share/man/de/man1/kid3-qt.1.gz
-usr/share/man/uk/man1/

Bug#990036: unblock: xdot/1.2-2

[Stefano Rivera]

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

Please unblock package xdot

[ Reason ]
Fixing a (non-filed) RC bug - missing dependency on numpy.
https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/1496

[ Impact ]
The package may not be usable, if the user doesn't have numpy installed,
already.

[ Tests ]
No automated tests.

Manually tested that the package is still installable, and works.

[ Risks ]
Trivial change.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock xdot/1.2-2
diff -Nru xdot-1.2/debian/changelog xdot-1.2/debian/changelog
--- xdot-1.2/debian/changelog   2020-11-23 16:08:19.0 -0400
+++ xdot-1.2/debian/changelog   2021-06-18 10:01:16.0 -0400
@@ -1,3 +1,9 @@
+xdot (1.2-2) unstable; urgency=medium
+
+  * Add missing dependency on python3-numpy, introduced in 1.2.
+
+ -- Stefano Rivera   Fri, 18 Jun 2021 10:01:16 -0400
+
 xdot (1.2-1) unstable; urgency=low
 
   [ Stefano Rivera ]
diff -Nru xdot-1.2/debian/control xdot-1.2/debian/control
--- xdot-1.2/debian/control 2020-11-23 16:08:19.0 -0400
+++ xdot-1.2/debian/control 2021-06-18 10:01:16.0 -0400
@@ -22,6 +22,7 @@
  graphviz,
  python3-gi,
  python3-gi-cairo,
+ python3-numpy,
  ${misc:Depends},
  ${python3:Depends}
 Description: interactive viewer for Graphviz dot files

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.

To avoid exactly this problem, postgresql-common is maintaining a list
of PG versions that have clusters on the system:

/etc/apt/apt.conf.d/01autoremove-postgresql

APT
{
  NeverAutoRemove
  {
"^postgresql.*-11";
"^postgresql.*-13";
  };
};

... so libgdal20 will not be autoremoved because
postgresql-11-postgis-2.5 is not autoremoved. The list is updated once
you `pg_dropcluster 11 main`.

> There is much less need for gdal-data breaking libgdal20 for us than
> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
> that use gdal in the maintainer scripts that would be using the old gdal
> on their removal. So there shouldn't be any actual expected breakage.

I don't know the GIS world enough to be able to say what the data
files in gdal-data are good for, but my guess would be that for the
"read geometry data from an old postgresql-11 cluster", which is what
we need for pg_upgradecluster, they aren't relevant, and just making
libgdal20 co-installable is enough.

People shouldn't be expecting to be able to use the old postgis to do
complex data type (gdal?) or coordinate system (proj?) transformations
on a system that has already been upgraded to the new library versions
anyway.

> This change is minimal, doesn't require NEW packages, nor introduces
> divergence from upstream (as when the files would be moved to
> u/s/gdal/ in libgdal28), hence it's my preferred solution.
> 
> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
> changes from the debdiff to unstable.

Sounds good to me, thanks!

Christoph

Bug#990034: libconfig-model-dpkg-perl: scan-copyrights does not handle non ASCII chars in package.json

[Walter Lozano]

Package: libconfig-model-dpkg-perl
Version: 2.132
Severity: normal

Dear Maintainer,

During my work I noticed that scan-copyrights does not handle non ASCII chars
in package.json, which leads to the following error

"malformed UTF-8 character in JSON string"

A proposed fix can be found in

https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-
perl/-/merge_requests/5

I hope you can check the issue and help me to fix it.

Thanks in advance,

Walter



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-55-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 libconfig-model-dpkg-perl depends on:
ii  debhelper  12.10ubuntu1
ii  libapt-pkg-perl0.1.36build3
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.138-2
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.9-1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.75-1
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-2
ii  libwww-perl6.43-1
ii  libyaml-libyaml-perl   0.81+repack-1
ii  licensecheck   3.0.45-1
ii  lintian2.62.0
ii  perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.371-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#990035: less dies with double free

[Jörg Sommer]

Package: less
Version: 551-2
Severity: normal

Hi,

I started less with piped input `cat file |less` and hit `s` to save the
data. Unfortunately, I've selected a directory like `/tmp` and hit `D` to
“Don't save.” Then I hit `s` again and selected the directory again and less
crashed.

I have the environment variables `LESS=-ij3MqRSWz-2` and
`LESSOPEN=|lesspipe %s` set.

This is the backtrace:

```
   PID: 2996284 (less)
   UID: 1000 (joerg)
   GID: 1000 (joerg)
Signal: 6 (ABRT)
 Timestamp: Fri 2021-06-18 15:39:58 CEST (26s ago)
  Command Line: less
Executable: /usr/bin/less
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/awesome.service
  Unit: user@1000.service
 User Unit: awesome.service
 Slice: user-1000.slice
 Owner UID: 1000 (joerg)
   Boot ID: f1e1e7fe6b0449b6ba3a21c1312f8ce2
Machine ID: 523cb54753234ed08c13ec497d0d3b64
  Hostname: zenbook
   Storage: 
/var/lib/systemd/coredump/core.less.1000.f1e1e7fe6b0449b6ba3a21c1312f8ce2.2996284.162402359800.zst
 (present)
 Disk Size: 49.2K
   Message: Process 2996284 (less) of user 1000 dumped core.

Stack trace of thread 2996284:
#0  0x7fdcd5bd5ce1 __GI_raise (libc.so.6 + 0x3bce1)
#1  0x7fdcd5bbf537 __GI_abort (libc.so.6 + 0x25537)
#2  0x7fdcd5c18768 __libc_message (libc.so.6 + 0x7e768)
#3  0x7fdcd5c1fa5a malloc_printerr (libc.so.6 + 0x85a5a)
#4  0x7fdcd5c20d55 _int_free (libc.so.6 + 0x86d55)
#5  0x55e57aefd3ab n/a (less + 0x143ab)
#6  0x55e57aefebda n/a (less + 0x15bda)
#7  0x55e57aef397b n/a (less + 0xa97b)
#8  0x55e57aef4f9f n/a (less + 0xbf9f)
#9  0x55e57aeed7fe n/a (less + 0x47fe)
#10 0x7fdcd5bc0d0a __libc_start_main (libc.so.6 + 0x26d0a)
#11 0x55e57aeed88a n/a (less + 0x488a)

Downloading separate debug info for /usr/bin/less...
[New LWP 2996284]
Downloading separate debug info for /lib/x86_64-linux-gnu/libtinfo.so.6...
Downloading separate debug info for 
/home/joerg/.cache/debuginfod_client/d6920dbdd057f44edaf4c1fbce191b5854dfd9e6/debuginfo...
Downloading separate debug info for /home/joerg/system-supplied DSO at 
0x7ffe533f2000...
Core was generated by `less'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
Download failed: Das Argument ist ungültig.  Continuing without source file 
./signal/../sysdeps/unix/sysv/linux/raise.c.
50  ../sysdeps/unix/sysv/linux/raise.c: Unpassender IOCTL (I/O-Control) für 
das Gerät.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0 }}
pid = 
tid = 
ret = 
#1  0x7fdcd5bbf537 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 }}, sa_flags = 0, sa_restorer = 0x0}
sigs = {__val = {32, 0 }}
#2  0x7fdcd5c18768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fdcd5d26e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
ap = {{gp_offset = 24, fp_offset = 0, overflow_arg_area = 
0x7ffe533c5700, reg_save_area = 0x7ffe533c5690}}
fd = 
list = 
nlist = 
cp = 
#3  0x7fdcd5c1fa5a in malloc_printerr (str=str@entry=0x7fdcd5d291c8 "double 
free or corruption (fasttop)") at malloc.c:5347
No locals.
#4  0x7fdcd5c20d55 in _int_free (av=0x7fdcd5d58b80 , 
p=0x55e57c25a9e0, have_lock=0) at malloc.c:4266
idx = 0
old = 
old2 = 
size = 
fb = 0x7fdcd5d58b90 
nextchunk = 
nextsize = 
nextinuse = 
prevsize = 
bck = 
fwd = 
__PRETTY_FUNCTION__ = "_int_free"
#5  0x55e57aefd3ab in opt_o (type=, s=0x55e57af14ee0 
 "/tmp/iii") at optfunc.c:118
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
filename = 
#6  0x55e57aefebda in toggle_option (o=0x55e57af13b80 , 
lower=, s=, s@entry=0x55e57af14ee0  
"/tmp/iii", how_toggle=) at option.c:446
num = 
no_prompt = 0
err = 0
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
#7  0x55e57aef397b in exec_mca () at command.c:262
cbuf = 0x55e57af14ee0  "/tmp/iii"
#8  0x55e57aef4f9f in mca_char (c=10) at command.c:635
ret = 
ret = 
#9  commands () at command.c:1180
c = 
action = 
cbuf = 
newaction = 101
save_search_type = 
extra = 0x55e57af135dd  "o"
tbuf = "s"
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
old_ifile = 
new_ifile = 
tagfile = 
again = 
#10 0x55e57aeed7fe in main (argc=, argv=0x7ffe533c59d0) at 
main.c:285
if

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Andreas Beckmann
> > modulo the problem I ran into. (I still have to retry it.)
> 
> Didn't see this on my side.
> Your --force-depends probably affected more than just libgdal20.

Found the problem, I had not restarted postgresql-11 after the
upgrade, so it was still linked against the old libc, but dlopening
the various postgis libs failed as these want the new libc. After
restarting, the geometry data is still there.

> So co-installable libgdal20/libgdal28 simplifies postgis data migration
> because postgresql-11+postgis from buster remains installed and accessible
> along postgresql-13+postgis.

Yes.

Christoph

Bug#990033: ITP: r-cran-mathjaxr -- use MathJax in R documentation files

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: r-cran-mathjaxr
  Version : 1.4-0
  Upstream Author : Wolfgang Viechtbauer 
* URL : https://github.com/wviechtb/mathjaxr
* License : GPL
  Programming Lang: R
  Description : use MathJax in R documentation files

Provides 'MathJax' and macros to enable its use within Rd files for
rendering equations in the HTML help files.

I intend to maintain this package as a member of the Debian R Packages
Maintainers team.

Bug#990032: ondir FTCBFS: passes a build architecture CC

[Helmut Grohne]

Source: ondir
Version: 0.2.3+git0.55279f03-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ondir fails to cross build from source, because it uses the build
architecture compiler. Normally, the solution is using dh_auto_build,
but here that's already the case and the issue arises from overriding
CC=cc. If you want to support CC as an environment variable, please use
dpkg's buildtools.mk. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru ondir-0.2.3+git0.55279f03/debian/changelog 
ondir-0.2.3+git0.55279f03/debian/changelog
--- ondir-0.2.3+git0.55279f03/debian/changelog  2016-12-22 13:30:22.0 
+0100
+++ ondir-0.2.3+git0.55279f03/debian/changelog  2021-06-18 07:25:07.0 
+0200
@@ -1,3 +1,10 @@
+ondir (0.2.3+git0.55279f03-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk initialize CC. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 18 Jun 2021 07:25:07 +0200
+
 ondir (0.2.3+git0.55279f03-1) unstable; urgency=medium
 
   * Initial release (Closes: #846237)
diff --minimal -Nru ondir-0.2.3+git0.55279f03/debian/rules 
ondir-0.2.3+git0.55279f03/debian/rules
--- ondir-0.2.3+git0.55279f03/debian/rules  2016-12-22 13:30:22.0 
+0100
+++ ondir-0.2.3+git0.55279f03/debian/rules  2021-06-18 07:25:05.0 
+0200
@@ -5,7 +5,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CPPFLAGS_MAINT_APPEND = -DVERSION=\"$(VERSION)\" 
-DGLOBAL_CONF=\"/etc/onddirrc\"
 
-CC ?= cc
+-include /usr/share/dpkg/buildtools.mk
 CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
dpkg-buildflags --get CFLAGS)
 LDFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get LDFLAGS)
 

Bug#990031: glibc FTCBFS: multiple reasons

[Helmut Grohne]

Source: glibc
Version: 2.31-12
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi Aurelien et al,

while we do cross build glibc stage2 during architecture bootstrap with
some hacks, I've never really attempted cross building it in a pristine
build environment. Now the need has arisen and I've figured that it
doesn't work. There are three distinct problems.

The binutils dependency is interpreted as a host architecture
dependency. Unfortunately, host binutils are neither runnable nor
coinstallable with build-essential. What you really want here is
binutils for the host architecture. This problem is known as "toolchain
dependency translation". We devised a number of possible solution and
ultimately settled on my crazy one back then in 2014 in Paris. The rough
idea is to suffix build tools with -for-build or -for-host and let those
packages magically do the right thing. Fortunately, this actually works
for binutils already.

Nextup is g++-10. The problem is equal to binutils. Unfortunately, we've
not fully implemented the devised solution here yet. We've got patches
for gcc-N and for gcc-defaults, but more review and testing is needed
before those can be uploaded to unstable. In the mean time, the linux
maintainers figured a clever workaround. Instead of $tool, they write
something slightly longer:

$tool ,
$tool-$gnutriplet1 [arch1] ,
$tool-$gnutriplet2 [arch2] ,
$tool-gnutriplet3 [arch3] ,
...

Yes, this is slightly longish and a little bit ugly. The upshot is that
it works today. Can you bear this temporarily?

Nextup, malloc/Makefile says that the check for libgd does not work for
cross compilation and skips building memusageat. debhelper then
complains when it is missing. In fact, the libgd check does work just
fine during cross builds and the hack can be removed.

So here you have a patch that makes glibc cross buildable to arm64
without any fuss.

Do note that I did not touch the multilib dependency. Cross building for
e.g. amd64 requires adding the nobiarch profile. I think this is a fair
compromise for now.

Helmut
diff --minimal -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog
--- glibc-2.31/debian/changelog 2021-05-01 22:56:06.0 +0200
+++ glibc-2.31/debian/changelog 2021-06-18 14:40:52.0 +0200
@@ -1,3 +1,13 @@
+glibc (2.31-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate binutils dependency with -for-host.
++ Use suffixed cross compilers until there is -for-host.
++ cross.patch: LIBGD detection actually works.
+
+ -- Helmut Grohne   Fri, 18 Jun 2021 14:40:52 +0200
+
 glibc (2.31-12) unstable; urgency=medium
 
   * debian/po/de.po: fix encoding declaration.  Closes: #986450.
diff --minimal -Nru glibc-2.31/debian/control glibc-2.31/debian/control
--- glibc-2.31/debian/control   2021-01-05 06:41:20.0 +0100
+++ glibc-2.31/debian/control   2021-06-18 14:30:58.0 +0200
@@ -8,10 +8,11 @@
  mig-for-host (>= 1.5-3) [hurd-i386], gnumach-dev (>= 2:1.8+git20200710-2~) 
[hurd-i386],
  hurd-dev (>= 1:0.9.git20201127-4~) [hurd-i386] | hurd-headers-dev [hurd-i386],
  kfreebsd-kernel-headers [kfreebsd-any],
- binutils (>= 2.29),
- g++-10, g++-10-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 
mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
- gcc-10 (>= 10-20200431) [arm64],
- gcc-10 (>= 10.1.0-3) [hurd-i386],
+ binutils-for-host (>= 2.29),
+ g++-10 , g++-10-multilib [amd64 i386 kfreebsd-amd64 mips mipsel 
mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el 
mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
+ g++-10-x86-64-kfreebsd-gnu [kfreebsd-amd64] , g++-10-i686-kfreebsd-gnu 
[kfreebsd-i386] , g++-10-x86-64-kfreebsd-gnu [kfreebsd-amd64] , 
g++-10-i686-kfreebsd-gnu [kfreebsd-i386] , g++-10-x86-64-linux-gnu 
[amd64] , g++-10-aarch64-linux-gnu [arm64] , 
g++-10-arm-linux-gnueabi [armel] , g++-10-arm-linux-gnueabihf [armhf] 
, g++-10-hppa-linux-gnu [hppa] , g++-10-i686-linux-gnu [i386] 
, g++-10-m68k-linux-gnu [m68k] , g++-10-mips-linux-gnu [mips] 
, g++-10-mipsel-linux-gnu [mipsel] , 
g++-10-mips64-linux-gnuabin32 [mipsn32] , 
g++-10-mips64el-linux-gnuabin32 [mipsn32el] , 
g++-10-mips64-linux-gnuabi64 [mips64] , g++-10-mips64el-linux-gnuabi64 
[mips64el] , g++-10-mipsisa32r6-linux-gnu [mipsr6] , 
g++-10-mipsisa32r6el-linux-gnu [mipsr6el] , 
g++-10-mipsisa64r6-linux-gnuabin32 [mipsn32r6] , 
g++-10-mipsisa64r6el-linux-gnuabin32 [mipsn32r6el] , 
g++-10-mipsisa64r6-linux-gnuabi64 [mips64r6] , 
g++-10-mipsisa64r6el-linux-gnuabi64 [mips64r6el] , 
g++-10-nios2-linux-gnu [nios2] , g++-10-powerpc-linux-gnu [powerpc] 
, g++-10-powerpc64-linux-gnu [ppc64] , 
g++-10-powerpc64le-linux-gnu [ppc64el] , g++-10-riscv64-linux-gnu 
[riscv64] , g++-10-sparc-linux-gnu [sparc] , 
g++-10-sparc64-linux-gnu [sparc64] , g++-10-s390x-linux-gnu [s390x] 
, g++-10-sh3-linux-gnu [s

Bug#987399: New upstream version 2.6.0

[Harald Dunkel]

Second that, except that the current version is 2.8.0 now.


Regards
Harri

Bug#990030: unblock: otrs2/6.0.32-5

[Patrick Matthäi]

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

Please unblock package otrs2

It fixes two security issues with the upstream patches.

 changelog   |   15 ++
 patches/14-ZSA-2021-03.diff |  100 
 patches/15-ZSA-2021-06.diff |   92 
 patches/series  |2
 4 files changed, 209 insertions(+)

Full diff attached. Thanks :)

unblock otrs2/6.0.32-5

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

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


otrs.diff.gz
Description: application/gzip

Bug#989915: RFS: minidb/2.0.5-1 -- simple SQLite3-based store for Python objects

[Tobias Frost]

Hi Maxime,

uploaded, thanks for your contribution!

Two nitpicks (just cosmetical issues)
- you dont need to B-D on debhelper AND debhelper-compat; the latter is 
sufficient.
- you can combine the years in d/copyright, no need for an extra line, just say
  "2009-2010,2014-2021 Thomas Perl "

-- 
tobi

Bug#990019: #990019,initscripts: single user mode broken with newer versions of systemd

[Jesse Smith]

I was a little confused by the subject of this bug since this has
nothing to do with systemd. Neither the script nor the init call has any
connection to systemd.

The issue here is that the init script (/etc/init.d/single) is trying to
call SysV init with the "-t1" flag, which is not valid. There is no -t
flag or -t1 flag for init.

I suspect what the script was intended to do is call "/sbin/telinit -t 1
s". This would switch to single user mode after a delay of just one second.

- Jesse

Bug#587380: debconf-set-selections: --checkonly issues warning about password db

[Marc Haber]

On Sun, Jun 27, 2010 at 07:23:06PM -0700, Vagrant Cascadian wrote:
> the following warning:
> 
>   debconf-set-selections --checkonly 
> /usr/share/simple-cdd/profiles/default.preseed
>   debconf: DbDriver "passwords" warning: could not open 
> /var/cache/debconf/passwords.dat: Permission denied
> 
> is it possible to check the format of a preseeding file without actually
> accessing the debconf password database and issuing a warning?
> 
>that would be nice. thanks!

Can this please have some maintainer attention after almost eleven
years?

Greetings
Marc

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

On Fri, Jun 18, 2021 at 10:59:18AM +, Paul Wise wrote:
> On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:
> 
> > I suggest to read [1] and all linked documents, and recreate the package.
> > You'll find dh_make(1) from the package dh-make useful to generate boiler 
> > plate
> > templates for the debian directory. Those templates needs to be hand-edited
> > afterwards, many of them wont be needed: you'd rm them… To get hints, you 
> > may
> > take a look a similar packages as well
> 
> The packages generated by stdeb are usually much closer to a final
> package than those generated by dh-make, so I would suggest to fix the
> existing packaging instead of starting from scratch.

I've just ran dh_make on it and did an diff: IMGO dh_make did a far
better job than that from the dsc of that RFS. However, that is my bikeshed 
color.

> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Bug#969376: openafs-client: Openafs cache erros on the logs

[Jose M Calhariz]

No problem, here is the reply to the Debian bug and my coworkers.

Kind regards
Jose M Calhariz

On Thu, Jun 17, 2021 at 08:26:57PM -0500, Andrew Deason wrote:
> That's a question for Ben. Can you reply to 969...@bugs.debian.org
> instead? (or ask him directly via ka...@mit.edu ). I was replying to you
> directly, so the reply-to didn't go to the debian bug, sorry.
> 



> Hi
>
> Thank you for the follow up.  The machine were this error is coming
> from have a complicated pattern of access to AFS, that I can not
> reproduce so I will try 1.8.8pre1 on that machine.  Is an experimental
> package for Debian near?  I can try to package myself, but I would
> prefer a package from the maintainer.
>
> Kind regards
> Jose M Calhariz
>
>
> On Thu, Jun 17, 2021 at 05:39:05PM -0500, Andrew Deason wrote:
> > Sorry, I may have accidentally not included you in this reply (not sure
> > if you got this?). I didn't mean to exclude you, so just in case, here
> > it is directly:
> >
> > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote:
> > > > The an example of errors on the logs are:
> > > >
> > > > afs: disk cache read error in CacheItems slot 350195 off 
> > > > 28015620/3520 code -4/80
> > > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; 
> > > > failing with an i/o error
> >
> > Hi, I'm the person that mentioned this briefly during the AFS workshop
> > this week. These messages are not in themselves a problem; they are just
> > reporting that we got an error code from the Linux kernel when trying to
> > read from the disk cache.
> >
> > On Tue, 1 Sep 2020 16:07:55 -0700
> > Benjamin Kaduk  wrote:
> >
> > > This error message is supposed to indicate that a read from the cache
> > > filesystem got EIO, which in turn is supposed to indicate a physical
> > > problem with the drive.  That said, I'm not going to jump to conclusions
> > > and try to blame your drive, as there are several other things that could
> > > be coming into play.
> >
> > The code logged is -4, which is EINTR (EIO would be -5). The most likely
> > trigger of this is a process that got a SIGKILL signal (or other fatal
> > signal) while we were reading from the disk cache. Traditionally we
> > wouldn't get errors in that case, but Linux started returning errors in
> > that situation after some version (possibly depending on the local fs in
> > use? but I don't recall exactly).
> >
> > If you think these messages happen when some other bug or problem is
> > happening, that's possible, but the messages themselves are not a
> > problem. If you want to avoid the situation that causes these messages,
> > you can try to avoid SIGKILL'ing the relevant processes, if you know
> > what's causing that. The message you've shown doesn't log the pid, but
> > there is already a change in 1.8.8pre1 to log the pid and some other
> > information in that log message.
> >
> > If you want the specific patch to add some more info to that log
> > message, it's here (gerrit 14437):
> >
> > https://git.openafs.org/?p=openafs.git;a=patch;h=5d863b4f6e817b1cc2615265c7747e17a2037ae6
> >
> > I know of at least one bug that can be triggered by the log message
> > you've mentioned, which is fixed by gerrit 14451 here:
> >
> > https://git.openafs.org/?p=openafs.git;a=patch;h=c55607d732a65f8acb1dfc6bf93aee0f4409cecf
> >
> > That's also in 1.8.8pre1, so if it's feasible for you to just try
> > 1.8.8pre1, that's probably easiest. The messages will still appear with
> > 1.8.8pre1, but they may be more informative, and some other related bugs
> > may be fixed. If you are seeing some other problematic behavior with
> > 1.8.8pre1, I can take a look if you provide some details.
> >
> >
>
> --
> --
>
> As pessoas mudam através do que alcançam
>
> --Wystan Hugh Auden



-- 
--

As pessoas mudam através do que alcançam

--Wystan Hugh Auden


signature.asc
Description: PGP signature

Bug#988779: closed by Debian FTP Masters (reply to Vincent Bernat ) (Bug#988779: fixed in haproxy 2.2.9-2)

[Vincent Bernat]

 ❦ 18 June 2021 11:48 +02, Stefan Schlesinger:

> Thanks for the fix! Is the updated version going to transition to
> buster-backports at some point?

Hello Stefan,

I have just uploaded it.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Paul Wise]

On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:

> I suggest to read [1] and all linked documents, and recreate the package.
> You'll find dh_make(1) from the package dh-make useful to generate boiler 
> plate
> templates for the debian directory. Those templates needs to be hand-edited
> afterwards, many of them wont be needed: you'd rm them… To get hints, you may
> take a look a similar packages as well

The packages generated by stdeb are usually much closer to a final
package than those generated by dh-make, so I would suggest to fix the
existing packaging instead of starting from scratch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#982459: mdadm --examine in chroot without /proc,/dev,/sys mounted corrupts host's filesystem

[Patrick Cernko]

Hi,

On 25.04.21 00:36, Judit Foglszinger wrote:


can you reproduce this bug on bullseye? (4.1-11)
If so, what is your configuration (VM used, type of RAID)?
Are all three conditions (/proc, /dev and /sys not mounted) required
or does this also happen, if eg /dev and /sys are there but not /proc?

If it still occurs until there would be a proper fix by upstream,
a workaround like "are we in a chroot, if so,
are the required things mounted, if not, fail",
could be used to avoid the file system corruption.

My own observations:

Could not reproduce in virtualbox (both chroot and host system using recent 
bullseye),
using RAID1,  /dev/md0 on / type ext4 (rw,relatime,errors=remount-ro)

# chroot chroot
/ # mdadm --examine --scan --config=partitions
/ # mdadm: cannot open /proc/partitions
/ # mdadm: No devices listed in partitions

(in background on host running the mentioned find / command)

No filesystem corruption after over 15 minutes,
running the mdadm command in chroot several times didn't make a difference on 
that.



I'm really sorry: Somehow I missed this mail when it came in my inbox 6 
weeks ago. I only recognized the answer when I checked bugs.debian.org 
last week.


I tried to reproduce the bug again and discovered, that my description 
contained a serious error: In fact /proc MUST be mounted in the chroot 
to observe the bug!


I also could reproduce the bug with mdadm-4.1-11 (from bullseye) 
installed in the buster chroot (all other packages still from buster).


I will try to reproduce the bug now with one of /dev or /sys mounted and 
check if it still occurs or not. I will send my report about this later 
as this will take some time again.


Sorry for the delayed answer and the error in my initial bug report.

Best Regards,
--
Patrick Cernko 
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#989777: Re: Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Salut Vincent,

Thanks for these informations.

Does this mean that I have a chance of seeing a patch arrive on Debian's 5.10 
LTS kernel ?

Or is it better for me that I migrate to Ubuntu while waiting for the 
availability of a kernel 5.11 or higher in the Backports directory ?

I'm not really a fan of Ubuntu and even less of its Snap packages for Chromium 
and other softwares.

What bothers me the most in this story is that Intel guarantees us on its 
website compatibility with Kernel 5.10, which is why I bought this material and 
in the end it is not ;-( If j had known I would have chosen another material...

I wish you a great weekend.

Meilleures salutations.

Philippe


Message d'origine
De : vincent.deb...@free.fr
Date : 17/06/2021 - 22:15 (E)
À : pham...@bluewin.ch
Cc : andreimpope...@gmail.com, 989...@bugs.debian.org, li...@packages.debian.org
Objet : Re: Re: Severity: High / Debian 10 & 11 with Kernel 
5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

Salut Philippe,

Le 2021-06-14 23:09, pham...@bluewin.ch a écrit :
> The boot is difficult, I have a recurring error message that turns in a loop.
> 
> journalctl -k | grep -Ei "iwl|bluetooth :
> 
> 
> root@portable-1:~# journalctl -k | grep -Ei "iwl|bluetooth"
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: enabling device 
> ( -> 0002)
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: 
> direct-loading firmware iwlwifi-ty-a0-gf-a0-59.ucode
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: api flags index 2 
> larger than supported by driver
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
> FSEQ Version: 93.8.63.28
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: loaded firmware 
> version 59.601f3a66.0 ty-a0-gf-a0-59.ucode op_mode iwlmvm
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwl-debug-yoyo.bin (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: Detected Intel(R) 
> Wi-Fi 6 AX210 160MHz, REV=0x420
> jun 14 22:48:12 portable-1 kernel: Bluetooth: Core ver 2.22
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI device and connection 
> manager initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: L2CAP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: SCO socket layer initialized
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwlwifi-ty-a0-gf-a0.pnvm (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: base HW address: 
> 54:14:f3:52:7b:e1
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0 wlp59s0: renamed from 
> wlan0
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP (Ethernet Emulation) ver 
> 1.3
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP filters: protocol multicast
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> 
> 
> systemctl status bluetooth.service :
> 
> 
> root@portable-1:~# systemctl status bluetooth.service
> ● bluetooth.service - Bluetooth service
>  Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Mon 2021-06-14 22:48:12 CEST; 10min ago
>Docs: man:bluetoothd(8)
>Main PID: 649 (bluetoothd)
>  Status: "Running"
>   Tasks: 1 (limit: 38030)
>  Memory: 2.6M
> CPU: 266ms
>  CGroup: /system.slice/bluetooth.service
>  └─649 /usr/libexec/bluetooth/bluetoothd
> 
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanIntervalConnect” in >
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanWindowConnect” in gr>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEMinConnectionInterval” i>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file d

Bug#987441: Krita

[Holger Wansing]

Hi Lothar,

Lothar Oelkers  wrote (Fri, 18 Jun 2021 09:56:10 +0200):
> Moin,
> bin begeistert von bullseye.
> Einzig Krita startet nicht nach korrekter Installation.
> Nach apt remove qt5dxcd-plugin funktionieren alle Anwendungen.
> Niemand vermisst das Paket.

Please don't post such issues to this bug!
This bug is only for problems regarding the debian-installer for Bullseye,
not more. We don't want it to be flooded with diverse Bullseye issues.

If you want to report an installation issue, please do so as documented
here:

https://d-i.debian.org/doc/installation-guide/de.amd64/apas04.html

or post to debian-b...@lists.debian.org


Holger

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

Bug#990029: konsole: Application and global menu

[Stefano Callegari]

Package: konsole
Version: 4:20.12.3-1
Severity: normal

Dear Maintainer,

when restore the konsole at startup from previous session, disappear the
application menu either in title bar (the burger icon) or in the panel bar
(simply empty).

If I open a new Konsole, both are showing.

Other restored together applications, like System Settings or Pidgin, have
their menus on title bar and in the panel bar, so it seems a konsole
problem.

Thanks.

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (903, 'unstable'), (500, 'testing'), (400, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages konsole depends on:
ii  kio5.78.0-4
ii  konsole-kpart  4:20.12.3-1
ii  libc6  2.31-12
ii  libkf5configcore5  5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5crash5   5.78.0-3
ii  libkf5dbusaddons5  5.78.0-2
ii  libkf5globalaccel-bin  5.78.0-3
ii  libkf5globalaccel5 5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5kiowidgets5  5.78.0-4
ii  libkf5notifyconfig55.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5windowsystem55.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libqt5core5a   5.15.2+dfsg-7
ii  libqt5gui5 5.15.2+dfsg-7
ii  libqt5widgets5 5.15.2+dfsg-7
ii  libstdc++6 10.2.1-6

konsole recommends no packages.

Versions of packages konsole suggests:
ii  lrzsz  0.12.21-10+b1

-- no debconf information

Bug#988779: closed by Debian FTP Masters (reply to Vincent Bernat ) (Bug#988779: fixed in haproxy 2.2.9-2)

[Stefan Schlesinger]

Hello!

Thanks for the fix! Is the updated version going to transition to 
buster-backports at some point?

Best, Stefan

Bug#990028: /usr/bin/mogrify-im6.q16: raw support requires ufraw-batch which is no longer in Debian

[Brian May]

Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: important
File: /usr/bin/mogrify-im6.q16

$ /usr/bin/mogrify-im6.q16 -verbose -write /dev/null 
/home/brian/photos/images/orig/2005/03/19/IMG_4706.CR2
'ufraw-batch' --silent --create-id=also --out-type=png --out-depth=16 
--output='/tmp/brian/magick-aPpSXk_qYFPwWeU4ZgkO-dXXYC9Ra4Et.png' 
'/tmp/brian/magick-OJc3dM30MFW8f-1VFUjQY1N_xwaRFy6r'
mogrify-im6.q16: delegate failed `'ufraw-batch' --silent --create-id=also 
--out-type=png --out-depth=16 --output='%u.png' '%i'' @ 
error/delegate.c/InvokeDelegate/1966.
mogrify-im6.q16: unable to open image 
`/tmp/brian/magick-aPpSXk_qYFPwWeU4ZgkO-dXXYC9Ra4Et.ppm': No such file or 
directory @ error/blob.c/OpenBlob/2924.

ufraw was removed from Debian - see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931725

According to https://github.com/ImageMagick/ImageMagick/issues/1617 it
looks like imagemagick fully supports using libraw instead. But this
needs to be compiled into the binary.

"If you install libraw development (header files are required), you must
then build/install ImageMagick from source. It will detect the delegate
library when you run the configure script and leverage it to read your
CR2 image."

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.31-12
ii  libmagickcore-6.q16-6  8:6.9.11.60+dfsg-1.3
ii  libmagickwand-6.q16-6  8:6.9.11.60+dfsg-1.3

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.53.3~dfsg-7
ii  libmagickcore-6.q16-6-extra  8:6.9.11.60+dfsg-1.3
ii  netpbm   2:10.0-15.4

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace   
pn  cups-bsd | lpr | lprng  
ii  curl7.74.0-1.2
pn  enscript
ii  ffmpeg  7:4.3.2-0+deb11u2
ii  gimp2.10.22-4
pn  gnuplot 
pn  grads   
ii  graphviz2.42.2-5
ii  groff-base  1.22.4-6
pn  hp2xx   
pn  html2ps 
pn  imagemagick-doc 
pn  libwmf-bin  
ii  mplayer 2:1.4+ds1-1
pn  povray  
pn  radiance
ii  sane-utils  1.0.31-4
pn  texlive-base-bin
pn  transfig
pn  ufraw-batch 
ii  xdg-utils   1.1.3-4.1

-- debconf-show failed

Bug#990000: tor: CVE-2021-34548 CVE-2021-34549 CVE-2021-34550

[Moritz Muehlenhoff]

On Fri, Jun 18, 2021 at 09:01:39AM +, Peter Palfrader wrote:
> On Thu, 17 Jun 2021, Salvatore Bonaccorso wrote:
> > CVE-2021-34548[1], CVE-2021-34549[2] and CVE-2021-34550[3].
> 
> Uploaded a 0.3.5.15-1 source package to security master with
> https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.5.15

Thanks! I'll take care of it later the evening.

Cheers,
Moritz

Bug#989979: thunderbird: Atom feeds cannot be retrieved

[Arjen Balfoort]

On Fri, 18 Jun 2021 09:35:18 +0200 Carsten Schoenert 
 wrote:

> Am 18.06.21 um 08:31 schrieb Arjen Balfoort:
>
> > Unfortunately, thunderbird-dbgsym is not available for amd64 in any
> > repository:
> > 
https://packages.debian.org/search?keywords=thunderbird-dbgsym&searchon=names&suite=all§ion=all

>
> I tend to disagree :)
> http://deb.debian.org/debian-debug/pool/main/t/thunderbird/
>
> More information how to enable debug-packages and how to install them
> can be found here:
> 
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

>
> As pointed from the output of the CLI switch for debugging.
>
> > $ thunderbird -g
> > INFO -> No package 'thunderbird-dbgsym' installed! Please install 
first and restart.
> > INFO -> More information how to adjust your sources.list to being 
able installing

> > INFO -> dbgsym packages in generally can be found here:
> > INFO -> 
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


I stand corrected! :)
I never realised the debug packages were found in a separate repository. 
You learn something new every day. Thanks!


Regards,
Arjen

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/15/21 8:23 AM, Andreas Beckmann wrote:
> On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
>>  From the many other packages I haven't seen other issues other than the
>> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>>
>> I really need more concrete cases to justify changes to gdal that I
>> don't like but will have to maintain.
> 
> What about libmrpt-dev ? (log posted here yesterday)

With hdf5 (1.10.6+repack-4) and ogdi-dfsg (4.1.0+ds-5) from unstable the
full-upgrade still fails to find a solution. With the Breaks removed
from gdal-data it works.

Kind Regards,

Bas

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

Bug#984824: dh-python: pybuild needs to support toml (PEP517/PEP518) builds with no setup.py

[Osamu Aoki]

Oops, typos:

s/what we need future/what we need is future/
s/projects.toml./pyproject.toml./

Bug#984824: dh-python: pybuild needs to support toml (PEP517/PEP518) builds with no setup.py

[Osamu Aoki]

Hi,

Here is my thought 

PEP-518 package may be without setup.py and may still be based on setuptools.  
For
that kind of package, work around using flit plugin doesn't work.

Packaging Python Projects tutorial has such example without setup.py by 
presenting
only setup.conf case as the first choice case. 
  https://packaging.python.org/tutorials/packaging-projects/

It even states:
> Dynamic metadata (setup.py) should be used only as an escape hatch when 
> absolutely
> necessary. setup.py used to be required, but can be omitted with newer 
> versions of
> setuptools and pip.

Of course, if I add the following escape hatch setup.py to the example using
setup.cnf only, such test package can build Debian package OK using the old 
setup.py
mechanism.

> #!/usr/bin/python3
> import setuptools
> setuptools.setup()

I think what we need future oriented solution, here.  We should create another 
plugin
for "build" which uses python3-build package as the PEP518 build backend.

   https://pypi.org/project/build/
   https://github.com/pypa/build
   https://packages.debian.org/unstable/python3-build

For Debian package building, we need to use --no-isolation to make sure build 
without
network access and with proper version.

> python3 -m build --no-isolation

Then install from generated wheel package file or from build directory, I guess.

This is more future oriented generic solution than the manual workaround using a
plugin or patching upstream source for each build tools.

If this "build" plugin matures, it should be selected automatically for package 
with
projects.toml.

Regards,

Osamu

Bug#990000: tor: CVE-2021-34548 CVE-2021-34549 CVE-2021-34550

[Peter Palfrader]

On Thu, 17 Jun 2021, Salvatore Bonaccorso wrote:
> CVE-2021-34548[1], CVE-2021-34549[2] and CVE-2021-34550[3].

Uploaded a 0.3.5.15-1 source package to security master with
https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.5.15

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

Bug#973570: fzf: keybinding files should be installed under /etc

[Jai Flack]

On Sun, 21 Feb 2021 17:11:28 +0100 Jonas Smedegaard  wrote:
> Debian Policy §12.6 says that /usr/share/doc/*/examples/ is "for the
> benefit of the system administrator and users as documentation only."
> 
> Notice the final part of "documentation only".

That is a good point; as they are intended for use I'll move them out of
doc/. This is also good opportinity to install the bash completions by
default and maybe the Vim plugin if it's not too intrusive.

-- 
Thanks,
Jai

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

Control: tags -1 moreinfo

Hi Tian,

thanks for volunteering and starting to contribute to Debian!

On Wed, Jun 16, 2021 at 11:10:08PM +0800, Tian wrote:


>  pocsuite3 (1.7.5-1) unstable; urgency=low
>  .
>* source package automatically created by stdeb 0.10.0

Unfortunatly the quality of packages generated by some generator usually
not adequate for inclusion in Debian. If you check the mentors page
of the package [1], you'll see that there are many issues…

I suggest to read [1] and all linked documents, and recreate the package.
You'll find dh_make(1) from the package dh-make useful to generate boiler plate
templates for the debian directory. Those templates needs to be hand-edited
afterwards, many of them wont be needed: you'd rm them… To get hints, you may
take a look a similar packages as well

[1] https://mentors.debian.net/package/pocsuite3/
[2] https://mentors.debian.net/intro-maintainers/

Once ready, please reupload to mentors and remove the moreinfo tag.

-- 
tobi

Bug#990027: pre-approval unblock: opendmarc/1.4.0~beta1+dfsg-6

[David Bürgin]

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

Please pre-approve unblock of package opendmarc

Recently several fixes for CVEs in OpenDMARC have landed in bullseye
thanks to unblock request #989324 being granted.

Now reports of crashes have arrived at the upstream bug tracker,
resulting in new CVE-2021-34555. It appears that the fix for
CVE-2019-16378 contains code that can segfault, given certain inputs. An
attacker can crash the current bullseye/sid version at will, so a fix is
urgently needed.

I have created a patch and proposed it upstream and would like to apply
it here as well via sponsorship on debian-mentors, hence this request
for pre-approval.

[ Reason ]
A fix for new CVE-2021-34555 has been proposed upstream.

[ Impact ]
Current opendmarc 1.4.0~beta1+dfsg-5 can be trivially crashed by a third
party leading to denial of service outage.

[ Tests ]
Reporter at upstream has confirmed the fix works, I also verified it via
manual test.

[ Risks ]
Upstream is not active, but they might prefer a different fix when they
come back.

[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing

unblock opendmarc/1.4.0~beta1+dfsg-6
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/changelog opendmarc-1.4.0~beta1+dfsg/debian/changelog
--- opendmarc-1.4.0~beta1+dfsg/debian/changelog	2021-06-02 14:17:33.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/changelog	2021-06-18 09:37:57.0 +0200
@@ -1,3 +1,10 @@
+opendmarc (1.4.0~beta1+dfsg-6) unstable; urgency=high
+
+  * Add patch for CVE-2021-34555 from upstream issue tracker:
+- Do not dereference NULL in multi-value From headers (Closes: #990001)
+
+ -- David Bürgin   Fri, 18 Jun 2021 09:37:57 +0200
+
 opendmarc (1.4.0~beta1+dfsg-5) unstable; urgency=high
 
   * Amend cve-2020-12272.patch to keep libopendmarc2 public ABI unchanged
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch	1970-01-01 01:00:00.0 +0100
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch	2021-06-15 16:36:43.0 +0200
@@ -0,0 +1,38 @@
+Description: CVE-2021-34555: Fix multi-value From rejection logic
+Author: David Bürgin 
+Bug: https://github.com/trusteddomainproject/OpenDMARC/pull/178
+
+--- a/opendmarc/opendmarc.c
 b/opendmarc/opendmarc.c
+@@ -2517,17 +2517,22 @@
+ 
+ 		for (c = 1; users[c] != NULL; c++)
+ 		{
+-			if (strcasecmp(domains[0], domains[c]) != 0)
++			if (domains[0] != NULL
++			&& domains[c] != NULL
++			&& strcasecmp(domains[0], domains[c]) != 0)
+ 			{
+-syslog(LOG_ERR,
+-   "%s: multi-valued From field detected",
+-   dfc->mctx_jobid);
+-			}
++if (conf->conf_dolog)
++{
++	syslog(LOG_ERR,
++	   "%s: multi-valued From field detected",
++	   dfc->mctx_jobid);
++}
+ 
+-			if (conf->conf_reject_multi_from)
+-return SMFIS_REJECT;
+-			else
+-return SMFIS_ACCEPT;
++if (conf->conf_reject_multi_from)
++	return SMFIS_REJECT;
++else
++	return SMFIS_ACCEPT;
++			}
+ 		}
+ 
+ 		user = users[0];
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/series opendmarc-1.4.0~beta1+dfsg/debian/patches/series
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/series	2021-06-02 12:14:59.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/series	2021-06-15 16:23:10.0 +0200
@@ -12,3 +12,4 @@
 cve-2019-16378.patch
 cve-2020-12272.patch
 cve-2019-20790.patch
+cve-2021-34555.patch

Bug#987441: Krita

[Lothar Oelkers]

Moin,
bin begeistert von bullseye.
Einzig Krita startet nicht nach korrekter Installation.
Nach apt remove qt5dxcd-plugin funktionieren alle Anwendungen.
Niemand vermisst das Paket.
Gruß
Lothar

Bug#989943: maybe use at instead of shutdown -r $TIME

[Tomas Pospisek]

On Thu, 17 Jun 2021, Tomas Pospisek wrote:

With respect to "unattended-upgrades blocking other cron.daily scripts via 
shutdown -r" I reflected:



Now what would a "correct" or "better" behavior be?

I suggest to trigger an asynchronous shutdown, that is *not*
to wait for `shutdown -r $TIME` to come back so that whatever
daily menial taks are scheduled via /etc/cron.daily are able
to be executed.


What about the idea of using

   echo "shutdown -r now" | at $TIME

instead of directly calling

   shutdown -r now

Pro:

* async execution. unattended-update can finish it's stuff and
 the rest of cron.daily finishes correctly
* consoles won't be flooded with repeat "Systeme will be going
 doing in XX hours"

Con:

* does care have to be taken that unattended-upgrade won't re-run
 while it wants the system to reboot?
* behavior change (this should be triggering a major semver change...)
 * this could be worked around with yet another config option
   (UseAtInstead=True)
* users on the system won't be warned of the system going down in
 XX hours

What do you think?


The idea in code:

--- /usr/bin/unattended-upgrade.orig2021-06-18 09:46:37.434386824 
+0200

+++ /usr/bin/unattended-upgrade 2021-06-18 09:47:03.958639111 +0200
@@ -1353,11 +1353,12 @@
 when = apt_pkg.config.find(
 "Unattended-Upgrade::Automatic-Reboot-Time", "now")
 logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
-cmd = ["/sbin/shutdown", "-r", when]
+cmd = ["/usr/bin/at", when]
 try:
-shutdown_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
-if shutdown_msg.strip():
-logging.warning("Shutdown msg: %s", shutdown_msg.strip())
+p = subprocess.Popen(cmd, stdin=subprocess.PIPE, 
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+p_out = p.communicate(input=b'shutdown -h 
now\n')[0].decode('utf-8').strip()
+if p_out:
+logging.warning("Shutdown msg: %s", p_out)
 except Exception as e:
 logging.error("Failed to issue shutdown: %s", e)

Feedback about whether this is a good idea is appreciated.

Thanks & greetings,
*t

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/14/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>>> What actual problems do are solved by making them co-installable?
>>>
>>> So far the only actualy problem that has been identified is the need for
>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
>>> present.
>>
>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
>> attached, no bug filed, yet). The only solution I could find so far was
>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
>> to gcc-10-base.
>> With a co-installable libgdal20/libgdal28 this is gone because the huge
>> dependency trees no longer conflict with each other.
>>
>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
>> issues. So I can concentrate on fixing the remaining incomplete
>> (unversioned) python (2) removal bits. ;-)
> 
> If co-installable libgdal is a must, then I'd rather drop gdal-data and
> move its content back to libgdal28 with an override for the
> big-usr-share lintian issue. That's how it was a long time ago:
> 
>  
> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
> 
> I'm not in favor of either option, though.
> 
> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
> for the bits that use it. It will help with the dependency resolution.

I'm increasingly in favor of removing the Breaks from gdal-data, the
attached procedure works for me in buster chroot.

Note the requirements of hdf5 (1.10.6+repack-4), ogdi-dfsg (4.1.0+ds-5),
and gdal (3.2.2+dfsg-2). Both hdf5 and ogdi-dfsg packages are taken from
sid and made available for bullseye via a local repo. gdal only drops
the Breaks to not have libgdal20 removed when libgdal28 is installed
(via postgresql-13-postgis-3 dependencies), see the attached debdiff.

Since the upgrade procedure documented in the release notes includes
purging removed and obsolete packages, users are not expected to keep
libgda20 around after the distribution upgrade.

There is much less need for gdal-data breaking libgdal20 for us than
there is in the UbuntuGIS PPA use case. I'm not aware of any packages
that use gdal in the maintainer scripts that would be using the old gdal
on their removal. So there shouldn't be any actual expected breakage.

This change is minimal, doesn't require NEW packages, nor introduces
divergence from upstream (as when the files would be moved to
u/s/gdal/ in libgdal28), hence it's my preferred solution.

If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
changes from the debdiff to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
# Have hdf5 (1.10.6+repack-4), ogdi-dfsg (4.1.0+ds-5), gdal (3.2.2+dfsg-2) 
available for bullseye

apt install postgresql postgresql-11-postgis-2.5{,-scripts} sudo less

pg_ctlcluster 11 main start

sudo -u postgres createdb test

sudo -u postgres psql -vON_ERROR_STOP=1 test 

Bug#989979: thunderbird: Atom feeds cannot be retrieved

[Carsten Schoenert]

Am 18.06.21 um 08:31 schrieb Arjen Balfoort:

> Unfortunately, thunderbird-dbgsym is not available for amd64 in any 
> repository: 
> https://packages.debian.org/search?keywords=thunderbird-dbgsym&searchon=names&suite=all§ion=all

I tend to disagree :)
http://deb.debian.org/debian-debug/pool/main/t/thunderbird/

More information how to enable debug-packages and how to install them
can be found here:
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

As pointed from the output of the CLI switch for debugging.

> $ thunderbird -g
> INFO  -> No package 'thunderbird-dbgsym' installed! Please install first and 
> restart.
> INFO  -> More information how to adjust your sources.list to being able 
> installing
> INFO  -> dbgsym packages in generally can be found here:
> INFO  -> 
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


-- 
Regards
Carsten