Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

2023-02-21 Thread Rebecca N. Palmer

Control: reassign -1 python3-xlrd
Control: affects -1 python3-pandas
Control: retitle -1 pandas can't open xls (not xlsx) files, xlrd too old

Then yes, you do need xlrd.  As Debian is currently in freeze, I suggest 
installing it from PyPI (warning, this doesn't automatically install 
security updates):


sudo apt-get install python3-pip
pip3 install --user xlrd

(I'm not actually sure whether Debian _should_ update to xlrd 2, as 
there are some (possibly not-technically-valid) .xlsx files that xlrd 1 
can open but openpyxl can't, and xlrd 2 is .xls-only.)




Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

2023-02-21 Thread Timo Aaltonen

Timo Aaltonen kirjoitti 23.9.2022 klo 11.21:

Paul Gevers kirjoitti 22.9.2022 klo 22.26:

Hi,

On 22-09-2022 20:38, Salvatore Bonaccorso wrote:

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.



Why is this binNMU actually needed? bind9-dyndb-ldap has the
following:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 
9.11)


which is satisifed as well after the bind9 update via
bullseye-security, and updates are possible. Do your request imply
that the relationship would be too lax?


I think there was a change after the bullseye release. The package in 
unstable has a strict relation instead of a larger-or-equal relation:


Depends: bind9-libs (= 1:9.18.6-2), libc6 (>= 2.34), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.5-0 (>= 2.5.4), libuuid1 (>= 2.16), bind9 (>= 
9.11)


bind-dyndb-ldap (11.9-5) unstable; urgency=medium

   * support-9.18.diff: Fix build with bind9 9.18. (Closes: #1006014)
 - drop patches that aren't needed anymore with this
   * control, rules: Use a strict dependency on bind9-libs that the
 package was built against, in order to avoid bind9 updates breaking
 the package. (Closes: #1004729)

  -- Timo Aaltonen   Wed, 23 Feb 2022 13:17:07 +0200

So, Timo, is the package in bullseye broken with the security update 
and does it need a fix, or is it fine?


It needs a rebuild, because the bind9 library sonames get bumped every 
time the upstream version changes. That's why the silly strict 
dependencies were introduced in sid.


Ondrej, let's talk about merging bind-dyndb-ldap to src:bind9 for 
bookworm, I'm all for it ;)


I'm sure you've seen my MR #21 to add it there, but it got zero 
comments. I noticed afterwards that you had some concerns about shipping 
the GPL2 plugin alongside withe the MPL2 bind9, but is it really a problem?




--
t



Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

2023-02-21 Thread Per Lundberg
Regretfully, this bug is still active and it's trivial to reproduce with 
this configuration:


* apt-get install docker.io (ensure that the docker daemon is running 
afterwards. Tested with 20.10.22+dfsg1-2 locally)

* apt-get install lxd (tested with 5.0.1-5)

Then, "lxc launch ubuntu:22.04" (accepting the defaults for LXD 
configuration). Networking will be broken inside the newly created LXD 
container.


The workaround for me is to run "sudo iptables -P FORWARD ACCEPT" after 
bootup (and after Docker has started). But I agree with previous 
comments; it's EXTREMELY BAD and unacceptable for a program like Docker 
to misbehave like this.


On the LXD side, this has been discussed and is a known issue:

* 
https://discuss.linuxcontainers.org/t/lxd-and-docker-firewall-redux-how-to-deal-with-forward-policy-set-to-drop/9953/9
* 
https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#prevent-issues-with-lxd-and-docker


(The suggestion given there is to insert firewall rules into the 
DOCKER-USER chain.)


I suggest we would consider patching the Docker package in Debian to 
remove the FORWARD DROP nonsense until this has been properly resolved 
upstream. We can't have programs that misbehave this badly in the 
distribution, IMO.


Best regards,
Per Lundberg



Bug#992823: Ever worst time : sympa package

2023-02-21 Thread Dominique Fournier CNRS
On the server with sympa package, it takes more than 2 minutes when the 
services are up !

---
# time /usr/sbin/needrestart
Scanning processes... 



Scanning linux images... 




Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

real2m23.706s
user2m10.592s
sys 0m12.930s
# service sympa stop
# time /usr/sbin/needrestart
Scanning processes... 



Scanning linux images... 




Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

real0m1.430s
user0m1.299s
sys 0m0.125s
-

Could we raise the Severity ?


smime.p7s
Description: Signature cryptographique S/MIME


Bug#1030924: linux-image-6.0.0-0.deb11.6-amd64: NFS3 client: spurious permission denied, 5.10 ok

2023-02-21 Thread Jakob Bohm

linux-image-5.19.0-0.deb11.2-amd64 is also affected.
linux-image-5.10.0-21-amd64 is not affected


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

2023-02-21 Thread Shengjing Zhu
On Tue, Feb 21, 2023 at 5:03 PM Per Lundberg  wrote:
>
> Regretfully, this bug is still active and it's trivial to reproduce with
> this configuration:
>
> * apt-get install docker.io (ensure that the docker daemon is running
> afterwards. Tested with 20.10.22+dfsg1-2 locally)
> * apt-get install lxd (tested with 5.0.1-5)
>
> Then, "lxc launch ubuntu:22.04" (accepting the defaults for LXD
> configuration). Networking will be broken inside the newly created LXD
> container.
>
> The workaround for me is to run "sudo iptables -P FORWARD ACCEPT" after
> bootup (and after Docker has started). But I agree with previous
> comments; it's EXTREMELY BAD and unacceptable for a program like Docker
> to misbehave like this.
>
> On the LXD side, this has been discussed and is a known issue:
>
> *
> https://discuss.linuxcontainers.org/t/lxd-and-docker-firewall-redux-how-to-deal-with-forward-policy-set-to-drop/9953/9
> *
> https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#prevent-issues-with-lxd-and-docker
>
> (The suggestion given there is to insert firewall rules into the
> DOCKER-USER chain.)
>
> I suggest we would consider patching the Docker package in Debian to
> remove the FORWARD DROP nonsense until this has been properly resolved
> upstream. We can't have programs that misbehave this badly in the
> distribution, IMO.

Please read message#91
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91 and then
think about it.
If you still think there's a secure patch that we can apply, I'd like to review.

-- 
Shengjing Zhu



Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Niels Thykier

Control: forcemerge 1031695 995569

Michael Biebl:

Package: debhelper
Version: 13.11.4
Severity: important
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

It appears we currently ship 35 packages in unstable installing 78
service files to /usr/lib/systemd/system which dh_installsystemd doesn't
handle:

[...]

The alternative is to update all those 35 packages and make sure they
install the files to /lib.


Michael


Sorry for being terse, I should be working on something else right now 
but prioritized a short message over nothing.


Duplicate of #995569. My concerns from back then still applies and I 
will not implement this feature until they are resolved. For the record, 
I do not feel the tech-ctte's resolution back then answered my question.


Additionally, we are in the bookworm freeze where toolchains are frozen 
and have been for a month now. I am also not going to implement this 
change for bookwork unless there is an agreement from the release team 
in place that this is the direction we want to go (I do not have time to 
look at that discussion right now either).


Thanks,
~Niels



Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

2023-02-21 Thread Per Lundberg

Hi Shengjing Zhu,

On 2023-02-21 11:44, Shengjing Zhu wrote:


Please read message#91
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91 and then
think about it.
If you still think there's a secure patch that we can apply, I'd like to review.


Hmm, you have some very valid points and concerns there. I should have 
read the whole bug before commenting... :-)



What surprises me though is that on Ubuntu, this seemingly works 
correctly (presuming that LXD is running as a snap in that case), as 
pointed out by a colleague. I don't know why but it would be interesting 
to dig deeper into the details here. I asked my colleague to check his 
sysctl settings and they look identical to mine (IPv4 forwarding not 
enabled in /etc/sysctl.conf). This is from his Ubuntu 22.04 machine:


user@host:~$ grep net.ipv4.ip_forward /etc/sysctl.conf
#net.ipv4.ip_forward=1

user@host:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

user@host:~$ grep ip_forward /etc/sysctl.d/*
/etc/sysctl.d/99-sysctl.conf:#net.ipv4.ip_forward=1

I'm almost inclined to set up an Ubuntu VM to test this in, but I don't 
really have the time (at work) right now. If anyone reading this has 
more insight into this, it would be incredibly interesting.


Best regards,
Per



Bug#898336: hpwdt NMI kernel crash on shutdown/reboot

2023-02-21 Thread Claudio Kuenzler
Just FYI, this bug still happens on the new Debian 12 Bookworm Alpha2,
currently Debian Testing.
Solution is the same as previously stated: Disable (blacklsit) hpwdt Kernel
module.


Bug#1031714: python3.11: doctest fails to deal with method wrappers

2023-02-21 Thread Julien Cristau
Package: python3.11
Version: 3.11.1-2
Severity: important
X-Debbugs-Cc: jcris...@debian.org
Tags: upstream fixed-upstream
Forwarded: https://github.com/python/cpython/issues/99433
Control: affects -1 mercurial

Hi,

python3.11 breaks mercurial's test-doctest.py with:

--- 
/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py.out
+++ 
/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py.err
@@ -0,0 +1,14 @@
+Traceback (most recent call last):
+  File 
"/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py", 
line 116, in 
+testmod(modname, **kwargs)
+  File 
"/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py", 
line 46, in testmod
+for test in finder.find(mod, name):
+^^
+  File "/usr/lib/python3.11/doctest.py", line 940, in find
+self._find(tests, obj, name, module, source_lines, globs, {})
+  File "/usr/lib/python3.11/doctest.py", line 1012, in _find
+self._from_module(module, val)):
+^^
+  File "/usr/lib/python3.11/doctest.py", line 974, in _from_module
+raise ValueError("object must be a class or function")
+ValueError: object must be a class or function

ERROR: test-doctest.py output changed

Looks like this was fixed in 3.11.2 with 
https://github.com/python/cpython/commit/c88a83e7d81fbf394bbdebe0f453bb64bdf33ba6

Cheers,
Julien



Bug#1029116: [PATCH] wifi: mt76: mt7921: correctly handle removal in the absence of firmware

2023-02-21 Thread Helmut Grohne
Trying to probe a mt7921e pci card without firmware results in a
successful probe where ieee80211_register_hw hasn't been called. When
removing the driver, ieee802111_unregister_hw is called unconditionally
leading to a kernel NULL pointer dereference among other things.

As with other drivers that delay registration after probe, we track the
registration state in a flag variable and conidtionalize deregistration.

Link: https://bugs.debian.org/1029116
Link: https://bugs.kali.org/view.php?id=8140
Reported-by: Stuart Hayhurst 
Fixes: 1c71e03afe4b ("mt76: mt7921: move mt7921_init_hw in a dedicated work")
Signed-off-by: Helmut Grohne 
Cc: sta...@vger.kernel.org
Sponsored-by: Freexian and Offensive Security
---
 drivers/net/wireless/mediatek/mt76/mt7921/init.c   | 1 +
 drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h | 1 +
 drivers/net/wireless/mediatek/mt76/mt7921/pci.c| 3 ++-
 drivers/net/wireless/mediatek/mt76/mt7921/sdio.c   | 3 ++-
 drivers/net/wireless/mediatek/mt76/mt7921/usb.c| 3 ++-
 5 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
index 542dfd425129..d5438212d5ff 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
@@ -315,6 +315,7 @@ static void mt7921_init_work(struct work_struct *work)
dev_err(dev->mt76.dev, "register device failed\n");
return;
}
+   dev->hw_registered = true;
 
ret = mt7921_init_debugfs(dev);
if (ret) {
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h 
b/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
index 15d6b7fe1c6c..e3b5d8ebf243 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
@@ -288,6 +288,7 @@ struct mt7921_dev {
bool hw_full_reset:1;
bool hw_init_done:1;
bool fw_assert:1;
+   bool hw_registered:1;
 
struct list_head sta_poll_list;
spinlock_t sta_poll_lock;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
index cb72ded37256..1841eb7345dc 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
@@ -110,7 +110,8 @@ static void mt7921e_unregister_device(struct mt7921_dev 
*dev)
struct mt76_connac_pm *pm = &dev->pm;
 
cancel_work_sync(&dev->init_work);
-   mt76_unregister_device(&dev->mt76);
+   if (dev->hw_registered)
+   mt76_unregister_device(&dev->mt76);
mt76_for_each_q_rx(&dev->mt76, i)
napi_disable(&dev->mt76.napi[i]);
cancel_delayed_work_sync(&pm->ps_work);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
index 8ce4252b8ae7..23a9dd3c6450 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
@@ -43,7 +43,8 @@ static void mt7921s_unregister_device(struct mt7921_dev *dev)
struct mt76_connac_pm *pm = &dev->pm;
 
cancel_work_sync(&dev->init_work);
-   mt76_unregister_device(&dev->mt76);
+   if (dev->hw_registered)
+   mt76_unregister_device(&dev->mt76);
cancel_delayed_work_sync(&pm->ps_work);
cancel_work_sync(&pm->wake_work);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
index 5321d20dcdcb..e55e1b50f760 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
@@ -301,7 +301,8 @@ static void mt7921u_disconnect(struct usb_interface 
*usb_intf)
if (!test_bit(MT76_STATE_INITIALIZED, &dev->mphy.state))
return;
 
-   mt76_unregister_device(&dev->mt76);
+   if (dev->hw_registered)
+   mt76_unregister_device(&dev->mt76);
mt7921u_cleanup(dev);
 
usb_set_intfdata(usb_intf, NULL);
-- 
2.39.0



Bug#1031715: godot3: Please upload 3.5 to BPO (build on bullseye succeeds without modifications)

2023-02-21 Thread Marcel Partap
Package: godot3
Version: 3.5.1-stable-1
Severity: wishlist
Tags: newcomer
X-Debbugs-Cc: mpar...@gmx.net

Godot 3.5 contains many fixes and improvements. I tried building it for current
stable the other day and that worked without any modifications. So it would be
great if a package could be pushed to the backports repo..


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

Kernel: Linux 6.1.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 godot3 depends on:
ii  libasound2 1.2.8-1+b1
ii  libc6  2.36-5
pn  libenet7   
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.2.0-14
ii  libgl1 1.5.0-1
ii  libogg01.3.4-0.1
ii  libopus0   1.3.1-0.1
ii  libpcre2-32-0  10.40-1
ii  libpng16-161.6.38-2
ii  libpulse0  16.1+dfsg1-2+b1
pn  libsquish0 
ii  libstdc++6 12.2.0-14
ii  libtheora0 1.1.1+dfsg.1-15
ii  libvorbis0a1.3.7-1
pn  libvpx6
ii  libvpx71.12.0-1
ii  libwebp6   0.6.1-2.1
ii  libwebp7   1.2.4-0.1
ii  libx11-6   2:1.8.3-3
ii  libxcursor11:1.2.1-1
ii  libxext6   2:1.3.4-1+b1
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  zlib1g 1:1.2.11.dfsg-4.1

godot3 recommends no packages.

godot3 suggests no packages.



Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize

2023-02-21 Thread Christopher Obbard
Control: severity -1 important
Control: retitle -1 e2fsprogs generates filesystems which cannot be
mounted on systems with older e2fsprogs

It turns out for debos the situation is a bit different. Since debos
uses packages on the host to prepare the partitions, new features in 
e2fsprogs from unstable which are unsupported in the target suite
causes the built system to not boot.

One such failure at boot-time of a Debian testing system is when
systemd-fsck tries to check a filesystem, it fails to mount the device:

  /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12

So, in short we cannot run images built for suites with older e2fsprogs
on a host system which has e2fsprogs >=1.47.0-1.

Fixing grub2 will not fix the issue for debos, so I have retitled the
bug.

In debos with newer e2fsprogs, we can set the following flag on a
partition to disable the feature which allows the system running older
e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this
flag:

  features: [ "^orphan_file" ]

So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards
compatibility.

I have reduced the severity of the bug since a workaround for debos
does exist. I wonder whether the bug should be reassigned to e2fsprogs
?



Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?

2023-02-21 Thread Adrian Bunk
Package: python3-protobuf
Version: 3.21.12-1
Severity: serious
Control: block 1028371 by -1

Looking at #1028371, should generated dependencies on python3-protobuf be
  python3-protobuf (>= 3.21), python3-protobuf (<< 3.22)
to ensure that the binary package is used with the same version
as the protobuf-compiler used during the build?

If yes, are other language bindings also affected by this problem?



Bug#948096: Please build and ship flasher_stubs

2023-02-21 Thread Faidon Liambotis
Control: severity -1 important
Control: retitle -1  Please build and ship flasher_stubs

On Fri, Jan 03, 2020 at 10:31:25PM +0200, Faidon Liambotis wrote:
> The Debian package will require some d/rules mechanics + esptool.py
> patches to fully implement this (and on a per-chip basis), and it's
> still not going to provide a solution for the ESP32, but... progress :)
> 
> Hopefully picolibc will pass through NEW soon; as soon as that happens,
> please include support for building and shipping the stub in the Debian
> package. I'll try to provide some patches if I find the time, but please
> don't wait for me :)

Some good news: first of all, I've verified that the changes that I
pushed upstream 3 years ago (miniz etc.) continue to work. On a current
Debian system, all that it takes to build the esp8266 stub is to
  apt install gcc-xtensa-lx106 picolibc-xtensa-lx106-elf
...and then the stub will just build. (There is a tiny warning about no
debug support that is silenced by removing "-g" from CFLAGS). I've just
tested the resulting stub from a build on a sid system just now, with
the source from esptool v4.5, and it successfully flashed my esp8266.

Moreover, more good news: we can now build stubs for the RISC-V chips,
which as of now are ESP32-C3, ESP32-H2, ESP32-C2 and ESP32-C6. For this,
  apt install gcc-riscv64-unknown-elf picolibc-riscv64-unknown-elf
is required, plus:
  1. passing the right CROSS_ prefixes for every chip (configurable)
  2. passing -mabi=ilp32 to CFLAGS (upstreamable)
  3. passing -specs=picolibc.specs to CFLAGS (to use picolibc)
With these, I've successfully built a stub for a ESP32-C3, and then
subsequently used it to flash a LOLIN C3 mini with no issues.

And a small piece of bad news: we are still missing the toolchain (both
gcc and picolibc) for the ESP32, ESP32-S2 and ESP32-S3 chips. These
don't even exist upstream, and with the focus on the RISC-V chips I
doubt it'll ever happen now. We can just disable stubs for these.

I'm attaching three patches which, once applied, result into:
  make -C flasher_stub embed
to just work for all but three chips. Given this is just basic upstream
functionality that can be easily enabled in Debian, I'm also marking
this bug as important.

Best,
Faidon
>From 12348a020dcfc04122e7821c7bfea8adde6a Mon Sep 17 00:00:00 2001
From: Faidon Liambotis 
Date: Tue, 21 Feb 2023 13:40:43 +0200
Subject: [PATCH 1/3] stub: Remove -g from the ESP8266 build flags

There is no debug support in the compiler. Without this, (otherwise
harmless) warnings are emitted:
  xtensa-lx106-elf-gcc: warning: target system does not support debug output
---
 flasher_stub/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/flasher_stub/Makefile b/flasher_stub/Makefile
index 55b5fa9..0bbcc5f 100644
--- a/flasher_stub/Makefile
+++ b/flasher_stub/Makefile
@@ -85,7 +85,7 @@ $(BUILD_DIR):
 
 CFLAGS = -std=c99 -Wall -Werror -Os \
  -mtext-section-literals -mlongcalls -nostdlib -fno-builtin -flto \
- -Wl,-static -g -ffunction-sections -Wl,--gc-sections -Iinclude -Lld
+ -Wl,-static -ffunction-sections -Wl,--gc-sections -Iinclude -Lld
 CFLAGS_ESPRISCV32 = -std=c99 -Wall -Werror -Os \
 		 -march=rv32imc -msmall-data-limit=0 \
  -nostdlib -fno-builtin -flto \
-- 
2.30.2

>From 28ba14a6480ca83f3a8734e06d907bbc33e85497 Mon Sep 17 00:00:00 2001
From: Faidon Liambotis 
Date: Tue, 21 Feb 2023 13:42:03 +0200
Subject: [PATCH 2/3] stub: build with Debian's riscv64 gcc and picolibc

---
 flasher_stub/Makefile | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/flasher_stub/Makefile b/flasher_stub/Makefile
index 0bbcc5f..9c03332 100644
--- a/flasher_stub/Makefile
+++ b/flasher_stub/Makefile
@@ -36,11 +36,11 @@ CROSS_8266 ?= xtensa-lx106-elf-
 CROSS_32 ?= xtensa-esp32-elf-
 CROSS_32S2 ?= xtensa-esp32s2-elf-
 CROSS_32S3 ?= xtensa-esp32s3-elf-
-CROSS_32C3 ?= riscv32-esp-elf-
-CROSS_32C6BETA ?= riscv32-esp-elf-
-CROSS_32H2 ?= riscv32-esp-elf-
-CROSS_32C2 ?= riscv32-esp-elf-
-CROSS_32C6 ?= riscv32-esp-elf-
+CROSS_32C3 ?= riscv64-unknown-elf-
+CROSS_32C6BETA ?= riscv64-unknown-elf-
+CROSS_32H2 ?= riscv64-unknown-elf-
+CROSS_32C2 ?= riscv64-unknown-elf-
+CROSS_32C6 ?= riscv64-unknown-elf-
 
 # Python command to invoke wrap_stub.py
 WRAP_STUB ?= ./wrap_stub.py
@@ -87,7 +87,8 @@ CFLAGS = -std=c99 -Wall -Werror -Os \
  -mtext-section-literals -mlongcalls -nostdlib -fno-builtin -flto \
  -Wl,-static -ffunction-sections -Wl,--gc-sections -Iinclude -Lld
 CFLAGS_ESPRISCV32 = -std=c99 -Wall -Werror -Os \
-		 -march=rv32imc -msmall-data-limit=0 \
+		 -march=rv32imc -mabi=ilp32 -msmall-data-limit=0 \
+ -specs=picolibc.specs \
  -nostdlib -fno-builtin -flto \
  -Wl,-static -g -ffunction-sections -Wl,--gc-sections -Iinclude -Lld
 LDLIBS = -lgcc
-- 
2.30.2

>From 9c5e618ffc2dee30ca659871247355a8ad1fb0e2 Mon Sep 17 00:00:00 2001
From: Faidon Liambotis 
Date: Tue, 21 Feb 2023 13:40:09 +0200
Sub

Bug#1031640: Info received (Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize)

2023-02-21 Thread Christopher Obbard
Control: retitle -1 e2fsprogs generates filesystems which cannot be mounted on 
systems with older e2fsprogs



Bug#1029626: pagure: diff for NMU version 5.11.3+dfsg-2.1

2023-02-21 Thread Adrian Bunk
Control: tags 1029626 + patch
Control: tags 1029626 + pending

Dear maintainer,

I've prepared an NMU for pagure (versioned as 5.11.3+dfsg-2.1) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru pagure-5.11.3+dfsg/debian/changelog pagure-5.11.3+dfsg/debian/changelog
--- pagure-5.11.3+dfsg/debian/changelog	2023-01-22 07:05:14.0 +0200
+++ pagure-5.11.3+dfsg/debian/changelog	2023-02-21 14:26:40.0 +0200
@@ -1,3 +1,11 @@
+pagure (5.11.3+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/pagure.postrm: Don't fail if adduser is not installed.
+(Closes: #1029626)
+
+ -- Adrian Bunk   Tue, 21 Feb 2023 14:26:40 +0200
+
 pagure (5.11.3+dfsg-2) unstable; urgency=medium
 
   [ Sergio Durigan Junior ]
diff -Nru pagure-5.11.3+dfsg/debian/pagure.postrm pagure-5.11.3+dfsg/debian/pagure.postrm
--- pagure-5.11.3+dfsg/debian/pagure.postrm	2023-01-22 07:03:43.0 +0200
+++ pagure-5.11.3+dfsg/debian/pagure.postrm	2023-02-21 14:26:34.0 +0200
@@ -19,7 +19,7 @@
 	# Delete the pagure user.  We explicitly don't delete any
 	# files here because we don't want to delete user data.
 	if getent passwd "$PAGURE_USER" > /dev/null; then
-	   deluser "$PAGURE_USER"
+	   deluser "$PAGURE_USER" || true
 	fi
 ;;
 esac


Bug#983719: esptool: Version 3.0 fixes critical bugs

2023-02-21 Thread Faidon Liambotis
Control: retitle -1 Package is severely outdated
Control: severity -1 serious

This package is severely outdated. esptool v2.8, as currently packaged
in Debian, was released in October 2019, almost 3.5 years ago. Upstream
has regularly released newer versions every few months in the meantime,
with the latest being v4.5, released last week.

Newer versions bring a myriad of fixes, as well as equally importantly,
support for newer chips that can be found in the wild.

As I've also reported in #948096, esptool in Debian is crippled right
now by not including any flasher stubs, limiting its usefulness. The
removal was justified at the time, but some of the underlying reasons
have been resolved for a long time now for several of the supported
chips, and only require simple patches to be applied to restore.

(Also note: the packaging and DFSG-ness can be simplified quite a bit,
since the binary blobs are now split into JSON files in the build tree,
that can be cleaned up with Files-Excluded, removing the need for
modifying the source through the uupdate script.)

Given how outdated the source is, and the lack of responses from the
maintainer in the BTS, I do not believe the package is fit for the next
release, therefore I'm elevating the severity to RC.

I should note that while the package seems to meet the criteria for
Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
it properly in the long run either. I'm happy to do a one-off NMU to
bring it to a more decent shape, however.

Best,
Faidon



Bug#992415: pinentry-tty: Segfault as host is entering S3/S0ix

2023-02-21 Thread andrew
Just an update, this can't be replicated in Bookworm.
Please close the bug.



Bug#1016598: binoculars: diff for NMU version 0.0.12-1.2

2023-02-21 Thread Adrian Bunk
Control: tags 1016598 + pending

Dear maintainer,

I've prepared an NMU for binoculars (versioned as 0.0.12-1.2) and 
uploaded it to DELAYED/3. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru binoculars-0.0.12/debian/changelog binoculars-0.0.12/debian/changelog
--- binoculars-0.0.12/debian/changelog	2023-01-11 18:48:13.0 +0200
+++ binoculars-0.0.12/debian/changelog	2023-02-21 15:13:26.0 +0200
@@ -1,3 +1,11 @@
+binoculars (0.0.12-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Also switch the binary dependency from python3-vtk7 to python3-vtk9.
+(Closes: #1016598)
+
+ -- Adrian Bunk   Tue, 21 Feb 2023 15:13:26 +0200
+
 binoculars (0.0.12-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru binoculars-0.0.12/debian/control binoculars-0.0.12/debian/control
--- binoculars-0.0.12/debian/control	2022-11-24 13:20:09.0 +0200
+++ binoculars-0.0.12/debian/control	2023-02-21 14:50:46.0 +0200
@@ -50,7 +50,7 @@
 Section: python
 Depends:
  gir1.2-hkl-5.0,
- python3-vtk7,
+ python3-vtk9,
  ${misc:Depends},
  ${python3:Depends},
 Suggests:


Bug#1031717: UDD/DMD: Use a consistent description for new upstream TODO items.

2023-02-21 Thread Bas Couwenberg
Package: qa.debian.org
Severity: normal
Tags: patch

Dear Maintainer,

The attached patch makes the description for 'new upstream' Todo list items on 
DMD consistent.

Currently it shows:
┌──┬┬─┬──┐
│ type │ source │ description   
  │ hide │
├──┼┼─┼──┤
│ new upstream │ netcdf │ New upstream version available: 4.9.1 (already in 
experimental, but not in unstable) (currently in unstable: 1:4.9.0-3) │ hide │
├──┼┼─┼──┤
│ new upstream │ pydecorate │ New version available: 0.3.4 (currently in 
unstable: 0.3.3-1)   │ 
hide │
└──┴┴─┴──┘

With the patch the description is consistent to improve readability:
┌──┬┬─┬──┐
│ type │ source │ description   
  │ hide │
├──┼┼─┼──┤
│ new upstream │ netcdf │ New upstream version available: 4.9.1 (already in 
experimental, but not in unstable) (currently in unstable: 1:4.9.0-3) │ hide │
├──┼┼─┼──┤
│ new upstream │ pydecorate │ New upstream version available: 0.3.4 (currently 
in unstable: 0.3.3-1)  │ hide │
└──┴┴─┴──┘

Kind Regards,

Bas
>From 7cdc564b8cf301c69ad3484a389bdd30811d5292 Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Tue, 21 Feb 2023 14:16:59 +0100
Subject: Use consistent description for new upstream TODO items.

---
 web/inc/dmd-data.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/inc/dmd-data.rb b/web/inc/dmd-data.rb
index a859ab6..e0a13f3 100755
--- a/web/inc/dmd-data.rb
+++ b/web/inc/dmd-data.rb
@@ -1010,7 +1010,7 @@ and source not in (select source from upload_history 
where date > (current_date
 :type => 'new upstream',
 :source => src,
 :link => nil,
-:description => "New version available",
+:description => "New upstream version available",
 :details => "#{v['upstream'][:version]}#{cursid}" }
   elsif v['upstream'][:status] == :out_of_date_in_unstable
 h = Digest::MD5.hexdigest("#{src}_#{v['upstream'][:version]}")
-- 
2.30.2



Bug#1031718: In some cases there is the error: connection refused (Socket error code 10061)

2023-02-21 Thread Debian

Package: libgnutls30
X-Debbugs-Cc: deb...@decotrain.de
Version: 3.7.1-5+deb11u2
Severity: normal

Hello,

this is more a question for ideas and support, because a bug cannot be 
proven.


There is a problem with the mail system on a server, that does not 
receive emails from certain providers any more.
The sender of the emails don't get any notice that the emails are not 
delivered and there is only one sender that could provide an error 
message. This is:


2/17/2023 12:43:19 PM - Server at PAWP195MB2418.EURP195.PROD.OUTLOOK.COM 
returned '550 5.4.316 Message expired, connection refused(Socket error 
code 10061)'
2/17/2023 12:33:05 PM - Server at domain.de (xx.79.98.xx) returned '450 
4.4.316 Connection refused [Message=Socket error code 10061]


Searching the internet shows that will be caused by a routing problem, 
but the mail system generally works and emails are received from other 
senders.


The problem exists since 2023-02-15 so the idea is to search what has 
changed.
The only thing that has changed is that an automated security update has 
happened:


Start-Date: 2023-02-15 07:38:27
Commandline: apt-get upgrade -y -o 
Dir::Etc::SourceList=/etc/apt/security.sources.list
Upgrade: libgnutls30:amd64 (3.7.1-5+deb11u2, 3.7.1-5+deb11u3), 
libgnutls-dane0:amd64 (3.7.1-5+deb11u2, 3.7.1-5+deb11u3)

End-Date: 2023-02-15  07:38:32

That's the reason why the question is placed here.

The changelog only tells about an "Fix double free":
https://metadata.ftp-master.debian.org/changelogs//main/g/gnutls28/gnutls28_3.7.1-5+deb11u2_changelog

It makes no sense that this bug was needed to avoid routing problems!?

Is there any other idea for the reason of the problem?

Best regards
karsten


-- System Information:
Debian Release: 11.6
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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


Bug#1031719: libpipewire-0.3-modules: pipewire module zeroconf discover filters out sources

2023-02-21 Thread Landry MINOZA
Package: libpipewire-0.3-modules
Version: 0.3.65-2
Severity: normal

Dear Maintainer,

Trying to use remote devices with pipewire, I don't see some devices
(specificaly a headset mic in my case).
Reproduce on 2 sid clients.

I load zeroconf module:

pactl load-module module-zeroconf-discover

When listing available devices:
Audio
 ├─ Devices:
 │  42. Audio interne   [alsa]
 │
 ├─ Sinks:
 │  *   45. Audio interne Stéréo analogique   [vol: 0.40]
 │  62. Starship/Matisse HD Audio Controller Stéréo analogique on 
landry@demetra [vol: 1.00]
 │  64. [G533 Wireless Headset Dongle]  [vol: 1.00]
 │
 ├─ Sink endpoints:
 │
 ├─ Sources:
 │  *   46. Audio interne Stéréo analogique   [vol: 1.00 MUTED]
 │  60. Starship/Matisse HD Audio Controller Stéréo analogique on 
landry@demetra [vol: 1.00]
 │
 ├─ Source endpoints:
 │
 └─ Streams:

The headset mic (source [G333 Wireless Headset Dongle] is exposed by
avahi:

❯ avahi-browse --resolve _pulse-source._tcp -t
+  wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono PulseAudio 
Sound Source local
+  wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller St__r__o a 
PulseAudio Sound Source local
=  wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono PulseAudio 
Sound Source local
   hostname = [demetra.local]
   address = [2a01:e0a:8db:8861:dead:beef:0:f0f8]
   port = [4713]
   txt = ["description=[G533 Wireless Headset Dongle] Mono" "subtype=hardware" 
"channel_map=mono" "format=s16le" "channels=1" "rate=48000" 
"device=alsa_input.usb-Logitech_G533_Gaming_Headset-00.mono-fallback" 
"cookie=0x4a6f9a3a" "fqdn=demetra" "uname=Linux x86_64 6.1.0-5-amd64" 
"user-name=landry" "server-version=PipeWire 0.3.65"]
=  wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller St__r__o a 
PulseAudio Sound Source local
   hostname = [demetra.local]
   address = [10.0.0.144]
   port = [4713]
   txt = ["description=Starship/Matisse HD Audio Controller 
St\195\169r\195\169o analogique" "subtype=hardware" 
"channel_map=front-left,front-right" "format=s32le" "channels=2" "rate=48000" 
"device=alsa_input.pci-_0a_00.4.analog-stereo" "cookie=0x4a6f9a3a" 
"fqdn=demetra" "uname=Linux x86_64 6.1.0-5-amd64" "user-name=landry" 
"server-version=PipeWire 0.3.65"]

On the remote host, this source is visible and usable:
Audio
 ├─ Devices:
 │  44. GM204 High Definition Audio Controller [alsa]
 │  46. [G533 Wireless Headset Dongle]  [alsa]
 │  47. Starship/Matisse HD Audio Controller [alsa]
 │ 122. Fairphone 4 5G  [bluez5]
 │
 ├─ Sinks:
 │  *   39. [G533 Wireless Headset Dongle] Stéréo analogique [vol: 0.65]
 │  53. Starship/Matisse HD Audio Controller Stéréo analogique [vol: 0.25]
 │
 ├─ Sink endpoints:
 │
 ├─ Sources:
 │  *   52. [G533 Wireless Headset Dongle] Mono [vol: 1.00]
 │  54. Starship/Matisse HD Audio Controller Stéréo analogique [vol: 1.00]


It used to work when my client host was using pulseaudio (bullseye).

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

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

Versions of packages libpipewire-0.3-modules depends on:
ii  libavahi-client3   0.8-8
ii  libavahi-common3   0.8-8
ii  libc6  2.36-8
ii  libdbus-1-31.14.6-1
ii  libglib2.0-0   2.74.5-1
ii  liblilv-0-00.24.14-1
ii  libpipewire-0.3-0  0.3.65-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsndfile11.2.0-1
ii  libssl33.0.8-1
ii  libsystemd0252.5-2

libpipewire-0.3-modules recommends no packages.

libpipewire-0.3-modules suggests no packages.

-- no debconf information


Bug#956804:

2023-02-21 Thread Valerio Bozzolan
Reading this discussion, I see that at the moment there is not any
official way to declare and expose an environment variable to
"catalina.sh".

I mean, for example, if you need to define this env:
(note, it's not a system property):

MY_CUSTOM_APPLICATION_SECRET=123

In short, this is the current situation of this package AFAIK:

1.
Any extra "Environment=FOO=BAR" variable set from systemd is ignored.
(Also if you force that with PassEnvironment=FOO)
Feature? Probably yes.

2.
Any extra environent variable set from /etc/default/tomcat9 is NOT
exposed to "bin/catalina.sh".
Feature? Probably yes.

[MOST IMPORTANT POINT]
3.
The supposed path to declare an extra env variable should be
"bin/setenv.sh", but, this is in a read-only location as per FHS and so
it's NOT supposed to be customized.
Feature? Probably NO.

If I'm correct:

It would probably make sense to discuss the issue n. 3.

For example, allowing a file such as "setenv.sh" to be created in an
officially writable location would probably make sense.

-- 
Valerio Bozz.


E-mail sent from Evolution from a random GNU/Linux distribution,
delivered from my Postfix mailserver.

Have fun with software freedom!



Bug#1031720: ITP: sabctools -- C implementations of key functions used within SABnzbd

2023-02-21 Thread Jeroen Ploemen
Package: wnpp
Severity: wishlist
Owner: j...@debian.org

https://github.com/sabnzbd/sabctools

Will be replacing python-sabyenc in the upcoming 4.0.0 release of
sabnzbdplus.


pgpJ9muwSKWRo.pgp
Description: OpenPGP digital signature


Bug#1031685: redmine doesn't work as thin instance

2023-02-21 Thread Jakob Haufe
We currently consider fixing this in a more automatic manner. See [1].

Cheers,
sur5r

[1] https://salsa.debian.org/ruby-team/redmine/-/merge_requests/4

-- 
ceterum censeo microsoftem esse delendam.


pgpzYol2UFqwR.pgp
Description: OpenPGP digital signature


Bug#1025409: libxcb-cursor0: Causes X11 errors for non-existing cursors / please update to a newer upstream release

2023-02-21 Thread Jakob Haufe
Control: fixed -1 0.1.4-1
Control: close

I somehow lost the Closes: entry while preparing the upload, closing
manually.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpeQLYZsS9Xt.pgp
Description: OpenPGP digital signature


Bug#956804:

2023-02-21 Thread Valerio Bozzolan
I just want to mention that, I don't see ANY way at all to expose any
custom environment variable to the Tomcat process itself.

Feature? Unsure.

AFAIK If you push an environment variable inside your catalina.sh, (for
example via the previously mentioned setenv.sh), that variable just die
in catalina.sh and - it seems to me - it is never exposed to the
Tomcat's Bootstrap process.

I'd just be curious if what I'm saying makes sense.

-- 
Valerio Bozz.


E-mail sent from Evolution from a random GNU/Linux distribution,
delivered from my Postfix mailserver.

Have fun with software freedom!



Bug#1031719: Output from a bullseye host with pulseaudio

2023-02-21 Thread Landry Minoza
Additionally this is what I see from a Bullseye desktop in the same network

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

$ pactl load-module module-zeroconf-discover
21

$ pactl list sources
Source #0
État : SUSPENDED
Nom : alsa_output.pci-_00_1f.3.analog-stereo.monitor
[…]

Source #1
État : IDLE
Nom :
tunnel.demetra.local.alsa_output.pci-_0a_00.4.analog-stereo.monitor
[…]

Source #2
État : IDLE
Nom :
tunnel.demetra.local.alsa_input.usb-Logitech_G533_Gaming_Headset-00.mono-fallback
Description : [G533 Wireless Headset Dongle] Mono on landry@demetra
Pilote : module-tunnel.c
Spécification de l'échantillon : s16le 1ch 48000Hz
Plan des canaux : mono
Module du propriétaire : 23
Sourdine : non
Volume : mono: 65536 / 100% / 0,00 dB
   balance 0,00
Volume de base : 65536 / 100% / 0,00 dB
Moniteur de la destination : n/d
Latence : 77655 usec, configuré 25 usec
Marqueurs : NETWORK DECIBEL_VOLUME LATENCY
Propriétés :
device.description = "[G533 Wireless Headset Dongle] Mono on landry@demetra"
tunnel.remote.server = "[10.0.0.144]:4713"
tunnel.remote.source =
"alsa_input.usb-Logitech_G533_Gaming_Headset-00.mono-fallback"
device.icon_name = "audio-input-microphone"
tunnel.remote_version = "35"
tunnel.remote.user = "landry"
tunnel.remote.fqdn = "demetra"
tunnel.remote.description = "[G533 Wireless Headset Dongle] Mono"
Formats :
pcm

Source #3
État : IDLE
Nom : tunnel.demetra.local.alsa_input.pci-_0a_00.4.analog-stereo
[…]

Source #4
État : IDLE
Nom :
tunnel.demetra.local.alsa_output.usb-Logitech_G533_Gaming_Headset-00.analog-stereo.monitor
Description : Monitor Source of [G533 Wireless Headset Dongle] Stéréo
analogique on landry@demetra
Pilote : module-tunnel.c
Spécification de l'échantillon : s16le 2ch 48000Hz
Plan des canaux : front-left,front-right
Module du propriétaire : 25
Sourdine : non
Volume : front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% /
0,00 dB
   balance 0,00
Volume de base : 65536 / 100% / 0,00 dB
Moniteur de la destination :
tunnel.demetra.local.alsa_output.usb-Logitech_G533_Gaming_Headset-00.analog-stereo
Latence : 0 usec, configuré 25 usec
Marqueurs : DECIBEL_VOLUME LATENCY
Propriétés :
device.description = "Monitor Source of [G533 Wireless Headset Dongle]
Stéréo analogique on landry@demetra"
device.class = "monitor"
device.icon_name = "audio-input-microphone"
Formats :
pcm

-- 
Landry MINOZA
landry.min...@gmail.com


Bug#1031722: gdb: changelog missing in binary packages

2023-02-21 Thread Christian Göttsche
Source: gdb
Version: 13.1-1
Severity: serious
Justification: violates Debian Policy 12.7.

The binary packages, e.g. gdb[1], do not contain a changelog file,
required by the Debian Policy 12.7.[2].


[1]: https://packages.debian.org/sid/amd64/gdb/filelist
[2]: 
https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes



Bug#1030298: #1030298: Patch backported from upstream, 10-day delayed NMU uploaded

2023-02-21 Thread Roland Mas

Hi all,

Upstream has a patch that I successfully tested on barriere.d.o (i386 
porterbox) after a minor tweak (the tolerance was not enough). I've 
committed it to a forked repository on salsa and submitted a merge 
request at 
https://salsa.debian.org/opencl-team/python-pyopencl/-/merge_requests/3


Also, given the urgency of the situation (since several dependent 
packages are at risk of getting thrown out of testing), I uploaded a 
10-day delayed NMU.


Thanks,

Roland.



Bug#1031723: ITP: obs-command-source -- plugin for OBS Studio providing a dummy source to execute commands

2023-02-21 Thread Joao Eriberto Mota Filho
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Norihiro Kamae 


* Package name: obs-command-source
  Version : 0.3.2
  Upstream Contact: Norihiro Kamae 
* URL : 
https://obsproject.com/forum/resources/dummy-source-to-execute-command.952/
* License : GPL-2
  Programming Lang: C, Python
  Description : plugin for OBS Studio providing a dummy source to execute 
commands

 This plugin provides a dummy source to execute arbitrary commands when a scene
 is switched.
 .
 Current features:
 .
   Start a command at the following events:
 * Show (the source is shown in either preview or program).
 * Hide (the source is hidden so that no longer shown in neither preview
   nor program).
 * Activate (the source goes to the program).
 * Deactivate (the source goes from the program).
 * Show in preview (the source goes to the preview).
 * Hide from preview (the source goes from the preview).
   .
   Optionally, kill the created process at these conditions (this feature is
   not available for Windows as of now):
 * When hiding, kill the process created at shown.
 * When deactivating, kill the process created at activated.
 * When hiding from the preview, kill the process created at preview.
 .
 Possible usage:
   * Implementing custom tally lights.
   * Controlling PTZ cameras by switching the scene. Ii is possible to combine
 with CURL to send some commands.
   * Start and stop a daemon program required for the scene.
   * Trigger other operations through websocket at the event. A helper script
 is available for this (request-websocket.py).
   * Start or stop a streaming and recording.
   * Open a full screen video.
   * Open a calculator to teach about finances when switching a scene.
   * Other actions.



Bug#1031724: fava: frontend is not built from source; missing source

2023-02-21 Thread Bastian Germann

Source: fava
Version: 1.18-1
Severity: serious

The package's frontend node package is not built from source.
It cannot be built from source as the svelte framework seems to be missing from 
Debian.
Additionally, some of the node packages' dependencies (see frontend/package.json) are included in the orig tarball but 
not represented in the package source. This is a Policy violation. Please at least include the missing source.




Bug#1029720: [Pkg-nagios-devel] Bug#1029720: Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'

2023-02-21 Thread Jan Wagner

Thanks for all your input.

As the release is coming closer and I'm very short on time at the moment 
patches are very appreciated.


Thanks Jan



Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Michael Biebl

Hi Niels

On Tue, 21 Feb 2023 10:47:09 +0100 Niels Thykier  wrote:

Sorry for being terse, I should be working on something else right now 
but prioritized a short message over nothing.


Duplicate of #995569.


Sorry, missed that...

 My concerns from back then still applies and I
will not implement this feature until they are resolved. For the record, 
I do not feel the tech-ctte's resolution back then answered my question.


Additionally, we are in the bookworm freeze where toolchains are frozen 
and have been for a month now. I am also not going to implement this 
change for bookwork unless there is an agreement from the release team 
in place that this is the direction we want to go (I do not have time to 
look at that discussion right now either).


Looping in the release team.

Quoting Helmut from IRC:

helmut
'I am indeed wondering whether the ctte's acceptance of "usr-is-merged 
is pulled by init-system-helpers" would be sufficient to address 
nthykier's concerns. That's new compared to his earlier rejection.'



I'm currently evaluating what the best course of action is here.

The patch for dh_installsystemd would be quite simple and then we'd 
mostly need a couple of binNMUs. In Trixie we will need that anyway and 
I assume for backports it would be beneficial as well.

This all speaks in favor of changing dh_installsystemd.

The alternative is to basically have 35 RC bugs against affected 
packages and fixing those individually by moving the files to /lib


Dear release team, could you please have a look at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695 and share your 
opinion on how to proceed here.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Michael Biebl

For bookworm we have

$ apt-file search -x ^/usr/lib/systemd/system/
amazon-ec2-net-utils: /usr/lib/systemd/system/policy-routes@.service
amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.service
amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.timer
arno-iptables-firewall: 
/usr/lib/systemd/system/arno-iptables-firewall.service

boinc-client: /usr/lib/systemd/system/boinc-client.service
booth: /usr/lib/systemd/system/booth-arbitrator.service
caddy: /usr/lib/systemd/system/caddy-api.service
caddy: /usr/lib/systemd/system/caddy.service
ceph-iscsi: /usr/lib/systemd/system/rbd-target-api.service
ceph-iscsi: /usr/lib/systemd/system/rbd-target-gw.service
cfengine3: /usr/lib/systemd/system/cf-apache.service
cfengine3: /usr/lib/systemd/system/cf-execd.service
cfengine3: /usr/lib/systemd/system/cf-hub.service
cfengine3: /usr/lib/systemd/system/cf-monitord.service
cfengine3: /usr/lib/systemd/system/cf-postgres.service
cfengine3: /usr/lib/systemd/system/cf-reactor.service
cfengine3: /usr/lib/systemd/system/cf-runalerts.service
cfengine3: /usr/lib/systemd/system/cf-serverd.service
cfengine3: /usr/lib/systemd/system/cfengine3.service
cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.service
cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.timer
debomatic: /usr/lib/systemd/system/debomatic.service
drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
fail2ban: /usr/lib/systemd/system/fail2ban.service
fapolicyd: /usr/lib/systemd/system/fapolicyd.service
freedombox: /usr/lib/systemd/system/avahi-daemon.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/bind9.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/calibre-server-freedombox.service
freedombox: /usr/lib/systemd/system/coturn.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/deluged.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/freedombox-manual-upgrade.service
freedombox: /usr/lib/systemd/system/janus.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/matrix-synapse.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/mediawiki-jobrunner.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/nmbd.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/plinth.service
freedombox: /usr/lib/systemd/system/quasselcore.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/shadowsocks-libev-local@.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/smbd.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/syncthing@syncthing.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/transmission-daemon.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/tt-rss.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/wordpress-freedombox.service
freedombox: /usr/lib/systemd/system/wordpress-freedombox.timer
freedombox: /usr/lib/systemd/system/zramswap.service.d/freedombox.conf
fwknop-apparmor-profile: /usr/lib/systemd/system/usr.sbin.fwknopd
gammu-smsd: /usr/lib/systemd/system/gammu-smsd.service
libpam-modules-bin: /usr/lib/systemd/system/pam_namespace.service
mpd: /usr/lib/systemd/system/mpd.service
mpd: /usr/lib/systemd/system/mpd.socket
mpdscribble: /usr/lib/systemd/system/mpdscribble.service
nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex-ws.service
nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex.service
nordugrid-arc-datadelivery-service: 
/usr/lib/systemd/system/arc-datadelivery-service.service

nordugrid-arc-gridftpd: /usr/lib/systemd/system/arc-gridftpd.service
nordugrid-arc-hed: /usr/lib/systemd/system/arched.service
nordugrid-arc-infosys-ldap: 
/usr/lib/systemd/system/arc-infosys-ldap-slapd.service

nordugrid-arc-infosys-ldap: /usr/lib/systemd/system/arc-infosys-ldap.service
nvme-cli: /usr/lib/systemd/system/nvmefc-boot-connections.service
nvme-cli: /usr/lib/systemd/system/nvmf-autoconnect.service
nvme-cli: /usr/lib/systemd/system/nvmf-connect.target
nvme-cli: /usr/lib/systemd/system/nvmf-connect@.service
pass-extension-tomb: /usr/lib/systemd/system/pass-close@.service
pcscd: /usr/lib/systemd/system/pcscd.service
pcscd: /usr/lib/systemd/system/pcscd.socket
phog: /usr/lib/systemd/system/greetd.service.d/phog.conf
powerman: /usr/lib/systemd/system/powerman.service
pvpgn: /usr/lib/systemd/system/pvpgn.service
python3-charon: /usr/lib/systemd/system/charon.service
qbittorrent-nox: /usr/lib/systemd/system/qbittorrent-nox@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-local@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-redir@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-server@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-tunnel@.service
systemd-oomd: 
/usr/lib/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf
systemd-oomd: 
/usr/lib/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf

tcmu-runner: /usr/lib/systemd/system/tcmu-runner.servic

Bug#1031725: unblock: accountsservice/22.08.8-6

2023-02-21 Thread Simon McVittie
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: accountsserv...@packages.debian.org
Control: affects -1 + src:accountsservice

accountsservice could benefit from some appropriate age-days to get it
into testing a bit sooner. It's currently at 3 of 10 days.

(Do you want requests like this for important/RC bug fixes during soft
freeze in general, or should maintainers prefer to wait 10 days and hope
that manual intervention isn't needed?)

[ Reason ]
Fixes a regression introduced while fixing previous RC bugs.

[ Impact ]
If not accepted, accounts-daemon crashes with an assertion failure on
systems where /etc/shadow doesn't exist (pwunconv or shadowconfig off),
which is inadvisable but at least partially supported. This leads to
gdm and probably other login managers not starting, preventing login.
(#1031309)

This is a regression caused by my previous fix for #1030262, which is
already in testing. At the time of fixing #1030262 it hadn't occurred
to me that a missing /etc/shadow was something that could happen on a
supportable system.

[ Tests ]
The scenario with the crash was manually tested in a bookworm GNOME VM. It
seemed too rare and weird to add an automated test, but the automated test
added while fixing #1030262 and #1030253 still passes in this version.

[ Risks ]
The service is high-visibility and security-sensitive, but the change
is straightforward (allowing a hash table to be NULL) and was already
accepted upstream.

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

unblock accountsservice/22.08.8-6
diffstat for accountsservice-22.08.8 accountsservice-22.08.8

 debian/changelog   |   10 ++
 debian/patches/0005-gdm_config_file_path.patch |7 -
 debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch |1 
 debian/patches/daemon-Don-t-crash-if-etc-shadow-doesn-t-exist.patch|   41 ++
 debian/patches/series  |1 
 debian/patches/tests-fix-invocation-of-AddUser.patch   |2 
 debian/patches/tests-fix-the-signature-for-the-SetLocked-call.patch|2 
 debian/patches/user-Use-correct-format-strings-to-print-accounts_user_ge.patch |1 
 src/daemon.c   |5 -
 9 files changed, 61 insertions(+), 9 deletions(-)

diff -Nru accountsservice-22.08.8/debian/changelog accountsservice-22.08.8/debian/changelog
--- accountsservice-22.08.8/debian/changelog	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/changelog	2023-02-18 09:22:31.0 +
@@ -1,3 +1,13 @@
+accountsservice (22.08.8-6) unstable; urgency=medium
+
+  * Team upload
+  * d/p/daemon-Don-t-crash-if-etc-shadow-doesn-t-exist.patch:
+Add patch to prevent a crash if /etc/shadow is missing or empty
+(Closes: #1031309)
+  * d/patches: Mark most patches as having been applied upstream
+
+ -- Simon McVittie   Sat, 18 Feb 2023 09:22:31 +
+
 accountsservice (22.08.8-5) unstable; urgency=medium
 
   * Team upload
diff -Nru accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch
--- accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch	2023-02-18 09:22:31.0 +
@@ -1,11 +1,10 @@
 From: Josselin Mouette 
 Date: Sat, 12 Oct 2019 10:29:08 +0200
-Subject: Fix path to the GDM configuration file, which is different
+Subject: Fix path to the GDM configuration file
 
-Bug-Debian: http://bugs.debian.org/627311
-Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49993
+It's different in Debian.
 
-in Debian.
+Bug-Debian: http://bugs.debian.org/627311
 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49993
 ---
  src/daemon.c | 2 +-
diff -Nru accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch
--- accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch	2023-02-18 09:22:31.0 +
@@ -8,6 +8,7 @@
 Bug: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/109
 Signed-off-by: Simon McVittie 
 Forwarded: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/120
+Applied-upstream: 23.0, commit:c142812f7653cd1f6e52224da8410cd09f102a4f
 ---
  src/daemon.c | 5 +
  src/user.c   | 5 +
di

Bug#1031727: epiphany-browser: CVE-2023-26081

2023-02-21 Thread Moritz Mühlenhoff
Source: epiphany-browser
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for epiphany-browser.

CVE-2023-26081[0]:
| In Epiphany (aka GNOME Web) through 43.0, untrusted web content can
| trick users into exfiltrating passwords, because autofill occurs in
| sandboxed contexts.

https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1275
https://gitlab.gnome.org/GNOME/epiphany/-/commit/53363c3c8178bf9193dad9fa3516f4e10cff0ffd


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-2023-26081
https://www.cve.org/CVERecord?id=CVE-2023-26081

Please adjust the affected versions in the BTS as needed.



Bug#1031726: hdf5: CVE-2022-26061 CVE-2022-25972 CVE-2022-25942

2023-02-21 Thread Moritz Mühlenhoff
Source: hdf5
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for hdf5. The reports
mentioned a vendor disclosure, but not sure when/how.

CVE-2022-26061[0]:
| A heap-based buffer overflow vulnerability exists in the gif2h5
| functionality of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF
| file can lead to code execution. An attacker can provide a malicious
| file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1487

CVE-2022-25972[1]:
| An out-of-bounds write vulnerability exists in the gif2h5
| functionality of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF
| file can lead to code execution. An attacker can provide a malicious
| file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1485

CVE-2022-25942[2]:
| An out-of-bounds read vulnerability exists in the gif2h5 functionality
| of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF file can lead to
| code execution. An attacker can provide a malicious file to trigger
| this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1486

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-26061
https://www.cve.org/CVERecord?id=CVE-2022-26061
[1] https://security-tracker.debian.org/tracker/CVE-2022-25972
https://www.cve.org/CVERecord?id=CVE-2022-25972
[2] https://security-tracker.debian.org/tracker/CVE-2022-25942
https://www.cve.org/CVERecord?id=CVE-2022-25942

Please adjust the affected versions in the BTS as needed.



Bug#1031728: resteasy: CVE-2023-0482

2023-02-21 Thread Moritz Mühlenhoff
Source: resteasy
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for resteasy.

CVE-2023-0482[0]:
| In RESTEasy the insecure File.createTempFile() is used in the
| DataSourceProvider, FileProvider and Mime4JWorkaround classes which
| creates temp files with insecure permissions that could be read by a
| local user.

https://github.com/resteasy/resteasy/pull/3409/
https://github.com/resteasy/resteasy/commit/3d8a551d80b98f185edaff6f895188ec8211366b


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-2023-0482
https://www.cve.org/CVERecord?id=CVE-2023-0482

Please adjust the affected versions in the BTS as needed.



Bug#1031730: emacs: CVE-2022-48339 CVE-2022-48338 CVE-2022-48337

2023-02-21 Thread Moritz Mühlenhoff
Source: emacs
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for emacs.

CVE-2022-48339[0]:
| An issue was discovered in GNU Emacs through 28.2. htmlfontify.el has
| a command injection vulnerability. In the hfy-istext-command function,
| the parameter file and parameter srcdir come from external input, and
| parameters are not escaped. If a file name or directory name contains
| shell metacharacters, code may be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1b4dc4691c1f87fc970fbe568b43869a15ad0d4c

CVE-2022-48338[1]:
| An issue was discovered in GNU Emacs through 28.2. In ruby-mode.el,
| the ruby-find-library-file function has a local command injection
| vulnerability. The ruby-find-library-file function is an interactive
| function, and bound to C-c C-f. Inside the function, the external
| command gem is called through shell-command-to-string, but the
| feature-name parameters are not escaped. Thus, malicious Ruby source
| files may cause commands to be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9a3b08061feea14d6f37685ca1ab8801758bfd1c

CVE-2022-48337[2]:
| GNU Emacs through 28.2 allows attackers to execute commands via shell
| metacharacters in the name of a source-code file, because lib-
| src/etags.c uses the system C library function in its implementation
| of the etags program. For example, a victim may use the "etags -u *"
| command (suggested in the etags documentation) in a situation where
| the current working directory has contents that depend on untrusted
| input.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=01a4035c869b91c153af9a9132c87adb7669ea1c


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-48339
https://www.cve.org/CVERecord?id=CVE-2022-48339
[1] https://security-tracker.debian.org/tracker/CVE-2022-48338
https://www.cve.org/CVERecord?id=CVE-2022-48338
[2] https://security-tracker.debian.org/tracker/CVE-2022-48337
https://www.cve.org/CVERecord?id=CVE-2022-48337

Please adjust the affected versions in the BTS as needed.



Bug#1031729: resteasy3.0: CVE-2023-0482

2023-02-21 Thread Moritz Mühlenhoff
Source: resteasy3.0
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for resteasy3.0.

CVE-2023-0482[0]:
| In RESTEasy the insecure File.createTempFile() is used in the
| DataSourceProvider, FileProvider and Mime4JWorkaround classes which
| creates temp files with insecure permissions that could be read by a
| local user.

https://github.com/resteasy/resteasy/pull/3409/
https://github.com/resteasy/resteasy/commit/3d8a551d80b98f185edaff6f895188ec8211366b


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-2023-0482
https://www.cve.org/CVERecord?id=CVE-2023-0482

Please adjust the affected versions in the BTS as needed.



Bug#1031731: glusterfs: CVE-2023-26253

2023-02-21 Thread Moritz Mühlenhoff
Source: glusterfs
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for glusterfs.

CVE-2023-26253[0]:
| In Gluster GlusterFS 11.0, there is an xlators/mount/fuse/src/fuse-
| bridge.c notify stack-based buffer over-read.

https://github.com/gluster/glusterfs/issues/3954


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-2023-26253
https://www.cve.org/CVERecord?id=CVE-2023-26253

Please adjust the affected versions in the BTS as needed.



Bug#1031732: iortcw: CVE-2019-25104

2023-02-21 Thread Moritz Mühlenhoff
Source: iortcw
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for rtcwcoop, which seems
to be a fork of iortcw, but the patches don't seem to have flown back?

CVE-2019-25104[0]:
| A vulnerability has been found in rtcwcoop 1.0.2 and classified as
| problematic. Affected by this vulnerability is the function
| AICast_ScriptLoad of the file code/game/ai_cast_script.c of the
| component Team Command Handler. The manipulation leads to denial of
| service. The name of the patch is
| f2cd18bc2e1cbca8c4b78bee9c392272bd5f42ac. It is recommended to apply a
| patch to fix this issue. The identifier VDB-221485 was assigned to
| this vulnerability.

https://github.com/rtcwcoop/rtcwcoop/pull/45


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-2019-25104
https://www.cve.org/CVERecord?id=CVE-2019-25104

Please adjust the affected versions in the BTS as needed.



Bug#1031733: libcommons-fileupload-java: CVE-2023-24998

2023-02-21 Thread Moritz Mühlenhoff
Source: libcommons-fileupload-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcommons-fileupload-java.

CVE-2023-24998[0]:
| Apache Commons FileUpload before 1.5 does not limit the number of
| request parts to be processed resulting in the possibility of an
| attacker triggering a DoS with a malicious upload or series of
| uploads.

https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17


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-2023-24998
https://www.cve.org/CVERecord?id=CVE-2023-24998

Please adjust the affected versions in the BTS as needed.



Bug#1031734: ibus-braille-preferences crashes when run

2023-02-21 Thread T. Joseph Carter
Package: ibus-braille
Version: 0.3-7
Severity: important

Upon running ibus-braille-preferences, I get this error:

```
aki:~ $ ibus-braille-preferences 
/usr/share/ibus-braille-preferences/main.py:24: PyGIWarning: Gtk was imported 
without specifying a version first. Use gi.require_version('Gtk', '4.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/share/ibus-braille-preferences/main.py:26: PyGIWarning: IBus was imported 
without specifying a version first. Use gi.require_version('IBus', '1.0') 
before import to ensure that the right version gets loaded.
  from gi.repository import IBus
Traceback (most recent call last):
  File "/usr/share/ibus-braille-preferences/main.py", line 265, in 
ibus_sharada_braille_preferences()
  File "/usr/share/ibus-braille-preferences/main.py", line 36, in __init__

self.guibuilder.add_from_file("/usr/share/ibus-braille-preferences/ui.glade")
gi.repository.GLib.GError: gtk-builder-error-quark: 
/usr/share/ibus-braille-preferences/ui.glade:75:52 Invalid property: 
GtkBox.border_width (11)
```

I suspect PyGIWarning is the clue: This probably requires GTK+ 3.x, not
4.x, but it doesn't specify what it needs. Seems line 26 is also going
to cause a potential problem. I suspect judicious use of the following
three lines added to a couple source files will fix it:

```python
from gi import require_version
require_version('Gtk', '3.0')
require_version('IBus', '1.0')
```

At least, that was all it took to get the preferences applet to run.
Didn't test the abbreviation or language editor with similar patches.

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

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

Versions of packages ibus-braille depends on:
ii  gir1.2-ibus-1.0   1.5.27-4
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  python3   3.11.1-3
ii  python3-espeak0.5-5+b1
ii  python3-gi3.42.2-3+b1
ii  python3-louis 3.24.0-1

Versions of packages ibus-braille recommends:
ii  python3-speechd  0.11.4-2

ibus-braille suggests no packages.

-- no debconf information



Bug#1031735: oggvideotools: autopkgtest relies on an obsolet location for file Effet_force_magnetique.ogv

2023-02-21 Thread Georges Khaznadar
Package: oggvideotools
Version: 0.9.1-6
Severity: normal

Dear Maintainer,

I am the author and maintainer of package pymecavideo, which yields the
binary package python3-mecavideo.

The new version (>> 8.0~rc4) will have the file "Effet_force_magnetique.ogv"
in a new location: /usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv

As this file is not accessible from the path
/usr/share/python3-mecavideo/video/Effet_force_magnetique.ogv which is used for
autopkgtests, the test fails, so the version 8.0~rc4  of package pymecavideo
introduces a regression.

To fix it, I shall upload a version 8.0~rc5 which creates a symlink from
/usr/share/python3-mecavideo/video to ../pymecavideo/data/video

But this is "quick and dirty" as a job.

Please can you modify your test script, to use instead, the definitive
location,
/usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv ?

Best regards, Georges.


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

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

Versions of packages oggvideotools depends on:
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libgd3 2.3.3-7+b1
ii  libstdc++6 12.2.0-14
ii  libtheora0 1.1.1+dfsg.1-16.1
ii  libvorbis0a1.3.7-1
ii  libvorbisenc2  1.3.7-1

oggvideotools recommends no packages.

oggvideotools suggests no packages.

-- no debconf information



Bug#1031352: Chromium on Wayland: Cannot join a Microsoft Teams enterprise meeting

2023-02-21 Thread Amr Ibrahim
Package: chromium
Version: 110.0.5481.77-2
Followup-For: Bug #1031352

Hallo,

Bug still exists in version 110.0.5481.77-2

Best,
Amr


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 chromium depends on:
ii  chromium-common110.0.5481.77-2
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-31.14.6-1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgbm122.3.3-1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.5-1
ii  libgtk-3-0 3.24.36-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-1+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenjp2-7   2.5.0-1+b1
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libre2-9   20220601+dfsg-1+b1
ii  libsnappy1v5   1.1.9-2
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.1
ii  libwebpdemux2  1.2.4-0.1
ii  libwebpmux31.2.4-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.3-3
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxnvctrl0525.85.05-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  110.0.5481.77-2

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n110.0.5481.77-2
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6  2.36-8
ii  libdouble-conversion3  3.2.1-1
ii  libjsoncpp25   1.9.5-4
ii  libstdc++6 12.2.0-14
ii  libx11-6   2:1.8.3-3
ii  libxnvctrl0525.85.05-1
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-4.1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
ii  chromium-

Bug#1031732: iortcw: CVE-2019-25104

2023-02-21 Thread Simon McVittie
On Tue, 21 Feb 2023 at 16:09:30 +0100, Moritz Mühlenhoff wrote:
> CVE-2019-25104[0]:
> https://github.com/rtcwcoop/rtcwcoop/pull/45

This looks like a denial of service via memory exhaustion when running
a multiplayer server. For a game from 2001, I would personally say this
is normal or even minor severity: it isn't really realistic to expect
a game this old to not be crashable.

I'm also not at all sure that iortcw is even vulnerable to this.

For historical reasons iortcw is actually two separate game engines with
similar but divergent content: SP/ is a single-player game with
computer-controlled enemies and no real security implications, while
MP/ is a team-based competitive multiplayer game with only human players.

rtcwcoop appears to be a fork of iortcw which combines the SP and MP
codebases, so that gamers can play the original game's single-player story
as a cooperative multiplayer game where they fight computer-controlled
enemies.

This denial of service seems to be in code to load AI scripts for
computer-controlled enemies or allies, which can happen in rtcwcoop
or in iortcw SP/; but iortcw MP/ doesn't have any computer-controlled
characters as far as I know, so it might well be impossible for the
resource exhaustion to actually happen in practice?

smcv



Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

2023-02-21 Thread Andrea Corallo
Tatsuya Kinoshita  writes:

> On 2023-02-20 at 20:22 +, Andrea Corallo wrote:
>> I've installed 5d0b45cd67b on emacs-29 in order to use always
>> `make-temp-file'.
>
> Please be careful with the difference between make-temp-file-internal
> and make-temp-file.
>
>> +++ b/lisp/emacs-lisp/comp.el
>>  (expand-file-name
>> - (make-temp-file-internal (file-name-sans-extension 
>> rel-filename)
>> -  0 ".eln" nil)
>> + (make-temp-file (file-name-sans-extension rel-filename) 0 
>> ".eln"
>> + nil)
>>   temporary-file-directory
>
> This second argument of make-temp-file should be nil, and expanding
> against temporary-file-directory is already done by make-temp-file.
>
> Thanks,

Hi Tatsuya,

thanks for checking, 68df9e5953c fix that.

Bests

  Andrea



Bug#1031712: libnet-server-perl: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Net/Server/Fork.pm line 168.

2023-02-21 Thread gregor herrmann
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=146575
Control: tag -1 + upstream patch

On Tue, 21 Feb 2023 07:54:07 +0100, Dominique Fournier via pkg-perl-maintainers 
wrote:

> 
> Each time there is a connection in Munin (using the lib-netserver-perl 
> package as tcp server),
> a log is generated :
> munin-node: Use of uninitialized value in numeric eq (==) at 
> /usr/share/perl5/Net/Server/Fork.pm line 168.
> 
> This appears in version 2.013-1 and don't exists in version 2.009-2 of the 
> package.
> 
> Could you patch the library to remove this not needed log ?

Thanks.

This is
https://rt.cpan.org/Public/Bug/Display.html?id=146575
and
https://github.com/rhandom/perl-net-server/issues/32
with a PR at
https://github.com/rhandom/perl-net-server/pull/33

Will try to get a patch into Debian soon.


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#1031718: Same problem with BTS server

2023-02-21 Thread Debian

Maybe this error can be tracked within the Debian BTS email server?
(There should be one more reply from the system for this email that will 
fail.)


There could be found other suspect log entries in the exim log:

2023-02-21 13:39:03 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:04 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:04 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
No supported cipher suites have been found.
2023-02-21 13:39:05 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:07 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:07 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
No supported cipher suites have been found.
2023-02-21 13:39:08 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.



=

email at ow...@bugs.debian.org

=


Hello Debian BTS administrators,

can you please check the log files of the mail system for a missing email?
It shoud have been send at 21 Feb 2023 13:45:01 UTC


It is regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031718
Normally I get emails from the BTS engine without any problem.
As you can see the email for submit was received and processed by the 
system.


The log for this submit mail is:

2023-02-21 14:41:44 1pUSXU-002AnH-Kx => sub...@bugs.debian.org 
R=dnslookup T=remote_smtp H=buxtehude.debian.org [209.87.16.39] 
X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no 
DN="C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=buxtehude.debian.org,EMAIL=hostmas...@buxtehude.debian.org" K 
C="250- 7971 byte chunk, total 7971\\n250 OK id=1pUSts-00Ad0p-7V"

2023-02-21 14:41:44 1pUSXU-002AnH-Kx Completed

The exact error why the mail response fails would help to solve the bug 
1031718.



Thank you for your help and support

karsten



Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Sam Hartman
> "Michael" == Michael Biebl  writes:
Michael> Excluding packages that only ship overrides/drop-ins, this
Michael> makes 37 affected packages in bookworm.

If I'm understanding this issue correctly, the concern would be a
package that moved from /lib/systemd/system to /usr/lib/systemd/system.
Under the TC resolution, that should not be happening for bookworm.

At least some of those packages are new services that have never been in
/lib/systemd/system.  I believe for example pam is in that set.

That's presumably not going to break something in the way that a file
moving between /lib and /usr/lib is.
But we don't want to encourage that movement.

It seems like knowing how many incorrect moves we've had would also be
valuable--how many things that used to be in /lib/systemd but are now
appearing in /usr/lib.



Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

2023-02-21 Thread Rob Landley
On 2/20/23 09:35, Alex Colomar wrote:
> On 2/20/23 15:29, Stefan Puiu wrote:
>> Hi Alex,
> 
> Hi Stefan,
> 
>>> 4 KiB is not that much better than 4096, since 4096 is easy to read.
>>> For higher numbers such as 33554432, it becomes more important to use 32 
>>> KiB.
>>> For consistency, using 4 KiB seems reasonable.
>> 
>> How about using KiB / MiB over a certain number of digits? It seems
>> excessive to use them everywhere.
> 
> We might do that.  So far, I prefer having the patches change 
> everything, and then we can later discuss about discarding part of them.

If you're going to tell people to learn something new: 1<<10 is a kilobyte,
1<<20 is a megabyte, 1<<30 is a gigabyte, and so on. I've sometimes used
16*(1<<30) for clarity.

>> Also, for the record, I had no idea what KiB / MiB means and how it's
>> different from KB/MB until this discussion.

Very few people do. Some people have been trying to make "fetch" happen for many
years, but it didn't. (Part of the reason is kibybyte/mebibyte/gibibyte are
minor tongue twisters, they're physically harder to say, so nobody does.)

>> I googled it before
>> writing this reply, and found this among the first hits:
>> https://ux.stackexchange.com/a/13850.
> 
> That answer was written more than a decade ago.  These days, binary 
> prefixes are more common.  In fact, I'd say most GNU/Linux commands

"First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it's a great symbolic gesture." - Linus Torvalds

(Still there in Documentation/process/coding-style.rst.)

GNU has nothing to do with Linux, and never did. Stallman has a history of
taking credit for other people's work:

https://functional.cafe/@tfb/109897415359142549

> respect them (an important exception being GNU coreutils (for example 
> ls(1)).  But many programs use prefixes accurately, such as fdisk(8).
> 
> In the Linux man-pages we have units(7), which documents these.  Maybe 
> that page should be more known.

FYI Michael Kerrisk last updated https://github.com/mkerrisk in 2021. It is now
2023. He still posts monthly proof-of-life to
https://twitter.com/mkerrisk/with_replies but hasn't replied to man-pages email
in the past year that I am aware of?

Dunno why. I emailed to ask, but...

> BTW, that answer is inaccurate (at least today): drive manufacturers 
> have the distinction pretty clear, and use it precisely (with lawsuits 
> won thanks to this); they use metric prefixes, because they mean it. 
> They can sell you 1 TB instead of 1 TiB, and most people won't even 
> know, but those who know, will know that 1 TB is 1'000'000'000'000 B, 
> which is what you get.

Remember when the dictionaries gave in on "literally" meaning "an emphatic form
of figuratively"? What's the "kibybyte" equivalent we all switched to there for
clarity?

We say "metric ton" and "imperial ton". We say "degrees farenheit" and "degrees
celsius". The celsius people didn't come up with a different word for degree,
yet somehow we all survived...

> They have no incentives to sell 1 TiB drives, 
> because they are visually almost the same, but there's around 9.95% more 
> bytes, so it's more expensive to produce.  It's not worth it for them.

"No, a _bud_ lite..."

>> I would say making the docs easy to understand for users is more
>> important than adhering to some specs users might not be familiar
>> with.
> 
> Well, using MiB prompts readers to use their search engine to learn what 
> that is (that's how I learnt it the first time; and that's what one does 
> when reading a book and finding a new word).

"They'll google it" is the modern version of "they'll read the documentation".
They will not, you're just delegating blame.

Rob

P.S. Maybe this is a generational thing? Are the kids saying "kibibyte" in high
school these days? I know that "hacker means computer breakin specialist" is
something a small number of boomers will resist to the death despite a google
news search only pulling up one meaning in general usage. And the "two spaces
after period" thing old hands cling to will only end when they die despite the
chicago manual of style, the AP stylebook, the MLA handbook, and the APA
publication manual all agreeing its' been one space after a period for decades
now. But maybe "kibibyte" is more than a shibboleth to somebody somewhere...



Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize

2023-02-21 Thread Theodore Ts'o
On Tue, Feb 21, 2023 at 12:17:20PM +, Christopher Obbard wrote:
> Control: severity -1 important
> Control: retitle -1 e2fsprogs generates filesystems which cannot be
> mounted on systems with older e2fsprogs
> 
> It turns out for debos the situation is a bit different. Since debos
> uses packages on the host to prepare the partitions, new features in 
> e2fsprogs from unstable which are unsupported in the target suite
> causes the built system to not boot.
> 
> One such failure at boot-time of a Debian testing system is when
> systemd-fsck tries to check a filesystem, it fails to mount the device:
> 
>   /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12
> 
> So, in short we cannot run images built for suites with older e2fsprogs
> on a host system which has e2fsprogs >=1.47.0-1.
> 
> Fixing grub2 will not fix the issue for debos, so I have retitled the
> bug.
> 
> In debos with newer e2fsprogs, we can set the following flag on a
> partition to disable the feature which allows the system running older
> e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this
> flag:
> 
>   features: [ "^orphan_file" ]
> 
> So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards
> compatibility.

E2fsprogs is always going to be adding new features.  Even if I dumb
down /etc/mk2fs.conf to not enable this feature in Bookworm, it *will*
enable this new feature in the next release of Debian.  This is true
for all file systems; we add new features to improve user experience.

So packages that are creating file systems to be consumed by older
target OS's must either (a) be aware of these changes for all file
systems (for example XFS is enabling the "bigtime" feature by default
in Bookworm to fix y2038 bug by expanding the size of the timestamp in
their inodes), OR, (b) run the mke2fs from the target OS in build
chroot.

This might get tricky for some target OS's, such as for example, GNU
Hurd, but the Hurd *absolutely* needs to either use mkfs.ext4 from
Hurd, or if you are using the mke2fs from Linux, you'll need
"mkfs.ext2 -O hurd".

The assumption that mkfs's from file systems never change and provide
full backwards compatibility for all target OS's is very much an
anti-pattern.

Best regards,

- Ted



Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k

2023-02-21 Thread Sean Whitton
Hello,

On Sun 19 Feb 2023 at 07:52PM +01, John Paul Adrian Glaubitz wrote:

> git-annex currently FTBFS on m68k with an error message that indicates that 
> some
> build dependencies are missing:
>
> Configuring git-annex-10.20230126...
> Setup: Encountered missing or private dependencies:
> clientsession,
> wai,
> wai-extra,
> warp >=3.2.8,
> warp-tls >=3.2.2,
> yesod >=1.4.3,
> yesod-core >=1.6.0,
> yesod-form >=1.4.8,
> yesod-static >=1.5.1
>
> Looking at debian/control, these build dependencies are for some reason only 
> enabled
> for a subset of architectures, namely those where the build dependency 
> doesn't arise

Joey, do you know why d/control restricts these build deps as it does?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1031737: Wrong margin character for changed text in man pages

2023-02-21 Thread Bjarni Ingi Gislason
Package: tcl8.6-doc
Version: 8.6.13+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  Displaying man page "chan.3tcl" with the next version (candidate) of
groff (1.23.0).

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

(test-nroff is in the git repository)

test-nroff -man -b -ww /tmp/chan.3tcl

   * What was the outcome of this action?

See later

   * What outcome did you expect instead?

  To see '|' at the right margin for changed text.



   The macro 'VS' contains the line

.ie n 'mc \s12\(br\s0

1) There is no type size change in nroff mode, so "\s12" does not change
the type size, that is, it stays unchanged.

2) The next version of "groff" (pending) interprets "\s12" as "\s1"
with an added text "2", which means, the digit "2" is printed instead
of "\(br" (same as '|').

  Example from "chan.3tcl":

deletes all existing file-events registered on the channel.  If  2

  and warnings (if the man option "--warnings=w" and environmental
variable "MAN_KEEP_STDERR=yes" are used):

troff: backtrace: '/tmp/chan.3tcl':150: macro 'VS'
troff: backtrace: file '/tmp/chan.3tcl':304
troff:/tmp/chan.3tcl:304: warning: expected numeric expression, got a
special character
troff: backtrace: '/tmp/chan.3tcl':150: macro 'VS'
troff: backtrace: file '/tmp/chan.3tcl':352
troff:/tmp/chan.3tcl:352: warning: expected numeric expression, got a
special character

###

  The fix is to drop the type size change and use

.ie n 'mc \(br

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

Kernel: Linux 6.1.7-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

tcl8.6-doc depends on no packages.

tcl8.6-doc recommends no packages.

Versions of packages tcl8.6-doc suggests:
ii  tcl8.6  8.6.13+dfsg-2

-- no debconf information



Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Michael Biebl

Am 21.02.23 um 17:45 schrieb Sam Hartman:

"Michael" == Michael Biebl  writes:

 Michael> Excluding packages that only ship overrides/drop-ins, this
 Michael> makes 37 affected packages in bookworm.

If I'm understanding this issue correctly, the concern would be a
package that moved from /lib/systemd/system to /usr/lib/systemd/system.


Well, not really. I'm concerned about packages shipping files in 
/usr/lib/systemd/system and expecting that those services are properly 
enabled/started/restarted/stopped.






OpenPGP_signature
Description: OpenPGP digital signature


Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-02-21 Thread Sam Hartman
> "Michael" == Michael Biebl  writes:

Michael> Am 21.02.23 um 17:45 schrieb Sam Hartman:
>>> "Michael" == Michael Biebl  writes:
Michael> Excluding packages that only ship overrides/drop-ins, this
Michael> makes 37 affected packages in bookworm.
>> 
>> If I'm understanding this issue correctly, the concern would be a
>> package that moved from /lib/systemd/system to
>> /usr/lib/systemd/system.

Michael> Well, not really. I'm concerned about packages shipping
Michael> files in /usr/lib/systemd/system and expecting that those
Michael> services are properly enabled/started/restarted/stopped.

I appreciate that is your concern.
However, it would be easier to work with you if you expressed empathy
and understanding for the other related concerns in the space.
My understanding is that the reason this is not a trivially accepted
patch is related to usrmerge and the issue I brought up.
Have I got that right?



Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

2023-02-21 Thread James Addison
Package: python3-dateutil
Followup-For: Bug #1003044
Control: tags -1 moreinfo

On Tue, 21 Feb 2023 00:35:16 +, James Addison wrote:
> The repro step attempted was to open a Python interpreter session and to 
> enter:
>   from matplotlib.dates import DateFormatter
>
> (that succeeded and did not emit any output)

OK: that wasn't a hugely useful comment; a more thorough date formatting
example would have been more convincing.

...the 'date_index_formatter.py'[1] example code included in the 'matplotlib'
source is a better candidate: and it also completes successfully without errors
when run using version 2.8.2-1 of the python3-dateutil package.

Given that python3-dateutil is depended-upon by a reasonably large number of
other packages, I'm reluctant to reduce the severity of this bug, but at the
same time, it's unclear what the extent of the breakage is here.

[1] - 
https://sources.debian.org/src/matplotlib/3.6.3-1/examples/ticks/date_index_formatter.py/



Bug#1030047: ruby-sanitize: CVE-2023-23627

2023-02-21 Thread duck

Quack Salvatore,

Thanks for the patch, it looks good.
I'm in the Ruby team but not involved in this particular package but I 
think we can let your NMU flow.

It's causing havoc on other packages so the sooner the better :-).

Regards.
\_o<

--
Marc Dequènes



Bug#1031738: installation-guide: documentation about limits to kernel boot parameters is outdated

2023-02-21 Thread James Addison
Source: installation-guide
Version: 20220129~deb11u1
Severity: normal
Tags: d-i patch

Dear Maintainer,

Some of the documentation related to limits in Linux kernel boot parameters in
the installation guide is outdated.

For example, the section describing[1] use of boot parameters for preseeding
references the 2.6.9 kernel in a callout note.

Please find attached a patch to update two such documentation sections.

Thanks,
James

[1] - 
https://www.debian.org/releases/bullseye/amd64/apbs02.en.html#preseed-bootparms
>From 55dbd6dae622cfb40e3397bc98e4e053b14ad45c Mon Sep 17 00:00:00 2001
From: James Addison 
Date: Tue, 21 Feb 2023 18:07:01 +
Subject: [PATCH] linux-kernel: update notes related to command-line limits

---
 en/appendix/preseed.xml  | 9 +
 en/boot-installer/parameters.xml | 9 +
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index 0a4582149..1ed69b83b 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -367,10 +367,11 @@ out any options (like preconfiguration options) that it 
recognizes.
 
 
 
-Current linux kernels (2.6.9 and later) accept a maximum of 32 command line
-options and 32 environment options, including any options added by default
-for the installer. If these numbers are exceeded, the kernel will panic
-(crash). (For earlier kernels, these numbers were lower.)
+Debian-built Linux kernels accept up to the default maximum of 32 command line
+options and 32 environment options. If these numbers are exceeded, the kernel
+will fail to boot. Additionally, there is an architecture-dependent limit to
+the number of characters for the entire kernel command line; command-lines
+longer than this limit are silently truncated.
 
 
 
diff --git a/en/boot-installer/parameters.xml b/en/boot-installer/parameters.xml
index 91d981406..18f87dc25 100644
--- a/en/boot-installer/parameters.xml
+++ b/en/boot-installer/parameters.xml
@@ -75,10 +75,11 @@ The installation system recognizes a few additional boot 
parameters
 
 
 
-With current kernels (2.6.9 or newer) you can use 32 command line options and
-32 environment options. If these numbers are exceeded, the kernel will panic.
-Also there is a limit of 255 characters for the whole kernel command line,
-everything above this limit may be silently truncated.
+Debian-built Linux kernels accept up to the default maximum of 32 command line
+options and 32 environment options. If these numbers are exceeded, the kernel
+will fail to boot. Additionally, there is an architecture-dependent limit to
+the number of characters for the entire kernel command line; command-lines
+longer than this limit are silently truncated.
 
 
 
-- 
2.39.1



Bug#1031739: linux: Please enable DLM kernel module in cloud kernels

2023-02-21 Thread Vincent Caron
Package: linux
Severity: normal

Dear Maintainer,

I am in a situation where I am using a GFS2 cluster in virtual machines and
realized I couldn't do it with the 'cloud' kernel because the 'dlm'
kernel module is not present in this flavour. It does work when I switch
to the bare-metal kernel.

Other distributed fs might require 'dlm' (OCFS2 comes to mind). It's a
handy tool when you can mount the same NAS-like (Ceph, etc) on multiple
virtual machines and avoid SPOFy NFS configurations this way.

The diff between the bare-metal and cloud configs seem to be :

CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
CONFIG_GFS2_FS_LOCKING_DLM=y

On an AMD64 Bullseye system, the /lib/modules part of the cloud kernel
weights 72584 kB and adding the dlm.ko modules seems it would add 480 kB
which is not negligible (+0.7%).


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

Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#1031697: Acknowledgement (libx11-xcb1: Please update to 1.8.4 - Apps crashing under wayland due to bugs caused by patches in 1.8.3)

2023-02-21 Thread Safir Secerovic
Hello again,

I forgot to mention that I did leave out:
--disable--thread-safety-constructor configure option from debian/rules
file
along with removing the two patches [1] when rebuilding from the current
debian source package (1.8.3).

Regards,
Safir

[1]
0003-Revert-Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch
0004-Revert-Allow-X-IfEvent-to-reenter-libX11.patch



On Mon, Feb 20, 2023 at 1:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1031697:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031697.
>
> 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.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   stephanlach...@debian.org, tjaal...@debian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian X Strike Force 
>
> If you wish to submit further information on this problem, please
> send it to 1031...@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.
>
> --
> 1031697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031697
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


Bug#1031740: fceux usage of sanitizers might introduce vulnerabilities

2023-02-21 Thread Adrian Bunk
Package: fceux
Version: 2.6.5+dfsg1-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

fceux (2.6.5+dfsg1-1) unstable; urgency=medium
...
  * enable compiler address sanitizer (ASAN)


Package: fceux
Version: 2.6.5+dfsg1-1
Depends: libasan8, ..., libubsan1 (>= 8),...


This is a bad idea not only due to slow execution and a factor 20
in binary size, but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9



Bug#1030273:

2023-02-21 Thread Alexander Beerhoff
Hi, the problem seems solved with linux-image-6.1.0-5-amd64

-- 
Umi sukoschi
Niwa ni izumi no
Ko no ma ka na


Bug#1031509: [Pkg-clamav-devel] Bug#1031509: ETA on Patch for Buster

2023-02-21 Thread Sebastian Andrzej Siewior
+LTS

On 2023-02-20 12:22:48 [+0200], Andries Malan wrote:
> Hi There
Hi,

> Would you be so kind as to provide an ETA for the above mentioned bug that
> was reported.
> This would be greatly appreciated.

I Cced the LTS team because Buster is LTS territory.

> Regards

Sebastian



Bug#1031741: goxel: usage of sanitizers might introduce vulnerabilities

2023-02-21 Thread Adrian Bunk
Package: goxel
Version: 0.10.6-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Package: goxel
Version: 0.10.6-3
Depends: libasan6 (>= 10), ...,libubsan1 (>= 8)

This is a bad idea not only due to slow execution and a factor 20
in binary size, but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9

This was likely unintentional due to debug=0 no longer working,
which resulted in a debug build without compiler optimization
and with sanitizers enabled after
https://github.com/guillaumechereau/goxel/commit/44745ead64b63083ccb48e8c7988d080674d795d

Replacing debug=0 with mode=release in debian/rules makes not
using the debug mode working again.

It needs an additional werror=0 due to gcc finding more issues
during compilation when optimization is enabled.

As a side effect, fixing this bug should make the package build
on all architectures again (several architectures no longer built
due to the sanitizers being unavailable or broken).



Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?

2023-02-21 Thread GCS
On Tue, Feb 21, 2023 at 1:27 PM Adrian Bunk  wrote:
> Looking at #1028371, should generated dependencies on python3-protobuf be
>   python3-protobuf (>= 3.21), python3-protobuf (<< 3.22)
 You mean on python3-bernhard, right?

> to ensure that the binary package is used with the same version
> as the protobuf-compiler used during the build?
 Then what? It would become uninstallable when a new protobuf version
(3.22 next time) is uploaded and built.

> If yes, are other language bindings also affected by this problem?
 I still don't get your point. How does a language binding package
version relate to the protobuf-compiler version? I don't follow the
internals of Protobuf, but I would say it's more related to the
library soname and its provided API version.

Regards,
Laszlo/GCS



Bug#1031742: Please make reboot command configurable

2023-02-21 Thread Andras Korn
Package: unattended-upgrades
Version: 2.9.1+nmu3
Severity: wishlist

Hi,

not all flavours of shutdown(8) support a time argument; for example, runit's 
only supports 'now' or no time.

When unattended-upgrades tries to schedule a reboot on runit systems, 
shutdown(8) prints an error, causing unattended-upgrades to become sad.

I'd like to provide my own mechanism for scheduling reboots (e.g. via at(1)). 
Please add a config tunable for this.

Thanks!

András

-- System Information:
Init: runit (via /run/runit.stopit)

-- 
 Keves, mint terdkalacsban a mazsola.



Bug#826902: Blorbtools

2023-02-21 Thread David Griffith



I've since put these Perl scripts into a package called "Blorbtools".  See 
https://gitlab.com/DavidGriffith/blorbtools



--
David Griffith
d...@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



Bug#1031743: python3.11-minimal: Python 3.11 should be compiled as a PIE, but it is not

2023-02-21 Thread j.fikar
Package: python3.11-minimal
Version: 3.11.1-2
Severity: normal
X-Debbugs-Cc: j.fi...@gmail.com

Dear Maintainer,

if I understood it correctly, the Python 3.10 and later should be compiled as
PIE (position independent executable). That is why there are the new packages
python3-nopie, python3.10-nopie, and 3.11-nopie.

But 3.11 is not a PIE. I checked arm64, amd64, armhf, armel, and i386
architectures.

$ file /usr/bin/python3.11
/usr/bin/python3.11: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=8dad83d75a00e6b5e26095c79dee978a8d57ef7d, for GNU/Linux 3.7.0,
stripped

The same is true for Sid version python3.11-minimal (3.11.2-4). The hardening-
check is reporting the same.

On the contrary, python3.10-minimal (3.10.9-1) is correctly a PIE

$ file /usr/bin/python3.10
/usr/bin/python3.10: ELF 64-bit LSB pie executable, ARM aarch64, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=7d2767e751dbd5c9287dbe5cd8de9022faa9d042, for GNU/Linux 3.7.0,
stripped


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

Kernel: Linux 5.19.0-28-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3.11-minimal depends on:
ii  libc6  2.35-0ubuntu3.1
ii  libexpat1  2.4.7-1ubuntu0.2
pn  libpython3.11-minimal  
ii  zlib1g 1:1.2.11.dfsg-2ubuntu9.2

Versions of packages python3.11-minimal recommends:
pn  python3.11  

Versions of packages python3.11-minimal suggests:
ii  binfmt-support  2.2.1-2



Bug#1031744: httpdirfs: usage of ubsan might introduce vulnerabilities

2023-02-21 Thread Adrian Bunk
Package: httpdirfs
Version: 1.2.4-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Package: httpdirfs
Version: 1.2.4-2
Depends: ..., libubsan1 (>= 8), ...


This is a bad idea not only due to slower execution,
but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9

While there are safe usages of ubsan, httpdirfs being the
only package in the archive that uses ubsan but not asan
is something that sounds wrong and underreviewed.



Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'

2023-02-21 Thread Samuel Henrique
Hello Julien,

> This is fixed in git, I need to get around to uploading an update.

Are you also planning to update the certificates for bookworm?

I'm asking as we are already in the freeze and there are a few
bugreports about old certificates that need to be dropped[0][1] (and I
assume there's also a bunch of new ones we need to get).

Are you looking into help maintaining the package as well?

[0] https://bugs.debian.org/1021749
[1] https://bugs.debian.org/1023945

Thank you,

-- 
Samuel Henrique 



Bug#1031706: optuna: test_create_new_trial randomly fails on s390x

2023-02-21 Thread Gard Spreemann

"Rebecca N. Palmer"  writes:

> test_create_new_trial (both parts) sometimes fails on s390x, failing
> the autopkgtest.
>
> It might make sense to remove this package on s390x, if it isn't
> reasonable to actually fix this.

Thanks for the report! I've brought this to upstream's attention [1],
but I'm a bit confused as the upstream tests seem to make some
surprising assumptions about monotonicity of `datetime.now()` [2]. I'll
hold off on further investigation until I've figured out whether I've
just misunderstood something on their part.

In the worst case I'll disable autopkgtests – or this particular test –
on s390x.

[1] https://github.com/optuna/optuna/issues/4453

[2] https://github.com/optuna/optuna/issues/4455



 Best,
 Gard


signature.asc
Description: PGP signature


Bug#1031732: iortcw: CVE-2019-25104

2023-02-21 Thread Moritz Muehlenhoff
On Tue, Feb 21, 2023 at 03:32:01PM +, Simon McVittie wrote:
> On Tue, 21 Feb 2023 at 16:09:30 +0100, Moritz Mühlenhoff wrote:
> > CVE-2019-25104[0]:
> > https://github.com/rtcwcoop/rtcwcoop/pull/45
> 
> This looks like a denial of service via memory exhaustion when running
> a multiplayer server. For a game from 2001, I would personally say this
> is normal or even minor severity: it isn't really realistic to expect
> a game this old to not be crashable.
> 
> I'm also not at all sure that iortcw is even vulnerable to this.

Please adjust the severity (and or close if not applicable at all) as
necessary, I have no insight on iortcw but only saw the CVE in the triage
of the incoming CVE feed and filed this bug to clarify impact on Debian's
packaged fork.

Cheers,
Moritz



Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

2023-02-21 Thread Sandro Tosi
On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer  wrote:
>
> On Sat, 7 Jan 2023 03:34:19 -0500 Sandro Tosi  wrote:
> > > python-dateutil expects to have 'dateutil-zoneinfo.tar.gz' in it's 
> > > directory
> > > tree, but this file is removed in the packaging.
> > >
> > > Error:
> > > "/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: 
> > > UserWarning:
> > > I/O error(2): Datei oder Verzeichnis nicht gefunden
> > >   warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))"
> > >
> > > Using: "matplotlib.dates import DateFormatter"
> >
> > indeed this is breaking matplotlib, thus the grave severity. it needs
> > to be addressed for bookworm
>
> How exactly does this break matplotlib?

it produces output on stderr, which many tools consider it an error
and fails build.

> dateutil.zoneinfo really shouldn't be used directly and I don't see any

can you back this quote please? zoneinfo is part of the public API,
and just breaking it (via the removal of the zonefile) and say not to
use it is going in the wrong direction.

> I guess we have two options if we want to change the current behavior:
> 1) Ship the outdated tzdata tarball even though nothing should really use it.
> 2) Add a patch to remove the dateutil.zoneinfo fallback.

i think you're missing

3) fix dateutil.zoneinfo to use a system-available zone info file

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#998105: The issue persists, was Re:

2023-02-21 Thread Sven Geuer
Control: reopen -1 =

Hello Christian,

On Fri, 20 Jan 2023 11:01:33 + c.bu...@posteo.jp wrote:
> Dear Sven,
> 
> there is a new release 1.3.3 in "unstable" branch of Debian.
> 
> Can you please try to reproduce the problem with that version and
> then report back.
> 
> Thanks
> Christian

Unfortunately BiT version 1.3.3 still fails with a version of python3-
keyring offering keyring.backends.chainer.

Debug output:

   $ backintime-qt --debug
   DEBUG: [common/backintime.py:589 argParse] Arguments: {'debug': True} | 
unknownArgs: []
   
   Back In Time
   Version: 1.3.3
   
   Back In Time comes with ABSOLUTELY NO WARRANTY.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `backintime --license' for details.
   
   DEBUG: [common/backintime.py:677 getConfig] config file: 
/home/sg/.config/backintime/config
   DEBUG: [common/backintime.py:678 getConfig] share path: 
/home/sg/.local/share/backintime
   DEBUG: [common/backintime.py:679 getConfig] profiles: 1=Hauptprofil
   DEBUG: [common/pluginmanager.py:240 PluginManager.load] Register plugin path 
/usr/share/backintime/plugins
   DEBUG: [common/pluginmanager.py:257 PluginManager.load] Add plugin 
qt4plugin.py
   DEBUG: [common/pluginmanager.py:257 PluginManager.load] Add plugin 
notifyplugin.py
   QSocketNotifier: Can only be used with threads started with QThread
   DEBUG: [qt/qttools.py:175 createQApplication] QT QPA platform plugin: wayland
   DEBUG: [qt/qttools.py:176 createQApplication] QT_QPA_PLATFORMTHEME=gnome
   DEBUG: [qt/qttools.py:178 createQApplication] QT_STYLE_OVERRIDE=
   DEBUG: [qt/qttools.py:179 createQApplication] QT active style: fusion
   DEBUG: [qt/qttools.py:180 createQApplication] QT fallback style: Adwaita
   DEBUG: [qt/qttools.py:181 createQApplication] QT supported styles: 
['Windows', 'Fusion']
   DEBUG: [qt/qttools.py:182 createQApplication] themeSearchPaths: 
['/usr/share/icons', ':/icons']
   DEBUG: [qt/qttools.py:183 createQApplication] fallbackSearchPaths: []
   DEBUG: [qt/qttools.py:185 createQApplication] Is SystemTray available: False
   DEBUG: [qt/qttools.py:197 createQApplication] Trying to set App ID for 
non-privileged user
   DEBUG: [common/tools.py:862 keyringSupported] Available keyring backends:
   DEBUG: [common/tools.py:865 keyringSupported] keyring.backends.fail.Keyring 
(priority: 0)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.chainer.ChainerBackend (priority: 10)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.SecretService.Keyring (priority: 5)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.libsecret.Keyring (priority: 4.8)
   DEBUG: [common/tools.py:878 keyringSupported] Metaclass 
keyring.backends.Gnome.Keyring not found: AttributeError("module 
'keyring.backends' has no attribute 'Gnome'")
   DEBUG: [common/tools.py:880 keyringSupported] Metaclass 
keyring.backends.kwallet.Keyring not found: AttributeError("module 
'keyring.backends.kwallet' has no attribute 'Keyring'")
   DEBUG: [common/tools.py:884 keyringSupported] Metaclass 
keyring.backend.SecretServiceKeyring not found: AttributeError("module 
'keyring.backend' has no attribute 'SecretServiceKeyring'")
   DEBUG: [common/tools.py:886 keyringSupported] Metaclass 
keyring.backend.GnomeKeyring not found: AttributeError("module 
'keyring.backend' has no attribute 'GnomeKeyring'")
   DEBUG: [common/tools.py:888 keyringSupported] Metaclass 
keyring.backend.KDEKWallet not found: AttributeError("module 'keyring.backend' 
has no attribute 'KDEKWallet'")
   DEBUG: [common/tools.py:899 keyringSupported] Available supported backends: 
[, ]
   DEBUG: [common/tools.py:905 keyringSupported] No appropriate keyring found. 
'keyring.backends.chainer' can't be used with BackInTime
   [...]

I still need to pin python3-keyring to use
keyring.backends.SecretService.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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


Bug#923824: libdancer2-plugin-database-perl: FTBFS randomly (failing tests)

2023-02-21 Thread Étienne Mollier
Control: tags -1 confirmed
Control: forwarded -1 
https://github.com/bigpresh/Dancer-Plugin-Database/issues/102

It took me several retries before triggering, but I ended up
hitting the same case of test failure, so it looks pretty much
hardware independent.  This looks to affect autopkgtest as well
on occasions[1], so can be annoying during testing migrations.
Upstream has been made aware of the issue at some point, but no
feedback from them so far.  I'm not sure how to fix that myself,
but we may be notified eventually if the issue is closed
upstream thanks to bts triage.

[1]: 
https://ci.debian.net/data/autopkgtest/testing/amd64/libd/libdancer2-plugin-database-perl/31340832/log.gz

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature


Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

2023-02-21 Thread James Addison
Source: feynmf
Followup-For: Bug #1029439

Assuming that we want to keep the feynmf sources as-is (I think we do;
feynmf.dtx hasn't changed[1] since 1996, a sign of stability), then this bug
seems like a regression in another component.

Looking at the build logs for a failure-to-build[2] in this thread and a
previous successful build[3], it looks like there's some divergence after
this common line of output:

  Writing index file fmfmanps.idx

And, reading a few lines below that in what I'm guessing is a LaTeX call stack
(a series of package names, one-per-line), the common element that both call
stacks originate from is 'l3backend-dvips.def', part of the latex3[4] codebase.

My guess would be that something in latex3 has changed over the course of the
past year or two that has introduced this problem as a side-effect.

The 'l3backend-dvips.def' file is currently part of the 'texlive-latex-base'
Debian package.

[1] - https://www.ctan.org/tex-archive/macros/latex/contrib/feynmf

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029439#5

[3] - 
https://buildd.debian.org/status/fetch.php?pkg=feynmf&arch=all&ver=1.08-13&stamp=1636243992&raw=0

[4] - https://github.com/latex3/latex3/



Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)

2023-02-21 Thread Samuel Henrique
Hello Guido,

> You need to fixup the tests too though

I have updated the Github PR and also attached the new patch with the
unit tests fixed.

Thank you,

-- 
Samuel Henrique 
From b2a7100730306d7e333ce84c00ccdaf693e6f081 Mon Sep 17 00:00:00 2001
From: Samuel Henrique 
Date: Mon, 1 Aug 2022 18:49:19 +0100
Subject: [PATCH] Fix RPM changelog header format (missing dash before version)

 As stated in the documentation at:
 https://rpm-packaging-guide.github.io/#working-with-spec-files

 "...
 Follow this format for the first line:

 * Day-of-Week Month Day Year Name Surname  - Version-Release
 ..."
---
 gbp/rpm/policy.py  |  2 +-
 tests/30_test_rpm_changelog.py | 26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py
index a2155e20..59989bb8 100644
--- a/gbp/rpm/policy.py
+++ b/gbp/rpm/policy.py
@@ -85,7 +85,7 @@ class Changelog(object):
 body_name_re = r'\[(?P.*)\]'
 
 # Changelog header format (when writing out changelog)
-header_format = "* %(time)s %(name)s <%(email)s> %(revision)s"
+header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s"
 header_time_format = "%a %b %d %Y"
 header_rev_format = "%(version)s"
 
diff --git a/tests/30_test_rpm_changelog.py b/tests/30_test_rpm_changelog.py
index 85142a41..2a0d068d 100644
--- a/tests/30_test_rpm_changelog.py
+++ b/tests/30_test_rpm_changelog.py
@@ -34,7 +34,7 @@ def test_str_format(self):
 time = datetime(2014, 1, 29, 12, 13, 14)
 header = _ChangelogHeader(RpmPkgPolicy, time, name="John Doe",
   email="u...@host.com", revision="1")
-eq_(str(header), "* Wed Jan 29 2014 John Doe  1\n")
+eq_(str(header), "* Wed Jan 29 2014 John Doe  - 1\n")
 
 def test_str_format_err(self):
 """Test missing properties"""
@@ -79,7 +79,7 @@ def setup(self):
 def test_str_format(self):
 """Basic test"""
 section = self.default_sect
-eq_(str(section), "* Wed Jan 29 2014 J. D.  1\n- my change\n\n")
+eq_(str(section), "* Wed Jan 29 2014 J. D.  - 1\n- my change\n\n")
 
 def test_append_entry(self):
 """Test add_entry() method"""
@@ -87,7 +87,7 @@ def test_append_entry(self):
 entry = _ChangelogEntry(RpmPkgPolicy, author="",
 text="- another\n  change")
 new_entry = section.append_entry(entry)
-eq_(str(section), "* Wed Jan 29 2014 J. D.  1\n- my change\n"
+eq_(str(section), "* Wed Jan 29 2014 J. D.  - 1\n- my change\n"
   "- another\n  change\n\n")
 eq_(new_entry, section.entries[-1])
 
@@ -96,25 +96,25 @@ def test_set_header(self):
 section = self.default_sect
 time = datetime(2014, 1, 30)
 section.set_header(time=time, name="Jane", email="u@h", revision="1.1")
-eq_(str(section), "* Thu Jan 30 2014 Jane  1.1\n- my change\n\n")
+eq_(str(section), "* Thu Jan 30 2014 Jane  - 1.1\n- my change\n\n")
 
 
 class TestChangelogParser(object):
 """Test the default changelog parser"""
 
 cl_default_style = """\
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 - Drop foo.patch
 
-* Tue Jan 28 2014 Markus Lehtonen  0.2
+* Tue Jan 28 2014 Markus Lehtonen  - 0.2
 - Update to 0.2
 
-* Mon Jan 27 2014 Markus Lehtonen  0.1
+* Mon Jan 27 2014 Markus Lehtonen  - 0.1
 - Initial version
 """
 cl_with_authors = """\
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 [Markus Lehtonen]
 - Version bump
 [John Doe]
@@ -122,17 +122,17 @@ class TestChangelogParser(object):
 """
 # Invalid timestamp / name
 cl_broken_header_1 = """\
-* Wed Jan 29 2014Markus Lehtonen  0.3-1
+* Wed Jan 29 2014Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Whitespace before the asterisk in the header
 cl_broken_header_2 = """\
- * Wed Jan 29 2014 Markus Lehtonen  0.3-1
+ * Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Invalid timestamp
 cl_broken_header_3 = """\
-* Wed Jan 32 2014 Markus Lehtonen  0.3-1
+* Wed Jan 32 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Missing email
@@ -143,7 +143,7 @@ class TestChangelogParser(object):
 # Garbage before section header
 cl_broken_header_5 = """\
 ---garbage---
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 
@@ -222,5 +222,5 @@ def test_add_section(self):
 time = datetime(2014, 1, 30)
 new_section = changelog.add_section(time=time, name="Jane Doe",
 email="j...@doe.com", revision="1.2")
-eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe  1.2\n\n")
+eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe  - 1.2\n\n")
 eq_(new_section, changelog.sections[0])


Bug#1031745: gdb: breaks rustc gdb debuginfo tests

2023-02-21 Thread Fabian Grünbichler
Package: gdb
Version: 13.1-1
Severity: serious
Control: affects -1 src:rustc
Justification: breaks unrelated software

While preparing an update to rustc 1.65 for experimental, we noticed
that the recent gdb update in sid makes rustc FTBFS by causing 5 of its
gdb-integration test cases fail.

test [debuginfo-gdb] src/test/debuginfo/destructured-fn-argument.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/function-arguments.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-stack-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-unique-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/unsized.rs ... FAILED
command did not execute successfully: 
"/<>/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" 
"--compile-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"
 "--rustc-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" 
"/<>/src/test/debuginfo" "--build-base" 
"/<>/build/x86_64-unknown-linux-gnu/test/debuginfo" "--stage-id" 
"stage2-x86_64-unknown-linux-gnu" "--suite" "debuginfo" "--mode" "debuginfo" 
"--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" 
"--llvm-filecheck" "/usr/lib/llvm-15/bin/FileCheck" "--optimize-tests" 
"--linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--target-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" "src/tools/tidy" 
"--verbose" "--llvm-version" "15.0.7" "--llvm-components" "aarch64 
aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info 
aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser 
amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca 
amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler 
arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc 
avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf 
bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen core 
coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf 
debuginfopdb demangle dlltooldriver dwarflinker dwp engine executionengine 
extensions filecheck frontendopenacc frontendopenmp fuzzercli fuzzmutate 
globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc 
hexagondisassembler hexagoninfo instcombine instrumentation interfacestub 
interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc 
lanaidisassembler lanaiinfo libdriver lineeditor linker lto m68k m68kasmparser 
m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit 
mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo 
mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler 
msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo 
objcarcopts objcopy object objectyaml option orcjit orcshared orctargetprocess 
passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc 
powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser 
riscvcodegen riscvdesc riscvdisassembler riscvinfo runtimedyld scalaropts 
selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler 
sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc 
systemzdisassembler systemzinfo tablegen target textapi transformutils ve 
veasmparser vecodegen vectorize vedesc vedisassembler veinfo webassembly 
webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler 
webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser 
x86codegen x86desc x86disassembler x86info x86targetmca xcore xcorecodegen 
xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" 
"" "--cflags" "" "--cxxflags" "" "--adb-path" "adb" "--adb-test-dir" 
"/data/tmp/work" "--android-cross-path" "" "--channel" "stable"

our rustc build uses an (arch-dependent) cut-off for the number of "allowed to
fail" tests - for amd64 it is 8, the current version of rustc in testing/sid
(1.63.0+dfsg1-2) had 2 such failing tests when it was initially built, a
rebuild with gdb from unstable causes the fail count to go to 8 - while not
failing the build itself, the errors look problematic enough to me that it
should likely be looked at more closely *before* gdb ends up in
testing/bookworm. it does also prevent us from getting through the backlog of
rustc upstream releases in experimental, since the baseline for rustc 1.65 test
failures is 4, and the 6 additional ones caused by gdb push it over the
threshold.

the same tests are failing for
- rustc 1.65 (not yet uploaded, MR on salsa[0] which successfully bui

Bug#1021582: closed by Piotr Ożarowski (fixed in 1.0.4-1)

2023-02-21 Thread Jelmer Vernooij
On Tue, Feb 21, 2023 at 06:12:30PM +, Debian Bug Tracking System wrote:
> Date: Tue, 21 Feb 2023 19:10:43 +0100
> From: Piotr Ożarowski 
> To: 1021582-d...@bugs.debian.org
> Subject: fixed in 1.0.4-1
> 
> Source: pytest-aiohttp
> Source-Version: 1.0.4-1
> 
> ups, looks like I hijacked your ITP. Sorry.
> If you want to comaintain or take over this package, just update it in
> DPT repo.
> 
> I needed this package as a build dependency for another package and
> apparently didn't check WNPP close enough

No worries, all good - thanks for packaging it! Your package ended up in the
archive before I managed to do duplicate work on it.

Cheers,

Jelmer



Bug#1031746: ITP: libdex -- Library for deferred execution

2023-02-21 Thread Jeremy Bícha
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: jeremy.bi...@canonical.com

Package Name: libdex-1-1 (etc)
Version: 0.1.0
Upstream Author: Christian Hergert
License: LGPL-2.1+
Programming Lang: C

Description: Library for deferred execution
 Dex is a library supporting "Deferred Execution" with the explicit goal of
 integrating with GNOME and GTK-based applications. It provides primatives
 for supporting futures in a variety of ways with both read-only and writable
 views. Additionally, integration with existing asynchronous-based APIs is
 provided through the use of wrapper promises.
 .
 "Fibers" are implemented which allows for writing synchronous looking code
 which calls asynchronous APIs from GIO underneath.

Other Info
--
This package will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/libdex

It is a required dependency for GNOME Builder 44.

Thanks,
Jeremy Bicha



Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

2023-02-21 Thread James Addison
Source: feynmf
Followup-For: Bug #1029439
X-Debbugs-Cc: debian-tex-ma...@lists.debian.org
Control: tags -1 help

I'm adding the 'help' tag to this bug, and am cc'ing the debian-tex-maint list,
because it feels like extra brainpower could aid in figuring this one out more
quickly.

A brief recap of this bug so far, for folks reading the list:

  * the feynmf Debian package is failing to build in testing (bookworm)
  * the bug may somehow be related to the mflogo TeX package
  * successful build logs are available on buildd.debian.org for comparison



Bug#1031415: FAI fix

2023-02-21 Thread Thomas Lange


In FAI, we cannot easily determine which mke2fs or grub version will
be used in the target system since we support deb and rpm based and
other linux distributions.

As I did with the older issues of mke2fs (metadata_csum) I will add a
comment, so the user can decide if he needs to add the option
-O ^metadata_csum_seed

In FAI this has to be done in the config examples (which goes into the
package fai-doc), not in the code itself. I therefore decrease the
severity to normal.

-- 
regards Thomas



Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

2023-02-21 Thread Felix Geyer

On 21.02.23 20:46, Sandro Tosi wrote:

it produces output on stderr, which many tools consider it an error
and fails build.


When raising the severity of a bug to grave I would expect some concrete details
on what exactly is broken instead of a hand-wavy "breaks some stuff".
But anyway let's focus on the issue.


dateutil.zoneinfo really shouldn't be used directly and I don't see any


can you back this quote please? zoneinfo is part of the public API,
and just breaking it (via the removal of the zonefile) and say not to
use it is going in the wrong direction.


https://dateutil.readthedocs.io/en/stable/zoneinfo.html#dateutil.zoneinfo.gettz
has a warning that you shouldn't use it.
For get_zonefile_instance() it only says "using the data provided by the
dateutil package". This implies that the data is outdated most of the time
since it's rarely updated. Unfortunately that's not clearly stated.

Of course it's part of the public API. Unfortunately its design leaves us only
with bad options.


I guess we have two options if we want to change the current behavior:
1) Ship the outdated tzdata tarball even though nothing should really use it.
2) Add a patch to remove the dateutil.zoneinfo fallback.


i think you're missing

3) fix dateutil.zoneinfo to use a system-available zone info file


It wouldn't be fixing it since the sole purpose of this API is to use the
bundled timezone database instead of the potentially absent (from a general POV,
of course the Debian package depends on tzdata) system timezone database.

I'm inclined to just ship the bundled timezone database with the package:

- We wouldn't have to permanently patch the code.
- dateutil consumers that just want accurate timezone information are supposed
  to use dateutil.tz.gettz() which already prefers the system database.
- Direct dateutil.zoneinfo users kind of opted into receiving outdated timezone
  information.

Felix



Bug#923824: libdancer2-plugin-database-perl: FTBFS randomly (failing tests)

2023-02-21 Thread Étienne Mollier
Control: tags -1 patch

It turned out I managed to find a workaround.  Putting it below
for ulterior reference if need be; few more details are
available on upstream bug tracker:

---8<--8<--8<--8<---
--- libdancer2-plugin-database-perl.orig/t/lib/TestApp.pm
+++ libdancer2-plugin-database-perl/t/lib/TestApp.pm
@@ -209,6 +209,9 @@
 var connection_failed => 1;
 };
 get '/database_connection_failed_fires' => sub {
+# Avoid catching an old handle which may not have expired yet
+database()->disconnect;
+sleep 0.2;
 # Give a ridiculous database filename which should never exist in order to
 # force a connection failure
 my $handle = database({ 
--->8-->8-->8-->8---

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
On air: Chicago - Beginnings


signature.asc
Description: PGP signature


Bug#1031701: fixed in python-xlrd 2.0.1-1

2023-02-21 Thread Diane Trout

Sorry my coworker got hit by this too, he worked around it by using
libreoffice to convert the .xls file to .xlsx.

I'd updated the xlrd package to 2.0.1 and pushed it to experimental to
see how much it might break,

Looks like there was some more discussion while I was fiddling with the
package.

On the plus side the update also enabled autopkgtests for xlrd.

Though I had to switch from pulling from pypi to github to keep being
able to build the -docs package, as upstream removed it from their pypi
release.

Diane




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


Bug#983597: Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

2023-02-21 Thread Dennis Filder
This may have gotten fixed by the fix for QTBUG-107850[1] (commit
7487332)[2].  QTBUG-84858 gets a tacit mention there, but is not among
the list of duplicates that got closed through this (even though it
probably should be).

I hastily backported this to 5.15.8 (see attachment), but have not yet
checked if it actually compiles (the test might use functions/macros
missing from 5.15) or works.  I can't look into this more currently
since I'm somewhat busy.  Hopefully I can try it out this weekend.

Regards.

1: https://bugreports.qt.io/browse/QTBUG-107850
2: 
https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
Description: backport commit 7487332 to hopefully fix #983597
 Edited from the original for 6.5.0 FF: https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
--- a/src/quick/items/qquickitem.cpp
+++ b/src/quick/items/qquickitem.cpp
@@ -2326,6 +2326,7 @@
 QQuickItem::~QQuickItem()
 {
 Q_D(QQuickItem);
+d->inDestructor = true;
 
 if (d->windowRefCount > 1)
 d->windowRefCount = 1; // Make sure window is set to null in next call to derefWindow().
@@ -2689,9 +2690,8 @@
 
 const bool wasVisible = isVisible();
 op->removeChild(this);
-if (wasVisible) {
+if (wasVisible && !op->inDestructor)
 emit oldParentItem->visibleChildrenChanged();
-}
 } else if (d->window) {
 QQuickWindowPrivate::get(d->window)->parentlessItems.remove(this);
 }
@@ -2768,8 +2768,9 @@
 
 d->itemChange(ItemParentHasChanged, d->parentItem);
 
-emit parentChanged(d->parentItem);
-if (isVisible() && d->parentItem)
+if (!d->inDestructor)
+emit parentChanged(d->parentItem);
+if (isVisible() && d->parentItem && !QQuickItemPrivate::get(d->parentItem)->inDestructor)
 emit d->parentItem->visibleChildrenChanged();
 }
 
@@ -2965,7 +2966,8 @@
 
 itemChange(QQuickItem::ItemChildRemovedChange, child);
 
-emit q->childrenChanged();
+if (!inDestructor)
+emit q->childrenChanged();
 }
 
 void QQuickItemPrivate::refWindow(QQuickWindow *c)
@@ -3194,6 +3196,7 @@
 , touchEnabled(false)
 #endif
 , hasCursorHandler(false)
+, inDestructor(false)
 , dirtyAttributes(0)
 , nextDirtyItem(nullptr)
 , prevDirtyItem(nullptr)
@@ -6106,9 +6109,11 @@
 QAccessible::updateAccessibility(&ev);
 }
 #endif
-emit q->visibleChanged();
-if (childVisibilityChanged)
-emit q->visibleChildrenChanged();
+if (!inDestructor) {
+emit q->visibleChanged();
+if (childVisibilityChanged)
+emit q->visibleChildrenChanged();
+}
 
 return true;// effective visibility DID change
 }
--- a/src/quick/items/qquickitem_p.h
+++ b/src/quick/items/qquickitem_p.h
@@ -472,6 +472,7 @@
 bool replayingPressEvent:1;
 bool touchEnabled:1;
 bool hasCursorHandler:1;
+quint32 inDestructor:1; // has entered ~QQuickItem
 
 enum DirtyType {
 TransformOrigin = 0x0001,
--- a/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
+++ b/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
@@ -130,6 +130,7 @@
 void isAncestorOf();
 
 void grab();
+void signalsOnDestruction();
 
 private:
 QQmlEngine engine;
@@ -3520,6 +3521,52 @@
 QVERIFY(!sub2.isAncestorOf(&sub2));
 }
 
+/*
+Items that are getting destroyed should not emit property change notifications.
+*/
+void tst_QQuickItem::signalsOnDestruction()
+{
+QQuickWindow window;
+window.show();
+
+// visual children, but not QObject children
+std::unique_ptr parent(new QQuickItem(window.contentItem()));
+std::unique_ptr child(new QQuickItem);
+std::unique_ptr grandChild(new QQuickItem);
+
+QSignalSpy childrenSpy(parent.get(), &QQuickItem::childrenChanged);
+QSignalSpy visibleChildrenSpy(parent.get(), &QQuickItem::visibleChildrenChanged);
+QSignalSpy childParentSpy(child.get(), &QQuickItem::parentChanged);
+QSignalSpy childChildrenSpy(child.get(), &QQuickItem::childrenChanged);
+QSignalSpy childVisibleChildrenSpy(child.get(), &QQuickItem::visibleChanged);
+QSignalSpy grandChildParentSpy(grandChild.get(), &QQuickItem::parentChanged);
+
+child->setParentItem(parent.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 0);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+
+grandChild->setParentItem(child.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 1);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+QCOMPARE(grandChildParentSpy.count(), 1);
+
+parent.reset();
+
+QVERIFY(!child->parentItem());
+QVERIFY(grandChild->parentItem());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildren

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

2023-02-21 Thread Ryan Kavanagh
On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>   Description : A tool for glamourous shell scripts
> 
> A tool for glamorous shell scripts. Leverage the power of Bubbles and
> Lip Gloss in your scripts and aliases without writing any Go code!

This long description does not provide users with enough information to
understand what the package does. What are "Bubbles" and "Lip Gloss" in
a shell script? What is a "glamourous shell script"?

It would be helpful if the package's long description satisfied §3.4.2
of the Debian Policy Manual [0]:

The description field needs to make sense to anyone, even people who
have no idea about any of the things the package deals with. [3]

[...]

[3] The blurb that comes with a program in its announcements and/or
README files is rarely suitable for use in a description. It is
usually aimed at people who are already in the community where the
package is used.

Best wishes,
Ryan

[0] 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature


Bug#1023623: dolphin: In file rename dialog: Delete and Backspace act on file, not on text

2023-02-21 Thread 6251d5d9-c833-4b45-8e6e-261c9164db95

Hi

I had the same symptoms and found a cause that I want to share with you.

For me, the cause was keyboard layouts. When I had German T3 or German 
E1 enabled or even only in the list of active layouts in Plasma, I 
observed the described behaviour.


I had this configured, because it is given as a workaround for neoqwertz 
layout on https://www.neo-layout.org/Probleme/FAQ/#linux-unix-bsd


The third workaround option (setting modifier_mapping) had the same effect.

Cure: have only one keyboard layout "German" configured in KDE Plasma.

Regards
Philipp Schwarz



Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

2023-02-21 Thread Boyuan Yang
Control: tags -1 +moreinfo

Indeed, please fix the error listed below before we can proceed.

Thanks,
Boyuan Yang

On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
wrote:
> On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> >  * Package name : libkysdk-base
> >    Version  : 1.0.1-1
> 
> >  libkysdk-base (1.0.1-1) unstable; urgency=medium
> >  .
> >    * Initial release. (Closes: #1031344)
> 
> Hi!
> Alas, the package fails to build:
> 
> .
> dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists in
debian/tmp but is not installed to anywhere (related file: "src/log/kylog-
rotate-default")
> dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
debian/tmp but is not installed to anywhere (related file:
"src/log/libkylog.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
debian/tmp but is not installed to anywhere (related file: "src/utils/data-
structure/linklist/listdata.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h exists
in debian/tmp but is not installed to anywhere (related file:
"src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> dh_missing: error: missing files, aborting
> 
>   While detecting missing files, dh_missing noted some files with a
similar name to those
>   that were missing.  This error /might/ be resolved by replacing
references to the
>   missing files with the similarly named ones that dh_missing found -
assuming the content
>   is identical.
> 
>   As an example, you might want to replace:
>    * src/log/kylog-rotate-default
>   with:
>    * etc/kysdk/kysdk-base/kylog-rotate-default
>   in a file in debian/ or as argument to one of the dh_* tools called
from debian/rules.
>   (Note it is possible the paths are not used verbatim but instead
directories 
>   containing or globs matching them are used instead)
> 
>   Alternatively, add the missing file to debian/not-installed if it
cannot and should not
>   be used.
> 
>   The following debhelper tools have reported what they installed
(with files per package)
>    * dh_install: libkysdk-base (0), libkysdk-base-dev (1), libkysdk-
config (2), libkysdk-config-dev (3), libkysdk-log (5), libkysdk-log-dev (3),
libkysdk-timer (2), libkysdk-timer-dev (3), libkysdk-utils (4), libkysdk-
utils-dev (9)
>    * dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0),
libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0), libkysdk-
log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), libkysdk-utils (0),
libkysdk-utils-dev (0)
>   If the missing files are installed by another tool, please file a
bug against it.
>   When filing the report, if the tool is not part of debhelper itself,
please reference the
>   "Logging helpers and dh_missing" section from the "PROGRAMMING"
guide for debhelper (10.6.3+).
> (in the debhelper package:
/usr/share/doc/debhelper/PROGRAMMING.gz)
>   Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
>   If the omission is intentional or no other helper can take care of
this consider adding the
>   paths to debian/not-installed.
> `
> 
> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄
> 
> 



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


Bug#1031747: python-socks: autopkgtest regression

2023-02-21 Thread Adrian Bunk
Source: python-socks
Version: 2.1.1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-socks/31564223/log.gz

...
autopkgtest [18:13:28]: test unittests: [---
=== python3.11 ===
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.hgtwobwo/downtmp/autopkgtest_tmp/tests/conftest.py'.
tests/conftest.py:34: in 
from tests.proxy_server import ProxyConfig, ProxyServer
tests/proxy_server.py:9: in 
from tiny_proxy import (
E   ModuleNotFoundError: No module named 'tiny_proxy'
autopkgtest [18:13:29]: test unittests: ---]
autopkgtest [18:13:29]: test unittests:  - - - - - - - - - - results - - - - - 
- - - - -
unittestsFAIL non-zero exit status 4
...



Bug#1031748: zoph fails to purge when adduser is not installed

2023-02-21 Thread Adrian Bunk
Package: zoph
Version: 0.9.19-1
Severity: serious

https://piuparts.debian.org/sid/fail/zoph_1.0.1-1.log

...
  Purging configuration files for zoph (1.0.1-1) ...
  /var/lib/dpkg/info/zoph.postrm: 39: delgroup: not found
  dpkg: error processing package zoph (--purge):
   installed zoph package post-removal script subprocess returned error exit 
status 127
  Errors were encountered while processing:
   zoph
...


https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called

The postrm script is called after the package’s files have been removed or 
replaced. The package whose postrm is being called may have previously been 
deconfigured and only be “Unpacked”, at which point subsequent package changes 
do not consider its dependencies. Therefore, all postrm actions must only rely 
on essential packages and must gracefully skip any actions that require the 
package’s dependencies if those dependencies are unavailable.


Bug#1031749: afnix FTBFS on 32bit: afnix-bexec: failure t_utility

2023-02-21 Thread Adrian Bunk
Source: afnix
Version: 3.8.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=afnix&ver=3.8.0-1

...
running: t_utility
afnix-bexec: failure t_utility
make[6]: *** [../../../../cnf/mak/afnix-runx.mak:301: t_utility.exe] Error 1



Bug#1031750: redis-server: "delaycompess" typo in logrotate file

2023-02-21 Thread Adrian Bunk
Package: redis-server
Version: 5:7.0.8-2
Severity: serious

https://piuparts.debian.org/sid/fail/redis-server_5:7.0.8-3.log

...
  error: /etc/logrotate.d/redis-server:7 unknown option 'delaycompess' -- 
ignoring line
...


src:redis has two packages with logrotate files,
only the one in redis-sentinel was fixed in 5:7.0.8-3.



Bug#1031751: rust-ahash: autopkgtest failure

2023-02-21 Thread Adrian Bunk
Source: rust-ahash
Version: 0.8.3-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ahash/31558299/log.gz

...
Testing map/aHash-alias
thread 'main' panicked at 'attempt to add with overflow', 
/usr/src/rustc-1.63.0/library/core/src/ops/arith.rs:786:1
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:48:5
   3: ::add_assign
 at /usr/src/rustc-1.63.0/library/core/src/ops/arith.rs:779:51
   4: >::add_assign
 at /usr/src/rustc-1.63.0/library/core/src/internal_macros.rs:127:17
   5: ahash::bench_map::{{closure}}::{{closure}}
 at ./tests/bench.rs:124:25
   6: criterion::bencher::Bencher::iter
 at /usr/share/cargo/registry/criterion-0.3.6/src/bencher.rs:88:23
   7: ahash::bench_map::{{closure}}
 at ./tests/bench.rs:119:13
   8: criterion::benchmark_group::BenchmarkGroup::bench_function::{{closure}}
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:254:60
   9:  as 
criterion::routine::Routine>::bench::{{closure}}
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:209:17
  10: core::iter::adapters::map::map_fold::{{closure}}
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/adapters/map.rs:84:28
  11: core::iter::traits::iterator::Iterator::fold
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:2370:21
  12:  as 
core::iter::traits::iterator::Iterator>::fold
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/adapters/map.rs:124:9
  13: core::iter::traits::iterator::Iterator::for_each
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:787:9
  14:  as 
alloc::vec::spec_extend::SpecExtend>::spec_extend
 at /usr/src/rustc-1.63.0/library/alloc/src/vec/spec_extend.rs:40:17
  15:  as 
alloc::vec::spec_from_iter_nested::SpecFromIterNested>::from_iter
 at 
/usr/src/rustc-1.63.0/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
  16:  as 
alloc::vec::spec_from_iter::SpecFromIter>::from_iter
 at 
/usr/src/rustc-1.63.0/library/alloc/src/vec/spec_from_iter.rs:33:9
  17:  as 
core::iter::traits::collect::FromIterator>::from_iter
 at /usr/src/rustc-1.63.0/library/alloc/src/vec/mod.rs:2645:9
  18: core::iter::traits::iterator::Iterator::collect
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:1792:9
  19:  as 
criterion::routine::Routine>::bench
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:205:9
  20: criterion::routine::Routine::test
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:18:9
  21: criterion::benchmark_group::BenchmarkGroup::run_bench
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:339:21
  22: criterion::benchmark_group::BenchmarkGroup::bench_function
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:254:9
  23: ahash::bench_map
 at ./tests/bench.rs:118:9
  24: ahash::benches
 at /usr/share/cargo/registry/criterion-0.3.6/src/macros.rs:71:17
  25: ahash::main
 at /usr/share/cargo/registry/criterion-0.3.6/src/macros.rs:127:17
  26: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

error: test failed, to rerun pass `--bench ahash`
autopkgtest [13:15:47]: test rust-ahash-0.8:@: ---]
autopkgtest [13:15:47]: test rust-ahash-0.8:@:  - - - - - - - - - - results - - 
- - - - - - - -
rust-ahash-0.8:@ FAIL non-zero exit status 101
...
autopkgtest [13:31:10]:  summary
rust-ahash-0.8:@ FAIL non-zero exit status 101
rust-ahash-0.8:default FAIL non-zero exit status 101
rust-ahash-0.8:std   FAIL non-zero exit status 101
rust-ahash-0.8:  PASS
rust-ahash-0.8:compile-time-rng PASS
rust-ahash-0.8:no-rng PASS
rust-ahash-0.8:runtime-rng PASS



Bug#1029829: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

2023-02-21 Thread Amanda Trusted



During our security testing of the fixes, we found another attack vector for 
the issue similar to the one mentioned in 
CVE-2022-37704.

Dump can be manipulated by an attacker through the RSH environment variable, 
which is used to specify the shell binary to be used for remote backups.

By manipulating this variable and invoking Dump via rundump, an attacker can 
execute arbitrary code with root privileges.

We now filter out RSH environment variable to prevent this exploit.

The fix for this issue is available at - 
https://github.com/zmanda/amanda/pull/202.

Is there anything else we can help you with to avert the March 2nd auto removal?

We also recommend pointing to the github repository 
(https://github.com/zmanda/amanda.git) instead of pointing to svn as future 
development will continue on github and we would like to phase out svn.

Best Regards,

AmandaTrusted

From: Amanda Trusted 
Date: Wednesday, February 15, 2023 at 5:10 PM
To: 1029...@bugs.debian.org <1029...@bugs.debian.org>
Cc: j...@calhariz.com 
Subject: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi Jose,

Here are the relevant bug fixes -
[0] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37704 
https://www.cve.org/CVERecord?id=CVE-2022-37704
Fix - https://github.com/zmanda/amanda/pull/197

[1] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37705 
https://www.cve.org/CVERecord?id=CVE-2022-37705
Fix - https://github.com/zmanda/amanda/pull/196


[2] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37703 
https://www.cve.org/CVERecord?id=CVE-2022-37703
Fix - https://github.com/zmanda/amanda/pull/198

These 3 fixes are due for release as part of Amanda 3.5.3 within a week.

Let us know if there are any other action items for us.

Regards,

AmandaTrusted

Confidentiality Notice | The information transmitted by this email is intended 
only for the person or entity to which it is addressed. This email may contain 
proprietary, business-confidential and/or privileged material. If you are not 
the intended recipient of this message, be aware that any use, review, 
re-transmission, distribution, reproduction or any action taken in reliance 
upon this message is strictly prohibited. If you received this in error, please 
contact the sender and delete the material from all computers.


Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

2023-02-21 Thread Scarlett Moore
On Tue, Feb 21, 2023, 3:12 PM Ryan Kavanagh  wrote:

> On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
> >   Description : A tool for glamourous shell scripts
> >
> > A tool for glamorous shell scripts. Leverage the power of Bubbles and
> > Lip Gloss in your scripts and aliases without writing any Go code!
>
> This long description does not provide users with enough information to
> understand what the package does. What are "Bubbles" and "Lip Gloss" in
> a shell script? What is a "glamourous shell script"?
>
> It would be helpful if the package's long description satisfied §3.4.2
> of the Debian Policy Manual [0]:
>
> The description field needs to make sense to anyone, even people who
> have no idea about any of the things the package deals with. [3]
>
> [...]
>
> [3] The blurb that comes with a program in its announcements and/or
> README files is rarely suitable for use in a description. It is
> usually aimed at people who are already in the community where the
> package is used.
>
> Best wishes,
> Ryan
>
> [0]
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
>

Yes sorry. I will update this description to a much more useful description
tomorrow.
Thanks,
Scarlett


  1   2   >