Bug#1041543: RM: minisapserver -- ROM; Obsolete in upstream

[Antonin Kral]

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

Hello,

I would like to propose removal of the minisapserver package. It has 
been obsolete by upstream for ages now as the functionality was migrated 
to VLC directly.

See https://wiki.videolan.org/MiniSAPServer/ for more information.

Thank you, Best,

Antonin


signature.asc
Description: PGP signature

Bug#1038004: not fixed yet

[Vladimir Stavrinov]

The problem still exists. The reason is missing asm/orc_h ash.h and
orc_header.h files. Fortunately workaround exists:

cp -a 
/usr/src/linux-headers-6.3.0-{2,1}-common/arch/x86/include/asm/orc_header.h
cp -a /usr/src/linux-headers-6.3.0-{2,1}-common/arch/x86/include/asm/orc_hash.h

dpkg --list nvidia-tesla-470-kernel-dkms linux-{image,headers}-6.3.0-?-amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  linux-headers-6.3.0-1-amd64  6.3.7-1  amd64Header
files for Linux 6.3.0-1-amd64
ii  linux-headers-6.3.0-2-amd64  6.3.11-1 amd64Header
files for Linux 6.3.0-2-amd64
ii  linux-image-6.3.0-1-amd646.3.7-1  amd64Linux 6.3
for 64-bit PCs (signed)
ii  linux-image-6.3.0-2-amd646.3.11-1 amd64Linux 6.3
for 64-bit PCs (signed)
ii  nvidia-tesla-470-kernel-dkms 470.199.02-1 amd64NVIDIA
binary kernel module DKMS source (Tesla 470 version)

Though the regular solution should be provided.

--

Bug#1041542: uuid: Memory unsafety for version 1 UUID with out-of-range timestamp

[Tim Duesterhus]

Package: uuid
Version: 1.6.2-1.5+b11
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I ran `uuid -d --1100-a000-` and noticed that the time
content was strangely formatted with a dot where a digit should be:

encode: STR: --1100-a000-
SIV: 80291759423830037102592
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 1 (time and node based)
content: time:  60266-07-14 05:26:.747955.2 UTC
 clock: 8192 (usually random)
 node:  00:00:00:00:00:00 (global unicast)

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

Suspecting memory unsafety, I reran the command in `valgrind` as

valgrind uuid -d --1100-a000-

   * What was the outcome of this action?

This showed a number of "use of uninitialized value" errors:

==6046== Memcheck, a memory error detector
==6046== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==6046== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==6046== Command: uuid -d --1100-a000-
==6046== 
==6046== Conditional jump or move depends on uninitialised value(s)
==6046==at 0x4846798: strlen (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6046==by 0x485D47A: uuid_str_vsnprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DDE5: uuid_str_vrsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DF03: uuid_str_rsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x48582AA: uuid_export (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x1098DE: ??? (in /usr/bin/uuid)
==6046==by 0x4889189: (below main) (libc_start_call_main.h:58)
==6046== 
==6046== Conditional jump or move depends on uninitialised value(s)
==6046==at 0x485D509: uuid_str_vsnprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DDE5: uuid_str_vrsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DF03: uuid_str_rsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x48582AA: uuid_export (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x1098DE: ??? (in /usr/bin/uuid)
==6046==by 0x4889189: (below main) (libc_start_call_main.h:58)
==6046== 
==6046== Conditional jump or move depends on uninitialised value(s)
==6046==at 0x4846798: strlen (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6046==by 0x485D47A: uuid_str_vsnprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DE15: uuid_str_vrsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DF03: uuid_str_rsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x48582AA: uuid_export (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x1098DE: ??? (in /usr/bin/uuid)
==6046==by 0x4889189: (below main) (libc_start_call_main.h:58)
==6046== 
==6046== Conditional jump or move depends on uninitialised value(s)
==6046==at 0x485D509: uuid_str_vsnprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DE15: uuid_str_vrsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x485DF03: uuid_str_rsprintf (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x48582AA: uuid_export (in 
/usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22)
==6046==by 0x1098DE: ??? (in /usr/bin/uuid)
==6046==by 0x4889189: (below main) (libc_start_call_main.h:58)
==6046== 
encode: STR: --1100-a000-
SIV: 80291759423830037102592
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 1 (time and node based)
content: time:  60266-07-14 05:26:.747955.2 UTC
 clock: 8192 (usually random)
 node:  00:00:00:00:00:00 (global unicast)
==6046== 
==6046== HEAP SUMMARY:
==6046== in use at exit: 0 bytes in 0 blocks
==6046==   total heap usage: 18 allocs, 18 frees, 10,431 bytes allocated
==6046== 
==6046== All heap blocks were freed -- no leaks are possible
==6046== 
==6046== Use --track-origins=yes to see where uninitialised values come from
==6046== For lists of detected and suppressed errors, rerun with: -s
==6046== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

   * What outcome did you expect instead?

I did not expect any use of uninitialized values, even for malformatted /
strange / out of range UUIDs. Instead the UUID should either be correctly
handled or an error message 

Bug#1041540: udev: Failed to get cgroup, ignoring: No medium found

[Sven Joachim]

Control: forwarded -1 https://github.com/systemd/systemd/issues/28469

On 2023-07-20 16:58 +0200, Sven Joachim wrote:

> Package: udev
> Version: 254~rc2-3
>
> On boot I see the following message, which seems to come from udev in
> the initramfs (see src/udev/udevd.c):
>
> Failed to get cgroup, ignoring: No medium found
>
> Obviously systemd is not running yet which could explain the complaint,
> but to an unsuspecting user the ENOMEDIUM error code is not very
> comprehensible.

This has also been reported upstream.

Cheers,
   Sven

Bug#1041541: ffmpeg: libsvtav1 encoding broken

[Wouter Verhelst]

Package: ffmpeg
Version: 7:5.1.3-1
Severity: normal

Dear Maintainer,

I ran the following on a bookworm machine:

ffmpeg -i foo.mp4 -c:a libopus -c:v libsvtav1 -crf 35 -preset 8 -y foo.webm

This proceeded to encode the video in AV1. However, when I tried the
same on unstable, I received the following output:

wouter@pc220518:~$ ffmpeg -i foo.mp4 -c:a libopus -c:v libsvtav1 -preset 8 -crf 
35 -y foo.webm
ffmpeg version 5.1.3-1 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-14)
  configuration: --prefix=/usr --extra-version=1 --toolchain=hardened 
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu 
--arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa 
--enable-libaom --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d 
--enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm 
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq 
--enable-librist --enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh 
--enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab 
--enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 
--enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq 
--enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl 
--enable-opengl --enable-sdl2 --disable-sndio --enable-libjxl 
--enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r 
--enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared
  libavutil  57. 28.100 / 57. 28.100
  libavcodec 59. 37.100 / 59. 37.100
  libavformat59. 27.100 / 59. 27.100
  libavdevice59.  7.100 / 59.  7.100
  libavfilter 8. 44.100 /  8. 44.100
  libswscale  6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc56.  6.100 / 56.  6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'foo.mp4':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2avc1mp41
title   : Make the code work for you: Flutter Code Generation
date: 2022-02-05
encoder : Lavf58.45.100
  Duration: 00:38:59.68, start: 0.00, bitrate: 564 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), 
yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 430 kb/s, 24.98 fps, 25 tbr, 
12800 tbn (default)
Metadata:
  handler_name: VideoHandler
  vendor_id   : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 96000 Hz, mono, 
fltp, 125 kb/s (default)
Metadata:
  handler_name: SoundHandler
  vendor_id   : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> av1 (libsvtav1))
  Stream #0:1 -> #0:1 (aac (native) -> opus (libopus))
Press [q] to stop, [?] for help
[libopus @ 0x564c58b50d80] No bit rate set. Defaulting to 64000 bps.
Svt[info]: ---
Svt[info]: SVT [version]:   SVT-AV1 Encoder Lib v1.6.0
Svt[info]: SVT [build]  :   GCC 12.3.0   64 bit
Svt[info]: ---
Svt[error]: Instance 1:  MinQpAllowed must be smaller than MaxQpAllowed
Svt[error]: Instance 1 : Invalid use_qp_file. use_qp_file must be [0 - 1]
[libsvtav1 @ 0x564c58b51d80] Error setting encoder parameters: bad parameter 
(0x80001005)
Error initializing output stream 0:0 -- Error while opening encoder for output 
stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[libopus @ 0x564c58b50d80] 1 frames left in the queue on closing
Conversion failed!

If any further information is required, please do not hesitate to let me
know.

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

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

Versions of packages ffmpeg depends on:
ii  libavcodec597:5.1.3-1
ii  libavdevice59   7:5.1.3-1
ii  libavfilter87:5.1.3-1
ii  libavformat59   7:5.1.3-1
ii  libavutil57 7:5.1.3-1
ii  libc6   2.37-6
ii  libpostproc56   7:5.1.3-1
ii  libsdl2-2.0-0   2.28.1+dfsg-1
ii  libswresample4  7:5.1.3-1
ii  libswscale6 7:5.1.3-1

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends

[Scott Kitterman]

On Thursday, July 20, 2023 10:58:03 AM EDT Piotr Ożarowski wrote:
> [Scott Kitterman, 2023-07-20]
> 
> > I had to override dh_python3 to add --no-guessing-deps in the latest
> 
> FTR: you can override detection with debian/py3dist-overrides (see
> dh_python3's manpage or /usr/share/doc/dh-python/README.PyDist for more
> details)
> 
> > dnspython upload because it was getting things wrong.  Here's what it
> > generated:
> > 
> > python3-httpcore | python3 (<< 3.8), python3-sniffio, python3:any
> > 
> > The correct answer here is actually use python3:any.  Here's what I
> > think is going on:
> > 
> > From the pyproject.toml file:
> > 
> > [tool.poetry.dependencies]
> > python = "^3.8"
> > httpx = {version=">=0.24.1", optional=true, python=">=3.8"}
> > httpcore = {version=">=0.17.3", optional=true, python=">=3.8"}
> > h2 = {version=">=4.1.0", optional=true, python=">=3.8"}
> > idna = {version=">=2.1,<4.0", optional=true}
> > cryptography = {version=">=2.6,<42.0", optional=true}
> > trio = {version=">=0.14,<0.23", optional=true}
> > sniffio = {version="^1.1", optional=true}
> > wmi = {version="^1.5.1", optional=true}
> > aioquic = {version=">=0.9.20", optional=true}
> > 
> > ...
> > 
> > [tool.poetry.extras]
> > doh = ['httpx', 'h2']
> > idna = ['idna']
> > dnssec = ['cryptography']
> > trio = ['trio']
> > wmi = ['wmi']
> > doq = ['aioquic']
> > 
> > There are two issues:
> > 
> > 1.  httpcore and sniffio shouldn't be listed at all.  They are optional.
> > I suspect that either poetry or dh-python is looking at the extras
> > section and since those packages aren't listed for one of the extras, it
> > assumes the package is required, despite the optional flag.  They
> > probably should be listed somewhere (upstream bug), but I think if it
> > says optional, it shouldn't be added to Depends.
> 
> dh_python3 doesn't look at source files. It generates dependencies by
> parsing installed requires.txt file so IMHO it's an upstream / poetry bug
> 
> > 2.  Generating an optional depends on python3 << 3.8 isn't helpful.  It
> > looks to me like {version=">=0.17.3", optional=true, python=">=3.8"} is
> > being mis-interpreted.  I believe the intent here is to say that the
> > dependency is optional when python3 > 3.8, not you need it if python3 >
> 
> can you show me how poetry / pyproject / whatever parsed this file
> interpreted it? I.e. what's in installed requires.txt
> 
> (I suspect it's a hard dependency there)
> 
> > 3.8.  There's a larger question of why the interpreter version is there
> > at all, given that's now the minimum python3 version supported, but
> > that's an upstream issue, we ought to get it right.
> 
> I agree

I have so far managed to avoid learning anything about how poetry works 
internally (learning about flit fully exhausted my curiosity in this area).  

Emmanuel,

Can you help out with this?

Thanks,

Scott K

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

Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends

[Piotr Ożarowski]

[Scott Kitterman, 2023-07-20]
> I had to override dh_python3 to add --no-guessing-deps in the latest

FTR: you can override detection with debian/py3dist-overrides (see
dh_python3's manpage or /usr/share/doc/dh-python/README.PyDist for more
details)

> dnspython upload because it was getting things wrong.  Here's what it
> generated:
> 
> python3-httpcore | python3 (<< 3.8), python3-sniffio, python3:any
> 
> The correct answer here is actually use python3:any.  Here's what I
> think is going on:
> 
> From the pyproject.toml file:
> 
> [tool.poetry.dependencies]
> python = "^3.8"
> httpx = {version=">=0.24.1", optional=true, python=">=3.8"}
> httpcore = {version=">=0.17.3", optional=true, python=">=3.8"}
> h2 = {version=">=4.1.0", optional=true, python=">=3.8"}
> idna = {version=">=2.1,<4.0", optional=true}
> cryptography = {version=">=2.6,<42.0", optional=true}
> trio = {version=">=0.14,<0.23", optional=true}
> sniffio = {version="^1.1", optional=true}
> wmi = {version="^1.5.1", optional=true}
> aioquic = {version=">=0.9.20", optional=true}
> 
> ...
> 
> [tool.poetry.extras]
> doh = ['httpx', 'h2']
> idna = ['idna']
> dnssec = ['cryptography']
> trio = ['trio']
> wmi = ['wmi']
> doq = ['aioquic']
> 
> There are two issues:
> 
> 1.  httpcore and sniffio shouldn't be listed at all.  They are optional.
> I suspect that either poetry or dh-python is looking at the extras
> section and since those packages aren't listed for one of the extras, it
> assumes the package is required, despite the optional flag.  They
> probably should be listed somewhere (upstream bug), but I think if it
> says optional, it shouldn't be added to Depends.

dh_python3 doesn't look at source files. It generates dependencies by
parsing installed requires.txt file so IMHO it's an upstream / poetry bug

> 2.  Generating an optional depends on python3 << 3.8 isn't helpful.  It
> looks to me like {version=">=0.17.3", optional=true, python=">=3.8"} is
> being mis-interpreted.  I believe the intent here is to say that the
> dependency is optional when python3 > 3.8, not you need it if python3 >

can you show me how poetry / pyproject / whatever parsed this file
interpreted it? I.e. what's in installed requires.txt

(I suspect it's a hard dependency there)

> 3.8.  There's a larger question of why the interpreter version is there
> at all, given that's now the minimum python3 version supported, but
> that's an upstream issue, we ought to get it right.

I agree

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Holger Levsen]

On Wed, Jul 19, 2023 at 04:31:56PM -0700, Vagrant Cascadian wrote:
> > sbuild: use predictible build paths (closes: #1034424)
> Very most highly excellent news! Thanks! :)

very much agreed, exciting times ahead! thank you! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

A ship is always safe at shore, but that is not what it's built for.
(Albert Einstein)


signature.asc
Description: PGP signature

Bug#1041540: udev: Failed to get cgroup, ignoring: No medium found

[Sven Joachim]

Package: udev
Version: 254~rc2-3

On boot I see the following message, which seems to come from udev in
the initramfs (see src/udev/udevd.c):

Failed to get cgroup, ignoring: No medium found

Obviously systemd is not running yet which could explain the complaint,
but to an unsuspecting user the ENOMEDIUM error code is not very
comprehensible.


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

Kernel: Linux 6.3.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udev depends on:
ii  adduser  3.137
ii  libacl1  2.3.1-3
ii  libblkid12.38.1-6
ii  libc62.37-6
ii  libcap2  1:2.66-4
ii  libkmod2 30+20230519-1
ii  libselinux1  3.5-1
ii  libudev1 254~rc2-3
ii  systemd-dev  254~rc2-3

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  254~rc2-3

-- no debconf information

Bug#1038668: veryfasttree_4.0.1+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Wed, Jul 19, 2023 at 07:05:32PM +0200 schrieb Thorsten Alteholz:
> On 11.07.23 21:40, Andreas Tille wrote:
> > uploaded with GPL-3.  Thanks for quick checking
> 
> as César confirmed, the code from  Stephane Guindon was already present in
> fasttree-2.1.10.c and really came from an very old version of pyhml that was
> still licensed under GPL-2+.
> So your original entry in debian/copyright was correct.

Yippy. ;-)

> I accepted the current upload with the GPL-3 entry now, but maybe you can
> change it back in a later upload.

Fixed in source only upload.

Thanks for accepting in any case
   Andreas. 

-- 
http://fam-tille.de

Bug#1020473: Interest in patch?

[Andreas Tille]

Hi Soren,

Am Wed, Jul 19, 2023 at 02:42:27PM -0700 schrieb Soren Stoutner:
> Would you be interested in a patch implementing this functionality?

Yes, for sure, as always.  I'm quite busy with other stuff so a patch
will always speed up things.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1030895: qt6-webengine: Enable riscv64 support

[Patrick Franz]

Hi,

On Sat, 15 Apr 2023 23:32:53 +0800 Bo YU  wrote:
[...]
> Could you try it on the next upload?
> 
> Thanks again for all here.

Before we can consider applying this patch, there is the question of 
maintenance. I am not very keen on having a 12.000-line patch to 
maintain for qtwebengine which in itself is already hard to maintain.

Just for fun, I tried to apply the patch to the recently released Qt 
Webengine 6.5.2 and unfortunately, a significant number of hunks from 
various subpackages could not be applied and would have to be 
readjusted. I'm afraid we'll run into the very same problem for each new 
Qt release. And that makes such a patch unsuitable.

So, unless you have an idea how to avoid running into this problem...


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1041539: dla-3309: Wrong CVE description / text

[Christian Fischer]

Package: www.debian.org
Severity: normal

I would like to point out a possible problem in the description of the 
following DSA advisory:


https://www.debian.org/lts/security/2023/dla-3309

It includes text about a "SourceCodester" product while the CVEs are 
actually about graphite-web like shown here:


https://security-tracker.debian.org/tracker/CVE-2022-4728
https://security-tracker.debian.org/tracker/CVE-2022-4729

Regards,

Bug#1040841: texstudio: enable terminal build option

[Tom Jampen]

close 1040841
thanks

Hi Axel

On 7/17/23 13:58, Axel Kittenberger wrote:
> I'm very sorry, I overlooked that on this machine "which texstudio"
> resulted in "/usr/local/bin/texstudio".

Thanks for clearing up the issue, I'm glad it works for you now.

Regards
Tom

Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends

[Scott Kitterman]

Package: dh-python
Version: 5.20230603
Severity: normal

I had to override dh_python3 to add --no-guessing-deps in the latest
dnspython upload because it was getting things wrong.  Here's what it
generated:

python3-httpcore | python3 (<< 3.8), python3-sniffio, python3:any

The correct answer here is actually use python3:any.  Here's what I
think is going on:

>From the pyproject.toml file:

[tool.poetry.dependencies]
python = "^3.8"
httpx = {version=">=0.24.1", optional=true, python=">=3.8"}
httpcore = {version=">=0.17.3", optional=true, python=">=3.8"}
h2 = {version=">=4.1.0", optional=true, python=">=3.8"}
idna = {version=">=2.1,<4.0", optional=true}
cryptography = {version=">=2.6,<42.0", optional=true}
trio = {version=">=0.14,<0.23", optional=true}
sniffio = {version="^1.1", optional=true}
wmi = {version="^1.5.1", optional=true}
aioquic = {version=">=0.9.20", optional=true}

...

[tool.poetry.extras]
doh = ['httpx', 'h2']
idna = ['idna']
dnssec = ['cryptography']
trio = ['trio']
wmi = ['wmi']
doq = ['aioquic']

There are two issues:

1.  httpcore and sniffio shouldn't be listed at all.  They are optional.
I suspect that either poetry or dh-python is looking at the extras
section and since those packages aren't listed for one of the extras, it
assumes the package is required, despite the optional flag.  They
probably should be listed somewhere (upstream bug), but I think if it
says optional, it shouldn't be added to Depends.

2.  Generating an optional depends on python3 << 3.8 isn't helpful.  It
looks to me like {version=">=0.17.3", optional=true, python=">=3.8"} is
being mis-interpreted.  I believe the intent here is to say that the
dependency is optional when python3 > 3.8, not you need it if python3 >
3.8.  There's a larger question of why the interpreter version is there
at all, given that's now the minimum python3 version supported, but
that's an upstream issue, we ought to get it right.

Scott K

Bug#1041537: python3 platlib points again to /usr/local

[Enrico Zini]

Package: meson
Version: 1.2.0-1
Severity: serious

Hello,

Thank you for maintaining Meson!

At first glance it looks like there is a regression of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026312

On stable:

   $ cat meson.build
   project('test', 'cpp', version: '3.36', license : 'GPL-2.0-or-later')
   
   pymod = import('python')
   python3 = pymod.find_installation('python3', required: false)
   message('PLATLIB', python3.get_path('platlib'))
   
   $ meson setup /tmp/zz
   The Meson build system
   Version: 1.0.1
   Source dir: [...]
   Build dir: /tmp/zz
   Build type: native build
   Project name: test
   Project version: 3.36
   C++ compiler for the host machine: ccache c++ (gcc 12.2.0 "c++ (Debian 
12.2.0-14) 12.2.0")
   C++ linker for the host machine: c++ ld.bfd 2.40
   Host machine cpu family: x86_64
   Host machine cpu: x86_64
   Program python3 found: YES (/usr/bin/python3)
   Message: PLATLIB /usr/lib/python3/dist-packages


On sid:

   $ cat meson.build
   project('test', 'cpp', version: '3.36', license : 'GPL-2.0-or-later')
   
   pymod = import('python')
   python3 = pymod.find_installation('python3', required: false)
   message('PLATLIB', python3.get_path('platlib'))
   
   $ meson setup /tmp/zz
   The Meson build system
   Version: 1.2.0
   Source dir: [...]
   Build dir: /tmp/zz
   Build type: native build
   Project name: test
   Project version: 3.36
   C++ compiler for the host machine: c++ (gcc 13.1.0 "c++ (Debian 13.1.0-8) 
13.1.0")
   C++ linker for the host machine: c++ ld.bfd 2.40.90.20230714
   Host machine cpu family: x86_64
   Host machine cpu: x86_64
   Program python3 found: YES (/usr/bin/python3)
   Message: PLATLIB /usr/local/lib/python3.11/dist-packages


This is affecting wreport, and I guess the same list of packages as
#1026312


Enrico


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
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 meson depends on:
ii  ninja-build1.11.1-1
ii  python33.11.4-5
ii  python3-pkg-resources  68.0.0-1
ii  python3-setuptools 68.0.0-1

Versions of packages meson recommends:
ii  dpkg-dev  1.21.22

meson suggests no packages.

-- no debconf information

Bug#1041536: debian-installer: The WPA/WPA2 PSK passphrase was either too long

[nicolaqu]

Package: debian-installer
Version: installation-report
Severity: important
Tags: d-i

Dear Maintainer,

I tried to install debian via pxe but I get the error
"The WPA/WPA2 PSK passphrase was either too long"
In the logs I found this: "INFO: Reached timeout for link detection on
enp2s0". Probably due to my slow pxe server.
So in my preseed I put: "d-i netcfg/link_wait_timeout string 10"
Then I tried to relaunch the installation getting the same error.
However, the value of 10 seconds is not taken into account in the logs:
"netcfg[2341]: INFO: Waiting time set to 3"

It's probably the same bug that caused the problem: Bug#999771
This problem was also in the bullseye.
Unfortunately I have not found any solution.

-- System Information:
Debian Release: 12.0
  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-9-amd64 (SMP w/32 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

Bug#1041054: dracut-network

[Laszlo]

Hello Team,

I opened an MR to resolve this -
https://salsa.debian.org/debian/dracut/-/merge_requests/23 .

As an upstream dracut maintainer, I'd like to add that:

1./ network-legacy is still likely the most tested and trusted dracut
networking backend. The entire dracut upstream testing is still on
network-legacy as other networking backends are not yet stable.

2./ network-manager requires dbus in initramfs, which is known to have
problems - https://github.com/dracutdevs/dracut/issues/2378

3./ Not all dracut kernel command line options are supported by all
dracut networking backends -
https://github.com/dracutdevs/dracut/issues/1876


Benjamin, if you have a chance to test other Dracut networking backends
(e.g. systemd-networkd or perhaps even connman) on Debian and report back
that would be useful both for the Debian and for the Dracut upstream
communities.

Best,
  Laszlo

Bug#1041535: transition: libcamera 0.1.0

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for libcamera 0.1.0.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 0.3.74-1) builds fine with the
new libcamera in experimental.

Thanks,
Dylan

Bug#1041533: xen-system-amd64: Xen fails to start hvm type VMs when a vncpasswd is set

[Claus R. Wickinghoff]

Package: xen-system-amd64
Version: 4.17.1+2-gb773c48e36-1
Severity: important

Dear Maintainer,

after upgrading my bullseye server to bookworm I ran into the issue that all 
VMs of type hvm are not starting anymore.

xl throws an error:
libxl: error: libxl_qmp.c:1399:qmp_ev_fd_callback: Domain 8:error on QMP 
socket: Connection reset by peer
libxl: error: libxl_qmp.c:1438:qmp_ev_fd_callback: Domain 8:Error happened with 
the QMP connection to QEMU
libxl: error: libxl_dm.c:3371:device_model_postconfig_done: Domain 8:Post DM 
startup configs failed, rc=-26
libxl: error: libxl_create.c:1896:domcreate_devmodel_started: Domain 8:device 
model did not start: -26
libxl: error: libxl_aoutils.c:646:libxl__kill_xs_path: Device Model already 
exited
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 8:Non-existant 
domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 8:Unable to 
destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 8:Destruction of 
domain failed

I started digging around in this QMP stuff and installed Xen freshly on another 
server with the actual bookworm iso, but the problem is the same there, too.

After reading the log of the VM I found this error:
xen-qemu-system-i386: -vnc 172.17.2.3:1,password=on,to=99: Cipher backend does 
not support DES algorithm

When disabling the vncpassword (and keeping the rest of the VM configuration 
untouched), xl is able to launch the VM properly.

I searched around for a while but I did not find any configuration option for 
choosing the cipher used by vnc.

Running vnc without password is a potential security risk.

I hope you have a clue to either fix this or extend the documentation on this.

Best regards
Claus


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

Kernel: Linux 6.1.0-10-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

Versions of packages xen-system-amd64 depends on:
ii  xen-hypervisor-4.17-amd64  4.17.1+2-gb773c48e36-1
ii  xen-hypervisor-common  4.17.1+2-gb773c48e36-1
ii  xen-utils-4.17 4.17.1+2-gb773c48e36-1

xen-system-amd64 recommends no packages.

xen-system-amd64 suggests no packages.

-- no debconf information

Bug#1040906: Re: Fwd: Bug#1040906: please add support for LoongArch CPU Loongson-3A5000-HV

[zhangdandan]

Hi，
  Thanks for your interest and reply.
>Do you by chance know which C-#ifdef protects code for this
>architecture? (E.g. on alpha this is __alpha__)
To define LoongArch target, you can use the __loongarch__.
If you want to use other C/C++ preprocessor macros related to the 
LoongArch architecture,

please visit LoongArch-toolchain-conventions Documentation [1].

[1]:https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html#_cc_preprocessor_built_in_macro_definitions 



thanks,
Dandan Zhang

Bug#1041532: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Robin Alexander]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package odr-dabmod that is part of
the Opendigitalradio DAB/DAB+ broadcasting chain. 

 * Package name : odr-dabmod
   Version  : 2.6.0-1
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/mmbtools
 * License  : GPL-3.0+ with autoconf exception, LGPL-3, Apache-
2.0, EXPAT, BSD-3-Clause, Expat, GPL-3.0+, FSFAP, GPL-2+ with Autoconf-
data exception, GPL-2.0+
 * Vcs  : https://salsa.debian.org/ralex/odr-dabmod
   Section  : hamradio

The source builds the following binary packages:

  odr-dabmod - DAB modulator compliant to ETSI EN 300 401

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

  https://mentors.debian.net/package/odr-dabmod/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmod/odr-dabmod_2.6.0-1.dsc

Changes for the initial release:

 odr-dabmod (2.6.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #1007104

Regards,



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

Bug#1041531: RFS: odr-audioenc/3.3.1-1 [ITP] -- DAB and DAB+ encoder that integrates into the ODR-mmbTools

[Robin Alexander]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package odr-audioenc that is part of
the DAB/DAB+ broadcasting chain. 

 * Package name : odr-audioenc
   Version  : 3.3.1-1
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/mmbtools
 * License  : Apache-2.0, Fraunhofer-FDK-AAC-for-Android,
Expat, GPL-2+ with Autoconf-data exception, GPL-3+ with Autoconf-
2.0~Archive exception, GPL-3.0+, FSFAP, apple-free, LGPL-2.1+, GPL-2.0+
 * Vcs  :
https://github.com/opendigitalradio/debian-audioenc
   Section  : contrib/hamradio

The source builds the following binary packages:

  odr-audioenc - DAB and DAB+ encoder that integrates into the ODR-
mmbTools

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

  https://mentors.debian.net/package/odr-audioenc/

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

  dget -x
https://mentors.debian.net/debian/pool/contrib/o/odr-audioenc/odr-audioenc_3.3.1-1.dsc

Changes for the initial release:

 odr-audioenc (3.3.1-1) unstable; urgency=medium
 .
   * Initial release. Closes: #1008124

Regards,




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

Bug#1041530: knot-resolver: does't start, flood syslog with error message about wrong path

[Petr Slansky]

Package: knot-resolver
Version: 5.6.0-1
OS: Debian GNU/Linux 12 (bookworm)

I installed knot-resolver; apt install knot-resolver
It doesn't start and log file /var/log/syslog is filled with messages
"Error: /var/cache/knot-resolver does not exist or is not a LMDB."

/var/log/syslog:

2023-07-20T14:07:59.024997+02:00 server systemd[1]: Created slice
system-kresd.slice - Slice /system/kresd.
2023-07-20T14:07:59.067938+02:00 server systemd[1]: Started
kres-cache-gc.service - Knot Resolver Garbage Collecto
r daemon.
2023-07-20T14:07:59.080597+02:00 server systemd[1]: Reached target
kresd.target - Knot Resolver daemons.
2023-07-20T14:07:59.324941+02:00 server kres-cache-gc[17168]: Knot
Resolver Cache Garbage Collector, version 5.6.0
2023-07-20T14:07:59.331578+02:00 server kres-cache-gc[17168]: Error:
/var/cache/knot-resolver does not exist or is not a LMDB.
2023-07-20T14:08:00.333478+02:00 server kres-cache-gc[17168]: Error:
/var/cache/knot-resolver does not exist or is not a LMDB.

Bug#1041525: ITP: arcos-desktop -- The ArcOS Project

[David Bremner]

Izaak Kuipers  writes:

> ArcOS is an Operating System Environment built using web technologies. It uses
> svelte, making it easy to maintain and blazingly fast. For more information
> about the ArcOS project, be sure to check out the website. The ArcOS team is
> also ready to talk to you through our Discord server!

Since you currently only supply windows MSI installers, perhaps you can
fill us in a bit on how you plan to package ArcOS for Debian. Perhaps
more importantly, maybe you can explain what advantage being shipped
with Debian will provide for users; what kind of OS integration is
possible, and why would installing via debian be better than installing
a package from your site as is currently done for Windows.

Bug#1039699: Adding students/teachers with gosa fails due to LDAP and postcreate command errors

[Guido Berhoerster]

>From Daniel:

uid=maxmus,ou=people,ou=Students,dc=skole,dc=skolelinux,dc=no
sn: Mustermann
givenName: Maxim
uid: maxmus
homePostalAddress:; ^M\

cn: Maxim Mustermann
postalAddress:; ^M\

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount

- postalAddress + homePostalAddress are buggy
- posixAccount is missing
- gidNumber is missing

and more, see the Student account template:

uid=newstudent,ou=people,ou=Students,dc=skole,dc=skolelinux,dc=no
objectClass: top   
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount
objectClass: gosaUserTemplate
objectClass: posixAccount
objectClass: shadowAccount
sn: NewStudent
givenName: NewStudent
uid: newstudent
cn: NewStudent NewStudent
homeDirectory: /skole/tjener/home0/%uid
loginShell: /bin/bash
uidNumber: 1002
gidNumber: 1002
gecos: NewStudent NewStudent



Using gosa on Debian bullseye to create a student produces this:

# mamus, people, Students, skole.skolelinux.no
dn: uid=mamus,ou=people,ou=Students,dc=skole,dc=skolelinux,dc=no
sn: Mustermann
givenName: Max
uid: mamus
cn: Max Musterschueler
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount


So apart from the homePostalAddress and postalAddress which shouldn't
be relevant to the problem at hand it seems identical to bookworm.

The student template seems to be identical as well:

# newstudent, people, Students, skole.skolelinux.no
dn: uid=newstudent,ou=people,ou=Students,dc=skole,dc=skolelinux,dc=no
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount
objectClass: gosaUserTemplate
objectClass: posixAccount
objectClass: shadowAccount
sn: NewStudent
givenName: NewStudent
uid: newstudent
cn: NewStudent NewStudent
homeDirectory: /skole/tjener/home0/%uid
loginShell: /bin/bash
uidNumber: 1002
gidNumber: 1002
gecos: NewStudent NewStudent


-- 
Guido Berhoerster

Bug#1041529: gqrx-sdr: unsatisfiable build dependencies

[Étienne Mollier]

Source: gqrx-sdr
Version: 2.15.9-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

Dear Maintainer,

gqrx-sdr currently fails to build from source due to
unsatisfiable build dependencies:

# apt-get build-dep gqrx-sdr
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:gqrx-sdr : Depends: libvolk2-dev but it is not installable
E: Unable to correct problems, you have held broken packages.

Upon further investigation, this looks to be caused by the
collision between gnuradio-dev and libvolk2-dev, the former
depending on libvolk-dev (unversioned) which in turn conflicts
with libvolk2-dev:

# apt-get install --dry-run gnuradio-dev libvolk2-dev 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libvolk2-dev is already the newest version (2.5.2-3).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libvolk-dev : Breaks: libvolk2-dev but 2.5.2-3 is to be installed
 libvolk2-dev : Breaks: libvolk-dev but 3.0.0-2 is to be installed
E: Unable to correct problems, you have held broken packages.

Removing the build dependency on libvolk2-dev and relying on the
libvolk-dev being pulled by gnuradio-dev looks to do the trick
on my end.

In hope this helps,
Have a nice day,  :)
Étienne.

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

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

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/7, please excuse my verbosity
   `-on air: Kingcrow - Right Before


signature.asc
Description: PGP signature

Bug#1041528: RFP: jsontestsuite -- comprehensive test suite for RFC 8259 compliant JSON parsers

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jsontestsuite
  Version : 0+20210227
  Upstream Contact: Nicolas Seriot 
* URL : https://github.com/nst/JSONTestSuite
* License : Expat
  Programming Lang: JSON
  Description : comprehensive test suite for RFC 8259 compliant JSON parsers

 JSON Parsing Test Suite is a comprehensive test suite
 for RFC 8259 compliant JSON parsers.

This project is useful as testsuite for JSON parser and validators.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS5IvoACgkQLHwxRsGg
ASHlHw/+MarDO+iwj9YXeAWtoOdWvJefvq/MWZKZWDfJChEq8CutJyXdiKtueWC7
CToC90JFAidy8tF5jUnmM7rWUyIA1eRqVe2d88bbk3lhFPbH6tcgOcyvQxzZ1Tuz
e1xbhL6iAE1g6/0qjY4Xnsgo5XjUVWs7FfwJKl02OOVvGQIH/CBFoEE2Z+qoELY7
jgL8ykJfVUnLhxm8xZg3hOEQqomq8poHBmHc2o54K7y5/zM3lMqyZGM1BmsmF0nw
c5mlP4oqKLmu7U1uN1Kthc/0Q8j8jamD8qRcOO1EuoaKqYnWd8p83mDkey3dFFha
yMg1bcyghT3kfMjhphMu2NU9WrpTcsuOftyB6F47foayfEA9bG+joup1+i94WBcm
F2aJSeP9Xk3NzgIvsYwulHao+GVH1uznCvsfYv69tYyDT79YQKBhOaYRy2cJQcwy
5WS8Y+wRRa36n0BpO3nvQXj4RzNdrGxQ2BM/rQpUA+WlrWTLwQBlo3NdvqLhAqRL
esZkeMQ1XbetLulEXA6tBIrR0ropzbsfNxEwI9VZaMspY1ygpl9c+KrpodDDyrsJ
OEo/mgescXN1egKbzgAybCg/pdmc8cxyqF5EQgPajKlBgJPSV4yiXHQ0TMKOxKrF
ogtH8piZrOmXbEClDGM3rql4emJUp8eIX4A64OntyaDBSyXoOSU=
=R6w4
-END PGP SIGNATURE-

Bug#1039911: transition: sdl12-compat taking over libsdl1.2-dev

[Simon McVittie]

On Sun, 16 Jul 2023 at 18:18:09 +0100, Simon McVittie wrote:
> On Sun, 16 Jul 2023 at 18:55:28 +0200, Sebastian Ramacher wrote:
> > Could you check whether that is an issue in sdl12-compat or
> > libsdl-perl?
>
> I already opened  and marked it as
> blocking this transition-tracker bug.

After talking to SDL upstream, it looks as though libsdl-perl was always
doing something that ought to be undefined behaviour (freeing the global
video surface object, which is "owned" by the SDL video implementation),
but an implementation quirk of libsdl1.2 meant that attempting to free
the global video surface was silently ignored.

The regression with sdl12-compat is because sdl12-compat is more likely
to deallocate the global video surface and allocate a new one, whereas
libsdl1.2 would usually keep using the same global video surface for the
lifetime of the process, even if parameters like the colour depth changed.

Possible solutions to continue this transition:

1. fix libsdl-perl (#1041211, RC; I sent a potential patch upstream, but
   I've never tried writing Perl XS bindings before, so I'm not very
   confident that I'm getting it right)

2. work around the issue in sdl12-compat because they aim for bug-for-bug
   compatibility (#1041416, wishlist, also forwarded upstream), after
   which #1041211 can be downgraded to non-RC

3. kick out libsdl-perl, dizzy, frozen-bubble and pangzero from testing
   until at least one of those two bugs can be fixed
   (I've checked with `dak rm -R -n -s testing` that those four source
   packages would be enough)

Or wait until one of those happens, and if we wait long enough with no
progress, autoremovals will implement (3) for us.

smcv

Bug#1041526: virtiofsd - No copying from Windows possible.

[Holger Schröder]

Package: virtiofsd
Version: 1.7.0-1
Severity: normal

Dear Maintainer,

With virtiofsd 1.7.0, nothing can be copied from the Windows guest to the host
system. It works the other way around. With 1.6.1 there was no problem, it
always worked reliably. There is nothing about it in the logs. On the host
system you will find only a 0 byte file.



Regards
 Holger...


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/16 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)

Versions of packages virtiofsd depends on:
ii  libc62.37-6
ii  libcap-ng0   0.8.3-1+b3
ii  libgcc-s113.1.0-8
ii  libseccomp2  2.5.4-1+b3

virtiofsd recommends no packages.

virtiofsd suggests no packages.

-- no debconf information

Bug#1041497: vmm: fails to run with python3 >= 3.10

[Pascal Volk]

On 2023-07-19 20:20, Bernd Zeimetz wrote:

[...]
AttributeError: module 'collections' has no attribute 'Callable'


collections.Callable is collections.abs.Callable since Python 3.10
[...]


Hi there,

this has been fixed in 
https://bitbucket.org/pvo/vmm/commits/29d157a4ee8f019fde92aa74976e9f168386a0fe/raw


Regards,
Pascal

Bug#1041527: Please update to OpenJFX 17

[Amr Ibrahim]

Package: openjfx

Hello,

Please update to the latest LTS OpenJFX 17 (17.0.8+2).

https://github.com/openjdk/jfx17u/tags

Best,
Amr

Bug#1041525: ITP: arcos-desktop -- The ArcOS Project

[Izaak Kuipers]

Package: wnpp
Severity: wishlist
Owner: Izaak Kuipers 
X-Debbugs-Cc: debian-de...@lists.debian.org, izaak.kuip...@gmail.com

* Package name: arcos-desktop
  Version : 5.0.8
  Upstream Contact: Izaak Kuipers 
* URL : https://izk-arcos.nl/
* License : GPLv3
  Programming Lang: TS
  Description : The ArcOS Project

ArcOS is an Operating System Environment built using web technologies. It uses
svelte, making it easy to maintain and blazingly fast. For more information
about the ArcOS project, be sure to check out the website. The ArcOS team is
also ready to talk to you through our Discord server!

Bug#988509: building kernel modules on a multiarch host fails

[Константин Савин]

As a clue.. you may use the DEB_HOST_GNU_CPU
*,* just try

> *DEB_HOST_GNU_CPU=amd64* *aptitude* {*install*|*safe-upgrade*|...}
>

Bug#1040183: Acknowledgement (zfs-initramfs: snapshots for rootfs mounted in /root/.zfs/snapshot)

[Richard van den Berg]

Tags: bookworm, fixed

It looks like this has been fixed in 2.1.12: 
https://github.com/openzfs/zfs/pull/14920


2.1.12-1 is already in unstable. Please consider including this fix in 
Debian stable (bookworm) as well.

Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking

[Thomas Parmelan]

Package: logcheck
Version: 1.4.3
Severity: normal
Tags: patch
X-Debbugs-Cc: tom+deb...@ankh.fr.eu.org

Dear maintainers,

The systemd journal is checked by default, in addition to rsyslog files,
starting with logcheck version 1.4.1. But the format of timestamps are
different by default for journal (uses the old-school format: "Jul 20
11:51:03") and rsyslog >= 8.2210.0-3 (uses an RFC3339-compatible format:
"2023-07-20T11:51:03.046581+0200"). So logcheck cannot compare them
correctly.

Also, journalctl can emit multi-line logs, whereas rsyslog cannot.

The attached patch adds a new ISO_TIMESTAMPS config variable to the logcheck
script, allowing logcheck to:
  - call journalctl with "-o short-iso-precise" in order to get a
nearly-RFC3339-compatible timestamp
  - add the missing ':' between the timezone hours and minutes to convert the
journalctl shot-iso-precise timestamp to the exact RFC3339 timestamp
format used by rsyslog
  - join continuous lines (lines starting with whitespace) from
journalctl output, as rsyslog only logs them as one line
  - handle SORTUNIQ correctly even when using ISO_TIMESTAMPS

I have been using this locally since early March.

(NB in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032197 I also
suggested to make journalctl use the "correct" timestamp format; if/when
this actually gets done, the "second sed action" in my logcheck patch
can be dropped)

Regards,
Tom

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

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

Versions of packages logcheck depends on:
ii  adduser 3.137
ii  cron [cron-daemon]  3.0pl1-162
ii  lockfile-progs  0.1.19
ii  logtail 1.4.3
ii  mime-construct  1.12+really1.11-1
ii  postfix [mail-transport-agent]  3.8.1-2

Versions of packages logcheck recommends:
ii  logcheck-database  1.4.3

Versions of packages logcheck suggests:
ii  rsyslog [system-log-daemon]  8.2306.0-2

-- 
Thomas Parmelan
--- logcheck.1.4.3	2023-07-20 11:03:01.945539427 +0200
+++ logcheck	2023-07-20 11:02:09.184636208 +0200
@@ -90,6 +90,7 @@
 REBOOT=0
 FQDN=0
 SORTUNIQ=0
+ISO_TIMESTAMPS=1
 SUPPORT_CRACKING_IGNORE=0
 SYSLOGSUMMARY=0
 LOCKDIR=/run/lock/logcheck
@@ -480,6 +481,10 @@
 		local JOURNALCTL_OPTS=() OPTS=()
 		local offsetfile offsettime
 
+		if [ "$ISO_TIMESTAMPS" -eq 1 ]; then
+		JOURNALCTL_OPTS+=("-o" "short-iso-precise")
+		fi
+
 		# There are some problems with this section.
 		debug "logoutput called with file: $file"
 		if [ -f "$file" ]; then
@@ -508,7 +513,13 @@
 offsettime="--since=-5h"
 		fi
 		debug "Running $JOURNALCTL ${JOURNALCTL_OPTS[*]} -q $offsettime"
+		# first sed action: join lines starting with whitespace
+		# (source: https://www.gnu.org/software/sed/manual/html_node/Joining-lines.html)
+		# second sed action: convert ISO8601 timestamps (as generated by journalctl -o short-iso-precise)
+		# to RFC3339 timestamps (as generated by rsyslog)
 		"$JOURNALCTL" "${JOURNALCTL_OPTS[@]}" --quiet "$offsettime" \
+	| sed -E ':a ; $!N ; s/\n\s+/ / ; ta ; P ; D' \
+	| sed -E 's/^([0-9T:.+-]{29})/\1:/' \
 	>> "$TMPDIR/logoutput/$file" 2>&1 \
 || error "Could not run journalctl or save output"
 		touch "$offsetfile"
@@ -602,13 +613,6 @@
 		INTRO=1
 fi
 
-# Use sort -u or -k 1,3 -s
-if [ "$SORTUNIQ" -eq 1 ];then
-		SORT="sort -u"
-else
-		SORT="sort -k 1,3 -s"
-fi
-
 # Set the mime encoding if required (blank means auto-detected)
 if [ -n "$MIMEENCODING" ]; then
 		ENCODING=(--encoding "$MIMEENCODING")
@@ -780,8 +784,20 @@
 # First sort the logs to remove duplicate lines (including from different logfiles with
 # the same lines) to reduce CPU and memory usage.
 debug "Sorting logs"
-$SORT "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' > "$TMPDIR/logoutput-sorted" \
+# Use "sort -u" or "sort ... | uniq"
+if [ "$SORTUNIQ" -eq 1 ];then
+	SORT_OPTS="-u"
+	sort $SORT_OPTS "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' > "$TMPDIR/logoutput-sorted" \
+		|| error "Could not save sorted log content to $TMPDIR/logoutput-sorted"
+else
+	if [ "$ISO_TIMESTAMPS" -eq 1 ]; then
+	SORT_OPTS="-k 1 -s"
+	else
+	SORT_OPTS="-k 1,3 -s"
+	fi
+	sort $SORT_OPTS "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' | uniq > "$TMPDIR/logoutput-sorted" \
 		|| error "Could not save sorted log content to $TMPDIR/logoutput-sorted"
+fi
 debug "After sorting, we have the following log entries to check" "$TMPDIR/logoutput-sorted"
 
 # See if the logoutput-sorted file actually has data to check,

Bug#1041523: tracker.debian.org: displays autopkgtest for other src:package on same page

[Martin-Éric Racine]

Package: tracker.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The tracker at  shows autopkgtest 
results for both this src:package and for another src:package.

While the two packages are related, they are NOT the same package.

src:dhcpcd is the only src:package that should be tracked by this page. 
src:dhcpcd5 should be tracked by its own existing page.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmS5CngACgkQrh+Cd8S0
17agfhAAhLTK9gTHfX3K9LXWp23n6Z7i0QWgstakul89zGxIzd1wucR22rpn4n6g
bIcMkoBDrCZ9OUaM8icZQiL5zvFzt7ug45weOoMN225mOtbe5iwQ5pWeoF1WeVZP
ieNaYIhE28ITWNaE5nBuFBuY8QRUHC+YXJfgljysJcYh7IvCeuoF+2wn/SWRRURI
xinWvFNzFdN9+bnWKqriVZnrQw9BY5rt+oyES8foUTlj9bLbxkhqc7nIwWC7hFCe
Rh/Mxt4/HagvDcpIRiuAPqnSc0cBAg63cOpo0cN+1q+cp29fkmPVCbV9Ip4RcrVW
HMjSyWnJpkhD3lLVVLdlkNT7+3ArIN18/H4Q85ao5C8cwUaZmE+H2tK3jKX9r5sc
8WHKDPaiuZbt5bvnKp0uVnyXbXdgU/N7hH+rZbmbIReX0sPsSnOtCyzHD3ALFQ2M
Rm3Rbl7KVbgRzGQgT6LtpYnpfQlFUG7dd4dqbuFKi5TUz5v9618LhGwJv7QXFqEF
ouVIKfgme7vER/nU4cVg4OtVdOTCN+eFrLjr4FGcYQAmVbdS+Eryz79NqGFHoEWu
O9S92iDwUyUy7VGdElAAzKX5n74GbWzWv3ZCgHtOxWAF6zpc4qRycPdaoDBQbpAw
IC2S5HqHri/hCsdORyGODCfEkhqaIW3iqpFOekdJp/GeOSCgWCI=
=ApSG
-END PGP SIGNATURE-

Bug#1040733: docopt.cpp: autopkgtest failure due to new CMake deprecation warning

[Gianfranco Costamagna]

Dear maintainer,

I've prepared an NMU for docopt.cpp (versioned as 0.6.2-2.4) and
uploaded.

Regards.

diff -Nru docopt.cpp-0.6.2/debian/changelog docopt.cpp-0.6.2/debian/changelog
--- docopt.cpp-0.6.2/debian/changelog   2021-08-17 05:44:44.0 +0200
+++ docopt.cpp-0.6.2/debian/changelog   2023-07-20 11:52:23.0 +0200
@@ -1,3 +1,11 @@
+docopt.cpp (0.6.2-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump minimum required cmake version to 3.11 to fix autopkgtests
+(Closes: #1040733)
+
+ -- Gianfranco Costamagna   Thu, 20 Jul 2023 
11:52:23 +0200
+
 docopt.cpp (0.6.2-2.3) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru docopt.cpp-0.6.2/debian/tests/docopt.cpp-examples 
docopt.cpp-0.6.2/debian/tests/docopt.cpp-examples
--- docopt.cpp-0.6.2/debian/tests/docopt.cpp-examples   2020-07-25 
07:18:18.0 +0200
+++ docopt.cpp-0.6.2/debian/tests/docopt.cpp-examples   2023-07-20 
11:52:21.0 +0200
@@ -9,7 +9,7 @@
 cd $AUTOPKGTEST_TMP

 cat << EOF > CMakeLists.txt
-cmake_minimum_required(VERSION 3.0)
+cmake_minimum_required(VERSION 3.11)
 project(docopt.cpp-examples)

 find_package(docopt)

On Sun, 09 Jul 2023 23:03:01 +0200 roehl...@debian.org wrote:

Source: docopt.cpp
Version: 0.6.2-2.3
Severity: important
User: roehl...@debian.org
Usertags: cmake3.27

Dear maintainer,

your package docopt.cpp will soon experience autopkgtest failures
because the new CMake release 3.27 will issue a deprecation warning
on stderr if cmake_minimum_required() asks for compatibility with
CMake 3.4 or older.

You can check for the exact failure on the cmake pseudo-excuses page
from experimental:
https://qa.debian.org/excuses.php?experimental=1=cmake

For a more in-depth discussion, kindly refer to the debian-devel
thread: https://lists.debian.org/debian-devel/2023/06/msg00150.html

Cheers

Timo




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040723: cppzmq: autopkgtest failure due to new CMake deprecation warning

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/zeromq/cppzmq/pull/608

Hello, I patched and forwarded upstream.
Please
G.
On Sun, 09 Jul 2023 23:03:00 +0200 roehl...@debian.org wrote:

Source: cppzmq
Version: 4.9.0-1
Severity: important
User: roehl...@debian.org
Usertags: cmake3.27

Dear maintainer,

your package cppzmq will soon experience autopkgtest failures because
the new CMake release 3.27 will issue a deprecation warning on stderr
if cmake_minimum_required() asks for compatibility with CMake 3.4 or
older.

You can check for the exact failure on the cmake pseudo-excuses page
from experimental:
https://qa.debian.org/excuses.php?experimental=1=cmake

For a more in-depth discussion, kindly refer to the debian-devel
thread: https://lists.debian.org/debian-devel/2023/06/msg00150.html

Cheers

Timo

Bug#1039604: glusterfs: Drop support for 32-bit architectures

[Michael Tokarev]

20.07.2023 11:40, Patrick Matthäi wrote:
..

I have uploaded glusterfs 11.0-1 to experimental, it is limited to these 
architectures:
amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64


Build-Depends: architecture-is-64-bits

fwiw, anyway.  Ok.


So if nobody rises up I would start to fill bugs for the reverse dependencies 
in the next days and after that uploading glusterfs 11.x to unstable.


It's an unfortunate timing: I uploaded new qemu a few minutes
before this your reply. Sure thing it went in without the
gluster-related changes.  I now fixed the [architecture]
list in there in qemu - next upload will have no deps on
gluster on 32bits.

Doing the same for samba as well now, - next samba will have
no deps on glusterfs on 32bits too.


What happens with stable, there I do not have an answer, yet.


What's about stable? the version of gluster in stable should
not be affected.


IMO the best way would be continue to use dh_install, there you can also limit 
the architectures:
     [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64] 
debian/tmp/usr/lib/foo/gluster.so


That's dh-exec, but yes. Somehow I dislike dh_exec personally :)

/mjt

Bug#1041323: CFEngine agent connection errors

[Guido Berhoerster]

On a related note, these error only shows up when cf-agent is run by cf-execd.
Invoking it manually works fine.

-- 
Guido Berhoerster

Bug#1041522: portmidi: new upstream available

[Debian/GNU]

Source: portmidi
Severity: normal

Dear Maintainer,

thanks for packaging portmidi.

unfortunately, it seems that Debian is lagging behind seriously.
PortMidi-217 (as found in Debian) was released in 2010.
However, the latest and greatest PortMidi release is v2.0.4 and was
released in late 2022.

Hooray for using another versioning scheme!
(but then: Debian already uses an epoch, so we are probably safe :-))

The sourceforge page ships v2.0.2 (released in early 2022), but it seems
that the project has now moved to GitHub
  https://github.com/PortMidi/portmidi

Please update the package.

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets

[Andreas Tille]

Hi,

Am Thu, Jul 20, 2023 at 12:57:11PM +0800 schrieb Bo YU:
> ...
> Oh, thanks you told me the background so today I learned many here.
> 
> I think it is okay i push the update to the salsa repo directly as
> your suggestion.

Thank you for your contribution and welcome in the team
   Andreas. 

-- 
http://fam-tille.de

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets

[Étienne Mollier]

Hi Bo,

Bo YU, on 2023-07-20:
> On Thu, Jul 20, 2023 at 2:27 AM Étienne Mollier  wrote:
> > Bo YU, on 2023-07-19:
> > > I am looking for a sponsor for my package "spades":
> > […]
> > > Changes since the last upload:
> > >
> > >  spades (3.15.5+dfsg-2.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> >
> > If you happen to go by the Salsa login vimerbf-guest, then you
> > should have direct access to push directly to the team
> > maintained repository.  Don't hesitate to work there, and ping
> > the debian-med[1] list once you are happy with your changes and
> > they are ready for "Team upload.".  ;)
> >
> Yeah, it is me. I just got access at yesterday so I am not sure I can
> follow the workflow of Debian med team. But now I can try after your
> confirmation.:)

In case your haven't come by it yet, you can have a look and
bookmark the Debian Med policy manual here[1].  These guidelines
ensure rough consistency between packages under Debian Med
umbrella; there are about one thousand and a half.

[1]: https://med-team.pages.debian.net/policy/

If you agree to it, please feel free to proceed, git easily
allows reverting changes anyway; just don't force push without
discussing the matter on the mailing list first.

> > >* Fix ftbfs on gcc-13. (Closes: #1037863)
> >
> > Thanks for your help fixing that bug, and also for the forward
> > upstream.  My only matter for head scratching is the following
> > hunk in your patch:
> >
> > --- a/assembler/ext/src/llvm/Signals.inc
> > +++ b/assembler/ext/src/llvm/Signals.inc
> > @@ -43,6 +43,7 @@
> >  #include "llvm/Support/Program.h"
> >  #include "llvm/Support/SaveAndRestore.h"
> >  #include "llvm/Support/raw_ostream.h"
> > +#include "llvm/Support/Signals.h"
> >  #include 
> >  #include 
> >  #include 
> >
> > Including cstdint would have probably been less intrusive, and
> > solves the build failure as far as I could test.  Was there a
> > specific reason to include the whole llvm/Support/Signals.h
> > instead of just cstdint?
> >
> Okay, I rebuild the package again without the change, it works.
> I recalled the background, maybe it messed up due to previous
> error I ignored. In fact, maybe I overlooked the log:
> ```
> [ 46%] Building CXX object 
> ext/llvm/CMakeFiles/llvm-support.dir/StringMap.cpp.o
> In file included from /<>/assembler/ext/src/llvm/Signals.cpp:219:
> /<>/assembler/ext/src/llvm/Signals.inc:347:50: error:
> 'void llvm::sys::CleanupOnSignal(uintptr_t)' should have been declared
> inside 'llvm::sys'
>   347 | void llvm::sys::CleanupOnSignal(uintptr_t Context) {
> ```
> 
> I will clean up the change for here and upstream.

Sounds good, let us know once you pushed your modification.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Neal Morse - So Many Roads


signature.asc
Description: PGP signature

Bug#1041323: CFEngine agent connection errors

[Guido Berhoerster]

This is fixed by allowing "127.0.0.1" and "::1" to connect to cf-serverd in
cf3/promises.cf. There also seems to be a typo regarding the local network:

…
body server control
# Debian Edu specific
{
  allowconnects => { "10.0.0.0.0/8" };
  allowallconnects  => { "10.0.0.0.0/8" };
  trustkeysfrom => { "10.0.0.0.0/8" };
…

After changing this to

…
body server control
# Debian Edu specific
{
  allowconnects => { "127.0.0.1", "::1", "10.0.0.0/8" };
  allowallconnects  => { "127.0.0.1", "::1", "10.0.0.0/8" };
  trustkeysfrom => { "10.0.0.0/8" };
…

the agent connects but then aborts due to a different error about an
untrusted server key:


Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No suitable 
server found for '/var/lib/cfengine3/inputs'
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
belongs to bundle 'failsafe_cfe_internal_update' in file 
'/var/lib/cfengine3/inputs/failsafe.cf' near line 121
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
encountered when actuating files promise '/var/lib/cfengine3/inputs'
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1> 
SSL_write: underlying network error (Broken pipe)
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   SSL_write: underlying network error (Broken pipe)
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1> 
Connection was hung up!
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   Connection was hung up!
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No suitable 
server found for '/var/lib/cfengine3/modules'
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
belongs to bundle 'failsafe_cfe_internal_update' in file 
'/var/lib/cfengine3/inputs/failsafe.cf' near line 130
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
encountered when actuating files promise '/var/lib/cfengine3/modules'
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1> 
SSL_write: underlying network error (Broken pipe)
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   SSL_write: underlying network error (Broken pipe)
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1> 
Connection was hung up!
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   Connection was hung up!
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1> 
Connection was hung up while receiving line:
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   Connection was hung up while receiving line:
Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1> 
Client closed connection early! He probably does not trust our key...
Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>  
   Client closed connection early! He probably does not trust our key...
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No suitable 
server found for '/var/lib/cfengine3/inputs'
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
belongs to bundle 'failsafe_cfe_internal_update' in file 
'/var/lib/cfengine3/inputs/failsafe.cf' near line 144
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Comment is 
'If we failed to fetch policy we try again using
  the 
legacy default in case we are fetching policy
  from a 
hub that is not serving mastefiles via a
  shortcut.'
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
encountered when actuating files promise '/var/lib/cfengine3/inputs'
Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Method 
'failsafe_cfe_internal_update' failed in some repairs
Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  TRUST 
FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  No suitable 
server found for 

Bug#1041521: OpenSSH: problematic interaction between GSSAPI Key Exchange and publickey in 8.9p1 and newer

[Sergio Gelato]

Source: openssh
Version: 1:9.2p1-2

Symptom: ssh fails with "sign_and_send_pubkey: internal error: initial hostkey 
not recorded".

This issue was reported upstream in 
https://bugzilla.mindrot.org/show_bug.cgi?id=3406 and rejected because it's a 
flaw in the GSSAPI key exchange patch. However, Damien Miller was kind enough 
to provide a hint in Comment 2.

To trigger it, one needs to (a) perform a successful GSSAPI key exchange, (b) 
attempt public key authentication. (In addition, the client and the server must 
both have the hostbound authentication protocol extension enabled for the 
problem to manifest itself. This is on by default in bookworm.) This is 
probably not a very common combination, but it can happen if one has Kerberos 
credentials for the correct realm but the wrong user, and a private key for the 
right user.

I suppose an ambitious developer might try to provide a functional equivalent 
to the host key binding that leverages the GSSAPI key exchange, instead of 
Damien Miller's one-statement suggestion.

A likely workaround for affected clients until this gets fixed is to set 
pubkeyauthentication=unbound as needed.

Bug#1041432: box64: unsatisfiable dependencies

[Adrian Bunk]

On Thu, Jul 20, 2023 at 08:28:23AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi Adrian,

Hi Josch,

> thank you for weighing in!
> 
> Quoting Adrian Bunk (2023-07-20 01:27:10)
> > 
> > Package: box64
> > Architecture: amd64 arm64 ppc64el riscv64
> > Depends:
> >  libgcc-s1:amd64,
> >  libstdc++6:amd64,
> > 
> > A package must not assume that the user has other architectures enabled.
> 
> why not? Is this codified in a policy somewhere? If foreign architectures are
> not enabled, box64 would just not be installable but there are tons of 
> packages
> I cannot install on my system without the package itself being buggy (for
> example due to Conflicts).
>...

testing migration checks that for every binary package from the source 
package there exists a configuration where it can be installed,[1] and 
that the migration does not make any other binary package currently in 
testing uninstallable on any architecture.

E.g. an alternative init system must be installable, but it can 
obviously not be installed at the same time as the default init system.

There is not even a requirement that all binary packages from a source 
package can be installed at the same time (often this is not possible).
 
> If I just drop these dependencies, that would make the package have an RC bug
> because box64 cannot function without amd64 shared libraries.

Yes.

>...
> It seems that the correct way forward would be to teach britney about foreign
> architecture dependencies? I had a look at the britney source and it seems to
> ship with its own dependency resolver instead of relying on dose3, for 
> example.
> Teaching it about foreign architectures looks like a massive change...
>...

This would be a huge can of worms in many places, for relatively fringe 
usecases.

My first question would be whether all dependency resolvers apt might 
use support it properly.

And the higher level issue how your package should be used on derivates 
that do not support all architectures, which is not uncommon for exactly 
the kind of hardware your package is intended for. Should [2] also be
required to ship packages for all other Debian release architectures 
like amd64 and s390x?

>...
> > For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might be 
> > an
> > option (untested).
> 
> Those packages install their libraries into /usr/ which is not
> searched by the dynamic linker. Maybe some LD_LIBRARY_PATH trickery can make 
> it
> work but those shared libraries are not meant for running actual binaries.

Just make the hardcoded location in the sources of your package configurable:

src/steam.c:strcpy(tmp, 
"BOX64_LD_LIBRARY_PATH=/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:");
src/main.c:if(FileExist("/lib/x86_64-linux-gnu", 0))
src/main.c:AddPath("/lib/x86_64-linux-gnu", >box64_ld_lib, 1);
src/main.c:if(FileExist("/usr/lib/x86_64-linux-gnu", 0))
src/main.c:AddPath("/usr/lib/x86_64-linux-gnu", >box64_ld_lib, 
1);
src/wrapped/wrappedlibdl.c:if(!strcmp(rfilename, 
"/usr/lib/x86_64-linux-gnu/d3d")) {

> Thanks!
> 
> cheers, josch

cu
Adrian

[1] For binary-all this is not required for all architectures and only 
checked for amd64 and arm64.
[2] http://raspbian.raspberrypi.org/raspbian/dists/bookworm/

Bug#1041520: RM: haskell-hoogle [mipsel armel armhf i386] -- RoQA; ANAIS; restricted to 64-bit architectures (resource hog), broken on 32-bit

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: haskell-hoo...@packages.debian.org

hoogle is a resource hog and installation takes extremely log on 32-bit
architectures (#1020246) and according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020246#15 it is
completely broken on 32-bit architectures.

The package has been restricted to 64-bit architectures, please remove
the obsolete 32-bit binary packages.


Andreas

Bug#1041519: transmission: contains prebuilt javascript without source

[Alexandre Rossi]

Source: transmission
Version: 4.0.1-1
Severity: serious
Justification: Policy 2.2.1

Hi,

The source package contains:

web/public_html/index.html
web/public_html/transmission-app.js

These files are copied into the binary package as:

/usr/share/transmission/public_html/index.html
/usr/share/transmission/public_html/transmission-app.js

Those files should be built from source with no network connection.

The corresponding lintian overrides are wrong: the files are not generated
during build.

# these are generated from web/src/*
transmission source: source-is-missing [web/public_html/index.html]
transmission source: source-is-missing [web/public_html/transmission-app.js]

The sad way to solve this would be to remove the webui (and I'm a user!).

The better way to solve this would be to build and would begin like the 
following
but requires packaging some of the below npm deps. I can help and would 
appreciate
some guidance or pointers to good examples of source packages that have solved
this problem.

--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,9 @@ Build-Depends: cmake,
qttools5-dev-tools,
qttools5-dev,
libqt5svg5-dev,
-   zlib1g-dev
+   zlib1g-dev,
+   node-webpack,
+   node-mini-css-extract-plugin
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/debian/transmission
diff --git a/debian/rules b/debian/rules
index 09fe4f7d..bfed98c1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,12 +2,13 @@

 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export NPM_CONFIG_OFFLINE=true

 %:
dh $@

 override_dh_auto_configure:
-   dh_auto_configure -- -DENABLE_GTK=ON -DENABLE_QT=ON -DENABLE_CLI=ON 
-DINSTALL_LIB=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo
+   dh_auto_configure -- -DENABLE_GTK=ON -DENABLE_QT=ON -DENABLE_CLI=ON 
-DINSTALL_LIB=OFF -DREBUILD_WEB=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo

 override_dh_auto_test:
@echo "skipping auto test"

Thanks,

Alex

--
transmission.git/web$ npm2deb depends package.json

Dependencies:   
   NPM   Debian
transmission-web (FIX_ME version) None
└─ lodash.isequal (^4.5.0)node-lodash 
(4.17.21+dfsg+~cs8.31.198.20210220-9)

Build dependencies:
NPM   Debian
@babel/core (^7.20.12)node-babel 
(6.26.0+repack-3~bpo10+1) @babel/eslint-parser (^7.19.1)
None
@babel/plugin-proposal-class-properties (^7.18.6) None
@primer/stylelint-config (^12.7.0)None
css-loader (^6.7.3)   node-css-loader 
(6.7.2+~cs14.0.11-1) css-minimizer-webpack-plugin (^4.2.2) 
None
eslint (^8.32.0)  None
eslint-plugin-sonarjs (^0.18.0)   None
eslint-plugin-unicorn (^45.0.2)   None
file-loader (^6.2.0)  node-file-loader (6.2.0-3)
   mini-css-extract-plugin (^2.7.2)  
node-mini-css-extract-plugin (2.4.6+~2.4.0-4)npm-run-all (^4.1.5)   
   None
prettier (^2.8.3) None  
   sass (^1.57.1)None
sass-loader (^13.2.0) None
style-loader (^3.3.1) node-style-loader (3.3.1-2)   
   stylelint (^14.16.1)  None
stylelint-config-prettier (^9.0.4)None
stylelint-config-sass-guidelines (^9.0.1) None
stylelint-config-standard (^29.0.0)   None
terser-webpack-plugin (^5.3.6)None
webpack (^5.76.0) node-webpack 
(5.76.1+dfsg1+~cs17.16.16-1)webpack-bundle-analyzer (^4.7.0)
  None
webpack-cli (^4.10.0) None
webpack-dev-server (^4.11.1)  None

Warnings occurred:
 [warning] prettier: Useless in Debian compilation, see node-jest for an example


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

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

Bug#1039604: glusterfs: Drop support for 32-bit architectures

[Patrick Matthäi]

Hello,

Am 15.07.2023 um 08:54 schrieb Michael Tokarev:


Yes, I use libglusterfs-dev in Build-Depends of samba and qemu.
I think it is already reduced to 64bits on ubuntu for samba (or,
rather, i386 is excluded).

The question is: how to specify dependencies properly and more important,
how to specify lists of files to install?


I have uploaded glusterfs 11.0-1 to experimental, it is limited to these 
architectures:

amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64

So if nobody rises up I would start to fill bugs for the reverse 
dependencies in the next days and after that uploading glusterfs 11.x to 
unstable.


What happens with stable, there I do not have an answer, yet.



Right now I have:

 d/control: Build-Depends: libglusterfs-dev
 d/foo.install: /usr/lib/foo/gluster.so

I can change the first one to be something like

  Build-Depends: libglusterfs-dev [amd64 arm64]

So in your depends you should use:

    libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x 
ia64 sparc64]


(with a few questions remaining: what is the complete list? How
about non-linux?).  But what to do with the second, - move the
handling to d/rules, like

 if [ -f debian/tmp/usr/lib/foo/gluster.so ]; then
   install -D debian/tmp/usr/lib/foo/gluster.so -t 
debian/foo/usr/lib/foo/

 fi

IMO the best way would be continue to use dh_install, there you can also 
limit the architectures:
    [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64] 
debian/tmp/usr/lib/foo/gluster.so


You way would work, too. But if you want to build the glusterfs module, 
but it is not available (for whatever reason) you wouldnt notice it.

Bug#1040408: Extended Maintenance: repo.jing.rocks

[JING LUO]

The same message has been sent to

==
Hello there,

repo.jing.rocks will extend a planned hardware maintenance over this weekend:
>From 2023-07-20T10:00:00 UTC to 2023-07-23T16:00:00 UTC

Sorry for the short notice.

Bug#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Paul Wise]

On Tue, 2023-07-18 at 16:20 -0500, Karl Schmidt wrote:

> While popcon seems a good idea - it seems that data from repository
> downloads would do much the same job. 

User related statistics should be opt-in, turning on logs on the
repository mirrors would mean it would be impossible to opt-out.

> statistics on non Debian [.deb packages]

These are already present in the popcon data, see "unknown" on:

https://popcon.debian.org/

> and even non Deb package software installed.

There are so many different packaging ecosystems that this would be
infeasible. They also often have their own telemetry submissions.

> I would imagine a setting to identify locations of non Debian
> executables so such data could be collected.

I think this is a bit too invasive, these could be stored in /usr/local
or home directories, or /srv or /opt or random other directories.

> There is a pseudo-package bug - wnpp - that almost no one uses,

This is widely used, there are hundreds of open RFPs. Some of them even
result in someone doing the work to package things, #1041232 for eg.

> I would think that statistics on what is missing from Debian would be
> quite important.

In practice it is quite irrelevant, because something missing from
Debian that lots of people use doesn't mean any person has the time,
skills and motivation to package it nor that it will be possible to
package or even redistribute. Usually contributors have some form of
personal interest in the things they package for Debian, rather than
packaging popular things that they have no interest in.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1041518: transition: openstructure

[Andrius Merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I would like to request a transition slot for openstructure
(experimental -> unstable) due to soname bump. Current ben tracker [1]
is OK.

openstructure has a single reverse dependency, promod3, which also has 
to undergo a transition of its own, but since it is a leaf package I 
suppose I can transition them together. The updated promod3 is also 
waiting in experimental.


Thanks,
Andrius

[1] https://release.debian.org/transitions/html/auto-openstructure.html

Bug#1040629: Additional information

[Gianfranco Costamagna]

control: tags -1 patch pending

diff -Nru fdroidserver-2.2.1/debian/changelog 
fdroidserver-2.2.1/debian/changelog
--- fdroidserver-2.2.1/debian/changelog 2023-03-09 15:11:34.0 +0100
+++ fdroidserver-2.2.1/debian/changelog 2023-07-20 08:54:25.0 +0200
@@ -1,3 +1,13 @@
+fdroidserver (2.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  [ Vladimir Petko  ]
+  * debian/patches/image-alias-deprecation.patch:
+- cherry-pick upstream fix for new pillow 10.0.0
+  (Closes: #1040629, LP: #2028117)
+
+ -- Gianfranco Costamagna   Thu, 20 Jul 2023 
08:54:25 +0200
+
 fdroidserver (2.2.1-1) unstable; urgency=medium
 
   * New upstream version 2.2.1

diff -Nru fdroidserver-2.2.1/debian/patches/image-alias-deprecation.patch 
fdroidserver-2.2.1/debian/patches/image-alias-deprecation.patch
--- fdroidserver-2.2.1/debian/patches/image-alias-deprecation.patch 
1970-01-01 01:00:00.0 +0100
+++ fdroidserver-2.2.1/debian/patches/image-alias-deprecation.patch 
2023-07-20 08:54:23.0 +0200
@@ -0,0 +1,28 @@
+Description: do not use deprecated Image.ANTIALIAS attribute
+ The ANTIALIAS alias was removed in Pillow 10.0.0:
+ https://pillow.readthedocs.io/en/stable/deprecations.html
+Author: Hans-Christoph Steiner 
+Origin: upstream
+Bug: 
https://github.com/f-droid/fdroidserver/commit/132e953c8c9f7d709586442aee6ff474cfa8fa18
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040629
+Last-Update: 2023-07-19
+--- a/fdroidserver/update.py
 b/fdroidserver/update.py
+@@ -250,7 +250,7 @@
+
+ if any(length > size for length in im.size):
+ oldsize = im.size
+-im.thumbnail((size, size), Image.ANTIALIAS)
++im.thumbnail((size, size), Image.Resampling.LANCZOS)
+ logging.debug("%s was too large at %s - new size is %s" % (
+ iconpath, oldsize, im.size))
+ im.save(iconpath, "PNG", optimize=True,
+@@ -1757,7 +1757,7 @@
+
+ size = dpi_to_px(density)
+
+-im.thumbnail((size, size), Image.ANTIALIAS)
++im.thumbnail((size, size), Image.Resampling.LANCZOS)
+ im.save(icon_path, "PNG", optimize=True,
+ pnginfo=BLANK_PNG_INFO, icc_profile=None)
+ empty_densities.remove(density)
diff -Nru fdroidserver-2.2.1/debian/patches/series 
fdroidserver-2.2.1/debian/patches/series
--- fdroidserver-2.2.1/debian/patches/series2023-03-09 15:11:34.0 
+0100
+++ fdroidserver-2.2.1/debian/patches/series2023-07-20 08:54:16.0 
+0200
@@ -1,3 +1,4 @@
 debian-java-detection.patch
 ignore-irrelevant-test.patch
 scanner-tests-need-dexdump.patch
+image-alias-deprecation.patch

Bug#1041467: sanlock: systemd service uses unsupported option "watchdog-check"

[Dröge]

On Wed, 19 Jul 2023 19:30:21 +0200 =?UTF-8?Q?H=c3=a5vard_F=2e_Aasen?= 
<[[havard.f.aa...@pfft.no](mailto:havard.f.aa...@pfft.no)](mailto:[havard.f.aa...@pfft.no](mailto:havard.f.aa...@pfft.no))>
 wrote:  
> On Wed, 19 Jul 2023 11:26:44 +0200 =?utf-8?q?Lars_Dr=C3=B6ge?= 
> <[[lars.dro...@tu-dortmund.de](mailto:lars.dro...@tu-dortmund.de)](mailto:[lars.dro...@tu-dortmund.de](mailto:lars.dro...@tu-dortmund.de))>
>  wrote:  
> > Package: sanlock  
> > [...]
>  
> It seems that we use a rather old version of this file, created by the  
> first maintainer of the package. Upstream has a different file that has  
> the "watchdog-check" functionality implemented.  
>  
> > [...]
>  
> As a temporary solution it most likely is, the check can be run manually  
> if you want it. The "watchdog-check" only does two things, and is easy  
> to replicate.  
> Ensuring that the wdmd.service is stopped, then executing  
> wdmd --probe  
> If it is successful, everything is well and nothing more needs to be  
> done, if it fails, you should try to load the "softdog" kernel module  
> with  
> modprobe softdog && udevadm settle  
> The relevant part, that is missing from the Debian package, can be found  
> here [1].  
>  
>  
> For unstable, I will try to use upstream files for both the systemd  
> service's as well as their init.d scripts and configuration files. For  
> bookworm the easiest solution might be to just copy in the two missing  
> functions.  

Thank you very much for the quick and helpful support.

Best regards,  
Lars


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1041432: box64: unsatisfiable dependencies

[Johannes Schauer Marin Rodrigues]

Hi Adrian,

thank you for weighing in!

Quoting Adrian Bunk (2023-07-20 01:27:10)
> 
> Package: box64
> Architecture: amd64 arm64 ppc64el riscv64
> Depends:
>  libgcc-s1:amd64,
>  libstdc++6:amd64,
> 
> A package must not assume that the user has other architectures enabled.

why not? Is this codified in a policy somewhere? If foreign architectures are
not enabled, box64 would just not be installable but there are tons of packages
I cannot install on my system without the package itself being buggy (for
example due to Conflicts).

If I just drop these dependencies, that would make the package have an RC bug
because box64 cannot function without amd64 shared libraries.

> There is a general issue around such dependencies, and also the more specific
> problem that permitting cross-architecture dependencies would also require
> checking that migrating a package for one architecture does not break
> dependencies on other architectures.
> 
> For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might be an
> option (untested).

Those packages install their libraries into /usr/ which is not
searched by the dynamic linker. Maybe some LD_LIBRARY_PATH trickery can make it
work but those shared libraries are not meant for running actual binaries.

Originally, box64 upstream shipped their own binary blobs of libstdc++.so.6 and
libgcc_s.so.1 and installed them into /usr/lib/x86_64-linux-gnu/. This is of
course not an option either as that would conflict with users who do have amd64
packages installed and would also make the package violate DFSG for shipping
binaries without source.

It seems that the correct way forward would be to teach britney about foreign
architecture dependencies? I had a look at the britney source and it seems to
ship with its own dependency resolver instead of relying on dose3, for example.
Teaching it about foreign architectures looks like a massive change...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1041517: sendemail: when using starttls, SSL_verifycn_name is not set, leading to hostname verification failed

[Judit Foglszinger]

Package: sendemail  
Version: 1.56-5.1   
Severity: normal
Tags: patch 
 
Hi,

when using sendemail to send an email with
relay mail-submit.debian.org (uses starttls),
hostname verification fails -

$ sendEmail -o tls=yes -f "ur...@debian.org" \
-t recip...@example.org -s mail-submit.debian.org:587 \
-o message-file=/tmp/mail.txt \
-xu urbec -xp the-password-is-always-password  \
-u "Test email"
Jul 13 21:06:32 (...) sendEmail[11565]: ERROR => TLS setup failed: hostname 
verification failed
$

Non recent versions of SSL.pm also did show the following error message -
Use of uninitialized value $2 in concatenation (.) or string at 
/usr/share/perl5/IO/Socket/SSL.pm line 792.

The current version in sid replaces the missing hostname
with the sender's IP, so no error message beyond
"hostname verification failed" anymore.

(versions before bookworm just allowed IP addresses as always verified,
but that's no longer the case)

The following patch passes the hostname -

Description: Fix TLS hostname verification.
Author: Unit 193 
Forwarded: no

--- sendemail-1.56.orig/sendEmail
+++ sendemail-1.56/sendEmail
@@ -1930,7 +1930,10 @@ if( $conf{'use_sendmail'} ) {
 if ($conf{'tls_server'} == 1 and $conf{'tls_client'} == 1 and 
$opt{'tls'} =~ /^(yes|auto)$/) {
 printmsg("DEBUG => Starting TLS", 2);
 if (SMTPchat('STARTTLS')) { quit($conf{'error'}, 1); }
-if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 
'SSLv23:!SSLv2')) {
+if (! IO::Socket::SSL->start_SSL($SERVER,
+   SSL_version => 'TLSv12:!SSLv2',
+   SSL_verifycn_scheme => 'smtp',
+   SSL_verifycn_name => $conf{'server'})) {
 quit("ERROR => TLS setup failed: " . 
IO::Socket::SSL::errstr(), 1);
 }
 printmsg("DEBUG => TLS: Using cipher: ". $SERVER->get_cipher(), 3);

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