Bug#990560: Thanks for investigations

[Bernhard]

Hello Helge

Thanks for investigating this topic.

My very first test with i386 was in a Acer Netbook with 64GB SSD.
This failure was not shown.

If i understand it right, this failure don't happen in case, of small partition 
<1TB:
2^31*512byte=1TB.
Can you please confirm?

But this failure happens at my Banana Pi with 4TB hard drive.

So, a small partition can be a workaround until subversion/apr is compiled with 
LBA support. Correct?

Best regards and thanks for support
Bernhard

Bug#1033537: aide-common: More configurable MTA command when run as non-root

[Kamil Jonca]

Package: aide-common
Version: 0.18.1-2
Severity: wishlist
X-Debbugs-Cc: kjo...@poczta.onet.pl

Recently aide started to send mails not by sendmail command but by connecting 
to port 25 on localhost, using s-nail.
As I can see user (root) sending mail is hardcoded in 
/usr/share/aide/bin/dailyaidecheck
these changes makes filtering mails quite fragile. It would be nice to have for 
example
custom header describes that this is the mail from aide on host 
say
X-Aide: $hostname 
or sth.


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 aide-common depends on:
ii  aide   0.18.1-2
ii  debconf [debconf-2.0]  1.5.82
ii  liblockfile1   1.17-1+b1
ii  ucf3.0043+nmu1

Versions of packages aide-common recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  cron   3.0pl1-162
ii  mailutils [mailx]  1:3.15-4
ii  s-nail 14.9.24-2

aide-common suggests no packages.

-- debconf-show failed

Bug#1033397: Gnus cannot store some incoming mail into nnml

[Rob Browning]

Florian Weimer  writes:

> Please backport the commit below; it fixes the issue and is supposed
> not to break the .overview file encoded.

Thanks.  I've added the fix to the salsa repo, so it should be in the
next upload.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Unit 193]

Severity: important

Howdy

On Sun, 26 Mar 2023, Francesco Poli (wintermute) wrote:


Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable


This doesn't actually render the package unusuable, on the contrary it 
works around throttling.  Instead, it hinders compatibility with another 
package.



Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:




This actually "only" happens when you use bestvideo, other formats such as 
'22' still work.


Eg, `mpv --ytdl-format=22 https://www.youtube.com/watch?v=RZAq-_gz_W8`


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...


Not API, but yt-dlp made a change to solve widespread, severe 
throttling, to the point of being unusable really.  I saw one report that 
had it going at an average speed of 30kb/s.


mpv didn't cope well, but that has been fixed upstream in subsequent[0] 
commits[1].


[0]: 
https://github.com/mpv-player/mpv/commit/94c189dae76ba280d9883b16346c3dfb9720687e
[1]: 
https://github.com/mpv-player/mpv/commit/362256edbc4f95c63e69c1fa8c8dce9cc6c44288


Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?


It's not really a bug in yt-dlp, but instead in mpv.


Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.


And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
is a workaround for the aforementioned throttling, to revert would mean to 
make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
utilize yt-dlp with the default quality option.


If we weren't so close to the freeze I'd say the right option would be to 
simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
an option anymore either.


So to sum up, at least for things I can do:

1. Break yt-dlp integration with mpv under the default options for one 
specific (granted, highly popular) site, but usable by itself and other 
tools.


2. Revert and break the ability to use yt-dlp to watch a video without
first downloading, for all tools.

Reverting also wouldn't cover backporting new releases to bookworm 
eventually either.




Thanks for your time and patience!



Regards,

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1033536: unblock: inn2/2.7.1~20230306-1

[Marco d'Itri]

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

Please unblock package inn2

I have here a newer snapshot of the inn2 stable 2.7 branch, with various
cleanups and minor bug fixes.
I am aiming to ship in bookworm the final release, which is almost ready.
The package has been used in production on one of my own servers for 
3 weeks.

I am attaching a git diff with only the documentation changes omitted.

unblock inn2/2.7.1~20230306-1

-- 
ciao,
Marco
diff --git a/Makefile.global.in b/Makefile.global.in
index fd86cbbe0..8a185ed39 100644
--- a/Makefile.global.in
+++ b/Makefile.global.in
@@ -201,8 +201,8 @@ SHELL		= @SHELL@
 UNCOMPRESS	= @UNCOMPRESS@
 YACC		= @YACC@
 
-FIXCONFIG	= $(SHELL) $(top)/support/fixconfig
-FIXSCRIPT	= $(SHELL) $(top)/support/fixscript
+FIXCONFIG	= $(top)/support/fixconfig
+FIXSCRIPT	= $(top)/support/fixscript
 
 PERLWHOAMI	= $(PERL) -e 'print scalar getpwuid($$>), "\n"'
 WHOAMI		= (whoami || /usr/ucb/whoami || $(PERLWHOAMI)) 2> /dev/null
diff --git a/backends/Makefile b/backends/Makefile
index bd50ff218..ac71bea03 100644
--- a/backends/Makefile
+++ b/backends/Makefile
@@ -72,7 +72,7 @@ LINKDEPS	= $(LIBLDDEPS) $(LDFLAGS) -o $@
 INNLIBS		= $(LIBINN) $(LIBS)
 STORELIBS	= $(BOTH) $(STORAGE_LIBS) $(LIBS)
 
-FIX		= $(FIXSCRIPT)
+FIX		= $(SHELL) $(FIXSCRIPT)
 
 $(FIXSCRIPT):
 	@echo Run configure before running make.  See INSTALL for details.
@@ -95,15 +95,15 @@ shrinkfile:	shrinkfile.o $(LIBINN)	; $(LINK) shrinkfile.o $(INNLIBS)
 buffchan:	buffchan.o $(LIBINN)
 	$(LINK) buffchan.o $(LIBINN) $(LIBS)
 
-actmerge:	actmerge.in  $(FIX)	; $(FIX) actmerge.in
-actsyncd:	actsyncd.in  $(FIX)	; $(FIX) actsyncd.in
-mod-active:	mod-active.in$(FIX)	; $(FIX) mod-active.in
-news2mail:	news2mail.in $(FIX)	; $(FIX) news2mail.in
-nntpsend:	nntpsend.in  $(FIX)	; $(FIX) nntpsend.in
-send-ihave:	send-ihave.in$(FIX)	; $(FIX) send-ihave.in
-send-uucp:	send-uucp.in $(FIX)	; $(FIX) send-uucp.in
-sendinpaths:	sendinpaths.in   $(FIX) ; $(FIX) sendinpaths.in
-sendxbatches:	sendxbatches.in  $(FIX)	; $(FIX) sendxbatches.in
+actmerge:	actmerge.in  $(FIXSCRIPT)	; $(FIX) actmerge.in
+actsyncd:	actsyncd.in  $(FIXSCRIPT)	; $(FIX) actsyncd.in
+mod-active:	mod-active.in$(FIXSCRIPT)	; $(FIX) mod-active.in
+news2mail:	news2mail.in $(FIXSCRIPT)	; $(FIX) news2mail.in
+nntpsend:	nntpsend.in  $(FIXSCRIPT)	; $(FIX) nntpsend.in
+send-ihave:	send-ihave.in$(FIXSCRIPT)	; $(FIX) send-ihave.in
+send-uucp:	send-uucp.in $(FIXSCRIPT)	; $(FIX) send-uucp.in
+sendinpaths:	sendinpaths.in   $(FIXSCRIPT)	; $(FIX) sendinpaths.in
+sendxbatches:	sendxbatches.in  $(FIXSCRIPT)	; $(FIX) sendxbatches.in
 
 $(LIBINN):	; (cd ../lib ; $(MAKE))
 $(LIBSTORAGE):	; (cd ../storage ; $(MAKE) library)
diff --git a/configure.ac b/configure.ac
index 204ff4aac..943058de9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -362,8 +364,11 @@ dnl (available since podlators 5.00).  This options permits disabling
 dnl heuristics only intended for Perl documentation, because they prevent
 dnl some patterns like C<@@NCM> (in perl-nocem man page) from being converted
 dnl as expected.
-AS_IF([`AS_ECHO(["=head1 test"]) | pod2text --guesswork=none > /dev/null`],
-[POD2TEXT_OPTION="--guesswork=none"])
+AC_MSG_CHECKING([if pod2text supports --guesswork])
+AS_IF([`AS_ECHO(["=head1 test"]) | pod2text --guesswork=none > /dev/null 2>&1`],
+[POD2TEXT_OPTION="--guesswork=none"
+ AC_MSG_RESULT([yes])],
+[AC_MSG_RESULT([no])])
 AC_SUBST(POD2TEXT_OPTION)
 
 dnl Checks for programs.
@@ -572,6 +577,12 @@ AS_IF([test x"$inn_cv_lib_bdb_ndbm" != xyes],
  AC_SUBST([DBM_LIBS])])
 AC_SUBST([DBM_CPPFLAGS])
 
+dnl If SQLite is found, check the presence of its Perl DBI driver.
+AS_IF([test x"$inn_use_SQLITE3" = xtrue],
+[INN_PERL_CHECK_MODULE([DBD::SQLite], [],
+[inn_perl_mod_warn="$inn_perl_mod_warn DBD::SQLite"
+ inn_perl_mod_warn="$inn_perl_mod_warn (for ovsqlite-util)"])])
+
 dnl If configuring with large file support, determine the right flags to
 dnl use based on the platform.
 if test x"$inn_enable_largefiles" = xyes ; then
diff --git a/contrib/Makefile b/contrib/Makefile
index 2c8eddc89..b585a46f6 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -32,7 +32,7 @@ $(FIXSCRIPT):
 ##  Compilation rules.
 
 LINK 		= $(LIBLD) $(LDFLAGS) -o $@
-FIX		= $(FIXSCRIPT)
+FIX		= $(SHELL) $(FIXSCRIPT)
 
 STORELIBS	= $(LIBSTORAGE) $(LIBHIST) $(LIBINN) $(STORAGE_LIBS) $(LIBS)
 
@@ -44,20 +44,21 @@ pullart:	pullart.o	; $(LINK) pullart.o $(LIBINN)
 reset-cnfs:	reset-cnfs.o	; $(LINK) reset-cnfs.o
 respool:	respool.o	; $(LINK) respool.o $(STORELIBS)
 
-analyze-traffic: analyze-traffic.in $(FIX) ; $(FIX) -i analyze-traffic.in
-archivegz:   archivegz.in   $(FIX) ; $(FIX) -i archivegz.in
-authmysql:   authmysql.in   $(FIX) ; $(FIX) -i authmysql.in
-backlogstat: 

Bug#1033466: libabsl-dev: Please update ASAP

[Benjamin Barenblat]

Control: owner 1033466 !

I’ll get 20230125.1 into experimental soon.

Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

[Diederik de Haas]

On Sunday, 26 March 2023 23:58:58 CEST Ken Milmore wrote:
> The upstream fix [1] to avoid the irksome error messages has been to replace
> a call to request_firmware() from the iwlwifi driver with
> firmware_request_nowarn() instead. This causes option flag FW_OPT_NO_WARN to
> be set inside the firmware subsystem to indicate that it should not
> complain if it fails to load this particular file.
> 
> Unfortunately, Debian also applies a couple of downstream patches which
> customise the firmware loading code so as to unconditionally issue a message
> at loglevel 3 whenever a firmware file fails to load. See [2] and [3] for
> details.

It's also indicated in https://bugs.debian.org/969264#37 and I do believe that
the problem stems from that upstream introduced firmware_request_nowarn in
commit 7dcc01343e483efda0882456f8361f061a5f416d (part of 4.18-rc1),
but the Debian patch (your [2]) hasn't been updated accordingly.

The bug report is usually about iwl-debug-yolo.bin (sorry, couldn't resist),
which a not-needed (nor useful) 'debug' msg, I believe the issue is wider:

root@quartz64b:~# dmesg --level err | grep firmware
[   33.225697] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[   33.225716] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   33.225806] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[   33.297583] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[   33.323650] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[   34.940552] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[   34.941576] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)

Logged as *errors* in dmesg ... which aren't actual errors:

root@quartz64b:~# dmesg | grep "brcmfmac"
[   33.201725] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   33.202444] usbcore: registered new interface driver brcmfmac
[   33.225697] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[   33.225806] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[   33.225814] brcmfmac mmc2:0001:1: Direct firmware load for 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin failed with error -2
[   33.285263] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.bin
[   33.294308] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.txt
[   33.297583] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[   33.323650] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[   33.328250] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.clm_blob
[   33.482658] brcmfmac_wcc: brcmf_wcc_attach: executing
[   33.488864] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 
2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
root@quartz64b:~# dmesg | grep "bluetooth"
[   34.940552] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[   34.941576] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[   34.947627] bluetooth hci0: firmware: direct-loading firmware 
brcm/BCM4345C0.hcd

So they weren't errors, but more debug-level messages as it all succeeded.

I don't know if it's also an upstream kernel issue or it's only caused by
Debian's patch, but AFAICT that patch needs to be revised to (at least) account
for the upstream change(s?) in firmware loading.

The bad news is that we're in hard-freeze and the current logic is used by
debian-installer to load the (non-free-)firmware, so it seems VERY unwise
to change the logic and output wrt firmware loading NOW.

The beginning of the Trixie development cycle would be an excellent time to
address this, but this is 'above my paygrade' and I can't make claims on other
people's time.

I personally would like to see a review of all the patches to see whether
they're still needed, still the best solution to the problem, can be upstreamed
etc, but having enough people with the needed skillset and time to do things,
has been a problem for a while. Even my request for help didn't get a (public)
response: https://lists.debian.org/debian-kernel/2022/06/msg00146.html ...

Cheers,
  Diederik

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

Bug#913431: Debian Installer Bullseye RC 2 release

[Philip Hands]

Hi Vincent,

I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.

So I've changed that code, and added a couple of other tweaks, as you
can see here:

  https://salsa.debian.org/philh/partman-base/-/commits/bug/913431

Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.

BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso

HTH

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1033535: installation-guide: Remove dmraid information

[Chris Hofstaedtler]

Source: installation-guide
Version: dmraid support was removed
Severity: normal
Tags: patch

Please remove information related to dmraid from the installation-guide.
Installer support for dmraid was removed in #864423.

MR: https://salsa.debian.org/zeha/installation-guide/-/merge_requests/2

Chris

Bug#1033524: Simplify the instructions for making bootable media

[Chris Hofstaedtler]

* Steve McIntyre  [230326 23:23]:
> On Mon, Mar 27, 2023 at 12:52:41AM +0200, Chris Hofstaedtler wrote:
> >* Steve McIntyre :
> >> We should definitely also kill section 4.4.2: Loadlin is *dead* -
> >> *nobody* has DOS any more.
> >
> >Section 5.1.4. "Booting from DOS using loadlin" should also go, I
> >guess.
> 
> Yup, good call.

Trivial MR for removing loadlin sections is here:
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/27

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

Le 26/03/2023 à 18:38, Emanuele Rocca a écrit :

Hi Vincent,

On 2023-03-24 11:03, Vincent Danjean wrote:

However, I did not rebuild all the installer packages to generate a
new installer and test it in real conditions.


I haven't had the time to test your patch yet, but there's a hack I'd
like to share to test things in d-i without rebuilding anything.


Thank you very much for the tip. I see later that you can also
just go to the second console and type the "wget ..." instruction
here (before (re)starting the partitioning).
  This allows me to fix my patch: ${str:start:end} is not available
in the installer context, nor is ${str// /} to remove space.
I used 'cut' and 'tr' to do the job.

  With this updated patch, I successfully created plain (GPT)
partition in MiB and GiB (plain and fractional) and also
LVM LV in GiB (plain and fractional) with the Debian Installer
Bookworm Alpha 2 release (amd64 and i386 netinst CD images)
  The only 'bug' (but it should be present before) is that
the first partition for whose I asked a size of 128MiB gets
a size of 127MiB, probably due to the fact that the start
of the partition has been aligned to the first MiB (ie 1024kiB)

  Moreover, the tests I provide now also pass within the
installer (run the 'tests' script with the "di" argument to
avoid the script to try to run 'bc'). Both outputs (in d-i and
in a 'normal' machine) have the same md5sum (on amd64 and i386)

  So, I think I've done all what I can.

  Regards,
Vincent


diff --git a/lib/base.sh b/lib/base.sh
index d38e101e..08cfec55 100644
--- a/lib/base.sh
+++ b/lib/base.sh
@@ -313,9 +313,125 @@ longint2human () {
 	printf "%i%s%i %s\n" $int $deci $frac $suffix
 }
 
+substr() {
+	local s="$1"
+	local start="$2" # first is 0
+	local size="$3"
+
+	if [ -n "$3" ]; then
+		echo "$s" | cut -c $(($start + 1))-$(($start + $size))
+	else
+		echo "$s" | cut -c $(($start + 1))-
+	fi
+}
+
+longmult() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^30
+
+	local carry=0
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 6 ]; do
+		enda="$(substr "$a" $((${#a} - 6)))"
+		a="${a%$enda}"
+		partres="$(expr "$enda" '*' "$b" + "$carry")"
+		if [ "${#partres}" -gt 6 ]; then
+			carry="$(substr "$partres" 0 $((${#partres} - 6)))"
+			endres="${partres#$carry}$endres"
+		else
+			partres="00$partres"
+			carry=0
+			endres="$(substr "$partres" $((${#partres} - 6)))$endres"
+		fi
+	done
+	partres="$(expr "$a" '*' "$b" + "$carry")"
+	echo "$partres$endres"
+}
+
+longadd() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^60
+
+	local carry="$b"
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 15 ]; do
+		enda="$(substr "$a" $((${#a} - 15)))"
+		a="${a%$enda}"
+		partres="$(expr "$enda" + "$carry")"
+		if [ "${#partres}" -gt 15 ]; then
+			carry="$(substr "$partres" 0 $((${#partres} - 15)))"
+			endres="${partres#$carry}$endres"
+		else
+			partres="000$partres"
+			echo "${a}$(substr "$partres" $((${#partres} - 15)))$endres"
+			return
+		fi
+	done
+	partres="$(expr "$a" + "$carry")"
+	echo "$partres$endres"
+}
+
+human2longint_binary_unit() {
+	local int="$1"
+	local frac="$2"
+	local powbase="$3" # 1 <= powbase <= 6
+	# must return "$int.$frac * 1024^$powbase"
+	# contraints :
+	# - no floating point operation
+	# - no computed values above 2^63-1
+	# - expr has no exponentiation
+	# - bash arithmetics consider that 0-leading numbers are octal
+
+	# max of useful decimals when converting: powbase*10
+	# next ones, when multipled by 1024^powbase, would be <1
+	# so no need to take into account to many decimals
+	frac="$(substr "$frac" 0 $((powbase * 10 )))"
+	local longint="${int}${frac}"
+	longint="$(substr "$longint" $(expr "$longint" : '0*' || true))" # remove leading 0
+	[ "$longint" ] || {
+		echo 0
+		return
+	}
+	while [ "$powbase" -gt 3 ]; do
+		longint="$(longmult "$longint" "$((1024**3))")"
+		powbase=$(( $powbase - 3 ))
+	done
+	longint="$(longmult "$longint" "$((1024**$powbase))")"
+
+	if [ -z "$frac" ]; then
+		# no fractional part, just return the result
+		echo "$longint"
+		return
+	fi
+	# non-null fractional part.
+	# longint must be divided by 10^length(frac)
+	local posfrac="$(( ${#longint} - ${#frac} ))"
+	if [ $posfrac -le 0 ]; then
+		echo 0
+		return
+	fi
+	local res="$(substr "$longint" 0 $posfrac)"
+	# roundup if the next decimal is >= 5
+	case "$(substr "$longint" $posfrac 1)" in
+	[5-9]*) # roundup
+		longadd "$res" 1
+		;;
+	*)
+		echo "$res"
+		;;
+	esac
+}
+
 human2longint () {
-	local human orighuman gotb suffix int frac longint
-	set -- $*; human="$1$2$3$4$5" # without the spaces
+	local human orighuman gotb suffix int frac
+	local binary powbase dfrac
+	human="$(echo "$*" | tr -d ' ')" # without the spaces
 	orighuman="$human"
 	human=${human%b} #remove last b
 	human=${human%B} #remove last B
@@ -323,9 +439,18 @@ human2longint () {
 	if [ "$human" != "$orighuman" ]; then
 		gotb=1
 	fi
+	binary=${human#${human%?}} # the 

Bug#1033489: sudo lecture is missing

[Thom]

Package: sudo
Version: 1.9.13p3-1
Followup-For: Bug #1033489
X-Debbugs-Cc: thom1...@gmail.com


Hi Marc!

Thank you for the clarification.

But I can't find a reason to drop lecture after so many years.

By the way upstream made some changes in lecture text resently. [1]
For what reason? To hide this information from users?
I don't think so.

So I'm voting to show the sudo lecture "once" again.

I can't imagine the negative consequences in this case.



[1] https://github.com/sudo-project/sudo/issues/195

Bug#1033534: Thunderbird unusable on ppc64el

[Timothy Pearson]

Package: thunderbird
Version: 1:102.9.0-1~deb11u1
Severity: important

Thunderbird uses an incorrect SQLite endianness when built on a little endian 
ppc64 (ppc64el) system.  As a result, it is unable to initialize and load its 
databases, leading to a blank / unusable application.

There is some discussion upstream and potential patches at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1757271

Bug#1033524: Simplify the instructions for making bootable media

[Steve McIntyre]

On Mon, Mar 27, 2023 at 12:52:41AM +0200, Chris Hofstaedtler wrote:
>* Steve McIntyre :
>> We should definitely also kill section 4.4.2: Loadlin is *dead* -
>> *nobody* has DOS any more.
>
>Section 5.1.4. "Booting from DOS using loadlin" should also go, I
>guess.

Yup, good call.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Bug#1033524: Simplify the instructions for making bootable media

[Chris Hofstaedtler]

* Steve McIntyre :
> We should definitely also kill section 4.4.2: Loadlin is *dead* -
> *nobody* has DOS any more.

Section 5.1.4. "Booting from DOS using loadlin" should also go, I
guess.

Bug#1031963: zsnes: diff for NMU version 1.510+bz2-10.2

[Adrian Bunk]

Control: tags 1031963 + patch
Control: tags 1031963 + pending

Dear maintainer,

I've prepared an NMU for zsnes (versioned as 1.510+bz2-10.2) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru zsnes-1.510+bz2/debian/changelog zsnes-1.510+bz2/debian/changelog
--- zsnes-1.510+bz2/debian/changelog	2021-05-14 15:46:32.0 +0300
+++ zsnes-1.510+bz2/debian/changelog	2023-03-26 23:50:58.0 +0300
@@ -1,3 +1,11 @@
+zsnes (1.510+bz2-10.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with -std=gnu++14 to workaround FTBFS with gcc 11.
+(Closes: #1031963)
+
+ -- Adrian Bunk   Sun, 26 Mar 2023 23:50:58 +0300
+
 zsnes (1.510+bz2-10.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru zsnes-1.510+bz2/debian/rules zsnes-1.510+bz2/debian/rules
--- zsnes-1.510+bz2/debian/rules	2021-05-05 23:23:56.0 +0300
+++ zsnes-1.510+bz2/debian/rules	2023-03-26 23:50:58.0 +0300
@@ -13,7 +13,7 @@
 DPKG_EXPORT_BUILDFLAGS=1
 include /usr/share/dpkg/buildflags.mk
 
-CFLAGS   += $(CPPFLAGS)
+CFLAGS   += $(CPPFLAGS) -std=gnu++14
 CXXFLAGS += $(CPPFLAGS)
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -lpthread
 

Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

[Ken Milmore]

This bug still persists on Bookworm kernels despite having been "fixed"
upstream. It has been annoying me for a while, so I decided to work out exactly
what was going on.

>From the upstream discussion and elsewhere, I gather that the firmware file
"iwl-debug-yoyo.bin" is optional "TLV debug data" associated with the iwlwifi
driver. This data does not seem to have been made generally available by Intel,
nor is it required for operation, nor is it even expected to exist on a normal
production system. So the error message generated when the kernel tries to load
it is harmless, but it is going to be irksome to almost everybody with an Intel
wireless adapter.

There are a few posts floating around which suggest making the problem go away
by setting the enable_ini module parameter on the iwlwifi module. This
certainly doesn't work for me on a fairly recent AX211 adapter, which fails to
initialise completely if I try messing with enable_ini.

The upstream fix [1] to avoid the irksome error messages has been to replace
a call to request_firmware() from the iwlwifi driver with
firmware_request_nowarn() instead. This causes option flag FW_OPT_NO_WARN to be
set inside the firmware subsystem to indicate that it should not complain if it
fails to load this particular file.

Unfortunately, Debian also applies a couple of downstream patches which
customise the firmware loading code so as to unconditionally issue a message at
loglevel 3 whenever a firmware file fails to load. See [2] and [3] for details.

>From the above, it is difficult to know what the correct "fix" is here, as the
Debian approach seems to be to deliberately issue an error on firmware load
failure, whether asked to or not. If this behaviour were changed, it would
clearly affect the error reporting behaviour for all firmware in general, so it
needs thought.

One possible approach might be to downgrade the Debian-specific errors in
[2] and [3] to a lower loglevel in cases where FW_OPT_NO_WARN has been set
by the driver. This would stop them from appearing on the console during
boot. Loglevel 3 would still need to be used in cases where FW_OPT_NO_WARN
is unset (i.e. for firmware that is expected to exist).

Sadly the required option flags are not available in
fw_get_filesystem_firmware() where the error messages are currently issued,
so either the flags will need to be passed in, or the error checking will need
to be moved out into _request_firmware() where the flags are visible.

Note also there are a lot of fallbacks in _request_firmware(): to compressed
versions of firmware files, to firmware embedded on the platform etc. I'm not
clear on how many of these should be tried prior to issuing an error message.

If a decision is ever made on the preferred solution here, I'll be happy to
prepare a patch, but I assume further discussion will be needed as it affects
firmware loading in general. Hopefully these notes may have shed some light
to inform that.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c?id=3f4600de8c93917594a8b3c9ca713160ee4d563c
[2] 
https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/bugfix/all/firmware_class-log-every-success-and-failure.patch
[3] 
https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/firmware_class-refer-to-debian-wiki-firmware-page.patch

Bug#1033524: Simplify the instructions for making bootable media

[Steve McIntyre]

On Sun, Mar 26, 2023 at 11:06:56PM +0200, Holger Wansing wrote:
>
>
>Am 26. März 2023 19:48:09 MESZ schrieb Steve McIntyre :
>>If anybody *does* want to keep the rest of the text, please put it in
>>an appendix called "extra USB options that nobody needs" or similar.
>
>We could add such info to the wiki, and point there from this guide, if it's 
>wanted to keep it (somewhere).

Yes, that sounds like a good idea. :-)

>>We should definitely also kill section 4.4.2: Loadlin is *dead* -
>>*nobody* has DOS any more.
>
>Also remove it from the images as well then?

Doing it right now, in fact!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Bug#1033533: x2goserver-xsession: Xsession scripts lacks OPTIONS variable and has_option() function

[Mike Gabriel]

Package: x2goserver-xsession
Severity: important
Version: 4.1.0.3-5
Tags: patch

The /etc/x2go/Xsession script in x2goserver-xsession lacks an API  
addition of Debian's /etc/X11/Xsession script. Other consumers of the  
Xsession startup mechanism require these:


  * OPTIONS variable
  * has_option() function

The fix has already been added to upstream's x2goserver version, but  
there hasn't been a release including this patch, yet.
cf.  
https://code.x2go.org/gitweb?p=x2goserver.git;a=commit;h=1f9a68b4d1d13f80073d888586b48999316d5907


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpUn2dXk9wJL.pgp
Description: Digitale PGP-Signatur

Bug#1031646: wireshark: Confusing/conflicting advice for novice users during installation

[Bálint Réczey]

Control: tags -1 moreinfo
Control: outlook -1 0 The text is likely clear enough and is not
likely to change

Hi Nitai,

NeatNit  ezt írta (időpont: 2023. febr. 19., V, 19:45):
>
> Package: wireshark
> Version: 3.6.2-2
> Severity: minor
>
> Dear Maintainer,
>
> When installing Wireshark, the instructions for whether to enable the 
> wireshark system group are as follows:
>
> Dumpcap can be installed in a way that allows members of the "wireshark"
> system group to capture packets. This is recommended over the alternative of
> running Wireshark/Tshark directly as root, because less of the code will run
> with elevated privileges.
>
> For more detailed information please see 
> /usr/share/doc/wireshark-common/README.Debian.gz
> once the package is installed.
>
> Enabling this feature may be a security risk, so it is disabled by default.
> If in doubt, it is suggested to leave it disabled.
>
> (source: 
> https://salsa.debian.org/debian/wireshark/-/blob/debian/master/debian/po/templates.pot
>  )
>
> The first paragraph says "This is recommended over the alternative", while 
> the last says "it is suggested to leave it disabled" -- making it unclear to 
> me (a relatively novice user) which option to choose! Better instructions 
> would help immensely - for example, those taken directly from the 
> README.Debian file:
>
> [Enabling the option] is the preferred way of installation if Wireshark/Tshark
> will be used for capturing and displaying packets at the same time, since
> that way only the dumpcap process has to be run with elevated privileges
> thanks to the privilege separation.
>
> ( 
> https://salsa.debian.org/debian/wireshark/-/blob/debian/master/debian/README.Debian
>  )
>
> The above paragraph clarifies the use cases under which this option is 
> recommended to be enabled. Putting this information directly in front of the 
> user BEFORE they have to make this decision - not just in a readme that can 
> be read after the fact - will make much more sense.
>
> I am sure every intention was to make this clear to the user during 
> installation, but alas, the way it is now is not doing that :)

I may not be a good judge because I'm not a novice in this field, but
I think the instructions are very clear.
Also please note the top of
https://salsa.debian.org/debian/wireshark/-/blob/debian/master/debian/templates
:

# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.

If you have clarification proposals, please discuss those there.

I keep this bug open for a while to collect more opinion or for
possibly a follow-up from the discussion at debian-l10n-english.

> I am not sure whether this is a debian issue or an upstream issue - it's 
> clearly in the debian subdirectory, but the same directory exists upstream 
> (relocated to packaging/debian 1 year ago)
>
> https://gitlab.com/wireshark/wireshark/-/tree/master/packaging/debian

Don't worry, Debian is the right place for discussing changes to the text first.

Cheers,
Balint

> All the best,
>
> Nitai
>
>
> -- 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.15.0-60-generic (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wireshark depends on:
> ii wireshark-qt 3.6.2-2
>
> wireshark recommends no packages.
>
> wireshark suggests no packages.
>
> -- no debconf information
>

Bug#1033524: Simplify the instructions for making bootable media

[Holger Wansing]

Am 26. März 2023 19:48:09 MESZ schrieb Steve McIntyre :
>If anybody *does* want to keep the rest of the text, please put it in
>an appendix called "extra USB options that nobody needs" or similar.

We could add such info to the wiki, and point there from this guide, if it's 
wanted to keep it (somewhere).

>We should definitely also kill section 4.4.2: Loadlin is *dead* -
>*nobody* has DOS any more.

Also remove it from the images as well then?


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#942471: x2goserver: Failed to open display, using x2go - warning: error sending to systemd

[Mike Gabriel]

Dear Jannis,

On  Mi 16 Okt 2019 23:32:11 CEST, Jannis Halder wrote:


Package: x2goserver
Version: 4.1.0.3-4
Severity: important

Dear Maintainer,

After an update in the last weeks / months, it is no longer possible  
for us to use x2go.


x2go client perspective:
The x2go client connects successfully and the authentication is  
positive. But then there is a pop-up window with the message "The  
connection with the remote server was shut down. Please check the  
state of your network connection.". More does not happen here anymore.


x2goserver host perspective:
In the logs I can see a successful authentication via ssh and the  
x2goserver also starts working. x2goserver also creates data in the  
home directory. But then something does not seem to be right. No  
display could be opened. Please see the attached logs.


The rdesktop command which is executed by /usr/bin/x2goruncommand, i  
can also run myself (manually on the remote Shell with using X11  
forwarding). Then everything works and the Windows login shows up,  
for example.


Thank you in advance for all your suggestions and help.


I am currently trying to get some issues in X2Go Server in Debian  
fixed before the Debian 12 release. Is the above still an issue for  
you? Or was it a temporary flaw/situation?


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp4Frm8DWNnL.pgp
Description: Digitale PGP-Signatur

Bug#1007233: nss: FTBFS on x32 architecture

[наб]

Control: found -1 2:3.89-2

On Mon, Mar 14, 2022 at 10:28:25AM +0100, Laurent Bigonville wrote:
> Source: nss
> Version: 2:3.52-1
>
> nss currently FTBFS on x32 architecture with the following error:
> 
> A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has 
> occurred with the token or slot.
> ERROR: Unable to switch FIPS modes.

The same FTBFS affects 2:3.89-2 on the buildds:
  
https://buildd.debian.org/status/fetch.php?pkg=nss=x32=2%3A3.89-2=1679018281=0
however, on my x32 machine, I just built nss 2:3.89-2 on x32
(apt source, dpkg-buildpackage, no funny options) on current sid
with no hiccups.

Tail of log below.

Best,
наб

-- >8 --

Check File: debian/libnss3/usr/lib/x86_64-linux-gnux32/libnssdbm3.chk
Generate an HMAC key ...
Library File Size: 173560 bytes
  key: 32 bytes
ae 74 83 c2 ce 8e 82 9a e6 a3
24 0e 71 ab 72 63 97 95 e6 35
da e6 b5 fa 9a 68 87 a9 2a cb
aa 8b
  signature: 32 bytes
20 53 30 e6 ec dc 4b 80 24 be
12 70 65 66 c8 ef 16 c5 b1 6e
ac 1a be 65 9d e6 a8 61 23 ab
3b f8
# Check FIPS mode correctly works
mkdir debian/tmp
LD_LIBRARY_PATH=debian/libnss3/usr/lib/x86_64-linux-gnux32 
debian/libnss3-tools/usr/bin/modutil -create -dbdir debian/tmp
< /dev/null

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser before continuing this operation. Type
'q ' to abort, or  to continue:
LD_LIBRARY_PATH=debian/libnss3/usr/lib/x86_64-linux-gnux32 
debian/libnss3-tools/usr/bin/modutil -fips true -dbdir debian/tmp < /dev/null

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser before continuing this operation. Type
'q ' to abort, or  to continue:
FIPS mode enabled.
make[1]: Leaving directory '/tmp/nss-3.89'
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/tmp/nss-3.89'
dh_makeshlibs -a -- -c4
make[1]: Leaving directory '/tmp/nss-3.89'
   dh_shlibdeps -a
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'libnss3' in '../libnss3_3.89-2_x32.deb'.


signature.asc
Description: PGP signature

Bug#1033219: unblock: ghostscript/10.0.0~dfsg-10

[Håvard F . Aasen]

Control: tags -1 - moreinfo

On 26.03.2023 20:45, Graham Inggs wrote:
> Control: tags -1 + moreinfo
> 
> Hi Håvard
> 
> I don't see ghostscript/10.0.0~dfsg-10 in unstable, so I assume this
> is a pre-approval request.

pre-apporval, yes.

> 
> Please explain why we need this fix in bookworm, and why it can't wait
> for trixie.

The fix is for making the package cross-buildable, not sure what more
to tell you.

Regards,
Håvard

Bug#1033532: aptitude: forgets upgrade action(s) to experimental after becoming root

[Kevin Locke]

Package: aptitude
Version: 0.8.13-5
Severity: normal

Dear Maintainer,

When running aptitude 0.8.13-5 as a non-root user, if an installed
package is marked for upgrade to a version from experimental, aptitude
forgets about the action after becoming root.  To reproduce, starting
from a fresh installation of Debian testing, as root:

echo 'deb https://deb.debian.org/debian experimental main' 
>/etc/apt/sources.list.d/debian-experimental.list
apt update
apt install aptitude

Then as a non-root user:

1. Run aptitude.
2. Mark an installed package for upgrade to the version from experimental.
   (e.g. upgrade mawk 1.3.4.20200120-3.1 to 1.3.4.20230203-1~exp1)
3. Press g to start an install run.
4. Become root when prompted.

Observe that after becoming root, the package upgrade is no longer
pending and the following message appears:

> No packages are scheduled to be installed, removed or upgraded.

Instead, the upgrade action should still be pending so it can be
completed as root.

Thanks,
Kevin

Note: This issue appears similar to https://bugs.debian.org/398956
where purge actions are forgotten after becoming root.


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff085eb000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fbf327df000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fbf327a5000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fbf32773000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbf32e2f000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fbf32681000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbf32522000)
libboost_iostreams.so.1.74.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fbf3250a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fbf3220)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbf32e28000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbf31e0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbf32121000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbf324ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbf31c1f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fbf324cb000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbf324b8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fbf32489000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fbf32463000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fbf32065000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbf32436000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fbf31b5)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fbf31a09000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fbf3205)
/lib64/ld-linux-x86-64.so.2 (0x7fbf32e3a000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbf32046000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fbf3203a000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fbf319e1000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.0
ii  libboost-iostreams1.74.0  1.74.0+ds1-20
ii  libc6 2.36-8
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-14
ii  libncursesw6  6.4-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.40.1-2
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.21
ii  sensible-utils  0.0.17+nmu1

Versions of packages 

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Sounds good.

I'm happy to take on the easier dependencies, such as pkg/browser or
jellydator/ttlcache.

But the dependency on boulder is giving me a massive headache. It is really
unfortunate that they chose to use such a heavy dependency for a rather
simple task (goodkey). What are your thoughts on resolving this?

-rt

On Sun, Feb 5, 2023 at 3:30 PM Leo Antunes  wrote:

> Hi Reinhard,
>
> It seems I underestimated the work and overestimated by free time: we need
> some bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and
> maybe some patching to get rid of other deps (e.g.
> github.com/letsencrypt/boulder), if we can manage that.
> OTOH, I see you already took care of #1030555 and #1030557! That's great!
> :)
>
> Cheers
> Leo
>
>
> --- Original Message ---
> On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler <
> siret...@gmail.com> wrote:
>
>
> > seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was
> accepted. Any update on sigstore packaging?
>
>
>

-- 
regards,
Reinhard

Bug#1032984:

[Stefan Schippers]

I have closed upstream bug:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/186
since i got no feedback at all and it seems affecting only the specific
libX11 1.8.4 - fvwm2 combination that very few people use, I think.

The dirty fix for me was to switch from fvwm2 to the developing fvwm3 window 
manager.

I don't know if the window manager crash is due to a libX11 bug or to library
API misuse by fvwm2. The problem appeared after a recent libX11 update
(1.8.3 -> 1.8.4) while fvwm2 is frozen since long time.

Stefan

Bug#1033531: bdebstrap: autopkgtest regression: ubuntu-keyring not available in testing

[Paul Gevers]

Source: bdebstrap
Version: 0.5.0-1
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, one of the tests 
depends on ubuntu-keyring which was removed from testing on 2019-07-24 
and hence your test fails in testing.


[Release Team hat on] Because of the timing of this bug (during the hard 
freeze) and because it doesn't seem to indicate functionality failure of 
this package, I have marked it as bookworm-ignore. However, if done 
reasonably soon, we'll unblock an upload fixing this issue.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033464: unblock: fish/3.6.0-3

[Luna Jernberg]

Alright thanks for the info :)

On 3/26/23, M. Zhou  wrote:
> On Sun, 2023-03-26 at 20:31 +0200, Luna Jernberg wrote:
>> Not to whine but is the plan to build 3.6.1 that was released yesterday
>> aswell?
>
> It's the hard freeze stage for Debian. Introducing a massive change, such
> as the full 3.6.1 upgrade will not likely successfully make it in testing
> according
> to the freeze policy. The 3.6.1 upgrade is postponed after the upcoming
> stable release.
>
>

Bug#1029944: A couple of patches

[Jeremy Sowden]

Actually, it wasn't much more work to get all the failing tests to
pass.  Version 2 of the patches attached.

J.

From 1f6b8e55807794c2466603116ae8ba9e6a50919a Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Sun, 26 Mar 2023 14:49:09 +0100
Subject: [PATCH v2 1/2] Use ipv6 lookback address if ipv4 is not available

Note that the `bind_local` parameter of `spawn_server_addr` is now
ignored.  It wasn't actually possible to set `hn_addr`, so passing `0`
would never have worked anyway.
---
 test/common/child.c | 160 +---
 test/common/child.h |   4 ++
 test/utils.c|   5 +-
 3 files changed, 143 insertions(+), 26 deletions(-)

diff --git a/test/common/child.c b/test/common/child.c
index 872fbdaddf4f..5c480def6c44 100644
--- a/test/common/child.c
+++ b/test/common/child.c
@@ -43,6 +43,10 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include "ne_socket.h"
 #include "ne_utils.h"
 #include "ne_string.h"
@@ -50,14 +54,23 @@
 #include "tests.h"
 #include "child.h"
 
+#ifndef NI_MAXHOST
+#define NI_MAXHOST 1025
+#endif
+
 static pid_t child = 0;
 
 int clength;
 
-static struct in_addr lh_addr, hn_addr;
-
 static int have_lh_addr;
 
+static union {
+	struct sockaddr_in  in;
+	struct sockaddr_in6 in6;
+} lh_sockaddr;
+static int  lh_family = AF_UNSPEC;
+static char lh_name[NI_MAXHOST];
+
 const char *want_header = NULL;
 got_header_fn got_header = NULL;
 char *local_hostname = NULL;
@@ -72,13 +85,98 @@ char *local_hostname = NULL;
 
 int lookup_localhost(void)
 {
-/* this will break if a system is set up so that `localhost' does
- * not resolve to 127.0.0.1, but... */
-lh_addr.s_addr = inet_addr("127.0.0.1");
+struct ifaddrs *ifaddr;
+
+if (have_lh_addr)
+return OK;
+
+if (getifaddrs() == -1)
+goto err_use_ipv4;
+
+for (struct ifaddrs *ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
+if (ifa->ifa_addr == NULL)
+continue;
+
+if (strcmp(ifa->ifa_name, "lo") != 0)
+continue;
+
+if (ifa->ifa_addr->sa_family != AF_INET &&
+ifa->ifa_addr->sa_family != AF_INET6)
+continue;
+
+if (getnameinfo(ifa->ifa_addr,
+ifa->ifa_addr->sa_family == AF_INET
+? sizeof(struct sockaddr_in)
+: sizeof(struct sockaddr_in6),
+lh_name, sizeof lh_name,
+NULL, 0,
+NI_NUMERICHOST))
+continue;
+
+memcpy(_sockaddr, ifa->ifa_addr,
+   ifa->ifa_addr->sa_family == AF_INET
+   ? sizeof(lh_sockaddr.in)
+   : sizeof(lh_sockaddr.in6));
+
+lh_family = ifa->ifa_addr->sa_family;
+
+if (lh_family == AF_INET)
+break;
+}
+
+freeifaddrs(ifaddr);
+
+err_use_ipv4:
+
+if (lh_family == AF_UNSPEC) {
+lh_family = AF_INET;
+strcpy(lh_name, "127.0.0.1");
+lh_sockaddr.in.sin_family = lh_family;
+lh_sockaddr.in.sin_addr.s_addr = inet_addr(lh_name);
+}
+
 have_lh_addr = 1;
 return OK;
 }
 
+int
+get_lh_family(void)
+{
+if (!have_lh_addr)
+lookup_localhost();
+
+return lh_family;
+}
+
+const char *
+get_lh_addr(void)
+{
+if (!have_lh_addr)
+lookup_localhost();
+
+return lh_name;
+}
+
+ne_inet_addr *
+get_lh_inet_addr(void)
+{
+ne_iaddr_type type;
+unsigned char *raw;
+
+if (!have_lh_addr)
+lookup_localhost();
+
+if (lh_family == AF_INET) {
+type = ne_iaddr_ipv4;
+raw = (unsigned char *) _sockaddr.in.sin_addr.s_addr;
+} else {
+type = ne_iaddr_ipv6;
+raw = lh_sockaddr.in6.sin6_addr.s6_addr;
+}
+
+return ne_iaddr_make(type, raw);
+}
+
 int lookup_hostname(void)
 {
 char buf[BUFSIZ];
@@ -101,19 +199,26 @@ int lookup_hostname(void)
 return OK;
 }
 
-static int do_listen(struct in_addr addr, int port)
+static int do_listen(int port)
 {
-int ls = socket(AF_INET, SOCK_STREAM, 0);
-struct sockaddr_in saddr = {0};
+int ls = socket(lh_family, SOCK_STREAM, 0);
+struct sockaddr *saddr;
+socklen_t saddrlen;
 int val = 1;
 
 setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, (void *), sizeof(int));
-
-saddr.sin_addr = addr;
-saddr.sin_port = htons(port);
-saddr.sin_family = AF_INET;
 
-if (bind(ls, (struct sockaddr *), sizeof(saddr))) {
+if (lh_family == AF_INET) {
+	lh_sockaddr.in.sin_port = htons(port);
+	saddr = (struct sockaddr *) _sockaddr.in;
+	saddrlen = sizeof(lh_sockaddr.in);
+} else {
+	lh_sockaddr.in6.sin6_port = htons(port);
+	saddr = (struct sockaddr *) _sockaddr.in6;
+	saddrlen = sizeof(lh_sockaddr.in6);
+}
+
+if (bind(ls, saddr, saddrlen)) {
 	printf("bind failed: %s\n", strerror(errno));
 	return -1;
 }
@@ -171,7 +276,7 @@ static int close_socket(ne_socket *sock)
 }
 
 /* This runs as the child process. 

Bug#1033464: unblock: fish/3.6.0-3

[M. Zhou]

On Sun, 2023-03-26 at 20:31 +0200, Luna Jernberg wrote:
> Not to whine but is the plan to build 3.6.1 that was released yesterday 
> aswell?

It's the hard freeze stage for Debian. Introducing a massive change, such
as the full 3.6.1 upgrade will not likely successfully make it in testing 
according
to the freeze policy. The 3.6.1 upgrade is postponed after the upcoming stable 
release.

Bug#1033530: auto-apt-proxy: autopkgtest regression: squid-deb-proxy not available in testing

[Paul Gevers]

Source: auto-apt-proxy
Version: 14
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, one of the tests 
depends on squid-deb-proxy which was removed from testing on 2022-10-19 
and hence your test fails in testing (and it's in principle too late to 
fix squid-deb-proxy in bookworm).


[Release Team hat on] Because of the timing of this bug (during the hard 
freeze) and because it doesn't seem to indicate functionality failure of 
this package, I have marked it as bookworm-ignore. However, if done 
reasonably soon, we'll unblock an upload fixing this issue.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hi Graham,

Am Sonntag, dem 26.03.2023 um 19:28 +0200 schrieb Graham Inggs:
> Hi Markus
> 
> On Sun, 26 Mar 2023 at 16:34, Markus Koschany  wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.


> How did you determine this?

Rhino 1.7.14 was mostly API compatible meaning I only had to fix an issue in
closure-compiler. All other packages can be built from source without
modifications. I didn't find any other runtime / ABI issues so far.   

> 
> > 2. shrinksafe has no reverse-dependencies
> 
> That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies.

I used codesearch.debian.net and found only documentation or other minor
references of shrinksafe in affected packages.

https://codesearch.debian.net/search?q=shrinksafe=1

Since all Java tests in dojo pass after the rebuild and almost all of the code
in dojo is Javascript anyway, I don't see how ledgersmb and tt-rss can be
affected by the new rhino version. Wouldn't those packages depend on rhino in
some way? To me it seems rhino is only required to build shrinksafe which can
be used for compressing Javascript files. But maybe the dojo maintainers can
chime in here.


Regards,

Markus


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

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

On 25/03/23 10:17 PM, Sebastian Ramacher wrote:

> > - upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
> >   new DCO in experimental for the second review round
> > 
> > I would prefer the last option.
> 
> Let's go ahead with the last option. Please let us know once openvpn
> 2.6.1 is in unstable.

src:openvpn 2.6.1-1 is in unstable. I have cherry-picked the three most
important fixes from 2.6.2 as well (one crash, one memory-leak and one
stall due to a blocking socket)

I have also uploaded src:openvpn 2.6.2-1~exp1 and src:openvpn-dco-dkms
0.0+git20230324-1~exp1 to experimental. Those are the version I'd like
to end up in bookworm.

I have filed an internal change to get 2.6.2+dcov2 installed on our eduVPN
node next week.

Bernhard


signature.asc
Description: PGP signature

Bug#1033529: unblock: libmicrohttpd/0.9.75-6

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libmicroht...@packages.debian.org, Daniel Baumann 
, car...@debian.org
Control: affects -1 + src:libmicrohttpd

Dear release team,

Please unblock package libmicrohttpd

The new version in unstable fixes CVE-2023-27371 a denial of service
vulnerability, which got fixed targted by picking the upstream commit
for it. No other changes were applied.

As the package is a key package is needs now a manual approval for
unblock. It was already long enough in unstable, and passes the
autopkgtest runs.

unblock libmicrohttpd/0.9.75-6

Regards,
Salvatore
diff -Nru libmicrohttpd-0.9.75/debian/changelog 
libmicrohttpd-0.9.75/debian/changelog
--- libmicrohttpd-0.9.75/debian/changelog   2023-01-30 17:30:27.0 
+0100
+++ libmicrohttpd-0.9.75/debian/changelog   2023-03-03 14:51:24.0 
+0100
@@ -1,3 +1,11 @@
+libmicrohttpd (0.9.75-6) sid; urgency=high
+
+  * Uploading to sid.
+  * Adding patch from libmicrohttpd 0.9.76 to fix a parser bug that could
+be used to crash servers using the MHD_PostProcessor [CVE-2023-27371].
+
+ -- Daniel Baumann   Fri, 03 Mar 2023 
14:51:24 +0100
+
 libmicrohttpd (0.9.75-5) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru 
libmicrohttpd-0.9.75/debian/patches/debian/0001-PostProcessor-DoS.patch 
libmicrohttpd-0.9.75/debian/patches/debian/0001-PostProcessor-DoS.patch
--- libmicrohttpd-0.9.75/debian/patches/debian/0001-PostProcessor-DoS.patch 
1970-01-01 01:00:00.0 +0100
+++ libmicrohttpd-0.9.75/debian/patches/debian/0001-PostProcessor-DoS.patch 
2023-03-03 14:47:29.0 +0100
@@ -0,0 +1,22 @@
+Author: Christian Grothoff 
+Description: fix parser bug that could be used to crash servers using the 
MHD_PostProcessor
+ Fix potential DoS vector in MHD_PostProcessor discovered
+ by Gynvael Coldwind and Dejan Alvadzijevic [CVE-2023-27371].
+ .
+ While the researchers have not been able to exploit this attack vector
+ when libmicrohttpd is compiled with the standard GNU C library, it is
+ recommended that you update MHD as soon as possible if PostProcessor
+ functionality is used in your applications.
+
+diff -Naurp libmicrohttpd.orig/src/microhttpd/postprocessor.c 
libmicrohttpd/src/microhttpd/postprocessor.c
+--- libmicrohttpd.orig/src/microhttpd/postprocessor.c
 libmicrohttpd/src/microhttpd/postprocessor.c
+@@ -297,7 +297,7 @@ MHD_create_post_processor (struct MHD_Co
+   return NULL; /* failed to determine boundary */
+ boundary += MHD_STATICSTR_LEN_ ("boundary=");
+ blen = strlen (boundary);
+-if ( (blen == 0) ||
++if ( (blen < 2) ||
+  (blen * 2 + 2 > buffer_size) )
+   return NULL;  /* (will be) out of memory or invalid 
boundary */
+ if ( (boundary[0] == '"') &&
diff -Nru libmicrohttpd-0.9.75/debian/patches/series 
libmicrohttpd-0.9.75/debian/patches/series
--- libmicrohttpd-0.9.75/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libmicrohttpd-0.9.75/debian/patches/series  2023-03-03 14:47:34.0 
+0100
@@ -0,0 +1 @@
+debian/0001-PostProcessor-DoS.patch

Bug#1033528: apbs: autopkgtest regression: apbs_tester.py': [Errno 2] No such file or directory

[Paul Gevers]

Source: apbs
Version: 3.4.1-5
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression
Control: found -1 3.0.0+dfsg1-3

Dear maintainer(s),

Your package has an autopkgtest, great. However, it started to fail in 
testing (October 2022). As it started to fail in stable around the same 
time, I rather expect some external dependency, so I marked it as 
bookworm-ignore, but please investigate.


Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/a/apbs/32295202/log.gz

autopkgtest [18:11:22]: test test-apbs: [---
cp: cannot stat '/usr/share/apbs/{tests,examples}': No such file or 
directory
/tmp/autopkgtest-lxc.nft4zx67/downtmp/build.RPN/src/debian/tests/test-apbs: 
2: cd: can't cd to 
/tmp/autopkgtest-lxc.nft4zx67/downtmp/autopkgtest_tmp/tests
python3: can't open file 
'/tmp/autopkgtest-lxc.nft4zx67/downtmp/build.RPN/src/apbs_tester.py': 
[Errno 2] No such file or directory

autopkgtest [18:11:22]: test test-apbs: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033527: unblock: cairosvg/2.5.2-1.1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: cairo...@packages.debian.org, car...@debian.org
Control: affects -1 + src:cairosvg

Dear release team,

Please unblock package cairosvg

It addresses CVE-2023-27586, #1033295 for which we plan to release as
well a DSA for bullseye-security. Testing with the new version both
manually and with the ci setup for security did not show so far any
regression.

What changes is that one need to explicitly allow to allow fetching
external files to address the problem.

I would propose to unblock it and age the package a bit, but still
give it some further exposure in unstable before it will migrate to
testing.

unblock cairosvg/2.5.2-1.1

Regards,
Salvatore
diff -Nru cairosvg-2.5.2/debian/changelog cairosvg-2.5.2/debian/changelog
--- cairosvg-2.5.2/debian/changelog 2021-08-30 22:54:50.0 +0200
+++ cairosvg-2.5.2/debian/changelog 2023-03-21 22:21:22.0 +0100
@@ -1,3 +1,11 @@
+cairosvg (2.5.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't allow fetching external files unless explicitly asked for
+(CVE-2023-27586) (Closes: #1033295)
+
+ -- Salvatore Bonaccorso   Tue, 21 Mar 2023 22:21:22 +0100
+
 cairosvg (2.5.2-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru 
cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch
 
cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch
--- 
cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch
1970-01-01 01:00:00.0 +0100
+++ 
cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch
2023-03-21 22:20:00.0 +0100
@@ -0,0 +1,66 @@
+From: Guillaume Ayoub 
+Date: Fri, 10 Mar 2023 16:11:22 +0100
+Subject: =?UTF-8?q?Don=E2=80=99t=20allow=20fetching=20external=20files=20u?=
+ =?UTF-8?q?nless=20explicitly=20asked=20for?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Origin: 
https://github.com/Kozea/CairoSVG/commit/12d31c653c0254fa9d9853f66b04ea46e7397255
+Bug-Debian: https://bugs.debian.org/1033295
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-27586
+
+---
+ cairosvg/__main__.py | 4 ++--
+ cairosvg/parser.py   | 6 ++
+ cairosvg/surface.py  | 3 ++-
+ 3 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/cairosvg/__main__.py b/cairosvg/__main__.py
+index 3ff6b5d1282f..0aad3d782489 100644
+--- a/cairosvg/__main__.py
 b/cairosvg/__main__.py
+@@ -42,8 +42,8 @@ def main(argv=None, stdout=None, stdin=None):
+ help='replace every raster pixel with its complementary color')
+ parser.add_argument(
+ '-u', '--unsafe', action='store_true',
+-help='resolve XML entities and allow very large files '
+- '(WARNING: vulnerable to XXE attacks and various DoS)')
++help='fetch external files, resolve XML entities and allow very large 
'
++ 'files (WARNING: vulnerable to XXE attacks and various DoS)')
+ parser.add_argument(
+ '--output-width', default=None, type=float,
+ help='desired output width in pixels')
+diff --git a/cairosvg/parser.py b/cairosvg/parser.py
+index f0f3a82573f3..61275f0a1073 100644
+--- a/cairosvg/parser.py
 b/cairosvg/parser.py
+@@ -390,6 +390,12 @@ class Tree(Node):
+ tree = ElementTree.fromstring(
+ bytestring, forbid_entities=not unsafe,
+ forbid_external=not unsafe)
++
++# Don’t allow fetching external files unless explicitly asked for
++if 'url_fetcher' not in kwargs and not unsafe:
++self.url_fetcher = (
++lambda *args, **kwargs: b'')
++
+ self.xml_tree = tree
+ root = cssselect2.ElementWrapper.from_xml_root(tree)
+ style = parent.style if parent else css.parse_stylesheets(self, url)
+diff --git a/cairosvg/surface.py b/cairosvg/surface.py
+index c5569e768032..a2f7736aabbe 100644
+--- a/cairosvg/surface.py
 b/cairosvg/surface.py
+@@ -113,7 +113,8 @@ class Surface(object):
+ :param parent_width: The width of the parent container in pixels.
+ :param parent_height: The height of the parent container in pixels.
+ :param scale: The ouptut scaling factor.
+-:param unsafe: A boolean allowing XML entities and very large files
++:param unsafe: A boolean allowing external file access, XML entities
++   and very large files
+(WARNING: vulnerable to XXE attacks and various DoS).
+ 
+ Specifiy the output with:
+-- 
+2.39.2
+
diff -Nru cairosvg-2.5.2/debian/patches/series 
cairosvg-2.5.2/debian/patches/series
--- cairosvg-2.5.2/debian/patches/series2021-08-30 22:54:50.0 
+0200
+++ cairosvg-2.5.2/debian/patches/series2023-03-21 22:20:08.0 
+0100
@@ 

Bug#1032622: Upload with updated and completed man page translations for bookworm

[Helge Kreutzmann]

Hello Thorsten,
On Sun, Mar 26, 2023 at 07:50:34PM +0200, Thorsten Alteholz wrote:
> On 25.03.23 08:04, Helge Kreutzmann wrote:
> > 
> > > Is there anything you need from my side for this upload left?
> 
> just a bit patience ...
> I  "adopted" the package, so I am also facing the same problems with the
> magic translation handling as you ...

Apologizes. 

> > Indeed. I can then request the unblock, which I already did for other
> > packages as well.
> 
> This is #1033522, so lets see what the release team thinks about it.

Given a good rationale and following the requested bug report template
has worked quite well for me for other packages, so I hope they'll do
so here as well.

Thanks for your work!

Greetings

Helge

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


signature.asc
Description: PGP signature

Bug#1033498: installation-reports: Missing FW files not detected on USB stick

[Rainer Dorsch]

Am Sonntag, 26. März 2023, 12:23:48 CEST schrieben Sie:
> [Resent to OP, please send any reply to debian-b...@lists.debian.org]
> 
> Hello,
> 
> On 26/03/2023 at 10:52, Rainer Dorsch wrote:
> >  │ The missing firmware files are:
> >   │
> >  │ brcm/brcmfmac4330-sdio.solidrun,cubox-i-q.bin  
> >   │
> >  │ brcm/brcmfmac4330-sdio.solidrun,cubox-i-q.bin  
> >   │
> >  │ brcm/brcmfmac4330-sdio.bin brcm/brcmfmac4330-sdio.bin  
> >   │
> 
> (...)
> 
> > I copied all files from
> > 
> > https://github.com/LibreELEC/brcmfmac_sdio-firmware
> > 
> > on a USB-stick (ext3 formated, with vfat I got an error, probably the
> > filenames were not compatible). I selected  but the same box showed
> > up again and I assume no FW files were found (but it did not say so).
> 
> At that stage the installer may not support any filesystem other than
> FAT and ISO 9660. Also the current search algorithm for loose firmware
> files is very poor.
> 
> What error did you have with vfat ? I can successfully create files with
> these names on a vfat filesystem so I doubt filenames are the culprit.

Many thanks for your quick response. I looked in it in more detail:

There are many symlinks in the repo and I used Dolphin (KDE filemanager) to 
copy the data. It complained and pointed to a potential permission issue, but 
reading the error message more carefully reveals that it is not a permission 
issue, but it could not copy symlinks.

If I do a cp on bash, the files are copied as (many identical) copies, i.e. 
symlinks are not preserved.

I have not yet tested if that resolves the FW not found issue though. It would 
have helped me, if the installed would be a little bit more verbose and 
reported something like

No non-free FW files found in these directories:



Then it would have become more obvious that the installer cannot see the ext3 
formatted USB stick.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1033526: svn-load: autopkgtest fails: No module named 'pysvn'

[Paul Gevers]

Source: svn-load
Version: 1.6-1
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. (But because of the freeze, let's 
ignore this for bookworm).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/s/svn-load/32132782/log.gz

autopkgtest [23:15:28]: test command1: [---
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
:1: DeprecationWarning: invalid escape sequence '\('
ETraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
F..Adding /tmp/tmp4zf5llte/importdir/foo
Committing transaction...
Committed revision 1.
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FAdding /tmp/tmpproq1ryt/importdir/bar
Adding /tmp/tmpproq1ryt/importdir/foo
Committing transaction...
Committed revision 1.
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FAdding /tmp/tmpsusv3tkb/importdir/foo
Committing transaction...
Committed revision 1.
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
.Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FTraceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
FAdding /tmp/tmp39bht1d1/importdir/src
Adding /tmp/tmp39bht1d1/importdir/src/bang.png
Adding /tmp/tmp39bht1d1/importdir/src/bar.gif
Adding /tmp/tmp39bht1d1/importdir/src/baz.png
Adding /tmp/tmp39bht1d1/importdir/src/blast
Adding /tmp/tmp39bht1d1/importdir/src/blast/boom.jpg
Adding /tmp/tmp39bht1d1/importdir/src/foo.jpg
Adding /tmp/tmp39bht1d1/importdir/src/main.c
Committing transaction...
Committed revision 1.
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
F./tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./test.py:232: 
ResourceWarning: unclosed file <_io.TextIOWrapper 
name='/tmp/tmpqrrh042w' mode='w' encoding='UTF-8'>

  self.makeMoveMap()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Adding /tmp/tmp8zmys6ht/importdir/bar$baz
Adding /tmp/tmp8zmys6ht/importdir/foo
Committing transaction...
Committed revision 1.
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./svn-load", line 
48, in 

import pysvn
ModuleNotFoundError: No module named 'pysvn'
F/tmp/autopkgtest-lxc.mx6xh_um/downtmp/build.yiw/src/./test.py:232: 
ResourceWarning: unclosed file <_io.TextIOWrapper 
name='/tmp/tmp04uqmv75' mode='w' encoding='UTF-8'>

  self.makeMoveMap()
ResourceWarning: Enable tracemalloc to 

Bug#1033525: ITP: ruby-google-apis-serviceusage-v1 -- simple REST client for Service Usage API V1

[Ravi Dwivedi]

package: wnpp
Severity: wishlist
Owner: 'Ravi Dwivedi' 

*Package Name : ruby-google-apis-serviceusage-v1
 Version : 0.28.0
 Upstream Author : Google LLC
*URL :  https://github.com/googleapis/google-api-ruby-client
*License : Apache-2.0
*Description : simple REST client for Service Usage API V1

I am packaging ruby-google-apis-serviceusage-v1 as it is a dependency of 
gitlab.

---
Ravi Dwivedi

Bug#1033219: unblock: ghostscript/10.0.0~dfsg-10

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Håvard

I don't see ghostscript/10.0.0~dfsg-10 in unstable, so I assume this
is a pre-approval request.

Please explain why we need this fix in bookworm, and why it can't wait
for trixie.

Regards
Graham

Bug#1023876: linux-image-5.19.0-0.deb11.2-amd64: infinite loop whit RAID1 when shutting down

[Salvatore Bonaccorso]

Hi,

On Thu, Mar 23, 2023 at 10:36:21PM +0100, Salvatore Bonaccorso wrote:
> Hi Eriberto,
> 
> On Sat, Nov 19, 2022 at 11:53:59AM -0300, Eriberto wrote:
> > Em sáb., 19 de nov. de 2022 às 11:36, Salvatore Bonaccorso
> >  escreveu:
> > >
> > > Hi
> > >
> > > On Fri, Nov 11, 2022 at 06:33:23PM -0300, Joao Eriberto Mota Filho wrote:
> > > > Package: src:linux
> > > > Version: 5.19.11-1~bpo11+1
> > > > Severity: important
> > > >
> > > > Dear maintainer,
> > > >
> > > > I have a desktop with 3 polls over RAID1 (2 SSD, 2 HDD, plus 2 SSD). The
> > > > current kernel on BPO creates an infinite loop when shutting down the 
> > > > system. I
> > > > can see several messages like:
> > > >
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > md: md2 stopped.
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > md: md2 stopped.
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > md: md2 stopped.
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > [...]
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > block device autoloading is deprecated and will be removed
> > > > [...]
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > md: md2 stopped.
> > > > [...]
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > md: md2 stopped.
> > > > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > > > systemd-shutdown[1]: Stopping MD devices.
> > > > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > > > md: md2 stopped.
> > > > [...]
> > > >
> > > > There is a solution from Arch Linux[1]:
> > > >
> > > > "Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid".
> > > >
> > > > [1] https://bbs.archlinux.org/viewtopic.php?id=279383
> > > >
> > > > Please, consider disabling the deprecated BLOCK_LEGACY_AUTOLOAD, 
> > > > enabled by
> > > > default in current kernel on Debian:
> > > >
> > > > $ cat /boot/config-5.19.0-0.deb11.2-amd64 | grep BLOCK_LEGACY_AUTOLOAD
> > > > CONFIG_BLOCK_LEGACY_AUTOLOAD=y
> > > >
> > > > Thanks in advance.
> > >
> > > I'm not sure, can we can do that (yet)? Some context about this is in
> > > https://lore.kernel.org/all/yhe%2fc0k0fn9j8...@bombadil.infradead.org/
> > > . In fact back for 5.18-rc1 upstream has weakened the removal schedule
> > > for block device autoloading and with 451f0b6f4c44 ("block: default
> > > BLOCK_LEGACY_AUTOLOAD to y")[1].
> > >
> > > Initially it was planned to make it for 5.19, see fbdee71bb5d8
> > > ("block: deprecate autoloading based on dev_t")[2].
> > >
> > >  [1]: 
> > > https://git.kernel.org/linus/451f0b6f4c44d7b649ae609157b114b71f6d7875
> > >  [2]: 
> > > https://git.kernel.org/linus/fbdee71bb5d8d054e1bdb5af4c540f2cb86fe296
> > >
> > > Regards,
> > > Salvatore
> > 
> > Thanks for the clarification Salvatore. Currently, this is a nightmare
> > for me because I am being compelled to power off my computer via the
> > energy switch.
> 
> I noticed in mainline landed 6c0f5898836c ("md: select
> BLOCK_LEGACY_AUTOLOAD") in 6.3-rc3, which was as well backported to
> 6.1.21.
> 
> https://git.kernel.org/linus/6c0f5898836c05c6d850a750ed7940ba29e4e6c5
> 
> So I guess we can/need to close this bug or mark it wontfix at least
> for the time beeing.
> 
> Thoughts?

Well scratch that about closing the bug. The bug still exists, it's
just that we won't disable BLOCK_LEGACY_AUTOLOAD.

I assume you are still able to reproduce the problem with the most
current kernel available?

Regards,
Salvatore

Bug#1033464: unblock: fish/3.6.0-3

[Luna Jernberg]

Not to whine but is the plan to build 3.6.1 that was released yesterday aswell?

On 3/26/23, M. Zhou  wrote:
> Control: tags -1 - moreinfo
>
> On Sun, 2023-03-26 at 07:28 +0200, Paul Gevers wrote:
>> Control: tags -1 confirmed moreinfo
>>
>> Hi Mo,
>>
>> On 25-03-2023 15:39, M. Zhou wrote:
>> > Please unblock package fish
>> > Not yet uploaded. This package does not have a proper
>> > autopkgtest, manual unblock needed.
>>
>> Please go ahead and remove the moreinfo tag once that happened.
>
>
> It has been uploaded to unstable.
> And turned green on all release archs:
> https://buildd.debian.org/status/package.php?p=fish
>
>

Bug#1033464: unblock: fish/3.6.0-3

[M. Zhou]

Control: tags -1 - moreinfo

On Sun, 2023-03-26 at 07:28 +0200, Paul Gevers wrote:
> Control: tags -1 confirmed moreinfo
> 
> Hi Mo,
> 
> On 25-03-2023 15:39, M. Zhou wrote:
> > Please unblock package fish
> > Not yet uploaded. This package does not have a proper
> > autopkgtest, manual unblock needed.
> 
> Please go ahead and remove the moreinfo tag once that happened.


It has been uploaded to unstable.
And turned green on all release archs:
https://buildd.debian.org/status/package.php?p=fish

Bug#1011625: mercurial: autopkgtest regression on s390x

[Paul Gevers]

tags 1011625 serious
user release.debian@packages.debian.org
usertag 1011625 bookworm-can-defer
retitle 1011625 mercurial: autopkgtest regression
thanks

Hi,

On Wed, 25 May 2022 15:03:58 +0200 Graham Inggs  wrote:

Sometime between 2021-10-16 and 2021-11-25 [1], mercurial's
autopkgtests regressed on s390x in testing.


It now regressed everywhere.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020445: numba: autopkgtest regression on ppc64el: inf != 0.625

[Paul Gevers]

On Fri, 27 Jan 2023 15:35:29 +0100 Bastian Germann  wrote:

Control: fixed -1 0.56.4+dfsg-1

This seems to have gone away with the latest upload.


But numba now fails everywhere, except on amd64 if run on a very 
powerful host (most of our hosts, it times out).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032622: Upload with updated and completed man page translations for bookworm

[Thorsten Alteholz]

Hi Helge,

On 25.03.23 08:04, Helge Kreutzmann wrote:



Is there anything you need from my side for this upload left?


just a bit patience ...
I  "adopted" the package, so I am also facing the same problems with the 
magic translation handling as you ...




Indeed. I can then request the unblock, which I already did for other
packages as well.


This is #1033522, so lets see what the release team thinks about it.

  Thorsten

Bug#1033523: installation-reports: First installation

[Innocenzo Ventre]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: el.diab...@gmail.com

(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/debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 

Machine: Intel NUC 11gen Barebone i3-1115G4, Kingston 8GB DDR4 3200Mhz, Adata 
1TB XPG SX6000 M.2 NVME
Partitions: 


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:




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- 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 debianbox 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 Device [8086:9a04] 
(rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Tiger 
Lake-LP GT2 [UHD Graphics G4] [8086:9a78] (rev 01)
lspci -knn: DeviceName: Onboard - Video
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core 
Processor PCIe Controller [8086:9a09] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt 4 PCI Express Root Port #1 [8086:9a25] (rev 01)
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.2 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt 4 PCI Express Root Port #2 [8086:9a27] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring 
Accelerator module [8086:9a11] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt 4 USB Controller [8086:9a13] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt 4 NHI #0 [8086:9a1b] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Device [:]
lspci -knn: 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt 4 NHI #1 [8086:9a1d] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Device [:]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB 
3.2 Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared 
SRAM [8086:a0ef] (rev 20)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 
[8086:a0f0] (rev 20)
lspci -knn: DeviceName: Onboard - Ethernet
lspci -knn: Subsystem: Intel Corporation Device [8086:0074]
lspci -knn: Kernel driver in use: iwlwifi
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger 
Lake-LP Serial IO I2C Controller #0 [8086:a0e8] (rev 20)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: 00:15.1 Serial bus controller [0c80]: Intel Corporation Tiger 
Lake-LP Serial IO I2C Controller #1 [8086:a0e9] (rev 20)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:3002]
lspci -knn: 00:16.0 Communication 

Bug#1033524: Simplify the instructions for making bootable media

[Steve McIntyre]

Source: installation-guide
Severity: important

Almost all of section 4.3 (Preparing Files for USB Memory Stick
Booting) needs to go away. We should *not* be telling most users about
manually formatting media, copying installer files, etc.

My strong preference would be to simply remove *everything* after the
text "Simply writing the installation image to USB like this should
work fine for most users." The rest of the text here is massively
overblown for anybody except developers, and is causing confusion.

If anybody *does* want to keep the rest of the text, please put it in
an appendix called "extra USB options that nobody needs" or similar.

We should also remove mentions of the mini.iso in the "normal users"
section - it's totally not a sensible option for most people to ever
be trying to use it here.

We should definitely also kill section 4.4.2: Loadlin is *dead* -
*nobody* has DOS any more.

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

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

Bug#1033439: pre-unblock: monitoring-plugins/2.3.3-5

[Sebastian Ramacher]

Hi Jan

On 2023-03-25 16:58:12 +0100, Jan Wagner wrote:
> Hi Sebastian,
> 
> Am 25.03.23 um 10:31 schrieb Sebastian Ramacher:
> > What's the rationale to include these patches? Do they fix bugs reported
> > in the BTS or upstream?
> 
> upstream

I was hoping to get some more details on the bugs and why fixing them
warrants an unblock.

Cheers
-- 
Sebastian Ramacher

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Graham Inggs]

Hi Markus

On Sun, 26 Mar 2023 at 16:34, Markus Koschany  wrote:
> 1. There is no transition needed because only shrinksafe is affected by the 
> new
> rhino version.

How did you determine this?

> 2. shrinksafe has no reverse-dependencies

That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies.

> 4. I have rebuilt all rhino reverse-dependencies successfully.

That's great, although we do have regular test rebuilds which should
find FTBFS with the new rhino.

> 7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to
> reconsider the current autopkgtest behavior. At least there should be a 
> warning
> or a note for maintainers in the future that dojo requires a rebuild whenever
> rhino changes.

I wait to hear the opinion of the dojo maintainers, but if it does
turn out that only dojo needs a rebuild, then dojo should be uploaded,
adding a versioned dependency on librhino-java >= 1.7.14 and << 1.7.15
(or similar).  Also, Rhino will need an upload, declaring a Breaks on
shrinksafe << 1.17.2+dfsg1-3 (or similar).

Regards
Graham

Bug#1031799: cmake-data: cmake does not search multiarch paths for HIP

[Cordell Bloor]

I have been discussing this issue with the upstream developers and have 
opened a merge request with a fix [1].


On 2/22/23 15:34, Cordell Bloor wrote:

It is not possible to use CMake's HIP language support together with
the Debian package for HIP. Consider this sample project:

CMakeLists.txt:

 cmake_minimum_required(VERSION 3.22)
 project(example LANGUAGES HIP)
 add_executable(ex main.hip)


The fix for this issue will require the user to instead write their 
CMakeLists.txt as:


cmake_minimum_required(VERSION 3.22)
project(example LANGUAGES CXX HIP)
add_executable(ex main.hip)

CMake needs to load the hip-lang information that is provided by the HIP 
runtime before the HIP ABI can be determined, but CMake needs to know 
the ABI to determine which multiarch directories so search for the HIP 
runtime. Enabling C or CXX before HIP will ensure that the appropriate 
architecture is known before starting the search and a warning will be 
emitted for projects that do not enable C or CXX before HIP.


Sincerely,
Cory Bloor

[1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8356

Bug#1033406: licensecheck: scan-copyrights fails to create copyright file for texlive-extra

[Dominique Dumont]

On Fri, 24 Mar 2023 21:22:33 +0530 Vignesh Raman  
wrote:
> Only when we run scan-copyrights with all the source files, it crashes.

With texlive-extra-2022.20230122 source, scan-copyright emits some warnings but 
does not fail.

Could you try scan-copyright on your side by running this command in 
texlive-extra directory ?

$ scan-copyright > copyright.debian

Since the source is quite big (the output of license-check weights 32MB), it's 
possible that your system runs out of memory. 
Please check for kernel message.

On my system, scan-copyright uses ~130MB when scanning texlive-extra.

All the best

Bug#913431: Debian Installer Bullseye RC 2 release

[Emanuele Rocca]

Hi Vincent,

On 2023-03-24 11:03, Vincent Danjean wrote:
> However, I did not rebuild all the installer packages to generate a
> new installer and test it in real conditions.

I haven't had the time to test your patch yet, but there's a hack I'd
like to share to test things in d-i without rebuilding anything.

Create a preseed file (say preseed.cfg) with the following line:

d-i partman/early_command string wget 
https://example.org/partman-base-vincent.sh -O /lib/partman/lib/base.sh

Upload the preseed file to a webserver, say https://example.org/preseed.cfg,
and your patched base.sh to https://example.org/partman-base-vincent.sh.

When booting the installer, pass the following to the kernel command
line:

 preseed/url=https://example.org/preseed.cfg

Just in case you want to give it a try.

Bug#1033521: ITP: ruby-google-apis-container-v1beta1 -- simple REST client for Kubernetes Engine API V1beta1

[Ravi Dwivedi]

package: wnpp
Severity: wishlist
Owner: 'Ravi Dwivedi' 

*Package Name : ruby-google-apis-container-v1beta1
 Version : 0.43.0
 Upstream Author : Google LLC
*URL :  https://github.com/googleapis/google-api-ruby-client
*License : Apache-2.0
*Description : simple REST client for Kubernetes Engine API V1beta1.

I am packaging ruby-google-apis-container-v1beta1 as it is a dependency 
of gitlab 15.9.2.


---
Ravi Dwivedi

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Sunday, 26 March 2023 03:29:00 CEST Otto Kekäläinen wrote:
>  For the record, I have now patches both for 10.3 and 10.5:
> 
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/13
> 
> The upstream PR has not been accepted:
> https://github.com/mariadb-corporation/mariadb-connector-c/pull/219
> 
> Some +1 might help get these included in next uploads.

I gave your original message a +1, which I imagine is what I am supposed to do 
in GitHub's convoluted interface. I find the upstream treatment of the issue 
to be less than reassuring: to work around some other problem, they have 
decided to break something else. Then again, I personally chose to ignore and 
avoid MySQL in my own projects many years ago due to the lacklustre record of 
its maintainers.

> Currently there isn't that many people helping with MariaDB
> maintenance in Debian. If you want to contribute, please consider
> helping by:
> 
> - Fixing some other bug listed at
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=mariadb
> c=mariadb-10.6=mariadb-10.5=mariadb-10.3=mariadb-10.1 - Review
> open MRs at
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
> - Review recent commits at
> https://salsa.debian.org/mariadb-team/mariadb-server
> 
> Thanks!

I appreciate your efforts, so I thank you again for pursuing this matter. 
However, I have plenty of other demands on my time before I can even consider 
getting involved here, not least another Debian packaging effort that is 
largely stalled due to upstream inactivity and insularity, this in turn 
blocking the migration of a public Debian service to a software stack that is 
actively supported within Debian.

This whole affair is a reminder that the end-user often has limited influence 
over precise technological choices. I chose to use Kontact/KMail many years 
ago, and since that decision was made, its maintainers introduced a middleware 
layer along with a dependency on MySQL, giving users very little opportunity 
to exclude this new technology from their environment other than to migrate to 
another application entirely. I imagine that a large proportion of the 
previously happy user base did indeed migrate to something else due to 
increasing dissatisfaction that was casually disregarded by the developers.

The outcome here is a broken mail program that people can only fix by either 
downgrading packages, with potential security and stability concerns, or to 
introduce the fix that the upstream developers refuse to apply. For non-
technical users, such remedies are not readily available, and so they just end 
up with a system that no longer works for them. All because people introduce 
problematic technology and won't stick around to fix it when it breaks.

Sorry to articulate my frustration with the state of modern technology!

Paul

Bug#1029944: A couple of patches

[Jeremy Sowden]

Here are a couple of patches that seem to fix the test failures.  The
first patch updates the test-harness to use ::1 if 127.0.0.1 is not
available.  The second patch updates a few test-cases to prevent them
failing, either by changing them to work with ::1, or just skipping
them.

I've tested by running the build in a net namespace where lo doesn't
have 127.0.0.1:

  $ sudo ip netns exec ipv6test ip -4 addr show lo
  $ sudo ip netns exec ipv6test ip -6 addr show lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  $ sudo ip netns exec ipv6test sudo -u $USER fakeroot debian/rules clean binary
  [...]
  make[2]: Entering directory 
'/space/azazel/tmp/neon27/debian/build-tree/neon-openssl/test'
  [...]
  rm -rf ca ca2
  OPENSSL=/usr/bin/openssl \
   /bin/bash makekeys ../../../../test 2>makekeys.out
  gzip -c --no-name ../../../../NEWS > file1.gz
  gzip -c --name ../../../../NEWS > file2.gz
  gzip -c --no-name ../../../../NEWS > trailing.gz
  echo "hello, world" >> trailing.gz
  dd of=badcsum.gz if=file1.gz bs=1 count=`perl -e 'printf "%d", 
(stat("file1.gz"))[7] - 8;'`
  25010+0 records in
  25010+0 records out
  25010 bytes (25 kB, 24 KiB) copied, 0.0247032 s, 1.0 MB/s
  echo 'broken!' >> badcsum.gz
  dd if=file1.gz of=truncated.gz bs=2048 count=2
  2+0 records in
  2+0 records out
  4096 bytes (4.1 kB, 4.0 KiB) copied, 3.8031e-05 s, 108 MB/s
  dd of=corrupt1.gz if=file1.gz bs=1 count=500
  500+0 records in
  500+0 records out
  500 bytes copied, 0.000968376 s, 516 kB/s
  cat ../../../../NEWS >> corrupt1.gz
  cat ../../../../NEWS > corrupt2.gz
  touch empty.gz
  cat ../../../../NEWS > random.txt
  echo hello world > hello.txt
  gzip -c hello.txt > hello.gz
  echo foobar > foobar.txt
  ../../../../test/run.sh: line 5: ulimit: core file size: cannot modify limit: 
Operation not permitted
  uri-tests. 15/15 passed
  util-tests  9/ 9 passed
  string-tests.. 32/32 passed
  socket 10/47 SKIPPED - addr_connect
  socket 11/47 SKIPPED - addr_peer
  socket 36/47 SKIPPED - prebind
  socket 44/47 passed (3 skipped)
  session...  8/ 8 passed
  request... 82/92 SKIPPED - local_addr
  request... 84/92 SKIPPED - addrlist
  request... 90/92 passed (2 skipped)
  auth.. 21/21 passed
  basic. 11/11 passed
  stubs.  1/ 1 passed
  redirect..  6/ 6 passed
  socket-ssl 11/48 SKIPPED - addr_connect
  socket-ssl 12/48 SKIPPED - addr_peer
  socket-ssl 22/48 SKIPPED - ssl_session_id (zero-length session 
ID, cannot test further)
  socket-ssl 37/48 SKIPPED - prebind
  socket-ssl 44/48 passed (4 skipped)
  ssl... 62/63 WARNING: NSS required for PKCS#11 testing
  ssl... 62/63 SKIPPED - pkcs11
  ssl... 63/63 WARNING: NSS required for PKCS#11 testing
  ssl... 63/63 SKIPPED - pkcs11_dsa
  ssl... 61/63 passed (2 skipped) (2 warnings)
  compress.. 22/22 passed
  xml...  5/ 5 passed
  xmlreq  3/ 3 passed
  oldacl  4/ 4 passed
  acl3744...  4/ 4 passed
  props.  7/ 7 passed
  lock.. 16/16 passed
  make[2]: Leaving directory 
'/space/azazel/tmp/neon27/debian/build-tree/neon-openssl/test'
  [...]
  make[2]: Entering directory 
'/space/azazel/tmp/neon27/debian/build-tree/neon-gnutls/test'
  [...]
  rm -rf ca ca2
  OPENSSL=/usr/bin/openssl \
   /bin/bash makekeys ../../../../test 2>makekeys.out
  gzip -c --no-name ../../../../NEWS > file1.gz
  gzip -c --name ../../../../NEWS > file2.gz
  gzip -c --no-name ../../../../NEWS > trailing.gz
  echo "hello, world" >> trailing.gz
  dd of=badcsum.gz if=file1.gz bs=1 count=`perl -e 'printf "%d", 
(stat("file1.gz"))[7] - 8;'`
  25010+0 records in
  25010+0 records out
  25010 bytes (25 kB, 24 KiB) copied, 0.0250625 s, 998 kB/s
  echo 'broken!' >> badcsum.gz
  dd if=file1.gz of=truncated.gz bs=2048 count=2
  2+0 records in
  2+0 records out
  4096 bytes (4.1 kB, 4.0 KiB) copied, 4.0065e-05 s, 102 MB/s
  dd of=corrupt1.gz if=file1.gz bs=1 count=500
  500+0 records in
  500+0 records out
  500 bytes copied, 0.000531978 s, 940 kB/s
  cat ../../../../NEWS >> corrupt1.gz
  cat ../../../../NEWS > corrupt2.gz
  touch empty.gz
  cat ../../../../NEWS > random.txt
  echo hello world > hello.txt
  gzip -c hello.txt > hello.gz
  echo foobar > foobar.txt
  ../../../../test/run.sh: line 5: ulimit: core file size: cannot modify limit: 
Operation not permitted
  uri-tests. 15/15 passed
  util-tests  9/ 9 passed
  string-tests.. 31/32 SKIPPED - strhash_sha_512_256 (SHA-2-512/256 not 
supported)
  string-tests.. 31/32 passed (1 skipped)
  

Bug#1033520: runc: CVE-2023-27561

[Salvatore Bonaccorso]

Source: runc
Version: 1.1.4+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/opencontainers/runc/issues/3751
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for runc.

CVE-2023-27561[0]:
| runc through 1.1.4 has Incorrect Access Control leading to Escalation
| of Privileges, related to libcontainer/rootfs_linux.go. To exploit
| this, an attacker must be able to spawn two containers with custom
| volume-mount configurations, and be able to run custom images. NOTE:
| this issue exists because of a CVE-2019-19921 regression.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27561
https://www.cve.org/CVERecord?id=CVE-2023-27561
[1] https://github.com/opencontainers/runc/issues/3751

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033485: Acknowledgement (RM: mariadb-10.5/unstable -- RoM; obsoleted by mariadb (10.11))

[Otto Kekäläinen]

> Is it 10.5 or 10.6 that should be removed?  Subject says one and the body 
> says the other.

Sorry for typo, title fixed now - 10.6 was the intent.

(Technically it does not hurt if you also remove any remnants of
mariadb-10.5 as long as src:mariadb remains.)

Bug#757769: jitsi-videobridge: changing from ITP to RFP

[James Valleroy]

retitle 757769 RFP: jitsi-videobridge -- a WebRTC compatible Selective 
Forwarding Unit that allows for multiuser video communication

noowner 757769
thanks

While some progress was made on packaging dependencies [1], there is 
still significant work needed, and this effort has been stalled for a 
long time now. So it is more accurately an RFP at this point.


[1] https://wiki.debian.org/Java/RequestedPackages/Jitsi


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033519: debootstrap: Fails to bootstrap wheezy (please symlink script as 'archived', like squeeze)

[Stephan Sürken]

Package: debootstrap
Version: 1.0.128+nmu2
Severity: wishlist

Dear Maintainer,

wheezy is archived, but script (unlike, f.e. squeeze) still links to sid:

---
ls -l /usr/share/debootstrap/scripts/wheezy 
/usr/share/debootstrap/scripts/squeeze
lrwxrwxrwx 1 root root 4 Oct 19 00:49 /usr/share/debootstrap/scripts/squeeze -> 
etch
lrwxrwxrwx 1 root root 3 Oct 19 00:49 /usr/share/debootstrap/scripts/wheezy -> 
sid
---

[i.e., bootstrap w/o special parameters for mirror (archived) and key file 
(removed) will fail.]

Please symlink wheezy like squeeze.

Thx!

Stephan

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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.20-1
ii  debian-archive-keyring  2023.2
ii  gnupg   2.2.40-1

Versions of packages debootstrap suggests:
ii  binutils 2.40-2
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.4+dfsg2-5

-- no debconf information

Bug#1033518: unblock: rails/2:6.1.7.3+dfsg-1

[Lucas Nussbaum]

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

Please unblock package rails.

That version fixes a number of CVEs and #1030050.
>From the changelog:
 + This is a security-only release from a rails stable branch.
Upstream changelogs:
https://github.com/rails/rails/releases/tag/v6.1.7.1
https://github.com/rails/rails/releases/tag/v6.1.7.2
https://github.com/rails/rails/releases/tag/v6.1.7.3
Fixed CVEs: CVE-2023-22796 CVE-2023-22794 CVE-2022-44566
CVE-2023-22795 CVE-2023-22792 CVE-2023-28120 CVE-2023-23913
  + All reverse dependencies and build-dependencies have been
tested using the ruby team's tooling. No regressions were found.
After a couple retries due to random failures, ci.debian.net also
agrees.

unblock rails/2:6.1.7.3+dfsg-1

- Lucas

Bug#1030050: fixed in rails 2:6.1.7.3+dfsg-1

[Lucas Nussbaum]

Hi,

On 26/03/23 at 19:34 +0530, Pirate Praveen wrote:
> Two autopkgtest regressions are blocking the migration to testing.

Both look random:

> ruby-clockwork (arm64 only):
> 1) Failure:
> Clockwork#test_0006_should pass all arguments to every 
> [/tmp/autopkgtest-lxc.42fb1p3k/downtmp/build.WCJ/src/test/clockwork_test.rb:88]:
> Expected false to be truthy.
> 
> 69 runs, 135 assertions, 1 failures, 0 errors, 0 skips
> 
> Full log 
> https://ci.debian.net/data/autopkgtest/testing/arm64/r/ruby-clockwork/32418759/log.gz

I requested retries for both the reference and the migration test, and
now the reference fails and the migration test succeeds.

https://ci.debian.net/packages/r/ruby-clockwork/testing/arm64/

> ruby-moneta (amd64 only):

Yes, that one was failing randomly for me as well. I requested retries.
The retry for the migration test succeeded.

https://ci.debian.net/packages/r/ruby-moneta/testing/amd64/

Lucas

Bug#1028250: debian-installer: broken cryptsetup support

[Cyril Brulebois]

Hi Guilhem,

Guilhem Moulin  (2023-03-26):
> In https://bugs.debian.org/1032235#107 elbrus (CC'ed) asked for a t-p-u
> upload of cryptsetup to fix a potential major regression should
> bookworm's src:argon2 ever be rebuilt with the bookworm toolchain.  The
> version currently in sid, 2:2.6.1-3, also includes 2 upstream patches to
> mitigate #1028250.  (“Mitigate”, because it only reduces the memory cost
> of the PBKDF on memory-constrained systems without swap.  This only buys
> time, and Milan argued that such systems are better off using a
> non-memory hard PBKDF.  I might propose a partman-crypto patch to that
> effect, but I guess it's too late for bookworm at this point.)
> 
> 2:2.6.1-3 (sid) and 2:2.6.1-1 (testing) differs as such:
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/compare/debian%2F2%252.6.1-1...debian%2F2%252.6.1-3
> 
> Would you rather have us exclude these backported upstream patches from
> the t-p-u upload or should we leave them in?  Concretely these patches
> set the maximum memory cost at ~256M on a system with 1G RAM, so in
> practice the memory pressure never exceeds 75% during installation
> (tested with d-i bookworm alpha 2 with updated src:cryptsetup udebs,
> graphical install).

Sorry, I haven't been able to follow upstream/downstream discussions too
closely, but I do appreciate everything that's been happening on that
front.

I'm happy to have the patches included, and I can definitely live with
possible temporary regressions (should that happen) that might arise
from having them.

Thanks for your help, as always.


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


signature.asc
Description: PGP signature

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Francesco Poli (wintermute)]

Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:

  $ mpv https://www.youtube.com/watch?v=...
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=251=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=audio%2Fwebm=yes=2393695=146.021=1565382960171852=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIgK694JvtFcYR2CD8XvmJn6i09Q9lraFGyVhAMcpRX-UICIQCCGeSN6JZGoxj5dZMwNp-qBqRmJ11_PZLZI2eZCTLkhg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-2393695;'
 has unknown duration.
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=248=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=video%2Fwebm=yes=8861743=146.000=1565383003479714=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIhAKRzV0x6RiHkG_vxxixrOMea0A9COXLNQKnMXZMH-JjoAiBflw-hlwAKQUe_kv1e7oI91GhJbXwXdDtknxSqJXSdVg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-8861743;'
 has unknown duration.
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  No video or audio streams selected.
  
  Exiting... (Errors when loading file)

Instead, if I manually download the YouTube video:

  $ yt-dlp -o test https://www.youtube.com/watch?v=...
  [youtube] Extracting URL: https://www.youtube.com/watch?v=...
  [youtube] ...: Downloading webpage
  [youtube] ...: Downloading android player API JSON
  [info] ...: Downloading 1 format(s): 248+251
  [dashsegments] Total fragments: 1
  [download] Destination: test.f248.webm
  [download] 100% of8.45MiB in 00:00:00 at 8.71MiB/s
  [dashsegments] Total fragments: 1
  [download] Destination: test.f251.webm
  [download] 100% of2.28MiB in 00:00:00 at 6.66MiB/s
  [Merger] Merging formats into "test.webm"
  Deleting original file test.f251.webm (pass -k to keep)
  Deleting original file test.f248.webm (pass -k to keep)

I obtain a 'test.webm' file, that can later be played with mpv:

  $ mpv test.webm
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (2%) A-V:  0.000
  
  Exiting... (Quit)


If I downgrade yt-dlp to version 2023.02.17-1, everything works again:

  $ mpv https://www.youtube.com/watch?v=...
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (3%) A-V:  0.000 Cache: 141s/15MB
  
  Exiting... (Quit)


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...

Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?

Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.

Thanks for your time and patience!


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

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

Versions of packages yt-dlp depends on:
ii  python33.11.2-1
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen 

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hello,

On Sun, 26 Mar 2023 09:41:48 +0200 Graham Inggs  wrote:
[...]
> To both the rhino and dojo maintainers, please investigate so we can
> have this resolved for bookworm.

Here are my investigations:

1. There is no transition needed because only shrinksafe is affected by the new
rhino version.

2. shrinksafe has no reverse-dependencies

3. We had the exact same problem before [1]. Back then the fix was to rebuild
the package and to fix the shrinksafe tests by setting a specific Javascript
version. [2] Since just rebuilding dojo also fixes the problem, I assume that
we don't have to change this option.

4. I have rebuilt all rhino reverse-dependencies successfully.

5. I have tested yui-compressor, a similar tool, with rhino 1.7.14 and without
rebuilding the existing package and this one works as expected.

6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable. Hence
why I tightened the dependency on rhino to 1.7.14. The current version of rhino
in testing breaks the Javascript application.

7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to
reconsider the current autopkgtest behavior. At least there should be a warning
or a note for maintainers in the future that dojo requires a rebuild whenever
rhino changes.

Regards,

Markus

[1] https://bugs.debian.org/970501
[2]
https://salsa.debian.org/js-team/dojo/-/commit/68e6a048b4c4386d0495e7faf11bd46bf0516604


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

Bug#1028250: debian-installer: broken cryptsetup support

[Guilhem Moulin]

Hi kibi,

In https://bugs.debian.org/1032235#107 elbrus (CC'ed) asked for a t-p-u
upload of cryptsetup to fix a potential major regression should
bookworm's src:argon2 ever be rebuilt with the bookworm toolchain.  The
version currently in sid, 2:2.6.1-3, also includes 2 upstream patches to
mitigate #1028250.  (“Mitigate”, because it only reduces the memory cost
of the PBKDF on memory-constrained systems without swap.  This only buys
time, and Milan argued that such systems are better off using a
non-memory hard PBKDF.  I might propose a partman-crypto patch to that
effect, but I guess it's too late for bookworm at this point.)

2:2.6.1-3 (sid) and 2:2.6.1-1 (testing) differs as such:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/compare/debian%2F2%252.6.1-1...debian%2F2%252.6.1-3

Would you rather have us exclude these backported upstream patches from
the t-p-u upload or should we leave them in?  Concretely these patches
set the maximum memory cost at ~256M on a system with 1G RAM, so in
practice the memory pressure never exceeds 75% during installation
(tested with d-i bookworm alpha 2 with updated src:cryptsetup udebs,
graphical install).

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033516: twisted: autopkgtest fails: failures=21, errors=35

[Paul Gevers]

Source: twisted
Version: 22.4.0-4
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression
Control: found -1 18.9.0-3

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/t/twisted/32195474/log.gz

twisted.test.test_application.LoadingTests.test_simpleStoreAndLoad
===
[ERROR]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/test/test_tcp.py", line 
1232, in clientDisconnected

hamcrest.assert_that(
  File "/usr/lib/python3/dist-packages/hamcrest/core/assert_that.py", 
line 58, in assert_that

_assert_match(actual=actual, matcher=matcher, reason=reason)
  File "/usr/lib/python3/dist-packages/hamcrest/core/assert_that.py", 
line 73, in _assert_match

raise AssertionError(description)
builtins.AssertionError:
Expected: a sequence containing [a sequence containing ['SSL routines', 
('SSL_write' or 'ssl_write_internal'), 'protocol is shutdown']]

 but: item 0: item 1: was ''


twisted.test.test_ssl.StolenTCPTests.test_properlyCloseFiles
---
Ran 11861 tests in 1260.901s

FAILED (skips=1673, failures=21, errors=35, successes=10149)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#988948: CVE-2019-11939

[GCS]

Hi,

On Fri, Mar 17, 2023 at 7:54 PM László Böszörményi (GCS)  
wrote:
> On Thu, Mar 16, 2023 at 11:15 PM Moritz Mühlenhoff  wrote:
> > Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff:
> > > CVE-2019-11939:
> > > https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757
> > is this fixed in Bookworm?
>  I let the Security Team decide how this should be treated. I will try
> to describe it in full and short.
 Friendly ping, how the Security Team sees this issue. I've provided
insights [1] and tend to think it's safe for Bullseye and later.

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/988948#17

Bug#1033515: wit: autopkgtest regression: [[: not found

[Paul Gevers]

Source: wit
Version: 3.01a-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently (October 
2022) started to fail in testing.


Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wit/32146692/log.gz

autopkgtest [11:20:32]: test wdf-test: [---
/tmp/autopkgtest-lxc.moidampy/downtmp/build.ztX/src/debian/tests/wdf-test: 
7: [[: not found

autopkgtest [11:20:32]: test wdf-test: ---]



autopkgtest [1autopkgtest [11:20:35]: test wdf-cat-test: 
[---
/tmp/autopkgtest-lxc.moidampy/downtmp/build.ztX/src/debian/tests/wdf-cat-test: 
7: [[: not found

autopkgtest [11:20:35]: test wdf-cat-test: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033514: xchain: autopkgtest fails: xvfb-run: command not found

[Paul Gevers]

Source: xchain
Version: 1.0.1-10
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xchain/32146659/log.gz

autopkgtest [11:18:09]: test command1: [---
bash: line 1: xvfb-run: command not found
autopkgtest [11:18:09]: test command1: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033513: xsel: autopkgtest fails: Inappropriate ioctl for device

[Paul Gevers]

Source: xsel
Version: 1.2.0+git9bfc13d.20180109-3
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xsel/32227709/log.gz

autopkgtest [22:21:32]: test command1: [---
xsel: Can't open display: (null)
: Inappropriate ioctl for device
autopkgtest [22:21:32]: test command1: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033512: zc.buildout: autopkgtest fails: cannot open /usr/share/python3-zope.testing/test_helper

[Paul Gevers]

Source: zc.buildout
Version: 2.13.2-4
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zc.buildout/32140722/log.gz

autopkgtest [06:23:21]: test all: [---
/tmp/autopkgtest-lxc.4d5588j5/downtmp/build.MKN/src/debian/tests/all: 2: 
.: cannot open /usr/share/python3-zope.testing/test_helper: No such file

autopkgtest [06:23:22]: test all: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033511: release-notes: mention the switch from old polkit .pkla files to JavaScript .rules

[Simon McVittie]

Package: release-notes
Severity: normal
Control: affects -1 src:policykit-1
X-Debbugs-Cc: policyki...@packages.debian.org

I think the transition mentioned in /usr/share/doc/polkitd/NEWS.Debian.gz
deserves to be included in the bookworm release notes. I attach some
possible wording. I'm not entirely sure which section this should go
in, so the location suggested below is only a guess: please move it
as necessary.

Note that I've included a link to the bookworm polkit(8) man page, but
the version displayed on manpages.debian.org is currently wrong (it
seems to be a cached version of the man page as it appeared in bullseye).
I've reported a separate bug. If the manpages.d.o bug is not fixed by
the time this is ready for merge, then a workaround would be to link
to the unstable version of polkit(8), which has the correct content.

smcv

diff --git a/en/issues.dbk b/en/issues.dbk
index 4b7b9dda..38e79ce9 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -55,6 +55,54 @@
 
 
 
+
+  
+  polkit .pkla files deprecated
+  
+polkit (formerly PolicyKit) has been upgraded from version 0.105 to
+version 122.
+This version changes the syntax used for local policy rules:
+it is now the same JavaScript-based format used by the upstream polkit
+project and by other Linux distributions.
+  
+  
+System administrators can override the default security policy by
+installing local policy overrides into
+/etc/polkit-1/rules.d/*.rules,
+which can either make the policy more restrictive or more
+permissive.
+Some sample policy rules can be found in the
+/usr/share/doc/polkitd/examples directory.
+Please see the polkit(8)
+  manual page for more details.
+  
+  
+Older Debian releases used the "local authority" rules format from
+upstream version 0.105, consisting of .pkla
+files with a .desktop-like syntax,
+installed into subdirectories of
+/etc/polkit-1/localauthority
+or /var/lib/polkit-1/localauthority.
+The polkitd-pkla package
+provides compatibility with these files, and will usually be
+installed during upgrades.
+If it is installed, then .pkla files will be
+processed at a higher priority than most .rules
+files.
+If the polkitd-pkla
+package is removed, .pkla files will no longer
+be used.
+  
+  
+The .pkla files should be considered deprecated,
+and polkitd-pkla is likely
+to be removed in a future Debian release.
+Please migrate any local policy overrides to the JavaScript format
+after upgrading.
+  
+
+
 
   
   Puppet configuration management system upgraded to 7

Bug#1033510: vim-ultisnips: flaky autopkgtest: Invalid multiword trigger

[Paul Gevers]

Source: vim-ultisnips
Version: 3.2-2
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/v/vim-ultisnips/32171934/log.gz

==
FAIL: runTest 
(test_ParseSnippets.ParseSnippets_MultiWord_UnmatchedContainer.runTest)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.yoo62zj7/downtmp/build.SFF/src/test/vim_test_case.py", 
line 67, in runTest

self.assertRegex(self.output, self.expected_error)
AssertionError: Regex didn't match: "Invalid multiword trigger: '!inv 
snip/' in \\S+:2" not found in 'An error occured. This is either a bug 
in UltiSnips or a bug in a\nsnippet definition. If you think this is a 
bug, please report it 
to\nhttps://github.com/SirVer/ultisnips/issues/new\nPlease read and 
follow:\nhttps://github.com/SirVer/ultisnips/blob/master/CONTRIBUTING.md#reproducing-bugs\n\nFollowing 
is the full stack trace:\nTraceback (most recent call last):\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/err_to_scratch_buffer.py", 
line 18, in wrapper\nreturn func(self, *args, **kwds)\n 
^\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", 
line 905, in _track_change\n 
self._try_expand(autotrigger_only=True)\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", 
line 749, in _try_expand\nsnippets = self._snips(before, False, 
autotrigger_only)\n 
\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", 
line 629, in _snips\nsource.ensure(filetypes)\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", 
line 31, in ensure\nself._load_snippets_for(ft)\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", 
line 53, in _load_snippets_for\nself._parse_snippets(ft, fn)\n  File 
"/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", 
line 69, in _parse_snippets\nraise SnippetSyntaxError(filename, 
line_index, msg)\nUltiSnips.snippet.source.file.base.SnippetSyntaxError: 
Invalid multiword trigger: \'!inv snip/\' in 
/nip\tp/autopkgtest-lxc.yoo62zj7/downtmp/autopkgtest_tmp/UltiSnipsTest_Casemj4yxyks/us/all.snippets:2'


--


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033155: gnupg2: diff for NMU version 2.2.40-1.1

[Andreas Metzler]

Control: tags 1033155 + pending

Dear maintainer,

I've prepared an NMU for gnupg2 (versioned as 2.2.40-1.1) and
uploaded it non-delayed.

Kind regards
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'
diff -Nru gnupg2-2.2.40/debian/changelog gnupg2-2.2.40/debian/changelog
--- gnupg2-2.2.40/debian/changelog	2022-10-19 17:09:42.0 +0200
+++ gnupg2-2.2.40/debian/changelog	2023-03-26 15:03:05.0 +0200
@@ -1,3 +1,11 @@
+gnupg2 (2.2.40-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * In migration CI test skip debian-archive-bookworm-stable.gpg (and
+aggregated keyring), gpg1 cannot read the ed25519 key. Closes: #1033155
+
+ -- Andreas Metzler   Sun, 26 Mar 2023 15:03:05 +0200
+
 gnupg2 (2.2.40-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru gnupg2-2.2.40/debian/tests/migration gnupg2-2.2.40/debian/tests/migration
--- gnupg2-2.2.40/debian/tests/migration	2022-09-02 00:08:12.0 +0200
+++ gnupg2-2.2.40/debian/tests/migration	2023-03-26 15:03:05.0 +0200
@@ -11,7 +11,9 @@
 mkdir "$GPG_HOME"
 chmod 700 "$GPG_HOME"
 
-cat /usr/share/keyrings/debian-archive-*.gpg | "${gpg1[@]}" --import
+cat $(ls /usr/share/keyrings/debian-archive-*.gpg \
+	| grep -vE 'debian-archive-bookworm-stable.gpg|debian-archive-keyring.gpg') \
+	| "${gpg1[@]}" --import
 "${gpg1[@]}" --list-keys
 "${gpg[@]}" --list-keys > "$DIR/key.list.before"
 migrate-pubring-from-classic-gpg "$GPG_HOME"


signature.asc
Description: PGP signature

Bug#1033509: manpages.debian.org: testing/polkitd/polkit.8.en.html has outdated content

[Simon McVittie]

Package: manpages.debian.org
Severity: important

This might well have the same root cause as #986030, but I'm reporting it
as a separate bug because I want to link to bookworm's polkit(8) in text
that I'm contributing to the bookworm release notes, and the HTML currently
displayed for that version is misleading.

To reproduce:
0. Precondition: src:policykit-1 has the following polkit(8) man pages:
   - bullseye, 0.105-31+deb11u1: an old version dated January 2009
   - bookworm, 122-3: a new version dated February 2021
   - unstable, 122-3: identical to bookworm
1. Visit https://manpages.debian.org/bullseye/policykit-1/polkit.8.en.html
2. and https://manpages.debian.org/testing/polkitd/polkit.8.en.html
3. and https://manpages.debian.org/unstable/polkitd/polkit.8.en.html

Expected result:
1. bullseye man page is the old version dated January 2009, which mentions
   pklocalauthority(8)
2. bookworm man page is the new version dated February 2021, which no
   longer mentions pklocalauthority(8), but does mention JavaScript, and
   has an AUTHORIZATION RULES section
3. unstable man page is also the new version dated February 2021

Actual result:
1. As expected. The "other versions" sidebar and the footer say that it is
   from polkitd_0.105-31+deb11u1.
2. The sidebar and footer claim that the man page is from polkitd_122-2
   (even though unstable is now at 122-3), but the HTML content is the
   old 2009 version (same as bullseye).
   - The text content of 
https://manpages.debian.org/testing/polkitd/polkit.8.en.gz
 *is* the correct 2021 version, though. Perhaps the generated HTML was
 cached and needs some cache invalidation to be regenerated?
3. As expected. The unstable man page has the correct February 2021 content.

Bug#1033508: refstack-client: autopkgtest regression: Invalid version: '0.0.0.02021.08.18.fa73ef2524'

[Paul Gevers]

Source: refstack-client
Version: 0.0.0~2021.08.18.fa73ef2524-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently (around 
beginning of February 2023) started to fail in testing.


Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/refstack-client/32427783/log.gz

Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.zvo2tfw5/downtmp/build.pFl/src/setup.py", 
line 27, in 

setuptools.setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
108, in setup

return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 185, in setup

return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 201, in run_commands

dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 969, in run_commands

self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File "/usr/lib/python3/dist-packages/pbr/packaging.py", line 243, in run
return du_install.install.run(self)
   
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py", 
line 698, in run

self.run_command('build')
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 318, in run_command

self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 132, in run

self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 318, in run_command

self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 63, in run

self.build_package_data()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 159, in build_package_data

for target, srcfile in self._get_package_data_output_mapping():
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 151, in _get_package_data_output_mapping

for package, src_dir, build_dir, filenames in self.data_files:
  ^^^
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 72, in __getattr__

self.data_files = self._get_data_files()
  ^^
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 84, in _get_data_files

self.analyze_manifest()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", 
line 181, in analyze_manifest

self.run_command('egg_info')
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 318, in run_command

self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 987, in run_command

cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 111, in ensure_finalized

self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", 
line 219, in finalize_options

parsed_version = parse_version(self.egg_version)
 ^^^
  File 
"/usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py", 
line 266, in __init__

raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'0.0.0.02021.08.18.fa73ef2524'


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033155: migration test fails when EC key present in test keyrings

[Andreas Metzler]

On 2023-03-26 Andreas Metzler  wrote:
> On 2023-03-18 Jonathan Wiltshire  wrote:
[...]
> > The stable release key for bookworm is EC, and this causes gpg1 to bail
> > out when it is imported as part of the migration test. Attached patch
> > limits the keyrings used to the archive's automatic keys, which are
> > still RSA.
> [...]


> afaict currently all keys are RSA except for
> debian-archive-bookworm-stable.gpg. Wouldn't it be better to just skip
> this single key?

Hello,

I am going to fix this by NMU. (non-delayed, Daniel is on the
LowThresholdNmu list.)

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'


signature.asc
Description: PGP signature

Bug#1033507: webext-form-history-control: Built-Using jquery which has been removed otherwise in 2020

[Paul Gevers]

Package: webext-form-history-control
Version: 2.5.1.0-1
Severity: important

Dear maintainer,

Your package copies in pieces from other source packages during build
and documents that in the Built-Using field. I haven't checked if
that's actually correct (according to Debian Policy, i.e. *required*
by their licenses [1]), but it's at least causing the issue that we
can't get rid of src:jquery in unstable and bookworm right now. jquery
was removed in 2020, but its source is being kept around for
webext-form-history-control.

webext-form-history-control is arch:all so it can't be
binNMU'd. Please check if you're using the Built-Using according to
policy [1], and if so please rebuild your binary by reuploading. If
you "abuse" Built-Using, then please fix your source package.

I also note that the code duplication isn't registered in the security
embedded-code-copies file [2]. I recommend you keep that file up to
date with code embedded in your binaries.

Paul

[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
[2] 
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies

Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10

[Markus Koschany]

Am Sonntag, dem 26.03.2023 um 12:15 +0300 schrieb Timo Aaltonen:
> Markus Koschany kirjoitti 24.3.2023 klo 15.35:
> > Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen:
> > > Markus Koschany kirjoitti 23.3.2023 klo 19.00:
> > > > Control: severity -1 serious
> > > > 
> > > > On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen 
> > > > wrote:
> > > >    
> > > > > Upstream doesn't support tomcat10 yet, and tomcatjss fails to build
> > > > > with
> > > > > it.
> > > > 
> > > > Unfortunately we can only support one Tomcat version per release. We
> > > > should
> > > > either migrate to tomcat10 or maybe it is possible to embed some of the
> > > > required tomcat9 classes in your source package as a workaround
> > > > provided
> > > > the
> > > > changes are rather small and the security impact is negligible.
> > > 
> > > Right, but that's for bookworm+1? By that time I'm sure
> > > jss/tomcatjss/dogtag have gained upstream support for tomcat10.
> > 
> > We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in
> > Buster
> > and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat
> > 9
> > was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm.
> > resteasy3.0
> > and tomcatjss are the only packages apart from i2p that still depend on
> > libtomcat9-java.
> 
> Nice, so you expect them to migrate after bookworm is already frozen?

Targeted fixes are still allowed. Including required tomcat9 classes in your
package may be a solution too. If you can find an agreement with the security
and release team, then even shipping libtomcat9-java might be possible. But
then your packages will not receive any security support. 


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

Bug#1033506: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u6

[Rene Engelhard]

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

Hi,

This fixes "CVE-2022-38745. Empty entry in Java class path risks
arbitrary code execution" just disclosed by Apache OpenOffice.

libreoffice 7.0.4 in bullseye (and buster, but that is EOL) also is affected.

The security team thinks this doesn't warrant a DSA and should be done
here.

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

[ Changes ]
https://cgit.freedesktop.org/libreoffice/core/commit/?id=5e8f64e50f97d39e83a3358697be14db03566878
(which is fixed in  7.2.6 and 7.3.1) backported.

Debdiff:

diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog  2022-11-27 19:37:58.0 +0100
+++ libreoffice-7.0.4/debian/changelog  2023-03-25 14:04:55.0 +0100
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u6) bullseye; urgency=medium
+
+  * debian/patches/avoid-empty-java.class.path.diff: apply upstream patch
+avoiding empty -Djava.class.path= (CVE-2022-38745)
+
+ -- Rene Engelhard   Sat, 25 Mar 2023 14:04:55 +0100
+
 libreoffice (1:7.0.4-4+deb11u5) bullseye; urgency=medium

   * debian/patches/hrk-euro-default.diff: default to EUR for .hr
diff -Nru libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff 
libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
--- libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff   
1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff   
2023-03-25 14:04:55.0 +0100
@@ -0,0 +1,90 @@
+From 5e8f64e50f97d39e83a3358697be14db03566878 Mon Sep 17 00:00:00 2001
+From: Stephan Bergmann 
+Date: Mon, 21 Feb 2022 11:55:21 +0100
+Subject: Avoid unnecessary empty -Djava.class.path=
+
+Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242
+Tested-by: Jenkins
+Reviewed-by: Stephan Bergmann 
+---
+ jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx | 16 +---
+ jvmfwk/source/framework.cxx |  8 ++--
+ jvmfwk/source/fwkbase.cxx   |  3 +++
+ 3 files changed, 22 insertions(+), 5 deletions(-)
+
+diff --git a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx 
b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+index 29de226211f1..e55b914edf13 100644
+--- a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
 b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+@@ -712,17 +712,22 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ // all versions below 1.5.1
+ options.emplace_back("abort", reinterpret_cast(abort_handler));
+ bool hasStackSize = false;
++#ifdef UNX
++// Until java 1.5 we need to put a plugin.jar or javaplugin.jar (<1.4.2)
++// in the class path in order to have applet support:
++OString sAddPath = getPluginJarPath(pInfo->sVendor, 
pInfo->sLocation,pInfo->sVersion);
++#endif
+ for (int i = 0; i < cOptions; i++)
+ {
+ OString opt(arOptions[i].optionString);
+ #ifdef UNX
+-// Until java 1.5 we need to put a plugin.jar or javaplugin.jar 
(<1.4.2)
+-// in the class path in order to have applet support:
+ if (opt.startsWith("-Djava.class.path="))
+ {
+-OString sAddPath = getPluginJarPath(pInfo->sVendor, 
pInfo->sLocation,pInfo->sVersion);
+ if (!sAddPath.isEmpty())
++{
+ opt += OStringChar(SAL_PATHSEPARATOR) + sAddPath;
++sAddPath.clear();
++}
+ }
+ #endif
+ if (opt == "-Xint") {
+@@ -767,6 +772,11 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ }
+ #endif
+ }
++#ifdef UNX
++if (!sAddPath.isEmpty()) {
++options.emplace_back("-Djava.class.path=" + sAddPath, nullptr);
++}
++#endif
+
+ std::unique_ptr sarOptions(new 
JavaVMOption[options.size()]);
+ for (std::vector::size_type i = 0; i != options.size(); ++i) {
+diff --git a/jvmfwk/source/framework.cxx b/jvmfwk/source/framework.cxx
+index 4163eea57b7c..8aa85082b838 100644
+--- a/jvmfwk/source/framework.cxx
 b/jvmfwk/source/framework.cxx
+@@ -195,8 +195,12 @@ javaFrameworkError jfw_startVM(
+ //In direct mode the options are specified by bootstrap 
variables
+ //of the form UNO_JAVA_JFW_PARAMETER_1 .. 
UNO_JAVA_JFW_PARAMETER_n
+ vmParams = jfw::BootParams::getVMParameters();
+-sUserClassPath =
+-"-Djava.class.path=" + jfw::BootParams::getClasspath();
++auto const cp = jfw::BootParams::getClasspath();
++if (!cp.isEmpty())
++   

Bug#1033505: caja: Hyphenation marks in long file names are NOT needed AT ALL! Why did they make this stupid function?!

[Eugene]

Package: caja
Version: 1.24.0-1
Severity: important
X-Debbugs-Cc: sher...@gmail.com

Dear Maintainer,

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

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

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


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils0.26-1
ii  gvfs  1.46.2-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-13+deb11u5
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcaja-extension11.24.0-1
ii  libexempi82.5.2-1
ii  libexif12 0.6.22-3
ii  libgail-3-0   3.24.24-4+deb11u2
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libglib2.0-data   2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libice6   2:1.0.10-1
ii  libmate-desktop-2-17  1.24.1-2
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libselinux1   3.1-3
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.2-1
ii  libxml2   2.9.10+dfsg-6.7+deb11u3
ii  mate-desktop  1.24.1-2
ii  shared-mime-info  2.0-1

Versions of packages caja recommends:
ii  gvfs-backends  1.46.2-1

Versions of packages caja suggests:
ii  engrampa1.24.1-1
pn  gstreamer1.0-tools  
pn  meld

Bug#1033155: migration test fails when EC key present in test keyrings

[Andreas Metzler]

On 2023-03-18 Jonathan Wiltshire  wrote:
> Source: gnupg2
> Version: 2.2.40-1
> Severity: important
> Tags: patch
> X-Debbugs-Cc: j...@debian.org

> Hi,

> The stable release key for bookworm is EC, and this causes gpg1 to bail
> out when it is imported as part of the migration test. Attached patch
> limits the keyrings used to the archive's automatic keys, which are
> still RSA.
[...]

Hello Jonathan,

afaict currently all keys are RSA except for
debian-archive-bookworm-stable.gpg. Wouldn't it be better to just skip
this single key?

cu Andreas

Bug#1033489: sudo lecture is missing

[Marc Haber]

On Sun, Mar 26, 2023 at 12:38:40PM +1000, Thom wrote:
> after first login after installation as regular user
> I try to use sudo comand at the first time
> but sudo legendary lecture did not display.

Upstream seems to have changed the default from "once" to "never". This
is also documented in sudoers(5).

I am not sure whether it is a good idea to deliver a package that is
configured differently by default.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1033492: unblock: php8.2/8.2.4-1 ????

[Paul Gevers]

Hi Ondřej,

On 26-03-2023 08:36, Ondřej Surý wrote:

just a quick reply - PHP already has a security (and if I remember correctly 
release) team exception from the last time. So, we already had this talk about 
upstream policies.


I *suspect* the same, but because of the shear amount of work ongoing 
for the release team at the moment, I hope people can help point to the 
relevant information instead of us needing to find it.


It can obviously wait a couple of days, we're not *that* close to 
releasing yet.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

On 2023-03-24 13:58, Vagrant Cascadian wrote:
> Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
> platforms and u-boot list to CC.
> 
> On 2023-03-22, Salvatore Bonaccorso wrote:
> > Thanks for tracking this down. I would like to loop in Masahiro and
> > upstream to see if something can/should be done on upstream side.
> >
> > Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> > special treatment for the link order of head.o") (which got backported
> > as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> > causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> > parameters previously working. Full quoting the Debian report below
> 
> In general it would be nice to not have the kernel grow nearly 25% in
> size from a single commit; was that an expected outcome from the above
> upstream change? Was the "special treament" originally done to keep the
> kernel size down?

This is currently being tracked [1], but the issue seems to be linked to
the version of the tools used in Debian, and the fact that we build our
kernels with BTF support, so the issue is likely to be difficult to find.

[1] https://lore.kernel.org/linux-arm-kernel/zbovcrmxjk7np...@aurel32.net/

> As for u-boot, It seems u-boot might need to update the various load
> addresses for the kernel, device tree and ramdisk at some point
> regardless of weather this particular issue gets fixed in the kernel, as
> the kernel will likely continue to grow a bit over time...

Yes that's probably a sane thing to do, at least in Debian.

> Aurelien Jarno included a patch referenced below which bumps the
> tolerances in u-boot from 36MB to 42MB.
> 
> 
> > On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> >> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> >> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> >> to boot with:
> >> 
> >> | 40175552 bytes read in 1695 ms (23 MiB/s)
> >> | 43794863 bytes read in 1817 ms (23 MiB/s)
> >> | Moving Image from 0x8 to 0x20, end=299
> >> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> >> 
> >> I tracked the issue to a significant increase of the kernel size between
> >> version 6.1.12-1 and 6.15-1:
> >> 
> >> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> >> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> >> 
> >> This is more than the 36MB that is allowed by u-boot with the default
> >> load addresses. A workaround is to shift the load addresses at the
> >> u-boot level as in the attached patch.
> >> 
> >> I have tracked issue on the upstream kernel side to the following commit
> >> on the stable tree:
> >> 
> >> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> >> | Author: Masahiro Yamada 
> >> | Date:   Thu Oct 13 08:35:00 2022 +0900
> >> | 
> >> | arm64: remove special treatment for the link order of head.o
> >> | 
> >> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> >> | 
> >> | In the previous discussion (see the Link tag), Ard pointed out that
> >> | arm/arm64/kernel/head.o does not need any special treatment - the 
> >> only
> >> | piece that must appear right at the start of the binary image is the
> >> | image header which is emitted into .head.text.
> >> | 
> >> | The linker script does the right thing to do. The build system does
> >> | not need to manipulate the link order of head.o.
> >> | 
> >> | Link: 
> >> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> >> | Suggested-by: Ard Biesheuvel 
> >> | Signed-off-by: Masahiro Yamada 
> >> | Reviewed-by: Nicolas Schier 
> >> | Link: 
> >> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> >> | Signed-off-by: Will Deacon 
> >> | Signed-off-by: Tom Saeger 
> >> | Signed-off-by: Greg Kroah-Hartman 
> >> 
> >> The problem is still reproducible on Linus' master.
> >> 
> >> I am reporting the bug to the linux package as I believed there is no
> >> real reason for such an increase in the kernel size. In case I missed
> >> something and this is actually wanted, the bug can be reassigned to the
> >> u-boot package.
> >> 
> >> Regards
> >> Aurelien
> >
> >> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
> >> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
> >> @@ -95,32 +95,32 @@
> >>   *   text_offset bytes (specified in the header of the Image) into a 2MB
> >>   *   boundary. The 'booti' command relocates the image if necessary. 
> >> Linux uses
> >>   *   a default text_offset of 0x8.  In summary, loading at 0x8
> >> - *   satisfies all these constraints and reserving memory up to 0x0240
> >> - *   permits fairly large (roughly 36M) kernels.
> >> + *   satisfies all these constraints and reserving memory up to 0x02a0
> >> + *   permits fairly large (roughly 42M) kernels.
> >>   *
> >>   * scriptaddr and pxefile_addr_r can be pretty much anywhere 

Bug#1033504: SD card reader support for the Banana Pi M5

[Marco d'Itri]

Package: linux-source-6.1
Version: 6.1.15-1
Severity: normal
Tags: patch upstream

The good news is that the Banana Pi M5 is almost fully supported by 
Bookworm, if the Debian kernel is loaded by a working u-boot like the 
one built by Armbian.

The bad news is that the SD card reader does not work with the Debian 
kernel (6.1.0-6-arm64) while it works fine with the Armbian kernel 
(6.2.0-rc3-meson64).

The symptoms are this message printed every second:

mmc0: error -84 whilst initialising SD card

and no card being detected.

I have identified these relevant patches applied by Armbian:

https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.2/general-meson-gx-mmc-fix-deferred-probing.patch
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.2/general-meson-mmc-1-arm64-amlogic-mmc-meson-gx-Add-core-tx-rx-eMMC-SD-SD.patch
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.2/general-meson-mmc-2-arm64-amlogic-dts-meson-update-meson-axg-device-tree.patch
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.2/general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patch
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.2/board-bananapim5-sd-use-270-mmc-clock-phase-via-dt.patch

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1033503: dgit autopkgtests broken by git 2.40

[Ian Jackson]

Package: dgit
Version: 10.7
Control: affects -1 git

Some of dgit's tests create strange git objects, to test error
handling.  For example, to avoid a repetition of #849041.

git 2.40, just uploaded to unstable, has this change:

 | * "git hash-object" now checks that the resulting object is well
 |   formed with the same code as "git fsck".
 |   (merge 8e4309038f jk/hash-object-fsck later to maint).

This was probably a good idea.  So, dgit's tests need to be updated.
Normally I would file this bug as RC and make the necessary changes.


However, we are currently in the freeze for bookworm.  Information on
tracker.d.o suggests that git is not going to migrate to bookworm
anyway, without an unblock from the release team.  I don't see an
unblock request in https://bugs.debian.org/release.debian.org .

Release team: do you think we (dgit maintainers) should update the
test suite now, for bookworm ?  The changes would be limited to tests,
but the new checks in git mean we'll need to take a different approach
for some of them, which might be complex or messy.


Unhelpfully, there is also #1032826, which prevents "dgit import-dsc"
working for the current git.dsc in bookworm.  I think this situation
is RC.  I haven't filed a bug against src:git because I think we can
fix this just by changing the infrastructure - I'm talking to DSA
about this - but if that turns out to be impossible, we may need to
upload a no-source-changes src:git :-/.


Thanks for everyone's attention and advice/opinions.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1009067: package from Ubuntu fixed the issue

[Norbert X]

The below testing procedure from 



```

wget 
https://launchpad.net/ubuntu/+archive/primary/+files/squid-deb-proxy-client_0.8.15+nmu1ubuntu4_all.deb


apt-get install ./squid-deb-proxy-client_0.8.15+nmu1ubuntu4_all.deb

```

fixed the issue on upcoming Debian 12 (bookworm). While package from sid 
is still buggy.



So please upload fixed package from Ubuntu Lunar 
 to Debian 12 
(bookworm) repository.

Bug#1033102: ntpsec: ntpq -c sysinfo fails with TypeError: 'int' object is not subscriptable

[Alex]

Package: ntpsec
Version: 1.2.0+dfsg1-4
Followup-For: Bug #1033102

I fixed the ntpq -c sysinfo fails with TypeError: 'int' object is not 
subscriptable problem my system.

Here comes the fix:

444c444
< if self.showhostnames[0]:
---
> if self.showhostnames:

Cheers
/alex

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

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

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u5
ii  libcap2  1:2.44-1
ii  libssl1.11.1.1n-0+deb11u4
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  python3  3.9.2-3
ii  python3-ntp  1.2.0+dfsg1-4
ii  tzdata   2021a-1+deb11u9

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd 247.3-7+deb11u1

Versions of packages ntpsec suggests:
ii  apparmor   2.13.6-10
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information

Bug#1033502: software-properties-common: got 'NoneType' object has no attribute 'people' while adding LP PPA

[Norbert]

Package: software-properties-common
Version: 0.99.30-4
Severity: normal
X-Debbugs-Cc: nrb...@gmail.com

Dear Maintainer,

to fix known VTE bug  I need to add my Ubuntu PPA
 to the Debian 12 (bookworm)
system.

So I use below steps to reproduce:

```
apt-get install software-properties-common
apt-get update
apt-key adv --keyserver keyserver.ubuntu.com --recv
E756285F30DB2B2BB35012E219BFCAF5168D33A9
add-apt-repository -y "deb http://ppa.launchpad.net/nrbrtx/vte/ubuntu jammy
main"
```

I expect that the above "deb http://ppa.launchpad.net/nrbrtx/vte/ubuntu jammy
main" line will be added to /etc/apt/sources.list file, but instead I get the
following error:

```
# add-apt-repository -y "deb http://ppa.launchpad.net/nrbrtx/vte/ubuntu jammy
main"
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in 
sys.exit(0 if addaptrepo.main() else 1)
  ^
  File "/usr/bin/add-apt-repository", line 345, in main
shortcut = handler(source, **shortcut_params)
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
40, in shortcut_handler
return handler(shortcut, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 78, in
__init__
self.lpppa
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 126, in
lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 113, in
lpteam
self._lpteam = self.lp.people(self.teamname)
   ^^
AttributeError: 'NoneType' object has no attribute 'people'
```

On Debian 11 the above process works as expected.

I do not find my method as rarely used or wrong. So please adjust add-apt-
repository script or its underhoods to eliminate the above error.


-- System Information:
Debian Release: 12.0
  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)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages software-properties-common depends on:
ii  ca-certificates  20230311
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-packagekitglib-1.01.2.6-3
ii  packagekit   1.2.6-3
ii  python-apt-common2.5.3
ii  python3  3.11.2-1
ii  python3-dbus 1.3.2-4+b1
ii  python3-gi   3.42.2-3+b1
ii  python3-software-properties  0.99.30-4

software-properties-common recommends no packages.

software-properties-common suggests no packages.

-- no debconf information

Bug#1033501: wrong aspect ratio in mate-panel workspace switcher

[Simon McVittie]

Control: retitle -1 wrong aspect ratio in mate-panel workspace switcher
Control: reassign -1 mate-panel 1.27.0-1
Control: forwarded -1 https://github.com/mate-desktop/mate-panel/issues/1230

On Sun, 26 Mar 2023 at 12:32:19 +0300, Norbert wrote:
> Steps to reproduce:
> 1. Install task-mate-desktop
> 2. Launch mate-display-properties to set display resolutions
> 3. Visually compare display proportions with mate-panel workspace switcher
> 
> Expected results:
> * display ratios in mate-panel workspace switcher and mate-display-properties
> are equal
> 
> Actual result:
> * display ratios in mate-panel workspace switcher and mate-display-properties
> are not equal
> 
> There is no such bug in Debian 10 and 11.
> 
> Upstream bug report is at 
> https://github.com/mate-desktop/mate-panel/issues/1230 .

It seems the libwnck developers consider this to be a bug in mate-panel:
the previous libwnck behaviour was not consistent with GTK's API
requirements, causing warnings from GTK.
https://gitlab.gnome.org/GNOME/gnome-panel/-/commit/dc1100165a840c39b4acd6fb533373e5f7594910
seems to be the fix for an equivalent bug in gnome-panel.

smcv

Bug#1033501: libwnck-3-0: Bug in libwnck3 breaks aspect ratio in mate-panel workspace switcher

[Norbert]

Package: libwnck-3-0
Version: 43.0-3
Severity: important
X-Debbugs-Cc: nrb...@gmail.com

Dear Maintainer,

Steps to reproduce:
1. Install task-mate-desktop
2. Launch mate-display-properties to set display resolutions
3. Visually compare display proportions with mate-panel workspace switcher

Expected results:
* display ratios in mate-panel workspace switcher and mate-display-properties
are equal

Actual result:
* display ratios in mate-panel workspace switcher and mate-display-properties
are not equal

There is no such bug in Debian 10 and 11.

Upstream bug report is at https://github.com/mate-desktop/mate-
panel/issues/1230 .


-- System Information:
Debian Release: 12.0
  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)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwnck-3-0 depends on:
ii  libatk1.0-0   2.46.0-5
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-1
ii  libgtk-3-03.24.37-2
ii  libpango-1.0-01.50.12+ds-1
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-common  43.0-3
ii  libx11-6  2:1.8.4-2
ii  libxrender1   1:0.9.10-1.1
ii  libxres1  2:1.2.1-1

libwnck-3-0 recommends no packages.

libwnck-3-0 suggests no packages.

-- no debconf information

Bug#1033500: ITP: ruby-google-apis-container-v1 --REST client for Google APIs

[Ravi Dwivedi]

package: wnpp
Severity: wishlist
Owner: 'Ravi Dwivedi' 

*Package Name : ruby-google-apis-container-v1
 Version : 0.43.0
 Upstream Author : Google LLC
*URL : https://github.com/googleapis/google-api-ruby-client
*License : Apache-2.0
*Description :  REST client for Google APIs

I am packaging  as it is a dependency of gitlab 15.9.2.

---
Ravi Dwivedi

Bug#1033488: Idea: use CROSS_GRADE_TO_ARCH, if set.

[Geert Stappers]

> cross-grading an ARM system from armhf to arm64

Idea for supporting such corner cases


if environmentvariable CROSS_GRADE_TO_ARCH is set
use it
else
dpkg --print-architecture



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10

[Timo Aaltonen]

Markus Koschany kirjoitti 24.3.2023 klo 15.35:

Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen:

Markus Koschany kirjoitti 23.3.2023 klo 19.00:

Control: severity -1 serious

On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen 
wrote:
   

Upstream doesn't support tomcat10 yet, and tomcatjss fails to build with
it.


Unfortunately we can only support one Tomcat version per release. We should
either migrate to tomcat10 or maybe it is possible to embed some of the
required tomcat9 classes in your source package as a workaround provided
the
changes are rather small and the security impact is negligible.


Right, but that's for bookworm+1? By that time I'm sure
jss/tomcatjss/dogtag have gained upstream support for tomcat10.


We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in Buster
and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat 9
was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm. resteasy3.0
and tomcatjss are the only packages apart from i2p that still depend on
libtomcat9-java.


Nice, so you expect them to migrate after bookworm is already frozen?

--
t

Bug#1033498: installation-reports: Missing FW files not detected on USB stick

[Holger Wansing]

Hi,

Am 26. März 2023 10:52:38 MESZ schrieb Rainer Dorsch :
>
>I copied all files from 
>
>https://github.com/LibreELEC/brcmfmac_sdio-firmware
>
>on a USB-stick (ext3 formated, with vfat I got an error, probably the 
>filenames 
>were not compatible). I selected  but the same box showed up again and I 
>assume no FW files were found (but it did not say so).

As always: we need the syslog from /var/log/installer, to debug.


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1033499: libicu67 tzdata version outdated

[Arash Hemmat]

Package: libicu67
Version: 67.1-7

Hi,
I'm using Debian bullseye (kernel 5.10.0-12-amd64 libc6 2.31-13+deb11u2) on
my web server and because of recent changes to the DST in my country the
time generated by php intl (which uses ICU) is returning the wrong time.
I've checked the source of the problem and I've noticed that the tzdata
version of libicu67 is very old and is currently using tzdata 2019c. Here
is how i check the version of libicu tzdata version on my debian server:

$ php -r "echo intltz_get_tz_data_version();"
2019c

This is causing huge problems for everyone using debian on their servers in
my country and based on my research updating libicu tzdata isn't that easy
and I'd prefer a bug fix from package maintainer.

Here is the wrong time that a being generated because of the outdated
libicu67 tzdata:

php -r "echo
datefmt_format(datefmt_create('en_US',IntlDateFormatter::FULL,IntlDateFormatter::FULL,'Asia/Tehran',IntlDateFormatter::GREGORIAN)
, time());"
Sunday, March 26, 2023 at 1:30:13 PM Iran Daylight Time

The time is 1 hour off because the DST has changed this year.

I suggest that the package maintainer update the libicu67 tzdata as a bug
fix and i think it has to be updated frequently every time ICU releases a
new tzdata package.