Bug#1021524: lomiri-system-settings is not installable

[Mike Gabriel]

Hi Adrian,

On  Mo 10 Okt 2022 04:49:47 CEST, Adrian Bunk wrote:


Package: lomiri-system-settings
Version: 1.0~git20221004.572f3a9-1
Severity: serious

The following packages have unmet dependencies:
 lomiri-system-settings : Depends: lomiri-keyboard-data but it is  
not installable
  Depends: ubports-wallpapers but it is not  
installable


thanks for reporting this.

lomiri-keyboard-data will come, but I could actually comment it out as  
we don't provide the language plugin in Debian, yet.


Regarding ubports-wallpapers, we might have to rename stuff upstream  
(ubports-wallpapers -> lomiri-wallpapers). Will discuss it with the  
UBports team.


Greets,
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



pgpNWQN2OA4oF.pgp
Description: Digitale PGP-Signatur

Bug#1021515: tex-common: user locale settings can cause postinst to fail

[Norbert Preining]

Hi Stuart,

> The postinst for tex-common is sensitive to the locale settings from the

Hmm, interesting ...

> $ luahbtex -ini   -jobname=luahbtex -progname=luahbtex luatex.ini  Unable to read environment locale: exit now.

We do set LANG=C already before running fmtutil, so I am surprised that
there is still something bad happening.


> Feeding in some environment variables to see if I could convince it to

What happens if you only feed LANG=C? Does it break?

Looking at the code, maybe we forgot to export LANG since it might not
be defined by now. As of now the code runs:

LANGSAVE=$LANG
LANG=C
printf "Building format(s) $*.\n\tThis may take some time... "
if $FMTUTIL "$@" > $tempfile 2>&1 ; then

LANG normally is already marked as export, but maybe in your particular
case it was unset, and thus not marked as to be exported.

Can you also do an experiment by adding
export LANG
to /var/lib/dpkg/info/tex-common.postinst (AFAIR, not on Debian) after
setting it to LANG=C, and see if that helps.

> $ LANG=C LANGUAGE=C LC_CTYPE=C LC_NUMERIC=C LC_TIME=C LC_COLLATE=C 
> LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C LC_NAME=C LC_ADDRESS=C luahbtex -ini   
> -jobname=luahbtex -progname=luahbtex luatex.ini  bash: warning: setlocale: LC_COLLATE: cannot change locale (en_AU.UTF-8)

That is indeed strange and I cannot reproduce it.

> Installing the 'locales' package and correctly configuring it to the
> locales that were in the environment was also enough.

It should not be necessary, and in fact will create problems later on.

> particular locale required. Adding some locale overrides to the postinst
> would be better, but it might mean that users do not get error messages
> displayed to them in their preferred language.

The locale variables are set for the fmtutil run only, and none of the
programs involved is localized, so there is no change.

I am just wondering what other locale vars are necessary, back then
we thought (and it worked bakc then) that LANG is enough.

Regards

Norbert

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

Bug#1021524: lomiri-system-settings is not installable

[Adrian Bunk]

Package: lomiri-system-settings
Version: 1.0~git20221004.572f3a9-1
Severity: serious

The following packages have unmet dependencies:
 lomiri-system-settings : Depends: lomiri-keyboard-data but it is not 
installable
  Depends: ubports-wallpapers but it is not installable

Bug#1021523: wine-development: Wine fails to create a new WINEPREFIX, even if it is the default

[Sebastián Lacuesta]

Package: wine-development
Version: 7.11~repack-1
Severity: important
X-Debbugs-Cc: sebastianlacue...@gmail.com

Dear Maintainer,

When trying to start a new default wine prefix, following error occurs:

wine: created the configuration directory '/home/myself/unwine'
002c:err:seh:NtRaiseException Unhandled exception code c005 flags 0 addr
0x170067170
wine: could not load kernel32.dll, status c135

I removed ~/.wine and tried to create a new prefix by launching winecfg-
development and I had previous reported error.

Created directories are:
$ tree /home/myself/.wine
/home/myself/.wine
├── dosdevices
│   ├── c: -> ../drive_c
│   └── z: -> /
├── drive_c
│   └── windows
│   ├── system32
│   └── syswow64
└── user.reg

Calling winecfg-development, winefile-development or any program provided by
wine-development without a default prefix and no WINEPREFIX environment
variable set should create a new one and launch the program. I have the issue
when doing the same but providing an empty WINEPREFIX.

Regards,
Sebastián


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine-development depends on:
ii  wine32-development  7.11~repack-1
ii  wine64-development  7.11~repack-1

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox0.74-3-4+b1
ii  exe-thumbnailer   1~icoextract-0.1.4-1
ii  icoextract-thumbnailer [exe-thumbnailer]  0.1.4-1
pn  playonlinux   
pn  q4wine
ii  winbind   2:4.16.5+dfsg-2
pn  wine-binfmt   
ii  winetricks20220411-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.7.2-1
ii  libc62.35-2
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libglib2.0-0 2.74.0-2
ii  libgphoto2-6 2.5.29-1
ii  libgphoto2-port122.5.29-1
ii  libgstreamer-plugins-base1.0-0   1.20.3-dmo1
ii  libgstreamer1.0-01.20.3-1
ii  libldap-2.5-02.5.13+dfsg-2
ii  libopenal1   1:1.19.1-2
ii  libpcap0.8   1.10.1-4
ii  libpulse016.1+dfsg1-2
ii  libudev1 251.5-1
ii  libunwind8   1.3.2-2
ii  libusb-1.0-0 2:1.0.26-1
ii  libx11-6 2:1.8.1-2
ii  libxext6 2:1.3.4-1+b1
ii  libz-mingw-w64   1.2.12+dfsg-2
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 7.0~repack-9
ii  gstreamer1.0-plugins-good  1.20.3-dmo1
ii  libasound2-plugins 1:1.2.7.1-dmo2
ii  libcups2   2.4.2-1+b1
ii  libdbus-1-31.14.4-1
ii  libgl1 1.5.0-1
ii  libgl1-mesa-dri22.2.0-1
ii  libgnutls303.7.7-2
ii  libgssapi-krb5-2   1.20-1
ii  libkrb5-3  1.20-1
ii  libodbc2   2.3.11-2
pn  libosmesa6 
ii  libsdl2-2.0-0  2.24.1+dfsg-1
ii  libv4l-0   1.22.1-4
ii  libvulkan1 1.3.224.0-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine-development suggests:
ii  cups-bsd   2.4.2-1+b1
ii  gstreamer1.0-libav 1:1.20.3-dmo2
ii  gstreamer1.0-plugins-bad   1:1.20.3-dmo6
ii  gstreamer1.0-plugins-ugly  1:1.20.3-dmo1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.35-2
ii  libwine-development  7.11~repack-1

wine32-development recommends no packages.

Versions of packages wine32-development suggests:
pn  wine32-development-preloader  

Versions of packages wine64-development depends on:
ii  libc62.35-2
ii  

Bug#1021467: debhelper/dh_installchangelogs: minimum number of changelog entries kept by trimming should be > 1

[Jaimos Skriletz]

Hello,

I just ran into this on a package that I haven't updated since
2018-06-03 (fvwm). The result was as mentioned, the full changelog was
trimmed and I was left with only a single changelog entry. I noticed
this because lintian triggered initial-upload-closes-no-bugs since the
changelog had a single entry.

I second that the trimming should keep a minimum number of past
entries, either based on number of changelog versions, number of
lines, or minimum filesystem size.

jaimos

Bug#1021368: autopkgtest: quilt patches not applied on arm64, ppc64el, or s390x

[Olek Wojnar]

Thanks again for the VERY quick response!

On 10/9/22 15:50, Paul Gevers wrote:


Pardon my ignorance of the finer points of autopkgtest but is there a 
way to get more-verbose logging?


I started it with --shell-fail. That gave me a shell on the first test 
that failed and I could then easily confirm that the patches were applied.


Ah, good to know! Love learning new tricks, thank you!

I think since long you don't need quilt. IIRC dpkg will apply patches 
natively when you ask it via apt for the source.


Another good thing learned, I didn't realize dpkg had that capability!

Yes, please. Can you verify that the third_party/ijar/common.h file 
has the following on lines 24 and 25?

#include 
#include 


root@elbrus:/tmp/autopkgtest-lxc.ookvjd3p/downtmp/build.OBp/src# head 
-n25 third_party/ijar/common.h | tail -n2

#include 
#include 


Ok, well then apologies for a spurious bug report. Sounds like there's 
something really strange going on here... But the patching is definitely 
working correctly.


Thanks again for the help troubleshooting. Now I need to figure out what 
is REALLY going on to cause these failures...


-Olek


OpenPGP_signature
Description: OpenPGP digital signature

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Paul Wise]

On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote:

> I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.

That sounds interesting and would be nice generally, however...

> On a sidenote: What the Depends ensures which the Enhances doesn't is
> that they are upgraded in lockstep. As in, if for some reason foo (or
> foo-dbgsym) have their version appear at different points in the archive
> apt would hold back on a Depends while with Enhances this dependency
> would be broken and hence auto-remove kicks in.

For the rolling Debian suites, the main and dbgsym archives are often
out of sync, the dbgsym packages updates sometimes appear first and
sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed
since old or new dbgsym has zero value for debugging and just because
the archives are currently not in sync, that doesn't mean one wants out
of sync dbgsyms to be removed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1021522: crack: reproducible-builds: date in various binaries

[Vagrant Cascadian]

Source: crack
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The date is embedded in various binaries:

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

  /usr/lib/Crack/stdlib-cracker

  Fri·Nov·10·06:59:40·-12·2023
  vs.
  Sun·Oct··9·02:42:03·+14·2022

There are two different patches to fix this issue, the first patches the
upstream src/util/Makefile to not embed a date at all, and is the
preferred approach from a reproducible builds perspective.

The second patch uses the SOURCE_DATE_EPOCH environment variable to
specify the date to use in the embedded files, if for some reason these
files require a date in order to function correctly.

According to my local tests, with this patch applied, and a soon-to-be
submitted patch to fix build paths, crack should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining crack!

live well,
  vagrant
From 14c413afff3bb0bdbcbe5113adfd569d0f496fe0 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 10 Oct 2022 00:10:18 +
Subject: [PATCH 2/4] src/util/Makefile: Remove embedded timestamps.

https://reproducible-builds.org/docs/timestamps/
---
 src/util/Makefile | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/util/Makefile b/src/util/Makefile
index b2a96c3..f09bb9f 100644
--- a/src/util/Makefile
+++ b/src/util/Makefile
@@ -42,25 +42,21 @@ $(XDIR)/stdlib-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB)
-	date > $@
 
 $(XDIR)/libdes-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../libdes/libdes.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../libdes/libdes.a
-	date > $@
 
 $(XDIR)/ufc-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -DINITDES -DFCRYPT -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../ufc-crypt/libufc.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../ufc-crypt/libufc.a
-	date > $@
 
 $(XDIR)/gnu-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../crypt/libufc.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../crypt/libufc.a
-	date > $@
 
 #--
 
-- 
2.37.2

From eae675adc4369871379c238fd7550d96d79512a2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 10 Oct 2022 00:12:03 +
Subject: [PATCH 4/4] src/util/Makefile: Use SOURCE_DATE_EPOCH to set date.

https://reproducible-builds.org/docs/source-date-epoch/
---
 src/util/Makefile | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/util/Makefile b/src/util/Makefile
index b2a96c3..1ea15be 100644
--- a/src/util/Makefile
+++ b/src/util/Makefile
@@ -20,6 +20,8 @@ EXE=$(XDIR)/dawg \
 
 #--
 
+DATESTAMP = $(shell LC_ALL=C date --utc --date=@$(SOURCE_DATE_EPOCH))
+
 all:$(EXE)
 	@echo all made in util
 
@@ -42,25 +44,25 @@ $(XDIR)/stdlib-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB)
-	date > $@
+	echo "$(DATESTAMP)" > $@
 
 $(XDIR)/libdes-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../libdes/libdes.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../libdes/libdes.a
-	date > $@
+	echo "$(DATESTAMP)" > $@
 
 $(XDIR)/ufc-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -DINITDES -DFCRYPT -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../ufc-crypt/libufc.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../ufc-crypt/libufc.a
-	date > $@
+	echo "$(DATESTAMP)" > $@
 
 $(XDIR)/gnu-cracker: cracker.c $(XLIB)
 	$(CC) $(CFLAGS) -c elcid.c
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB) ../crypt/libufc.a
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o $(XLIB) ../crypt/libufc.a
-	date > $@
+	echo "$(DATESTAMP)" > $@
 
 #--
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021520: guymager: reproducible-builds: date in guymager manpage

[Vagrant Cascadian]

Source: guymager
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The date is embedded in /usr/share/man/man1/guymager.1.gz:

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

  TH·guymager·1·"2023-11-10"·"version·0.8.13-1
  vs.
  TH·guymager·1·"2022-10-09"·"version·0.8.13-1

The attached patch to the upstream manuals/rebuild.sh file fixes this by
using SOURCE_DATE_EPOCH to determine the date to embed in the manpage.

According to my local tests, with this patch applied guymager should
build reproducibly on tests.reproducible-builds.org once it migrates to
bookworm/testing! There are other outstanding issues with build-paths,
which are only tested on unstable/experimental.

Thanks for maintaining guymager!

live well,
  vagrant
From af2c2f8de89f0aba6c1579d94f4a70c957aba5ff Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 23:28:44 +
Subject: [PATCH 2/2] manuals/rebuild.sh: Use SOURCE_DATE_EPOCH to set the date
 used for manpages.

https://reproducible-builds.org/docs/source-date-epoch/
---
 manuals/rebuild.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/manuals/rebuild.sh b/manuals/rebuild.sh
index bdb4311..b8cf453 100755
--- a/manuals/rebuild.sh
+++ b/manuals/rebuild.sh
@@ -1,6 +1,6 @@
 #!/bin/bash
 
-TH_Date=`date '+%Y-%m-%d'`
+TH_Date=`date --utc --date=@${SOURCE_DATE_EPOCH} '+%Y-%m-%d'`
 TH_Source=`head -qn 1 ../debian/changelog ../changelog 2>/dev/null | awk '{
   Version = $2
   gsub ("(", "", Version)
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021521: crack: reproducible-builds: build path embedded in various binaries

[Vagrant Cascadian]

Source: crack
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various binaries in /usr/lib/Crack:

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

  /usr/lib/Crack/cracker

  /build/1st/crack-5.0a/src/util/cracker.c:980
  vs.
  /build/2/crack-5.0a/2nd/src/util/cracker.c:980

The attached patch to debian/Crack.make fixes this by adding the default
CFLAGS to C5FLAGS using dpkg-buildflags.

According to my local tests, with this patch applied, and the patch
recently submitted to fix timestamp issues, crack should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining crack!

live well,
  vagrant
From 9238dca4c095b5a914ae5a0c03ffd31d842f1156 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 10 Oct 2022 00:08:01 +
Subject: [PATCH 1/4] debian/Crack.make: Use dpkg-buildflags to set default
 CFLAGS.

---
 debian/Crack.make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/Crack.make b/debian/Crack.make
index 0d12115..57848b6 100755
--- a/debian/Crack.make
+++ b/debian/Crack.make
@@ -42,7 +42,7 @@ CRACK_PATH=/usr/local/bin:/usr/ccs/bin:/usr/sbin:/sbin:/usr/bin:/bin:/usr/ucb:/u
 # - redhat linux 4.0
 # - digital unix v4.0
 
-C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H -DUSE_UNISTD_H -DUSE_PWD_H"
+C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H -DUSE_UNISTD_H -DUSE_PWD_H $(dpkg-buildflags --get CFLAGS)"
 
 #
 # now pick your compiler
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1013554: golang-github-valyala-tcplisten: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/valyala/tcplisten returned exit code 1

[Mathias Gibbens]

Control: tags -1 + pending

Hi Marco,

On Sat, 2022-10-08 at 04:53 +0200, Marco d'Itri wrote:
> On Jul 30, Mathias Gibbens  wrote:
> 
> >   Feel free to apply it directly yourself. :) If this does fix the
> > issue, it would probably be good to contact Lucas and see if we can
> > figure out what in the rebuild setup needs to be tweaked to ensure
> > that "ip6-localhost" is properly resolvable.
> This bug has been inactive for over two months: do you need any help?
> It is keeping cfrpki out of testing.

  I had left it in Aloïs' hands, but I also know he's been pretty busy.
I hadn't looked at the build-rdeps for this package, but see there are
several. So, I've pushed my proposed patch to the salsa repo along with
a few other small cleanups. It's ready for an upload to unstable after
a `dch -r` and `git tag`. My gpg key should be included in the DD
uploaders keyring after this month's update, at which point I will
upload the package myself, or if either you or Aloïs want to you can
upload it sooner.

Mathias


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

Bug#1021519: easyeffects: Better spectrum

[Roman Hornik]

Package: easyeffects
Version: 6.3.0-1
Severity: wishlist
X-Debbugs-Cc: roman.hor...@debian-linux.cz

Dear Maintainer,

Could the horizontal axis of the spectrum be more linear (half-half logarithmic
and linear), with a frequency range of at least 24kHz (or better up to 48kHz -
for measurements), and a higher horizontal resolution (4096, or better up to
8192 points)? The resolution at low frequencies is insufficient, with only
about 25 coarse bars taking up the left half of the screen.

Thanks.

Roman Horník


-- System Information:
Debian Release: Sid/Experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-rc7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages easyeffects depends on:
ii  calf-plugins 0.90.3-3
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libadwaita-1-0   1.2.0-1
ii  libbs2b0 3.1.0+dfsg-6
ii  libc62.36-1
ii  libcairo21.16.0-6
ii  libebur128-1 1.2.6-1+b1
ii  libfftw3-single3 3.3.8-2
ii  libfmt9  9.1.0+ds1-2
ii  libgcc-s112.2.0-5
ii  libglib2.0-0 2.74.0-2
ii  libgtk-4-1   4.8.1+ds-1
ii  liblilv-0-0  0.24.20-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpipewire-0.3-00.3.59-1
ii  librubberband2   1:3.1.0-dmo1
ii  libsamplerate0   0.2.2-2
ii  libsigc++-3.0-0  3.2.0-5
ii  libsndfile1  1.1.0-3
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-5
ii  libtbb12 2021.5.0-15
ii  libzita-convolver4   4.0.3-2

Versions of packages easyeffects recommends:
ii  lsp-plugins  1.1.31-3
ii  lsp-plugins-lv2  1.1.31-3

easyeffects suggests no packages.

-- no debconf information

Bug#1015922: dracut-core: grep missing in 90lvm/lvm_scan

[Thomas Deutschmann]

Hi,

I also hit this today.

Upstream fix: 
https://github.com/dracutdevs/dracut/commit/79f9d9e1c29a9c8fc046ab20765e5bde2aaa3428


Should be included if we bump to 057.


--
Regards,
Thomas

Bug#1021085: closed by Debian FTP Masters (reply to Thorsten Glaser ) (Bug#1021085: fixed in mksh 59c-19)

[Thorsten Glaser]

Vagrant Cascadian dixit:

>  succeeded-tested[1_(1_ignored)f/576p]·lksh_musl=✓

Oh right… another occurrence, I had only looked for the reported one.

Thanks for noticing,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1021518: jakarta-jmeter: reproducible-builds: year in documentation files

[Vagrant Cascadian]

Source: jakarta-jmeter
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The current year is embedded in various documentation files:

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

  /usr/share/jmeter/printable_docs/building.html

  Copyright··1999-2022,·Apache·Software·Foundation
  vs.
  Copyright··1999-2023,·Apache·Software·Foundation

Not only does this break reproducible builds, it is not an accurate
reflection of the correct copyright dates.

The attached patch to two upstream .vsl files fixes this by using the
date that the current upstream version was uploaded to debian (maybe it
is older, feel free to adjust appropriately).

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

Thanks for maintaining jakarta-jmeter!

live well,
  vagrant
From e19489b243bff03a128b8005dd7fdbd5ada11b6d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 23:22:36 +
Subject: [PATCH] xdocs/stylesheets/site*.vsl: Use specific date for Copyright
 headers.

This breaks reproducible builds, but also the dates for Copyright
headers are valid for when the content was initially authored, not
the build date.
---
 xdocs/stylesheets/site.vsl   | 2 +-
 xdocs/stylesheets/site_printable.vsl | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xdocs/stylesheets/site.vsl b/xdocs/stylesheets/site.vsl
index e91d687..3c0f36e 100644
--- a/xdocs/stylesheets/site.vsl
+++ b/xdocs/stylesheets/site.vsl
@@ -33,7 +33,7 @@
 #set ($space = $space.charAt(0))
 #set ($udsc = "_")
 #set ($udsc = $udsc.charAt(0))
-#set ($year = $date.getYear()+1900)
+#set ($year = "2016")
 ##
 ## Website settings
 #set ($imgdir = "$relativePath/images")
diff --git a/xdocs/stylesheets/site_printable.vsl b/xdocs/stylesheets/site_printable.vsl
index b817284..36ec7eb 100644
--- a/xdocs/stylesheets/site_printable.vsl
+++ b/xdocs/stylesheets/site_printable.vsl
@@ -33,7 +33,7 @@
 #set ($space = $space.charAt(0))
 #set ($udsc = "_")
 #set ($udsc = $udsc.charAt(0))
-#set ($year = $date.getYear()+1900)
+#set ($year = "2016")
 ##
 ## Printable document settings
 #set ($imgdir = "$relativePath/../docs/images")
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1021517: easyeffects: EE not loading LV2 plugins

[Roman Hornik]

Package: easyeffects
Version: 6.3.0-1
Severity: important
X-Debbugs-Cc: roman.hor...@debian-linux.cz

Dear Maintainer,

it is not possible to load any LSP plugin, such as an equalizer. EE reports
that plugins are not installed, even though they are. These packages are:
lsp-plugins(-jack, -ladspa, -lv2, -r3d-glx and -vst), all in version 1.1.31-3
When run from the terminal with -l , the program spits out a bunch of
the following lines:


(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: sr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: xsr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: xmr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: fr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: qr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.189:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: gr_31

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.201:
lv2_wrapper.cpp:65  Could not find the plugin: http://lsp-
plug.in/plugins/lv2/para_equalizer_x32_lr

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.201:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: mode

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.201:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: bal

(easyeffects:6305): easyeffects-WARNING **: 01:07:49.201:
lv2_wrapper.cpp:353 http://lsp-plug.in/plugins/lv2/para_equalizer_x32_lr
port symbol not found: frqs_l


In truth, I don't know for what reason the program wants to contact the remote
server (http://lsp-plug.in) via lv2_wrapper.cpp, but none of those URLs are
valid.


Thanks.

Roman Horník


-- System Information:
Debian Release: Sid/Experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-rc7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages easyeffects depends on:
ii  calf-plugins 0.90.3-3
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libadwaita-1-0   1.2.0-1
ii  libbs2b0 3.1.0+dfsg-6
ii  libc62.36-1
ii  libcairo21.16.0-6
ii  libebur128-1 1.2.6-1+b1
ii  libfftw3-single3 3.3.8-2
ii  libfmt9  9.1.0+ds1-2
ii  libgcc-s112.2.0-5
ii  libglib2.0-0 2.74.0-2
ii  libgtk-4-1   4.8.1+ds-1
ii  liblilv-0-0  0.24.20-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpipewire-0.3-00.3.59-1
ii  librubberband2   1:3.1.0-dmo1
ii  libsamplerate0   0.2.2-2
ii  libsigc++-3.0-0  3.2.0-5
ii  libsndfile1  1.1.0-3
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-5
ii  libtbb12 2021.5.0-15
ii  libzita-convolver4   4.0.3-2

Versions of packages easyeffects recommends:
ii  lsp-plugins  1.1.31-3
ii  lsp-plugins-lv2  1.1.31-3

easyeffects suggests no packages.

-- no debconf information

Bug#1021516: ssocr: reproducible-builds: date in ssocr manpage

[Vagrant Cascadian]

Source: ssocr
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The date is embedded in /usr/share/man/man1/ssocr.1.gz:

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

  TH·ssocr·1·"2023-11-10"·"2.22.1"·"OCR·for·seven·segment·displays"
  vs.
  TH·ssocr·1·"2022-10-09"·"2.22.1"·"OCR·for·seven·segment·displays"

The attached patch to the upstream Makefile fixes this by using
SOURCE_DATE_EPOCH to determine the date to embed in the manpage.

According to my local tests, with this patch applied, and the patch
applied to fix build paths from #1021514, ssocr should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining ssocr!

live well,
  vagrant
From 72522a777380147442bb9108fbcad2422b7acc32 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 23:10:05 +
Subject: [PATCH 1/2] Makefile: Use SOURCE_DATE_EPOCH for the date embedded in
 manpage.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 556bbde..1ca185f 100644
--- a/Makefile
+++ b/Makefile
@@ -22,7 +22,7 @@ charset.o: charset.c charset.h defines.h help.h Makefile
 
 ssocr.1: ssocr.1.in Makefile defines.h
 	sed -e 's/@VERSION@/$(VERSION)/' \
-	-e "s/@DATE@/$(shell date +%Y-%m-%d)/" \
+	-e "s/@DATE@/$(shell date --utc --date=@(SOURCE_DATE_EPOCH) +%Y-%m-%d)/" \
 	-e 's/@CRYEARS@/$(CRYEARS)/' <$< >$@
 
 ssocr-manpage.html: ssocr.1
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021515: tex-common: user locale settings can cause postinst to fail

[Stuart Prescott]

Package: tex-common
Version: 6.17
Severity: normal
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The postinst for tex-common is sensitive to the locale settings from the
environment and so can fail in strange ways. Users can end up with odd
locale settings in a chroot (as I did, where my login environment had
leaked into the chroot but the specified locale was not installed), when
connecting over ssh (the remote system's locale settings are applied to
the remote session), or through simple misconfiguration.

While the particularly odd locale seettings that I had in the chroot were
my fault, the postinst should be robust to such failures.

- 8< -
Setting up tex-common (6.17) ...
debconf: falling back to frontend: Readline
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.YvPIYmjZ
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
- 8< -

The log file mentioned ends with the following lines:
- 8< -
fmtutil [ERROR]: running `luahbtex -ini   -jobname=luahbtex -progname=luahbtex 
luatex.ini From a Debian perspective, tex-common depending on the locales package is
not a nice thing to do; it's also not sufficient to solve this bug, since
installing the locales package is not the same as configuring the
particular locale required. Adding some locale overrides to the postinst
would be better, but it might mean that users do not get error messages
displayed to them in their preferred language.

regards
Stuart

Bug#1021514: ssocr: reproducible-builds: build path embedded in /usr/bin/ssocr

[Vagrant Cascadian]

Source: ssocr
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/ssocr:

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

  /build/1st/ssocr-2.22.1/ssocr.c:54
  vs.
  /build/2/ssocr-2.22.1/2nd/ssocr.c:54

The attached patch to debian/rules fixes this by adding a dh_auto_build
override that passes the default CFLAGS as CCOPTIONS.

According to my local tests, with this patch applied, ssocr should
*almost* build reproducibly on tests.reproducible-builds.org! (I'll
submit a patch also for the remaining timestamp issue)

Thanks for maintaining ssocr!

live well,
  vagrant
From 085cdf7a5b78f15adf72cd5dcdfe4007874e5cd7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 23:10:43 +
Subject: [PATCH 2/2] debian/rules: Add dh_auto_build override to explicitly
 pass the default CFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index f864541..edda100 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,3 +13,6 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 override_dh_auto_install:
 	@echo Do not use install target of upstream Makefile
+
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021513: centrifuge: reproducible builds: Embeds build time and hostname in centrifuge-build-bin

[Vagrant Cascadian]

Source: centrifuge
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The time and hostname are embedded in /usr/lib/centrifuge/centrifuge-build-bin:

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

  ionos5-amd64
  vs.
  i-capture-the-hostname
  
  Fri·Nov·10·04:07:04·-12·2023
  vs.
  Sat·Oct··8·23:46:23·+14·2022

The attached patch to the upstream Makefile fixes this by setting a
place holder value for BUILD_HOST and uses SOURCE_DATE_EPOCH for
BUILD_TIME.

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

Thanks for maintaining centrifuge!

live well,
  vagrant
 From 02388806caa80233efa22e874ee1748da3f51109 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 22:22:14 +
Subject: [PATCH] Makefile: Use consistent build time and build host.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 66775a8..e24685e 100644
--- a/Makefile
+++ b/Makefile
@@ -248,8 +248,8 @@ both-debug: centrifuge-class-debug centrifuge-build-bin-debug
 
 DEFS=-fno-strict-aliasing \
  -DCENTRIFUGE_VERSION="\"$(GIT_VERSION)\"" \
- -DBUILD_HOST="\"`hostname`\"" \
- -DBUILD_TIME="\"`date`\"" \
+ -DBUILD_HOST="\"BUILDHOST\"" \
+ -DBUILD_TIME="\"`date --utc --date=@$(SOURCE_DATE_EPOCH) +%F`\"" \
  -DCOMPILER_VERSION="\"`$(CXX) -v 2>&1 | tail -1`\"" \
  $(FILE_FLAGS) \
 	 $(CFLAGS) \
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Philip Rinn]

Hi,

I followed 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_from_an_SD_card_image 
using the daily build of the unstable netboot installer from 
https://d-i.debian.org/daily-images/arm64/20221009-02:38/netboot/SD-card-images/ 
and I was able to install successfully but the system does not boot - it tries 
to boot from eMMC actually:


U-Boot SPL 2020.04+olimex-2-20210111.165338 (Jan 30 2020 - 11:10:18 +)
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE:  BL31: v2.2(debug):v2.2-8-g51ce3c6-dirty
NOTICE:  BL31: Built : 19:42:23, Mar 20 2020
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x40ab7d8, model: Olimex A64-Olinuxino-eMMC
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: Enabling DRIVEVBUS
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.360V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:PMIC: AXP803: dldo4 voltage: 3.300V
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2020.04+olimex-2-20210111.165338 (Jan 30 2020 - 11:10:18 +) Allwinner 
Technology


CPU:   Allwinner A64 (SUN50I)
Model: Olimex A64-Olinuxino-eMMC
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from EXT4... ** File not found /uboot.env **

** Unable to read "/uboot.env" from mmc0:1 **
In:serial
Out:   serial
Err:   serial
Allwinner mUSB OTG (Peripheral)
Net:   phy interface7
eth0: ethernet@1c3
Warning: usb_ether using MAC address from ROM
, eth1: usb_ether
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2904 bytes read in 1 ms (2.8 MiB/s)
## Executing script at 4fc0
30797760 bytes read in 1340 ms (21.9 MiB/s)
29408 bytes read in 3 ms (9.3 MiB/s)
32463063 bytes read in 1412 ms (21.9 MiB/s)
Booting Debian 5.19.0-2-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
   Loading Ramdisk to 4810a000, end 49fff8d7 ... OK
   Loading Device Tree to 480ff000, end 481092df ... OK

Starting kernel ...


[I didn't use the exact same board as the reporter but the industrial variant of 
that board - I don't see any reason why they should behave differently in that 
regard.]



When I tried to install u-boot again from an chroot, I got (/dev/sda is the 
SDCARD and I needed to install u-boot-sunxi):


$ sudo systemd-nspawn -q -E DEBIAN_FRONTEND=noninteractive -E LANG=C -E LC_ALL=C 
-D /PATH/WHERE/I/MOUNTED/THE/SDCARD --bind=/dev/sda -E 
TARGET=/usr/lib/u-boot/a64-olinuxino-emmc/ u-boot-install-sunxi64 /dev/sda
/usr/bin/u-boot-install-sunxi64: device/image (/dev/sda) uses GPT partition 
table, unusable on sunxi64



fdisk gives me:

Disk /dev/sda: 14,72 GiB, 15804137472 bytes, 30867456 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: SOME-UUID

DeviceStart  End  Sectors  Size Type
/dev/sda1  2048   999423   997376  487M Linux filesystem
/dev/sda2999424 28866559 27867136 13,3G Linux filesystem
/dev/sda3  28866560 30865407  1998848  976M Linux swap


To me it seems the debian-installer (or is it flash-kernel-installer?) is doing 
something wrong here ...


Might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000313


I'm happy to debug further, but I'm lost.

Best,
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021512: yersinia: reproducible-builds: build path embedded in /usr/bin/yersinia

[Vagrant Cascadian]

Source: yersinia
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/yersinia:

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

  /build/1st/yersinia-0.8.2/src/yersinia.c:104
  vs.
  /build/2/yersinia-0.8.2/2nd/src/yersinia.c:104

The attached patch to debian/rules fixes this by passing CFLAGS directly
to make, and adding -ffile-prefix-map to CFLAGS to avoid embedding build
paths.

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

Thanks for maintaining yersinia!

live well,
  vagrant
From 07a0c305ca6db96371243184b2c4469fd30c3d11 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 22:03:45 +
Subject: [PATCH] debian/rules: Pass CFLAGS directly to make, and add
 -ffile-prefix-map to CFLAGS to avoid embedding build paths.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 5e53fa6..c2f3893 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,8 @@ endif
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 CFLAGS = -Wall -g
+# Avoid embedding build path for reproducible builds
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
 
 config.status:
 	dh_testdir
@@ -37,7 +39,7 @@ build-stamp:  config.status
 	dh_testdir
 
 	# Add here commands to compile the package.
-	$(MAKE)
+	$(MAKE) CFLAGS="$(CFLAGS)"
 	#docbook-to-man debian/yersinia.sgml > yersinia.1
 
 	touch build-stamp
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021402: reproducible: Please force merged-/usr for build2

[Luca Boccassi]

Control: tags -1 patch

On Fri, 7 Oct 2022 at 16:21, Simon McVittie  wrote:
>
> Package: jenkins.debian.org
> Severity: normal
> X-Debbugs-Cc: usrme...@packages.debian.org, debian...@lists.debian.org
>
> The reproducible builds infrastructure tries to vary the merged-/usr
> status of the build system, like this:
>
> - base tarball: explicitly disable merged-/usr
> - build1: leave merged-/usr disabled
> - build2: pass "--extrapackages usrmerge" to pbuilder, to convert the
>   system to merged-/usr
>
> This has been very useful for detecting bugs of the same class as
> .
>
> However, now that new chroots are merged-/usr by default, I don't think
> this is working as intended. Disabling merged-/usr during base chroot
> creation now creates a flag file /etc/unsupported-skip-usrmerge-conversion
> representing "please don't merge /usr, contrary to the default", and
> installing the usrmerge package is not sufficient to undo the effect of
> that flag file.
>
> I believe the procedure to convert a non-merged-/usr QA chroot to
> merged-/usr is now something like this:
>
> 1. ensure the usrmerge package is installed
> 2. rm /etc/unsupported-skip-usrmerge-conversion
> 3. dpkg-reconfigure usrmerge
>
> Please do that for reproducible builds in build2, reinstating the
> previous setup where build1 is not merged-/usr but build2 is. I think
> implementing this on reproducible builds will require adding a pbuilder
> hook that does steps 2 and 3?

Turns out this is quite easy to implement, so here's a MR (only tested
in isolation):

https://salsa.debian.org/qa/jenkins.debian.net/-/merge_requests/143

Kind regards,
Luca Boccassi

Bug#1021085: closed by Debian FTP Masters (reply to Thorsten Glaser ) (Bug#1021085: fixed in mksh 59c-19)

[Vagrant Cascadian]

Control: found 1021085 59c-19

On 2022-10-02, Debian Bug Tracking System wrote:
>  mksh (59c-19) unstable; urgency=medium
...
>* Omit number of tests failed/ignored/passed from README.Debian
>  because fragile/ignore-fail tests make it unreproducible;
>  thanks lamby for noting (Closes: #1021085)

This still seems to finding it's way into the README.Debian:

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

  /usr/share/doc/mksh/README.Debian.gz

  D:loglibc:final(59c-19)·system=✔
  succeeded-tested[0f/583p]·mksh_klibc=✔
  succeeded-tested[0f/579p]·mksh_musl=✔
  succeeded-tested[0f/579p]·mksh_dietlibc=✔
  succeeded-tested[0f/579p]·mksh_glibc=✓ Absent·lksh_klibc=✔
  succeeded-tested[0f/577p]·lksh_musl=✓ Absent·lksh_dietlibc=✓
  Absent·lksh_glibc=✓ Absent·finishing

  D:loglibc:final(59c-19)·system=✔
  succeeded-tested[0f/583p]·mksh_klibc=✔
  succeeded-tested[0f/579p]·mksh_musl=✔
  succeeded-tested[0f/579p]·mksh_dietlibc=✔
  succeeded-tested[0f/579p]·mksh_glibc=✓ Absent·lksh_klibc=✔
  succeeded-tested[1_(1_ignored)f/576p]·lksh_musl=✓
  Absent·lksh_dietlibc=✓ Absent·lksh_glibc=✓ Absent·finishing


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1021511: liburi-perl: URI 5.13 breaks Net::Twitter::Lite::WithAPIv1_1

[gregor herrmann]

Package: liburi-perl
Version: 5.13-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have some scripts which use Net::Twitter::Lite::WithAPIv1_1 for
interacting with the Twitter API.

Today I noticed that they don't work anymore on my laptop (while the
same scripts with the same credentials still work on a machine
running testing). The failure is:

HTTP Response Code: 400
HTTP Message..: Bad Request
Twitter error.: 400: Bad Request
twitter_error.: $VAR1 = [
  {
'code' => 215,
'message' => 'Bad Authentication data.'
  }
];

After checking which package I had updated recently I found that liburi-perl
is the culprit; after downgrading to 5.12-1 the errors are gone.


No further debugging so far … So maybe libnet-twitter-lite-perl is
the problem and needs to adjust.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmNDQFdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgba5RAAqnge5vKNU+FLQsrtMO+XNtciuLJPTIqQyY7qP2lLHWIUPzOW+nOzl61u
ga7yJnNFsXju1w0oG8SFPoPFwn14eSyLiDtPLMUlUUKP7yCOLuTfBBXYfM9Obs2Y
2s2pQw77Ma5ccskatXTverSPaw9S9eA2xuqtqxrJdhyS3vZHhs5F/nszu7+/FBdz
Hn4Ssr+WpOU5xzfVixrYm8J+mu3qd8OsKR6dwRhrp/qLzhh5eEkpiDLb36WmL7v0
JLcQ438dKKWhEYBlmGuT5y8+yG7a8wkAYa4vi8ibph4cWjK0HFGbLkoc+tD2jWBH
BFiTsERqXk6eQJnwGfPNFwaYJ8U4ZFqYOztt2VWWZpnrPx9QCigFY7MFxEfXELq8
vx9M1uvS71/iXFoIv2AcWulgSGTk2m6Ihne4FiMez68uSDo1RLfBidIditpNd5TZ
mKrKiO8s1VBkt0zdpDzuobCkwrl8nFL46sipHv964eu4jD+hurYympnIHZThTond
mAGhGoCuOzkv3hvZRkaxXDtK6uu8ideSKxVwvhmkO267r2ndbXzoBgqVAp/U+JqO
9EnXyf/gaU2t8N6kpW7BbEQL+S/YlJOXuBNcszF2+PnbyCEX6Cmqyc1XINFIUpqR
LUYlMwWzm3A0LVLo/IJfkiF61W2OV7qlDWDaga3JP/wYZQiwzqw=
=oBwu
-END PGP SIGNATURE-

Bug#765848: pulseaudio: same problem on Debian 11.4

[Giuliano Cabrele]

Package: pulseaudio
Version: 14.2-2
Followup-For: Bug #765848
X-Debbugs-Cc: gcabrel...@gmail.com

Dear Maintainer,

 Casually disconnecting the earphones, when I connected them back I realized I 
had  had no sound.
 Acting on the audio widget and bringing up the audio configuration there was 
no "Line out" shown 
(only "Line in" present). 
The only way to recover the sound was to reboot with the earphones plugged-in.

I tried by booting on a different partition running Debian 10.14 and everything 
was ok:
 the "Line out"  remained present on the audio setting when diconnecting the 
earphones,
 and when plugging  them back the audio was immediately udible.
Same with a live version of Debian 10.
Therefore no HW problem.

Going back to 11.4 os, I tried to install pavucontrol-qt (0.16.0-1): 
the problem still persist, but now instead of having to reboot I just need
to bring up pavucontrol and without any further action the audio is back.



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-7
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-7
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-7
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 247.3-7

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio 

Bug#1021372: libsqlite0: not coïnstallable

[Thorsten Glaser]

László Böszörményi (GCS) dixit:

> Please note that src:sqlite and its binary packages are not part of
>Bullseye. The package you have installed on your system is a leftover

Oh, hmm.

>probably from Buster. For this reason I can't change a non-existing

That or from sid; this used to be a sid system but I switched to
bullseye to avoid UsrMove.

The package is still existing in sid, too.

> Honestly, I don't know why you don't migrate your legacy
>applications. The last sqlite release is from 2005 and we are heading

It’s not my application. I also have enough TODOs on my hands and
prefer to invest time into stuff under actual Open Source licences,
which SQLite isn’t, and don’t have the tuits needed to learn enough
about it to convert that software myself.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1009698: util-linux: more is less like more and more like less now :-)

[Martin Lester]

I just wanted to add that, like the original poster, I use more and
less for different purposes, and was unpleasantly surprised to
discover this change in testing.

Martin Lester.

Bug#1021510: lxqt-qtplugin: hardcoded dependencies on libfm-qt8

[Sebastian Ramacher]

Source: lxqt-qtplugin
Version: 0.16.0-1
Severity: serious

The libfm-qt started its transition from libfm-qt8 to libfm-qt11. Since
lxqt-qtplugin hardcodes a dependency on libfm-qt8, this dependency needs
to be fixed with a sourceful upload.

Cheers
-- 
Sebastian Ramacher

Bug#1021368: autopkgtest: quilt patches not applied on arm64, ppc64el, or s390x

[Paul Gevers]

Hi Olek,

On 09-10-2022 21:37, Olek Wojnar wrote:
I have just started the test on one of our workers manually and I can 
confirm that the patches are all applied.


Pardon my ignorance of the finer points of autopkgtest but is there a 
way to get more-verbose logging?


I started it with --shell-fail. That gave me a shell on the first test 
that failed and I could then easily confirm that the patches were applied.


Are you using the -ddd option? I can't 
figure out from the CI logs, for example, whether or not quilt 
successfully applied patches. One reason I thought patches might not be 
applied was that I never saw quilt being installed in the test bed.


I think since long you don't need quilt. IIRC dpkg will apply patches 
natively when you ask it via apt for the source.


Yes, please. Can you verify that the third_party/ijar/common.h file has 
the following on lines 24 and 25?

#include 
#include 


autopkgtest [03:49:26]: test java-1: ---]
autopkgtest [03:49:26]: test java-1:  - - - - - - - - - - results - - - 
- - - - - - -

java-1   FAIL non-zero exit status 1
autopkgtest [03:49:26]:  - - - - - - - - - - running shell - - - - - - - 
- - -
root@elbrus:/tmp/autopkgtest-lxc.ookvjd3p/downtmp/build.OBp/src# head 
-n25 third_party/ijar/common.h | tail -n2

#include 
#include 

Those are the lines that fix the "'numeric_limits' is not a member of 
'std'" error. If they are present, that confirms that 
add_include_for_limits.patch is definitely being applied correctly. But 
if that's the case, then I'm really stumped as to why we're seeing that 
failure and only on those architectures...


Unfortunately I can't help you with that.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021509: xxkb: reproducible-builds: build path embedded in /usr/bin/xxkb

[Vagrant Cascadian]

Source: xxkb
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/xxkb:

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

  /build/1st/xxkb-1.11.1/xxkb.c:73
  vs.
  /build/2/xxkb-1.11.1/2nd/xxkb.c:73

The attached patch to debian/rules fixes this by adding a dh_auto_build
override that passes the default CFLAGS as CCOPTIONS.

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

Thanks for maintaining xxkb!

live well,
  vagrant
From 0c91003ba8b5707f352faffd12b7cd6b2bae1122 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 19:48:15 +
Subject: [PATCH] debian/rules: Add dh_auto_build override passing default
 CFLAGS as CCOPTIONS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index d76fbcc..8fb8ca3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,5 +14,8 @@ override_dh_auto_install:
 	mv debian/tmp/usr/share/man/man1/xxkb.1x \
 		debian/tmp/usr/share/man/man1/xxkb.1
 
+override_dh_auto_build:
+	dh_auto_build -- CCOPTIONS="$(CFLAGS)"
+
 override_dh_installchangelogs:
 	dh_installchangelogs CHANGES.koi8
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021508: wxwidgets3.2: Use doxygen-awesome-css Debian package

[Bastian Germann]

Source: wxwidgets3.2
Version: 3.2.1+dfsg-1

The Debian package doxygen-awesome-css has just arrived in the archive.
Please consider replacing the embedded copy in 
docs/doxygen/doxygen-awesome-css with it.

Bug#1021372: libsqlite0: not coïnstallable

[GCS]

Hi Thorsten,

On Fri, Oct 7, 2022 at 12:39 AM Thorsten Glaser  wrote:
> Package: libsqlite0
> Version: 2.8.17-15
> Severity: important
> X-Debbugs-Cc: t...@mirbsd.de
>
> This library package lacks the Multi-Arch: same annotation
> but looks like it could easily get it.
 Please note that src:sqlite and its binary packages are not part of
Bullseye. The package you have installed on your system is a leftover
probably from Buster. For this reason I can't change a non-existing
package. You may grab the source package, change it and compile for
yourself on both i386 and amd64.

> I have legacy applications that are hard to recompile for which I
> need libsqlite0:i386, but to install that apt wants to remove sqlite
> (so I had to install sqlite:i386 which pulls in other :i386 libs
> unnecessarily).
 Honestly, I don't know why you don't migrate your legacy
applications. The last sqlite release is from 2005 and we are heading
towards 2023 when it becomes an adult in human sense. The src:sqlite3
has more possibilities and most importantly fixes against possible
data loss / security problems in the library.

Regards,
Laszlo/GCS

Bug#1021368: autopkgtest: quilt patches not applied on arm64, ppc64el, or s390x

[Olek Wojnar]

Hi Paul,

Thanks for the quick reply and the troubleshooting!

On 10/6/22 16:14, Paul Gevers wrote:

Hi Olek,

On 06-10-2022 22:05, Paul Gevers wrote:

On 06-10-2022 21:38, Olek Wojnar wrote:
It's entirely possible that this is also a problem in may package, 
which is
why I have the test suite there in the first place. However, I have 
not been

able to discover a reason why the tests run correctly on amd64 but fail,
exactly as they did before I wrote the patch, on the other 
architectures.


Thanks and happy to provide any additional information if it will help!


I notice this in the log, is that the patch you're talking about?

dpkg-source: warning: unexpected end of diff 
'src/debian/patches/remove_javac.patch'


No, that patch was just missing a newline, as I recall. The patch in 
question is:

debian/patches/add_include_for_limits.patch

I have just started the test on one of our workers manually and I can 
confirm that the patches are all applied.


Pardon my ignorance of the finer points of autopkgtest but is there a 
way to get more-verbose logging? Are you using the -ddd option? I can't 
figure out from the CI logs, for example, whether or not quilt 
successfully applied patches. One reason I thought patches might not be 
applied was that I never saw quilt being installed in the test bed.



With the following:

root@ci-worker-arm64-09:~# /usr/bin/autopkgtest --no-built-binaries 
--shell-fail --user debci --apt-upgrade --add-apt-release=unstable 
--pin-packages=unstable=src:bazel-bootstrap bazel-bootstrap -- lxc 
--sudo --name elbrus autopkgtest-testing-arm64


I get to test java-1 and after installing quilt I get this:
root@elbrus:/tmp/autopkgtest-lxc.7zdkbsmk/downtmp/build.loA/src# quilt push
File series fully applied, ends at patch debian/patches/remove_skylib.patch

and $(quilt pop -a) confirms I can removal all patches normally.


Ok, well it's good to know that everything applies correctly when done 
manually!


Is there anything else you want me to run in the testbed of the broken 
test (please be verbose)?


Yes, please. Can you verify that the third_party/ijar/common.h file has 
the following on lines 24 and 25?

#include 
#include 

Those are the lines that fix the "'numeric_limits' is not a member of 
'std'" error. If they are present, that confirms that 
add_include_for_limits.patch is definitely being applied correctly. But 
if that's the case, then I'm really stumped as to why we're seeing that 
failure and only on those architectures...


Thanks again!

-Olek


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021506: binutils-common: not co-installable due to differing content of /usr/share/man/man1/ld.gold.1.gz

[Johannes Schauer Marin Rodrigues]

Package: binutils-common
Version: 2.39-4
Severity: important

Hi,

in src:2.39-4, a Build-Depends on help2man was added. This enabled the
codepath checking "which help2man" in d/rules which leads to man pages
generated for ld.gold by help2man. These man pages differ for different
architectures and thus, binutils-common becomes uninstallable with
itself. Steps to reproduce:

$ mmdebstrap --arch=amd64,arm64 
--include=binutils-common:amd64,binutils-common:arm64 unstable /dev/null
[...]
Unpacking binutils-common:arm64 (2.39-6) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-E9IDZj/70-binutils-common_2.39-6_arm64.deb (--unpack):
 trying to overwrite shared '/usr/share/man/man1/ld.gold.1.gz', which is 
different from other instances of package binutils-common:arm64
Errors were encountered while processing:
 /tmp/apt-dpkg-install-E9IDZj/70-binutils-common_2.39-6_arm64.deb

The differing content looks like this (using amd64 and arm64 as an
example):

@@ -882,8 +882,8 @@
 \fB\-z\fR nokeep\-text\-section\-prefix
 Merge all .text.* prefix sections. (default)
 .PP
-debian/tmp/usr/bin/ld.gold: supported targets: elf32\-x86\-64 
elf32\-x86\-64\-freebsd elf32\-x86\-64\-nacl elf64\-x86\-64 
elf64\-x86\-64\-freebsd elf64\-x86\-64\-nacl elf32\-iamcu elf32\-i386 
elf32\-i386\-freebsd elf32\-i386\-nacl
-debian/tmp/usr/bin/ld.gold: supported emulations: elf32_x86_64 
elf32_x86_64_nacl elf_x86_64 elf_x86_64_nacl elf_iamcu elf_i386 elf_i386_nacl
+debian/tmp/usr/bin/ld.gold: supported targets: elf32\-iamcu elf32\-i386 
elf32\-i386\-freebsd elf32\-i386\-nacl elf32\-x86\-64 elf32\-x86\-64\-freebsd 
elf32\-x86\-64\-nacl elf64\-x86\-64 elf64\-x86\-64\-freebsd 
elf64\-x86\-64\-nacl elf64\-sparc elf32\-sparc elf64\-powerpcle elf64\-powerpc 
elf32\-powerpcle elf32\-powerpc elf32\-bigarm elf32\-bigarm\-nacl 
elf32\-littlearm elf32\-littlearm\-nacl elf32\-tilegx\-be elf64\-tilegx\-be 
elf32\-tilegx\-le elf64\-tilegx\-le elf64\-tradlittlemips 
elf32\-tradlittlemips\-nacl elf64\-tradbigmips elf32\-tradlittlemips\-nacl 
elf32\-tradlittlemips elf32\-tradlittlemips\-nacl elf32\-tradbigmips 
elf32\-tradlittlemips\-nacl elf64\-littleaarch64 elf64\-bigaarch64 
elf32\-littleaarch64 elf32\-bigaarch64 elf64\-s390 elf32\-s390
+debian/tmp/usr/bin/ld.gold: supported emulations: elf_iamcu elf_i386 
elf_i386_nacl elf32_x86_64 elf32_x86_64_nacl elf_x86_64 elf_x86_64_nacl 
elf64_sparc elf32_sparc elf64lppc elf64ppc elf32lppc elf32ppc armelfb 
armelfb_nacl armelf armelf_nacl elf32tilegx_be elf64tilegx_be elf32tilegx 
elf64tilegx elf64ltsmip elf32\-tradlittlemips\-nacl elf64btsmip 
elf32\-tradlittlemips\-nacl elf32ltsmip elf32\-tradlittlemips\-nacl elf32btsmip 
elf32\-tradlittlemips\-nacl aarch64_elf64_le_vec aarch64_elf64_be_vec 
aarch64_elf32_le_vec aarch64_elf32_be_vec elf64_s390 elf32_s390
 .SH "REPORTING BUGS"
 Report bugs to 
 .SH COPYRIGHT

Thanks!

cheers, josch

Bug#1021505: mir: FTBFS on hppa - symbols

[John David Anglin]

Source: mir
Version: 1.8.2+dfsg-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

For example, see:
https://buildd.debian.org/status/fetch.php?pkg=mir=hppa=1.8.2%2Bdfsg-4=1665340087=0

Regards,
Dave Anglin

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

Kernel: Linux 5.19.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1020702: prusa-slicer: SEGV on start

[Bernhard Übelacker]

Hello,
it looks like following line should expect the Get() call returning a nullptr,
which wxWidget documentation explicitly notes.

   2079
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);


I have raised this question to upstream here:

   https://github.com/prusa3d/PrusaSlicer/issues/9024

Kind regards,
Bernhard


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
234 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:
 Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
#1  std::__cxx11::basic_string, 
std::allocator >::_M_is_local (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:274
#2  std::__cxx11::basic_string, 
std::allocator >::capacity (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1134
#3  std::__cxx11::basic_string, std::allocator 
>::_M_assign (this=this@entry=0x0, __str=L"") at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:279
#4  0x7f258896e05a in std::__cxx11::basic_string, 
std::allocator >::assign (__str=L"", this=0x0) at 
/usr/include/c++/12/bits/basic_string.h:1540
#5  0x7f258896e0c6 in wxTranslations::SetLanguage (this=0x0, 
lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
#6  0x563e57fb8e26 in Slic3r::GUI::GUI_App::load_language (this=0x563e59d29200, 
language=..., initial=) at ./src/slic3r/GUI/GUI_App.cpp:2079
#7  0x563e57fbaaf5 in Slic3r::GUI::GUI_App::on_init_inner 
(this=0x563e59d29200) at ./src/slic3r/GUI/GUI_App.cpp:1093
#8  0x563e57fbd4c6 in Slic3r::GUI::GUI_App::OnInit (this=) 
at ./src/slic3r/GUI/GUI_App.cpp:1035
#9  0x7f258891feda in wxEntry (argc=, argv=) 
at ./src/common/init.cpp:487
#10 0x563e57f9f7b9 in Slic3r::GUI::GUI_Run (params=...) at 
./src/slic3r/GUI/GUI_Init.cpp:54
#11 0x563e577605de in Slic3r::CLI::run (this=, argc=, argv=) at ./src/PrusaSlicer.cpp:618
#12 0x563e57735bf4 in main (argc=, argv=) at 
./src/PrusaSlicer.cpp:844


https://docs.wxwidgets.org/3.0/classwx_translations.html#ab384ea68c44e74cfd2cd59e782529540

Bug#1019865: Debian Bug report logs - #1019865

[Andy Mann]

Package: evolution
Version: 3.45.3-2 / 3.46.0-2

I have since apt upgraded to version 3.46.0-2. 
I confirm the workaround for this problem, with the suggested disabling of 
requesting read receipts:
edit> preferences> composer preferences> UNTICK always request read receipt

The compose window then starts as normal. It also now starts as normal from the 
command line.

Bug#1019554: Stamp files are not updated

[Helge Kreutzmann]

Hello Lin,
thanks for your analysis and answer.

On Fri, Oct 07, 2022 at 12:34:33PM +, Lance Lin wrote:
> I believe I've found the issue! Sorry it has taken so long to get back to you 
> but I believe I have an answer.

Great! Thanks for your research.

> It seems to be related to an inadequate cleanup. I don't have a great 
> explanation but I found something that works.
> 
> The -33 version that removed the symlinks *somehow* (I am not sure) corrupted 
> the whole install. I've found that
> uninstalling anacron, removing the files associated with anacron and then 
> re-installing the package (-35) will 
> 
> yield a service that works.
> 
> Specifically, I removed:
> /var/lib/systemd/deb-systemd-helper-*/ ... anacron files [might not be 
> needed?]
> /var/lib/dpkg/info/anacron.* files [might not be needed?]
> /var/spool/anacron

I don't have them in my backups.

> /etc/anacrontab [I think this file is the problem!!]

This one is unchanged compared to older versions before the problem.

> Since you already have cron files, perhaps you could back them up, uninstall 
> anacron, remove the files, and then
> re-install anacron (-35), and then overlay your existing cron files? Would 
> you be so kind to test this out on 
> 
> your machine and see if this fixes it?

I will do this; however, I'm currently travelling with very little
access to my testing machine thus I will do this next weekend, I hope
this is ok.


> Thank you for your help in tracking this down!

You are welcome, thanks for tracking this down!

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#1021504: cargo: BD-Uninstallable: libgit2-dev

[Sebastian Ramacher]

Source: cargo
Version: 0.57.0-7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org


report:
 -
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: libgit2-dev:amd64 (< 1.4~~)


Cheers
-- 
Sebastian Ramacher

Bug#1021503: exim4-config installations fails with: absolute value of integer "2G" is too large (overflow)

[Frederic Peters]

Package: exim4-config
Version: 4.96-5
Severity: normal

Hi,

Updating to 4.96-5, the exim4-config update fails with:

2022-10-09 19:09:01 Exim configuration error in line 878 of 
/var/lib/exim4/config.autogenerated.tmp:
  absolute value of integer "2G" is too large (overflow)
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not installing
/var/lib/exim4/config.autogenerated.tmp to /var/lib/exim4/config.autogenerated
dpkg: error handling exim4-config (--configure):
 installed exim4-config package post-installation script subprocess returned 
error exit status 1

This is related to:

  * Change remote_smtp transports to set message_linelength_limit = 2G if
IGNORE_SMTP_LINE_LENGTH_LIMIT was set to avoid accepting messages (due to
IGNORE_SMTP_LINE_LENGTH_LIMIT disabling the limit in the ACLs) without
being able to pass them on. Closes: #1019959

I locally changed the configuration files to have
  message_linelength_limit = 1G, instead of 2G
and upgrade succeeded.


  Fred


-- Package-specific info:
Exim version 4.96 #2 built 09-Oct-2022 12:26:52
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2022
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS TLS_resume move_frozen_messages DANE 
DKIM DNSSEC Event I18N OCSP PIPECONNECT PRDR Queue_Ramp SOCKS SRS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 external plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4-config depends on:
ii  adduser3.129
ii  debconf [debconf-2.0]  1.5.79

Versions of packages exim4-config recommends:
ii  ca-certificates  20211016

exim4-config suggests no packages.

-- Configuration Files:
/etc/email-addresses changed [not included]
/etc/exim4/conf.d/router/200_exim4-config_primary changed [not included]
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp changed [not included]
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost changed [not 
included]
/etc/exim4/passwd.client [Errno 13] Permission non accordée: 
'/etc/exim4/passwd.client'

-- debconf information excluded

Bug#938929: Dependency problem with iptables and libvirt-daemon-system

[Maximilian Wilhelm]

Hey folks,

just set up a new KVM host on Bullseye and ran into the same problems. 
Our automation purges iptables after setting up nftables to have clean 
slate which also would remove libvirt-daemon-system here.


As I don't use any networking related features offered by libvirt I 
would consider it great if there wouldn't be a hard dependency on any 
related packages. Maybe the dependency on iptables could become a 
recommends?


Thanks and best regards,
Max

Bug#1020747: AM_PATH_PYTHON

[Jerome BENOIT]

Hello Bastien, thanks for your reply.

On Fri, 30 Sep 2022 14:31:47 + Bastien =?ISO-8859-1?Q?Roucari=E8s?= 
 wrote:

control: reassign -1 automake
control: affects -1 autoconf-archive


Hi,


The macro AM_PATH_PYTHON dos not support 3 level python version...



The `configure.ac' of graph-tool passes a 2 level python version to 
AM_PATH_PYTHON.



The bug lie in automake not autoconf-archive 



Could be workarround by a little sed script in order remove micro version on graph tool 
side


Can you please more specific here ?
Are you referred to the PYTHON_FULL_VERSION set up in `configure.ac' ?
If so, it was working well before ax_python_devel serial 32 went.
Second, I am not sure that removing micro version for devel stuff is a good 
idea.

Best wishes,
Jerome




Bastien


--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.115.3
Severity: important

Hi!

I have:

  $ grep -n '(0\.1\.14)' debian/NEWS
  1:apt-listbugs (0.1.14) unstable; urgency=medium
  $ grep -n '(0\.1\.14)' debian/changelog
  391:apt-listbugs (0.1.14) unstable; urgency=medium

in my package ('apt-listbugs').

Running "lintian -EviIL +pedantic" on the .changes file generates
the following report:

  N:
  W: apt-listbugs: debian-news-entry-has-unknown-version 0.1.14 
[usr/share/doc/apt-listbugs/NEWS.Debian.gz:1]
  N:
  N:   The version number of the most recent NEWS.Debian entry does not match 
any
  N:   of the version numbers in the changelog file for this package. This
  N:   usually means the version in NEWS.Debian needs to be updated to match a
  N:   change to package version that happened after the NEWS.Debian entry was
  N:   written.
  N:
  N:   Visibility: warning
  N:   Show-Always: no
  N:   Check: debian/changelog
  N:
  N:


The report does not look right: it seems to me that version 0.1.14 is
indeed present in the changelog file of my package!

Please investigate and fix this bug in lintian.
Thanks for your time!




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

Kernel: Linux 5.18.0-4-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 lintian depends on:
ii  binutils2.39-6
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libencode-perl  3.19-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes

[Sven Eckelmann]

On Thu, 05 Aug 2021 21:08:44 +0300 Teemu Likonen  wrote:
> I have more information about Libreoffice's freezes when "Tools /
> Options..." is opened. There is "gpg" process running forever and taking
> lots of CPU time. The "ps" command says that command line is:
> 
> gpg --batch --no-sk-comments --status-fd 37 --no-tty --charset utf8 \
> --enable-progress-filter --exit-on-status-write-error --display :0 \
> --ttyname /dev/pts/0 --ttytype xterm-256color --logger-fd 41 \
> --with-colons --with-keygrip --list-secret-keys --

Can you run `sudo strace -p $PID_OF_GPG_PROCESS` to check if it tries to 
access a file and then fails doing that? If this is the case, please check 
with `ls -l /proc/$PID_OF_GPG_PROCESS/fd/`, which is the file behind the 
mentioned file descriptor in the strace output.

If it is really failing because of this, please teardown the rules for 
apparmor with `sudo aa-teardown` and then restart libreoffice and try to go to 
the menu which was mentioned earlier. See also #955271 for a patch to 
/etc/./apparmor.d/usr.lib.libreoffice.program.soffice.bin and information how 
it will be fixed in future Debian versions

Kind regards,
Sven

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

Bug#1017064: lintian: incorrectly complains about adopted-extended-field XB-Ruby-Versions

[Francesco Poli]

Control: found -1 lintian/2.115.3


On Fri, 12 Aug 2022 18:03:50 +0200 Francesco Poli (wintermute) wrote:

[...]
> Both reports look wrong, since I have no plain 'Ruby-Versions'
> field in my package source, and 'XB-Ruby-Versions' has not been
> adopted, thus requiring the 'XB-' prefix.
> 
> Please fix this bug in lintian.
> Thanks for your time and patience!

This bug is still present in the lintian version currently in sid.
Please fix it.


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


pgpBd6gxuKSin.pgp
Description: PGP signature

Bug#1021501: RFS: shaderc/2022.2-1 [ITP] -- Library API for accessing glslc functionality - shared libraries

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : shaderc
   Version  : 2022.2-1
   Upstream contact : David Neto 
 * URL  : https://github.com/google/shaderc/
 * License  : Apache-2.0, BSD-3-clause
 * Vcs  : https://salsa.debian.org/debian/shaderc
   Section  : libs

The source builds the following binary packages:

  glslc - Command line compiler for GLSL/HLSL to SPIR-V
  libshaderc-dev - Library API for accessing glslc functionality -
static libraries and headers
  libshaderc1 - Library API for accessing glslc functionality - shared
libraries

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2022.2-1.dsc

Changes for the initial release:

 shaderc (2022.2-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #890472)

Regards,
--
  Philippe.

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[David Kalnischkies]

On Sun, Oct 09, 2022 at 10:26:39AM +0800, Paul Wise wrote:
> I have often wanted a different kind of relationship between packages
> and their dbgsym packages than mere Depends. Currently when a dbgsym is
> installed it keeps the library package installed even after it is no
> longer used and both should be auto-removed. 

I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.
Okay, foo-dbgsym doesn't enhance the functionality of foo directly,
but declaring it "enhances default-core-viewer | gdb" is not really
a useful remark and surely, like with a "normal" plugin, its usefulness
shrinks to fringe use cases without foo being present (at least in the
form of a core file produced by it).


apt currently doesn't handle Enhances in terms of auto-removal, but I
would be willing to change it so that:
foo is manually installed: all things enhancing it are not auto-removed.
foo is auto-installed: considered for auto-removal if all things
enhancing it are also auto-removable (or in other words: foo-dbgsym is
manually installed: all things enhanced by it are not auto-removed).


That should give you the property that if nothing depends on foo anymore
and you don't have anything enhancing it manually installed, it will be
auto-removed, while foo and its enhancing foo-dbgsym (or plugin or
whatever) stay around as long as foo is still in use – which allows you
to set foo-dbgsym to auto-installed after you have it (manually)
installed, while e.g. Helmut can install foo-dbgsym without installing
a (for him) useless foo keeping it on manual and hence having it stick
around.


Looking at existing Enhances I can imagine this doing the right thing™
also for more normal plugins and other enhancers:

If you want to use emacs mode you have to install a mode – emacs is
brought in via a Recommends if its not already there. You can't express
that you installed that mode for emacs only. You have to keep it
manually installed or otherwise current apt autoremoves it. It also
keeps emacs installed even if you later decide its not your thing and
apt could autoremove it. With the change above you could set the mode to
auto-installed and have apt do its thing after emacs is [auto]removed.

Similar, if you install abook to use it from inside mutt, you have to
keep it manually installed – which perhaps you want as that is how you
manage your adressbock and want to keep it even if mutt is gone, but you
can't express the opposite: That you have no need for abook if mutt (or
any other thing it might enhance) isn't around anymore.


Enhance is mainly used by software centers currently to show plugins and
stuff so you can explicitly install it – as in, they will all end up
being manually installed. Software centers usually hide things of no
interest to casual users, so I am reasonably sure dbgsyms are already
hidden (otherwise they would already appear in searches and such).

That means that potentially less things are considered for autoremoval
with the above change: In the emacs case (and many others) the enhanced
foo is not considered for auto-removal due to an existing and already
interpreted Depends/Recommends/Suggests, so no change. In the (less
common) case¹ of installing abook on its own and having mutt brought
in via an unrelated unused dependency chain it would now keep mutt
installed as long as abook is considered manually installed.
Also, the reverse is true.

Keeping "too many" things installed is already a problem as we have no
idea if a Recommends/Suggests is really used for anything or if it was
brought in for completely unrelated reasons and is now unused (or if it
was brought in for unrelated reasons, but the user discovered and
heavily uses it via the other tool recommending it). We err on removing
"too few" in all those cases as that is usually a much smaller problem
in practice, so that doesn't feel like too big of a difference.


I left it intentionally open if and who does set foo-dbgsym to
auto-installed after it is installed. 'apt install foo-dbgsym' gives you
a manually installed foo-dbgsym and you would need to 'apt-mark auto'
it afterwards. I think aptitude can do that in one go. I would probably
add a way in apt as well (a NeverManual similar to NeverAuto perhaps),
but certainly not by default (imagine the emacs example from above, if
the enhancer would be set to auto-installed by default and emacs wasn't
installed before they would both considered garbage upon install…).


On a sidenote: What the Depends ensures which the Enhances doesn't is
that they are upgraded in lockstep. As in, if for some reason foo (or
foo-dbgsym) have their version appear at different points in the archive
apt would hold back on a Depends while with Enhances this dependency
would be broken and hence auto-remove kicks in. That might actually be
a benefit through as if you remove the debug section from your sources
a hold back is not really a good idea. It seldomly is a good idea for
various reasons (hence why apt likes to go 

Bug#1021500: rssguard: Crashes randomly after refreshing feeds

[Juan Marín Noguera]

Package: rssguard
Version: 4.0.4+dfsg-1+b1
Severity: important

Dear Maintainer,

I am using RSSGuard as a client for Nextcloud News, but recently (since
some point in time between September 26 and October 7) the program has
started crashing unpredictably after some time using it.  This usually
happens after some action like refreshing the feeds or copying the URL
of some feed, but so far I have been unable to find the root cause, as
it does not happen right after any user input, or even when the window
is focused.

These are the last lines of the log from one of the crashes.  The
failing malloc does not happen immediately after the previous lines.

```
time="   249.327" type="debug" -> database: Message with custom ID '1225' is 
already present in DB and has DB ID '1228'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1224' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1224' is 
already present in DB and has DB ID '1229'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1223' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1223' is 
already present in DB and has DB ID '1230'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1221' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1221' is 
already present in DB and has DB ID '1231'.
time="   249.328" type="debug" -> feed-downloader: Updating messages in DB took 
27394 microseconds.
time="   249.328" type="debug" -> feed-downloader: QPair(0,0) messages for feed 
29 stored in DB.
time="   249.328" type="debug" -> feed-downloader: Made progress in feed 
updates, total feeds count 1/32 (id of feed is 1).
time="   249.328" type="debug" -> feed-downloader: Downloading new messages for 
feed ID '4' URL: 'https://www.debian.org/News/news' title: 'Debian News' in 
thread: '0x7f41f3fff640'.
time="   249.328" type="debug" -> database: SQLite connection 'feed_upd' is 
already active.
time="   249.328" type="debug" -> database: SQLite database connection 
'feed_upd' to file '/home/juan/.config/RSS Guard 4/database/database.db' seems 
to be established.
time="   249.328" type="debug" -> network: Settings of BaseNetworkAccessManager 
loaded.
time="   249.331" type="debug" -> feed-model: There is request to reload feed 
model, reloading the 1 items individually.
time="   249.333" type="debug" -> feed-model: There is request to reload feed 
model, reloading the 1 items individually.
time="   249.775" type="debug" -> network: Destroying Downloader instance.
time="   249.775" type="debug" -> network: Destroying 
SilentNetworkAccessManager instance.
time="   249.775" type="critical" -> nextcloud: Feeds update failed with error 
'QNetworkReply::ContentAccessDenied'.
time="   249.775" type="debug" -> network: Settings of BaseNetworkAccessManager 
loaded.
malloc(): unaligned fastbin chunk detected
Aborted
```

Thank you for supporting Debian and free software.  Please let me know
if you need more details or I can help some other way.


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

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

Versions of packages rssguard depends on:
ii  libc62.35-2
ii  libgcc-s112.2.0-5
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5dbus5  5.15.6+dfsg-2
ii  libqt5gui5   5.15.6+dfsg-2
ii  libqt5multimedia55.15.6-2
ii  libqt5network5   5.15.6+dfsg-2
ii  libqt5qml5   5.15.6+dfsg-2
ii  libqt5sql5   5.15.6+dfsg-2
ii  libqt5sql5-sqlite5.15.6+dfsg-2
ii  libqt5webenginecore5 5.15.10+dfsg-7
ii  libqt5webenginewidgets5  5.15.10+dfsg-7
ii  libqt5widgets5   5.15.6+dfsg-2
ii  libqt5xml5   5.15.6+dfsg-2
ii  libstdc++6   12.2.0-5

rssguard recommends no packages.

rssguard suggests no packages.

-- no debconf information

Bug#1021499: fim: --slideshow=5 is buggy. doesn't show first picture, and 'q' doesn't quit

[d3fault]

Package: fim
Version: 0.5.3-9+b1
Severity: normal
X-Debbugs-Cc: d3faultdot...@gmail.com

Dear Maintainer,

   * What led up to the situation?
  fim --slideshow=5 ./*.jpg
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  I looked at the screen. I also pressed 'q'.
   * What was the outcome of this action?
  The first image of the slideshow was just all black. The 2nd+
images do show.
  Also if you press 'q' while the slideshow is still running, the
app doesn't quit
  but instead it just progresses to the next image. After all the
images have been
  shown, then 'q' will quit. I would also expect slideshow mode to
loop around
  indefinitely, but that's not really a bug.
   * What outcome did you expect instead?
  I expected to see the first image. I also expected 'q' to quit the app.

Also confirmed the bug exists on Bullseye.
It works fine in fbi.


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

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

Versions of packages fim depends on:
ii  libaa1   1.4p5-50
ii  libc62.35-3
ii  libdjvulibre21   3.5.28-2
ii  libexif120.6.24-1+b1
ii  libgcc-s112.2.0-5
ii  libgif7  5.2.1-2.5
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpng16-16  1.6.38-2
ii  libreadline8 8.2-1
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   12.2.0-5
ii  libtiff5 4.4.0-4

fim recommends no packages.

fim suggests no packages.

-- no debconf information

Bug#1020827: grep: warning: stray \ befor ...

[Richard Lewis]

On Tue, 27 Sep 2022, 09:27 Stefano Callegari,  wrote:

> I have an email like this every cron

> grep: warning: stray \ before !
> grep: warning: stray \ before "
> grep: warning: stray \ before "
> grep: warning: stray \ before &
> grep: warning: stray \ before "
> grep: warning: stray \ before "
> grep: warning: stray \ before "
>
> and many more lines.

Think this is an issue in the rules shipped by debian - there have
been some unwanted backslashes in some rules files for ages, and
apparently  grep has started warning about these. The rules should
only quote things that are special for regular expressions, so +, ., *
( etc, but not other characters

The patch in  https://salsa.debian.org/debian/logcheck/-/merge_requests/14
should fix these - please review!

Bug#1021498: tcm: reproducible-builds: build path embedded in /usr/bin/tcm

[Vagrant Cascadian]

Source: tcm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/tcm:

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

  /build/1st/tcm-2.20+TSQD/src/ed/helper.c:31·(discriminator·2)
  vs.
  /build/2/tcm-2.20+TSQD/2nd/src/ed/helper.c:31·(discriminator·2)

The attached patch to debian/rules fixes this by adding
-ffile-prefix-map to CFLAGS.

Alternately, using the default CFLAGS from dpkg-buildflags or switching
to "dh" and a recent debhelper compat level might resolve this issue.

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

Thanks for maintaining tcm!

live well,
  vagrant
From 8b76667fe07f16eaf520949a19b9e2a96dcb61e9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Oct 2022 16:42:54 +
Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CFLAGS to avoid
 embedding build paths.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 7d92a0c..85e1a8a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,8 @@ include /usr/share/dpkg/buildtools.mk
 
 CFLAGS = -Wall -g
 CFLAGS	+= -fcommon
+# Avoid embedding build paths
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 CFLAGS += -O0
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021497: autopkgtest: Provide a way to escape # character in Test-Command

[Fab Stz]

Package: autopkgtest
Version: 5.16
Severity: normal

Dear Maintainer,

If I have such a line in the d/tests/control

Test-Command: modprobe --verbose --set-version "$(for kernel in /boot/config-
*;
do echo ${kernel#*-}; done | tail -n1)" my_kernel_module

It will consider the command is only

modprobe --verbose --set-version "$(for kernel in /boot/config-*; do echo
${kernel

Everything after '#' is ignored, as stated in [1]

Would you provide a way to escape it? I don't know how though...

For example in debhelper [2] to escape a $, they suggest ${Dollar}. Or for a
new line, they would do ${Newline}. So maybe something similar, like ${Hash} 
or
${NumberSign}. But the use of the dollar sign, wouldn't be very optimal since
it already has a meaning in shell.

[1] 
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
[2] https://manpages.debian.org/bullseye/debhelper/debhelper.7.en.html

For now, I put the command in a separate script called with "Command:"



-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.2.4
ii  libdpkg-perl1.20.12
ii  procps  2:3.3.17-5
ii  python3 3.9.2-3
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
pn  ovmf  
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:5.2+dfsg-11+deb11u2
ii  schroot   1.6.10-12+deb11u1
ii  vmdb2 0.22-1

Bug#1021496: anacron: cron.daily stopped executing a month ago

[Ralf Jung]

Package: anacron
Version: 2.3-35
Severity: important

Dear Maintainer,

I just realized that my cron.daily jobs stopped being executed about a month 
ago.
'sudo journalctl | grep cron.daily' shows

Sep 04 14:28:19 r-thinktop anacron[12633]: Job `cron.daily' started
Sep 04 14:28:19 r-thinktop anacron[13691]: Updated timestamp for job 
`cron.daily' to 2022-09-04
Sep 04 14:28:20 r-thinktop anacron[12633]: Job `cron.daily' terminated
Sep 05 09:59:36 r-thinktop anacron[34905]: Will run job `cron.daily' in 5 min.
Sep 05 10:04:36 r-thinktop anacron[34905]: Job `cron.daily' started
Sep 05 10:04:36 r-thinktop anacron[36056]: Updated timestamp for job 
`cron.daily' to 2022-09-05
Sep 05 10:04:37 r-thinktop anacron[34905]: Job `cron.daily' terminated
Sep 06 09:24:00 r-thinktop anacron[40089]: Will run job `cron.daily' in 5 min.
Sep 06 09:29:00 r-thinktop anacron[40089]: Job `cron.daily' started
Sep 06 09:29:00 r-thinktop anacron[40715]: Updated timestamp for job 
`cron.daily' to 2022-09-06
Sep 06 09:29:01 r-thinktop anacron[40089]: Job `cron.daily' terminated
Sep 07 09:46:33 r-thinktop anacron[54913]: Will run job `cron.daily' in 5 min.
Sep 07 09:51:33 r-thinktop anacron[54913]: Job `cron.daily' started
Sep 07 09:51:33 r-thinktop anacron[55857]: Updated timestamp for job 
`cron.daily' to 2022-09-07
Sep 07 09:51:33 r-thinktop anacron[54913]: Job `cron.daily' terminated
Sep 08 11:38:05 r-thinktop anacron[67536]: Will run job `cron.daily' in 5 min.
Sep 08 11:43:05 r-thinktop anacron[67536]: Job `cron.daily' started
Sep 08 11:43:05 r-thinktop anacron[69218]: Updated timestamp for job 
`cron.daily' to 2022-09-08
Sep 08 11:43:06 r-thinktop anacron[67536]: Job `cron.daily' terminated

and then it ends.
This is a problem, since obviously many things rely on these cron jobs running 
regularly.
For example, one of my SSL certificates expired because of this.

Kind regards,
Ralf

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

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

Versions of packages anacron depends on:
ii  libc6  2.35-1
ii  lsb-base   11.4
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-149

Versions of packages anacron suggests:
ii  postfix [mail-transport-agent]  3.6.4-1+b3
ii  powermgmt-base  1.37
ii  rsyslog [system-log-daemon] 8.2208.0-1

-- no debconf information

Bug#1020487: "grep: warning: stray \ before /" during setup

[Hilmar Preuße]

Control: reassign -1 ucf
Control: severity -1 important
Control: merge -1 1019326

Am 22.09.2022 um 08:00 teilte Hilmar Preusse mit:


Dear Maintainer,

during setup of the package we see a lot of:

Setting up texlive-base (2022.20220722-1) ...
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /



Seems to be caused by ucf: reassign, merge.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021495: ITP: lomiri-gallery-app -- Gallery App for Lomiri Operating Environment

[Mike Gabriel]

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

* Package name: lomiri-gallery-app
  Version : 2.10.9
  Upstream Author : UBports Developers 
* URL : 
https://gitlab.com/ubports/development/apps/lomiri-gallery-app
* License : GPL-3
  Programming Lang: C++/QML
  Description : Gallery App for Lomiri Operating Environment

 This app is a core app for Ubuntu Touch's shell Lomiri. Ubuntu Touch is
 a mobile OS developed by the UBports Foundation. Lomiri is its operating
 environment optimized for touch based human-machine interaction, but
 also supports convergence (i.e. switching between tablet/phone and
 desktop mode).
 .
 This package provides Lomiri's Gallery App.
 .
 This package will be maintained by Debian's UBports Packaging Team.

Bug#1021494: libmatroska7: Please package 1.7.1

[Christian Marillat]

Package: libmatroska7
Version: 1.6.3-2
Severity: normal
X-Debbugs-Cc: maril...@debian.org

Dear Maintainer,

1.7.1 is needed by mkvtoolnix 71.1.0 package.

Also update the libebml-dev build-dependency and dependency for the
libmatroska-dev package to 1.4.4 as this version is required.

Christian

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

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

Versions of packages libmatroska7 depends on:
ii  libc6   2.35-3
ii  libebml51.4.2-2+b1
ii  libgcc-s1   12.2.0-5
ii  libstdc++6  12.2.0-5

libmatroska7 recommends no packages.

libmatroska7 suggests no packages.

-- no debconf information

Bug#1021493: ITP: overte -- 3D social virtual worlds software

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: overte
  Version : 2022.09.1
  Upstream Author : Overte e.V.
* URL : https://overte.org/
* License : Apache-2.0
  Programming Lang: C++, JvaScript
  Description : 3D social virtual worlds software

 Overte is a 3D social virtual worlds software.
 .
  * Desktop and VR use
  * Hundreds of users simultaneously
  * Collaborative in-world creation
  * Full-body avatars
  * FBX, glTF, and OBJ support
  * JavaScript scripting engine
  * 16km³ world space in a server
  * Fully self-hosted

This package will be maintained in the collaborative Debian section of
Salsa, at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNC7HIACgkQLHwxRsGg
ASHo9Q//S+0PHzaC9bnaNLpq4ts89TNenefKq94psUCh2wAYN6SiRE87Z6OLSTFt
X/stItnMTlVjVl8+Di2U5LAq7eXc2SEaP8ElSJKs46gDO8wzrU2pV2Pr4Rfp+D2O
7wDQQ4bIoA7cZiDKVxjVgTylaQ7hT2is+QrmaXiLspb6z905xqeqTO2ZGCT4hUML
TZeXoF//ZxdwMX/D25kqxKne5UIZMVzbnl0NIFBbAUVXBr5ILCZibu4GIyn2jurV
dlS/o8tTM1hQhhrPCvuAGh0NUujBmehuCIrBIpvNf7QKQBsZaG4pMEPwNULefYF3
rqaI8GaEQW3Ec29njrR55vY23Qz//+GFUiSGT8SrjPb6gGHcHUImXgXpWy8qXvkD
4oCk77h10W1nZ0KsshTd9OEwQkHaAfX9p2JNjarrZUIDsL03YbPEt4GGYowr+mGM
4hEPwndvauSK1Os2P41wYf2UjSnUOzSuAbEbBFlxVfUd0n5p7puqSBYbLkmzXcOh
bYPwRmYnbapxniB68Owue+knob5hx8/y8lrc2je/1gmPYwemJtmI8tdA98tePys/
Kxq3ZBSsU17Rbk67sNzBF/7x7Wj4G7pnkPXS2Ku4lRKRqcEts3PLm73pxFB4fBqd
JsvHSMC6ErutICRmYLFhpmAej4rr5Yy0SIKwkqQaYXkoPLno4Y8=
=hsV9
-END PGP SIGNATURE-

Bug#1020677: httraqt: Segfault upon mirroring initiation

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and found unfortunately the dbgsym package
not containing useful files.

This seems related to CMAKE_CXX_FLAGS getting reset,
therefore loosing Qt related flags.

Before the application crashed already when trying to open
one leaf in the tree view, with the Qt flags this crash did not happen,
so this might be related.

The second patch just removes a leftover CMakeLists.txt.rej from a previous 
patch.

Kind regards,
Bernhard


Before:
-- CMAKE_CXX_FLAGS -O3 -DNDEBUG -Wall

After:
-- CMAKE_CXX_FLAGS -g -O2 
-ffile-prefix-map=/home/benutzer/source/httraqt/git/httraqt=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wall -DQT_NO_DEPRECATED_WARNINGSFrom 1349c117855ba576dd9eb7aea2612550c58a1727 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:29:40 +0200
Subject: Remove CMakeLists.txt.rej from 10_reproducible_build.patch.

---
 debian/patches/10_reproducible_build.patch | 27 --
 1 file changed, 27 deletions(-)

diff --git a/debian/patches/10_reproducible_build.patch b/debian/patches/10_reproducible_build.patch
index 22f5ebb..7a620e5 100644
--- a/debian/patches/10_reproducible_build.patch
+++ b/debian/patches/10_reproducible_build.patch
@@ -17,30 +17,3 @@ Last-Update: 2017-07-18
  MESSAGE("-- Version build date: ${BUILD_DATE}")
  
  configure_file (
 /dev/null
-+++ httraqt-1.4.9/CMakeLists.txt.rej
-@@ -0,0 +1,24 @@
-+--- CMakeLists.txt
- CMakeLists.txt
-+@@ -6,7 +6,7 @@ CMAKE_POLICY(SET CMP0003 OLD)
-+ CMAKE_POLICY(SET CMP0015 OLD)
-+ 
-+ # if you use the version 5, please change it to 5
-+-SET(USE_QT_VERSION 4)
-++SET(USE_QT_VERSION 5)
-+ 
-+ MESSAGE("Qt version for compiling: " ${USE_QT_VERSION})
-+ 
-+@@ -62,12 +62,6 @@ set(APP_RESOURCES  "${PROJECT_SOURCE_DIR
-+ MESSAGE("-- Version info: ${HTTRAQT_VERSION}") 
-+ SET(VERSION ${HTTRAQT_VERSION})
-+ 
-+-EXECUTE_PROCESS (
-+-  COMMAND date +"%d %b %Y"
-+-  COMMAND sed -e "s/\"//g"
-+-  OUTPUT_VARIABLE BUILD_DATE
-+-  OUTPUT_STRIP_TRAILING_WHITESPACE)
-+-
-+ MESSAGE("-- Version build date: ${BUILD_DATE}")
-+ 
-+ configure_file (
-- 
2.35.1

From a678025eece455ffcc3916c65bfac194b5747b1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:34:36 +0200
Subject: Do not override CMAKE_CXX_FLAGS.

Adds additionally QT_NO_DEPRECATED_WARNINGS as those warnings
might be mostly useful for upstream developers.
---
 .../30_do_not_override_CMAKE_CXX_FLAGS.patch  | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch

diff --git a/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
new file mode 100644
index 000..b11608a
--- /dev/null
+++ b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
@@ -0,0 +1,21 @@
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 1310490..a51d391 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -26,11 +26,14 @@ OPTION (USE_PROFILER "Include in binary file profiling information" OFF)
+ 
+ 
+ IF(${USE_DEBUGGER})
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_DEBUG} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG} -Wall")
+ ELSE()
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_RELEASE} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} -Wall")
+ ENDIF()
+ 
++SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DQT_NO_DEPRECATED_WARNINGS")
++
++
+ MESSAGE(STATUS "CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}")
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8d027f0..43c04ea 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 10_reproducible_build.patch
 20_cross.patch
+30_do_not_override_CMAKE_CXX_FLAGS.patch
-- 
2.35.1

Bug#1018003: comment

[mYnDstrEAm]

In the totally outdated issue tracker I can't edit the text: it doesn't crash 
anymore because as a workaround I have the monitor HDMI cable disconnected 
except when I use it.



When connecting the HDMI cable, the session ends only when the monitor that the 
HDMI cable is plugged into is turned off. The wallpaper is changed to a default 
one nevertheless. Currently, the remaining problem is that when doing one of 
these things to switch the monitor back again the sessions as well: a) pulling 
out the HDMI cable b) switching off the active second monitor c) press meta+p 
and selecting "Unify outputs" (haven't tried the other ones yet).

For the workout to be complete, I only need to find out how to switch back to 
the formerly active display without the session ending. I'll try a few more 
things later such as going into standby, then pulling out the HDMI cable, and 
waking it again. If somebody knows a working workaround, please comment.

Bug#1021492: libhttrack-dev: Generates many warnings about missing spaces between literal and string macro.

[Bernhard Übelacker]

Package: libhttrack-dev
Version: 3.49.2-1.1+b1
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
currently the header htsglobal.h generates many warnings in
build of depending package httraqt.

/usr/include/httrack/htsglobal.h:211:28: warning: invalid suffix on literal; 
C++11 requires a space between literal and string macro [-Wliteral-suffix]
  211 | #define HTS_DEFAULT_FOOTER ""

Attached a diff to add those few spaces to htsglobal.h.

Kind regards,
Bernhard



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

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

Versions of packages libhttrack-dev depends on:
ii  libc62.35-2
ii  libhttrack2  3.49.2-1.1+b1
ii  zlib1g-dev   1:1.2.11.dfsg-4.1

libhttrack-dev recommends no packages.

libhttrack-dev suggests no packages.

-- no debconf informationFrom cd855083532d8146d00694fafdb480f17fc7ccee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 17:13:49 +0200
Subject: Avoid warning because of missing space between literal and string
 macro.

/usr/include/httrack/htsglobal.h:211:28: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
  211 | #define HTS_DEFAULT_FOOTER ""
---
 ..._space_between_literal_and_string_macro.patch | 16 
 debian/patches/series|  1 +
 2 files changed, 17 insertions(+)
 create mode 100644 debian/patches/10_avoid_warning_because_missing_space_between_literal_and_string_macro.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/10_avoid_warning_because_missing_space_between_literal_and_string_macro.patch b/debian/patches/10_avoid_warning_because_missing_space_between_literal_and_string_macro.patch
new file mode 100644
index 000..0cf02cb
--- /dev/null
+++ b/debian/patches/10_avoid_warning_because_missing_space_between_literal_and_string_macro.patch
@@ -0,0 +1,16 @@
+diff --git a/src/htsglobal.h b/src/htsglobal.h
+index 65ba1c6..72139e3 100644
+--- a/src/htsglobal.h
 b/src/htsglobal.h
+@@ -208,9 +208,9 @@ Please visit our Website: http://www.httrack.com
+ 
+ /* Copyright (C) 1998-2017 Xavier Roche and other contributors */
+ #define HTTRACK_AFF_AUTHORS "[XR'2014]"
+-#define HTS_DEFAULT_FOOTER ""
++#define HTS_DEFAULT_FOOTER ""
+ #define HTTRACK_WEB "http://www.httrack.com;
+-#define HTS_UPDATE_WEBSITE "http://www.httrack.com/update.php3?Product=HTTrack="HTTRACK_VERSIONID"="HTTRACK_VERSION"=%d=%s;
++#define HTS_UPDATE_WEBSITE "http://www.httrack.com/update.php3?Product=HTTrack=; HTTRACK_VERSIONID "=" HTTRACK_VERSION "=%d=%s"
+ 
+ #define H_CRLF "\x0d\x0a"
+ #define CRLF   "\x0d\x0a"
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..fe50f7a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+10_avoid_warning_because_missing_space_between_literal_and_string_macro.patch
-- 
2.35.1

Bug#1018003: comment

[mYnDstrEAm]

May also be related to "Plasmashell problems after changing the HDMI output and 
KDE does not recognize the new display": 
https://bugs.kde.org/show_bug.cgi?id=457755

Currently, it doesn't crash anymore but I often need to go to an alt+f3 (any 
number) terminal and run `loginctl unlock-session {id}` and `logout` to resume 
the session.

Bug#1021491: ntfs-3g: set /sbin/mount.ntfs as alternatives

[Fab Stz]

Package: ntfs-3g
Version: 1:2017.3.23AR.3-4+deb11u2
Severity: wishlist
Tags: patch

Dear Maintainer,

For now, the /sbin/mount.ntfs file is a symlink to mount.ntfs-3g

I would like to have both ntfs-3g and another driver installed and for that, I
would like to be able to choose whether mount.ntfs is the one of ntfs-3g, or 
of
the other driver.

Currently I can't have another package write over mount.ntfs since it is the
one of ntfs-3g.

Could you consider making that link use the "alternatives" system?

You could add this file "debian/ntfs-3g.alternatives" with this content:

Name: mount.ntfs
Link: /sbin/mount.ntfs
Alternative: /sbin/mount.ntfs-3g
Priority: 50

This should then automatically be managed by dh_installalternatives
You may also need to remove the link you currently create in
"debian/ntfs-3g.links"


Regards


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ntfs-3g depends on:
ii  fuse3 [fuse]   3.10.3-2
ii  libc6  2.31-13+deb11u4
ii  libgcrypt201.8.7-6
ii  libgnutls303.7.1-5+deb11u2
ii  libntfs-3g883  1:2017.3.23AR.3-4+deb11u2

ntfs-3g recommends no packages.

Versions of packages ntfs-3g suggests:
ii  fdisk  2.36.1-8+deb11u1

Bug#999757: pulseaudio: My system has no audio and pavucontrol sees no cards in the configuration tab

[Maximiliano Estudies]

Package: pulseaudio
Version: 16.1+dfsg1-2
Followup-For: Bug #999757
X-Debbugs-Cc: maxiestud...@gmail.com

After updating pulseaudio can't see any cards or sinks. pavucontrol won't list 
any card in the configuration tab,
and pactl show cards returns nothing. Weirdly pacmd list-cards and pacmd 
list-sinks do show the correct 
information but the sink state is IDLE


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 pulseaudio depends on:
ii  adduser 3.129
ii  init-system-helpers 1.65.2
ii  libasound2  1.2.7.2-1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.35-2
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.4-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.2.0-3
ii  libglib2.0-02.74.0-2
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   16.1+dfsg1-2
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.1.0-3
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1
ii  libstdc++6  12.2.0-3
ii  libsystemd0 251.5-1
ii  libtdb1 1.4.7-1
ii  libudev1251.5-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-31
ii  libx11-62:1.8.1-2
ii  libx11-xcb1 2:1.8.1-2
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  lsb-base11.4
ii  pulseaudio-utils16.1+dfsg1-2
ii  sysvinit-utils [lsb-base]   3.05-6

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.4-1
ii  libpam-systemd [logind]  251.5-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 251.5-1

-- Configuration Files:
/etc/pulse/default.pa changed:
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
.ifexists module-gsettings.so
.nofail
load-module module-gsettings
.fail
.endif
load-module module-default-device-restore
load-module module-always-sink
load-module module-intended-roles
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif
load-module module-position-event-sounds
load-module module-role-cork
load-module module-filter-heuristics
load-module module-filter-apply
.nofail
.include /etc/pulse/default.pa.d


-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # 

Bug#1021490: bookworm: please mention users must migrate off dmraid

[Chris Hofstaedtler]

Package: release-notes
Severity: normal
X-Debbugs-Cc: g...@debian.org

Hi,

please add a note to the bookworm release notes, stating that users need
to migrate off dmraid during or before the bookworm cycle.

New systems cannot be installed with it. bookworm will still have the
dmraid package, so users should be able to copy their data off any such
setup.

I would think in trixie dmraid will be gone completely.

Chris

Bug#1021489: mkvtoolnix: likely contains embedded copy of libebml

[Diederik de Haas]

Package: mkvtoolnix
Version: 71.0.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just learned on #matroska IRC a couple of things:
- - version 71.0.0 requires libebml 2.0.0, which isn't released yet
- - version 71.1.0 has been released earlier today to address that and to
  requires libebml 1.4.4, which was released yesterday but isn't
  packaged for Debian yet (https://bugs.debian.org/1021486)
- - when the needed system-level libraries aren't available or not at the
  required version, the ``configure`` script will fall back to the
  embedded copy.

So I have to assume that the recently released version 71.0.0 must use
an embedded copy of libebml.


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 mkvtoolnix depends on:
ii  libc6  2.35-2
ii  libdvdread86.1.3-1
ii  libebml5   1.4.2-2+b1
ii  libflac8   1.3.4-2
ii  libfmt99.1.0+ds1-2
ii  libgcc-s1  12.2.0-3
ii  libgmp10   2:6.2.1+dfsg1-1
ii  libmatroska7   1.6.3-2
ii  libogg01.3.5-1
ii  libpugixml1v5  1.12.1-1
ii  libqt5core5a   5.15.4+dfsg-5
ii  libstdc++6 12.2.0-3
ii  libvorbis0a1.3.7-1
ii  zlib1g 1:1.2.11.dfsg-4.1

mkvtoolnix recommends no packages.

Versions of packages mkvtoolnix suggests:
ii  mkvtoolnix-gui  70.0.0-1+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY0LL0QAKCRDXblvOeH7b
bgdzAP9PCeWdraM+svFoQ902bz96AC+nM+sgXG0O6a80RsCm3AEAuNLMvfgLp3Lz
lmeqgEd7oVIJDfLtYZmtFIOkq0cBPA4=
=w6/c
-END PGP SIGNATURE-

Bug#1020552: fwupd: segfaults on Secure Boot dbx update

[Bernhard Übelacker]

Dear Maintainer,



Sep 23 09:58:10 leopard gnome-software[3304]: FIXME: Unknown progress handling
is not yet implemented for GsProgressButton
Sep 23 09:58:11 leopard fwupd[3397]: 06:58:11:0428 FuCommon
fu_common_read_uint16_safe: assertion 'buf != NULL' failed
Sep 23 09:58:11 leopard kernel: fwupd[3397]: segfault at 8 ip 7f4e9c012efa
sp 7fff5687e1a0 error 4 in libfu_plugin_uefi_dbx.so[7f4e9c012000+3000]
Sep 23 09:58:11 leopard kernel: Code: fb ff ff 49 89 c7 48 85 c0 0f 85 71 ff ff
ff 48 8b 44 24 30 4c 89 e9 48 8d 3d 02 22 00 00 48 8d 15 a3 21 00 00 be 80 00
00 00 <4c> 8b 40 08 31 c0 e8 9b fb ff ff 48 8b 7c 24 30 48 85 ff 74 05 e8
Sep 23 09:58:11 leopard systemd[1]: fwupd.service: Main process exited,
code=killed, status=11/SEGV



This crashing line above would point to function 
fu_uefi_dbx_signature_list_validate.
There it possibly wanted to output the message "failed to get checksum for %s: 
%s".

Kind regards,
Bernhard


benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) set environment 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_dbx.so
(gdb) file /usr/libexec/fwupd/fwupd
Reading symbols from /usr/libexec/fwupd/fwupd...
Reading symbols from 
/usr/lib/debug/.build-id/fe/65dd99a090ab87754fcd40f9833e4f127abe58.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x13c20: file ../src/fu-main.c, line 1913.
(gdb) run
Starting program: /usr/libexec/fwupd/fwupd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe5a8) at 
../src/fu-main.c:1913
1913../src/fu-main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep "\.text"
...
0x77fc4ae0 - 0x77fc60d5 is .text in 
/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_dbx.so
...
(gdb) find /b 0x77fc4ae0, 0x77fc60d5, 0xfb, 0xff, 0xff, 0x49, 
0x89, 0xc7, 0x48, 0x85, 0xc0, 0x0f, 0x85, 0x71, 0xff, 0xff, 0xff, 0x48, 0x8b, 
0x44, 0x24, 0x30, 0x4c, 0x89, 0xe9, 0x48, 0x8d, 0x3d, 0x02, 0x22, 0x00, 0x00, 
0x48, 0x8d, 0x15, 0xa3, 0x21, 0x00, 0x00, 0xbe, 0x80, 0x00, 0x00, 0x00, 0x4c, 
0x8b, 0x40, 0x08, 0x31, 0xc0, 0xe8, 0x9b, 0xfb, 0xff, 0xff, 0x48, 0x8b, 0x7c, 
0x24, 0x30, 0x48, 0x85, 0xff, 0x74, 0x05, 0xe8
0x77fc4ed0 
1 pattern found.
(gdb) b * (0x77fc4ed0 + 42)
Breakpoint 2 at 0x77fc4efa: file ../plugins/uefi-dbx/fu-uefi-dbx-common.c, 
line 61.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77fc4efa in 
fu_uefi_dbx_signature_list_validate_volume at 
../plugins/uefi-dbx/fu-uefi-dbx-common.c:61
(gdb) disassemble /r 0x77fc4ed0, 0x77fc4ed0 + 62
Dump of assembler code from 0x77fc4ed0 to 0x77fc4f0e:
   0x77fc4ed0 :fb  
sti
   0x77fc4ed1 :ff  
(bad)
   0x77fc4ed2 :ff 49 
89decl   -0x77(%rcx)
   0x77fc4ed5 :c7  
(bad)
   0x77fc4ed6 :48 85 
c0test   %rax,%rax
   0x77fc4ed9 :0f 85 71 ff 
ff ff   jne0x77fc4e50 
   0x77fc4edf :48 8b 
44 24 30  mov0x30(%rsp),%rax
   0x77fc4ee4 :4c 89 
e9mov%r13,%rcx
   0x77fc4ee7 :48 8d 
3d 02 22 00 00lea0x2202(%rip),%rdi# 0x77fc70f0
   0x77fc4eee :48 8d 
15 a3 21 00 00lea0x21a3(%rip),%rdx# 0x77fc7098
   0x77fc4ef5 :be 80 
00 00 00  mov$0x80,%esi
   0x77fc4efa :4c 8b 40 08 mov
0x8(%rax),%r8  <<
   0x77fc4efe :31 c0   
xor%eax,%eax
   0x77fc4f00 :e8 9b fb ff 
ff  call   0x77fc4aa0 
   0x77fc4f05 :48 8b 
7c 24 30  mov0x30(%rsp),%rdi
   0x77fc4f0a :48 85 
fftest   %rdi,%rdi
   0x77fc4f0d :74 05 
  je 0x77fc4f14 
End of assembler dump.


https://sources.debian.org/src/fwupd/1.5.7-4/plugins/uefi-dbx/fu-uefi-dbx-common.c/#L61


60  if (checksum == NULL) {
61  g_debug ("failed to get checksum for %s: %s", fn, 
error_local->message);
62  continue;
63  }

Bug#1021488: printer-driver-cups-pdf: cups-pdf ignores some settings in /etc/cups/cups-pdf.conf

[Alf]

Package: printer-driver-cups-pdf
Version: 3.0.1-14
Severity: important

Dear Maintainer,

   * What led up to the situation?
Just printing to cups-pdf printer results in a filename with suffix "job-ID" and not 
stripped suffix "txt" as configured.
Example:
Input file = Bookworm.txt (plain text)
Output file = Bookworm.txt__enable-job_32.pdf

   * What exactly did you do (or not do) that was effective (or ineffective)?
Whatever changes in cups-pdf.conf I do, be it "Key: Label", "Key: TitlePref" or 
"Key: PDFVer"
will result in a similar output filename.

   * What outcome did you expect instead?
Output filename should be just
Bookworm.pdf
and PDF-version should be 1.4.

Debug log clearly shows that my settings
Label 0 (default)
TitlePref 1
PDFVer 1.4 (default)(

are not respected:

/var/log/cups/cups-pdf-PDF_log:
l
Sun Oct  9 12:51:25 2022  [DEBUG] GSCall = "%s -q -dCompatibilityLevel=%s 
-dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" 
-dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode 
-dPDFSETTINGS=/prepress -c -f %s"
Sun Oct  9 12:51:25 2022  [DEBUG] Grp= "lpadmin"
Sun Oct  9 12:51:25 2022  [DEBUG] GSTmp  = "TMPDIR=/var/tmp"
Sun Oct  9 12:51:25 2022  [DEBUG] Log= "/var/log/cups"
Sun Oct  9 12:51:25 2022  [DEBUG] PDFVer = "1.2"
Sun Oct  9 12:51:25 2022  [DEBUG] PostProcessing = ""
Sun Oct  9 12:51:25 2022  [DEBUG] Out= "${HOME}/PDF"
Sun Oct  9 12:51:25 2022  [DEBUG] Spool  = 
"/var/spool/cups-pdf/SPOOL"
Sun Oct  9 12:51:25 2022  [DEBUG] UserPrefix = ""
Sun Oct  9 12:51:25 2022  [DEBUG] RemovePrefix   = ""
Sun Oct  9 12:51:25 2022  [DEBUG] OutExtension   = "pdf"
Sun Oct  9 12:51:25 2022  [DEBUG] Cut= 3
Sun Oct  9 12:51:25 2022  [DEBUG] Truncate   = 64
Sun Oct  9 12:51:25 2022  [DEBUG] DirPrefix  = 0
Sun Oct  9 12:51:25 2022  [DEBUG] Label  = 2
Sun Oct  9 12:51:25 2022  [DEBUG] LogType= 7
Sun Oct  9 12:51:25 2022  [DEBUG] LowerCase  = 1
Sun Oct  9 12:51:25 2022  [DEBUG] TitlePref  = 0
Sun Oct  9 12:51:25 2022  [DEBUG] DecodeHexStrings   = 1
Sun Oct  9 12:51:25 2022  [DEBUG] FixNewlines= 0
Sun Oct  9 12:51:25 2022  [DEBUG] AllowUnsafeOptions = 0
Sun Oct  9 12:51:25 2022  [DEBUG] AnonUMask  = 
Sun Oct  9 12:51:25 2022  [DEBUG] UserUMask  = 0077
Sun Oct  9 12:51:25 2022  [DEBUG] *** End of Configuration ***





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

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

Versions of packages printer-driver-cups-pdf depends on:
ii  cups2.4.2-1+b1
ii  cups-client 2.4.2-1+b1
ii  ghostscript 9.56.1~dfsg-1
ii  libc6   2.35-2
ii  libcups22.4.2-1+b1
ii  libpaper-utils  1.1.28+b1

printer-driver-cups-pdf recommends no packages.

Versions of packages printer-driver-cups-pdf suggests:
ii  system-config-printer  1.5.16-1

-- Configuration Files:
/etc/cups/cups-pdf.conf changed:
Out ${HOME}/PDF
Label 0
TitlePref 1
Grp lpadmin
DecodeHexStrings 1


-- no debconf information

Bug#1021487: libblockdev: please drop libdmraid-dev

[Chris Hofstaedtler]

Source: libblockdev

Hi,

dmraid is mostly dead, and I think latest in trixie we want to
remove it completely. Support from d-i is already gone. You can find
some history in #864423.

I would aim for having bookworm still ship with dmraid itself, but
only as a migration path off it. I would think libblockdev can drop
supporting it now.

Please remove the Build-Depends libdmraid-dev. This will probably
also remove dmraid from the key package set.

Thanks,
Chris

Bug#1020516: i386: nothing but a blinking underscore at the top left

[Bernhard Übelacker]

> ... But what is this 2.0.8-2+b1 version?
> I can't find anything about what is this +b1, what are the changes?

Hello,
just a short addition to your question.
The +b1 version is just a rebuild against the current packages in 
unstable, e.g. by some library transition.

The source package getting rebuilt is unchanged.

https://wiki.debian.org/binNMU

Kind regards,
Bernhard

Bug#1021486: libebml5: New upstream release (v1.4.4; needed for mkvtoolnix v71+)

[Diederik de Haas]

Package: libebml5
Version: 1.4.2-2+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

libebml released version 1.4.4 yesterday and IIUC that version is needed
for mkvtoolnix 71.1.

mkvtoolnix 71.0 apparently needs libebml 2.0.0, but that version
doesn't exist yet and 71.1 was just released to only require 1.4.4.

So it would be great is 1.4.4 could be packaged for Debian.

TIA,
Diederik

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libebml5 depends on:
ii  libc6   2.35-2
ii  libgcc-s1   12.2.0-3
ii  libstdc++6  12.2.0-3

libebml5 recommends no packages.

libebml5 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY0LEQQAKCRDXblvOeH7b
bgO/AQDC/nZLKW8A6T5Dt4eUMOQaAtRuGdFEjWNz81emZPngbwEAo+0yiZF5ZhfC
xIzPJO5yymW+NVQCri0ELJfz83mwRgg=
=sdfi
-END PGP SIGNATURE-

Bug#1021485: no version information is shipped in the POMs for the plexus- dependencies

[Pierre Gruet]

Package: libplexus-interactivity-api-java
Version: 1.1-1
Severity: normal

Hello,

Currently no version information is provided in the shipped POMs for plexus-*,
this is because this information is missing in all POMs in the source although
the child POMs both declare a dependency on two plexus- artifacts.

This leads to errors about "dependencies.dependency.version" being missing when
one attempts to build a software depending on plexus-interactivity, e.g. using
maven-javadoc-plugin which depends on it.

I will make an upload solving this soon.

Best,

-- 
Pierre

Bug#1017104: #1017104: dpkg fails when purging git-daemon-run (patch)

[Chris Hofstaedtler]

Control: tags -1 + patch

Jonathan,

I'm attaching a patch for the git-daemon-run postrm script, please
apply it when you can.
Currently, the postrm fails, causing dpkg to fail. From what I can
tell, the change is harmless (the old behavior was wrong IMO).

Thanks,
Chris

>From 095ac91986212502a7fb35c1de9808cf304e1e78 Mon Sep 17 00:00:00 2001
From: Chris Hofstaedtler 
Date: Sun, 9 Oct 2022 11:47:33 +
Subject: [PATCH] git-daemon-run.postrm: remove -f flag from deluser call

Does not exist since #1002495 and was always wrong.

Signed-off-by: Chris Hofstaedtler 
---
 debian/git-daemon-run.postrm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/git-daemon-run.postrm b/debian/git-daemon-run.postrm
index f6aa282d05..1c2ac6570a 100644
--- a/debian/git-daemon-run.postrm
+++ b/debian/git-daemon-run.postrm
@@ -18,5 +18,5 @@ done
 rmdir /var/log/git-daemon || :
 
 getent passwd gitlog >/dev/null || exit 0
-! deluser --version >/dev/null 2>&1 || exec deluser -f gitlog
+! deluser --version >/dev/null 2>&1 || exec deluser gitlog
 echo 'deluser program not available, not removing system user "gitlog".' >&2
-- 
2.37.2

Bug#932047: lightdm: greeter session support for elogind

[Mark Hindley]

Yves-Alexis,

On Sun, Oct 09, 2022 at 01:46:56PM +0200, Yves-Alexis Perez wrote:
> for some reason it seems I never actually replied to this bug, sorry.

No worries.

> I might have replied on different bugs, but I'm not really keen on modifying
> pam files, especially for specific / non-default stuff.

Yes, I remember that from our previous discussions.

> Do you know what are the opinion of PAM people and systemd-logind people on
> that?

Added to CC:

Dear Steve and Sam as PAM maintainers,

I am wanting to add libpam-elogind support to lightdm-greeter. Currently
/etc/pam.d/lightdm-greeter hooks logind directly with

  session   optional pam_systemd.so

I have proposed two patches: either to add

 session   optional pam_elogind.so

or replace both with

 @include common-session

Yves-Alexis is understandably cautious about changing the PAM configuration.  Do
you have any thoughts, advice or comments on which might be the most 
appropriate?

Thanks

> It might be nice to have them chime in. Also not sure how this thing is
> handled on other DM, any idea?

A quick look shows most use '@include common-session'. AFAICS that is the case 
for

 gdm3: /etc/pam.d/gdm-password 
 sddm: /etc/pam.d/sddm-greeter
 xdm: /etc/pam.d/xdm
 slim: /etc/pam.d/slim (although it doesn't use logind interfaces)

AFAICS lxdm doesn't use logind at all.

HTH.

Best wishes

Mark

Bug#933098: Which skills needed for a maintainer for xskat?

[Florian Ernst]

Hello Marco,

On Sat, Oct 08, 2022 at 10:42:59AM +, Marco wrote:
> which skills are exactly needed for package maintainers?

That is a rather broad question given the wide variety of packages and
their respective build systems and further implementation details. As
such, I'd have a hard time to pinpoint the "exactly" from your question.

But now on a more serious note, there are many resources available for
dealing with the technical and/or organizational aspects of packaging,
e.g.

https://www.debian.org/doc/manuals/debmake-doc/
https://www.debian.org/doc/manuals/maint-guide/
https://www.debian.org/doc/manuals/developers-reference/
https://wiki.debian.org/DebianMaintainer

that will also link to further resources. And of course there is quite
some overlap among these documents, and often not all details will be
needed.

As for the xskat package in particular, there most probably won't be all
too many exciting changes required (or much glory to be earned, to be
honest): no new upstream release for over 18 years, most of the
packaging already done with a rather simple structure (just as you
stated: it compiles easily and just works), so mostly keeping up with
the latest Debian standards and recommendations, as e.g. pointed out as
"action needed" on , which so far
I had done a whopping 6 times over the past 16 years.

> Are there people out there who can help newcomers if they encounter
> problems?

That would be the Debian Mentors with some more documentation at
 and a mailing list at
 (with a FAQ at
).

JFTR, I personally most probably won't be available for any such help.

HTH,
Flo


signature.asc
Description: PGP signature

Bug#932047: lightdm: greeter session support for elogind

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2022-10-09 at 10:03 +0100, Mark Hindley wrote:
> Hi Yves-Alexis,
> 
> With another user bumping into this issue, I am keen to have it resolved in
> bookworm.
> 
> I think adding
> 
>  session   optional pam_elogind.so
> 
> to /etc/pam.d/lighdm-greeter is the best and correct fix.
> 
> I know you have been reluctant in the past, but would you consider it again.

Hi Mark,

for some reason it seems I never actually replied to this bug, sorry. I might
have replied on different bugs, but I'm not really keen on modifying pam
files, especially for specific / non-default stuff.

Do you know what are the opinion of PAM people and systemd-logind people on
that? It might be nice to have them chime in. Also not sure how this thing is
handled on other DM, any idea?
> 
> Alternatively, I am happy to offer an NMU?

Please refrain for now.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNCtLAACgkQ3rYcyPpX
RFuVzgf/ZUcNnSJTge42ZSCEvgRnwwjlCZw595S3MlZlSjQfRjPZfU2mitNvfs7u
WZqXUEF1H+KoFeGF5IUEwoWYAK62KXz/9aTmO44kz6kTJKVy4JT8Lv/XWer7jkXN
Ku1q62VcPxwilWYgiOyX4YVPfWgFrD7N/DJ+/04lpZHASqvPh+hrjR6wK4SIl1OH
+WCoRTtgaRw/bRaXL0STpPFi2BhzBsXRyQTcNgbjFRrXLOU2u4fBAb3g60V0aGxP
ZU0FdjYbwsTkI875rd2t0fN6uURU6AtrFE+L0vaAfpbxCWtdkG41RlotvfiNzJ6L
F42WnwLeOsWT4uQ6/MeEWm8+JcLXKA==
=YNpO
-END PGP SIGNATURE-

Bug#1020516: i386: nothing but a blinking underscore at the top left

[Bernhard Übelacker]

Hello,
I tried to install just lightdm and openbox inside a minimal testing VM.
It was started by even "older" "qemu-system-i386 -enable-kvm -cpu pentium-v1".

Unfortunately I just hit bug #1020802.
When having those X drivers not being tried to load,
then login works to the openbox DE.

Can you still reproduce this issue?

Kind regards,
Bernhard

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

Bug#1021484: RFS: runit/2.1.2-49 -- system-wide service supervision

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

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

 * Package name : runit
   Version  : 2.1.2-49
   Upstream contact : Gerrit Pape 
 * URL  : http://smarden.org/runit/
 * License  : GPL-3+, CC0-1.0, BSD-3-clause
 * Vcs  : https://salsa.debian.org/debian/runit
   Section  : admin

The source builds the following binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  runit-systemd - transitional package for runit-systemd users
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-49.dsc

Git repo:

  https://salsa.debian.org/debian/runit/-/tree/next

Changes since the last upload:

 runit (2.1.2-49) experimental; urgency=medium
 .
   * make_svlink: create links also when CPSV_DIR is not /etc/sv
   * make the default directory for runsvdir configurable
   * stage 1: setup to experiment with a runtime service layout
   * /lib/lsb/init-functions.d/40-runit: mask sysv services and
  forward signals to runscripts; this can be tuned with flag files if
  start-stop-daemon wrapper is preferred. (Closes: #1021465)
   * add an sv_wtime utility needed for triggered upgrade of services
   * support triggered upgrade for runit services; this mode requires
  metafiles that are usually produced by dh-runit (Closes: #1021474)
   * invoke-run:
  - check for new metafile path inside the service directory
  - remove hardcoded path when 'chpst -e' is used
  - avoid loop when signals for sysv script are forwarded
   * cpsv:
  - improve readability of -d with colored diff
  - improve heuristic on sysvinit scripts
   * update-service:
  - add policy compliant commands
  - update manpage
   * run_sysv_scripts: small optimizations
   * svlogd: copy pkg metafile inside the log directory
   * Add a purge fallback for runit package, to fix piuparts
  sporadic failure

Regards,
-- 
  Lorenzo Puliti

Bug#1021483: Pipewire keeps waking up CPU even when not playing sound

[Josh Triplett]

Package: pipewire
Version: 0.3.59-1
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

Reporting this as "important" because as far as I can tell my battery
life has gone down noticeably since switching from Pulseaudio to Pipewire.

Even when not playing any sound whatsoever, pipewire is waking up more
than a hundred times per second, and using ~10ms of CPU out of every 1s.

This keeps the CPU in lower sleep states, and uses more battery.

- Josh Triplett

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

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.59-1
ii  pipewire-bin 0.3.59-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#444138: Heloo

[M,OR Asiri]

‫أُرسل ،من  ،&&الـ iPhone‬

Bug#994927: closed by Niels Thykier (Re: Bug#994927: dh_auto_configure/autoconf needs to stop passing --runstatedir=/run to ./configure)

[Christoph Berg]

> Having considered this, I think I will close this as wontfix.  I think if
> anything is to be done then it is that autoconf2.69 ought re-instate their
> backported patch given debhelper have been using the option by default (for
> compat 10+ packages) since 2016.

Ack. For PostgreSQL, I removed its hardcoded "autoconf must be 2.69 or
else you get to keep the pieces" check without any ill effects.

Christoph

Bug#1021205: transition: simdjson

[Emilio Pozuelo Monfort]

On 07/10/2022 16:43, M. Zhou wrote:

Thanks. It has been uploaded to unstable.


binNMUs scheduled.

Cheers,
Emilio

Bug#1021482: nmu: ruby-pg-query_2.1.0-2

[Pirate Praveen]

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

nmu ruby-pg-query_2.1.0-2 . ANY . experimental . -m "Rebuild with ruby 
3.1"

Bug#1021310: libsdl2: FTBFS on hppa - patch attached

[Helge Deller]

As Dave wrote, it's (partly) a 32-bit big-endian issue.

This check in test/testevdev.c

#if ULONG_MAX == 0xUL
#   define SwapLongLE(X) SDL_SwapLE32(X)
#else
/* assume 64-bit */
#   define SwapLongLE(X) SDL_SwapLE64(X)
#endif

always chooses the #else part, because the  file
isn't #included and thus ULONG_MAX isn't defined.

Adding:
#include 
to the top of test/testevdev.c,
or applying the attached patch fixes the build on hppa (and probably power).diff -up ./test/testevdev.c.org ./test/testevdev.c
--- ./test/testevdev.c.org	2022-10-09 09:23:28.958270080 +
+++ ./test/testevdev.c	2022-10-09 09:45:10.542076834 +
@@ -935,12 +935,8 @@ static const GuessTest guess_tests[] =
 }
 };
 
-#if ULONG_MAX == 0xUL
-#   define SwapLongLE(X) SDL_SwapLE32(X)
-#else
-/* assume 64-bit */
-#   define SwapLongLE(X) SDL_SwapLE64(X)
-#endif
+#define SwapLongLE(X) \
+	((sizeof(unsigned long) == 4) ? SDL_SwapLE32(X) : SDL_SwapLE64(X))
 
 static int
 run_test(void)

Bug#1019425: dkms 3.0.6-2 not signing modules

[Nicolas Cavallari]

Because patching /usr/sbin/dkms after every update quickly gets old, i
found another workaround by putting this into /etc/dkms/framework.conf:



do_signing=1

check_the_mok_key() {
case "${KBUILD_SIGN_PIN-}" in
[Nn][oO])
return 0;;
esac
KBUILD_SIGN_PIN="${KBUILD_SIGN_PIN-}" \
openssl rsa -in "$mok_signing_key" \
-passin env:KBUILD_SIGN_PIN -check -noout || return
}

ask_for_mok_password() {
until check_the_mok_key; do
stty -echo
printf "\nEnter passphrase for %s (type 'no' to cancel):" \
"$mok_signing_key"
IFS='' read -r KBUILD_SIGN_PIN || KBUILD_SIGN_PIN=no
stty echo
done
}

kmodsign() {
ask_for_mok_password < /dev/tty > /dev/tty 2>&1

KBUILD_SIGN_PIN="${KBUILD_SIGN_PIN-}" "$sign_file" "$@"
}



Hopefully this will be resolved in the future and this workaround will
no longer be necessary.

Bug#1021348: exim4-base: race in system boot causes exim4 to fail starting automatically

[Andreas Metzler]

On 2022-10-06 Giacomo Mulas  wrote:
> Package: exim4-base
> Version: 4.96-4
> Severity: normal

> Dear Maintainer,

> Since several months now I noticed that exim4.service fails to start 
> at boot when I am at work.

> If I run

> systemctl status exim4

> I get:

[...]
> ott 06 12:43:29 capitanata exim4[4169]: 2022-10-06 12:43:29 Exim 
> configuration error in line 508 of /var/lib/exim4/config.autogenerated.tmp:
> ott 06 12:43:29 capitanata exim4[4169]:   Unexpected end of configuration 
> file: .endif missing
> ott 06 12:43:29 capitanata exim4[4245]: Invalid new configfile 
> /var/lib/exim4/config.autogenerated.tmp, not installing
[...]
> Exim4 invariably starts without a hitch if I manually issue a

> systemctl start exim4

> after boot.
[...]


Hello,

this is pretty strange since /usr/sbin/update-exim4 does not rely on
dynamic data. Is your configuration data valid?
/usr/sbin/update-exim4.conf -v --output  /tmp/testme
/usr/sbin/exim4 -bV -C /tmp/testme

cu Andreas

Bug#1021481: reportbug: -r always create a new bug even when replying

[Nicolas Cavallari]

Package: reportbug
Version: 11.5.1
Severity: normal


When trying to provide additional information to an existing bug, a
configuration problem from my side prevented reportbug from sending a
mail.  reportbug then suggested to use "reportbug -r /tmp/[...]" to
resume the submission.

However, this option made reportbug send the mail to submit@ instead of
replying to the existing bug number.  This created a new bug, even if
the existing bug number was present in the "Followup-For" pseudo-header.

See #1021480 for such a junk bug.

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** $HOME/.reportbugrc:
reportbug_version "11.5.1"
mode advanced
ui text
realname "Nicolas Cavallari"
email "batch...@free.fr"
smtphost "smtp.free.fr:587"
smtpuser "batchman"
smtptls

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.5.3
ii  python33.10.6-1
ii  python3-reportbug  11.5.1
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.79
ii  debsums 3.0.2
pn  dlocate 
pn  emacs-bin-common
ii  file1:5.41-4
ii  gnupg   2.2.39-1
ii  postfix [mail-transport-agent]  3.6.4-1+b3
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.5.3
ii  file   1:5.41-4
ii  python33.10.6-1
ii  python3-apt2.3.0+b2
ii  python3-debian 0.1.48
ii  python3-debianbts  3.2.3
ii  python3-requests   2.27.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information

Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

[Bernhard Übelacker]

Dear Maintainer,
tried to have a look at another bug report, but found X not starting up.

I could reproduce this inside a qemu VM started with:
  qemu-system-i386 -enable-kvm -cpu pentium-v1 ...

So due to the current documentation [1] it looks like plain Pentium will
not be supported in bookworm, but cannot say where Pentium Pro gets sorted in.

[1] https://www.debian.org/releases/testing/i386/ch02s01.en.html#idm269


Nevertheless, following are a few more details.

Kind regards,
Bernhard


gdb -q --args X :0
(gdb) run
...
Program received signal SIGILL, Illegal instruction.
0xac3672de in ?? () from /lib/i386-linux-gnu/libz3.so.4
(gdb) bt
#0  0xac3672de in ?? () from /lib/i386-linux-gnu/libz3.so.4
#1  0xb7fcdd6b in call_init (env=0xbdd0, argv=0xbdc4, argc=2, l=) at ./elf/dl-init.c:70
#2  call_init (l=, argc=2, argv=0xbdc4, env=0xbdd0) at 
./elf/dl-init.c:26
#3  0xb7fcde5c in _dl_init (main_map=, argc=2, argv=0xbdc4, 
env=0xbdd0) at ./elf/dl-init.c:117
#4  0xb7fd4d97 in call_dl_init (closure=0xbfffe570) at ./elf/dl-open.c:485
#5  0xb7965934 in __GI__dl_catch_exception (exception=, 
operate=, args=) at ./elf/dl-error-skeleton.c:182
#6  0xb7fd4d25 in dl_open_worker (a=0xbfffe6b8) at ./elf/dl-open.c:808
#7  0xb79658d7 in __GI__dl_catch_exception (exception=, 
operate=, args=) at ./elf/dl-error-skeleton.c:208
#8  0xb7fd50c0 in _dl_open (file=0xbfffe98c 
"/usr/lib/i386-linux-gnu/dri/zink_dri.so", mode=-2147483390, 
caller_dlopen=0xb713a8a5, nsid=, argc=2, argv=0xbdc4, env=0xbdd0) 
at ./elf/dl-open.c:886
#9  0xb787f848 in dlopen_doit (a=0xbfffe91c) at ./dlfcn/dlopen.c:56
#10 0xb79658d7 in __GI__dl_catch_exception (exception=, 
operate=, args=) at ./elf/dl-error-skeleton.c:208
#11 0xb79659a0 in __GI__dl_catch_error (objname=0xbfffe8d4, errstring=0xbfffe8d8, 
mallocedp=0xbfffe8d3, operate=0xb787f7d0 , args=0xbfffe91c) at 
./elf/dl-error-skeleton.c:227
#12 0xb7fe1df8 in _rtld_catch_error (objname=0xbfffe8d4, errstring=0xbfffe8d8, 
mallocedp=0xbfffe8d3, operate=0xb787f7d0 , args=0xbfffe91c) at 
./elf/dl-error-skeleton.c:260
#13 0xb787f297 in _dlerror_run (operate=, args=) 
at ./dlfcn/dlerror.c:138
#14 0xb787f918 in dlopen_implementation (dl_caller=, mode=258, 
file=0xbfffe98c "/usr/lib/i386-linux-gnu/dri/zink_dri.so") at ./dlfcn/dlopen.c:71
#15 ___dlopen (file=0xbfffe98c "/usr/lib/i386-linux-gnu/dri/zink_dri.so", 
mode=258) at ./dlfcn/dlopen.c:81
#16 0xb713a8a5 in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#17 0xb713aa20 in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#18 0xb7139109 in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#19 0xb7139693 in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#20 0xb713995f in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#21 0xb71377cb in ?? () from /lib/i386-linux-gnu/libgbm.so.1
#22 0xb7137935 in gbm_create_device () from /lib/i386-linux-gnu/libgbm.so.1
#23 0xb714c450 in glamor_egl_init () from /usr/lib/xorg/modules/libglamoregl.so
#24 0xb71a2c03 in ?? () from /usr/lib/xorg/modules/drivers/modesetting_drv.so
#25 0x0048aade in InitOutput ()
#26 0x0044a3c9 in ?? ()
#27 0x00432b2b in ?? ()
#28 0xb78213b5 in __libc_start_call_main (main=main@entry=0x432b00, 
argc=argc@entry=2, argv=argv@entry=0xbdc4) at 
../sysdeps/nptl/libc_start_call_main.h:58
#29 0xb782147f in __libc_start_main_impl (main=0x432b00, argc=2, argv=0xbdc4, 
init=0x0, fini=0x0, rtld_fini=0xb7fcd930 <_dl_fini>, stack_end=0xbdbc) at 
../csu/libc-start.c:389
#30 0x00432b67 in _start ()
(gdb) display/i $pc
1: x/i $pc
=> 0xac3672de:  pxor   %xmm0,%xmm0


With libz3-4-dbgsym:

Core was generated by `/usr/lib/xorg/Xorg :0'.
Program terminated with signal SIGILL, Illegal instruction.
#0  std::__mutex_base::__mutex_base (this=0x6f3fe0) at 
/usr/include/c++/12/bits/std_mutex.h:65

warning: Source file is more recent than executable.
65  constexpr __mutex_base() noexcept = default;
(gdb) bt 5
#0  std::__mutex_base::__mutex_base (this=0x6f3fe0) at 
/usr/include/c++/12/bits/std_mutex.h:65
#1  std::mutex::mutex (this=0x6f3fe0) at /usr/include/c++/12/bits/std_mutex.h:91
#2  __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at ./src/util/memory_manager.cpp:39
#3  _GLOBAL__sub_I_memory_manager.cpp(void) () at 
./src/util/memory_manager.cpp:373
#4  0xb7fcdd6b in call_init (env=0xbdd0, argv=0xbdc4, argc=2, l=) at ./elf/dl-init.c:70
(More stack frames follow...)


(Same issue also for kms_swrast_dri.so and swrast_dri.so.)


And came also to this closed upstream issue:
  https://github.com/Z3Prover/z3/issues/6369


A workaround might be to move these files out of /usr/lib/i386-linux-gnu/dri:
  kms_swrast_dri.so
  swrast_dri.so
  zink_dri.so
(Or get it some other way not loaded by Xorg.)

Bug#995595: #995595: current version builds fine

[Chris Hofstaedtler]

guile-3.0 3.0.8-2 builds fine (on the buildds and locally).

Should this bug be closed?

Chris

Bug#1021480: dkms 3.0.6-2 not signing modules

[Nicolas Cavallari]

Package: dkms
Version: 3.0.6-3
Followup-For: Bug #1019425

Because patching /usr/sbin/dkms after every update quickly gets old, i
found another workaround by putting this into /etc/dkms/framework.conf:



do_signing=1

check_the_mok_key() {
case "${KBUILD_SIGN_PIN-}" in
[Nn][oO])
return 0;;
esac
KBUILD_SIGN_PIN="${KBUILD_SIGN_PIN-}" \
openssl rsa -in "$mok_signing_key" \
-passin env:KBUILD_SIGN_PIN -check -noout || return
}

ask_for_mok_password() {
until check_the_mok_key; do
stty -echo
printf "\nEnter passphrase for %s (type 'no' to cancel):" \
"$mok_signing_key"
IFS='' read -r KBUILD_SIGN_PIN || KBUILD_SIGN_PIN=no
stty echo
done
}

kmodsign() {
ask_for_mok_password < /dev/tty > /dev/tty 2>&1

KBUILD_SIGN_PIN="${KBUILD_SIGN_PIN-}" "$sign_file" "$@"
}



Hopefully this will be resolved in the future and this workaround will
no longer be necessary.


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dkms depends on:
ii  build-essential12.9
ii  clang-13 [c-compiler]  1:13.0.1-7
ii  clang-14 [c-compiler]  1:14.0.6-2
ii  dctrl-tools2.24-3+b1
ii  dh-dkms3.0.6-3
ii  dpkg-dev   1.21.9
ii  gcc [c-compiler]   4:12.2.0-1
ii  gcc-11 [c-compiler]11.3.0-8
ii  gcc-12 [c-compiler]12.2.0-5
ii  kmod   30+20220630-3
ii  lsb-release12.0-1
ii  make   4.3-4.1
ii  patch  2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.29-1
ii  linux-headers-amd64 [linux-headers-generic]  5.19.11-1
ii  sudo 1.9.11p3-1

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.6~rc1-1
ii  menu   2.1.49

-- Configuration Files:
/etc/dkms/framework.conf changed [not included]
/etc/dkms/sign_helper.sh changed [not included]
/etc/modprobe.d/dkms.conf changed [not included]

-- no debconf information

Bug#932047: lightdm: greeter session support for elogind

[Mark Hindley]

Hi Yves-Alexis,

With another user bumping into this issue, I am keen to have it resolved in
bookworm.

I think adding

 session   optional pam_elogind.so

to /etc/pam.d/lighdm-greeter is the best and correct fix.

I know you have been reluctant in the past, but would you consider it again.

Alternatively, I am happy to offer an NMU?

Best wishes and thanks.

Mark

Bug#1019952: gnome-disk-utility: segfault in libudisks2.so.0.0.0

[Bernhard Übelacker]

Hello piorunz,
I tried to get some more information from your dmesg line and think
the crash takes place in function udisks_drive_ata_get_smart_enabled.

I could not find any crashes related to this function in udisks2
upstream bug tracker, but gnome-disks upstream tracker
contains [56], that might be related.

To be sure it would be good if you could generate a backtrace
of the crash.
For this is might be already sufficient to install systemd-coredump [1].
Then the segfault line should be followed more information
about the crash in the journal.

Kind regards,
Bernhard







[74281.147838] gnome-disks[2098897]: segfault at a0 ip 7f7b10aeefc8 sp
7ffd5bd91c48 error 4 in libudisks2.so.0.0.0[7f7b10adb000+53000]
[74281.147852] Code: e9 0d ce fe ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 53
48 89 fb e8 77 c3 fe ff 48 8b 3b 48 89 c6 e8 bc c0 fe ff 48 89 df 5b <48> 8b 80
a0 00 00 00 ff e0 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44



(gdb) find /b 0x77022960, 0x7707392f, 0xe9, 0x0d, 0xce, 0xfe, 
0xff, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x1f, 
0x00, 0x53, 0x48, 0x89, 0xfb, 0xe8, 0x77, 0xc3, 0xfe, 0xff, 0x48, 0x8b, 0x3b, 
0x48, 0x89, 0xc6, 0xe8, 0xbc, 0xc0, 0xfe, 0xff, 0x48, 0x89, 0xdf, 0x5b, 0x48, 
0x8b, 0x80, 0xa0, 0x00, 0x00, 0x00, 0xff, 0xe0, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x1f, 0x44
0x77034f9e 
1 pattern found.
(gdb) b * (0x77034f9e + 42)
Breakpoint 2 at 0x77034fc8: file ./udisks/udisks-generated.c, line 9308.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77034fc8 in 
udisks_drive_ata_get_smart_enabled at ./udisks/udisks-generated.c:9308
(gdb) disassemble /r 0x77034f9e, 0x77034f9e + 62
Dump of assembler code from 0x77034f9e to 0x77034fdc:
   0x77034f9e :e9 0d ce fe 
ff  jmp0x77021db0 
   0x77034fa3:  66 2e 0f 1f 84 00 00 00 00 00   cs nopw 0x0(%rax,%rax,1)
   0x77034fad:  0f 1f 00nopl   (%rax)
   0x77034fb0 :   53  
push   %rbx
   0x77034fb1 :   48 89 fb
mov%rdi,%rbx
   0x77034fb4 :   e8 77 c3 fe ff
  call   0x77021330 
   0x77034fb9 :   48 8b 3b
mov(%rbx),%rdi
   0x77034fbc :  48 89 c6
mov%rax,%rsi
   0x77034fbf :  e8 bc c0 fe ff
  call   0x77021080 
   0x77034fc4 :  48 89 df
mov%rbx,%rdi
   0x77034fc7 :  5b  
pop%rbx
   0x77034fc8 :  48 8b 80 a0 00 00 00mov
0xa0(%rax),%rax   
   0x77034fcf :  ff e0   
jmp*%rax
   0x77034fd1:  66 2e 0f 1f 84 00 00 00 00 00   cs nopw 0x0(%rax,%rax,1)
   0x77034fdb:  0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
End of assembler dump.

  9305  gboolean
  9306  udisks_drive_ata_get_smart_enabled (UDisksDriveAta *object)
  9307  {
  9308return UDISKS_DRIVE_ATA_GET_IFACE (object)->get_smart_enabled 
(object);
  9309  }


[56] https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/56

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#996297: 996297: patched with workaround

[Chris Hofstaedtler]

Control: severity -1 normal

0.11.2-2 added a workaround patch, so the FTBFS itself is gone.

Bug#1021479: RFS: openarc/1.0.0~beta3+dfsg-1~exp3 -- Authenticated Received Chain (ARC) milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : openarc
   Version  : 1.0.0~beta3+dfsg-1~exp3
   Upstream contact : The Trusted Domain Project 
 * URL  : https://github.com/trusteddomainproject/OpenARC
 * License  : GPL-3+ with AutoConf exception, BSD-2-clause and SOSL
 * Vcs  : https://salsa.debian.org/debian/openarc
   Section  : mail

The source builds the following binary packages:

  openarc - Authenticated Received Chain (ARC) milter
  libopenarc-dev - Authenticated Received Chain (ARC) library (development 
files)
  libopenarc0 - Authenticated Received Chain (ARC) library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/openarc/openarc_1.0.0~beta3+dfsg-1~exp3.dsc

Changes since the last upload:

 openarc (1.0.0~beta3+dfsg-1~exp3) experimental; urgency=medium
 .
   * Update debian/watch to monitor GitHub tags instead of releases page.
   * Bump Standards-Version to 4.6.1 without further changes.

Thank you,
David

Bug#968170:

[Munirah Tawar]

I can get people's wifi password

Bug#1018740: debootstrap: better initialisisation of /etc/machine-id

[Bastian Blank]

On Mon, Aug 29, 2022 at 10:52:07PM +0200, Holger Levsen wrote:
> So probably it would be better to either remove the file or write 
> "uninitialized"
> into it... or support both via commandline flags :)

Actually debootstrap must write it as _empty_, to avoid running into
first boot setup.[1]  Only a tool who knows what comes next can actually
write "uninitialized" into it.

Bastian

[1]: https://www.freedesktop.org/software/systemd/man/machine-id.html
-- 
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5

Bug#1021478: mmdebstrap - Enables first boot experience via machine-id

[Bastian Blank]

Package: mmdebstrap
Version: 1.2.1-2
Severity: serious

mmdebstrap writed "uninitialized" to /etc/machine-id.  This triggers
first boot semantic[1], so makes the boot wait for input.

Please write an empty file if you are not equipped to handle first boot
questions.

Bastian

[1]: https://www.freedesktop.org/software/systemd/man/machine-id.html

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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.5.3
ii  perl 5.34.0-5
ii  python3  3.10.6-1

Versions of packages mmdebstrap recommends:
pn  arch-test
pn  fakechroot   
ii  fakeroot 1.29-1
ii  gpg  2.2.39-1
pn  libdistro-info-perl  
ii  libdpkg-perl 1.21.9
ii  mount2.38.1-1
pn  uidmap   

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.5.3
pn  apt-transport-tor  
ii  apt-utils  2.5.3
pn  binfmt-support 
ii  ca-certificates20211016
pn  debootstrap
ii  distro-info-data   0.54
ii  dpkg-dev   1.21.9
pn  genext2fs  
pn  perl-doc   
pn  proot  
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  

Bug#1021021: Upload planned

[Felix Lechner]

Hi,

I plan to upload version 5.5.1 in the near future.

Kind regards
Felix Lechner