Bug#1074035: ITP: golang-github-shenwei356-stable -- streaming pretty text table for Golang (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org, 
nil...@debian.org

* Package name: golang-github-shenwei356-stable
  Version : 0.1.7
  Upstream Contact: https://github.com/shenwei356/stable/issues
* URL : https://github.com/shenwei356/stable
* License : Expat
  Programming Lang: Go
  Description : streaming pretty text table for Golang (library)

 stable is a streaming pretty text table for Golang.
 .
 Features:
  - Supporting streaming output (optional).
When a writer is configured, a newly added row is formatted and written to
the writer immediately. It is memory-effective for a large number of rows.
And it is helpful to pipe the data in shell.
  - Supporting wrapping text or clipping text.
The minimum and maximum width of the column can be configured for each
column or globally.
  - Configured table styles.
Some preset styles are also provided.
  - Unicode supported

Needed for new version of seqkit.

Will be maintained in Debian Go Packaging Team.
Will need sponsor to upload to new.

-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1060386: fail2ban: Fail2ban Debian 12 fails to start

[Mingye Wang]

Dear Luca,

I am aware of the fix you've provided, but like Stefaan had said, the
package is supposed to work on a default Bookworm install -- it's how
it works before the systemd switch, and indeed how it works in testing
(Debian 13).

Version 1.0.2-3 ended up in testing, but DID NOT find its way into
stable. We should either seek to move that into stable, or seek to
move the current working version in testing (1.1.0-4) -- with a more
comprehensive systemd patch[0], into stable.

[0]: 
https://sources.debian.org/patches/fail2ban/1.1.0-4/update_backend_system.diff/

Thanks,
Mingye Wang (Artoria2e5)

Bug#1074034: ITP: golang-github-elliotwutingfeng-asciiset -- ASCII character bitset (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org, 
nil...@debian.org

* Package name: golang-github-elliotwutingfeng-asciiset
  Version : 0.0~git20240214.24af97c
  Upstream Contact: https://github.com/elliotwutingfeng/asciiset/issues
* URL : https://github.com/elliotwutingfeng/asciiset
* License : BSD-3-Clause
  Programming Lang: Go
  Description : ASCII character bitset (library)

 asciiset is an ASCII character bitset. Bitsets are fast and memory-efficient
 data structures for storing and retrieving information using bitwise
 operations. asciiset is an extension of the asciiSet data structure from the
 Go Standard library source code.
 .
 Possible applications include checking strings for prohibited ASCII
 characters, and counting unique ASCII characters in a string.

Needed for new version of seqkit.

Will be maintained in Debian Go Packaging Team.
Will need sponsor to upload to new.

Kind regards,
-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1043408: ITP: golang-github-dsnet-compress -- Collection of compression related Go packages.

[Maytham Alsudany]

Packaging is complete and awaiting upload at
https://salsa.debian.org/go-team/packages/golang-github-dsnet-compress

-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1074033: libapache2-mod-auth-cas: Please update the outdated config.{guess,sub} to recognize the LoongArch

[zhangdandan]

Source: libapache2-mod-auth-cas
Version: 1.2-1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the libapache2-mod-auth-cas failed for loong64 in the Debian 
Package Auto-Building environment.

The build error log is as follows,
```
dh_testdir
./configure --host=loongarch64-linux-gnu --build=loongarch64-linux-gnu 
--prefix=/usr --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info ASFLAGS="" ASFLAGS_FOR_BUILD="" 
CFLAGS="-g -O2 -Werror=implicit-function-declaration ..
checking build system type... Invalid configuration 
`loongarch64-linux-gnu': machine `loongarch64' not recognized

configure: error: /bin/bash ./config.sub loongarch64-linux-gnu failed
make: *** [debian/rules:14: configure-stamp] Error 1
```

The full log can be found at [1].
Build failed 12 times in Debian Auto-Building ENV.

The LoongArch architecture has been supported in config upstream [2] and 
autotools-dev source package [3].

Please consider the patch (modify debian/rules) I have attached.
I have built libapache2-mod-auth-cas successfully on my local ENV.

[1]:https://buildd.debian.org/status/logs.php?pkg=libapache2-mod-auth-cas=1.2-1=loong64
[2]:https://git.savannah.gnu.org/cgit/config.git/commit/?id=20403c5701973a4cbd7e0b4bbeb627fcd424a0f1
[3]:https://packages.debian.org/bookworm/autotools-dev

Thanks
Dandan Zhang

diff -Nru libapache2-mod-auth-cas-1.2/debian/rules 
libapache2-mod-auth-cas-1.2/debian/rules
--- libapache2-mod-auth-cas-1.2/debian/rules2019-01-09 09:33:42.0 
+
+++ libapache2-mod-auth-cas-1.2/debian/rules2019-02-15 14:14:09.0 
+
@@ -10,6 +10,7 @@
 
 configure: configure-stamp
 configure-stamp:
+   dh_update_autotools_config
dh_testdir
./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) 
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
$(shell dpkg-buildflags --export=configure)
touch $@

Bug#1074032: nvidia-smi locks up machine with new file descriptor limit

[Steve M. Robbins]

Package: nvidia-smi
Version: 535.183.01-1
Severity: normal

A couple months ago, I ran "nvidia-smi" command without issue.

I ran it again today and the machine simply locked up.

Recently, the hard limit of file descriptors was raised for debian:
https://lists.debian.org/debian-devel/2024/06/msg00041.html

I think nvidia-smi breaks because of this.  I lowered the limit using ulimit
-Hn 1048576 and now the command again runs without issue.

-Steve


-- Package-specific info:
uname -a:
Linux riemann 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.8.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  535.183.01  Sun May 12 19:39:15 
UTC 2024
GCC version:  gcc version 13.2.0 (Debian 13.2.0-25) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 
1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3351]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Jun 21 21:33 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jun 21 21:33 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Jun 21 21:33 /dev/nvidia-modeset
crw-rw-rw-  1 root root   237,   0 Jun 21 22:02 /dev/nvidia-uvm
crw-rw-rw-  1 root root   237,   1 Jun 21 22:02 /dev/nvidia-uvm-tools
crw-rw-rw-  1 root root   195,   0 Jun 21 21:33 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Jun 21 21:33 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Jun 21 21:33 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun 21 21:33 pci-:01:00.0-render -> ../renderD128

/dev/nvidia-caps:
total 0
cr 1 root root 240, 1 Jun 21 22:02 nvidia-cap1
cr--r--r-- 1 root root 240, 2 Jun 21 22:02 nvidia-cap2
video:x:44:steve

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libcuda.so.1
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-nvvm.so.4-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.4
  slave nvidia--libnvidia-nvvm.so.535.183.01-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.535.183.01
  slave 

Bug#1074031: coreutils: ptx: -A and -r are nonsensical together?

[наб]

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

$ ptx -O
GNU core utilities
vore gamer utilities
.xx "utilities" "" "GNU core utilities vore gamer" ""
.xx "utilities" "GNU" "core utilities vore gamer" ""
.xx "" "GNU core utilities vore" "gamer utilities" ""
.xx "" "GNU core" "utilities vore gamer utilities" ""
.xx "" "GNU core utilities vore gamer" "utilities" ""
.xx "" "GNU core utilities" "vore gamer utilities" ""

$ ptx -Or
GNU core utilities
vore gamer utilities
.xx "" "" "core utilities" "" "GNU"
.xx "" "" "gamer utilities" "" "vore"
.xx "" "core" "utilities" "" "GNU"
.xx "" "gamer" "utilities" "" "vore"

$ ptx -OA
GNU core utilities
vore gamer utilities
.xx "utilities" "" "GNU core utilities vore gamer" "" ":1"
.xx "utilities" "GNU" "core utilities vore gamer" "" ":1"
.xx "" "GNU core utilities vore" "gamer utilities" "" ":2"
.xx "" "GNU core" "utilities vore gamer utilities" "" ":1"
.xx "" "core utilities vore gamer" "utilities" "GNU" ":2"
.xx "" "GNU core utilities" "vore gamer utilities" "" ":2"

$ ptx -OAr
GNU core utilities
vore gamer utilities
.xx "" "" "core utilities" "" ":1"
.xx "" "" "gamer utilities" "" ":2"
.xx "" "core" "utilities" "" ":1"
.xx "" "gamer" "utilities" "" ":2"

So... the first word is removed but argument 5 is still the line number?

Best,
наб

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FORCED_MODULE, 
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 coreutils depends on:
ii  libacl1   2.3.2-1
ii  libattr1  1:2.5.2-1
ii  libc6 2.38-13
ii  libgmp10  2:6.3.0+dfsg-2
ii  libselinux1   3.5-2
ii  libssl3t64 [libssl3]  3.1.5-1.1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1074030: coreutils: ptx: -G errors out on empty lines, default and -O format accept them

[наб]

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

$ ptx

asd
^D
asd
$ ptx -O

asd
^D
.xx "" "" "asd" ""
$ ptx -G

asd
^D
ptx: error: regular expression has a match of length zero: ‘\n’
$ echo $?
1

Best,
наб

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FORCED_MODULE, 
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 coreutils depends on:
ii  libacl1   2.3.2-1
ii  libattr1  1:2.5.2-1
ii  libc6 2.38-13
ii  libgmp10  2:6.3.0+dfsg-2
ii  libselinux1   3.5-2
ii  libssl3t64 [libssl3]  3.1.5-1.1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1073378: 1073378 chromium with 'Restore Pages' message

[Sergio Campanile]

An interesting thing happened today, but it may well be a coincidence.

I had a Linux crash that made me reboot the computer; I was in the 
middle of a Chromium session navigating the web. After I rebooted and 
entered again in Chromium, it didn't show the 'Restore Pages' popup. 
After I closed Chromium and opened again, it started again to show the 
popup. I can't reproduce the situation (I am not going to crash my Linux 
again!), but this is my conjecture: wouldn't be possible that the tag of 
failed Chromium session is *inverted*, i.e., when it closes badly and 
open again it behaves as it is well, and in the opposite case, when it 
closes well, it behaves as it is bad? Again, this may be a coincidence, 
but maybe it is worth to investigate...


Let's hope that the solution for this problem is found soon...

Thanks for your attention,


/--Sergio Campanile/
/Toronto, Canada/



On 2024-06-19 15:03, Sergio Campanile wrote:


Only to let you know, I installed the newer version of Chromium (just 
announced) and the issue of "Restore Pages" pop up is still there (I 
also tried to delete the org.chromium from /tmp directory with same 
results).




/--Sergio Campanile/
/Toronto, Canada/



On 2024-06-18 23:45, Andres Salomon wrote:
I noticed that chromium segfaults upon exit; I suspect that this is 
why the Restore Pages message pops up. I'll look into that segfault 
when I have more free time available.

Bug#1073077: krita: Fails to build with jpeg-xl 0.9

[Jeremy Bícha]

Control: tags -1 +patch

I have submitted a merge request to fix this issue:

https://salsa.debian.org/qt-kde-team/extras/krita/-/merge_requests/3

Thank you,
Jeremy Bícha

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Don Armstrong]

On Fri, 21 Jun 2024, Vincent Lefevre wrote:
> On 2024-06-20 20:28:16 -0700, Don Armstrong wrote:
> > On Thu, 20 Jun 2024, Vincent Lefevre wrote:
> > > Reopening since after more than 2 hours, I still haven't received the
> > > "Please confirm subscription" e-mail.
> > 
> > Looks like you had some non-ascii characters which triggered a bug; can
> > you try again now? [Python 3 is much more strict than python 2, and I've
> > tried to be as minimal with the changes as possible, so we're probably
> > handling utf-8 incorrectly. Hopefully it isn't an issue.]
> 
> I've tried again with
> 
> Date: Fri, 21 Jun 2024 09:56:17 +0200
> From: Vincent Lefevre 
> To: 1073053-subscr...@bugs.debian.org
> Subject: subscribe
> Message-ID: <20240621075617.ga6...@qaa.vinc17.org>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> 
> and a non-ASCII character as usual, i.e. not UTF-8.
> Still the same problem.

Hrm. Looing at this more closely, the version of EOC that we're using
doesn't handle encodings at all, and just happened to work correctly,
but modern python with bytes->string coercion is causing all sorts of
issues.

I'll dig back into this and get a real solution implemented.

-- 
Don Armstrong  https://www.donarmstrong.com

I finally developed
a computer with feelings.
It just doesn't have
feelings for me.
 -- a softer world #633
http://www.asofterworld.com/index.php?id=633

Bug#1074028: RFS: quickemu/4.9.2-1 [ITP] -- quickly create and run optimised virtual machines

[Maytham Alsudany]

Package: sponsorship-requests
Severity: wishlist
User: maytha8the...@gmail.com
Usertags: pending-upload
Control: block 1018072 by -1

Dear mentors,

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

 * Package name : quickemu
   Version  : 4.9.2-1
   Upstream contact : https://github.com/quickemu-project/quickemu/issues
 * URL  : https://github.com/quickemu-project/quickemu
 * License  : BSD-3-Clause, Expat
 * Vcs  : https://salsa.debian.org/Maytha8/quickemu
   Section  : utils

The source builds the following binary packages:

  quickemu - quickly create and run optimised virtual machines

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/quickemu/quickemu_4.9.2-1.dsc

Changes for the initial release:

 quickemu (4.9.2-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1018072)

Kind regards,
-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1074027: RFS: cjson/1.7.18-1 [ITA] -- Ultralightweight JSON parser in ANSI C

[Maytham Alsudany]

Package: sponsorship-requests
Severity: normal
User: maytha8the...@gmail.com
Usertags: pending-upload
Control: block 1067510 by -1
X-Debbugs-Cc: cj...@packages.debian.org, b...@debian.org

Dear mentors,

I am looking for a sponsor (or upload rights) for my package "cjson":

 * Package name : cjson
   Version  : 1.7.18-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://github.com/DaveGamble/cJSON
 * License  : Apache-2.0, MIT
 * Vcs  : https://salsa.debian.org/debian/cjson
   Section  : libs

The source builds the following binary packages:

  libcjson-dev - Ultralightweight JSON parser in ANSI C (development files)
  libcjson1 - Ultralightweight JSON parser in ANSI C

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/c/cjson/cjson_1.7.18-1.dsc

Changes since the last upload:

 cjson (1.7.18-1) unstable; urgency=medium
 .
   * Adopt package (Closes: #1067510)
   * New upstream version 1.7.18
 * Includes fix for CVE-2024-31755 (Closes: #1071742)
   * Add Build-Depends-Package to d/libcjson1.symbols
   * Add autopkgtest suite running upstream's tests
   * Bump Standards-Version to 4.7.0 (no changes)

Kind regards,


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

Bug#1074026: general: When switching focus to another monitor, the language indicator doesn't move to the active screen.

[Zyniuk Andrij]

Package: general
Severity: wishlist
X-Debbugs-Cc: zinyk...@ukr.net


Summary: When switching focus to another monitor, the language indicator and 
program panel dont't move to the active screen.

Steps to Reproduce:
   
1) Open multiple monitors setup.
2) Switch focus from one monitor to another.
   
Expected Result: Both the language indicator and program panel should move to 
the active monitor.

Actual Result: Both the language indicator and program panel remain on the 
previous monitor.

Bug#1074025: general: After disconnecting the external monitor connected to the laptop, the laptop screen remains blurred.

[Zyniuk Andrij]

Package: general
Severity: important
X-Debbugs-Cc: zinyk...@ukr.net

Due to frequent emergency power outages, 
it has been observed that after disabling the external monitor, 
the laptop screen does not become the primary. 
As a result, any interaction with the system becomes impossible.

A full system reboot helps

Steps to play:

1) Connect the laptop to an external monitor.
2) Use external monitor as main screen.
3) Disable external monitor during system operation.
4) Try using a laptop screen.

Expected result: The laptop screen should display the image correctly.

Actual Result: The laptop screen remains splashed (blurred).

Bug#1072965: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.256.02-1~deb11u1

[Andreas Beckmann]

On 21/06/2024 19.05, Adam D. Barratt wrote:

On Tue, 2024-06-11 at 02:02 +0200, Andreas Beckmann wrote:

A new upstream release of the nvidia drivers in non-free is needed
for fixing a few new CVEs.


The ppc64el build failed:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'rcu_read_unlock_strict'
make[5]: *** [/usr/src/linux-headers-5.10.0-30-common/scripts/Makefile.modpost:123: 
/<>/kernel-source-tree/Module.symvers] Error 1


OK, I can reproduce that with linux-headers-5.10.0-30-powerpc64le but 
not with linux-headers-5.10.0-28-powerpc64le (nor with 
linux-headers-6.8.12-powerpc64le)


Andreas

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Sam Hartman  writes:
>> "Helmut" == Helmut Grohne  writes:

> Helmut> 5. Given earlier disagreement on this
> Helmut> matter, should we discuss this matter in a wider setting
> Helmut> such as d-devel?

> No, please no!
> If there ends up being disagreement, the TC should use its policy making
> powers and put this to bed.

I forgot about the TC involvement.  This is a better answer than mine.

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

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[Bernhard Übelacker]

Am 21.06.24 um 20:47 schrieb David Bremner:

Hi Bernhard;

Thanks for the patch. This does seem to be progress, but I don't think
it completely fixes Axel's bug. At least for me I still see

  -> .
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
<** 451 4.3.0 Error returned from nullmailer-queue

and I get a non-zero exit code. I think the problem you found was
probably a crash during the reporting of the error message.


Yes, it was crashing while it tried to write the error message.

I had hoped the expected behaviour might have been the error message ;-)

I did some archaeology and found the issue got visible
at 2017-12-30 in the Buster development cycle with the
migration of nullmailer 1:2.1-5 into testing.


Kind regards,
Bernhard



debian-9-stretch: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20170801T042817Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20170901T034632Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171001T043059Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171101T034619Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171201T034339Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171215T032758Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171223T034540Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171227T051715Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171229T045928Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171230T035716Z/: Child 
process closed connection unexpectedly. nullmailer (1:2.1-5) over (1:1.13-1.2) 
...
testing https://snapshot.debian.org/archive/debian/20180101T053014Z/: Child 
process closed connection unexpectedly.
debian-10-buster: Child 
process closed connection unexpectedly.
debian-11-bullseye:   Child 
process closed connection unexpectedly.
debian-12-bookworm:   Child 
process closed connection unexpectedly.

Bug#1073519: bullseye-pu: cups/2.3.3op2-3+deb11u7

[Thorsten Alteholz]

On Mon, 17 Jun 2024, Adam D. Barratt wrote:

Please go ahead.


Great, thanks ...

... and uploaded.

  Thorsten

Bug#1069357: cpp-httplib: FTBFS fixed on mentors

[Andrea Pappacoda]

Hi all, I've uploaded a fixed version on Mentors, available here: 
https://mentors.debian.net/package/cpp-httplib/


If you're a DD, I'd greatly appreciate a sponsored upload :D

Bye.

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4

[Preuße]

On 04.06.2024 17:29, Stephen Gelman wrote:

On May 29, 2024 at 4:04:13 PM, Bastian Germann mailto:b...@debian.org>> wrote:


Hi,


I suggest fq renames the binary because it was introduced over 4 years
later and has only been in one release so far.


Both packages have very low usage acc to popcon, but for fq the fq
binary is the entire point of the package, whereas for nq, the fq binary
seems to only be a small part of the functionality of the package.
Therefore, I think that nq should rename the fq binary.



With that argument I could also upload another new package called tq,
which contains only the binary /usr/bin/tq (+ man page) and argue that
it has the right keep that name b/c it is the only binary in it. ;-)

I rather follow the argumentation of Bastian: new packages should better
care if they introduce file conflicts w/ existing packages, especially
if the names of the programs are rather short.

I had a look if there are packages, which needs nq or fq for building,
i.e. if renaming could cause FTBFS bugs: currently there are none for
both. So, we only will generate frustrated end users.

Hilmar
--
sigfault

Bug#1074023: The lightdm service does not start after the device was turned off due to low battery while using Xfce

[Artemka]

Package: lightddm
Version: 1.26.0-8

Bug#1071268: strscpy must be used

[Adrien CLERC]

OK, so strlcpy got removed from Linux kernel: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57f22c8dab6b266ae36b89b073a4a33dea71e762


It should be replaced with strscpy, which differs in returned value in 
case of error. The current code doesn't check the returned value, so 
replacing strlcpy with strscpy in nf_conntrack_rtsp.c "just works", but 
it's as safe code as before.


Adrien

Bug#1071268: make.log

[Adrien CLERC]

Hi,

The failure is about a missing function:

> cat /var/lib/dkms/nat-rtsp/0.7+5.3/build/make.log
DKMS make.log for nat-rtsp-0.7+5.3 for kernel 6.8.12-amd64 (x86_64)
ven. 21 juin 2024 23:36:01 CEST
make : on entre dans le répertoire « /usr/src/linux-headers-6.8.12-amd64 »
  CC [M]  /var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.o
  CC [M]  /var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_nat_rtsp.o
/var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.c: In function 
‘help’:
/var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.c:473:9: warning: 
enumeration value ‘IP_CT_DIR_MAX’ not handled in switch [-Wswitch]

  473 | switch (CTINFO2DIR(ctinfo)) {
  | ^~
/var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.c: In function 
‘init’:
/var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.c:553:17: error: 
implicit declaration of function ‘strlcpy’; did you mean ‘strscpy’? 
[-Werror=implicit-function-declaration]

  553 | strlcpy(hlpr->name, tmpname, sizeof(hlpr->name));
  | ^~~
  | strscpy
cc1: some warnings being treated as errors
make[2]: *** 
[/usr/src/linux-headers-6.8.12-common/scripts/Makefile.build:248 : 
/var/lib/dkms/nat-rtsp/0.7+5.3/build/nf_conntrack_rtsp.o] Erreur 1

make[2]: *** Attente des tâches non terminées
make[1]: *** [/usr/src/linux-headers-6.8.12-common/Makefile:1946 : 
/var/lib/dkms/nat-rtsp/0.7+5.3/build] Erreur 2
make: *** [/usr/src/linux-headers-6.8.12-common/Makefile:252 : 
__sub-make] Erreur 2

make : on quitte le répertoire « /usr/src/linux-headers-6.8.12-amd64 »


Maybe it's linked to kernel headers cleaning, and some #include are missing?

Adrien

Bug#1073825: dracut: manual dracut creates initramfs-*.img files, post-install hook does initrd.img-*

[Jens Schmidt]

On 2024-06-21  15:07, Laszlo wrote:

> Would the following work ? If it does it should be probably added to
> the Debian package config.
> 
>> initrdname="initrd-${kernel}.img"

You mean as a value in /etc/{dracut.conf|dracut.conf.d/*}?

I haven't tested it, because I thought that the dracut script does
not evaluate the value (as far as I can see from the sources).  But
OTOH dracut *sources* the configuration files, so this might
actually work.  Of course only if dracut sources them per kernel
version.

I could test it, but only on Monday ...

Bug#1073518: bookworm-pu: cups/2.4.2-3+deb12u6

[Thorsten Alteholz]

On Mon, 17 Jun 2024, Adam D. Barratt wrote:

Please go ahead.


great, thanks ...

... and uploaded.

  Thorsten

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Preuße]

On 21.06.2024 10:40, Vincent Lefevre wrote:

Hi,


I've tried again with

Date: Fri, 21 Jun 2024 09:56:17 +0200


For me bug subscription works again fine. No clue what is the difference
to your setup.

Hilmar
--
sigfault

Bug#1074022: gpp: copyright file has missing files and licenses

[Leandro Cunha]

Package: gpp
Version: 2.28-1
severity: important

Some of my reviews detected missing licenses and files.

src/gcc.c

**
** Copyright (C) 1996, 1999, 2001 Denis Auroux
** Copyright (C) 2003-2023 Tristan Miller
**
** This program is free software: you can redistribute it and/or
** modify it under the terms of the GNU Lesser General Public License as
** published by the Free Software Foundation, either version 3 of the
** License, or (at your option) any later version.
**
** This program is distributed in the hope that it will be useful,
** but WITHOUT ANY WARRANTY; without even the implied warranty of
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
** GNU Lesser General Public License for more details.
**
** You should have received a copy of the GNU Lesser General Public License
** along with this program.  If not, see .

Copyright file does not list this file nor LGPL-3.0-or-later.
https://spdx.org/licenses/LGPL-3.0-or-later.html

This remains under review and should be changed in a few days.
Bug open for tracking.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1059083: RFS: updated golang-github-azure-azure-sdk-for-go

[Shengjing Zhu]

On Fri, Jun 21, 2024 at 8:33 PM Maytham Alsudany
 wrote:
>
> Ping! Still need a sponsor to upload golang-github-azure-azure-sdk-for-
> go. Urgently needed for new versions of rclone and prometheus.
>

I think people are hesitant to sponsor because of the reconstruction
of the upstream repository.

This was first brought by Félix last year, but we never have a clear
answer how to adapt the changes.
https://lists.debian.org/debian-go/2023/06/msg00030.html

I looked again at the upstream repository. The main modules are in a
subdirectory /sdk
https://github.com/Azure/azure-sdk-for-go/tree/main/sdk, which is not
used by previous legacy versions. And there is one separate module in
/profile, this directory is also not used previously, but currently no
packages need that.

So I propose to create a new package called
golang-github-azure-azure-sdk-for-go-sdk, which contains all the
modules in the /sdk directory. And the package version uses
0.0~gitMMDD schema. This package doesn't conflict with the
previous legacy version, and can be co-installed.

-- 
Shengjing Zhu

Bug#1074014: encode mandatory merged-/usr into policy

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:


Helmut> Questions: 1. Do you agree that policy should be changed?
Yes.
The TC has effectively set policy here already, and while they did
not  use their power under 6.1.1 to actually officially set project
policy, their position has been clear.


Helmut>  If yes:

Helmut>  2. Do you agree that policy should prohibit installing into
Helmut> aliased paths?

Yes.

3.

Helmut> Do you agree that the current progress is
Helmut> sufficient for changing policy? If not, when can we change
Helmut> policy?

I am not sure I agree with this question, but I agree with a simpler
question: should we change policy now.

Helmut> 4. Do you agree with the proposed wording? Can you
Helmut> suggest improvements?

I have no objections to the wording.

Helmut> 5. Given earlier disagreement on this
Helmut> matter, should we discuss this matter in a wider setting
Helmut> such as d-devel?

No, please no!
If there ends up being disagreement, the TC should use its policy making
powers and put this to bed.


signature.asc
Description: PGP signature

Bug#1073981: tmux: entering copy mode is very slow with large history

[Romain Francoise]

There's definitely something fishy going on... cat'ing a 336MB text
file with 6.7M lines in a tmux pane results in 700MB of resident
memory usage with 3.3a and ~3.2GB with 3.4, an increase of 4.4x. And
since entering copy mode actually *copies* the entire history of the
pane into a new memory grid, it allocates the same huge amount of
memory and copies everything over. In 3.4 this involves way more
memory.

It's also much much slower than 3.3a at actually accepting the output
from cat, which is unsurprising.

I'll dig deeper.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Helmut Grohne  writes:

> given the progress we have made with /usr-move and DEP17, I think it is
> time to consider encoding the changes into policy. As of this writing,
> there are 216 source packages in unstable that still install into
> aliased locations and their number has been dropping since a while. All
> but very few packages have bug reports of important severity and will
> have their severity upgraded to serious on August 6th.

Thank you again for all the work that you have done on this.  I agree that
we have reached the point in the transition where we should update Policy
to reflect the new requirements of the archive.

> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.

> - To support merged-/usr systems, packages must not install files in both
> - /path and /usr/path. For example, a package must not install both
> - /bin/example and /usr/bin/example.
> + Since base-files implements mandatory merged-/usr by installing the
> + aliasing symbolic links, other packages must not install files into
> + aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is
> + not prepared to deal with such aliasing and in prohibiting the
> + installation into aliased locations, we avoid triggering undefined
> + behaviour. Conversely, packages may assume that /bin, /lib and /sbin are
> + symlinks at all times and that their files below /usr/bin, /usr/lib and
> + /usr/sbin are also accessible via their aliased locations.

I spent some time thinking about this, since I personally still wish
people wouldn't write /usr/bin/sh when they mean /bin/sh.  I don't think
Policy should prohibit this since, among other reasons, we have no
effective enforcement mechanism and the package will clearly work fine on
Debian systems.  But it would be nice if people didn't gratuitously break
portability, admittedly mostly to non-Linux systems at this point.

That said, I think I convinced myself that this is just not something
Policy can reasonably address.  We should state the assumption as you
stated it since that's required for packages to use /bin/sh at all, and
this probably is not the place to give people portability advice,
particularly since it only applies to things that might be copied from
Debian to a non-Debian system and most of those aren't under our control
and will never be written to Policy anyway.

> Questions:
>  1. Do you agree that policy should be changed?

Yes.

>  If yes:

>  2. Do you agree that policy should prohibit installing into aliased
> paths?

Yes.

>  3. Do you agree that the current progress is sufficient for changing
> policy? If not, when can we change policy?

Yes.

>  4. Do you agree with the proposed wording? Can you suggest
> improvements?

Yes.

>  5. Given earlier disagreement on this matter, should we discuss this
> matter in a wider setting such as d-devel?

You certainly can, but at this late stage I don't think it would change
anything.  We're already into mass-bug-filing territory and it's going to
be an RC bug, so it's already de facto policy and I don't see a
justification for not making it de jure policy.

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

Bug#1073825: dracut: manual dracut creates initramfs-*.img files, post-install hook does initrd.img-*

[Farblos]

On 2024-06-20  22:15, Thomas Lange wrote:

> I use
> # dpkg-reconfigure dracut
> to recreate the initrd for all kernels.

Nice, thanks.  That suits my needs.

I still feel the inconsistency between manual "dracut --regenerate-all"
and post-install hooks itching, but now less so.  So feel free to do
with this bug what you think is right.

Bug#1074021: swift: flaky autopkgtest: timeout too tight?

[Paul Gevers]

Source: swift
Version: 2.33.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails, particularly on amd64, but all architectures 
are affected. I copied the failure output of one of the recent failures 
and wondered if maybe one (or more) internal timeouts are too tight. The 
autopkgtest also seems to fail systematically on s390x due to 
autopkgtest timeout since halfway May 2024.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/s/swift/47856417/log.gz

286s ==
286s FAIL: 
test.unit.proxy.controllers.test_obj.TestECObjController.test_GET_disconnect
286s 
test.unit.proxy.controllers.test_obj.TestECObjController.test_GET_disconnect

286s --
286s testtools.testresult.real._StringException: Traceback (most recent 
call last):
286s   File 
"/tmp/autopkgtest-lxc.npd7s04o/downtmp/build.4lh/src/test/unit/proxy/controllers/test_obj.py", 
line 2957, in test_GET_disconnect

286s self.assertIn("Trying to read EC fragment during GET (retrying)",
286s   File "/usr/lib/python3.11/unittest/case.py", line 1140, in assertIn
286s self.fail(self._formatMessage(msg, standardMsg))
286s   File "/usr/lib/python3.11/unittest/case.py", line 703, in fail
286s raise self.failureException(msg)
286s AssertionError: 'Trying to read EC fragment during GET (retrying)' 
not found in "ChunkWriteTimeout feeding fragments for '/a/c/o': 
ChunkWriteTimeout (0.1s after 3.59s)"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074020: scribus: Fails to build with poppler 24.06

[Jeremy Bícha]

Source: scribus
Version: 1.5.8+dfsg-5
Severity: important
Tags: ftbfs patch

scribus fails to build with poppler 24.06 available in Debian Experimental.

This is fixed with svn commits 26042, 26047, 26079, 26125, and 26169.

https://launchpad.net/ubuntu/+source/scribus/1.6.1-0ubuntu8

Thank you,
Jeremy Bícha

Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1

[Jeremy Bícha]

On Fri, Jun 21, 2024 at 3:52 PM Salvatore Bonaccorso  wrote:
> On Wed, Jun 19, 2024 at 07:11:11PM +0100, Adam D. Barratt wrote:
> > On Sat, 2024-06-15 at 08:28 +0200, Salvatore Bonaccorso wrote:
> > > Hi Jeremy, Simon,
> > >
> > > On Fri, Jun 14, 2024 at 06:22:13PM -0400, Jeremy Bícha wrote:
> > > >
> > [...]
> > > > Salvatore, I pushed commits a few days ago to the debian/bookworm
> > > > and
> > > > debian/bullseye branches of
> > > > https://salsa.debian.org/gnome-team/gdk-pixbuf based directly on
> > > > similar work that had been done by Ubuntu Security but I hadn't
> > > > made
> > > > time to do further testing and reach out to Debian Security. Do you
> > > > want to use those versions or the version you have prepared now?
> > >
> > > Ups, apologies I did no spot that you did as well already the work.
> > >
> > > If you prefer to have your version included for the point-release we
> > > can ask there SRM to reject my version and you can upload your one
> > > (notice to please change the target distribtuion to 'bookworm' for
> > > the point release update).
> > >
> > > As you have already done as well the bullseye one, can you fille a
> > > bullseye-pu request + upload for bullseye-pu as well?
> > >
> > > Just let here know if you want
> > >
> > > gdk-pixbuf | 2.42.10+dfsg-1+deb12u1 | stable-new  | source
> > >
> > > rejected in favour of your version.
> >
> > Ping on this, as we're getting closer to the freeze windows.
>
> Friendly ping as the window is closing on sunday.
>
> Otherwise can we have the uploaded and pending in stable-new version
> accepted for the point release?
>
> Notabene, I did not managed yet to work on the bullseye version as
> well, which would be convinient to have as well included in the
> upcoming point release.

Let's go with your existing 2.42.10+dfsg-1+deb12u1 upload for bookworm.

I'll do an upload and file a separate bug later today (or early
tomorrow) with my bullseye version.

Thank you,
Jeremy Bícha

Bug#1073750: lightdm: move aliased files from / to /usr (DEP17)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2024-06-20 at 07:37 +0200, Helmut Grohne wrote:
> That quite definitely is the long term solution. It has one downside:
> Backporting to bookworm-backports and earlier will result in a broken
> package that is not (re)started during package installation and
> upgrades. Now lightdm is not a package with a long history of backports
> so this trade-off may well be a good one and a backport also can revert
> this change (if one remembers to do so).
> 
> So this mainly is a question of how you want to deal with backports.

Yes, to be honest I'm unlikely to backport 1.32 to Bookworm, so I guess I'll
go with the move.

Thanks for the reply!

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmZ130cACgkQ3rYcyPpX
RFtlYwgAovVHigiLsFB1Yrq3gHj3SZ703/qA/7HTPyrgsZg9K4UnsPsQ3VlCb04B
zd8Zi9iMPE1v+hBXnYHmRrKn02tIvgVidTvas+WY56tcXq2k1obyv61xk7E84Cnx
4pE4labdMdsgQbF2Uqqzuk0m4OU1Rghq0hbxQp0j0Kt1GR6MeiTWGt4qaUM2m7Ju
YW4qcl3bglZwHt7lv5Nxmy9I7Tjg2Gq0yskVSu61nut47wjXucxb890Ru7CIUHkM
V1taRlrbhqIk4P+YTM1HauH3ABs/TGW6hRijjHtQDgy9qTGjboBzpV+fk5kEyS2l
JFbUucItmNZ5WcSOt3HghkVBpwd2bg==
=rxY5
-END PGP SIGNATURE-

Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1

[Salvatore Bonaccorso]

Hi all,

On Wed, Jun 19, 2024 at 07:11:11PM +0100, Adam D. Barratt wrote:
> On Sat, 2024-06-15 at 08:28 +0200, Salvatore Bonaccorso wrote:
> > Hi Jeremy, Simon,
> > 
> > On Fri, Jun 14, 2024 at 06:22:13PM -0400, Jeremy Bícha wrote:
> > > 
> [...]
> > > Salvatore, I pushed commits a few days ago to the debian/bookworm
> > > and
> > > debian/bullseye branches of
> > > https://salsa.debian.org/gnome-team/gdk-pixbuf based directly on
> > > similar work that had been done by Ubuntu Security but I hadn't
> > > made
> > > time to do further testing and reach out to Debian Security. Do you
> > > want to use those versions or the version you have prepared now?
> > 
> > Ups, apologies I did no spot that you did as well already the work.
> > 
> > If you prefer to have your version included for the point-release we
> > can ask there SRM to reject my version and you can upload your one
> > (notice to please change the target distribtuion to 'bookworm' for
> > the point release update).
> > 
> > As you have already done as well the bullseye one, can you fille a
> > bullseye-pu request + upload for bullseye-pu as well?
> > 
> > Just let here know if you want 
> > 
> > gdk-pixbuf | 2.42.10+dfsg-1+deb12u1 | stable-new  | source
> > 
> > rejected in favour of your version.
> 
> Ping on this, as we're getting closer to the freeze windows.

Friendly ping as the window is closing on sunday.

Otherwise can we have the uploaded and pending in stable-new version
accepted for the point release?

Notabene, I did not managed yet to work on the bullseye version as
well, which would be convinient to have as well included in the
upcoming point release.

Regards,
Salvatore

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Hi Jörn,

On Fri, Jun 21, 2024 at 04:21:36PM +0200, Jörn Heusipp wrote:
> 
> > Looks like it just missed 6.9.5. Hopefully it will be in 6.9.6 then.
> 
> The fix landed in upstream 6.9.6.

Thanks!

Regards,
Salvatore

Bug#1073927: autopkgtest: --shell and --shell-fail are broken

[Paul Gevers]

Hi,

On 21-06-2024 11:21 a.m., Paride Legovini wrote:

qemu doesn't try to directly open a shell, it gives the following output
and those methods normally work for me:


Right, I probably experienced this with qemu when I was working on my 
commands-via-ssh implementation and thought it was due to that.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074008: RFS: sslscan/2.1.4-1 -- Tests SSL/TLS enabled services to discover supported cipher suites

[Phil Wyett]

Hi Alejo,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: GOOD

2. Lintian: GOOD

3. Licenses check: GOOD

4. Build Twice (sudo pbuilder build --twice .dsc): GOOD

5. Install (No previous installs): GOOD

6. Upgrade (Over previous installs if any): GOOD

Summary...

I believe this package is now ready for sponsorship/upload. Could a Debian
Developer (DD) with available free time, please review this package and upload
if you feel it is ready and appropriate for the distribution.

Regards

Phil

-- 

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074019: bullseye-pu: package ngircd/26.1-1+deb11u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: ngi...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:ngircd
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix one major and two more "Oh, that's not good" issues. It was agreed
upon with security team to handle them via SPU.

1. In a TLS-based server-server connection, the server certificate is
not validated.

github issue: https://github.com/ngircd/ngircd/issues/120

For reasons neither upstream or I understand, a CVE number request was rejected.

2. In a server-server connection, a connection may still use
plain text despite the connection ought to be TLS-based.

Fix: 
https://github.com/ngircd/ngircd/commit/21c1751b045b0be49e584a4ba191a330e0c381bb
Debian bug: https://bugs.debian.org/1067237

3. Some IRC services might send an empty string for the hostname to
implement the "uncloak host" functionality, leading to a protocol
violation in subsequent "WHOIS" or other commands against the ngircd
server.

Fix: 
https://github.com/ngircd/ngircd/commit/1118b0e77ca961a7b082f90cb124210eca8fb6bd

[ Impact ]
1. Server-server links are prone to MITM attacks even when using TLS.

2. Downgrade attacks.

3. Client confusion, possibly crash.

[ Tests ]
1. The unstable version of ngircd now has an autopkgtest for that
situation. For a test, it was manually backported, and it passed.
It's not included however to keep the change small.
2./3. No test in particular, but the change is small.

Also, a private IRC network using ngircd with Debian bookworm was
already upgraded in April, using a preliminary release. No technical
issues were found, only documentation needed a little clarification
(included).

[ Risks ]
1. This might break flawed configurations, most notably if the peer's
   certificate has expired and/or cannot be verified against the configured
   trust store. The ngircd.NEWS and ngircd.README.Debian files have been
   updated.
2./3. No risks are to be expected.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
  (27~rc1-1, 2024-04-13)

[ Changes ]
All the changes were cherry-pick from upstream.
1. Whopping 19 patches, prefixed "S2S-TLS"
2. patch Respect-SSLConnect-option
3. patch METADATA-Fix-unsetting-cloakhost

Also the mentioned changes to documentation in debian/


[ Other info ]
The same story will follow for bookworm in a moment. In fact,
bullseye and bookworm have the same version of ngircd at the moment.

Regards,

Christoph

diff -Nru ngircd-26.1/debian/changelog ngircd-26.1/debian/changelog
--- ngircd-26.1/debian/changelog2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/changelog2024-05-01 11:00:00.0 +0200
@@ -1,3 +1,13 @@
+ngircd (26.1-1+deb11u1) bullseye; urgency=high
+
+  * Cherry-pick "Respect "SSLConnect" option for incoming
+connections". Closes: #1067237
+  * Cherry-pick "Support for server certificate validation on server
+links [S2S-TLS]"
+  * Cherry-pick "METADATA: Fix unsetting "cloakhost""
+
+ -- Christoph Biedl   Wed, 01 May 2024 
11:00:00 +0200
+
 ngircd (26.1-1) unstable; urgency=medium
 
   * New upstream version 26.1
diff -Nru ngircd-26.1/debian/ngircd.conf ngircd-26.1/debian/ngircd.conf
--- ngircd-26.1/debian/ngircd.conf  2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/ngircd.conf  2024-05-01 11:00:00.0 +0200
@@ -273,6 +273,14 @@
# is only available when ngIRCd is compiled with support for SSL!
# So don't forget to remove the ";" above if this is the case ...
 
+   # SSL Trusted CA Certificates File for verifying peer certificates.
+   # (Default: not set; so no certificates are trusted)
+   ;CAFile = /etc/ssl/certs/ca-certificates.crt
+
+   # Certificate Revocation File (for marking otherwise valid
+   # certficates as invalid)
+   ;CRLFile = /etc/ssl/CA/crl.pem
+
# SSL Server Key Certificate
;CertFile = /etc/ssl/certs/server.crt
 
@@ -366,6 +374,10 @@
# Connect to the remote server using TLS/SSL (Default: false)
;SSLConnect = yes
 
+   # Verify the TLS certificate presented by the remote server
+   # (Default: yes)
+   ;SSLVerify = yes
+
# Define a (case insensitive) list of masks matching nicknames that
# should be treated as IRC services when introduced via this remote
# server, separated by commas (",").
diff -Nru ngircd-26.1/debian/ngircd.NEWS ngircd-26.1/debian/ngircd.NEWS
--- ngircd-26.1/debian/ngircd.NEWS  1970-01-01 01:00:00.0 +0100
+++ ngircd-26.1/debian/ngircd.NEWS  2024-05-01 11:00:00.0 +0200
@@ -0,0 +1,8 @@
+ngircd (26.1-1+deb11u1) bullseye; urgency=high
+
+  * This version introduces x509 certificate validation on TLS-based
+server-server links. Existing 

Bug#1073981: tmux: entering copy mode is very slow with large history

[brian m. carlson]

On 2024-06-21 at 09:26:36, Romain Francoise wrote:
> Thanks. There's a similar report in the Ubuntu bug tracker about 3.4.
> 
> I will take a look, but this has always been a use case that tmux is
> not designed for. Do you really have a need for 10M lines of
> scrollback history in each window?

I very frequently do things like run test output (Git's testsuite
particularly is very verbose), and then search the terminal in copy mode
for relevant output (like "not ok").  I will say most of panes actually
have very little backscroll, but I tend to have a handful with a lot of
data.

It isn't that I actually have 10 million lines in any one pane
(presently I only have 3.2 million in one pane with the rest very
minimal), only that I don't want to worry about how much I do have.  I'm
afraid that my laptop doesn't actually have sufficient memory for me to
have 10 million lines of scrollback in every pane, since I have 27 panes
just in this one session.

> Also, I'm curious. Is it better with an empty `status-right'?

Changing the line in my config to this:

  set -g status-right ''

interestingly seems to make the problem much _worse_ in that copy mode
takes many more seconds to start.  The change I made here is very recent
in that it adjusts to use an ISO 8601-style date instead of the unusual
date format that's set by default and actually occurred after tmux 3.4
was released (before, the option was unset and the problem still
occurred).
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1074018: bookworm-pu: package ngircd/26.1-1+deb12u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ngi...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:ngircd
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix one major and two more "Oh, that's not good" issues. It was agreed
upon with security team to handle them via SPU.

1. In a TLS-based server-server connection, the server certificate is
not validated.

github issue: https://github.com/ngircd/ngircd/issues/120

For reasons neither upstream or I understand, a CVE number request was rejected.

2. In a server-server connection, a connection may still use
plain text despite the connection ought to be TLS-based.

Fix: 
https://github.com/ngircd/ngircd/commit/21c1751b045b0be49e584a4ba191a330e0c381bb
Debian bug: https://bugs.debian.org/1067237

3. Some IRC services might send an empty string for the hostname to
implement the "uncloak host" functionality, leading to a protocol
violation in subsequent "WHOIS" or other commands against the ngircd
server.

Fix: 
https://github.com/ngircd/ngircd/commit/1118b0e77ca961a7b082f90cb124210eca8fb6bd

[ Impact ]
1. Server-server links are prone to MITM attacks even when using TLS.

2. Downgrade attacks.

3. Client confusion, possibly crash.

[ Tests ]
1. The unstable version of ngircd now has an autopkgtest for that
situation. For a test, it was manually backported, and it passed.
It's not included however to keep the change small.
2./3. No test in particular, but the change is small.

Also, a private IRC network using ngircd with Debian bookworm was
already upgraded in April, using a preliminary release. No technical
issues were found, only documentation needed a little clarification
(included).

[ Risks ]
1. This might break flawed configurations, most notably if the peer's
   certificate has expired and/or cannot be verified against the configured
   trust store. The ngircd.NEWS and ngircd.README.Debian files have been
   updated.
2./3. No risks are to be expected.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
  (27~rc1-1, 2024-04-13)

[ Changes ]
All the changes were cherry-pick from upstream.
1. Whopping 19 patches, prefixed "S2S-TLS"
2. patch Respect-SSLConnect-option
3. patch METADATA-Fix-unsetting-cloakhost

Also the mentioned changes to documentation in debian/


[ Other info ]
n/a

Regards,

Christoph

diff -Nru ngircd-26.1/debian/changelog ngircd-26.1/debian/changelog
--- ngircd-26.1/debian/changelog2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/changelog2024-05-01 12:00:00.0 +0200
@@ -1,3 +1,13 @@
+ngircd (26.1-1+deb12u1) bookworm; urgency=high
+
+  * Cherry-pick "Respect "SSLConnect" option for incoming
+connections". Closes: #1067237
+  * Cherry-pick "Support for server certificate validation on server
+links [S2S-TLS]"
+  * Cherry-pick "METADATA: Fix unsetting "cloakhost""
+
+ -- Christoph Biedl   Wed, 01 May 2024 
12:00:00 +0200
+
 ngircd (26.1-1) unstable; urgency=medium
 
   * New upstream version 26.1
diff -Nru ngircd-26.1/debian/ngircd.conf ngircd-26.1/debian/ngircd.conf
--- ngircd-26.1/debian/ngircd.conf  2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/ngircd.conf  2024-05-01 12:00:00.0 +0200
@@ -273,6 +273,14 @@
# is only available when ngIRCd is compiled with support for SSL!
# So don't forget to remove the ";" above if this is the case ...
 
+   # SSL Trusted CA Certificates File for verifying peer certificates.
+   # (Default: not set; so no certificates are trusted)
+   ;CAFile = /etc/ssl/certs/ca-certificates.crt
+
+   # Certificate Revocation File (for marking otherwise valid
+   # certficates as invalid)
+   ;CRLFile = /etc/ssl/CA/crl.pem
+
# SSL Server Key Certificate
;CertFile = /etc/ssl/certs/server.crt
 
@@ -366,6 +374,10 @@
# Connect to the remote server using TLS/SSL (Default: false)
;SSLConnect = yes
 
+   # Verify the TLS certificate presented by the remote server
+   # (Default: yes)
+   ;SSLVerify = yes
+
# Define a (case insensitive) list of masks matching nicknames that
# should be treated as IRC services when introduced via this remote
# server, separated by commas (",").
diff -Nru ngircd-26.1/debian/ngircd.NEWS ngircd-26.1/debian/ngircd.NEWS
--- ngircd-26.1/debian/ngircd.NEWS  1970-01-01 01:00:00.0 +0100
+++ ngircd-26.1/debian/ngircd.NEWS  2024-05-01 12:00:00.0 +0200
@@ -0,0 +1,8 @@
+ngircd (26.1-1+deb12u1) bookworm; urgency=high
+
+  * This version introduces x509 certificate validation on TLS-based
+server-server links. Existing configurations will likely break, for
+details see , starting at
+"TLS-based server-server links".
+
+ -- Christoph Biedl   Wed, 

Bug#1074017: ITP: golang-github-aymanbagabas-go-udiff -- uDiff - a micro Go diffing library

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-aymanbagabas-go-udiff
  Version : 0.2.0-1
  Upstream Author : Ayman Bagabas
* URL : https://github.com/aymanbagabas/go-udiff
* License : BSD-3-clause and Expat
  Programming Lang: Go
  Description : µDiff - a micro Go diffing library

 Micro diff (µDiff) is a Go library that implements the Myers' diffing
 algorithm.
 .
 It aims to provide a minimal API to compute and apply diffs with zero
 dependencies. It also supports generating diffs in the Unified Format.

Bug#1074016: ITP: rosbags -- The pure python library for everything rosbag

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: rosbags
  Version : 0.10.3
  Upstream Author : Ternaris
* URL or Web page : https://gitlab.com/ternaris/rosbags
* License : Apache-2.0
  Description : The pure python library for everything rosbag

It contains:
   - highlevel easy-to-use interfaces,
   - rosbag2 reader and writer,
   - rosbag1 reader and writer,
   - extensible type system with serializers and deserializers,
   - efficient converter between rosbag1 and rosbag2,
   - and more.
Rosbags does not have any dependencies on the ROS software stacks and can be
used on its own or alongside ROS1 or ROS2

Bug#1040250: coreutils: tail: legacy flag format broken with empty number field

[наб]

On Mon, Jul 03, 2023 at 11:09:58PM +0200, наб wrote:
> However, coreutils tail somehow takes it to mean... 10?
> (Thus, coreutils tail +c f is the same as V7 tail +10c.)
This was actually mandated by SUSv3 and earlier
(before it was removed in later POSIXes).

So maybe do keep doing it.


signature.asc
Description: PGP signature

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Bernhard Übelacker  writes:

> Am 21.06.24 um 01:57 schrieb Bernhard Übelacker:
>
>> Especially the third point is puzzling, I could not yet see why this 
>> pointer-content-mixup happens.
>
>
> Hello David, hello Axel,
> I did some further tests and found following location where cli_program
> is delared here:
>
>./lib/cli++/cli++.h:35:extern const char* cli_program;
>
> But the defintion looks a bit different:
>
>./src/smtpd.cc:55:extern const char cli_program[] = "nullmailer-smtpd";
>
>
> A package built with following change does no longer show this crash.
>
> Kind regards,
> Bernhard

Hi Bernhard;

Thanks for the patch. This does seem to be progress, but I don't think
it completely fixes Axel's bug. At least for me I still see

 -> .
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
<** 451 4.3.0 Error returned from nullmailer-queue

and I get a non-zero exit code. I think the problem you found was
probably a crash during the reporting of the error message.

Bug#1074015: xpdf: Fails to build with poppler 24.06

[Jeremy Bícha]

Source: xpdf
Version: 3.04+git20240202-1
Severity: important
Tags: ftbfs patch

xpdf fails to build with poppler 24.06 available in Experimental.

This issue has already been fixed upstream. The change is compatible
with the version of poppler already in Unstable. Could you update to a
new git snapshot or cherry-pick
578c8e5076d565702a18981442ff386227083d3b ?

Thank you,
Jeremy Bícha

Bug#1074014: encode mandatory merged-/usr into policy

[Helmut Grohne]

Package: debian-policy
Version: 4.7.0.0
X-Debbugs-Cc: bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org

Hi,

given the progress we have made with /usr-move and DEP17, I think it is
time to consider encoding the changes into policy. As of this writing,
there are 216 source packages in unstable that still install into
aliased locations and their number has been dropping since a while. All
but very few packages have bug reports of important severity and will
have their severity upgraded to serious on August 6th.

Generally speaking DEP17 says that no package should install any files
below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs
directory conflict between base-files which now installs symlinks at the
relevant locations. What happens with these locations depends on the
order of unpacks. In many cases, this is not a problem, because
base-files is essential and thus unpacked early. Other than that,
running dpkg-deb -x foo.deb / causes these symlinks to be overwritten
with actual directories possibly breaking the installation. We currently
have mitigations for these problems in place and plan to drop them after
trixie.

For these reasons, I propose changing section 10.1 and encoding the
avoidance of symlink vs directory conflicts into policy. To get a
discussion going, I suggest the following update.

- To support merged-/usr systems, packages must not install files in both
- /path and /usr/path. For example, a package must not install both
- /bin/example and /usr/bin/example.
+ Since base-files implements mandatory merged-/usr by installing the
+ aliasing symbolic links, other packages must not install files into
+ aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is
+ not prepared to deal with such aliasing and in prohibiting the
+ installation into aliased locations, we avoid triggering undefined
+ behaviour. Conversely, packages may assume that /bin, /lib and /sbin are
+ symlinks at all times and that their files below /usr/bin, /usr/lib and
+ /usr/sbin are also accessible via their aliased locations.

I suspect that this is not perfect, but it is hopefully good enough for
entering the discussion.

Questions:
 1. Do you agree that policy should be changed?

 If yes:

 2. Do you agree that policy should prohibit installing into aliased
paths?
 3. Do you agree that the current progress is sufficient for changing
policy? If not, when can we change policy?
 4. Do you agree with the proposed wording? Can you suggest
improvements?
 5. Given earlier disagreement on this matter, should we discuss this
matter in a wider setting such as d-devel?

Thanks for considering

Helmut

Bug#1074000: RESTful API feature does not work, because of missing "orjson" library

[Daniel Echeverri]

Hello!!

El vie, 21 jun 2024 a la(s) 7:51 a.m., Michael Kussmaul (
michael.kussm...@nix.ch) escribió:

> Package: glances
> Version: 4.0.5+dfsg-1
>
> I use glances with Debian testing and with API mode, so I can query
> glances parameters over the included REST interface:
>
> glances -w --disable-webui -B 0.0.0.0
>
> But since version 4, this seems to be broken in Debian, because there is
> no "orjson" library found (orjson python package is not available in Debian
> testing).
>
> Steps to reproduce:
>
> 1.) start glances in RESTful API mode:
>  glances -w --disable-webui -B 0.0.0.0
> 2.) access API, eg. status:
>  curl http://localhost:61208/api/4/status
>
> it returns: "Internal Server Error"
>
> and glances log-file logs the following error message:
>
> Jun 21 10:20:47 mapout systemd[1]: Started glances.service - Glances.
>
> Jun 21 10:20:47 mapout glances[1168]: INFO: Started server process
> [1168]
>
> Jun 21 10:20:47 mapout glances[1168]: INFO: Waiting for application
> startup.
>
> Jun 21 10:20:47 mapout glances[1168]: INFO: Application startup
> complete.
>
> Jun 21 10:20:47 mapout glances[1168]: INFO: Uvicorn running on
> http://0.0.0.0:61208 (Press CTRL+C to quit)
>
> Jun 21 14:23:41 mapout glances[1168]: ERROR:Exception in ASGI
> application
>
> Jun 21 14:23:41 mapout glances[1168]: Traceback (most recent call last):
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/uvicorn/protocols/http/h11_impl.py", line
> 407, in run_asgi
>
> Jun 21 14:23:41 mapout glances[1168]: result = await app(  # type:
> ignore[func-returns-value]
>
> Jun 21 14:23:41 mapout glances[1168]:
> ^^
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/uvicorn/middleware/proxy_headers.py", line
> 69, in __call__
>
> Jun 21 14:23:41 mapout glances[1168]: return await self.app(scope,
> receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:
> 
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/fastapi/applications.py", line 1054, in
> __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await super().__call__(scope,
> receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/applications.py", line 123, in
> __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await
> self.middleware_stack(scope, receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/middleware/errors.py", line 186,
> in __call__
>
> Jun 21 14:23:41 mapout glances[1168]: raise exc
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/middleware/errors.py", line 164,
> in __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive,
> _send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/middleware/gzip.py", line 26, in
> __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive,
> send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/middleware/cors.py", line 85, in
> __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive,
> send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/middleware/exceptions.py", line
> 65, in __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await
> wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 64,
> in wrapped_app
>
> Jun 21 14:23:41 mapout glances[1168]: raise exc
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 53,
> in wrapped_app
>
> Jun 21 14:23:41 mapout glances[1168]: await app(scope, receive, sender)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 756, in __call__
>
> Jun 21 14:23:41 mapout glances[1168]: await
> self.middleware_stack(scope, receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 776, in app
>
> Jun 21 14:23:41 mapout glances[1168]: await route.handle(scope,
> receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 297, in handle
>
> Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive,
> send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 77, in app
>
> Jun 21 14:23:41 mapout glances[1168]: await
> wrap_app_handling_exceptions(app, request)(scope, receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]:   File
> 

Bug#1061200: transition: vtk9

[Anton Gladky]

Hi,

it looks like the transition can be finished soon.
Please check. Thanks

Anton

Bug#1074012: 32 bit package is missing in stable (bookworm) and testing (trixie)

[Robin]

Package: libswt-cairo-gtk-4-jni
Version: 4.26.0-1
Severity: grave

Issue description:
Prevents tuxguitar from being installed:

$ sudo apt-get install tuxguitar
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 tuxguitar : Hängt ab von: libswt-gtk-4-java ist aber nicht installierbar
 Hängt ab von: libswt-cairo-gtk-4-jni ist aber nicht installierbar
 Hängt ab von: libeclipse-e4-ui-widgets-java soll aber nicht 
installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte 
Pakete.

Severity: grave
Since this package is without any function here and moreover keeps other 
packages from being installed, the severity of this bug is grave.

Suggested fix:
Build this package for 32 bit and put it up to the repos for bookworm and 
trixie.

System:
Pure debian bookworm install on 32 bit hardware. (Works great and fast 
otherwise)
Debian-Kernel 6.5.0-0.deb12.4-686-smp

Bug#1074013: ITP: golang-github-charmbracelet-x -- Charm experimental packages

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-charmbracelet-x
  Version : 0.0~git20240606.7c42867-1
  Upstream Author : Charm
* URL : https://github.com/charmbracelet/x
* License : Expat
  Programming Lang: Go
  Description : Charm experimental packages

 Experimental Charm's Go libraries with no guarantee of backward compatibility.
 .
 Includes ANSI escape sequence parsing, terminal event input handling, and
 various utilities for files, strings, and slices, among others.
 .
 Each library serves a specific function to enhance terminal application
 development.

Bug#1074011: 32 bit package is missing in stable (bookworm) and testing (trixie)

[Robin]

Package: libswt-gtk-4-java
Version: 4.26.0
Severity: grave

Issue description:
Prevents tuxguitar from being installed:

$ sudo apt-get install tuxguitar
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 tuxguitar : Hängt ab von: libswt-gtk-4-java ist aber nicht installierbar
 Hängt ab von: libswt-cairo-gtk-4-jni ist aber nicht installierbar
 Hängt ab von: libeclipse-e4-ui-widgets-java soll aber nicht 
installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte 
Pakete.

Severity: grave
Since this package is without any function here and moreover keeps other 
packages from being installed, the severity of this bug is grave.

Suggested fix:
Build this package for 32 bit and put it up to the repos for bookworm and 
trixie.

System:
Pure debian bookworm install on 32 bit hardware. (Works great and fast 
otherwise)
Debian-Kernel 6.5.0-0.deb12.4-686-smp

Bug#1002996: ITP: python-orjson -- fast, correct JSON library for Python

[Daniel Echeverri]

Hello!

Since 4.x version glances package depends from python-orjson, do you plan
to work on this soon? I could upload the package once it's already.  For
the other hand, I was checking the dependencies of python-orjson seems
depends of itoap rust library that isn't include in debian yet. For now, I
will work in can include this rust library in debian, meanwhile I receive
news about you.

Thank you very much!

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1074010: libgtk3-perl: use Gtk3 -init breaks decimal handling in source

[Jeffrey Ratcliffe]

Package: libgtk3-perl
Version: 0.038-3
Severity: important
Tags: l10n

Dear Maintainer,

   * What led up to the situation?

Installed a new version of Perl

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

I stored the following in a file called "test":

#!/usr/bin/perl

use warnings;
use strict;

use Gtk3 -init;

my $VAR = 0.001;

print "VAR $VAR\n"

and tested it with:

LC_ALL=de_DE perl test

   * What was the outcome of this action?

The following was printed:
VAR 0

   * What outcome did you expect instead?

Either
VAR 0.001

Or
VAR 0,001

If I comment out the "use Gtk3 -init;" line, or even just remove the "-init",
then I get the expect results.

Needless to say, this has a major impact on how Perl source is interpreted in
any locale that uses something other than a decimal point, e.g. a decimal comma
in German or French.


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

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

Versions of packages libgtk3-perl depends on:
ii  gir1.2-gdkpixbuf-2.0   2.42.12+dfsg-1
ii  gir1.2-gtk-3.0 3.24.42-1
ii  gir1.2-pango-1.0   1.54.0+ds-1
ii  libcairo-gobject-perl  1.005-4+b2
ii  libglib-object-introspection-perl  0.051-1+b2
ii  libglib-perl   3:1.329.3-3+b2
ii  perl   5.38.2-5

libgtk3-perl recommends no packages.

libgtk3-perl suggests no packages.

-- no debconf information

Bug#1074007: ITP: yubihsm-connector -- USB to HTTP bridge for the YubiHSM

[Colin Watson]

On Fri, Jun 21, 2024 at 06:36:06PM +0200, Simon Josefsson wrote:
> Thanks for working on this package.
> 
> > I have the hardware and I intend to maintain this as part of
> > https://salsa.debian.org/auth-team, which already has quite a few
> > other Yubico-related packages.
> 
> What do you think about using pkg-security-team instead?  I haved moved
> libntlm and shishi there too, and I see opportunity for more shared
> contributions by merging the auth-team into pkg-security-team (or
> rather: I don't see a lot of opportunity for team contributions in the
> auth-team, and I'm hoping pkg-security-team is better at that).  I've
> worked on a bunch of auth-team packages at some point in their history,
> and I'm not sure there were ever any coherent team.

I guess I don't really mind.  There is the minor issue that I'm in
auth-team and am not in pkg-security-team, but I suppose that would be
fixable. :-)  A YubiHSM is also less about personal authentication than
a YubiKey is.

CCing a couple of the other auth-team folks to see what they think.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1072965: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.256.02-1~deb11u1

[Adam D. Barratt]

On Tue, 2024-06-11 at 02:02 +0200, Andreas Beckmann wrote:
> A new upstream release of the nvidia drivers in non-free is needed
> for fixing a few new CVEs.

The ppc64el build failed:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'rcu_read_unlock_strict'
make[5]: *** 
[/usr/src/linux-headers-5.10.0-30-common/scripts/Makefile.modpost:123: 
/<>/kernel-source-tree/Module.symvers] Error 1

Regards,

Adam

Bug#1073074: Info received (Bug#1073074: Acknowledgement (firefox: looses previous tabs))

[Phil Dibowitz]

On 6/21/24 3:57 AM, Vincent Lefevre wrote:

The firefox 127.0.1-1 Debian package is now available.
Is this bug fixed?



I just got the forced-restart and all my tabs were restored even though 
I didn't enter the master password. Seems fixed.


Thanks!
--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1072650: RM: quantlib-python [riscv64] -- RoM

[Dirk Eddelbuettel]

Package: ftp.debian.org
Severity: normal

As of the last release, quantlib-python no longer builds on riscv64 within
the 600 minute window. The source package quantlib-swig, using source package
libquantlib-dev, puts considerable strain on the C++ compiler and system and
several architectures have long used -O0 and similar switches.

As discussed in #1072650 (CC'ed) and proposed by Graham (also CC'ed),
removing the binary is the best course of action now: it permits users on
other platforms to use the package, and ongoing work to accommodate the build
system can continue.

Thanks,  Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1074007: ITP: yubihsm-connector -- USB to HTTP bridge for the YubiHSM

[Simon Josefsson]

Thanks for working on this package.

> I have the hardware and I intend to maintain this as part of
> https://salsa.debian.org/auth-team, which already has quite a few
> other Yubico-related packages.

What do you think about using pkg-security-team instead?  I haved moved
libntlm and shishi there too, and I see opportunity for more shared
contributions by merging the auth-team into pkg-security-team (or
rather: I don't see a lot of opportunity for team contributions in the
auth-team, and I'm hoping pkg-security-team is better at that).  I've
worked on a bunch of auth-team packages at some point in their history,
and I'm not sure there were ever any coherent team.

/Simon


signature.asc
Description: PGP signature

Bug#1073967: jose 11-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1073967 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: jose
Version: 11-2+deb12u1

Explanation: fix potential denial-of-service issue [CVE-2023-50967]

Bug#1073966: jose 10-3+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1073966 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: jose
Version: 10-3+deb11u1

Explanation: fix potential denial-of-service issue [CVE-2023-50967]

Bug#1073923: mobian-keyring 20230202.0+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1073923 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: mobian-keyring
Version: 20230202.0+deb12u1

Explanation: update Mobian archive key

Bug#1070137: cloud-init-22.4.2 22.4.2-2~deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1070137 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cloud-init-22.4.2
Version: 22.4.2-2~deb11u1

Explanation: introduce later-versioned replacement for cloud-init package

Bug#1072122: cloud-init 22.4.2-1+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1072122 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cloud-init
Version: 22.4.2-1+deb12u1

Explanation: declare conflicts/replaces on versioned package introduced for 
bullseye

Bug#1074008: RFS: sslscan/2.1.4-1 -- Tests SSL/TLS enabled services to discover supported cipher suites

[Alejo Marín]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : sslscan
   Version  : 2.1.4-1
   Upstream contact : rbsec 
 * URL  : https://github.com/rbsec/sslscan

 * License  : GPL-3.0+ with OpenSSL exception, ISC
 * Vcs  : https://salsa.debian.org/debian/sslscan
   Section  : utils

The source builds the following binary packages:

  sslscan - Tests SSL/TLS enabled services to discover supported cipher suites

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sslscan/sslscan_2.1.4-1.dsc


Changes since the last upload:

 sslscan (2.1.4-1) unstable; urgency=medium
 .
   [ Jhon Alejandro Marín Rodríguez ]
   * New upstream version 2.1.4

Regards,
-- 
  jamarin90

Bug#1074004: dh-golang: Include //go:embed referenced files during install

[Denis Manente]

`go list` seem to help to find embedded files:
https://pkg.go.dev/embed#hdr-Tools
> To support tools that analyze Go packages, the patterns found in 
//go:embed lines are available in “go list” output.
> See the EmbedPatterns, TestEmbedPatterns, and XTestEmbedPatterns 
fields in the “go help list” output.


```
~/golang-google-protobuf# go list -f '{{- if .EmbedFiles -}}{{ 
.ImportPath }} {{ .EmbedFiles }}{{ end }}' all

crypto/internal/nistec [p256_asm_table.bin]
google.golang.org/protobuf/internal/editiondefaults 
[editions_defaults.binpb]

```
filter to only list files from the current source needed

Bug#1074004: dh-golang: Include //go:embed referenced files during install

[Denis Manente]

`go list` seem to help to find embedded files:
https://pkg.go.dev/embed#hdr-Tools
> To support tools that analyze Go packages, the patterns found in 
//go:embed lines are available in “go list” output.
> See the EmbedPatterns, TestEmbedPatterns, and XTestEmbedPatterns 
fields in the “go help list” output.


```
~/golang-google-protobuf# go list -f '{{- if .EmbedFiles -}}{{ 
.ImportPath }} {{ .EmbedFiles }}{{ end }}' all

crypto/internal/nistec [p256_asm_table.bin]
google.golang.org/protobuf/internal/editiondefaults 
[editions_defaults.binpb]

```

Bug#1074007: ITP: yubihsm-connector -- USB to HTTP bridge for the YubiHSM

[Colin Watson]

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

* Package name: yubihsm-connector
  Version : 3.0.4
  Upstream Contact: Yubico Open Source Maintainers 
* URL : https://developers.yubico.com/yubihsm-connector/
* License : Apache-2.0
  Programming Lang: Go
  Description : USB to HTTP bridge for the YubiHSM 2

The YubiHSM 2 is a USB-attached device for managing cryptographic keys.
The YubiHSM Connector bridges the USB communication to HTTP, allowing
applications to use the device without needing direct access to the
device node, or needing to be on the same machine.

The Connector is not a trusted component.  Applications establish
cryptographic sessions with the device.


We're in the process of starting to use a YubiHSM in Freexian.  Upstream
does provide their own Debian packages, but given that there's no
licensing obstacle I'd prefer to have this in Debian.  I have the
hardware and I intend to maintain this as part of
https://salsa.debian.org/auth-team, which already has quite a few other
Yubico-related packages.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1074006: ITP: jinjax -- Super components powers for your Jinja templates

[Daniel Baumann]

Package: wnpp

  * Package name : jinjax
  * Upstream Author : Juan-Pablo Scaletti
  * License : MIT
  * Homepage : https://github.com/jpsca/jinjax
   https://jinjax.scaletti.dev

Regards,
Daniel

Bug#1074005: newsboat: Please update to 2.35

[Martin Dosch]

Hi Nikos,

thanks for the info, I wasn't aware of it. Just scared of losing 
newsboat in trixie ^^.


Best regards,
Martin

Am 21.06.2024 17:28, schrieb Nikos Tsipinakis:

Hi Martin,

Updating newsboat is currently blocked on 2.36 releasing due to 
https://github.com/newsboat/newsboat/issues/2748

Cheers,
Nikos

On Fri, 21 Jun 2024, at 17:23, Martin Dosch wrote:

Package: newsboat
Version: 2.32-3
Severity: wishlist

Dear Maintainer,

please update to the newest upstream version 2.35. Currently newsboat is
not in trixie and maybe we are lucky and the build issues will be also
resolved when updating.

Best regards,
Martin

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

Kernel: Linux 6.8.12-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 newsboat depends on:
ii  libc6 2.38-13
ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.8.0-1
ii  libgcc-s1 14.1.0-2
ii  libjson-c50.17-1+b1
ii  libncursesw6  6.5-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-2
ii  libstfl0  0.22-3+b8
ii  libtinfo6 6.5-2
ii  libxml2   2.12.7+dfsg-3

Versions of packages newsboat recommends:
ii  sensible-utils  0.0.23

newsboat suggests no packages.

-- no debconf information

Attachments:
* signature.asc


signature.asc
Description: PGP signature

Bug#1074005: newsboat: Please update to 2.35

[Nikos Tsipinakis]

Hi Martin,

Updating newsboat is currently blocked on 2.36 releasing due to 
https://github.com/newsboat/newsboat/issues/2748

Cheers,
Nikos

On Fri, 21 Jun 2024, at 17:23, Martin Dosch wrote:
> Package: newsboat
> Version: 2.32-3
> Severity: wishlist
>
> Dear Maintainer,
>
> please update to the newest upstream version 2.35. Currently newsboat is 
> not in trixie and maybe we are lucky and the build issues will be also 
> resolved when updating.
>
> Best regards,
> Martin
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (500, 
> 'unstable-debug'), (500, 'testing-debug'), (500, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.8.12-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 newsboat depends on:
> ii  libc6 2.38-13
> ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.8.0-1
> ii  libgcc-s1 14.1.0-2
> ii  libjson-c50.17-1+b1
> ii  libncursesw6  6.5-2
> ii  libsqlite3-0  3.46.0-1
> ii  libstdc++614.1.0-2
> ii  libstfl0  0.22-3+b8
> ii  libtinfo6 6.5-2
> ii  libxml2   2.12.7+dfsg-3
>
> Versions of packages newsboat recommends:
> ii  sensible-utils  0.0.23
>
> newsboat suggests no packages.
>
> -- no debconf information
>
> Attachments:
> * signature.asc

Bug#1074005: newsboat: Please update to 2.35

[Martin Dosch]

Package: newsboat
Version: 2.32-3
Severity: wishlist

Dear Maintainer,

please update to the newest upstream version 2.35. Currently newsboat is 
not in trixie and maybe we are lucky and the build issues will be also 
resolved when updating.

Best regards,
Martin

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

Kernel: Linux 6.8.12-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 newsboat depends on:
ii  libc6 2.38-13
ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.8.0-1
ii  libgcc-s1 14.1.0-2
ii  libjson-c50.17-1+b1
ii  libncursesw6  6.5-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-2
ii  libstfl0  0.22-3+b8
ii  libtinfo6 6.5-2
ii  libxml2   2.12.7+dfsg-3

Versions of packages newsboat recommends:
ii  sensible-utils  0.0.23

newsboat suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1074004: dh-golang: Include //go:embed referenced files during install

[Denis Manente]

Package: dh-golang
Version: 1.62
Severity: wishlist
X-Debbugs-Cc: denis.mane...@automatic-server.com

Dear Maintainer,

Can we consider to install files referenced by //go:embed automatically or by a 
env
(e.g. DH_GOLANG_INSTALL_EMBED) to the build directory? This reduces manual 
corrections
with DH_GOLANG_INSTALL_[EXTRA/ALL] and is probably more future-proof.

Example: golang-google-protobuf
https://salsa.debian.org/go-team/packages/golang-google-protobuf/-/commit/4e6acb3b273c64905dfdf67cc3977629ad8fdd6e
Author had to initially add and now change the path since the package has 
moved. This
could be automated if the embedded file list can be parsed/accessed in some way:
https://salsa.debian.org/go-team/packages/golang-google-protobuf/-/blob/cf9838f774366ec018ecdf0bc975d08c30d1c879/internal/editiondefaults/defaults.go#L11

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

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

Versions of packages dh-golang depends on:
ii  debhelper 13.15.3
ii  libdpkg-perl  1.22.6
ii  perl  5.38.2-4

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

Bug#1073267: About Lintian reports note

[Leandro Cunha]

There is an absurd amount of packages with the
acute-accent-in-manual-page information, which seems to me to report
false positives and we cannot consider this until it is validated as
valid (even more so at the moment that Lintian is now with some
problems left aside). Not all of Lintian's reports are accurate. I had
even forgotten to mention this and when I saw it here I ended up
remembering this detail.
https://udd.debian.org/lintian-tag.cgi?tag=acute-accent-in-manual-page

I am doing this as a note.
If you don't like this message, contribute to Lintian!
-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1073931: composer: security update broke feature branches

[Heiko Przybyl]

Package: composer
Followup-For: Bug #1073931
X-Debbugs-Cc: h...@users.noreply.github.com

Hi,

using composer_2.0.9-2+deb11u4 provided under [1] seems to fix the issue. I
wasn't able to trigger it anymore.

Kind regards,
Heiko

[1] https://people.debian.org/~taffit/composer/composer_2.0.9-2+deb11u4_all.deb

Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28

[Dirk Eddelbuettel]

On 21 June 2024 at 05:34, Dirk Eddelbuettel wrote:
| 
| On 21 June 2024 at 10:43, Sebastian Ramacher wrote:
| | Control: tags -1 moreinfo
| | 
| | On 2024-05-27 12:01:45 -0500, Dirk Eddelbuettel wrote:
| | > 
| | > Package: release.debian.org
| | > Severity: normal
| | > User: release.debian@packages.debian.org
| | > Usertags: transition
| | > 
| | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| | > experimental was has now cleared NEW.
| | > 
| | > I checked my email folder, and the last time this happened (gsl 2.7, early
| | > 2021) we attempted an automatic transition but some things got in the way 
it
| | > seems. Help from Graham (CC'ed) was invaluable then,
| | > 
| | > I am easy either way: a formal or automatic transition works for me, so
| | > please advise as to what you preferred course of action is. The package 
has a
| | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| | 
| | Did you perform test builds of the reverse dependencies?
| 
| Mo, how wow I trigger this?

Ok, now with more coffee and after an early morning bike ride:

  "No, how would I trigger this?"  Happy to help but will need a hint.

Dirk

| | If so, have bugs been filed for those failing to build?
| 
| See above.
| 
| Dirk
| 
| | 
| | Cheers
| | -- 
| | Sebastian Ramacher
| 
| -- 
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1073282: ITP: golang-github-charlievieth-fastwalk -- Fast directory traversal for Golang

[Vincent Blut]

[Obviously, I forgot to Cc the debian-go mailing list…]

Le 2024-06-20 23:08, Vincent Blut a écrit :
> Package: wnpp
> Followup-For: Bug #1073282
> 
> Hi,
> 
> I'm ready to push my work but sadly I'm still not allowed to push to the
> repository.¹ Could someone have a look at my access request?
> 
> Cheers,
> Vincent
> 
> ¹ 
> https://salsa.debian.org/go-team/packages/golang-github-charlievieth-fastwalk




signature.asc
Description: PGP signature

Bug#1068762: bookworm-pu: package oar/2.5.9-1+deb12u1

[Vincent Danjean]

  Hi,

Le 16/06/2024 à 00:43, Jonathan Wiltshire a écrit :

Control: tag -1 moreinfo

On Wed, Apr 10, 2024 at 03:10:25PM +0200, Vincent Danjean wrote:

+  * oar-web-status: add missing dependency to libcgi-fast-perl (Closes:
+#1068711)


This seems to be missing in the diff, unless I've misunderstood something?
debian/control isn't changed.


  Good catch. Sorry. Here is the updated debdiff in attachment
and the diff of the debdiff below:
$ diff -u old/debdiff debdiff
--- old/debdiff 2024-06-21 16:32:02.102400997 +0200
+++ debdiff 2024-06-21 16:30:14.997030785 +0200
@@ -18,6 +18,17 @@
  oar (2.5.9-1) unstable; urgency=medium

* New release
+diff -Nru oar-2.5.9/debian/control oar-2.5.9/debian/control
+--- oar-2.5.9/debian/control   2021-01-11 16:44:43.0 +0100
 oar-2.5.9/debian/control   2024-04-10 14:02:42.0 +0200
+@@ -194,6 +194,7 @@
+  libtie-ixhash-perl,
+  libappconfig-perl,
+  libsort-naturally-perl,
++ libcgi-fast-perl,
+  php,
+  php-mysql | php-pgsql
+ Suggests: oar-doc
 diff -Nru oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch 
oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
 --- oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch   
1970-01-01 01:00:00.0 +0100
 +++ oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch   
2024-04-10 14:02:42.0 +0200

  Regards,
Vincent

diff -Nru oar-2.5.9/debian/changelog oar-2.5.9/debian/changelog
--- oar-2.5.9/debian/changelog  2021-01-11 16:44:43.0 +0100
+++ oar-2.5.9/debian/changelog  2024-04-10 14:02:42.0 +0200
@@ -1,3 +1,16 @@
+oar (2.5.9-1+deb12u1) bookworm; urgency=medium
+
+  [ Pierre Neyron ]
+  * Fix Drawgantt-SVG with php8 (Closes: #1068444)
+- create_function does not exists anymore
+- static methods must be declared as such
+  * Fix the oar user creation on new install (locked otherwise) (Closes:
+#1068713)
+  * oar-web-status: add missing dependency to libcgi-fast-perl (Closes:
+#1068711)
+
+ -- Vincent Danjean   Wed, 10 Apr 2024 14:02:42 +0200
+
 oar (2.5.9-1) unstable; urgency=medium
 
   * New release
diff -Nru oar-2.5.9/debian/control oar-2.5.9/debian/control
--- oar-2.5.9/debian/control2021-01-11 16:44:43.0 +0100
+++ oar-2.5.9/debian/control2024-04-10 14:02:42.0 +0200
@@ -194,6 +194,7 @@
  libtie-ixhash-perl,
  libappconfig-perl,
  libsort-naturally-perl,
+ libcgi-fast-perl,
  php,
  php-mysql | php-pgsql
 Suggests: oar-doc
diff -Nru oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch 
oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
--- oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
1970-01-01 01:00:00.0 +0100
+++ oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
2024-04-10 14:02:42.0 +0200
@@ -0,0 +1,45 @@
+[drawgantt-svg] Fixes for PHP 8
+
+Backported from upstream 2.5.10
+
+Fix fatal errors occuring with PHP8:
+- The create_function function is REMOVED as of PHP 8.0.0. 
(https://www.php.net/manual/en/function.create-function.php)
+- Non-static methods Shuffle::Init() and Shuffle::get_int() cannot be called 
statically. Need to make them static.
+
+From: Pierre Neyron 
+
+diff --git 
a/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in 
b/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
+index 5fd3b636..e24d3faa 100644
+--- a/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
 b/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
+@@ -269,10 +269,10 @@ function date2px($date) {
+ // class to compute colors for jobs
+ class Shuffle {
+ protected static $singleton;
+-function init($shuffle_instance) {
++static function init($shuffle_instance) {
+ self::$singleton = $shuffle_instance;
+ }
+-function get_int($job) {
++static function get_int($job) {
+ if (self::$singleton === null) {
+ self::init(new Shuffle());
+ }
+@@ -603,7 +603,7 @@ class Resource {
+   if ($this->type == $CONF['resource_group_level']) {
+ $first_resource_base = true;
+   }
+-  usort($this->children, create_function('$a,$b','return $b->cmp($a);'));
++  usort($this->children, function($a,$b) { return $b->cmp($a); });
+   foreach ($this->children as $child) {
+ $h += $child->svg_hierarchy($x+$CONF['hierarchy_resource_width'], 
$y+$h, $labels);
+   }
+@@ -650,7 +650,7 @@ class Resource {
+   }
+ }
+ foreach ($states as $value => $date_weight_array) {
+-  usort($date_weight_array, create_function('$a,$b','list($d1,$w1)=$a; 
list($d2,$w2)=$b; return ($d1 != $d2)?(($d1 < $d2)?-1:1):(($w1 != $w2)?(($w1 < 
$w2)?1:-1):0);'));
++  usort($date_weight_array, function($a,$b) { list($d1,$w1)=$a; 
list($d2,$w2)=$b; return ($d1 != $d2)?(($d1 < $d2)?-1:1):(($w1 != $w2)?(($w1 

Bug#1074003: please switch from llvm-16 to a more recent one

[Michael Tokarev]

Source: ghc
Version: 9.4.7-5
Severity: important

Please remove references to llvm-15 from ghc, switching to a more recent llvm 
version.
Currently ghc 9.6.5 is in experimental, which already uses llvm-17.

llvm-15 should go, see 
https://release.debian.org/transitions/html/llvm-15-rm.html -
this is why this bug report is of severity: important.  It is holding more 
recent
llvm migration to testing, see #1068961

Thanks,

/mjt

Bug#1074002: ITP: python-graphene-directives -- schema directives implementation for graphene

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-graphene-directives
  Version : 0.4.6
  Upstream Contact: Strollby 
* URL : https://github.com/strollby/graphene-directives
* License : Expat
  Programming Lang: python
  Description : schema directives implementation for graphene

Graphene directives provides the implementation of schema directives
needed for graphene.

This is a dependency for graphene-federation (#1073797).

Bug#1051785: workaround

[Simon McVittie]

On Fri, 21 Jun 2024 at 12:55:34 +0200, C wrote:
> Neither [...], nor setting the gsettings entry
> on my user or as root, worked and I suspect it's because the value on the
> Debian-gdm user takes precedence.

Setting a gsettings entry for your user or for root is not expected to
affect the behaviour of the gdm greeter, because the gdm greeter does not
run as your user, or as root: it runs as Debian-gdm (or as gdm on Ubuntu).
So that part is as working as designed: if you want to change the behaviour
of the greeter, it is the Debian-gdm user's settings that must be changed,
and no other user's personal settings are going to affect it.

> Neither the dconf workaround suggested above, nor [...], worked

What dconf workaround would that be? I don't see one in the previous
messages to this bug.

The intended way to change the settings of the Debian-gdm user is to edit
/etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would
be to locate the line "[org/gnome/login-screen]" and fill in
"enable-smartcard-authentication=false" below it, so it looks
something like this:

...
[org/gnome/login-screen]
enable-smartcard-authentication=false
logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
...

And then restart gdm (the easiest/most reliable way is to reboot).

However, if you have already used a workaround that edits the user's
settings, like this one:

> sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm
> dbus-run-session gsettings set org.gnome.login-screen
> enable-smartcard-authentication false

then that is probably going to take a higher priority than whatever you
write into /etc/gdm3/greeter.dconf-defaults.

> For the record I didn't try the other suggestion in the bug (creating /etc/
> pam.d/gdm-password and using update-alternatives to set that as the default 
> for
> gdm-smartcard), but maybe Debian should have this as an option for people that
> run into this issue?
> If that's a valid option then believe it would be a simple addition to have
> that file (even called something else, like "gdm-no-smartcard",
> "gdm-password-only", etc.) in place, even if it's not the default.

Marco designed the smart card handling setup that is currently used in
Debian, so I'm not going to make changes to it without understanding his
design intentions.

I personally think using smart cards as orthogonal to PAM authentication
is likely to be more common than using them for PAM authentication, and
if I understand correctly, using smart cards for authentication needs
sysadmin configuration *anyway* to associate each smartcard with a user
ID; so I would personally prefer it if the default was to use ordinary
password authentication, with some sort of opt-in for using smart cards
to authenticate, which sysadmins would be expected to enable after they
have enrolled users (set up the smartcard -> user mapping).

In RHEL, it seems to be opt-in:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/authenticating-the-user-in-the-desktop-environment_using-the-desktop-environment-in-rhel-8#configuring-smartcard-authentication-in-gdm-using-the-command-line_authenticating-the-user-in-the-desktop-environment
Doing the equivalent in Debian/Ubuntu might make more sense than trying
to guess whether smart card authentication is wanted from whether smart
card hardware happens to be plugged in?

Or, perhaps smart card authentication could be active if and only if
at least one smartcard -> user mapping has been created?

Or, perhaps enable-smartcard-authentication should be one of the fields
that is included in our example /etc/gdm3/greeter.dconf-defaults ready
for users to edit? The default could be either true or false, whichever
seems more appropriate.

 smcv

Bug#1059158: fixed in 4:7.4.7-1+deb12u3, too

[Rene Engelhard]

# mark bugs fixed in  4:7.4.7-1+deb12u3 correctly, didn't get done
# because they were already archived
unarchive 1059158
fixed 1059158 4:7.4.7-1+deb12u3
unarchive 1069835
fixed 1069835 4:7.4.7-1+deb12u3

Bug#1017039: 0overlay-root vs 90dmsquash-live

[Laszlo]

Hello,

Some helpful context for this discussion from the current Ubuntu
packaging - 
https://git.launchpad.net/ubuntu/+source/dracut/commit/?id=18ebec86061b1c285b3a1be13d708240b5e8a332

Thanks,
  Laszlo

Bug#1074001: ITP: libdjinterop -- C++ library to allow access to DJ record database formats

[Boyuan Yang]

Package: wnpp
Owner: Boyuan Yang 
Severity: wishlist

* Package name: libdjinterop
  Version : 0.21.0
  Upstream Contact: Name 
* URL : https://github.com/xsco/libdjinterop
* License : LGPL-3.0-or-later
  Programming Lang: C++
  Description : C++ library to allow access to DJ record database formats

 The libdjinterop library is a C++ library that allows access to database
 formats used to store information about DJ record libraries.
 .
 This library currently supports:
   - Engine Library, as used on "Prime"-series DJ equipment.

This package is a dependency to the new version of mixxx.

This package will be maintained in Debian Multimedia Team.

Thanks,
Boyuan Yang



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

Bug#1073825: dracut: manual dracut creates initramfs-*.img files, post-install hook does initrd.img-*

[Laszlo]

Hello !

> The "initrdname" option does not seem to be suitable ...

>From the description of the upstream PR -
https://github.com/dracut-ng/dracut-ng/pull/160

> The initrdname configuration option is required to match a initr*${kernel}* 
> file pattern.

Would the following work ? If it does it should be probably added to
the Debian package config.

> initrdname="initrd-${kernel}.img"

Laszlo

Bug#1074000: RESTful API feature does not work, because of missing "orjson" library

[Michael Kussmaul]

Package: glances
Version: 4.0.5+dfsg-1

I use glances with Debian testing and with API mode, so I can query glances 
parameters over the included REST interface:

glances -w --disable-webui -B 0.0.0.0

But since version 4, this seems to be broken in Debian, because there is no 
"orjson" library found (orjson python package is not available in Debian 
testing).

Steps to reproduce:

1.) start glances in RESTful API mode:
 glances -w --disable-webui -B 0.0.0.0
2.) access API, eg. status:
 curl http://localhost:61208/api/4/status

it returns: "Internal Server Error"

and glances log-file logs the following error message:

Jun 21 10:20:47 mapout systemd[1]: Started glances.service - Glances.
Jun 21 10:20:47 mapout glances[1168]: INFO: Started server process [1168]
Jun 21 10:20:47 mapout glances[1168]: INFO: Waiting for application startup.
Jun 21 10:20:47 mapout glances[1168]: INFO: Application startup complete.
Jun 21 10:20:47 mapout glances[1168]: INFO: Uvicorn running on 
http://0.0.0.0:61208 (Press CTRL+C to quit)
Jun 21 14:23:41 mapout glances[1168]: ERROR:Exception in ASGI application
Jun 21 14:23:41 mapout glances[1168]: Traceback (most recent call last):
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/uvicorn/protocols/http/h11_impl.py", line 407, 
in run_asgi
Jun 21 14:23:41 mapout glances[1168]: result = await app(  # type: 
ignore[func-returns-value]
Jun 21 14:23:41 mapout glances[1168]:  
^^
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/uvicorn/middleware/proxy_headers.py", line 69, 
in __call__
Jun 21 14:23:41 mapout glances[1168]: return await self.app(scope, receive, 
send)
Jun 21 14:23:41 mapout glances[1168]:

Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/fastapi/applications.py", line 1054, in __call__
Jun 21 14:23:41 mapout glances[1168]: await super().__call__(scope, 
receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/applications.py", line 123, in 
__call__
Jun 21 14:23:41 mapout glances[1168]: await self.middleware_stack(scope, 
receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/middleware/errors.py", line 186, in 
__call__
Jun 21 14:23:41 mapout glances[1168]: raise exc
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/middleware/errors.py", line 164, in 
__call__
Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive, _send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/middleware/gzip.py", line 26, in 
__call__
Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/middleware/cors.py", line 85, in 
__call__
Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/middleware/exceptions.py", line 65, 
in __call__
Jun 21 14:23:41 mapout glances[1168]: await 
wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 64, in 
wrapped_app
Jun 21 14:23:41 mapout glances[1168]: raise exc
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 53, in 
wrapped_app
Jun 21 14:23:41 mapout glances[1168]: await app(scope, receive, sender)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/routing.py", line 756, in __call__
Jun 21 14:23:41 mapout glances[1168]: await self.middleware_stack(scope, 
receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/routing.py", line 776, in app
Jun 21 14:23:41 mapout glances[1168]: await route.handle(scope, receive, 
send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/routing.py", line 297, in handle
Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/routing.py", line 77, in app
Jun 21 14:23:41 mapout glances[1168]: await 
wrap_app_handling_exceptions(app, request)(scope, receive, send)
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 64, in 
wrapped_app
Jun 21 14:23:41 mapout glances[1168]: raise exc
Jun 21 14:23:41 mapout glances[1168]:   File 
"/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 53, in 
wrapped_app
Jun 21 14:23:41 mapout glances[1168]: await 

Bug#1059083: RFS: updated golang-github-azure-azure-sdk-for-go

[Maytham Alsudany]

Ping! Still need a sponsor to upload golang-github-azure-azure-sdk-for-
go. Urgently needed for new versions of rclone and prometheus. 

The other two new dependencies have already been uploaded.

On Mon, 2024-04-29 at 18:10 +0800, Maytham Alsudany wrote:
> Ping! Needed to update rclone package.
> 
> On Tue, 2024-04-16 at 10:20 +0300, Maytham Alsudany wrote:
> > Ping! Still looking for a sponsor.
> > 
> > On Sat, 2024-01-06 at 15:42 +0800, Maytham Alsudany wrote:
> > > Hi Go team,
> > > 
> > > I'm looking for a sponsor to upload the following packages.
> > > 
> > >  - golang-github-azure-azure-sdk-for-go (experimental)
> > >* Team upload
> > >* New upstream version 68.0.0+git20231220.f497335 (Closes: #1059083)
> > >* Update Depends and Build-Depends
> > >* Update d/watch to track HEAD
> > >* Disable all tests as they rely on network access
> > >* Override lintian warnings regarding test data

-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)

[Matthias Klose]

it's now Mid June, let's go on with this transition.  Please provide a 
transition slot now.


Thanks, Matthias

Bug#1073999: golang-github-protonmail-gluon: depend on golang-github-protonmail-go-mbox

[Maytham Alsudany]

Source: golang-github-protonmail-gluon
Severity: serious
Control: block -1 by 1059832

Dear Maintainer,

golang-github-protonmail-gluon should depend on the (not yet packaged)
golang-github-protonmail-go-mbox instead of patching emersion/go-mbox, 
asitmakesitunusablebyreversedependencies.

Kind regards,
Maytham


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

Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Diederik de Haas]

Control: found -1 6.6.15-1

On Friday, 21 June 2024 13:41:38 CEST Christoph Berg wrote:
> I just had the same problem on linux-image-6.6.15-amd64.

Updating found version accordingly.

> > It seems to me that at least with purging that file should be removed
> > and subsequently the ``/lib/modules/`` dir.
> 
> TBH, I'd even argue plain "remove" should remove the debris from the
> modules directory, it's not like there's anything of value in the
> modules.* files left behind.

I didn't have that many kernels installed, so I only verified it with 1 and for 
that I used 'purge'. But I'm inclined to agree that remove should remove that 
file too.

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

Bug#1073996: Info received (Bug#1073996: twisted: autopkgtest fails on test_flatten: "builtins.KeyError: 'root'")

[Florent 'Skia' Jacquet]

Updated patch with removal of now unused variable.diff -Nru twisted-24.3.0/debian/changelog twisted-24.3.0/debian/changelog
--- twisted-24.3.0/debian/changelog 2024-03-04 15:57:17.0 +0100
+++ twisted-24.3.0/debian/changelog 2024-06-21 11:20:23.0 +0200
@@ -1,3 +1,10 @@
+twisted (24.3.0-2) unstable; urgency=medium
+
+  * Patch: fix test_flatten in autopkgtest. (Closes: #1073996)
+This patch can probably be dropped after next upstream release.
+
+ -- Florent 'Skia' Jacquet   Fri, 21 Jun 2024 
11:20:23 +0200
+
 twisted (24.3.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru twisted-24.3.0/debian/patches/series 
twisted-24.3.0/debian/patches/series
--- twisted-24.3.0/debian/patches/series2024-03-04 15:57:17.0 
+0100
+++ twisted-24.3.0/debian/patches/series2024-06-21 11:20:23.0 
+0200
@@ -15,3 +15,4 @@
 debian-hacks/Drop-dependency-on-typing_extensions.patch
 debian-hacks/reproducible-docs.patch
 tests/skip-test_sendFileDescriptorTriggersPauseProducing.patch
+tests/Tests-Fix-test_flatten.patch
diff -Nru twisted-24.3.0/debian/patches/tests/Tests-Fix-test_flatten.patch 
twisted-24.3.0/debian/patches/tests/Tests-Fix-test_flatten.patch
--- twisted-24.3.0/debian/patches/tests/Tests-Fix-test_flatten.patch
1970-01-01 01:00:00.0 +0100
+++ twisted-24.3.0/debian/patches/tests/Tests-Fix-test_flatten.patch
2024-06-21 11:20:23.0 +0200
@@ -0,0 +1,42 @@
+From: Florent 'Skia' Jacquet 
+Date: Fri, 21 Jun 2024 12:06:48 +0200
+Subject: Test: Fix twisted.web.test.test_flatten
+
+Following some removal from Python itself, the following started to appear in 
autopkgtest:
+
+2993s ---  ---
+2993s   File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
1999, in _inlineCallbacks
+2993s result = context.run(
+2993s   File "/usr/lib/python3/dist-packages/twisted/python/failure.py", line 
519, in throwExceptionIntoGenerator
+2993s return g.throw(self.value.with_traceback(self.tb))
+2993s   File "/usr/lib/python3/dist-packages/twisted/web/_flatten.py", line 
435, in _flattenTree
+2993s roots.append(frame.f_locals["root"])
+2993s builtins.KeyError: 'root'
+
+This is fixed upstream in https://github.com/twisted/twisted/pull/12213
+This patch is a cherry-pick of the needed changes, and can probably be dropped 
next release.
+--- a/src/twisted/web/_flatten.py
 b/src/twisted/web/_flatten.py
+@@ -418,7 +418,6 @@
+ 
+ while stack:
+ try:
+-frame = stack[-1].gi_frame
+ element = next(stack[-1])
+ if isinstance(element, Deferred):
+ # Before suspending flattening for an unknown amount of time,
+@@ -428,11 +427,11 @@
+ except StopIteration:
+ stack.pop()
+ except Exception as e:
+-stack.pop()
+ roots = []
+ for generator in stack:
+-roots.append(generator.gi_frame.f_locals["root"])
+-roots.append(frame.f_locals["root"])
++if generator.gi_frame is not None:
++roots.append(generator.gi_frame.f_locals["root"])
++stack.pop()
+ raise FlattenerError(e, roots, extract_tb(exc_info()[2]))
+ else:
+ stack.append(element)

Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Christoph Berg]

Re: Diederik de Haas
> When removing or 'even' purging a linux-image- package, it
> reports the following issue:
> 
> rmdir: failed to remove '/lib/modules/': Directory not empty
> 
> The reason for that is that there's still a ``modules.weakdep`` file.

I just had the same problem on linux-image-6.6.15-amd64.

> It seems to me that at least with purging that file should be removed
> and subsequently the ``/lib/modules/`` dir.

TBH, I'd even argue plain "remove" should remove the debris from the
modules directory, it's not like there's anything of value in the
modules.* files left behind.

Kernels are the only package that I'm actually purging, if "remove"
wouldn't leave /lib/modules/*/ behind, I wouldn't have to do that.

Christoph

Bug#1073948: gtklock-playerctl-module: Stop using libsoup2.4

[Jeremy Bícha]

Control: forwarded -1
https://github.com/jovanlanik/gtklock-playerctl-module/issues/9

On Fri, Jun 21, 2024 at 7:35 AM Maytham Alsudany
 wrote:
>
> On Fri, 21 Jun 2024 19:10:25 +0800 Maytham Alsudany  
> wrote:
> > On Thu, 20 Jun 2024 10:50:29 -0400  Jeremy Bícha 
> >  wrote:
> > > libsoup3 was released in late 2021. This is a major API bump from 
> > > libsoup2.4.
> > >
> > > The Debian GNOME maintainers would like to stop building libsoup2.4.
> > > Therefore, please stop using libsoup2.4.
> >
> > This has been forwarded to upstream.
>
> Since this package was only uploaded about a week ago, feel free to increase
> the severity of this bug and remove gtklock-playerctl-module from testing if
> that helps with migration. In either case, I'll follow up with upstream in the
> meantime.

It seems unlikely that we will be able to remove libsoup2.4 from
Debian before Debian 13 "Trixie" is released; therefore I don't
believe it makes things worse to allow this new package into Testing
now.

Thank you,
Jeremy Bícha

Bug#1073948: gtklock-playerctl-module: Stop using libsoup2.4

[Maytham Alsudany]

On Fri, 21 Jun 2024 19:10:25 +0800 Maytham Alsudany  
wrote:
> On Thu, 20 Jun 2024 10:50:29 -0400  Jeremy Bícha  
> wrote:
> > libsoup3 was released in late 2021. This is a major API bump from 
> > libsoup2.4.
> > 
> > The Debian GNOME maintainers would like to stop building libsoup2.4.
> > Therefore, please stop using libsoup2.4.
> 
> This has been forwarded to upstream.

Since this package was only uploaded about a week ago, feel free to increase
the severity of this bug and remove gtklock-playerctl-module from testing if
that helps with migration. In either case, I'll follow up with upstream in the
meantime.

Kind regards,
-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Diederik de Haas]

Source: linux
Version: 6.9.2-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When removing or 'even' purging a linux-image- package, it
reports the following issue:

rmdir: failed to remove '/lib/modules/': Directory not empty

The reason for that is that there's still a ``modules.weakdep`` file.
It seems to me that at least with purging that file should be removed
and subsequently the ``/lib/modules/`` dir.

FWIW: I do not have any DKMS package which could also result in the
inability to remove the modules dir.

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZnVlCwAKCRDXblvOeH7b
bvdqAPwOCZQoQ5xXUbW+FkytY5Ovj5xoPizPFOWdFTvtaXro0QD/RhTTHvmL4cZ4
GfAOEDPN4Rv+vnze+lNZt+xCrTSa4AY=
=QCxl
-END PGP SIGNATURE-

Bug#1073948: gtklock-playerctl-module: Stop using libsoup2.4

[Maytham Alsudany]

Control: forwarded -1 
https://github.com/jovanlanik/gtklock-playerctl-module/issues/9
Control: usertag -1 + todo

On Thu, 20 Jun 2024 10:50:29 -0400  Jeremy Bícha  
wrote:
> libsoup3 was released in late 2021. This is a major API bump from
libsoup2.4.
> 
> The Debian GNOME maintainers would like to stop building libsoup2.4.
> Therefore, please stop using libsoup2.4.

This has been forwarded to upstream.

Thanks,
-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera



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

Bug#1073074: Info received (Bug#1073074: Acknowledgement (firefox: looses previous tabs))

[Vincent Lefevre]

Hi,

On 2024-06-19 13:39:56 -0700, Phil Dibowitz wrote:
> Mike Hommey  wrote:
> > This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1901899
> 
> Yes! I haven't been able to get it to remember my tabs for a week, but I put
> in the password once, and now my tabs are properly restored on startup (even
> if I don't enter the password). Nice catch, thanks!
> 
> It'd be great if we could get 127.0.1 in which this is fixed.

The firefox 127.0.1-1 Debian package is now available.
Is this bug fixed?

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