Bug#1054432: Not a bug

[Yadd]

Control: severity -1 wishlist

Files are readable

Bug#1055100: calibre: Installation in Bookworm stable is not possible. Paketdaten sind beschädigt.

[yokota]

Hello Martin,

> Entpacken von calibre (6.13.0+repack-2+deb12u1) ...
> dpkg-deb (Unterprozess): Dekomprimieren des Archivs
> »/var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb«
> (Größe=28871284), Element »data.tar«: lzma-Fehler: komprimierte Daten sind
> beschädigt
> dpkg-deb: Fehler: »«-Unterprozess gab den Fehlerwert 2 zurück
> dpkg: Fehler beim Bearbeiten des Archivs
> /var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb (--unpack):
>  »dpkg-deb --fsys-tarfile«-Unterprozess gab den Fehlerwert 2 zurück
> Fehler traten auf beim Bearbeiten von:
>  /var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

> Element »data.tar«: lzma-Fehler: komprimierte Daten sind beschädigt
>> Element "data.tar": lzma-Error: compressed Data is corrupted
It seems your download package file is broken.
This is not calibre's fault.

Remove broken package file in /var/cache/apt/archives/ and re-install
calibre from package manger, or download pacakge file manually from
Debian server at https://packages.debian.org/bookworm/calibre and
install proper package file.

> Versions of packages calibre depends on:
> pn  calibre-bin

You also needs "calibre-bin" pacakge to use calibre.
Install calibre-bin package from package manger.
Or, you can download it manually from Debian server at
https://packages.debian.org/bookworm/calibre-bin

--
YOKOTA

Bug#1053340: openjdk-17-jdk says 'A fatal error has been detected by the Java Runtime Environment'

[Vladimir Petko]

Hi,

 The crash appears to be originating from Defensics itself, I do not
have access to the software unfortunately to be sure about it. Would
it be possible to examine the core dump and check the stack trace?

Best Regards,
 Vladimir.

Bug#1055134: ITP: golang-github-bits-and-blooms-bloom -- Go package implementing Bloom filters, used by Milvus and Beego.

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-github-bits-and-blooms-bloom
  Version : 3.6.0-1
  Upstream Author : Will Fitzgerald
* URL : https://github.com/bits-and-blooms/bloom
* License : BSD-2-clause
  Programming Lang: Go
  Description : Go package implementing Bloom filters, used by Milvus and 
Beego.

 Bloom filters
 .
 A Bloom filter is a concise/compressed representation of a set, where
 the main requirement is to make membership queries; *i.e.*, whether an
 item is a member of a set. A Bloom filter will always correctly report
 the presence of an element in the set when the element is indeed
 present. A Bloom filter can use much less storage than the original set,
 but it allows for some 'false positives': it may sometimes report that
 an element is in the set whereas it is not.
 .
 This is a Go library for a bloom filter.

It is required by the latest Yggdrasil.

Bug#1055133: ITP: arpwitch -- A modern arpwatch replacement with JSON formatted outputs and easy options to exec commands when network changes are observed.

[Aquila Macedo Costa]

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

* Package name: arpwitch
  Version : 0.3.10
  Upstream Author : Nicholas de Jong 
* URL : https://github.com/ndejong/arpwitch
* License : BSD-2
  Programming Lang: Python3
  Description : A modern arpwatch replacement with JSON formatted outputs 
and easy options to exec commands when network changes are observed.

I'm writing to submit an Intention to Package (ITP) for arpwitch
under the Debian Python Team's umbrella.

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Arnaud Rebillout]

On 31/10/2023 22:36, Chris Lamb wrote:

tags 1055039 + pending
thanks

Hey Arnaud!


Long story below.

A huge thanks for tracking this down! I've gone ahead and removed
ProcSubset=pid from the systemd unit files, and am uploading a version
to unstable and experimental right now. However, do you think this
warrants an update to stable as well…? Thanks again.


I would say yes, upload to stable as well. At least for our use-case, it 
makes Redis unusable, that's pretty bad. I wish I could tell you more 
precisely what goes wrong in our case though...


I checked a bit more in the redis source code, to find reference to 
/proc (and not /proc/self):


  $ find -name '*.[ch]' | xargs grep -ho '[ "]/proc/[^ "]*' \
    | grep -v /self/ | tr -d ' ",.' |  sort | uniq -c
  1 /proc/cpuinfo
  1 /proc/curproc/map
  1 /proc/%d/maps
  1 /proc/%d/task/%d/maps
  1 /proc/%ld/psinfo
  1 /proc/%ld/smaps
  1 /proc//stat
  3 /proc/sys/net/core/somaxconn
  1 /proc/sys/net/ipv4/tcp_tw_reuse'
  8 /proc/sys/vm/overcommit_memory

To me, it suggests that yes, Redis needs full access to /proc to be 
fully functional.


Moreover, I see that ProcSusbset=pid caused some trouble already, that 
you fixed in 80470e3dc0ae56db9c9512c38a175783bcfc ;)


Looking at the part of the code that was touched by this patch, I see 
that Redis checks whether overcommit memory is enabled (function 
checkOvercommit), and it displays a big fat warning if ever it's not. I 
suppose that, with ProcSubset=pid, Redis won't be able to perform this 
check and won't be able to display this warning.


So, yep, I still think that it's better to backport this change to 
stable. If ever someone needs to re-enable ProcSubset=pid, maybe it will 
need more care. Better reach out to upstream to ask whether it's a good idea


Thank you very much for maintaining this package!

--

Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1000401: golang-github-go-git-go-git: please make the build reproducible

[Santiago Vila]

severity 1000401 normal
thanks

El 22/11/21 a las 16:55, Chris Lamb escribió:

Source: golang-github-go-git-go-git
Version: 5.4.2-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
golang-github-go-git-go-git could not be built reproducibly.

This is because the testsuite leaves a Git worktree (or similar)
around in a .tmp directory. A patch is attached that cleans this up
after running the tests.


Hello. While I can check that the patch seems to work (if I remember well
from the tests I did several days ago), I still wonder: How it is possible
that this patch works at all?

The program is already built when the tests are executed. How does the
outcome of the tests affects the package contents? (I don't see any git
repository when I do dpkg -c on the packages, for example).

Do you remember some detail about this?

Thanks.

Bug#1055116: rust-rustls, please prepare update for new ring.

[Jonas Smedegaard]

Control: block -1 by 1055132

Quoting Peter Green (2023-10-31 19:33:29)
> Package: rust-rustls
> 
> After a long wait, ring released version 0.17 which is far more portable than
> previous versions. The lack of portability of ring has been a thorn in the
> side of the rust team for some time so we would really like to upgrade.
> 
> The good news is that rustls has updated to the new version of ring *without*
> bumping semver. So hopefully this transition can be kept relatively small.
> 
> I've uploaded the new version of ring to experimental, could you prepare new
> versions of the rustls packages to work with it.

That's wonderful news.

I am happy to update rust-rustls, as soon as possible.  Seems to only
blocker is an transitive dependency on rust-rcgen needing an update as
well: See bug#1055132.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1055132: rust-rcgen: please update to v0.11.3

[Jonas Smedegaard]

Source: rust-rcgen
Version: 0.11.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.11.3.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVBnucACgkQLHwxRsGg
ASE+KxAAlIfygeQdnoL13C/bdRhT4sHJQD3H7jaUxGdjpSmOyspmPv6cljxWQsG4
rLQU7N8NgfcBf0VNOnubiMXkODUpm7VozjnRQAR+Yep3EfeP4WmQlsd83LHG4C7b
pgMjqqYccNY1O1VRGfpTxRTdi4cz7Vnn9gTh1HmfnKI3bnShfxezfRUu/7pYnQcZ
pQyOjr9yCjCxG4IyvonRMCcRXNfCci4BVC4CWLvk7wclzZkFQZsMISqDznm65HGd
3s1FrcInS0aIrxc9hNpj+LyWJZW0jCEL1irMOJ0eO3ZXOd8+UnZ4zLk0ux+wDWiV
+J3HwZz2Nm1r9HgGj2y+QVgMXWClzwI2rWD053oo1rEDa25JJ5aHn+u1KQ+aWyg0
ahfUy4okLmza0/oyYCwRjUcm+LtUjx89f6ebIGk3Lo9L1C4GWq0FTNwqnqGY8mzo
gcfm9iGkp78B57+joMvUbTEL7ihfqRHJOU8BJhjZg9tcHi/oN2zdkIYtmCJvh0qZ
+em4s1bHLFg/Vg6CpVXgW+BORcuNcUETSHaUSAGSMyqhmCvMbDXPhf42gKWZDaJ4
iTWKZv9+Pxc8rTLVl0G4/VRtfKhEIPxsq43FKYP2Iz1SLNnrreYTfc4KoHAHKTg1
okizPmIYmXGUZA7xoVQAjQfbuX87wxiVaHxw3ssRbu5S4hW70FQ=
=DnnQ
-END PGP SIGNATURE-

Bug#1055131: RFS: lighttpd/1.4.73-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.73-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.73-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Important changes in lighttpd 1.4.73:
* HTTP/2 detect and log rapid reset attack
While lighttpd is not affected by HTTP/2 rapid reset attacks any more
than by other DoS attacks, changes have been made to lighttpd to detect
and log when a rapid reset attack occurs, and to close the HTTP/2
connection.  Log watchers might subsequently use the trace to block IPs.

The goal is to make lightpd 1.4.73 available in unstable, testing,
and then backports (or sloppy-backports) to maintained Debian versions.

Please advise next steps.
Thank you.  Glenn

P.S. The version of lighttpd in Debian Experimental is 1.4.71-1+exp1
 and can be retired.

Bug#1055130: ITP: geopm-service -- Global Extensible Open Power Manager Service

[Brad Geltz]

Package: wnpp
Severity: wishlist
Owner: Brad Geltz 
X-Debbugs-Cc: debian-de...@lists.debian.org,christopher.m.cantal...@intel.com

* Package name: geopm-service
  Version : 3.0.0
  Upstream Author : Intel
* URL : https://github.com/geopm/geopm
* License : BSD-3-Clause
  Programming Lang: C, C++, Python
  Description : Global Extensible Open Power Manager Service

The GEOPM Service provides a user-level interface to read telemetry and
configure settings of heterogeneous hardware platforms. Linux system
administrators may manage permissions for user access to telemetry and
configuration at a fine granularity. This package includes the geopm
systemd service unit that provides a DBus interface io.github.geopm.
Additionally the libgeopmd.so shared object library is installed with
this package.

The GEOPM Service software is openly developed and maintained by Intel.

More information can be found at:  https://geopm.github.io.

System Information: Currently only supports amd64 / x86_64 CPU architectures.

Bug#1055111: ffmpeg FTBFS: makeinfo: Undefined subroutine ::Config::set_from_init_file called at doc/t2h.pm

[Sebastian Ramacher]

Hi Hilmar

On 2023-10-31 23:15:03 +0100, Hilmar Preuße wrote:
> > https://buildd.debian.org/status/logs.php?pkg=ffmpeg=7%3A6.0-8
> > 
> > ...
> > makeinfo --html -I doc --no-split -D config-not-all 
> > --init-file=/<>/doc/t2h.pm --output doc/ffmpeg.html 
> > /<>/doc/ffmpeg.texi
> > makeinfo: error parsing /<>/doc/t2h.pm: Undefined subroutine 
> > ::Config::set_from_init_file called at /<>/doc/t2h.pm 
> > line 24.
> > make[2]: *** [/<>/doc/Makefile:70: doc/ffmpeg.html] Error 1
> > 
> Could it be caused the upload of TeXinfo 7.1, did it work with TeXinfo from
> testing? I don't see any change for this in the
> /usr/share/doc/texinfo/NEWS.gz .

It is caused by texinfo 7.1, yes. Builds with texinfo from testing work
fine.

Cheers
-- 
Sebastian Ramacher

Bug#1055128: [request-tracker-maintainers] Bug#1055128: request-tracker5: Incorrect CVE mentioned in request-tracker5 changelog

[Andrew Ruthven]

Control: found 1055128 5.0.5+dfsg-1

On Wed, 2023-11-01 at 09:11 +1100, Geoff Crompton wrote:
> I noticed in the changelog entry for 5.0.3+dfsg-3~deb12u2
> CVE-2023-41620 is mentioned. But the description fro that CVE matches
> the description for CVE-2023-41260 on
> https://docs.bestpractical.com/release-notes/rt/5.0.5
> 
> I think there is a minor typo in the changelog. I noticed this typo is
> also present in the changelog for 5.0.5+dfsg-1 on
> https://metadata.ftp-master.debian.org/changelogs//main/r/request-
> tracker5/request-tracker5_5.0.5+dfsg-1_changelog.

Dammit. I was double checking those. Thank you for raising this.

I've pushed commits to fix these in the next upload of each version, but I
won't upload new versions just to fix this.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#1055111: ffmpeg FTBFS: makeinfo: Undefined subroutine ::Config::set_from_init_file called at doc/t2h.pm

[Hilmar Preuße]

On 10/31/23 17:21, Adrian Bunk wrote:

Hi,


https://buildd.debian.org/status/logs.php?pkg=ffmpeg=7%3A6.0-8

...
makeinfo --html -I doc --no-split -D config-not-all --init-file=/<>/doc/t2h.pm 
--output doc/ffmpeg.html /<>/doc/ffmpeg.texi
makeinfo: error parsing /<>/doc/t2h.pm: Undefined subroutine 
::Config::set_from_init_file called at /<>/doc/t2h.pm line 24.
make[2]: *** [/<>/doc/Makefile:70: doc/ffmpeg.html] Error 1

Could it be caused the upload of TeXinfo 7.1, did it work with TeXinfo 
from testing? I don't see any change for this in the 
/usr/share/doc/texinfo/NEWS.gz .


Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055129: libgpiod: Please upload v2.0.2 to Debian

[Diederik de Haas]

Source: libgpiod
Version: 1.6.3-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Upstream has v2.0.2 of libgpiod and it would be great to have that in
the Debian archive, so hereby the request to package it.

Cheers,
  Diederik

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZUF6IQAKCRDXblvOeH7b
blWrAQDPUsY1BhtrwXWdijxg8B9pbJTO7KKvT5MHt9q8TiHzwAD8CSCG4Rhx58GJ
/irGK0/jEo1/RWsFCh34tdcT/G8Gsg4=
=2PAD
-END PGP SIGNATURE-

Bug#1055128: request-tracker5: Incorrect CVE mentioned in request-tracker5 changelog

[Geoff Crompton]

Package: request-tracker5
Version: 5.0.3+dfsg-3~deb12u2
Severity: minor

Dear Maintainer,

I noticed in the changelog entry for 5.0.3+dfsg-3~deb12u2
CVE-2023-41620 is mentioned. But the description fro that CVE matches
the description for CVE-2023-41260 on 
https://docs.bestpractical.com/release-notes/rt/5.0.5

I think there is a minor typo in the changelog. I noticed this typo is
also present in the changelog for 5.0.5+dfsg-1 on
https://metadata.ftp-master.debian.org/changelogs//main/r/request-tracker5/request-tracker5_5.0.5+dfsg-1_changelog.


Kind regards,
Geoff Crompton

Bug#1052330: comment about the attached hs_err log files

[Vladimir Petko]

Hi,

I apologise for the late reply.

I have tried to reproduce the issue but had no luck so far.

I wonder if it would be possible to provide a sample project and a
list of plugins installed to reproduce the crash. Or produce a core
dump by adding -XX:+CreateCoredumpOnCrash in eclipse.ini and enable
core dumps in your system?

I am also wondering if WebView is at fault[1]. The Eclipse SWT project
lists another memory corruption bug[2]. Would it be possible to try to
investigate with ElectricFence[3] as described in the comment?

Best Regards,
 Vladimir.

[1] https://github.com/eclipse-platform/eclipse.platform.swt/labels/Linux%2FGTK
[2] https://github.com/eclipse-platform/eclipse.platform.swt/issues/592
[3] 
https://github.com/eclipse-platform/eclipse.platform.swt/issues/592#issuecomment-1513433434

Bug#1055123: efivar builds with -march=native on !ia64

[Aurelien Jarno]

Hi,

On 2023-10-31 22:43, Adrian Bunk wrote:
> Source: efivar
> Version: 38-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=efivar=38-1
> 
> -march=native is a baseline violation on architectures where
> it is supported, and causes a FTBFS on architectures where
> it is not supported.

This is correct if the resulting binaries are shipped in the package
which is not the case here, so I am not sure this bug warrants the
serious severity.

Anyway at least for riscv64 there is a patch available upstream [1].

Regards
Aurelien

[1] 
https://github.com/rhboot/efivar/commit/aab4e9b10ac9e98588a1b19771cf6f4c8c0a3096

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1055126: procps: pgrep and pidwait are identical. one should by a symlink to the other

[Craig Small]

On Wed, 1 Nov 2023 at 08:15, Ani Hay  wrote:

> Instead of wasting all this space one should be a symlink to the other.
>
39 kilobytes is not exactly a lot.

Bug#1055117: FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

[Mauricio Oliveira]

Hi Troy,

> On Tue, Oct 31, 2023 at 4:16 PM Troy Heber  wrote:
> > Yep, it was a mistake in my upload. I have already tried to include it
> > in an 8.0.3-2 upload already but couldn't figure out a way to force the push
> > of an updated orig.tar.gz so I'm waiting for help form the FTP
> > masters to get it replaced with the proper one. Do you know of any
> > way for me to force the replacement without their assistance?

On Tue, Oct 31, 2023 at 4:21 PM Mauricio Oliveira
 wrote:
> No, unfortunately I'm not familiar with another method; I think
> archive administrators would be the right option!

I realize this is not exactly what you're looking for, which is
replacing the _orig_ tarball,
but it is possible to include the gdb tarball in the _debian_ tarball
(d/s/include-binaries),
if this is something that would suit your packaging preferences.

$ cd crash-8.0.3
$ wget http://ftp.gnu.org/gnu/gdb/gdb-10.2.tar.gz
$ patch -p1 -F0 

crash-8.0.3-gdb-10.2.debdiff
Description: Binary data

Bug#1055127: [l10n] Updated Czech translation of apt-listchanges

[Miroslav Kure]

Package: apt-listchanges
Severity: wishlist
Tags: l10n, patch

Hi,

in attachement there is updated Czech (cs.po) translation of 
apt-listchanges. Please include it with the package.

Thank you
-- 
Miroslav Kuře
# Czech translation of apt-listchanges.
# Copyright (C) 2005 Free Software Foundation
# Miroslav Kure , 2005, 2008, 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listchanges\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2023-10-23 20:10-0400\n"
"PO-Revision-Date: 2023-10-31 22:00+0100\n"
"Last-Translator: Miroslav Kure \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: pygettext.py 1.4\n"

#: ../apt_listchanges/ALCApt.py:57
msgid "APT pipeline messages:"
msgstr "Zprávy z APT pipeline:"

#: ../apt_listchanges/ALCApt.py:64
msgid "Packages list:"
msgstr "Seznam balíků:"

#: ../apt_listchanges/ALCApt.py:74
msgid ""
"APT_HOOK_INFO_FD environment variable is not defined\n"
"(is Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD set to 20?)"
msgstr ""
"Proměnná prostředí APT_HOOK_INFO_FD není definovaná\n"
"(je Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD nastavena na 20?)"

#: ../apt_listchanges/ALCApt.py:82
msgid "Invalid (non-numeric) value of APT_HOOK_INFO_FD environment variable"
msgstr "Neplatná (nečíselná) hodnota proměnné prostředí APT_HOOK_INFO_FD"

#: ../apt_listchanges/ALCApt.py:85
#, python-format
msgid "Will read apt pipeline messages from file descriptor %d"
msgstr "Budu číst zprávy z apt pipeline z deskriptoru souboru %d"

#: ../apt_listchanges/ALCApt.py:90
msgid ""
"APT_HOOK_INFO_FD environment variable is incorrectly defined\n"
"(Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD should be greater "
"than 2)."
msgstr ""
"Proměnná prostředí APT_HOOK_INFO_FD je definovaná nesprávně\n"
"(Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD má být větší než 2)"

#: ../apt_listchanges/ALCApt.py:98
#, python-format
msgid "Cannot read from file descriptor %(fd)d: %(errmsg)s"
msgstr "Nelze číst z deskriptoru souboru %(fd)d: %(errmsg)s"

#: ../apt_listchanges/ALCApt.py:105
msgid ""
"Wrong or missing VERSION from apt pipeline\n"
"(is Dpkg::Tools::Options::/usr/bin/apt-listchanges::Version set to 2?)"
msgstr ""
"Chybná nebo chybějící verze z roury aptu\n"
"(je Dpkg::Tools::Options::/usr/bin/apt-listchanges::Version nastavena na 2?"

#: ../apt_listchanges/ALCConfig.py:164
#, python-format
msgid "Unknown configuration file option: %s"
msgstr "Neznámá volba konfiguračního souboru: %s"

#: ../apt_listchanges/ALCConfig.py:179
msgid "Usage: apt-listchanges [options] {--apt | filename.deb ...}\n"
msgstr "Použití: apt-listchanges [volby] {--apt | soubor.deb ...}\n"

#: ../apt_listchanges/ALCConfig.py:186
#, python-format
msgid "Unknown argument %(arg)s for option %(opt)s.  Allowed are: %(allowed)s."
msgstr "Neznámý argument %(arg)s pro volbu %(opt)s. Povolené jsou: %(allowed)s."

#: ../apt_listchanges/ALCConfig.py:200
#, python-format
msgid "%(deb)s does not have '.deb' extension"
msgstr "%(deb)s nemá příponu „.deb“"

#: ../apt_listchanges/ALCConfig.py:204
#, python-format
msgid "%(deb)s does not exist or is not a file"
msgstr "%(deb)s neexistuje nebo není souborem"

#: ../apt_listchanges/ALCConfig.py:208
#, python-format
msgid "%(deb)s is not readable"
msgstr "%(deb)s není čitelný"

#: ../apt_listchanges/ALCConfig.py:315
msgid "--since= and --show-all are mutually exclusive"
msgstr "--since= a --show-all se vzájemně vylučují"

#: ../apt_listchanges/ALCConfig.py:325
msgid "--since= expects a path to exactly one .deb archive"
msgstr "--since= očekává cestu k právě jednomu .deb archivu"

#: ../apt_listchanges/ALCConfig.py:333
msgid "--latest= and --show-all are mutually exclusive"
msgstr "--latest= a --show-all se vzájemně vylučují"

#: ../apt_listchanges/ALCLog.py:37 ../apt_listchanges/ALCLog.py:46
#, python-format
msgid "apt-listchanges: %(msg)s"
msgstr "apt-listchanges: %(msg)s"

#: ../apt_listchanges/ALCLog.py:41
#, python-format
msgid "apt-listchanges warning: %(msg)s"
msgstr "apt-listchanges varování: %(msg)s"

#: ../apt_listchanges/ALCSeenDb.py:154
#, python-format
msgid "Database %(db)s failed to load: %(errmsg)s"
msgstr "Databázi %(db)s se nepodařilo nahrát: %(errmsg)s"

#: ../apt_listchanges/AptListChangesGtk.py:51
msgid "apt-listchanges: Reading changelogs"
msgstr "apt-listchanges: Načítají se změny"

#: ../apt_listchanges/AptListChangesGtk.py:53
msgid "Reading changelogs. Please wait."
msgstr "Načítají se změny. Čekejte prosím."

#: ../apt_listchanges/AptListChangesGtk.py:112
msgid "Continue Installation?"
msgstr "Pokračovat v instalaci?"

#: ../apt_listchanges/AptListChangesGtk.py:113
msgid ""
"Select yes to continue with the installation.\n"
"Select no to abort the installation."
msgstr ""
"Zvolte Ano pro pokračování v instalaci.\n"
"Zvolte Ne pro přerušení instalace."

#: ../apt_listchanges/DebianFiles.py:121 

Bug#1055126: procps: pgrep and pidwait are identical. one should by a symlink to the other

[Ani Hay]

Package: procps
Version: 2:3.3.17-5
Severity: normal
X-Debbugs-Cc: anihay1...@gmail.com

Dear Maintainer,

procps offers two identical files:
$ ls -al pgrep pidwait 
-rwxr-xr-x 1 root root 39344 Oct  9 06:02 pgrep
-rwxr-xr-x 1 root root 39344 Oct  9 06:02 pidwait

$ diff pgrep pidwait

Instead of wasting all this space one should be a symlink to the other.

I tested it on Debian 11, Debian 12 and Debian sid and they all have
this problem.

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

Kernel: Linux 5.15.130-20472-g682e24dd583b (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)

Versions of packages procps depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u7
ii  libncurses6  6.2+20201114-2+deb11u2
ii  libncursesw6 6.2+20201114-2+deb11u2
ii  libprocps8   2:3.3.17-5
ii  libtinfo66.2+20201114-2+deb11u2
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.4-2

procps suggests no packages.

-- no debconf information

Bug#1039859: mixxx: Mixxx GUI is broken / elements not rendered

[Matthew Ruffell]

Hi everyone,

This is a wayland related bug, and a known issue upstream:

https://bugs.launchpad.net/mixxx/+bug/1850729
https://github.com/mixxxdj/mixxx/issues/9787

It seems the waveform code is incompatible with the QtWayland platform
plugin change, which is mentioned on their troubleshooting page:
https://github.com/mixxxdj/mixxx/wiki/Troubleshooting#mixxx-on-wayland

A workaround is to launch mixxx with

$ mixxx -platform xcb

Which uses the x11 platform plugin.

Upstream actually have -platform xcb set in their desktop file by
default, and if you look at debian/patches/0002-desktop_file.patch:

diff --git a/res/linux/org.mixxx.Mixxx.desktop
b/res/linux/org.mixxx.Mixxx.desktop
index bf90e33..35f4b68 100644
--- a/res/linux/org.mixxx.Mixxx.desktop
+++ b/res/linux/org.mixxx.Mixxx.desktop
@@ -8,7 +8,8 @@ GenericName[fr]=Interface numérique pour DJ
 Comment=A digital DJ interface
 Comment[de]=Ein digitales DJ-System
 Comment[fr]=Une interface numérique pour DJ
-Exec=sh -c "pasuspender -- mixxx -platform xcb || mixxx -platform xcb"
+Exec=mixxx
+Keywords=dj;music;alsa;jack:realtime;standalone;
 Terminal=false
 Icon=mixxx
 Type=Application

The exec line gets changed to remove the pasuspender call and platform
plugin changes. I understand removing pasuspender, but maybe we should
restore -platform xcb.

Gnome-Shell is wayland by default, and I think other desktops are
moving the same way, so maybe we should force the x11 backend by
default to have a working application while upstream decides how to
rebuild their interface for wayland to fix the issue.

Thanks,
Matthew

Bug#1052069: ways to proceed?

[Adam Majer]

Hi,

So, what's the way to proceed here? Can we add the boot parameter when 
the legacy kernel module is to be loaded on newer Intel processors?


- Adam

Bug#1055076: glibc: wrong _PATH_NOLOGIN in paths.h

[Olivier Duclos]

Woops! I didn't know that. Thanks for the explanation :)

-- 
  Olivier Duclos

On Tue, Oct 31, 2023, at 20:02, Aurelien Jarno wrote:
> Hi,
>
> On 2023-10-30 22:17, Olivier Duclos wrote:
>> Package: libc6-dev
>> Source: glibc
>> Version: 2.38-3
>> Severity: normal
>> 
>> In /usr/include/paths.h at line 56 we have:
>> 
>>   #define _PATH_NOLOGIN   "/etc/nologin"
>> 
>> This path is incorrect and should be replaced by "/usr/sbin/nologin".
>
> I think you are missing two different things:
> - The /etc/nologin file that prevent non-root users to log on a
>   machine if it exists.
> - The nologin shell that can be used in /etc/passwd to prevent the
>   corresponding users to login.
>
> Changing _PATH_NOLOGIN to "/usr/sbin/nologin", as you suggest, might
> prevent users to log on there system once packages are rebuild against
> the changed paths.h as this binary is provided by an essential package
> present on all systems. "might" because pam does not use the glibc
> paths.h and hard codes the path instead. But OpenSSH seems to use it.
>
> Regards
> Aurelien
>
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net

Bug#1055125: gpac: CVE-2023-5595

[Salvatore Bonaccorso]

Source: gpac
Version: 2.2.1+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/2633
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2023-5595[0]:
| Denial of Service in GitHub repository gpac/gpac prior to 2.3.0-DEV.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5595
https://www.cve.org/CVERecord?id=CVE-2023-5595
[1] https://github.com/gpac/gpac/issues/2633

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055124: gpac: CVE-2023-5586

[Salvatore Bonaccorso]

Source: gpac
Version: 2.2.1+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/2632
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2023-5586[0]:
| NULL Pointer Dereference in GitHub repository gpac/gpac prior to
| 2.3.0-DEV.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5586
https://www.cve.org/CVERecord?id=CVE-2023-5586
[1] https://github.com/gpac/gpac/issues/2632

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055123: efivar builds with -march=native on !ia64

[Adrian Bunk]

Source: efivar
Version: 38-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=efivar=38-1

-march=native is a baseline violation on architectures where
it is supported, and causes a FTBFS on architectures where
it is not supported.

It also changes the set of architectures where the package
might run based on the capabilities of the buildd, e.g. on amd64
code built on an AMD buildd might not run on Intel hardware and
code built on Intel hardware might not run on AMD hardware.

Bug#1055122: gpac: CVE-2023-5377

[Salvatore Bonaccorso]

Source: gpac
Version: 2.2.1+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/2606
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2023-5377[0]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to
| v2.2.2-DEV.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5377
https://www.cve.org/CVERecord?id=CVE-2023-5377
[1] https://github.com/gpac/gpac/issues/2606

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055121: libqt6gui6 should Depends: libxcb-cursor0

[Ximin Luo]

Package: libqt6gui6
Version: 6.4.2+dfsg-18
Severity: important
Tags: patch

Dear Maintainer,

When running:

https://github.com/ankitects/anki/releases/download/2.1.66/anki-2.1.66-linux-qt6.tar.zst

I get the following error:

| anki-2.1.66-linux-qt6$ QT_DEBUG_PLUGINS=1 DISABLE_QT5_COMPAT=1 ./anki 
| Anki starting...
| Initial setup...
| Preparing to run...
|   File "", line 1, in 
|   File "aqt", line 489, in run
|   File "aqt", line 563, in _run
|   File "aqt.profiles", line 134, in setupMeta
|   File "aqt.profiles", line 416, in _loadMeta
| resetting corrupt _global
| [..]
| Qt debug: Got keys from plugin meta data QList("vkkhrdisplay") 
| Qt debug: checking directory path "$HOME/anki-2.1.66-linux-qt6/platforms" ... 
| Qt debug: 
"$HOME/anki-2.1.66-linux-qt6/lib/PyQt6/Qt6/plugins/platforms/libqxcb.so" cannot 
load: Cannot load library 
$HOME/anki-2.1.66-linux-qt6/lib/PyQt6/Qt6/plugins/platforms/libqxcb.so: 
(libxcb-cursor.so.0: cannot open shared object file: No such file or directory) 
| Qt debug: QLibraryPrivate::loadPlugin failed on 
"$HOME/anki-2.1.66-linux-qt6/lib/PyQt6/Qt6/plugins/platforms/libqxcb.so" : 
"Cannot load library 
$HOME/anki-2.1.66-linux-qt6/lib/PyQt6/Qt6/plugins/platforms/libqxcb.so: 
(libxcb-cursor.so.0: cannot open shared object file: No such file or 
directory)" 
| Qt info: Could not load the Qt platform plugin "xcb" in "" even though it was 
found. 
| Qt fatal: This application failed to start because no Qt platform plugin 
could be initialized. Reinstalling the application may fix this problem.
| 
| Available platform plugins are: minimalegl, xcb, linuxfb, eglfs, offscreen, 
vnc, minimal, wayland, wayland-egl, vkkhrdisplay.
|  
| Aborted
| 134

The important part is

| (libxcb-cursor.so.0: cannot open shared object file: No such file or 
directory)

Installing libxcb-cursor0 fixes the problem.


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

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

Versions of packages libqt6gui6 depends on:
ii  fontconfig  2.14.2-6
ii  libc6   2.37-12
ii  libdrm2 2.4.115-1
ii  libegl1 1.6.0-1
ii  libfontconfig1  2.14.2-6
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-4
ii  libglib2.0-02.78.0-2
ii  libglx0 1.6.0-1
ii  libharfbuzz0b   8.0.1-1
ii  libice6 2:1.0.10-1
ii  libinput10  1.23.0-2
ii  libjpeg62-turbo 1:2.1.5-2
ii  libmd4c00.4.8-1
ii  libmtdev1   1.1.6-1
ii  libopengl0  1.6.0-1
ii  libpng16-16 1.6.40-1
ii  libqt6core6 [qt6-base-abi]  6.4.2+dfsg-18
ii  libqt6dbus6 6.4.2+dfsg-18
ii  libsm6  2:1.2.3-1
ii  libstdc++6  13.2.0-4
ii  libts0  1.22-1+b1
ii  libudev1254.5-1
ii  libx11-62:1.8.7-1
ii  libx11-xcb1 2:1.8.7-1
ii  libxcb-glx0 1.15-1
ii  libxcb-icccm4   0.4.1-1.1
ii  libxcb-image0   0.4.0-2
ii  libxcb-keysyms1 0.4.0-1+b2
ii  libxcb-randr0   1.15-1
ii  libxcb-render-util0 0.3.9-1+b1
ii  libxcb-render0  1.15-1
ii  libxcb-shape0   1.15-1
ii  libxcb-shm0 1.15-1
ii  libxcb-sync11.15-1
ii  libxcb-xfixes0  1.15-1
ii  libxcb-xkb1 1.15-1
ii  libxcb1 1.15-1
ii  libxkbcommon-x11-0  1.5.0-1
ii  libxkbcommon0   1.5.0-1
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages libqt6gui6 recommends:
ii  qt6-gtk-platformtheme  6.4.2+dfsg-18
ii  qt6-qpa-plugins6.4.2+dfsg-18
ii  qt6-wayland6.4.2-5

libqt6gui6 suggests no packages.

-- no debconf information

Bug#1054556: Raising severity to serious, ceres-solver has reached unstable

[Pierre Gruet]

Source: colmap
Version: 3.8-1
Followup-For: Bug #1054556
Control: severity -1 serious

Hi,

ceres-solver/2.2.0+dfsg-3 has reached unstable, thus I am raising the severity
of this bug to RC.

Best,

-- 
Pierre

Bug#74947: FWD: Bug#74947: bsdgames, wump: cave has incorrect geometry

[Paul Nuffer]

Hello BSD Games maintainers,

In case there's interest in adding the dodecahedron cave back to wump
without waiting for the other changes mentioned above, I've created a
patch for this.

I used the OpenBSD wump source files to copy these functions. The
OpenBSD dodecahedral_cave_init() creates a 20 room cave with three
tunnels from each room, and creates 2 bats and 2 pits. The nodes are
randomly assigned room numbers to give the appearance of change, but
the layout of the tunnel assignment guarantees each room will have 3
tunnels, and all rooms will be connected.

I adjusted the OpenBSD source in `dodecahedral_cave_init()` to use
`random()` instead of the BSD `arc4random()`, and I changed the
initialization loops to use the variables `room_num` and `link_num` to
match the format of the existing debug call in the same function. The
initial values for bat_num and pit_num were changed to -1 to ensure
the proper default values will be set in `main()` for both oldstyle
and regular play. I added the OpenBSD documentation for the `-o`
option into the wump.6 manpage as well.

I've been playing with this patch on my Debian 12 system, and it works
as I'd expect it to.

Please let me know if you have any questions, or if there's a better
way to submit a patch or discuss this change.

Thanks for your time,

Paul
diff --git a/wump/wump.6 b/wump/wump.6
index 67ae2c3..2d52203 100644
--- a/wump/wump.6
+++ b/wump/wump.6
@@ -40,7 +40,7 @@
 .Nd hunt the wumpus in an underground cave
 .Sh SYNOPSIS
 .Nm
-.Op Fl h
+.Op Fl ho
 .Op Fl a Ar arrows
 .Op Fl b Ar bats
 .Op Fl p Ar pits
@@ -69,6 +69,10 @@ The default is three.
 .It Fl h
 Play the hard version -- more pits, more bats, and a generally more
 dangerous cave.
+.It Fl o
+Play the original version, where there are twenty rooms arranged on the
+vertices of a dodecahedron, connected by the edges.
+In this case, the default is two pits and two bat rooms.
 .It Fl p
 Specifies the number of rooms in the cave which contain bottomless pits.
 The default is three.
diff --git a/wump/wump.c b/wump/wump.c
index ec21a14..d7fda7c 100644
--- a/wump/wump.c
+++ b/wump/wump.c
@@ -99,13 +99,14 @@ int player_loc = -1;			/* player location */
 int wumpus_loc = -1;			/* The Bad Guy location */
 int level = EASY;			/* level of play */
 int arrows_left;			/* arrows unshot */
+int oldstyle = 0;			/* dodecahedral cave? */
 
 #ifdef DEBUG
 int debug = 0;
 #endif
 
-int pit_num = PIT_COUNT;		/* # pits in cave */
-int bat_num = BAT_COUNT;		/* # bats */
+int pit_num = -1;		/* # pits in cave */
+int bat_num = -1;		/* # bats */
 int room_num = ROOMS_IN_CAVE;		/* # rooms in cave */
 int link_num = LINKS_IN_ROOM;		/* links per room  */
 int arrow_num = NUMBER_OF_ARROWS;	/* arrow inventory */
@@ -116,6 +117,7 @@ int	bats_nearby(void);
 void	cave_init(void);
 void	clear_things_in_cave(void);
 void	display_room_stats(void);
+void	dodecahedral_cave_init(void);
 int	gcd(int, int);
 int	getans(const char *);
 void	initialize_things_in_cave(void);
@@ -148,9 +150,9 @@ main(argc, argv)
 	setregid(getgid(), getgid());
 
 #ifdef DEBUG
-	while ((c = getopt(argc, argv, "a:b:hp:r:t:d")) != -1)
+	while ((c = getopt(argc, argv, "a:b:hop:r:t:d")) != -1)
 #else
-	while ((c = getopt(argc, argv, "a:b:hp:r:t:")) != -1)
+	while ((c = getopt(argc, argv, "a:b:hop:r:t:")) != -1)
 #endif
 		switch (c) {
 		case 'a':
@@ -167,6 +169,9 @@ main(argc, argv)
 		case 'h':
 			level = HARD;
 			break;
+		case 'o':
+			oldstyle = 1;
+			break;
 		case 'p':
 			pit_num = atoi(optarg);
 			break;
@@ -196,6 +201,21 @@ main(argc, argv)
 			usage();
 	}
 
+	if (oldstyle) {
+		room_num = 20;
+		link_num = 3;
+		/* Original game had exactly 2 bats and 2 pits */
+		if (bat_num < 0)
+			bat_num = 2;
+		if (pit_num < 0)
+			pit_num = 2;
+	} else {
+		if (bat_num < 0)
+			bat_num = BAT_COUNT;
+		if (pit_num < 0)
+			pit_num = PIT_COUNT;
+	}
+
 	if (link_num > MAX_LINKS_IN_ROOM ||
 	link_num > room_num - (room_num / 4)) {
 		(void)fprintf(stderr,
@@ -221,7 +241,10 @@ main(argc, argv)
 	}
 
 	instructions();
-	cave_init();
+	if (oldstyle)
+		dodecahedral_cave_init();
+	else
+		cave_init();
 
 	/* and we're OFF!  da dum, da dum, da dum, da dum... */
 	(void)printf(
@@ -244,10 +267,13 @@ quiver holds %d custom super anti-evil Wumpus arrows.  Good luck.\n",
 
 		if (!getans("\nCare to play another game? (y-n) "))
 			exit(0);
-		if (getans("In the same cave? (y-n) "))
-			clear_things_in_cave();
-		else
-			cave_init();
+		clear_things_in_cave();
+		if (!getans("In the same cave? (y-n) ")) {
+			if (oldstyle)
+dodecahedral_cave_init();
+			else
+cave_init();
+		}
 	}
 	/* NOTREACHED */
 	return (0);
@@ -609,6 +635,73 @@ try_again:		link = (random() % room_num) + 1;
 #endif
 }
 
+void
+dodecahedral_cave_init()
+{
+	int vert[20][3] = {
+		{1, 4, 7},
+		{0, 2, 9},
+		{1, 3, 11},
+		{2, 4, 13},
+		{0, 3, 5},
+		{4, 6, 14},
+		{5, 7, 16},
+		{0, 6, 8},
+		{7, 9, 17},
+		{1, 8, 10},
+		{9, 11, 18},
+		{2, 10, 12},
+		{11, 13, 19},
+		{3, 12, 14},
+		

Bug#1055120: rust-chrono breaks rust-pyo3 autopkgtest: panicked at 'called `Option::unwrap()` on a `None` value'

[Paul Gevers]

Source: rust-chrono, rust-pyo3
Control: found -1 rust-chrono/0.4.31-1
Control: found -1 rust-pyo3/0.19.0-3
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of rust-chrono the autopkgtest of rust-pyo3 fails 
in testing when that autopkgtest is run with the binary packages of 
rust-chrono from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
rust-chronofrom testing0.4.31-1
rust-pyo3  from testing0.19.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of rust-chrono to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-chrono

https://ci.debian.net/data/autopkgtest/testing/armel/r/rust-pyo3/39387157/log.gz

1099s failures:
1099s
1099s  conversions::chrono::tests::test_pyo3_datetime_topyobject 
stdout 
1099s thread 'conversions::chrono::tests::test_pyo3_datetime_topyobject' 
panicked at 'called `Option::unwrap()` on a `None` value', 
src/conversions/chrono.rs:574:26

1099s stack backtrace:
1099s0: rust_begin_unwind
1099s  at 
/usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5

1099s1: core::panicking::panic_fmt
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14

1099s2: core::panicking::panic
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/panicking.rs:117:5

1099s3: core::option::Option::unwrap
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/option.rs:950:21
1099s4: 
pyo3::conversions::chrono::tests::test_pyo3_datetime_topyobject::{{closure}}::{{closure}}

1099s  at ./src/conversions/chrono.rs:571:36
1099s5: pyo3::marker::Python::with_gil
1099s  at ./src/marker.rs:433:9
1099s6: 
pyo3::conversions::chrono::tests::test_pyo3_datetime_topyobject::{{closure}}

1099s  at ./src/conversions/chrono.rs:570:17
1099s7: pyo3::conversions::chrono::tests::test_pyo3_datetime_topyobject
1099s  at ./src/conversions/chrono.rs:603:9
1099s8: 
pyo3::conversions::chrono::tests::test_pyo3_datetime_topyobject::{{closure}}

1099s  at ./src/conversions/chrono.rs:567:40
1099s9: core::ops::function::FnOnce::call_once
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5

1099s   10: core::ops::function::FnOnce::call_once
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
1099s note: Some details are omitted, run with `RUST_BACKTRACE=full` for 
a verbose backtrace.

1099s
1099s  conversions::chrono::tests::test_pyo3_time_topyobject stdout 
1099s thread 'conversions::chrono::tests::test_pyo3_time_topyobject' 
panicked at 'called `Option::unwrap()` on a `None` value', 
src/conversions/chrono.rs:798:22

1099s stack backtrace:
1099s0: rust_begin_unwind
1099s  at 
/usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5

1099s1: core::panicking::panic_fmt
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14

1099s2: core::panicking::panic
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/panicking.rs:117:5

1099s3: core::option::Option::unwrap
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/option.rs:950:21
1099s4: 
pyo3::conversions::chrono::tests::test_pyo3_time_topyobject::{{closure}}::{{closure}}

1099s  at ./src/conversions/chrono.rs:797:28
1099s5: pyo3::marker::Python::with_gil
1099s  at ./src/marker.rs:433:9
1099s6: 
pyo3::conversions::chrono::tests::test_pyo3_time_topyobject::{{closure}}

1099s  at ./src/conversions/chrono.rs:796:13
1099s7: pyo3::conversions::chrono::tests::test_pyo3_time_topyobject
1099s  at ./src/conversions/chrono.rs:822:9
1099s8: 
pyo3::conversions::chrono::tests::test_pyo3_time_topyobject::{{closure}}

1099s  at ./src/conversions/chrono.rs:794:36
1099s9: core::ops::function::FnOnce::call_once
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5

1099s   10: core::ops::function::FnOnce::call_once
1099s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
1099s note: Some details are omitted, run with `RUST_BACKTRACE=full` for 
a verbose backtrace.

1099s
1099s  conversions::chrono::tests::test_pyo3_datetime_frompyobject 
stdout 
1099s thread 

Bug#1054666: open-vm-tools: CVE-2023-34059 CVE-2023-34058

[Moritz Muehlenhoff]

On Tue, Oct 31, 2023 at 10:29:55AM +0100, Bernd Zeimetz wrote:
> 
> Both uploaded!

DSA has been released, thanks!

Cheers,
Moritz

Bug#1055117: FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

[Mauricio Oliveira]

Thanks for the prompt reply and update, and sorry about the repeated noise.

No, unfortunately I'm not familiar with another method; I think
archive administrators would be the right option!

On Tue, Oct 31, 2023 at 4:16 PM Troy Heber  wrote:
>
> On 10/31/23 16:01, Mauricio Oliveira wrote:
>
> > It looks like 8.0.3-1 doesn't include the gdb-10.2 tarball as 8.0.2-1,
> > and thus fails to build.
>
> > Could you please include it in 8.0.3-2 when you have a chance?
>
> Yep, it was a mistake in my upload. I have already tried to include it
> in an 8.0.3-2 upload already but couldn't figure out a way to force the push
> of an updated orig.tar.gz so I'm waiting for help form the FTP
> masters to get it replaced with the proper one. Do you know of any
> way for me to force the replacement without their assistance?
>
> Troy



-- 
Mauricio Faria de Oliveira

Bug#1055118: RM: python3-renderpm [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] -- NBS; source no longer builds arch:$arch binaries

[Paul Gevers]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-report...@packages.debian.org, Georges Khaznadar 

Control: affects -1 + src:python-reportlab
Control: clone -1 -2
Control: retitle -2 RM: python3-reportlab-accel [amd64 arm64 armel armhf i386 
mips64el ppc64el s390x] -- NBS; source no longer builds arch:$arch binaries

Dear ftp-master,

src:python-reportlab no longer builds arch:$arch binaries. Please remove the
cruft left in unstable such that the package can migrate.

Paul

Bug#1055107: crowdsec fails its autopkgtests on armel

[Cyril Brulebois]

Nilesh Patra  (2023-10-31):
> Since this means it is a flaky test and a recurring problem, would it
> make sense to skip those tests to save some cycles for debci?

I didn't say I was certain, quite the opposite.

> I had triggered it - we will see if it fixes itself.

Looking at https://ci.debian.net/packages/c/crowdsec/testing/armel/
it succeeded, 4 times in a row, within 2 minutes…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1055117: FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

[Mauricio Oliveira]

Package: crash
Version: 8.0.3-1
Tags: ftbfs

Hi Troy,

It looks like 8.0.3-1 doesn't include the gdb-10.2 tarball as 8.0.2-1,
and thus fails to build.

Could you please include it in 8.0.3-2 when you have a chance?

Thanks again,
Mauricio

Buildd log on amd64 [1]:
---

dh_auto_build
...
/usr/bin/wget is required to download gdb-10.2.tar.gz
...
dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true"
returned exit code 2


Comparison between 8.0.2-1 and 8.0.3-1:
---

$ curl -s http://deb.debian.org/debian/pool/main/c/crash/crash_8.0.2.orig.tar.gz
| tar tz | fgrep gdb-10.2
crash-8.0.2/gdb-10.2.tar.gz
crash-8.0.2/gdb-10.2.patch

$ curl -s http://deb.debian.org/debian/pool/main/c/crash/crash_8.0.3.orig.tar.gz
| tar tz | fgrep gdb-10.2
crash-8.0.3/gdb-10.2.patch

[1] 
https://buildd.debian.org/status/fetch.php?pkg=crash=amd64=8.0.3-1=1698677722

-- 
Mauricio Faria de Oliveira

Bug#1055076: glibc: wrong _PATH_NOLOGIN in paths.h

[Aurelien Jarno]

Hi,

On 2023-10-30 22:17, Olivier Duclos wrote:
> Package: libc6-dev
> Source: glibc
> Version: 2.38-3
> Severity: normal
> 
> In /usr/include/paths.h at line 56 we have:
> 
>   #define _PATH_NOLOGIN   "/etc/nologin"
> 
> This path is incorrect and should be replaced by "/usr/sbin/nologin".

I think you are missing two different things:
- The /etc/nologin file that prevent non-root users to log on a
  machine if it exists.
- The nologin shell that can be used in /etc/passwd to prevent the
  corresponding users to login.

Changing _PATH_NOLOGIN to "/usr/sbin/nologin", as you suggest, might
prevent users to log on there system once packages are rebuild against
the changed paths.h as this binary is provided by an essential package
present on all systems. "might" because pam does not use the glibc
paths.h and hard codes the path instead. But OpenSSH seems to use it.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1053310: Fixes for stable/oldstable?

[Andreas Metzler]

On 2023-10-31 Tomas Pospisek  wrote:
[...]
> PS: I'd prefer this bugreport to be open as long as the stable and
> oldstable packages are still vulnerable...

Hello Thomas,
The Debian BTS does not use a simple open/close logic, it tracks which
specific versions a bug applies to. If you look at
https://bugs.debian.org/cgi-bin/1053310 there is both textual info
("Found in version exim4/4.94.2-7 Fixed in version exim4/4.97~RC2-2")
and a nice graph in red and green to display this and the overview pages
can also show bugs applying to specific distributions. (Menu items at
the bottom of the page.) e.g. 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=exim4-base
does not show this bug under "Resolved bugs".

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#1053310: Fixes for stable/oldstable?

[Andreas Metzler]

On 2023-10-31 Tomas Pospisek  wrote:
> On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote:
[...]
>> Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered
>> no-dsa (see comment on the security-tracker about it), and are going
>> to be fixed in the next point releases.

> The notes say:

> ***
> [bookworm] - exim4  (Only an issue if Exim4 run behind an
>  untrusted proxy-protocol proxy)
[...]
> So I think I can parse from those that CVE-2023-42117 is only critical when
> exim is run behind a "untrusted proxy-protocol proxy".

> Questions if you will:

> * what does "no-dsa" mean? DSA seems to mean Debian Security Announce.
>   Does it mean there is no DSA for that problem yet? What does it mean
>   when a CVE is considered "no-dsa" then? That no DSA will be released for
>   it?

Hello Thomas,

Exactly. The severity was judged to be very low, not "worth" the effort
of a DSA.

> * what is a "untrusted proxy-protocol proxy" in the context of a mail
>   transport agent? So exim shouldn't be used behind an untrusted socks
>   proxy? Well I have no real control who connects how to a public MTA...
>   anybody can connect to it to try his luck sending me email. That
>   includes untrusted socks proxies...

This
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html
or more precisely part "1. Inbound proxies".

You need to explicitely configure exim to tell it that specific hosts
are acting as load-balancing proxy sitting in front of exim. I cannot
think of a szenario where these load-balancing proxies would not be
trusted machines. The issue is about weakening the chain a little bit -
take over the proxy first and then do something to the exim machines
behind.

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#1055116: rust-rustls, please prepare update for new ring.

[Peter Green]

Package: rust-rustls

After a long wait, ring released version 0.17 which is far more portable than
previous versions. The lack of portability of ring has been a thorn in the
side of the rust team for some time so we would really like to upgrade.

The good news is that rustls has updated to the new version of ring *without*
bumping semver. So hopefully this transition can be kept relatively small.

I've uploaded the new version of ring to experimental, could you prepare new
versions of the rustls packages to work with it.

Bug#1028212: proposed stable release update

[Antoine Beaupré]

I have filed #1055115 to update the package in bookworm.

a.
-- 
Nothing in life is to be feared, it is only to be understood.
Now is the time to understand more, so that we may fear less.
 - Marie Curie

Bug#1055113: linux-image-5.10.0-26-s390x: af_iucv kernel module fails to load on bootup / manual start via modprobe

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo upstream

On Tue, Oct 31, 2023 at 06:39:32PM +0100, Leonardo Martinho wrote:
> Package: src:linux
> Version: 5.10.197-1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* update to 5.10.197-1 includes upstream changes from 6.x kernel.
>* in particular this:
>  * 
> https://lore.kernel.org/all/20230917191101.257176...@linuxfoundation.org/
>* this isn't an issue with the upstream state in the 6.x kernel as the 
> problems this change might cause are alleviated by this commit that altered 
> the way the iucv_if symbol was loaded:
>  * 
> https://github.com/torvalds/linux/commit/4eb9eda6ba64114d98827e2870e024d5ab7cd35b
>* I tested the aformentioned commit and it did fix the issue
>* For the next version, please include this commit in order to fix the 
> broken state of af_iucv in 5.10.197 and further kernel images.

If the change introduces a regresssion and the above mentioned commit
is required to fix the regression, can you please ask the stable@ list
to pick it up for 5.10.y (keep us in the loop please)?

When it lands in 5.10.y upstream solving the regression it will be
picked automatically downstream in Debian as well.

ideally you include as well the regressions list in CC.

Regards,
Salvatore

Bug#1055115: bookworm-pu: package prometheus-node-exporter-collectors/0.0~git20230203.6f710f8-1

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: prometheus-node-exporter-collect...@packages.debian.org
Control: affects -1 + src:prometheus-node-exporter-collectors

[ Reason ]
Since the bookworm upgrade, all hosts with the
prometheus-node-exporter-collectors package install repeatedly hit the
mirrors with spurious apt-update runs. The Debian package
systemd.timer(1) schedule is once on boot and then every 15 minutes
after, which imposes a tremendous load on the mirror system.

It also happens to lock the apt status files which can in turn cause
deadlocks with other programs. There seems to be an (unrelated?)
regression in apt where some (python?) apt program can hang this way
indefinitely. That's tracked separately, e.g.

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

[ Impact ]
The mirror networks are going to be badly negatively affected by
this. This actually doesn't seem to have been a problem so far,
possibly because deb.debian.org is absorbing everything we can throw
at it and no one is looking at Fastly (or Amazon?), but I suspect this
could become a problem as Prometheus adoption widens.

This also can mean some security upgrades don't get deployed, as the
apt update lockfile gets hung.

[ Tests ]
There's no autopkgtest on this package, but the patches provided here
have been tested in production in about 90 servers for torproject.org
over a few weeks now, fixing the diagnosed issue.

https://gitlab.torproject.org/tpo/tpa/team/-/issues/41355 is our
tracking ticket documenting this.

[ Risks ]
Code is *relatively* simple. It diverges from upstream a little now
because upstream did a little reactoring post bookworm and I didn't
want to make the patch bigger than it absolutely needs to be.

[ 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 ]
There are three individual patches, cherry-picked and backported from
upstream. The first one simply stops running apt-update.

The second and third patch add a new metric which keeps track of the
last update timestamp on the apt metadata.

That is important: previously, the script was running apt-update so we
could be pretty sure it was running automatically. But by making this
change, we're *not* running apt-update automatically and assume users
have properly setup something *else* that does.

This was the behaviour in bullseye, for the record, but it's possible
that some users *assume* the wrong (new) behavior was the correct one
and installed the package not knowing they need to deploy their own
APT::Periodic thing.
diff -Nru 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
--- 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
2023-02-02 23:57:45.0 -0500
+++ 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
2023-10-31 13:57:52.0 -0400
@@ -1,3 +1,10 @@
+prometheus-node-exporter-collectors (0.0~git20230203.6f710f8-1+deb12u1) 
bookworm; urgency=medium
+
+  * Team upload
+  * Fix deadlock with other apt update runs (Closes: #1028212)
+
+ -- Antoine Beaupré   Tue, 31 Oct 2023 13:57:52 -0400
+
 prometheus-node-exporter-collectors (0.0~git20230203.6f710f8-1) unstable; 
urgency=medium
 
   * New upstream snapshot (Closes: #1030058)
diff -Nru 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
--- 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
1969-12-31 19:00:00.0 -0500
+++ 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
2023-10-31 13:57:52.0 -0400
@@ -0,0 +1,65 @@
+From 28c179ddfd3d7e0f5bc49b93f924f0dffba5b71d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Fri, 13 Oct 2023 12:29:48 -0400
+Subject: [PATCH] do not run apt update or simulate apt dist-upgrade
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is causing all sorts of problems. The first of which is that
+we're hitting our poor mirrors every time the script is ran, which, in
+the Debian package configuration, is *every 15 minutes* (!!).
+
+The second is that this locks the cache and makes this script
+needlessly stumble upon a possible regression in APT from Debian
+bookworm and Ubuntu 22.06:
+

Bug#1055114: nethack-console: nethack does not handle some terminals

[Francesco Ariis]

Package: nethack-console
Version: 3.6.6-3+b2
Severity: normal
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

  when I try to run nethack, I get this error:

f@x270:~$ nethack
Unknown terminal type: screen-it.

But the terminal type `screen-it` is present in the terminal capability
database ~/.terminfo

f@x270:~$ ls .terminfo/s/screen-it
.terminfo/s/screen-it

Expected: `nethack` to run without fuss.
Actual: I have to invoke nethack as `TERM=screen nethack`.


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

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

Versions of packages nethack-console depends on:
ii  libc6   2.36-9+deb12u3
ii  libncurses6 6.4-4
ii  libtinfo6   6.4-4
ii  nethack-common  3.6.6-3+b2

nethack-console recommends no packages.

nethack-console suggests no packages.

-- no debconf information

Bug#1054290: zlib: CVE-2023-45853

[David Dooling]

Thanks for that analysis, James.

Using James' analysis as a starting point, I dug into some of the
usages of the 'zipOpenNewFile*' functions.

nodejs-18.13.0+dfsg1:
The Node.js source code includes a copy of the zlib source code. This
copy was patched over a month ago.

mariadb-10.11.4:
The MariaDB source code includes a copy of the zlib source code. This
copy has not been patched. This implies MariaDB should be mentioned in
this CVE but is not.

After checking two common packages and seeing the same, someone
nonstandard pattern, I downloaded and compiled zlib myself. By
default, it does not appear that any of the minizip functions are
included in any header file or library installed as part of the normal
zlib './configure && make && make install'. So perhaps all these
usages of these functions are associated with downstream software
closing zlib source into their code? If that is the case, what does
that mean for this CVE and actually creating a coherent response
across all these packages?

-- 
David Dooling

Bug#1055113: linux-image-5.10.0-26-s390x: af_iucv kernel module fails to load on bootup / manual start via modprobe

[Leonardo Martinho]

Package: src:linux
Version: 5.10.197-1
Severity: normal
Tags: patch

Dear Maintainer,

   * update to 5.10.197-1 includes upstream changes from 6.x kernel.
   * in particular this:
 * https://lore.kernel.org/all/20230917191101.257176...@linuxfoundation.org/
   * this isn't an issue with the upstream state in the 6.x kernel as the 
problems this change might cause are alleviated by this commit that altered the 
way the iucv_if symbol was loaded:
 * 
https://github.com/torvalds/linux/commit/4eb9eda6ba64114d98827e2870e024d5ab7cd35b
   * I tested the aformentioned commit and it did fix the issue
   * For the next version, please include this commit in order to fix the 
broken state of af_iucv in 5.10.197 and further kernel images.


-- Package-specific info:
** Version:
Linux version 5.10.0-26-s390x (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.197-1 (2023-09-29)

** Command line:
ro dasd=200-21f vmpoff="LOGOFF" root=/dev/dasdb1 elevator=deadline BOOT_IMAGE=0

** Not tainted

** Kernel log:

** Model information
[2.097360] systemd[1]: Queued start job for default target Graphical 
Interface.
[2.097906] systemd[1]: Created slice system-getty.slice.
[2.098153] systemd[1]: Created slice system-modprobe.slice.
[2.098338] systemd[1]: Created slice system-postfix.slice.
[2.098611] systemd[1]: Created slice system-s390\x2dnetwork.slice.
[2.098780] systemd[1]: Created slice system-serial\x2dgetty.slice.
[2.098913] systemd[1]: Created slice User and Session Slice.
[2.098952] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[2.099115] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[2.099197] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[2.099225] systemd[1]: Reached target Local Encrypted Volumes.
[2.099260] systemd[1]: Reached target Paths.
[2.099280] systemd[1]: Reached target Remote File Systems.
[2.099298] systemd[1]: Reached target Slices.
[2.099355] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[2.099408] systemd[1]: Listening on LVM2 poll daemon socket.
[2.099470] systemd[1]: Listening on Syslog Socket.
[2.099516] systemd[1]: Listening on fsck to fsckd communication Socket.
[2.099552] systemd[1]: Listening on initctl Compatibility Named Pipe.
[2.099626] systemd[1]: Listening on Journal Audit Socket.
[2.099673] systemd[1]: Listening on Journal Socket (/dev/log).
[2.099728] systemd[1]: Listening on Journal Socket.
[2.099799] systemd[1]: Listening on Network Service Netlink Socket.
[2.099878] systemd[1]: Listening on udev Control Socket.
[2.099923] systemd[1]: Listening on udev Kernel Socket.
[2.100303] systemd[1]: Mounting Huge Pages File System...
[2.100788] systemd[1]: Mounting POSIX Message Queue File System...
[2.101377] systemd[1]: Mounting Kernel Debug File System...
[2.101790] systemd[1]: Mounting Kernel Trace File System...
[2.101893] systemd[1]: Finished Availability of block devices.
[2.102471] systemd[1]: Starting Create list of static device nodes for the 
current kernel...
[2.102985] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. 
using dmeventd or progress polling...
[2.103442] systemd[1]: Starting Load Kernel Module configfs...
[2.103873] systemd[1]: Starting Load Kernel Module drm...
[2.113355] systemd[1]: Starting Load Kernel Module fuse...
[2.114146] systemd[1]: Condition check resulted in Set Up Additional Binary 
Formats being skipped.
[2.114171] systemd[1]: Condition check resulted in File System Check on 
Root Device being skipped.
[2.114844] systemd[1]: Starting Journal Service...
[2.118418] systemd[1]: Starting Load Kernel Modules...
[2.118880] systemd[1]: Starting Remount Root and Kernel File Systems...
[2.119363] systemd[1]: Starting Coldplug All udev Devices...
[2.122274] systemd[1]: Mounted Huge Pages File System.
[2.122329] systemd[1]: Mounted POSIX Message Queue File System.
[2.122369] systemd[1]: Mounted Kernel Debug File System.
[2.122409] systemd[1]: Mounted Kernel Trace File System.
[2.122544] systemd[1]: Finished Create list of static device nodes for the 
current kernel.
[2.122686] systemd[1]: modprobe@configfs.service: Succeeded.
[2.122781] systemd[1]: Finished Load Kernel Module configfs.
[2.123078] systemd[1]: modprobe@drm.service: Succeeded.
[2.123171] systemd[1]: Finished Load Kernel Module drm.
[2.124415] systemd[1]: Mounting Kernel Configuration File System...
[2.128549] systemd[1]: Mounted Kernel Configuration File System.
[2.139950] fuse: init (API version 7.32)
[2.140223] systemd[1]: modprobe@fuse.service: Succeeded.
[2.140320] systemd[1]: Finished Load Kernel Module fuse.
[2.140701] systemd[1]: Mounting FUSE Control File 

Bug#1015930: debian-livecoding list creation status

[weepingclown]

Hi,

It has been over an year since the list creation for debian-livecoding mailing 
list was requested (yes, I do understand that there have been things that has 
been going on for much longer). There is some support shown directly under the 
bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015930, not to mention 
others who haven't shared anything there. And after DebConf23 the enthusiasm of 
people have only increased with regards to livecoding and there are efforts 
going on with regards to packaging various livecoding tools. As such, it would 
be a good idea to have a mailing list under debian lists itself for the live 
coding team to communicate.

I tried asking about the status for this bug in the IRC channel, but couldn't 
get any reply. It would be great if this request is processed, but if not, then 
at the very least, is it possible to get the reason why this is not considered?

Thanks

Bug#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

On Tue, Oct 31, 2023 at 05:32:53PM +0100, Cyril Brulebois wrote:
> Nilesh Patra  (2023-10-31):
> > On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra  wrote:
> > Full log at: 
> > https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz
> > 
> > > This is currently blocking golang-github-gin-gonic-gin to testing which
> > > fixes a bunch of RC bugs (of same kind).
> 
> I think we've had this issue showing up in a few cases (on other archs
> though), but I wasn't able to replicate it, possibly timing issues or
> something similar.

Since this means it is a flaky test and a recurring problem, would it
make sense to skip those tests to save some cycles for debci?

> I'd suggest a retry if that wasn't attempted already.

I had triggered it - we will see if it fixes itself.


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1054712: ensmallen: FTBFS: adam_test.cpp:17:10: fatal error: catch2/catch.hpp: No such file or directory

[Drew Parsons]

Source: ensmallen
Followup-For: Bug #1054712

Should be noted that the problem is linked to debian patch
0002-use-system-catch.patch, which disables upstream's local copy of
catch in order to use the system catch2 library.

So one workaround could be to disable 0002-use-system-catch.patch.

Bug#967795: [Pkg-pascal-devel] Bug#967795: view3dscene: depends on deprecated GTK 2

[Peter B]

On 22/10/2023 22:15, Bastian Germann wrote:

Meanwhile, you can drop libgtkglext1-dev, which is not used, and unblock 
#967491.


Pushed to Salsa, 4.2.0-3
https://salsa.debian.org/pascal-team/view3dscene

Bug#1055107: crowdsec fails its autopkgtests on armel

[Cyril Brulebois]

Hi,

Nilesh Patra  (2023-10-31):
> On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra  wrote:
> Full log at: 
> https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz
> 
> > This is currently blocking golang-github-gin-gonic-gin to testing which
> > fixes a bunch of RC bugs (of same kind).

I think we've had this issue showing up in a few cases (on other archs
though), but I wasn't able to replicate it, possibly timing issues or
something similar. I'd suggest a retry if that wasn't attempted already.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1055112: Please backport patch for malformed ECC keys stored permanently in NSSDB (3.94 only)

[Simo Sorce]

Package: libnss3

Please backport
https://hg.mozilla.org/projects/nss/rev/a69c9f36bb8ac1c47cacb6c6ec9f06309de33951
to Sid

This is an upstream bug that has annoying consequences for people that
generate ECC keys on NSS softoken.
The fix does *not* correct the data already stored in DBs so it is
somewhat important to update packages quickly to minimize the number of
people affected.

It should be possible to manually export and then re-import keys to
"fix" the format, but this has not been tested.

The bug was first triggered in the pkcs11-provider upstream project CI
when Fedora imported 3.94 and now it started showing up for Debian (and
MacOS) as well.

Note that Firefox is unaffected because NSS can reformat the keys as it
reads them, the only affected applications are PKCS#11 applications
that use softoken directly.

Fedora 38 fix here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-eb53986016

HTH,
Simo.

-- 
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc

Bug#1055111: ffmpeg FTBFS: makeinfo: Undefined subroutine ::Config::set_from_init_file called at doc/t2h.pm

[Adrian Bunk]

Source: ffmpeg
Version: 7:6.0-8
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian TeX Task Force 

https://buildd.debian.org/status/logs.php?pkg=ffmpeg=7%3A6.0-8

...
makeinfo --html -I doc --no-split -D config-not-all 
--init-file=/<>/doc/t2h.pm --output doc/ffmpeg.html 
/<>/doc/ffmpeg.texi
makeinfo: error parsing /<>/doc/t2h.pm: Undefined subroutine 
::Config::set_from_init_file called at /<>/doc/t2h.pm line 
24.
make[2]: *** [/<>/doc/Makefile:70: doc/ffmpeg.html] Error 1

Bug#1055110: libgridxc builds with -march=native

[Adrian Bunk]

Source: libgridxc
Version: 2.0.0-1
Severity: serious
Tags: ftbfs

-march=native is a baseline violation on architectures where
it is supported, and causes a FTBFS on architectures where
it is not supported.

It also changes the set of architectures where the package
might run based on the capabilities of the buildd, e.g. on amd64
code built on an AMD buildd might not run on Intel hardware and
code built on Intel hardware might not run on AMD hardware.

Bug#1053774: spdlog: need new upstream release 1.12 for catch2 v3

[Drew Parsons]

Source: spdlog
Followup-For: Bug #1053774

Looks like you'll need to grab PR#2827 from upstream
https://github.com/gabime/spdlog/pull/2827

Bug#1028398: snapd: both Telegram-desktop and Skype cannot load and save files

[Francesco Potortì]

Sorry for not following up sooner.

I cannot see this bug any more, it should be closed

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it
(gate 20, 1st floor, room C71) ISPIN:  https://ieee-jispin.org/

Bug#1055109: perl: 5.26 FTBFS on hppa: broken miniperl? Please revert fix.

[John David Anglin]

Source: perl
Version: 5.36.0-9
Severity: normal

Dear Maintainer,

Would you please revert the following fix:

  * Lower the optimization level of opmini.c on hppa. (Closes: #869122  
)

This was only required for gcc-6 and the issue was fixed in later versions of 
gcc.
I have checked that the fix is no longer needed with gcc-13.

Thanks,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.60+ (SMP w/4 CPU threads)
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)

Bug#1055108: /usr/libexec/gnome-remote-desktop-daemon: Every time I reboot my remote desktop password is reset

[Jonathan Kamens]

Package: gnome-remote-desktop
Version: 44.2-6
Severity: normal
File: /usr/libexec/gnome-remote-desktop-daemon

Dear Maintainer,

Every time I reboot, the remote desktop password, as shown in the
remote desktop pop-up from the sharing settings panel, is changed to a
new, random value.

I have two laptops running Debian testing. This only happens on one of
them. I am not sure why, but this may be relevant:

* Both computers are configured with automatic login.
* On the computer that does not have the problem described above, I'm
  prompted immediately after reboot to enter my login keychain
  password because it wasn't unlocked during login (because of
  automatic login).
* On the computer that does have the problem described above, I'm not
  prompted to enter my login keychain password until I open the
  sharing control panel.

I have no idea why the two computers behave differently in this way
either.

  jik

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages gnome-remote-desktop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  fuse33.14.0-4
ii  init-system-helpers  1.65.2
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libepoxy01.5.10-1
ii  libfreerdp-server2-2 2.11.2+dfsg1-1
ii  libfreerdp2-22.11.2+dfsg1-1
ii  libfuse3-3   3.14.0-4
ii  libglib2.0-0 2.78.0-2
ii  libmutter-12-0   44.5-2
ii  libnotify4   0.8.2-1
ii  libpipewire-0.3-00.3.83-1
ii  libsecret-1-00.21.1-1
ii  libtss2-esys-3.0.2-0 4.0.1-3
ii  libtss2-mu0  4.0.1-3
ii  libtss2-rc0  4.0.1-3
ii  libtss2-tctildr0 4.0.1-3
ii  libwinpr2-2  2.11.2+dfsg1-1
ii  libxkbcommon01.6.0-1
ii  pipewire 0.3.83-1
ii  wireplumber  0.4.15-1

gnome-remote-desktop recommends no packages.

gnome-remote-desktop suggests no packages.

-- no debconf information

Bug#996356: Confirmed at Google

[Andrew Jorgensen]

We believe we've also observed this bug at Google on Debian 11. We
confirmed that packets are received by the kernel, but dhclient
doesn't catch them. The root cause appears to be a race condition, and
we provided some details in
https://gitlab.isc.org/isc-projects/dhcp/-/issues/264 to ISC, but we
understand dhclient is being deprecated.

The bug was also reported to Ubuntu at
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139 and
there's a detailed discussion of the bug, reproduction cases, and
proposed fixes, the last of which was accepted into Ubuntu Jammy.

We built a test package with Ubuntu's fix applied to Debian 11 and
confirmed over the weekend (more than 100k runs) that it resolves the
issue.

Because of some risk that the fix could cause issues elsewhere, the
patch included an option to revert the change at runtime. I haven't
found evidence of anyone needing to use that option.

Oddly we also find that Debian 12 does not have this issue, even
though the later version of dhclient does not include any fix for
this. There must be some other reason why the race condition is not
hit there.

Bug#1054712: ensmallen: FTBFS: adam_test.cpp:17:10: fatal error: catch2/catch.hpp: No such file or directory

[Drew Parsons]

Source: ensmallen
Followup-For: Bug #1054712
Control: forwarded 1054712 https://github.com/mlpack/ensmallen/issues/372

This error occurs because of the upgrade of catch2 from v2 to v3.

Unfortunately ensmallen upstream don't sound very enthusiastic about
dealing with it, https://github.com/mlpack/ensmallen/issues/372

Arguably the catch developers made life unjustifiablydifficult. Maybe
they should have released catch3 rather than catch2 v3.

On the other hand, judging by the patch for termpaint, the required
changes are likely to be essentially trivial, e.g. 
  #include "catch2/catch_all.hpp"
instead of 
  #include "catch2/catch.hpp"

cf.
https://github.com/termpaint/termpaint/commit/dc293554b745b3f010445e9445e620399f8ee2f7

Bug#1055085: (some kind of) transition: add python3.12 as a supported python3 version

[Graham Inggs]

Hi Matthias

On Tue, 31 Oct 2023 at 07:15, Matthias Klose  wrote:
> Please setup a tracker to add python3.12 as a supported python3 version. This 
> is
> non-blocking, as packages can migrate on their own once built. I'm not yet
> starting this, just want to have an overview of affected packages.
>
> Please re-use the final version of the python3.11 tracker.
> https://release.debian.org/transitions/html/python3.11-add.html

I've set up a tracker [1].  It is based on the tracker used for
python3.11 with the inclusion of boost-defaults (which is otherwise
not pulled in) and the exclusion of dh-python (which confused ben in
dependency levels 1 and 2).  Excluding the 'unknown' packages on the
tracker (which should not need rebuilding), it lists the same packages
as the old one.

Regards
Graham


[1] https://release.debian.org/transitions/html/python3.12-add.html

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Chris Lamb]

tags 1055039 + pending
thanks

Hey Arnaud!

> Long story below.

A huge thanks for tracking this down! I've gone ahead and removed
ProcSubset=pid from the systemd unit files, and am uploading a version
to unstable and experimental right now. However, do you think this
warrants an update to stable as well…? Thanks again.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1055080: obfuscate: Missing manpage

[Jeremy Bícha]

On Mon, Oct 30, 2023 at 8:39 PM gregor herrmann  wrote:
> The next step, as usual, was to type `man obfuscate', but alas:
>
> % man obfusctate
> No manual entry for obfusctate
>
> (Also to --help output is not very helpful …)

obfsucate does not have any command line options.

For a GNOME app like this, I believe it's more customary to provide
help pages instead. (This app doesn't have that either.)

Thank you,
Jeremy Bícha

Bug#1054574: adminer seems dead upstream, switch to adminerevo ?

[Chris Lamb]

Hi Alexandre,

> 1) new package src:adminerevo providing adminer and removal of src:adminer
>
> Advantages : explicit branding
>
> 2) src:adminer using adminerevo source and building adminer pkg
>
> Advantages : easy upgrade path (no Provides:, Conflicts:, no conffile
>  moving around in postinst)
>
> 3) src:adminer using adminerevo source and building adminerevo pkg
>
> Advantages : explicit branding for binary package and easier
>  going back if src:adminer ever comes back alive

Hmm. Unfortunately I'm a little bit out of the loop with adminer
stuff so I won't be able to provide anything close to reliable
guidance.

However, I'm a little hesitant re. using the existing src:adminer with
the adminerevo source (ie. #2 and #3) on philosophical/aesthetic
grounds. It just feels "right" to have a different source package for
that.

Perhaps consider raising this on debian-devel for clarification,
otherwise I'd go with #1.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory

[Mark Hindley]

Control: tags -1 upstream
Control: retitle -1 Upstream testsuite fails to produce deterministic results

Santiago,

On Sun, Oct 29, 2023 at 02:39:44PM +0100, Santiago Vila wrote:
> However, I can create a machine for you to reproduce the problem.

Thanks. I have reproduced on your provided machine, but still not locally and I
can't identify the underlying difference between the builds.

In the failure case the problem is in the upstream testsuite, specifically the
test for #491391 in tests/run-testsuite which produces

init.d:
bootchart
four
one
rmnologin
three
two

insserv:
override

rc0.d:

rc1.d:

rc2.d:
S01one
S01three
S01two
S02four
S98rmnologin
S99bootchart

rc3.d:
S01one
S01three
S01two
S02four
S98rmnologin
S99bootchart

rc4.d:
S01one
S01three
S01two
S02four
S98rmnologin
S99bootchart

rc5.d:
S01one
S01three
S01two
S02four
S98rmnologin
S99bootchart

rc6.d:

rcS.d:
error: incorrect 5 sequence bootchart not before rmnologin

The same failure mode appears to be responsible for armel and armhf autopkgtest
failures logged on ci.debian.net[1]

As Ian pointed out[2], there are significant and surprising changes in looping
order and behaviour between the successful and failing testsuites. The diff is 
attached.

Having said that, I still can't reproduce locally or determine a good fix.
Hopefully Jesse will have a useful contribution

Mark

[1]  
https://ci.debian.net/data/autopkgtest/unstable/armel/i/insserv/38435862/log.gz

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

diff -u --label /sshx\:atlas\:/tmp/build.log --label /home/mark/src/debian/insserv/build.log /tmp/tramp.mDUEXG.log /home/mark/src/debian/insserv/build.log
--- /sshx:atlas:/tmp/build.log
+++ /home/mark/src/debian/insserv/build.log
@@ -4,8 +4,15 @@
 dpkg-buildpackage: info: source changed by Mark Hindley 
  dpkg-source --before-build .
 dpkg-buildpackage: info: host architecture amd64
- fakeroot debian/rules clean
-echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
+dpkg-source: info: using patch list from debian/patches/series
+dpkg-source: info: applying install-binaries-ignore-PREFIX.patch
+dpkg-source: info: applying 11_debian_conf.patch
+dpkg-source: info: applying 110_portmap.patch
+dpkg-source: info: applying warn_in_ignore_mode.patch
+dpkg-source: info: applying 0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch
+dpkg-source: info: applying 0005-Fix-spelling-error-in-manpage.patch
+ debian/rules clean
+echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
 -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
 dh clean --with=bash-completion
dh_auto_clean
@@ -18,7 +25,7 @@
 make[1]: Leaving directory '/home/mark/insserv-1.24.0'
dh_clean
  debian/rules build
-echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
+echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
 -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
 dh build --with=bash-completion
dh_update_autotools_config
@@ -31,14 +31,14 @@
 cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2   -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe   -c map.c
 cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2   -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe   -c listing.c
 cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2   -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe   insserv.c -c 
-insserv.c: In function ‘main’:
-insserv.c:2923:20: warning: ignoring return value of ‘asprintf’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
+insserv.c: In function 'main':
+insserv.c:2923:20: warning: ignoring return value of 'asprintf' declared with attribute 'warn_unused_result' [-Wunused-result]
  2923 |asprintf(_path, "%s/.", optarg);
   |

Bug#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra  wrote:
> Source: crowdsec
> Version: 1.4.6-6
> Severity: serious
> X-Debbugs-Cc: k...@debian.org
> 
> Dear Maintainer,
> 
> crowdsec fails its autopkgtests on unstable with:
> 
> | 316s === RUN   TestOneShot
> | 316s journalctl_test.go:172: Expected log output 'journalctl: invalid 
> option' but got nothing !
> | 316s --- FAIL: TestOneShot (0.08s)
> | 316s === RUN   TestStreaming
> | 316s journalctl_test.go:181: unreliable test: 
> https://github.com/crowdsecurity/crowdsec/issues/2352
> | 316s --- SKIP: TestStreaming (0.00s)
> | 316s FAIL
> | 316s FAIL   
> github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/journalctl0.225s
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers 
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers/v1  
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/middlewares/v1  
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/cstest[no test files]
> 

Full log at: 
https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz

> This is currently blocking golang-github-gin-gonic-gin to testing which
> fixes a bunch of RC bugs (of same kind).

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

Source: crowdsec
Version: 1.4.6-6
Severity: serious
X-Debbugs-Cc: k...@debian.org

Dear Maintainer,

crowdsec fails its autopkgtests on unstable with:

| 316s === RUN   TestOneShot
| 316s journalctl_test.go:172: Expected log output 'journalctl: invalid 
option' but got nothing !
| 316s --- FAIL: TestOneShot (0.08s)
| 316s === RUN   TestStreaming
| 316s journalctl_test.go:181: unreliable test: 
https://github.com/crowdsecurity/crowdsec/issues/2352
| 316s --- SKIP: TestStreaming (0.00s)
| 316s FAIL
| 316s FAIL 
github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/journalctl0.225s
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers 
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers/v1  
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/middlewares/v1  
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/cstest[no test files]

This is currently blocking golang-github-gin-gonic-gin to testing which
fixes a bunch of RC bugs (of same kind).

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

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

Bug#1055106: Test failure prevents Django 4.x from entering in testing

[s3v]

Package: src:django-tables
Version: 2.6.0-1
Severity: grave
Tags: patch


Dear Maintainer,
Tests fail on Debian CI infrastructure [1] and on my local machine as well
(full log attached).
This failure prevents python-django (3:4.2.6-1) from entering in testing [2].

$> autopkgtest --no-built-binaries django-tables_2.6.0-1.dsc -- null
...
...

ImportError: cannot import name 'url' from 'django.conf.urls' 
(/usr/lib/python3/dist-packages/django/conf/urls/__init__.py)
autopkgtest [14:12:24]: test test-run-py3: ---]
autopkgtest [14:12:24]: test test-run-py3:  - - - - - - - - - - results - - - - 
- - - - - -
test-run-py3 FAIL non-zero exit status 1
autopkgtest [14:12:24]:  summary
command1 PASS
test-run-py3 FAIL non-zero exit status 1


The root cause is that url() function was deprecated since Django 3.1 [3]
and removed in Django 4.x
Attached patch addresses the failure.

Kind Regards


[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/django-tables/39070283/log.gz
[2] https://qa.debian.org/excuses.php?package=python-django
[3] https://code.djangoproject.com/ticket/31534--- django-tables-2.6.0/debian/tests/test-run-py3   2023-05-25 15:35:19.0 +
+++ django-tables-2.6.0/debian/tests/test-run-py3-new   2023-10-31 14:37:50.661433357 +
@@ -45,14 +45,14 @@
 
 
 cat > testproject/urls.py << __EOF__
-from django.conf.urls import url
+from django.urls import re_path
 from django.contrib import admin
 
 from tutorial.views import people
 
 urlpatterns = [
-url(r'^admin/', admin.site.urls),
-url(r'^people/', people)
+re_path(r'^admin/', admin.site.urls),
+re_path(r'^people/', people)
 ]
 __EOF__
 


full_log.tar.gz
Description: application/gzip

Bug#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory

[Martin Budaj]

Thanks, I'll check it out in a week or so.
Martin

On Fri, Oct 27, 2023, 21:21 Lucas Nussbaum  wrote:

> Source: therion
> Version: 6.1.8-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9 -DTHLINUX
> -I/<>/build -I/<> -isystem /usr/include/webp
> -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/utest.dir/utest-proj.cxx.o -MF
> CMakeFiles/utest.dir/utest-proj.cxx.o.d -o
> CMakeFiles/utest.dir/utest-proj.cxx.o -c /<>/utest-proj.cxx
> > /<>/utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No
> such file or directory
> > 1 | #include 
> >   |  ^~
> > compilation terminated.
> > [113/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thwarppt.cxx.o -MF
> CMakeFiles/therion-common.dir/thwarppt.cxx.o.d -o
> CMakeFiles/therion-common.dir/thwarppt.cxx.o -c
> /<>/thwarppt.cxx
> > [114/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion.dir/therion-main.cxx.o -MF
> CMakeFiles/therion.dir/therion-main.cxx.o.d -o
> CMakeFiles/therion.dir/therion-main.cxx.o -c
> /<>/therion-main.cxx
> > [115/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thsvg.cxx.o -MF
> CMakeFiles/therion-common.dir/thsvg.cxx.o.d -o
> CMakeFiles/therion-common.dir/thsvg.cxx.o -c /<>/thsvg.cxx
> > [116/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thtexfonts.cxx.o -MF
> CMakeFiles/therion-common.dir/thtexfonts.cxx.o.d -o
> CMakeFiles/therion-common.dir/thtexfonts.cxx.o -c
> /<>/thtexfonts.cxx
> > [117/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thpdf.cxx.o -MF
> CMakeFiles/therion-common.dir/thpdf.cxx.o.d -o
> CMakeFiles/therion-common.dir/thpdf.cxx.o -c /<>/thpdf.cxx
> > [118/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thwarpp.cxx.o -MF
> CMakeFiles/therion-common.dir/thwarpp.cxx.o.d -o
> CMakeFiles/therion-common.dir/thwarpp.cxx.o -c /<>/thwarpp.cxx
> > [119/168] /usr/bin/c++ -DFMT_SHARED -DIMG_API_VERSION=1 -DPROJ_VER=9
> -DTHLINUX -I/<>/build -I/<> -isystem
> /usr/include/webp -isystem /<>/extern/quickhull -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -Wextra -MD -MT
> CMakeFiles/therion-common.dir/thsymbolset.cxx.o -MF
> CMakeFiles/therion-common.dir/thsymbolset.cxx.o.d -o
> CMakeFiles/therion-common.dir/thsymbolset.cxx.o -c
> /<>/thsymbolset.cxx
> > ninja: build stopped: subcommand failed.
> > dh_auto_build: error: cd build && LC_ALL=C.UTF-8 ninja -j8 -v returned
> exit code 1
> > make[1]: *** [debian/rules:33: 

Bug#1055104: ITP: netspeed -- Monitor network interface stats like upload/download speeds, bytes transferred, etc. in a GUI.

[Divyanshu Agrawal]

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

* Package name: netspeed
  Version : 0.1.1
  Upstream Author : Divyanshu Agrawal 
* URL : https://github.com/agrawal-d/netspeed/
* License : AGPL-3.0-or-later
  Programming Lang: Rust
  Description : Monitor network interface stats like upload/download 
speeds, bytes transferred, etc. in a GUI.

netspeed is a tiny utility to monitor network speeds and
other statistics of all network interfaces on your device.

It has a simple GUI interface and is useful if you want
to quickly observer your network.

It has a simple, easy to maintain codebase with no complex
dependencies: https://github.com/agrawal-d/netspeed

Bug#1055103: webpack: split env

[Bastien Roucariès]

Package: webpack
Version: 5.76.1+dfsg1+~cs17.16.16-1
Severity: important

Dear Maintainer,

I think the way to go is to split env from webpack

env need webpack to build but need a few package


Yadd what do you think ?

Bastien

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

Bug#1055069: please enable SC8280XP sound modules

[Emanuele Rocca]

Hi Dmitry!

On 2023-10-31 02:17, Dmitry Baryshkov wrote:
> BTW, Emanuele, are you by chance responsible for the X13s wiki page?

I started it, but most of the useful content has been provided by
someone else. :-)

See https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s?action=info

> There are several corrections that I'd like to suggest.

It's a wiki, please feel free to contribute your improvements directly.

  Emanuele

Bug#1055102: odbcinst1debian2: Error while installing package

[Janos Katein]

Package: odbcinst1debian2
Severity: important
X-Debbugs-Cc: moo-...@posteo.net

Dear Maintainer,

I wanted to install the odbcint1debian2 package and I expected it to
install properly. But instead I got the following error message:

Package failed to install:
Error while installing package: trying to overwrite 
'/usr/lib/x86_64-linux-gnu/libodbcinst.so.2.0.0', which is also in package 
libodbcinst2

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

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

Versions of packages odbcinst1debian2 depends on:
ii  libc6 2.36-9+deb12u3
ii  libltdl7  2.4.7-5
ii  libodbcinst2  2.3.11-2+deb12u1
iu  odbcinst  2.3.11-3

odbcinst1debian2 recommends no packages.

odbcinst1debian2 suggests no packages.

Bug#1055084: [Pkg-raspi-maintainers] Bug#1055084: raspi-firmware: Raspberry Pi 4 fails to boot 6.1.0-13-arm64 reliably (detects /dev/mmcblk0 instead of mmcblk1)

[Lucas Nussbaum]

On 31/10/23 at 10:44 +0100, Cyril Brulebois wrote:
> Hi Lucas,
> 
> Lucas Nussbaum  (2023-10-31):
> > After upgrading my RPI4 to bookworm, it no longer boots reliably.
> > Sometimes the SD card gets detected as mmcblk0, sometimes as mmcblk1,
> > causing the initramfs to fail to find the root filesystem.
> > 
> > Going back to the bullseye kernel (5.10.0-26-arm64) makes it boot
> > reliably, detecting the SD card as mmcblk1.
> 
> Using label-based booting makes this issue go away:
>   
> https://salsa.debian.org/raspi-team/image-specs/-/commit/f89f71560d2ca1bd60d97dbb26b89782657d56ae
> 
> Before this commit, the first few boots would happen with a label-based
> booting, but that would go away as soon as the raspi-firmware hook would
> run, leaving you to get either mmcblk0 or mmcblk1 at boot-up.
> 
> I only observed that on the Pi 4 family (Pi 4 and Compute Module 4), and
> I'm not sure this is directly linked to the Linux version. (I've had a
> lot of back and forth due to heavy debugging so I don't recall coming to
> a conclusion for that one except “use labels, always”.)

Thanks!

So, assuming there's a specific issue when upgrading from bullseye to
bookworm (which I believe but I'm not 100% sure), this would affect
upgrades but not new installs, since new installs now use partition
labels.

For reference, to fix this, I did:
# check that I use labels
lsblk -o name,mountpoint,label,size,uuid
# edit /etc/default/raspi-firmware
sed -i 's/^#ROOTPART=.*/ROOTPART=LABEL=RASPIROOT/' /etc/default/raspi-firmware
# apply changes to cmdline.txt
dpkg-reconfigure raspi-firmware
# check that cmdline.txt looks good
# reboot

Lucas

Bug#1054574: adminer seems dead upstream, switch to adminerevo ?

[Alexandre Rossi]

Hi,

> according to git activity and comments in the issues, adminer seems dead
> upstream.
> 
> Part of the community have forked it into adminerevo:
> 
> https://docs.adminerevo.org/
> 
> Would you consider packaging that instead of adminer ?

Yes, I'm thinking about it and I'm wondering on the strategy regarding
upgrades.

Options are:

1) new package src:adminerevo providing adminer and removal of src:adminer

Advantages : explicit branding

2) src:adminer using adminerevo source and building adminer pkg

Advantages : easy upgrade path (no Provides:, Conflicts:, no conffile
 moving around in postinst)

3) src:adminer using adminerevo source and building adminerevo pkg

Advantages : explicit branding for binary package and easier
 going back if src:adminer ever comes back alive

Maybe Chris can advise here.

Thanks,

Alex

Bug#1055101: RFS: libapache2-mod-authn-otp/1.1.10-1 -- Apache module for one-time password authentication

[Daniel Fancsali]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libapache2-mod-authn-otp":

* Package name : libapache2-mod-authn-otp
  Version  : 1.1.10-1
  Upstream contact : "Archie L. Cobbs" 
* URL  : 
* License  : Apache License 2.0
* Vcs  :  
  Section  : httpd

The source builds the following binary packages:

libapache2-mod-authn-otp - Apache module for one-time password 
authentication
To access further information about this package, please visit the 
following URL:


 

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


 dget -x 



Changes since the last upload:

None - initial upload.

Regards,
Daniel Fancsali

Bug#1055100: calibre: Installation in Bookworm stable is not possible. Paketdaten sind beschädigt.

[Martin]

Package: calibre
Version: calibre_6.13.0+repack-2+deb12u1_all.deb
Severity: important
X-Debbugs-Cc: 11luk...@posteo.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

The installation of calibre is not possibel. I tried it with synaptic and with
apt

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

Trying to install ends up with a message, that the package is defect

   * What was the outcome of this action?

Entpacken von calibre (6.13.0+repack-2+deb12u1) ...
dpkg-deb (Unterprozess): Dekomprimieren des Archivs
»/var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb«
(Größe=28871284), Element »data.tar«: lzma-Fehler: komprimierte Daten sind
beschädigt
dpkg-deb: Fehler: »«-Unterprozess gab den Fehlerwert 2 zurück
dpkg: Fehler beim Bearbeiten des Archivs
/var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb (--unpack):
 »dpkg-deb --fsys-tarfile«-Unterprozess gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/calibre_6.13.0+repack-2+deb12u1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

   * What outcome did you expect instead?

The installation of calibre

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/2 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 calibre depends on:
ii  ca-certificates20230311
pn  calibre-bin
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.5-2
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.4.2-final+dfsg-1
ii  optipng0.7.7-2+b1
ii  poppler-utils  22.12.0-2+b1
ii  pyqt6-dev-tools6.4.2-1
ii  python33.11.2-1+b1
ii  python3-apsw   3.40.0.0-2+b1
ii  python3-bs44.11.2-2
ii  python3-chm0.8.6-3+b4
ii  python3-css-parser 1.0.8-1
ii  python3-cssselect  1.2.0-2
ii  python3-dateutil   2.8.2-2
ii  python3-feedparser 6.0.10-1
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-8+b1
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-3
ii  python3-lxml   4.9.2-1+b1
ii  python3-markdown   3.4.1-2
ii  python3-mechanize  1:0.4.8+pypi-5
ii  python3-msgpack1.0.3-2+b1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-pil9.4.0-1.1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-py7zr  0.11.3+dfsg-5
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pyparsing  3.0.9-1
ii  python3-pyqt6  6.4.2-1
ii  python3-pyqt6.qtquick  6.4.2-1
ii  python3-pyqt6.qtsvg6.4.2-1
ii  python3-pyqt6.qtwebengine  6.4.0-1
ii  python3-pyqt6.sip  13.4.1-1
ii  python3-regex  0.1.20221031-1+b1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.4-2
ii  python3-zeroconf   0.47.3-1
ii  python3.11 3.11.2-6
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.3.0-1
ii  python3-ipython8.5.0-4
ii  qt6-wayland6.4.2-1
ii  udisks22.9.4-4

Versions of packages calibre suggests:
pn  python3-unrardll  

Bug#1042572: claws-mail: can't update claws-mail to v4.1.1 from bullseye-backports

[Andreas Rönnquist]

On Wed, 2 Aug 2023 18:14:11 +0200 Ricardo Mones  wrote:
> Hi,
> 
> On Sun, 30 Jul 2023 15:41:15 +0100
> no2spam  wrote:
> 
> > Package: claws-mail
> > Version: 4.1.1-2~bpo11+1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > I'm using claws-mail on Debian Bullseye. Update fails because of a
> > plugin version mismatch in bullseye-backports repository:
> > 
> >  * claws-mail-bsfilter-plugin is still on version 4.1.0-2~bpo11+1
> 
> This plugin was temporarily removed to allow migration to testing, so
> is not present on that version. Since the plan was to add it again ASAP
> the dependencies were not adjusted to remove it, unfortunately. This
> was my mistake, so sorry for that. You can allow upgrade by removing it
> with your preferred package manager, e.g.:
> sudo apt remove claws-mail-bsfilter-plugin
> 
> >  * claws-mail-pgpcore is missing (dependency of claws-mail-pgpinline
> >package)
> 
> The pgpcore plugin is provided by claws-mail-pgpmime, so just install
> it, e.g.:
> sudo apt install claws-mail-pgpmime
> 
> Not sure why you're experiencing this issue, these dependencies have
> not changed in ages.
> 
> > Could you upload claws-mail-bsfilter-plugin (v4.1.1 amd64) to the
> > bullseye-backports repository? That should fix it.
> 
> Current stable release is bookworm, so not sure if current backporter is
> interested in bullseye. You should probably consider upgrading your
> system to bookworm, which is where the next backport is more likely to
> happen.


The packages are now in the debian backports NEW queue, so you should
be able to get them soon.

best
-- Andreas Rönnquist
gus...@debian.org

Bug#1055069: please enable SC8280XP sound modules

[Dmitry Baryshkov]

Hi!

On Tue, 31 Oct 2023 at 13:31, Emanuele Rocca  wrote:
>
> Hi!
>
> On Mon, Oct 30, 2023 at 07:54:25PM +0100, Vincent Blut wrote:
> > Le 2023-10-30 20:30, Dmitry Baryshkov a écrit :
> > > Package: src:linux
> > > Version: 6.5.8-1
> > > Severity: normal
> > >
> > > Please enable the following options as modules to enable audio support
> > > on Lenovo X13s platform:
> > >
> > > CONFIG_SND_SOC_SC8280XP
> > > CONFIG_SC_LPASSCC_8280XP
> >
> > Emanuele, as you’re working on support for the Lenovo X13s platform, could 
> > you
> > please comment on that?
>
> Looks good, I've opened 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/880

Thank you!

BTW, Emanuele, are you by chance responsible for the X13s wiki page?
There are several corrections that I'd like to suggest.

-- 
With best wishes
Dmitry

Bug#1055099: rust-async-task: Failing autopkgtests

[Jeremy Bícha]

Source: rust-async-task
Version: 4.5.0-1
Severity: serious

The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.

https://ci.debian.net/packages/r/rust-async-task/testing/amd64/

Autopkgtest log excerpt
--
showing two different errors:

157s error[E0425]: cannot find function `spawn_local` in crate `async_task`
157s   --> examples/spawn-local.rs:22:40
157s|
157s 22 | let (runnable, task) = async_task::spawn_local(future, schedule);
157s|^^^ not found
in `async_task`
157s
157s error[E0554]: `#![feature]` may not be used on the stable release channel
157s  --> benches/spawn.rs:1:12
157s   |
157s 1 | #![feature(test)]
157s   |
157s
157s For more information about this error, try `rustc --explain E0554`.
157s error: could not compile `async-task` due to previous error


Thank you,
Jeremy Bícha

Bug#1053310: Fixes for stable/oldstable?

[Tomas Pospisek]

Hi Salvatore,

thanks a lot for your reply (more below):

On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote:


Hi Tomas,

On Tue, Oct 31, 2023 at 11:07:06AM +0100, Tomas Pospisek wrote:

Hello Exim maintainers,

this ticket, asking for packages with fixes for CVE-2023-42117 and other
security relavant issues is closed.

However only a package for unstable has been released:

https://security-tracker.debian.org/tracker/CVE-2023-42117

all other Debian releases (stable, oldstable) still seem to be carrying the
vulnerable Exim4 version.

What is the status of releasing fixed Exims for Debian stable, oldstable? Is
anybody working on it? Is help needed?


Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered
no-dsa (see comment on the security-tracker about it), and are going
to be fixed in the next point releases.


The notes say:

***
[bookworm] - exim4  (Only an issue if Exim4 run behind an
 untrusted proxy-protocol proxy)
[bullseye] - exim4  (Only an issue if Exim4 run behind an
 untrusted proxy-protocol proxy)
[buster] - exim4  (Only an issue if Exim4 run behind an untrusted
   proxy-protocol proxy)
https://www.zerodayinitiative.com/advisories/ZDI-23-1471/
https://bugs.exim.org/show_bug.cgi?id=3031
https://www.openwall.com/lists/oss-security/2023/09/29/5
https://www.openwall.com/lists/oss-security/2023/10/01/4
https://exim.org/static/doc/security/CVE-2023-zdi.txt
***

So I think I can parse from those that CVE-2023-42117 is only critical 
when exim is run behind a "untrusted proxy-protocol proxy".


Questions if you will:

* what does "no-dsa" mean? DSA seems to mean Debian Security Announce.
  Does it mean there is no DSA for that problem yet? What does it mean
  when a CVE is considered "no-dsa" then? That no DSA will be released for
  it?
* what is a "untrusted proxy-protocol proxy" in the context of a mail
  transport agent? So exim shouldn't be used behind an untrusted socks
  proxy? Well I have no real control who connects how to a public MTA...
  anybody can connect to it to try his luck sending me email. That
  includes untrusted socks proxies...

So to wrap I it /seems/ that I'm probably fine, however the details are so 
terse that my assessement seems to be rather shaky...



Does this help?


A bit. Thanks a lot

Best greetings!
*t

Bug#1055088: game-data-packager: jazz_jackrabbit_collection information outdated

[Simon McVittie]

On Tue, 31 Oct 2023 at 09:43:42 +0100, Fabian Greffrath wrote:
> the packaging information for the jazz_jackrabbit_collection package
> from GOG.com is outdated. Thre is a new package available for download
> called 'setup_jazz_jackrabbit_collection_2.0_csv2_(51327).exe' now,
> and some of the file contents have changed.
> 
> What is the best way to update g-d-p in this regard? Manually, file by
> file? Or is there a better way?

game-data-packager make-template --base=jazz-jackrabbit 
setup_jazz_jackrabbit_collection_2.0_csv2_(51327).exe

should provide a reasonable starting point: it will try to guess how
the contents of the installer should be installed, and how they intersect
with the groups of files in the existing data/jazz-jackrabbit.yaml.

The output will need some adjustment, because make-template can't know
anything about a particular game's semantics. If some of the binary blobs
have changed, I would guess that you'll probably want to represent them as
"use foo.bar?2.0 if available, or foo.bar?1.2, or foo.bar?1.0" similar to
how data/doom.yaml works.

Or you might want to represent different versions as different packages,
similar to the way that in data/larry.yaml, larry1-en-data is marked as a
"better_version" of larry1-ega-data.

smcv

Bug#1055069: please enable SC8280XP sound modules

[Emanuele Rocca]

Hi!

On Mon, Oct 30, 2023 at 07:54:25PM +0100, Vincent Blut wrote:
> Le 2023-10-30 20:30, Dmitry Baryshkov a écrit :
> > Package: src:linux
> > Version: 6.5.8-1
> > Severity: normal
> > 
> > Please enable the following options as modules to enable audio support
> > on Lenovo X13s platform:
> > 
> > CONFIG_SND_SOC_SC8280XP
> > CONFIG_SC_LPASSCC_8280XP
> 
> Emanuele, as you’re working on support for the Lenovo X13s platform, could you
> please comment on that?

Looks good, I've opened 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/880

  Emanuele

Bug#1055098: rust-unicode-segmentation: please update to v1.10.1

[Jonas Smedegaard]

Source: rust-unicode-segmentation
Version: 1.9.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v1.10.1.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA5AsACgkQLHwxRsGg
ASGzJw/9Gk2xOid0Hs2Rb+350FOeQ8VWbTBcLACGjjAsSeT6+EDIsc0CLcv0UMd8
5WVmdALYLmhaDEMGuFzVC9YxxLAYY1hcJSZ3cYTuEGfGEha37nDL6RQuobpG3kvK
X05ISS8yEPv+gvCyhxnSzY5tGjH8VtbyKq8/ieDcIikQMuxErHzBEdCvBMid/fFG
dw3Lx50PL5Xg2HpfLID56FiUpOmVJuBm/Zv6vxzAJG74wLSU9UhTWb9fsP/i08yH
NW4GEmWeCFWfuksiZZGRSwdHYTbwXJ2qoq44KPpuOmnLyLkLW9K2KuQW1vK531Id
c0JrIT16EJi5taoBM/9CbD6EZ5bO50Ll6xiLgEyi03h1/oo914233stbJ2AMKnqW
NFX+gIMNlA9cS/wJ72Dp5FL/9GINcCdgsaAtNj9/r+SSxXOYb/8whBwZrC6FWCAs
0HDc88ZNCqY8sk/Bw2rmRfGbKH4fR0ipz4Phn1/OmClCBClRO3WcsEGRcrGWnOIE
wM8v/Uiq7SF/n/cyYRfQFPLeSLQUDEyx9VFzg0yJ+4VBJSTUlD7l+KnCbeGO/Xt6
Wm7Es9gv9uT8yY5TdpgpirfVriMTGhJ4zVv3sQN6wjSkeS6WewdQTnu3MgIYVM5T
+LF2C7F3ME7lXe4jHbigBn6YqVsSOkr6u3HHQVnoQXlZ1eFAqAI=
=xnTW
-END PGP SIGNATURE-

Bug#1055097: rust-time: please update to v0.3.26

[Jonas Smedegaard]

Source: rust-time
Version: 0.3.23-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.26.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA45wACgkQLHwxRsGg
ASFqhA//QwTnZ9zzBpVB6XP1Zu97//SzagcXJPbJS2o5e4iDr6zNwhR4h4EjldFa
3YaBty6XCA4JWHc1rdbnq7zeZTYtIDWLzX8AzNCdvA+E9ccjnTA4PYZN5cuYlR5r
iSh3k0ERuNbgV0tcbcsP+TQWeQPVg6FEwk/GW+b99K45GK60HZomIgh+CyFzUXgX
A11MvP3MnP6wCV5Nqe/3UpSbEHieZ4Cq2/Rk2/lzgnO4N7hy40oFEgi/BX/YYecY
LmihJtT1kb2rNhSkwv3BDMLAz+QUz8CgCtAIvXx5rsPW+8/8emZViOIFhRywCDMN
BIuc2VlbgKVZEhJqWefyjeeOQyDmoydsqrVZbY/niwzgMGHjT8qO2uveUlt97wi9
l9eiPBV4QgVOtUxRc5CL+rChFWezpvp1E3X/gjDf1aM0YHC+GuMq9dq0Wos/3ZaJ
6nvoAwkSWgtp8FtITVDWI2j5ME59VB9bBl2JnTvLPQd3RegmuWRuwKvpC2sNOMpN
G1sLW+70JdRJcuxqz4mceCKwUNo4fZj6qnkUu260DVmN3MdFNYX++G9tS8XjxhOd
EqZDm+PuNKN330l8QQUQp77f1r0vauyN16/cCjgDSzLaQeqbffKHkCQOTQGVkkmE
IEQi2TgoyNT8TNBh82WJhuk1LRvX5SqMbBsstWTqRz9WxdQSyX8=
=XkSk
-END PGP SIGNATURE-

Bug#1055096: rust-sysinfo: please upgrade to v0.29

[Jonas Smedegaard]

Source: rust-sysinfo
Version: 0.28.4-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.29.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA40IACgkQLHwxRsGg
ASHAwA//XX0pwAr5MnJeHz8LtP7NIsHG+9clcZ2KqZxyq6PpJRkzO1XNgb+jzOI1
1oEoxH/GUSB4w6GaCd4LybJUfodLczF23doQxgXYAjcHnPV6dziPQx75WBOLgHjB
lKwXtrbAOPTQhRRqSeutwrCN4fEGnFxn3Rf43bMowQ/VUMPUNaa1BUcCDD1aerbV
ghjWp6Ff/zEgdPvejeO4w1OKDJKi2pr5PKgxs8lJlTUzASyq0b9GiTevGfegpFhp
jgBkCoo/Q48lZCp156iQGYRRGCosDXsa6+dZ5gCFEQeS/RUzDlLMoy97XtOobvy7
i2VgteEMkI/KrrBYI1TVAOrHsrobio14QUwUjnYh2K53J647Ch97eVukyUehShji
2AnIm71M5zjXtmRkddYdER5OMiz7GhxC9Z5LNmDaOdXvkraHEjSpXUv5eAsys1tt
eRLjcGVWJCMOQKyy9mXfy0Q9oLAGxCsBUxpxeFIUnRlU2dgKjejxZGXdtz3ZBT4r
cmMjH0FOmxwW2roEzBgfLtc+p9Gnau+qwO7PvoDaRR1W37LpSJnKoQabq3mYJJOD
c+hOPy+Fasjfu1e/nPijXx/Bzy/iu2pc5K8sv0sTRUw/nhigSAjMlq/k2bI4vstJ
ACW8A1BMJF8IuE9bxf7RAuUX8Snrh1hH0oPcWi+H6SP1S+8Z5WI=
=5CJL
-END PGP SIGNATURE-

Bug#1055095: rust-sysctl: please upgrade to v0.5

[Jonas Smedegaard]

Source: rust-sysctl
Version: 0.4.4-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.5.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4wgACgkQLHwxRsGg
ASFy0A/+MVzrnckZefX6kz7uKQfr8SqoO1Ks343XhsLs0vxexWOVUa9vNJqOkpej
SSfwQ/0qjv1BM3yOnq3Dj277lSlyqs1ekto0VeCMHh7PWp+YXHqx01xTv+x9Gm8G
k+CF6hbsqNN9z8ZLRoyBjHwvsspRZmF8hG22cR3pabyJeOHuGJcat9gwq7eZaHXN
0s9MTW9TRQrigWDGUy01zauj4s10yCaqAdkmuwDMbH1xIy7QGbrWIjufmJVTOUAu
NF3NEmDWWfeipl3QYALIK27/hex/mbLLa1/bUEhIfoRvKEkwpyi/UZkmGoDvpv+g
8/3BYSKIG/a21XzMWRic2kB6mM4+cyHq7HEtlWt6rAGAXF0cOaVVW+jzZwEhlQ/O
wEdAuQSbytiln80lHrA0TWJmp/SyLITeG4ZMTCGYmNoeWNVL/Y1F89sNaH1sfsjo
mzWxcKj2MOVzKj9NVr7ZMdbjShoqtU2AhbPQsCRWRRLY+ER3FpOu9fhNz3n1FPln
jvYcEHF5rQwebpxY2kSPhvKeeghU1VOh5aTkYeMu7nyka3R9H0N+PlhEQIJtrvLi
YG/QqgdT6uh0Pnr09E3B4Sq5mBhbnOv/sc0DkKpITJOIDnVaFlicJlPS7dWblMJv
CK8RWKNZSjEv2urQt/E2TxaEUPRBHdJcGqlgt4yWE52e2HGvKtk=
=Bmkr
-END PGP SIGNATURE-

Bug#1055094: rust-starship-battery: please update to v0.8.2

[Jonas Smedegaard]

Source: rust-starship-battery
Version: 0.8.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.8.2.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4ssACgkQLHwxRsGg
ASFwXw/+Jo0Ycw86r5aQGXA/eWA4GMUNnaJpYl01kHY6BurXXptCou5NMUoUUabC
PIer/no2cEh6dFSMtVUKQ7XCAvdwJofPwKOazRnYGwFeXU3Fso/+NG9J1DqBptEQ
0mB0nFRHOvTuhohJMGG6Cx8ZH7k/dgQCh9piIRD2hYa2ObswXWfQGfcnYMCXywcf
UDqThe/2t25gN0OFLKri8yDZTTifkWapOL4yO+Zy1niKOt2SsLjJXMwm8d2A0pJC
mPNB3zT5azH3TmvKPridJs/LMFWHrwIcM3DI7IcWJxSIvAOM3SYnJTLWMrJ2I1uq
XX8Ngu0hZhfuzR5ev32hLiRXXBy9QaFn1zzgfK9QlEgLFxKeTH65CmA+2LfJax+9
iwzmG70evtWJ9vP8gi2XG2lutNnGln8eoYLmegxim8ELD66g5UWlkzsAIjXrLpbp
6anLa20clQ7I0hGk3fR/2P2cxfloV0IKd6t68RsEjiY8i3TnDRQF1FqNf7/i2S+1
zKbBxvAECc1nJmGc0EtAMfKxATdl5OA1Zif2HXQJ3d80gO0IhyvKqaoExb8tCbNR
B2/zb3rWeTAaGcEqulslcJKz70CB/FlVScQ8IK4m3tmQotyReuYsWvfL+ILjrw6h
yMtRhcjTxgImqKcJxW+0r9dK0DzPFDb8/Y2X5K8LT6K5dd/OuqQ=
=k0Z/
-END PGP SIGNATURE-

Bug#1055093: rust-serde-json: please update to v1.0.105

[Jonas Smedegaard]

Source: rust-serde-json
Version: 1.0.103-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v1.0.105.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4oEACgkQLHwxRsGg
ASHnOBAAjVUD97PNIBVQaWqUptRy67Bc/+/UwZFj5+BxulxsTFybpzRmsjRJLNEN
7t8SHO4tXHzERvjerLq0IornUSdXcKUK745UkSaVuuzea5Y1yAFlXU9EjylTm4J+
yrwAsrh1PJ51yiYt6GsdxtKrD72RP3HF2065y+Jq5DgyBDrix9lNmItgEuDNmkKP
d4eMtsmM0UhOnggq2Lzl0FRqtQUWeuGzf3YYfWNWmKcmCrlDUyYoaeJ8YUsC3oRb
vi/4jjQ8b10dXlXpWoPsrIGnCmifopMZGdeFIGRqM53Rm8JJimIEpXOZH67YKSei
SpGgMszOZfqNZizrjsK46/txrglHYTwbXn5x6FdNXXszTzu5SWmQvGMVgSq2ElRb
84gr69+WyX066jJEEwm9eH6f/anko+SeEoNtEmBQhFsByuTqBwIO0N/my1q4gEuw
7MJevkv3BOrAS2aP1lRHJWXsQ7b2Jmn3WOXeFxC+GYacCTP/dA5eAXa9I+pPDwWK
mQ+2IGei4P80iVmR66BzG7lfV65/yanY9br1mc6C5enjNuZqDP8JENBEC62DS7kf
oWmUdetwCEpV7T/jdYzvgzI0gz32WjcEMM8ZY+uQPXQAf2E1FGOs1H6NnFep6/op
t2+aV7nIavuYx8LNY4SCo9GgvtPUwrq/q/TZ8rEPGxUuapwBkjA=
=Gzi3
-END PGP SIGNATURE-

Bug#1055092: rust-hashbrown: please upgrade to v0.14

[Jonas Smedegaard]

Source: rust-hashbrown
Version: 0.12.3-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.14.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4a0ACgkQLHwxRsGg
ASEcUhAAqQDycWGBtgWKVTLeQrmlemHLJEri5IEHVD83H7HVB54dTyZNHRdxi9vV
GG8CjJ+NSlN3sRd3derVBmVIlk0f0S4OyeE6IKILjizDxlRf1SAIy9jemMzA1wK1
CWdadS/KYCTu0DTYvyQgaazXFsyzqZtn3ZAkwwYgFqU8bsH1gxlxDBjy+DDa4Jpk
eoIdUDkUJGZOeS7seVMz5gsPJ99SL6R7xLqygpEYfEyG4w0gE+vjoswNt+ILnLBt
t0hq9rubSNA+bP4fIiXJsVaNNrj+VHk+yH9TLiWbhD0/DTwfDIRZoQNEMnQ1g4JG
m7Tj9eTIWN8D0fVWgzy6XZsg0R9bVw97s88adjKGWy+Fnw2egFIJNNBps1tdt1a6
Ro19PHA1uzDuR55KlfyENniJu65pBQeLc2jgaWaE3EuSH8bol7t6CReBpSrLpjho
e2PSKz6UI+3y3xCbhe9Xr7cNoCvenxfnDKkejFLgjpUnaWI1B6BeSYsrONIRwqJF
ED/d2o7/gDJe8Fj4CEdZyaAP+0LUUVWy8R82Wo+mezFkvcqGBxS2MW97lcgCYDxy
dXT2zTC0MTRpk+rJT5t8DutToGaWgNXFrltOcXscDqq/CsXl2Cc6tFwEFLMNhFHI
8ApPh4WvbB+Hy3QqH7fFvisIi8nlO4L35NaCTj9qjDu56YccP6w=
=XIG1
-END PGP SIGNATURE-

Bug#1055091: rust-fern: please update to v0.6.2

[Jonas Smedegaard]

Source: rust-fern
Version: 0.6.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.6.2.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4V8ACgkQLHwxRsGg
ASHkhw/9HbdAQEU+A9nfbOz3oNdXgvJ7JXURf9MwP7qTgLQtbBjsgpkNsDoY27mc
a1MQ50BPT4QZNup5iOQvOQQLQiEhhvtXRO9eYpSqpFAih44jci8XO+JZ4CoeRSlj
Z/2VKo30ypWSHWE6xjuqo62zdK/GdeaHONNbS4m5CHfpPrhoEjZayLD7tC0Rj6pG
04lC0/4CxNM9djYmPHmuXFbjgQ4TiZx0XROcMuPitV6qqWGI0qw5+ADjmGSLZUTQ
QAFtnwC6q5y4Fo2PZnfMnTcVfCLs6r+F38jEOzgMU814C9uvRCexy1jWD5OAFRdf
diX12hXbzOmI+g142842rxrU27LB3HqtxxpDTYvtozzZYgIbSgtMXqacGez/Sj9t
uLjCB/AMT8uhdgUaDLXuTwNA7wWKisMyHvd9dJDZvHV8HDQYsBxmF/uyfP9o3AO7
UED4V3VagqgPcv47GvyD5BzE8hrNQjRlWhID5b5TgHrWdoUFhcj24jLkNrK/SMRI
o5LQMA65K6pYH9HMi6FujH5XKoXOA9YlkFdcNdtiRE4FuxvcQYqZ7ni6ujYnwtL4
eLwvIHQFZsGx0CZu8v9vGQ8n63pYj+LWcBevc6farX01yBCH9m5Mg18h5V29op5E
daT54zUw6IWJa7hF+wP9WlmFOAICnHwPKljBi6FV/mwwPBn8hjA=
=b41Z
-END PGP SIGNATURE-

Bug#1055090: rust-backtrace: please update to v0.3.69

[Jonas Smedegaard]

Source: rust-backtrace
Version: 0.3.68-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.69.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVA4I8ACgkQLHwxRsGg
ASE17RAArqfOrJzi+71BNO1yUm5uLyP25mj4vkBi5OT3siSlht81k3bfPaQ89i5t
/QfAl2i7TNAjHs/hyJyzXrnhQwHwNB+jAmQauMsqa/AvIbQzV1gnxZS7D5rivDjl
s1rXMtxPUO4aspa+AcTuWg7P0wn5io735UtXYYtBrtZ5+xvtr0CU5h38HEOcYlpE
C9Bp7pQn0p7m8wxruOlA0dEk8/exuDK04dZ8mY2CMWMqU0p2D0D0Ux56jItrkJI8
okWCURgG894ee/6VwKfyUqKe/xVp9atmZlfUZmHlWrzUR7USBw25ypaQCujm9gzq
WVLMq6ta5tqmPfFnvy4eJ8YsIbcmohKhakubgCKiJ9qtnxzcq/28CsoDEMFITNcJ
000QXSzjB/71Qe/xmbHtDpdUPyPjxT9xKLItHl924gfZozPw6ar5FPi6fRNOONaM
xqfKzHDHUfGdJPhxTN+2WuSW4+wT+HHxptqRJ2y2iGu/52QZQ5XiDJpabUpQ4Vj/
U/F7TJPTTBOLLcvzlY8eJ3Ke/eAiTLQ4W9LQhniW0UXEcnYxoGpUHfiaPPgDAFVy
S3SuiqBw4woL/ykmbHIekt9IGCSvovpeD+WvQhHxdH2IKQ8qro5gQvpyxEvncNyo
djFROsRa6hvDQkeA94gsqZiwuWslR3/TSn52411rgX4qXE6lOP4=
=3JPA
-END PGP SIGNATURE-

Bug#1053310: Fixes for stable/oldstable?

[Salvatore Bonaccorso]

Hi Tomas,

On Tue, Oct 31, 2023 at 11:07:06AM +0100, Tomas Pospisek wrote:
> Hello Exim maintainers,
> 
> this ticket, asking for packages with fixes for CVE-2023-42117 and other
> security relavant issues is closed.
> 
> However only a package for unstable has been released:
> 
> https://security-tracker.debian.org/tracker/CVE-2023-42117
> 
> all other Debian releases (stable, oldstable) still seem to be carrying the
> vulnerable Exim4 version.
> 
> What is the status of releasing fixed Exims for Debian stable, oldstable? Is
> anybody working on it? Is help needed?

Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered
no-dsa (see comment on the security-tracker about it), and are going
to be fixed in the next point releases.

Does this help?

Regards,
Salvatore

Bug#1053310: Fixes for stable/oldstable?

[Tomas Pospisek]

Hello Exim maintainers,

this ticket, asking for packages with fixes for CVE-2023-42117 and other 
security relavant issues is closed.


However only a package for unstable has been released:

https://security-tracker.debian.org/tracker/CVE-2023-42117

all other Debian releases (stable, oldstable) still seem to be carrying 
the vulnerable Exim4 version.


What is the status of releasing fixed Exims for Debian stable, oldstable? 
Is anybody working on it? Is help needed?

*t

PS: I'd prefer this bugreport to be open as long as the stable and
oldstable packages are still vulnerable...

Bug#1031192: toil: FTBFS (The job JobClass is requesting 2.0 cores)

[Santiago Vila]

El 31/10/23 a las 11:23, Michael R. Crusoe escribió:

 > (Ok, I *can* checkout such tag, but the fact that I can't
 > see it in a normal way makes me to suspect there may be
 > something wrong).
 >
 > (Maybe it is because I have a personal dislike for non-linear
 > history in git, but I don't really know if that's something
 > that it's covered by debian-med policy or not).

I also dislike non-linear history, but the mistake has already been made and 
there have been subsequent releases. So this disconnected tag is the best I can 
do, sorry.


Ok, I will base my bookworm branch on the appropriate tag which matches
the version in bookworm.

I asked just to be sure that it's ok.

Thanks a lot.

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Mon, 26 Jun 2023 21:20:15 +0200 Johannes Schauer Marin Rodrigues
wrote:

[...]
> Quoting Francesco Poli (2023-06-26 20:20:47)
> > If I may share my thoughts (daydreams?!?) about this issue, I was hoping to
> > see a (relatively) simple command able to create a QEMU/KVM image for
> > autopkgtest without requiring superuser privileges. An image that could be
> > easily upgraded after creation (without the need to re-create it from
> > scratch). Bonus, if the image can then be used also for interactive testing
> > of packages and for package building.
> > 
> > Basically, I was hoping to see [sbuild-qemu-create] drop the requirement
> > of superuser privileges (thus dropping the behind-the-scenes use of
> > vmdb2 and switching to some other backend)...
> > 
> > [sbuild-qemu-create]: 
> > 
> > I am not sure I clearly understand whether this may happen or whether
> > this is actually going to happen soon...
> 
> this is not a daydream and I think we have nearly all building blocks in place
> to make all of this happen very soon!
[...]
> Of course once either MR !236 or !237 get merged
[...]
> So I don't think it's a daydream.
[...]
> So stay tuned! :D


Hello!   :-)

I stayed tuned and I saw that mmdebstrap/1.4.0-1 ships a
mmdebstrap-autopkgtest-build-qemu that does not require superuser
privileges (according to its man page).

Do I understand correctly that this new script is one of the building
blocks that can make the above-summarized "daydream" come true?

Could you please give me a status update on the "daydream"?

Looking forward to hearing back from you.
Thanks for all the good stuff!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpxDDUrEBwZA.pgp
Description: PGP signature

Bug#1031192: toil: FTBFS (The job JobClass is requesting 2.0 cores)

[Michael R. Crusoe]

On Sat, 21 Oct 2023 13:17:42 +0200 Santiago Vila  wrote:
> El 21/10/23 a las 12:27, Michael R. Crusoe escribió:
> > On Fri, 20 Oct 2023 23:29:46 +0200 Santiago Vila 
 wrote:

> > > El 20/10/23 a las 23:08, Andreas Tille escribió:
> > > > Am Fri, Oct 20, 2023 at 10:12:17PM +0200 schrieb Santiago Vila:
> > > >>
> > > >> But then I also realized that version tagged "debian/5.9.2-2" 
in git

> > > >> is different than version 5.9.2-2 in the FTP archive, i.e.
> > > >> what I can get by doing "apt-get source toil" in bookworm.
> >
> > Whoops, what a huge mess. Probably my fault. I've re-imported the 
DSCs for debian/5.9.2-1 and debian/5.9.2-2 and reset the tags to point 
to them.

> >
> > Can you try again?
>
> I don't see the tag "debian/5.9.2-2" when I do "git log".
>
> (Ok, I *can* checkout such tag, but the fact that I can't
> see it in a normal way makes me to suspect there may be
> something wrong).
>
> (Maybe it is because I have a personal dislike for non-linear
> history in git, but I don't really know if that's something
> that it's covered by debian-med policy or not).

I also dislike non-linear history, but the mistake has already been made 
and there have been subsequent releases. So this disconnected tag is the 
best I can do, sorry.


--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055066: usrmerge: Cannot update to version 38 on sbuild

[Luca Boccassi]

Control: fixed -1 1.0.133
Control: fixed -1 1.0.128+nmu2+deb12u1
Control: fixed -1 1.0.123+deb11u2
Control: close -1

On Tue, 31 Oct 2023 at 08:02, John Paul Adrian Glaubitz
 wrote:
>
> Hello!
>
> I am not sure whether this issue has been fixed.
>
> We're seeing this issue on buildds and porterboxes on Debian Ports,
> regenerating the chroots fails:
>
> dpkg: warning: ignoring pre-dependency problem!
> Preparing to unpack .../tar_1.34+dfsg-1.2_ppc64.deb ...
> Unpacking tar (1.34+dfsg-1.2) ...
> Selecting previously unselected package usr-is-merged.
> Preparing to unpack .../usr-is-merged_38_all.deb ...
>
>
> **
> *
> * The usr-is-merged package cannot be installed because this system does
> * not have a merged /usr.
> *
> * Please install the usrmerge package to convert this system to merged-/usr.
> *
> * For more information please read https://wiki.debian.org/UsrMerge.
> *
> **
>
>
> dpkg: error processing archive 
> /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack):
>  new usr-is-merged package pre-installation script subprocess returned error 
> exit status 1
> Selecting previously unselected package util-linux.
> dpkg: regarding .../util-linux_2.39.2-5_ppc64.deb containing util-linux, 
> pre-dependency problem:
>  util-linux pre-depends on libblkid1 (>= 2.37.2)
>   libblkid1:ppc64 is unpacked, but has never been configured.
>
> Could it be that debootstrap needs to be switched to enabled usrmerge by 
> default?

The buildds have already been updated with a new config ~3 weeks ago:

https://lists.debian.org/debian-devel/2023/10/msg00019.html
https://lists.debian.org/debian-devel/2023/10/msg00024.html

Are the ports buildds managed differently? If so, they either need
that change, or to take debootstrap from proposed-updates where the
defaults have been switched. There is nothing actionable in
debootstrap, as the relevant changes have already been made and
uploaded (pending the next stable release to make it out of p-u).