Bug#1009672: ITP: kfilt -- filter Kubernetes resources

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: kfilt
  Version : 0.0.7
  Upstream Author : Ryan Eschinger
* URL : https://github.com/ryane/kfilt
* License : Apache-2
  Programming Lang: golang
  Description : filter Kubernetes resources

 kfilt is a tool that lets you filter specific resources from a stream
 of Kubernetes YAML manifests. It can read manifests from a file, URL,
 or from stdin.

 kfilt was primarily created to assist developers who are creating Helm
 charts or Kustomize bases. Often, when making changes, it is helpful to
 narrow down focus to a specific resource or set of resources in the
 output. Without kfilt, you might redirect output to a file for
 inspection in your text editor or to write complicated grep commands.
 kfilt makes it easy to filter the output to see just the resources you
 are currently interested in. Or, to exclude specific resources.

 You can also use kfilt to selectively apply (or delete) resources with
 kubectl.


This package will be maintained under go team.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1009671: ITP: python3-parsimonious -- fastest pure-Python PEG parser

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python3-parsimonious
  Version : 0.9.0
  Upstream Author : Name  Erik Rose 
* URL : https://github.com/erikrose/parsimonious
* License : MIT/X
  Programming Lang: Python
  Description : fastest pure-Python PEG parser

visa ser o analisador de lookahead arbitrário mais rápido escrito
em Python puro - e o mais utilizável.
.
based on parsing expression grammars (PEGs), which means it is fed
with a simplified type of EBNF notation.
.
was designed to undergird a MediaWiki parser that wouldn't take 5
seconds or a GB of RAM to do one page, but it's applicable to all
sorts of languages.

Bug#1009670: installation-reports: Mostly working installation on rockpro64

[Vagrant Cascadian]

On 2022-04-13, Vagrant Cascadian wrote:
> I will admit I used a tained image that added a couple modules for
> HDMI output on another platform (rock64); I'll check without the extra
> modules and report back if they're needed.

Grahpical installer seems to work out of the box on rockpro64, yay!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009670: installation-reports: Mostly working installation on rockpro64

[Vagrant Cascadian]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: vagr...@debian.org

Boot method: microSD media
Image version: 
https://d-i.debian.org/daily-images/arm64/20220413-02:17/netboot/gtk/SD-card-images/
Date: 2022-04-13 ~2:00:00 UTC

Machine: Pine64 Rockpro64 RK3399
Partitions:
Filesystem  Type 1K-blocksUsed Available Use% Mounted on
udevdevtmpfs   1925472   0   1925472   0% /dev
tmpfs   tmpfs   395808 944394864   1% /run
/dev/mapper/rkp64a-rewt ext4   4721184 1222728   3237952  28% /
tmpfs   tmpfs  1979032   0   1979032   0% /dev/shm
tmpfs   tmpfs 5120   0  5120   0% /run/lock
/dev/sda5   ext4447306   65659353129  16% /boot
tmpfs   tmpfs   395804   0395804   0% /run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

This wasn't *too* easy, but not too bad either.

The initial boot failed because I was unable to change the partition
type to be bootable, and there is another OS install on this disk. I
tried unmarking the bootable partition of the other install but upon
selecting it, nothing changed. Same for trying to mark the partition I
wanted it to boot from as bootable.

My guess is this is because with GPT partition tables bootable is not
a flag but a partition type?

I worked around this by manually adjusting the partition table to
change the partition types for the two partitions to use the "EFI
System" partition that u-boot, for better or worse, uses as a flag to
mark the partition as bootable.

The daily images use u-boot 2022.04+dfsg-2, which supports booting
from devices on a PCIe sata card for rockpro64, although not all sata
cards work, apparently. With older versions of u-boot (or if you have
an unlucky pick of sata cards) you would have to put /boot on a
microSD or eMMC device.


I will admit I used a tained image that added a couple modules for
HDMI output on another platform (rock64); I'll check without the extra
modules and report back if they're needed.


live well,
  vagrant


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220413-02:01:57"
X_INSTALLATION_MEDIUM=netboot-gtk

==
Installer hardware-summary:
==
uname -a: Linux rkp64w 5.16.0-6-arm64 #1 SMP Debian 5.16.18-1 (2022-03-29) 
aarch64 GNU/Linux
lspci -knn: 00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd 
RK3399 PCI Express Root Port [1d87:0100]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 01:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 
Serial ATA Controller [1b21:0612] (rev 02)
lspci -knn: Subsystem: ASMedia Technology Inc. Device [1b21:1060]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.16.0-6-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.16.0-6-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.16.0-6-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.16.0-6-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 02: Generic USB Hub [04fe:0008]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Chicony
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Drive

Bug#1009240: esys-particle: diff for NMU version 2.3.5+dfsg2-4.1

[Stefano Rivera]

Control: tags 1009240 + patch
Control: tags 1009240 + pending

Dear maintainer,

I've prepared an NMU for esys-particle (versioned as 2.3.5+dfsg2-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru esys-particle-2.3.5+dfsg2/debian/changelog esys-particle-2.3.5+dfsg2/debian/changelog
--- esys-particle-2.3.5+dfsg2/debian/changelog	2022-01-17 11:16:32.0 -0400
+++ esys-particle-2.3.5+dfsg2/debian/changelog	2022-04-13 21:24:02.0 -0400
@@ -1,3 +1,11 @@
+esys-particle (2.3.5+dfsg2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Don't call Py_Initialize() before Py_Main(), fixing sys.path on
+Python 3.10. (Closes: #1009240)
+
+ -- Stefano Rivera   Wed, 13 Apr 2022 21:24:02 -0400
+
 esys-particle (2.3.5+dfsg2-4) unstable; urgency=medium
 
   * Team upload
diff -Nru esys-particle-2.3.5+dfsg2/debian/patches/python-3.10-pyinitialize.patch esys-particle-2.3.5+dfsg2/debian/patches/python-3.10-pyinitialize.patch
--- esys-particle-2.3.5+dfsg2/debian/patches/python-3.10-pyinitialize.patch	1969-12-31 20:00:00.0 -0400
+++ esys-particle-2.3.5+dfsg2/debian/patches/python-3.10-pyinitialize.patch	2022-04-13 21:23:18.0 -0400
@@ -0,0 +1,18 @@
+Description: Don't call Py_Initialize before Py_Main
+ This is unsupported, and breaks sys.path on Python 3.10.
+ Since https://github.com/python/cpython/commit/af1d64d9f7a7cf673279725fdbaf4adcca51d41f
+ See: https://bugs.python.org/issue36204
+ See: https://bugs.python.org/issue34008
+Bug-Debian: https://bugs.debian.org/1009240
+Author: Stefano Rivera 
+
+--- a/Python/MpiPython/MpiPythonMain.cpp
 b/Python/MpiPython/MpiPythonMain.cpp
+@@ -48,7 +48,6 @@
+ if(myrank==0){// if rank==0 --> master
+   // start python
+   // std::cout << "master start\n";
+-  Py_Initialize();
+   
+ #if PY_VERSION_HEX >= 0x0300
+   wchar_t** wargv = new wchar_t*[argc+1];
diff -Nru esys-particle-2.3.5+dfsg2/debian/patches/series esys-particle-2.3.5+dfsg2/debian/patches/series
--- esys-particle-2.3.5+dfsg2/debian/patches/series	2022-01-17 11:16:10.0 -0400
+++ esys-particle-2.3.5+dfsg2/debian/patches/series	2022-04-13 21:21:00.0 -0400
@@ -7,3 +7,4 @@
 07_fix_FTBFS_perl5.26.patch
 09_fix_tk9.patch
 support-python-3.10.patch
+python-3.10-pyinitialize.patch

Bug#978748: libboost-dev: Boost 1.75

[strager]

Is there anything I can do to help get a newer version of Boost into
the Debian repository?

On Thu, 31 Dec 2020 14:27:31 +0100 Giovanni Mascellani  wrote:
> Hi,
>
> Il 31/12/20 10:20, Olaf van der Spek ha scritto:
> > Could Boost 1.75 be packaged?
>
> Eventually it will be (either 1.75 or a newer version), but I don't know
> when. 1.74 will be in bullseye, there is no point rushing a new
> transition now.
>
> Giovanni.
> --
> Giovanni Mascellani 
>
>

Bug#1009669: foliate: Can not open file, "No response" error

[Brian Vaughan]

Package: foliate
Version: 2.6.4-1+dfsg1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: bgvaug...@gmail.com

After selecting a file, EPUB or MOBI, there's a spinner displayed, but the file
is never displayed. After closing foliate and reopening it, it shows the
messages, "Could not open file", and "The string did not match the expected
pattern.", followed by a button, "Open Another File...". Opening the same or
another file has the same result.

I believe this is the same as the upstream issue, 'glib2 2.72.0 causes "Empty
response" #878'. glib2 on my system is 2.72.0-1+b1.

https://github.com/johnfactotum/foliate/issues/878


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages foliate depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-webkit2-4.0   2.36.0-3
ii  gjs  1.72.0-2
ii  python3  3.10.4-1

foliate recommends no packages.

foliate suggests no packages.

-- no debconf information

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[zhenwei pi]

Package: util-linux
Version: 2.36.1-7
Severity: wishlist

Dear Maintainer,

util-linux supports two new commands irqtop/lsirq since v2.36.
The related release note: https://lwn.net/Articles/826866/

The irqtop(from util-linux) command has better user experience:
 - aggregate interrupt information seems clear on a morden server(128
   CPUs or more).
 - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
 - specify cpus in list format to monitor.
 - specify output columns to print.

The lsirq command supports:
 - specify output columns to print.
 - sort result.
 - raw/json/KV format to show.

-- System Information:
Debian Release: 11.0
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.0-39-generic (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory

locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages util-linux depends on:
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-7
ii  libc6  2.31-12
ii  libcap-ng0 0.7.9-2.2+b1
ii  libcrypt1  1:4.4.18-4
ii  libmount1  2.36.1-7
ii  libpam0g   1.4.0-7
ii  libselinux13.1-3
ii  libsmartcols1  2.36.1-7
ii  libsystemd0247.3-5
ii  libtinfo6  6.2+20201114-2
ii  libudev1   247.3-5
ii  libuuid1   2.36.1-7
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools  
pn  kbd 
pn  util-linux-locales  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "zh_CN.UTF-8",
LC_MONETARY = "zh_CN.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_ADDRESS = "zh_CN.UTF-8",
LC_TELEPHONE = "zh_CN.UTF-8",
LC_NAME = "zh_CN.UTF-8",
LC_MEASUREMENT = "zh_CN.UTF-8",
LC_IDENTIFICATION = "zh_CN.UTF-8",
LC_NUMERIC = "zh_CN.UTF-8",
LC_PAPER = "zh_CN.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#1009667: rust-heck - new upstream release 0.4

[Ben Westover]

The upgrade to 0.4 would help clap_derive, which I had to patch a little bit 
for heck 0.3 compatibility. It hasn't been uploaded yet, so it would be great 
for me to be able to get rid of that patch before then.

Bug#1009667: rust-heck - new upstream release 0.4

[peter green]

Package: rust-heck

A new version of rust-cbindgen was recently uploaded, with a dependency on heck 
0.4,
debian currently has 0.3. It would almost certainly be possible to patch 
cbindgen
to use heck 0.3 but I'm wondering if it makes more sense to upgrade heck.

The main changes in heck 0.4 are they renamed a bunch of stuff and they made
unicode support optional. I don't think these changes are significant enough
to justify packaging multiple versions of heck in parallel.

I started looking at the reverse dependencies of heck, all of them have fixes
upstream but in one case the upstream fix has not been included in a release
and in other cases the new upstream releases have semver bumps that would
open large dependency cans of worms. So it looks to me like patching is
likely the most reasonable approach in most cases to get the heck transition
to complete in a reasonable time.

rust-heck 0.3 -> 0.4
  rust-enum-as-inner 0.3 -> 0.4
rust-trust-dns-proto no rdeps, already broken, not in testing
  rust-glib-macros fixed upstream, patching ( 
91220bd0f31abe5d8ae3ac35aa4913664637ec83 ) seems like the best approach to 
avoid entangling the heck transition with a gtk stack transition
  rust-gtk3-macros fixed upstream, patching ( 
b74649ac901b284ac619ff40f8a16723fa72f653 ) seems like the best approach to 
avoid entangling the heck transition with a gtk stack transition
  rust-gtk4-macros fixed upstream, patching ( 
d0a6adb7a3ef5acc2d9fce7df8c16770b8a04f0a )seems like the best approach to avoid 
entangling the heck transition with a gtk stack transition
  rust-structopt-derive fixed in upstream git ( 
2736281a647cecb23ae1c17bbaf625b18ebf4b38 ) , but not released, apply as patch.
  rust-strum-macros fixed upstream but updating opens up a dependency can of 
worms, patching ( fb88d04dcfb2eb2ba63c4f6dd924afed96d5b2f7seems ) the most 
sensible approach
  rust-system-deps patching (72af87c58bd92456218d5877eb9513c36810547e )seems 
like the best approach to avoid entangling the heck transition with a gtk stack 
transition
  rust-wasm-bindgen-webidl already broken and not in testing, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007026

Anyone have any comments/objections before I go ahead and start working on this?

Bug#1009666: collectd-core: Please package NUT plugin

[Ian Eure]

Package: collectd-core
Version: 5.12.0-7
Severity: wishlist

Dear Maintainer,

I want to use collectd to monitor my UPS, but I’m not able to, 
since collectd isn’t build with the --enable-nut flag.


Would it be possible to include support for this, either in the 
collectd-core package or a separate collectd-plugin-nut one?


Thanks,

 -- Ian

-- System Information:
Debian Release: 11.3
 APT prefers stable-security
 APT policy: (900, 'stable-security'), (900, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-13-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.utf8), LANGUAGE not set

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

Versions of packages collectd-core depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libcap21:2.44-1
ii  lsb-base   11.1.0

Versions of packages collectd-core recommends:
ii  perl 5.32.1-4+deb11u2
ii  rrdtool  1.7.2-3+b7

Versions of packages collectd-core suggests:
pn  apache2 
pn  apcupsd 
pn  bind9   
pn  ceph
pn  chrony  
pn  collectd-dev
ii  default-jre-headless2:1.11-72
pn  default-mysql-server
pn  gpsd
pn  hddtemp 
pn  httpd-cgi   
ii  intel-cmt-cat   4.1-1
ii  iptables1.8.7-1
pn  ipvsadm 
ii  libatasmart40.19-5
pn  libbson-1.0-0   
ii  libc6   2.31-13+deb11u3
pn  libconfig-general-perl  
ii  libcurl3-gnutls 7.74.0-1.3+deb11u1
ii  libdbi1 0.9.0-6
ii  libesmtp6   1.0.6-4.3
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libglib2.0-02.66.8-1
ii  libgps283.22-4
ii  libgrpc++1  1.30.2-3
ii  libgrpc10   1.30.2-3
ii  libhiredis0.14  0.14.1-1
ii  libhtml-parser-perl 3.75-1+b1
ii  libi2c0 4.2-1+b1
ii  libip4tc2   1.8.7-1
ii  libip6tc2   1.8.7-1
ii  libjansson4 2.13.1-1.1
ii  libldap-2.4-2   2.4.57+dfsg-3
ii  liblua5.3-0 5.3.3-1.1+b1
ii  libmariadb3 1:10.5.15-0+deb11u1
ii  libmemcached11  1.0.18-4.2
ii  libmicrohttpd12 0.9.72-2
ii  libmnl0 1.0.4-3
ii  libmodbus5  3.1.6-2
pn  libmongoc-1.0-0 
ii  libmosquitto1   2.0.11-1
ii  libnotify4  0.7.9-3
ii  libopenipmi02.0.29-0.1+b1
ii  liboping0   1.10.0-4+b1
ii  libowcapi-3.2-4 3.2p4+dfsg1-4+b1
ii  libpcap0.8  1.10.0-2
ii  libperl5.32 5.32.1-4+deb11u2
ii  libpq5  13.5-0+deb11u1
ii  libprotobuf-c1  1.3.3-1+b2
ii  libprotobuf23   3.12.4-1
ii  libpython3.93.9.2-1
ii  libqpid-proton110.22.0-5.1
ii  librabbitmq40.10.0-1
ii  librdkafka1 1.6.0-1
pn  libregexp-common-perl   
ii  libriemann-client0  1.10.4-2+b2
ii  librrd8 1.7.2-3+b7
pn  librrds-perl
ii  librte-eal2120.11.4-2~deb11u1
ii  librte-ethdev21 20.11.4-2~deb11u1
ii  libsensors5 1:3.6.0-7
ii  libsnmp40   5.9+dfsg-3+b1
ii  libssl1.1   1.1.1n-0+deb11u1
ii  libstdc++6  10.2.1-6
ii  libudev1247.3-7
ii  liburi-perl 5.08-1
ii  libvarnishapi2  6.5.1-1+deb11u2
ii  libvirt07.0.0-3
ii  libxenmisc4.14  4.14.4+74-gd7b6b5-1
ii  libxml2 2.9.10+dfsg-6.7+deb11u1
ii  libyajl22.1.0-3
ii  lm-sensors  1:3.6.0-7
pn  mbmon   
pn  memcached   
pn  nginx   
ii  notification-daemon 3.20.0-4
ii  ntp [time-daemon]   1:4.2.8p15+dfsg-1
pn  olsrd   
pn  openvpn 
pn  pdns-server 
pn  postgresql  
pn  redis-server
pn  slapd   
pn  varnish 
pn  zookeeper   

-- Configuration Files:
/etc/collectd/collection.conf [Errno 13] Permission denied: 
'/etc/collectd/collection.conf'


-- debconf information excluded

Bug#1009665: ghostscript: with -dNEWPDF=false, the ToUnicode CMap sometimes has an incorrect mapping

[Vincent Lefevre]

Package: ghostscript
Version: 9.56.0~dfsg-1
Severity: normal
Tags: upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=704681

In some cases, the ToUnicode CMap generated by ps2pdf -dNEWPDF=false
is incorrect. Testcase chartest7.pdf attached.

$ pdftotext chartest7.pdf - | head -n 1
’ê
$ /usr/bin/ps2pdf -dNEWPDF=false out.pdf
$ pdftotext out.pdf - | head -n 1
Šê

Even though upstream does not intend to work on the old PDF interpreter
any longer, the fact that the incorrect mapping does not appear yet with
the new PDF interpreter is just due to some other issues with it.

The chartest7.pdf file has been obtained with pdflatex from

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\pdfglyphtounicode{Scaron}{0160}
\pdfgentounicode=1
\begin{document}
\thispagestyle{empty}
'ê
\end{document}

Note that TeX Live now has

\pdfglyphtounicode{Scaron}{0160}
\pdfgentounicode=1

by default, which makes the bug more visible than before.

This follows bug 995392 against previous ghostscript versions (which
only had the old PDF interpreter).

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 ghostscript depends on:
ii  libc6   2.33-7
ii  libgs9  9.56.0~dfsg-1

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.56.0~dfsg-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


chartest7.pdf
Description: Adobe PDF document

Bug#1009664: gddrescue: Please upgrade gddrescue to 1.26

[Anthony Fok]

Package: gddrescue
Version: 1.23-2+b1
Severity: normal
X-Debbugs-Cc: f...@debian.org

Hi Michael,

Thank you so much for maintaining gddrescue which has helped me rescue
failing disks quite a few times.

GNU ddrescue 1.26 has been released, and it would be really nice if you
could upgrade the Debian packaging from 1.23 to 1.26 at your
convenience.  Here are the links to the release announcements:

* 1.24: https://lists.gnu.org/archive/html/info-gnu/2019-02/msg00012.html
* 1.25: https://lists.gnu.org/archive/html/info-gnu/2020-03/msg2.html
* 1.26: https://lists.gnu.org/archive/html/info-gnu/2022-01/msg00013.html

Changes in version 1.24:

* The new option '--command-mode' has been added. It activates a scripting
  interface similar to the one of ed which reads commands from the standard
  input and executes them, copying parts of the input file on demand.

* Ddrescue now tries to create a backup copy of the mapfile, with the name
  .bak, every time it is going to overwrite a fsynced mapfile.
  On startup, ddrescue verifies that the backup mapfile (if it exists) is
  not a non-regular file, and that its name is not the same as infile or
  outfile.

* It has been documented that when ddrescue finishes, the contents of any
  areas marked as bad-sector remain untouched in the output file.

* The configure script now accepts appending options to CXXFLAGS using the
  syntax 'CXXFLAGS+=OPTIONS'.


Changes in version 1.25:

* Default constructors have been added to classes Block and Sblock.
  (Reported by Rosen Penev).

* A failure in 'make check', happening when testing under a directory
  with spaces in the name, has been fixed. (Reported by David Morrison).

* In rescue mode, any non-finished subsector that is now found during the
  initial read of the mapfile will be joined to its corresponding sector
  (if it is also not finished), marking the whole sector with the less
  processed state, so as to make sure that sub-sector data will not be
  discarded from a successful read during the rescue. (A subsector is
  a block smaller than the sector size). (Reported by David Burton).

* The time needed to write the mapfile is now excluded from the mapfile
  save and sync intervals. (It seems that some mapfiles take 7 seconds
  to write). (Reported by David Burton).

* Ddrescue now extends the output file using 'ftruncate' if it works,
  because it is slightly more efficient.

* Large numbers in messages (like device sizes) are now printed in groups
  of 3 digits separated by underscore '_' characters to make them more
  readable.


Changes in version 1.26:

* While writing the mapfile, ddrescue now checks the return value of each
  call to 'fprintf' to catch any temporary failure of 'fprintf' not
  reported by the system when closing the file. (Hole in mapfile reported
  by Radomír Tomis).

* Domain mapfiles may now contain unordered and overlapping blocks when
  '-L, --loose-domain' is specified as long as no block overlaps with
  other block of different status.
  (Suggested by Gábor Katona and Shaya Potter).

* Ddrescue now shows the file name in all the diagnostics with a file
  involved. (Reported by Radomír Tomis).

* Ddrescue now exits with status 1 on fatal read errors. (Suggested by
  Marco Marques).

  * Empty phases are now completely skipped.

* Ddrescue now scrolls forward after each pass. This keeps on the screen
  the final status of the previous pass, making it easier to estimate the
  amount of work done by the current pass.
  (Based on a suggestion by David Morrison).

* In case of error in a numerical argument to a command line option,
  ddrescue now shows the name of the option and the range of valid values.

* The option synonyms '--*-logfile' and '--pause' have been removed and
  are no longer recognized.

* Ddrescuelog now can convert between mapfiles and bitmaps of blocks
  (big and little endian). The new option '-F, --format' has been added
  to ddrescuelog. It selects the input format for '--create-mapfile',
  or the output format for '--list-blocks'. (Bitmap format proposed by
  Florian Sedivy).

* Option '-d, --delete-if-done' of ddrescuelog no longer returns an error
  if the mapfile is read from standard input. Instead it behaves like
  '-D, --done-status' because there is nothing to delete.

* 'ddrescuelog --show-status' now rounds percentages up to get the sum
  closer to 100%.

* Three missing '#include ' have been added.
  (Reported by Richard Burkert).

  * The description of the algorithm in the manual has been improved.


Many thanks!

Kind regards,

Anthony Fok

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via 

Bug#1009171: closed by Julian Gilbey (Re: Bug#1009171: python3-spyder: Dependency on older python3-spyder-kernels)

[Julian Gilbey]

On Wed, Apr 13, 2022 at 09:58:26PM +0200, Marc Glisse wrote:
> Ah, I failed to notice that spyder had been removed from testing already,
> sorry for the unnecessary report, and thanks a lot for working on the new
> version, which was far from a trivial update from what I can see. It seems
> to be working fine, from 30 seconds of use so far...

Thanks!  It was, indeed, a lot of work!

   Julian

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Control: reopen -1

On 2022-03-31 17:12:16 +0200, Vincent Lefevre wrote:
> [...] It now appears that this remaining issue was related to the
> PDF interpreter, not just the PDF writer. So I'm updating the bug
> title to be less restrictive.

The new PDF interpreter has actually more important issues: the
math symbols do not appear correctly with pdftotext. So one needs
to use the old interpreter with -dNEWPDF=false, which makes the
bug reappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Gabriel Filion]

Hi there,

For what it's worth, upstream puppet does not yet suppport ruby 3.0.

see: https://puppet.com/docs/puppet/7/release_notes_puppet.html

puppet 7 added support for ruby 2.7 but 2.9 and 3.0 were never there 
upstream. I'm guessing they'll bump to 3.x for the puppet 8 cycle only.

Bug#1008977: RFS: unbound/1.15.0-0.1 [NMU] [RC] -- validating, recursive, caching DNS resolver

[Bastian Germann]

Control: severity -1 normal
Control: retitle -1 RFS: unbound/1.15.0-0.1 [NMU] -- validating, recursive, 
caching DNS resolver

Christian,

For NMU sponsoring, please explain how you contacted upstream and how long you have been waiting 
unanswered. Your changes are not only targeted to specific bugs, which is expected for NMUs. As this 
is team maintained, have you tried joining the team?


Thanks,
Bastian

Bug#1009240: esys-particle: autopkgtest regression since rebuild for python3.10 as default

[Stefano Rivera]

I did some digging:

The issue here is that sys.path is not being correctly configured

It is being initialized to:
['', '/tmp/cpython/lib/python310.zip', '/tmp/cpython/lib/python3.10', 
'/tmp/cpython/lib/python3.10/lib-dynload']

not:
['', '/tmp/cpython/lib/python310.zip', '/tmp/cpython/lib/python3.10', 
'/tmp/cpython/lib/python3.10/lib-dynload', 
'/tmp/cpython/lib/python3.10/site-packages']

You can verify this by running:
esysparticle -c 'import sys; print(sys.path)'

More digging showed that it is actually being correctly initialized in
Py_Initialize(), but then re-initialized to be incorrect in Py_Main().

A git bisect got me to
https://github.com/python/cpython/commit/af1d64d9f7a7cf673279725fdbaf4adcca51d41f
as being the commit that made that change.

I haven't got to the bottom of exactly why that reinitialization is
going wrong, but these bugs hint at this code as being unsupported:
https://bugs.python.org/issue36204
https://bugs.python.org/issue34008

The easy answer here is to stop calling Py_Initialize(), as it's not
necessary.

The "right" long-term approach would be to migrate to Py_RunMain().

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1009663: pipewire: Stream properties `lfe-cutoff` and `upmix` don't work.

[Mladen Mijatov]

Package: pipewire
Version: 0.3.49-1
Severity: normal
X-Debbugs-Cc: meaneye@gmail.com

Configuring `lfe-cutoff` and `upmix` in stream properties it's suppose to
generate audio for subwoofer speaker on 5.1 sound card configuration. This
doesn't happen. No matter if configuration is made in
~/.config/pipewire/client.conf or /usr/share/pipewire/client.conf it simply
won't generate LFE channel.


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
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:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  init-system-helpers  1.62
ii  libpipewire-0.3-modules  0.3.49-1
ii  pipewire-bin 0.3.49-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1009662: dd-opentracing-cpp: FTBFS with glibc >= 2.34 (Catch2)

[Steve Langasek]

Package: dd-opentracing-cpp
Version: 1.3.1-1
Severity: serious
Tags: patch experimental
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Stephen,

dd-opentracing-cpp fails to build from source against glibc 2.34 or later
because MINSIGSTKSZ is no longer a compile-time constant:

[...]
In file included from /usr/include/signal.h:328,
 from /<>/3rd_party/include/catch2/catch.hpp:7955,
 from /<>/test/test_main.cpp:2:
/<>/3rd_party/include/catch2/catch.hpp:10735:58: error: call to non
-‘constexpr’ function ‘long int sysconf(int)’
10735 | static constexpr std::size_t sigStackSize = 32768 >= MINSIGSTKSZ ? 
32768 : MINSIGSTKSZ;
  |  ^~~
In file included from /usr/include/x86_64-linux-gnu/bits/sigstksz.h:24,
 from /usr/include/signal.h:328,
 from /<>/3rd_party/include/catch2/catch.hpp:7955,
 from /<>/test/test_main.cpp:2:
/usr/include/unistd.h:640:17: note: ‘long int sysconf(int)’ declared here
  640 | extern long int sysconf (int __name) __THROW;
  | ^~~
In file included from /<>/test/test_main.cpp:2:
/<>/3rd_party/include/catch2/catch.hpp:10794:45: error: size of 
array ‘altStackMem’ is not an integral constant-expression
10794 | char FatalConditionHandler::altStackMem[sigStackSize] = {};
  | ^~~~
make[3]: *** [test/CMakeFiles/catch.dir/build.make:79: 
test/CMakeFiles/catch.dir/test_main.cpp.o] Error 1
[...]

  
(https://launchpad.net/ubuntu/+source/dd-opentracing-cpp/1.3.1-1/+build/22380587)

glibc 2.34 is currently only in experimental in Debian, but this package
will need fixed to be buildable once it reaches unstable.

I've applied the attached patch in Ubuntu to fix this build failure, which
simply consists of vendorizing a new version of the Catch2 header that
includes the upstream fix for this problem.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dd-opentracing-cpp-1.3.1/debian/patches/series 
dd-opentracing-cpp-1.3.1/debian/patches/series
--- dd-opentracing-cpp-1.3.1/debian/patches/series  1969-12-31 
16:00:00.0 -0800
+++ dd-opentracing-cpp-1.3.1/debian/patches/series  2022-04-13 
13:47:02.0 -0700
@@ -0,0 +1 @@
+update-catch2.patch
diff -Nru dd-opentracing-cpp-1.3.1/debian/patches/update-catch2.patch 
dd-opentracing-cpp-1.3.1/debian/patches/update-catch2.patch
--- dd-opentracing-cpp-1.3.1/debian/patches/update-catch2.patch 1969-12-31 
16:00:00.0 -0800
+++ dd-opentracing-cpp-1.3.1/debian/patches/update-catch2.patch 2022-04-13 
13:48:11.0 -0700
@@ -0,0 +1,2725 @@
+Description: import catch2 version 2.13.8 to fix build failure with glibc 2.34
+Author: Steve Langasek 
+Last-Update: 2022-04-13
+Forwarded: no
+
+Index: dd-opentracing-cpp-1.3.1/3rd_party/include/catch2/catch.hpp
+===
+--- dd-opentracing-cpp-1.3.1.orig/3rd_party/include/catch2/catch.hpp
 dd-opentracing-cpp-1.3.1/3rd_party/include/catch2/catch.hpp
+@@ -1,9 +1,9 @@
+ /*
+- *  Catch v2.11.1
+- *  Generated: 2019-12-28 21:22:11.930976
++ *  Catch v2.13.8
++ *  Generated: 2022-01-03 21:20:09.589503
+  *  --
+  *  This file has been merged from multiple headers. Please don't edit it 
directly
+- *  Copyright (c) 2019 Two Blue Cubes Ltd. All rights reserved.
++ *  Copyright (c) 2022 Two Blue Cubes Ltd. All rights reserved.
+  *
+  *  Distributed under the Boost Software License, Version 1.0. (See 
accompanying
+  *  file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+@@ -14,8 +14,8 @@
+ 
+ 
+ #define CATCH_VERSION_MAJOR 2
+-#define CATCH_VERSION_MINOR 11
+-#define CATCH_VERSION_PATCH 1
++#define CATCH_VERSION_MINOR 13
++#define CATCH_VERSION_PATCH 8
+ 
+ #ifdef __clang__
+ #pragma clang system_header
+@@ -66,13 +66,16 @@
+ #if !defined(CATCH_CONFIG_IMPL_ONLY)
+ // start catch_platform.h
+ 
++// See e.g.:
++// 
https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/TargetConditionals.h.auto.html
+ #ifdef __APPLE__
+-# include 
+-# if TARGET_OS_OSX == 1
+-#  define CATCH_PLATFORM_MAC
+-# elif TARGET_OS_IPHONE == 1
+-#  define CATCH_PLATFORM_IPHONE
+-# endif
++#  include 
++#  if (defined(TARGET_OS_OSX) && TARGET_OS_OSX == 1) || \
++  (defined(TARGET_OS_MAC) && TARGET_OS_MAC == 1)
++#define CATCH_PLATFORM_MAC
++#  elif (defined(TARGET_OS_IPHONE) && TARGET_OS_IPHONE == 1)
++#define CATCH_PLATFORM_IPHONE
++#  endif
+ 
+ #elif defined(linux) || defined(__linux) || 

Bug#1009385: communication

[Michael Tokarev]

[Resending whole thing. I think it is is important to have it publicly
available and to reach you, so adding it to the bugreport too.
Apparently team+dns@tracker.d.o isn't working and there's no archives]

I want to follow up on the todays ldns incident.
I think it was quite interesting.

The whole thing of me pushing the 1.7.1-2.1 NMU was not
noticed by the current maintainer of ldns package. I don't
know why, but after uploading to DELAYED/2, I thought I'd
ask Santiago directly, because strangely I did see his
reply to other emails but not to my upload. And indeed,
he replied he didn't receive my nmudiff emails about the
delayed upload.

So next, instead of me ensuring the comminication is working
correctly, I switched to mostly private email exchange between
me and Santiago. We discussed many things, he reviewed my
changes, we discussed possible master branch rewrite (the
top two commits by Robert), I've asked Robert about his
opinion on these 2 commits, -- this all has been done in
private email exchange.  I was wrong here not to add some
Cc to team+dns@ or some bugreport, or anything.

On the contrary, the discussion spinned off the python3.10
ftbfs bug, but I replied to Santiago in private, because
that discussion has nothing to do with that bugreport really.

So initially it was me who made whole thing absolutely
unknown to all the dns team, whole team was absolutely
unaware about the happenings in there.

I apologize for this discussion going on entirely in private.
The problem was not because of my incompetence or me being
unaware, no, *that*'d be understandable. The thing was that
I had this thought many times, I had this feeling every time
I replied, that this whole thing should be made public, but
I didn't do anything with that, -- the usual "I don't have
time right now for this" played its game.

And sure thing, Daniel did the best he thought it is, without
any knowledge about all the happenings behind the scenes.

Hopefully the whole thing is much better now. Yes it required
master branch rewrite, because of *my* NMU which went out of
order. And it was still the same single rewrite after Daniel
changes.

Now, to sum it up: mjt-1.8 branch *was* ready for the upload
(tho I was more comfortable with another 1.7 upload too).
Now I need to review it before it can be merged (now it's
just fast-forward, but please let me one more chance for
mjt-1.8 branch rewrite if I'll find anything in there which
needs a rebase - I'm not asking about master branch rewrite
here).

I kept it separate from master for 2 reasons now: first I
need to review it myself, and second, if by a chance we'll
have to fix the 1.7.1-3 upload, we wont need another rewrite.

[While I experimented with team+dns@tracker.d.o, I also
force-pushed mjt-1.8 branch again, fixing changelog so
it will not include already listed entries, and adding
two more commits to there.  I'm still not entirely sure
what I have in there is what I actually want it to be,
so I still have to re-review my own changes - whenever
they're making sense on top of Daniel's changes. Please
be patient there]

Thank you all for the patience. This was a good lesson for
everyone, I think.

/mjt

Bug#1008426: h2o: diff for NMU version 2.2.5+dfsg2-6.2

[Chris Hofstaedtler]

Hi Anton,

* Anton Gladky  [220412 19:18]:
> thanks a lot for NMU! Feel free to upload immediately,
> but please commit your changes into the git. Thanks!

okay, can/will do. Could you push the tag tags/upstream/2.2.5+dfsg2 into
git?

I have cancelled the NMU in the meantime.

Thanks,
Chris

Bug#999620: pktanon: autopkgtest regression on armhf

[Steve Langasek]

Note that this will consistently fail alignment checks on architectures
which require alignment, because the initial buffer is allocated with
reasonable alignment (32bit) but the ethernet header is 14 bytes long, so
the TCP header fields will always be unaligned within the buffer.

On Wed, Apr 13, 2022 at 01:20:49PM -0700, Steve Langasek wrote:
> Here is a backtrace of the armhf SIGBUS.
> 
> Note that not all ARM implementations return SIGBUS which is probably why
> this was not reproducible on the porter machine.
> 
> # gdb --args pktanon -c /usr/share/doc/pktanon/examples/profiles/profile.xml 
> ./profiles/sample.pcap ./out.pcap
> [...]
> Reading symbols from pktanon...
> Reading symbols from 
> /usr/lib/debug/.build-id/af/1ac53f46ae133c8898358966960cba95ac7a70.debug...
> (gdb) run
> Starting program: /usr/bin/pktanon -c 
> /usr/share/doc/pktanon/examples/profiles/profile.xml ./profiles/sample.pcap 
> ./out.pcap
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> ---
> pktanon --- profile-based traffic anonymization
> ---
> initializing PktAnon,  configuration = 
> /usr/share/doc/pktanon/examples/profiles/profile.xml
> unknown element: pktanon-config: 37
> unknown element: anonymizations: 102
> istream: opened file ./profiles/sample.pcap
> ostream: opened output file ./out.pcap
> initialized
> 
> Program received signal SIGBUS, Bus error.
> pktanon::TcpPacketTransformation::transform (this=, 
> source_buffer=, destination_buffer=0xfffef35a 
> "\212y\262X\335\300l\221", max_packet_length=40) at 
> transformations/TcpPacketTransformation.cpp:88
> 88  hton32 (output_header->ack_num);
> (gdb) bt
> #0  pktanon::TcpPacketTransformation::transform (this=, 
> source_buffer=, 
> destination_buffer=0xfffef35a "\212y\262X\335\300l\221", 
> max_packet_length=40) at transformations/TcpPacketTransformation.cpp:88
> #1  0x0040b77c in pktanon::IPv4PacketTransformation::transform 
> (this=0x4b4eb0, 
> source_buffer=, destination_buffer=0xfffef346 "E", 
> max_packet_length=)
> at transformations/IPv4PacketTransformation.cpp:153
> #2  0x0040af64 in pktanon::EthernetPacketTransformation::transform (
> this=0x4ad780, source_buffer=, 
> destination_buffer=0xfffef338 
> "\376\212\a\213\001\254\303\341\372DI\355\b", max_packet_length=74) at 
> transformations/EthernetPacketTransformation.cpp:53
> #3  0x00416862 in pktanon::transform_packet (stats=..., 
> packet_len=, 
> transformed_packet=0xfffef338 
> "\376\212\a\213\001\254\303\341\372DI\355\b", original_packet=0xfffef438 "", 
> record_header=...) at Utils.h:26
> #4  pktanon::IstreamInput::read_packets (this=0x4b3ce0)
> at IstreamRecordsHandler.cpp:121
> #5  0x00415130 in pktanon::PktAnonRuntime::run () at PktAnonRuntime.cpp:37
> #6  0x00405bfa in main (argc=, argv=)
> at src/Main.cpp:73
> (gdb) 
> 
> So, this is trying to do an hton32() operation on a field that is not 4-byte
> aligned.
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#957892: ucarp: diff for NMU version 1.5.2-2.3

[Guilherme Xavier]

Hi,

Sorry for my mistake, in the previous email sent by me the delay was 2
days and not 22. I had a problem with my keyboard.

Bug#996262: libticables: Patch to add riscv64 support

[Aurelien Jarno]

Hi 

On 2022-04-11 15:56, Ileana Dumitrescu wrote:
> Hi Lionel and Aurelien,
> 
> > ... you should indeed include Aurelien's patch in the Debian package :)
> 
> I just uploaded Aurelien's patch and some other debian package updates to the 
> libticables salsa repo at https://salsa.debian.org/science-team/libticables/. 
> When the next upstream release is ready, I will remove the patch from the 
> debian folder.

Thanks!

> Aurelien, thank you for submitting the patch! Are you able to upload these 
> updates into debian? I do not have debian developer privileges (but am hoping 
> to in the near future!). 

Yes, I can upload a package. Just prepare it on salsa and tell me when
it's ready. I can fetch it from there, build it and upload it.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1008849: shiboken2 - Needs tighter dependency on python3

[Nicholas D Steeves]

Hi Yuri and Kurt,

Kurt, would you please read the following discussion, and comment if
it's possible to generate a tighter Python dependency at build time?

Yuri D'Elia  writes:

> On Tue, Apr 12 2022, Nicholas D Steeves wrote:
>>> This also requires that shiboken2 should be currently rebuilt.
>>>
>>
>> Agreed.
>>
>>> Either the python3 dependency should be tightened, or FORCE_LIMITED_API
>>> should be used.
>>
>> These are not the only available options.  Are you aware of binNMUs?
>>   https://wiki.debian.org/binNMU
>
> I'm using it for development, and not being able to work if the minor
> version changes is a bigger problem than it sounds: I cannot rebuild
> third-party software which is using shiboken/pyside unless I completely
> rebuild pyside in parallel.
>

I understand, and agree that the issue is real, and that a rebuild is
required.  A binNMU is the most expedient solution ;-)  Please read
"What are binNMUs?" at the link provided above...

> I remember I already had this issue with the 3.9 transition.
>

Yes, this is totally normal during transitions, and this is why
transitions are needed.  You can also see proof of past binNMUs here:

  https://snapshot.debian.org/binary/libshiboken2-py3-5.15/

Those "+b" versions are binNMUs.

> IMHO if shiboken2 is tied to the minor version, it should depend on the
> minor version as well so that the whole pyside/shiboken2 so that
> transitions and downstream dependencies will also be handled as part of
> the transitions?
>
> For example, the current situation is probably breaking packages which
> are currently build with shiboken.
>

Kurt, this is the point I'm wondering about, because it would be better
if the transition tracker would alert us of outstanding issues rather
than waiting for someone to report breakage.  If this isn't feasible,
could you document that fact in the source package?

> This makes shiboken2 completely useless if you have more than a one
> minor version of python installed (for example during transition
> periods). shiboken2 will work only for _one_ minor version.
>

This might be by design.  Kurt, do you know?  There's also the question
of if pyside2/shiboken2 is even py3.10-ready (I haven't tested yet).

> I actually don't use shiboken2 _directly_ myself, but is there any real
> drawback to build with FORCE_LIMITED_API ?

As a general principle, I worry that this would either reduce
functionality and/or debugging, or introduce regression potential, so
this is not a change I'm willing to make as a team member and not
as one of the primary maintainers/uploaders of pyside2.  I can however
test py3.10 compatibility and request a binNMU.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#999620: pktanon: autopkgtest regression on armhf

[Steve Langasek]

Here is a backtrace of the armhf SIGBUS.

Note that not all ARM implementations return SIGBUS which is probably why
this was not reproducible on the porter machine.

# gdb --args pktanon -c /usr/share/doc/pktanon/examples/profiles/profile.xml 
./profiles/sample.pcap ./out.pcap
[...]
Reading symbols from pktanon...
Reading symbols from 
/usr/lib/debug/.build-id/af/1ac53f46ae133c8898358966960cba95ac7a70.debug...
(gdb) run
Starting program: /usr/bin/pktanon -c 
/usr/share/doc/pktanon/examples/profiles/profile.xml ./profiles/sample.pcap 
./out.pcap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
---
pktanon --- profile-based traffic anonymization
---
initializing PktAnon,  configuration = 
/usr/share/doc/pktanon/examples/profiles/profile.xml
unknown element: pktanon-config: 37
unknown element: anonymizations: 102
istream: opened file ./profiles/sample.pcap
ostream: opened output file ./out.pcap
initialized

Program received signal SIGBUS, Bus error.
pktanon::TcpPacketTransformation::transform (this=, 
source_buffer=, destination_buffer=0xfffef35a 
"\212y\262X\335\300l\221", max_packet_length=40) at 
transformations/TcpPacketTransformation.cpp:88
88hton32 (output_header->ack_num);
(gdb) bt
#0  pktanon::TcpPacketTransformation::transform (this=, 
source_buffer=, 
destination_buffer=0xfffef35a "\212y\262X\335\300l\221", 
max_packet_length=40) at transformations/TcpPacketTransformation.cpp:88
#1  0x0040b77c in pktanon::IPv4PacketTransformation::transform (this=0x4b4eb0, 
source_buffer=, destination_buffer=0xfffef346 "E", 
max_packet_length=)
at transformations/IPv4PacketTransformation.cpp:153
#2  0x0040af64 in pktanon::EthernetPacketTransformation::transform (
this=0x4ad780, source_buffer=, 
destination_buffer=0xfffef338 "\376\212\a\213\001\254\303\341\372DI\355\b", 
max_packet_length=74) at transformations/EthernetPacketTransformation.cpp:53
#3  0x00416862 in pktanon::transform_packet (stats=..., 
packet_len=, 
transformed_packet=0xfffef338 "\376\212\a\213\001\254\303\341\372DI\355\b", 
original_packet=0xfffef438 "", record_header=...) at Utils.h:26
#4  pktanon::IstreamInput::read_packets (this=0x4b3ce0)
at IstreamRecordsHandler.cpp:121
#5  0x00415130 in pktanon::PktAnonRuntime::run () at PktAnonRuntime.cpp:37
#6  0x00405bfa in main (argc=, argv=)
at src/Main.cpp:73
(gdb) 

So, this is trying to do an hton32() operation on a field that is not 4-byte
aligned.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1001053: also being affected

[Michael Tokarev]

13.04.2022 22:37, Daniel Lakeland wrote:
My wife has a dual mirrored glusterfs file server that is used for central storage of biology research data. They'd been running old versions of 
Debian, until one of them had a hard drive failure. After replacing hardware and installing the latest Debian release, upgrading the other machine, 
and synchronizing the gluster fileserver, now no-one can access the server because they are experiencing something similar to this bug.


We missed a bugfix from upstream samba 4.13.17, this one:

CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch

which smells like this very bug.

Security team imported all security-related patches up to 4.13.16, but
did not include any bugfixes, and this is one of the bugfixes.

From this patch:
 BUG: https://bugzilla.samba.org/show_bug.cgi?id=14922
 Reported-at: https://lists.samba.org/archive/samba/2021-November/238720.html

Please take a look..

I prepared an update for samba in bullseye (it has quite some other
issues too, including a serious data corruption issue which bite
me hard). I *hope* it will fix your issue too, as it includes the
above mentioned change.  I should try to push it to stable-proposed-updates.

And yes it should hopefully be fixed in 4.16 release too, which is
available in unstable.

Thanks!

/mjt

Bug#1009171: closed by Julian Gilbey (Re: Bug#1009171: python3-spyder: Dependency on older python3-spyder-kernels)

[Marc Glisse]

Ah, I failed to notice that spyder had been removed from testing already, 
sorry for the unnecessary report, and thanks a lot for working on the new 
version, which was far from a trivial update from what I can see. It seems 
to be working fine, from 30 seconds of use so far...


--
Marc Glisse

Bug#1009320: FW issue

[mh]

It seems 5.17.x has problems with the respective FW (no problems with
prior kernels)

dmesg output after trying to load list of broadcasters
*
[ 6801.250773] si2168 2-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware
version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs
Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue
without a firmware.
**

Greetings

MH

Bug#957892: ucarp: diff for NMU version 1.5.2-2.3

[guilherme.lnx]

Package: ucarp
Version: 1.5.2-2.2
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ucarp (versioned as 1.5.2-2.3) and
uploaded it to DELAYED/22. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u ucarp-1.5.2/debian/changelog ucarp-1.5.2/debian/changelog
--- ucarp-1.5.2/debian/changelog
+++ ucarp-1.5.2/debian/changelog
@@ -1,3 +1,12 @@
+ucarp (1.5.2-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Added patch to fix a ftbfs with GCC-10. Thanks to Reiner Herrmann
+. (Closes: #957892)
+  * Bumped debhelper compat to 7. (Closes: #965852)
+
+ -- Guilherme de Paula Xavier Segundo   Wed, 13 Apr 2022 14:32:50 -0300
+
 ucarp (1.5.2-2.2) unstable; urgency=high
 
   * Non-maintainer upload.

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

BTW, Daniel, please re-tag 1.7.1-3 - this is what's at the tip of master now.
I hope anyway :)

Thanks,

/mjt

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

Fixed my branch on the ldns repo, rebasing it on top of now-okay master.
If we ever need one more 1.7 release it will be easier to rebase now with
the conflicts resolved.

I have to review my branch again, I think something might not be right
there after the rebase on top of dkg's changes.  I will do this tomorrow.

Please don't rush it the next time. People were discussing things for quite
some days already, and you aren't even an uploader. Just don't do that again.

There's no harm done, we are all people and we all do mistakes.  I did it
too, by doing an NMU without the 2 commits which were pending in master.

Thanks,

/mjt

Bug#1001053: also being affected

[Daniel Lakeland]

My wife has a dual mirrored glusterfs file server that is used for 
central storage of biology research data. They'd been running old 
versions of Debian, until one of them had a hard drive failure. After 
replacing hardware and installing the latest Debian release, upgrading 
the other machine, and synchronizing the gluster fileserver, now no-one 
can access the server because they are experiencing something similar to 
this bug.


She's running a vanilla old school OpenLDAP/Mit Krb5 system as described.

Here are logs with level 3 from an attempted connection:

[2022/04/12 16:01:14.492911,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
  fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.493014,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
  ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.494598,  3] 
../../source3/smbd/negprot.c:776(reply_negprot)

  Selected protocol SMB 2.???
[2022/04/12 16:01:14.496032,  3] 
../../source3/smbd/smb2_negprot.c:293(smbd_smb2_request_process_negprot)

  Selected protocol SMB3_02
[2022/04/12 16:01:14.496813,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
  fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.496887,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
  ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.646176,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
  fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.646273,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
  ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.648899,  2] 
../../auth/kerberos/gssapi_pac.c:168(gssapi_obtain_pac_blob)
  obtaining PAC via GSSAPI gss_inquire_sec_context_by_oid (Heimdal OID) 
failed:  Miscellaneous failure (see text): Ticket have not authorization 
data of type 128
[2022/04/12 16:01:14.648992,  3] 
../../auth/gensec/gensec_util.c:73(gensec_generate_session_info_pac)
  gensec_generate_session_info_pac: Unable to find PAC for 
fmari...@marianilab.net, resorting to local user lookup
[2022/04/12 16:01:14.649062,  3] 
../../source3/auth/user_krb5.c:50(get_user_from_kerberos_info)

  Kerberos ticket principal name is [fmari...@marianilab.net]
[2022/04/12 16:01:14.658003,  3] 
../../source3/auth/user_krb5.c:123(get_user_from_kerberos_info)
  get_user_from_kerberos_info: Username MARIANILAB.NET\fmariani is 
invalid on this system
[2022/04/12 16:01:14.658102,  3] 
../../source3/auth/auth_generic.c:222(auth3_generate_session_info_pac)
  auth3_generate_session_info_pac: Failed to map kerberos principal to 
system user (NT_STATUS_LOGON_FAILURE)
[2022/04/12 16:01:14.658254,  3] 
../../source3/smbd/smb2_server.c:3861(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] 
status[NT_STATUS_ACCESS_DENIED] || at 
../../source3/smbd/smb2_sesssetup.c:146



I'm not sure if this is the same bug, or a related bug.


The version installed is as follows:

root@manticore:/var/log/samba# apt policy samba
samba:
  Installed: 2:4.13.14+dfsg-1+b2
  Candidate: 2:4.13.14+dfsg-1+b2
  Version table:
 *** 2:4.13.14+dfsg-1+b2 500
    500 http://deb.debian.org/debian testing/main amd64 Packages
    100 /var/lib/dpkg/status
 2:4.13.13+dfsg-1~deb11u3 500
    500 http://deb.debian.org/debian stable/main amd64 Packages


It also happened under the 4.13.13+dfsg-1~deb11u3 version, I upgraded to 
the testing version in hopes it might have been fixed, but isn't.


Is this the same bug, or a different bug that needs a different fix?

Bug#1009467: [Bioconductor/Biostrings] S.h seems to be deprecated (Issue #66)

[Andreas Tille]

Hi Hervé,

Am Wed, Apr 13, 2022 at 09:46:59AM -0700 schrieb Hervé Pagès:
> @tillea And most importantly, it seems that Debian is building the wrong 
> version of Bioconductor. The `S.h` file was removed from R 4.2 and they are 
> reporting a bug for **Biostrings** 2.62.0, which belongs to Bioconductor 3.14 
> (the current release). BioC 3.14 should only be used with R 4.1: it has been 
> expressly designed and tested against this version of R.

Thanks a lot for this hint.  The R-pkg team is always heading for the latest 
stable release of any R / BioC package.  The maintainer of r-core obviously 
does the same but without any warning about bumping to a potentially 
incompatible R version.  (Debian has the distribution "experimental" for this 
kind of migrations but it was not used unfortunately.)
 
> If you are using R 4.2, you should build Bioconductor 3.15, which is still in 
> development and [will be released on April 
> 27](https://bioconductor.org/developers/release-schedule/). **Biostrings** is 
> currently at version 2.63.3. This version belongs to BioC 3.15 and works with 
> R 4.2.

I'm afraid we simply need to wait for Bioconductor 3.15 in this case since 
there are more Bioconductor packages with this issue and trying to patch all 
these and assuming that everything will work as expected is probably nanaive.  
This will cause some noise amongst all Bioconductor packages which will removed 
from the testing distribution.  Users of Debian stable will not be affected.

Kind regards, Andreas.

Bug#1009661: phosh: gnome-control-center 42 is in unstable

[Jeremy Bicha]

Source: phish
Version: 0.17.0-1
X-Debbugs-CC: a...@sigxcpu.org

gnome-control-center 42 was just uploaded to unstable.
You can revert 
https://salsa.debian.org/DebianOnMobile-team/phosh/-/commit/b5e2f983d

Thank you,
Jeremy Bicha

Bug#1009660: gnome-contacts: 42 is incompatible with evolution-ews

[Jeremy Bicha]

Source: gnome-contacts
Version: 42.0-1
Severity: serious
Control: affects -1 src:evolution-ews
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/222

gnome-contacts 42 won't start if evolution-ews is installed.

Thank you,
Jeremy Bicha

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

Okay guys.

I thought about this a bit more.

One wrong action by one developer does not make the environment
unhealthy.

I fixed the mess done to the master branch.

I think - provided this wont happen again - it's okay to work
on this to fix the rest of the mess done.

I'm doing this right now.

Thanks,

/mjt

Bug#1008818: needrestart: creates root-owned .rpmdb in non-root user $HOME, possibly corrupting existing one

[Thorsten Glaser]

Patrick Matthäi dixit:

> But how did it happened, that .rpmdb is owned by root in your own user
> directory?

rpm is installed, I run sudo apt-get something.

> Same in my test, if I use $ sudo needrestart => .rpmdb of ~root/ is used

Hmm.

Maybe !env_reset in sudoers would do this…

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#1008849: shiboken2 - Needs tighter dependency on python3

[Yuri D'Elia]

On Tue, Apr 12 2022, Nicholas D Steeves wrote:
>> This also requires that shiboken2 should be currently rebuilt.
>>
>
> Agreed.
>
>> Either the python3 dependency should be tightened, or FORCE_LIMITED_API
>> should be used.
>
> These are not the only available options.  Are you aware of binNMUs?
>   https://wiki.debian.org/binNMU

I'm using it for development, and not being able to work if the minor
version changes is a bigger problem than it sounds: I cannot rebuild
third-party software which is using shiboken/pyside unless I completely
rebuild pyside in parallel.

I remember I already had this issue with the 3.9 transition.

IMHO if shiboken2 is tied to the minor version, it should depend on the
minor version as well so that the whole pyside/shiboken2 so that
transitions and downstream dependencies will also be handled as part of
the transitions?

For example, the current situation is probably breaking packages which
are currently build with shiboken.

This makes shiboken2 completely useless if you have more than a one
minor version of python installed (for example during transition
periods). shiboken2 will work only for _one_ minor version.

I actually don't use shiboken2 _directly_ myself, but is there any real
drawback to build with FORCE_LIMITED_API ?

Bug#170850: opportunity

[Allen S]

Hello,

I lead family investment vehicles who want to invest a proportion of their 
funds with a trust party .

Please if you are interested in discussing investment in your sector?

Please email, or simply write to me here. I value promptness and will make 
every attempt to respond within a short time.

Thank you.
Allen S.

Bug#277964: opportunity

[Allen S]

Hello,

I lead family investment vehicles who want to invest a proportion of their 
funds with a trust party .

Please if you are interested in discussing investment in your sector?

Please email, or simply write to me here. I value promptness and will make 
every attempt to respond within a short time.

Thank you.
Allen S.

Bug#989660: Backport the fix to bullseye-updates

[Julian Gilbey]

On Wed, Mar 02, 2022 at 02:37:20PM +0100, Amr Ibrahim wrote:
> Hello,
> 
> Is there any hope to backport the fix to bullseye-updates? This bug causes
> the code to be corrupted every time it's saved and autoformat is turned on.
> 
> Best,
> Amr

Hello Amr,

I'm sorry, I seem to have missed this bug report.  I have prepared a
backport for bullseye and submitted a bug to release.debian.org
requesting that it be allowed in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009659

Best wishes,

   Julian

Bug#1009659: bullseye-pu: package spyder/4.2.1+dfsg1-3

[Julian Gilbey]

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

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
(Explain what the reason for the (old-)stable update is. I.e.
what is the bug, when was it introduced, is this a regression
with respect to the previous (old-)stable.)

The bug is reported in https://bugs.debian.org/989660
I didn't spot it at the time because I'm only an uploader, not the
named maintainer, and had forgotten to check the BTS.  Sorry about
that.  The bug was present in version 4.2.1 of Spyder, but was fixed
by upstream in version 4.2.2.

The bug means that in some cases when the black code formatter is
used, the code is modified before being saved (rather than just being
reformatted).  This is likely to cause bugs in the user's code.

[ Impact ]
(What is the impact for the user if the update isn't approved?)

As noted above, this might silently corrupt code that the user is
editing.

[ Tests ]
(What automated or manual tests cover the affected code?)

Unfortunately there are no tests in the stable version of this
package.  (This has been rectified in unstable.)

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, alternatives available.)

This patch is moderately complex; it appears to fix the issue and it
was approved by the core Spyder maintainer, who is very sharp-eyed.
It is also present in the current version of Spyder (uploaded to
unstable within the last few days).  There are no alternatives I am
aware of.

[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
(Explain *all* the changes)

Applying the upstream patch is the only change made.

[ Other info ]
(Anything else the release team should know.)

I have not yet uploaded it to bullseye; I await your instructions.

Best wishes,

   Julian
diff -Nru spyder-4.2.1+dfsg1/debian/changelog 
spyder-4.2.1+dfsg1/debian/changelog
--- spyder-4.2.1+dfsg1/debian/changelog 2021-02-21 09:28:17.0 +
+++ spyder-4.2.1+dfsg1/debian/changelog 2022-04-13 19:05:26.0 +0100
@@ -1,3 +1,9 @@
+spyder (4.2.1+dfsg1-3+deb11u1) bullseye; urgency=medium
+
+  * Fix duplicate-code-on-save bug (closes: #989660)
+
+ -- Julian Gilbey   Wed, 13 Apr 2022 19:05:26 +0100
+
 spyder (4.2.1+dfsg1-3) unstable; urgency=medium
 
   * Missed one dependency (python3-setuptools) in the last upload, and
diff -Nru 
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
 
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
--- 
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
   1970-01-01 01:00:00.0 +0100
+++ 
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
   2022-04-13 19:05:26.0 +0100
@@ -0,0 +1,183 @@
+From: Edgar Andrés Margffoy Tuay 
+Subject: Prevent double saving when running a file
+  This patch has had the line-endings converted to make it compatible
+Origin: upstream, https://github.com/spyder-ide/spyder/pull/14759
+Applied-Upstream: 
https://github.com/spyder-ide/spyder/commit/9325d0d7be1a88602b8092d35be309edc876aa38
+Bug: https://github.com/spyder-ide/spyder/issues/14653
+Bug-Debian: http://bugs.debian.org/989660
+Last-Update: 2022-04-13
+
+---
+ spyder/plugins/editor/plugin.py | 130 
+ spyder/plugins/editor/widgets/editor.py |   4 +-
+ 2 files changed, 69 insertions(+), 65 deletions(-)
+
+diff --git a/spyder/plugins/editor/plugin.py b/spyder/plugins/editor/plugin.py
+index 1faec3c82..8034714a0 100644
+--- a/spyder/plugins/editor/plugin.py
 b/spyder/plugins/editor/plugin.py
+@@ -2567,72 +2567,72 @@ def edit_run_configurations(self):
+ def run_file(self, debug=False):
+ """Run script inside current interpreter or in a new one"""
+ editorstack = self.get_current_editorstack()
+-if editorstack.save(save_new_files=False):
+-editor = self.get_current_editor()
+-fname = osp.abspath(self.get_current_filename())
+-
+-# Get fname's dirname before we escape the single and double
+-# quotes. Fixes spyder-ide/spyder#6771.
+-dirname = osp.dirname(fname)
+ 
+-# Escape single and double quotes in fname and dirname.
+-# Fixes spyder-ide/spyder#2158.
+-fname = fname.replace("'", r"\'").replace('"', r'\"')
+-dirname = dirname.replace("'", r"\'").replace('"', r'\"')
++editor = self.get_current_editor()
++fname = osp.abspath(self.get_current_filename())
+ 
+-runconf = get_run_configuration(fname)
+-if runconf is None:
+-dialog = 

Bug#950404: fixed in ndpi 4.2-1

[Gianfranco Costamagna]

well, this bug was not really fixed, but the package is now removed in s390x, 
so not a real issue anymore.

G.

On Wed, 13 Apr 2022 18:00:10 + Debian FTP Masters 
 wrote:

Source: ndpi
Source-Version: 4.2-1
Done: Gianfranco Costamagna 

We believe that the bug you reported is fixed in the latest version of
ndpi, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 950...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gianfranco Costamagna  (supplier of updated ndpi 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 Apr 2022 17:37:09 +0200
Source: ndpi
Binary: libndpi-bin libndpi-bin-dbgsym libndpi-dev libndpi-wireshark libndpi4.2 
libndpi4.2-dbgsym
Architecture: source amd64
Version: 4.2-1
Distribution: unstable
Urgency: medium
Maintainer: Ludovico Cavedon 
Changed-By: Gianfranco Costamagna 
Description:
 libndpi-bin - extensible deep packet inspection library - ndpiReader
 libndpi-dev - extensible deep packet inspection library - development files
 libndpi-wireshark - extensible deep packet inspection library - wireshark 
dissector
 libndpi4.2 - extensible deep packet inspection library - shared library
Closes: 950404 1003311
Changes:
 ndpi (4.2-1) unstable; urgency=medium
 .
   * New upstream version 4.2 (Closes: #950404)
   * Uncomment commented tests, lets see how they perform on different archs.
   * Update library soname from 4.0 to 4.2
   * Drop docs file, removed
   * Add clean target to make subsequent builds succeed
   * Add libroaring-dev dependency (commented for now since it FTBFS on s390x)
   * Refresh patches and drop patches now upstream
   * Update copyright file and years
   * debian/patches/cross.patch: fix cross building issue
 - fix FTCBFS (Closes: #1003311)
   * Fix FTCFBS: Don't configure during autogen.sh. (Closes: #1003311)
   * Refresh symbols
Checksums-Sha1:
 6b3bfac3cc8acbef58ace41afc9a0c14ca533cda 2105 ndpi_4.2-1.dsc
 45baf86a439d7d8ad5c340d2769504cfcbec3629 126559327 ndpi_4.2.orig.tar.gz

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

13.04.2022 21:19, Daniel Kahn Gillmor wrote:
..

reviewed and i'll push that to salsa as a "debian/experimental" branch
later today, if either of you want to take a look at what i'm
considering for release.


The whole thing was ready, polished, everything addressed.
If you wanted another 1.7.1 upload that's fine, just add
one more commit after my nmu. It was not done in the master
branch for a very good reason.

Please feel free to use any of my changes you like.
Please don't add me to uploaders.

This is not how I think package maintenance should be done.
I don't want to work in such an unhealthy environment.

Thanks,

/mjt

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

13.04.2022 21:29, Michael Tokarev wrote:


The only prob is that the master branch on the ldns repository is
seriously messed up.


Also you've made similar commits as I did, but in an incomplete way
(like the watch file update).

Thanks,

/mjt

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

13.04.2022 21:19, Daniel Kahn Gillmor wrote:

Hi Michael and Santiago--

I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385.  I'm
reviewing Michael's changes for 1.8.1, and they're looking good to me.
Thank you for all that work, Michael!  I think we should consider
uploading 1.8.1 into experimental while we wait for 1.7.1-3 to propagate
to testing.


I don't see a reason to use experimental here, since ldns is not a very
popular package, it wont do much good in experimental.

The only prob is that the master branch on the ldns repository is
seriously messed up.

It was for a reason I asked how to resolve this situation.
You made it significantly worse.

/mjt

Bug#1002508: readline: Please provide a udeb

[Samuel Thibault]

Hello,

NEW was processed quickly :)

I have uploaded it to unstable.

Samuel

Samuel Thibault, le dim. 03 avril 2022 16:58:59 +0200, a ecrit:
> I have uploaded the attached changes to DELAYED/10 for experimental so
> its NEW processing doesn't interfere with maintenance.
> 
> Samuel
> 
> Samuel Thibault, le ven. 11 févr. 2022 02:01:45 +0100, a ecrit:
> > Hello,
> > 
> > Is there any news on this?  Perhaps I can just NMU?
> > 
> > Samuel
> > 
> > Samuel Thibault, le sam. 08 janv. 2022 18:21:28 +0100, a ecrit:
> > > Hello,
> > > 
> > > I see that a newer upload of readline was done but without the proposed
> > > patch. Is there any problem with it? (attached here again)
> > > 
> > > Having readline available would really make the installer a *lot* easier
> > > to handle for blind users.
> > > 
> > > Samuel
> > > 
> > > Samuel Thibault, le jeu. 23 déc. 2021 15:31:17 +0100, a ecrit:
> > > > So as to provide better support for the text installer for speakup-based
> > > > accessibility, we need libreadline in d-i. Here is a patch to add the
> > > > udeb build, could you apply it?
> > > > 
> > > > Thanks,
> > > > Samuel
> > 
> > > --- debian/control.original   2021-12-23 14:14:29.494489058 +0100
> > > +++ debian/control2021-12-23 15:03:01.596025090 +0100
> > > @@ -23,6 +23,21 @@
> > >   The GNU history library provides a consistent user interface for
> > >   recalling lines of previously typed input.
> > >  
> > > +Package: libreadline8-udeb
> > > +Architecture: any
> > > +Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
> > > +Pre-Depends: ${misc:Pre-Depends}
> > > +Package-Type: udeb
> > > +Build-Profiles: 
> > > +Section: debian-installer
> > > +Description: GNU readline and history libraries, run-time libraries (d-i)
> > > + The GNU readline library aids in the consistency of user interface
> > > + across discrete programs that need to provide a command line
> > > + interface.
> > > + .
> > > + The GNU history library provides a consistent user interface for
> > > + recalling lines of previously typed input.
> > > +
> > >  Package: lib64readline8
> > >  Architecture: i386 powerpc s390 sparc
> > >  Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
> > > @@ -47,6 +62,21 @@
> > >   The GNU readline library aids in the consistency of user interface
> > >   across discrete programs that need to provide a command line
> > >   interface.
> > > + .
> > > + The GNU history library provides a consistent user interface for
> > > + recalling lines of previously typed input.
> > > +
> > > +Package: readline-common-udeb
> > > +Architecture: all
> > > +Multi-Arch: foreign
> > > +Depends: ${misc:Depends}
> > > +Package-Type: udeb
> > > +Build-Profiles: 
> > > +Section: debian-installer
> > > +Description: GNU readline and history libraries, common files (d-i)
> > > + The GNU readline library aids in the consistency of user interface
> > > + across discrete programs that need to provide a command line
> > > + interface.
> > >   .
> > >   The GNU history library provides a consistent user interface for
> > >   recalling lines of previously typed input.
> > > --- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
> > > +++ debian/rules  2021-12-23 15:08:20.460279596 +0100
> > > @@ -17,6 +17,10 @@
> > >  CROSS=gcc
> > >  endif
> > >  
> > > +ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
> > > +  buildudeb = yes
> > > +endif
> > > +
> > >  ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
> > >build64 = yes
> > >CC64 = $(CROSS) -m64
> > > @@ -69,9 +73,11 @@
> > >  SHELL= bash
> > >  
> > >  p_rl = libreadline$(soversion)
> > > +p_rlu= libreadline$(soversion)-udeb
> > >  p_rl32   = lib32readline$(soversion)
> > >  p_rl64   = lib64readline$(soversion)
> > >  p_comm   = readline-common
> > > +p_commu  = readline-common-udeb
> > >  p_rld= libreadline-dev
> > >  p_rld32  = lib32readline-dev
> > >  p_rld64  = lib64readline-dev
> > > @@ -79,12 +85,15 @@
> > >  p_rlfe   = rlfe
> > >  
> > >  d= debian/tmp
> > > +du   = debian/tmp-udeb
> > >  d32  = debian/tmp32
> > >  d64  = debian/tmp64
> > >  d_rl = debian/$(p_rl)
> > > +d_rlu= debian/$(p_rlu)
> > >  d_rl32   = debian/$(p_rl32)
> > >  d_rl64   = debian/$(p_rl64)
> > >  d_comm   = debian/$(p_comm)
> > > +d_commu  = debian/$(p_commu)
> > >  d_rld= debian/$(p_rld)
> > >  d_rld32  = debian/$(p_rld32)
> > >  d_rld64  = debian/$(p_rld64)
> > > @@ -93,6 +102,7 @@
> > >  
> > >  srcdir   = $(CURDIR)
> > >  builddir = $(CURDIR)/build
> > > +builddiru= $(CURDIR)/buildudeb
> > >  builddir32   = $(CURDIR)/build32
> > >  builddir64   = $(CURDIR)/build64
> > >  
> > > @@ -111,6 +121,16 @@
> > >   --host=$(DEB_HOST_GNU_TYPE) \
> > >   --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> > >  
> > > +ifneq ($(buildudeb),)
> > > + rm -rf $(builddiru)
> > > + mkdir $(builddiru)
> > > + cd $(builddiru) && \
> > > +   CFLAGS="$(CFLAGS) -Os" 

Bug#1009657: mysql-workbench: not installable under sid

[Sicelo]

Package: mysql-workbench
Version: 8.0.26+dfsg-1+b1
Severity: serious

Attempting to install mysql-workbench under sid fails with the following
output:

sicelo@tpt440p:~$  sudo apt install mysql-workbench
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mysql-workbench : Depends: libgdal29 (>= 3.3.0) but it is not installable
   Depends: python3 (< 3.10) but 3.10.4-1 is to be installed
   Recommends: mysql-utilities but it is not installable
E: Unable to correct problems, you have held broken packages.



Further command output that may be relevant follows:



sicelo@tpt440p:~$  apt-cache policy mysql-workbench libgdal29 mysql-utilities
mysql-workbench:
  Installed: (none)
  Candidate: 8.0.26+dfsg-1+b1
  Version table:
 8.0.26+dfsg-1+b1 500
500 http://ftp.nl.debian.org/debian sid/main amd64 Packages
libgdal29:
  Installed: (none)
  Candidate: (none)
  Version table:
mysql-utilities:
  Installed: (none)
  Candidate: (none)
  Version table:

sicelo@tpt440p:~$  cat /etc/apt/sources.list
deb http://ftp.nl.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.nl.debian.org/debian/ sid main non-free contrib

deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free
deb-src http://security.debian.org/debian-security bullseye-security main 
contrib non-free


Please feel free to request more information as required.

Thank you

Bug#1009656: reportbug: with bullseye-pu, claims "This package doesn't appear to exist"

[Julian Gilbey]

Package: reportbug
Version: 11.4.1
Severity: normal

I just had the following interaction with reportbug:

-
erdos:~ $ reportbug release.debian.org
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Julian Gilbey ' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to you, or
you are trying to report a bug in an existing package, please press Enter to
exit reportbug.)

1 binnmu   binNMU requests
2 britney  testing migration script bugs
3 bullseye-pu  bullseye proposed updates requests
4 buster-pubuster proposed updates requests
5 otherNone of the other options
6 rm   Stable/Testing removal requests
7 transition   transition tracking
8 unblock  unblock requests

Choose the request type: 3
Please enter the name of the package: spyder
Checking package information...
This package doesn't appear to exist; continue [y|N|?]? y
Latest version seems to be 4.2.1+dfsg1-3, is this the proper one [Y|n|?]? 
-

It says the package doesn't appear to exist, but then knows it's
version number!

Best wishes,

   Julian

-- Package-specific info:
** Environment settings:
EDITOR="emacs -nw"
PAGER="less"
VISUAL="emacs -nw"
DEBEMAIL="j...@debian.org"
DEBFULLNAME="Julian Gilbey"
INTERFACE="text"

** /home/jdg/.reportbugrc:
reportbug_version "3.15"
mode expert
ui text
realname "Julian Gilbey"
email "j...@debian.org"
no-query-bts

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

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

Versions of packages reportbug depends on:
ii  apt2.4.4
ii  python33.9.8-1
ii  python3-reportbug  11.4.1
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.79
ii  debsums3.0.2
ii  dlocate1.10
ii  emacs-bin-common   1:27.1+1-3.1+b1
ii  exim4  4.95-5
ii  exim4-daemon-heavy [mail-transport-agent]  4.95-5
ii  file   1:5.41-2
ii  gnupg  2.2.27-3
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.4.4
ii  file   1:5.41-2
ii  python33.9.8-1
ii  python3-apt2.3.0+b1
ii  python3-debian 0.1.43
ii  python3-debianbts  3.2.0
ii  python3-requests   2.27.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Daniel Kahn Gillmor]

Hi Michael and Santiago--

I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385.  I'm
reviewing Michael's changes for 1.8.1, and they're looking good to me.
Thank you for all that work, Michael!  I think we should consider
uploading 1.8.1 into experimental while we wait for 1.7.1-3 to propagate
to testing.

I'm assembling a git branch that includes your changes that i've
reviewed and i'll push that to salsa as a "debian/experimental" branch
later today, if either of you want to take a look at what i'm
considering for release.

--dkg


signature.asc
Description: PGP signature

Bug#904999: autodep8: python autopkg tests are always run for all supported python versions

[Stefano Rivera]

Hi Matthias (2018.07.30_06:37:50_-0400)

I think this bug was fixed in 0.20, except for the :any issue that mjt
describes.

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1009655: dctrl-tools: Matches comment bodies

[Stefano Rivera]

Package: dctrl-tools
Version: 2.14
Severity: normal

When support for comments was added in
https://salsa.debian.org/debian/dctrl-tools/-/commit/2bc3218cf4f70db497b97687b0d4bc3a847ec217
it was known that this was incomplete (missing semantic understanding of
comments) but there doesn't appear to be an open bug tracking this.

Currently grep-dctrl will match on the bodies of comments, which is very
surprising for the user:

grep-dctrl -FBuild-Depends -w bar << EOF
Source: foo
Build-Depends:
  foo,
# bar,
  baz
EOF

This seems like something that should be opt-in, not default behaviour.

SR

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Daniel Kahn Gillmor]

Thanks both Michael and Santiago for sorting this out!

I agree that backporting
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3
to 1.7.1 is the most reasonable/conservative fix.  We want that to
propagate into testing as soon as possible without risking being blocked
by any other surprising regressions.

I'll take care of that as part of the debian DNS team right now, which
should take care of the NMU as well.

   --dkg



signature.asc
Description: PGP signature

Bug#1009621: ITP: python-sasl -- Python bindings for Cyrus libsasl2

[Daniel Kahn Gillmor]

I did a bit of work packaging python-sasl to create a simple/reasonable
debian package, and i've published my work at
https://salsa.debian.org/debian/python-sasl

But after playing with the module more, i no longer think it should be
in in debian.  as the debian/TODO file in the salsa repo notes:

  The module itself doesn't feel great -- it has no documentation, no
  examples, and what feels to me like a distinctly unpythonic interface.
  It has also seen only very intermittent upstream contributions.

  So i'm abandoning this work for now (and closing the bug report) but
  leaving it visible for anyone who wants to pick up on it from here.

Hopefully this data trail is useful for someone in the future.

  --dkg

On Tue 2022-04-12 23:16:48 -0700, Daniel Kahn Gillmor wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Kahn Gillmor 
> X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net
>
> * Package name: python-sasl
>   Version : 0.3.1
>   Upstream Author : Todd Lipcon 
> * URL : https://github.com/cloudera/python-sasl
> * License : Apache-2.0
>   Programming Lang: C, Python
>   Description : Python bindings for libsasl2
>
> This package should enable a Python-based tool to take advantage of
> any installed SASL module.
>
> This should be useful for testing tools like sasl-xoauth2 (see for
> example #1006888)


signature.asc
Description: PGP signature

Bug#1009359: New security upgrade prevent Chromium from starting

[Andres Salomon]

On 4/13/22 12:11, Anthony Callegaro wrote:

Me again,

I tried debugging further. If I remove the Preferences file I am then able to 
start chromium and if I try to restore pages from the window that makes it 
crashes manually I manage to restore some tabs but some will make it crash 
consistently.

The weird thing is that I have several tabs from the same domain (i.e. our 
internal gitlab) and some will make chromium crash while other from the same 
domain won't.

I do manage to open these tabs from a clean session without crashes.



That's bizarre.  So just to be clear, if you start chromium 
--temp-profile and go to the internal gitlab page(s), it's fine every 
time. However, if you mkdir /tmp/myhome; chromium 
--user-data-dir=/tmp/myhome; and then configure settings (in 
chrome://settings/onStartup) to continue where you left off, go to the 
internal gitlab page(s), close the browser and restart it again with 
chromium --user-data-dir=/tmp/myhome, it crashes? Or does it only crash 
with your specific older cache?


And chromium's crashpad handler isn't giving you any kind of backtrace?  
What about if you run chromium -g?






So I thought that maybe the cache was corrupted and tried running with the 
following, and got a new error :


chromium --aggressive-cache-discard
[134834:134834:0413/180206.632615:ERROR:sandbox_linux.cc(377)] 
InitializeSandbox() called with multiple threads in process gpu-process.
*** stack smashing detected ***: terminated
[134835:134847:0413/180211.873710:ERROR:ssl_client_socket_impl.cc(997)] 
handshake failed; returned -1, SSL error code 1, net_error -3
Trace/breakpoint trap1

Would a full strace help ? Here is the tail :


clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=739454484}) = 0
write(30, "\0", 1)  = 1
getrandom("\x1e\x85\x40\xd1\xe5\x34\xa6\x14\xbb\x67\xaa\xae\xc9\xe0\x70\x72", 
16, 0) = 16
getrandom("\xa1\x79\xcb\x8d\xd1\x7e\x75\xd5\xdc\x71\x7a\x42\x6c\x49\x99\x02", 
16, 0) = 16
getrandom("\x27\xb6\x64\xa2\x8d\x24\x75\xc2\x04\xb9\x93\x10\xad\x0b\x1f\xce", 
16, 0) = 16
getrandom("\xaa\x09\xc9\x17\x34\xd6\xea\xcf\x3a\x3c\x7c\xd5\x02\xeb\xd1\x19", 
16, 0) = 16
getrandom("\x69\x79\x27\x44\x05\x46\x2a\x0c\x81\xa1\xbc\xea\xe2\x99\x3e\xcc", 
16, 0) = 16
getrandom("\x93\x05\xa1\xa1\xda\x79\xb4\xfd\x46\xf8\x61\x48\x98\x96\x6b\x12", 
16, 0) = 16
getrandom("\x90\x1b\xdf\xfd\xc4\x03\x92\xca\xdf\x74\x85\x90\x21\x78\x9f\x83", 
16, 0) = 16
clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=740413539}) = 0
futex(0x7f61777fd528, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x7f61777fd4d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55f686cb5ca8, FUTEX_WAKE_PRIVATE, 1) = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=740599805}) = 0
futex(0x7f61777fd528, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x7f61777fd4d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55f686cb5ca8, FUTEX_WAKE_PRIVATE, 1) = 1
getrandom("\x00\xac\x62\x93\xd0\x11\x62\xa7\xfe\x7f\xc6\x2b\x7a\xe4\xa0\xf5", 
16, 0) = 16
gettimeofday({tv_sec=1649866186, tv_usec=877238}, {tz_minuteswest=-120, 
tz_dsttime=0}) = 0
brk(0x55f687f25000) = 0x55f687f25000
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
gettid()= 136609
prctl(PR_GET_DUMPABLE)  = 1 (SUID_DUMP_USER)
rt_sigprocmask(SIG_BLOCK, [CONT], [TRAP], 8) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\0\0\0\1\0\0\0\250\271\353\214a\177\0\0H\361\307\206\366U\0\0\0\0\0\0\0\0\0\0"...,
 iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
rt_sigtimedwait([CONT], [0413/180946.877861:ERROR:scoped_ptrace_attach.cc(27)] 
ptrace: Operation not permitted (1)
{si_signo=SIGCONT, si_code=SI_TKILL, si_pid=136623, si_uid=1000}, {tv_sec=5, 
tv_nsec=0}, 8) = 18 (SIGCONT)
rt_sigprocmask(SIG_SETMASK, [TRAP], NULL, 8) = 0
futex(0x55f686c7f168, FUTEX_WAKE_PRIVATE, 2147483647) = 0
rt_sigaction(SIGTRAP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, 
sa_restorer=0x7f618ce83140}, NULL, 8) = 0
getpid()= 136609
gettid()= 136609
rt_tgsigqueueinfo(136609, 136609, SIGTRAP, {si_signo=SIGTRAP, 
si_code=SI_KERNEL}) = 0
rt_sigreturn({mask=[]}) = 24
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
[136654:136660:0413/180946.892051:ERROR:ssl_client_socket_impl.cc(997)] 
handshake failed; returned -1, SSL error code 1, net_error -3
+++ killed by SIGTRAP +++
Trace/breakpoint trap

Thanks in advance for any insight
LeTic

--- Original Message ---
On Wednesday, April 13th, 2022 at 11:56, Anthony Callegaro 
 wrote:





Hey Andres,

Thanks for taking a look. Here are the info :

libdrm-amdgpu1:amd64/bullseye 2.4.104-1 uptodate
libdrm-intel1:amd64/bullseye 2.4.104-1 uptodate
libdrm-nouveau2:amd64/bullseye 2.4.104-1 uptodate
libdrm-radeon1:amd64/bullseye 2.4.104-1 uptodate
libdrm2:amd64/bullseye 2.4.104-1 uptodate
libgl1:amd64/bullseye 1.3.2-1 uptodate

Bug#904999: : autodep8: python autopkg tests are always run for all supported python versions

[Michael Tokarev]

On Mon, 30 Jul 2018 12:37:50 +0200 Matthias Klose  wrote:

Package: autodep8
Version: 0.13
Severity: important

The python autopkg tests are always run for all supported python versions,
ignoring, if a module is available for all available versions.  This is the case
for extensions only built for the default python/python3 version.  The tests
should be only run for all versions, if

 - the b-d's contain python-all/python3-all python-all-dev/python3-all-dev


AFAICS, this is - at least in parts - due to Build-Depends: python3-dev:ANY
suffix.

https://salsa.debian.org/ci-team/autodep8/-/blob/master/support/python/generate#L67

 grep-dctrl -n -sBuild-Depends -FBuild-Depends -w python3-dev -a '!' 
-FBuild-Depends -w python3-all-dev debian/control

this fails to find python3-dev:any but finds python3-dev without
the suffix.

This has another interesting implication due to another
issue in grep-dctrl: it finds commented-out parts of
d/control too. Like this:

 Build-Depends:
 # python3-all-dev, -- does not work
   python3-dev

thinking it has dependency on pyhon3-all-dev while in fact
it does not.

And yet more, it fails to realize there are other types of
build dependencies, like Build-Depends-Arch and Build-Depends-Indep.

*sigh* :)

Thanks,

/mjt

Bug#1009179: dkms: Upstream has removed mkdeb|mkdsc|mkbmdeb

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/dell/dkms/issues

On Fri, 08 Apr 2022 13:04:04 +0300 Jaak Pruulmann-Vengerfeldt  
wrote:

Package: dkms
Version: 3.0.3-1
Severity: important
Tags: upstream

Dear Maintainer,

It appears that dkms upstream has removed support for mkdeb, mkdsc and
mkbmdeb --
https://github.com/dell/dkms/commit/68b083eaa3f71c166adfece8e4f760e0cdf96185

From that commit one can't really see if there have been any
discussions. 


With the new upstream version arriving in unstable, it is not clear what
is now the proper way to create binary-only module packages, for
example? Our packaging seems to assume that all the support is still
there in upstream.. 



With best regards,
jaak.



Hello, please consider joining the upstream discussion or open a defect there.

G.

Bug#1009452: libgit2-glib: FTBFS: gir1.2-ggit-1.0 missing files: usr/lib/python3*/*-packages/gi/overrides

[Jeremy Bicha]

This issue is related to https://bugs.debian.org/1009097

Thank you,
Jeremy Bicha

Bug#1009653: dh-rebar: please export REBAR_DEPS_PREFER_LIBS="TRUE"

[Philipp Huebner]

Package: dh-rebar
Version: 0.0.4+nmu1
Severity: important

Dear Maintainer,

thanks to https://github.com/erlang/rebar3/issues/1855 I have become
aware of the environment variable REBAR_DEPS_PREFER_LIBS, which if set
to "TRUE" makes it unnecessary to patch out deps from rebar.config(.script).

Instead of adding this to every single Erlang package's rules file,
I request this to be set from dh-rebar.

Best wishes
Philipp


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-rebar depends on:
ii  debhelper  13.6
ii  rebar  2.6.4-3

dh-rebar recommends no packages.

dh-rebar suggests no packages.

-- no debconf information

Bug#1007752: lcms2: Version 2.13.1 is out

[gregor herrmann]

On Wed, 16 Mar 2022 10:01:31 +0100, Mathieu Malaterre wrote:

> It would super nice to have 2.13.1 in archive before the soft-freeze
> (next year). 2.13.1 include a major fix regarding thread safety.
> 2.13.1 is actually required to build current JPEG-XL package.

It also supposedly should fix #1009448 in src:libpdf-builder-perl.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[gregor herrmann]

Control: tag -1 + confirmed
Control: forwarded -1 
https://github.com/PhilterPaper/Perl-PDF-Builder/issues/177
Control: block -1 with 1007752

On Tue, 12 Apr 2022 20:39:41 +0200, Lucas Nussbaum wrote:

> Source: libpdf-builder-perl
> Version: 3.023-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220412 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > Test Summary Report
> > ---
> > t/tiff.t  (Wstat: 512 Tests: 19 Failed: 2)
> >   Failed tests:  13, 16
> >   Non-zero exit status: 2
> > Files=42, Tests=680, 22 wallclock secs ( 0.22 usr  0.07 sys + 16.41 cusr  
> > 2.13 csys = 18.83 CPU)
> > Result: FAIL
> > Failed 1/42 test programs. 2/680 subtests failed.
> > make[1]: *** [Makefile:1298: test_dynamic] Error 255
> > make[1]: Leaving directory '/<>'
> > dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

According to https://github.com/PhilterPaper/Perl-PDF-Builder/issues/177
this seems to be regression in lcms, which should be fixed in
lcms2-2.13.1.



Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1009652: buster-pu: package nvidia-graphics-drivers/418.226.00-3

[Andreas Beckmann]

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

Hi,

I'd like to update nvidia-graphics-drivers in buster to the final
upstream release. It has reached EoL in 03/2022, that should be
documented with a NEWS entry (as we had done with the 340xx legacy
driver 2 years ago).

It contains a few packaging fixes and improvements that have already
been backported to some of the driver releases in stable.

The "gappy" changelog with many "UNRELEASED" entries is due to the fact
that the package is kept in sync with nvidia-graphics-drivers-tesla-418
and to ease merging.

This package is more or less identical to
nvidia-graphics-drivers-tesla-418 in sid (a similar update request for
bullseye will follow soon), minus some unsuitable bullseye-specific
changes (debhelper bump etc.).


Andreas


ngd-418.226.00-3.diff.xz
Description: application/xz

Bug#1009650: trousers: NMU 0.3.15-0.2

[Bastian Germann]

Source: trousers
Version: 0.3.15-0.2

I am NMUing trousers again because my last NMU introduced an error.
The debdiff for the new version 0.3.15-0.2 is attached.diff -Nru trousers-0.3.15/debian/changelog trousers-0.3.15/debian/changelog
--- trousers-0.3.15/debian/changelog2022-04-12 19:21:33.0 +0200
+++ trousers-0.3.15/debian/changelog2022-04-13 16:42:37.0 +0200
@@ -1,3 +1,17 @@
+trousers (0.3.15-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove invalid lintian override
+  * Adjust trousers.postinst check for tcsd.conf mode (Closes: #1009630)
+  * Remove "extra" priority (inherits "optional")
+  * Revert the init script but use -e /dev/tpm0 over wildcard (Closes: 
#1009635)
+  * d/rules: Remove useless override target
+  * debhelper: Update to v13, getting rid of unnecessary build dependencies
+  * 06-host_name_max.patch: Replace implementation-specific import with 
unistd.h
+  * Consistently use $USER variable in init script (Closes: #808812)
+
+ -- Bastian Germann   Wed, 13 Apr 2022 16:42:37 +0200
+
 trousers (0.3.15-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru trousers-0.3.15/debian/compat trousers-0.3.15/debian/compat
--- trousers-0.3.15/debian/compat   2016-11-20 16:10:31.0 +0100
+++ trousers-0.3.15/debian/compat   1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru trousers-0.3.15/debian/control trousers-0.3.15/debian/control
--- trousers-0.3.15/debian/control  2021-06-14 23:19:13.0 +0200
+++ trousers-0.3.15/debian/control  2022-04-13 16:42:37.0 +0200
@@ -2,9 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Pierre Chifflier 
-Build-Depends: debhelper (>= 9),
-dh-autoreconf,
-autotools-dev (>= 20100122.1),
+Build-Depends: debhelper-compat (= 13),
 libssl-dev,
 libtool,
 pkg-config
@@ -13,6 +11,7 @@
 
 Package: trousers
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}, lsb-base (>= 3.0-6), tpm-udev
 Breaks: udev (<< 136-1)
 Description: open-source TCG Software Stack (daemon)
@@ -29,7 +28,6 @@
 Package: trousers-dbg
 Architecture: any
 Section: debug
-Priority: extra
 Depends:
  ${misc:Depends}, trousers (= ${binary:Version}),
  libtspi1 (= ${binary:Version}), libtspi-dev (= ${binary:Version})
diff -Nru trousers-0.3.15/debian/libtspi1.lintian-overrides 
trousers-0.3.15/debian/libtspi1.lintian-overrides
--- trousers-0.3.15/debian/libtspi1.lintian-overrides   2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.15/debian/libtspi1.lintian-overrides   1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# trousers license is BSD
-libtspi1: possible-gpl-code-linked-with-openssl
diff -Nru trousers-0.3.15/debian/not-installed 
trousers-0.3.15/debian/not-installed
--- trousers-0.3.15/debian/not-installed1970-01-01 01:00:00.0 
+0100
+++ trousers-0.3.15/debian/not-installed2022-04-13 16:42:37.0 
+0200
@@ -0,0 +1 @@
+usr/lib/*/libtspi.la
diff -Nru trousers-0.3.15/debian/patches/06-host_name_max.patch 
trousers-0.3.15/debian/patches/06-host_name_max.patch
--- trousers-0.3.15/debian/patches/06-host_name_max.patch   2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.15/debian/patches/06-host_name_max.patch   2022-04-13 
16:42:37.0 +0200
@@ -6,7 +6,7 @@
  #define HOST_NAME_MAX 64
  #endif
  
-+#include 
++#include 
  #include "trousers/tss.h"
  #include "trousers/trousers.h"
  #include "trousers_types.h"
diff -Nru trousers-0.3.15/debian/rules trousers-0.3.15/debian/rules
--- trousers-0.3.15/debian/rules2021-06-14 23:15:06.0 +0200
+++ trousers-0.3.15/debian/rules2022-04-13 16:42:37.0 +0200
@@ -3,16 +3,10 @@
 export DH_VERBOSE = 1
 
 %:
-   dh ${@} --with autoreconf
+   dh ${@}
 
 override_dh_auto_configure:
dh_auto_configure -- --with-gui=none
 
-override_dh_auto_install:
-   dh_auto_install
-
-override_dh_install:
-   dh_install -X.la --fail-missing --sourcedir=debian/tmp
-
 override_dh_strip:
dh_strip --dbg-package=trousers-dbg
diff -Nru trousers-0.3.15/debian/trousers.init 
trousers-0.3.15/debian/trousers.init
--- trousers-0.3.15/debian/trousers.init2022-04-12 19:21:33.0 
+0200
+++ trousers-0.3.15/debian/trousers.init2022-04-13 16:42:37.0 
+0200
@@ -29,7 +29,7 @@
start)
log_daemon_msg "Starting $DESC" "$NAME"
 
-   if [ "$(echo /dev/tpm*)" != "/dev/tpm*" ]
+   if [ ! -e /dev/tpm0 ]
then
log_warning_msg "device driver not loaded, skipping."
exit 0
@@ -37,9 +37,9 @@
 
for tpm_dev in /dev/tpm*; do
TPM_OWNER=$(stat -c %U $tpm_dev)
-   if [ "x$TPM_OWNER" != "xtss" ]
+   if [ "x$TPM_OWNER" != "x$USER" ]
then
-   log_warning_msg "TPM device 

Bug#1007905: transition: icu

[Rene Engelhard]

Hi,

Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS):

LibreOffice self-testing, especially its break iterator test fails for
the Lao language.


https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0

We could backport the needed stuff to 7.3.


Otherwise everything was fine. But I think I might
redo the rebuilds (only on amd64 now) to test everything with the
final release of ICU. If that's not mandatory, I think ICU is quite OK
for a transition soon.


If python3-defaults was done (or actually even progressing...)...


Regards,


Rene

Bug#1009649: libc upgrade caused connection failure after "ssh debug1: expecting" SSH2_MSG_KEX_ECDH_REPLY

[Joey Hess]

Package: openssh-server
Version: 1:9.0p1-1
Severity: normal

I upgraded libc6 on a armhf box running a rather stale version of
testing, due to installing some package that needed the new version:

2022-04-12 18:23:06 upgrade libc6:armhf 2.32-4 2.33-7

After this partial upgrade, sshing to the host failed. With -v,
the last line displayed was:

ssh debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

I fell down a rabbit hole of old bug reports about connections failing
(or hanging) at that point, which seemed to indicate a MTU or other
networking problem. Notably though, even ssh localhost failed like that,
and it was not hanging like in old reports such as [1], so this seemed
like a slightly different problem.

There was nothing useful logged in the journal.

I resolved the problem with this upgrade:

2022-04-13 11:38:09 upgrade openssh-server:armhf 1:8.4p1-6 1:9.0p1-1

So it seems that something about openssh 8.4p1-6 was broken by glibc
2.33. I'm filing this bug because it seems at least possible that
whatever incompatability that was is still lurking, and will be
triggered again by a future glibs upgrade.

Kernel: Linux honeybee 5.14.0-2-armmp-lpae #1 SMP Debian 5.14.9-2 (2021-10-03) 
armv7l GNU/Linux

-- 
see shy jo

[1] https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085


signature.asc
Description: PGP signature

Bug#1009645: dkms: messages from patching go to stdout/stderr instead of make.log

[Gianfranco Costamagna]

Hello Andreas,

can you please provide a patch or help maintaining the package?
You seem to have more interests than me in this package, and you need it for 
your packages,
so maybe please consider adding yourself to the team, and just upload when you 
have patches :)

thanks in advance!

(btw some patches introduced regressions in autopkgtests, can you please help 
there too?)

G.

On Wed, 13 Apr 2022 16:46:49 +0200 Andreas Beckmann  wrote:

Package: dkms
Version: 3.0.3-1
Severity: minor
Tags: upstream

If dkms applies patches (PATCH=(...) in dkms.conf), the messages go to
stdout/stderr, while the should probably go to make.log instead.

IMO the patching messages add a lot of noise to the dkms output.

From an autopkgtest trying to build a kernel module (the '^I:.*' messages are 
from
/usr/lib/dkms/dkms-autopkgtest, all others from dkms):

I: Trying to build nvidia-legacy-390xx/390.147 for 5.17.0-trunk-armmp-lpae
applying patch 0001-backport-error-on-unknown-conftests.patch...patching file 
conftest.sh
patching file nvidia/nvidia.Kbuild

applying patch do-div-cast.patch...patching file 
nvidia-modeset/nvidia-modeset-linux.c

applying patch kernel-5.7.0-set-memory-array.patch...patching file conftest.sh

applying patch 0006-backport-pde_data-changes-from-470.103.01.patch...patching 
file common/inc/nv-procfs.h
patching file conftest.sh
patching file nvidia/nvidia.Kbuild

applying patch bashisms.patch...patching file conftest.sh

applying patch use-kbuild-compiler.patch...patching file Makefile

applying patch use-kbuild-flags.patch...patching file Kbuild
patching file nvidia/nvidia.Kbuild
patching file Makefile
patching file nvidia-modeset/nvidia-modeset.Kbuild

applying patch use-kbuild-gcc-plugins.patch...patching file Kbuild

applying patch conftest-verbose.patch...patching file Kbuild

applying patch cc_version_check-gcc5.patch...patching file conftest.sh

applying patch nvidia-use-ARCH.o_binary.patch...patching file 
nvidia/nvidia.Kbuild

applying patch nvidia-modeset-use-ARCH.o_binary.patch...patching file 
nvidia-modeset/nvidia-modeset.Kbuild

applying patch include-swiotlb-header-on-arm.patch...patching file 
common/inc/nv-linux.h

applying patch ignore_xen_on_arm.patch...patching file common/inc/nv-linux.h
patching file conftest.sh

applying patch arm-outer-sync.patch...patching file common/inc/nv-linux.h
patching file nvidia-drm/nvidia-drm-linux.c

applying patch nvidia-drm-arm-cflags.patch...patching file conftest.sh


Building module:
cleaning build area
unset ARCH; env NV_VERBOSE=1 make -j16 modules 
KERNEL_UNAME=5.17.0-trunk-armmp-lpae
cleaning build area

Bug#993768: [Pkg-rust-maintainers] Bug#993768: exa: "git" feature was disabled in this build of exa

[Sylvestre Ledru]

Hello,

Le 13/04/2022 à 17:45, 王 一臻 a écrit :

Hi

It seems that `git` feature is still being disabled in the current build, is 
this going to be fixed?

Regards,

Yeah, it should be enabled. I think we had a version mismatch with the git crate
but i might be wrong :)

Feels free to try to fix it!

Cheers
S

Bug#993768: exa: "git" feature was disabled in this build of exa

[王 一臻]

Hi

It seems that `git` feature is still being disabled in the current build, is 
this going to be fixed?

Regards,

Yizhen

Bug#1009643: Acknowledgement (Puppet: Fails to work with Ruby 3.0)

[Sven Mueller]

Just a quick update:

The problem of this particular one is:

in puppet/file_system.rb

  def self.symlink(path, dest, options = {})
@impl.symlink(assert_path(path), dest, options)
  end

Changing this to:

  def self.symlink(path, dest, **options)
@impl.symlink(assert_path(path), dest, **options)
  end

Works.

I suspect the fix to https://bugs.debian.org/1006231 to look very similar,
but there are lots of code locations that use the same "hash as vararg"
mechanism.

Am Mi., 13. Apr. 2022 um 16:33 Uhr schrieb Debian Bug Tracking System <
ow...@bugs.debian.org>:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1009643:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009643.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Puppet Package Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 1009...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1009643: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009643
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1007905: transition: icu

[GCS]

On Wed, Apr 13, 2022 at 2:36 PM Jeremy Bicha  wrote:
> mozjs78 and mozjs91 now no longer have an ICU dependency in Unstable.
>
> 0ad was fixed also.
 Thanks. Did the rebuild locally on i386 and amd64; started with the
ICU 71.1 RC release and finished with the final release if that
matters. Only used Sid versions, didn't try the ones in experimental.
The following is the result.
icu-le-hb is outdated, need to be removed; pyicu needs an update that
I've locally. gnucash self-testing fails with its C and Golang tests.
The former can be fixed by adding tzdata build dependency and not yet
checked the latter.
LibreOffice self-testing, especially its break iterator test fails for
the Lao language. Otherwise everything was fine. But I think I might
redo the rebuilds (only on amd64 now) to test everything with the
final release of ICU. If that's not mandatory, I think ICU is quite OK
for a transition soon.

Regards,
Laszlo/GCS

Bug#1009622: ck: FTBFS on armhf due to wrong -march target

[Steve Langasek]

Package: ck
Version: 0.7.1-6
Followup-For: Bug #1009622
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Please find attached an updated patch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ck-0.7.1/debian/patches/armhf-with-fp.patch 
ck-0.7.1/debian/patches/armhf-with-fp.patch
--- ck-0.7.1/debian/patches/armhf-with-fp.patch 1969-12-31 16:00:00.0 
-0800
+++ ck-0.7.1/debian/patches/armhf-with-fp.patch 2022-04-13 08:11:41.0 
-0700
@@ -0,0 +1,29 @@
+Description: do not hard-code CPU target based on uname
+ The compiler in Debian correctly targets the right ISA for the
+ architecture.  Hard-coding this can result in misbuilds depending on the
+ build machine.  Also, armv7-a is the wrong target for armhf now, it should
+ be armv7-a+fp.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1009622
+Last-Update: 2022-04-13
+Forwarded: no
+
+Index: ck-0.7.1/configure
+===
+--- ck-0.7.1.orig/configure
 ck-0.7.1/configure
+@@ -506,14 +506,6 @@
+   ENVIRONMENT=64
+   ;;
+   arm|armv6|armv6l|armv7|armv7l)
+-  case "$PLATFORM" in
+-  "armv6"|"armv6l")
+-  CFLAGS="$CFLAGS -march=armv6k";
+-  ;;
+-  "armv7"|"armv7l")
+-  CFLAGS="$CFLAGS -march=armv7-a";
+-  ;;
+-  esac
+   RTM_ENABLE="CK_MD_RTM_DISABLE"
+   LSE_ENABLE="CK_MD_LSE_DISABLE"
+   MM="${MM:-"CK_MD_RMO"}"
diff -Nru ck-0.7.1/debian/patches/series ck-0.7.1/debian/patches/series
--- ck-0.7.1/debian/patches/series  2021-10-29 22:05:18.0 -0700
+++ ck-0.7.1/debian/patches/series  2022-04-13 08:09:38.0 -0700
@@ -1,2 +1,3 @@
 debian/0001-cc-builtins.patch
 debian/0002-disable-sse.patch
+armhf-with-fp.patch

Bug#1009622: ck: FTBFS on armhf due to wrong -march target

[Steve Langasek]

Control: reopen -1

Thanks for the quick turnaround, unfortunately it seems my fix is
insufficient.  It worked in a test build only because the environment I was
testing on returned armv8l for platform instead of armv7.  On a real armv7
system, the additional -march argument is unfortunately added to the
commandline BEFORE the one from the upstream build system, which overrides
it.  So surgery on the upstream build system is required.

On Tue, Apr 12, 2022 at 11:39:09PM -0700, Steve Langasek wrote:
> Package: ck
> Version: 0.7.1-6
> Severity: important
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> 
> Hi Daniel,
> 
> In Ubuntu, ck fails to build on armhf because the upstream build system is
> passing an explicit -march option that is no longer correct because it does
> not include floating-point support which is implicit in armhf:
> 
> [...]
> /usr/bin/cc -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 
> -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith 
> -Wcast-align -Wcast-qual -Wwrite-strings -Wstrict-prototypes 
> -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization 
> -fstrict-aliasing -O2 -pipe -Wno-parentheses -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -march=armv7-a -fPIC -D_XOPEN_SOURCE=600 
> -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 -pedantic -Wall -W -Wundef 
> -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align -Wcast-qual 
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs 
> -Winline -Wdisabled-optimization -fstrict-aliasing -O2 -pipe -Wno-parentheses 
> -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -march=armv7-a -fPIC -I/<>/include 
> -I/<>/include -D__arm__ -c -o 
> /<>/src/ck_barrier_tournament.o 
> /<>/src/ck_barrier_tournament.c
> cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
> cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
> [...]
> 
>   (https://launchpad.net/ubuntu/+source/ck/0.7.1-6/+build/22357550)
> 
> I have not verified whether this build failure exists with the current
> toolchain in Debian, therefore I am not marking this as a serious bug;
> however, I expect that if this toolchain change has not yet happened in
> Debian, it will happen soon.
> 
> I have applied the attached patch in Ubuntu to let ck build by choosing an
> appropriate cpu target of -march=armv7-a+fp.  Please consider applying it in
> Debian as well.  Alternatively, upstream could just not override the -march
> at all and trust the compiler defaults.
> 
> Thanks,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1009647: xfstt: xset fp+ unix/:7101 reports "Incorrect font server address or syntax"

[boffi]

Package: xfstt
Version: 1.11-2
Severity: important
X-Debbugs-Cc: giacomo.bo...@gmail.com

Dear Maintainer,

as far as I can tell, I have xfstt running

$ xfsinfo -server unix/:7101
name of server: unix/:7101
version number: 2
vendor string:  HD
vendor release number:  1
maximum request size:   1024 longwords (8192 bytes)
number of catalogues:   0
Number of alternate servers: 0
number of extensions:   0
$ fslsfonts -server unix/:7101 | wc -l
692
$

but, when I tried to let my X know about the server, I had a problem

$ xset fp+ unix/:7101
xset:  bad font path element (#7), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax

Thank you for your dedication and your time, regards ፨ gb

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 xfstt depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.62
ii  libc6  2.33-7
ii  libgcc-s1  12-20220319-1
ii  libstdc++6 12-20220319-1
ii  lsb-base   11.1.0

xfstt recommends no packages.

xfstt suggests no packages.

-- debconf information:
  xfstt/listen_tcp: true

Bug#792169: thinkfan: Fails to set fan speed and exits when started at high temperature

[Lee Garrett]

Hi Matthijs!

Does this bug still affect you? There have been a lot of changes since
your bug report (switch from C to C++ amongst others). I was not able to
reproduce the error, however I don't have the exact same hardware.

Greetings,
Lee


On Sun, 12 Jul 2015 13:16:36 +0200 Matthijs Kooijman 
wrote:
> Package: thinkfan
> Version: 0.9.2-1
> Severity: important
> Tags: patch
> 
> Hi,
> 
> while modifying my configuration to be a bit more aggressive on high
> temperatures, I found that thinkfan exited without changing the fan
> level. When started with -n, it wrote:
> 
>   setfan_ibm: Error writing to /proc/acpi/ibm/fan: Invalid argument
>   Cleaning up and resetting fan control.
> 
> I've marked this bug as important, since it causes the fan to revert to
> automatic hardware / BIOS control when the temperature is high, which is
> likely when you need the extra fanspeed from thinkfan the most. Feel
> free to downgrade if you feel this is less of an issue then I think :-)
> 
> Adding a bit of debug information shows that it tried to write the
> empty string, instead of a proper fan level. It turns out that, at the
> top of the fancontrol() function, lvl_idx is initialized at the maximum
> level, but the cur_lvl variable is not changed.
> 
> Normally, this is not a problem since based on the temperature, the
> index is stepped down to the appropriate level and cur_lvl is updated.
> However, if the highest level turns out to be appropriate, thinkfan
> continues to write the fan level, without updating cur_lvl.
> 
> The fix is simple: Just run the set_fan macro to set cur_lvl too. This
> also means that the level is immediately made effective, which prevents
> having to wait for the watchdog timeout if the highest fanlevel is
> appropriate (which would be the effect of just setting cur_lvl instead
> of calling set_fan).
> 
> --- thinkfan.c.orig 2015-07-12 13:09:28.259263201 +0200
> +++ thinkfan.c  2015-07-12 13:09:43.231401029 +0200
> @@ -111,6 +111,7 @@
>  
> // Set initial fan level...
> lvl_idx = config->num_limits - 1;
> +   set_fan;
>  
> for (i=0; i < num_temps; i++)
> if (temps[i] > tmax) tmax = temps[i];
> 
> 
> Gr.
> 
> Matthijs
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), 
> (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.0.2+ (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#1009646: libnss-mdns uses perl in postrm script

[Gioele Barabucci]

Package: libnss-mdns
Version: 0.15.1-1
Tags: patch

Dear maintainers of libnss-mdns,

the current postrm script of `libnss-mdns` requires Perl. Maintscripts
should not assume the existence of Perl in future systems.

The specific use of `perl` in this maintscript can be replaced
with an equivalent `sed` invocation, as in the following patch (also
available as a merge request at
)


diff --git a/debian/libnss-mdns.postrm b/debian/libnss-mdns.postrm
index ef3f90b..93ff69a 100644
--- a/debian/libnss-mdns.postrm
+++ b/debian/libnss-mdns.postrm
@@ -14,27 +14,10 @@ remove_mdns() {
 return
 fi
 log "Removing mdns from NSS setup"
-perl -i -pe '
-my @remove=(
-"mdns4_minimal [NOTFOUND=return]",
-"mdns4_minimal",
-"mdns4",
-"mdns6_minimal [NOTFOUND=return]",
-"mdns6_minimal",
-"mdns6",
-"mdns_minimal [NOTFOUND=return]",
-"mdns_minimal",
-"mdns",
-);
-sub remove {
-my $s=shift;
-foreach my $bit (@remove) {
-$s=~s/\s+\Q$bit\E//g;
-}
-return $s;
-}
-s/^(hosts:)(.*)/$1.remove($2)/e;
-' /etc/nsswitch.conf
+sed -E -i /etc/nsswitch.conf \
+-e '/^hosts:/s/\s+mdns4(_minimal)?(\s+\[NOTFOUND=return\])?//g' \
+-e '/^hosts:/s/\s+mdns6(_minimal)?(\s+\[NOTFOUND=return\])?//g' \
+-e '/^hosts:/s/\s+mdns(_minimal)?(\s+\[NOTFOUND=return\])?//g'
 }
 
 action="$1"



--
Gioele Barabucci

Bug#1009645: dkms: messages from patching go to stdout/stderr instead of make.log

[Andreas Beckmann]

Package: dkms
Version: 3.0.3-1
Severity: minor
Tags: upstream

If dkms applies patches (PATCH=(...) in dkms.conf), the messages go to
stdout/stderr, while the should probably go to make.log instead.

IMO the patching messages add a lot of noise to the dkms output.

>From an autopkgtest trying to build a kernel module (the '^I:.*' messages are 
>from
/usr/lib/dkms/dkms-autopkgtest, all others from dkms):

I: Trying to build nvidia-legacy-390xx/390.147 for 5.17.0-trunk-armmp-lpae
applying patch 0001-backport-error-on-unknown-conftests.patch...patching file 
conftest.sh
patching file nvidia/nvidia.Kbuild

applying patch do-div-cast.patch...patching file 
nvidia-modeset/nvidia-modeset-linux.c

applying patch kernel-5.7.0-set-memory-array.patch...patching file conftest.sh

applying patch 0006-backport-pde_data-changes-from-470.103.01.patch...patching 
file common/inc/nv-procfs.h
patching file conftest.sh
patching file nvidia/nvidia.Kbuild

applying patch bashisms.patch...patching file conftest.sh

applying patch use-kbuild-compiler.patch...patching file Makefile

applying patch use-kbuild-flags.patch...patching file Kbuild
patching file nvidia/nvidia.Kbuild
patching file Makefile
patching file nvidia-modeset/nvidia-modeset.Kbuild

applying patch use-kbuild-gcc-plugins.patch...patching file Kbuild

applying patch conftest-verbose.patch...patching file Kbuild

applying patch cc_version_check-gcc5.patch...patching file conftest.sh

applying patch nvidia-use-ARCH.o_binary.patch...patching file 
nvidia/nvidia.Kbuild

applying patch nvidia-modeset-use-ARCH.o_binary.patch...patching file 
nvidia-modeset/nvidia-modeset.Kbuild

applying patch include-swiotlb-header-on-arm.patch...patching file 
common/inc/nv-linux.h

applying patch ignore_xen_on_arm.patch...patching file common/inc/nv-linux.h
patching file conftest.sh

applying patch arm-outer-sync.patch...patching file common/inc/nv-linux.h
patching file nvidia-drm/nvidia-drm-linux.c

applying patch nvidia-drm-arm-cflags.patch...patching file conftest.sh


Building module:
cleaning build area
unset ARCH; env NV_VERBOSE=1 make -j16 modules 
KERNEL_UNAME=5.17.0-trunk-armmp-lpae
cleaning build area

nvidia-legacy-390xx.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.17.0-trunk-armmp-lpae/updates/dkms/

nvidia-legacy-390xx-modeset.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.17.0-trunk-armmp-lpae/updates/dkms/

nvidia-legacy-390xx-drm.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.17.0-trunk-armmp-lpae/updates/dkms/
depmod...
I: Testing if nvidia-legacy-390xx modules are correctly installed
nvidia-legacy-390xx/390.147, 5.17.0-trunk-armmp-lpae, armv7l: installed

Andreas

Bug#1009644: wims-lti uses perl in postrm script

[Gioele Barabucci]

Package: wims-lti
Version: 0.4.4.1-10
Tags: patch

Dear wims-lti maintainer,

the current postrm script of `wims-lti` requires Perl. Maintscripts
should not rely on the existence of Perl in future systems.

In this specific case it is possible to replace the single use of `perl`
with an invocation of `mktemp` or `shuf` (both from coreutils), as in
these patches:

Using `mktemp`:

diff -ur a/debian/wims-lti.postrm b/debian/wims-lti.postrm
--- a/debian/wims-lti.postrm2021-09-06 19:07:17.0 +0200
+++ b/debian/wims-lti.postrm2022-04-13 15:10:38.698891971 +0200
@@ -35,7 +35,7 @@
# backup the database
# create a random temporary file name, without tempfile
# ... Why is not debianutils part of piupart's package list?
-   t="/var/tmp/wims-lti"$(perl -e 'print rand();')".sqlite3"
+   t="$(mktemp --tmpdir=/var/tmp --suffix .sqlite3 wims-lti-X)"
cp /var/lib/wims-lti/db.sqlite3 $t
echo "Made a backup of the database in $t"
# clean every file left

Using `shuf`:

diff -ur a/debian/wims-lti.postrm b/debian/wims-lti.postrm
--- a/debian/wims-lti.postrm2021-09-06 19:07:17.0 +0200
+++ b/debian/wims-lti.postrm2022-04-13 15:10:38.698891971 +0200
@@ -35,7 +35,7 @@
# backup the database
# create a random temporary file name, without tempfile
# ... Why is not debianutils part of piupart's package list?
-   t="/var/tmp/wims-lti"$(perl -e 'print rand();')".sqlite3"
+   t="/var/tmp/wims-lti"$(shuf -i 1000- -n1)".sqlite3"
cp /var/lib/wims-lti/db.sqlite3 $t
echo "Made a backup of the database in $t"
# clean every file left

Regards,

--
Gioele Barabucci

Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Sven Mueller]

Package: puppet
Version: 5.5.22-4
Severity: serious
Justification: Fails at core functions

Since testing switched /usr/bin/ruby to use ruby3.0, a previously working
Puppet manifest fails:

s...@larsa.muc:/tmp$ ruby3.0 /usr/bin/puppet apply t.pp
Notice: Compiled catalog for larsa.muc.corp.google.com in environment
production in 0.01 seconds
Error: Could not set 'link' on ensure: wrong number of arguments (given 3,
expected 2) (file: /tmp/t.pp, line: 1)
Error: Could not set 'link' on ensure: wrong number of arguments (given 3,
expected 2) (file: /tmp/t.pp, line: 1)
Wrapped exception:
wrong number of arguments (given 3, expected 2)
Error: /Stage[main]/Main/File[/tmp/testme123]/ensure: change from 'absent'
to 'link' failed: Could not set 'link' on ensure: wrong number of arguments
(given 3, expected 2) (file: /tmp/t.pp, line: 1)
Notice: Applied catalog in 0.02 seconds
s...@larsa.muc:/tmp$ cat t.pp
file {"/tmp/testme123":
  ensure => symlink,
  target => "/tmp/t.pp",
}

Bug#986862: lollypop: Filename args doesn't work when Lollypop is already running

[Andreas Rönnquist]

Hi -

As you might have noticed, upstream has closed the forwarded bug of this
one - but I don't really find the problem solved for me.

Could you please try with 1.4.31 which I just uploaded to unstable, and
see how it affects your use case?

I'm guessing that you still run into problems.

-- Andreas Rönnquist
gus...@debian.org

Bug#1009467: r-bioc-biostrings: FTBFS: BitMatrix.c:9:10: fatal error: S.h: No such file or directory

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/Bioconductor/Biostrings/issues/66

Bug#1009642: libnss-docker uses perl in postrm script

[Gioele Barabucci]

Package: libnss-docker
Version: 0.02-1
Tags: patch

Dear maintainer of libnss-docker,

the current postrm script of `libnss-docker` requires Perl. Maintscripts
should not rely on the existence of Perl in future systems.

The specific use of `perl` in this maintscript can be easily replaced
with an equivalent `sed` invocation, as in the following patch (also
available as a pull request at
https://github.com/dex4er/deb-libnss-docker/pull/2

diff --git a/debian/libnss-docker.postrm b/debian/libnss-docker.postrm
index 0cf8206..d0bdf43 100644
--- a/debian/libnss-docker.postrm
+++ b/debian/libnss-docker.postrm
@@ -16,14 +16,8 @@ remove_nss_entry() {
 log "Could not find /etc/nsswitch.conf."
 return
 fi
-perl -i -pe '
-sub remove {
-my $s = shift;
-$s =~ s/\s+docker(\s+\[NOTFOUND=return\])?//g;
-return $s;
-}
-s/^(hosts:)(.*)/$1.remove($2)/e;
-' /etc/nsswitch.conf
+sed -E -i /etc/nsswitch.conf \
+-e 's/^(hosts:.*)(\s+docker(\s+\[NOTFOUND=return\])?)(.*)$/\1\4/g'
 }

 action="$1"

--
Gioele Barabucci

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

On 13.04.2022 16:44, Santiago Ruano Rincón wrote:
..

So what do we do now?  I think the best is to include
this fix as 1.7.1-3 (provided it actually fixes the
issue) for now, instead of uploading 1.8.


Why just don't uploading 1.8.1?


Well, we know 1.7 (sort of) works while 1.8 might cause
surprizes.


What else is missing, other than the now fixed autodep8-python3?


I don't know anything else what's missing
(besides adding another Closes: by 1.8 for this new bug)


And rewrite the history for this one too ;)


No if we go for your 1.8.1 upload :-)
Am I wrong?


It's still the same rewrite really, no matter which way to
go: either add one commit before the 2 commits in there or
one, it's exactly the same thing now.  No, you aren't wrong.

I can handle that later today (hopefully).

Thanks!

/mjt

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Santiago Ruano Rincón]

El 13/04/22 a las 16:25, Michael Tokarev escribió:
> [Just a quick follow-up]
> 
> On 13.04.2022 15:52, Santiago Ruano Rincón wrote:
> [...]
> > It seems it was fixed on 1.8.0.
> > https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3
> 
> Wonderful.. :)  Thank you Santiago!
> So, the prob should've be there after just any
> recompile of ldns, including the bin-NMU upload
> to rebuild it with python3.10.  *sigh*.
> 
> So what do we do now?  I think the best is to include
> this fix as 1.7.1-3 (provided it actually fixes the
> issue) for now, instead of uploading 1.8.

Why just don't uploading 1.8.1?

What else is missing, other than the now fixed autodep8-python3?

> And rewrite the history for this one too ;)

No if we go for your 1.8.1 upload :-)
Am I wrong?

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1008358: virt-manager: FTBFS: RuntimeError: unsupported configuration: unfiltered sgio is no longer supported

[Fabio Fantoni]

I prepared a PR that fix this: 
https://salsa.debian.org/libvirt-team/virt-manager/-/merge_requests/13




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Michael Tokarev]

[Just a quick follow-up]

On 13.04.2022 15:52, Santiago Ruano Rincón wrote:
[...]

It seems it was fixed on 1.8.0.
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3


Wonderful.. :)  Thank you Santiago!
So, the prob should've be there after just any
recompile of ldns, including the bin-NMU upload
to rebuild it with python3.10.  *sigh*.

So what do we do now?  I think the best is to include
this fix as 1.7.1-3 (provided it actually fixes the
issue) for now, instead of uploading 1.8.

And rewrite the history for this one too ;)

Thanks,

/mjt

Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]

[Santiago Ruano Rincón]

Control: tags -1 + upstream
Control: tags -1 + forwarded https://github.com/NLnetLabs/ldns/issues/142

El 13/04/22 a las 10:37, Michael Tokarev escribió:
> 13.04.2022 10:09, Michael Tokarev wrote:
> ..
> > But let's try.
> > 
> > How this utility is used in building of dns-root-data?  Lemme take a look
> > at this package.  If you can provide me some minimal testcase to produce
> > just the DS record which differs, it will be nice.
> 
> I don't have time for this today.
> 
> Thinking about this further, since there was absolutely no code changes
> in ldns itself, - how about building dns-root-data with ldns 1.7.1-2
> and 1.7.1-2.1 WITHOUT ANYTHING ELSE CHANGING, and comparing the results?
> 
> The thing is that it just can not be this change. Yes it can be a change
> in some other tool. Like libssl I already wrote about, or maybe gcc
> generating different code, or something different.

Like wrong SHA256 on GCC11:
https://github.com/NLnetLabs/ldns/issues/142

> 
> And since I don't have any idea about how ldns works, and don't even
> know what a DS record is, that would be difficult and definitely time-
> consuming for me to understand all this.
> 
> If it's an issue with gcc code generation, we'll have to address this
> upstream most likely. Or maybe it's fixed in 1.8 already.

It seems it was fixed on 1.8.0.
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1007905: transition: icu

[Jeremy Bicha]

mozjs78 and mozjs91 now no longer have an ICU dependency in Unstable.

0ad was fixed also.

Thanks,
Jeremy Bicha

Bug#1009640: www.debian.org: https://www.debian.org/download starts download of iso-image right away

[Cord Beermann]

Package: www.debian.org
Severity: important

Hello,

while looking for a download of debian software i came to 
https://www.debian.org/download
which right away started to download the current netinst.iso.

Please refrain from this, this might be a prominent link at the top of the
page (it already is) but the download must not start on itself. 

It is unexpected and a waste of bandwidth and storage which some users
aren't even aware of. It seems to be also possible to weaponize this.

http://justhaifei1.blogspot.com/2015/10/watch-your-downloads-risk-of-auto.html
https://en.wikipedia.org/wiki/Drive-by_download

Cord

Bug#1009074: [usbguard] this action needs authorisation

[Harri Haataja]

Package: usbguard
Version: 1.1.1+ds-2
Followup-For: Bug #1009074
X-Debbugs-Cc: x...@iki.fi

(On my machine, not original reporter..)
The obnoxious popup dialog appears twice also if given a correct password.
It appears on every resume (at least) and has no user discernible effect on 
anything
and there is no obvious reasib why it happens, what should be done, or whether 
it
can be disabled somehow.

This is a massive usability fail IMO, and makes people hate and uninstall 
usbguard even more.

One journal line also does seem to appear:

gsd-usb-protect[4348]: Error calling USBGuard DBus to change the protection 
after a screensaver event: Timeout was reached


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usbguard depends on:
ii  dbus   1.14.0-1
ii  init-system-helpers1.62
ii  libaudit1  1:3.0.7-1+b1
ii  libc6  2.33-7
ii  libcap-ng0 0.7.9-2.2+b1
ii  libgcc-s1  12-20220319-1
ii  libglib2.0-0   2.72.0-1+b1
ii  libpolkit-gobject-1-0  0.105-33
ii  libseccomp22.5.3-2
ii  libstdc++6 12-20220319-1
ii  libusbguard0   1.1.1+ds-2

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf [Errno 13] Permission denied: 
'/etc/usbguard/usbguard-daemon.conf'

-- no debconf information

Bug#1009639: localepurge: unable to create reproduicble system image due to 'mktemp' in postinst script

[Venkata.Pyla]

Package: localepurge

Version: 0.7.3.10

Severity: normal



Dear Maintainer,



Hi,



I am working to fix a reproducible issue happened during system image creation,

There, when locale purge configuration is copied before package (localepurge) 
installation,

it produces a debconf cache entry with non-reproducible entries, that is due to 
'mktemp' used in postinst script [0],



I wanted to know whether we can use other temporary file at [0], which can be 
reproducible?



[0] 
https://salsa.debian.org/elmig-guest/localepurge/-/blob/master/debian/postinst#L206



steps to verify this issue:

1. create a minimal base image with debootstrap $ sudo debootstrap bullseye 
rootfs/ http://deb.debian.org/debian/ 2. create a configuration for 
locale.nopurge $ sudo chroot rootfs /bin/bash -c "echo en > /etc/locale.nopurge"

3. install localepurge

$ sudo chroot rootfs /bin/bash -c "apt update && apt install localepurge"

4. Check the debconf cache entry (shown below) that has non-reproducible ```

Name: ucf/changeprompt

Template: ucf/changeprompt

Value: keep_current

Owners: ucf

Flags: seen

Variables:

BASENAME = locale.nopurge

FILE = /etc/locale.nopurge

NEW = /tmp/tmp.WJBJ9kEpAu

```



Thanks,

Venkata.



-- System Information:

Debian Release: 11.3

  APT prefers stable

  APT policy: (500, 'stable')

Architecture: amd64 (x86_64)



Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU threads)

Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory

locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), 
LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash

Init: unable to detect



Versions of packages localepurge depends on:

ii  debconf [debconf-2.0]  1.5.77

ii  locales2.31-13+deb11u3

ii  perl   5.32.1-4+deb11u2

ii  procps 2:3.3.17-5

ii  ucf3.0043



localepurge recommends no packages.



Versions of packages localepurge suggests:

pn  bleachbit  

pn  debfoster  

pn  deborphan  



-- debconf information:

perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

LANGUAGE = (unset),

LC_ALL = (unset),

LC_CTYPE = "C.UTF-8",

LANG = "en_US.UTF-8"

are supported and installed on your system.

perl: warning: Falling back to the standard locale ("C").

locale: Cannot set LC_MESSAGES to default locale: No such file or directory

locale: Cannot set LC_ALL to default locale: No such file or directory

  localepurge/dontbothernew: false

* localepurge/remove_no:

* localepurge/use-dpkg-feature: true

  localepurge/verbose: false

* localepurge/none_selected: false

  localepurge/quickndirtycalc: true

* localepurge/nopurge: NEEDSCONFIGFIRST

  localepurge/mandelete: true

  localepurge/showfreedspace: true

Bug#1009638: u-boot: slightly simplify the display of a Debian-specific revision

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

Hello.
The following suggestion removes a Debian-specific patch.


>From 1f2cf0d0fd82ce494d960e28585f657814d1 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 13 Apr 2022 13:46:54 +0200
Subject: [PATCH] Simplify the parts displaying a Debian-specific revision
 during boot

Use the LOCALVERSION dedicated Kconfig string instead of maintaining a
Debian-specific patch on the upstream Makefile.
The result at boot time should be similar.
---
 .../patches/add-debian-revision-to-u-boot-version  | 14 --
 debian/patches/series  |  2 --
 debian/rules   |  5 -
 3 files changed, 4 insertions(+), 17 deletions(-)
 delete mode 100644 debian/patches/add-debian-revision-to-u-boot-version

diff --git a/debian/patches/add-debian-revision-to-u-boot-version 
b/debian/patches/add-debian-revision-to-u-boot-version
deleted file mode 100644
index e6dcdfce23..00
--- a/debian/patches/add-debian-revision-to-u-boot-version
+++ /dev/null
@@ -1,14 +0,0 @@
-Add the debian revision to the U-boot version, which is displayed at
-boot and can be helpful to determine which specific version is used.
-
 a/Makefile
-+++ b/Makefile
-@@ -447,7 +447,7 @@
- 
- # Read UBOOTRELEASE from include/config/uboot.release (if it exists)
- UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null)
--UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
-+UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)$(DEBIAN_REVISION)
- 
- export VERSION PATCHLEVEL SUBLEVEL UBOOTRELEASE UBOOTVERSION
- export ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
diff --git a/debian/patches/series b/debian/patches/series
index d9683fee22..c85336b306 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,5 +1,3 @@
-add-debian-revision-to-u-boot-version
-
 tools-generic-builds.patch
 
 mx53loco
diff --git a/debian/rules b/debian/rules
index fed6b6b092..680209f295 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,6 @@ include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 
 DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 's,.*+dfsg,+dfsg,')
-common_make_args += DEBIAN_REVISION='$(DEBIAN_REVISION)'
 
 include debian/targets.mk
 
@@ -85,6 +84,10 @@ define build_template
  CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
  $($(package)_assigns) $($(platform)_assigns) \
  $(platform)_defconfig
+
+   sed -i '/^CONFIG_LOCALVERSION="/s/"/$(DEBIAN_REVISION)"/' \
+ debian/build/$(platform)/.config
+
dh_auto_build -- $(common_make_args) \
  O=debian/build/$(platform) \
  CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
-- 
2.30.2

Bug#1009536: [Pkg-javascript-devel] Bug#1009536: node-connect-timeout: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1

[Yadd]

On 12/04/2022 21:21, Lucas Nussbaum wrote:

Source: node-connect-timeout
Version: 1.9.0-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220412 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Incompatible with nodejs 14, good candidate for removal

Bug#1009300: dpkg: allow symbol files to be excluded from install

[Guillem Jover]

On Mon, 2022-04-11 at 10:13:52 +0200, Ansgar wrote:
> Package: dpkg
> Version: 1.21.7
> Severity: wishlist

> Someone wondered on IRC why we ship symbols files in shared library
> packages instead of the associated -dev packages

While there is in theory no technical limitation why these could not
be shipped in -dev packages, as the tools care about only explicitly
linked shared libraries (so if a transitive shared library does not
have shlibs/symbols files, that should not be a problem if these are not
present on the system). The problem is that the tooling needs to be
able to find these files, and it goes from object SONAME declaration
to shared object on disk, then looks for the package owning that file,
and then looks for the shlibs or symbols present in that package (either
from the system or package build directories).

(This should probably be documented somewhere explicitly, as I did not
see anything obvious neither in dpkg docs nor the Debian policy manual.)

> and noted that they
> take 1% of disk space for a fresh debian:sid docker container (and
> probably more on the -slim variant of the container).

I just checked (OOC) and f.ex. on the current sid-slim variant it
seems to be around 1.77%. The actual size of these files there is
1.6 MiB (according to du -sch). After a quick look I see either trivial
targets that would more than offset that, f.ex.:

  $ dpkg -P e2fsprogs libext2fs2 mount gcc-9-base
  $ rm -f /var/cache/debconf/*.dat-old
  $ rm -f /var/cache/debconf/templates.dat

Or other more localized/focused things like there being both libpcre2-8-0
and libpcre3, or (libcrypto + libssl) + (libhogweed + libnettle +
libp11-kit + libtasn + libidn2 + libunistring + libgnutls), that would
give way more significant gains (f.ex. getting rid of the GnuTLS stack
would amount to something like an additional 8 MiB, including
reduction from the then no longer present symbols files).

Matthias Klose seems to have implied (in a bug report) to not find
symbols files for C++ libraries very helpful, so if he'd decide to
stop shipping them for libstdc++6 (the biggest there), that would be
an additional 400 KiB reduction.

Otherwise making dpkg transparently compress such files on the db,
would reduce its size by 1.1 MiB (with just gzip), which is something
that I had previously already considered for the old changelog in the
dpkg db proposal.

> It would be nice if it was possible to exclude symbol files from such
> environments. This could mean:
> 
>  - Ship them in the -dev package instead.

While this could potentially be done, it seems to me the amount of
global effort and resulting properties might not be a very good
trade-off for the gains of currently less than 2 MiB (or potentially
around ~500 KiB) of space there.

Conceptually storing them in either  or -dev packages can
be argued to make sense and have good and bad properties.

Shipping them on :

  - They are guaranteed to be kept in sync with the shared object they
describe (no requirement for guaranteeing exact version dependencies
between  and -dev, even though this tends to be current
practice).
  - They do not require adding some way to back-reference the -dev
package corresponding to its  (a new control field f.ex.).
  - They do not depend on the -dev package being arch:any (which
Multi-Arch would require, but that's an optional feature from dpkg
PoV).
  - (There could be external functional reliance on these files being
shipped in  packages to extract specific symbol version
information, as this can be considered part of the interface.)

Shipping them on -dev:

  - They are shipped in the package that would denote the file might
get used, and don't "waste" space in case no building is going to
be happening.
  - The Build-Depends-Package field in symbols files could be somehow
simplified into some boolean variant (but not its
Build-Depends-Package_s_ counterpart, although both of these are
optional, unlike the required new back-reference field in the control
file).

So doing this change seems to me would imply that:

 - Maintainers (not just debhelper) would need to modify the packaging
   to move those files to the new package (which has global impact), for
   a potentially very long-winded transition.
 - Switching all libraries seems like a rather large undertaking for
   a potentially ~500 KiB gain TBH. Switching only packages in the minbase
   set would create a weird packaging oddness and non-uniformity. :/
 - Regardless of a full or a partial transition, both locations would
   need to be supported anyway, which would also make packaging a bit
   more complicated/confusing.

This seems in contrast to other proposals to reduce the essential set,
which imply global efforts, but they also imply complexity reduction by
making f.ex. the bootstrapping requirements smaller, or making
dependencies explicit to get rid of implied assumptions. Which in this
case seems to instead end up 

Bug#1009585: [Pkg-javascript-devel] Bug#1009585: node-fd-slicer: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 3

[Yadd]

Control: tags -1 + help

On 12/04/2022 21:22, Lucas Nussbaum wrote:

Source: node-fd-slicer
Version: 1.1.0+repack1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220412 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Package is broken with node 14. Maybe someone can help here ?

Bug#1006457: Chromium fails to start on aarch64 systems

[MichaIng]

I also just verified that both are installed, ah via chromium-common 
indeed as dependencies.


> I have a rock64 board lying around unused, I'll have to hook it up to 
a monitor and see what happens on there with xfce and chromium.


That would be great. While we tested it with installed desktop 
environments as well, for plain X server + Chromium (for e.g. kiosk mode 
usage), we install these packages explicitly:


--- X server ---
xserver-xorg-core
xserver-xorg-input-libinput
xinit
dbus-x11
xfonts-base
x11-xserver-utils
x11-utils
mesa-utils
mesa-utils-extra
--- Chromium ---
chromium
libpam-systemd

Best regards,

Micha

Bug#1009636: ruby-devise-two-factor: CVE-2021-43177 - possible reuse of OTP due to incomplete fix for CVE-2015-7225

[Neil Williams]

On Wed, 13 Apr 2022 11:18:50 +0100 Neil Williams 
wrote:
> Source: ruby-devise-two-factor
> Version: 4.0.2-1
> Severity: important
> Tags: security
> X-Debbugs-Cc: codeh...@debian.org, Debian Security Team
> 
> 
> Hi,
> 
> The following vulnerability was published for ruby-devise-two-factor.
> 
> CVE-2021-43177[0]:
> | As a result of an incomplete fix for CVE-2015-7225, in versions of
> | devise-two-factor prior to 4.0.2 it is possible to reuse a One-Time-
> | Password (OTP) for one (and only one) immediately trailing interval.
> | CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N)
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-43177
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43177
> 
> Please adjust the affected versions in the BTS as needed.
> 
> See also: https://security-tracker.debian.org/tracker/CVE-2015-7225
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798466


Please note, I've filed the bug because the pull request linked to the
CVE is currently open:
https://github.com/tinfoil/devise-two-factor/pull/108

However, there is a comment that this has been fixed in 4.0.2 but no
link to the fixing commit.

It is possible that
https://github.com/tinfoil/devise-two-factor/commit/64576bb9e7d29800c5f92bb86fb6ecff91ad6105
is the fixing commit but this is not clear.


-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpFpix0YLbZV.pgp
Description: OpenPGP digital signature

Bug#1009636: ruby-devise-two-factor: CVE-2021-43177 - possible reuse of OTP due to incomplete fix for CVE-2015-7225

[Neil Williams]

Source: ruby-devise-two-factor
Version: 4.0.2-1
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for ruby-devise-two-factor.

CVE-2021-43177[0]:
| As a result of an incomplete fix for CVE-2015-7225, in versions of
| devise-two-factor prior to 4.0.2 it is possible to reuse a One-Time-
| Password (OTP) for one (and only one) immediately trailing interval.
| CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-43177
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43177

Please adjust the affected versions in the BTS as needed.

See also: https://security-tracker.debian.org/tracker/CVE-2015-7225
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798466


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1004171: bash: Replace add-shell/remove-shell with declarative shells.d trigger

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2022-01-22 09:25:43)
> the attached patch replaces add-shell/remove-shell with the declarative
> shells.d trigger from debianutils.
> 
> For details about this new mechanism see https://bugs.debian.org/990440.
> 
> This further reduces the number of maintainer scripts in the
> Essential:yes set and is the last missing piece for DPKG_ROOT support in
> bash.
> 
> I also submitted the same improvement to dash:
> 
> https://salsa.debian.org/debian/dash/-/merge_requests/8

the shells.d patch has been applied in dash in unstable for over a month now
and the dash maintainer states that there have been no problems since then.

I'd thus like to send a friendly ping to this bug and ask about applying
shells.d support from debianutils to bash as well.

If you have no objections, I can also prepare an NMU as I've done for #958083.

Thanks!

cheers, josch

signature.asc
Description: signature