Bug#1070223: RM: python-ara -- ROM; unmaintained package

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-...@packages.debian.org
Control: affects -1 + src:python-ara

Hi,

I went to see with Michal Arbet, the current maintainer of the package,
how he could fix the current open bugs, and he has no time for it. He
agreed for this package to be removed, rather then having it bitrot in
Unstable.

Please remove python-ara from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1070150: Loading of expl3.ltx **extremely** slow on emulated runs

[Max Chernoff]

Hi Norbert,

On Thu, 2024-05-02 at 08:44 +0900, norb...@preining.info wrote:
> at Debian they got a report that loading expl3.ltx when building formats
> is **extremely** slow when running under emulations:
>
> 1070150 at bugs.debian.org
>
> Running fmtutil output through ts (timestamp utility from moreutils):
>
> May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1 branch)
> May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
> May 01 14:51:15 
> (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks,
> May 01 14:51:19 document commands, control, par, spacing, files, font 
> encodings, lengths,
>
> That is 23 **minutes** to load expl3-code.tex. Ok, the file is nearly 4k
> lines, but still, 23 minutes seems to be excessive.

I don't think that this is TeX-related. From a Fedora 39 x86_64 host:

$ podman run --arch arm64 --rm -it --pull always debian:stable /bin/bash

$ apt update && \
  apt install -y moreutils && \
  apt install -y --download-only python3-minimal
[...]

$ time apt install -y python3-minimal | ts
May 02 05:27:51 Reading package lists...
May 02 05:27:52 Building dependency tree...
May 02 05:27:52 Reading state information...
May 02 05:27:52 The following additional packages will be installed:
May 02 05:27:52   ca-certificates krb5-locales libexpat1 libgpm2 
libgssapi-krb5-2 libk5crypto3
May 02 05:27:52   libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 
libnsl2
May 02 05:27:52   libpython3.11-minimal libpython3.11-stdlib libreadline8 
libsqlite3-0 libssl3
May 02 05:27:52   libtirpc-common libtirpc3 media-types openssl python3.11 
python3.11-minimal
May 02 05:27:52   readline-common
May 02 05:27:52 Suggested packages:
May 02 05:27:52   gpm krb5-doc krb5-user python3.11-venv python3.11-doc 
binutils
May 02 05:27:52   binfmt-support readline-doc
May 02 05:27:53 The following NEW packages will be installed:
May 02 05:27:53   ca-certificates krb5-locales libexpat1 libgpm2 
libgssapi-krb5-2 libk5crypto3
May 02 05:27:53   libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 
libnsl2
May 02 05:27:53   libpython3.11-minimal libpython3.11-stdlib libreadline8 
libsqlite3-0 libssl3
May 02 05:27:53   libtirpc-common libtirpc3 media-types openssl 
python3-minimal python3.11
May 02 05:27:53   python3.11-minimal readline-common
[...]
May 02 05:28:40 done.

real0m52.253s
user0m51.889s
sys 0m7.453s

$ exit

$ podman run --arch arm64 --rm --pull always -it debian:sid /bin/bash

$ apt update && \
  apt install -y moreutils && \
  apt install -y --download-only python3-minimal
[...]

$ time apt install -y python3-minimal | ts
May 02 05:29:22 Reading package lists...
May 02 05:29:26 Building dependency tree...
May 02 05:29:26 Reading state information...
May 02 05:29:30 Installing:
May 02 05:29:30   python3-minimal
May 02 05:29:30
May 02 05:29:30 Installing dependencies:
May 02 05:29:30   ca-certificates libpython3.11-minimal media-types
readline-common
May 02 05:29:30   libexpat1   libpython3.11-stdlib  openssl
May 02 05:29:30   libgpm2 libreadline8t64   python3.11
May 02 05:29:30   libncursesw6libsqlite3-0  python3.11-minimal
May 02 05:29:30
May 02 05:29:30 Suggested packages:
May 02 05:29:30   gpm python3.11-venv python3.11-doc binutils 
binfmt-support readline-doc
[...]
May 02 05:32:56 done.

real3m52.398s
user3m54.177s
sys 0m7.514s

$ exit

Thanks,
-- Max

Bug#1070222: RM: sahara -- ROM; unmaintained upstream, RC buggy

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sah...@packages.debian.org
Control: affects -1 + src:sahara

Hi,

Sahara FTBFS (unit tests failures), and is unmaintained upstream. It's
time to get it removed from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)

[John Paul Adrian Glaubitz]

On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote:
> Hi,
> 
> [John Paul Adrian Glaubitz 2020-05-10]
> > I would like to adopt this package. There is a new upstream available and 
> > the
> > repository has been moved to Github with some recent activity [1].
> 
> What came out of this intent?
> 
> I just migrated the package to a git repository on
> https://salsa.debian.org/debian/unadf >.

I started working on this, but I got stuck because of the fact that the upstream
package is actually not just unadf but a whole library that might need different
treatment.

Adrian

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

Bug#1069690: bookworm-pu: package libkf5ksieve/4:22.12.3-1+deb12u1

[Salvatore Bonaccorso]

Hi Patrick,

On Mon, Apr 22, 2024 at 09:36:54PM +0200, Patrick Franz wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> X-Debbugs-Cc: delta...@debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> There is a bug in libkf5sieve where the password instead of the
> username is sent when using managesieve and could therefore be
> logged on a server as the login will fail.
> 
> [ Impact ]
> Potentially sensitive passwords are logged on a server.
> 
> [ Tests ]
> Affected user has successfully tested the patched version.
> 
> [ Risks ]
> The patch is trivial (1 line is changed) and it's quite obvious
> that it was a bug in the first place.
> 
> [ 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 ]
> 1-line patch to fix the bug.

> diffstat for libkf5ksieve-22.12.3 libkf5ksieve-22.12.3

As it is not yet uploaded for bookworm, you might add as well the CVE
id reference in the changelog: CVE-2023-52723 .

p.s.: I think you can take advantage of the improved workflow for this
specific one, if you are sure the package will be accepted as it is
from SRM, you can with the proposed update bug filling, along as well
already do the upload.

(but note, just commenting this with no authrotiy speaking, as not
part of the release team)

Regards,
Salvatore

Bug#1070221: lintian: warn about help2man generated pages containing errors loading shared libraries

[Paul Wise]

Package: lintian
Severity: wishlist

For manual pages generated by tools like help2man that run binaries to
get usage statements for conversion to manual page format, please check
that the manual pages do not contain common text indicating that the
executable or script was not able to run successfully, so didn't output
any usage statement and so a useful manual page was not generated.

For example when running an ELF executable:

   $ ./src/jbig2
   jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open 
shared object file: No such file or directory
   
   $ zcat /usr/share/man/man1/jbig2.1.gz
   .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.3.
   .TH JBIG2: "1" "February 2024" "jbig2: error while loading shared libraries: 
libjbig2enc.so.0: cannot open shared object file: No such file or directory" 
"User Commands"
   .SH NAME
   jbig2: \- encoder for JBIG2
   .SH DESCRIPTION
   src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot 
open shared object file: No such file or directory

For example when running a Python script:

   $ ./foo.py 
   Traceback (most recent call last):
 File "./foo.py", line 2, in 
   import bar
   ImportError: No module named bar
   
   $ help2man --no-discard-stderr ./foo.py 
   .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.3.
   .TH TRACEBACK "1" "May 2024" "Traceback (most recent call last):"
"User Commands"
   .SH NAME
   Traceback \- manual page for Traceback (most recent call last):
   .SH DESCRIPTION
   .SS "Traceback (most recent call last):"
   .IP
   File "./foo.py", line 2, in 
   .IP
   import bar
   .PP
   ImportError: No module named bar
   .IP
   File "./foo.py", line 2, in 
   .IP
   import bar
   .PP
   ImportError: No module named bar
   .SH "SEE ALSO"
   The full documentation for
   .B Traceback
   is maintained as a Texinfo manual.  If the
   .B info
   and
   .B Traceback
   programs are properly installed at your site, the command
   .IP
   .B info Traceback
   .PP
   should give you access to the complete manual.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070220: jbig2: broken manual page: src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory

[Paul Wise]

Package: jbig2
Version: 0.29-2.1
Severity: normal
Usertags: help2man

The jbig2 manual page is broken. Looks like it was generated via
help2man using the binary in the build tree but without using
LD_LIBRARY_PATH so the binary could not find libraries it uses,
so jbig2 could not start, so it didn't print the usage statement
and help2man did not convert the usage statement to a manual page.
The help2man conversion in debian/rules may have some kind of problem.

   $ COLUMNS=80 man jbig2 | cat
   JBIG2:(1)User Commands   
JBIG2:(1)
   
   NAME
  jbig2: - encoder for JBIG2
   
   DESCRIPTION
  src/jbig2: error while loading shared libraries: libjbig2enc.so.0: 
can‐
  not open shared object file: No such file or directory
   
   jbig2: error while loading sh... February 2024   
JBIG2:(1)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070219: python3-pyasn: __init__.py:201: SyntaxWarning: invalid escape sequence '\.'

[Paul Wise]

Package: python3-pyasn
Version: 1.6.1-3+b4
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

When installing pyasn I get a syntax warning with Python 3.12,
the fix would be to use raw strings with Python regexes:

https://docs.python.org/3/library/re.html#raw-string-notation

   Selecting previously unselected package python3-pyasn.
   Preparing to unpack .../16-python3-pyasn_1.6.1-3+b4_amd64.deb ...
   Unpacking python3-pyasn (1.6.1-3+b4) ...
   Setting up python3-pyasn (1.6.1-3+b4) ...
   /usr/lib/python3/dist-packages/pyasn/__init__.py:201: SyntaxWarning: invalid 
escape sequence '\.'
 pattern = re.compile("^[AS]|[as]|[aS]|[As]][0-9]*(\.)?[0-9]+")

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-pyasn depends on:
ii  libc62.37-19
ii  python3  3.11.8-1

python3-pyasn recommends no packages.

python3-pyasn suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070188: python3-spyder: uninstallable in unstable due to pylint

[Julian Gilbey]

On Wed, May 01, 2024 at 03:04:56PM +0200, Roland Mas wrote:
> Package: python3-spyder
> Version: 5.5.1+ds-1
> Severity: important
> 
> Dear Maintainer,
> 
> python3-spyder is no longer installable in sid; it depends (and
> build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in
> unstable.
> 
> Loosening the versioned dependency is enough to allow spyder to build,
> but I don't know whether that introduces runtime changes or not.

Dear Roland,

That would be a reasonable thing to do.  Version 5.5.4 depends on
pylint >= 3.1.  I don't have time to do this right now, unfortunately,
so if someone else would like to make the required changes and upload
a patched version of 5.5.1 in the meantime, please feel free to do
so.

See
https://github.com/spyder-ide/spyder/commit/26244db2750f92aa6cbbfd74252d6aa4daa07811
for the changes required (but obviously don't change python-lsp-server
for now!).

Best wishes,

   Julian

Bug#1070215: python-qtpy: Please support qtpy abstraction in packaging

[Julian Gilbey]

Hi Stuart,

On Thu, May 02, 2024 at 09:50:46AM +1000, Stuart Prescott wrote:
> Source: python-qtpy
> Version: 2.4.1-2
> Severity: normal
> X-Debbugs-Cc: stu...@debian.org
> 
> Dear Maintainer,
> 
> The qtpy description says "Abstraction layer for PySide2/PySide6/PyQt5/PyQt6"
> however the packaging for python3-qtpy is optimised only for applications
> using PyQt5, declaring Depends on all the python3-pyqt5 packages.
> 
> An application that uses qtpy and any library other than pyqt5 needs to
> have pyqt5 installed in addition to what is actually required.
> [...]

Indeed; I have had a similar discussion a while back with one of the
other qtpy maintainers, but I don't remember the details.

I like your idea about having python3-qtpy-* packages; I hadn't
thought of doing this, and it would be the least disruptive for
reverse dependencies, as they could simply change to one of the
python3-qtpy-* packages.

I don't have the capacity to do this myself, but please feel free to
do a team upload.  If going down this route, the src:python-qtpy
testsuite could be enhanced to test the various different backends.
(This is supported by upstream, if I recall correctly.)  Before you do
this, though, please do compile a list of reverse dependencies that
would be hit by this change so we understand the scope of the impact.

> One possible solution to this would be for src:python-qtpy to include
> the following packages:
> 
> Package: python3-qtpy
> Depends: python3-packaging
> Contains: everything
> 
> Package: python3-qtpy-pyqt5
> Depends: python3-qtpy, python3-pyqt5, python3-pyqt5.*
> Contains: probably nothing
> 
> Package: python3-qtpy-pyqt6
> Depends: python3-qtpy, python3-pyqt6, python3-pyqt6.*
> Contains: probably nothing
> 
> Package: python3-qtpy-pyside6
> Depends: python3-qtpy, python3-pyside6.*
> Contains: probably nothing

> Another solution is for python-qtpy to declare at most Suggests on any
> of the pyqt/pyside packages and leave it to the application to declare
> dependencies on the toolkit packages it needs. The application package
> knows what toolkit and libraries are required while, by design, qtpy
> does not. This would also provide better support for the split toolkit
> packages given that Qt5 and Qt6 are modularised - the application can
> depend on only what is needed rather than having all the split packages
> installed just in case.

This seems superfluous given your suggestion above: your new
python3-qtpy package would be exactly this, except lacking the
Suggests.  (It should, of course, also suggest the python3-qtpy-*
packages.)  But given that python3-qtpy is extremely unlikely to be
requested by an individual user - it is instead a runtime dependency
of other packages - having a long list of Suggests is unlikely to
bring much benefit.

> PySide6 will hit NEW soon-ish and sasview will need the updated
> packaging for qtpy soon after.

I wouldn't do the qtpy update, then, until PySide6 has reached
testing, or it will need two journeys to NEW itself.

> I'm happy to do a Team Upload to implement whichever agreed strategy you
> prefer.

Best wishes,

   Julian

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

On 2024-05-01 19:05:06 +0100, Richard Lewis wrote:
> I agree that you should be able to filter out duplicate lines. And i think
> this is possible with a  custom filter.

Yes, but "sed" may not be the best tool for that. With sed, removing
lines containing only the usual network managers is easier.

> I dont think it should be the default - most chkrootkit users have a more
> static network setup,

If they have a static network setup, why hiding the interface name?
Doing that makes the output more confusing, and the replacement of
an interface by another one would not be detected.

> and the alert shows something has changed. For laptops where
> networking is more dynamic it's hard to design something that works
> for everyone without also hiding information for other people.

But are lines containing *only* the usual network managers suspicious?

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

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Andres Salomon]

Control: reassign -1 snappy

Thanks, I've verified it's related to snappy 1.2.0:

dilinger@debian-sid:~$ dpkg -l |grep snapp
ii  libsnappy1v5:amd64  1.1.10-1+b1 
amd64fast compression/decompression library

dilinger@debian-sid:~$ chromium
VMware: No 3D enabled (0, Success).
VMware: No 3D enabled (0, Success).
[6693:6693:0501/220817.653832:ERROR:chrome_browser_cloud_management_controller.cc(161)] 
Cloud management controller initialization aborted as CBCM is not 
enabled. Please use the `--enable-chrome-browser-cloud-management` 
command line flag to enable it if you are not using the official Google 
Chrome build.

[...]
dilinger@debian-sid:~$ sudo apt install libsnappy1v5
[...]
Setting up libsnappy1v5:amd64 (1.2.0-1) ...
Processing triggers for libc-bin (2.37-18) ...
dilinger@debian-sid:~$ chromium
/usr/lib/chromium/chromium: symbol lookup error: 
/usr/lib/chromium/chromium: undefined symbol: 
_ZN6snappy11RawCompressEPKcmPcPm



I guess the ABI quietly changed without any kind of SONAME change? 
Here's snappy 1.1.10:


root@hm90:/chromium-124.0.6367.78# objdump -T 
/usr/lib/x86_64-linux-gnu/libsnappy.so.1.1.10|grep RawCompressE
4850 gDF .text	009f  Base 
_ZN6snappy11RawCompressEPKcmPcPm


And here's snappy 1.2.0:

root@hm90:/chromium-124.0.6367.78# objdump -T 
/usr/lib/x86_64-linux-gnu/libsnappy.so.1.1.10|grep RawCompressE
5240 gDF .text	00a2  Base 
_ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE






On 5/1/24 20:06, Jethro Nederhof wrote:

Package: chromium
Version: 124.0.6367.78-1
Severity: important
X-Debbugs-Cc: jet...@jethron.id.au

Dear Maintainer,

Attempting to run chromium fails with:

/usr/lib/chromium/chromium: symbol lookup error: /usr/lib/chromium/chromium: 
undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm

I suspect this is due to the upload of 1.2.0-1 of libsnappy1v5 on 2024-05-01.

The closest symbol I can find in the newer libsnappy.so.* files is 
_ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE

Thank you for your work packaging chromium!

Kind regards,
Jethro


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

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

Versions of packages chromium depends on:
ii  chromium-common  124.0.6367.78-1
ii  libasound2t641.2.11-1+b1
ii  libatk-bridge2.0-0t642.52.0-1
ii  libatk1.0-0t64   2.52.0-1
ii  libatomic1   14-20240429-1
ii  libatspi2.0-0t64 2.52.0-1
ii  libc62.37-19
ii  libcairo21.18.0-3+b1
ii  libcups2t64  2.4.7-1.2+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libexpat12.6.2-1
ii  libflac12t64 1.4.3+ds-2.1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgbm1  24.0.6-1+b1
ii  libgcc-s114-20240429-1
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  libjpeg62-turbo  1:2.1.5-3
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b3
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpng16-16t64   1.6.43-5
ii  libpulse016.1+dfsg1-5
ii  libsnappy1v5 1.2.0-1
ii  libstdc++6   

Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Alban Browaeys]

On Mon, 29 Apr 2024 13:09:27 -0700 Jay 
wrote:
> On Sat, Jun 17, 2023 at 4:55 AM Alban Browaeys
 wrote:
> > This bug would likely be fixed by Debian (the systemd package?)
> > shipping a /usr/lib/systemd/user-environment-generators/ systemd
user
> > environment generator with the default PATH Debian already set in
> > /etc/profile.
> I plan to check with the Debian systemd package maintainers about
this option.
> 
> But
> > Or ship an  /usr/lib/environment.d/*.conf file (which itself is
read by
> > a systemd user environment generator : /usr/lib/systemd/user-
> > environment-generators/30-systemd-environment-d-generator).
> This might be the solution we're looking for. A
> /usr/lib/environment.d/??-gdm3.conf file
> provided by the gdm3 package?


No, in that it should not be named after gdm.
It is a bit far, but to me your issue is due to gdm3 not overwriting
the systemd user environment with its own PATH value anymore. This
means that you got things back working by reverting
https://gitlab.gnome.org/GNOME/gdm/-/commit/ccecd9c975d04da80db4cd547b67a1a94fa83292
because you made gdm3 overwrite the system user session environment
PATH value as it was doing before.
So the issue is that the systemd user enviroment is not set properly
for Debian specific PATH components (and that gdm3 does not overwrite
this systemd user session PATH value anymore if one is set, thus the
gdm3 fallback PATH mention in the patch. That is if no PATH value is
defined in the environment, then the old behavior of gdm setting it is
preserved, but if one is defined, then it is not changed).
Thus if you get the wrong PATH value it is not because gdm set it to
the wrong value, but because it stopped overweriting the bad value (in
that Debian requires a specific value that is not hte default and as no
Debian specific config has been provided, the default is wrong).


So the issue is, to me, Debian systemd specific and only involves gdm
because it has stopped overwriting the systemd default value (which is
wrong on Debian because Debian has specific path).

The Debian specific defaults are shown in /etc/profile
if [ "$(id -u)" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH


Debian systemd package just need to ship a config file to set this PATH
value.
So a /usr/lib/environment.d/??-debian.conf file shipped by the Debian
systemd package is what I deem the correct fix.

This bug report should be reassigned to systemd in my opinion.


So you were right that reverting commit ccecd9c9 would fix your issue,
but not because gdm added a bug but because it stopped hiding an
underlying "bug" (well wrong default PATH value in systemd for Debian).
It could be that systemd maintainers thing this is gdm job to overwrite
their value, though it looks more correct to me to bug them first as
they are the one setting the wrong default for Debian (or so I believe,
I have not checked extensively if the wrong PATH default value could be
fine at the systemd level and be changed afterwards).

Cheers,
Alban

Bug#1060963: paramiko: FTBFS: dh_auto_test: error: pybuild

[Alexandre Detiste]

> E   ModuleNotFoundError: No module named 'six'

This happens because we unknot the
 python3-mock -> python3-pbr -> python3-six
dependency chain.

I did this _on purpose_ to discover missing python3-six
(build-)dependencies and/or upstream that needs a cleanup.

Here it's of course better to do this long overdue paramiko update
than merely adding python3-six as build-dep for a quick fix.

Greetings and thank you



https://tracker.debian.org/news/1492697/accepted-python-mock-510-1-source-into-unstable/

 python-mock (5.1.0-1) unstable; urgency=medium
 .
   * Team Upload
   * New upstream version 5.1.0 (Closes: #717192, #717193, #1030887)
 (LP: #1248066)
   * remove obsolete build-dep python3-pbr & python3-unittest2
   * use new dh-sequence-python3


https://tracker.debian.org/news/1505240/accepted-python-pbr-600-1-source-into-unstable/

python-pbr (6.0.0-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #1060153).
   * Do not use six anymore.

Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix^J out-of-bound writes when writing escape sequence

[Miguel Jacq]

On Mon, 22 Apr 2024 09:31:39 +0200 Charlemagne Lasse 
 wrote:
> Hi,
> 
> Can this be backported to older Debian versions via the security repo?
> This bug can be used to execute code when using the PHP engine:
>
> * https://www.offensivecon.org/speakers/2024/charles-fol.html
> * https://www.openwall.com/lists/oss-security/2024/04/18/4
>

Indeed.. I know that buster is old-old stable, but starting to get nervous that 
it
doesn't contain the fix that Bullseye and Bookworm have. Especially as we 
approach
the date of a security conference that will talk about this issue.

Is anyone on the LTS team working on it for Buster? That might also help trickle
down to ELTS for Stretch/Jessie?


signature.asc
Description: PGP signature

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Jethro Nederhof]

Package: chromium
Version: 124.0.6367.78-1
Severity: important
X-Debbugs-Cc: jet...@jethron.id.au

Dear Maintainer,

Attempting to run chromium fails with:

/usr/lib/chromium/chromium: symbol lookup error: /usr/lib/chromium/chromium: 
undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm

I suspect this is due to the upload of 1.2.0-1 of libsnappy1v5 on 2024-05-01.

The closest symbol I can find in the newer libsnappy.so.* files is 
_ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE

Thank you for your work packaging chromium!

Kind regards,
Jethro


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

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

Versions of packages chromium depends on:
ii  chromium-common  124.0.6367.78-1
ii  libasound2t641.2.11-1+b1
ii  libatk-bridge2.0-0t642.52.0-1
ii  libatk1.0-0t64   2.52.0-1
ii  libatomic1   14-20240429-1
ii  libatspi2.0-0t64 2.52.0-1
ii  libc62.37-19
ii  libcairo21.18.0-3+b1
ii  libcups2t64  2.4.7-1.2+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libexpat12.6.2-1
ii  libflac12t64 1.4.3+ds-2.1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgbm1  24.0.6-1+b1
ii  libgcc-s114-20240429-1
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  libjpeg62-turbo  1:2.1.5-3
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b3
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpng16-16t64   1.6.43-5
ii  libpulse016.1+dfsg1-5
ii  libsnappy1v5 1.2.0-1
ii  libstdc++6   14-20240429-1
ii  libwoff1 1.0.2-2+b1
ii  libx11-6 2:1.8.7-1+b1
ii  libxcb1  1.17.0-1
ii  libxcomposite1   1:0.4.5-1+b1
ii  libxdamage1  1:1.1.6-1+b1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2+b1
ii  libxkbcommon01.6.0-1+b1
ii  libxml2  2.9.14+dfsg-1.3+b3
ii  libxnvctrl0  535.171.04-1
ii  libxrandr2   2:1.5.4-1
ii  libxslt1.1   1.1.35-1+b1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.15.1-1+b1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages chromium recommends:
ii  chromium-sandbox  124.0.6367.78-1

Versions of packages chromium suggests:
ii  chromium-driver  124.0.6367.78-1
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.37-19
ii  libdrm2   2.4.120-2
ii  libjsoncpp25  1.9.5-6+b2
ii  libstdc++614-20240429-1
ii  libx11-6  2:1.8.7-1+b1
ii  libxnvctrl0   535.171.04-1
ii  x11-utils 7.7+6+b1
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages chromium-common 

Bug#1070216: cruft-ng: should call "plocate --null /" to avoid chocking on filenames that contains a newline

[Alexandre Detiste]

Package: cruft-ng
Version: 0.9.61
Severity: normal


https://git.sr.ht/~nabijaczleweli/voreutils contains such test data

Bug#1070215: python-qtpy: Please support qtpy abstraction in packaging

[Stuart Prescott]

Source: python-qtpy
Version: 2.4.1-2
Severity: normal
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The qtpy description says "Abstraction layer for PySide2/PySide6/PyQt5/PyQt6"
however the packaging for python3-qtpy is optimised only for applications
using PyQt5, declaring Depends on all the python3-pyqt5 packages.

An application that uses qtpy and any library other than pyqt5 needs to
have pyqt5 installed in addition to what is actually required.

As a concrete example, the next version of sasview will need PySide6 for
Qt6 while using qtpy (via superqt widgets). The current packaging of qtpy
means that 'apt install sasview' will end up installing PySide6 and Qt6
via sasview's own dependencies plus also PyQt5 and Qt5 via python3-qtpy's
dependencies.

One possible solution to this would be for src:python-qtpy to include
the following packages:

Package: python3-qtpy
Depends: python3-packaging
Contains: everything

Package: python3-qtpy-pyqt5
Depends: python3-qtpy, python3-pyqt5, python3-pyqt5.*
Contains: probably nothing

Package: python3-qtpy-pyqt6
Depends: python3-qtpy, python3-pyqt6, python3-pyqt6.*
Contains: probably nothing

Package: python3-qtpy-pyside6
Depends: python3-qtpy, python3-pyside6.*
Contains: probably nothing

Another solution is for python-qtpy to declare at most Suggests on any
of the pyqt/pyside packages and leave it to the application to declare
dependencies on the toolkit packages it needs. The application package
knows what toolkit and libraries are required while, by design, qtpy
does not. This would also provide better support for the split toolkit
packages given that Qt5 and Qt6 are modularised - the application can
depend on only what is needed rather than having all the split packages
installed just in case.

PySide6 will hit NEW soon-ish and sasview will need the updated
packaging for qtpy soon after.

I'm happy to do a Team Upload to implement whichever agreed strategy you
prefer.

thanks!
Stuart

Bug#1070214: plocate: please mark plocate "Multi-Arch: foreign"

[Alexandre Detiste]

Package: plocate
Version: 1.1.22-2
Severity: normal

Dear Maintainer,

I'm facing a weird data corruption in cruft-ng.
(test_plocate goes beyond the end of plocate's stdout)

I'd like to play with cruft-ng:i386 + plocate:adm64
combination to rule out error source.

This same change might also be usefull for other plocate users.

Greetings


tchet@quieter:~/deb/systemd-cron$ LANG=C apt rdepends plocate
plocate
Reverse Depends:
 |Recommends: catfish
 |Recommends: hollywood
  Depends: parl-desktop
  Recommends: education-common
  Depends: cruft-ng

Bug#1070150: Loading of expl3.ltx **extremely** slow on emulated runs

[Norbert Preining]

Hi all,

at Debian they got a report that loading expl3.ltx when building formats
is **extremely** slow when running under emulations:

1070...@bugs.debian.org

Running fmtutil output through ts (timestamp utility from moreutils):

May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1 branch)
May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
May 01 14:51:15 
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks,
May 01 14:51:19 document commands, control, par, spacing, files, font 
encodings, lengths,

That is 23 **minutes** to load expl3-code.tex. Ok, the file is nearly 4k
lines, but still, 23 minutes seems to be excessive.

Any ideas?

Please keep the Cc

Best regards

Norbert

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

Bug#1070213: python-oslo.privsep: please drop the obsolete python3-mock dependency

[Alexandre Detiste]

Source: python-oslo.privsep
Version: 3.3.0-2
Severity: normal

Dear Maintainers,

This project has switched to unittest.mock
from the standard library.

Greetings

tchet@quieter:/tmp/python-oslo.privsep$ grep mock -r | grep -e debian -e import
debian/control: python3-mock,
oslo_privsep/tests/test_capabilities.py:from unittest import mock
oslo_privsep/tests/test_daemon.py:from unittest import mock
oslo_privsep/tests/test_priv_context.py:from unittest import mock
tchet@quieter:/tmp/python-oslo.privsep$

Bug#1070212: python-oslo.log: please remove the extraneous python3-mock dependency

[Alexandre Detiste]

Source: python-oslo.log
Version: 5.5.1-1
Severity: normal

Dear Maintainers,

This project has switched to unittest.mock
from the standard library.

Greetings

tchet@quieter:/tmp/python-oslo.log$ grep mock -r | grep -e debian -e import
debian/control: python3-mock,
oslo_log/tests/unit/test_formatters.py:from unittest import mock
oslo_log/tests/unit/test_helpers.py:from unittest import mock
oslo_log/tests/unit/test_log.py:from unittest import mock
oslo_log/tests/unit/test_pipe_mutex.py:from unittest import mock
oslo_log/tests/unit/test_rate_limit.py:from unittest import mock
oslo_log/tests/unit/test_versionutils.py:from unittest import mock
tchet@quieter:/tmp/python-oslo.log$

Bug#1070211: ITP: krb5-wallet -- The wallet system manages secure data. It is build on top of remctl. One of the object types it supports is Kerberos keytabs, making it suitable as a user-accessible

[Bill MacAllister]

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

* Package name: krb5-wallet
  Version : 1.5
  Upstream Contact: Bill MacAllister 
* URL : https://salsa.debian.org/whm/krb5-wallet
* License : (Expat)
  Programming Lang: (C, Perl)
  Description : The wallet used remctl to manage secure data.

The wallet is a client/server system using a central server with a
supporting database and a stand-alone client that can be widely
distributed to users. The server runs on a secure host with access to
a local database; tracks object metadata such as ACLs, attributes,
history, expiration, and ownership; and has the necessary access
privileges to create wallet-managed objects in external systems (such
as Kerberos service principals). The client uses the remctl protocol
to send commands to the server, store and retrieve objects, and query
object metadata. The same client can be used for both regular user
operations and wallet administrative actions.

All wallet actions are controlled by a fine-grained set of ACLs. Each
object has an owner ACL and optional get, store, show, destroy, and
flags ACLs that control more specific actions. A global administrative
ACL controls access to administrative actions. An ACL consists of zero
or more entries, each of which is a generic scheme and identifier
pair, allowing the ACL system to be extended to use any existing
authorization infrastructure. Supported ACL types include Kerberos
principal names, regexes matching Kerberos principal names, and LDAP
attribute checks.

Currently, the object types supported are simple files, passwords,
Kerberos keytabs, and Duo integrations. By default, whenever a
Kerberos keytab object is retrieved from the wallet, the key is
changed in the Kerberos KDC and the wallet returns a keytab for the
new key. However, a keytab object can also be configured to preserve
the existing keys when retrieved. Included in the wallet distribution
is a script that can be run via remctl on an MIT Kerberos KDC to
extract the existing key for a principal, and the wallet system will
use that interface to retrieve the current key if the unchanging flag
is set on a Kerberos keytab object for MIT Kerberos. (Heimdal doesn't
require any special support.)

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Shmerl]

On Mon, 26 Feb 2024 19:53:49 +0100 Fabio Pedretti 
wrote:
> Ubuntu fixed it with this patch:
>
https://launchpadlibrarian.net/715235929/meson_1.3.2-1_1.3.2-1ubuntu1.diff.gz
>

Can this fix be added to Debian? Meson has been stuck without
moving to testing for a very long time and now it seems to be
stalling Mesa in result too.

Shmerl.

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Steev Klimaszewski]

Hi Hilmar,

On Wed, May 1, 2024 at 4:17 PM Preuße, Hilmar  wrote:
>
> On 01.05.2024 22:46, Steev Klimaszewski wrote:
>
> Hi,
>
> > May 01 14:28:46 catcodes, registers, parameters,
> > May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1
> > branch)
> > May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
> > May 01 14:51:15
> > (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks, > 
> > May 01 14:51:19 document commands, control, par, spacing, files, font
> >
> >
>
> Noticed that too, that loading this file takes quite long. In Debian
> stable (on a Rasbpi4) it are just a few seconds. In a chroot (Debian
> unstable / experimental) it takes longer, but still not the 30 minutes I
> see in your log. There is no difference between pdflatex and lualatex.
>
> H,
> --
> sigfault
Correct, when run on the same host architecture, it's fine.  The issue
comes in when running on an amd64 host, and in an arm64 chroot.  So,
e.g. running an arm64 docker container on amd64, or running an arm64
systemd-nspawn container on an amd64 host.  While, yes, qemu-user
emulation is slow (single threaded iirc?) stable takes 13 minutes to
do this, testing/unstable/experimental take significantly longer as
mentioned.

Bug#1040016: discord

[matt]

On Tue, 21 Nov 2023 08:15:09 -0600 Jeffrey Cliff  wrote:
> 1) isn't it electron based ? ie shouldn't this request depend on
> https://bugs.debian.org/842420 ?
> 2) as others have mentioned before, isn't this proprietary?
> https://en.wikipedia.org/wiki/Discord claims as such
>
> Jeff Cliff
> --
> 
> End the campaign to Cancel Richard Stallman - go to stallmansupport.org !
> 
>
> 
yes, it is proprietary, but I was thinking it could go to the non-free
repos
https://www.mattquintanilla.xyz/

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Xiyue Deng]

Currently there is a behavior difference between elpafied packages and
upstream ELPA packages on `load-path' handling: for elpafied packages,
all nested directories are added to `load-path', while for upstream ELPA
only the root directory is added.  Normally this should not be an issue,
but when trying to elpafy auctex, it's nested directory "style/"
contains many modules whose names collide with standard modules and
hence broken Eglot.  This sounds like a bad practice of the package, but
it would still be good to match upstream behavior so as to minimize
surprises.  Will try to figure this out.

-- 
Xiyue Deng

Bug#1070074: several errors on tab completion

[Gabriel F. T. Gomes]

Hi, Ivan and Alban,

Thank you very much for your reports. They certainly help me debug this large 
update.

I see two different issues:

1. Missing _comp_deprecate* functions

Bash-completion 2.12 adds a new file to /etc/bash_completion.d
(/etc/bash_completion.d/000_bash_completion_compat.bash), and this file
contains several calls to _comp_deprecate_func and _comp_deprecate_var.

These functions are only defined in version 2.12.0 of bash-completion.

I believe that the problem that Ivan reported happened after the
downgrade (from 2.12.0-1 to 2.11-8) and subsequently opening a new shell.

This happens because the downgrade does not remove the file from /etc.

I might need to move this file to a different location so that it gets
removed by downgrades.

2. New completion files requiring new function from bash_completion

This is mainly what Alban reported and the only solution I can think of
is restarting the shell or re-sourcing bash-completion.

Maybe we could have a downstream patch that provides this functions and
tells the user that they must re-source bash-completion. Providing them
as empty stubs would probably cause more harm than good, because the
calling routines would then misbehave; Copying them from the older
version could also work, but I fear that this would be a lot of work
for me.

On Tue, 30 Apr 2024 15:38:33 +0200
Alban Browaeys  wrote:

> Package: bash-completion
> Followup-For: Bug #1070074
> 
> I doubt this issue is related to util-linux-extra being too old.
> 
> I had a similar error while pressing "sudo" I got the error:
> "sudo bash: _comp_initialize : commande introuvable"
> ie "commande introuvable" is "command not found".
> 
> It turned out that this error only happens in bash shell I had opened
> before the upgrade (the fact you had the issue opening new bash shell is
> awakward to me). The bash shell I opened after were fine.
> 
> Note the _comp_deprecate_var, _comp_xxx functions are defined in 
> /usr/share/bash-completion/bash_completion
> which is part of the bash-completion package, so upgrading
> util-linux-extra can have no effect on them being present or not.
> 
> From the error I got above I guess bash completion 
> /usr/share/bash-completion/completions/*
> might get source anew after upgrade while the
> /usr/share/bash-completion/bash-completion common function definition
> file is not.
> A way to workaround this issue would be to source this file in existing
> bash shells: "source /usr/share/bash-completion/bash_completion" indeed
> fixed my shell with broken "sudo" and missing _comp_initialize
> command.
> 
> I see no easy fix as as far as I know, the 
> /usr/share/bash-completion/bash_completion
> is imported when the bash shell is started (profile file or bashrc) but it 
> seems the
> completion files can be source during the shell runtime.
> Maybe the a check at each completion files function call could be added
> to check if /usr/share/bash-completion/bash_completion has changed and
> source it when so. But this looks more like an upstream issue
> than a Debian specific topic.
> 
> NB: I still do not understand why you got the "command not found" when
> opening a new bash shell. The new
> /usr/share/bash-completion/bash_completion is source from the latest
> version at this point.
> Maybe your $HOME/.bashrc is not up to date:
> 
> /etc/skel/.bashrc: (should be in your $HOME/.bashrc)
> # If not running interactively, don't do anything
> case $- in
> *i*) ;;
>   *) return;;
> esac
> (...)
> # enable programmable completion features (you don't need to enable
> # this, if it's already enabled in /etc/bash.bashrc and /etc/profile
> # sources /etc/bash.bashrc).
> if ! shopt -oq posix; then
>   if [ -f /usr/share/bash-completion/bash_completion ]; then
> . /usr/share/bash-completion/bash_completion
>   elif [ -f /etc/bash_completion ]; then
> . /etc/bash_completion
>   fi
> fi
> 
> 
> /etc/bash.bashrc:
> # enable bash completion in interactive shells
> #if ! shopt -oq posix; then
> #  if [ -f /usr/share/bash-completion/bash_completion ]; then
> #. /usr/share/bash-completion/bash_completion
> #  elif [ -f /etc/bash_completion ]; then
> #. /etc/bash_completion
> #  fi
> #fi
> 
> or it is not imported from your $HOME/.profile which should have:
> # if running bash
> if [ -n "$BASH_VERSION" ]; then
> # include .bashrc if it exists
> if [ -f "$HOME/.bashrc" ]; then
> . "$HOME/.bashrc"
> fi
> fi
> 
> 
> but even then /etc/profile should have source the common bash completion 
> functions:
> /etc/profile:
> /etc/profile.d/bash_completion.sh
> # shellcheck shell=sh disable=SC1091,SC2166,SC2268,SC3028,SC3044,SC3054
> # Check for interactive bash and that we haven't already been sourced.
> if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a 
> "x${BASH_COMPLETION_VERSINFO-}" = x ]; then
> 
> # Check for recent enough version of bash.
> if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
> [ "${BASH_VERSINFO[0]}" -eq 4 -a 

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

[Roland Clobus]

Hello Daniel,

On 20/04/2024 13:32, Daniel Reichelt wrote:

Package: live-build
Version: git-master
Severity: normal

Hi all,

I recently built a .deb of the current master and noticed build failures like 
this:

---8<--
P: Begin copying binary includes...
/usr/lib/live/build/binary_includes: 36: cd: can't cd to config/includes.binary
E: An unexpected failure occurred, exiting...

---8<--

...since I don't have any files stored in config/includes.binary and since 
commit d14306a7, the check for the exixtence of such files is no longer 
happening.


What are you doing that makes the directory 'config/includes.binary' 
disappear?
If I use 'lb config --distribution sid', the directory is created (but 
empty) and there will be no error message.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package

[James Addison]

Source: openttd
Version: 14.0-1
Severity: serious
Tags: upstream
Justification: Policy 12.5
Control: forwarded -1 https://github.com/OpenTTD/OpenTTD/pull/12603

Dear Maintainer,

The build scripts for the initial version 14.0 release of OpenTTD include a
CMake file that determines whether and how to add compile-time flags to request
that libatomic should be linked.

The relevant CMake file addition was sourced[1] from the LLVM codebase, which
is licensed under a variant of the Apache 2.0 license with some exception
clauses added for the LLVM project.  This is not yet documented in the source
package.

I'm reporting this bug with severity 'serious' because I feel that there is
a potential licensing concern here; until that is confirmed one way or the
other, I've offered what I believe is a possible resolution (adding the LLVM
license -- slightly confusingly _also_ referred to as v14, because that is the
version of LLVM where it was introduced, despite v18 being LLVM-current), to
upstream[2].

To explain my reasoning: On balance I'd prefer opening a serious-severity bug
to prevent migration (that could later be reduced in severity) than to allow
the package transition while being aware of a potential problem.

Thanks,
James

[1] - https://github.com/OpenTTD/OpenTTD/pull/10513

[2] - https://github.com/OpenTTD/OpenTTD/pull/12603

Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)

[Petter Reinholdtsen]

Hi,

[John Paul Adrian Glaubitz 2020-05-10]
> I would like to adopt this package. There is a new upstream available and the
> repository has been moved to Github with some recent activity [1].

What came out of this intent?

I just migrated the package to a git repository on
https://salsa.debian.org/debian/unadf >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Preuße]

On 01.05.2024 22:46, Steev Klimaszewski wrote:

Hi,


May 01 14:28:46 catcodes, registers, parameters,
May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1 
branch)

May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
May 01 14:51:15 
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks, > May 01 14:51:19 document commands, control, par, spacing, files, font





Noticed that too, that loading this file takes quite long. In Debian 
stable (on a Rasbpi4) it are just a few seconds. In a chroot (Debian 
unstable / experimental) it takes longer, but still not the 30 minutes I 
see in your log. There is no difference between pdflatex and lualatex.


H,
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command

[Stefano Rivera]

Hi Manny (2024.05.01_19:47:09_+)

Please report this upstream to https://github.com/pypa/pip
This does not sound Debian-specific at all.

I can't reproduce the bug, without writing a proxy that causes a failure
like you had, which is far beyond the effort I'm willing to put in here.
You're in a much better position to advocate for this bug upstream than
I am.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/

Bug#794669: confirmed: pdebuild ignores --pbuildersatisfydepends without --use-pdebuild-internal

[Georgios Zarkadas]

Package: pbuilder
Version: 0.231 (& current git version at salsa.debian.org)

By inspecting the code of pdebuild and pdebuild-checkparams:

1. When using the '--use-pdebuild-internal' option, then
PBUILDERSATISFYDEPENDSCMD is passed explicitly
to the script that is executed inside the chroot, at line:

67  --pbuildersatisfydepends "$PBUILDERSATISFYDEPENDSCMD"

2. When not using the '--use-pdebuild-internal' option, then
the remaining command line arguments are passed to
pbuilder --build, at line:

   107  "$@" \

Those are pbuilder arguments, since pdebuild-checkparams,
by shifting all recognised by pdebuild options, eats everything
up to the '--'.

So, the '--pbuildersatisfydepends' option is not honored in the
second case. This IMHO is a bug for the 'pdebuild' man page,
since this distinction is not mentioned in the text.

This is not a bug for pbuilder, since it does not honor this option
anyway; thus passing it by pdebuild at the second case would be
meaningless. The selection of satisfydepends has been delegated
to the system administrator, through the 'pbuilder-satisfydepends'
symlink at '/usr/lib/pbuilder/'. In the usual case, the developer is also
the administrator of his/her own computer and can set the symlink.

I don't currently have an opinion on whether a more "flexible"
approach on this subject (i.e. add the feature to the second
pdebuild case also) would be desirable, or not.

Gheers,
Georgios

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Steev Klimaszewski]

On 4/30/24 11:22 PM, Norbert Preining wrote:

When running the hook with the 2023.20240207, this step takes around 3 hours.

Ouch, that hurts.


I'm guessing that this is related to enabling lua on aarch64 finally, but I'm
not familiar at all with latex and how to get the smallest possible test case to
show the issue.

If you suspect lua, then could you please run (as root or via sudo)
time fmtutil-sys --byengine luatex
time fmtutil-sys --byengine luajittex
and let us see the times there?


I've additionally piped the first command to ts as well, but forgot to 
do that while I was still logging, so here is the fmtutil-sys --byengine 
luatex | ts output:


root@sid:~# time fmtutil-sys --byengine luajittex | ts
May 01 14:26:13 fmtutil: fmtutil is using the following fmtutil.cnf 
files (in precedence order):

May 01 14:26:13 fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
May 01 14:26:13 fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
May 01 14:26:13 fmtutil: fmtutil is using the following fmtutil.cnf file 
for writing changes:

May 01 14:26:13 fmtutil:   /etc/texmf/web2c/fmtutil.cnf
May 01 14:26:13 fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
May 01 14:26:13 fmtutil [INFO]: Did not find entry for 
byengine=luajittex skipped

May 01 14:26:13 fmtutil [INFO]: not selected formats: 17
May 01 14:26:13 fmtutil [INFO]: total formats: 17
May 01 14:26:13 fmtutil [INFO]: exiting with status 0

real    0m9.009s
user    0m10.184s
sys 0m0.156s
root@sid:~# time fmtutil-sys --byengine luatex | ts
May 01 14:26:46 fmtutil: fmtutil is using the following fmtutil.cnf 
files (in precedence order):

May 01 14:26:46 fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
May 01 14:26:46 fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
May 01 14:26:46 fmtutil: fmtutil is using the following fmtutil.cnf file 
for writing changes:

May 01 14:26:46 fmtutil:   /etc/texmf/web2c/fmtutil.cnf
May 01 14:26:46 fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
May 01 14:26:46 fmtutil [INFO]: --- remaking luatex with luatex
May 01 14:26:46 fmtutil: running `luatex -ini   -jobname=luatex 
-progname=luatex luatex.ini' ...
May 01 14:26:47 This is LuaTeX, Version 1.17.0 (TeX Live 2023/Debian)  
(INITEX)

May 01 14:26:47  restricted system commands enabled.
May 01 14:26:47 
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatex.ini
May 01 14:26:47 
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatexconfig.tex

May 01 14:26:47 (/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex))
May 01 14:26:47 
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatexiniconfig.tex)
May 01 14:26:47 
(/usr/share/texlive/texmf-dist/tex/generic/unicode-data/load-unicode-data.tex

May 01 14:26:47
May 01 14:26:47 load-unicode-data.tex v1.17 (2023-09-18)
May 01 14:26:47 Reading Unicode data
May 01 14:26:47 # UnicodeData-15.1.0.txt
May 01 14:26:47 # Modified 2023-09-18 08:45:00 GMT [JAW]
May 01 14:28:20 ) 
(/usr/share/texlive/texmf-dist/tex/luatex/hyph-utf8/etex.src

May 01 14:28:20 (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
May 01 14:28:21 Preloading the plain format: codes, registers, 
parameters, fonts, more fonts,

May 01 14:28:21 macros, math definitions, output routines, hyphenation
May 01 14:28:21 (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
May 01 14:28:21 [skipping from \patterns to end-of-file...]))
May 01 14:28:21 (/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib
May 01 14:28:21 Skipping module "grouptypes"; Loading module 
"interactionmodes";

May 01 14:28:21 Skipping module "nodetypes"; Skipping module "iftypes";)
May 01 14:28:21 (/var/lib/texmf/tex/generic/config/language.def
May 01 14:28:21 
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex))

May 01 14:28:21 Augmenting the Plain TeX definitions: \tracingall;
May 01 14:28:21 Adding new e-TeX definitions: \eTeX, \loggingall, 
\tracingnone,

May 01 14:28:21 register allocation; extended register allocation;
May 01 14:28:21 Recycling: \addlanguage, \@nswer (not defined), \@sk, 
\b@dresponsetrue,
May 01 14:28:21 \b@dresponsefalse, \ch@ckforyn, \mayber@cycle, 
\et@xabort, \et@xbuf,
May 01 14:28:21 \et@xfmtsrc, \et@xfilehdr, \et@xinf, \et@xpatterns, 
\l@ngdefnfile, \n@xt,
May 01 14:28:21 \p@rse (not defined), \pr@mpt (not defined), \pr@mptloop 
(not defined),
May 01 14:28:21 \forcer@cycle, \usef@llback, \usef@llbacktrue, 
\usef@llbackfalse,
May 01 14:28:21 Retaining: \et@xerr, \et@xinput, \et@xlibhdr, \et@xmsg, 
\et@xtoks, \et@xwarn,
May 01 14:28:21 \et@xl@@d, \et@xl@ad, \et@xload, \et@xlang, \et@xhash, 
\eTeX, \etexhdrchk,

May 01 14:28:29 \etexstatus, \module, \uselanguage, \r@tain, \r@cycle,))
May 01 14:28:29 Beginning to dump on file luatex.fmt
May 01 14:28:29  (format=luatex 2024.5.1)
May 01 14:28:29 3389 strings using 10306 bytes
May 01 14:28:29 68809 memory locations dumped; current usage is 149&7701
May 01 14:28:29 1883 multiletter control sequences
May 01 14:28:29 

Bug#1060224: bluetoothd started segfaulting

[Joey Hess]

Thanks, I've tried 5.73-1 and have not been able to get it to crash so
far.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1070207: dcmtk: CVE-2024-28130

[Salvatore Bonaccorso]

Source: dcmtk
Version: 3.6.7-13
Severity: important
Tags: security upstream
Forwarded: https://support.dcmtk.org/redmine/issues/1120
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.6.7-9
Control: found -1 3.6.7-8

Hi,

The following vulnerability was published for dcmtk.

CVE-2024-28130[0]:
| An incorrect type conversion vulnerability exists in the
| DVPSSoftcopyVOI_PList::createFromImage functionality of OFFIS DCMTK
| 3.6.8. A specially crafted malformed file can lead to arbitrary code
| execution. An attacker can provide a malicious file to trigger this
| vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-28130
https://www.cve.org/CVERecord?id=CVE-2024-28130
[1] https://support.dcmtk.org/redmine/issues/1120
[2] https://talosintelligence.com/vulnerability_reports/TALOS-2024-1957
[3] 
https://github.com/DCMTK/dcmtk/commit/601b227eecaab33a3a3a11dc256d84b1a62f63af

https://github.com/DCMTK/dcmtk/commit/7d54f8efec995e5601d089fa17b0625c2b41af23

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069188: runit-services: smartmontools runscript

[Lorenzo]

Control: tags -1 moreinfo

Hi!

On Wed, 17 Apr 2024 17:17:39 +0300
"Dimitris T."  wrote:

> Package: runit-services
> Version: 0.7.1
> Severity: wishlist
> 
> Lorenzo hey,
> 
> just tried smartmontools runscript found here : 
> https://git.devuan.org/xinomilo/runscript-collection/src/branch/master/smartmontools
thanks for sharing it

> 
> [...]
>

Did you take it from void linux? (I think I saw a similar finish
file there) In any case I'm not convinced by the finish file:

#!/bin/sh 
# no devices found, disable smartd
[ $1 = 17 ] && sv d $(dirname $0)

Ok, we don't want to keep restarting if there is a permanent
failure condition, but there are others condition like this
that are not catched by [ $1 = 17 ]

I had a look at smartd(8) and found the '-q onecheck' option
and I'm using it as a test, so the runscript becomes

---
#!/usr/bin/env /lib/runit/invoke-run

sv start default-syslog || true

if ! /usr/sbin/smartd -q onecheck ; then
#no devices or other fatal problem
sv d "${PWD##*/}"
fi

exec 2>&1
if [ "$VERBOSE" = 1 ]; then
echo "Invoke-run: Starting $NAME"
fi
exec /usr/sbin/smartd -n $smartd_opts
---

and there is no need for the finish file.
Could you test if it works for you? If you have a system with
no devices suitable for smartd it should put the service down
the same way as the finish file does.

Best,
Lorenzo

> 
> thanks in advance,
> d
> 
> -- System Information:
> Distributor ID:   Devuan
> Description:  Devuan GNU/Linux 6 (excalibur/ceres)
> Release:  6
> Codename: excalibur ceres
> Architecture: x86_64
> 
> Kernel: Linux 6.8.6-3-liquorix-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
> LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
> 
> Versions of packages runit-services depends on:
> ii  runit 2.1.2-59
> ii  runit-helper  2.16.2
> 
> Versions of packages runit-services recommends:
> ii  runit-init  2.1.2-59
> 
> Versions of packages runit-services suggests:
> pn  socklog  
> 
> -- no debconf information

Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command

[Manny]

Package: python3-pip
Version: 23.0.1+dfsg-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com

This command was executed inside a venv:

===8<
$ pip install --proxy 127.0.0.1:8118 --log-file 
"$log_dir"/pip-argostranslate_install_"$(date +%F)".err --log 
"$log_dir"/pip-argostranslate_install_"$(date +%F)".log -e .
===8<

The operation failed about 150 megs into the download and dumped a
stack trace to the terminal. The "$log_dir" contained no log files.

I also used a similar command on Bullseye likely version
20.3.4-4+deb11u1 of python3-pip, without using a venv. The operation
succeeded, but the logfile was not produced. I cannot say that with
certainty though. My notes indicate that I used the --log* options,
but today the old log files are not there; and nor are the new ones. I
doubt I would have deleted the old logs, but it’s remotely
possible. In any case, certainly the bug is present in today’s
version.

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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20230311
ii  python3 3.11.2-1+b1
ii  python3-distutils   3.11.2-3
ii  python3-setuptools  66.1.1-1
ii  python3-wheel   0.38.4-2

Versions of packages python3-pip recommends:
ii  build-essential  12.9
ii  python3-dev  3.11.2-1+b1

python3-pip suggests no packages.

-- no debconf information

Bug#1070205: nut-scanner: complains about missing libnetsnmp.so

[Simon]

Package: nut-snmp
Version: 2.8.1-3.1+b1
Severity: important
X-Debbugs-Cc: simon.harh...@muenster.de

Dear Maintainer,

'nut' and 'nut-snmp' are installed. I tried to query our ups via 'nut-scanner 
-S' and got following message:
'Cannot load SNMP library (libnetsnmp.so) : file not found. SNMP search 
disabled.'
This renders nut unusable with a UPS via snmp.

But the package 'libsnmp40t64' (in sid) is installed and following files are 
present:
root@host:~# ls /usr/lib/x86_64-linux-gnu/libnetsnmp.so*
/usr/lib/x86_64-linux-gnu/libnetsnmp.so.40  
/usr/lib/x86_64-linux-gnu/libnetsnmp.so.40.2.1

With bookworm 'nut-scanner -S' works without problems.

Thanks for your work and support!
Simon

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

Kernel: Linux 6.8.4-2-pve (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C, 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 nut-snmp depends on:
ii  libc6 2.37-19
ii  libsnmp40t64  5.9.4+dfsg-1.1+b1
ii  nut-server2.8.1-3.1+b1

nut-snmp recommends no packages.

nut-snmp suggests no packages.

-- no debconf information

Bug#1021470: xsok: reproducible-builds: build path embedded in /usr/games/xsok

[Vagrant Cascadian]

Control: found 1021470 1.02-20
Control: severity 1021470 minor

On 2024-05-01, Debian Bug Tracking System wrote:
> From: Petter Reinholdtsen 
> Subject: Accepted xsok 1.02-20 (source) into unstable
...
> As far as I can tell, the latest changes to the package build system
> made the build reproducible.  I suspect it was the switching to level 13
> with default compiler flags.

Still appears to be an issue, though tests.reproducible-builds.org is no
longer testing build path variations. Downgrading the severity
accordingly.

It can be reproduced using reprotest manually, or possibly by enabling
salsa-ci pipelines, or building twice with sbuild, which currently
randomizes the build path by default.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1070204: gnome-boxes: Missing dependency on qemu-utils and libvirt-clients

[inasprecali]

Package: gnome-boxes
Version: 43.2-1
Severity: important
X-Debbugs-Cc: inasprec...@disroot.org

Dear Maintainer,

The problem is present on the gnome-boxes pacakge distributed in
the current Debian stable branch, Bullseye.  When creating a new
virtual machine with the "+" button on the upper left corner,
GNOME Boxes was hanging on the "Review and Create" menu, without
showing anything inside the popup window.

On a terminal, I saw the following messages:

Boxes-Message: 20:12:50.764: libvirt-machine.vala:268: Failed to connection to 
system libvirt: Unable to open qemu+unix:///system: Failed to connect socket to 
'/var/run/libvirt/libvirt-sock-ro': No such file or directory

(gnome-boxes:8952): GLib-GObject-WARNING **: 20:12:50.820: 
../../../gobject/gsignal.c:2722: handler '2749' of instance '0x561b3992a600' is 
not blocked

(gnome-boxes:8952): Boxes-WARNING **: 20:12:56.637: review-page.vala:44: Box 
setup failed: Failed to create volume: internal error: creation of non-raw file 
images is not supported without qemu-img.

(gnome-boxes:8952): Boxes-CRITICAL **: 20:12:56.637: 
boxes_assistant_review_page_populate: assertion 'machine != NULL' failed

I then installed the qemu-utils package, which contains the qemu-img command,
and the problem went away, with GNOME Boxes now proceeding on the
"Review and Create" menu and showing the options to select how much RAM and
disk space to allocate for the new virtual machine.

However, I also saw a message on the popup window, containing the following
text: "Virtualization extensions are unavailable on your system. Check your
BIOS settings to enable them.".  I found this odd, as I double checked that
I indeed had virtualization support enabled in my BIOS.

On the terminal, I saw the following messages:

libvirt-machine.vala:268: Failed to connection to system libvirt: Unable to 
open qemu+unix:///system: Failed to connect socket to 
'/var/run/libvirt/libvirt-sock-ro': No such file or directory

(gnome-boxes:5406): GLib-GObject-WARNING **: 20:23:34.328: 
../../../gobject/gsignal.c:2722: handler '2748' of instance '0x55a59ef865c0' is 
not blocked

(gnome-boxes:5406): Boxes-WARNING **: 20:23:40.894: util-app.vala:442: Failed 
to execute child process ?virsh? (No such file or directory)

I then installed the package libvirt-clients, which contains the virsh
command, and this problem too went away.

>From my observation, it seems that the gnome-boxes package should depend
(or at least recommend) the qemu-utils and libvirt-clients packages.
At the moment, gnome-boxes in Bullseye has no dependency on
either package, not "Depends", not "Recommends" and not "Suggests" either.

Since creating virtual machines is, in my opinion, an important feature
for a graphical frontend to virtualization software, I think gnome-boxes
should at least have a "Recommends" dependency on both libvirt-clients
and qemu-utils, if not a mandatory "Depends" relationship.

This is partially addressed in the testing branch (Trixie): there,
gnome-boxes does have a "Depends" on libvirt-clients, but still no
dependency of any kind on qemu-utils.

Thank you for your attention.

-- System Information:
Debian Release: 12.5
  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-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  genisoimage  9:1.1.11-3.4
ii  libarchive13 3.6.2-1
ii  libc62.36-9+deb12u6
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgudev-1.0-0   237-2
ii  libhandy-1-0 1.8.1-1
ii  libosinfo-1.0-0  1.10.0-2
ii  libosinfo-bin1.10.0-2
ii  libsecret-1-00.20.5-3
ii  libsoup-3.0-03.2.2-2
ii  libspice-client-glib-2.0-8   0.42-1
ii  libspice-client-gtk-3.0-50.42-1
ii  libtracker-sparql-3.0-0  3.4.2-1
ii  libusb-1.0-0 2:1.0.26-1
ii  libvirt-daemon   9.0.0-4
ii  libvirt-glib-1.0-0   4.0.0-2
ii  libwebkit2gtk-4.1-0  2.42.5-1~deb12u1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  tracker   

Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)

[Manny]

Package: python3-pip
Version: 23.0.1+dfsg-1
Severity: normal
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com

In Bullseye, an app was installed as follows:

===8<
  $ torsocks pip3 install argostranslate
  $ torsocks pip3 install --log-file $logs_dir/pip3-argostranslategui.err --log 
$logs_dir/pip3-argostranslategui.log --cache-dir /usr/local/tarballs 
argostranslategui
  $ torsocks argospm install translate-${lang1}_$lang2
===8<

It ran fine. Then an update to the latest Bullseye point release was
performed, followed immediately with an “aptitude full-upgrade”. A
full log of the upgrade was not kept, but I did note this conflict:

===8<
python3-virtualenv : Depends: python3-pip-whl but it is not going to be 
installed
 Depends: python3-setuptools-whl but it is not going to be 
installed
===8<

It’s probably irrelevant because aptitude’s resolution resulted in a
functioning python/pip - but worth mentioning in case it matters. An
attempt to execute the app after the upgrade to Bookworm went like
this:

===8<
  $ /usr/local/bin/argos-translate -v
  Traceback (most recent call last):
File "/usr/local/bin/argos-translate", line 3, in 
  from argostranslate import cli
  ModuleNotFoundError: No module named 'argostranslate'

  $ pip3 list | grep -i argo
  (no output)
  $ pip list | grep -i argo
  (no output)
===8<

It’s also a bug for pip3 to have lost track of the fact that it
managed the app. Running “pip3 list” should reveal the existence of
the app.

I’m told it would have been wise to have installed the app in a
virtual environment not in the system (likely accurate). But
nonetheless a needed app module should never be silently dropped
without informing the user in the very least. If a needed module
needed to be scrapped for some reason, ideally a signal would be sent
to the apt procedure to block the upgrade and inform the user of steps
needed.

Recapping, I see four bugs:
① (upstream) an app module was dropped/lost
② (upstream) the user was not informed about the loss
③ (debian) the anomaly failed to block aptitude from moving forward
④ (upstream) pip3 lost track of the fact it was managing the app

I did not apply the upstream tag because bug 3 above is debian
related. But this report should probably be seen by upstream devs as
well.

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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20230311
ii  python3 3.11.2-1+b1
ii  python3-distutils   3.11.2-3
ii  python3-setuptools  66.1.1-1
ii  python3-wheel   0.38.4-2

Versions of packages python3-pip recommends:
ii  build-essential  12.9
ii  python3-dev  3.11.2-1+b1

python3-pip suggests no packages.

-- no debconf information

Bug#1070202: RM: rust-atk-sys/experimental -- ROM; RoM; unmaintained library

[Matthias Geiger]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: werdah...@riseup.net
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I uploaded an experimental version some time ago that wasn't picked up
by dak apperantly when it was removing it from unstable.

Please remove that version too.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYylOcVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1v10P/0mU1wKvJWR8YoKiNUMxENOAaSuA
ek/oI1K523ENvG3r/z4W6PimJP5dxnCs43J137AYQZSuKb0vk4eL4CTvTHXdWY+f
oraBEDArFjCEgKQK26Ir7Ht0UKTDPpNJrXW8Gt29ArPHtZ4di6yms6Gs0gjob59l
PfpsUcebuko9HHu5l5ADpVo7irVE6sHwxUJmLHkDgQ4hNrAUlJrS20G/TdIo6wN+
y95BEjY3KM1ckTsHUzkHuO9jhHZVhTmA2ih8koW1nk7UI2/AOnT4eQyH6dChMjKR
aT3UKiNbwtOz+sKQxYCJ5cXJlcXudbPmWC4qcxjQhwNqaSHfadjUphCnbBxczu5j
0YrmM0vixNarEBidzVkCxdRpIMNdT7IJDRlu6hNns+cq94lPz7pcg8JnPE/dqSrw
w0Fx6hzSA9LbnD02DalJgHGL5AEElkVC6D3NPD4PtXlJzAz28BGWOequHk8ncG5W
EnNI/ADihFJUiFPeqyrdIuNl43rRMXiDvjeDqwSKv3aGdFIEdqQbDYT7rPTWRCkr
G9LKcb50ocxvrUaymkuS/XsDn0dwiCm26md4v3SbfHhAq7vEkKGXLIKMczFtuV7B
aGJ7LW6X/7m8fGzdAUU/3yr4JJ2pvJs+jo/psA5VWOGmlCVA6/i/46yDyM9ydu+S
2At0DG/Yl4DA8Wm9
=Sxom
-END PGP SIGNATURE-

Bug#1070015: haskel-pandoc: FTBFS on armel: Couldn't match expected type: WriterState -> m a

[Ilias Tsitsimpis]

On Sun, Apr 28, 2024 at 05:14PM, Sebastian Ramacher wrote:
> https://buildd.debian.org/status/fetch.php?pkg=haskell-pandoc=armel=3.1.3-1%2Bb1=1713911741=0

I have been trying to understand what is wrong, but haven't found
anything. My best guess right now is that this is a GHC bug that
manifests due to the time64 transition.

Oddly enough, if we run 'build' again it succeeds.

My course of action for now is:
  * Upload a workaround for haskell-pandoc that runs 'build' twice, so
we can finish with this transition
  * Upgrade to GHC 9.6 with the next transition, with the hope that this
bug is fixed there
  * If not, report this upstream

-- 
Ilias

Bug#1070201: scikit-learn: autopkgtest regression on i386 with NumPy 1.26

[Graham Inggs]

Source: scikit-learn
Version: 1.4.1.post1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

scikit-learn's autopkgtest regresses on i386 when tested with numpy
1.26 [1].  I've copied what I hope is the relevant part of the log
below.

Regards
Graham


[1] https://ci.debian.net/packages/s/scikit-learn/testing/i386/


1386s === FAILURES
===
35104
1386s __ test_graphviz_toy
___
35105
1386s
35106
1386s def test_graphviz_toy():
35107
1386s # Check correctness of export_graphviz
35108
1386s clf = DecisionTreeClassifier(
35109
1386s max_depth=3, min_samples_split=2, criterion="gini", random_state=2
35110
1386s )
35111
1386s clf.fit(X, y)
35112
1386s
35113
1386s # Test export code
35114
1386s contents1 = export_graphviz(clf, out_file=None)
35115
1386s contents2 = (
35116
1386s "digraph Tree {\n"
35117
1386s 'node [shape=box, fontname="helvetica"] ;\n'
35118
1386s 'edge [fontname="helvetica"] ;\n'
35119
1386s '0 [label="x[0] <= 0.0\\ngini = 0.5\\nsamples = 6\\n'
35120
1386s 'value = [3, 3]"] ;\n'
35121
1386s '1 [label="gini = 0.0\\nsamples = 3\\nvalue = [3, 0]"] ;\n'
35122
1386s "0 -> 1 [labeldistance=2.5, labelangle=45, "
35123
1386s 'headlabel="True"] ;\n'
35124
1386s '2 [label="gini = 0.0\\nsamples = 3\\nvalue = [0, 3]"] ;\n'
35125
1386s "0 -> 2 [labeldistance=2.5, labelangle=-45, "
35126
1386s 'headlabel="False"] ;\n'
35127
1386s "}"
35128
1386s )
35129
1386s
35130
1386s assert contents1 == contents2
35131
1386s
35132
1386s # Test plot_options
35133
1386s contents1 = export_graphviz(
35134
1386s clf,
35135
1386s filled=True,
35136
1386s impurity=False,
35137
1386s proportion=True,
35138
1386s special_characters=True,
35139
1386s rounded=True,
35140
1386s out_file=None,
35141
1386s fontname="sans",
35142
1386s )
35143
1386s contents2 = (
35144
1386s "digraph Tree {\n"
35145
1386s 'node [shape=box, style="filled, rounded", color="black", '
35146
1386s 'fontname="sans"] ;\n'
35147
1386s 'edge [fontname="sans"] ;\n'
35148
1386s "0 [label=0  0.0samples = 100.0%"
35149
1386s 'value = [0.5, 0.5]>, fillcolor="#ff"] ;\n'
35150
1386s "1 [label=value = [1.0, 0.0]>, "
35151
1386s 'fillcolor="#e58139"] ;\n'
35152
1386s "0 -> 1 [labeldistance=2.5, labelangle=45, "
35153
1386s 'headlabel="True"] ;\n'
35154
1386s "2 [label=value = [0.0, 1.0]>, "
35155
1386s 'fillcolor="#399de5"] ;\n'
35156
1386s "0 -> 2 [labeldistance=2.5, labelangle=-45, "
35157
1386s 'headlabel="False"] ;\n'
35158
1386s "}"
35159
1386s )
35160
1386s
35161
1386s assert contents1 == contents2
35162
1386s
35163
1386s # Test max_depth
35164
1386s contents1 = export_graphviz(clf, max_depth=0, class_names=True,
out_file=None)
35165
1386s contents2 = (
35166
1386s "digraph Tree {\n"
35167
1386s 'node [shape=box, fontname="helvetica"] ;\n'
35168
1386s 'edge [fontname="helvetica"] ;\n'
35169
1386s '0 [label="x[0] <= 0.0\\ngini = 0.5\\nsamples = 6\\n'
35170
1386s 'value = [3, 3]\\nclass = y[0]"] ;\n'
35171
1386s '1 [label="(...)"] ;\n'
35172
1386s "0 -> 1 ;\n"
35173
1386s '2 [label="(...)"] ;\n'
35174
1386s "0 -> 2 ;\n"
35175
1386s "}"
35176
1386s )
35177
1386s
35178
1386s assert contents1 == contents2
35179
1386s
35180
1386s # Test max_depth with plot_options
35181
1386s contents1 = export_graphviz(
35182
1386s clf, max_depth=0, filled=True, out_file=None, node_ids=True
35183
1386s )
35184
1386s contents2 = (
35185
1386s "digraph Tree {\n"
35186
1386s 'node [shape=box, style="filled", color="black", '
35187
1386s 'fontname="helvetica"] ;\n'
35188
1386s 'edge [fontname="helvetica"] ;\n'
35189
1386s '0 [label="node #0\\nx[0] <= 0.0\\ngini = 0.5\\n'
35190
1386s 'samples = 6\\nvalue = [3, 3]", fillcolor="#ff"] ;\n'
35191
1386s '1 [label="(...)", fillcolor="#C0C0C0"] ;\n'
35192
1386s "0 -> 1 ;\n"
35193
1386s '2 [label="(...)", fillcolor="#C0C0C0"] ;\n'
35194
1386s "0 -> 2 ;\n"
35195
1386s "}"
35196
1386s )
35197
1386s
35198
1386s assert contents1 == contents2
35199
1386s
35200
1386s # Test multi-output with weighted samples
35201
1386s clf = DecisionTreeClassifier(
35202
1386s max_depth=2, min_samples_split=2, criterion="gini", random_state=2
35203
1386s )
35204
1386s clf = clf.fit(X, y2, sample_weight=w)
35205
1386s
35206
1386s > contents1 = export_graphviz(clf, filled=True, impurity=False,
out_file=None)
35207
1386s
35208
1386s /usr/lib/python3/dist-packages/sklearn/tree/tests/test_export.py:131:
35209
1386s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _
35210
1386s /usr/lib/python3/dist-packages/sklearn/utils/_param_validation.py:213:
in wrapper
35211
1386s return func(*args, **kwargs)
35212
1386s /usr/lib/python3/dist-packages/sklearn/tree/_export.py:906: in
export_graphviz
35213
1386s exporter.export(decision_tree)
35214
1386s /usr/lib/python3/dist-packages/sklearn/tree/_export.py:466: in export
35215
1386s self.recurse(decision_tree.tree_, 0, 

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Richard Lewis]

On Wed, 1 May 2024, 00:57 Vincent Lefevre,  wrote:

> On 2024-05-01 01:29:10 +0200, Vincent Lefevre wrote:
> > For instance, /var/log/chkrootkit/log.expected contains
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > But /var/log/chkrootkit/log.today currently has a duplicate line:
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > which has the effect to generate an alert.
>
> This is actually due to the filter in /etc/chkrootkit/chkrootkit.conf,
> which obfuscates the output.
>
> The unfiltered output:
>
> lo: not promisc and no packet sniffer sockets
> eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1261])
> wlp0s20f3: PACKET SNIFFER(/usr/sbin/NetworkManager[1261],
> /usr/sbin/wpa_supplicant[1263])
>
> But for a laptop, there is not always an Ethernet cable plugged in.
>
> IMHO, known packet sniffers should be filtered out.
>

I agree that you should be able to filter out duplicate lines. And i think
this is possible with a  custom filter.


I dont think it should be the default - most chkrootkit users have a more
static network setup, and the alert shows something has changed. For
laptops where networking is more dynamic it's hard to design something that
works for everyone without also hiding information for other people.

I think the defaults need to be conservative, while allowing people to hide
what they want.

Maybe the best solution is to provide more docs/examples about how to hide
duplicate lines.

Bug#1070200: ejabberd: Please package 24.02

[Martin Dosch]

Source: ejabberd
Version: 23.01-1
Severity: wishlist

Dear Maintainer,

please consider packaging 24.02 (if possible it would be great if you'd 
also backport it to bookworm).
Ejabberd < 24.02 has an issue with channel binding and TLSv1.3. When 
using channel binding (e.g. SCRAM mechanism SCRAM-SHA-1-PLUS) with 
TLSv1.3 tls-exporter must be used but ejabberd < 24.02 uses tls-unique 
(which should only be used for < TLSv1.3). [1]

Due to the recent MITM on jabber.ru many clients and servers have 
enabled SCRAM mechanisms with channel binding to mitigate MITM attacks. 
But due to the linked issue authenticating will fail when using a SCRAM 
mechanism with channel binding and TLSv1.3, therefore it would be 
awesome if Debian would provide ejabberd 24.02 and enable ejabberd 
operators using Debian to upgrade to a fixed version.

Best regards,
Martin

[1] https://github.com/processone/ejabberd/issues/4105

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

Kernel: Linux 6.1.0-20-amd64 (SMP w/4 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


signature.asc
Description: PGP signature

Bug#1070175: RM: salt/3002.6+dfsg1-4+deb11u1

[Adam D. Barratt]

On Wed, 2024-05-01 at 19:46 +0200, Moritz Muehlenhoff wrote:
> On Wed, May 01, 2024 at 06:29:29PM +0100, Adam D. Barratt wrote:
> > On Wed, 2024-05-01 at 13:02 +0200, Moritz Muehlenhoff wrote:
> > > Please remove salt in the next Bullseye point release.
> > > It was already removed frm unstable for being unsupportable
> > > and unmaintained (https:://bugs.debian.org/1069654).
> > > 
> > > There are two related packages which need to be removed
> > > alongside, since salt-common depends on them (but which
> > > have no other dependencies outside of salt):
> > > 
> > > pytest-salt-factories 0.93.0-1
> > > pytest-testinfra 6.1.0-1
> > 
> > I'm not doubting whether at least the former should be removed, but
> > "salt-common depends on them" isn't a reason to remove things in
> > itself. A relationship in the opposite direction certainly would be
> > (i.e. "they depend on salt-common").
> 
> It's actually build dependencies, both pytest-salt-factories and
> pytest-testinfra build depend on salt-common.

Ah, that makes more sense. Thanks for the clarification.

Regards,

Adam

Bug#1070175: RM: salt/3002.6+dfsg1-4+deb11u1

[Moritz Muehlenhoff]

On Wed, May 01, 2024 at 06:29:29PM +0100, Adam D. Barratt wrote:
> On Wed, 2024-05-01 at 13:02 +0200, Moritz Muehlenhoff wrote:
> > Please remove salt in the next Bullseye point release.
> > It was already removed frm unstable for being unsupportable
> > and unmaintained (https:://bugs.debian.org/1069654).
> > 
> > There are two related packages which need to be removed
> > alongside, since salt-common depends on them (but which
> > have no other dependencies outside of salt):
> > 
> > pytest-salt-factories 0.93.0-1
> > pytest-testinfra 6.1.0-1
> 
> I'm not doubting whether at least the former should be removed, but
> "salt-common depends on them" isn't a reason to remove things in
> itself. A relationship in the opposite direction certainly would be
> (i.e. "they depend on salt-common").

It's actually build dependencies, both pytest-salt-factories and
pytest-testinfra build depend on salt-common.

Cheers,
Moritz

Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/

[Mark Hindley]

On Wed, May 01, 2024 at 07:10:29PM +0200, Lorenzo wrote:
> > Thanks. Does the attached patch help?
> 
> yes, it seems it works

Good.

As small refinement to avoid emitting inappropriate dangling symlink warnings.

Mark
>From 07d2dd72221e961637ea7a9cd2143b6c8a411373 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 1 May 2024 18:33:39 +0100
Subject: [PATCH] Don't emit dangling symlink warning for non-executable
 scripts.

---
 debian/openrc.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 3b62f026..e53be30c 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -37,8 +37,8 @@ if [ "${1}" = "configure" ] ; then
 echo "*** WARNING: skipping non-executable $rclink"
 			else
 echo "*** WARNING: dangling link $rclink"
+				echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
 			fi
-			echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
 			fi
 		done
 	done
-- 
2.39.2

Bug#1070175: RM: salt/3002.6+dfsg1-4+deb11u1

[Adam D. Barratt]

On Wed, 2024-05-01 at 13:02 +0200, Moritz Muehlenhoff wrote:
> Please remove salt in the next Bullseye point release.
> It was already removed frm unstable for being unsupportable
> and unmaintained (https:://bugs.debian.org/1069654).
> 
> There are two related packages which need to be removed
> alongside, since salt-common depends on them (but which
> have no other dependencies outside of salt):
> 
> pytest-salt-factories 0.93.0-1
> pytest-testinfra 6.1.0-1

I'm not doubting whether at least the former should be removed, but
"salt-common depends on them" isn't a reason to remove things in
itself. A relationship in the opposite direction certainly would be
(i.e. "they depend on salt-common").

Regards,

Adam

Bug#1070197: debsign: Ensure future GnuPG interop by forcing OpenPGP compliant behavior

[Guillem Jover]

Package: devscripts
Version: 2.23.7
Severity: wishlist
Tags: patch
X-Debbugs-Cc: Daniel Kahn Gillmor 

Hi!

GnuPG upstream has decided to get out of the standardizing process for
OpenPGP, and instead is trying to push its own proprietary fork based on
an old draft that did not have consensus within the IETF working group.

This is going to be a source of interoperability problems, but we can
mitigate them somewhat when creating signatures by requiring compliance
with the OpenPGP RFC, even if it's going to be locked into an old version,
as later ones are not planned to get implemented. More so, given that the
latest releases of GnuPG have been switched to default to the proprietary
draft.

We need to set secure signing preferred algorithms as the current GnuPG
defaults with --openpgp cater for heavy backwards compatibility at the
cost of being insecure but potentially being compatible with very old
programs.

We care more about secure defaults than backwards compatibility with
ancient programs, so we pass our preferences to gpg when signing. This
should also cover the case for users that have created old keys with
insecure key preferences which might end up producing insecure
signatures.

Equivalent changes were made to dpkg-buildpackage.

Attached the patch implementing this.

(Ideally debsign would also grow additional OpenPGP backends, like
dpkg did, or perhaps it could be replaced entirely with the upcoming
dpkg-sign program.)

Thanks,
Guillem
From 14fd5d300f4cf9188d09aed356cc348d3d5c49fa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 27 Apr 2024 20:33:05 +0200
Subject: [PATCH] debsign: Ensure future GnuPG interop by forcing OpenPGP
 compliant behavior

GnuPG upstream has decided to get out of the standardizing process for
OpenPGP, and instead is trying to push its own proprietary fork based on
an old draft that did not have consensus within the IETF working group.

This is going to be a source of interoperability problems, but we can
mitigate them somewhat when creating signatures by requiring compliance
with the OpenPGP RFC, even if it's going to be locked into an old version,
as later ones are not planned to get implemented. More so, given that the
latest releases of GnuPG have been switched to default to the proprietary
draft.

We need to set secure signing preferred algorithms as the current GnuPG
defaults with --openpgp cater for heavy backwards compatibility at the
cost of being insecure but potentially being compatible with very old
programs.

We care more about secure defaults than backwards compatibility with
ancient programs, so we pass our preferences to gpg when signing. This
should also cover the case for users that have created old keys with
insecure key preferences which might end up producing insecure
signatures.

Equivalent changes were made to dpkg-buildpackage.
---
 scripts/debsign.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/debsign.sh b/scripts/debsign.sh
index 15b0dfc2..bc894b18 100755
--- a/scripts/debsign.sh
+++ b/scripts/debsign.sh
@@ -178,6 +178,8 @@ signfile() {
 then
 	$signcommand --no-auto-check-trustdb \
 		--local-user "$signas" --clearsign \
+		--openpgp \
+		--personal-digest-preferences 'SHA512 SHA384 SHA256 SHA224' \
 		--list-options no-show-policy-urls \
 		--armor --textmode --output "$ASCII_SIGNED_FILE"\
 		"$UNSIGNED_FILE" || \
@@ -188,6 +190,8 @@ signfile() {
 	}
 else
 	$signcommand --local-user "$signas" --clearsign \
+		--openpgp \
+		--personal-digest-preferences 'SHA512 SHA384 SHA256 SHA224' \
 		--no-show-policy-url \
 		--armor --textmode --output "$ASCII_SIGNED_FILE" \
 		"$UNSIGNED_FILE" || \
-- 
2.43.0

Bug#1069557: libkdumpfile: FTBFS on armel: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2

[Michel Lind]

Hi Lucas,

On 4/20/24 8:23 AM, Lucas Nussbaum wrote:

Source: libkdumpfile
Version: 0.5.4-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel

Hi,

During a rebuild of all packages in sid, your package failed to build
on armel.
Thanks for filing. I've notified upstream: 
https://github.com/ptesarik/libkdumpfile/issues/80


and will try and reproduce and fix this.

Best regards,

--
 _o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


OpenPGP_0x8B229D2F7CCC04F2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070196: opendmarc: Reconfiguring opendmarc does not provide a running mysql server

[freek]

Package: opendmarc
Version: 1.4.2-2+b1
Severity: important
X-Debbugs-Cc: f.de.kru...@gmail.com

Dear Maintainer,


   * What led up to the situation?
   Installation of opendmarc using:
   DEBIAN_FRONTEND=noninteractive apt-get install -yqq opendmarc
   Executing:
   dkpg-reconfigure opendmarc
   Reinstall database for opendmarc? Answer: Yes
   Connection method for MySQL database of opendmarc: Chosen: TCP/IP
   Host name of the MySQL database server for opendmarc: Chosen: localhost
   Port number for the MySQL service: Default: 3306
   Authentication plugin for MySQL database: Chosen: default
   MySQL database name for opendmarc: Chosen: opendmarc
   MySQL username for opendmarc: Chosen: opendmarc@localhost
   MySQL application password for opendmarc: Entered password (hidden)
   Password confirmation: Entered same password
   Name of the database's administrative user: Left to be root
   Password of the database's administrative user: Above password entered
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Output was:
 An error occurred while installing the database:
 ERROR 2002 (HY000): Can't connect to local server through socket 
'/run/mysqld/mysqld.sock' (2) .
   Followed by a choice. Tried several but resulted never in an active mysql 
server
   * What was the outcome of this action?
   See above
   * What outcome did you expect instead?
   A running mysql server with a socket or active port 3306.



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

Kernel: Linux 6.6.20+rpt-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages opendmarc depends on:
ii  adduser3.134
ii  dbconfig-mysql 2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-2
ii  libc6  2.36-9+rpt2+deb12u4
ii  libmilter1.0.1 8.17.1.9-2
ii  libopendmarc2  1.4.2-2+b1
ii  publicsuffix   20230209.2326-1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.050-5+b1
ii  libdbi-perl   1.643-4
ii  libhttp-message-perl  6.44-1
ii  libjson-perl  4.1-1
ii  libopendbx1   1.4.6-16+b1
ii  libopendbx1-mysql 1.4.6-16+b1
ii  libswitch-perl2.17-3
ii  perl  5.36.0-7+deb12u1

Versions of packages opendmarc suggests:
pn  libmime-tools-perl  
pn  libxml-simple-perl  
pn  python  
pn  python-mysqldb  

-- debconf information:
  opendmarc/mysql/app-pass: (password omitted)
  opendmarc/mysql/admin-pass: (password omitted)
  opendmarc/password-confirm: (password omitted)
  opendmarc/app-password-confirm: (password omitted)
  opendmarc/internal/reconfiguring: false
  opendmarc/internal/skip-preseed: false
  opendmarc/dbconfig-reinstall: false
  opendmarc/passwords-do-not-match:
  opendmarc/purge: false
  opendmarc/remote/host: localhost
  opendmarc/remove-error: abort
  opendmarc/install-error: abort
  opendmarc/mysql/authplugin: default
  opendmarc/db/dbname: opendmarc
  opendmarc/db/app-user: opendmarc@localhost
  opendmarc/database-type: mysql
  opendmarc/dbconfig-remove: true
  opendmarc/dbconfig-install: true
  opendmarc/mysql/method: Unix socket
  opendmarc/upgrade-backup: true
  opendmarc/upgrade-error: abort
  opendmarc/remote/port:
  opendmarc/mysql/admin-user: root
  opendmarc/missing-db-package-error: abort
  opendmarc/dbconfig-upgrade: true
  opendmarc/remote/newhost:

Bug#1070161: ITS: ramond

[Boyuan Yang]

Hi,


On Wed, 2024-05-01 at 07:57 +0200, Nicolas Dandrimont wrote:
> On Wed, May 1, 2024, at 04:50, Boyuan Yang wrote:
> > Source: ramond
> > Version: 0.5-4.2
> > Severity: important
> > Tags: sid trixie
> > X-Debbugs-CC: nicolas.dandrim...@crans.org
> > 
> > Dear package ramond maintainer in Debian,
> > 
> > After looking into the package you maintain (ramond, 
> > https://tracker.debian.org/pkg/ramond), I found that this package
> > received no maintainer updates in the past 12 years and is not in
> > good
> > shape. As a result, I am filing an ITS (Intent to Salvage) request
> > against your package to take over package maintenance according to
> > section 5.12 in Debian's Developers' Reference [1].
> > 
> > [...]
> 
> Hi,
> 
> Thank you for picking up this package. You should feel free to go ahead
> with immediate adoption[1].
> 
> [1] https://wiki.debian.org/LowThresholdAdoption
> 
> In this day and age, most managed switches are able to block unwanted
> IPv6 router advertisements, so before spending much effort on a project
> that, last I checked, was dormant upstream, you should assess whether
> ramond is still relevant.

Thanks, I am making the upload with fixes.

Best,
Boyuan


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

Bug#1070195: glib2.0: test failure with pcre2/10.43: asserts that a variable-length lookbehind is an error

[Matthew Vernon]

Hi,

On 01/05/2024 17:29, Simon McVittie wrote:


Matthew, if pcre2 (>= 10.43) isn't urgent, please don't upload it to
unstable until after this glib2.0 bug has been fixed (and ideally also
migrated to testing).


Thanks for looking into this! I'm happy to hold off on a pcre2 upload to 
unstable until this has happened.


Regards,

Matthew

Bug#1070195: glib2.0: test failure with pcre2/10.43: asserts that a variable-length lookbehind is an error

[Simon McVittie]

Source: glib2.0
Version: 2.78.4-7
Severity: important
Tags: ftbfs trixie sid patch upstream fixed-upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3945
X-Debbugs-Cc: Matthew Vernon 
Control: fixed -1 2.80.0-7

GLib contains GRegex, an API wrapper around pcre2 (or pcre in older GLib
branches).

Because variable-length lookbehind was historically not allowed, its test
suite includes a test that asserts that these two regexes:

(?= 10.43) isn't urgent, please don't upload it to
unstable until after this glib2.0 bug has been fixed (and ideally also
migrated to testing).

Unfortunately my understanding of the time64 situation is that further
package migrations are stalled because they cause the testing migration
scripts to crash (see #1070121). I would prefer to avoid significant
non-urgent changes in unstable until more of the time64 migration can
be forced through by the release team.

Thanks,
smcv

Bug#825264: umlet: Please update umlet to the newest upstream version

[Olivier Berger]

Hi.

AFAIU, in the meantime, the javaparser package may no longer be an issue... see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820471#19

Any possible update on recent versions of umlet ?

Thanks in advance.

Best regards,

Le Thu, May 26, 2016 at 06:55:42PM +0200, Benjamin Mesing a écrit :
> Hi Peter,
> 
> unfortunately the new version of umlet requires a new version of
> javaparser, which I will not have sufficient time to package. There is
> a request open for help for this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820471
> Until someone steps in to help, umlet will not be updated. This may
> take months or even years. So your best option for now, is probably to
> download the latest release from umlet.com
> 
> Best regards
> 
> Ben
> 
> 
> On Wed, 2016-05-25 at 11:37 +0200, Peter Spiess-Knafl wrote:
> > Package: umlet
> > Version: 13.3-1
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > could you please update umlet to the latest upstream version?
> > 
> > Greetings
> > Peter
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: stretch/sid
> >   APT prefers testing
> >   APT policy: (900, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages umlet depends on:
> > ii  default-jdk [java6-sdk] 2:1.8-57
> > ii  default-jre [java7-runtime] 2:1.8-57
> > ii  jarwrapper  0.55
> > ii  libautocomplete-java2.5.0-1
> > ii  libbatik-java   1.8-3
> > ii  libecj-java 3.10.1-2
> > ii  libfop-java 1:2.1-3
> > ii  libgnumail-java 1.1.2-10
> > ii  libitext5-java  5.5.6-2
> > ii  libjavaparser-java  1.0.8-1
> > ii  libjlibeps-java 0.1+2-2
> > ii  libjsyntaxpane-java 0.9.6~r156-6
> > ii  liblog4j1.2-java1.2.17-7
> > ii  librsyntaxtextarea-java 2.5.0-1
> > ii  openjdk-8-jdk [java6-sdk]   8u77-b03-3+b1
> > ii  openjdk-8-jre [java7-runtime]   8u77-b03-3+b1
> > ii  oracle-java8-installer [java7-runtime]  8u72+8u71arm-1~webupd8~0
> > 
> > umlet recommends no packages.
> > 
> > umlet suggests no packages.
> > 
> > -- no debconf information

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#1070194: Please package new upstream version

[Jakob Haufe]

Package: ansible-lint
Version: 6.17.2-1
Severity: wishlist

Dear maintainers of ansible-lint,

ansible-lint has had several upstream releases which include various bug
fixes. It would be nice to have those in Debian as well.

Cheers,
sur5r

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

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

Versions of packages ansible-lint depends on:
ii  ansible-core2.16.6-1
ii  black   24.4.0-2
ii  git 1:2.43.0-1
ii  python3 3.11.8-1
ii  python3-ansible-compat  4.1.12-1
ii  python3-filelock3.13.4-1
ii  python3-jinja2  3.1.3-1
ii  python3-jsonschema  4.19.2-2
ii  python3-packaging   24.0-1
ii  python3-pathspec0.12.1-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-rich13.7.1-1
ii  python3-ruamel.yaml 0.17.21-1
ii  python3-subprocess-tee  0.4.1-1
ii  python3-wcmatch 8.5.1-1
ii  python3-yaml6.0.1-2
ii  yamllint1.33.0-1

ansible-lint recommends no packages.

ansible-lint suggests no packages.

-- no debconf information


-- 
ceterum censeo microsoftem esse delendam.


pgpS9X8WsHAKc.pgp
Description: OpenPGP digital signature

Bug#1060224: bluetoothd started segfaulting

[Bernhard Übelacker]

Hello,
I am just trying to get the source line from the dmesg code line.



[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 
f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 
8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08



And it points to function a2dp_suspend_complete, [transport.c:431].

This function leads to upstream report [701],
which should be fixed since release 5.72 [83cfad1].

Kind regards,
Bernhard

[transport.c:431] 
https://sources.debian.org/src/bluez/5.71-1/profiles/audio/transport.c/#L431
[701] https://github.com/bluez/bluez/issues/701
[83cfad1] 
https://github.com/bluez/bluez/commit/83cfad1badee6aae77eb15177ccc917249ab9bb3
[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 
20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08

https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4  ==  0b0100:
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access
.






# 2024-05-01 trixie/testing amd64 qemu VM

apt dist-upgrade
apt install gdb bluez bluez-dbgsym
apt build-dep bluez


mkdir /home/benutzer/source/bluez/orig -p
cd/home/benutzer/source/bluez/orig
apt source bluez



echo -n "find /b ..., ..., 0x" && \
echo "00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e 
fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 
00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

gdb -q
set width 0
set pagination off
file /usr/sbin/bluetoothd
tb main
run
pipe info target | grep -E "\.text$"

find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 0x54, 
0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 0x53, 
0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 0x8b, 
0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 0x48, 
0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
b * (0x5559a34b + 42)
info b
disassemble /r 0x5559a34b, 0x5559a34b + 62
directory /home/benutzer/source/bluez/orig/bluez-5.71




benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/bluetoothd
Reading symbols from /usr/sbin/bluetoothd...
Reading symbols from 
/usr/lib/debug/.build-id/b3/ec9634ecf4f0995fa44119b844150cc8d98db5.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x25bd0: file src/main.c, line 1355.
(gdb) run
Starting program: /usr/sbin/bluetoothd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe478) at src/main.c:1355
1355src/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep -E "\.text$"
0x555798f0 - 0x55663b30 is .text
(gdb) find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 
0x54, 0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 
0x53, 0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 
0x8b, 0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 
0x48, 0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
0x5559a34b 
1 pattern found.
(gdb) b * (0x5559a34b + 42)
Breakpoint 2 at 0x5559a375: file profiles/audio/transport.c, line 431.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5559a375 in a2dp_suspend_complete at 
profiles/audio/transport.c:431
(gdb) disassemble /r 0x5559a34b, 0x5559a34b + 62
Dump of assembler code from 0x5559a34b to 0x5559a389:
...
   0x5559a360 :f3 0f 1e fa 
endbr64
   0x5559a364 :41 55   
push   %r13
   0x5559a366 :41 54   
push   %r12
   0x5559a368 :55  
push   %rbp
   0x5559a369 :53  
push   %rbx
   0x5559a36a :   48 83 ec 08 
sub$0x8,%rsp
   0x5559a36e :   48 8b 2a
mov(%rdx),%rbp
   0x5559a371 :   48 8b 7a 08 
mov0x8(%rdx),%rdi
   0x5559a375 :   48 8b 45 20 
mov0x20(%rbp),%rax  <
   0x5559a379 :   4c 8b ad 

Bug#1070190: (no subject)

[Marco Moock]

> I have patched sendmail in order to enable O RejectNUL=True directive,

Is that already included in 8.18.1?
A grep over all files shows _FFR_REJECT_NUL_BYTE.

> but I do not achieved the fact to enable it by default.

What was the reason for that?

-- 
kind regards
Marco

Send unsolicited bulk mail to 1714574365mu...@cartoonies.org

Bug#1070192: ITP: rust-blight -- Hassle-free CLI backlight utility/library for Linux

[Maytham Alsudany]

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

* Package name: rust-blight
  Version : 0.7.1
  Upstream Contact: Maaz Ahmed 
* URL : https://github.com/VoltaireNoir/blight
* License : Expat
  Programming Lang: Rust
  Description : Hassle-free CLI backlight utility/library for Linux

Will be maintained within Rust team, will need sponsor.

--
Kind regards,
Maytham Alsudany


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

Bug#1070191: New upstream version 1.24.3

[Guido Günther]

Source: rust-gst-plugin-gtk4
Severity: wishlist

Hi,
Please update to the new upstream version. 0.12.5 added support for
dmabuf import which can significantly reduce CPU usage.
Cheers,
 -- Guido


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: 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#1070190: sendmail-bin: CVE-2023-51765 SMTP smuggling with NUL followup

[Bastien Roucariès]

Package: sendmail-bin
Severity: important
Tags: security help
Forwarded: https://marc.info/?l=oss-security=171447187004229=2

Dear Maintainer,

CVE-2023-51765 is not fully fixed at least for forwarding bad mail.

We must reject NUL including mail as a stop gap method.

I have patched sendmail in order to enable O RejectNUL=True directive,
but I do not achieved the fact to enable it by default.

It will need a NEWS.debian entry I suppose

Andreas could you get a glimpse at how to render  RejectNUL a default ?

Bastien

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

Bug#1070189: ITP: gnome-shell-extension-happy-appy-hotkey -- Hotkey application focus / launcher for GNOME Shell

[David Edmondson]

Package: wnpp
Severity: wishlist
Owner: David Edmondson 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dme.org

* Package name: gnome-shell-extension-happy-appy-hotkey
  Version : 8
  Upstream Contact: Jan Ouwens 
* URL : https://github.com/jqno/gnome-happy-appy-hotkey/
* License : GPL3
  Programming Lang: Javascript
  Description : Hotkey application focus/launch extension for GNOME Shell

> Assign hotkeys to applications to give them focus or launch them
> 
> Features:
>  - Assign a hotkey to an app to:
>   - Give it focus if it's already running, or
>   - Launch it if it's not.
>  - Assign a hotkey to cycle through all the apps that don't have a hotkey
>  - Optionally restrict hotkeys to current workspace
>  - Supports Wayland

Bug#1019042: [Pkg-rust-maintainers] Bug#1019042: rust-qwertone: FTBFS - dep issue

[Jeremy Bícha]

Control: severity -1 serious

This issue is now RC since it's not possible to build qwertone on Unstable now.

But I expect qwertone will get an upload to fix this issue within a
few days. See https://salsa.debian.org/debian/qwertone/-/merge_requests/1

Thank you,
Jeremy Bícha

Bug#1058652: RM: python-boto -- ROM; orphaned upstream, replaced by python-boto3

[Jeremy Bícha]

Control: tags -1 -moreinfo

The reverse dependencies have been taken care of now.

Thank you,
Jeremy Bícha

Bug#1070188: python3-spyder: uninstallable in unstable due to pylint

[Roland Mas]

Package: python3-spyder
Version: 5.5.1+ds-1
Severity: important

Dear Maintainer,

python3-spyder is no longer installable in sid; it depends (and
build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in
unstable.

Loosening the versioned dependency is enough to allow spyder to build,
but I don't know whether that introduces runtime changes or not.

Roland.

Bug#1065045: RM: pyannotate -- ROM; leaf package

[Alexandre Detiste]

control: tag -1 -moreinfo

This one should still be removed ...

It hasn't moved an inch still 2019
https://github.com/dropbox/pyannotate

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

Bug#1070186: python3-datalad: Don't recommend python3-boto

[Jeremy Bícha]

Package: python3-datalad
Version: 0.19.6-2
Severity: serious

Debian Policy § 2.2 says that packages in main (like python3-datalad)
are not allowed to have Recommends on packages that are not in main
(unless it is only a non-default alternative for a package in main).

python3-datalad Recommends: python3-boto but python3-boto has been
removed from Testing and will likely be removed from Unstable soon.
See https://bugs.debian.org/1058652

The replacement is python3-boto3 but the package will likely need
changes to upstream code to work with the new version.

Thank you,
Jeremy Bícha

Bug#1070187: python-pgpy: please drop the extraneous python3-six dependency

[Alexandre Detiste]

Source: python-pgpy
Version: 0.6.0-1.1
Severity: normal


A final cleanup has been proposed upstream

https://github.com/SecurityInnovation/PGPy/pull/437


Greetings

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1070185: python-oslo.reports: please drop the extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-oslo.reports
Version: 3.3.0-2
Severity: normal

This package does not need it anymore

tchet@quieter:/tmp/python-oslo.reports$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@quieter:/tmp/python-oslo.reports$

Bug#1070184: gnome-maps: Unable to start gnome-maps

[Enrique Garcia]

Package: gnome-maps
Version: 46.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: cqu...@arcor.de

I have recently upgraded my Debian testing and it comes with gnome-46.0-1. I am
using XFCE 4 desktop and when I try to start gnome-maps nothing happens. From
the command line nothing happens, it seems like frozen and after exactly 10
seconds the prompt returns but no window has appeared.


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

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

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  geoclue-2.0  2.7.1-2+b1
ii  gir1.2-adw-1 1.5.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b3
ii  gir1.2-geoclue-2.0   2.7.1-2+b1
ii  gir1.2-geocodeglib-2.0   3.26.3-6+b2
ii  gir1.2-glib-2.0 [gir1.2-gobject-2.0] 1.78.1-15
ii  gir1.2-gtk-4.0   4.12.5+ds-3
ii  gir1.2-gweather-4.0  4.4.0-1
ii  gir1.2-pango-1.0 1.52.1+ds-1
ii  gir1.2-rest-1.0  0.9.1-6+b1
ii  gir1.2-secret-1  0.21.4-1+b1
ii  gir1.2-shumate-1.0   1.2~beta-3+b1
ii  gir1.2-soup-3.0  3.4.4-5+b1
ii  gir1.2-xdp-1.0   0.7.1-5+b1
ii  gjs  1.79.3-1
ii  libc62.37-18
ii  libcairo21.18.0-1+b1
ii  libglib2.0-0t64  2.78.4-7
ii  libglib2.0-bin   2.78.4-7
ii  libgtk-4-1   4.12.5+ds-3
ii  libjson-glib-1.0-0   1.8.0-2+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpangocairo-1.0-0  1.52.1+ds-1
ii  librsvg2-2   2.58.0+dfsg-1
ii  libshumate-1.0-1 1.2~beta-3+b1
ii  libxml2  2.9.14+dfsg-1.3+b3

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#1070182: python-oslo.policy: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-oslo.policy
Version: 4.3.0-2
Severity: normal

Dear Maintainer,

This package does not use six anymore.

Greetings

tchet@quieter:/tmp/python-oslo.policy$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@quieter:/tmp/python-oslo.policy$

Bug#1065309: transition: gnat (12 -> 13 + time_t64)

[Graham Inggs]

Hi Nicholas

I think the builds are on track, except for:

libtemplates-parser FTBFS on arch:all [1]
gprbuild FTBFS on arch:any [2]
libgnatcoll, libgnatcoll-bindings and libgnatcoll-db are blocked by
the builds of gprbuild

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=libtemplates-parser=sid
[2] https://buildd.debian.org/status/package.php?p=gprbuild=sid

Bug#1070181: px: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: px
Version: 3.3.1-1
Severity: important

Dear Maintainer,

please remove here the dependency on python3-six;
python3-dateutil still has the right dependencies;
and will be fixed/released some day.

Greetings

https://wiki.debian.org/Python3-six-removal

tchet@quieter:/tmp/px$ grep six -r
debian/control: python3-six,
requirements.txt:# NOTE: We don't use six ourselves, but python-dateutil does. 
Do remove once
requirements.txt:six
tchet@quieter:/tmp/px$

Bug#1070180: python-falcon: please drop extraneous python3-six dependency

[Alexandre Detiste]

Source: python-falcon
Version: 3.1.1-3
Severity: normal

Dear Maintainer,

six usage has been removed upstream since v2.0

Greetings

tchet@quieter:/tmp/python-falcon$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
docs/changes/2.0.0.rst:- Removed the :py:mod:`six` and 
:py:mod:`python-mimeparse` dependencies.
tchet@quieter:/tmp/python-falcon$ 

Bug#1070179: octave-symbolic: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: octave-symbolic
Version: 3.1.1-2
Severity: normal

Dear Maintainer,

It looks like six can now safely be removed.

https://wiki.debian.org/Python3-six-removal

Greetings



Package: octave-symbolic
Architecture: all
Depends: ${misc:Depends},
 ${octave:Depends},
 python3-sympy,
# The following should be removed once sympy-1.6.patch is removed
 python3-six
Description: symbolic package for Octave
 ${octave:Upstream-Description}

Bug#1070178: python-warlock: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-warlock
Version: 2.0.1-3
Severity: normal

Dear Maintainer,

This package doesn't need six (itself).

Greetings

tchet@quieter:/tmp/python-warlock$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
poetry.lock: ( . )
tchet@quieter:/tmp/python-warlock$

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-04-30 Elliott Mitchell  wrote:
> On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> > On 2024-04-29 Elliott Mitchell  wrote:
[...] 
> > > From `nslcd` on clients I was getting the message:
> > > nslcd[12345]: [1a2b3c]  failed to bind to LDAP 
> > > server ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The 
> > > TLS connection was non-properly terminated.: Resource temporarily 
> > > unavailable
[...] 
> > > Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
> > > is two arguments, the ldaps and ldapi are a single argument).  I got
> > > traces from `slapd`: (serial numbers filed off)
> > 
> > > tls_read: want=5, got=5
> > >   :  16 03 01 01 8f
> > 
> > > tls_read: want=399, got=399
> > >   0160:fd12  
> > >   0170::3456:7890:abcd:  
> > >   0180::3.-.@.   
> > > TLS: can't accept: A disallowed SNI server name has been received..
> > > connection_read(13): TLS accept failure error=-1 id=1005, closing
[...]
> > I guess you used the IPv6 address as either CN or Subject Alternative
> > Name. Both take names, not IP addresses. There is a different field for
> > IP addresses.
> > 
> > gnutls-cli --port 636 fd12:3456:7890:abcd::3 
> > 
> > will probably give more info.
> > 
> > FWIW I have just generated a local test certificate with "IPAddress:"
> > set to '::1' and things work for me as expected.

> Hmm, `gnutls-cli --port ldaps` gave a different result.  The connection
> successfully established and I was left being able to type to `slapd`.
[...]
> Anything further is purely guesswork.


Hello,

well you could post the complete output of
gnutls-cli --port 636 fd12:3456:7890:abcd::3
perhaps even with -d10? I would reassign to openldap then if there are
no obvious clues.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1070177: nvidia-cuda-toolkit: CVE-2024-0072, CVE-2024-0076

[Andreas Beckmann]

Source: nvidia-cuda-toolkit
Version: 4.0.13-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

https://nvidia.custhelp.com/app/answers/detail/a_id/5517

CVE-2024-0072   NVIDIA CUDA toolkit for all platforms contains a
vulnerability in cuobjdump and nvdisasm where an attacker may cause a
crash by tricking a user into reading a malformed ELF file. A successful
exploit of this vulnerability may lead to a partial denial of service.

CVE-2024-0076   NVIDIA CUDA toolkit for all platforms contains a
vulnerability in cuobjdump and nvdisasm where an attacker may cause a
crash by tricking a user into reading a malformed ELF file. A successful
exploit of this vulnerability may lead to a partial denial of service.

CVE-2023-31028  NVIDIA nvJPEG2000 Library for Windows and Linux contains
a vulnerability where improper input validation might enable an attacker
to use a specially crafted input file. A successful exploit of this
vulnerability might lead to a partial denial of service.

CVE-2024-0080   NVIDIA nvTIFF Library for Windows and Linux contains a
vulnerability where improper input validation might enable an attacker
to use a specially crafted input file. A successful exploit of this
vulnerability might lead to a partial denial of service.

CVE IDs Addressed   Affected Products   Affected Versions   
Updated Version
CVE-2024-0072
CVE-2024-0076   NVIDIA CUDA Toolkit All versions prior to CUDA 
Toolkit v12.4CUDA Toolkit v12.4U1
CVE-2023-31028  nvJPEG2000 Library  All versions prior to 
nvJPEG2000 v0.7.x nvJPEG2000 v0.7.x
CVE-2024-0080   nvTIFF Library  All versions prior to nvTIFF 
v0.3.0 nvTIFF v0.3.0

nvJPEG2000 and nvTIFF are not part of the CUDA Toolkit and are not
packaged in Debian.


Andreas

Bug#1049680: freedink-dfarc: Fails to build binary packages again after successful build

[Petter Reinholdtsen]

I had a look at this issue, and the cause is in src/Makefile.am, which
intentionally list several files both in both dfarc_SOURCES and
BUILT_SOURCES.  The problematic files are generated but stored
in the tarball to save a build dependencuy (wxglade).

I am not sure how to avoid this problem, and left it to someone with
more time to spend on it. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#1069268: gnulib: package version is long

[Vincent Lefevre]

Hi Simon,

On 2024-05-01 11:36:56 +0200, Simon Josefsson wrote:
> Vincent Lefevre  writes:
> > IMHO, for additional version information, the Debian changelog is a
> > good place for the user + output from a standard command providing
> > the version, e.g. "gnulib-tool --version". Scripts can use such a
> > command to record the necessary information about software in log
> > files. By "standard", I mean that it needs to exist upstream.
> >
> > For instance, for GCC, there is "gcc --version", where Debian adds
> > some information. In particular for gcc-snapshot:
> >
> > $ gcc-snapshot --version
> > gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
> > r14-8187-gb00be6f1576]
> > [...]
> >
> > One has all the details... When compiling software, this can be
> > found in the generated config.log file, which is really nice for
> > bug reports and debugging.
> >
> > And the gcc-snapshot version string is basically just a date.
> 
> Right.  There is one implementation problem: gnulib-tool is patched to
> read the version from /usr/share/doc/gnulib/changelog.Debian.gz now, but
> if we change changelog to only be a date, we would want to change this
> logic to actually print the useful git commit version information, and
> I'm not yet sure how to do that.

IMHO, changelog.Debian.gz should contain complete information about
the version, not in the Debian package version, but in the log. It
already has lines like:

  * New upstream snapshot from stable branch stable-202401.

You may choose some fixed format such that it is parsable by both
humans and the machine, i.e. something that a human can understand,
but simple enough to that a script can produce a more compact version
for gnulib-tool.

However, the Debian policy

  https://www.debian.org/doc/debian-policy/ch-docs.html

says

  Packages must not require the existence of any files in
  /usr/share/doc/ in order to function.[6] Any files that are used or
  read by programs but are also useful as stand alone documentation
  should be installed elsewhere, such as under /usr/share/package/,
  and then included via symbolic links in /usr/share/doc/package.

  [6] The system administrator should be able to delete files in
  /usr/share/doc/ without causing any programs to break.

BTW, since gnulib-tool is already in /usr/share/gnulib, it would
make sense to have version information there too (perhaps just in
the compact form, for gnulib-tool).

> There is also the "risk" that upstream gnulib eventually release
> versioned archives.  There is a recently added v1.0 tag in git for
> example, suggesting things may change.  Since we haven't used the
> 0~20240501* pattern for gnulib version historically, to move to a

(Anyway, the 0~20240501* pattern would have been a bad idea, IMHO,
because AFAIK, there is no version 0 in gnulib, and that would have
confused the user.)

> version based approach we would need an epoch like 1:1.3-1 or (more
> likely) 1:1.3+20250314-2 since I think we need to package more recent
> git commits than what's in any most recent gnulib git tags.  However I
> don't think the upstream version number is relevant either, for the same
> reasons we realized the upstream commit id or branches weren't.  So we
> can continue to use dates for package versions even if upstream start to
> release packaged archives.
> 
> I'm now inclinced to use a pure date-based version string like
> 20240501-1 going forward.  Any objections?

This is OK for me. Until there would be an obvious advantage to
change, I'd say that it is better to still use just the date.

> We then also have to fix Debian's gnulib-tool --version output to embed
> the latest git commit information from upstream that we package --
> possibly using the new git bundle as a source?  Instead of parsing
> /usr/share/doc/gnulib/changelog.Debian.gz, which may not be present in
> stripped down images anyway.

Well, you must not use files under /usr/share/doc (see above).

I saw that you now ship gnulib.bundle, but I don't know whether
this is a good thing (usefulness in practice vs the fact that
it makes the package significantly larger).

> Since gnulib is a fairly large package, I would prefer to not spam the
> archive with new *.orig.tar.gz uploads too often.  So I prefer to not
> fix this bug until we have to upload a more recent gnulib into the
> archive for other reasons.  I don't expect that to take long: I'm
> planning to do new release of several projects (oath-toolkit, libidn2,
> inetutils, etc) that use gnulib, and work on making those Debian
> packages use the Debian gnulib package instead of vendored code would
> require a new gnulib Debian package upload.

OK. I reverted to 20240117+stable-1 on my machines. IIRC, I had
inst

Bug#1070176: Mark pdns-recursor as EOLed in Bullseye

[Moritz Muehlenhoff]

Source: debian-security-support
Version: 1:13+2024.01.30
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

Please mark pdns-recursor as EOL/no longer covered by security support
in Bullseye. These packages can still be used for select use cases
(internal resolver within a company network), but 4.4 is lagging too
much behind to be supportable as a general purpose resolver.

Cheers,
Moritz

Bug#1070175: RM: salt/3002.6+dfsg1-4+deb11u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org
Control: affects -1 + src:salt
User: release.debian@packages.debian.org
Usertags: rm

Please remove salt in the next Bullseye point release.
It was already removed frm unstable for being unsupportable
and unmaintained (https:://bugs.debian.org/1069654).

There are two related packages which need to be removed
alongside, since salt-common depends on them (but which
have no other dependencies outside of salt):

pytest-salt-factories 0.93.0-1
pytest-testinfra 6.1.0-1

Cheers,
Moritz

Bug#1070174: ruby-actionpack-xml-parser: Typo in package description

[Thomas Vincent]

Source: ruby-actionpack-xml-parser
Version: 2.0.1-4
Severity: minor

Dear Maintainer,

We noticed a typo in ruby-actionpack-xml-parser's long description when 
translating it on the DDTP.
The description mentions "the Action Packg", while we believe it should be "the 
Action Pack".

Thanks for maintaining ruby-actionpack-xml-parser!
Thomas, for the DDTP team.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 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

Bug#1070173: mirror submission for mirrors.jcut.edu.cn

[stack zhao]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.jcut.edu.cn
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Maintainer: stack zhao 
Country: CN China




Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/
Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/mirrors.jcut.edu.cn

Bug#1069897: Netcfg to get search domain

[Frédéric Guyot]

Here is a proposed patch:

diff -Naur netcfg-master/dhcp.c netcfg-master-updated/dhcp.c
--- netcfg-master/dhcp.c 2024-05-01 11:14:26.209026580 +0100
+++ netcfg-master-updated/dhcp.c 2024-05-01 11:15:11.888387848 +0100
@@ -41,6 +41,7 @@
   "domain",
   "hostname",
   "dns",
+ "search",
   "ntpsrv", /* extra */
   NULL };

Bug#1070172: Exception when invoked without options

[Guido Günther]

Package: gcovr
Version: 7.2-1
Severity: grave

Hi,
invoking gcovr 7.2 in an empty directory fails like

$ gcovr 
--
   GCC Code Coverage Report
Traceback (most recent call last):
  File "/usr/bin/gcovr", line 1972, in 
print_text_report(covdata)
  File "/usr/bin/gcovr", line 822, in print_text_report
OUTPUT.write("Directory: "+options.root+"\n")
 ~^
TypeError: can only concatenate str (not "NoneType") to str


This makes meson think gcovr is not available, e.g.:

  
https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265

I've marked this as grave as it breaks CI pipelines.

Cheers,
 -- Guido


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: 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 gcovr depends on:
ii  python33.11.6-1
ii  python3-pkg-resources  68.1.2-2

gcovr recommends no packages.

gcovr suggests no packages.

-- no debconf information

Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/

[Mark Hindley]

Control: tags -1 patch

Lorenzo,

On Wed, May 01, 2024 at 10:59:36AM +0200, Lorenzo Puliti wrote:
> Package: openrc
> Version: 0.45.2-2
> Severity: normal
> X-Debbugs-Cc: plore...@disroot.org
> 
> Hi,
> 
> it appears that, at least under certain conditions, openrc postinstall
> script fails if a sysvinit script in /etc/init.d/ is not executable.
> 
> Note that recently debhelper started to chmod -x initscripts when a package is
> removed but not purged, so openrc should deal whit non executebles files under
> /etc/init.d/

Thanks. Does the attached patch help?

Mark
>From 7d20e19bf392869853fb7df884030c669d7ff641 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 1 May 2024 11:16:44 +0100
Subject: [PATCH] d/openrc.postinst: ignore non-executable scripts in
 /etc/init.d

Closes: #1070167
---
 debian/openrc.postinst | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 6e5cd7ae..3b62f026 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -25,7 +25,7 @@ if [ "${1}" = "configure" ] ; then
 			rclink=/etc/rc${rl}.d/${f}
 			initsh=$(readlink -f ${rclink})
 			svc=$(basename ${initsh})
-			if [ -f ${initsh} ]; then
+			if [ -x ${initsh} ]; then
 case ${rl} in
 1) orl="recovery" ;;
 2) orl="default" ;;
@@ -33,8 +33,12 @@ if [ "${1}" = "configure" ] ; then
 esac
 rc-update add ${svc} ${orl}
 			else
+			if [ -f ${initsh} ]; then
+echo "*** WARNING: skipping non-executable $rclink"
+			else
 echo "*** WARNING: dangling link $rclink"
-echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
+			fi
+			echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
 			fi
 		done
 	done
-- 
2.39.2

Bug#1070133: Patches for these two bugs

[Steve McIntyre]

Control: tag 1070133 +patch
Control: tag 1070135 +patch

Here's a debdiff against what's already in 3.11.2-6+deb12u1 in
-proposed-updates

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"
diff -Nru python3.11-3.11.2/debian/changelog python3.11-3.11.2/debian/changelog
--- python3.11-3.11.2/debian/changelog  2024-03-02 20:28:50.0 +
+++ python3.11-3.11.2/debian/changelog  2024-04-26 16:10:48.0 +0100
@@ -1,3 +1,14 @@
+python3.11 (3.11.2-6+deb12u2) bookworm; urgency=medium
+
+  * Apply upstream security fix for CVE-2024-0450
+Protect zipfile from "quoted-overlap" zipbomb.
+Closes: #1070133
+  * Apply and tweak upstream security fix for CVE-2023-6597
+tempfile.TemporaryDirectory: fix symlink bug in cleanup
+Closes: #1070135
+
+ -- Steve McIntyre   Fri, 26 Apr 2024 16:10:48 +0100
+
 python3.11 (3.11.2-6+deb12u1) bookworm; urgency=medium
 
   [ Anders Kaseorg ]
diff -Nru python3.11-3.11.2/debian/patches/CVE-2023-6597.patch 
python3.11-3.11.2/debian/patches/CVE-2023-6597.patch
--- python3.11-3.11.2/debian/patches/CVE-2023-6597.patch1970-01-01 
01:00:00.0 +0100
+++ python3.11-3.11.2/debian/patches/CVE-2023-6597.patch2024-04-26 
16:10:48.0 +0100
@@ -0,0 +1,202 @@
+commit 5585334d772b253a01a6730e8202ffb1607c3d25
+Author: Serhiy Storchaka 
+Date:   Thu Dec 7 18:37:10 2023 +0200
+
+[3.11] gh-91133: tempfile.TemporaryDirectory: fix symlink bug in cleanup 
(GH-99930) (GH-112839)
+
+(cherry picked from commit 81c16cd94ec38d61aa478b9a452436dc3b1b524d)
+
+Co-authored-by: Søren Løvborg 
+
+diff --git a/Lib/tempfile.py b/Lib/tempfile.py
+index aace11fa7b..f59a63a7b4 100644
+--- a/Lib/tempfile.py
 b/Lib/tempfile.py
+@@ -270,6 +270,22 @@ def _mkstemp_inner(dir, pre, suf, flags, output_type):
+ raise FileExistsError(_errno.EEXIST,
+   "No usable temporary file name found")
+ 
++def _dont_follow_symlinks(func, path, *args):
++# Pass follow_symlinks=False, unless not supported on this platform.
++if func in _os.supports_follow_symlinks:
++func(path, *args, follow_symlinks=False)
++elif _os.name == 'nt' or not _os.path.islink(path):
++func(path, *args)
++
++def _resetperms(path):
++try:
++chflags = _os.chflags
++except AttributeError:
++pass
++else:
++_dont_follow_symlinks(chflags, path, 0)
++_dont_follow_symlinks(_os.chmod, path, 0o700)
++
+ 
+ # User visible interfaces.
+ 
+@@ -863,17 +879,10 @@ def __init__(self, suffix=None, prefix=None, dir=None,
+ def _rmtree(cls, name, ignore_errors=False):
+ def onerror(func, path, exc_info):
+ if issubclass(exc_info[0], PermissionError):
+-def resetperms(path):
+-try:
+-_os.chflags(path, 0)
+-except AttributeError:
+-pass
+-_os.chmod(path, 0o700)
+-
+ try:
+ if path != name:
+-resetperms(_os.path.dirname(path))
+-resetperms(path)
++_resetperms(_os.path.dirname(path))
++_resetperms(path)
+ 
+ try:
+ _os.unlink(path)
+diff --git a/Lib/test/test_tempfile.py b/Lib/test/test_tempfile.py
+index 1242ec7e3c..675edc8de9 100644
+--- a/Lib/test/test_tempfile.py
 b/Lib/test/test_tempfile.py
+@@ -1565,6 +1565,103 @@ def test_cleanup_with_symlink_to_a_directory(self):
+  "were deleted")
+ d2.cleanup()
+ 
++@os_helper.skip_unless_symlink
++def test_cleanup_with_symlink_modes(self):
++# cleanup() should not follow symlinks when fixing mode bits (#91133)
++with self.do_create(recurse=0) as d2:
++file1 = os.path.join(d2, 'file1')
++open(file1, 'wb').close()
++dir1 = os.path.join(d2, 'dir1')
++os.mkdir(dir1)
++for mode in range(8):
++mode <<= 6
++with self.subTest(mode=format(mode, '03o')):
++def test(target, target_is_directory):
++d1 = self.do_create(recurse=0)
++symlink = os.path.join(d1.name, 'symlink')
++os.symlink(target, symlink,
++target_is_directory=target_is_directory)
++try:
++os.chmod(symlink, mode, follow_symlinks=False)
++except NotImplementedError:
++pass
++try:
++os.chmod(symlink, mode)
++except FileNotFoundError:

Bug#1070171: RFP: mangl -- An enhanced man page viewer

[Ziga Lenarcic]

Package: wnpp
Severity: wishlist

* Package name: mangl
  Version : 1.1.4
  Upstream Author : Ziga Lenarcic 
* URL : https://github.com/zigalenarcic/mangl
* License : BSD 2-Clause and BSD 3-Clause
  Programming Lang: C
  Description : An enhanced man page viewer

mangl is an enhanced man page viewer with the following
features:
  * searching of man pages
  * hyperlinks to other man pages
  * search withing a man page
  * browsing history (back etc.)
  * colored text
  * GLFW GUI
  * truetype support
  * draggable scrollbar
  * keyboard and mouse interaction

The package is an improvement (in some cases) over what
the default man executable provide. In general it was written
to prevent resorting to online browsing of man pages because
the default viewer doesn't have linked pages.
Disclosure: I'm the author of the program and am willing to
adjust the build process etc. to help with inclusion in the
Debian packages.

Bug#1070163: socat: support duplicating data to multiple clients of listening socket?

[Gerhard Rieger]

Hello,

Socat is not able to do this, and there is currently no plan to 
implement this feature.


However, due to the repeated requests, a script socat-mux.sh has been 
written and released with Socat 1.8.0.0 that is able to provide 
many-to-one, one-to-all communications. Internally it utilizes two Socat 
(parent) processes that use UDP broadcast on loopback interface for data 
multiplication. Please note that this has a security risk because local 
users are able to join the communications.


The script provided with 1.8.0.0 requires this actual Socat version; in 
the next bug fix release a backported version will be included for older 
Socat versions, find it attached to this message.


You should be able to realize your use case with the following command:

socat-mux.sh UNIX-LISTEN:sock,unlink-early=1,fork \
TCP-CONNECT:1.2.3.4:1234

Hope this helps!
- Gerhard


Am 01.05.24 um 07:34 schrieb Paul Wise:

Package: socat
Severity: wishlist
X-Debbugs-Cc: so...@dest-unreach.org
Forwarded: so...@dest-unreach.org

socat does not appear to have a way to send data to multiple clients of
a listening socket, which would be useful to proxy data from overloaded
servers to multiple local clients.

For example:

socat TCP-CONNECT:1.2.3.4:1234 UNIX-LISTEN:sock,unlink-early=1 &
socat UNIX-CONNECT:out STDOUT &
socat UNIX-CONNECT:out STDOUT &

The second client is not allowed to connect to the socket:

2024/05/01 13:12:32 socat[957352] E connect(, AF=1 "out", 5): Connection 
refused

This can be achieved, by using this nmap ncat command:

ncat --listen --unixsock out --keep-open --send-only

This appears to work by reading some data, then writing it
to all the client sockets, then repeating the process.

Unfortunately ncat breaks when one of the clients terminates,
so ncat currently does not appear to be useful for this yet.

Ncat: Program bug: fd (4) not on list. QUITTING.

PS: some places on the web where people are looking for this feature,
for both local Unix domain stream sockets and local TCP ports:

https://serverfault.com/questions/747980/simpliest-unix-non-blocking-broadcast-socket
https://unix.stackexchange.com/questions/195880/socat-duplicate-stdin-to-each-connected-client
https://stackoverflow.com/questions/17480967/using-socat-to-multiplex-incoming-tcp-connection
https://gist.github.com/mathieue/3505472



socat-mux.sh
Description: application/shellscript

Bug#1070170: Generate and include amalgamated header file

[Nikos Tsipinakis]

Source: catch2
Version: 2.13.10-1
Severity: wishlist
X-Debbugs-Cc: ni...@tsipinakis.com

Dear Maintainer,

I've been depending on the catch2 library package for newsboat which by default
vendors the catch library. To be compatible with the Debian policy I have
overridden this so that the packaged version is used instead. 

However with version 3 now there are separate header files for each function and
since upstream is relying on the single header/amalgamated version it is not
easy to patch to include all the required functionalities.

It'd be great to also generate and include the amalgamated header file
(generation script can be found here[1]) in order to ease the version 3
transition for amalgamated header users.

[1] 
https://github.com/catchorg/Catch2/blob/fa5a53df17303339eff8fda5cae0b601af207085/tools/scripts/generateAmalgamatedFiles.py

Cheers,
Nikos 

Bug#1068161: Video playback regression

[Daniel Richard G.]

Hi Andres,

On Tue, 2024 Apr 30 02:42-04:00, Andres Salomon wrote:
> Please let me know if this is still broken with chromium 124.

I'm happy to report that the issue appears to be resolved in the current
124.0.6367.78-1~deb12u1. (I did not test 124.0.6367.60.)

Some additional info that I meant to send in earlier:

* I was able to work around the problem in 123 with "--use-gl=egl".
  Even now, with 124, I get "MESA: error: Out of instructions"
  messages on the terminal when this flag is removed (but video now
  works either way).

* The video adapter is listed as a "VGA compatible controller [0300]:
  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
  Graphics Controller [8086:27a2]", on a Lenovo ThinkPad.

* This is a different and much older bug, but I've observed that some
  Web sites show visual artifacts in chromium on this particular system,
  and --use-gl=egl also cleared those up. I think the issue may be that
  the driver for this specific hardware is buggy, and affected users are
  better off using the alternate GL implementation. (I can provide more
  details if this is of interest.)

Bug#1070169: fontconfig: fills the logs with warnings about multiple values

[Francesco Potortì]

Package: fontconfig
Version: 2.15.0-1.1
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

Today I got this in syslog (an excerpt):

telegram-desktop_telegram-desktop.desktop[8823]: Fontconfig warning: 
"/etc/fonts/conf.avail/25-arphic-uming-bitmaps.conf", line 11: Having multiple 
values in  isn't supported and may not work as expected

telegram-desktop_telegram-desktop.desktop[8823]: Fontconfig warning: 
"/etc/fonts/conf.avail/40-generic.conf", line 27: Having multiple  in 
 isn't supported and may not work as expected

telegram-desktop_telegram-desktop.desktop[8823]: Fontconfig warning: 
"/etc/fonts/conf.avail/41-arphic-uming.conf", line 16: Having multiple  
in  isn't supported and may not work as expected

telegram-desktop_telegram-desktop.desktop[8823]: Fontconfig warning: 
"/etc/fonts/conf.avail/40-generic.conf", line 27: Having multiple  in 
 isn't supported and may not work as expected

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - CNR, Pisa, ItalyWeb:http://fly.isti.cnr.it


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

Kernel: Linux 6.6.15-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 fontconfig depends on:
ii  fontconfig-config  2.15.0-1.1
ii  libc6  2.37-18
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#1069268: gnulib: package version is long

[Simon Josefsson]

Hi Vincent,

Vincent Lefevre  writes:

> Thanks for the explanations. However, I think that it is not the
> goal of the Debian version string to entirely reflect all the
> Debian-side and upstream-side versions involved. This may be a
> good idea when the obtained version string is short enough and
> easy to understand, but here, this is not the case. There are
> probably better places to give such information, in a clearer
> way. This could be in well-chosen files and/or output from
> commands like "gnulib-tool --version" (see below).

I agree now.

> BTW, is the "+stable" really useful in the version string?

I'm no longer convinced it adds anything useful, so would prefer to
remove it.

>> To be honest, after writing all this, I'm no longer certain why anyone
>> would really look at the version number at all for the gnulib Debian
>> package.  A sequentially increasing number is sufficient for packaging
>> reasons: if anyone really wants to know what git commits are inside the
>> package, just read the source code in the package to find out.
>
> IMHO, for additional version information, the Debian changelog is a
> good place for the user + output from a standard command providing
> the version, e.g. "gnulib-tool --version". Scripts can use such a
> command to record the necessary information about software in log
> files. By "standard", I mean that it needs to exist upstream.
>
> For instance, for GCC, there is "gcc --version", where Debian adds
> some information. In particular for gcc-snapshot:
>
> $ gcc-snapshot --version
> gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
> r14-8187-gb00be6f1576]
> [...]
>
> One has all the details... When compiling software, this can be
> found in the generated config.log file, which is really nice for
> bug reports and debugging.
>
> And the gcc-snapshot version string is basically just a date.

Right.  There is one implementation problem: gnulib-tool is patched to
read the version from /usr/share/doc/gnulib/changelog.Debian.gz now, but
if we change changelog to only be a date, we would want to change this
logic to actually print the useful git commit version information, and
I'm not yet sure how to do that.

There is also the "risk" that upstream gnulib eventually release
versioned archives.  There is a recently added v1.0 tag in git for
example, suggesting things may change.  Since we haven't used the
0~20240501* pattern for gnulib version historically, to move to a
version based approach we would need an epoch like 1:1.3-1 or (more
likely) 1:1.3+20250314-2 since I think we need to package more recent
git commits than what's in any most recent gnulib git tags.  However I
don't think the upstream version number is relevant either, for the same
reasons we realized the upstream commit id or branches weren't.  So we
can continue to use dates for package versions even if upstream start to
release packaged archives.

I'm now inclinced to use a pure date-based version string like
20240501-1 going forward.  Any objections?

We then also have to fix Debian's gnulib-tool --version output to embed
the latest git commit information from upstream that we package --
possibly using the new git bundle as a source?  Instead of parsing
/usr/share/doc/gnulib/changelog.Debian.gz, which may not be present in
stripped down images anyway.

Since gnulib is a fairly large package, I would prefer to not spam the
archive with new *.orig.tar.gz uploads too often.  So I prefer to not
fix this bug until we have to upload a more recent gnulib into the
archive for other reasons.  I don't expect that to take long: I'm
planning to do new release of several projects (oath-toolkit, libidn2,
inetutils, etc) that use gnulib, and work on making those Debian
packages use the Debian gnulib package instead of vendored code would
require a new gnulib Debian package upload.

/Simon


signature.asc
Description: PGP signature

Bug#1070168: zstd: Poor performance of Debian build

[Laurent Bonnaud]

Package: zstd
Version: 1.5.5+dfsg2-2
Severity: normal

Dear Maintainer,

here is a quick benchmark of the zstd build in Debian:

$ zstd -V
*** Zstandard CLI (64-bit) v1.5.5, by Yann Collet ***

$ zstd -b
 3#Synthetic 50% :  1000 ->   3230847 (x3.095),  168.9 MB/s, 1310.7 MB/s

and here is the same benchmark in the flatpak build:

$ flatpak run org.freedesktop.Platform//23.08

[ org.freedesktop.Platform ~]$ zstd -V
*** Zstandard CLI (64-bit) v1.5.5, by Yann Collet ***

[ org.freedesktop.Platform ~]$ zstd -b
 3#Synthetic 50% :  1000 ->   3230847 (x3.095),  201.1 MB/s, 1502.0 MB/s

The performance difference is significant IMHO.


-- 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)

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

Versions of packages zstd depends on:
ii  libc6   2.38-6
ii  libgcc-s1   14-20240429-1
ii  liblz4-11.9.4-2
ii  liblzma55.6.1+really5.4.5-1
ii  libstdc++6  14-20240429-1
ii  zlib1g  1:1.3.dfsg-3.1

zstd recommends no packages.

zstd suggests no packages.

-- no debconf information

--
Laurent.

Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)

[Arnaud Rebillout]

On 30/04/2024 21:44, Simon McVittie wrote:

coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie
for whatever reason. Because debootstrap doesn't currently know about
versioned Provides, I think it would be useful to get versions of these
packages in trixie that have been rebuilt against the 64-bit time_t ABIs
and package names.

If the versions in trixie don't migrate imminently, please consider:

nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64"
nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64"


I tried to rebuild coreutils 9.4-3 in the Kali Linux suite "kali-dev" 
(based on Debian testing), and for the **armhf** architecture.


The thing is, in the build chroot there is coreutils+libssl3 already 
installed. Then apt needs to install the build depends for coreutils, 
ie. libssl-dev that depends on libssl3t64. And of course, for armhf and 
armel, libssl3t64 is not co-installable with libssl3, so the build fails 
straight there. Can't even install the build deps.


I suppose it's not a surprise for those familiar with the matter. And 
the NMU suggested by Simon would probably work for other architectures, 
maybe it's better than nothing.


Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer