Bug#1033091: clipman: Outdated clipman version in Debian Sid

[Callum Andrew]

Package: clipman
Version: 1.2.0+git20200218.39fd4fe-2+b5
Severity: normal
X-Debbugs-Cc: cchlori...@gmail.com

Dear Maintainer,
Can you please update the clipman package? The latest upstream
version is 1.6.1, which came out a while ago and has some improvements
over the version in Sid.

Thanks for maintaining the clipman package!

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

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

Versions of packages clipman depends on:
ii  libc6 2.36-8
ii  wl-clipboard  2.1.0-0.1+b1

clipman recommends no packages.

clipman suggests no packages.

-- no debconf information

Bug#1033090: unblock: dhcpdump/1.8-6

[Boian Bonev]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dhcpd...@packages.debian.org, kilob...@debian.org
Control: affects -1 + src:dhcpdump

Please unblock package dhcpdump

[ Reason ]
Patches in 1.8-6 fix:
 - a severe bug (OOB access) that is triggered by network data
 - a bug in protocol decode that make it non-working on big-endian
and improve/fix behavior for:
 - DHCP flags display
 - option 82 data display

[ Impact ]
Users will have a buggy tool.

[ Tests ]
Fully tested on different types of DHCP traffic.

[ Risks ]
Very low - the package is leaf and fixes are trivial to verify.

[ 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 testing

[ Other info ]
N/A

unblock dhcpdump/1.8-6
diff -Nru dhcpdump-1.8/debian/changelog dhcpdump-1.8/debian/changelog
--- dhcpdump-1.8/debian/changelog   2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/changelog   2023-03-08 16:43:02.0 +
@@ -1,3 +1,45 @@
+dhcpdump (1.8-6) unstable; urgency=medium
+
+  * QA upload.
+  * Upload 1.8-5 fixes to unstable.
+
+ -- Adam Borowski   Wed, 08 Mar 2023 17:43:02 +0100
+
+dhcpdump (1.8-5) experimental; urgency=medium
+
+  [ Boian Bonev ]
+  * QA upload.
+  * Install binary and man page.
+  * Add patches that fix:
+- build options in Makefile (hardening and cross)
+- ethertype handling (Closes: #873635)
+- flags calculation
+- opt82 processing
+- counts in string arrays (OOB access)
+- spelling errors
+- wrong description in man page (Closes: #647228)
+  * Do not depend on tcpdump.
+  * Bump standards to 4.6.2, no changes.
+  * Remove unrelated key and override source not signed.
+  * wrap-and-sort
+
+  [ Joao Paulo Lima de Oliveira ]
+  * debian/control:
+- Set Rules-Requires-Root:no.
+- Set homepage-field.
+- Bumped Standards-Version to 4.6.1.
+- Set debhelper-compat version in Build-Depends.
+- Added Depends ${shlibs:Depends} in Depends fields.
+  * debian/rules:
+- Rewrite to use dh-sequencer.
+  * debian/metadata:
+- Added missing upstream metadata.
+- Added upstream's key.
+  * debian/watch:
+- Add watch file.
+
+ -- Boian Bonev   Thu, 23 Feb 2023 08:31:03 +
+
 dhcpdump (1.8-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru dhcpdump-1.8/debian/control dhcpdump-1.8/debian/control
--- dhcpdump-1.8/debian/control 2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/control 2023-02-23 06:56:52.0 +
@@ -2,12 +2,19 @@
 Section: admin
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: libpcap0.8-dev
-Standards-Version: 3.8.0.1
+Build-Depends:
+ debhelper-compat (= 13),
+ libpcap-dev,
+Standards-Version: 4.6.2
+Rules-Requires-Root: no
+Homepage: http://www.mavetju.org/download/
 
 Package: dhcpdump
 Architecture: any
-Depends: ${shlibs:Depends}, tcpdump
-Description: Parse DHCP packets from tcpdump
- This package provides a tool for visualization of DHCP packets as
- recorded and output by tcpdump to analyze DHCP server responses.
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: Parse DHCP packets from interface
+ This package provides a tool for visualization of DHCP packets
+ on a network interface to analyze DHCP client requests and
+ server responses.
diff -Nru dhcpdump-1.8/debian/copyright dhcpdump-1.8/debian/copyright
--- dhcpdump-1.8/debian/copyright   2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/copyright   2023-02-23 06:59:21.0 +
@@ -3,8 +3,23 @@
 Source: http://www.mavetju.org/download/
 
 Files: *
-Copyright: 2001, 2002 by Edwin Groothuis, ed...@mavetju.org
- All rights reserved.
+Copyright: 2001-2002 Edwin Groothuis 
+License: BSD-2-clause
+
+Files: debian/*
+Copyright:
+ 2001-2008 Martin Schulze 
+ 2017  Manuel A. Fernandez Montecelo 
+ 2017  Svante Signell 
+ 2017  Chris Lamb 
+ 2017  Helmut Grohne 
+ 2022  Marcos Talau 
+ 2022  Bastian Germann 
+ 2022  Olivier Chirossel 
+ 2023  Joao Paulo Lima de Oliveira 
+ 2023  Boian Bonev 
+License: BSD-2-clause
+
 License: BSD-2-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
diff -Nru dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 
dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch
--- dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 1970-01-01 
00:00:00.0 +
+++ dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 2023-02-23 
06:29:29.0 +
@@ -0,0 +1,22 @@
+Description: Fix network order 16bit value
+ Get the packet's ethertype in a way that works on any
+ kind of endian machine
+ .
+Author: Ben Hildred <426...@gmail.com>
+Origin: vendor
+Forwarded: BTS #873635
+Last-Update: 2017-08-29
+
+--- a/dhcpdump.c
 b/dhcpdump.c
+@@ -132,8 

Bug#1033089: subread: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

Source: subread
Version: 2.0.4+dfsg-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/subread.html

  /usr/bin/exactSNP

  /build/1st/subread-2.0.4+dfsg/src/input-files.c:3084
  vs.
  /build/2/subread-2.0.4+dfsg/2nd/src/input-files.c:3084

The attached patch fixes this by patching src/Makefile.Linux to not
override the CFLAGS and CXXFLAGS variables, so that the default flags
include -ffile-prefix-map to avoid embedding the build path.

Earlier versions (e.g. 2.0.3* currently in bookworm) did pass the
default flags, so this is a regression from what is currently in
bookworm.

According to my local tests, with this patch applied subread should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining subread!

live well,
  vagrant
From 661536e4afcec2e40682257e5aba8119b46935d7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 16 Mar 2023 21:51:54 -0700
Subject: [PATCH 1/3] src/Makefile.Linux: Do not set CFLAGS and CXXFLAGS to
 empty values.

---
 src/Makefile.Linux | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/Makefile.Linux b/src/Makefile.Linux
index 0571c1a..a6ec556 100644
--- a/src/Makefile.Linux
+++ b/src/Makefile.Linux
@@ -6,8 +6,6 @@ OPT_LEVEL = 3
 include makefile.version
 -include ~/.R/DBPZ_debug_makefile
 
-CXXFLAGS=
-CFLAGS=
 CCFLAGS += -O${OPT_LEVEL} -fsigned-char -Wall -DMAKE_FOR_EXON  -D MAKE_STANDALONE -D SUBREAD_VERSION=\"${SUBREAD_VERSION}\"  -D_FILE_OFFSET_BITS=64 ${WARNING_LEVEL}
 LDFLAGS += ${STATIC_MAKE} -pthread -lz -O${OPT_LEVEL} -DMAKE_FOR_EXON -D MAKE_STANDALONE -lm
 CFLAGS += ${CCFLAGS} -fmessage-length=0 -ggdb
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1014599: svgpp: CVE-2021-44960

[Anton Gladky]

Hello Moritz,

yes, it will be done within the next two days.

Best regards

Anton


Am Do., 16. März 2023 um 22:36 Uhr schrieb Moritz Mühlenhoff :

> Am Fri, Jul 08, 2022 at 04:31:10PM +0200 schrieb Moritz Mühlenhoff:
> > Source: svgpp
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: normal
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerability was published for svgpp.
> >
> > CVE-2021-44960[0]:
> > | In SVGPP SVG++ library 1.3.0, the XMLDocument::getRoot function in the
> > | renderDocument function handled the XMLDocument object improperly,
> > | returning a null pointer in advance at the second if, resulting in a
> > | null pointer reference behind the renderDocument function.
> >
> > https://github.com/svgpp/svgpp/issues/101
>
> This was fixed in
> https://github.com/svgpp/svgpp/commit/0bc57f2cc6d9d86a0fa1ce73e508c2b5994b4b91
> Could we get that fixed for Bookworm?
>
> Cheers,
> Moritz
>

Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients

[Steven Monai]

Package: ntpsec
Version: 1.2.2+dfsg1-1
Severity: normal
X-Debbugs-Cc: stevem...@gmail.com

Dear Maintainer,

On my LAN, I run Samba on Debian servers to implement Domain
Controllers (DCs) for an Active Directory (AD) domain. Per the Samba
documentation, I have set up authenticated time service (known as
MS-SNTP) on the DCs for Windows clients. Non-Windows clients also use
the DCs for non-auth time service, via unicast [S]NTP. Up to and
including bullseye, I have always used the 'ntp' package for this
purpose on the DCs, and it was functional.

Recently, however, upon upgrading from bullseye to bookworm, I found
that the DCs would no longer respond correctly to client requests for
time service. In other words, neither authenticated clients (Windows,
MS-SNTP) nor non-auth clients ([S]NTP) would receive any valid time
responses from the DCs running on bookworm.

Doing some experimentation, I discovered that when the 'mssntp'
keyword was removed from the 'restrict' line in 'ntp.conf', non-auth
time service was restored to clients (while MS-SNTP was disabled,
ofc). I can only assume this is a bug in the 'ntpsec' implementation
of MS-SNTP.

Without MS-SNTP service working on the DCs, Windows domain clients
(with the default time client settings) never receive time service
from the DCs as they should. Although it is easy enough to modify the
Windows time client settings to use non-auth NTP services, it would
be nice for MS-SNTP to work as advertised in 'ntpsec'.

Please let me know if there's any more information I can provide to
aid in troubleshooting/debugging this issue.

Thank you for your time.

Cheers,
-S.M.

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ntpsec depends on:
ii  adduser3.131
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-2
ii  libc6  2.36-8
ii  libcap21:2.66-3
ii  libssl33.0.8-1
ii  netbase6.4
ii  python33.11.2-1
ii  python3-ntp1.2.2+dfsg1-1
ii  sysvinit-utils [lsb-base]  3.06-2
ii  tzdata 2022g-7

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-162
ii  systemd 252.6-1

Versions of packages ntpsec suggests:
ii  apparmor   3.0.8-3
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpsec/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
tos maxclock 11
tos minclock 4 minsane 3
tos orphan 7
tinker panic 0
ntpsigndsocket /var/lib/samba/ntp_signd/
server 10.150.10.10 iburst burst prefer
server 10.150.10.11 iburst burst prefer
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
restrict default kod nomodify limited mssntp
restrict 127.0.0.1
restrict ::1


-- no debconf information

Bug#1033087: llvm-toolchain-14: missing nodoc build profile support (for bootstrapping)

[Cyan Young]

Package: llvm-toolchain-14
Severity: wishlist

Dear Maintainer,

Recently we are bootsrtraping Debian from scratch for a project. We already
have a set of "devel" packages, and most of LLVM's build dependencies can be
satisfied.

The problem is, LLVM is using Doxygen and Sphinx to generate documentation,
and Doxygen depends on LLVM itself - such dependency loop can block
LLVM from being bootstrapped.

After stripping out every *-doc package and disabling documentation build
process, LLVM can be successfully built without any issue.

I consulted a DD about this problem, DD suggests me to add 'nodoc' build
profile support to LLVM. So I tried to implement this change, but encountered
a new problem, package 'libllvm-ocaml-dev' is requiring some documentation
related files:

$ cat debian/libllvm-X.Y-ocaml-dev.install.in
@OCAML_STDLIB_DIR@
usr/lib/llvm-@LLVM_VERSION@/share/doc/llvm/ocaml-html/ 
usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/
usr/lib/llvm-@LLVM_VERSION@/share/doc/LLVM/llvm/ocaml-html/ 
usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/ 

I expect that there is a package which contains LLVM OCaml documentation only,
so it does not build with 'nodoc'. This means package libllvm-*-ocaml-dev
should be splited.

Do you have any suggestions about this? I should not remove those two lines
in d/rules with nodoc enabled, since this may against Debian policies.

Thanks,
Cyan

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

Kernel: Linux 6.2.1-aosc-main (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1033086: [INTL:ro] Romanian debconf templates translation of nullmailer

[Remus-Gabriel Chelu]

Package: nullmailer
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «nullmailer» file.

Thanks,
Remus-Gabriel

nullmailer_debconf_ro.po
Description: Binary data

Bug#1033085: [INTL:ro] Romanian debconf templates translation of nsca

[Remus-Gabriel Chelu]

Package: nsca
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «nsca» file.

Thanks,
Remus-Gabriel

nsca_debconf_ro.po
Description: Binary data

Bug#691815: motion: Latest Motion (-3.2) exits after running on_event_start script

[Nicolas Mora]

Hello,

I recently took over maintenance for the package motion in Debian.

This bug is quite old and related to old version of motion. Since it 
hasn't got any update since 2013, I have the sensation it can be closed.


I'll wait a little bit for a feedback before closing it.

/Nicolas

Bug#679023: motion: Fails to connect to IPv6-enabled cameras

[Nicolas Mora]

Hello,


I recently took over maintenance for the package motion in Debian.

This bug is quite old and related to old version of motion. Since it 
hasn't got any update since 2012, I have the sensation it can be closed.


I'll wait a little bit for a feedback before closing it.

/Nicolas

Bug#607977: motion: Using the NTSC video format, Motion goes crasch.

[Nicolas Mora]

Hello,

I recently took over maintenance for the package motion in Debian.

This bug is quite old and related to old version of motion. Since it 
hasn't got any update since 2010, I have the sensation it can be closed.


I'll wait a little bit for a feedback before closing it.

/Nicolas

Bug#1033084: [INTL:ro] Romanian debconf templates translation of nginx

[Remus-Gabriel Chelu]

Package: nginx
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «nginx» file.

Thanks,
Remus-Gabriel

nginx_debconf_ro.po
Description: Binary data

Bug#1031652: c-ares 1.17.1-1+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: c-ares
Version: 1.17.1-1+deb11u2

Explanation: prevent stack overflow and denial of service

Bug#1033083: [INTL:ro] Romanian debconf templates translation of netdiag

[Remus-Gabriel Chelu]

Package: netdiag
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «netdiag» file.

Thanks,
Remus-Gabriel

netdiag_debconf_ro.po
Description: Binary data

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Mathieu Mirmont]

On Thu, Mar 16, 2023 at 02:57:52PM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> Hi Mathieu
> 
> On 2023-03-15 23:05:39 +0100, Mathieu Mirmont wrote:
> > diff -Nru socklog-2.1.0+repack/debian/changelog 
> > socklog-2.1.0+repack/debian/changelog
> > --- socklog-2.1.0+repack/debian/changelog   2020-12-22 22:40:42.0 
> > +0100
> > +++ socklog-2.1.0+repack/debian/changelog   2023-03-06 22:01:18.0 
> > +0100
> > @@ -1,3 +1,15 @@
> > +socklog (2.1.0+repack-5) unstable; urgency=medium
> > +
> > +  * Various uninteresting changes
> 
> What are these uninteresting changes?

Sorry that's not the greatest description indeed. Looking at the git
commit this is:

- Use spaces instead of tabs to align columns in d/socklog.install and
  d/socklog-run.runit.
- Add set -eu at the top of the d/repack.sh script.
- Update the copyright date in d/copyright.
- Include /usr/share/dpkg/buildflags.mk in d/rules.
- Remove Breaks/Replaces: socklog (<= 2.1.0+repack-3) in d/control
  (see below for the rationale).

> > diff -Nru socklog-2.1.0+repack/debian/control 
> > socklog-2.1.0+repack/debian/control
> > --- socklog-2.1.0+repack/debian/control 2020-12-22 22:40:42.0 
> > +0100
> > +++ socklog-2.1.0+repack/debian/control 2023-03-06 21:52:36.0 
> > +0100
> > @@ -37,9 +37,8 @@
> >   ${misc:Depends}, ${shlibs:Depends}
> >  Recommends: ipsvd, mailx
> >  Provides: system-log-daemon, linux-kernel-log-daemon
> > -Conflicts: system-log-daemon, linux-kernel-log-daemon, ${runit:Conflicts}
> > -Breaks: socklog (<= 2.1.0+repack-3), ${runit:Breaks}
> > -Replaces: socklog (<= 2.1.0+repack-3)
> > +Conflicts: system-log-daemon, linux-kernel-log-daemon
> > +Breaks: ${runit:Breaks}
> 
> What's the rationale behind those changes?

Until socklog 2.1.0+repack-3 the two binary packages were merged into
one. That version was never released and bullseye shipped with
2.1.0+repack-4 so this Breaks/Replaces is now obsolete.

Then there's ${runit:Conflicts} and ${runit:Breaks} that expand to the
same value. Using both seems redundant and Breaks is sufficient since
the packages can be unpacked at the same time.

Cheers,

-- 
Mathieu Mirmont 

Bug#1033080: unblock: base-files/12.4

[Santiago Vila]

Closing as duplicate the one which has a greater bug number.

Sorry for the noise.

Bug#1033082: bullseye-pu: package xapian-core/1.4.18-3+deb11u1

[Olly Betts]

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

[ Reason ]
This is a targetted fix for a potential database corruption if switching
the new revision live fails with ENOSPC but the recovery process does
NOT get ENOSPC:

https://bugs.debian.org/1032398

It looks like all previous 1.4.x releases are affected.  This is a
regression compared to Xapian 1.2.x (which was in jessie).

The fix here is taken from upstream's 1.4.22 release and is the simplest
way to address the problem: simply reread the current version file
from disk which means the in memory state will match the previously
committed state.

[ Impact ]
This can result in corrupted databases for users if their partition
fills up while indexing.  It doesn't happen every time, but it's
definitely been hit by one notmuch user on Debian, and likely explains
a smattering of reports of database corruption over the years.

[ Tests ]
There's a pretty thorough upstream testsuite for xapian-core.  The
specific scenario of ENOSPC isn't currently tested by that, but we've
exercised it by hand by injecting an ENOSPC failure using strace, which
reliably triggers corruption without the patch and no corruption with
it.

The fix was include in the upstream 1.4.22 release which was released
2023-02-02 (6 weeks ago) and uploaded to unstable the same day - there
haven't been any reports of issue with it.

[ Risks ]
This is a really low risk change.  It only touches the code path taken
when a commit operation fails to write to disk, and does a more complete
reset of state in that case.

The rollback being done here is actually more complicated than necessary
(the multiple tables are now committed together atomically, but used to
be committed one-by-one which required extra care to roll-back).  That's
been cleaned up on upstream git master, but I've gone for the simpler
and less invasive fix from upstream 1.4.x.

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

[ Changes ]
The change switches from calling a function which attempts to roll-back
the in-memory state directly (but gets it wrong in this situation) to
one which resets the in-memory state to what it would be if the database
was opened afresh.

Cheers,
Olly
diff -Nru xapian-core-1.4.18/debian/changelog 
xapian-core-1.4.18/debian/changelog
--- xapian-core-1.4.18/debian/changelog 2021-02-24 07:33:41.0 +1300
+++ xapian-core-1.4.18/debian/changelog 2023-03-17 11:20:07.0 +1300
@@ -1,3 +1,15 @@
+xapian-core (1.4.18-3+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/fix-db-corruption-on-ENOSPC.patch: New patch to
+fix potential database corruption if switching the new revision
+live fails with ENOSPC but the recovery process does NOT get ENOSPC.
+The fix here is taken from upstream's 1.4.22 release and is the simplest
+way to address the problem: simply reread the current version file
+from disk which means the in memory state will match the previously
+committed state.  Closes: #1032398
+
+ -- Olly Betts   Fri, 17 Mar 2023 11:20:07 +1300
+
 xapian-core (1.4.18-3) unstable; urgency=medium
 
   * debian/rules: Workaround testcase sensitivity to excess precision by
diff -Nru xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch
--- xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
1970-01-01 12:00:00.0 +1200
+++ xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
2023-03-17 11:20:07.0 +1300
@@ -0,0 +1,40 @@
+commit 90f7a35483b4cf7dd848c34634803bf28f95081d
+Author: Olly Betts 
+Date:   Wed Jan 25 11:40:44 2023 +1300
+
+Fix recovery from failed commit
+
+If renaming to switch the new version file live fails (e.g. due to
+ENOSPC) we discard the changes, try to write and switch to a different
+new version file with an increased revision (on failure of this too we
+close the database), and throw DatabaseError.
+
+Unfortunately the roll-back of state is not complete, and if switching
+to the different new version file succeeds that bad state persists on
+disk.
+
+Thanks to Uwe Kleine-König for reporting and coming up with the idea
+to reproduce using strace to inject a rename() failure - this is a
+simple reproducer:
+
+rm -rf enospc.db
+strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db 
< INSTALL
+xapian-check enospc.db
+
+No automated regression test for this yet as this doesn't trivially
+fit into the existing testsuite framework, but we ought to have
+tests using fault injection.
+
+(cherry picked from 

Bug#1033036: linux-image-6.1.0-6-amd64: v6.1+ regression, PCI power management and mhi-pci-generic failure.

[Salvatore Bonaccorso]

Control: tags -1 + upstream moreinfo

Hi,

On Wed, Mar 15, 2023 at 11:42:19PM -0700, xoraxiom wrote:
> Package: linux-image-6.1.0-6-amd64
> Version: 6.1.15-1
> Severity: important
> 
> Dear Maintainer,
> 
> PCIe cellular modem device:
>   71:00.0 Wireless controller [0d40]: Foxconn International, Inc. Device
> e0b1
> fails to initialise with Debian kernel versions >= 6.1. and upstream kernels
> up to v6.2.5.
> 
> Running lspci or attempting to bring the device up through ModemManager
> causes the included error message loop in the dmesg buffer.
> 
> Device is fully functional with Debian kernel version: 6.0.12-1 from
> package: linux-image-6.0.0-6-amd64, and earlier v6.0.* versions.

Given you verified this is as well a problem upstream, can you please
report it there, keep us please in the loop.

As you were as well able to verify a earlier functional kernel, any
chance you could bisect the issue to determine the bad commit
upstream?

Regards,
Salvatore

Bug#1033035: hw-detect: trivial patches

[Cyril Brulebois]

Pascal Hambourg  (2023-03-16):
> IIUC the script arguments are expected to be network interface names
> except the first one which may be "-n". In this case, I believe it
> should be shifted away before setting IFACES="$@".

OK, this might be fixing an actual issue.

> > > - check-missing-firmware.sh: define local variables in functions
> 
> These variables are intended to be used only inside their respective
> functions, so it is cleaner and safer if they are declared as local
> (like in other hw-detect scripts) to avoid potential side effects with
> other functions or the main body if they use variables with the same
> names.

OK, this doesn't seem to be fixing anything at the moment.

> > The commit messages say what you do, not why.
> 
> Sorry, I thought it was obvious.
> 
> > > - check-missing-firmware.sh: replace spaces with tabs in indentation
> > 
> > NACK. We have mixed tabs and spaces all over the place, in hw-detect and
> > in other components. We don't need noise. Especially not at this stage.
> 
> Spaces for indentation are present only in one function, so I thought
> it might be a text editor glitch or human error and it was desirable
> to make it consistent with the rest of the script. AFAICS the only
> consistent use of spaces for indentation in other hw-detect scripts is
> before "case" patterns, which makes sense. Most other occurrences look
> like mistakes. But I take your point about avoiding cosmetic fixes
> now.

They can't be mistakes since I'm not aware of a defined let alone
enforced code style.

Fixing inconsistencies locally when actually working on the code
doesn't seem like a bad idea. Touching code just to make it “pretty”
doesn't look so appealing to me. There's nothing more annoying than
ending up with merge conflicts after working on something for a while,
just because someone toyed with whitespaces…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Mathieu

On 2023-03-15 23:05:39 +0100, Mathieu Mirmont wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: sock...@packages.debian.org
> Control: affects -1 + src:socklog
> 
> Please unblock package socklog
> 
> [ Reason ]
> Fix RC bug #1031794.
> 
> [ Impact ]
> No change of behaviour.
> 
> [ Tests ]
> After a manual package install and update the services socklog-klog
> and socklog-unix run fine. Also dpkg-source -x does not complain
> anymore.
> 
> [ Risks ]
> Low, the changes are trivial.
> 
> [ 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 testing
> 
> [ Other info ]
> I was hoping to get this pushed before the hard freeze but I wasn't
> lucky finding an uploader on time. The changes are therefore a bit
> more than what I would want at this point but they are all trivial.
> 
> unblock socklog/2.1.0+repack-5
> 
> -- 
> Mathieu Mirmont 

> diff -Nru socklog-2.1.0+repack/debian/changelog 
> socklog-2.1.0+repack/debian/changelog
> --- socklog-2.1.0+repack/debian/changelog 2020-12-22 22:40:42.0 
> +0100
> +++ socklog-2.1.0+repack/debian/changelog 2023-03-06 22:01:18.0 
> +0100
> @@ -1,3 +1,15 @@
> +socklog (2.1.0+repack-5) unstable; urgency=medium
> +
> +  * Various uninteresting changes

What are these uninteresting changes?

> +  * watch, repack.sh: append +repack to tarball filename
> +  * Refresh lintian overrides
> +  * service/socklog-unix: remove supervise symlink (Closes: #1031794)
> +  * control: bump debian policy to 4.6.2, no change required
> +  * gitlab-ci.yml: disable unnecessary jobs
> +  * gbp.conf: add configuration file
> +
> + -- Mathieu Mirmont   Mon, 06 Mar 2023 22:01:18 +0100
> +
>  socklog (2.1.0+repack-4) unstable; urgency=medium
>  
>* copyright: bump the year
> diff -Nru socklog-2.1.0+repack/debian/control 
> socklog-2.1.0+repack/debian/control
> --- socklog-2.1.0+repack/debian/control   2020-12-22 22:40:42.0 
> +0100
> +++ socklog-2.1.0+repack/debian/control   2023-03-06 21:52:36.0 
> +0100
> @@ -5,7 +5,7 @@
>  Uploaders: Gerrit Pape 
>  Vcs-Browser: https://salsa.debian.org/debian/socklog
>  Vcs-Git: https://salsa.debian.org/debian/socklog.git
> -Standards-Version: 4.5.1
> +Standards-Version: 4.6.2
>  Homepage: http://smarden.org/socklog
>  Build-Depends: debhelper-compat (= 13),
> dh-runit,
> @@ -37,9 +37,8 @@
>   ${misc:Depends}, ${shlibs:Depends}
>  Recommends: ipsvd, mailx
>  Provides: system-log-daemon, linux-kernel-log-daemon
> -Conflicts: system-log-daemon, linux-kernel-log-daemon, ${runit:Conflicts}
> -Breaks: socklog (<= 2.1.0+repack-3), ${runit:Breaks}
> -Replaces: socklog (<= 2.1.0+repack-3)
> +Conflicts: system-log-daemon, linux-kernel-log-daemon
> +Breaks: ${runit:Breaks}

What's the rationale behind those changes?

Cheers

>  Description: system and kernel logging services - runit services
>   socklog cooperates with the runit package to create a small and
>   secure replacement for rsyslog. socklog supports system logging
> diff -Nru socklog-2.1.0+repack/debian/copyright 
> socklog-2.1.0+repack/debian/copyright
> --- socklog-2.1.0+repack/debian/copyright 2020-11-23 16:13:31.0 
> +0100
> +++ socklog-2.1.0+repack/debian/copyright 2023-03-06 21:52:36.0 
> +0100
> @@ -9,7 +9,7 @@
>  
>  Files: debian/*
>  Copyright: Copyright 2001-2008, Gerrit Pape 
> - 2019-2020, Mathieu Mirmont 
> + 2019-2023, Mathieu Mirmont 
>  License: BSD-3-clause
>  
>  License: BSD-3-clause
> diff -Nru socklog-2.1.0+repack/debian/gbp.conf 
> socklog-2.1.0+repack/debian/gbp.conf
> --- socklog-2.1.0+repack/debian/gbp.conf  1970-01-01 01:00:00.0 
> +0100
> +++ socklog-2.1.0+repack/debian/gbp.conf  2023-03-06 22:01:10.0 
> +0100
> @@ -0,0 +1,3 @@
> +[DEFAULT]
> +pristine-tar = True
> +sign-tags = True
> diff -Nru socklog-2.1.0+repack/debian/gitlab-ci.yml 
> socklog-2.1.0+repack/debian/gitlab-ci.yml
> --- socklog-2.1.0+repack/debian/gitlab-ci.yml 2020-11-02 03:12:15.0 
> +0100
> +++ socklog-2.1.0+repack/debian/gitlab-ci.yml 2023-03-06 21:52:36.0 
> +0100
> @@ -1,3 +1,7 @@
>  include:
>- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
>- 
> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
> +
> +variables:
> +  SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1
> +  SALSA_CI_DISABLE_AUTOPKGTEST: 1
> diff -Nru socklog-2.1.0+repack/debian/repack.sh 
> socklog-2.1.0+repack/debian/repack.sh
> --- socklog-2.1.0+repack/debian/repack.sh 2020-11-02 01:53:45.0 
> +0100
> +++ socklog-2.1.0+repack/debian/repack.sh 2023-03-06 21:52:36.0 
> +0100
> @@ -1,12 +1,13 @@
>  #!/bin/sh
> +set -eu
>  
>  # Command line check.
> -if [ $# -ne 3 ] 

Bug#1032993: release.debian.org: key packages: mksh should not be a key package

[Paul Gevers]

Control: retitle -1 Build-Depends for tests should not be key packages
Control: tags -1 confirmed

Hi Thorsten,

On 15-03-2023 12:55, Thorsten Glaser wrote:

mksh is only a key package because shunit2 build-depends on it.


Ack.


(Would be nice if the key package status is shown in tracker or so…
I was surprised by its presence in the list.)


That would need somebody to work on a patch for the tracker. :)


However, shunit2 only uses it at build time to run its tests
against and its testsuite runner only fails if the last shell,
which is zsh, fails.


Which is a bug in shunit2. Has that been reported?

Anyways, to come back to your request, we already communicated [1] that 
we intend to change the key package situation, but that will be after 
the bookworm release.


Paul

[1] https://lists.debian.org/debian-devel-announce/2022/10/msg4.html 
section "nocheck and nodoc build profiles"


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032989: Liferea 1.14.1-1 segfaults on startup when trying to read gsettings

[Paul Gevers]

Hi Grzegorz,

First of all, thanks for the bug report, much appreciated.

On 15-03-2023 11:19, Grzegorz Szymaszek wrote:

After I have upgraded liferea from 1.14.0-1 to 1.14.1-1 today, it no
longer starts,


Grr. The new upstream version was supposed to be safe (so late in the 
freeze). There are reports upstream about segfaults in that version too, 
so it seems it's not Debian only.



segfaulting when trying to read the "enable-reader-mode"
setting. I have attached (liferea.crash) the result of the following
command:


One weirdness is that I'm running liferea myself too (I always build and 
use it some time before I upload). So there must be a delta between your 
system or setup and mine.



 gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args liferea

from which the short summary is:

 Thread 1 "liferea" received signal SIGSEGV, Segmentation fault.
 0x55577a6e in conf_get_bool_value_from_schema (gsettings=, 
gsettings@entry=0x0, key=key@entry=0x555cb33a "enable-reader-mode", 
value=value@entry=0x54) at ../conf.c:258
 258 *value = g_settings_get_boolean (gsettings,key);

Let me know if there is more info I can provide to help.


I have extremely limited experience with reading a plain stack trace 
(except in Matlab), so I forwarded that upstream, but I have one idea 
and one question.


1) Could you backup ~/.config/liferea and ~/.local/share/liferea  and 
then test what happens if you remove either or both of these locations? 
I have the *feeling* that there might be something in *your* 
configuration that triggers the issue. If we can find what that is, it 
will be easier for me to reproduce and help upstream working on a fix.


2) What desktop engine are you using? I'm on KDE (with X).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032989: Liferea 1.14.1-1 segfaults on startup when trying to read gsettings

[Grzegorz Szymaszek]

Thanks for the response.

On Thu, Mar 16, 2023 at 03:12:24PM +0100, Paul Gevers wrote:
> 1) Could you backup ~/.config/liferea and ~/.local/share/liferea  and
> then test what happens if you remove either or both of these locations?
> [...]

It crashes even with all of ~/.{cache,config,local/share}/liferea
deleted. I did not try resetting gsettings yet, I hope I will be able to
test it tomorrow.

> 2) What desktop engine are you using? I'm on KDE (with X).

Sway 1.7 (Wayland).

-- 
Grzegorz


signature.asc
Description: PGP signature

Bug#1032968: unblock: passt/0.0~git20230309.7c7625d-1

[Paul Gevers]

Hi Stefano,

On 14-03-2023 22:44, Stefano Brivio wrote:

- full slirp4netns(1) compatibility not granted


I've never heard of this before, what does that mean for the user?


[ Tests ]
I ran the upstream test suite against the packaged version on a
Debian testing (Bookworm) x86_64 system.


If you can do this manually, you can probably also do it automatically. 
If you turn this into an autopkgtest [1] your package could migrate 
without our intervention (providing that it passes on all architectures 
where the binary builds and that it tests a substantial part of the 
as-installed binaries). See 
https://release.debian.org/testing/freeze_policy.html#hard section "Soft 
freeze for non-key packages with autopkgtests"


Apart from the migration benefits, adding an autopkgtest will also 
prevent dependencies from breaking your package unnoticed (in testing) 
in the future because they will be prevented from migration.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Étienne Mollier]

Hi all,

I feel responsible for several of the issues listed by Paul, as
my earlier activity matches the time frame of some of the
changes and problems.

Christian Kastner, on 2023-03-16:
> On 2023-03-16 10:31, Paul Gevers wrote:
> > Control: tags -1 moreinfo On 16-03-2023 00:16, Christian Kastner 
> > wrote: For next time, can you please contact us earlier? We could 
> > have solved the earlier problems in testing-proposed-updates (in 
> > January), then we would now be in a better position.
> 
> I didn't think of that solution as the RC-blocked dependency was only
> available in unstable, and admittedly because I thought this would
> resolve itself in time.
> 
> But in any case: yes, earlier contact would have been helpful, and I'll
> do so in future.

Acknowledged, I must admit I had a similar perception of the
situation when I sloppily checked migration status two months
ago, and it didn't occur immediately to me that it would become
an entangled migration problem during hard freeze.  I'm sorry
about that.

> > By the way, I checked, but none of the ci.d.n host will run any of 
> > your tests, as none of them has an amdgpu (is that a thing you could 
> > expect on non-amd architectures by the way?).
> 
> Correct! Tests will be skipped on official infra.
> 
> It's not just a matter of the missing hardware (we have it, but DSA has
> understandable concerns), it's also about how to even express that a
> package needs a GPU to run its tests (build-time or autopkgtest).

Some kernel and hardware combinations may cause a host hangup,
e.g. the rocm-hipamd package version in testing doesn't
serialize properly tests and this causes a number of bus
contention errors when running the test suite, eventually
leading to a hangup.  I also have a more concerning case of a
test item running into a potential kernel bug on rx6800, which
I'm long overdue to investigate in depth with competent kernel
people (actually I'm unable to tell whether the hardware or the
kernel is at fault thus far, as the crash occurs in amdgpu ecc
functions).

There are other technical concerns regarding maintenance of
virtual machines and binding them to physical hardware due to
having to pass the GPU through the hardware.  The third issue
was it is almost always mandatory to run using non-free-firmware
that cannot be freely audited for passing tests.

The current combination of skippable tests with check on the
availability of kfd device is the best we managed achieve thus
far.

> I recently initiated a discussion about this [3]. For now, the idea to
> run parallel debci infra with guaranteed GPU presence, gather
> experience, and to eventually share proposals on how a GPU dependency
> could be expressed in d/control and d/tests/control.

(I'm overdue to answer to [3], but overall I was mostly fine
with the ideas and haven't spotted anything of concern yet.)

> > One thing I spotted along the way; the (Build-)Depends on llvm 
> > related packages use the *versioned* ones. Is there a reason not to 
> > use the unversioned ones from src:llvm-defaults? That would make llvm
> > transitions a bit easier.
> 
> I'd have to check with the co-maintainers who added it, but from what I
> gather so far, the ROCm stack needs a very recent llvm because of many
> changes being upstreamed there.

The ROCm stack is actually developed against a fork of llvm (the
rocm-llvm).  To avoid having to package more or less a code copy
of the native llvm, we target instead the next llvm-toolchain
version which contains upstreamed changes from rocm-llvm.  Even
that requires extensive patching, thankfully we have benefited
from the substantial help of people from AMD this far on that
front.

> > [1] https://lists.debian.org/debian-devel/2022/09/msg00105.html and 
> > follow-up 
> 
> [2] 
> https://github.com/torvalds/linux/blob/v6.2/drivers/gpu/drm/amd/amdkfd/Kconfig#L6-L8
> [3] https://lists.debian.org/debian-ai/2023/03/msg00038.html

Thank you for your work on putting together Debian 12 bookworm!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/tty1, please excuse my verbosity
   `-on air: Status Minor - Feel My Hunger


signature.asc
Description: PGP signature

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Johannes Schauer Marin Rodrigues]

Quoting Dima Kogan (2023-03-16 18:21:23)
> > I have a patch for you that should fix this problem in the sense that
> > mmdebstrap should not choose the unshare mode anymore. If you like, apply
> > the following to mmdebstrap from unstable:
> >
> > https://mister-muffin.de/p/ZwXV.diff
> 
> Neither of your patches apply to the current mmdebstrap from unstable
> (I'm at 5d24b65 in the git tree). If you want me to test, you should
> give me another patch. But I trust you to fix it, and I don't NEED the
> patch, since I now know to fix the /etc/subuid and /etc/subgid. So you can
> just apply the patch to the tree and close this bug.

Just very quickly, maybe you can try out mmdebstrap from upstream git? You only
need the mmdebstrap script itself:

https://gitlab.mister-muffin.de/josch/mmdebstrap/raw/branch/main/mmdebstrap

If you run it without --mode or with --mode=auto, it should not anymore choose
unshare mode on the machines where it doesn't work.

If you do force unshare mode with --mode=unshare, it should tell you what is
wrong.

Thanks!

cheers, josch

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Johannes Schauer Marin Rodrigues]

Quoting Dima Kogan (2023-03-16 20:04:19)
> I see this on a machine where the user is missing from /etc/subuid:
> 
>   dima@shorty:~$ /tmp/mmdebstrap bookworm /tmp/tst.tar.gz 
> http://deb.debian.org/debian
> 
>   E: unable to pick chroot mode automatically
> 
> 
>   dima@shorty:~$ /tmp/mmdebstrap --mode=unshare bookworm /tmp/tst.tar.gz 
> http://deb.debian.org/debian
> 
>   W: no entry in /etc/subuid for dima
>   E: failed to parse /etc/subuid and /etc/subgid
> 
> Is this right? Can we get better error messages? The "normal" command a
> user would type is the first one, and "unable to pick chroot mode
> automatically" is unhelpful. It tells the user nothing about what went
> wrong, or how to even look for a solution.

Thank you for your feedback! How about:

E: unable to pick chroot mode automatically (use --mode for manual selection)

This will make the user look up the --mode argument and its possible values in
the man page. If the user then selects --mode=unshare, the error message
indicates what is wrong.

What do you think?

cheers, josch

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Johannes Schauer Marin Rodrigues]

Quoting Dima Kogan (2023-03-16 20:34:14)
> Johannes Schauer Marin Rodrigues  writes:
> 
> > Thank you for your feedback! How about:
> >
> > E: unable to pick chroot mode automatically (use --mode for manual 
> > selection)
> >
> > This will make the user look up the --mode argument and its possible values 
> > in
> > the man page. If the user then selects --mode=unshare, the error message
> > indicates what is wrong.
> 
> That's better. What's the internal logic? I guess mmdebstrap tried
> "unshare", and it didn't work. Did it try all the others too, and they didn't
> work also?

Yes. It tried everything and didn't find anything it's able to use.

> It doesn't hurt to have ridiculously long error messages. We COULD say
> 
>   E: unable to pick chroot mode automatically (use --mode for manual
>   selection). Tried A, which didn't work because X; tried B, which
>   didn't work because Y...

The problem with ridiculously long error messages is, that mmdebstrap currently
has no way to wrap long error messages after 80 columns or so. A very long
error message is hard to read if it doesn't get wrapped similar to how you did
it in your example.

The second reason is, that it would not be easy to store and forward the reason
why the other modes failed. Especially the unshare mode can fail for 26
different reasons if I counted correctly. Letting the test-function silently
fail when checking for the mode but extracting the error message would turn the
code even more into spagetti.

> So if mmdebstrap already knows that --mode=unshare would produce
> 
>   W: no entry in /etc/subuid for dima
>   E: failed to parse /etc/subuid and /etc/subgid
> 
> It could say that initially. Maybe that's overkill and too much typing
> for you. What you have already already tells the user what to read about and
> play with (--mode), so maybe that's fine.

Thank you for your feedback. You are only the second person for whom unshare
mode did not work out-of-the-box so your feedback is very valuable. :)

cheers, josch

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Paul Gevers]

Hi,

[@aurel32, glibc question at the bottom]

On 16-03-2023 11:57, Bastian Germann wrote:

Am 16.03.23 um 09:13 schrieb Paul Gevers:
I'm not 100% sure I parse that sentence as you intended, so let me ask 
explicitly: if we binNMU (now or in the future) src:argon2 version 
0~20171227-0.3 in bookworm, would it also loose its linking to 
libpthread? That would be a time bomb (not only in the archive, but 
also for downstreams and other users that do rebuilds). I *think* 
you're saying that despite libc's version, that is *not* the case.


Time bomb confirmed.


Thanks. That changes things.

For the record, with my current understanding I prefer the scenario of 
keeping the versions of argon2 and cryptsetup in bookworm as they are. 
Feel free to convince the Release Team of the opposite in an unblock 
request.


cryptsetup will need to migrate to mitigate the time bomb.


Ack.

As I already mentioned on this or some related bug, I would find it nice 
for #1014110 to be fixed in bookworm (threaded argon2 executable) but I 
do not insist on it.


cryptsetup can only migrate when argon2 migrates, which leaves me two 
options: letting argon2 in as it is now in unstable or going for 
cryptsetup via t-p-u. Both sub-optimal, because argon2 has changes that 
weren't even meeting the freeze policy rules at the time of the upload.


While writing this up and discussing with others, I realized that the 
error is coming from one of glibc's binaries. It has been stated that 
the issue started with with a change there, but is that change done on 
purpose, or a bug? I.e. is one of glibc's binaries missing a dependency?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Guilhem Moulin]

Hi,

On Thu, 16 Mar 2023 at 13:44:11 +0100, Paul Gevers wrote:
>> As I already mentioned on this or some related bug, I would find it nice
>> for #1014110 to be fixed in bookworm (threaded argon2 executable) but I
>> do not insist on it.
>
> cryptsetup can only migrate when argon2 migrates,

I see that in the excuse page now but don't understand the reason why,
there was no ABI change in the src:argon2 upload and libcryptsetup12 has
‘Depends: libargon2-1 (>= 0~20171227)’.  I'm not really familiar with
britney's logic but don't understand what it tries to enforce that
ordering.

> which leaves me two options: […]

Apologies for the mess and extra work, and many thanks for trying to
find a way forward!

> While writing this up and discussing with others, I realized that the error
> is coming from one of glibc's binaries. It has been stated that the issue
> started with with a change there, but is that change done on purpose, or a
> bug? I.e. is one of glibc's binaries missing a dependency?

It was intentional, see the article
https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
 .
Unfortunately that change broke initramfs-tools' fix for 
https://bugs.debian.org/950254
which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs.
Until last week src:argon2 had never been rebuilt with the newer glibc,
so it's just unfortunate that we missed that at the time.

I wonder if other packages are affected.  Another fix would be to change
initramfs-tools' inclusion logic for LIBGCC_S_SO.  (I don't know if
autodetection is still doable, otherwise it could still copy the library
unconditionally at the expense of a larger initramfs image.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Paul Gevers]

Hi Guilhem,

On 16-03-2023 14:31, Guilhem Moulin wrote:

cryptsetup can only migrate when argon2 migrates,


I see that in the excuse page now but don't understand the reason why,


It took me a while and the help of colleagues, but it's 
libcryptsetup12-udeb that has:

Depends: libargon2-1-udeb (>= 0~20190702)


While writing this up and discussing with others, I realized that the error
is coming from one of glibc's binaries. It has been stated that the issue



started with with a change there, but is that change done on purpose, or a
bug? I.e. is one of glibc's binaries missing a dependency?


It was intentional, see the article
https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
 .
Unfortunately that change broke initramfs-tools' fix for 
https://bugs.debian.org/950254
which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs.
Until last week src:argon2 had never been rebuilt with the newer glibc,
so it's just unfortunate that we missed that at the time.


I'm very happy that we found this well before the release, even thought 
it's late in the freeze.



I wonder if other packages are affected.  Another fix would be to change
initramfs-tools' inclusion logic for LIBGCC_S_SO.  (I don't know if
autodetection is still doable, otherwise it could still copy the library
unconditionally at the expense of a larger initramfs image.)


Can you elaborate and/or can you discuss with the initramfs-tools 
maintainers? I lack the background of how this all works and 
interconnects, so you'll need to explain everything or come with a 
proposal that the stakeholders (you and other involved maintainers) 
agree with.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Guilhem Moulin]

On Thu, 16 Mar 2023 at 16:01:47 +0100, Paul Gevers wrote:
> On 16-03-2023 14:31, Guilhem Moulin wrote:
>>> cryptsetup can only migrate when argon2 migrates,
>>
>> I see that in the excuse page now but don't understand the reason why,
>
> It took me a while and the help of colleagues, but it's libcryptsetup12-udeb
> that has:
> Depends: libargon2-1-udeb (>= 0~20190702)

Oh I see, thanks for the info and sorry for not doing the homework!
That might also explain why src:cryptsetup 2:2.6.1-2 was blocked from
entering testing in time.  That's unfortunate though, as it'll block
unblock requests for src:cryptsetup unless src:argon2 is unblocked as
well.  Leaving it to kibi if the #1028250 mitigation warrants an unblock
or not :-)

>> I wonder if other packages are affected.  Another fix would be to change
>> initramfs-tools' inclusion logic for LIBGCC_S_SO.  (I don't know if
>> autodetection is still doable, otherwise it could still copy the library
>> unconditionally at the expense of a larger initramfs image.)
>
> Can you elaborate and/or can you discuss with the initramfs-tools
> maintainers? I lack the background of how this all works and interconnects,
> so you'll need to explain everything or come with a proposal that the
> stakeholders (you and other involved maintainers) agree with.

Sure, will file a bug against initramfs-tools and X-Debbugs-Cc:
debian-release@l.d.o.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Salvatore Bonaccorso]

Hi Marc-Robin,

On Tue, Mar 14, 2023 at 02:48:56PM +0100, Marc-Robin Wendt wrote:
> Hello Salvatore,
> 
> sorry for the delay. So lets hope, this will solve the problem for all
> the affected people.
> 
> On Fri, 2023-03-10 at 17:11 +0100, Salvatore Bonaccorso wrote:
> > Hello Marc-Robin,
> > 
> > 
> > > Anyhow I had some errors:
> > > 
> > > qla2xxx :61:00.1: swiotlb buffer is full (sz: 65536 bytes),
> > > total
> > > 32768 (slots), used 28799 (slots)
> > > 
> > > But I'm not sure, if this is releated and it doesn't affect
> > > functions.
> > > 
> > > Do you need further informations about the testing process?
> > 
> > I assume this has to be tackled separately. You can confim it was not
> > seen before in earlier kernels?
> > 
> > 
> I checked with last working Kernel 5.10.136-1 and same errors there. So
> not related to our problem. Seems like is related to LVM.
> 
> Thanks for you efforts.

Thanks for checking back to the earlier version, so at least not
related to this issue and relieved the patch series resolves the
problem. I'm confident will be as well the case for the other
affected.

I have queued them for the next Debian upload based on at least
5.10.174-1 as well.

Regards,
Salvatore

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Aurelien Jarno]

Hi,

On 2023-03-16 13:44, Paul Gevers wrote:
> Hi,
> 
> [@aurel32, glibc question at the bottom]
> 
> On 16-03-2023 11:57, Bastian Germann wrote:
> > Am 16.03.23 um 09:13 schrieb Paul Gevers:
> > > I'm not 100% sure I parse that sentence as you intended, so let me
> > > ask explicitly: if we binNMU (now or in the future) src:argon2
> > > version 0~20171227-0.3 in bookworm, would it also loose its linking
> > > to libpthread? That would be a time bomb (not only in the archive,
> > > but also for downstreams and other users that do rebuilds). I
> > > *think* you're saying that despite libc's version, that is *not* the
> > > case.
> > 
> > Time bomb confirmed.
> 
> Thanks. That changes things.
> 
> > > For the record, with my current understanding I prefer the scenario
> > > of keeping the versions of argon2 and cryptsetup in bookworm as they
> > > are. Feel free to convince the Release Team of the opposite in an
> > > unblock request.
> > 
> > cryptsetup will need to migrate to mitigate the time bomb.
> 
> Ack.
> 
> > As I already mentioned on this or some related bug, I would find it nice
> > for #1014110 to be fixed in bookworm (threaded argon2 executable) but I
> > do not insist on it.
> 
> cryptsetup can only migrate when argon2 migrates, which leaves me two
> options: letting argon2 in as it is now in unstable or going for cryptsetup
> via t-p-u. Both sub-optimal, because argon2 has changes that weren't even
> meeting the freeze policy rules at the time of the upload.
> 
> While writing this up and discussing with others, I realized that the error
> is coming from one of glibc's binaries. It has been stated that the issue
> started with with a change there, but is that change done on purpose, or a

From what I understand the change has been triggered by the move of the
pthread_exit() function from libpthread.so.1 to libc.so.6, which
happened in glibc 2.34.

libgcc_s.so.1 is loaded dynamically when such function is used to avoid
a dependency loop, so libc.so.6 is NOT linked against libgcc_s.so.1.
This is not something new, it has been like that for 10+ years.

> bug? I.e. is one of glibc's binaries missing a dependency?

Technically the libc6 package is indeed missing a dependency against
libgcc-s1. This is not an issue given libgcc-s1 is de facto essential.

On the glibc side, it should be possible to add such a dependency
(although it would not have prevented this bug), but that will create a
dependency loop, and tools (apt, aptitude, rebootstrap, ...) would have
to learn how to deal with it.

Regards
Aurelien


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


signature.asc
Description: PGP signature

Bug#1010667: ruby-xmlhash: diff for NMU version 1.3.6-3.1

[Adrian Bunk]

Control: tags 1010667 + patch
Control: tags 1010667 + pending

Dear maintainer,

I've prepared an NMU for ruby-xmlhash (versioned as 1.3.6-3.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru ruby-xmlhash-1.3.6/debian/changelog ruby-xmlhash-1.3.6/debian/changelog
--- ruby-xmlhash-1.3.6/debian/changelog	2022-07-01 02:30:29.0 +0300
+++ ruby-xmlhash-1.3.6/debian/changelog	2023-03-16 17:28:19.0 +0200
@@ -1,3 +1,11 @@
+ruby-xmlhash (1.3.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2022-21949: Improper Restriction of XML External Entity Reference
+(Closes: #1010667)
+
+ -- Adrian Bunk   Thu, 16 Mar 2023 17:28:19 +0200
+
 ruby-xmlhash (1.3.6-3) unstable; urgency=medium
 
   [ Cédric Boutillier ]
diff -Nru ruby-xmlhash-1.3.6/debian/patches/0001-Remove-misnamed-libxml-parsing-flag.patch ruby-xmlhash-1.3.6/debian/patches/0001-Remove-misnamed-libxml-parsing-flag.patch
--- ruby-xmlhash-1.3.6/debian/patches/0001-Remove-misnamed-libxml-parsing-flag.patch	1970-01-01 02:00:00.0 +0200
+++ ruby-xmlhash-1.3.6/debian/patches/0001-Remove-misnamed-libxml-parsing-flag.patch	2023-03-16 17:28:02.0 +0200
@@ -0,0 +1,27 @@
+From 4a5a8974d5dfc7f8c906b22b346279a5482d3d69 Mon Sep 17 00:00:00 2001
+From: Stephan Kulow 
+Date: Mon, 4 Apr 2022 16:17:56 +0200
+Subject: Remove misnamed libxml parsing flag
+
+See details on
+https://stackoverflow.com/questions/38807506/what-does-libxml-noent-do-and-why-isnt-it-called-libxml-ent
+---
+ ext/xmlhash/xmlhash.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ext/xmlhash/xmlhash.c b/ext/xmlhash/xmlhash.c
+index aa8eacf..d07aee8 100644
+--- a/ext/xmlhash/xmlhash.c
 b/ext/xmlhash/xmlhash.c
+@@ -209,7 +209,7 @@ static VALUE parse_xml_hash(VALUE self, VALUE rb_xml)
+   memcpy(data, StringValuePtr(rb_xml), RSTRING_LEN(rb_xml));
+ 
+   reader = xmlReaderForMemory(data, RSTRING_LEN(rb_xml), 
+-			  NULL, NULL, XML_PARSE_NOENT | XML_PARSE_NOERROR | XML_PARSE_NOWARNING );
++			  NULL, NULL, XML_PARSE_NOERROR | XML_PARSE_NOWARNING );
+   init_XmlhashParserData();
+ 
+   if (reader != NULL) {
+-- 
+2.30.2
+
diff -Nru ruby-xmlhash-1.3.6/debian/patches/series ruby-xmlhash-1.3.6/debian/patches/series
--- ruby-xmlhash-1.3.6/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ ruby-xmlhash-1.3.6/debian/patches/series	2023-03-16 17:28:15.0 +0200
@@ -0,0 +1 @@
+0001-Remove-misnamed-libxml-parsing-flag.patch

Bug#1033079: bullseye-pu: package intel-microcode/3.20230214.1~deb11u1

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: intel-microc...@packages.debian.org, Salvatore Bonaccorso 

Control: affects -1 + src:intel-microcode

(Please refer to #1032847#12 for security team's feedback
that this should go through SPU.)

The upload updates intel microcodes to target (See #1031334)
   - INTEL-SA-00700: CVE-2022-21216
   - INTEL-SA-00730: CVE-2022-33972
   - INTEL-SA-00738: CVE-2022-33196
   - INTEL-SA-00767: CVE-2022-38090

the CVEs are information disclosure via local access vulnerbilities and
potential privilege escalations.

I've updated the package in sid already (unblock request #1032847) and the
update of bookworm is the next step to get the CVEs fixed for LTS/ELTS.
I'm working on LTS (buster) and ELTS (stretch an jessie) as part of the
Freexian LTS/ELTS project)

This package is identical to the unstable version, with the exception that
unstable used the new firmware section and this package for bullseye is using
non-free.

To keep the fixes consistent, I'd like to let them flow from sid -> jessie…


[ Tests ]
I've tested that the package works on Intel hardware that I have access to.

[ 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 testing


(I've already uploaded to bullseye-spu as I am confident that this upload will 
be accepted.
To avoid further delays for LTS/ELTS, I'd appreciate feedback whether this will 
be accepted,
so that I can proceed with uploading to buster, stretch and jessie without the 
need to have
weird version numbers :)

Thanks in advance,

-- 
tobi
diff -Nru intel-microcode-3.20220510.1~deb11u1/changelog 
intel-microcode-3.20230214.1~deb11u1/changelog
--- intel-microcode-3.20220510.1~deb11u1/changelog  2022-07-04 
20:10:32.0 +0200
+++ intel-microcode-3.20230214.1~deb11u1/changelog  2023-03-14 
19:17:02.0 +0100
@@ -1,3 +1,84 @@
+2023-02-14:
+  * New Microcodes:
+sig 0x000806f4, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f4, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f5, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f5, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f6, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f6, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f7, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f8, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f8, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992
+sig 0x000b06a3, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992
+
+  * Updated Microcodes:
+sig 0x00050653, pf_mask 0x97, 2022-08-30, rev 0x1000161, size 36864
+sig 0x00050656, pf_mask 0xbf, 2022-08-26, rev 0x4003303, size 37888
+sig 0x00050657, pf_mask 0xbf, 2022-08-26, rev 0x5003303, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2022-08-26, rev 0x7002503, size 29696
+sig 0x000606a6, pf_mask 0x87, 2022-10-09, rev 0xd000389, size 296960
+sig 0x000606c1, pf_mask 0x10, 2022-09-23, rev 0x1000211, size 289792
+sig 0x000706a1, pf_mask 0x01, 2022-09-16, rev 0x003e, size 75776
+sig 0x000706a8, pf_mask 0x01, 2022-09-20, rev 0x0022, size 76800
+sig 0x000706e5, pf_mask 0x80, 2022-08-31, rev 0x00b8, size 113664
+sig 0x000806a1, pf_mask 0x10, 2022-09-07, rev 0x0032, size 34816
+sig 0x00090672, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x00090675, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x000906a3, pf_mask 0x80, 2023-01-11, rev 0x0429, size 218112
+sig 0x000906a4, pf_mask 0x80, 2023-01-11, rev 0x0429, size 218112
+sig 0x000906c0, pf_mask 0x01, 2022-09-02, rev 0x2424, size 20480
+sig 0x000a0671, pf_mask 0x02, 2022-08-31, rev 0x0057, size 103424
+sig 0x000b0671, pf_mask 0x32, 2022-12-19, rev 0x0112, size 207872
+sig 0x000b06f2, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x000b06f5, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+
+2022-11-08:
+  * New Microcodes:
+sig 0x000606c1, pf_mask 0x10, 2022-08-07, rev 0x1000201, size 286720
+sig 0x000b0671, pf_mask 0x32, 2022-09-07, rev 0x010e, size 204800
+
+  * Updated Microcodes:
+sig 0x000706e5, pf_mask 0x80, 2022-08-02, rev 0x00b6, size 113664
+sig 0x000806c1, pf_mask 0x80, 2022-06-28, rev 0x00a6, size 110592
+sig 0x000806d1, pf_mask 0xc2, 2022-06-28, rev 0x0042, size 102400
+sig 0x000806ec, pf_mask 0x94, 2022-07-31, rev 0x00f4, size 105472
+sig 0x00090661, pf_mask 0x01, 2022-07-15, rev 0x0017, size 20480
+sig 0x00090672, pf_mask 0x07, 2022-09-19, rev 0x0026, size 218112
+sig 0x00090675, pf_mask 0x07, 2022-09-19, rev 0x0026
+sig 0x000b06f2, 

Bug#1033081: [INTL:ro] Romanian debconf templates translation of nas

[Remus-Gabriel Chelu]

Package: nas
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «nas» file.

Thanks,
Remus-Gabriel

nas_debconf_ro.po
Description: Binary data

Bug#1033080: unblock: base-files/12.4

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:base-files

Please unblock package base-files

[ Reason ]
It contains the changes everybody expects for bookworm as stable.

[ Tests ]
I've done my best double-checking that everything is correct.

[ Risks ]
The upload contains also other minor changes, but all of them are small,
all of them are low risk, and none of them should affect the end user.

[ 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 testing

[ Other info ]

Note 1: I'm actually using a diff in "git show" format,
because the old "copyright.in" is now simply "copyright"
and a debdiff would show this as a spurious big difference.

Note 2: All the changes in the licenses/* directory are really the
result of refreshing the licenses. I do not decide about those changes
nor I have a way to control them.

Thanks.

unblock base-files/12.4diff --git a/debian/README b/debian/README
index 01570a9..9ced2ea 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "bookworm" or "testing"?
+says "trixie/sid". Should it not read "trixie" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "sid" or "unstable"?
+says "trixie/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable 
distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bookworm/sid" (or whatever is appropriate).
+"trixie/sid" (or whatever is appropriate).
 
-Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
+Q. Why "trixie/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff --git a/debian/base-files.lintian-overrides 
b/debian/base-files.lintian-overrides
index d57f3a3..691e9e6 100644
--- a/debian/base-files.lintian-overrides
+++ b/debian/base-files.lintian-overrides
@@ -2,21 +2,21 @@
 # Permissions 0700 on /root are intentional as people expect
 # the /root directory to be more private than /home/* directories.
 #
-base-files: non-standard-dir-perm root/ 0700 != 0755
+base-files: non-standard-dir-perm 0700 != 0755 [root/]
 #
 # The /etc/os-release symlink is relative on purpose to avoid breaking dracut.
 # See Bug #755394 for details.
 #
-base-files: symlink-should-be-absolute etc/os-release ../usr/lib/os-release
+base-files: relative-symlink ../usr/lib/os-release [etc/os-release]
 #
 # The purpose of having licenses here is precisely to allow
 # other packages to reference them.
 #
-base-files: extra-license-file usr/share/common-licenses/Artistic
-base-files: extra-license-file usr/share/common-licenses/BSD
-base-files: extra-license-file usr/share/common-licenses/GPL-1
-base-files: extra-license-file usr/share/common-licenses/GPL-2
-base-files: extra-license-file usr/share/common-licenses/GPL-3
-base-files: extra-license-file usr/share/common-licenses/LGPL-2
-base-files: extra-license-file usr/share/common-licenses/LGPL-2.1
-base-files: extra-license-file usr/share/common-licenses/LGPL-3
+base-files: extra-license-file [usr/share/common-licenses/Artistic]
+base-files: extra-license-file [usr/share/common-licenses/BSD]
+base-files: extra-license-file [usr/share/common-licenses/GPL-1]
+base-files: extra-license-file [usr/share/common-licenses/GPL-2]
+base-files: extra-license-file [usr/share/common-licenses/GPL-3]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
diff --git a/debian/changelog b/debian/changelog
index 3259901..c9b9f12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+base-files (12.4) unstable; urgency=medium
+
+  * Release candidate for bookworm as stable:
+  - Use "12" as version in /etc/issue and /etc/issue.net.
+(never expected to change after release)
+  - Use 12.0 as version in /etc/debian_version.
+(expected to change at every point release)
+  - Change PRETTY_NAME in /usr/lib/os-release, adding 12 as version number
+and "(bookworm)" as codename. Add also VERSION_ID and VERSION.
+(never expected to change)
+  - Variable VERSION_CODENAME was already defined as 

Bug#1033078: unblock: flatpak/1.14.4-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: flat...@packages.debian.org, secur...@debian.org
Control: affects -1 + src:flatpak

Please unblock package flatpak

[ Reason ]
New upstream stable release fixing a security issue.

[ Impact ]
CVE-2023-28101: A malicious Flatpak app could prevent the flatpak(1) CLI
from displaying its permissions as intended, by having crafted permissions
or other metadata containing terminal escape sequences or other special
characters.

CVE-2023-28100: A malicious Flatpak app could execute code outside the
sandbox if run from a Linux virtual console. (Mitigation: I'm fairly
sure nobody actually does this, because Flatpak is intended to be used
in a Wayland or X11 environment; running it from an xterm or equivalent
is not vulnerable.)

[ Tests ]
The automated test suite is run at build-time and by autopkgtest, and
still passes. It includes tests for the two CVE issues. Coverage on buildds
and lxc is not great, because we're unable to actually run Flatpak apps in
that environment, but I ran the autopkgtest in qemu before upload and that
also passes.

[ Risks ]
Low risk, targeted fixes only. The only non-security change is a
translation update.

[ 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 testing

[ Other info ]
As with bullseye, I'm involved in upstream release management, and I'd
like to make use of upstream stable releases for stable/security updates
in preference to forking the upstream codebase for Debian.

unblock flatpak/1.14.4-1
debdiff *.dsc | filterdiff -p1 -x'po/*.po' -x 'po/*.pot' -xconfigure

diffstat for flatpak-1.14.3 flatpak-1.14.4

 NEWS|   20 +
 app/flatpak-builtins-info.c |8 
 app/flatpak-builtins-remote-info.c  |5 
 app/flatpak-cli-transaction.c   |   17 -
 common/flatpak-context.c|   36 ++
 common/flatpak-run.c|4 
 common/flatpak-utils-private.h  |   14 +
 common/flatpak-utils.c  |  121 +
 common/flatpak-version-macros.h |2 
 configure   |   26 +-
 configure.ac|2 
 debian/changelog|   15 +
 doc/reference/html/flatpak-Version-information.html |2 
 doc/reference/html/index.html   |2 
 po/cs.po|  204 
 po/da.po|  204 
 po/de.po|  204 
 po/en_GB.po |  204 
 po/es.po|  204 
 po/flatpak.pot  |  206 
 po/fr.po|  204 
 po/gl.po|  204 
 po/hi.po|  204 
 po/hr.po|  204 
 po/hu.po|  204 
 po/id.po|  204 
 po/oc.po|  204 
 po/pl.gmo   |binary
 po/pl.po|  250 ++--
 po/pt.po|  204 
 po/pt_BR.po |  204 
 po/ro.po|  204 
 po/ru.po|  204 
 po/sk.po|  204 
 po/sv.po|  204 
 po/tr.po|  204 
 po/uk.po|  204 
 po/zh_CN.po |  204 
 po/zh_TW.po |  204 
 tests/make-test-app.sh  |8 
 tests/package_version.txt   |2 
 tests/test-context.c|   84 ++
 tests/test-info.sh  |   14 -
 tests/test-seccomp.sh   |8 
 tests/testcommon.c  |   74 +
 tests/try-syscall.c 

Bug#1033077: keys from /usr/share/keyrings/debian-archive-keyring.gpg are missing from /etc/apt/trusted.gpg.d

[Johannes Schauer Marin Rodrigues]

Package: debian-archive-keyring
Version: 2023.1
Severity: important
Control: affects -1 + src:mmdebstrap

Hi,

the ascii armored keys that are now installed in /etc/apt/trusted.gpg.d
are missing three keys which are otherwise provided by
/usr/share/keyrings/debian-archive-keyring.gpg, namely:

pub   rsa4096 2019-02-05 [SC] [expires: 2027-02-03]
  6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517
uid  Debian Stable Release Key (10/buster) 


pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
  80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE
uid  Debian Archive Automatic Signing Key (10/buster) 

sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
  5E61B217265DA9807A23C5FF4DFAB270CAA96DFA
uid  Debian Security Archive Automatic Signing Key 
(10/buster) 
sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

This is breaking my package mmdebstrap.

Thanks!

cheers, josch

Bug#1033076: unblock: python-motor/2.3.0-3

[Étienne Mollier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-mo...@packages.debian.org
Control: affects -1 + src:python-motor

Please unblock package python-motor

[ Reason ]
python-motor in testing is affected by the grave RC bug #1031763
reported by an end user.

[ Impact ]
If python-motor doesn't migrate, the RC bug will cause a removal
of the package from bookworm, but it won't pull reverse
dependencies in the process on first sight.  Overall impact
looks thus somewhat low.

[ Tests ]
I didn't run the test suite as I discovered the registered
autopkgtest needed a package mongodb-server, which is not
available in any section of the archive currently.  Build time
tests also require a running mongodb server to be actually
executed, which I don't have at hand, nor I have the energy to
deploy.  Best I could do was to mimick autodep8 in unstable and
testing context:

(sid-amd64-sbuild)$ python3
Python 3.11.2 (main, Mar  5 2023, 08:28:49) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor
>>> motor


(testing-amd64-sbuild)$ python3
Python 3.11.2 (main, Feb 12 2023, 00:48:52) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor
>>> motor


[ Risks ]
As I didn't extensively test the package, it is quite possible
issues are hidden, but I didn't get any (negative) feedback from
the bug submitter so far, so maybe things are okay after all.

The package does not have reverse dependencies so risks of
affecting other packages look low.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

[ Other info ]
There was a standards version bump from 4.5.1 to 4.6.2 by the
Janitor lingering in the repository.  Said bump didn't seem to
require changes from packaging perspective, so I kept the
modification as is.  This change may be reverted if deemed not
appropriate.

unblock python-motor/2.3.0-3

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.
On air: Pendragon - Indigo
diff -Nru python-motor-2.3.0/debian/changelog 
python-motor-2.3.0/debian/changelog
--- python-motor-2.3.0/debian/changelog 2022-05-26 20:39:58.0 +0200
+++ python-motor-2.3.0/debian/changelog 2023-03-03 14:29:00.0 +0100
@@ -1,3 +1,17 @@
+python-motor (2.3.0-3) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Debian Janitor ]
+  * Update standards version to 4.6.2, no changes needed.
+
+  [ Étienne Mollier ]
+  * python-3.11.patch: add patch from upstream.
+This fixes an import error of motor.motor_asyncio.
+Thanks to Andrey Rakhmatullin for the hint!  (Closes: #1031763)
+
+ -- Étienne Mollier   Fri, 03 Mar 2023 14:29:00 +0100
+
 python-motor (2.3.0-2) unstable; urgency=medium
 
   * Remove obsolete field Name from debian/upstream/metadata (already present 
in
diff -Nru python-motor-2.3.0/debian/control python-motor-2.3.0/debian/control
--- python-motor-2.3.0/debian/control   2022-05-26 20:39:58.0 +0200
+++ python-motor-2.3.0/debian/control   2023-03-03 14:29:00.0 +0100
@@ -7,7 +7,7 @@
dh-python,
python3-all,
python3-setuptools,
-Standards-Version: 4.5.1
+Standards-Version: 4.6.2
 Homepage: https://github.com/mongodb/motor
 Vcs-Browser: https://salsa.debian.org/python-team/packages/python-motor
 Vcs-Git: https://salsa.debian.org/python-team/packages/python-motor.git
diff -Nru python-motor-2.3.0/debian/patches/python-3.11.patch 
python-motor-2.3.0/debian/patches/python-3.11.patch
--- python-motor-2.3.0/debian/patches/python-3.11.patch 1970-01-01 
01:00:00.0 +0100
+++ python-motor-2.3.0/debian/patches/python-3.11.patch 2023-03-03 
14:29:00.0 +0100
@@ -0,0 +1,34 @@
+Description: fix asyncio.coroutine import error with python3.11
+Author: Steven Silvester
+Bug: https://github.com/mongodb/motor/pull/185
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031763
+Reviewed-By: Étienne Mollier 
+Last-Update: 2023-03-03
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- python-motor.orig/motor/frameworks/asyncio/__init__.py
 python-motor/motor/frameworks/asyncio/__init__.py
+@@ -25,7 +25,6 @@
+ import os
+ import warnings
+ 
+-from asyncio import coroutine  # For framework interface.
+ from concurrent.futures import ThreadPoolExecutor
+ 
+ 
+@@ -34,6 +33,15 @@
+ except ImportError:
+ contextvars = None
+ 
++try:
++from asyncio import coroutine
++except ImportError:
++
++def coroutine():
++raise RuntimeError(
++"The coroutine decorator was removed in Python 3.11.  Use 'async 
def' instead"
++

Bug#1033075: unblock: strongswan/5.9.8-5

[Yves-Alexis Perez]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: strongs...@packages.debian.org
Control: affects -1 + src:strongswan

Hi release team,

I've updated the strongSwan package in sid few days ago to fix a
security issue (only present in testing/sid, not stable). The timing
(with the freeze) wasn't perfect, and I actually lost a couple of days
by uploading the binary instead of the sources.

I'm unsure why it didn't migrate with the new freeze policy (it had 10
days) but could you let it migrate now? The changes are minimal and
actually fix a security issue.

unblock strongswan/5.9.8-5

Bug#1033074: unblock: base-files/12.4

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:base-files

Please unblock package base-files

[ Reason ]
It contains the changes everybody expects for bookworm as stable.

[ Tests ]
I've done my best double-checking that everything is correct.

[ Risks ]
The upload contains also other minor changes, but all of them are small,
all of them are low risk, and none of them should affect the end user.

[ 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 testing

[ Other info ]

Note 1: I'm actually using a diff in "git show" format,
because the old "copyright.in" is now simply "copyright"
and a debdiff would show this as a spurious big difference.

Note 2: All the changes in the licenses/* directory are really the
result of refreshing the licenses. I do not decide about those changes
nor I have a way to control them.

Thanks.

unblock base-files/12.4diff --git a/debian/README b/debian/README
index 01570a9..9ced2ea 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "bookworm" or "testing"?
+says "trixie/sid". Should it not read "trixie" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "sid" or "unstable"?
+says "trixie/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable 
distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bookworm/sid" (or whatever is appropriate).
+"trixie/sid" (or whatever is appropriate).
 
-Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
+Q. Why "trixie/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff --git a/debian/base-files.lintian-overrides 
b/debian/base-files.lintian-overrides
index d57f3a3..691e9e6 100644
--- a/debian/base-files.lintian-overrides
+++ b/debian/base-files.lintian-overrides
@@ -2,21 +2,21 @@
 # Permissions 0700 on /root are intentional as people expect
 # the /root directory to be more private than /home/* directories.
 #
-base-files: non-standard-dir-perm root/ 0700 != 0755
+base-files: non-standard-dir-perm 0700 != 0755 [root/]
 #
 # The /etc/os-release symlink is relative on purpose to avoid breaking dracut.
 # See Bug #755394 for details.
 #
-base-files: symlink-should-be-absolute etc/os-release ../usr/lib/os-release
+base-files: relative-symlink ../usr/lib/os-release [etc/os-release]
 #
 # The purpose of having licenses here is precisely to allow
 # other packages to reference them.
 #
-base-files: extra-license-file usr/share/common-licenses/Artistic
-base-files: extra-license-file usr/share/common-licenses/BSD
-base-files: extra-license-file usr/share/common-licenses/GPL-1
-base-files: extra-license-file usr/share/common-licenses/GPL-2
-base-files: extra-license-file usr/share/common-licenses/GPL-3
-base-files: extra-license-file usr/share/common-licenses/LGPL-2
-base-files: extra-license-file usr/share/common-licenses/LGPL-2.1
-base-files: extra-license-file usr/share/common-licenses/LGPL-3
+base-files: extra-license-file [usr/share/common-licenses/Artistic]
+base-files: extra-license-file [usr/share/common-licenses/BSD]
+base-files: extra-license-file [usr/share/common-licenses/GPL-1]
+base-files: extra-license-file [usr/share/common-licenses/GPL-2]
+base-files: extra-license-file [usr/share/common-licenses/GPL-3]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
diff --git a/debian/changelog b/debian/changelog
index 3259901..c9b9f12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+base-files (12.4) unstable; urgency=medium
+
+  * Release candidate for bookworm as stable:
+  - Use "12" as version in /etc/issue and /etc/issue.net.
+(never expected to change after release)
+  - Use 12.0 as version in /etc/debian_version.
+(expected to change at every point release)
+  - Change PRETTY_NAME in /usr/lib/os-release, adding 12 as version number
+and "(bookworm)" as codename. Add also VERSION_ID and VERSION.
+(never expected to change)
+  - Variable VERSION_CODENAME was already defined as 

Bug#1032968: unblock: passt/0.0~git20230309.7c7625d-1

[Stefano Brivio]

On Thu, 16 Mar 2023 16:22:33 +0100
Paul Gevers  wrote:

> Hi Stefano,
> 
> On 14-03-2023 22:44, Stefano Brivio wrote:
> > - full slirp4netns(1) compatibility not granted  
> 
> I've never heard of this before, what does that mean for the user?

pasta(1) is supposed to provide a drop-in replacement for
slirp4netns(1): you create a network namespace, as a regular user, and
it can give that namespace network connectivity without creating any
interface outside it.

The main distinction is that it's written with performance, IPv6, and
security in mind, but functionally it's supposed to be a superset of it.

It has other functionalities (such as full IPv6 support), so it's not
useless otherwise, but it's probably unexpected for users (and I see
it as a source of potential bugs) that they can't set an outbound
address as they could do it on slirp4netns.

> > [ Tests ]
> > I ran the upstream test suite against the packaged version on a
> > Debian testing (Bookworm) x86_64 system.  
> 
> If you can do this manually, you can probably also do it automatically. 
> If you turn this into an autopkgtest [1] your package could migrate 
> without our intervention (providing that it passes on all architectures 
> where the binary builds and that it tests a substantial part of the 
> as-installed binaries).

Salsa seems to be inaccessible at the moment (and I can't fetch that
link from archive.org), but yes, I started reading about it just after
I realised the migration was blocked, so I know a bit already.

The current problem with the upstream test suite is that it takes a
long time to complete, and has a lot of dependencies, including things
that are not packaged in Debian (e.g. https://github.com/google/neper/).

But most of those dependencies (and time) are only needed for
performance tests, and we're working to refactor the test framework to
make it reasonably modular. It's not exactly trivial as we spawn virtual
machines and there are context dependencies between test cases, so it
will probably take a while. Just to give an idea, screen capture of
latest run:

  https://passt.top/#continuous-integration

Once that is done, it should be trivial (from what I remember of the
document you linked) to create autopkgtests for it.

We also have optional tests (which I run from time to time) to check
build and basic functionality on several distributions, including a few
flavours of Debian:

  https://passt.top/passt/tree/test/distro/debian

but that makes little sense now that it's packaged (and that we'll be
able to have distribution tests... in distributions, eventually).

-- 
Stefano

Bug#1033073: libnginx-mod-rtmp: clients hang trying to play published streams due to Debian default nginx configuration

[Mark Nipper]

Package: libnginx-mod-rtmp
Version: 1:1.2.2+dfsg-3
Severity: important
Tags: upstream

I've already opened an issue for this upstream at:
---
https://github.com/arut/nginx-rtmp-module/issues/1719

But to summarize my findings here, the Debian stock nginx
configuration uses:
---
worker_processes auto;

which seems to break things a bit for this module.  The default
value for that setting upstream is 1.  If I use 1 instead of
auto, then everything works fine.  If I leave it as auto or any
number other than 1, then I run into the issue where clients
trying to play a currently published stream hang indefinitely
after successfully opening the TCP connection to this RTMP module
on 1935.  Setting that option to 1 can massively decrease
performance though on massively multicore systems of today.

Thanks to the Open Streaming Platform folks though, I
found that I can keep worker_processes configured as anything
other than 1, thereby maintaining the potential performance
gains, by also uncommenting multi_accept in the events block,
which is commented out by default in Debian and also enabling the
top level rtmp_auto_push option for this module:
---
events {
worker_connections 768;
multi_accept on;
}

rtmp_auto_push on;
---

This gives me a working configuration with no client hangs
observed.

Assuming I'm not completely wrong about all of this, it's
probably worth mentioning in a README or some such in
/usr/share/doc at the very least as otherwise, people might have
a bad experience trying to make this module work consistently.

Thanks!

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

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

Versions of packages libnginx-mod-rtmp depends on:
ii  libc6   2.36-8
ii  nginx [nginx-abi-1.22.1-7]  1.22.1-9

Versions of packages libnginx-mod-rtmp recommends:
ii  nginx  1.22.1-9

libnginx-mod-rtmp suggests no packages.

-- no debconf information

-- 
Mark Nipper

Bug#1031328: crowdsec: symlink-target-in-build-tree for some test files

[Cyril Brulebois]

Control: tag -1 upstream
Control: forwarded -1 https://github.com/crowdsecurity/crowdsec/issues/2125

Cyril Brulebois  (2023-02-15):
> This was spotted during the final stages of 1.4.2-* preparations but it
> seemed not important enough to delay an upload:
> 
> E: golang-github-crowdsecurity-crowdsec-dev: symlink-target-in-build-tree 
> /build/crowdsec-1.4.2/_build/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/hubdir/collections/crowdsecurity/test_collection.yaml
>  
> [usr/share/gocode/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/install/collections/test_collection.yaml]
> E: golang-github-crowdsecurity-crowdsec-dev: symlink-target-in-build-tree 
> /build/crowdsec-1.4.2/_build/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/hubdir/scenarios/crowdsecurity/barfoo_scenario.yaml
>  
> [usr/share/gocode/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/install/scenarios/barfoo_scenario.yaml]
> 
> Those are test files, and they don't trigger a test suite failure
> within an autopkgtest test bed, that's why I proceeded with an upload
> without a fix.
> 
> That being said, that means the build is not reproducible, and it'd be
> far better to have that addressed once we have 1.4.2 into testing.

It looks like the existence of those symlinks is just a symptom of a
slightly bigger problem: some test files (and symlinks) created by the
test suite are left over, and they end up being shipped in the -dev
package.

I've forwarded this upstream (link above), and I plan on removing those
files manually via debian/rules; I'll wait a little to get an ACK from
upstream before doing so though. I'll probably check that an autopkgtest
run with the amended packaging still succeeds.


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


signature.asc
Description: PGP signature

Bug#956226: Not fixed in Debian 12 D-I Alpha2 as of 2023-03-16

[olivier]

Dear all,

This sitation also arises in the latest Debian Instaler (Netinst ISO) for 
Debian 12 available in Testing.
LVM-Thin Physical Volume previously created by a Proxmox-VE installer ISO 
cannot be removed by the Debian Installer.
Normal LVM (non-thin) PV also created by the same Proxmox Instal successfully 
removed.

Cheers,

Olivier

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

[Thomas Schmitt]

Hi,

Pete Batard wrote:
> Debian does not use an efi.img.

Oh it does with ISOs for i386 and amd64. There is a data file in the ISO
filesystem named
  /boot/grub/efi.img
advertised as MBR partition of type 0xEF and as El Torito boot image
for EFI:

  $ xorriso -indev debian-11.5.0-amd64-netinst.iso -report_system_area plain 
-report_el_torito plain
  ...
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x80  0x000   782336
  MBR partition  :   2   0x00  0xef 4064 5184
  MBR partition path :   2  /boot/grub/efi.img
  ...
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
  El Torito boot img :   1  BIOS  y   none  0x  0x00  42312
  El Torito boot img :   2  UEFI  y   none  0x  0x00   51841016
  El Torito img path :   1  /isolinux/isolinux.bin
  El Torito img opts :   1  boot-info-table isohybrid-suitable
  El Torito img path :   2  /boot/grub/efi.img

But Debian is nice by having in the ISO filesystem a copy of the file
tree in the FAT filesystem of the EFI partition.

  # mount debian-11.5.0-amd64-netinst.iso /mnt/iso
  ...
  # mount /mnt/iso/boot/grub/efi.img /mnt/fat
  $ (cd /mnt/fat ; find . -type f -exec ls -ld '{}' ';')
  -rwxr-xr-x 1 root root 934240 Sep 10  2022 ./efi/boot/bootx64.efi
  -rwxr-xr-x 1 root root 1684864 Sep 10  2022 ./efi/boot/grubx64.efi
  -rwxr-xr-x 1 root root 101 Sep 10  2022 ./efi/debian/grub.cfg
  $ (cd /mnt/iso ; find ./EFI -type f -exec ls -ld '{}' ';')
  -r--r--r-- 1 root root 934240 Sep 10  2022 ./EFI/boot/bootx64.efi
  -r--r--r-- 1 root root 1684864 Sep 10  2022 ./EFI/boot/grubx64.efi
  -r--r--r-- 1 root root 101 Sep 10  2022 ./EFI/debian/grub.cfg

The differences in the paths become insignificant when copying to FAT.
The tests results indicate that the lack of x-permissions with the ISO
files is not an issue either.

In the arm64 ISOs the /EFI tree is present three times. Once as appended
MBR partition 2, once as FAT image file /boot/grub/efi.img in the ISO
which serves as El Torito boot image, and again as unpacked /EFI tree in
the ISO.
(xorriso could point El Torito to the appended partition, thus eliminating
the need for the /boot/grub/efi.img file.)


> From what I can see, the maximum individual file name length when using
> Joliet extensions is 128 "characters"

It's less. A Joliet directory record has the same maximum size as an ISO
directory record: 255 bytes. Joliet encodes names in UCS-2 which uses
16 bit per character. The fixed header part of a directory record is 34
bytes large. So only 110 UCS-2 characters have room. For some reason
libisofs offers to write 103 characters at most. (It's long ago that this
decision was made not by me.)

In file
  /mnt/iso/.disk/mkisofs
i see the recorded -as mkisofs option:
  -joliet-long
which means according to man xorrisofs:
Allow  103  characters in Joliet file names rather than 64 as is
prescribed by the specification. Allow Joliet paths longer  than
the prescribed limit of 240 characters.


> if you are using Windows' native utilities, you won't be able
> format a partition that is larger than 64 GB to FAT32,

The largest official Debian ISOs are 50 GB.
But i have a script which can merge a complete set to a ~90 GB ISO. :))


Have a nice day :)

Thomas

Bug#1033035: hw-detect: trivial patches

[Pascal Hambourg]

On 16/03/2023 at 12:05, Cyril Brulebois wrote:


Pascal Hambourg  (2023-03-16):


- check-missing-firmware.sh: shift positional parameters after reading
-n


IIUC the script arguments are expected to be network interface names 
except the first one which may be "-n". In this case, I believe it 
should be shifted away before setting IFACES="$@".



- check-missing-firmware.sh: define local variables in functions


These variables are intended to be used only inside their respective 
functions, so it is cleaner and safer if they are declared as local 
(like in other hw-detect scripts) to avoid potential side effects with 
other functions or the main body if they use variables with the same names.



The commit messages say what you do, not why.


Sorry, I thought it was obvious.


- check-missing-firmware.sh: replace spaces with tabs in indentation


NACK. We have mixed tabs and spaces all over the place, in hw-detect and
in other components. We don't need noise. Especially not at this stage.


Spaces for indentation are present only in one function, so I thought it 
might be a text editor glitch or human error and it was desirable to 
make it consistent with the rest of the script. AFAICS the only 
consistent use of spaces for indentation in other hw-detect scripts is 
before "case" patterns, which makes sense. Most other occurrences look 
like mistakes. But I take your point about avoiding cosmetic fixes now.

Bug#1033072: mailman3-web: After upgrade, moderation operations are broken

[Peter Chubb]

Package: mailman3-web
Version: 0+20200530-2.1
Severity: normal

Dear Maintainer,

I had a working mailman3 installation.  I did 'apt upgrade' which pulled
in a new python3-hyperkitty and nginx.  Now when trying to manage
'held messages' on a list:
  -- the checkbox next to 'Subject' does not toggle all the checkboxes below it.
  -- Clicking on a held message does not switch to a page where I can manage
 the sender of that message. In fact it does nothing.

I suspect the javascript to run this is broken somehow.
In my bro3wser console when looking at teh javascript I see:

Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery must be 
included before Bootstrap's JavaScript.
at Object.jQueryDetection (bootstrap.min.js:34:98)
at bootstrap.min.js:34:407
at bootstrap.min.js:6:200
at bootstrap.min.js:6:288
main.js:38 Uncaught ReferenceError: $ is not defined
at main.js:38:1
held_messages:445 Uncaught ReferenceError: $ is not defined
at held_messages:445:7
held_messages.js:3 Uncaught ReferenceError: $ is not defined
at loadjs (held_messages.js:3:3)
at held_messages:452:1

The held_messages source file refers to jquery-3.6.0; but 
jquery-1.11.3 is installed in /var/lib/mailman3/web/static/postorius/libs/jquery


I notice that version 3.6 is in
/usr/share/python3-django-postorius/static/postorius/libs/jquery ...
should the nginx snippet in /etc/mailman3 be updated to point here?

For now I deleted /var/lib/mailman3/web/static/postorius and replaced it
with a symlink to /usr/share/python3-django-postorius/static/postorius



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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  python33.11.2-1
ii  python3-django-hyperkitty  1.3.7-1
ii  python3-django-postorius   1.3.8-3
ii  python3-psycopg2   2.9.5-1+b1
ii  python3-whoosh 2.7.4+git6-g9134ad92-7
ii  sysvinit-utils [lsb-base]  3.06-2
ii  ucf3.0043+nmu1
ii  uwsgi-core 2.0.21-5
ii  uwsgi-plugin-python3   2.0.21-5

Versions of packages mailman3-web recommends:
ii  nginx  1.22.1-7

Versions of packages mailman3-web suggests:
ii  postgresql  15+247

-- debconf information:
  mailman3-web/remote/port:
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/missing-db-package-error: abort
* mailman3-web/passwords-do-not-match:
* mailman3-web/superuser-mail: listadmin@sel4.systems
  mailman3-web/pgsql/manualconf:
  mailman3-web/mysql/method: Unix socket
* mailman3-web/db/dbname: mailman3web
  mailman3-web/db/basepath:
* mailman3-web/dbconfig-install: true
  mailman3-web/install-error: abort
  mailman3-web/remove-error: abort
  mailman3-web/upgrade-backup: true
* mailman3-web/db/app-user: mailman3web@localhost
  mailman3-web/pgsql/no-empty-passwords:
  mailman3-web/mysql/admin-user:
* mailman3-web/restart-webserver: true
* mailman3-web/pgsql/method: Unix socket
* mailman3-web/pgsql/admin-user: postgres
* mailman3-web/configure-webserver: none
  mailman3-web/internal/reconfiguring: false
  mailman3-web/mysql/authplugin: default
  mailman3-web/nginx-choice:
  mailman3-web/dbconfig-remove: true
  mailman3-web/upgrade-error: abort
* mailman3-web/emailname: sel4.systems
* mailman3-web/dbconfig-reinstall: true
* mailman3-web/superuser-name: seL4
  mailman3-web/remote/host: localhost
  mailman3-web/purge: false
* mailman3-web/database-type: pgsql
* mailman3-web/pgsql/authmethod-user: ident
  mailman3-web/internal/skip-preseed: false
  mailman3-web/pgsql/changeconf: false
* mailman3-web/pgsql/authmethod-admin: ident
  mailman3-web/remote/newhost:

Bug#536422: same problem

[Nicolas Mora]

Hello,

I recently took over maintenance for the package motion in Debian.

This bug is quite old and related to old version of motion and libav. 
Since it hasn't got any update since 2009, I have the sensation it can 
be closed.


I'll wait a little bit for a feedback before closing it.

/Nicolas

Bug#1030780: Maintainers wanted for softether-vpn

[Sergio Ryan]

Tell me how can I start. I can adopt this package and maintain it as I 
still use it everyday.


OpenPGP_0x2D1BCB89660F8747.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033071: nodejs: Build errors on node-js packages due to support for tsc 3.6

[Walter Lozano]

Package: nodejs
Version: 12.22.12~dfsg-1~deb11u3
Severity: important

Dear Maintainer,

In commit [1] a symlink to @types/node/tsc3.6 was included to mitigate
regression introduced in 12.22.12 which dropped support for tsc 3.6 (Closes:
#1014914)

With this fix, other packages start to experience build errors, as example

$ docker run -it --rm debian:bullseye-slim sh -c 'cat /etc/apt/sources.list |
sed s/^deb/deb-src/ > /etc/apt/sources.list.d/srcs.list && apt update && apt
install --no-install-recommends -y apt-src && apt-src install node-babel7 &&
apt-src build node-babel7'
...
cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types
cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6'
dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node
./node_modules/\@types returned exit code 1
make: *** [debian/rules:15: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
E: Building failed

I cannot confirm how many packages are affected but an initial list is:

- node-babel7
- node-domutils
- node-follow-redirects
- node-htmlparser2
- node-jschardet
- node-recast

[1] https://salsa.debian.org/js-
team/nodejs/-/commit/c7b5bc3fb81df93b194bd9caa46bea6f226a9f7a

Thanks in advance!

Walter


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nodejs depends on:
ii  libc6  2.35-0ubuntu3.1
ii  libnode72  12.22.9~dfsg-1ubuntu3

Versions of packages nodejs recommends:
ii  ca-certificates  20211016ubuntu0.22.04.1
ii  nodejs-doc   12.22.9~dfsg-1ubuntu3

Versions of packages nodejs suggests:
pn  npm  

-- no debconf information

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Richard Lewis]

On Thu, 16 Mar 2023, 12:21 Holger Levsen,  wrote:

>
>
> since bookworm rsyslog defaults to timestamps in short-iso-precise format,
> while logcheck rules (and journald) still default to the old rule format,
>

I dont understand - logcheck rules cater for both formats since 1.4.1 iirc
and this is already explained in NEWS.Debian. (and i thought that included
instructions for updating local rules in that)

can you clarify what the request for logcheck is here?

Did you maybe not upgade logcheck-database to latest version?


and while the default logcheck rules in the package are easily switched,
> this poses problems for larger installations with local logcheck rules
> used on systems running different suites.
>

the longer term solution is perhaps macros in rules, which may happen in
trixie. then rules can start

^@TIMESTAMP @HOSTNAME:.$

(or whatever syntax is chosen)

and you could set TIMESTAMP to whatever you liked


>  | h01ger: I wasn't aware that logcheck checks the journal until 2
> weeks ago someone asked about it
>  https://github.com/systemd/systemd/issues/26639 was the result
> of this discussion
>  yeah, its a new feature (and sensible! i want it!)
>


it's actually not a new feature, was possible in at least bulleye, just
enabled it by default recently given the downgrade of rsyslog

 mbiebl: issues/26639 seems sensible too. will/shall that land in
> bookworm?
>  atm, it doesn't look like
>  dropping timestamps from all logcheck rules could migate this and
> is an easy way to run mixed suite setups
>

not sure the package should drop the prefixes,

 though it makes me wonder why i kept those for the last 10 or so
> years, if they now suddenly are not needed ;)
>  breaking habbits..
>  maybe you could make the existing parsing/regexps work with both
> formats
>  2023-03-16T12:45:45.159206+01:00
>  vs
>  2023-03-16T12:50:13.503482+0100
>  you'd basically just need an optional ':'  in the timezone
> information
>  that is rsyslog and journalctl --output=short-iso-precise
>  doesnt help with systems not yet running bookworm.
>  (and those are not all running bullseye either, but older
> releases too)
>  I thought this was about fixing it in bookworm
>  well, its also about using logcheck for all 'my' systems. i
> (co-)maintain several setups using logcheck...
>  and i'm sure i'm not the only one who'll encounter this
>  since when do both rsyslog and journalctl support
> --output=short-iso-precise ?
>  #475303 is from 2008, so i assume changing rsyslog format for old
> systems could work
>  rsyslog uses rfc 3339 by default since bookworm (has supported
> for 10+years), journald supports short-iso-precise since I can reemember
>  cool, so i'll switch to short-iso-precise everywhere at once
>  systemd, just checked: since v234
>  i guess this could be a NEWS entry for logcheck
>  | h01ger: so you'd miss o-o-stable (v232)
>  mbiebl: can i put this conversation in a wishlist bug against
> logcheck, asking to document this in NEWS?
>  It was my impression that logcheck changed the regexps which
> match the timestamps in a way that both matched the old and new format?


yes!



>

Bug#1033070: unblock: node-babel7/7.20.15+ds1+~cs214.269.168-2

[Pirate Praveen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: node-bab...@packages.debian.org
Control: affects -1 + src:node-babel7

Please unblock package node-babel7

[ Reason ]
This prevents breaking partial upgrades by updating minimum version of 
node-regexpu-core


[ Impact ]
gitlab partial upgrade from bullseye to bookworm is found to break when 
node-regexpu-core is not upgraded.

https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192

[ Tests ]
No upstream code changed, only minimum version of dependency is updated.

[ Risks ]
No upstream code changed, only minimum version of dependency is updated.

[ 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 testing

[ Other info ]

unblock node-babel7/7.20.15+ds1+~cs214.269.168-2


diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog	2023-02-17 13:35:54.0 +0530
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog	2023-03-16 17:52:46.0 +0530
@@ -1,3 +1,11 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-2) unstable; urgency=medium
+
+  * Update minimum version of node-regexpu-core to 5.2.1~.
+packages/babel-helper-create-regexp-features-plugin/package.json has
+"regexpu-core": "^5.2.1" and not adding it breaks partial upgrades.
+
+ -- Pirate Praveen   Thu, 16 Mar 2023 17:52:46 +0530
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-1) unstable; urgency=medium
 
   * Team upload
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/control node-babel7-7.20.15+ds1+~cs214.269.168/debian/control
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/control	2023-02-17 13:35:54.0 +0530
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/control	2023-03-16 17:52:20.0 +0530
@@ -108,7 +108,7 @@
  , node-make-dir
  , node-quick-lru
  , node-regenerator-transform (>= 0.14~)
- , node-regexpu-core
+ , node-regexpu-core (>= 5.2.1~)
  , node-resolve
  , node-semver (>= 7.0~)
  , node-slash

Bug#992172: exim4: CVE-2021-38371

[Andreas Metzler]

On 2023-03-15 Moritz Mühlenhoff  wrote:
> Am Sun, Aug 15, 2021 at 07:21:40AM +0200 schrieb Andreas Metzler:
> > On 2021-08-14 Salvatore Bonaccorso  wrote:
[...]
> > > CVE-2021-38371[0]:
> > > | The STARTTLS feature in Exim through 4.94.2 allows response injection
> > > | (buffering) during MTA SMTP sending.
> > [...]
> > 
> > IIRC that is mitigated in experimental (4.95 rc) by ALPN and unkown
> > command related changes, I will not be able to check in detail for a
> > week or so, though.

> Do you know if this is fixed in 4.96/bookworm?

Yes it is. 4.95 and later are fine.
https://lists.exim.org/lurker/message/20230315.200011.3128be8e.en.html

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#988948: CVE-2019-11939

[Moritz Mühlenhoff]

Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff:
> Source: thrift
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> CVE-2019-11939:
> https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757

Hi,
is this fixed in Bookworm?

Cheers,
Moritz

Bug#1033069: release-notes: Update release notes entry for OpenJDK security support

[Moritz Muehlenhoff]

Package: release-notes
Severity: important

Hi,
the "5.2.1.2. OpenJDK 17" section needs to be updated for bookworm:
The same applies for Java 21, so instead it should state:

Debian bookworm comes with an early access version of OpenJDK 21 (the next 
expected OpenJDK LTS
version after OpenJDK 17), to avoid the rather tedious bootstrap process. The 
plan is for
OpenJDK 21 to receive an update in bookworm to the final upstream release 
announced for
September 2023, followed by security updates on a best effort basis, but users 
should not
expect to see updates for every quarterly upstream security update.

Cheers,
Moritz

Bug#1033067: unblock: glide/2002.04.10ds1-21

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gl...@packages.debian.org
Control: affects -1 + src:glide

Please unblock package glide

[ Reason ]

This non-key package does not currently contain autopkgtests.

These two releases include a couple of changes to make the package
finally reproducible, as the generated shared libraries would change
the optimized objects being linked to depending on the build system
(for host=i386 build=amd64).

[ Impact ]

Same generated objects regardless of the build system being used.

[ Tests ]

The tests were performed locally in an amd64 host and an i386 chroot,
before and after the fixes, and the reproducible builds are now green
for i386 for this package.

[ Risks ]

The risks seem minimal, as this is just making sure the build always
behaves in the same way.

[ Checklist ]

  [√] all changes are documented in the d/changelog
(There is the grammar fix in the changelog itself, which I do not
 tend to mention explicitly as it seems unnecessary verbiage.)
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

(nothing)


unblock glide/2002.04.10ds1-21

Thanks,
Guillem
diff -Nru glide-2002.04.10ds1/debian/changelog 
glide-2002.04.10ds1/debian/changelog
--- glide-2002.04.10ds1/debian/changelog2023-02-26 23:15:35.0 
+0100
+++ glide-2002.04.10ds1/debian/changelog2023-03-10 02:37:51.0 
+0100
@@ -1,6 +1,20 @@
+glide (2002.04.10ds1-21) unstable; urgency=medium
+
+  * Pass --build and --host to configure via chores.3dfx.
+
+ -- Guillem Jover   Fri, 10 Mar 2023 02:37:51 +0100
+
+glide (2002.04.10ds1-20) unstable; urgency=medium
+
+  * Use autoconf $host_cpu instead of «uname -m» to decide how to optimize
+and what to compile into the resulting objects, which was making the
+build unreproducible on i386 when built on an amd64 build system.
+
+ -- Guillem Jover   Sat, 04 Mar 2023 13:24:56 +0100
+
 glide (2002.04.10ds1-19) unstable; urgency=medium
 
-  * Enable LFS build options. This should ABI safe as the shared library
+  * Enable LFS build options. This should be ABI safe as the shared library
 does not expose any problematic type.
   * Actually show the debconf error when the target is not a symlink.
 
diff -Nru glide-2002.04.10ds1/debian/patches/no-uname.patch 
glide-2002.04.10ds1/debian/patches/no-uname.patch
--- glide-2002.04.10ds1/debian/patches/no-uname.patch   1970-01-01 
01:00:00.0 +0100
+++ glide-2002.04.10ds1/debian/patches/no-uname.patch   2023-03-04 
13:38:57.0 +0100
@@ -0,0 +1,30 @@
+Description: Use autoconf $host_cpu instead of «uname -m»
+ This was making the build unreproducible as the uname will return the build
+ system CPU and not the host one.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ glide3x/configure.in |3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/glide3x/configure.in
 b/glide3x/configure.in
+@@ -142,6 +142,7 @@ AM_CONDITIONAL(FX_GLIDE_CVG, test x$FX_G
+ #
+ # Architecture
+ #
++AC_CANONICAL_HOST
+ AC_ARG_ENABLE([build-architecture],
+   [dnl
+   --enable-build-architecture Enable AMD 3DNow instructions 
[default=current]],
+@@ -152,7 +153,7 @@ AC_ARG_ENABLE([build-architecture],
+*)
+AC_MSG_ERROR([Illegal value (${enableval}) for 
--enable-build-architecture])
+;;
+-   esac],[FX_GLIDE_BUILD_ARCHITECTURE=`uname -m`])
++   esac],[FX_GLIDE_BUILD_ARCHITECTURE=$host_cpu])
+ AC_SUBST(FX_GLIDE_BUILD_ARCHITECTURE)
+ #
+ # Various tests needed at points in the build
diff -Nru glide-2002.04.10ds1/debian/patches/series 
glide-2002.04.10ds1/debian/patches/series
--- glide-2002.04.10ds1/debian/patches/series   2022-07-17 18:28:36.0 
+0200
+++ glide-2002.04.10ds1/debian/patches/series   2023-03-04 13:16:21.0 
+0100
@@ -36,3 +36,4 @@
 z12-local-libtool
 z13-install-perms
 no-x11.patch
+no-uname.patch
diff -Nru glide-2002.04.10ds1/debian/rules glide-2002.04.10ds1/debian/rules
--- glide-2002.04.10ds1/debian/rules2023-02-25 15:42:22.0 +0100
+++ glide-2002.04.10ds1/debian/rules2023-03-10 01:34:56.0 +0100
@@ -10,6 +10,12 @@
 
 include /usr/share/dpkg/default.mk
 
+ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
+  confflags += --build=$(DEB_HOST_GNU_TYPE)
+else
+  confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+endif
+
 ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
 ifeq ($(DEB_HOST_ARCH),alpha)
   CFLAGS += -mcpu=ev5 -fomit-frame-pointer \
@@ -32,6 +38,7 @@
   cd $(CURDIR)/glide3x; \
   mkdir $(CURDIR)/debian/tmp.$(1); \
   ./chores.3dfx --generate "--configure=--enable-fx-glide-hw=$(1) \
+$(confflags) \
 --prefix=/usr" --build-dir=build.$(1); \
   cd build.$(1); \
   ./build.3dfx --no-x DESTDIR="$(CURDIR)/debian/tmp.$(1)/" \

Bug#1033068: liquidsoap: udpate to 2.1.4 or apply RC patch

[Romain Beauxis]

Package: liquidsoap
Version: 2.1.3-1+b1
Severity: important

Dear Maintainer,

Thank you so much for maintaining liquidsoap for debian!

I have received the notification that debian bookworm was being put in
hard freeze and was wondering if it would be possible to either update
the package to version 2.1.4 before the final release?

Talking to our users it's pretty clear that for a lot of them, the
version shipped by the debian distribution that they use is the one that
they will base their script on.

The 2.1.x release cycle has been on debug mode for 4 releases now and
2.1.4 brings the best, most stable we've had on this release cycle so
far. It is also planned to be the last bugfix for that release cycle.

If for some reason it is not possible to update to this version, I would
suggest at least cherry-pick this commit: 
https://github.com/savonet/liquidsoap/commit/5e37c159
This commit fixes an issue where a remote request will be fully loaded
into memory before being processed by the streaming system, leading to
potentially large memory usage spike.

Again, thank for the hard work keeping this package up-to date and best
of luck for the final debian bookworm release!

-- Romain


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.15.49-linuxkit (SMP w/5 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages liquidsoap depends on:
ii  adduser   3.131
ii  curl  7.88.1-1
ii  libao41.2.2+20180113-1.1
ii  libasound21.2.8-1+b1
ii  libavcodec59  7:5.1.2-3
ii  libavdevice59 7:5.1.2-3
ii  libavfilter8  7:5.1.2-3
ii  libavformat59 7:5.1.2-3
ii  libavutil57   7:5.1.2-3
ii  libc6 2.36-8
ii  libcamomile-ocaml-data1.0.2+2-1
ii  libcurl3-gnutls   7.88.1-1
ii  libexif12 0.6.24-1+b1
ii  libfaad2  2.10.1-1
ii  libflac12 1.4.2+ds-2
ii  libfreetype6  2.12.1+dfsg-4
ii  libgcc-s1 12.2.0-14
ii  libgd32.3.3-9
ii  libgif7   5.2.1-2.5
ii  libglib2.0-0  2.74.6-1
ii  libgstreamer-plugins-base1.0-01.22.0-3
ii  libgstreamer1.0-0 1.22.0-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-2
ii  libjpeg62-turbo   1:2.1.5-2
ii  liblo70.31-1
ii  libmad0   0.15.1b-10.1+b1
ii  libmagic1 1:5.44-3
ii  libmp3lame0   3.100-6
ii  libogg0   1.3.5-3
ii  libopus0  1.3.1-3
ii  libpcre3  2:8.39-15
ii  libpng16-16   1.6.39-2
ii  libportaudio2 19.6.0-1.2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libsamplerate00.2.2-3
ii  libshine3 3.1.1-2
ii  libsoundtouch12.3.2+ds1-1
ii  libspeex1 1.2.1-2
ii  libssl3   3.0.8-1
ii  libstdc++612.2.0-14
ii  libswresample47:5.1.2-3
ii  libswscale6   7:5.1.2-3
ii  libtheora01.1.1+dfsg.1-16.1
ii  libtiff6  4.5.0-5
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.8.4-2
ii  libxpm4   1:3.5.12-1.1
ii  ocaml-base4.13.1-4
ii  sox   14.4.2+git20190427-3.4

Versions of packages liquidsoap recommends:
ii  logrotate 3.21.0-1
ii  vorbis-tools  1.4.2-1+b1
ii  vorbisgain0.37-2+b1

Versions of packages liquidsoap suggests:
pn  festival  
pn  icecast2  
pn  mplayer   
pn  yt-dlp

-- no debconf information

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi

Removed my old .vfu directory and allowed vfu to create a new 
default configuration.


PLEASE NOTE: I have disabled usage of internal viewer and editor 
(when I tested it with internal editor - everything worked fine)


Problem exists when I use vim or any other editor for following files:
aa%bb.txt
aa|bb.txt

On Wed, Mar 15, 2023 at 12:00:57PM +0200, Vladi Belperchinov-Shabanski wrote:


hello!

regarding opening of files with names like:

 'aa bb.txt'
 'aa$bb.txt'
 'aa%bb.txt'

as of v5.00: 30.Jan.2023, VFU does not require %f to be quoted.
it was reflected in the enclosed sample vfu.conf and HISTORY
changes files.

I'm sorry for the change but the old way was not good enough
even though it was this way for years.

please, get back to me if this does not help for some reason.

cheers!
Vladi.




--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Holger Levsen]

On Thu, Mar 16, 2023 at 01:31:37PM +, Richard Lewis wrote:
> I dont understand - logcheck rules cater for both formats since 1.4.1 iirc
> and this is already explained in NEWS.Debian. (and i thought that included
> instructions for updating local rules in that)

it's not. just checked the NEWS from 1.4.2 and it only explains
that systemd's journal is now also checked. no word about different time 
formats.
 
> Did you maybe not upgade logcheck-database to latest version?

this is also about giving advice what to do with *local* logcheck rules.
 
> the longer term solution is perhaps macros in rules, which may happen in
> trixie.

we need some solution/workaround/configuration/advice for bookworm, else
people will just not use logcheck, if it creates too much noise.

> >  dropping timestamps from all logcheck rules could migate this and
> > is an easy way to run mixed suite setups
> not sure the package should drop the prefixes,

i'm basically wondering why to have timestamp regexes in logcheck rules
at all. *not* having them has two benefits, I guess: a.) (very) slightly faster,
b.) easier to maintain/read by humans. what benefits *does* having them?

> >  It was my impression that logcheck changed the regexps which
> > match the timestamps in a way that both matched the old and new format?
> yes!

cool. so this sounds like easy advice to give for updating local rules! :)
and that's what I'm asking for to be done in debian/NEWS.


-- 
cheers,
Holger

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

We live in a world where teenagers get more and more desperate trying to
convince adults to behave like grown ups.


signature.asc
Description: PGP signature

Bug#1032967: [btrfs-progs][armhf] Cannot delete a subvolume or create a snapshot

[Adam Borowski]

On Tue, Mar 14, 2023 at 11:36:29PM +0200, Παύλος Γκέσος wrote:
> Package: btrfs-progs
> Version: 5.10.1-2 armhf
> 
> When I try to delete a previous created btrfs subvolume I get this:
> ERROR: Could not statfs: Value too large for defined data type
> 
> The same when I try to make a btrfs snapshot.

Hi, there are known issues with large filesystems on 32-bit.  Not just
btrfs for that matter -- it's just more likely to be affected because of
native multi-device support and two layers of addressing.

Thus:
* how big is the filesystem?
* does it consist of multiple devices?
* has it been rebalanced or converted to a different redundancy profile?

If the sum of all parts that are (or ever have been) included in the
filesystem approaches 8TB, this would be the cause.  In addition, any
address space that was allocated in the past but had been balanced/converted
away is lost -- virtual offsets always go up.  This is not a concern on
64-bit as you can't possibly use them up, but for 32-bit the limit can be
exceeded even with a single large disk.

Other filesystems also suffer from this limit, although MD at least moves
the threshold from being applied to raw device size to the available size
which allows redundant raid as long as the resulting size is below[1] 8TB.

Shedding the limit would require changing many parts of the kernel, and
there is currently no intention of ever doing that.  Thus, I'm afraid you
need to either use a smaller filesystem or a 64-bit kernel (which your CPU
doesn't support).

There's little support for 32-bit in general, it's in maintenance mode
these days...


Did I assume correctly that you ran into the limit?  If not, please say so.
Otherwise, all we can do is improving error messages.


[1]. Because disk manufacturers cheat on the definition of "terabyte",
an "8TB" disk has less than 1099511627776 bytes.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Richard Lewis]

On Thu, 16 Mar 2023, 13:40 Holger Levsen,  wrote:

> On Thu, Mar 16, 2023 at 01:31:37PM +, Richard Lewis wrote:
> > I dont understand - logcheck rules cater for both formats since 1.4.1
> iirc
> > and this is already explained in NEWS.Debian. (and i thought that
> included
> > instructions for updating local rules in that)
>
> it's not. just checked the NEWS from 1.4.2 and it only explains
> that systemd's journal is now also checked. no word about different time
> formats.
>

Is it not the first entry, from version 1.4.0 from dec 2022 in
/usr/share/doc/logcheck-database/README.logcheck-database.gz  ??

at least on my system it is there. i think my version is non-standard
(systemd unit is coming for trixie)


While I can sort of see an argument for putting this in logcheck's news
instead (or as well) that doesnt seem correct to me...logcheck-database is
what provides the rules for normal users -  it is recommended by logcheck.
I would assume people not using it know what they are doing.

If you really want to catch all users shouldnt it be in rsyslog's
NEWS.Debian ?

What do you think the best way forward is?

(I do intend to write something for debian's release notes about the
rsyslog change, if no-one else does.)

The wider issue is that logcheck has not been a package that works out of
the box without significant configuration and has had minimal attention for
several debian releases. we are trying to change that, but please give us
some time while we understand the gap - i think debian is slightly
fortunate to be releasing bookworm with a logcheck package that works at all

I suspect most of the rules in debian are so old they never match anything,
and there are definitely many updates needed. but i dont  think anyone has
the desire to do so before bookworm.

i personally dont think it is worth even contemplating that work until we
have revised the way rules are selected and the format they use.

Bug#1030780: Maintainers wanted for softether-vpn

[Sergio Ryan]

I can help, I have been using SoftEther for years now.

---

Sincerely,

Sergio

On Tue, 07 Feb 2023 14:23:55 +0100 "Andrej Shadura" wrote:

> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> Hi all,
>
> I packaged SoftEther VPN back in 2020 when people in Belarus 
protested against decades of dictatorship, and they needed a safe way to 
communicate with the outside world and with each other, circumventing 
the state censorship.

>
> Since then, due to a massive crackdown on protests and repressions 
against anyone remotely involved, most of my friends have moved abroad, 
and I, personally, don't know a single user of this VPN right now. 
Packaging is not hard, but not super trivial either, and requires some 
work to package subsequent releases. Not using this software myself, I'm 
really not in position to continue being the maintainer, and if nobody 
takes it over, I will have to orphan it eventually.

>
> Please let me know if you can help.
>
> --
> Cheers,
> Andrej
>
>



OpenPGP_0x2D1BCB89660F8747.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033066: RM: sendpage -- RoQA; obsolete, unmaintained, dead upstream

[Moritz Muehlenhoff]

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

Please remove sendpage. It's dead upstream, obsolete and unmaintained
(last maintainer upload 14 years ago and dropped from testing since
2021).

Cheers,
Moritz

Bug#1033064: installation-reports: Successful bookworm installation

[Martin Dosch]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: mar...@mdosch.de

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
Date: 2023-03-11

Machine: Lenovo Thinkpad 13
Partitions: 
LC_ALL=C df -Tl
Filesystem   Type 1K-blocks  Used Available Use% 
Mounted on
udev devtmpfs   8090756 0   8090756   0% /dev
tmpfstmpfs  1626956  1340   1625616   1% /run
/dev/mapper/think13--vg-root ext4 959122528 181009856 729318256  20% /
tmpfstmpfs  8134772  3192   8131580   1% 
/dev/shm
tmpfstmpfs 5120 0  5120   0% 
/run/lock
/dev/nvme0n1p2   ext2466026189587251454  43% /boot
/dev/nvme0n1p1   vfat523248  5948517300   2% 
/boot/efi
tmpfstmpfs  162695240   1626912   1% 
/run/user/1000
tmpfstmpfs  162695220   1626932   1% 
/run/user/1001

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

All went smooth.

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230217"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux think13 6.1.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 
(2023-01-29) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th 
Gen Core Processor Host Bridge/DRAM Registers [8086:5904] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD 
Graphics 620 [8086:5916] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #1 [8086:9d10] (rev f1)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #4 [8086:9d13] (rev f1)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC 
Controller [8086:9d58] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD 
Audio [8086:9d71] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl, 
snd_sof_pci_intel_skl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus 
[8086:9d23] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:5063]
lspci -knn: 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection (4) I219-V [8086:15d8] (rev 21)
lspci 

Bug#1030857: transmission 4.0.1-1

[Sandro Tosi]

> Really upstream should release 4.0.2 with these fixes right away,
> since 4.0.1 is, technically speaking, what we in the biz call
> "broken". But I digress.

upstream released 4.0.2:
https://github.com/transmission/transmission/releases/tag/4.0.2


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

Package: release-notes
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The release notes for i386 should specify the minimum CPU requirements.

While a kernel compiled for Geode LX (essentially a basic i686 without the 
optional CPU features) still ships in Debian, many packages enforce CPU flags 
that barf on anything older than 686-PAE.

One such package is 'sudo' (Bug #1004894) where upstream unilaterally enabled 
-fcf-protection and the Debian maintainer refuses to comment out the 
corresponding ./configure macros.

Additionally, other packages apparently disregard build-essentials' GCC 
defaults and instead configure flags to match the CPU features of the build 
host, which produces binaries that segfault on a Geode.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmQTa+AACgkQrh+Cd8S0
17YqHRAAtsb991JnECg5MgWkkH2XwYoGgSh2N15aPOta1Gt/MqP2pdYjfDEPvsqm
Mxsq8Q+OMdNXd/i5ZglqRbpRWUO8TGOQzL+keD3U3RBss9zhFqSiv47S6eZM6R1N
RefspxicGI/7WmMUW8tdnU6pmtnEiw1czjLlZ2WICZ1kYB3MknTxlLpxp8IxnDEX
cPyKbVPd/jtdzOysNILfPZiFFsPBcOsPzYSgLxvZRZk0XzoLQQLXK5ZNb306Z8hv
wDW47WB+iHBVNd0WiZaFod8fJMELIdqzcLUgv6I1fHzB0VnwkuECdr0RFSG+vuL8
C6APU+63p9C3Py9gmwI1fRfThBdX4c1qgKCY+kDxoAf8CGjma0vgdS65bJb7Lfes
JwpyxXX5SXqdHGWuqd3pqVYO523cKOzZSWoFiwhFaopyjxLWrTMqvVXuWLl7Mawp
oqrkjWdgogyPiZGWa/xTqccuKDjqClUQM3ZjcEPKx4/R4m2iMVMTsbqZfMgRlU/H
Z5zTQUleGH4EsE0XnTF0R2gf2OCJrlxT2xyqEx72c1/edZwKfQdekXraFOv+TudZ
JKgL43lbqem90+0+QoIjWDl2PV9Uy1R1PEg0ouHrinW6ZpZlJN9M4JTTvfXg6JEJ
RHvV/8wEx4UpUOlx9Zw2mkruHKKEwo8NfvhU63nGVeJbiMsPEtM=
=uw4a
-END PGP SIGNATURE-

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi

Removed my old .vfu directory and allowed vfu to create a new default
configuration.

PLEASE NOTE: I have disabled usage of internal viewer and editor (when I
tested it with internal editor - everything worked fine)

Problem exists when I use vim or any other editor for following files:
aa%bb.txt
aa|bb.txt

On Wed, Mar 15, 2023 at 12:00:57PM +0200, Vladi Belperchinov-Shabanski wrote:


hello!

regarding opening of files with names like:

 'aa bb.txt'
 'aa$bb.txt'
 'aa%bb.txt'

as of v5.00: 30.Jan.2023, VFU does not require %f to be quoted.
it was reflected in the enclosed sample vfu.conf and HISTORY
changes files.

I'm sorry for the change but the old way was not good enough
even though it was this way for years.

please, get back to me if this does not help for some reason.

cheers!
Vladi.




--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1031324: crowdsec: 404 on cscli hub update

[Cyril Brulebois]

Cyril Brulebois  (2023-03-01):
> Apparently upstream needs to do something specific for each upstream
> release that's getting packaged into Debian (so that the version we're
> reporting — according to the version spec they requested — matches
> something that's available on the hub).
> 
> That happened for v1.4.2 already, and the same needs to happen for
> v1.4.6.
> 
> That doesn't require any code change in the package.
> 
> Marking with pending anyway, since that's about to be fixed upstream
> (and documented as a known requirement so that they remember to do that
> for later versions).

After internal discussion upstream, it was decided to just include a 'v'
prefix in BUILD_VERSION, making the need for any manuals steps go away.


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


signature.asc
Description: PGP signature

Bug#986724: Already fixed

[Aurelien Jarno]

Hi,

On 2023-03-11 03:08, Andreas Teiß wrote:
> Hello,
> 
> is this bug already fixed in libc6 2.28-10+deb10u2?

The bug is still not fixed upstream, so there is no chance we can have
fixed it in 2.28-10+deb10u2.

Regards
Aurelien

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

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> I recently (with version 1.3.2) extended the documentation for unshare mode in
> the mmdebstrap  manual page to also cover these two files:
>
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/46fc269b549abe89d99e63addba0813bcbc938ac
>
> Does this answer some of the questions you had or do you think I should add
> more?

I like the docs. When debugging problems it's helpful to

- have a clear error message that says what the problem is

- have a clear connection between the error message, and a chunk of the
  docs that talks about that failure

Here I had:

W: no entry in /etc/subuid for dima
E: invalid idmap

and with the older mmdebstrap:

newuidmap: uid range [1-2) -> [10-11) not allowed
E: newuidmap 2086656  0 60017 1 1 10 1 failed: 
E: child had a non-zero exit status: 1
E: chown failed

Can we change "W: no entry in /etc/subuid for dima" to something like
"W: no entry in /etc/subuid for dima: mode=unshare will fail; see THIS
section of the docs", or maybe make it an error? If the docs contained
the exact error message we would see with this issue, that would be
super helpful too. Do you know why the older mmdebstrap has a different
error message? Is it something you changed in the code, or is there
something about that machine that's causing it?


> There are two problems:
>
>  2) whatever method you use to create new users does not create these
>  entries

I don't know why they're missing. It's an old install of sid,
continually being updated: /etc goes back to 2006! I don't think I ever
did anything funky with the users, but who knows. It's not an mmdebstrap
problem, in any case.


> I have a patch for you that should fix this problem in the sense that
> mmdebstrap should not choose the unshare mode anymore. If you like, apply the
> following to mmdebstrap from unstable:
>
> https://mister-muffin.de/p/ZwXV.diff

Neither of your patches apply to the current mmdebstrap from unstable
(I'm at 5d24b65 in the git tree). If you want me to test, you should
give me another patch. But I trust you to fix it, and I don't NEED the
patch, since I now know to fix the /etc/subuid and /etc/subgid. So you
can just apply the patch to the tree and close this bug.

Thank you very much for your help!

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Dima Kogan]

I see this on a machine where the user is missing from /etc/subuid:

  dima@shorty:~$ /tmp/mmdebstrap bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

  E: unable to pick chroot mode automatically


  dima@shorty:~$ /tmp/mmdebstrap --mode=unshare bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

  W: no entry in /etc/subuid for dima
  E: failed to parse /etc/subuid and /etc/subgid

Is this right? Can we get better error messages? The "normal" command a
user would type is the first one, and "unable to pick chroot mode
automatically" is unhelpful. It tells the user nothing about what went
wrong, or how to even look for a solution.

Thanks.

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> Thank you for your feedback! How about:
>
> E: unable to pick chroot mode automatically (use --mode for manual selection)
>
> This will make the user look up the --mode argument and its possible values in
> the man page. If the user then selects --mode=unshare, the error message
> indicates what is wrong.

That's better. What's the internal logic? I guess mmdebstrap tried
"unshare", and it didn't work. Did it try all the others too, and they
didn't work also? It doesn't hurt to have ridiculously long error
messages. We COULD say

  E: unable to pick chroot mode automatically (use --mode for manual
  selection). Tried A, which didn't work because X; tried B, which
  didn't work because Y...

So if mmdebstrap already knows that --mode=unshare would produce

  W: no entry in /etc/subuid for dima
  E: failed to parse /etc/subuid and /etc/subgid

It could say that initially. Maybe that's overkill and too much typing
for you. What you have already already tells the user what to read about
and play with (--mode), so maybe that's fine.

Thanks!

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> The problem with ridiculously long error messages is, that mmdebstrap
> currently has no way to wrap long error messages after 80 columns or
> so. A very long error message is hard to read if it doesn't get
> wrapped similar to how you did it in your example.

I don't think this is something that mmdebstrap should be thinking
about. Error messages aren't something that needs to be immediately
fully consumable at a glance. Debugging takes time, and if we can save
the user even a bit of debugging time, then the extra minute it takes
for them to wrap the line is worth it. And does it really take any time
at all? I use either xterm or the emacs shell 100% of the time, and both
of those will wrap long lines to make them legible, without me having to
ask.


> The second reason is, that it would not be easy to store and forward
> the reason why the other modes failed. Especially the unshare mode can
> fail for 26 different reasons if I counted correctly. Letting the
> test-function silently fail when checking for the mode but extracting
> the error message would turn the code even more into spagetti.

Yeah. I was wondering if this was the case.

I think what you have is great. Ship it!

And thanks.

Bug#1031162: task-gnome-desktop: Libreoffice is configured to open all text documents on default gnome desktop

[Holger Wansing]

Control: reassign -1 gnome


Stuart Read  wrote (Sun, 12 Feb 2023 10:10:25 -0600):
> Package: task-gnome-desktop
> Version: 3.71
> Severity: normal
> 
> Dear Maintainer,
> 
> After a fresh install of bullseye from di-bookworm-alpha1 netinst, all text
> documents on the system (such as README.Debian, or .ssh/config) open with 
> Libreoffice Writer by default.
> 
> This doesn't seem desirable, I think it used to be gedit.
> I'm also not sure how to change this globally.

This is not defined in task-gnome-desktop.
Re-assigning to gnome metapackage for now


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#854209: More general problem than just with convert_UTF

[Soren Stoutner]

I was looking at Lintian’s source code to prepare a patch that would correct 
these false positives and I realized that Lintian doesn’t actually check for 
the presence of the problematic license at all.  Rather, it was checking for 
some text that appears at the bottom of convert_UTF.  Probably because they 
were worried that the words in the license file were too common and they didn’t 
want false-positives (which is what they ended up with anyway).

So, I corrected the check to actually look for the problematic license and 
then ran the patched version against the qtwebengine-opensource-src package, 
which is one of the packages that had the false positive.  This removed the 
false positive, but I was surprised to find that it discovered four other 
affected files in the package.

E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/
3rdparty/chromium/third_party/breakpad/breakpad/LICENSE]
E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/
3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_10-1998.ucm]
E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/
3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_11-2001.ucm]
E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/
3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_14-1998.ucm]

One of these is a summary license file, but the other three are data files that 
contain the problematic license in their headers.

This made me start to wonder how many other files in Debian also have the 
problematic license that have gone undetected because the Lintian check was 
not well formatted.

In the case of these files it is possible, perhaps even likely, that Unicode 
also relicensed them under a DFSG-free license at some point.  I am going to 
work with upstream to determine if that was the case and, if so, correct the 
license.  Otherwise, I will work with upstream to see if there is some DFSG 
alternative to these files.

Given the fact that this license extends beyond the convert_UTF file, I am 
planning on amending my patch to rename the check to something more generic, 
like license-problem-unicode and updating the description of the tag.

For anyone coming to this bug report with questions about the status of a 
particular Unicode license, the problematic license contains the following 
statement:

> Unicode, Inc. hereby grants the right to freely use the information
> supplied in this file in the creation of products supporting the
> Unicode Standard

This is not DFSG-free because it restricts the users from using the source 
code in ways that do not support the Unicode standard.  This phrase does not 
exist in the license that Unicode adopted later and which they relicensed 
their files to use.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1033063: RFS: hoteldruid/3.0.5-1 -- web-based property management system for hotels or B

[Marco M. F. De Santis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : hoteldruid
   Version  : 3.0.5-1
   Upstream contact : Marco Maria Francesco De Santis 


 * URL  : http://www.hoteldruid.com/
 * License  : CC0-1.0, AGPL-3
 * Vcs  : None
   Section  : web

The source builds the following binary packages:

  hoteldruid - web-based property management system for hotels or B

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_3.0.5-1.dsc


Changes since the last upload:

 hoteldruid (3.0.5-1) unstable; urgency=low
 .
   * New upstream release
   * debian/control: updated Standards-Version
   * debian/control: added recommendation on php-mbstring previously
 included in core php packages
   * fixed icon name in desktop file
   * fixed launchable field in appdata file

Regards,
--
  Marco Maria Francesco De Santis

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Holger Levsen]

On Thu, Mar 16, 2023 at 05:52:44PM +, Richard Lewis wrote:
> Is it not the first entry, from version 1.4.0 from dec 2022 in
> /usr/share/doc/logcheck-database/README.logcheck-database.gz  ??

aaah, thanks! I only checked /usr/share/doc/logcheck/NEWS.Debian.gz
but not /usr/share/doc/logcheck-database/NEWS.Debian.gz

> While I can sort of see an argument for putting this in logcheck's news
> instead (or as well) that doesnt seem correct to me...logcheck-database is
> what provides the rules for normal users -  it is recommended by logcheck.
> I would assume people not using it know what they are doing.
> 
> If you really want to catch all users shouldnt it be in rsyslog's
> NEWS.Debian ?

no, because it also effects logcheck users not using logcheck-database
at all. ;)
 
> What do you think the best way forward is?
> 
> (I do intend to write something for debian's release notes about the
> rsyslog change, if no-one else does.)

that's great, maybe that's the best way forward indeed.

so maybe reassign this bug to src:release-notes?

> The wider issue is that logcheck has not been a package that works out of
> the box without significant configuration and has had minimal attention for
> several debian releases. we are trying to change that, but please give us
> some time while we understand the gap - i think debian is slightly
> fortunate to be releasing bookworm with a logcheck package that works at all

;) I very much appreciate your efforts bringing logcheck back in shape!
 
> I suspect most of the rules in debian are so old they never match anything,
> and there are definitely many updates needed. but i dont  think anyone has
> the desire to do so before bookworm.

*g*

> i personally dont think it is worth even contemplating that work until we
> have revised the way rules are selected and the format they use.

I trust your judgement.

Thanks for maintaining logcheck.


-- 
cheers,
Holger

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

In a world where you can be anything, be kind.


signature.asc
Description: PGP signature

Bug#1032999: unblock: mesa/22.3.6-1

[Timo Aaltonen]

Paul Gevers kirjoitti 15.3.2023 klo 21.46:

Hi Timo,

On 15-03-2023 19:15, Timo Aaltonen wrote:
There's actually 22.3.7 out, which I was thinking of uploading to sid, 


Is that following the freeze policy [1]? I.e. targeted fixes? (It might 
be, I don't know the release policy of mesa).


Mesa does quarterly feature releases, and then bugfix releases on top of 
those. 22.3 was the feature release, 22.3.x are for bugfixes only. So 
yes, it does follow the policy. 23.0 is the latest release and will stay 
in experimental until bookworm is out.


since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


Well, it's blocked by something else, having *this* version tested in 
unstable is worth quite a bit for us. So, please only upload that 
version if it meets the freeze policy.


Paul


I think it makes sense to let 22.3.6 migrate first, and not risk that by 
another upload at this time. Once it has migrated, I'll see if 22.3.7-1 
could make it to the release or not.



--
t

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Julien Cristau]

Control: reopen -1
Control: found it 6.1.15-1

On Thu, Mar 16, 2023 at 11:17:19 +0100, Julien Cristau wrote:

> Version: 6.1.15-1
> 
> On Tue, Mar 14, 2023 at 15:29:08 +0100, Diederik de Haas wrote:
> 
> > On Tuesday, 14 March 2023 14:55:04 CET Julien Cristau wrote:
> > > Package: src:linux
> > > Version: 6.1.12-1
> > > 
> > > After upgrading to 6.1.12-1 my laptop started hanging regularly (3 times
> > > in a few hours).  Downgraded to 6.1.8-1 and I've not seen this for a
> > > week, so this looks like a recent regression.
> > 
> > Testing now has 6.1.15-1, can you test it with that?
> > There's another update in the pipeline (at least to 6.1.19) and when it 
> > becomes available, it would be useful if you could test that as well.
> 
> I rebooted on 6.1.15-1 last night and things are still looking good so
> I'll call this fixed.  Thanks.
> 
Spoke too soon:

> [84564.498495] BUG: kernel NULL pointer dereference, address: 0398
> [84564.498502] #PF: supervisor write access in kernel mode
> [84564.498504] #PF: error_code(0x0002) - not-present page
> [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0 
> [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI
> [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted 6.1.0-6-amd64 
> #1  Debian 6.1.15-1
> [84564.498516] Hardware name: LENOVO 20XW00ABUS/20XW00ABUS, BIOS N32ET82W 
> (1.58 ) 12/05/2022
> [84564.498518] Workqueue: kacpi_notify acpi_os_execute_deferred
> [84564.498525] RIP: 0010:queue_work_on+0x15/0x40
> [84564.498529] Code: ff ff ff e9 9a fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
> 66 90 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 44 00 00  48 
> 0f ba 2a 00 73 15 31 c9 80 e7 02 74 06 fb 0f 1f 44 00 00 89
> [84564.498531] RSP: 0018:b15ea96c3e38 EFLAGS: 00010002
> [84564.498533] RAX: 0202 RBX: 0202 RCX: 
> 
> [84564.498535] RDX: 0398 RSI: 93ea00051000 RDI: 
> 2000
> [84564.498536] RBP: 0004 R08: 93ea0383b510 R09: 
> 
> [84564.498537] R10:  R11: 005f R12: 
> 93f13f639b00
> [84564.498538] R13:  R14: 93ebffadba80 R15: 
> 93ebdd74a998
> [84564.498539] FS:  () GS:93f13f60() 
> knlGS:
> [84564.498540] CS:  0010 DS:  ES:  CR0: 80050033
> [84564.498541] CR2: 0398 CR3: 000503886004 CR4: 
> 00770ef0
> [84564.498543] PKRU: 5554
> [84564.498544] Call Trace:
> [84564.498546]  
> [84564.498552]  ucsi_acpi_notify+0xa8/0xc0 [ucsi_acpi]
> [84564.498557]  acpi_ev_notify_dispatch+0x42/0x5a
> [84564.498560]  acpi_os_execute_deferred+0x13/0x20
> [84564.498563]  process_one_work+0x1c4/0x380
> [84564.498565]  worker_thread+0x4d/0x380
> [84564.498568]  ? _raw_spin_lock_irqsave+0x23/0x50
> [84564.498572]  ? rescuer_thread+0x3a0/0x3a0
> [84564.498574]  kthread+0xe6/0x110
> [84564.498577]  ? kthread_complete_and_exit+0x20/0x20
> [84564.498580]  ret_from_fork+0x1f/0x30
> [84564.498584]  
> [84564.498585] Modules linked in: tun xt_conntrack nft_chain_nat 
> xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 
> nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c 
> nfnetlink br_netfilter bridge stp llc ctr ccm rfcomm cmac algif_hash 
> algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr 
> overlay ipmi_devintf bnep ipmi_msghandler binfmt_misc nls_ascii nls_cp437 
> vfat fat snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common 
> snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic snd_soc_dmic snd_sof_pci_intel_tgl 
> snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation 
> soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof 
> iwlmvm snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core 
> snd_soc_acpi_intel_match x86_pkg_temp_thermal intel_powerclamp snd_soc_acpi 
> snd_soc_core coretemp snd_compress mac80211 soundwire_bus btusb mei_hdcp 
> btrtl kvm_intel btbcm
> [84564.498630]  btintel intel_rapl_msr snd_hda_intel btmtk pmt_telemetry 
> pmt_class bluetooth libarc4 snd_intel_dspcfg kvm snd_intel_sdw_acpi iwlwifi 
> snd_hda_codec irqbypass uvcvideo snd_hda_core videobuf2_vmalloc rapl 
> processor_thermal_device_pci_legacy videobuf2_memops jitterentropy_rng 
> snd_hwdep processor_thermal_device intel_cstate cfg80211 videobuf2_v4l2 
> snd_pcm processor_thermal_rfim thinkpad_acpi videobuf2_common drbg 
> processor_thermal_mbox nvram processor_thermal_rapl ansi_cprng videodev 
> platform_profile snd_timer ecdh_generic iTCO_wdt ledtrig_audio ucsi_acpi 
> mei_me typec_ucsi intel_pmc_bxt snd iTCO_vendor_support roles intel_uncore 
> pcspkr intel_rapl_common mc mei watchdog soundcore ecc typec intel_vsec 
> intel_soc_dts_iosf wmi_bmof rfkill ac soc_button_array int3403_thermal joydev 
> int340x_thermal_zone cdc_mbim int3400_thermal cdc_wdm acpi_thermal_rel 
> 

Bug#1012763: golang-github-emicklei-go-restful: CVE-2022-1996

[Moritz Mühlenhoff]

Am Mon, Jun 13, 2022 at 06:12:36PM +0200 schrieb Moritz Mühlenhoff:
> Source: golang-github-emicklei-go-restful
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for 
> golang-github-emicklei-go-restful.
> 
> CVE-2022-1996[0]:
> | Authorization Bypass Through User-Controlled Key in GitHub repository
> | emicklei/go-restful prior to v3.8.0.
> 
> https://huntr.dev/bounties/be837427-415c-4d8c-808b-62ce20aa84f1/
> https://github.com/emicklei/go-restful/commit/fd3c327a379ce08c68ef18765bdc925f5d9bad10

Could we get that fixed for Bookworm?

Cheers,
Moritz

Bug#1014599: svgpp: CVE-2021-44960

[Moritz Mühlenhoff]

Am Fri, Jul 08, 2022 at 04:31:10PM +0200 schrieb Moritz Mühlenhoff:
> Source: svgpp
> X-Debbugs-CC: t...@security.debian.org
> Severity: normal
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for svgpp.
> 
> CVE-2021-44960[0]:
> | In SVGPP SVG++ library 1.3.0, the XMLDocument::getRoot function in the
> | renderDocument function handled the XMLDocument object improperly,
> | returning a null pointer in advance at the second if, resulting in a
> | null pointer reference behind the renderDocument function.
> 
> https://github.com/svgpp/svgpp/issues/101

This was fixed in 
https://github.com/svgpp/svgpp/commit/0bc57f2cc6d9d86a0fa1ce73e508c2b5994b4b91
Could we get that fixed for Bookworm?

Cheers,
Moritz

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Diederik de Haas]

On Thursday, 16 March 2023 18:11:27 CET Julien Cristau wrote:
> > I rebooted on 6.1.15-1 last night and things are still looking good so
> > I'll call this fixed.  Thanks.
> 
> Spoke too soon:
> > [84564.498495] BUG: kernel NULL pointer dereference, address:
> > 0398 [84564.498502] #PF: supervisor write access in kernel
> > mode
> > [84564.498504] #PF: error_code(0x0002) - not-present page
> > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0
> > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted
> > 6.1.0-6-amd64 #1  Debian 6.1.15-1 [84564.498516] Hardware name: LENOVO
> > 20XW00ABUS/20XW00ABUS, BIOS N32ET82W (1.58 ) 12/05/2022 [84564.498518]
> > Workqueue: kacpi_notify acpi_os_execute_deferred

Bummer.

Since 6.1.8 I found the following 2 commits in drivers/usb/typec/ucsi:

3d7f77e55da3455c8844b651e37779c90e201f48 titled
"usb: ucsi: Ensure connector delayed work items are flushed"

fdd11d7136fd070b3a74d6d8799d9eac28a57fc5 titled
"usb: typec: ucsi: Don't attempt to resume the ports before they exist"

Especially the first one looks 'promising'.
Can you make a patch which reverts that commit and use 'test-patches' from
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
to build a kernel and test that?

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

Bug#1033062: unblock: dhcpcd5/9.4.1-21

[Martin-Éric Racine]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dhcp...@packages.debian.org
Control: affects -1 + src:dhcpcd5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package dhcpcd5

[ Reason ]
This and the previous upload contain important documentation changes to 
facilitate migration from Stable.

[ Impact ]
Missing an important piece of information that might save them some guesswork 
when updating config files.

[ Tests ]
No code change. It's purely a debian/control and debian/NEWS change.

[ Risks ]
None. It's purely a debian/control and debian/NEWS change.

[ 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 testing

unblock dhcpcd5/9.4.1-21

[ Debdiff ]
- --- dhcpcd5-9.4.1/debian/changelog2023-02-19 15:13:44.0 +0200
+++ dhcpcd5-9.4.1/debian/changelog  2023-03-14 13:00:16.0 +0200
@@ -1,3 +1,18 @@
+dhcpcd5 (9.4.1-21) unstable; urgency=medium
+
+  * Document migration to Predictable Network Interface Names in NEWS.Debian.
+Specify Debian 12 (Bookworm) as the release where this got implemented.
+
+ -- Martin-Éric Racine   Tue, 14 Mar 2023 13:00:16 
+0200
+
+dhcpcd5 (9.4.1-20) unstable; urgency=medium
+
+  * Finalize debian/control dependencies and phrasing.
++ Specify that Linux ports utilize Predictable Network Interface Names.
+= Move Suggests on resolvconf to dhcpcd-base.
+
+ -- Martin-Éric Racine   Fri, 03 Mar 2023 09:21:00 
+0200
+
 dhcpcd5 (9.4.1-19) unstable; urgency=medium
 
   [ lintian-brush ]
diff -Nru dhcpcd5-9.4.1/debian/control dhcpcd5-9.4.1/debian/control
- --- dhcpcd5-9.4.1/debian/control  2023-02-18 07:15:24.0 +0200
+++ dhcpcd5-9.4.1/debian/control2023-03-12 09:57:19.0 +0200
@@ -11,26 +11,6 @@
 Vcs-Browser: https://salsa.debian.org/debian/dhcpcd5
 Vcs-Git: https://salsa.debian.org/debian/dhcpcd5.git
 
- -Package: dhcpcd
- -Architecture: all
- -Depends: dhcpcd-base,
- - sysvinit-utils (>= 3.05-4~) | lsb-base (>= 3.0-6),
- - ${misc:Depends},
- - ${shlibs:Depends}
- -Provides: dhcpcd
- -Replaces: dhcpcd5 (<< 9.4.1-12)
- -Breaks: dhcpcd5 (<< 9.4.1-12)
- -Suggests: dhcpcd-gtk,
- -  openresolv | resolvconf
- -Description: DHCPv4 and DHCPv6 dual-stack client (init.d script and systemd 
unit)
- - dhcpcd provides seamless IPv4 and IPv6 auto-configuration.
- - .
- - This package provides the optional init.d script and systemd units.
- - .
- - It can be safely purged on systems where interfaces are configured
- - by ifupdown via  using the DHCP method with
- - binaries provided by dhcpcd-base.
- -
 Package: dhcpcd-base
 Architecture: any
 Conflicts: dhcp-client
@@ -42,6 +22,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: wpasupplicant
+Suggests: resolvconf | openresolv | systemd-resolved
 Description: DHCPv4 and DHCPv6 dual-stack client (binaries and exit hooks)
  dhcpcd provides seamless IPv4 and IPv6 auto-configuration:
   * DHCPv4 client
@@ -58,8 +39,29 @@
  where interfaces are configured by ifupdown via 
  using the DHCP method.
  .
- - The init.d script and systemd unit required for systems without ifupdown are
- - packaged separately as dhcpcd.
+ The init.d script and systemd service required for systems without ifupdown
+ are packaged separately as dhcpcd.
+ .
+ Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface Names
+ on Linux ports. See NEWS.Debian for more details.
+
+Package: dhcpcd
+Architecture: all
+Depends: dhcpcd-base,
+ sysvinit-utils (>= 3.05-4~) | lsb-base (>= 3.0-6),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Provides: dhcpcd
+Replaces: dhcpcd5 (<< 9.4.1-12)
+Breaks: dhcpcd5 (<< 9.4.1-12)
+Suggests: dhcpcd-gtk
+Description: DHCPv4 and DHCPv6 dual-stack client (init.d script and systemd 
unit)
+ dhcpcd provides seamless IPv4 and IPv6 auto-configuration.
+ .
+ This package provides the optional init.d script and systemd service.
+ .
+ It should not be installed on systems where interfaces are configured
+ by ifupdown via  using the DHCP method.
 
 Package: dhcpcd5
 Section: oldlibs
diff -Nru dhcpcd5-9.4.1/debian/NEWS dhcpcd5-9.4.1/debian/NEWS
- --- dhcpcd5-9.4.1/debian/NEWS 1970-01-01 02:00:00.0 +0200
+++ dhcpcd5-9.4.1/debian/NEWS   2023-03-14 10:27:50.0 +0200
@@ -0,0 +1,21 @@
+dhcpcd5 (9.4.1-21) unstable; urgency=medium
+
+   Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface Names
+   on Linux ports. This brings dhcpcd in line with other networking tools.
+
+   This change is only noticeable on hosts where networking is controlled by
+   ifupdown via . For example:
+
+   Before:
+
+   iface eth0 inet dhcp
+   iface eth0 inet6 auto
+
+   After:
+
+   iface enp4s0 inet dhcp
+   iface enp4s0 inet6 auto
+
+   'sudo dmesg | grep -i renamed' shows available Predictable Interface Names.
+
+ -- 

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

[Pete Batard]

Hi,

Just going to report that I have tested media creation from the 
2023-03-13 version of debian-testing-amd64-netinst.iso, using only the 
Windows native utilities (i.e. formatting a USB drive to FAT32 using 
Windows Disk manager and mounting the ISO and copying the files using 
Windows File Explorer) and I can report that everything looks good:


1. The .deb files in /firmware/ are now being listed by File Explorer, 
and therefore copied over.

2. The installer does successfully boot and detect the installation media.

Now, I don't have a platform where any of the /firmware/ files are 
relevant, so I haven't been able to validate that part, but seeing that 
the .deb are present and successfully copied over, I don't anticipate an 
issue.


Thus, as far as I am concerned, this bug can be closed, and I would like 
to thank everyone who devoted some of their time to ensure that a fix 
was applied in a very timely manner.



On 2023.03.15 07:48, Thomas Schmitt wrote:

Besides such user pitfalls with the produced ISO and the problem of
symbolic links there are other constraints which an ISO has to fulfill
for this use case.
At least:
- The file tree of the FAT filesystem in the EFI partition needs to be
   mirrored by a copy in the ISO filesystem.


Indeed. That used to be less of an issue when Linux installation media 
used to treat the whole media as the ESP, but the move towards using 
self-contained efi.img does indeed mean that FST will only work if the 
distro maintainers do take care of duplicating the efi.img content at 
the ISO-9660 file system level (or use a utility, like grub-mkrescue, 
that will do that for them).


As far as Debian is concerned, this is not currently an issue, as Debian 
does not use an efi.img.



- File names must be unique in respect to case-insensitive comparison.


True, though I have yet to encounter any installation media where 
someone had named two file/folders in the same directory with the same 
name but different capitalization. I'm pretty sure that we can count on 
people mastering an image to avoid that, as it would be very confusing 
to have different files/folders at the same level, that differ only from 
capitalization.


So I think we can discount this as a corner case that's unlikely to be 
an issue.



- (I am not sure whether file name length can be a problem.)


From what I can see, the maximum individual file name length when using 
Joliet extensions is 128 "characters" (I'm not going to go into Unicode 
glyphs vs characters here) and 255 for Rock Ridge. The latter is also 
the maximum maximum individual file name length for FAT32 with long 
names. So, even if Debian tends to have fairly long names for some .deb 
packages, I don't anticipate much of an issue. And case sensitivity 
isn't an issue either, meaning that looking for a mixed case file name 
on FAT32 will resolve properly, even as the underlying file system is 
not exactly one that could be qualified as case sensitive.



I guess Pete Batard can give a more comprehensive list.


Well, once you eliminate the search of installation media by label 
(which Debian doesn't do), the lack of symbolic links, which is what 
we've been dealing with here, is actually the biggest limitation of 
trying to work with FAT.


Otherwise, it's really the volume labelling constraints of FAT that's 
the most problematic, because, this time, you *must* use UPPERCASE and a 
few very limited subset of non alphanum characters for FAT labels, and 
you are also limited to 11 characters, which is very very short. The end 
result of this is that, pretty much any Linux distro that does a search 
of the installation media by label, and doesn't pay attention to file 
system transposition to FAT, is likely to use a regular mixed case label 
that is also longer than 11 characters, and you must alter the 
GRUB/Syslinux kernel options in the config files is you ever want that 
media to work with FST.


Finally, to be completely comprehensive, though this is not an actually 
constraint of the FAT file system, but one of Windows, I am going to 
point out that if you are using Windows' native utilities, you won't be 
able format a partition that is larger than 64 GB to FAT32, which can 
come as an issue for users who picked a large USB Flash Drive. However, 
you can either use non native utilities to format larger partitions to 
FAT32 (since this is not a limitation of the File System, just of the 
default Windows utilities) or you can always create a partition that is 
small enough to be formatted to FAT32 and leave the rest of the media free.


Regards,

/Pete

Bug#1002747: Acknowledgement (makeparallel looks for --jobserver-fds instead of --jobserver-args)

[Sean Anderson]

On 12/28/21 14:15, Debian Bug Tracking System wrote:
> [You don't often get email from ow...@bugs.debian.org. Learn why this is 
> important at http://aka.ms/LearnAboutSenderIdentification.]
> 
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1002747: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002747.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Android Tools Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 1002...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 1002747: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002747
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Ping?

Bug#1031326: crowdsec: delays during upgrade from 1.0.9-*

[Cyril Brulebois]

Control: tag -1 patch pending

Cyril Brulebois  (2023-02-15):
> Seen during upgrade tests, starting at 1.0.9-*: there's an important
> delay (~ 1 minute) during the upgrade, with no apparent activity.

That's 1 minute and 30 seconds, which is the default TimeoutStop(U)Sec
setting.

> According to crowdsec.log, we're waiting for the existing process to
> shut down following the SIGTERM:
> 
> time="14-02-2023 22:27:53" level=info msg="Crowdsec engine shutting down"

After having checked with upstream, it appears that old versions had
troubles stopping. Trying a SIGTERM outside systemd, I'm seeing this in
the logs:

time="16-03-2023 20:25:51" level=warning msg="SIGTERM received, shutting 
down"
time="16-03-2023 20:25:51" level=info msg="Crowdsec engine shutting down"

and more than an hour later, crowdsec still hasn't stopped…

I suppose this was never noticed before because of systemd's default
timeout that ensures this doesn't block forever.

I'm told this is fixed in later versions, and that the fix wasn't
trivial; trying to get it backported to 1.0.* versions could be risky.
Therefore, I plan to mitigate the upgrade delay issue by deploying a
runtime crowdsec.service override, lowering the default timeout from
90 seconds to 20 seconds, when an upgrade from a pre-1.4.x version is
spotted: there's still plenty of time to wrap things up (even on
slow-ish systems), but that means less waiting for everyone during
upgrades…


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


signature.asc
Description: PGP signature

Bug#1033061: linux: Enable Intel In-Field Scan (IFS)

[Miguel Bernal Marin]

Source: linux
Version: 6.1.15-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the Intel In-Field Scan (IFS) driver as module.

Intel In-Field Scan is to be supported with upcoming CPUs (Xeon Saphire
Rapids) and allows for initiating circuit-level tests on a CPU core for
detecting hardware problems not caught by parity or ECC checks [1].
Future CPUs will support more than one type of test which will show up with
a new platform-device instance-id, for now only .0 is exposed [2].

As for what all of these silicon-level hardware tests that will be conducted,
that isn't entirely clear. This proposed Intel IFS kernel driver is just the
infrastructure for handling In-Field Scan while the tests themselves will be
loaded as a binary similar to the Intel CPU microcode. The Intel IFS tests will
be loaded from a file and are specific to particular CPU Family/Model/Stepping.
These files are authenticated prior to use and when loaded stored within secure
memory [3].

It was marked as BROKEN at c483e7ea10fa ("platform/x86/intel/ifs: Mark as
BROKEN") in v5.19-rc1 upstream because a suggested change to the IFS code
has shown that the userspace API needs a bit more work.

The solution finally landed at v6.2 and the BROKEN status was removed at
1a63b5808286 ("Revert "platform/x86/intel/ifs: Mark as BROKEN"") where the
issues with user interface [4] to load scan test images have been addressed.

The solutions is not a "bugfix" so the patches won't be backported to v6.1.

A MR was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/680

where the patches involved the solutions where backported and was enabled in
the Kconfig.

[1] https://www.phoronix.com/news/Intel-In-Field-Scan-IFS
[2] https://docs.kernel.org/x86/ifs.html
[3] https://www.phoronix.com/news/Intel-In-Field-Scan
[4] 
https://lore.kernel.org/lkml/26102aca-a730-ddf8-d024-2e7367696...@redhat.com/

Thanks,
Miguel

Bug#1033059: Acknowledgement (logcheck: NEWS advice how to deal with timestamps in different formats)

[Holger Levsen]

 | h01ger: thanks for the bug report, but something got mixed up there: 
rsyslog uses rfc3339, not short-iso-precise
 short-iso-precise is an output format of journalctl that is similar to 
rfc3339 but differs in the presentation of the timezone information
 *g*, thanks
 mbiebl: this is also why you said this:
 [12:51] < mbiebl> maybe you could make the existing parsing/regexps 
work with both formats
 (above)
 yes


-- 
cheers,
Holger

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

Fischers Fritz fischt Plastik.


signature.asc
Description: PGP signature

Bug#1033059: Acknowledgement (logcheck: NEWS advice how to deal with timestamps in different formats)

[Holger Levsen]

 a properly placed [:]? might be all that's need


-- 
cheers,
Holger

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

All data, over time, approaches deleted, or public. (@quinnnorton)


signature.asc
Description: PGP signature

Bug#1033042: webkit2gtk: Please disable ccache on m68k

[Alberto Garcia]

Control: tags -1 pending

On Thu, Mar 16, 2023 at 10:21:21AM +0100, John Paul Adrian Glaubitz wrote:
> On m68k, the build currently fails with ccache enabled

Thanks, applied to the 2.40.x branch:

   
https://salsa.debian.org/webkit-team/webkit/-/commit/3b82c5ced3fa8a7446899712a0caa03f7f34ec96

One of these days I think I'll probably re-evaluate how much good
ccache is doing in the recent builds.

Berto

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Cyril Brulebois]

Hello Frédéric,

Frédéric Bonnard  (2023-03-16):
> since debian-installer (20230217) uses kernel 6.1.0-5 in mini.iso, the
> kernel hangs before I have the installer menu (see attached .png) ;

(nothing attached)

> same happens with 
> https://cdimage.debian.org/cdimage/weekly-builds/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
> I tried rebuilding d-i with kernel 6.1.0-4 and it seems to work (6.1.0-6
> fails too).
> Now why am I opening this bug against d-i ? If I run the d-i with
> 6.1.0-4, I complete the installation and then runtime kernel of the
> machine that gets installed is 6.1.0-6 and when the machine is
> rebooted, kernel 6.1.0-6 boots fine ...
> So I'm not sure on which side is the issue :)
> Any clue what could be happening ?

It would be helpful to confirm which exact kernel version is getting
used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
working), then look at the changes between both versions, in src:linux
(and resulting udebs).

ISTR trying to boot ppc64el under QEMU requires many manual steps, but
I'll try and figure that out, once I'm done with other topics.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Guilhem Moulin]

Hi,

On Thu, 16 Mar 2023 at 09:13:44 +0100, Paul Gevers wrote:
> On 15-03-2023 23:28, Guilhem Moulin wrote:
>> Yes there is, namely the fact that libargon2-1 no longer links against
>> libpthread, which in turn caused a major regression in
>> cryptsetup-initramfs (mitigated in src:cryptsetup 2:2.6.1-2).  Unlike
>> what I initially claimed in #1014110's msg#20 that change can't be
>> reverted or fixed in src:argon2 since it's caused by building with a
>> newer libc; a binNMU would therefore have caused the same regression,
>
> I'm not 100% sure I parse that sentence as you intended, so let me ask
> explicitly: if we binNMU (now or in the future) src:argon2 version
> 0~20171227-0.3 in bookworm, would it also loose its linking to libpthread?
> That would be a time bomb (not only in the archive, but also for downstreams
> and other users that do rebuilds).

Yup, any rebuilt of src:argon2 in bookworm using the bookworm toolchain
would break cryptsetup-initramfs <<2:2.6.1-2.  That would include src:argon2
uploads to security-master and s-p-u.

> For the record, with my current understanding I prefer the scenario of
> keeping the versions of argon2 and cryptsetup in bookworm as they are.

With the clarification I hope you agree that src:cryptsetup ≥2:2.6.1-2
should be in bookworm :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033060: qa.debian.org: wrong username and email for my DDPO page

[Russell Coker]

Package: qa.debian.org
Severity: normal

https://qa.debian.org/developer.php?login=etbe%40debian.org
https://qa.debian.org/developer.php?login=russell%40coker.com.au

The above pages attribute my packages to Taihsiang Ho ,
apparently due to my last upload of the rasdaemon package.

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Holger Levsen]

Package: logcheck
Version: 1.4.2
Severity: wishlist

Dear Maintainer,

since bookworm rsyslog defaults to timestamps in short-iso-precise format,
while logcheck rules (and journald) still default to the old rule format,
and while the default logcheck rules in the package are easily switched,
this poses problems for larger installations with local logcheck rules
used on systems running different suites.

So I'd recommend to add some advice to logcheck/debian/NEWS based on this
conversation on #debian-devel just now:

 mbiebl: given #475303 as context, what's your advice on resolving 
this: rsyslog now uses new time format, journald uses the old format and 
logcheck rules are in the old format. does journald use the old format because 
this is bookworm upgraded and not fresh install? should i simply remove/ignore 
the timestamps in my logcheck rules? should we add some hint to the release 
notes?
- zwiebelbot- | (#debian-devel) Debian#475303: Enable support for high 
precision timestamps - https://bugs.debian.org/475303
 | h01ger: I wasn't aware that logcheck checks the journal until 2 
weeks ago someone asked about it
 https://github.com/systemd/systemd/issues/26639 was the result of this 
discussion
 yeah, its a new feature (and sensible! i want it!)
 mbiebl: issues/26639 seems sensible too. will/shall that land in 
bookworm? 
 atm, it doesn't look like
 dropping timestamps from all logcheck rules could migate this and is 
an easy way to run mixed suite setups
 though it makes me wonder why i kept those for the last 10 or so 
years, if they now suddenly are not needed ;)
 breaking habbits..
 maybe you could make the existing parsing/regexps work with both 
formats
 2023-03-16T12:45:45.159206+01:00
 vs
 2023-03-16T12:50:13.503482+0100
 you'd basically just need an optional ':'  in the timezone information
 that is rsyslog and journalctl --output=short-iso-precise
 doesnt help with systems not yet running bookworm.
 (and those are not all running bullseye either, but older releases too)
 I thought this was about fixing it in bookworm
 well, its also about using logcheck for all 'my' systems. i 
(co-)maintain several setups using logcheck...
 and i'm sure i'm not the only one who'll encounter this
 since when do both rsyslog and journalctl support 
--output=short-iso-precise ?
 #475303 is from 2008, so i assume changing rsyslog format for old 
systems could work
 rsyslog uses rfc 3339 by default since bookworm (has supported for 
10+years), journald supports short-iso-precise since I can reemember
 cool, so i'll switch to short-iso-precise everywhere at once
 systemd, just checked: since v234
 i guess this could be a NEWS entry for logcheck
 | h01ger: so you'd miss o-o-stable (v232)
 mbiebl: can i put this conversation in a wishlist bug against 
logcheck, asking to document this in NEWS?
 It was my impression that logcheck changed the regexps which match the 
timestamps in a way that both matched the old and new format?
 sure, feel free to quote this wherever you like
 mbiebl: everyone using logcheck has local rules which need to be 
changed
 hmpf, one setup has 13 machines still running stretch... 
 mbiebl: & thanks! ("feel free..")
 we do provide backports fwiw
 not sure if that is option in your case
 it is, thanks!
  systemd | 241-5~bpo9+1| stretch-backports  
 cool cool. happy this is conceptually solved now ;) i've migrated very 
few systems to bookworm yet and have been noticing those 1-2 new daily mails 
since 2 weeks or so, knowing this will need solving eventually... 
 mbiebl: thank you very much for this conversation!


-- 
cheers,
Holger

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

The pandemic isn’t over. We just stopped caring about other people.


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Package: installation-reports

Boot method: CD
Image version: http://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso

Hi!
since debian-installer (20230217) uses kernel 6.1.0-5 in mini.iso, the kernel 
hangs
before I have the installer menu (see attached .png) ; same happens with 
https://cdimage.debian.org/cdimage/weekly-builds/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
I tried rebuilding d-i with kernel 6.1.0-4 and it seems to work (6.1.0-6
fails too).
Now why am I opening this bug against d-i ? If I run the d-i with
6.1.0-4, I complete the installation and then runtime kernel of the machine that
gets installed is 6.1.0-6 and when the machine is rebooted, kernel
6.1.0-6 boots fine ...
So I'm not sure on which side is the issue :)
Any clue what could be happening ?
Thanks,

F.


signature.asc
Description: PGP signature

Bug#1032998: imagemagick: font issue since 8:6.9.10.23+dfsg-2.1+deb10u2

[Utkarsh Gupta]

Hi Bastien,

Did you look at the following bug report?


- u

On Wed, Mar 15, 2023 at 8:09 PM Maxime Besson  wrote:
>
> Package: imagemagick
> Version: 8:6.9.10.23+dfsg-2.1+deb10u2
> Severity: normal
>
> Dear Maintainer,
>
> After updating to 8:6.9.10.23+dfsg-2.1+deb10u2, libgd-securityimage-perl
> does not work anymore because of the CVE-2022-44267 and CVE-2022-44268
> mitigation:
>
> 
>
> Removing this line from /etc/ImageMagick-6/policy.xml restores correct
> hebavior.
>
> Here is a test script that tries to generate a Captcha
>
> use GD::SecurityImage use_magick => 1;
>
> my $image = GD::SecurityImage->new(
> width=> 200,
> height   => 100,
> lines=> 4,
> gd_font  => 'Giant',
> scramble => 1,
> rndmax   => 10,
> );
> $image->random;
> $image->create( 'normal', 'default', "#403030", "#FF644B");
> print $image->out( force => 'png' );
>
> The update breaks usage of fonts, and causes warnings to be printed, and
> the image to be missing any text (which is bad for a Captcha)
> , likely due to the fact that font configuration files for ImageMagick
> are in /etc
>
> -- Package-specific info:
> ImageMagick program version
> ---
>
> -- System Information:
> Debian Release: 10.13
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/6 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> -- Configuration Files:
> /etc/ImageMagick-6/policy.xml changed [not included]
>
> -- no debconf information
>

Bug#1033057: Temporary directory /var/lib/aide/dailyaidecheck has wrong owner/mode

[Yuri D'Elia]

Package: aide
Version: 0.18.1-1
Severity: normal

After updating from 0.18-2 to 0.18.1-1, dailyaidecheck doesn't start
anymore:

dailyaidecheck[102105]: terminated: Temporary directory 
/var/lib/aide/dailyaidecheck has wrong owner/mode.
systemd[1]: dailyaidecheck.service: Main process exited, code=exited, 
status=1/FAILURE

aide is running through systemd. I'm testing it by doing:

systemctl reset-failed dailyaidecheck.service
systemctl start dailyaidecheck.service

/var/lib/aide/dailyaidecheck is created by the script itself, and is
left dangling as:

drwxr-x--- 2 _aide _aide 4.0K Mar 16 13:02 dailyaidecheck/

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 aide depends on:
ii  libacl1   2.3.1-3
ii  libaudit1 1:3.0.9-1
ii  libc6 2.36-8
ii  libcap2   1:2.66-3
ii  libext2fs21.47.0-2
ii  libmhash2 0.9.9.9-9
ii  libpcre2-8-0  10.42-1
ii  libselinux1   3.4-1+b5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages aide recommends:
ii  aide-common  0.18.1-1

Versions of packages aide suggests:
pn  figlet