Bug#970575: pytorch-geometric: RFP -> ITP

[Andrius Merkys]

Control: retitle -1 ITP: pytorch-geometric -- Geometric Deep Learning
Control: owner -1 !

Hello,

I managed to successfully build pytorch-geometric. Will upload soon.

Andrius

Bug#1052149: bookworm-pu: package openssh/1:9.2p1-2+deb12u1

[Colin Watson]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh

[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bookworm.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release.  I agree.

[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions.  See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.

[ Tests ]
I have tested this manually as far as I'm able to do so.  Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent, and by disallowing remote addition of FIDO/PKCS#11
keys by default.

[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.

The third upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity.  Ubuntu did the same thing in their security updates
for this.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
See attached debdiff.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]
diff -Nru openssh-9.2p1/debian/.git-dpm openssh-9.2p1/debian/.git-dpm
--- openssh-9.2p1/debian/.git-dpm   2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/.git-dpm   2023-09-17 21:23:50.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-74edce484429249265baaee1e8a5d1785ee7afa7
-74edce484429249265baaee1e8a5d1785ee7afa7
+29c7785a3673101b3af8f6f712795fa128e52ddd
+29c7785a3673101b3af8f6f712795fa128e52ddd
 cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
 cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
 openssh_9.2p1.orig.tar.gz
diff -Nru openssh-9.2p1/debian/changelog openssh-9.2p1/debian/changelog
--- openssh-9.2p1/debian/changelog  2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/changelog  2023-09-17 21:23:50.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:9.2p1-2+deb12u1) UNRELEASED; urgency=medium
+
+  * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+  ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+  execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson   Sun, 17 Sep 2023 21:23:50 +0100
+
 openssh (1:9.2p1-2) unstable; urgency=medium
 
   * Fix mistakenly-unreleased entry for 1:9.2p1-1 in debian/NEWS.
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 
openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01 
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17 
21:23:50.0 +0100
@@ -0,0 +1,30 @@
+From dee3878689aef5365955442869be02d420b65ea6 Mon Sep 17 00:00:00 2001
+From: Damien Miller 
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream, 
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index b2e2b32a5..9e48c134e 100644
+--- a/ssh-pkcs11.c
 b/ssh-pkcs11.c
+@@ -1537,10 +1537,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+   error("dlopen %s failed: %s", provider_id, dlerror());
+   goto fail;
+   }
+-  if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+-  error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+-  goto fail;
+-  }
++  if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++  fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+   p = xcalloc(1, sizeof(*p));
+   p->name = xstrdup(provider_id);
+   p->handle = handle;
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 
openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01 
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 2023-09-17 
21:23:50.0 +0100
@@ -0,0 +1,104 @@
+From 5c06b89189eb27f692b900526d60bf744918511e Mon Sep 17 00:00:00 2001
+From: Damien Miller 
+Date: Fri, 7 Jul 2023 13:30:15 +1000
+Subject: 

Bug#1044217: flashbench: Fails to build source after successful build

[Bastian Germann]

I am uploading a NMU to fix this and several other issues.
The debdiff is included.diff -Nru flashbench-62/debian/changelog flashbench-62/debian/changelog
--- flashbench-62/debian/changelog  2012-11-13 23:36:04.0 +0100
+++ flashbench-62/debian/changelog  2023-09-18 10:40:00.0 +0200
@@ -1,3 +1,13 @@
+flashbench (62-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop Vcs fields along with get-orig-source (Closes: #1052151)
+  * Follow Homepage redirection (Closes: #792635)
+  * Fix description typo (Closes: #775230)
+  * Clean erase[.o] (Closes: #1044217)
+
+ -- Bastian Germann   Mon, 18 Sep 2023 10:40:00 +0200
+
 flashbench (62-1) unstable; urgency=low
 
   * Initial release (Closes: #693156) (LP: #1078488)
diff -Nru flashbench-62/debian/control flashbench-62/debian/control
--- flashbench-62/debian/control2012-11-13 19:06:58.0 +0100
+++ flashbench-62/debian/control2023-09-18 10:40:00.0 +0200
@@ -4,9 +4,7 @@
 Maintainer: Dmitrijs Ledkovs 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.3
-Homepage: http://git.linaro.org/gitweb?p=people/arnd/flashbench.git;a=summary
-Vcs-Bzr: lp:~ubuntu-core-dev/flashbench/debian
-Vcs-Browser: https://code.launchpad.net/~ubuntu-core-dev/flashbench/debian/
+Homepage: http://git.linaro.org/people/arnd.bergmann/flashbench.git
 
 Package: flashbench
 Architecture: any
@@ -15,5 +13,5 @@
  This utility helps to identify properties of SD cards and flash based
  storage. In particular it can be used to discover page and segement
  sizes and maximum number of concurrently open segments. These
- properties can then be used to better align paritions and tune
+ properties can then be used to better align partitions and tune
  filesystem options for maximum performance.
diff -Nru flashbench-62/debian/copyright flashbench-62/debian/copyright
--- flashbench-62/debian/copyright  2012-11-13 18:51:55.0 +0100
+++ flashbench-62/debian/copyright  2023-09-18 10:40:00.0 +0200
@@ -1,6 +1,6 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: flashbench
-Source: http://git.linaro.org/gitweb?p=people/arnd/flashbench.git;a=summary
+Source: http://git.linaro.org/people/arnd.bergmann/flashbench.git
 
 Files: *
 Copyright: 2010-2012 Arnd Bergmann 
diff -Nru flashbench-62/debian/patches/fix-clean-target.patch 
flashbench-62/debian/patches/fix-clean-target.patch
--- flashbench-62/debian/patches/fix-clean-target.patch 2012-11-13 
19:00:06.0 +0100
+++ flashbench-62/debian/patches/fix-clean-target.patch 2023-09-18 
10:40:00.0 +0200
@@ -15,4 +15,4 @@
 +
  clean:
 -  rm flashbench flashbench.o dev.o vm.o
-+  rm -f flashbench flashbench.o dev.o vm.o
++  rm -f erase erase.o flashbench flashbench.o dev.o vm.o
diff -Nru flashbench-62/debian/rules flashbench-62/debian/rules
--- flashbench-62/debian/rules  2012-11-13 18:57:34.0 +0100
+++ flashbench-62/debian/rules  2023-09-18 10:40:00.0 +0200
@@ -4,10 +4,3 @@
 
 %:
dh $@ 
-
-get-orig-source:
-   bzr export --per-file-timestamps \
-   -r$(DEB_VERSION_UPSTREAM) \
-   --root=$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM) \
-   $(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM).orig.tar.gz \
-   "lp:$(DEB_SOURCE)"

Bug#1052160: papirus-icon-theme: Please breakup the huge package into smaller packages

[Amr Ibrahim]

Package: papirus-icon-theme
Version: 20230901-1
Severity: wishlist

Dear Maintainer,

The icon theme package is enormous. Please breakup the huge package into
smaller packages. An idea is to split Papirus from EPapirus. Even more smaller
packages would be better.

Best,
Amr


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

Kernel: Linux 6.4.0-4-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 papirus-icon-theme depends on:
ii  hicolor-icon-theme  0.17-2

Versions of packages papirus-icon-theme recommends:
ii  librsvg2-common  2.54.7+dfsg-2

Versions of packages papirus-icon-theme suggests:
ii  gtk-update-icon-cache  3.24.38-5

-- no debconf information

Bug#983291: Re: Default font: Transition from DejaVu to Noto

[Fabian Greffrath]

> If I recall it correctly, the primary suggestion in that bug report
> is to split fonts-noto-core into an LCG and an "other" package.

I have created a MR to implement this:

https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1

 - Fabian



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

Bug#910377: System-critical package management

[Simon Richter]

Hi,

On 18.09.23 19:38, Julian Andres Klode wrote:


I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.


popen("systemd-inhibit ... cat", "w");

should work.

   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039529: [Debian-med-packaging] Bug#1039529: Bug#1039529: sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared

[Flavien Bridault]

Dear developers,

My message was maybe missed during the summer, I give a new attempt... I 
can offer a hand to provide the ITK patch if that can help...


Cheers,


*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE


Le 23/08/2023 à 09:54, Flavien Bridault a écrit :

Dear developers,

It turns out that sight FTBFS is due to a regression in itkMacro.h. 
This has been fixed upstream in 
https://github.com/InsightSoftwareConsortium/ITK/commit/7fbe8880a99ce1442b5b3e04ab05babdabe8e930. 



I could hack this in sight but this would be really tedious. This 
might break also other client code, as reported here 
https://github.com/InsightSoftwareConsortium/ITK/issues/4074/


Do you think it could be possible to add a patch for this in the 
insighttoolkit5 package ?


Thanks a lot.


*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
    IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg 
Cedex - FRANCE


Le 27/06/2023 à 00:10, Sebastian Ramacher a écrit :

Source: sight
Version: 21.1.1-3
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in 
the past)

X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=sight=amd64=21.1.1-3%2Bb2=1687809257=0 



[ 66%] Linking CXX shared library 
../../../lib/x86_64-linux-gnu/libsight_module_filter_vision.so
cd /<>/obj-x86_64-linux-gnu/modules/filter/vision && 
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/module_filter_vision.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wl,--as-needed -Wl,--sort-common 
-Wl,-O2 -Wl,-z,relro -Wl,-z,now -shared 
-Wl,-soname,libsight_module_filter_vision.so.21.1 -o 
../../../lib/x86_64-linux-gnu/libsight_module_filter_vision.so.21.1.0 
CMakeFiles/module_filter_vision.dir/Plugin.cpp.o 
CMakeFiles/module_filter_vision.dir/SColourImageMasking.cpp.o 
CMakeFiles/module_filter_vision.dir/SDepthImageMasking.cpp.o 
CMakeFiles/module_filter_vision.dir/SOpticalFlow.cpp.o 
CMakeFiles/module_filter_vision.dir/SPointCloudFromDepthMap.cpp.o 
CMakeFiles/module_filter_vision.dir/STransformDepthMap2mm.cpp.o 
CMakeFiles/module_filter_vision.dir/STransformDepthTL2mm.cpp.o 
CMakeFiles/module_filter_vision.dir/SUltrasoundImage.cpp.o 
CMakeFiles/module_filter_vision.dir/registerServices.cpp.o 
-Wl,-rpath,/<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/libopencv_highgui.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_video.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_service.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_geometry_data.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_filter_vision.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_io_opencv.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libopencv_videoio.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_features2d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_flann.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_activity.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libopencv_ml.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_data.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_core.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_log_setup.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_log.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_regex.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libxml2.so 
/usr/lib/x86_64-linux-gnu/libcrypto.so -ldl 
/usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_features2d.so.4.6.0 

Bug#1052167: RM: foo-yc20 -- ROM (team); RC-buggy; low popcon; depends on gtk2

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:foo-yc20

foo-yc20 is RC-buggy and nobody noticed up to now that it is unusable. Please 
remove it.
It has a low popcon and nobody in the Multimedia Team feels responsible for it. 
It also depends on gtk2.

Bug#1052162: python3-powerline-gitstatus: Seeing branch name but not (modified, ...) file counter

[Christian Buhtz]

Package: python3-powerline-gitstatus
Version: 1.3.2-1
Severity: normal

Dear Maintainer,

I installed the package "python3-powerline-gitstatus" but NOT "powerline-
gitstatus".

I migrated from Debian 11 to 12 (with installing everything fresh and new). In
Debian 11 I saw on my bash the branch  name and the counters for modified (etc)
files. But currently on Debian 12 I do see the branch name only. The counters
for modified or untracked files are missing.

I tried to install "powerline-gitstatus". When I do this everything related to
git (including the branch name) is missing in the bash powerline prompt. When I
purge that package the branch name comes back.

I did not configured powerline somehow. It do use the config files from /etc

Kind
Christian Buhtz


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages python3-powerline-gitstatus depends on:
ii  python33.11.2-1+b1
ii  python3-powerline  2.8.3-4

python3-powerline-gitstatus recommends no packages.

python3-powerline-gitstatus suggests no packages.

-- no debconf information

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Simon Josefsson]

tor 2023-09-14 klockan 11:10 +0200 skrev Jan Mojzis:
> > I would be happy to help review, co-maintain and upload this
> > package.
> 
> Great, thank You.
> 
> 
> First prototype for review:
> 'https://salsa.debian.org/janmojzis/lib25519'
> 
> if it's ok
> can you please create 'salsa.debian.org/debian/lib25519',
> I will move it there.

Great!

I have created it -- can you push everything there, and I will do a
review via a merge request to that repository?

/Simon

> 
> Currently without autopkgtest,
> I will add it when librandombytes package  arrives in unstable.
> 
> 
> Thanks
> Jan
> 



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

Bug#1052156: cryptsetup: please (temporarily) disable cryptroot-sysvinit autopkgtest

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi,

On Mon, 18 Sep 2023 at 10:46:30 +0100, Luca Boccassi wrote:
> With sysvinit scripts no longer being mandatory, the udev one has been
> removed from src:systemd. It is in the process of being adopted by
> src:sysvinit, but being optional and all that might take some time yet.
>
> Cryptsetup has a sysvinit autopkgtest that no longer works due to this,
> could you please disable it so that src:systemd can migrate?

Given 
https://tracker.debian.org/news/1464127/accepted-sysvinit-308-1-source-into-unstable/
I suppose this is no longer necessary?  At least our cryptroot-sysvinit
autopkgtest passes with sysv-rc=3.08-1 and udev=254.3-1.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1052163: gnome-shell crashed the moment of snapping a screenshot of part of the screen, while a Firefox picture-in-picture video was running always-on-top

[Amr Ibrahim]

Package: gnome-shell
Version: 44.4-1
Severity: normal

Dear Maintainer,

gnome-shell crashed the moment of snapping a screenshot of part of the screen,
while a Firefox picture-in-picture pop-out video was running always-on-top of
other windows.


Steps to reproduce:

1. Run a Firefox picture-in-picture video always-on-top
2. Snap a screenshot of part of the screen


Upstream believes that the bug could be somewhere else, not gnome:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7023


The core dump message and a stack trace are attached.


Best,
Amr


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

Kernel: Linux 6.4.0-4-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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   23.13.9-4
ii  gir1.2-adw-1 1.4~rc-1
ii  gir1.2-atk-1.0   2.49.91-2
ii  gir1.2-atspi-2.0 2.49.91-2
ii  gir1.2-freedesktop   1.78.0-1
ii  gir1.2-gcr-3 3.41.1-3
ii  gir1.2-gdesktopenums-3.0 45~rc-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   45~beta-1
ii  gir1.2-geoclue-2.0   2.7.0-3
ii  gir1.2-glib-2.0  1.78.0-1
ii  gir1.2-gnomebg-4.0   44.0-2
ii  gir1.2-gnomebluetooth-3.042.6-1
ii  gir1.2-gnomedesktop-4.0  44.0-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.5-1
ii  gir1.2-gtk-4.0   4.12.1+ds-3
ii  gir1.2-gweather-4.0  4.3.2-1
ii  gir1.2-ibus-1.0  1.5.29~rc1-1
ii  gir1.2-mutter-12 44.4-2
ii  gir1.2-nm-1.01.44.0-1
ii  gir1.2-nma4-1.0  1.10.6-1
ii  gir1.2-pango-1.0 1.51.0+ds-2
ii  gir1.2-polkit-1.0123-1
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-2
ii  gir1.2-soup-3.0  3.4.3-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.40.5-1
ii  gnome-backgrounds45~rc-1
ii  gnome-settings-daemon45~rc-1
ii  gnome-shell-common   44.4-1
ii  gsettings-desktop-schemas45~rc-1
ii  gstreamer1.0-pipewire0.3.80-2
ii  libatk-bridge2.0-0   2.49.91-2
ii  libatk1.0-0  2.49.91-2
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libecal-2.0-23.49.3-1
ii  libedataserver-1.2-273.49.3-1
ii  libgcr-base-3-1  3.41.1-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.78.0-1
ii  libgjs0g 1.76.2-4
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.78.0-1
ii  libglib2.0-bin   2.78.0-1
ii  libgnome-autoar-0-0  0.4.4-2
ii  libgnome-desktop-4-2 44.0-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.38-5
ii  libgtk-4-1   4.12.1+ds-3
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-12-0   44.4-2
ii  libnm0   1.44.0-1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libpolkit-agent-1-0  123-1
ii  libpolkit-gobject-1-0123-1
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.21.0-1
ii  libsystemd0  254.1-3
ii  libx11-6 2:1.8.6-1
ii  libxfixes3   1:6.0.0-2
ii  python3  3.11.4-5+b1

Versions of packages gnome-shell recommends:
pn  bolt   
pn  chrome-gnome-shell 
ii  

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

> 
> Great!
> 
> I have created it -- can you push everything there, and I will do a
> review via a merge request to that repository?
> 

Ready for the review:

Note:
- currently all ASM implementations are disabled,
so that we don't have a problem with a reproducible-build/symbols/PIC/etc... in 
the first phase

Jan

Bug#1052165: foo-yc20: Terminates directly

[Bastian Germann]

Source: foo-yc20
Severity: serious
Version: 1.3.0-6

The program is terminated directly with the following message, no matter if I 
try tro run the GUI or CLI version:

terminate called after throwing an instance of 'char const*'
Aborted

Bug#1052141: valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

[Mathieu Malaterre]

Source: valgrind
Version: 1:3.19.0-1

On amdhal.d.o:

% valgrind ./fails
==3527834== Memcheck, a memory error detector
==3527834== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3527834== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3527834== Command: ./fails
==3527834==
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x23
get_Form_szB: unhandled 35 (DW_FORM_rnglistx)
--3527834-- WARNING: Serious error when reading debug info
--3527834-- When reading debug info from /home/malat/pr110643/fails:
--3527834-- get_Form_contents: unhandled DW_FORM
--3527834-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92

valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree):
Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

host stacktrace:
==3527834==at 0x58040D44: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x58040E93: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x58040FFB: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C3BB7: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C3D53: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C91E3: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5807A497: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5806F613: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809E927: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580AB983: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809AA1B: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809647F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809882F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580DFC5F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable syscall 222 (lwpid 3527834)
==3527834==at 0x401AB6C: __mmap64 (mmap64.c:58)
==3527834==by 0x401AB6C: mmap (mmap64.c:46)
==3527834==by 0x40066F3: _dl_map_segments (dl-map-segments.h:139)
==3527834==by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268)
==3527834==by 0x40078BF: _dl_map_object (dl-load.c:2272)
==3527834==by 0x400243B: openaux (dl-deps.c:64)
==3527834==by 0x40012FB: _dl_catch_exception (dl-catch.c:237)
==3527834==by 0x40028EB: _dl_map_object_deps (dl-deps.c:232)
==3527834==by 0x4017A47: dl_main (rtld.c:1972)
==3527834==by 0x4014E8B: _dl_sysdep_start (dl-sysdep.c:140)
==3527834==by 0x4016273: _dl_start_final (rtld.c:497)
==3527834==by 0x4016273: _dl_start (rtld.c:584)
==3527834==by 0x401A193: (below main) (dl-start.S:30)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFF130
valgrind stack range: [0x1002CC 0x1002DB] top usage: 17968 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Bug#1052154: python-debian: Make 'Package-List' a multiline field

[Philipp Hahn]

Source: python-debian
Version: 0.1.39
Severity: wishlist

Dear Maintainer,

according to 
> Package-List:
> package package-type section priority key-value-list
>   This multiline field contains a list of binary packages generated by this 
> source package.

but it is not listed as "Multivalue fields" for "class Dsc" in
:

> _multivalued_fields = {
>   "files": ["md5sum", "size", "name"],
>   "checksums-sha1": ["sha1", "size", "name"],
>   "checksums-sha256": ["sha256", "size", "name"],
>   "checksums-sha512": ["sha512", "size", "name"],
> }

IMHO the following lines should be added:

> "package-list": ["package", "package-type", "section", "priority", 
> "key-value-list"],

This (slightly) changes the API as the returned type for
`Dsc()["package-list"]` changes, which might break existing code:
  old: str
  new: List[str]

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 28601b07cb3f9a46ad989b6b1fefba00363329e5 Mon Sep 17 00:00:00 2001
Message-Id: 
<28601b07cb3f9a46ad989b6b1fefba00363329e5.1695027946.git.h...@univention.de>
From: Philipp Hahn 
Date: Mon, 18 Sep 2023 11:01:37 +0200
Subject: [PATCH] fix!: Make Dsc["Package-List"] a multiline field

according to 
> Package-List:
> package package-type section priority key-value-list
>   This multiline field contains a list of binary packages generated by this 
> source package.

Register the field `Package-List` as a multi-valued field.

BREAKING CHANGE: This changes the return type from `str` to `List[str]`.
---
 src/debian/deb822.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/debian/deb822.py b/src/debian/deb822.py
index 2c08797..a1ce4b1 100644
--- a/src/debian/deb822.py
+++ b/src/debian/deb822.py
@@ -1909,6 +1909,7 @@ class Dsc(_gpg_multivalued, _VersionAccessorMixin):
 "checksums-sha1": ["sha1", "size", "name"],
 "checksums-sha256": ["sha256", "size", "name"],
 "checksums-sha512": ["sha512", "size", "name"],
+"package-list": ["package", "package-type", "section", "priority", 
"key-value-list"],
 }
 
 
-- 
2.30.2

Bug#1052159: Setting/changing passwords as admin does not work

[Guido Berhoerster]

Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-9

When creating a user or changing the password as an admin, the password
is not being set after submitting the form by clicking on the "Set
password" button.

Upon further inspection, the password change form seems to be opened 
with the selected entry, userManagement->pwd_change_queue property
contains the selected user, e.g.
"uid=gber,ou=people,ou=Teachers,dc=skole,dc=skolelinux,dc=no".  However
when submitting the form, userManagement->pwd_change_queue is empty so
that userManagement->handlePasswordQueue() method bails out at the start
instead of modifying the password.

The only error I see in the logs is this when the form is requested:

[Mon Sep 18 11:35:17.973862 2023] [php:error] [pid 68872] [client 
10.0.2.2:53452] PHP Fatal error:  Uncaught Exception: Serialization of 
'LDAP\\ResultEntry' is not allowed in [no active file]:0\nStack trace:\n#0 
{main}\n  thrown in [no active file] on line 0, referer: 
https://www/gosa/main.php?plug=1

-- 
Guido Berhoerster

Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser

[Aymeric Agon-Rambosson]

Le dimanche 17 septembre 2023 à 21:18, Bastian Germann 
 a écrit :


All of the listed packages build fine with the experimental 
gubo-parser.


Out of curiosity, how did you establish this ? I am currently 
running a loop of sbuild commands over the listed packages and the 
architectures, but I wonder whether there are some simpler ways.


That will not be needed. Next step for you is to file the 
transition bug. Youcan see already filed ones at:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org

In the bug you should tell them that there are no build failures 
with the experimental version in the reverse dependencies.


Will do, I'll keep you posted.

Bug#1051659: gdm3: GDM does not detect users correctly

[Marco Marzetti]

Hello,

I hit this issue today after upgrading to gdm 45~beta-1 . Switching to
"/etc/pam.d/gdm-smartcard-sssd-or-password" works, but breaks "face
chooser" on the GDM login screen.
Apparently the same happens also on Ubuntu. Please see:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1933027/comments/13 .

It would be great if either one could disable smart-card integration via
update-alternatives (as suggested here:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1933027/comments/12) or
if "gdm-smartcard-sssd-or-password" could provide the same login experience
as of the previous behavior.

Thank you

Regards

-- 
Marco

Bug#1052164: xemacs21: should not try to byte-compile the files from /usr/share/emacs/site-lisp

[Vincent Lefevre]

Package: xemacs21
Version: 21.4.24-12
Severity: important

Files in /usr/share/emacs/site-lisp are not necessarily compatible
with XEmacs. So XEmacs should not try to byte-compile them, or
at least, package installation should no fail because of that.

For instance, mmm-mode is not compatible with xemacs21, so that
its maintainer had to add "Conflicts: xemacs21". This is not
satisfactory: a multi-user machine may have the packages emacs-gtk
and xemacs21 installed because there are users who use GNU Emacs
and other users who use XEmacs. In such a case, with the current
situation, it is not possible to install mmm-mode for GNU Emacs
users because of the conflict. This is really bad.

FYI, here are the errors one obtains when installing mmm-mode
if "Conflicts: xemacs21" is removed and xemacs21 is installed:

[...]
Setting up mmm-mode (0.5.9-2) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install emacsen-common for xemacs21
emacsen-common: Handling install of emacsen flavor xemacs21
Loading /usr/share/emacsen-common/debian-startup...
Loading 00debian...
Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
Done
Install mmm-mode for emacs
install/mmm-mode: Handling install of emacsen flavor emacs
install/mmm-mode: byte-compiling for emacs
Install mmm-mode for xemacs21
install/mmm-mode: Handling install of emacsen flavor xemacs21
install/mmm-mode: byte-compiling for xemacs21
Compiling /usr/share/xemacs21/site-lisp/mmm-mode/cl-lib.el...
>>Error occurred processing cl-lib.el: Opening input file: No such file or 
>>directory, /usr/share/xemacs21/site-lisp/mmm-mode/cl-lib.el

Compiling /usr/share/xemacs21/site-lisp/mmm-mode/mmm-auto.el...
While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/mmm-mode/mmm-auto.el:
  !! File error (("Cannot open load file" "cl-lib"))
>>Error occurred processing mmm-auto.el: Cannot open load file: cl-lib
[...]
ERROR: install script from mmm-mode package failed
dpkg: error processing package mmm-mode (--configure):
 installed mmm-mode package post-installation script subprocess returned error 
exit status 1

If a cl-lib file is provided in order to attempt to support xemacs21,
there are other errors like

Wrong number of arguments: (lambda (oldfun newfun)  
(byte-code "..." [newfun oldfun define-function make-obsolete] 3)), 4   

because for some functions, the number of arguments for xemacs21
is different from the one for the latest GNU Emacs versions.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xemacs21 depends on:
ii  xemacs21-mule  21.4.24-12

xemacs21 recommends no packages.

xemacs21 suggests no packages.

-- no debconf information

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

Bug#1052166: mmm-mode: should avoid the conflict with xemacs21 by disabling the xemacs flavors

[Vincent Lefevre]

Package: mmm-mode
Version: 0.5.9-2
Severity: important
Tags: patch

The conflict with xemacs21 is not acceptable as it prevents the
installation of mmm-mode on machines with both emacs-gtk and xemacs21
installed (typically multi-user machines).

It appears that disabling the xemacs flavors avoids the installation
failure (see attached patch, which removes the conflict and patches
mmm-mode.emacsen-install to disable the xemacs flavors and do some
cleanup); apel and flim do something similar:

case $FLAVOR in
*xemacs*|emacs2[0-3]|emacs1?|mule2)
exit 0
;;
esac

and ditto for w3m-el:

case $FLAVOR in
*xemacs*|emacs2[0-5]|emacs1?|mule2)
exit 0
;;
esac

so I suppose that this is OK. It works on a test machine, where I
installed xemacs21 for the test, and I can select mmm-mode with
GNU Emacs. If there is any issue with xemacs21 at run time, this
is their problem.

Note that mmm-mode.emacsen-remove still has a comment about xemacs,
but I suppose that this doesn't matter.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mmm-mode depends on:
hi  emacs-gtk [emacsen]  1:27.1+1-3.1+b1
ii  emacsen-common   3.0.5
ii  xemacs21-mule [emacsen]  21.4.24-12

mmm-mode recommends no packages.

mmm-mode suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -aurd mmm-mode-0.5.9-a/debian/control mmm-mode-0.5.9-b/debian/control
--- mmm-mode-0.5.9-a/debian/control 2023-09-18 01:04:40.0 +0200
+++ mmm-mode-0.5.9-b/debian/control 2023-09-18 16:42:21.024106528 +0200
@@ -10,7 +10,6 @@
 Priority: optional
 Architecture: all
 Depends: emacs24 | emacsen | emacs-snapshot, emacsen-common (>= 2.0.8), 
${misc:Depends}
-Conflicts: xemacs21
 Homepage: https://github.com/purcell/mmm-mode
 Description: Multiple Major Mode for Emacs
  MMM Mode is a minor mode for Emacs that allows Multiple Major Modes
diff -aurd mmm-mode-0.5.9-a/debian/mmm-mode.emacsen-install 
mmm-mode-0.5.9-b/debian/mmm-mode.emacsen-install
--- mmm-mode-0.5.9-a/debian/mmm-mode.emacsen-install2018-09-23 
06:41:57.0 +0200
+++ mmm-mode-0.5.9-b/debian/mmm-mode.emacsen-install2023-09-18 
16:45:33.380094673 +0200
@@ -5,10 +5,14 @@
 FLAVOR="$1"
 FLAVORTEST=`echo $FLAVOR | cut -c-6`
 
+if [ ${FLAVORTEST} = xemacs ] ; then
+exit 0
+fi
+
 echo "install/mmm-mode: Handling install of emacsen flavor ${FLAVOR}"
 
 # e25 makes things stale and unflavoured, just emacs and source dir == compile 
dir
-# before that flavours emacs24, xemacs21 etc.
+# before that flavours emacs24, etc.
 echo "install/mmm-mode: byte-compiling for ${FLAVOR}"
 mkdir -p /usr/share/${FLAVOR}/site-lisp/mmm-mode
 
@@ -18,21 +22,12 @@
fi
 done
 
-# xemacs: cl-lib.el shipped in the flavour directory
-if [ "$FLAVORTEST" = "xemacs" ]; then
-   FILES="cl-lib.el $FILES"
-fi
-   
 cd /usr/share/${FLAVOR}/site-lisp/mmm-mode
 cat < path.el
 (setq load-path (cons "." load-path) byte-compile-warnings nil)
 EOF
-if [ ${FLAVORTEST} = xemacs ] ; then
-SITEFLAG="-no-site-file"
-else
-SITEFLAG="--no-site-file"
-fi
-${FLAVOR} -q ${SITEFLAG} -batch -l path.el -f batch-byte-compile $FILES
+
+${FLAVOR} -q --no-site-file -batch -l path.el -f batch-byte-compile $FILES
 rm -f path.el
 
 exit 0;

Bug#1050237: mutter: Upload mutter & GNOME Shell 45 to Unstable

[Simon McVittie]

On Tue, 22 Aug 2023 at 09:39:06 -0400, Jeremy Bícha wrote:
> This is a tracking and discussion bug for uploading Mutter & GNOME
> Shell 45 to Unstable.

I've done the usual mass-bug-filing for extensions that are not compatible
with the new Shell version:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-45

smcv

Bug#1052164: xemacs21: should not try to byte-compile the files from /usr/share/emacs/site-lisp

[Vincent Lefevre]

On 2023-09-18 16:20:00 +0200, Vincent Lefevre wrote:
> Files in /usr/share/emacs/site-lisp are not necessarily compatible
> with XEmacs. So XEmacs should not try to byte-compile them, or
> at least, package installation should no fail because of that.
> 
> For instance, mmm-mode is not compatible with xemacs21, so that
> its maintainer had to add "Conflicts: xemacs21". This is not
> satisfactory: a multi-user machine may have the packages emacs-gtk
> and xemacs21 installed because there are users who use GNU Emacs
> and other users who use XEmacs. In such a case, with the current
> situation, it is not possible to install mmm-mode for GNU Emacs
> users because of the conflict. This is really bad.
[...]

I've looked at the mmm-mode source and submitted a new bug with
a patch to avoid the issue on the mmm-mode side by disabling the
xemacs flavor (as other packages do that):

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

I suppose that this is sufficient, but I don't know the Emacs
handling in Debian...

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

Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled

[ivanhu]

Hi Boyuan,


On 9/18/23 02:58, Boyuan Yang wrote:

Source: acpica-unix
Version: 20230628-1
Severity: serious
X-Debbugs-CC: ivan...@canonical.com
Tags: sid

Hi Ivan Hu,

In the latest Debian package upload of acpica-unix/20230628-1, you removed 
big-endian support
for this package. However, you did not request to sync such changes with Debian 
Testing to
have existing big-endian packages (notably the s390x in Debian Testing). As a 
result, your
new upload cannot migrate to Debian Testing. It is likely that your package 
also stuck in
Ubuntu's -proposed repo for the same reason. You can check the package's 
condition at [1]
(and [2] for Ubuntu).

If you are clear that upstream is completely not supporting big-endian build 
anymore, please
submit a package removal request to Debian Release Team (using reportbug tool) 
to remove
the current s390x package in Debian Testing. If you don't know how to do it, 
please let me
know via email asap and I can help to make the report. Some similar effort may 
also be
necessary on the Ubuntu side.


yes, please help to make the report. Thanks!

Cheers,
Ivan



Thanks, and please let me know if you have further questions.

[1] https://tracker.debian.org/pkg/acpica-unix
[2] https://launchpad.net/ubuntu/+source/acpica-unix

Regards,
Boyuan Yang

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Jonathan Rubenstein]

Hi, where should I mention my RFS to hopefully get a sponsor? If anyone 
reading this is interested of course please respond, but there might be 
a suitable place with relevant uploaders who might be interested in 
sponsoring that I'm not aware of.


Any help is appreciated.

Best Regards,
  Jonathan Rubenstein

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:40:50PM +0200, Francesco P. Lovergine wrote:

I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?



I would simply patch Mozilla::CA to have SSL_ca_file() returning the Debian directory 
/usr/share/ca-certificates/mozilla instead of the cacert.pem file. That would avoid to patch 
third-parties code that eventually use explicitly the modules. 
This is compatible with the IO::Socket::SSL module.


Does it make sense? 


--
Francesco P. Lovergine

Bug#1052145: gjs: Please upgrade gjs to >= 1.77.2

[Simon McVittie]

On Mon, 18 Sep 2023 at 09:05:49 +0200, Jérémy Lal wrote:
> gpaste for gnome 45 depends on gjs >= 1.77.2.
> 
> I didn't check but it might be the case for other extensions ?

We cannot have gjs 1.77.2 until src:mozjs115 is accepted by the ftp team:
https://ftp-master.debian.org/new/mozjs115_115.1.0-1.html

smcv

Bug#1052168: libconfig-model-dpkg-perl: maps @copyright{} to no-info-found

[Andreas Metzler]

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

Hello,

something in libconfig-model-dpkg-perl seems to have changed, when
upgrading guile-gnutls with "cme update dpkg-copyright" the generated
file moved from

Files: doc/gnutls-guile.texi
Copyright: @copyright{} 2001-2023, Free Software Foundation, Inc.
License: GFDL-1.3+

to

Files: doc/gnutls-guile.texi
Copyright: no-info-found
License: GFDL-1.3+

while licensecheck still finds a copyright statement:
guile-gnutls-4.0.0$ licensecheck --copyright  --encoding utf8  --lines=300 
--shortname-scheme=debian,spdx doc/gnutls-guile.texi
doc/gnutls-guile.texi: GFDL-1.3+
  [Copyright: @copyright{} 2001--2023 Free Software Foundation, Inc.]

cu Andreas

Bug#1052033: davmail: Davmail uses too much memory

[Alexandre Rossi]

Hi,

> Upon launch Davmail uses 7.5GiB of virtual memory and 107.8MiB of
> resident memory but, after using it for about a day, 7.6GiB of virtual
> memory and 686MiB of resident memory.  Given that davmail only needs to
> keep a very small state, that seems to point to a memory leak.

I have prepared a change that may improve things a bit following
upstream suggested JVM arguments.

I would add that in Java, memory is mostly not managed by the program
so memory leaks cannot happen (although useless mamory usage can
happen). Regrading Java applications memory usage, you can read[1].

I'm not sure more can be done on this.

[1] https://stackoverflow.com/a/561450

Thanks,

Alex

Bug#986740: forked-daapd : please package new upstream release

[Sébastien Noel]

Le 2023-09-16 18:06, Bastian Germann a écrit :


I am happy to review and sponsor your upload.
Please add yourself as Uploader and keep it in the Multimedia Team.
Also, please rename the binary package to owntone.
There is a Debian package available from upstream:
https://github.com/owntone/owntone-apt
Maybe you can use parts of it.


Thank you for the proposal. I already have made the ajustements
to upgrade forked-daap to the newest owntone release,
but I'm not happy with it, and after a long thought I think it's best
to simply removed the software from the Debian archive.

The software in Debian is currently crippled due to the impossibility
to rebuild the web interface (based on the Vue.js framework with,
as usual in the JS world, a "not small" dependency tree).
The proper way of dialing with this (ie packaging all the missing
javascript modules) is more of a crusade than a weekend project.

I consider that shipping a software without half of the functionalities
is a disservice to our users, and an "insult" to upstream developer.
Upstream has already a pipeline that produce a complete package,
we should not pretend that we are doing better than them, specifically
if all we can deliver is a broken version.

Best regards,
Sébastien

Bug#986740: forked-daapd : please package new upstream release

[Bastian Germann]

Control: retitle -1 RM: forked-daapd -- ROM; RC-buggy; needs many Vue.js 
packages for full features
Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove forked-daapd. The package misses a lot of functionality because the Vue.js part cannot be used without a 
lot of packaging effort. It has two RC bugs which made it miss bullseye and bookworm. The only volunteer who considered 
working on it does no longer want to do it, so the package does not have a human being responsible for it.

Bug#1041708: Bug#1051979: Do not suggest APT::Default-Release setting

[Osamu Aoki]

Hi,

As far as I understand, my text comes from:
  $ man apt_preferences 

Since　Bug#1041708 was mentioned, I CC it.

I concur more-or-less with what Julian Andres Klode said for the solution.

I think what is needed is:
  by way of being not set up anymore, 
  nor presenting impression of recommendation in release notes.

## Debian Reference

As for the entry document such as Debian Reference, 

I should skip mentioning setting "APT::Default-Release" to whatever since
setting it in /etc/apt/apt.conf.d/* tends to cause persistent confusing setting.

If someone dare to set such thing, use /etc/apt/preferences with PIN priority. 
I have such example already with ample warnings.

## man apt_preferences

What is written there is 100% correct.  But it does create impression of using 

   APT::Default-Release "stable";

as a part of normal system configuration to some readers.

I think this document needs to explain apt system functionality thoroughly,
dropping use of `APT::Default-Release` reference may not be a option.

I propose to replace this line with 

   APT::Default-Release "testing";

I think this don't drive people to set this to "stable" as much.

If I go farther, to make deprecated usage of APT::Default-Release in
/etc/apt/apt.conf more explicit, I suggest that the following part:

   Note that this has precedence over any general priority you set in the
   /etc/apt/preferences file described later, but not over specifically pinned
   packages. For example,
   
should be changed to something along:

   Note that this has precedence over any general priority you set in the
   /etc/apt/preferences file described later, but not over specifically pinned
   packages. (In order to avoid confusion with /etc/apt/preferences settings,
   use of APT::Default-Release in /etc/apt/apt.conf is deprecated.)  For
   example,
   

That's my thought on this topic.

Osamu

On Mon, 2023-09-18 at 10:24 +0700, Max Nikulin wrote:
> On 16/09/2023 15:37, Osamu Aoki wrote:
> > So my first thought was replace it with:
> > 
> > - Release definition in "/etc/apt/apt.conf" configuration file started with
> > "APT::Default-Release"
> > 
> > But As I read complicationa it causes from your messages, let's drop it.  I
> > don't use it anyway.
> 
> Since the "APT::Default-Release" option is present in the document for 
> years, I would prefer to see a warning close to the current place where 
> it is mentioned. Consider somebody is asked about this setting and their 
> opens the reference to provide a link. Completely disappeared mention 
> may make them thinking that it was seen in another document.
> 
> I do not insist however. I admit that removing obsolete material 
> completely is widely used practice, so I am OK with your plan to just 
> drop it.
> 
>  From my point of view, it is worst variant when "APT::Default-Release" 
> is described without the not so trivial regexp or without a warning 
> concerning complications. This feature evolved into a kind of pitfall.
> 
> Thank you for your work on debian-reference.
> 
> 

Bug#1052146: UDD: broken data from bugs-binpkgs-pts CGI script

[Paul Wise]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

The UDD list of BTS binary packages for the PTS started outputting some
incorrect package names. I am not sure if these are caused by bad data
in the BTS itself or if something has broken in the UDD database.

   $ curl -sL https://udd.debian.org/cgi-bin/bugs-binpkgs-pts.cgi | grep -vP 
'^(?:src:)?[-a-z0-9.+]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+$' 
   115.2.0esr-1 severity: 0 1 0 0 0
   critical update 0 1 0 0 0
   firefox-esr  version: 0 1 0 0 0
   ng/dl.   debian 0 1 0 0 0
   trixie's 0 1 0 0 0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1052147: ITP: node-source-map-loader -- Node.js library to extract source maps

[Yadd]

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

* Package name: node-source-map-loader
  Version : 4.0.1
  Upstream Contact: JS Founadation
  
* URL : https://github.com/webpack-contrib/source-map-loader
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to extract source maps

node-source-map-loader is a JS library to extracts source maps from
existing source files. Can be used in a node-webpack rule.

It's a build dependency of node-jupyterlab, will be maintained under JS
Team umbrella.

Bug#1052148: ITP: pytorch-cluster -- PyTorch extension library of optimized graph cluster algorithms

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 970575 by -1

* Package name: pytorch-cluster
  Version : 1.6.1
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_cluster
* License : Expat
  Programming Lang: C
  Description : PyTorch extension library of optimized graph 
cluster algorithms (Python 3)


This package consists of a small extension library of highly optimized 
graph cluster algorithms for the use in PyTorch. The package consists of 
the following clustering algorithms:


  * Graclus from Dhillon et al.: Weighted Graph Cuts without 
Eigenvectors: A

Multilevel Approach
  * Voxel Grid Pooling from, e.g., Simonovsky and Komodakis: Dynamic
Edge-Conditioned Filters in Convolutional Neural Networks on Graphs
  * Iterative Farthest Point Sampling from, e.g. Qi et al.: PointNet++: 
Deep

Hierarchical Feature Learning on Point Sets in a Metric Space
  * k-NN and Radius graph generation
  * Clustering based on nearest points
  * Random Walk Sampling from, e.g., Grover and Leskovec: node2vec: 
Scalable

Feature Learning for Networks

All included operations work on varying data types and are implemented 
both for CPU and GPU.


pytorch-cluster is a test dependency for pytorch-geometric (ITP bug 
#970575).


Remark: This package is to be maintained with Debian Deep Learning Team at
   https://salsa.debian.org/deeplearning-team/pytorch-cluster

Bug#1043252: Next OCaml transition: 4.14.x

[Stéphane Glondu]

Hi,

OCaml 5.1.0 has just been released, and a version 4.14.2 will soon be 
released. Current version in unstable is 4.13.1.


I played a bit with opam-debian-switch, and it turns out that (at least) 
35 packages are broken (at the moment) with OCaml 5.1.0 whereas only 1 
seems broken with 4.14.1.


Therefore, I am planning to migrate to 4.14.x first.


Cheers,

--
Stéphane

Bug#1036256: golang-github-pin-tftp: FTBFS in testing

[Arnaud Rebillout]

I tried to rebuild the package locally, works for me. Tried to run 
autopkgtests in GitLab CI: worked [1]. It hints at flaky tests indeed...


I noticed that in Debian we package 2.2.0, however upstream is at 
version 3.0.0, with significant changes.


We have only two reverse build-deps: gobuster and ignition.

1) gobuster already uses pin-tftp 3.0

2) ignition seems to use an older version of pin-tftp, but I could 
rebuild it with pin-tftp 3.0 successfully


So I'm going to upload version 3.0 of pin-tftp, and I'll check if builds 
and autopkgtests succeed with this new version.


--

[1]: https://gitlab.com/arnaudr/golang-github-pin-tftp/-/jobs/5108371487

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1052156: cryptsetup: please (temporarily) disable cryptroot-sysvinit autopkgtest

[Luca Boccassi]

Source: cryptsetup
Severity: important
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Maintainer(s),

With sysvinit scripts no longer being mandatory, the udev one has been
removed from src:systemd. It is in the process of being adopted by
src:sysvinit, but being optional and all that might take some time yet.

Cryptsetup has a sysvinit autopkgtest that no longer works due to this,
could you please disable it so that src:systemd can migrate?

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1051465: [Debian-on-mobile-maintainers] Bug#1051465: Bug#1051465: unl0kr: Lacks automated migration when osk-sdl is already installed

[Arnaud Ferraris]

Hi,

Le 12/09/2023 à 10:30, undef via Debian-on-mobile-maintainers a écrit :
I seem to have dropped the BTS on reply, so including the history in 
this email.



Another option I realized might work is to add a `breaks` and `replaces` 
osk-sdl in unl0kr then ship a link from the osk-sdl keyscript to the 
unl0kr one in unl0kr. I haven't tested anything at this point, but this 
would mean we don't have to modify people's crypttab.


Some potential issues for this option:

* It would require an update to osk-sdl to make sure the crypttab config 
isn't removed if unl0kr is also installed.


* A user removing osk-sdl manually then installing unl0kr would need to 
configure things manually. Then again, neither would 3a below.




That sounds like an interesting idea indeed! This could be done by 
turning osk-sdl into a transitional package, which would depend on 
unl0kr, and would ship the symlink itself.


A few additional checks should probably be performed in maintainer 
scripts to ensure users won't end up with an unusable system unless 
doing something stupid (like removing both osk-sdl and unl0kr).


Cheers,
Arnaud


On 9/9/23 21:04, Arnaud Ferraris wrote:

Le 09/09/2023 à 11:27, undef via Debian-on-mobile-maintainers a écrit :

Thanks for getting the ball rolling on this one.

I think in the first instance we should switch c-s-m to unl0kr to 
catch new installs as you say. That'll stop the problem from getting 
worse. It would probably be a good idea to ask more technical users 
to make the switch too before making this type of change.


Yes, I believe this should be done ASAP as I think currently there's 
only the 2 of us actively using unl0kr, so getting it into more hands 
will likely help catch bugs and make it more stable.




After that, I have a couple of thoughts on the automated transition:

1. If unl0kr is installed while osk-sdl is it should probably do 
nothing. This avoids breaking working installs.


This is fine for now, but I think it should be revisited at some point 
in the future (ideally pre-trixie release, see below).




2. If unl0kr is installed and osk-sdl isn't it should check for 
osk-sdl's debconf setting indicating that c-s-m or similar configured 
crypttab in the first place. If this is set unl0kr could attempt to 
add its keyscript to the crypttab.


 a. This probably also requires a release of osk-sdl with the 
inverse to:


     * Deconfigure itself

     * Configure unl0kr

     * Set unl0kr's debconf flag as osk-sdl's is.


That sounds reasonable indeed.



3. A new install of unl0kr without osk-sdl ever having been installed 
could either:


 a. Do nothing, leaving the package installed in a dormant state 
as it is now.


 b. Prompt loudly using debconf then automatically attempt to 
configure (this is somewhat recommended against in debconf's docs).


 c. Just automatically attempt to configure (negating the need 
for 2).



I'm somewhat reticent to do 3c as this will break installs that are 
non-standard (say someone's configured a TPM or yubikey unlock), but 
there is at least some desire for the package automatically 
configuring the system: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028554


I think that 3a is the best option here, as it basically matches the 
current behaviour of osk-sdl, which is just fine.





That leaves the matter of how do we trigger the switch? Currently the 
only packages installed indicating FDE on Mobian devices are unl0kr 
and osk-sdl. I can't think of a neat way to cause one to be removed 
and replaced with the other without triggering the install on non-FDE 
devices.


I'm leaving the "how" aside for now, rather discussing the "why" here: 
IIUC osk-sdl is now unmaintained and will likely stay that way; 
therefore, as it's a rather critical component (in the sense that it 
deals with secrets/encryption) I believe it shouldn't be part of the 
upcoming Trixie release.


New installs (after the upcoming c-s-m changes are in) won't be 
affected, which is already a good thing; but I'm a bit reluctant to 
leave existing users with an unmaintained critical component, hence my 
belief that an automated migration would be nice.


As suggested by the bug severity this isn't an urgent matter though, 
and the idea of dropping osk-sdl for trixie can also be discussed.


Cheers,
Arnaud

PS: osk-sdl could be made a transitional package at some point, which 
would depend on unl0kr, and would take care of modifying the crypttab 
so unl0kr is used instead.





___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers



___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1052059: roundcube: Please apply security fix from 1.6.3

[Guilhem Moulin]

I requested a CVE ID for this issue.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1037091: podman run fails because of missing ~/.config/docker/config.json

[Reinhard Tartler]

Control: tag -1 +moreinfo +unreproducible

Hi Felix,

thanks for taking the time to write a bug report to Debian. I'm sorry to
hear that podman does not work for you as you'd expect. It seems to me that
you may have an old, possibly modified installation of podman on your
system, and I'd expect you wouldn't see this if you installed podman from
Debian in a fresh VM or new laptop. If you were, I'd absolutely love to
hear about this.

In order to recover your system, can you please try the command

podman system reset -f

You can read upon it at https://manpages.debian.org/podman-system-reset

Please let me know if that fixes the issue or whether you had further
thoughts or ideas on this.

Best,
-rt


On Sun, Jun 4, 2023 at 8:57 AM Felix Stupp 
wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b1
> Severity: important
>
>
> Dear maintainer,
>
> the current version of podman does not allow me to run any container due
> to the following error message:
> Error: stat /home/$USER/.config/docker/config.json: no such file or
> directory
>
> I can trigger this issue with a simple: podman run debian
> However, what container I try to run seems not to matter.
>
> The current version in experimental (4.4.0+ds1-1) is also not working on
> my machine.
>
> I cannot say which version introduced this issue as I do not use podman
> very often. To the best of my knowledge, the last time I used it, it
> worked fine and I do not know of any changes I introduced (beside
> updates) which could explain this issue.
>
> However, it still seems at least weird to me, that podman requires (not
> just reads optionally) a config file which is in Docker's config dir.
>
> I can append further debugging information if requested.
>
> Thanks
> Felix Stupp
>
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing
>   APT policy: (550, 'testing'), (500, 'testing-security'), (500,
> 'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350,
> 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  crun 1.8.1-1+b1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.36-9
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
> ii  runc 1.1.5+ds1-1+b1
>
> Versions of packages podman recommends:
> ii  buildah1.28.2+ds1-3+b1
> ii  dbus-user-session  1.14.6-1
> ii  fuse-overlayfs 1.10-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.13+dfsg1-1+b1
>
> Versions of packages podman suggests:
> ii  containers-storage  1.43.0+ds1-8
> ii  docker-compose  1.29.2-3
> ii  iptables1.8.9-2
>
> -- Configuration Files:
> /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
> '/etc/cni/net.d/87-podman-bridge.conflist'
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Moritz Muehlenhoff]

On Mon, Sep 18, 2023 at 07:27:24AM +0200, Salvatore Bonaccorso wrote:
> Moritz is taking care of releasing the DSA.

Indeed, all builds are in, I'll release tonight.

Cheers,
Moritz

Bug#1052150: bullseye-pu: package openssh/1:8.4p1-5+deb11u2

[Colin Watson]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh

[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bullseye.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release.  I agree.

[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions.  See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.

[ Tests ]
I have tested this manually as far as I'm able to do so.  Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent.

[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.

The second upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity.  Ubuntu did the same thing in their security updates
for this.

I wasn't able to backport the other part of upstream's fix for this
(disallowing remote addition of FIDO/PKCS#11 keys by default), because
that relies on the mechanism in
https://www.openssh.com/agent-restrict.html and bullseye doesn't have
that.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
See attached debdiff.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]
diff -Nru openssh-8.4p1/debian/.git-dpm openssh-8.4p1/debian/.git-dpm
--- openssh-8.4p1/debian/.git-dpm   2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/.git-dpm   2023-09-17 23:46:46.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-ed99ef256258d8556dbe39d976c2528ede050f14
-ed99ef256258d8556dbe39d976c2528ede050f14
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
 2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
 2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
 openssh_8.4p1.orig.tar.gz
diff -Nru openssh-8.4p1/debian/changelog openssh-8.4p1/debian/changelog
--- openssh-8.4p1/debian/changelog  2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/changelog  2023-09-17 23:46:46.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:8.4p1-5+deb11u2) bullseye; urgency=medium
+
+  * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+  ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+  execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson   Sun, 17 Sep 2023 23:46:46 +0100
+
 openssh (1:8.4p1-5+deb11u1) bullseye; urgency=medium
 
   * Backport from upstream:
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 
openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01 
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17 
23:46:46.0 +0100
@@ -0,0 +1,30 @@
+From 8175e38eaf5636f45c3f27f4eadee1d583b70d35 Mon Sep 17 00:00:00 2001
+From: Damien Miller 
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream, 
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index f495883d1..d864051c4 100644
+--- a/ssh-pkcs11.c
 b/ssh-pkcs11.c
+@@ -1519,10 +1519,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+   error("dlopen %s failed: %s", provider_id, dlerror());
+   goto fail;
+   }
+-  if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+-  error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+-  goto fail;
+-  }
++  if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++  fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+   p = xcalloc(1, sizeof(*p));
+   p->name = xstrdup(provider_id);
+   p->handle = handle;
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch 
openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01 
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch 2023-09-17 
23:46:46.0 +0100
@@ -0,0 +1,171 

Bug#1043252: Next OCaml transition: 4.14.x

[Julien Puydt]

Hi

Le lun. 18 sept. 2023, 09:37, Stéphane Glondu  a écrit :

>
> OCaml 5.1.0 has just been released, and a version 4.14.2 will soon be
> released. Current version in unstable is 4.13.1.
>
> I played a bit with opam-debian-switch, and it turns out that (at least)
> 35 packages are broken (at the moment) with OCaml 5.1.0 whereas only 1
> seems broken with 4.14.1.
>
> Therefore, I am planning to migrate to 4.14.x first.
>

I agree with that plan ; can you list which packages get broken in each
case?

Notice that as far as I know Coq isn't broken by the new OCaml but has
performance issues with it - the Coq and OCaml upstreams are trying to fix
this, so I expect new versions of both will get out when that will be fixed.

Cheers,

J.Puydt

>

Bug#1051498: RFS: strace/6.5-0.1 [NMU] -- System call tracer

[Bastian Germann]

Control: tags -1 - moreinfo

There was a new version uploaded.

Bug#1052146: UDD: broken data from bugs-binpkgs-pts CGI script

[Stuart Prescott]

On 18/09/2023 17:30, Paul Wise wrote:

$ curl -sL https://udd.debian.org/cgi-bin/bugs-binpkgs-pts.cgi | grep -vP 
'^(?:src:)?[-a-z0-9.+]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+$'
115.2.0esr-1severity: 0 1 0 0 0
criticalupdate 0 1 0 0 0
firefox-esr version: 0 1 0 0 0
ng/dl.  debian 0 1 0 0 0
trixie's 0 1 0 0 0



I don't think the BTS or UDD are broken here, I think that's just 
#1052073 which has some very interesting metadata that might take some 
time to clean up...



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1034590: precedence of /etc/containers/storage.conf should higher than /usr/share/containers/storage.conf

[Reinhard Tartler]

Control: tag -1 upstream

Hi,

Thanks for taking the time to report this. It doesn't sound like a problem
that we could fix in the packaging, but needs some code changes.  For this,
I'd like to ask you a favor. Can you please check if this was reported
before at https://github.com/containers/podman/issues ? If not yet, please
report it as https://github.com/containers/podman/issues/new/choose

In any case, please report back with the upstream issue number so that we
can track progress on resolving it.


On Fri, Jul 14, 2023 at 5:39 PM 鐘翊修  wrote:

> So
>
> |   Before upgrade to 4.4.0+ds1-1 (4.3)  |4.4.0+
> /etc/containers/strorage.conf|   use btrfs |btrfs
> /usr/share/containers/storage.conf  |   use
> overlayfs | overlayfs
>
> 
>
> When use 4.3, podman takes /etc/containers/storage.conf, so the storage
> is btrfs.
> But after upgrade 4.4.0+ (at least when it was April).
> Podman takes values in /usr/share/containers/storage.conf instead of
> /etc/containers/strorage.conf (wrong behavior)
> So just get the following
>
> User-selected graph driver \"overlay\" overwritten by graph driver
> \"btrfs\" from database
>
> That is the observed error. But not expected error.
>
> The expected behavior is
>
> Podman follows man 5 containers-storage.conf.
> Prefer values from /etc/containers/storage.conf.
>
> After version upgrade from 4.3 to 4.4, no configuration required, no
> reset required.
>
>
> Faidon Liambotis 於 2023/7/15 02:02 寫道:
> > Control: tags -1 moreinfo
> >
> > On Wed, Apr 19, 2023 at 09:24:21AM +0800, 鐘翊修 wrote:
> >> following man 5 containers-storage.conf,
> >> when a system have both /etc/containers/storage.conf and
> /usr/share/containers/storage.conf
> >>
> >> the values in /etc/containers/storage.conf overwrite the value in
> /usr/share/containers/storage.conf
> >>
> >> But in 4.4.0+ds1-1. with both files, podman takes the config from
> /usr/share/containers/stroage.conf
> >>
> >> To reproduce this
> >>
> >> Create podman graph database on podman 4.3.1 with btrfs (config in
> /etc/containers/storage.conf)
> >>
> >> upgrade from 4.3.1 to 4.4.0
> >>
> >> run the following command
> >>
> >> sudo podman info
> >>
> >> expected error message
> >>
> >> User-selected graph driver \"overlay\" overwritten by graph driver
> \"btrfs\" from database
> > I'm not sure I follow. Could you elaborate on the exact steps you took?
> > Do you mean that you expected to get this error message but didn't, or
> > that you got that error message even though you shouldn't have?
> >
> > Are you aware that you need to run "podman system reset" before changing
> > storage.conf? See podman-system-reset(1).
> >
> > Thanks,
> > Faidon
>
>

-- 
regards,
Reinhard

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[gregor herrmann]

On Mon, 18 Sep 2023 11:16:29 +0200, Francesco Paolo Lovergine wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Francesco Paolo Lovergine 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: libmozilla-ca-perl
>   Version : 20230821-1
>   Upstream Contact: Gisle Aas 
> * URL : https://github.com/libwww-perl/Mozilla-CA
> * License : MPL-2.0
>   Programming Lang: Perl
>   Description : Mozilla's CA cert bundle in PEM format

Attention attention :)

We don't package Mozilla::CA in Debian because we have
ca-certificates with the same certs.

Typically other modules either just work or need minimal patches to
find the certificates from ca-certificates.


Cheers,
gregor

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

Bug#1052142: ghc: Please add patch to restore minimal build support for sparc and sparc64

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.6-1
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello!

When upstream dropped NGC support for SPARC, they also accidentally removed 
build support
for unregisterised builds by removing sparc* and sparc64* from 
m4/ghc_convert_cpu.m4 and
m4/fptools_set_haskell_platform_vars.m4 meaning that building on sparc64 is no 
longer
possible.

The attached patch re-adds sparc and sparc64 to re-enable builds. The problem 
has also been
reported upstream [1].

Thanks,
Adrian

> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23959

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: ghc-9.4.6/m4/ghc_convert_cpu.m4
===
--- ghc-9.4.6.orig/m4/ghc_convert_cpu.m4
+++ ghc-9.4.6/m4/ghc_convert_cpu.m4
@@ -68,6 +68,12 @@ case "$1" in
   sh4)
 $2="sh4"
 ;;
+  sparc64*)
+$2="sparc64"
+;;
+  sparc*)
+$2="sparc"
+;;
   vax)
 $2="vax"
 ;;
Index: ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4
===
--- ghc-9.4.6.orig/m4/fptools_set_haskell_platform_vars.m4
+++ ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4
@@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 riscv64)
 test -z "[$]2" || eval "[$]2=ArchRISCV64"
 ;;
-hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax)
+hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax)
 test -z "[$]2" || eval "[$]2=ArchUnknown"
 ;;
 *)

Bug#1052143: ITP: node-html-loader -- Node module that exports HTML as string

[Yadd]

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

* Package name: node-html-loader
  Version : 4.2.0
  Upstream Contact: JS Foundation
  
* URL : https://github.com/webpack-contrib/html-loader
* License : Expat
  Programming Lang: JavaScript
  Description : Node module that exports HTML as string

node-html-loader exports HTML as string. HTML is minimized when the
compiler demands. It is typically used as node-webpack plugin.

node-html-loader is a dependency of node-jupyterlab and will be
maintained under JS Team umbrella

Bug#1052144: ghc: Needs to link against libatomic on at least m68k

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.6-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello!

On m68k, building ghc fails with:

"inplace/bin/ghc-stage1" -o utils/iserv/stage2_p/build/tmp/ghc-iserv-prof 
-hisuf p_hi -osuf  p_o -hcsuf p_hc -static -prof  -H32m -O -lffi -optl-pthread 
-Wall -hide-all-packages -package-env - -i -iutils/iserv/src 
-iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build 
-iutils/iserv/stage2_p/build/iserv/autogen 
-Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. 
-Iutils/iserv/stage2_p/build/.  -optP-include 
-optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id 
array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id 
bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 
-package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 
-no-hs-main -XHaskell2010  -threaded -optl-Wl,--export-dynamic -no-hs-main 
-no-user-package-db -rtsopts  -Wnoncanonical-monad-instances  -outputdir 
utils/iserv/stage2_p/build -split-sections   -static -prof  -H32m -O -lffi 
-optl-pthread -Wall -hide-all-packages -package-env - -i -iutils/iserv/src 
-iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build 
-iutils/iserv/stage2_p/build/iserv/autogen 
-Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. 
-Iutils/iserv/stage2_p/build/.  -optP-include 
-optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id 
array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id 
bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 
-package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 
-no-hs-main -XHaskell2010  -threaded -optl-Wl,--export-dynamic -no-hs-main 
-no-user-package-db -rtsopts  -Wnoncanonical-monad-instances  
utils/iserv/stage2_p/build/Main.p_o 
utils/iserv/stage2_p/build/cbits/iservmain.p_o
Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
Call hs_init_ghc() from your main() function to set these options.
/usr/bin/ld.bfd: 
/<>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.9.1_p.a(atomic.p_o):
 in function `hs_cmpxchg64':
atomic.c:(.text.hs_cmpxchg64+0x16): undefined reference to 
`__sync_val_compare_and_swap_8'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
make[2]: *** [utils/iserv/ghc.mk:104: 
utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1
make[2]: *** Waiting for unfinished jobs


which indicates that the build needs to link against libatomic.

This issue has also been reported upstream [1].

Thanks,
Adrian

> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23974

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1052152: python3-notebook: New Terminal tab/page is blank

[Emmanuel FARHI]

Package: python3-notebook
Version: 6.4.12-2.2
Severity: normal
X-Debbugs-Cc: emmanuel.fa...@synchrotron-soleil.fr

Dear Maintainer,

   * What led up to the situation?

The Jupyter server must be started, and a browser must point to it as client.
Then one should select the "New..." menu (top right), and select the lower
"Terminal" option.

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

Some users wish to interact with the server via shell commands. They open a
Terminal page, but it is shown as empty.

   * What was the outcome of this action?

The Terminal is not usable. The prompt in the terminal does not appear, but it
is shown as active.

   * Analysis

The file /usr/lib/python3/dist-packages/notebook/static/terminal/js/main.min.js
has been changed from a 1.3 MB size to 900 kB from bullseye to bookworm.
This file is generated from static/terminal/js/main.j,s which source code has
not changed.

So this is the conversion main.js -> main.min.js which is at the origin of the
bug.
It may have been generated via a new version of jquery which could be a hint to
find the root cause.



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

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

Versions of packages python3-notebook depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1
ii  libjs-backbone 1.4.1~dfsg+~1.4.15-3
ii  libjs-bootstrap3.4.1+dfsg-3
ii  libjs-bootstrap-tour   0.12.0+dfsg-5
ii  libjs-codemirror   5.65.0+~cs5.83.9-2
ii  libjs-es6-promise  4.2.8-12
ii  libjs-jed  1.1.1-4
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-typeahead 2.11.0+dfsg1-3
ii  libjs-jquery-ui1.13.2+dfsg-1
ii  libjs-marked   4.2.3+ds+~4.0.7-2
ii  libjs-mathjax  2.7.9+dfsg-1
ii  libjs-moment   2.29.4+ds-1
ii  libjs-requirejs2.3.6+ds+~2.1.34-2
ii  libjs-requirejs-text   2.0.12-1.1
ii  libjs-text-encoding0.7.0-5
ii  libjs-underscore   1.13.4~dfsg+~1.11.4-3
ii  libjs-xterm3.8.1+~cs0.9.0-1
ii  python33.11.2-1+b1
ii  python3-argon2 21.1.0-2
ii  python3-ipykernel  6.17.0-1
ii  python3-ipython-genutils   0.2.0-5
ii  python3-jinja2 3.1.2-1
ii  python3-jupyter-client 7.4.9-2
ii  python3-jupyter-core   4.12.0-1
ii  python3-nbconvert  6.5.3-3
ii  python3-nbformat   5.5.0-1
ii  python3-nest-asyncio   1.5.4-1
ii  python3-prometheus-client  0.16.0-0.1
ii  python3-send2trash 1.8.1~b0-2
ii  python3-terminado  0.17.0-1
ii  python3-tornado6.2.0-3
ii  python3-traitlets  5.5.0-1
ii  python3-zmq24.0.1-4+b1

Versions of packages python3-notebook recommends:
ii  python3-ipywidgets  6.0.0-11

Versions of packages python3-notebook suggests:
ii  python-notebook-doc  6.4.12-2.2

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/python3/dist-packages/notebook/static/terminal/js/main.min.js (from 
python3-notebook package)

Bug#910377: System-critical package management

[Guillem Jover]

[ CCing #910377 for some context. ]

Hi!

On Thu, 2023-09-07 at 11:59:47 +0900, Simon Richter wrote:
> > The lack of any system of recognition for packages that are critical to 
> > system operation impedes the reliability of Debian-based systems. For 
> > example, a reboot during a background package upgrade process on critical 
> > system packages unbeknownst to the user may result in the system unable to 
> > boot as expected, with little readily-available feedback to the user as to 
> > the cause.
> 
> Locking out reboots while the package manager is active is a policy that
> needs to be provided by the policy layer that allows ordinary users to
> reboot -- so this is the responsibility of the desktop environment.
> 
> The base system and package manager require superuser privileges for both
> reboot and invoking the package manager. For single-user systems, it is the
> responsibility of the administrator to not issue a reboot command while a
> package upgrade is in progress, which is not an onerous requirement because
> the package upgrade must be manually commanded as well.

I guess one case that this does not cover is when the user initiates a
shutdown/reboot, and an external superuser might be performing remote
package management on that system.

But in that case, that same superuser can use a frontend that already
inhibits those actions (such as apt), or on systems using systemd can
run dpkg via systemd-inhibit.

> > A potential middle-ground solution to this is to allow packages to
> > be marked as "system-critical" to DPKG by external system components
> > - for example a standard desktop Ubuntu system might mark the Gnome
> > Display Manager, Networking drivers, and others in this way during
> > installation.  These system-critical packages could then be protected
> > by DPKG in the following ways:
> 
> > - They are automatically reverted to a known good state on upgrade
> >   failure (e.g. previous version)
> 
> Generally, packages are expected to go from one functional state to another
> in a very quick operation after verifying that the operation can be
> performed.

Well dpkg is supposed to be resilient against system crashes, abrupt
shutdowns or reboots anyway, breakage in dpkg in those cases (but not
due to specific handling from within some other package) should be
considered bugs in dpkg.

> > - They cannot be removed without being unmarked as "system-critical"
> 
> We have "Essential: yes", which dpkg protects, and "Protected: yes", which
> are protected by apt.

Both are protected by dpkg and apt, for dpkg just with different
--force- options, so that you can control which one to let through.

> > - The system could check during every shutdown that system-critical
> >   packages are in a consistent state, reverting to a known good
> >   state if not
> 
> Again, this would need to be inside the policy layer that defines "shutdown"
> -- there are many of those, and most of them are outside the Debian system
> (e.g. if you run Debian in a container under Kubernetes, then Kubernetes is
> the policy layer that would be responsible for that.

Agreed.

> On desktop systems, systemd is the appropriate policy layer to decide about
> reboots, and (if I remember correctly) packagekit is the policy layer that
> invokes dpkg, so packagekit would need to inhibit reboots while it is
> working, and it can do so easily because it can assume systemd to be present
> and running.

apt already does this, so any other frontend using libapt or apt
directly will get this automatically.

> > I am interested in knowing the communities' thoughts on this, and if
> > these ideas have any merit to them.
> 
> On the lower levels, what can be reasonably implemented already is. The
> lockout you describe belongs into the desktop system, but it would require
> new UI to be developed to be useful -- rejecting the reboot is easy, but
> indicating to the user why the reboot was rejected or disabling the option
> requires a new communication channel, and without that functionality, the
> user experience would be "I tried to reboot and it didn't do anything."
> 
> Breaking the layer separation would be a horrible complicated mess -- adding
> new low level errors means adding appropriate error handlers to all
> intermediate layers until the error can bubble up to the user. This is
> something component systems have historically struggled with -- every time
> Windows displays some "error code c0312313" type dialog, this is a missing
> handler chain.

While dpkg on systems using systemd _could_ by default take an
system inhibitor lock, and could provide a good enough reason like say
"Packaging system upgrade" or whatever, my concern has been with the
added dependency chain, and after reading your mail and thinking about
this now, I have to agree this seems like a higher level policy.
(Of course dpkg could also do that and grow a new --no-inhibit,
or --refuse-inhibit or similar option, but still.)

But 

Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a

[Lee Garrett]

Hi Cord,

On 17.09.23 12:02, Cord Beermann wrote:

tags 1050906 wontfix
severity 1050906 wishlist
thanks

Hallo! Du (Lee Garrett) hast geschrieben:


>From a user experience it's currently a bit cumbersome, as I'll send a mail,
wait 15 minutes to notice that it hasn't arrived, change a few things and
resend, wait another 15 minutes, etc. Which is quite an ineffective workflow.


Rejecting based on Mail content is discouraged by a RfC.

If we would reject misdirected mails to our lists we would produce

2 backscatter mails daily to mostly innocent netizens.


Rejecting ingress mails at the SMTP level can't and won't create backscatter 
mails. You're probably thinking of bouncing mails?



So in the current state of Mail-Federation which is mostly driven by
spamming monopolists I don't see a working solution.

Yours,
 Cord, Debian Listmaster of the day

Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1

[Emilio Pozuelo Monfort]

On 17/09/2023 17:12, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Sun, 2023-09-17 at 11:36 +0200, Emilio Pozuelo Monfort wrote:

This updates rust-cbindgen to 0.24, as required by Firefox ESR 115.
The risk is low as the only (build)rdep of cbindgen are firefox-esr
and thunderbird.

Attached is a debian/ diff of the update.



-  * Only build the cbindgen binary.

afaict that's still true, so maybe the changelog entry should still be
present?


Ack. I removed it because the packages are already gone in the current version 
in bullseye, so there's no change to the status quo. However I see how we're 
documenting the changes wrt the previous version in d/changelog, so that entry 
is still relevant. Added back.



In any case, please go ahead.


Uploaded.

Cheers,
Emilio

Bug#1052157: RM: mozjs78 -- RoM; unmaintained, use mozjs115 instead

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: mozj...@packages.debian.org
Affects: src:mozjs78

Please remove mozjs78.

mozjs is the SpiderMonkey JavaScript engine for Firefox. mozjs78 is
from Firefox ESR 78 which is no longer supported. It has no remaining
reverse dependencies in Unstable.

The supported alternative is mozjs115 (currently in Debian's NEW
queue). mozjs102 reaches End of Life in a few days.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#904044: Fwd: OpenVPN3

[Marc Leeman]

-- Forwarded message -
From: Marc Leeman
Date: Mon, 18 Sept 2023 at 13:34
Subject: OpenVPN3
To: OpenVPN maintainer

Hi,

Because our company decided "there will be no impact" to use multifactor
authentication, I was forced to package openvpn3.

I don't know if you were planning anything in that direction, but my
current work can be found here:

https://salsa.debian.org/televic-team/openvpn3

It's rough, I need to go through the finer details.

If you are nog planning anything, I can open an ITP.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044

-- 
g. Marc


-- 
g. Marc

Bug#1052145: gjs: Please upgrade gjs to >= 1.77.2

[Jérémy Lal]

Package: gjs
Version: 1.76.2-4
Severity: wishlist

gpaste for gnome 45 depends on gjs >= 1.77.2.

I didn't check but it might be the case for other extensions ?

Jérémy


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 gjs depends on:
ii  gir1.2-gtk-3.0  3.24.38-5
ii  libc6   2.37-8
ii  libgcc-s1   13.2.0-3
ii  libgjs0g1.76.2-4
ii  libglib2.0-02.78.0-1
ii  libstdc++6  13.2.0-3

gjs recommends no packages.

gjs suggests no packages.

-- no debconf information

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Trent W. Buck]

On Wed 11 Jan 2023 00:17:44 +, Gervase wrote:
> On Sat, 2022-12-24 at 14:16 +, Gervase wrote:
> > Awhile back, I did have a look around the fix.  From what I
> > remembered,
> > intrigeri's solution used a systemd shutdown 'script' to check for
> > devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
> > commands to umount the partitions.
> 
> Apparently, I got confused.  What I saw is the script called 'shutdown'
> from the mkinitcpio package used in Arch Linux (see 
> https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/shutdown
> ).
> 
> What it does is (1) recursively umount the devices, (2) detaches loop
> back devices and then (3) disassembles stacked devices (i.e. encrypted
> devices, lvm and raid).
> 
> In contrast, what intrigeri's solution SEEMS to do (I haven't done any
> experimentation using the solution) is provide a way for Debian's initrd
> process to "pivot" back to a systemd shutdown procedure within an
> initramfs environment, as opposed to running the Arch Linux shutdown
> script.  This shutdown procedure differs from Arch Linux's because its
> initramfs infrastructure differs from Debian's, I assume?

It does final umount/swapoff :

https://github.com/systemd/systemd/blob/v252/src/shutdown/shutdown.c#L422

i.e. it's similar to arch's script, except it's 1) C code; 2) distro-agnostic; 
and 3) a bit feature-limited.

I think if you want it to run arbitrary other commands (e.g. "zpool export 
-a"), you would need more code.

I think for that you'd want systemdize /run/initramfs/shutdown
(i.e. be a copy of systemd's /bin/init), and then run some subset of
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L291-L330

Note that systemd can "be" the boot initrd, too, which is the previous flow 
chart:
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L236-L288

AFAIK Debian initramfs-tools doesn't support this at all.
AFAIK ArchLinux supports this, but it is opt in (off by default).

Last time I looked (around Debian 10),
Debian dracut theoretically supported putting systemd in charge of boot initrd 
(and shutdown initrd?), BUT
it also installed a zillion bits of coreutils that systemd itself doesn't use.
Since my goal was to REDUCE the attack surface of the boot initrd, I gave up on 
dracut at the time.

> As intrigeri wrote in his instructions, the relevant scripts would need
> to be written for dismantling devices ('virtual' or physical) and placed
> in /usr/share/initramfs-tools/hooks/* (if I understood things
> correctly).  So, if ZFS was installed as root, there would need to be a
> script for that and/or if LUKS was installed as root, there would need
> to be a script for that, etc...

I think it'd be better if /run/initramfs/shutdown used existing code -- either
/lib/systemd/systemd-shutdown/*.shutdown, or
maybe .service units, if that's appropriate.

But I confess I still do not understand how a "pure systemd" boot initrd + 
shutdown initrd would actually look.

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[gregor herrmann]

On Mon, 18 Sep 2023 14:29:08 +0200, gregor herrmann wrote:

> > * Package name: libmozilla-ca-perl
> 
> We don't package Mozilla::CA in Debian because we have
> ca-certificates with the same certs.

I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?


Cheers,
gregor

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

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:33:18PM +0200, gregor herrmann wrote:

On Mon, 18 Sep 2023 14:29:08 +0200, gregor herrmann wrote:


> * Package name: libmozilla-ca-perl

We don't package Mozilla::CA in Debian because we have
ca-certificates with the same certs.


I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?

--
Francesco P. Lovergine

Bug#1052141: Acknowledgement (valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.)

[Mathieu Malaterre]

Reproducer

% clang++-16 -std=c++17 -Wfatal-errors -Wall -Wextra -Werror -O1 -o
fails 
'-DHWY_DISABLED_TARGETS=(HWY_NEON|HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128)'
math_test4.cc -lhwy -lhwy_contrib -lhwy_test
% valgrind ./fails
// Copyright 2020 Google LLC
// SPDX-License-Identifier: Apache-2.0
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//  http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

#ifndef HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_
#define HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_

// Memory allocator with support for alignment and offsets.

#include 
#include 

#include "hwy/base.h"

namespace hwy {

// Minimum alignment of allocated memory for use in HWY_ASSUME_ALIGNED, which
// requires a literal. This matches typical L1 cache line sizes, which prevents
// false sharing.
#define HWY_ALIGNMENT 64

// Pointers to functions equivalent to malloc/free with an opaque void* passed
// to them.
using AllocPtr = void* (*)(void* opaque, size_t bytes);
using FreePtr = void (*)(void* opaque, void* memory);

// Returns null or a pointer to at least `payload_size` (which can be zero)
// bytes of newly allocated memory, aligned to the larger of HWY_ALIGNMENT and
// the vector size. Calls `alloc` with the passed `opaque` pointer to obtain
// memory or malloc() if it is null.
HWY_DLLEXPORT void* AllocateAlignedBytes(size_t payload_size,
 AllocPtr alloc_ptr, void* opaque_ptr);

// Frees all memory. No effect if `aligned_pointer` == nullptr, otherwise it
// must have been returned from a previous call to `AllocateAlignedBytes`.
// Calls `free_ptr` with the passed `opaque_ptr` pointer to free the memory; if
// `free_ptr` function is null, uses the default free().
HWY_DLLEXPORT void FreeAlignedBytes(const void* aligned_pointer,
FreePtr free_ptr, void* opaque_ptr);

// Class that deletes the aligned pointer passed to operator() calling the
// destructor before freeing the pointer. This is equivalent to the
// std::default_delete but for aligned objects. For a similar deleter equivalent
// to free() for aligned memory see AlignedFreer().
class AlignedDeleter {
 public:
  AlignedDeleter() : free_(nullptr), opaque_ptr_(nullptr) {}
  AlignedDeleter(FreePtr free_ptr, void* opaque_ptr)
  : free_(free_ptr), opaque_ptr_(opaque_ptr) {}

  template 
  void operator()(T* aligned_pointer) const {
return DeleteAlignedArray(aligned_pointer, free_, opaque_ptr_,
  TypedArrayDeleter);
  }

 private:
  template 
  static void TypedArrayDeleter(void* ptr, size_t size_in_bytes) {
size_t elems = size_in_bytes / sizeof(T);
for (size_t i = 0; i < elems; i++) {
  // Explicitly call the destructor on each element.
  (static_cast(ptr) + i)->~T();
}
  }

  // Function prototype that calls the destructor for each element in a typed
  // array. TypeArrayDeleter would match this prototype.
  using ArrayDeleter = void (*)(void* t_ptr, size_t t_size);

  HWY_DLLEXPORT static void DeleteAlignedArray(void* aligned_pointer,
   FreePtr free_ptr,
   void* opaque_ptr,
   ArrayDeleter deleter);

  FreePtr free_;
  void* opaque_ptr_;
};

// Unique pointer to T with custom aligned deleter. This can be a single
// element U or an array of element if T is a U[]. The custom aligned deleter
// will call the destructor on U or each element of a U[] in the array case.
template 
using AlignedUniquePtr = std::unique_ptr;

// Aligned memory equivalent of make_unique using the custom allocators
// alloc/free with the passed `opaque` pointer. This function calls the
// constructor with the passed Args... and calls the destructor of the object
// when the AlignedUniquePtr is destroyed.
template 
AlignedUniquePtr MakeUniqueAlignedWithAlloc(AllocPtr alloc, FreePtr free,
   void* opaque, Args&&... args) {
  T* ptr = static_cast(AllocateAlignedBytes(sizeof(T), alloc, opaque));
  return AlignedUniquePtr(new (ptr) T(std::forward(args)...),
 AlignedDeleter(free, opaque));
}

// Similar to MakeUniqueAlignedWithAlloc but using the default alloc/free
// functions.
template 
AlignedUniquePtr MakeUniqueAligned(Args&&... args) {
  T* ptr = static_cast(AllocateAlignedBytes(
  sizeof(T), /*alloc_ptr=*/nullptr, /*opaque_ptr=*/nullptr));
  return AlignedUniquePtr(new (ptr) T(std::forward(args)...),
  

Bug#1052151: flashbench: No debian directory in Vcs

[Bastian Germann]

Source: flashbench
Version: 62-1

The referenced Vcs does not point to a repo that holds the debianization.
Please Drop the Vcs fields.

Bug#1052155: [l10n:cs] Updated Czech translation of PO debconf template for mrtg

[Michal Šimůnek]

Package: mrtg
Version: 2.17.10-10
Severity: wishlist
Tags: l10n, patch

In attachment there is updated Czech translation of PO debconf
template (cs.po) for package mrtg, please include it.
# Czech PO debconf template translation of mrtg.
# Copyright (C) 2021 Michal Simunek 
# This file is distributed under the same license as the mrtg package.
# Michal Simunek , 2021 - 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: mrtg 2.17.10-10\n"
"Report-Msgid-Bugs-To: m...@packages.debian.org\n"
"POT-Creation-Date: 2023-09-07 20:43-0300\n"
"PO-Revision-Date: 2023-09-18 20:15+0200\n"
"Last-Translator: Michal Simunek \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../mrtg.templates:1001
msgid "/etc/mrtg.cfg should be moved to /etc/mrtg/mrtg.cfg"
msgstr "/etc/mrtg.cfg by se měl přesunout do /etc/mrtg/mrtg.cfg"

#. Type: note
#. Description
#: ../mrtg.templates:1001
msgid ""
"Older versions of MRTG on Debian had the configuration file /etc/mrtg.cfg. "
"The new version reads from /etc/mrtg/mrtg.cfg instead, so MRTG will not work "
"correctly until you move your configuration across manually."
msgstr ""
"Starší verze MRTG mají v Debianu konfigurační soubor /etc/mrtg.cfg."
"Nová verze na místo něj používá /etc/mrtg/mrtg.cfg, takže MRTG nebude "
"správně fungovat, dokud své nastavení ručně nepřesunete."

#. Type: boolean
#. Description
#: ../mrtg.templates:2001
msgid "Fix owner, group and permissions for /var/www/html/mrtg?"
msgstr "Opravit vlastníka, skupinu a oprávnění pro /var/www/html/mrtg?"

#. Type: boolean
#. Description
#: ../mrtg.templates:2001
msgid ""
"By default MRTG writes all graphs in the directory /var/www/html/mrtg/. This "
"directory currently exists, but it is insecure. The directory should be "
"owned by the user 'mrtg' and group 'www-data', with recommended permissions "
"of 0750."
msgstr ""
"Ve výchozím nastavení ukládá MRTG veškerou grafiku do adresáře /var/www/html/"
"mrtg/. Tento adresář nyní existuje, ale není zabezpečený. Je třeba, aby jej "
"vlastnil uživatel 'mrtg' a skupina 'www-data'. Doporučené oprávnění je 0750."

#. Type: boolean
#. Description
#: ../mrtg.templates:3001
msgid "Create /var/www/html/mrtg?"
msgstr "Vytvořit /var/www/html/mrtg?"

#. Type: boolean
#. Description
#: ../mrtg.templates:3001
msgid ""
"By default MRTG writes all graphs in the directory /var/www/html/mrtg/. "
"However, this directory doesn't currently exist. The directory should be "
"owned by the user 'mrtg' and group 'www-data', with recommended permissions "
"of 0750."
msgstr ""
"Ve výchozím nastavení ukládá MRTG veškerou grafiku do adresáře /var/www/html/"
"mrtg/. Tento adresář však nyní neexistuje. Je také třeba, aby jej vlastnil "
"uživatel 'mrtg' a skupina 'www-data'. Doporučené oprávnění je 0750."

#. Type: boolean
#. Description
#: ../mrtg.templates:3001
msgid ""
"Alternatively, you can use another path for generated graphs. Note that "
"keeping this directory empty when using another path is not a problem."
msgstr ""
"Případně můžete pro generovanou grafiku použít jinou cestu. Pamatujte, že "
"při použití jiné cesty není problém ponechat tento adresář prázdný."

#. Type: boolean
#. Description
#: ../mrtg.templates:4001
msgid "Remove old and conflicting file /etc/cron.d/mrtg?"
msgstr "Odstranit starý a konfliktní soubor /etc/cron.d/mrtg?"

#. Type: boolean
#. Description
#: ../mrtg.templates:4001
msgid ""
"MRTG no longer needs to use cron because it is started via systemd (or init."
"d scripts)."
msgstr ""
"MRTG již nepotřebuje používat cron, protože se spouští přes systemd "
"(nebo skripty init.d)."

#. Type: boolean
#. Description
#: ../mrtg.templates:4001
msgid ""
"A file /etc/cron.d/mrtg exists, left behind by an old version of MRTG. If "
"kept, this file will cause duplicate work because MRTG now runs as a daemon. "
"It is therefore strongly recommended to remove the cron file."
msgstr ""
"Po staré verzi MRTG zůstal soubor /etc/cron.d/mrtg. Ponecháte-li "
"jej, způsobí tento soubor duplicitní úlohu, protože MRTG nyní běží "
"jako daemon. Proto se důrazně doporučuje odstranit cron soubor."

#. Type: boolean
#. Description
#: ../mrtg.templates:4001
msgid ""
"If this cron job is needed, consider renaming the file (e.g. from /etc/cron."
"d/mrtg to /etc/cron.d/mrtg-custom) to avoid future warnings."
msgstr ""
"Pokud je tato úloha cronu potřeba, zvažte pro předejití budoucím "
"výstrahám přejmenování souboru (např. z /etc/cron.d/mrtg na "
"/etc/cron.d/mrtg-custom)."

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Alexandre Detiste]

Le dim. 17 sept. 2023 à 21:26, Russ Allbery  a écrit :
> Based on previous discussion with Guillem, I think the direction Guillem
> is headed is something like adding a new member (or field in another
> member) to the deb format that holds a list of volatile files that the
> package considers itself responsible for.  I think I agree with Guillem's
> position (at least as I understand it) that it doesn't make sense for dpkg
> to parse other files to populate that list.  That can very easily be
> handled outside of dpkg.

Yes, it's better to keep dpkg clean & generic and
handle the fast moving parts elsewhere.
(like not tainting dpkg forever with the oneshot UsrMerge final migration)

I understand why redhat would bolt tmpfiles directly into rpm,
but it's a more integrated ecosystem.

> So the idea would be that the package would install tmpfiles.d files,
> service units, and similar files as normal, and then debhelper would parse
> those files, extract the list of paths that they manage, and use that to
> write a control file or the like that dpkg consumes to register those
> files.

Yes.

And debputy too, which is a rewrite of debhelper, but in Python,
with different assumptions (everything in one machine-editable
yaml instead of so many tiny files in debian/ )

> those files.
and not only files but glob patterns: /var/cache/[package]/**


> If I'm correct about that design, an intermediate step in that direction
> from where cruft is today would be to add that logic to debhelper and then
> have debhelper ship that database in the package in
> /usr/share/cruft/ or some similar directory, and then cruft could
> just consume that database of registered paths to get attribution
> information until such time as that can move into dpkg.

Yes, that's what dh_cruft does. I use it extensively for my proprietary
Debian-derivative, but did not try to push it down Debian packagers
(because it's in Perl and I cannot really maintain it,
so the tmpfiles.d parsing is not there yet).

Having today machine readable data (instead of "if $1 == purge... rm -rf ...")
make it easier to later turn it into another packaging format.

> This design is just off the top of my head, and I'm probably missing some
> problems and some details.

You've got a good grasp of the important parts.

So this tool can be used to recover trashed system
- I receive 10 years old filesystem images that
have seen much "sudo make install" abuse -
but also be used to make the distribution better as a whole.

So I file bugs regularly against random _other_ packages
for the dynamic things piuparts won't notice by design;
because it doesn't run the tools in packages it tests.
(most of the times it's a missing "rm .." in postrm);


Maybe having cruft run in last step of all autopkgtests
would ensure all dynamic files are registered.
 (maybe only on Salsa first)

The first step would be that autopkgtest itself provides
this authoritative list of allowed file names.

(see from :  unexplained: /  )
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cruft-ng/37993513/log.gz

Greetings

---

I uploaded a new "cruft-ng" with a new "cruft --package PACKAGE" option
that dumps this one package volatile files ruleset to ease import in
another tool.

And "cruft FILE" now works closer to  [ "dpkg -S" + volatile files ].

Bug#910377: System-critical package management

[Julian Andres Klode]

On Mon, Sep 18, 2023 at 12:24:20PM +0200, Guillem Jover wrote:
> While dpkg on systems using systemd _could_ by default take an
> system inhibitor lock, and could provide a good enough reason like say
> "Packaging system upgrade" or whatever, my concern has been with the
> added dependency chain, and after reading your mail and thinking about
> this now, I have to agree this seems like a higher level policy.
> (Of course dpkg could also do that and grow a new --no-inhibit,
> or --refuse-inhibit or similar option, but still.)
> 
> But then, I recalled I had a git branch adding a dpkg-db-lock command
> with a --wait-lock option, that I could recover and polish to provide
> an example pre-hook script that would call that via a background
> systemd-inhibit if systemd is running and the command is available,
> where an admin that wanted to do that for their system or fleet of
> systems could hook into the dpkg config. I've done that locally, and
> will check whether that's viable and probably merge it for 1.22.1
> or 1.22.2, so that people that want to do it can easily do so.

I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1052158: RM: youtube-dl -- RoQA; dead upstream; transitional package

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:youtube-dl

youtube-dl is dead upstream and a transitional package to yt-dlp now. Please 
remove it.
See also #1036272.

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Trent W. Buck]

On Fri 07 Apr 2017 12:02:46 +0200, intrigeri wrote:
> /lib/systemd/system/initramfs-shutdown.service:
> ⋯
> /usr/share/initramfs-tools/initramfs-restore:
> ⋯
> /usr/bin/unmkinitramfs /initrd.img "$WORKDIR"
> ⋯
> /lib/systemd/system-shutdown/initramfs-tools:
> ⋯
> /usr/share/initramfs-tools/hooks/shutdown:
> ⋯
> copy_exec /lib/systemd/systemd-shutdown /shutdown
> touch $DESTDIR/etc/initrd-release

I am interested in this ticket for two use cases:

a. netbooting Debian Live on diskless hosts.
b. "zpool export -a" on servers.

I am only considering case (a), below.

I tried intrigeri's approach for Debian Live but I ran into a couple of 
problems:

1. it assumes /initrd.img inside the rootfs exists and
   is consistent with the already-running system.
   This is not the case for me (I remove it to save space), and
   also not necessarily the case during upgrades.

2. it tries to unpack /initrd.img after systemd-networkd stops.
   Without KeepConfiguration= (which is a pain to guarantee),
   that means no network access, which means no access to remote rootfs.

I instead tried just keeping the boot initrd around.
Using a simple bind-mount didn't work (I don't understand why) – SOME files are 
missing after switch_root.
Doing a full cp -a did work, though.

This method seems to work for my very simple test case of 
failed-to-unmount-rootfs error going away.
I'm really not happy with it overall, though.
I've run out of "time budget" to work on this in the short term.


https://github.com/cyberitsolutions/bootstrap2020/tree/twb/doc/workaround-778849

PS: I looked at dracut, but it's simply unsupported for live-boot (Debian Live 
/ Tails), and
for servers, I found it unreliable (much worse than initramfs-tools).
(e.g. if bash has a security update, dracut doesn't trigger and the 
embedded copy of bash in the initrd remains vulnerable.)
(e.g. telling dracut to use only busybox/klibc and not bash breaks, because 
lots of dracut components need bash but don't declare a dependency on it.)
(e.g. dracut is written in bash and regularly has errors but doesn't exit 
non-zero, so you do not notice until the server doesn't actually boot anymore.)


usr_share_initramfs-tools_hooks_PrisonPC-install-systemd-shutdown
Description: Bourne shell script


shs11IyvBEnz.sh
Description: Bourne shell script

Bug#1037909: yubioath-desktop: ftbfs with GCC-13

[Bastian Germann]

I am sponsiring a NMU to fix this.
The debdiff is attached.diff -Nru yubioath-desktop-5.1.0/debian/changelog 
yubioath-desktop-5.1.0/debian/changelog
--- yubioath-desktop-5.1.0/debian/changelog 2022-02-11 15:59:17.0 
+0100
+++ yubioath-desktop-5.1.0/debian/changelog 2023-09-17 16:29:46.0 
+0200
@@ -1,3 +1,11 @@
+yubioath-desktop (5.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 02-fix-gcc-13 patch to fix gcc-13 build issue, thanks
+Jonathan Bergh  also. (Closes: #1037909)
+
+ -- Bo YU   Sun, 17 Sep 2023 22:29:46 +0800
+
 yubioath-desktop (5.1.0-1) unstable; urgency=medium
 
   * new upstream version 5.1.0
diff -Nru yubioath-desktop-5.1.0/debian/patches/02-fix-gcc-13.patch 
yubioath-desktop-5.1.0/debian/patches/02-fix-gcc-13.patch
--- yubioath-desktop-5.1.0/debian/patches/02-fix-gcc-13.patch   1970-01-01 
01:00:00.0 +0100
+++ yubioath-desktop-5.1.0/debian/patches/02-fix-gcc-13.patch   2023-09-17 
16:29:27.0 +0200
@@ -0,0 +1,18 @@
+Description: fix gcc-13 build issue 
+ Due to the upstream has beed renamed(6.0.0) and it seems the code has been 
+ refactored, so do not forward it.
+Author: Bo YU  
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037909
+Last-Update: 2023-07-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/QZXing/zxing/zxing/common/Types.h
 b/QZXing/zxing/zxing/common/Types.h
+@@ -2,6 +2,7 @@
+ #ifndef ZXING_TYPES_H
+ #define ZXING_TYPES_H
+ 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru yubioath-desktop-5.1.0/debian/patches/series 
yubioath-desktop-5.1.0/debian/patches/series
--- yubioath-desktop-5.1.0/debian/patches/series2022-02-11 
15:59:38.0 +0100
+++ yubioath-desktop-5.1.0/debian/patches/series2023-09-17 
16:16:17.0 +0200
@@ -1 +1,2 @@
 01-fix_target_path
+02-fix-gcc-13.patch

Bug#1052153: linux-headers-6.1.0-10-amd64linux-headers-6.1.0-10-amd64: Building module for rtl8821ce not possible

[TB]

Package: linux-headers-6.1.0-10-amd64linux-headers-6.1.0-10-amd64
Version: 6.1.0-10
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: t...@b.de

Dear Maintainer,

while installing of linux-headers-6.1.0-10-amd64 I got the following messages:

##
inux-headers-6.1.0-10-amd64 (6.1.38-2) wird eingerichtet ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-10-amd64.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
'make' -j4 KVER=6.1.0-10-amd64..(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-10-amd64 (x86_64)
Consult /var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build/make.log for more 
information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-10-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-10-amd64.postinst line 11.
dpkg: Fehler beim Bearbeiten des Paketes linux-headers-6.1.0-10-amd64 
(--configure):
 »installiertes post-installation-Skript des Paketes 
linux-headers-6.1.0-10-amd64«-Unterprozess gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 linux-headers-6.1.0-10-amd64
#

In the /var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build/make.log the 
intresting lines:


  CC [M]  /var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build/core/rtw_sreset.o
/var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build/core/rtw_br_ext.c:20:18: 
fatal error: net/ipx.h: Datei oder Verzeichnis nicht gefunden
   20 | #include 
  |  ^~~
compilation terminated.
make[2]: *** 
[/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.build:255: 
/var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build/core/rtw_br_ext.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:2037: 
/var/lib/dkms/rtl8821ce/v5.5.2_34066.20200325/build] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.1.0-10-amd64“ wird verlassen
make: *** [Makefile:2244: modules] Fehler 2
###


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

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

Bug#1043523: RM: bitmeter -- RoQA; unmaintained; depends on gtk2

[Bastian Germann]

Control: retitle -1 RM: bitmeter -- ROM (team); low popcon; depends on gtk2
Control: reassign -1 ftp.debian.org
Control: severity -1 normal

Please remove bitmeter. The Multimedia Team has not cared about
this low-popcon package for a long time. It depends on gtk2.

Bug#1024216: NMU yt-dlp

[Bastian Germann]

I am uploading a NMU to fix this.
The debdiff is attached and also available in git.diff -Nru mkchromecast-0.3.9~git20200902+db2964a/debian/changelog 
mkchromecast-0.3.9~git20200902+db2964a/debian/changelog
--- mkchromecast-0.3.9~git20200902+db2964a/debian/changelog 2020-10-16 
08:47:59.0 +0200
+++ mkchromecast-0.3.9~git20200902+db2964a/debian/changelog 2023-09-18 
12:18:36.0 +0200
@@ -1,3 +1,10 @@
+mkchromecast (0.3.9~git20200902+db2964a-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace youtube-dl with yt-dlp (Closes: #1024216).
+
+ -- Bastian Germann   Mon, 18 Sep 2023 10:18:36 +
+
 mkchromecast (0.3.9~git20200902+db2964a-2) unstable; urgency=medium
 
   * Also drop .gitignore files not present in the tarball.
diff -Nru mkchromecast-0.3.9~git20200902+db2964a/debian/control 
mkchromecast-0.3.9~git20200902+db2964a/debian/control
--- mkchromecast-0.3.9~git20200902+db2964a/debian/control   2020-10-16 
08:47:59.0 +0200
+++ mkchromecast-0.3.9~git20200902+db2964a/debian/control   2023-09-18 
12:05:32.0 +0200
@@ -37,7 +37,7 @@
  python3-requests,
  sox (>=14.4.1),
  vorbis-tools (>=1.4.0),
- youtube-dl,
+ yt-dlp,
  ${misc:Depends},
  ${python3:Depends}
 Suggests: ffmpeg
diff -Nru mkchromecast-0.3.9~git20200902+db2964a/debian/patches/series 
mkchromecast-0.3.9~git20200902+db2964a/debian/patches/series
--- mkchromecast-0.3.9~git20200902+db2964a/debian/patches/series
1970-01-01 01:00:00.0 +0100
+++ mkchromecast-0.3.9~git20200902+db2964a/debian/patches/series
2023-09-18 12:15:48.0 +0200
@@ -0,0 +1 @@
+yt-dlp.patch
diff -Nru mkchromecast-0.3.9~git20200902+db2964a/debian/patches/yt-dlp.patch 
mkchromecast-0.3.9~git20200902+db2964a/debian/patches/yt-dlp.patch
--- mkchromecast-0.3.9~git20200902+db2964a/debian/patches/yt-dlp.patch  
1970-01-01 01:00:00.0 +0100
+++ mkchromecast-0.3.9~git20200902+db2964a/debian/patches/yt-dlp.patch  
2023-09-18 12:16:41.0 +0200
@@ -0,0 +1,36 @@
+Description: Replace youtube-dl with yt-dlp
+Author: Bastian Germann 
+---
+--- mkchromecast-0.3.9~git20200902+db2964a.orig/mkchromecast/__init__.py
 mkchromecast-0.3.9~git20200902+db2964a/mkchromecast/__init__.py
+@@ -786,7 +786,7 @@ if args.loop is True and args.video is T
+ Command
+ """
+ if args.command is not None and args.video is True:
+-safe_commands = ["ffmpeg", "avconv", "youtube-dl"]
++safe_commands = ["ffmpeg", "avconv", "yt-dlp"]
+ command = shlex.split(args.command)
+ if command[0] not in safe_commands:
+ print(colors.error("Refusing to execute this."))
+--- mkchromecast-0.3.9~git20200902+db2964a.orig/mkchromecast/audio.py
 mkchromecast-0.3.9~git20200902+db2964a/mkchromecast/audio.py
+@@ -84,7 +84,7 @@ if youtube_url is not None:
+ query = urllib.parse.parse_qs(url_data.query)
+ video = query["v"][0]
+ print(colors.options("Playing video:") + " " + video)
+-command = ["youtube-dl", "-o", "-", youtube_url]
++command = ["yt-dlp", "-o", "-", youtube_url]
+ mtype = "audio/mp4"
+ else:
+ if os.path.exists(configf) and tray is True:
+--- mkchromecast-0.3.9~git20200902+db2964a.orig/mkchromecast/video.py
 mkchromecast-0.3.9~git20200902+db2964a/mkchromecast/video.py
+@@ -73,7 +73,7 @@ I think that the command below is sendin
+ browser closes the connection.
+ """
+ if youtube_url is not None:
+-command = ["youtube-dl", "-o", "-", youtube_url]
++command = ["yt-dlp", "-o", "-", youtube_url]
+ 
+ elif screencast is True:
+ if res is None:

Bug#1052125: nala cannot install the debreate package

[Nikolay Sabelnikov]

hello. thank you for responding quickly. Then with your permission, I will 
create a bug in their Git with a reference to this bug.

18 сентября 2023 г. 05:31:47 GMT+03:00, Blake Lee  
пишет:
>I was able to reproduce this on my system. First this is the error that 
>happens when installing. This is what crashes Nala because of the formatter.
>
>```
>Traceback (most recent call last): 
> File "/usr/bin/debreate", line 230, in  
>   main() 
> File "/usr/bin/debreate", line 27, in main 
>   import globals.paths 
> File "/usr/share/debreate/globals/paths.py", line 16, in  
>   import libdbr.paths 
> File "/usr/share/debreate/lib/libdbr/paths.py", line 18, in  
>   from . import sysinfo 
> File "/usr/share/debreate/lib/libdbr/sysinfo.py", line 37, in  
>   if not __os_name: 
>  ^ 
>NameError: name '__os_name' is not defined
>```
>
>This portion happens with apt as well, although apt doesn't crash. If you use 
>--raw-dpkg switch with Nala it will complete. I have already fixed this crash 
>upstream but haven't released yet.
>
>I would say you should likely report this to the debreate devs, even getting 
>the install to complete with apt, the same error is thrown when I try to run 
>the program.

Bug#1037602: ceph: ftbfs with GCC-13

[Bo YU]

Source: ceph
Followup-For: Bug #1037602
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

I found these commits that was trying to fix the issue but it looks like
they not done yet. I can confrim the attached patch can fix the issue.
https://salsa.debian.org/ceph-team/ceph/-/commit/9104dcb08ce6e86f4b2f33286938c6a90f659471
https://salsa.debian.org/ceph-team/ceph/-/commit/9cc4c414c1729b6a5b101c46cdfea4ab32f179f3

Or upgrade to 18.1.2 as you have done on salsa, but this maybe cost more
time to finish.

The reason I am ccing riscv mail list is that the ceph package is a very
key package and now it was a blocker for riscv64 official rebootstrap
from my view.
https://buildd.debian.org/status/package.php?p=ceph

So could you apply it or upgrade to new version at your next upload?

-- 
Regards,
--
  Bo YU

diff -Nru ceph-16.2.11+ds/debian/changelog ceph-16.2.11+ds/debian/changelog
--- ceph-16.2.11+ds/debian/changelog2023-02-16 18:54:41.0 +0800
+++ ceph-16.2.11+ds/debian/changelog2023-09-18 15:34:20.0 +0800
@@ -1,3 +1,10 @@
+ceph (16.2.11+ds-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix gcc-13 build issue. (Closes: #1037602)
+
+ -- Bo YU   Mon, 18 Sep 2023 15:34:20 +0800
+
 ceph (16.2.11+ds-2) unstable; urgency=medium
 
   * Add missing python3-distutils runtime depends in ceph-common.
diff -Nru ceph-16.2.11+ds/debian/patches/fix-gcc-13-issue.patch 
ceph-16.2.11+ds/debian/patches/fix-gcc-13-issue.patch
--- ceph-16.2.11+ds/debian/patches/fix-gcc-13-issue.patch   1970-01-01 
07:30:00.0 +0730
+++ ceph-16.2.11+ds/debian/patches/fix-gcc-13-issue.patch   2023-09-18 
15:34:15.0 +0800
@@ -0,0 +1,59 @@
+--- a/src/common/subsys_types.h
 b/src/common/subsys_types.h
+@@ -17,6 +17,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ enum ceph_subsys_id_t {
+   ceph_subsys_,   // default
+--- a/src/rocksdb/db/compaction/compaction_iterator.h
 b/src/rocksdb/db/compaction/compaction_iterator.h
+@@ -9,6 +9,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "db/compaction/compaction.h"
+ #include "db/compaction/compaction_iteration_stats.h"
+--- a/src/common/Cycles.h
 b/src/common/Cycles.h
+@@ -32,6 +32,8 @@
+ #ifndef CEPH_CYCLES_H
+ #define CEPH_CYCLES_H
+ 
++#include 
++
+ /**
+  * This class provides static methods that read the fine-grain CPU
+  * cycle counter and translate between cycle-level times and absolute
+--- a/src/rocksdb/include/rocksdb/rocksdb_namespace.h
 b/src/rocksdb/include/rocksdb/rocksdb_namespace.h
+@@ -8,3 +8,5 @@
+ #ifndef ROCKSDB_NAMESPACE
+ #define ROCKSDB_NAMESPACE rocksdb
+ #endif
++
++#include 
+--- 
a/src/rocksdb/third-party/folly/folly/synchronization/detail/ProxyLockable-inl.h
 
b/src/rocksdb/third-party/folly/folly/synchronization/detail/ProxyLockable-inl.h
+@@ -14,6 +14,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ namespace folly {
+ namespace detail {
+--- a/src/librbd/api/PoolMetadata.h
 b/src/librbd/api/PoolMetadata.h
+@@ -9,6 +9,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ namespace librbd {
+ 
diff -Nru ceph-16.2.11+ds/debian/patches/series 
ceph-16.2.11+ds/debian/patches/series
--- ceph-16.2.11+ds/debian/patches/series   2023-02-16 18:54:41.0 
+0800
+++ ceph-16.2.11+ds/debian/patches/series   2023-09-17 23:50:59.0 
+0800
@@ -23,3 +23,4 @@
 
CVE-2022-3650_1_ceph-crash_drop_privleges_to_run_as_ceph_user_rather_than_root.patch
 CVE-2022-3650_2_ceph-crash_fix_stderr_handling.patch
 CVE-2022-3854_1_rgw_Guard_against_malformed_bucket_URLs.patch
+fix-gcc-13-issue.patch
diff -Nru ceph-16.2.11+ds/debian/rules ceph-16.2.11+ds/debian/rules
--- ceph-16.2.11+ds/debian/rules2023-02-16 18:54:41.0 +0800
+++ ceph-16.2.11+ds/debian/rules2023-09-18 11:46:12.0 +0800
@@ -46,7 +46,7 @@
 endif
 
 # Fix build with fmt 9
-export DEB_CXXFLAGS_MAINT_APPEND += -DFMT_DEPRECATED_OSTREAM
+export DEB_CXXFLAGS_MAINT_APPEND += -DFMT_DEPRECATED_OSTREAM -fpermissive
 
 # Enable hardening
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
diff -Nru ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog 
ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog
--- ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog 2023-02-16 
18:54:41.0 +0800
+++ ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog 2023-09-18 
15:34:20.0 +0800
@@ -1,3 +1,10 @@
+ceph (16.2.11+ds-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix gcc-13 build issue. (Closes: #1037602)
+
+ -- Bo YU   Mon, 18 Sep 2023 15:34:20 +0800
+
 ceph (16.2.11+ds-2) unstable; urgency=medium
 
   * Add missing python3-distutils runtime depends in ceph-common.
diff -Nru 
ceph-16.2.11+ds/src/test/debian-jessie/debian/patches/fix-gcc-13-issue.patch 
ceph-16.2.11+ds/src/test/debian-jessie/debian/patches/fix-gcc-13-issue.patch
--- 

Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs

[Reinhard Tartler]

Hi Gregor,

On Wed, Sep 13, 2023 at 3:03 AM Gregor Riepl  wrote:

> As mentioned in the upstream bug report[1], the fix is actually in
> containers/storage 1.48, included with podman 4.6 and not 4.5.
>
> So, the bug can (hopefully) be fixed for good when this version is
> packaged.
>

I've now worked on packaging 4.6.2, and it is currently available
in debian/experimental. Can you do me a favor? Please test it and let me
know whether
it fixes this issue.



> It might also be helpful to include a what's new message, to make users
> aware they need to reset their storage after upgrading. There doesn't
> seem to be an easy way to convert vfs containers or images to overlay.
>
> [1]
> https://github.com/containers/podman/issues/19811#issuecomment-1716344802
>
> I'm happy to add a note in NEWS.Debian, which is going to be presented
on package upgrades. Can you please provide a wording for that text that you
would have been useful to you?

Thank you


-- 
regards,
Reinhard

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco Paolo Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libmozilla-ca-perl
  Version : 20230821-1
  Upstream Contact: Gisle Aas 
* URL : https://github.com/libwww-perl/Mozilla-CA
* License : MPL-2.0
  Programming Lang: Perl
  Description : Mozilla's CA cert bundle in PEM format

  Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority
  certificates in a form that can be consumed by modules and libraries
  based on OpenSSL.
  The module provide a single function:
  SSL_ca_file()
  Returns the absolute path to the Mozilla's CA cert bundle PEM file.

Bug#1042090: podman: fails to start container with userns mapping

[Reinhard Tartler]

Control: tag -1 +upstream +moreinfo

Hi Hristo,

Thanks for taking the time to report this issue. In the meantime, podman
4.5 is now in debian/testing (and 4.6.2 in debian/experimental). Can you
please upgrade your package and give it another try? If you're right, you
shouldn't see this issue anymore. Please report back so that I can mark
this as fixed in the Debian bug tracker.

Best,
-rt

On Wed, Jul 26, 2023 at 10:51 AM Hristo Venev  wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b1
> Severity: normal
> X-Debbugs-Cc: hri...@venev.name
>
> Dear Maintainer,
>
> When trying to run a container using podman (as root) with a uid/gid
> mapping specified via `--userns`, it fails to start:
>
> > # podman run --rm --userns
> auto:uidmapping=1000:1001:1,gidmapping=1000:1001:1 debian:12
> > ERRO[] Unmounting
> /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged: invalid argument
> > Error: mounting storage for container INSERT_ANOTHER_ID_HERE: creating
> overlay mount to /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged,
> mount_data="lowerdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/diff1:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_ANOTHER_SHORT_ID_HERE,upperdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/diff,workdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/work,,volatile":
> permission denied
>
> The following appears in the kernel log:
> > [TIME] overlayfs: failed to resolve
> '/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE':
> -13
>
> The outcome is listed above. The expected outcome was that the container
> would start, with most IDs mapped from those delegated to the
> `containers` user, except uid/gid 1000 inside the container which
> correspond to 1001 outside.
>
> Running the container with just `--userns auto` works. However, then all
> files passed to the container via bind mounts would be owned by
> nobody:nogroup instead of 1000:1000.
>
> This seems similar to https://github.com/containers/podman/issues/18435,
> which was probably fixed in podman 4.5.0.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.3.0-1-amd64 (SMP w/24 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 podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  crun 1.8.5-1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.37-6
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
>
> Versions of packages podman recommends:
> pn  buildah   
> pn  catatonit | tini | dumb-init  
> pn  dbus-user-session 
> pn  fuse-overlayfs
> pn  slirp4netns   
> pn  uidmap
>
> Versions of packages podman suggests:
> pn  containers-storage  
> pn  docker-compose  
> ii  iptables1.8.9-2
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#1036256: golang-github-pin-tftp: FTBFS in testing

[Thiago Andrade]

Hi Arnaud Rebillout

I'm waiting for this upgrade. After I'll try to upgrade gobuster to 
3.6.0 version.


Regards.
Thanks a lot!

On 18/09/2023 05:19, Arnaud Rebillout wrote:
I tried to rebuild the package locally, works for me. Tried to run 
autopkgtests in GitLab CI: worked [1]. It hints at flaky tests indeed...


I noticed that in Debian we package 2.2.0, however upstream is at 
version 3.0.0, with significant changes.


We have only two reverse build-deps: gobuster and ignition.

1) gobuster already uses pin-tftp 3.0

2) ignition seems to use an older version of pin-tftp, but I could 
rebuild it with pin-tftp 3.0 successfully


So I'm going to upload version 3.0 of pin-tftp, and I'll check if 
builds and autopkgtests succeed with this new version.


--

[1]: https://gitlab.com/arnaudr/golang-github-pin-tftp/-/jobs/5108371487


--
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄

Bug#1052155: [l10n:cs] Updated Czech translation of PO debconf template for mrtg

[Eriberto]

Thanks Michal!

Already sent to Salsa.

Regards,

Eriberto

Em seg., 18 de set. de 2023 às 06:33, Michal Šimůnek
 escreveu:
>
> Package: mrtg
> Version: 2.17.10-10
> Severity: wishlist
> Tags: l10n, patch
>
> In attachment there is updated Czech translation of PO debconf
> template (cs.po) for package mrtg, please include it.

Bug#1052061: mrtg: [INTL:nl] Dutch translation of debconf templates

[Eriberto]

Thanks Frans!

Already sent to Salsa.

Regards,

Eriberto

Em sáb., 16 de set. de 2023 às 16:03, Frans Spiesschaert
 escreveu:
>
>
>
> Package: mrtg
> Severity: wishlist
> Tags: l10n patch
>
>
>
> Dear Maintainer,
>
>
> Please find attached the updated Dutch translation of mrtg debconf
> messages. A draft has been posted to the debian-l10n-dutch mailing list
> allowing for review.
> Please add it to your next package revision.
> It should be put as debian/po/nl.po in your package build tree.
>
>
> --
> Kind regards,
> Frans Spiesschaert
>

Bug#1052172: gnome-terminal: crash during scroll-up

[Patrice Duroux]

Package: gnome-terminal
Version: 3.49.99-1
Severity: normal

Dear Maintainer,


I am not sure that this should be addressed to gnome-terminal or vte or glib.

Here is the crash report:

#coredumpctl info 16058
   PID: 16058 (gnome-terminal-)
   UID: 1001 (patrice)
   GID: 1001 (patrice)
Signal: 11 (SEGV)
 Timestamp: Mon 2023-09-18 19:24:10 CEST (24s ago)
  Command Line: /usr/libexec/gnome-terminal-server
Executable: /usr/libexec/gnome-terminal-server
 Control Group: /user.slice/user-1001.slice/user@1001.service/app.slice/app-
org.gnome.Terminal.slice/gnome-terminal-server.service
  Unit: user@1001.service
 User Unit: gnome-terminal-server.service
 Slice: user-1001.slice
 Owner UID: 1001 (patrice)
   Boot ID: 1781d746c50b49e981e5f202919486f2
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: 
   Storage: /var/lib/systemd/coredump/core.gnome-
terminal-.1001.1781d746c50b49e981e5f202919486f2.16058.169505785000.zst
(present)
  Size on Disk: 2.2M
   Message: Process 16058 (gnome-terminal-) of user 1001 dumped core.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-254.3-1.amd64
Stack trace of thread 16058:
#0  0x7f71764f6b30 g_utf8_pointer_to_offset
(libglib-2.0.so.0 + 0x91b30)
#1  0x7f7175a014a6 emit_text_changed_insert
(libvte-2.91.so.0 + 0x6a4a6)
#2  0x7f71759cd607
_ZN3vte8terminal8Terminal18emit_text_scrolledEl (libvte-2.91.so.0 + 0x36607)
#3  0x7f71759f721d
_ZN3vte8platform6Widget25vadjustment_value_changedEv (libvte-2.91.so.0 +
0x6021d)
#4  0x7f71765c1540 g_closure_invoke (libgobject-2.0.so.0 +
0x16540)
#5  0x7f71765d4afc signal_emit_unlocked_R
(libgobject-2.0.so.0 + 0x29afc)
#6  0x7f71765d6501 signal_emit_valist_unlocked
(libgobject-2.0.so.0 + 0x2b501)
#7  0x7f71765dc186 g_signal_emit_valist
(libgobject-2.0.so.0 + 0x31186)
#8  0x7f71765dc243 g_signal_emit (libgobject-2.0.so.0 +
0x31243)
#9  0x7f7175cb4297 emit_value_changed (libgtk-3.so.0 +
0xb4297)
#10 0x7f7175e5e152 gtk_range_real_change_value
(libgtk-3.so.0 + 0x25e152)
#11 0x7f7175c915ce _gtk_marshal_BOOLEAN__ENUM_DOUBLE
(libgtk-3.so.0 + 0x915ce)
#12 0x7f71765c1540 g_closure_invoke (libgobject-2.0.so.0 +
0x16540)
#13 0x7f71765d5188 signal_emit_unlocked_R
(libgobject-2.0.so.0 + 0x2a188)
#14 0x7f71765d5d51 signal_emit_valist_unlocked
(libgobject-2.0.so.0 + 0x2ad51)
#15 0x7f71765dc186 g_signal_emit_valist
(libgobject-2.0.so.0 + 0x31186)
#16 0x7f71765dc243 g_signal_emit (libgobject-2.0.so.0 +
0x31243)
#17 0x7f7175e5c46c update_slider_position (libgtk-3.so.0 +
0x25c46c)
#18 0x7f7175e5f75c gtk_range_drag_gesture_update
(libgtk-3.so.0 + 0x25f75c)
#19 0x7f7175c94e20 _gtk_marshal_VOID__DOUBLE_DOUBLEv
(libgtk-3.so.0 + 0x94e20)
#20 0x7f71765c1749 _g_closure_invoke_va
(libgobject-2.0.so.0 + 0x16749)
#21 0x7f71765d65bf signal_emit_valist_unlocked
(libgobject-2.0.so.0 + 0x2b5bf)
#22 0x7f71765dc186 g_signal_emit_valist
(libgobject-2.0.so.0 + 0x31186)
#23 0x7f71765dc243 g_signal_emit (libgobject-2.0.so.0 +
0x31243)
#24 0x7f71765c4986 g_cclosure_marshal_VOID__BOXEDv
(libgobject-2.0.so.0 + 0x19986)
#25 0x7f71765c1749 _g_closure_invoke_va
(libgobject-2.0.so.0 + 0x16749)

Not easy to reproduce but I finally got it twice after some dbgsym installs.

Regards,
Patrice


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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-terminal-data   3.49.99-1
ii  gsettings-desktop-schemas 45~rc-1
ii  libatk1.0-0   2.49.91-2
ii  libc6 2.37-10
ii  libgcc-s1 13.2.0-4
ii  libglib2.0-0  2.78.0-2
ii  libgtk-3-03.24.38-5

Bug#1052171: libva-utils: trouble using the d/watch file

[Bastian Germann]

Control: tags -1 pending

Am 18.09.23 um 19:19 schrieb Patrice Duroux:

Why not downloading the source under tags?


It is already done but not yet released:
https://salsa.debian.org/multimedia-team/libva-utils/-/commit/9065cff5917eabda1b909899a13c5016fa56503a

Bug#690593:

[niTin Solanki]

My Google photo Lock folder is this open the photo and video

Bug#781561: angband: conffiles not removed

[Alexandre Detiste]

Hi Paul,

We are packaging a new release.

For some reason lintian-brush decided to remove
the whole d/maintscript

Can you have a look and say if it's fine.

https://salsa.debian.org/games-team/angband

That or this bug should had been closed ages ago.

Sorry I'm a bit confused on this one, I need a hand.

Alexandre

Bug#1052178: qtscxml FTCBFS: runs the built qscxmlc

[Helmut Grohne]

Source: qtscxml-everywhere-src
Version: 5.15.10-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qtscxml-everywhere-src fails to cross build from source, because it runs
the built qscxmlc during build. It turns out that the build system is
quite clever and actually looks for a native qscxmlc first and falls
back to the host one only in case the native one is not found. As such,
adding the missing dependency is sufficient here. I would like to thank
Lisandro for helping me discover the relevant source code. As usual, I'm
attaching a patch for your convenience.

Helmut
diff --minimal -Nru qtscxml-everywhere-src-5.15.10/debian/changelog 
qtscxml-everywhere-src-5.15.10/debian/changelog
--- qtscxml-everywhere-src-5.15.10/debian/changelog 2023-07-08 
18:17:12.0 +0200
+++ qtscxml-everywhere-src-5.15.10/debian/changelog 2023-09-18 
11:07:41.0 +0200
@@ -1,3 +1,10 @@
+qtscxml-everywhere-src (5.15.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add libqt5scxml5-bin to cross Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Sep 2023 11:07:41 +0200
+
 qtscxml-everywhere-src (5.15.10-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru qtscxml-everywhere-src-5.15.10/debian/control 
qtscxml-everywhere-src-5.15.10/debian/control
--- qtscxml-everywhere-src-5.15.10/debian/control   2023-07-08 
18:17:12.0 +0200
+++ qtscxml-everywhere-src-5.15.10/debian/control   2023-09-18 
11:07:36.0 +0200
@@ -6,6 +6,7 @@
Dmitry Shachnev ,
Lisandro Damián Nicanor Pérez Meyer 
 Build-Depends: debhelper-compat (= 13),
+   libqt5scxml5-bin ,
pkg-kde-tools,
qml-module-qttest (>= 5.15.10+dfsg~),
qtbase5-dev (>= 5.15.10+dfsg~),

Bug#1052170: ITP: node-playwright -- JavaScript framework for Web Testing and Automation

[Yadd]

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

* Package name: node-playwright
  Version : 1.38.0
  Upstream Contact: Microsoft Corporation
  
* URL : https://github.com/Microsoft/playwright
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : JavaScript framework for Web Testing and Automation

node-playwright is a framework for Web Testing and Automation. It allows
testing Chromium, Firefox and WebKit with a single API. Playwright is
built to enable cross-browser web automation that is ever-green, capable,
reliable and fast.

Another node-jupyterlab dependency, will be maintained under JS Team
umbrella.

Bug#1052170: ITP: node-playwright -- JavaScript framework for Web Testing and Automation

[Jérémy Lal]

Le lun. 18 sept. 2023 à 19:15, Yadd  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Yadd 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: node-playwright
>   Version : 1.38.0
>   Upstream Contact: Microsoft Corporation
>   
> * URL : https://github.com/Microsoft/playwright
> * License : Apache-2.0
>   Programming Lang: JavaScript
>   Description : JavaScript framework for Web Testing and Automation
>
> node-playwright is a framework for Web Testing and Automation. It allows
> testing Chromium, Firefox and WebKit with a single API. Playwright is
> built to enable cross-browser web automation that is ever-green, capable,
> reliable and fast.
>

Hi, I am a heavy user of node-playwright, so this interests me.
Note that latest version of playwright stopped downloading automatically
the needed browser, which is a good thing.
Playwright is also able to use system-installed chromium, but maybe not
firefox,
and I'm pretty sure it won't work out of the box with webkitgtk.

Cheers,
Jérémy

Bug#1052174: release.debian.org: transition: gumbo-parser

[Aymeric Agon-Rambosson]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: none, Aymeric Agon-Rambosson 


User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:gumbo-parser
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gumbo-parser.html


Hello,

I am looking for the transition from libgumbo1 to libgumbo2 due to 
an upstream SONAME bump in the new release.


The reverse dependencies are the following :

- gumbo-parser ok

- bibledit-cloud ok
- claws-mail ok
- httpdirfs-fuse ok
- kristall ok
- libhtml-gumbo-perl ok
- litehtml ok
- mupdf ok
- tdom ok
- zim-tools ok

- pymupdf ok
- sioyek ok

All of them build fine with the experimental gumbo-parser.

Ben file:

Affected: .depends ~ /\b(libgumbo2|libgumbo1)\b/
Good: .depends ~ /\b(libgumbo2)\b/
Bad: .depends ~ /\b(libgumbo1)\b/

Best,

Aymeric Agon-Rambosson

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

[Nilesh Patra]

On Thu, 10 Aug 2023 19:16:55 +0545 Nisha Pariyar  
wrote:
> * Package name: golang-github-dsnet-compress
>Version : 0.0.1-1
>Upstream Author : Joe Tsai
> * URL : https://github.com/dsnet/compress
> * License : BSD-3-clause
>Programming Lang: Go
>Description : Collection of compression related Go packages.
> 
>   Collection of compression libraries for Go
>   .
>   A collection of pure Go libraries for popular compression algorithms,
>   designed to extend the Go standard library capabilities. Includes
>   implementations of Brotli (RFC 7932), BZip2, DEFLATE (RFC 1951), and
>   XFLATE formats. Offers a balance between maintainable code,
>   performance, and flexibility. Active development; API stability not
>   guaranteed. Requires Go 1.9+.

I wanted to ask a couple of questions before I start with a review:

* Is there a package that needs dsnet/compress? If so, which one - and
  is it a crucial dependency?
* The README says that:
NOTE: This library is in active development. As such, there are no 
guarantees about the stability of the API.
The author reserves the right to arbitrarily break the API for any 
reason.

This does not sound very good in debian's context. Breaking APIs in
major releases are still OK, but I'm a little concerned about this in
for instance patch/minor releases.

* There's a compression library https://github.com/klauspost/compress
  which is already in debian (golang-github-klauspost-compress). The
  additional functionality that dsnet/compress seems to provide is
  brotli compression/decompression. If this is not used eventually
  (assuming this package is dep of another package that you're trying to get in)
  do you think it'd be possible to patch the code and convince upstream?

In principle I'd have just started with a review and uploaded eventually
but the API problem made me re-think.

Let me know.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1052133: apt: E: Removing essential system-critical packages is not permitted. This might break the system.

[Thorsten Glaser]

Johannes Schauer Marin Rodrigues dixit:

>Quoting Thorsten Glaser (2023-09-17 23:03:50)
>> E: Removing essential system-critical packages is not permitted. This might 
>> break the system.
>>
>> Used to be that it asks for “Yes, do as I say!”, and this is missing
>> in sid now‽ I kinda need that…
>
>it's documented in "man apt-get" if you search for "essential" you find:
>
>> --allow-remove-essential

oic

>It appears that there are people who will assume that when their computer tells
>them to type “Yes, do as I say!” then that's just what they will do without
>switching their brain on first: https://youtu.be/0506yDSgU7M?t=633

Yeah, you’re caught between a rock and a hard place there, I suppose.

>To prevent this from happening in the future, this was changed to become even
>more difficult and now one has to read the manual and pass the option above
>instead.

The problem is, the last time apt-get told me to look up a switch
to allow something (release name change, IIRC), the manpage did not
have that information at all, let alone easily findable.

Maybe add…

N: See remove-essential in the apt-get(8) manual page for details.

… to that message, as second line?

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#1052177: Provides a PostgreSQL extension without depending on the correct server version

[Christoph Berg]

Source: pg-gvm
Version: 22.4.0-2
Severity: serious
Tags: patch

Hi,

pg-gvm currently ships a single binary package "pg-gvm" that installs
files to /usr/lib/postgresql/15/, but doesn't declare that anywhere;
the packaging doesn't conform to the established PostgreSQL extension
packaging scheme.

PostgreSQL 16 is just entering unstable, the package needs to be
updated.

A branch to fix that is at 
https://salsa.debian.org/pkg-security-team/pg-gvm/-/merge_requests/1

I plan to NMU this in 10 days to get the PostgreSQL 16 transition
forward if I don't hear back otherwise.

Thanks,
Christoph

Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser

[Aymeric Agon-Rambosson]

Le dimanche 17 septembre 2023 à 21:18, Bastian Germann 
 a écrit :


That will not be needed. Next step for you is to file the 
transition bug. Youcan see already filed ones at:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org


Done, bug #1052174.

Bug#1034472: reportbug: auto-apt-proxy prints IPv6 literally incorrectly

[Alexander Clouter]

Hello,

On Sat, 16 Sep 2023, at 17:46, Helmut Grohne wrote:
>
> I also experience this problem. I'm attaching a patch that makes it work
> for me, but I am unsure whether the patch is universally correct as it
> may need some quoting of the ip in "Acquire::http::Proxy::${ip}=DIRECT"
> if the ip contains "::". In my case, the ip does not and therefore it
> works. Could you give the patch a try in your environment where "::"
> does happen?

The patch does work for me, thanks.

I suspect a better fix, especially given the escaping problem you have 
highlighted, would be just to pass through the DNS name to connect to.

For where 'apt-proxy' is a CNAME or are A/ records, then probably just 
returning 'apt-proxy' is the right thing to do. For SRV records, I think all 
that needs to be done is to return the target.

Do you think this would be suitable?

Happy to put it together myself, but it would be great if Antonio Terceiro 
could chip in.

Thanks

Bug#1052190: icingaweb2-module-toplevelview: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-toplevelview
Version: 0.3.3-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#986736: RFP: xmake -- A cross-platform build utility based on Lua

[Lin Qigang]

The xmake that was in Debian previously does not seem to be the same one 
that I have uploaded. There is a substantial following for it, and it 
has been actively maintained since 2015 [1]. Here is a listing of 
projects that volunteered their usage of xmake [2].


I believe this package is very useful and a good addition to Debian. The 
autopkgtest that I prepared for it shows only a fraction of its 
versatility [3]. The homepage contains a great deal of documentation on 
its usage as well [4].


I have been in contact with the upstream maintainer, Ruki Wang, since 
taking over the ITP, and I am sure this package will not be ignored or 
forgotten by its many users. Please consider adding it to Debian.


[1] https://github.com/xmake-io/xmake
[2] https://xmake.io/#/about/who_is_using_xmake
[3] 
https://salsa.debian.org/xmake-team/xmake/-/blob/master/debian/tests/unittests

[4] https://xmake.io/

Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052171: libva-utils: trouble using the d/watch file

[Patrice Duroux]

Source: libva-utils
Version: 2.12.0+ds1-1
Severity: minor

Dear Maintainer,

The d/watch file use the tags line to generate a release download link, but not
all tags are (strangely) releases, for instance tag 1.18.0 or the current tag
2.20.0 is not working (yet).

#uscan --download
Newest version of libva-utils on remote site is 2.20.0, local version is
2.12.0+ds1
 => Newer package available from:
=> https://github.com/intel/libva-utils/releases/download/2.20.0/libva-
utils-2.20.0.tar.bz2
uscan warn: In directory ., downloading
  https://github.com/intel/libva-utils/releases/download/2.20.0/libva-
utils-2.20.0.tar.bz2 failed: 404 Not Found
uscan warn: No upstream tarball downloaded. No further processing with
mk_origtargz ...

Why not downloading the source under tags?

Regards,
Patrice


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/watch b/debian/watch
index 4ac3094..5353a2a 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,7 +1,4 @@
 version=4
-opts="\
-compression=bz2, \
-dversionmangle=s/\+(?:git)?[0-9]*(?:\+g[0-9a-f]*)//, \
-
downloadurlmangle=s#/tag/#/download/#;s#(@ANY_VERSION@)$#$1/@PACKAGE@-$2.tar.bz2#,
 \
-filenamemangle=s#@ANY_VERSION@#@PACKAGE@-$1.tar.bz2#" \
-  https://github.com/intel/@PACKAGE@/tags .*/releases/tag/@ANY_VERSION@
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+https://github.com/intel/libva-utils/tags \
+(?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1052071:

[Nilson Silva]

Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553


De: Yadd 
Enviado: segunda-feira, 18 de setembro de 2023 07:23
Para: Nilson Silva 
Assunto: Re: built-in packages: esniff in tad

On 9/18/23 13:25, Nilson Silva wrote:
>
> HiYaad!
>
> I decided to package and maintain esniff:
> https://salsa.debian.org/nilsonfsilva/node-esniff
>
> Once ready, I discovered that it is built into "tad", the package you
> maintain.
>
> I don't know if it's possible to unincorporate it.

Hi,

yes it is possible but what is the benefit ?

> If this is not possible, could you respond and close the bug?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052071
>
> Another thing: do you sponsor nodejs starter packs?
> I have been using your packages as a reference.
> Congratulations on your beautiful work on Debian!
>
> best wishes
> Nilson F. Silva

Bug#1052071:

[Nilson Silva]

Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553


De: Yadd 
Enviado: segunda-feira, 18 de setembro de 2023 11:10
Para: Nilson Silva 
Assunto: Re: built-in packages: esniff in tad

On 9/18/23 17:41, Nilson Silva wrote:
> Hi Yadd!
>
>> Another thing: do you sponsor nodejs starter packs?
> !
> Thank you in advance for your attention to my email.
>
> Answering your question:
> I don't know if esniff is still an active project, as it hasn't been updated 
> since 2016.
> And I also don't know how you keep up with the supposed updates that the 
> package will undergo.
>
> But perhaps this is a good reason for disincorporation.
>
> Another reason would be the issue of packages that depend on esniff.
>
> I actually got to this package, after running
> npm2deb depends on -b -r
> and I discovered that it is a dependency on the package I was bringing to 
> Debian.
>
> So I spent the end of the week working on it.

Do you know `pkgjs-depends` ? Very helpful for such search

> Since tad is a mandatory dependency of esniff, I found that the two cannot 
> coexist
> in the same environment. But after all the packaging work.

I still don't understand what you want to do

> I believe the CI/CD test detected the problem in autopkgtests
>
> Now my concern would be:
> What if someone else has the same problem as me? package something that also
>   depends on esniff, but don't know that esniff is a "tad" module?

Ftpmasters asked us to no more package "too-little node module". Then we
started to embed little package in bigger ones but in this case, the
global package exports all names. Then you can require node-esniff in
any debian/control.
Then even if we disassemble the package to have a separate node-esniff,
no changes.

For now, node-tad isn't used by any package, neither esniff. So
multiplicating source packages without real use isn't interesting.

> I understand your concern as it is a crucial dependency for "tad". But if you 
> decide to cancel the incorporation, you can also co-maintain the package with 
> me.

JS Team is a team, I'm not owner of any package.

> If you obviously want to.
>
> But far be it from me to create controversy on this subject.
> What can I do, and put the "pad" with Build-depends of the package I want to 
> bring to Debian?
>
> and by the way, if you can sponsor. Thank you very much!

What is your goal with esniff ? Is it a need for building an interesting
package ?

> Nilson F. Silva

Bug#1052071:

[Nilson Silva]

De: Nilson Silva 
Enviado: segunda-feira, 18 de setembro de 2023 12:12
Para: Yadd 
Assunto: RE: built-in packages: esniff in tad

Hi Yadd!

> Do you know `pkgjs-depends` ? Very helpful for such search
Good to know that this tool exists. I'll try it. Thanks

> I still don't understand what you want to do
I'm sorry if I didn't make myself understood. And sometimes translators don't 
help either.
But that's how I discovered the situation

1. Debi
Selecting previously unselected node-esniff package.
(Reading database... 75473 files and directories currently installed.)
Preparing to unpack node-esniff_1.1.0+dfsg-1_all.deb ...
Unpacking node-esniff (1.1.0+dfsg-1) ...
dpkg: error processing file node-esniff_1.1.0+dfsg-1_all.deb (--install):
 trying to replace '/usr/share/nodejs/esniff/accessed-properties.js' which is 
also in the tad 3.1.0+~cs10.23.44-1 package
Errors were found during processing:
 node-esniff_1.1.0+dfsg-1_all.deb
debi: error: subprocess dpkg -i node-esniff_1.1.0+dfsg-1_all.deb returned exit 
status

2. apt install node-esniff
Reading package lists... Done
Building dependency tree... Done
Reading status information... Done
Note, selecting 'tad' instead of 'node-esniff'
tad is already the latest version (3.1.0+~cs10.23.44-1).
0 updated, 0 newly installed, 0 to remove and 0 not updated

> Ftpmasters asked us to no more package "too-little node module". Then we
>started to embed little package in bigger ones but in this case, the
> global package exports all names. Then you can require node-esniff in
> any debian/control.
> Then even if we disassemble the package to have a separate node-esniff, no 
> changes.
It was good to know that. This will be a guide for my packages. Thanks

> For now, node-tad is not used by any package, not even esniff. Then
> multiplying source packages without real use is not interesting.
You are sure!

> JS Team is a team, I'm not owner of any package.
Clear. I expressed myself wrong. I wanted to say that since you are also the 
maintainer,
you have the right to decide about the package

> What is your goal with esniff ? Is it a need for building an interesting 
> package?
Yes. It's a package I want to bring to Debian.
But I don't know if it's interesting in your eyes. I'll get it ready. When I'm 
ready, I'll submit
it for you to take a look at.

But thank you very much for everything

Best wishes
Nilson F. Silva

Bug#1052175: ITP: golang-github-yuin-goldmark-highlighting-v2 -- A Syntax highlighting extension for the goldmark markdown parser (v2)

[Peymaneh]

Hi,

Am 18.09.23 um 20:14 schrieb Shengjing Zhu:

On Tue, Sep 19, 2023 at 2:06 AM Peymaneh  wrote:


Package: wnpp
Severity: wishlist
Owner: Peymaneh 

* Package name: golang-github-yuin-goldmark-highlighting-v2
   Version : 0.0~git20230729.37449ab-1
   Upstream Author : Yusuke Inuzuka
* URL : https://github.com/yuin/goldmark-highlighting
* License : Expat
   Programming Lang: Go
   Description : A Syntax highlighting extension for the goldmark markdown 
parser.

This package provides github.com/yuin/goldmark-highlighting/v2

Version 1 is packaged in Debian as golang-github-yuin-goldmark-highlighting

Version 2 is needed for updating Caddy.



v1 is only used by caddy, you can just update it to v2 without
changing source & binary package name when you upload the new version
of caddy.
There is no rule that major versions must be packaged separately. It's
only needed when the transition is hard to coordinate with all the
reverse-depends. (Just comparing to the C libraries, we only add
version suffix in -dev package name when reverse-depends are hard to
adapt to the new api.)



Alright :)


OpenPGP_signature.asc
Description: OpenPGP digital signature