Bug#1032590: Intermediate certficate support

[Bernhard Schmidt]

Control: forwarded -1 
https://github.com/FreeRADIUS/freeradius-server/issues/4753
Control: priority -1 important
Control: found -1 3.0.25+dfsg-1

On 09/03/23 05:29 PM, Sakirnth Nagarasa wrote:

Hi,

> It would be great if you could upgrade freeradius version 3.2.2 to
> Debian. With that certficates chains can be used without failing.
> 
> It patches this bug:
> https://github.com/FreeRADIUS/freeradius-server/issues/4753

Thanks for the report. Unfortunately we are in Freeze already, so just
uploading 3.2.2 is not easily possible.

https://release.debian.org/testing/freeze_policy.html

However, I can backport patches. According to the GH issue you provided
the bug was introduced in 3.0.22 and fixed with 

https://github.com/FreeRADIUS/freeradius-server/commit/aa5b642a3d6fed8663e5242d91884d25d14e9f53

I will upload a 3.2.1-3 within the next hours to cherry-pick this, could
you please test the resulting binary and report back? I will then apply
for a freeze exception.

Bernhard


signature.asc
Description: PGP signature

Bug#1032435: installation-reports: Fails to install GRUB bootloader

[John Talbut]

Thanks, Pascal, you gave me some more ideas where to look.

I have spent a lot of time on this without being able to discover 
exactly where the error lay in order to be able to correct it without 
going back to square 1.  In the end the only thing that has worked has 
been a complete reinstall including erasing all previous information in 
all partitions.


Consistently what was happening whatever I did was that when I tried to 
boot it would go straight to grub>: - The grub prompt on a blank screen. 
 When I checked the settings and files information on this screen, e.g. 
using ls and set commands, the information never corresponded to what 
was actually installed.


Clearly something was wrong that was used very early in the boot process 
but I was unable to find what.  None of the information that I could 
find online that I could make sense of stated exactly which files or 
settings the UEFI firmware first goes to.


One thing that seems to be the case but is not made clear is that grub 
needs two partitions for booting.  One is a plain EFI partition and the 
other is a normally formatted (e.g. ext4) partition mounted at /boot. 
Confusingly, although the EFI partition seems to get mounted as 
/boot/efi it has to be a separate partition in the installer 
partitioning scheme.

Bug#1032615: dstat is discontinued, let us consider dool ?

[Christian Ehrhardt]

Package: dstat
Version: 0.7.4-6.1

(Resent as I forgot to add package and version due to all the writing)

Hi,
I've used dstat for years and was always happy. Then I stepped away
for a while and recently found it would break if some options were
used. For example in current sid:

root@d10-sid:~# dstat --cpu-adv --noupdate --output foo.csv 10 6
Traceback (most recent call last):
  File "/usr/bin/dstat", line 2847, in 
main()
  File "/usr/bin/dstat", line 2687, in main
scheduler.run()
  File "/usr/lib/python3.11/sched.py", line 151, in run
action(*argument, **kwargs)
  File "/usr/bin/dstat", line 2806, in perform
oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
^^^
  File "/usr/bin/dstat", line 547, in showcsv
if isinstance(self.val[name], types.ListType) or
isinstance(self.val[name], types.TupleType):
  ^
NameError: name 'types' is not defined. Did you mean: 'type'?

Since I remembered this as rather well developed I wondered and had a
look at [1].
Reading there didn't make me too happy as it is essentially dead since
almost 4 years now due to [2].


But it made me spot that there is a continued fork in the form of [3]

That not only fixes the issue I had above, but many many others.
So I wondered if/how we should consider replacing dstat with dool in Debian?

I did check, but there is no ITP yet listed in [4]
So it seems there was no discussion yet AFAICS.

Hence I wanted to ask how/if you'd want to play this out.
1. Should we add dool independent of dstat, and once dool looks good
make dstat a transitional (and add a name alias and conflicts to dool
to take over as drop in)?
2. Should we keep src:dstat even though it actually isn't and use the
dool content (just adding a license and wording changes in some
places, and adding both binary names, probably man page alternatives
as well)
3. Anything else (there are too many details to predict)

Please let me know what you think and prefer, based on that I could
prepare an ITP+upload or a proposal to change src:dstat once I have
some weekend time again. Due to the freezes we have some time anyway
:-)

Thanks in advance for thinking about this with me,
Christian

[1]: https://github.com/dstat-real/dstat
[2]: https://github.com/dstat-real/dstat/issues/170
[3]: https://github.com/scottchiefbaker/dool
[4]: https://www.debian.org/devel/wnpp/requested

-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1021316: rust-kvm-bindings: diff for NMU version 0.5.0-1.1

[Adrian Bunk]

Control: tags 1021316 + patch
Control: tags 1021316 + pending
Control: tags 1024868 + patch

Dear maintainer,

I've prepared an NMU for rust-kvm-bindings (versioned as 0.5.0-1.1) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru rust-kvm-bindings-0.5.0/debian/changelog rust-kvm-bindings-0.5.0/debian/changelog
--- rust-kvm-bindings-0.5.0/debian/changelog	2022-09-27 03:22:22.0 +0300
+++ rust-kvm-bindings-0.5.0/debian/changelog	2023-03-10 08:31:53.0 +0200
@@ -1,3 +1,10 @@
+rust-kvm-bindings (0.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on i386. (Closes: #1021316, #1024868)
+
+ -- Adrian Bunk   Fri, 10 Mar 2023 08:31:53 +0200
+
 rust-kvm-bindings (0.5.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-kvm-bindings-0.5.0/debian/patches/0001-src-x86-does-not-support-32bit-x86.patch rust-kvm-bindings-0.5.0/debian/patches/0001-src-x86-does-not-support-32bit-x86.patch
--- rust-kvm-bindings-0.5.0/debian/patches/0001-src-x86-does-not-support-32bit-x86.patch	1970-01-01 02:00:00.0 +0200
+++ rust-kvm-bindings-0.5.0/debian/patches/0001-src-x86-does-not-support-32bit-x86.patch	2023-03-10 08:31:17.0 +0200
@@ -0,0 +1,29 @@
+From ab632a2c14ad8a9b4ffa2eb18cf162ef51b65ef2 Mon Sep 17 00:00:00 2001
+From: Adrian Bunk 
+Date: Sat, 10 Dec 2022 02:18:43 +0300
+Subject: src/x86/ does not support 32bit x86
+
+Signed-off-by: Adrian Bunk 
+---
+ src/lib.rs | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/lib.rs b/src/lib.rs
+index 005808b..edbc73c 100644
+--- a/src/lib.rs
 b/src/lib.rs
+@@ -11,9 +11,9 @@
+ #[cfg(feature = "fam-wrappers")]
+ extern crate vmm_sys_util;
+ 
+-#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
++#[cfg(any(target_arch = "x86_64"))]
+ mod x86;
+-#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
++#[cfg(any(target_arch = "x86_64"))]
+ pub use self::x86::*;
+ 
+ #[cfg(any(target_arch = "aarch", target_arch = "aarch64"))]
+-- 
+2.30.2
+
diff -Nru rust-kvm-bindings-0.5.0/debian/patches/series rust-kvm-bindings-0.5.0/debian/patches/series
--- rust-kvm-bindings-0.5.0/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ rust-kvm-bindings-0.5.0/debian/patches/series	2023-02-26 01:21:57.0 +0200
@@ -0,0 +1 @@
+0001-src-x86-does-not-support-32bit-x86.patch

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Sanford Rockowitz]

Package: ddcutil
Version: 1.4.2-1
Severity: normal
X-Debbugs-Cc: rockow...@minsoft.com

Bug report #1031259 vs ddcutil 1.4.1-1 suggests installing files in
/usr/lib/modules-load.d to ensure that driver i2c-dev is loaded at system
startup, avoiding the possible need for user configuration after package
installation.  The change was made in the upstream source, and ddcutil 1.4.2-1
was uploaded to mentors on 2023-02-22.

The package sponsor, Andrey Rakhmatullin, has suggested that a pre-approval
request be submitted at this point before uploading from mentors to sid.

The change consists of 2 new files installed into /usr/lib/modules-load.d, an
updated Changelog.md file, along with modified DEBIAN/changelog,
DEBIAN/ddcutil.install, DEBIAN/libddcutil4.install, and updates to relevant
Autotools files.




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

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

Versions of packages ddcutil depends on:
ii  i2c-tools 4.3-2build1
ii  libc6 2.36-0ubuntu4
ii  libdrm2   2.4.113-2
ii  libglib2.0-0  2.74.3-0ubuntu1
ii  libkmod2  30+20220630-3ubuntu1
ii  libudev1  251.4-1ubuntu7
ii  libx11-6  2:1.8.1-2
ii  libxrandr22:1.5.2-2
ii  pci.ids   0.0~2022.08.07-1
ii  usb.ids   2022.05.20-1
ii  usbutils  1:014-1build1

ddcutil recommends no packages.

ddcutil suggests no packages.
diff -Nru ddcutil-1.4.1/CHANGELOG.md ddcutil-1.4.2/CHANGELOG.md
--- ddcutil-1.4.1/CHANGELOG.md  2023-01-23 10:47:29.0 -0500
+++ ddcutil-1.4.2/CHANGELOG.md  2023-02-21 13:26:28.0 -0500
@@ -1,5 +1,16 @@
 # Changelog
 
+## [1.4.2] 2023-02-17
+
+### Added 
+
+- **ddcutil** installation installs files /usr/lib/modules-load.d/ddcutil.conf
+  and /usr/lib/modules-load.d#libddcutil.conf to ensure that kernel module 
+  i2c-dev is loaded at boot time if it is not built into the kernel. There are
+  two files so that when split up into distribution packages, each of the 
+  command line **ddcutil** package and the shared library **libddcutil** 
+  package installs a file.  
+
 ## [1.4.1] 2023-01-16
 
 ### Fixed
diff -Nru ddcutil-1.4.1/configure ddcutil-1.4.2/configure
--- ddcutil-1.4.1/configure 2023-01-23 11:31:05.0 -0500
+++ ddcutil-1.4.2/configure 2023-02-21 13:27:43.0 -0500
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.71 for ddcutil 1.4.1.
+# Generated by GNU Autoconf 2.71 for ddcutil 1.4.2.
 #
 # Report bugs to .
 #
@@ -621,8 +621,8 @@
 # Identity of this package.
 PACKAGE_NAME='ddcutil'
 PACKAGE_TARNAME='ddcutil'
-PACKAGE_VERSION='1.4.1'
-PACKAGE_STRING='ddcutil 1.4.1'
+PACKAGE_VERSION='1.4.2'
+PACKAGE_STRING='ddcutil 1.4.2'
 PACKAGE_BUGREPORT='rockow...@minsoft.com'
 PACKAGE_URL=''
 
@@ -1506,7 +1506,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ddcutil 1.4.1 to adapt to many kinds of systems.
+\`configure' configures ddcutil 1.4.2 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1577,7 +1577,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ddcutil 1.4.1:";;
+ short | recursive ) echo "Configuration of ddcutil 1.4.2:";;
esac
   cat <<\_ACEOF
 
@@ -1753,7 +1753,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ddcutil configure 1.4.1
+ddcutil configure 1.4.2
 generated by GNU Autoconf 2.71
 
 Copyright (C) 2021 Free Software Foundation, Inc.
@@ -2180,7 +2180,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ddcutil $as_me 1.4.1, which was
+It was created by ddcutil $as_me 1.4.2, which was
 generated by GNU Autoconf 2.71.  Invocation command line was
 
   $ $0$ac_configure_args_raw
@@ -2944,7 +2944,7 @@
 printf "%s\n" "#define VERSION_VMINOR  4  " >>confdefs.h
 
 
-printf "%s\n" "#define VERSION_VMICRO  1  " >>confdefs.h
+printf "%s\n" "#define VERSION_VMICRO  2  " >>confdefs.h
 
 
 printf "%s\n" "#define VERSION_VSUFFIX  \"\" " >>confdefs.h
@@ -2954,7 +2954,7 @@
 
 VERSION_VMINOR=4
 
-VERSION_VMICRO=1
+VERSION_VMICRO=2
 
 VERSION_VSUFFIX=""
 
@@ -3506,7 +3506,7 @@
 
 # Define the identity of the package.
  PACKAGE='ddcutil'
- VERSION='1.4.1'
+ VERSION='1.4.2'
 
 
 printf "%s\n" "#define PACKAGE \"$PACKAGE\"" >>confdefs.h
@@ -19678,7 

Bug#1032589: sq-wot: Please update

[Peter Green]

Please try to update this tool in order to have a more recent version
in Bookworm!


I tried to update sequoia-wot and got

dpkg-checkbuilddeps: error: Unmet build dependencies: 
librust-clap-mangen-0.2+default-dev librust-openpgp-cert-d-0.1+default-dev 
librust-sequoia-cert-store-0.2+default-dev librust-sequoia-openpgp-1-dev (>= 
1.13-~~) librust-sequoia-policy-config-0.5+default-dev

clap-mancgen, openpgp-cert sequoia-cert-store and sequoia-policy-config
don't seem to be in Debian at all.

Bug#1032540: conda-package-streaming: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Nilesh Patra]

unblock 1032540 by 1031293
close 1032540
stop


Once python3-zstandard has migrated to testing the build time test
should work again.


python-zstandard has migrated, and I am able to build conda-package-streaming 
in a testing chroot.
Closing the bug.

Thanks,
Nilesh

Bug#1032542: conda-package-handling: FTBFS in testing:, dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11

[Nilesh Patra]

unblock 1032542 by 1031293
close 1032542
stop

python-zstandard has migrated, and I am able to build conda-package-handling in 
a testing chroot.
Closing the bug.

Thanks,
Nilesh

Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Salvatore Bonaccorso]

hi,

On Thu, Mar 09, 2023 at 09:19:53PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> Very unfortunate timing. lnav was prepared back in january with a
> final upload aimed for bookworm (and obviously suceeding then). So
> some new change entering bookworm after is causing it.
> 
> I have forwarded the report upstream
> https://github.com/tstack/lnav/issues/1128 .

So now that's getting interesting. Analyzing the build logs from last
successful run to the archive upload and your build I noticed:

-Setting up libcurl3-gnutls:amd64 (7.87.0-2) ...
-Setting up libcurl4-gnutls-dev:amd64 (7.87.0-2) ...
+Setting up libcurl3-gnutls:amd64 (7.88.1-1) ...
+Setting up libcurl4-gnutls-dev:amd64 (7.88.1-1) ...

In fact if I downgrade the packages to 7.87.0-2 the test suite
succeeds again, would you be able to confirm? 7.88.1-6 as well still
triggers the test failures.

curl maintainers, is there potential for a regression betweeen 7.87.0
and 7.88.1 or a incompatible change between the two which can explain
that?

Regards,
Salvatore

Bug#1032613: sane-utils: sane-find-scanner reports Realtek RTL2832 software defined radio dongles as being graphical scanners

[Mark Robinson]

Package: sane-utils
Version: 1.0.31-4.1
Severity: normal

Dear Maintainer,

$ sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

could not open USB device 0x1d6b/0x0002 at 006:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0001 at 011:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0003 at 007:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 005:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0003 at 004:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 002:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0001 at 010:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 003:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0001 at 009:001: Access denied (insufficient 
permissions)
could not open USB device 0x046d/0xc31c at 001:012: Access denied (insufficient 
permissions)
could not open USB device 0x046d/0xc542 at 001:013: Access denied (insufficient 
permissions)
could not open USB device 0x1a40/0x0101 at 001:003: Access denied (insufficient 
permissions)
found USB scanner (vendor=0x0bda [Realtek], product=0x2838 [RTL2838UHIDIR]) at 
libusb:001:007
could not open USB device 0x0409/0x005a at 001:005: Access denied (insufficient 
permissions)
found USB scanner (vendor=0x0bda [Realtek], product=0x2838 [RTL2838UHIDIR]) at 
libusb:001:004
could not open USB device 0x0409/0x005a at 001:002: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 001:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0001 at 008:001: Access denied (insufficient 
permissions)
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.
$


I think that this causes graphical scanners to become unusable on my system but 
I've no time to analyse it.

The RTL2832 can be used as a radio scanner which could be a source of confusion.

Thank you.

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

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

Versions of packages sane-utils depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libavahi-client3   0.8-5+deb11u1
ii  libavahi-common3   0.8-5+deb11u1
ii  libc6  2.31-13+deb11u5
ii  libieee1284-3  0.2.11-14
ii  libjpeg62-turbo1:2.0.6-4
ii  libpng16-161.6.37-3
ii  libsane1   1.0.31-4.1
ii  libsystemd0247.3-7+deb11u1
ii  libusb-1.0-0   2:1.0.24-3
ii  libxml22.9.10+dfsg-6.7+deb11u3
ii  lsb-base   11.1.0
ii  update-inetd   4.51

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
ii  avahi-daemon  0.8-5+deb11u1
pn  unpaper   

-- debconf information:
  sane-utils/saned_run: false
  sane-utils/saned_scanner_group: true

Bug#1032612: gnome-control-center: wifi can be shut down to save power disables wifi

[tomas k]

Package: gnome-control-center
Version: 1:3.38.4-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: foren...@wi.rr.com

Dear Maintainer,

In gnome-control-center> power, there is an option with a switch "wifi can be 
turned off to save power",
which means if I turn the switch off, wifi will not be turned off to save 
power. 
But in actuality, disabling that option turns wifi off. TYurning wifi back one 
reactivates the 
troublesome switch. 

I would expect the switch to function that if you turn it off, wifi stays on 
all the time.

I know you guys work hard on this stuff. Kudos to you! See what you can do 
about this.  

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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.55-3
ii  apg2.2.3.dfsg.1-5+b2
ii  colord 1.4.5-3
ii  desktop-base   11.0.3
ii  desktop-file-utils 0.26-1
ii  gnome-control-center-data  1:3.38.4-1
ii  gnome-desktop3-data3.38.5-3
ii  gnome-settings-daemon  3.38.2-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  libaccountsservice00.6.55-3
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcheese-gtk253.38.0-3
ii  libcheese8 3.38.0-3
ii  libcolord-gtk1 0.1.26-2
ii  libcolord2 1.4.5-3
ii  libcups2   2.3.3op2-3+deb11u2
ii  libepoxy0  1.5.5-1
ii  libfontconfig1 2.13.1-4.2
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgnome-bluetooth13   3.34.3-2
ii  libgnome-desktop-3-19  3.38.5-3
ii  libgoa-1.0-0b  3.38.0-3
ii  libgoa-backend-1.0-1   3.38.0-3
ii  libgsound0 1.0.2-5
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libgtop-2.0-11 2.40.0-2
ii  libgudev-1.0-0 234-1
ii  libhandy-1-0   1.0.3-2
ii  libibus-1.0-5  1.5.23-2
ii  libkrb5-3  1.18.3-6+deb11u3
ii  libmalcontent-0-0  0.10.0-2
ii  libmm-glib01.14.12-0.2
ii  libnm0 1.30.6-1+deb11u1
ii  libnma01.8.30-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpolkit-gobject-1-0  0.105-31+deb11u1
ii  libpulse-mainloop-glib014.2-2
ii  libpulse0  14.2-2
ii  libpwquality1  1.4.4-1
ii  libsecret-1-0  0.20.4-2
ii  libsmbclient   2:4.13.13+dfsg-1~deb11u5
ii  libsoup2.4-1   2.72.0-2
ii  libudisks2-0   2.9.2-2+deb11u1
ii  libupower-glib30.99.11-2
ii  libwacom2  1.8-2
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.7.2-1
ii  libxi6 2:1.7.10-1
ii  libxml22.9.10+dfsg-6.7+deb11u3

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-3.4
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-user-docs   3.38.2-1
ii  gnome-user-share  3.34.0-2
ii  iso-codes 4.6.0-1
ii  libcanberra-pulse 0.30-7
ii  libnss-myhostname 247.3-7+deb11u1
ii  malcontent-gui0.10.0-2
ii  network-manager-gnome 1.20.0-3
ii  policykit-1   0.105-31+deb11u1
ii  pulseaudio-module-bluetooth   14.2-2
ii  realmd0.16.3-3
ii  rygel 0.40.0-1
ii  rygel-tracker 0.40.0-1
ii  system-config-printer-common  1.5.14-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   3.38.1-1
ii  gstreamer1.0-pulseaudio  1.18.4-2+deb11u1
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-7
ii  x11-xserver-utils7.7+8

-- no debconf information

Bug#1032550: igdiscover: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Nilesh Patra]

On 3/10/23 00:17, Santiago Vila wrote:

Nilesh Patra wrote:

I wonder if it is another of those "$specific-CPU-configuration" failures.


Please note that no specific configuration is mandated by Debian policy, so
I understand that packages must build from source regardless of the number
of CPUs. This is what usually happens, and it's also what our users expect.

If you could not reproduce the randomness with the grub trick above, please
contact me privately, as I could offer ssh access to a machine where
such randomness happens.


Thank you Santiago for providing me access to such a machine. I could repro the 
issue
and added in a patch to fix it as well.
I saw all builds passing on doing 30 consecutive builds with my patch, so I 
believe this
works fine.

I have uploaded with my changes. @Andreas, I think we will need to file an 
unblock request
for this to migrate.

Thanks,
Nilesh

Bug#1032611: ITP: sp800-90b-entropy-assessment -- Estimating the quality of a source of entropy

[NIIBE Yutaka]

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

* Package name: sp800-90b-entropy-assessment
  Version : 1.1.5
  Upstream Contact: Chris Celi 
* URL : https://github.com/usnistgov/SP800-90B_EntropyAssessment
* License : 
https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications#software
  Programming Lang: C++
  Description : Estimating the quality of a source of entropy

 Cryptographic random bit generators (RBGs), also known as random
 number generators (RNGs), require a noise source that produces
 digital outputs with some level of unpredictability, expressed as
 min-entropy.  SP 800-90B provides a standardized means of estimating
 the quality of a source of entropy.

This is a set of tools for NIST's SP 800-90B Recommendation for the
Entropy Sources Used for Random Bit Generation.

Debian has packages for RNG: ent and dieharder.  This package is
specifically useful for evaluating/building TRNG.

Good source of entropy is important for computing, especially for free
computing.  I started PLL-based true random generator project, named
Gomti: https://sr.ht/~gniibe/gomti/

For Gomti, I'm using ea_iid, ea_non_iid, and ea_restart in this
package to evaluate the output of TRNG.

It requires following packages:

libbz2-dev libdivsufsort-dev libjsoncpp-dev libssl-dev libmpfr-dev

I plan to maintain the package at salsa.debian.org.  I'm open to team
maintenance (or co-maintainers), but I don't know appropriate one.
Suggestions are welcome.
-- 

Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[dkm]

March 9, 2023 5:25 PM, "Diederik de Haas"  wrote:

> On Thursday, 9 March 2023 03:38:13 CET d...@kataplop.net wrote:
> 
>> Here's the result of using latest package:
>> 
>> [38.546040] brcmfmac :01:00.0: firmware: failed to load
>> brcm/brcmfmac4356-pcie.bin (-2) [ 38.546408] brcmfmac :01:00.0:
>> firmware: failed to load brcm/brcmfmac4356-pcie.bin (-2) [ 38.546416]
>> brcmfmac :01:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.bin
>> failed with error -2
>> 
>> Downgrading it and reloading the module brings the interface up:
> 
> The brcm/brcmfmac4356-pcie.bin file (f.e.) has been moved/renamed to cypress/
> cyfmac4356-pcie.bin and *maybe* that causes the issue.
> 
> If you can access this file, could you try if it solves the issue?
> https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4035730/artifacts
> file/debian/output/firmware-brcm80211_20230210-3+salsaci_all.deb

Hi!

I've installed this package and still get the same faulty behavior:

[87955.527414] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-pcie 
for chip BCM4356/2
[87955.527517] brcmfmac :01:00.0: firmware: failed to load 
brcm/brcmfmac4356-pcie.gpd-win-pocket.bin (-2)
[87955.527553] brcmfmac :01:00.0: firmware: failed to load 
brcm/brcmfmac4356-pcie.gpd-win-pocket.bin (-2)
[87955.527561] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac4356-pcie.gpd-win-pocket.bin failed with error -2
[87955.527608] brcmfmac :01:00.0: firmware: failed to load 
brcm/brcmfmac4356-pcie.bin (-2)
[87955.527647] brcmfmac :01:00.0: firmware: failed to load 
brcm/brcmfmac4356-pcie.bin (-2)
[87955.527654] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac4356-pcie.bin failed with error -2

Let me know if I can test something else,
Thanks,
Marc

Bug#1032610: reliably composable initramfs - zero-pad output to allow concatenation

[Birgit Edel]

Package: initramfs-tools-core
Version: 0.140
Severity: wishlist
File: /usr/sbin/mkinitramfs
Tags: patch

mkinitramfs supports compression that neither encodes size, nor is 
guaranteed to signal the end of compressed archive. Linux refuses to 
parse additional archives beyond the first compressed one - unless they 
start at 4-byte boundary like uncompressed ones do.


I request
A) to modify mkninitramfs to append such padding and
B) to add tests to ensure concatenation keeps working (even after, say, 
compression algo/lvl changes)


Rationale:
1. Documentation: After the requested change, inserting custom 
configuration or installation prerequisites to provided installation 
media will just work again. Append your changes, done.
2. It worked before: Without compression, still just works(tm). Should 
never have been broken.
3. Debugging: With compression and before the requested change, raw cpio 
and xz-compressed (len modulo 4 == 0) can be concatenated just fine. But 
compressed-after-lz4 or raw-after-compressed makes the kernel ignore the 
second half - and if that was not surprising enough, it *sometimes* 
works, by chance.
4. Least surprise: With or without this change, alignment and/or EOF 
signal might be added by the bootloader [10]. Since this can surprise 
the person working on the image, it would be beneficial to preempt it in 
ways visible in the filesystem.


Considerations:
5. Breaks reproducible builds: Post-change files are up to 0-3 bytes 
bigger. See also #855357
6. Boot bugs: Unlikely, padding was always allowed; since the 
introduction of lz4 even necessary.
7. Breakage in non-kernel Debian software: Unlikely; unmkinitramfs had 
already been documented to not support multiple compressed archives. 
Scripts would not depend on its behavior when parsing such anyway.
8. Breakage in bootloaders/firmware: Unlikely; all compression 
algorithms (save xz) already sometimes produce the post-change 
alignment, by (~25%) chance.


The attached sample code copies the desired bytes from /dev/zero. Also 
attached is an autopkgtest script that calls qemu-system on the 
concatenation of all currently supported compression algorithms in an 
attempt to confirm that the kernel has not errorred out before parsing 
the last one. It worked on my system, but even if it also works on 
yours: beware that it is an amd64-only, non-EFI-only test.


dmesg samples, just to aid in detecting duplicates of this report
Initramfs unpacking failed: invalid magic at start of compressed archive
Initramfs unpacking failed: Decoding failed
Initramfs unpacking failed: broken padding

[10] see grub.git/grub-core/loader/linux.c@a8c473
[11] see linux.git/Documentation/filesystems/ramfs-rootfs-initramfs.rst


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.32-4+b1
ii  cpio 2.13+dfsg-4
ii  e2fsprogs1.46.2-2
ii  klibc-utils  2.0.8-6.1
ii  kmod 28-1
ii  logsave  1.46.2-2
ii  udev 247.3-7+deb11u1

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.30.1-6+b3
ii  pigz 2.6-1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-2

-- no debconf informationdiff --git a/initramfs-tools-0.140/mkinitramfs b/initramfs-tools-0.140/mkinitramfs
index 9516992..332b148 100755
--- a/initramfs-tools-0.140/mkinitramfs
+++ b/initramfs-tools-0.140/mkinitramfs
@@ -451,4 +451,16 @@ if [ -s "${__TMPCPIOGZ}" ]; then
 fi
 } >"${outfile}" || exit 1
 
+# compressed cpio might create a total length breaking otherwise working concatenation
+#  only done once, as early cpio is not compressed, thus unaffected
+# https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html
+# [dmesg] Initramfs unpacking failed: invalid magic at start of compressed archive
+# [dmesg] Initramfs unpacking failed: Decoding failed
+# [dmesg] Initramfs unpacking failed: broken padding
+outsize=$(wc -c <"${outfile}")
+pad=$(( 4 - (outsize % 4) + 4 ))
+# printf "\n\nCOMPRESS %s PADDING %d\n\n" "$compress" "$pad" >&2
+dd status=none bs=1 count=$pad if=/dev/zero >>"${outfile}" ||
+	 { echo "E: mkinitramfs failure padding $?" >&2; exit 1; }
+
 exit 0
diff --git a/initramfs-tools/initramfs-tools-0.140/debian/tests/amd64-appendcpio b/initramfs-tools-0.140/debian/tests/amd64-appendcpio
new file mode 100755
index 000..2293e06
--- /dev/null
+++ b/initramfs-tools-0.140/debian/tests/amd64-appendcpio
@@ -0,0 +1,69 @@
+#!/bin/sh -e
+
+SUPPORTED_FLAVOURS='amd64 generic'
+ROOTDISK_QEMU_IF=virtio
+ROOTDISK_LINUX_NAME=nonexistent
+. debian/tests/test-common
+
+# This 

Bug#1032609: zathura: immediate segmentation fault on some PDF file

[Vincent Lefevre]

On 2023-03-10 02:23:00 +0100, Vincent Lefevre wrote:
> zathura disables coredumps, which is a bigger issue, since one has
> no ideas where it crashes.

Concerning the lack of coredumps, I've done a search on the web
and found this:

  https://blog.winny.tech/posts/debugging-zathura-gtk-seccomp/

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1032609: zathura: immediate segmentation fault on some PDF file

[Vincent Lefevre]

Package: zathura
Version: 0.5.2-1
Severity: important
Tags: security

I got an immediate segmentation fault on some PDF file.

I couldn't reproduce the crash on the same PDF file, so that I suppose
that it is useless to attach it (which is a bit large). This is a PDF
generated by paps piped to ps2pdf (to convert PostScript to PDF).

zathura disables coredumps, which is a bigger issue, since one has
no ideas where it crashes.

Since PDF files often come from untrusted sources, this may be a
security issue. In any case, the code needs to be carefully reviewed.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages zathura depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgirara-gtk3-3 0.3.9-1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libmagic11:5.44-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libseccomp2  2.5.4-1+b3
ii  libsqlite3-0 3.40.1-1
ii  libsynctex2  2022.20220321.62855-5
ii  zathura-pdf-poppler  0.3.1-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  firefox [www-browser]   110.0.1-1
hi  firefox-esr [www-browser]   92.0-local
ii  lynx [www-browser]  2.9.0dev.12-1
ii  opera-stable [www-browser]  96.0.4693.50
ii  w3m [www-browser]   0.5.3+git20230121-2
pn  zathura-cb  
pn  zathura-djvu
pn  zathura-ps  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#992823: takes long time to analyse perl processes

[Paul Wise]

On Mon, 2023-03-06 at 13:40 +0800, Paul Wise wrote:

> I just profiled needrestart using NYTProf and found that the
> problem is actually caused by the Module::ScanDeps Perl module:

Some ideas from a discussion on #debian-perl about this:

 * Parse the Perl code using PPI instead of Module::ScanDeps
    - Change Module::ScanDeps to use PPI instead?
 * Parse the Perl code using Perl's parsing instead
    - Would require getting Perl upstream to export a module
    - or possibly the libperl might have something?
 * Add a Perl module that exports data about imported code
    - PERL5OPT=-MNeedRestart
    - divert /usr/bin/perl to a script that adds -MNeedRestart
 * Add code to Perl upstream that exports data about imported code

Ultimately though, needrestart shouldn't have to parse code (as root?)
in order to figure out what code a particular interpreter process,
for *any* language (including Perl, Python, shell etc) has loaded.

That will require defining a standard for how the processes should
export that information and then sending patches for all interpreters.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1032388: gnome-shell: can't switch keyboard layout using top bar menu in Xorg mode with per-window input source

[Simon McVittie]

Control: retitle -1 gnome-shell: can't switch keyboard layout using top bar 
menu in Xorg mode with per-window input source

On Thu, 09 Mar 2023 at 23:14:10 +0100, Todor Tsankov wrote:
> On 09/03/2023 01:02, Simon McVittie wrote:
> > Is it still the same situation you described in earlier messages, where
> > using Wayland avoids the bug, disabling "Switch input sources individually
> > for each window" also avoids the bug, but it can be reproduced by using
> > Xorg and enabling "Switch input sources individually for each window"?
> > 
> 
> Yes, that's it.

I can reproduce this in a test VM, and I've reported it upstream as
. I don't know
whether it's really a gnome-shell bug or a mutter bug, so I'll leave it
assigned to mutter here for now.

smcv

Bug#1032549: python-pbcore: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Santiago Vila]

reassign 1032549 pylint
found 1032549 2.15.10-1
fixed 1032549 2.16.2-2
affects 1032549 src:python-pbcore
thanks

El 9/3/23 a las 19:18, Nilesh Patra escribió:

This has been fixed with pylint 2.16.2-2, which is currently in unstable but 
it'd migrate to testing
by tomorrow or the day after. Could you please consider to re-build and close 
the bug once it does?


Hi. I have built python-pbcore in bookworm right now to confirm the build 
failure,
and I have also installed pylint from sid in the bookworm chroot to confirm that
pylint was indeed the reason for the failure.

I'm not closing the bug yet, as I see you want to be very cautious, but I 
believe
it could be closed already.

(In either case, I'm doing a reassign to put the bug where it belongs)

Thanks.

Bug#1032608: firmware-iwlwifi: missing one firmware in iwlwifi

[Jonathan Klabunde Tomer]

Package: firmware-iwlwifi
Version: 20230210-1
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
   after upgrading to 20230210-1, my laptop became unable to connect to wifi
   networks
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   booted my computer
   * What was the outcome of this action?
   iwlwifi module failed to load firmware for my device because it was absent,
   so i could not connect to networks
   * What outcome did you expect instead?
   iwlwifi loads firmware and connects to networks

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- no debconf information
>From jonathanto...@gmail.com Mon Sep 17 00:00:00 2001
From: Jonathan Klabunde Tomer 
Date: Wed, 8 Mar 2023 23:44:28 -0800
Subject: [PATCH] iwlwifi: add missing entry to base

The entry in the base section of config/iwlwifi/defines for
iwlwifi-so-a0-hr-b0-72 was missing from 5869e3d, when the section for the fw
itself was added. As a result, since version 71 was removed in b932a14 (and
upstream in 3435843), we no longer include any version of this fw in the
build, removing support for these cards.
---
 debian/changelog  | 4 
 debian/config/iwlwifi/defines | 1 +
 2 files changed, 5 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 6564619..7a2ece7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,11 @@
 firmware-nonfree (20230210-3) UNRELEASED; urgency=medium
 
+  [ Bastian Germann ]
   * firmware-atheros: Remove ath9k_htc from description
 
+  [ Jonathan Klabunde Tomer ]
+  * iwlwifi: add missing entry to base
+
  -- Bastian Germann   Sun, 26 Feb 2023 11:34:51 +0100
 
 firmware-nonfree (20230210-2) unstable; urgency=medium
diff --git a/debian/config/iwlwifi/defines b/debian/config/iwlwifi/defines
index 9b7a3be..9d206b8 100644
--- a/debian/config/iwlwifi/defines
+++ b/debian/config/iwlwifi/defines
@@ -112,6 +112,7 @@ files:
  iwlwifi-so-a0-gf-a0.pnvm
  iwlwifi-so-a0-gf4-a0-72.ucode
  iwlwifi-so-a0-gf4-a0.pnvm
+ iwlwifi-so-a0-hr-b0-72.ucode
  iwlwifi-so-a0-jf-b0-72.ucode
 longdesc: Intel Wireless cards supported by the iwl3945, iwl4965, and
  iwlwifi drivers
-- 
2.39.2

Bug#1032607: open-vm-tools 12.2.0 was released on Mar 7, 2023.

[John Wolfe]

Package: open-vm-tools
Version: 12.2.0

There are no new features in the open-vm-tools 12.2.0 release. This is 
primarily a maintenance release that addresses a few critical problems, 
including:

  *  Linux quiesced snapshots have been updated to avoid intermittent hangs of 
the vmtoolsd process.

  *  Updated the guestOps to handle some edge cases when File_GetSize() fails 
or returns -1.

  *  A number of Coverity reported issues have been addressed.

For complete details, see: 
https://github.com/vmware/open-vm-tools/releases/tag/stable-12.2.0

Release Notes are available at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.2.0/ReleaseNotes.md

The granular changes that have gone into the 12.2.0 release are in the 
ChangeLog at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.2.0/open-vm-tools/ChangeLog

Bug#382269: bluetooth: fails to start bluetooth because firmware

[atumalaca]

Package: bluetooth
Version: 5.55-3.1
Followup-For: Bug #382269
X-Debbugs-Cc: atumal...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation? I cannot use my bluetooth (ATHEROS AR3011) 
because it does not load in firmware. Works fine in Ubuntu. Seems it's a bug 
from 2011.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Nothing was effective, only changing distro.
   * What was the outcome of this action? Works fine in Ubuntu 20.04 and 22.04.
   * What outcome did you expect instead? That my bluetooth works normal.

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


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

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

Versions of packages bluetooth depends on:
ii  bluez  5.55-3.1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
pn  bluez-meshd  
ii  bluez-obexd  5.55-3.1

-- no debconf information

Bug#1032517: [Pkg-nginx-maintainers] Bug#1032517:

[Jan Mojzis]

> 
> Jan,
> Did default config files in /etc/nginx/  moved from nginx-common to nginx ?

Yes,
config files moved to the nginx package, and nginx-common is empty metapackage 
(since 1.22.1-6).

Jan

Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El jue, 9 de mar. de 2023 18:18, Jon Beniston  escribió:

> Hi,
>
> >> It would be good if the serial NMEA plugin could be added
> (libqtposition_serialnmea.so), so serial port / USB GPS devices can be used
> directly
>
> >I remember looking into this when I've got to package it. Looking at the
> build log [1] I think it needs the Gypsy GPS Daemon, which I understand it
> is not packaged in Debian.
>
> The serial NMEA plugin doesn't need Gypsy GPS Demon. (The plugin is for
> directly accessing serial GPS devices). There is a separate plugin that
> uses
> Gypsy.
>
> It does require the qt serial port package though (libqt5serialport5), and
> I
> can't see being referenced in that build log. Does it need to be added as a
> dependency?



Yes, it is possible. Sadly we won't make it for the bullseye release :-( I
would be more than happy to add that feature as soon as possible

Bug#1032388: gnome-shell: fails to switch keyboard layout from topbar menu

[Todor Tsankov]

On 09/03/2023 01:02, Simon McVittie wrote:
> Control: reopen -1
> 
> On Wed, 08 Mar 2023 at 19:55:20 +0100, Todor Tsankov wrote:
>> On 07/03/2023 12:21, Debian Bug Tracking System wrote:
>> > #1032388: gnome-shell: fails to switch keyboard layout from topbar menu
>> 
>> The bug is still present for me with mutter 43.3-5 from unstable.
> 
> Even after logging out and back in?
> 

Yes.

> Is anything logged in the journal?
> 

Yes, this message:

Mar 09 23:02:58 alsvin gnome-shell[3173]: Window manager warning:
Overwriting existing binding of keysym ff09 with keysym ff09 (keycode 17).

I am not sure what it is about.

> Is it still the same situation you described in earlier messages, where
> using Wayland avoids the bug, disabling "Switch input sources individually
> for each window" also avoids the bug, but it can be reproduced by using
> Xorg and enabling "Switch input sources individually for each window"?
> 

Yes, that's it.

--Todor

Bug#1032606: ITP: etlcpp -- Embedded template library: a C++ template library for embedded applications

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: etlcpp
  Version : 20.35.14
  Upstream Author : John Wellbelove
* URL or Web page : https://www.etlcpp.com/
* License : MIT
  Description : Embedded template library: a C++ template library for 
embedded applications

Bug#1032545: r-cran-qpdf: FTBFS in testing: QPDF.hh:1569:36: error: ‘std::string_view’ has not been declared

[Andreas Tille]

Am Thu, Mar 09, 2023 at 10:08:02PM +0100 schrieb Sebastian Ramacher:
> > What do you think?
> 
> std::string_view was introduced in C++17, but r-cran-qpdf is building
> with C++11. Have you tried bumping the C++ version?

Ahhh, right.  Thanks a lot for the hint.  Just uploaded a fix.

I guess I need to file an unblock request for the just uploaded
r-cran-qpdf 1.3.0+dfsg-2?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1032373: fwupd: Can't update in Secure Boot mode on Thinkpad Carbon X1 Gen5

[Steve McIntyre]

Hey Russell,

On Sun, Mar 05, 2023 at 11:11:18PM +1100, Russell Coker wrote:
>Package: fwupd
>Version: 1.8.12-2
>Severity: normal
>
>I have a Thinkpad Carbon X1 Gen5 running Debian/Testing with the fwupd from
>Unstable with Secure Boot enabled.  I believe that we should get everything
>working with Secure Boot enabled and to the largest extent possible have
>Debian working with all security features.
>
>When I install updates with the "fwupdmgr" program it looks like it is all
>working well, the updates are installed and it prompts to reboot the system.
>
>When I boot up I get a screen with white text on blue background saying
>"Verification failed: (0x1A) Security Violation" which according to various
>pages Google turns up means it's a secure boot issue.

Yes, that sounds like a correct diagnosis.

>I have the fwupd-amd64-signed package installed, but the version doesn't seem
>to match, is there a problem with this?
>
># dpkg -l fwupd\*|grep ^ii
>ii  fwupd  1.8.12-2 amd64Firmware update 
>daemon
>ii  fwupd-amd64-signed 1:1.4+1  amd64Tools to manage 
>UEFI firmware updates (signed)
>ii  fwupdate   12-7 amd64Transitional 
>package for fwupd

Nope, this should be fine. The fwupd folks moved the fwupd UEFI
support out into a separate source package a while back, hence the
distinct versioning. (Compare https://tracker.debian.org/pkg/fwupd
with https://tracker.debian.org/pkg/fwupd-efi).

I'm not sure what exactly might be happening here to cause your
problem. Could you run the following for me and report the output
please?

# find /boot/efi/ -type f | xargs sha256sum

I'd like to double-check exactly what things you have in the ESP...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#1032604: linux-image-6.1.0-6-amd64-unsigned: Include ublk driver (CONFIG_BLK_DEV_UBLK)

[Salvatore Bonaccorso]

Hi Vitaliy,

On Thu, Mar 09, 2023 at 11:58:50PM +0300, Vitaliy Filippov wrote:
> Package: src:linux
> Version: 6.1.15-1
> Severity: normal
> 
> Dear Maintainer,
> 
> There is a new "ublk" driver in the upstream Linux since 6.0 
> https://www.kernel.org/doc/html/next/block/ublk.html
> 
> Please include in the build. Currently it's not included,
> CONFIG_BLK_DEV_UBLK is not set.

I believe this is too early. The driver is furthermore still
considered experimental, so nothing we would ship at this stage for
bookworm. Maybe after bookworm release it can be reconsidered
depending on how it evolves and be included in trixie?

If people want to experiment with it already now I guess the best
option is to build a own kernel.

Regards,
Salvatore

Bug#1032605: apt: should change "non-free" to "non-free non-free-firmware" in /etc/apt/sources.list

[Vincent Lefevre]

Package: apt
Version: 2.6.0
Severity: important

Since packages like intel-microcode have moved from non-free to
non-free-firmware, apt should update the /etc/apt/sources.list
file accordingly.

It seems that users of the bookworm repository had the update
of /etc/apt/sources.list, but nothing has been done for testing
and unstable.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-listchanges-main "listchanges.conf";
Dir::Etc::apt-listchanges-parts "listchanges.conf.d";
Dir::Etc::apt-file-main "apt-file.conf";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::solvers "";
Dir::Bin::solvers:: "/usr/lib/apt/solvers";
Dir::Bin::planners "";
Dir::Bin::planners:: "/usr/lib/apt/planners";
Dir::Bin::dpkg 

Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Jon Beniston]

Hi,
 
>> It would be good if the serial NMEA plugin could be added
(libqtposition_serialnmea.so), so serial port / USB GPS devices can be used
directly

>I remember looking into this when I've got to package it. Looking at the
build log [1] I think it needs the Gypsy GPS Daemon, which I understand it
is not packaged in Debian.

The serial NMEA plugin doesn't need Gypsy GPS Demon. (The plugin is for
directly accessing serial GPS devices). There is a separate plugin that uses
Gypsy.

It does require the qt serial port package though (libqt5serialport5), and I
can't see being referenced in that build log. Does it need to be added as a
dependency?

Cheers,
Jon

Bug#1032604: linux-image-6.1.0-6-amd64-unsigned: Include ublk driver (CONFIG_BLK_DEV_UBLK)

[Vitaliy Filippov]

Package: src:linux
Version: 6.1.15-1
Severity: normal

Dear Maintainer,

There is a new "ublk" driver in the upstream Linux since 6.0 
https://www.kernel.org/doc/html/next/block/ublk.html

Please include in the build. Currently it's not included, CONFIG_BLK_DEV_UBLK 
is not set.

-- Package-specific info:
** Version:
Linux version 6.1.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05)

Bug#1032545: r-cran-qpdf: FTBFS in testing: QPDF.hh:1569:36: error: ‘std::string_view’ has not been declared

[Sebastian Ramacher]

On 2023-03-09 21:13:02 +0100, Andreas Tille wrote:
> Hi,
> 
> Am Wed, Mar 08, 2023 at 09:30:38PM +0100 schrieb Lucas Nussbaum:
> > > /usr/include/qpdf/QPDF.hh:1569:36: error: ‘std::string_view’ has not been 
> > > declared
> > >  1569 | void linearizationWarning(std::string_view);
> > >   |^~~
> > > In file included from bindings.cpp:3:
> > > /usr/include/qpdf/QPDFWriter.hh:557:27: error: ‘std::string_view’ has not 
> > > been declared
> > >   557 | void writeString(std::string_view str);
> > >   |   ^~~
> > > /usr/include/qpdf/QPDFWriter.hh:559:30: error: ‘std::string_view’ has not 
> > > been declared
> > >   559 | void writeStringQDF(std::string_view str);
> > >   |  ^~~
> > > /usr/include/qpdf/QPDFWriter.hh:560:32: error: ‘std::string_view’ has not 
> > > been declared
> > >   560 | void writeStringNoQDF(std::string_view str);
> > >   |^~~
> > > make[1]: *** [/usr/lib/R/etc/Makeconf:178: bindings.o] Error 1
> 
> This error occures due to the upgrade of qpdf from 11.2.0 to 11.3.0.
> r-cran-qpdf ships with a code copy of 11.2.0 which was removed in favour
> of dynamic linking.  The only way I see to fix this bug while keeping
> the same r-cran-qpdf version is to keep the original upstream tarball
> and link against the code copy.
> 
> What do you think?

std::string_view was introduced in C++17, but r-cran-qpdf is building
with C++11. Have you tried bumping the C++ version?

Cheers
-- 
Sebastian Ramacher

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

[Marc-Robin Wendt]

Hello Salvatore,

I followed instructions and it made me a linux-image-5.10.0-21-amd64-
unsigned_5.10.162-1a~test_amd64.deb, which, after installed, boots
nicely and seems to work without errors at mpt3sas anymore.
All XEN-functionality seems to work in our environment.

Anyhow I had some errors:

qla2xxx :61:00.1: swiotlb buffer is full (sz: 65536 bytes), total
32768 (slots), used 28799 (slots)

But I'm not sure, if this is releated and it doesn't affect functions.

Do you need further informations about the testing process?
-- 
Greetings
Marc-Robin

On Wed, 2023-03-08 at 17:38 +0100, Salvatore Bonaccorso wrote:
> Hi Marc,
> 
> On Sat, Mar 04, 2023 at 12:09:15PM +0100, Marc-Robin Wendt wrote:
> > Its actually not my game, but if it speeds things up, I will help
> > testing (if anyone tells me, what to do).
> 
> Thank you. Can you try with the following series of 4 patches.
> 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> 
> will describe how to pass a series of patches to apply for testing.
> 
> Thanks already in advance,
> 
> Regards,
> Salvatore

Bug#1031696: Also affects bookworm

[Pete Batard]

Please note that, since bookworm has started to include firmware files, 
this issue is also starting to affect bookworm users [1] and I can only 
advise Debian maintainers to raise its priority, rather than dismiss it 
as something that will only affect folks who don't use DD mode to write 
the ISOHybrid, as this is going to affect people who are used to simply 
extracting the ISO content onto FAT32 media to install Debian on a UEFI 
system.


In short, if this issue is left unaddressed, bookworm will be 
introducing a *regression* compared to bullseye, in that it will no 
longer be possible to perform a Debian installation on a UEFI system 
through file system transposition, and everyone will be forced to either 
use DD or use a utility (like Rufus 3.22) that includes a *custom 
workaround* for Debian, in order to duplicate the symbolically linked 
firmware files.


Regards,

/Pete

[1] 
https://old.reddit.com/r/debian/comments/11mqi55/debian_installer_bookworm_alpha_2_missing_firmware/

Bug#1031649: wine: /usr/bin/wine64 still required

[Paul Gevers]

Hi Jens,

On 09-03-2023 19:06, Jens Reyer wrote:

2.
Keep everything as it is now, make sure vulkan 1.3.239 doesn't make it 
to bullseye, and bullseye-ignore this and the 2 other bugs.


I assume you ment bookworm when you wrote bullseye here. However:
$ rmadison  -s unstable,testing vulkan-loader
vulkan-loader | 1.3.239.0-1   | testing| source
vulkan-loader | 1.3.239.0-1   | unstable   | source

vulkan already migrated a month ago, so that ship has sailed.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Salvatore Bonaccorso]

Hi,

Very unfortunate timing. lnav was prepared back in january with a
final upload aimed for bookworm (and obviously suceeding then). So
some new change entering bookworm after is causing it.

I have forwarded the report upstream
https://github.com/tstack/lnav/issues/1128 .

Regards,
Salvatore

Bug#1032545: r-cran-qpdf: FTBFS in testing: QPDF.hh:1569:36: error: ‘std::string_view’ has not been declared

[Andreas Tille]

Hi,

Am Wed, Mar 08, 2023 at 09:30:38PM +0100 schrieb Lucas Nussbaum:
> > /usr/include/qpdf/QPDF.hh:1569:36: error: ‘std::string_view’ has not been 
> > declared
> >  1569 | void linearizationWarning(std::string_view);
> >   |^~~
> > In file included from bindings.cpp:3:
> > /usr/include/qpdf/QPDFWriter.hh:557:27: error: ‘std::string_view’ has not 
> > been declared
> >   557 | void writeString(std::string_view str);
> >   |   ^~~
> > /usr/include/qpdf/QPDFWriter.hh:559:30: error: ‘std::string_view’ has not 
> > been declared
> >   559 | void writeStringQDF(std::string_view str);
> >   |  ^~~
> > /usr/include/qpdf/QPDFWriter.hh:560:32: error: ‘std::string_view’ has not 
> > been declared
> >   560 | void writeStringNoQDF(std::string_view str);
> >   |^~~
> > make[1]: *** [/usr/lib/R/etc/Makeconf:178: bindings.o] Error 1

This error occures due to the upgrade of qpdf from 11.2.0 to 11.3.0.
r-cran-qpdf ships with a code copy of 11.2.0 which was removed in favour
of dynamic linking.  The only way I see to fix this bug while keeping
the same r-cran-qpdf version is to keep the original upstream tarball
and link against the code copy.

What do you think?

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1032603: umbrello: FTBFS on hppa - Please enable LFS

[John David Anglin]

Source: umbrello
Version: 4:22.12.3-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails here:
Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_428e4/fast && gmake[2]: 
Entering directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J'
/usr/bin/gmake  -f CMakeFiles/cmTC_428e4.dir/build.make 
CMakeFiles/cmTC_428e4.dir/build
gmake[3]: Entering directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J'
Building CXX object CMakeFiles/cmTC_428e4.dir/src.cxx.o
/usr/bin/c++ -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_OFFT_IS_64BIT  -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2  -fno-delete-null-pointer-checks 
-Wno-deprecated-declarations  -std=gnu++17 -o 
CMakeFiles/cmTC_428e4.dir/src.cxx.o -c 
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx:7:33:
 warning: left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx:8:23:
 note: in expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx:7:57:
 warning: left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx:8:23:
 note: in expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J/src.cxx:8:89:
 error: size ‘-1’ of array ‘off_t_is_large’ is negative
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |  
~~~^~~~
gmake[3]: *** [CMakeFiles/cmTC_428e4.dir/build.make:78: 
CMakeFiles/cmTC_428e4.dir/src.cxx.o] Error 1
gmake[3]: Leaving directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J'
gmake[2]: *** [Makefile:127: cmTC_428e4/fast] Error 2
gmake[2]: Leaving directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-wH7h8J'


Source file was:

#include 
 /* Check that off_t can represent 2**63 - 1 correctly.
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807.  */
#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  int main() { return 0; }


dh_auto_configure: error: cd obj-hppa-linux-gnu && cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/hppa-linux-gnu 
-DCMAKE_BUILD_TYPE=Debian -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DBUILD_KF5=ON .. returned exit code 1
make[1]: *** [debian/rules:14: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=umbrello=hppa=4%3A22.12.3-1=1677784733=0

Build is successful if LFS is enabled, "future=+lfs" option. I had a successful
build with it:
https://buildd.debian.org/status/fetch.php?pkg=umbrello=hppa=4%3A22.12.3-1=1678355202=0

Regards,
Dave Anglin

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

Kernel: Linux 6.1.15+ (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#1032602: calligra: FTBFS on hppa - please enable LFS

[John David Anglin]

Source: calligra
Version: 1:3.2.1+dfsg-7
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails here:

Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_07c80/fast && gmake[2]: 
Entering directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY'
/usr/bin/gmake  -f CMakeFiles/cmTC_07c80.dir/build.make 
CMakeFiles/cmTC_07c80.dir/build
gmake[3]: Entering directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY'
Building CXX object CMakeFiles/cmTC_07c80.dir/src.cxx.o
/usr/bin/c++ -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_OFFT_IS_64BIT  -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wno-deprecated -Wno-deprecated-declarations -Wdate-time -D_FORTIFY_SOURCE=2  
-std=c++17 -o CMakeFiles/cmTC_07c80.dir/src.cxx.o -c 
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx:7:33:
 warning: left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx:8:23:
 note: in expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx:7:57:
 warning: left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx:8:23:
 note: in expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY/src.cxx:8:89:
 error: size ‘-1’ of array ‘off_t_is_large’ is negative
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |  
~~~^~~~
gmake[3]: *** [CMakeFiles/cmTC_07c80.dir/build.make:78: 
CMakeFiles/cmTC_07c80.dir/src.cxx.o] Error 1
gmake[3]: Leaving directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY'
gmake[2]: *** [Makefile:127: cmTC_07c80/fast] Error 2
gmake[2]: Leaving directory 
'/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-xHX3fY'


Source file was:

#include 
 /* Check that off_t can represent 2**63 - 1 correctly.
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807.  */
#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  int main() { return 0; }


dh_auto_configure: error: cd obj-hppa-linux-gnu && cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/hppa-linux-gnu 
-DCMAKE_BUILD_TYPE=Debian -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DBUILD_TESTING=OFF -DBUILD_app_cstester=OFF 
-DBUILD_app_devtools=OFF -DCALLIGRA_SHOULD_BUILD_UNMAINTAINED=ON .. returned 
exit code 1
make[1]: *** [debian/rules:13: override_dh_auto_configure] Error 25

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=calligra=hppa=1%3A3.2.1%2Bdfsg-7=1678056816=0

Build is successful if LFS is enabled, "future=+lfs" option. I had a successful
build with it:
https://buildd.debian.org/status/fetch.php?pkg=calligra=hppa=1%3A3.2.1%2Bdfsg-7=1678349115=0

Regards,
Dave Anglin


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

Kernel: Linux 6.1.15+ (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#1026062: kded5: Catched kded5 crash in systemctl status

[Ronald Púpala]

Package: kded5
Version: 5.103.0-1
Followup-For: Bug #1026062

Dear Maintainer,

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

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

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


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

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

Versions of packages kded5 depends on:
ii  libc6  2.36-8
ii  libkf5configcore5  5.103.0-1
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5crash5   5.103.0-1
ii  libkf5dbusaddons5  5.103.0-1
ii  libkf5service-bin  5.103.0-1
ii  libkf5service5 5.103.0-1
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5dbus55.15.8+dfsg-3
ii  libqt5gui5 5.15.8+dfsg-3
ii  libqt5widgets5 5.15.8+dfsg-3
ii  libstdc++6 12.2.0-14

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information


rony@ares:~$ systemctl  --user status plasma-kded.service
● plasma-kded.service - KDE Daemon
 Loaded: loaded (/usr/lib/systemd/user/plasma-kded.service; static)
 Active: active (running) since Thu 2023-03-09 20:16:53 CET; 2min 51s ago
   Main PID: 61674 (kded5)
  Tasks: 32 (limit: 16600)
 Memory: 114.0M
CPU: 4.436s
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kded.service
 ├─61674 /usr/bin/kded5
 ├─61701 /usr/bin/xsettingsd
 ├─62111 /usr/bin/kded5
 └─62113 /usr/lib/x86_64-linux-gnu/libexec/drkonqi --platform xcb 
--display :0 --appname kded5 --apppath /usr/bin --signal 11 --pid 61674 
--restarted

mar 09 20:18:54 ares kded5[62111]: apper.daemon: Creating Helper
mar 09 20:18:54 ares kded5[62111]: apper.daemon: System is not ready, 
application should conserve resources
mar 09 20:18:54 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:18:54 ares kded5[62111]: packagekitqt.transaction: Unknown 
Transaction property: "Sender" QVariant(QString, ":1.759")
mar 09 20:18:54 ares kded5[62111]: packagekitqt.transaction: Unknown 
Transaction property: "Sender" QVariant(QString, ":1.759")
mar 09 20:18:54 ares kded5[62111]: Registering ":1.37/StatusNotifierItem" to 
system tray
mar 09 20:18:54 ares kded5[62111]: Registering ":1.198/StatusNotifierItem" to 
system tray
mar 09 20:18:54 ares kded5[62111]: Registering ":1.49/StatusNotifierItem" to 
system tray
mar 09 20:18:55 ares kded5[62111]: kf.i18n: KLocalizedString: Using an empty 
domain, fix the code. msgid: "There is one new update" msgid_plural: "There are 
%1 new updates" msgctxt: ""
mar 09 20:18:55 ares kded5[62111]: kf.i18n: KLocalizedString: Using an empty 
domain, fix the code. msgid: "Review" msgid_plural: "" msgctxt: ""
rony@ares:~$ systemctl  --user status plasma-kded.service
× plasma-kded.service - KDE Daemon
 Loaded: loaded (/usr/lib/systemd/user/plasma-kded.service; static)
 Active: failed (Result: exit-code) since Thu 2023-03-09 20:19:46 CET; 27s 
ago
   Duration: 2min 52.222s
Process: 61674 ExecStart=/usr/bin/kded5 (code=exited, status=255/EXCEPTION)
   Main PID: 61674 (code=exited, status=255/EXCEPTION)
CPU: 4.560s

mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares kded5[62111]: QDBusAbstractAdaptor: Cannot relay signal 
KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
mar 09 20:19:46 ares systemd[1673]: plasma-kded.service: 

Bug#1032601: The patch

[spinal . by]

xfconf-4.18.0.patch
Description: Binary data

Bug#1032413: kodi-inputstream-adaptive FTCBFS: assumes a toolchain file

[Timo Röhling]

Hi,

* Helmut Grohne  [2023-03-06 13:12]:

A while later meson came along and when adding support for it, we
actually created a "crossfile" (how meson calls it) and pass that. That
option certainly is on the table. Another major difference here is that
the tool that creates this crossfile currently is a script debcrossgen
in the meson package and we can change this crossfile generator without
touching debhelper. For cmake, we've essentially inlined this into
Debian::Debhelper::Buildsystem::cmake, so whenever we need to change a
cmake cross compilation flag, we need a debhelper upload, which is
suboptimal.

Given that meson and cmake are also part of the toolchain
build-essential set (just like debhelper), would it not be better to
have a separate cross-toolchain-helper package that provides such
generators for all supported build systems?


So yeah, I recognize that a toolchain file probably is the more common
way of cross building cmake projects and maybe we should switch to that
model.

I'd say that is a matter of personal preference. It is certainly
more convenient for developers who need to invoke cmake manually,
but in effect, it is not much different from the current "inline"
approach.

While we are on the subject, you may be interested to learn that cmake
recently gained an new feature to inject variables and configure
many aspects of the cmake build cycle via configuration file [1].
This might even be useful for debhelper in general.


Cheers
Timo

[1] https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1032601: libxfconf-0-dev doesn't provide Vala API files

[Arthur Demchenkov]

Package: libxfconf-0-dev
Version: 4.18.0-2
Severity: important
Tags: patch

Dear Maintainer,

I'm trying to build Xfce panel plugin which is written using Vala
language, and it fails because of missing Vala API files in
libxfconf-0-dev package.

Vala is the language which is widely used for writing applications
that use glib/gtk+ libraries.

I attach the patch for xfconf package that can fix the issue.

The plugin I was trying to build:
https://gitlab.xfce.org/panel-plugins/xfce4-notes-plugin

Thank you!


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

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

Versions of packages libxfconf-0-dev depends on:
ii  gir1.2-xfconf-0   4.18.0-2
ii  libglib2.0-dev2.74.6-1
ii  libxfconf-0-3 4.18.0-2
ii  pkg-config1.8.1-1
ii  pkgconf [pkg-config]  1.8.1-1

libxfconf-0-dev recommends no packages.

libxfconf-0-dev suggests no packages.

-- no debconf information

Bug#1032600: nautilus: crash with gtk-4-1 (4.10.0+ds-1)

[Patrice Duroux]

Package: nautilus
Version: 44~rc-1
Severity: normal

Dear Maintainer,

My system is a Sid + some experimental packages related to GNOME 44.

Here is the coredumpctl output:

   PID: 18898 (nautilus)
   UID: 1001 (patrice)
   GID: 1001 (patrice)
Signal: 11 (SEGV)
 Timestamp: Thu 2023-03-09 19:50:28 CET (6min ago)
  Command Line: nautilus
Executable: /usr/bin/nautilus
 Control Group: /user.slice/user-1001.slice/user@1001.service/app.slice/app-
org.gnome.Terminal.slice/vte-spawn-8c1d6d05-2053-4c57-83e1-497091928919.scope
  Unit: user@1001.service
 User Unit: vte-spawn-8c1d6d05-2053-4c57-83e1-497091928919.scope
 Slice: user-1001.slice
 Owner UID: 1001 (patrice)
   Boot ID: 113369a57e60432088271379fdb28e3a
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: kos-moceratops
   Storage:
/var/lib/systemd/coredump/core.nautilus.1001.113369a57e60432088271379fdb28e3a.18898.167838782800.zst
(present)
  Size on Disk: 8.8M
   Message: Process 18898 (nautilus) of user 1001 dumped core.

Module libudev.so.1 from deb systemd-252.6-1.amd64
Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Stack trace of thread 18898:
#0  0x7fb6f00d9352 n/a (libgtk-4.so.1 + 0xd9352)
#1  0x7fb6f00cf421 gtk_accessible_update_property
(libgtk-4.so.1 + 0xcf421)
#2  0x7fb6f08b36bd n/a (libgobject-2.0.so.0 + 0x1b6bd)
#3  0x7fb6f08b63cf g_object_setv (libgobject-2.0.so.0 +
0x1e3cf)
#4  0x7fb6f08b747b g_object_set_property
(libgobject-2.0.so.0 + 0x1f47b)
#5  0x7fb6f08a8983 n/a (libgobject-2.0.so.0 + 0x10983)
#6  0x7fb6f08ae450 g_closure_invoke (libgobject-2.0.so.0 +
0x16450)
#7  0x7fb6f08c12f6 n/a (libgobject-2.0.so.0 + 0x292f6)
#8  0x7fb6f08c7e75 g_signal_emit_valist
(libgobject-2.0.so.0 + 0x2fe75)
#9  0x7fb6f08c803f g_signal_emit (libgobject-2.0.so.0 +
0x3003f)
#10 0x7fb6f08b22b4 n/a (libgobject-2.0.so.0 + 0x1a2b4)
#11 0x7fb6f08b5227 g_object_notify_by_pspec
(libgobject-2.0.so.0 + 0x1d227)
#12 0x560979804a6e n/a (nautilus + 0x3fa6e)
#13 0x560979805c3d n/a (nautilus + 0x40c3d)
#14 0x56097980642b n/a (nautilus + 0x4142b)
#15 0x5609798069ba n/a (nautilus + 0x419ba)
#16 0x56097988f24a n/a (nautilus + 0xca24a)
#17 0x7fb6f09eadef g_main_context_dispatch
(libglib-2.0.so.0 + 0x59def)
#18 0x7fb6f09eb1c8 n/a (libglib-2.0.so.0 + 0x5a1c8)
#19 0x7fb6f09eb25c g_main_context_iteration
(libglib-2.0.so.0 + 0x5a25c)
#20 0x7fb6efdd80cd g_application_run (libgio-2.0.so.0 +
0xe00cd)
#21 0x5609797f2ceb n/a (nautilus + 0x2dceb)
#22 0x7fb6ef86218a __libc_start_call_main (libc.so.6 +
0x2718a)
#23 0x7fb6ef862245 __libc_start_main_impl (libc.so.6 +
0x27245)
#24 0x5609797f2d31 n/a (nautilus + 0x2dd31)


Moreover, I am not able to install the libgtk-4-1-dbgsym from experimental, is
that «normal»?

By the way, Nautilus is also suffering a similar problem to
appstream (https://github.com/ximion/appstream/issues/470)
and
ostree (https://github.com/ostreedev/ostree/issues/2827)

with (lot of) messages like those:

(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.894: GFileInfo
created without standard::sort-order
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.894: file
../../../gio/gfileinfo.c: line 2061 (g_file_info_get_sort_order): should not be
reached
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: GFileInfo
created without standard::edit-name
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: file
../../../gio/gfileinfo.c: line 1697 (g_file_info_get_edit_name): should not be
reached
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: GFileInfo
created without standard::is-symlink
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: file
../../../gio/gfileinfo.c: line 1631 (g_file_info_get_is_symlink): should not be
reached
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: GFileInfo
created without standard::is-hidden
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: file
../../../gio/gfileinfo.c: line 1587 (g_file_info_get_is_hidden): should not be
reached
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: GFileInfo
created without standard::is-backup
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: file
../../../gio/gfileinfo.c: line 1609 (g_file_info_get_is_backup): should not be
reached
(org.gnome.Nautilus:18898): GLib-GIO-CRITICAL **: 19:50:28.929: GFileInfo
created without standard::sort-order

Bug#1032599: DejaVu TTF file modification time

[Boyuan Yang]

Source: fonts-dejavu
Version: 2.37-5
Severity: normal
X-Debbugs-CC: fab...@debian.org zino...@tiscali.it

在 2023-03-09星期四的 14:48 +0100，y...@centrum.cz写道：
> Would it be possible to change the last modified time of the files when
> the content is changed?

This seems a valid bug. Converting into a bug report against src:fonts-
dejavu.

Thanks,
Boyuan Yang

> Example (Debian Bullseye vs. Bookworm):
> 
> 1febe065ea088f1cad75b9b83d08cf2b  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
> f59457d7ce48dd38a0c8aee8afc6f91a  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
> b7d24616d08e8c4078625b0dbc58f788  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
> c031de593106b3460e9fb2afa809739d  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
> a5f738a3580a34a186c0429e228a046e  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSerif-Bold.ttf
> 28b1e0094a2742f5bdeff02c5f27b587  fonts-dejavu-core_2.37-
> 2_all/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf
> 8e8b513b726656ec8d6e10cda501e093  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
> 06cad0e761fdbe54bf1dc994d68345c1  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
> fb8092f241307d55d227ec087bebacb2  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
> 103fd854bda52322e91cae038bca5f6e  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
> 210b05a3bd109be17bcab2b2afafacff  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSerif-Bold.ttf
> e91039cc9d7b02c664497148ac8b4a96  fonts-dejavu-core_2.37-
> 5_all/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf
> 
> ... content changed but date remains 2016-07-30 09:51:12 (touch in
> Makefile).
> 
> Some systems (especially backups) may depend on this information.
> 



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

Bug#1032598: libxfce4panel-2.0-dev doesn't provide Vala API files

[Arthur Demchenkov]

Package: libxfce4panel-2.0-dev
Version: 4.18.2-1
Severity: important
Tags: patch

Dear Maintainer,

I'm trying to build Xfce panel plugin which is written using Vala
language, and it fails because of missing Vala API files in
libxfce4panel-2.0-dev package.

Vala is the language which is widely used for writing applications
that use glib/gtk+ libraries.

I attach the patch for xfce4-panel package that can fix the issue.

The plugin I was trying to build:
https://gitlab.xfce.org/panel-plugins/xfce4-notes-plugin

Thank you!


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

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

Versions of packages libxfce4panel-2.0-dev depends on:
ii  gir1.2-libxfce4panel-2.0  4.18.2-1
ii  libglib2.0-dev2.74.6-1
ii  libgtk-3-dev  3.24.36-5
ii  libxfce4panel-2.0-4   4.18.2-1
ii  libxfce4util-dev  4.18.1-2

libxfce4panel-2.0-dev recommends no packages.

libxfce4panel-2.0-dev suggests no packages.

-- no debconf information
diff -Naur xfce4-panel-4.18.2-orig/debian/control 
xfce4-panel-4.18.2/debian/control
--- xfce4-panel-4.18.2-orig/debian/control  2023-01-12 10:55:51.0 
+0300
+++ xfce4-panel-4.18.2/debian/control   2023-03-09 21:26:23.315340377 +0300
@@ -19,6 +19,7 @@
libxfce4ui-2-dev (>= 4.17.1),
libxfce4util-dev (>= 4.17.2),
libxfconf-0-dev,
+   valac,
xfce4-dev-tools
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
diff -Naur xfce4-panel-4.18.2-orig/debian/libxfce4panel-2.0-dev.install 
xfce4-panel-4.18.2/debian/libxfce4panel-2.0-dev.install
--- xfce4-panel-4.18.2-orig/debian/libxfce4panel-2.0-dev.install
2022-08-29 02:22:07.0 +0300
+++ xfce4-panel-4.18.2/debian/libxfce4panel-2.0-dev.install 2023-03-09 
21:31:11.642408338 +0300
@@ -3,3 +3,4 @@
 usr/lib/*/pkgconfig/libxfce4panel-2.0.pc
 usr/share/gtk-doc/html/libxfce4panel-2.0
 usr/share/gir-1.0/*
+usr/share/vala/vapi/*
diff -Naur xfce4-panel-4.18.2-orig/debian/rules xfce4-panel-4.18.2/debian/rules
--- xfce4-panel-4.18.2-orig/debian/rules2023-02-27 08:06:13.0 
+0300
+++ xfce4-panel-4.18.2/debian/rules 2023-03-09 21:05:54.056387740 +0300
@@ -7,7 +7,7 @@
dh $@ --with gir
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-gtk-doc --enable-introspection=yes 
--enable-vala=no
+   dh_auto_configure -- --enable-gtk-doc --enable-introspection=yes
 
 override_dh_installchangelogs:
DEB_BUILD_OPTIONS=notrimdch dh_installchangelogs NEWS

Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El domingo, 5 de marzo de 2023 18:31:03 -03 Jon Beniston escribió:
> Package: libqt5positioning5-plugins
> Version: 5.15.2+dfsg-2
> Severity: wishlist
> X-Debbugs-Cc: j...@beniston.com
> 
> Dear Maintainer,
> 
> It would be good if the serial NMEA plugin could be added 
> (libqtposition_serialnmea.so), so serial port / USB GPS devices can be used 
> directly. (These don't appear to be supported by Geoclue).
> 
> (https://doc.qt.io/qt-5/position-plugin-serialnmea.html)

I remember looking into this when I've got to package it. Looking at the build
log [1] I think it needs the Gypsy GPS Daemon, which I understand it is not
packaged in Debian.


[1] 



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

Bug#1032597: libxfce4util-dev doesn't provide Vala API files

[Arthur Demchenkov]

Package: libxfce4util-dev
Version: 4.18.1-2
Severity: important
Tags: patch

Dear Maintainer,

I'm trying to build Xfce panel plugin which is written using Vala
language, and it fails because of missing Vala API files in
libxfce4util-dev package.

Vala is the language which is widely used for writing applications
that use glib/gtk+ libraries.

I attach the patch for xfce4-panel package that can fix the issue.

The plugin I was trying to build:
https://gitlab.xfce.org/panel-plugins/xfce4-notes-plugin

Thank you!


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

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

Versions of packages libxfce4util-dev depends on:
ii  gir1.2-libxfce4util-1.0  4.18.1-2
ii  libglib2.0-dev   2.74.6-1
ii  libxfce4util74.18.1-2

libxfce4util-dev recommends no packages.

Versions of packages libxfce4util-dev suggests:
pn  devhelp  

-- no debconf information
diff -Naur libxfce4util-4.18.1-orig/debian/control 
libxfce4util-4.18.1/debian/control
--- libxfce4util-4.18.1-orig/debian/control 2023-01-12 10:28:40.0 
+0300
+++ libxfce4util-4.18.1/debian/control  2023-03-09 21:40:14.405305943 +0300
@@ -9,6 +9,7 @@
intltool,
libgirepository1.0-dev,
libglib2.0-dev,
+   valac,
xfce4-dev-tools
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
diff -Naur libxfce4util-4.18.1-orig/debian/libxfce4util-dev.install 
libxfce4util-4.18.1/debian/libxfce4util-dev.install
--- libxfce4util-4.18.1-orig/debian/libxfce4util-dev.install2022-12-05 
09:48:34.0 +0300
+++ libxfce4util-4.18.1/debian/libxfce4util-dev.install 2023-03-09 
21:40:30.773607053 +0300
@@ -3,3 +3,4 @@
 usr/lib/*/pkgconfig/*
 usr/share/gir-1.0/*
 usr/share/gtk-doc/html/libxfce4util/*
+usr/share/vala/vapi/*
diff -Naur libxfce4util-4.18.1-orig/debian/rules 
libxfce4util-4.18.1/debian/rules
--- libxfce4util-4.18.1-orig/debian/rules   2023-02-27 08:48:49.0 
+0300
+++ libxfce4util-4.18.1/debian/rules2023-03-09 21:34:15.846357983 +0300
@@ -10,7 +10,7 @@
 endif
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-gtk-doc --enable-introspection=yes 
--enable-vala=no
+   dh_auto_configure -- --enable-gtk-doc --enable-introspection=yes
 
 execute_after_dh_auto_install:
find debian/tmp -name '*.la' -delete

Bug#1032550: igdiscover: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Santiago Vila]

El 9/3/23 a las 16:18, Andreas Tille escribió:

I've rebuild igdiscover 0.11-3 in a testing and unstable
environment.  Both builds are passing all tests.


Hello. This one FTBFS randomly for me. Therefore,
to "reproduce the randomness" you might have to try several times,
not just once.

My build environment is currently made of VMs with 1 and 2 CPUs.

For this package, I have two successful builds using 2 CPUs,
and nothing more, so it may be random there, or maybe not,
because I've not tested it enough times to know.

When using 1 CPU, this is my build history so far:

Status: successful  igdiscover_0.11-3_amd64-20220501T161126.901Z
Status: failed  igdiscover_0.11-3_amd64-20221108T225319.839Z
Status: successful  igdiscover_0.11-3_amd64-20221115T130535.295Z
Status: successful  igdiscover_0.11-3_amd64-20221115T130920.067Z
Status: failed  igdiscover_0.11-3_amd64-20221115T133708.367Z
Status: successful  igdiscover_0.11-3_amd64-20221115T135147.584Z
Status: failed  igdiscover_0.11-3_amd64-20221115T144835.514Z
Status: successful  igdiscover_0.11-3_amd64-20221115T144843.540Z
Status: successful  igdiscover_0.11-3_amd64-20221115T145126.644Z
Status: successful  igdiscover_0.11-3_amd64-20221115T145404.560Z
Status: successful  igdiscover_0.11-3_amd64-20221115T144945.690Z
Status: successful  igdiscover_0.11-3_amd64-20221115T145128.070Z
Status: successful  igdiscover_0.11-3_amd64-20230111T155218.678Z
Status: successful  igdiscover_0.11-3_amd64-20230111T155235.799Z
Status: successful  igdiscover_0.11-3_amd64-20230125T193926.333Z
Status: successful  igdiscover_0.11-3_amd64-20230125T194042.500Z
Status: successful  igdiscover_0.11-3_amd64-20230125T195323.679Z
Status: failed  igdiscover_0.11-3_amd64-20230125T195500.696Z
Status: successful  igdiscover_0.11-3_amd64-20230125T200024.475Z
Status: successful  igdiscover_0.11-3_amd64-20230125T20.253Z
Status: successful  igdiscover_0.11-3_amd64-20230125T200433.788Z
Status: successful  igdiscover_0.11-3_amd64-20230125T201954.420Z
Status: successful  igdiscover_0.11-3_amd64-20230125T202301.598Z
Status: successful  igdiscover_0.11-3_amd64-20230125T203341.230Z
Status: failed  igdiscover_0.11-3_amd64-20230125T203408.732Z
Status: failed  igdiscover_0.11-3_amd64-20230125T204109.497Z
Status: successful  igdiscover_0.11-3_amd64-20230125T204244.306Z
Status: successful  igdiscover_0.11-3_amd64-20230125T204258.004Z
Status: successful  igdiscover_0.11-3_amd64-20230125T205136.438Z
Status: successful  igdiscover_0.11-3_amd64-20230125T205808.095Z
Status: failed  igdiscover_0.11-3_amd64-20230125T210534.566Z
Status: successful  igdiscover_0.11-3_amd64-20230125T210502.213Z
Status: successful  igdiscover_0.11-3_amd64-20230125T210815.549Z
Status: successful  igdiscover_0.11-3_amd64-20230125T211006.621Z
Status: successful  igdiscover_0.11-3_amd64-20230126T180837.356Z
Status: successful  igdiscover_0.11-3_amd64-20230126T180948.067Z
Status: failed  igdiscover_0.11-3_amd64-20230126T182131.288Z
Status: failed  igdiscover_0.11-3_amd64-20230126T183203.578Z


My advice, therefore, is to try using a machine with a single CPU.

This is very easy to achieve by setting GRUB_CMDLINE_LINUX="nr_cpus=1"
in /etc/default/grub.

Nilesh Patra wrote:

I wonder if it is another of those "$specific-CPU-configuration" failures.


Please note that no specific configuration is mandated by Debian policy, so
I understand that packages must build from source regardless of the number
of CPUs. This is what usually happens, and it's also what our users expect.

If you could not reproduce the randomness with the grub trick above, please
contact me privately, as I could offer ssh access to a machine where
such randomness happens.

Thanks.

Bug#1032596: zfs-initramfs: cannot boot (dropped to shell) if mountpoint=legacy for boot dataset

[Olivier]

Package: zfs-initramfs
Version: 2.1.9-2
Severity: important
Tags: upstream

Dear Maintainer,


   * What led up to the situation?
Upgrading from 2.1.9-1 to 2.1.9-2
My root dataset has mountpoint=legacy
I reported this upstream
https://github.com/openzfs/zfs/issues/14599
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I modified /usr/share/initramfs-tools/scripts/zfs (see upstream bug report)
   * What was the outcome of this action?
This fixed my issue



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

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

Versions of packages zfs-initramfs depends on:
ii  busybox 1:1.35.0-4+b2
ii  initramfs-tools 0.142
ii  zfs-dkms [zfs-modules]  2.1.9-2
ii  zfsutils-linux  2.1.9-2

zfs-initramfs recommends no packages.

zfs-initramfs suggests no packages.

-- no debconf information

Bug#1032595: krfb keyboard Wayland

[Dave Maxwell]

Package: krfb
Version: 4:22.12.3-1

krfb will not accept keyboard input from a vnc client under Wayland.

There is a two line fix for the issue upstream:

https://invent.kde.org/network/krfb/-/merge_requests/44/diffs?commit_id=01c775f2e89b705d8375c0ccc0543fc82be53414



I applied it to a krfb source deb and built it.  It does enable keyboard
input under Wayland.




-- 

Dave Maxwell
Network Administrator
Big Walnut Local Schools

-- 


_This email may contain confidential and/or privileged information and is 
covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521. 
If it does not contain privileged information concerning a BWLSD employee 
or student, this email and responses are subject to Ohio public records 
requests. If you are not the intended recipient (or have this email in 
error) please notify the sender immediately and destroy this email. Any 
unauthorized copying, disclosure or distribution of the material in this 
email is strictly forbidden._

Bug#1032512: Unneeded versioned dependency to libx11-xcb1

[Lisandro Damián Nicanor Pérez Meyer]

To the email I just sent I'll add one more thing:

El jueves, 9 de marzo de 2023 15:21:29 -03 Klaus Ethgen escribió:
[snip] 
> But the unneeded versioned dependency is in that package and is against
> the debian policy...

If there is a version there then it comes from the package's shlibs/symbols 
files, ie, totally external to Qt.


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

Bug#1032594: apt: hard-coded directory permissions 0755

[Philipp Hahn]

Package: apt
Version: 2.2.4
Severity: normal

https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/contrib/fileutl.cc#L398
>  if (mkdir(progress.c_str(), 0755) != 0)

it would be good to make this configurabel with something similar to
`FileMode`.

We are using `apt-ftpachive` in a shared ennvironment. We are using
`umask 0002` to give group-membery rwx-access by default.
Our top-level directory has mode 02775 and group "build", so that every
path created below it is again owned by that group and has the SGID-bit
set.

But directories and files created by `apt-ftparchive` lack
write-permission for the group:
- Permissions for files can be configured via `FileMode`, which defaults
  to 0644.
- But there is nothing for directories, which is hard-coded to 0755.


-- Package-specific info:

-- /etc/apt/preferences --

Package: *
Pin: release a=testing
Pin-Priority: 50

-- (no /etc/apt/preferences.d/* present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- (/etc/apt/sources.list.d/pbuilder.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2+deb11u2
ii  libapt-pkg6.0   2.2.4
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-5+deb11u3
ii  libseccomp2 2.5.1-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7+deb11u1

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-3
ii  dpkg-dev1.20.12
ii  gnupg   2.2.27-2+deb11u2
ii  gnupg1  1.4.23-1.1
ii  gnupg2  2.2.27-2+deb11u2
ii  powermgmt-base  1.36

-- no debconf information

Bug#1032512: Unneeded versioned dependency to libx11-xcb1

[Klaus Ethgen]

Am Do den  9. Mär 2023 um 19:00 schrieb Patrick Franz:
> On Thu, 9 Mar 2023 06:34:16 +0100 Klaus Ethgen  wrote:
> [...]
> > But the versioned dependency is unneeded as I could test by forcing
> > install old version. It does not only work, it does also work better
> > in the "broken" state than with the correct dependencies.
> > 
> > So it IS a bug of this package.
> 
> No, it is not a bug in Qt.

I see that different.

> The versioned dependency is picked up by the Debian build system and not 
> by code in Qt. If it has to pick 1.8.4, then it is because it either 
> needs it or it cannot determine which version would suffice. Merely 
> pointing to a single use case is not enough to lower it. Maybe there are 
> use cases where 1.8.4 is needed.

I challenge that there is a need for versioned at all!

Just remove the version number dependency and everything is great.

> There are a dozen packages depending on libx11-xcb1 1.8.4 - do you want 
> those to lessen their dependencies as well ?

Yes... But only 3 packages are in my use and they works pretty well with
unversioned dependency.

> Manually editing automatically picked-up dependencies is asking for
> trouble.

Just remove the version at all. That is supported by the build system.

> The bug is in libx11. If you want the situation solved, please help 
> fixing the bug there.

Well, I delivered all that is needed to fix the bug. And yes, the bug is
there.

But the unneeded versioned dependency is in that package and is against
the debian policy...

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1032549: python-pbcore: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Nilesh Patra]

Hi Lucas,


Source: python-pbcore
Version: 2.1.2+dfsg-5
Severity: serious
Justification: FTBFS



WARNING: The wheel package is not available.
/usr/bin/python3.11: No module named pip
error: Command '['/usr/bin/python3.11', '-m', 'pip', '--disable-pip-version-check', 
'wheel', '--no-deps', '-w', '/tmp/tmpqico3vl0', '--quiet', 
'astroid<=2.14.0-dev0,>=2.12.13']' returned non-zero exit status 1.
E: pybuild pybuild:388: test: plugin custom failed with: exit code=1: 
python3.11 setup.py test
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 
returned exit code 13



This error stems from an older pylint.
In your build log, I see that an older version of pylint is being used:

| Selecting previously unselected package pylint.
| Preparing to unpack .../111-pylint_2.15.10-1_all.deb ...
| Unpacking pylint (2.15.10-1) ...

This has been fixed with pylint 2.16.2-2, which is currently in unstable but 
it'd migrate to testing
by tomorrow or the day after. Could you please consider to re-build and close 
the bug once it does?

If you want, I'll send a reminder as well.

Thanks,
Nilesh

Bug#1032550: igdiscover: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Nilesh Patra]

Control: severity -1 important


I've rebuild igdiscover 0.11-3 in a testing and unstable
environment.  Both builds are passing all tests.


Same for me, I'm reducing the severity.

Lucas, could you please do a re-run? I wonder if it is another of
those "$specific-CPU-configuration" failures.

Thanks,
Nilesh

Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Faidon Liambotis]

Control: tags -1 + patch

On Wed, Mar 08, 2023 at 06:51:36PM +0100, Sylvestre Ledru wrote:
> Le 08/03/2023 à 18:13, Simon McVittie a écrit :
> > On Wed, 08 Mar 2023 at 17:46:11 +0200, Faidon Liambotis wrote:
> > > I'm not submitting an MR because I noticed that "15" branch has
> > > progressed further compared to 1-15.0.7-1, and I'm not sure how you'd
> > > like to handle it; basically whether these changes are suitable for
> > > bookworm at this point, or whether you'd like to to fork a branch for
> > > bookworm.
> > See also #1032316 which is exactly about whether 1%15.0.7-1 is intended
> > for bookworm or not: the reason I started looking at this is that
> > 1%15.0.7-1 not migrating is holding back fixes in src:mesa, at least
> > one of which is RC.
> 
> yeah, it is intended for bookworm
> 
> sorry if i didn't state it clearly earlier.
> 
> Faidon, would you like to push your fixes directly in the repo?

I pushed this as an MR against the 15 branch:
  https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/113
(I don't have access to push directly -- and that's totally fine :)

I also kicked off a test build on barriere, which will take a few hours.
I'll let folks now if it succeeds.

Faidon

Bug#1031649: wine: /usr/bin/wine64 still required

[Jens Reyer]

Hi Paul

On 09.03.23 15:50, Paul Gevers wrote:

Hi,

On Sun, 19 Feb 2023 18:17:39 -0600 Austin English 
 wrote:



Yes, it's arguably a bug in winetricks. Film what I gather upstream,
it's also not yet fully supported.
On Sat, 25 Feb 2023 17:10:47 +0100 Jens Reyer  
wrote:
ftr: I just uploaded a new winetricks 20230212-1 to unstable which 
should migrate to bookworm before the hard freeze. It workarounds a 
missing /usr/bin/wine64. The fix is quite late in Winetricks logic to 
figure out wine64, so it should work just fine with both setups.  
Tested against wine 8.0~repack-2, 8.0~repack-4 and winehq-staging 
8.2~bookworm-1.


If I understand correctly, this bug can now be downgraded in severity 
because winetricks migrated to bookworm. Maybe even better, reassign to 
winetricks and close it with the version in bookworm? Or am I missing 
the point?


Well, yes, from my winetricks perspective this bug could be closed as 
described.



But I suspect (without any evidence) that a missing /usr/bin/wine64 also 
affects others, at least in non-packaged software, but maybe also in 
Debian. Changing this now shortly before the release imo calls for 
trouble. In general I think /usr/bin/wine64 should be kept as long as 
Wine is built as it is now, since just too many people got used to it. 
Only once Wine is built the new way (upstream is still working on this) 
this setup should be changed.


This change was intended to fix #1029536, where I unfortunately 
mentioned that removing /usr/bin/wine64 might solve the issue. That 
issue may be either ignored or preferably fixed another way, e.g. by 
doing a "ln -s /usr/lib/wine/wine64 /usr/lib/wine/wine64-stable".


Finally this issue here blocked the fix for #1031102 from migrating to 
testing.  As far as I see that could be ignored, since it's a build 
issue with vulkan 1.3.239, which is also only in unstable. I do not know 
if the current wine 8.0~repack-4 would even build with the vulkan 
currently in testing. If it doesn't there would be a new rc bug.


So we have three options (ordered best to least from my perspective, and 
assuming wine builds with both vulkan versions from testing and unstable 
(requirement for 1 and 3). Please note that I stepped down from 
maintaining wine, and might miss something).


1.
Revert the /usr/bin/wine64 removal, add the /usr/lib/wine/wine64-stable 
link instead, and then let wine migrate to bullseye.


2.
Keep everything as it is now, make sure vulkan 1.3.239 doesn't make it 
to bullseye, and bullseye-ignore this and the 2 other bugs.


3.
Reassign this bug as you suggested to winetricks and close it with the 
version in bookworm.


Greets
jre

Bug#1032512: Unneeded versioned dependency to libx11-xcb1

[Patrick Franz]

Hi,

On Thu, 9 Mar 2023 06:34:16 +0100 Klaus Ethgen  wrote:
[...]
> But the versioned dependency is unneeded as I could test by forcing
> install old version. It does not only work, it does also work better
> in the "broken" state than with the correct dependencies.
> 
> So it IS a bug of this package.

No, it is not a bug in Qt.

The versioned dependency is picked up by the Debian build system and not 
by code in Qt. If it has to pick 1.8.4, then it is because it either 
needs it or it cannot determine which version would suffice. Merely 
pointing to a single use case is not enough to lower it. Maybe there are 
use cases where 1.8.4 is needed.

There are a dozen packages depending on libx11-xcb1 1.8.4 - do you want 
those to lessen their dependencies as well ? Manually editing 
automatically picked-up dependencies is asking for trouble.

The bug is in libx11. If you want the situation solved, please help 
fixing the bug there.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#958287: More recent release on author's GitHub

[Martin Lester]

Hello.

There seems to be a marginally more recent release (version 1.1) on
the author's GitHub:

https://github.com/niklasso/minisatp

Martin Lester.

Bug#1029116: hw-detect: check-missing-firmware fails will attempting to reload kernel module on MT7922 WiFi card

[Cyril Brulebois]

Control: reassign -1 src:linux 6.1.15-1

Cyril Brulebois  (2023-01-17):
> Stuart Hayhurst  (2023-01-17):
> > Source: hw-detect
> > Version: 1.152
> > Severity: important
> > X-Debbugs-Cc: stuart.a.hayhu...@gmail.com
> > 
> > Running "Detect network interfaces" hangs the installer, and with a
> > bit of troubleshooting, it's caused when check-missing-firmware
> > removes and loads the kernel module for my WiFi chip (mt7921e driver)
> 
> This wouldn't be the first issue about this modprobe dance, but I'm not
> sure why the kernel would go haywire… I'm definitely looking into
> firmware related issues these days, so maybe I'll be able to reproduce
> it somewhere, and/or find a different solution to account for the newly
> installed firmware (current plan would be to keep hw-detect ± as is
> while introducing support for non-free-firwmare).

Reassigning to the kernel, which definitely shouldn't panic…

More details in the MR:
  https://salsa.debian.org/kernel-team/linux/-/merge_requests/673


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


signature.asc
Description: PGP signature

Bug#1032593: Automatically map intersphinx references to local packages

[Faidon Liambotis]

Source: sphinx
Version: 5.3.0-3
Severity: wishlist

Countless packages contain a stanza in their docs/conf.py like:
intersphinx_mapping = {
"python": ("https://docs.python.org/3;, None),
}

Given packages in Debian cannot use network access when being built, and
the dh_make Sphinx boilerplates suggest defining http_proxy to avoid
Sphinx resolving this through the internet, one of these two things
happens:

1) The maintainer patches the upstream source through debian/patches, to
point these references to the local filesystem. That's actually what
src:sphinx does as well for itself, through the intersphinx_local.diff
patch. A quick codesearch[1] reveals ~385 packages doing something
similar.

2) The maintainer does not patch the source, Sphinx attemps to fetch the
file from the network, fails due to http_proxy, and the generated docs
do not resolve these references. Build-time warnings are emitted of the
form:
   WARNING: py:class reference target not found: pathlib.Path
I don't know of an easy way to grep through the build logs to generate
numbers. Anecdotally, I've seen quite a few packages in that category as
well. (Perhaps one could add a tag to the Buildd Log Scanner[2] to scan
for this?)

It'd be great if intersphinx in Debian was patched to map these
references to the local Debian package and also to generate the
necessary dependencies -- perhaps guarded by a environment variable or
command-line option that dh_sphinx would only pass, for example.

Beyond patching the Sphinx code itself, there is of course the matter of
generating these mappings, which is surprisingly non-trivial. From what
I can tell the mappings need to be created heuristically, since I
haven't seen of a way for a central Sphinx to document in metadata where
the generation documentation will be published.

I played around with a few ideas, and while I haven't settled on
something that I feel is not dirty yet, I tried to implement something
akin to what dh-python's pydist/generate_fallback_list.py does: have a
script in the source to be executed manually periodically to regenerate
the cache, which creates a mapping that is then committed to git, and
shipped in the binary. 

So I implemented the attached proof of concept that:
* Scans Contents-all and Contents-amd64 to find objects.inv files
  and maps them back to the binary packages;
* Queries UDD (through one query with joins) to:
  - find the respective source packages for these binary packages
  - find the upstream metadata[3] for these source package
* Prints a tab-separated intersphinx_mappings file that has:
  \t\

It takes ~10s to run on my computer right now, which should be fine for
being executed periodically by the maintainer.

I'm sure there are many issues with this approach that I haven't thought
through, as well as a number of corner cases, but I wanted to have
something to kickstart this discussion beyond just wishful thinking!

I'd love any feedback! Note that I haven't looked at all at what it
would take to integrate this mapping to the Sphinx source (as well as
${sphinx:Depends}) as I thought it'd be good to validate the approach
before I do so.

Regards,
Faidon

1: 
https://codesearch.debian.net/search?q=intersphinx_mapping+path%3Adebian%2F=1=1
2: https://qa.debian.org/bls/
3: I ran into stale data in that table, which is now tracked as #1032587
#!/usr/bin/python3
#
# Copyright © 2023 Faidon Liambotis 
#
# Roughly based on dh-python/pydist/generate_fallback_list.py which is:
# Copyright © 2010-2015 Piotr Ożarowski 
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
# THE SOFTWARE.

import re
import sys

try:
from distro_info import DistroInfo  # python3-distro-info package
except ImportError:
DistroInfo = None
from gzip import decompress
from pathlib import Path
from urllib.parse import urlparse
from urllib.request import urlopen

import psycopg2
import psycopg2.extras

if "--ubuntu" in sys.argv and DistroInfo:
SOURCES = [

Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[dkm]

> If you can access this file, could you try if it solves the issue?
> https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4035730/artifacts
> file/debian/output/firmware-brcm80211_20230210-3+salsaci_all.deb

Hi,

I don't have access, so I've tried to create an account... which failed on some 
internal error. Retrying to create an account then fails because the username 
(dkm) and/or email (dkm+sa...@kataplop.net) are already used (probably because 
of my initial try).

If there's no other way, I'll go ask on IRC for support with my account 
creation.

Marc

Bug#1032592: libzstd: FTBFS on hppa and others - numeric value overflows 32-bit unsigned int

[John David Anglin]

Source: libzstd
Version: 1.5.4+dfsg2-4
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails testing basic decompression:

test : basic compression 
tmp  : 32.48%   (  64.0 KiB =>   20.8 KiB, tmp.zst) 
tmp  : 32.48%   (  64.0 KiB =>   20.8 KiB, tmp.zst) 
tmp  : 32.48%   (  64.0 KiB =>   20.8 KiB, tmp.zst) 
tmp  : 32.48%   (  64.0 KiB =>   20.8 KiB, tmp.zst) 
test : basic decompression
tmp.zst : 65537 bytes 
test : too large compression level => auto-fix
Warning : compression level higher than max, reduced to 19 
tmp  : 31.53%   (  64.0 KiB =>   20.2 KiB, tmp.zst) 
error: numeric value overflows 32-bit unsigned int 

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libzstd=hppa=1.5.4%2Bdfsg2-4=1678356348=0

1.5.2+dfsg2-3 was okay.

Regards,
Dave Anglin

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

Kernel: Linux 6.1.15+ (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#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[Diederik de Haas]

On Thursday, 9 March 2023 03:38:13 CET d...@kataplop.net wrote:
> Here's the result of using latest package:
> 
> [38.546040] brcmfmac :01:00.0: firmware: failed to load
> brcm/brcmfmac4356-pcie.bin (-2) [   38.546408] brcmfmac :01:00.0:
> firmware: failed to load brcm/brcmfmac4356-pcie.bin (-2) [   38.546416]
> brcmfmac :01:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.bin
> failed with error -2
> 
> Downgrading it and reloading the module brings the interface up:

The brcm/brcmfmac4356-pcie.bin file (f.e.) has been moved/renamed to cypress/
cyfmac4356-pcie.bin and *maybe* that causes the issue.

If you can access this file, could you try if it solves the issue?
https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4035730/artifacts/
file/debian/output/firmware-brcm80211_20230210-3+salsaci_all.deb

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

Bug#1032591: xarchive error when open or unpack .zst files

[eng . stk]

Package: xarchiver

Version: 1:0.5.4.20-1

Since zstd package updated from v1.5.2 to v1.5.4, xarchiver errors out  
when trying to open or unpack a zstd compressed archive (like .tar.zst:


"Sorry this archive format is not supported."

There's an xarchiver upstream fix for this bug, please consider merging it:

https://github.com/ib/xarchiver/commit/a298cf82391e4b447e702d7e51078554253b1b8d

Thanks!

Bug#1032590: Intermediate certficate support

[Sakirnth Nagarasa]

Package: freeradius

Hi,

It would be great if you could upgrade freeradius version 3.2.2 to
Debian. With that certficates chains can be used without failing.

It patches this bug:
https://github.com/FreeRADIUS/freeradius-server/issues/4753

https://github.com/FreeRADIUS/freeradius-server/releases/tag/release_3_2_2

Thanks and cheers,
Saki

Bug#1010988: libtpms: FTBFS on hppa - error: ‘-fstack-protector’ not supported for this target [-Werror]

[John David Anglin]

Source: libtpms
Version: 0.9.2-3
Followup-For: Bug #1010988

Dear Maintainer,

This can be worked around by configuring with "--disable-hardening"
on hppa.  This can be added in debian/rules.

Regards,
Dave Anglin

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

Kernel: Linux 6.1.15+ (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#1032589: sq-wot: Please update

[Gunnar Wolf]

Package: sq-wot
Version: 0.2.0-1+b5
Severity: normal

Dear sq-wot maintainers,

The currently packaged version 0.2 of this tool was released in
February 2022. It remained with relatively little changes until last
December, but since then, five new releases were announced (it
currently sits at 0.6.0):

https://crates.io/crates/sequoia-wot/versions

The online published documentation no longer matches sq-wot's
functionality.

Please try to update this tool in order to have a more recent version
in Bookworm!

Thanks,

- Gunnar.

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 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 sq-wot depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libhogweed6  3.8.1-2
ii  libnettle8   3.8.1-2

sq-wot recommends no packages.

sq-wot suggests no packages.

-- no debconf information

-- 



signature.asc
Description: PGP signature

Bug#1032588: gbdfed FTCBFS: multiple reasons

[Helmut Grohne]

Source: gbdfed
Version: 1.6-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gbdfed fails to cross build from source for two completely distinct
reasons.

1. It ships a broken, outdated, embedded copy of PKG_CHECK_MODULES in
   aclocal.m4. Please remove this copy. Failing that, update it and
   register it with the security tracker. The actual bug has long been
   fixed in pkg-config and pkgconf. gbdfed just happens to ship a copy
   of the bug.

2. Use of AC_CHECK_FILE for build system files. The macro is only meant
   to be used for host system files and thus fails. Please use a simple
   test -e instead. I'm attaching a patch for your convenience.

Helmut
--- gbdfed-1.6.orig/configure.in
+++ gbdfed-1.6/configure.in
@@ -40,7 +40,7 @@ dnl These use the pkgconfig macro (in ac
 PKG_CHECK_MODULES(FREETYPE, freetype2 >= 2.0,DEFINES="-DHAVE_FREETYPE" CPPFLAGS="$CPPFLAGS $FREETYPE_CFLAGS" LIBS="$LIBS $FREETYPE_LIBS",)
 PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.6,CPPFLAGS="$CPPFLAGS $GTK_CFLAGS" LIBS="$LIBS $GTK_LIBS",)
 
-AC_CHECK_FILE(hbf.c, DEFINES="$DEFINES -DHAVE_HBF" HBFSRC="hbf.c" HBFOBJ="hbf.o",)
+AS_IF([test -e hbf.c],[DEFINES="$DEFINES -DHAVE_HBF" HBFSRC="hbf.c" HBFOBJ="hbf.o"])
 
 AC_PATH_XTRA
 

Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode

[Fierelier OwO]

Debian 12* -- Sorry!

On 3/9/23, Fierelier OwO  wrote:
> I'm not sure if this is too late to change for Debian 13 by now, I'd
> still love to see it happen.
>

Bug#1032550: igdiscover: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: tags -1 unreproducible
Control: tags -1 moreinfo

Hi,

I've rebuild igdiscover 0.11-3 in a testing and unstable
environment.  Both builds are passing all tests.

Could you give some more detailed information?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode

[Fierelier OwO]

What smcv said is probably the right idea. The Rust toolchain should
be compiled in i586, and Rust programs should be compiled to i586 as
well (I'm not sure of the specifics here).

The Rust team has been expressing issues with adapting the correct
processor definition for their i686 build, see:
https://github.com/rust-lang/compiler-team/issues/548#issuecomment-1439976916
-- It is unlikely we will see them change it now, hence the pull that
Martin linked will most likely never be merged.

I'm not sure if this is too late to change for Debian 13 by now, I'd
still love to see it happen.

Bug#1032540: conda-package-streaming: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: block -1 by 1031293

Once python3-zstandard has migrated to testing the build time test
should work again.

Kind regards, Andreas.

Bug#1032542: conda-package-handling: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: block -1 by 1031293

Once python3-zstandard has migrated to testing the build time test
should work again.

Kind regards, Andreas.

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Stefan Monnier]

Timo Aaltonen [2023-03-09 08:50:09] wrote:
> Stefan Monnier kirjoitti 9.3.2023 klo 0.18:
>> Control: found -1 2:21.1.7-1
>> I still see this problem with the latest version on `testing`.
> I'm sure the problem is in the kernel driver (i915) and not xserver.

In that case, the kernel version would be relevant, right?
My latest test is with kernel version 6.1.0-5.


Stefan

Bug#1031649: wine: /usr/bin/wine64 still required

[Paul Gevers]

Hi,

On Sun, 19 Feb 2023 18:17:39 -0600 Austin English 
 wrote:



Yes, it's arguably a bug in winetricks. Film what I gather upstream,
it's also not yet fully supported.

On Sat, 25 Feb 2023 17:10:47 +0100 Jens Reyer  wrote:
ftr: I just uploaded a new winetricks 20230212-1 to unstable which 
should migrate to bookworm before the hard freeze. It workarounds a 
missing /usr/bin/wine64. The fix is quite late in Winetricks logic to 
figure out wine64, so it should work just fine with both setups.  Tested 
against wine 8.0~repack-2, 8.0~repack-4 and winehq-staging 8.2~bookworm-1.


If I understand correctly, this bug can now be downgraded in severity 
because winetricks migrated to bookworm. Maybe even better, reassign to 
winetricks and close it with the version in bookworm? Or am I missing 
the point?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032587: UDD's upstream_metadata table may contain stale data?

[Faidon Liambotis]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Severity: normal
X-Debbugs-Cc: ti...@debian.org

m trying to query UDD for upstream metadata, but upon running some
SELECTs on public.upstream_metadata I've noticed that it doesn't have
data for e.g. src:python-structlog, which I added to the package with
the 22.3.0-1 upload on 18 Feb 2023.

I asked about the refresh frequency in #debian-qa, to which Lucas
responded that's not 100% sure of the status and encouraged me to file a
bug here. He also noted there is no mention of upstream metadata in
https://udd.debian.org/udd-status.cgi and that maybe [the updater] is no
longer running.

This is my first attempt to query this data, so I hope this isn't an
operator error!

Thanks in advance,
Faidon

Bug#1032582: linux: Enable CAN_MCP251XFD

[Diederik de Haas]

Control: tag -1 moreinfo

On Thursday, 9 March 2023 15:04:11 CET Bastian Germann wrote:
> The driver CAN_MCP251X is already enabled on all platforms.
> Please enable CAN_MCP251XFD as module as well. Thank you!

Can you describe *why* this would a useful addition? 

For CAN_MCP251X the motivation was:
"Without CONFIG_CAN_MCP251X=m, MCP251X based CAN controllers are unusable. 
This is often found paired with single board computers like the RPi, ODROID, 
UDOO, Toradex, etc."

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

Bug#1032586: Please add Provides: headers to provide names following the HDF5 Filter Plugin Packaging Guidelines

[Enrico Zini]

Source: h5py
Version: 3.7.0-8
Severity: wishlist
Tags: patch

Hello,

the HDF5 Filter Plugin Packaging Guidelines at
https://salsa.debian.org/science-team/h5f-packaging-guidelines
suggests a unified naming scheme for HDF5 filter plugin packages, so
that packages that depend on a plugin can do so regardless of where it
is implemented.

I created a MR to add support for this for hdf5-plugin-lzf, which also
adds autopkgtests to test that the plugins loads:
https://salsa.debian.org/science-team/h5py/-/merge_requests/2

I tested the MR by creating a fork of h5py and setting
"Settings/CI-CD/General pipelines/CI/CD configuration file" to
recipes/debian.yml@salsa-ci-team/pipeline[1]:
https://salsa.debian.org/enrico/h5py/-/pipelines/509549


Thanks,

Enrico

[1] see https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

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

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

Bug#1032585: RM: wxwidgets3.0 -- ROM; Unmaintained; replaced by wxwidgets3.2

[Scott Talbert]

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

Bug#716763: apt: Man page of apt-cache dont mentions regex on operations with pkg argument , except from 'search'

[David Kalnischkies]

On Wed, Mar 08, 2023 at 11:28:18PM +0100, Nis Martensen wrote:
> On 12 Jul 2013 Prekates Alexandros wrote:
> > Man page of apt-cache dont mentions regex on operations with pkg argument
> > ,except from 'search'
> > 
> > But i tested in wheezy and i see that using regex with operation like show ,
> > showpkg  works.

(For MultiArch – merged around 0.8 in 2010 – I rewrote the command line
 parsing for all tools to have them all behave somewhat similar. The
 bigger ones like 'show' "always" supported regex, but it e.g. didn't
 handle "foobar:armel/experimental" and I didn't want to write
 more or less the same thing 10+ times. The documentation always only
 speaks about package names for those commands even through you could
 even back than do a lot of other things as well… the docs never
 mentioned all of this all to explicitly in a lot of places. Honestly,
 I think most users couldn't handle the truth, but our docs are just
 in general in need of a revamp, so perhaps some day I am proven wrong
 by someone who rewrites them)


> Is there a recommended way to request a literal package name match from
> apt-cache show?

With apt-patterns nowadays, I presume the answer is:
apt-cache show '?exact-name(vera++)'

Note that in a Multi-Arch context multiple packages with that exact name
exist – e.g. vera++:amd64 and vera++:i386, so you might have to make
further selections with more patterns. I don't really use them, so not
really much of an expert on them. See apt-patterns(7).


That selection is done for you if you do 'apt-cache show vera++' as it
will assume that you are interested in information for the package
which would be installed if you were doing 'apt-get install vera++'.
(Yes, that is a recursive definition)

That works, because 'vera++' is a real binary package name and apt
checks if a package with that name exists before it tries regex matches
or assumes the postfix '+' is a modifier indication that this package
should be installed (aka: apt-get remove vera+++ # installs vera++).

That means that if what you provided is for whatever reason not a real
binary package name apt goes looking for what you could have possibly
meant, similar to how 'install' goes looking for what you might have
meant, like a package from another architecture with that name or
a glob, a regex, a task or a single-provider of a virtual package, …


> In reportbug we are parsing the output of apt-cache show to obtain
> information on available packages. This does not always work correctly
> if the package name includes "+" or ".", see #1031924 for an example bug
> report.

To use Simons examples from #1031924 (reordered for my benefit):

| freefem++ -> (correct)
| hello -> (correct)

is an existing binary package (that it is also a source
package name is of no concern for 'show')

| dbus-c++ -> dbus-cpp
| gtk+2.0 -> librcc
| lucene++ -> lucene-solr
| gtk+3.0 -> wxpython3.0

is a source package, no binary package with that name exists.  apt
interprets them hence as regexes and so likely multiple stanzas for
multiple matching packages are produced. Funnily enough gtk+3.0 doesn't
even produce binary packages which match (while gtk+2.0 does, but both
just as sidenote, it makes no difference for apt).

| gtk4 -> (correct)

Neither an existing binary nor a regex or anything else apt can
make sense of, so no package can be found. I presume reportbug has
a fallback or whatever which ends up doing the right thing for source
packages?


Arguably, providing a source package name to reportbug is incorrect
usage if I understand its man page right. In any case it is incorrect
usage for "apt-cache show" as it doesn't know source packages, you
would have to use "apt-cache showsrc" for those.


> Should we just re.escape() the package name before passing it to
> apt-cache show? Or is there a risk of this breaking with future versions
> of apt (e.g., if apt is changed to address #776840)?

#776840 was addressed years before it was reported with the code
I commented on in the beginning. Indeed, going back and compiling
1.0.9.6 and running it against ~todays data gives the intended result:

~$ apt-get -v | head -n 1
apt 1.0.9.6 for amd64 compiled on Mar  9 2023 13:27:46
~$ apt-get install -s vera++
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libboost-wave1.74.0
The following NEW packages will be installed:
  libboost-wave1.74.0 vera++
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Inst libboost-wave1.74.0 (1.74.0+ds1-20 Debian:unstable [amd64])
Inst vera++ (1.2.1-2+b7 Debian:11.6/stable, Debian:unstable, Debian:testing 
[amd64])
Conf libboost-wave1.74.0 (1.74.0+ds1-20 Debian:unstable [amd64])
Conf vera++ (1.2.1-2+b7 Debian:11.6/stable, Debian:unstable, Debian:testing 
[amd64])

I am therefore taking the liberty to close this referenced bugreport
via a CC of this message. The rest of this message should shine some
light on why this might 

Bug#1032584: xdg-desktop-portal-gnome: 44 causes long delay in portal apps for non-GNOME desktops

[Jeremy Bícha]

Source: xdg-desktop-portal-gnome
Version: 44~beta-1
Severity: serious
Control: forwarded -1
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/74

If xdg-desktop-portal-gnome 44~beta-1 is installed and a non-GNOME
desktop is used (like MATE), the first time trying to use something
like the file chooser in a portal-confined app will do nothing until
the systemd user service times out (90 seconds??). Afterwards, the
file chooser works normally.

In Debian (and Ubuntu), it's not expected that
xdg-desktop-portal-gnome would be installed on a system that does not
have GNOME installed (it is not a dependency of other things).
However, it is easily possible for someone to have multiple desktops
installed on their system and they would experience this bug then.

Thank you,
Jeremy Bícha

Bug#1032583: Please add Provides: headers to provide names following the HDF5 Filter Plugin Packaging Guidelines

[Enrico Zini]

Source: bitshuffle
Version: 0.3.5-4
Severity: wishlist
Tags: patch

Hello,

the HDF5 Filter Plugin Packaging Guidelines at
https://salsa.debian.org/science-team/h5f-packaging-guidelines
suggests a unified naming scheme for HDF5 filter plugin packages, so
that packages that depend on a plugin can do so regardless of where it
is implemented.

I created a MR to add support for this to bitshuffle, which also adds
autopkgtests to test that the plugins load from h5py:
https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/2

I tested the MR by creating a fork of bitshuffle and setting
"Settings/CI-CD/General pipelines/CI/CD configuration file" to
recipes/debian.yml@salsa-ci-team/pipeline[1]:
https://salsa.debian.org/enrico/bitshuffle/-/pipelines/509547


Thanks,

Enrico

[1] see https://salsa.debian.org/salsa-ci-team/pipeline#basic-use


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

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

Bug#912993: printer-driver-cups-pdf: creates wrong filename using short title

[in . cognito35]

I'm on Debian testing with package printer-driver-cups-pdf version 3.0.1-14.

I get broken output file names as well, and I think it is an upstream bug.

Here is my configuration as dumped by cups-pdf:

-- snip --
Thu Mar  9 14:50:11 2023  [DEBUG] *** Final Configuration ***
Thu Mar  9 14:50:11 2023  [DEBUG] AnonDirName= 
"/var/spool/cups-pdf/ANONYMOUS"
Thu Mar  9 14:50:11 2023  [DEBUG] AnonUser   = "nobody"
Thu Mar  9 14:50:11 2023  [DEBUG] GhostScript= "/usr/bin/gs"
Thu Mar  9 14:50:11 2023  [DEBUG] GSCall = "%s -q 
-dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite 
-sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false 
-dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s"
Thu Mar  9 14:50:11 2023  [DEBUG] Grp= "lpadmin"
Thu Mar  9 14:50:11 2023  [DEBUG] GSTmp  = "TMPDIR=/var/tmp"
Thu Mar  9 14:50:11 2023  [DEBUG] Log= "/var/log/cups"
Thu Mar  9 14:50:11 2023  [DEBUG] PDFVer = "1.2"
Thu Mar  9 14:50:11 2023  [DEBUG] PostProcessing = ""
Thu Mar  9 14:50:11 2023  [DEBUG] Out= 
"${HOME}/tmp/transfer/print"
Thu Mar  9 14:50:11 2023  [DEBUG] Spool  = 
"/var/spool/cups-pdf/SPOOL"
Thu Mar  9 14:50:11 2023  [DEBUG] UserPrefix = ""
Thu Mar  9 14:50:11 2023  [DEBUG] RemovePrefix   = ""
Thu Mar  9 14:50:11 2023  [DEBUG] OutExtension   = "pdf"
Thu Mar  9 14:50:11 2023  [DEBUG] Cut= 3
Thu Mar  9 14:50:11 2023  [DEBUG] Truncate   = 64
Thu Mar  9 14:50:11 2023  [DEBUG] DirPrefix  = 0
Thu Mar  9 14:50:11 2023  [DEBUG] Label  = 2
Thu Mar  9 14:50:11 2023  [DEBUG] LogType= 7
Thu Mar  9 14:50:11 2023  [DEBUG] LowerCase  = 1
Thu Mar  9 14:50:11 2023  [DEBUG] TitlePref  = 0
Thu Mar  9 14:50:11 2023  [DEBUG] DecodeHexStrings   = 1
Thu Mar  9 14:50:11 2023  [DEBUG] FixNewlines= 0
Thu Mar  9 14:50:11 2023  [DEBUG] AllowUnsafeOptions = 0
Thu Mar  9 14:50:11 2023  [DEBUG] AnonUMask  = 
Thu Mar  9 14:50:11 2023  [DEBUG] UserUMask  = 0077
Thu Mar  9 14:50:11 2023  [DEBUG] *** End of Configuration ***
-- snip --

A few lines later in the log file I get these really suspicious entries:

-- snip --
Thu Mar  9 14:50:11 2023  [DEBUG] found title in ps code: cups-pdf.c
idt/tmp/transfer/print
Thu Mar  9 14:50:11 2023  [DEBUG] found end of postscript code: %%EOF

-- snip --

Note that newline ("cups-pdf.c***\n***idt/tmp/transfer/print") is part of
the first log line!

So IMHO there is something wrong with this block from cups-pdf.c:

-- snip --
  if (sscanf(buffer, "Title: %"TBUFSIZE"c", title)==1) {
log_event(CPDEBUG, "found title in ps code: %s", title);
is_title=1;
  }
-- snip --

Can it be that the result in variable title needs to be zero-terminated?

Bug#1032517: [Pkg-nginx-maintainers] Bug#1032517:

[Jérémy Lal]

Le jeu. 9 mars 2023 à 15:00, Piotr Jurkiewicz <
piotr.jerzy.jurkiew...@gmail.com> a écrit :

> On Wed, 8 Mar 2023 19:05:39 +0100 Jan Mojzis  wrote:
> > Hello,
> > can You please send me the steps how i can reproduce it
> > - packages list/versions before the upgrade
> > - exact apt/apt-get command
> > - packages list/versions after the upgrade
> >
> > Jan
> >
> >
>
> I used aptitude to perform upgrade.
>
> Before upgrade:
>
> ii  libnginx-mod-http-echo 1.22.0-3 amd64
> ii  libnginx-mod-http-perl 1.22.0-3 amd64
> ri  nginx-common   1.22.0-3 all
> ii  nginx-light1.22.0-3 amd64
> ii  python3-certbot-nginx  1.29.0-1 all
>
> After:
>
> ii  libnginx-mod-http-echo 1:0.63-4 amd64
> ii  libnginx-mod-http-perl 1.22.1-7 amd64
> ii  nginx  1.22.1-7 amd64
> ii  nginx-common   1.22.1-7 all
> ii  nginx-light1.22.1-7 all
> ii  python3-certbot-nginx  2.1.0-2  all
>
> Then I used aptitude to purge leftover configuration files:
>
> # aptitude purge ?config-files
> The following packages will be REMOVED:
>emacsen-common{p} libpython3.10-minimal{p} nginx-common{p}
> php8.1-cli{p} php8.1-common{p} php8.1-fpm{p} php8.1-opcache{p}
> php8.1-readline{p} python3.10-minimal{p}
> 0 packages upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 0 B will be used.
> Do you want to continue? [Y/n/?] y
>

Jan,
Did default config files in /etc/nginx/  moved from nginx-common to nginx ?

Jérémy

Bug#1032387: aide: Cron job does not send mail with new _aide user

[Marc Haber]

On Thu, Mar 09, 2023 at 02:46:10PM +0100, Guillem Jover wrote:
> Sorry for apparently dropping the ball on this, but was trying to dig
> further what was going on, and tried directly on my production system
> by doing changes and letting the cron job run as usual, so had to wait
> a couple of days to get some of the results. :)
> 
> I think this might have been a problem with the systemd service, which
> does not seem to give the same POSIX capabilities as the capsh
> invocation. I can probably test this hypothesis by installing aide in
> one of my systemd-based systems.

Ah. So it might be possible that I encountered the issue with systemd
and then assumed that the capsh-based invocation would have the same
issue. That at least explains why I wasn't able to reproduce this with
capsh alone.

> I think the options here could be to match the POSIX capabilities for
> the systemd service to the ones used in capsh, which should then let
> the sendmail set-uid-root case work, in addition to the patch I
> provided, otherwise that seems like a regression for the systemd case.

Supporting plain bsd-mailx in the systemd case would indeed be nice as
it would remove the necessity to use s-nail. I think that's too late for
bookworm now though, I'd be willing to ease the sysvinit pain for
bookworm with non-intrusive patches but that one is too big, I think.

> Another option would be to make the disabling for the mail on non-root
> case conditional on --systemdservice option passed by the systemd
> service. Which should make it work fine with non-systemd's capsh
> invocation. I can prepare an update for that.

The non-root systemd case works fine with s-nail, making it necessary to
have an SMTP listener.


> Also another problem is that USER is currently hardcoded to root, so
> that makes the directory check fail. Ideally USER would get automatically
> set instead of hardcoding it to root though, as that makes a check fail,
> say with USER=$(id -u -n) or similar. Will prepare another patch with
> that too.

USER is a bad variable name anyway, I'm working hard to eliminate that
from all my scirpts, but old habits dont die easily.

fyi, I'd like to to an upload quite soon.

Greetings
Marc

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

Bug#1032582: linux: Enable CAN_MCP251XFD

[Bastian Germann]

Source: linux
Version: 6.1.15-1
Severity: wishlist

The driver CAN_MCP251X is already enabled on all platforms.
Please enable CAN_MCP251XFD as module as well. Thank you!

Bug#1032517:

[Piotr Jurkiewicz]

On Wed, 8 Mar 2023 19:05:39 +0100 Jan Mojzis  wrote:

Hello,
can You please send me the steps how i can reproduce it
- packages list/versions before the upgrade
- exact apt/apt-get command
- packages list/versions after the upgrade

Jan




I used aptitude to perform upgrade.

Before upgrade:

ii  libnginx-mod-http-echo 1.22.0-3 amd64
ii  libnginx-mod-http-perl 1.22.0-3 amd64
ri  nginx-common   1.22.0-3 all
ii  nginx-light1.22.0-3 amd64
ii  python3-certbot-nginx  1.29.0-1 all

After:

ii  libnginx-mod-http-echo 1:0.63-4 amd64
ii  libnginx-mod-http-perl 1.22.1-7 amd64
ii  nginx  1.22.1-7 amd64
ii  nginx-common   1.22.1-7 all
ii  nginx-light1.22.1-7 all
ii  python3-certbot-nginx  2.1.0-2  all

Then I used aptitude to purge leftover configuration files:

# aptitude purge ?config-files
The following packages will be REMOVED:
  emacsen-common{p} libpython3.10-minimal{p} nginx-common{p} 
php8.1-cli{p} php8.1-common{p} php8.1-fpm{p} php8.1-opcache{p} 
php8.1-readline{p} python3.10-minimal{p}

0 packages upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] y

Bug#1032575: a2ps: new upstream version available

[Roland Rosenfeld]

Hi Salvatore!

On Thu, 09 Mar 2023, Salvatore Bonaccorso wrote:

> Source: a2ps
> Version: 1:4.14-7
> Severity: wishlist
> X-Debbugs-Cc: car...@debian.org

> Not in time for the Debian bookworm release, but please package
> afterwards the new a2ps upstream version:
> 
> https://lists.gnu.org/archive/html/info-gnu/2023-03/msg2.html

To avoid duplicate work from the QA team:

I think about adopting the package and currently work on upgrade in
the following salsa repo:

https://salsa.debian.org/roland/a2ps

Greetings
Roland

Bug#1032581: mirror submission for debian.mirror.ac.za

[TENET Mirror service]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.mirror.ac.za
Type: leaf
Archive-architecture: amd64 arm64 hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 
powerpc s390x
Archive-http: /debian/
Archive-rsync: debian/debian/
Maintainer: TENET Mirror service 
Country: ZA South Africa
Sponsor: TENET South Africa https://tenet.ac.za




Trace Url: http://debian.mirror.ac.za/debian/project/trace/
Trace Url: http://debian.mirror.ac.za/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.mirror.ac.za/debian/project/trace/debian.mirror.ac.za

Bug#1032387: aide: Cron job does not send mail with new _aide user

[Guillem Jover]

Hi!

On Thu, 2023-03-09 at 14:07:45 +0100, Marc Haber wrote:
> Control: retitle -1 non-root check in dailyaidecheck might be unnecessary
> Control: tags -1 patch
> Control: severity -1 normal

> On Sun, Mar 05, 2023 at 07:14:14PM +0100, Guillem Jover wrote:
> > Something like the attached patch might do I guess? Will test properly
> > later today, and further check the README in case there is something
> > else to update or so, and probably update the commit message with more
> > information. Let me know whether I might have missed something obvious.
> 
> I am totally unsure with this topic at the moment. I cannot reproduce
> the behavior that I experienced when building the code, and sadly I do
> not have enough documentation about the exact environment that I
> experienced this.
> 
> I am however reluctant to apply your patch in bookworm, there is quite
> many possibility to add breakage by removing the check, and I'd rather
> not do that at this time of the release schedule. I might revisit that
> after the bookworm release, and am open to arguments.

Sorry for apparently dropping the ball on this, but was trying to dig
further what was going on, and tried directly on my production system
by doing changes and letting the cron job run as usual, so had to wait
a couple of days to get some of the results. :)

I think this might have been a problem with the systemd service, which
does not seem to give the same POSIX capabilities as the capsh
invocation. I can probably test this hypothesis by installing aide in
one of my systemd-based systems.

I think the options here could be to match the POSIX capabilities for
the systemd service to the ones used in capsh, which should then let
the sendmail set-uid-root case work, in addition to the patch I
provided, otherwise that seems like a regression for the systemd case.

Another option would be to make the disabling for the mail on non-root
case conditional on --systemdservice option passed by the systemd
service. Which should make it work fine with non-systemd's capsh
invocation. I can prepare an update for that.

The third option I see, which is what I've currently ended up with, is
to document that this does not work (currently/it's a regression), but
that setting MAILCMD=mail and USER=_aide explicitly in the default
file makes this work again.

Also another problem is that USER is currently hardcoded to root, so
that makes the directory check fail. Ideally USER would get automatically
set instead of hardcoding it to root though, as that makes a check fail,
say with USER=$(id -u -n) or similar. Will prepare another patch with
that too.

Thanks,
Guillem

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> After upgrade, something that used to work stopped working, which
> seemed appropriate to me, but if you disagree I don't feel like
> arguing over this.

Debian decided that support for non-systemd init systems is optional and
that we're allowed to use systemd features. I am not a systemd fanboi,
but I see its advantages and have committed to using its features and I
feel that it's fair to leave the work of supporting non-systemd init
systems to the users of those init systems. Thanks for helping here, and
I will try to be as accomodating as possible while not spending too much
time myself. My focus therefore is not to break systemd systemd and not
to add ballast.

> -if command -v systemd-sysusers >/dev/null; then
> +if command -v adduser >/dev/null; then
> +# XXX: Use deprecated options to handle a smooth partial upgrade,
> +# switch the the new options after bookworm's release.
> +adduser --system --group --force-badname --quiet \
> +--no-create-home --home /var/lib/aide --shell /usr/sbin/nologin \
> +---gecos 'Advanced Intrusion Detection Environment' _aide
> +elif command -v systemd-sysusers >/dev/null; then
>  systemd-sysusers
>  fi

I am not sure whether calling systemd-sysusers from postinst is still
necessary if dh_installsysusers is used, so I'll adapt this after
testing the new dh_installsysusers stuff.

>  # added updating to 0.18-1
>  rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
>  
> -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> +if dpkg --compare-versions "$2" lt "0.18-2"; then

I am wondering why your postinst didn't trigger there. And I think if
there is one person in Debian who knows how dpkg --compare-versions
works then I am right now talking to him.

Current stable has 0.17.3-4+deb11u1, and we had  number of 0.17.4
versions in testing during the bullseye cycle, so even the first version
comparing with 0.17.5-1 should have always triggered the chown
mechanisms, right?

>  # we're updating from a version earlier than 0.17.5, chown logs and 
> databases
>  chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log 
> /var/log/aide/aide.log.* || true
> +chown --quiet _aide:adm /var/log/aide/aideinit.log 
> /var/log/aide/aideinit.errors || true
>  chmod --quiet 2755 /var/log/aide || true
>  chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new 
> || true

This would re-chown the other logfiles and the database for a user who
had updated to 0.18-1 or 0.18-2 before and then decided to run aide with
a different user. Wouldn't it be clearer to have a dedicated dpkg
--compare-versions route for the forgotten aideinit.log, like:

if dpkg --compare-versions "$2" lt 0.18-3; then
# we're updating from a version earlier than 0.18-3, chown aideinit logs
chown --quiet _aide:adm /var/log/aide/aideinit.log 
/var/log/aide/aideinit.errors|| true
fi

>  Depends: aide (>= 0.17),
>   liblockfile1,
>   ucf (>= 2.0020),
> + adduser | systemd-sysusers,
>   ${misc:Depends}

This is hopefully handled by dh_installsysusers

>  Recommends: cron,
> + libcap2-bin,
>   bsd-mailx | mailx | s-nail

I'd rather not have this but document it in README.Debian to not pull in
libcap2-bin on systemd systems which don't need that dependency. I have
added a half-sentence mentioning libcap2-bin to README.Debian. The
scripts should run fine without libcap2-bin installed and fall back to
running as root instead.

Greetings
Marc

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:
> So ideally this would get adduser support, and depend on either that
> or systemd-standalone-sysusers.

As the maintainer of adduser, I specifically selected aide to be my test
balloon to "test the enemy" ;-)

I was not aware of dh_installsysusers and will change the package to use
that instead.

Greetings
Marc

Bug#1032580: unblock: gnome-initial-setup/43.2-4

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gnome-initial-se...@packages.debian.org
Control: affects -1 + src:gnome-initial-setup

Please unblock package gnome-initial-setup

[ Reason ]
Fix UI glitches observed while testing fixes for #1029821

[ Impact ]
If not fixed, the full-screen "out of box experience" app shown on the
first login to GNOME, after initial installation or creating a new user,
is less polished than it should be.

The main fix since bookworm is that for users in locales that use a
non-trivial IBus input method rather than a simple Xkb keyboard layout
(Chinese, Japanese, Hindi, etc.), the default input method was mislabelled
and did not always appear. (#1032382)

This version also has an upstream change backported from upstream version
44.rc, fixing a regression that caused the shortlist of plausible
non-default keyboard layouts and input methods to be empty. There is
still a known bug that the shortlist is not very *useful* (it does not
have enough information to be weighted towards commonly-used keyboard
layouts and input methods for the relevant country, and away from
rare/specialized layouts like Dvorak), but that's not a regression and
it's better than nothing.

It also includes smaller tweaks to ensure the gnome-initial-setup window
is appropriately labelled in Alt+Tab and the Overview.

[ Tests ]
Manually tested via the steps in debian/README.source of unstable's
gnome-initial-setup, using English and Japanese locales.

Also carried out an installation of bookworm in Japanese (using a
parallel installation in English as a reference for which button does
what) and before logging in to GNOME for the first time, logged in via
tty to upgrade gnome-initial-setup and all packages from src:gnome-desktop
to their unstable versions.

[ Risks ]
This is a highly visible package with code that is surprisingly
fragile internally, and my initial attempt at this patchset caused it
to crash; but I expect that a lot of people will be testing new GNOME
installs between now and release day, so we'll get regression reports
if appropriate.

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

unblock gnome-initial-setup/43.2-4
diffstat for gnome-initial-setup-43.2 gnome-initial-setup-43.2

 data/gnome-initial-setup.desktop.in.in |1 
 debian/README.source   |   19 +
 debian/changelog   |   52 ++
 debian/control |2 
 debian/patches/Add-StartupWMClass-to-.desktop-file.patch   |   29 +
 debian/patches/driver-Set-a-non-trivial-window-title.patch |   28 +
 debian/patches/keyboard-Correctly-update-labels-for-IBus-engines.patch |  189 ++
 debian/patches/keyboard-Resort-refilter-list-when-picking-shortlist.patch  |   96 +
 debian/patches/keyboard-Update-filter-and-sort-when-the-display-name-cha.patch |   46 ++
 debian/patches/reenable-existing-user-mode.patch   |6 
 debian/patches/series  |5 
 gnome-initial-setup/gis-driver.c   |1 
 gnome-initial-setup/pages/keyboard/cc-input-chooser.c  |   86 +++-
 13 files changed, 529 insertions(+), 31 deletions(-)

diff -Nru gnome-initial-setup-43.2/data/gnome-initial-setup.desktop.in.in gnome-initial-setup-43.2/data/gnome-initial-setup.desktop.in.in
--- gnome-initial-setup-43.2/data/gnome-initial-setup.desktop.in.in	2022-12-02 15:11:34.0 +
+++ gnome-initial-setup-43.2/data/gnome-initial-setup.desktop.in.in	2023-03-09 12:51:50.0 +
@@ -10,3 +10,4 @@
 OnlyShowIn=GNOME;
 NoDisplay=true
 X-GNOME-HiddenUnderSystemd=@systemd_hidden@
+StartupWMClass=org.gnome.InitialSetup
diff -Nru gnome-initial-setup-43.2/debian/changelog gnome-initial-setup-43.2/debian/changelog
--- gnome-initial-setup-43.2/debian/changelog	2022-12-06 14:27:10.0 +
+++ gnome-initial-setup-43.2/debian/changelog	2023-03-06 23:46:19.0 +
@@ -1,3 +1,55 @@
+gnome-initial-setup (43.2-4) unstable; urgency=medium
+
+  * Team upload
+  * d/p/keyboard-Resort-refilter-list-when-picking-shortlist.patch:
+Add patch from upstream 44.rc to display more input methods and
+keyboard layouts without clicking the "more..." button. This has
+a known issue that the shortlist of keyboard layouts is often not
+particularly useful, but at least it includes the default and
+current layouts (possibly different) and some other possibilities.
+  * d/p/keyboard-Correctly-update-labels-for-IBus-engines.patch,
+

Bug#1032579: unblock: gnome-desktop/43.2-2

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gnome-desk...@packages.debian.org, 
debian-japan...@lists.debian.org
Control: affects -1 + src:gnome-desktop

Please unblock package gnome-desktop

[ Reason ]
Make default input method for ja_JP match what tasksel installs
(#1029821, grave)

[ Impact ]
If not accepted, Japanese-speaking users will find that gnome-initial-setup
leaves them without a working input method, unless they happen to have
installed ibus-anthy separately. This is because GNOME upstream prefers
to default to ibus-anthy, but Japanese-speaking Debian/Ubuntu users say
that ibus-mozc is a higher-quality default on architectures where it
is built, and therefore that's what task-japanese-gnome-desktop pulls in.

If this change is not accepted, then we should change tasksel to make
task-japanese-gnome-desktop pull in ibus-anthy instead of ibus-mozc
();
but Japanese-speaking users have told us that defaulting to ibus-anthy
would be unacceptable, so we have not gone that route.

[ Tests ]
Manually tested via the steps in debian/README.source of unstable's
gnome-initial-setup, both with ibus-mozc installed (reflecting what will
happen on x86 and ARM) and with only ibus-anthy installed (reflecting
what will happen on ppc64el and s390x, where ibus-mozc is unavailable
and ibus-anthy is the best thing available for Japanese users).

Also carried out an installation of bookworm in Japanese (using a
parallel installation in English as a reference for which button does
what) and before logging in to GNOME for the first time, logged in via
tty to upgrade gnome-initial-setup and all packages from src:gnome-desktop
to their unstable versions.

I can't read or write Japanese, so I can't tell the difference between
anthy and mozc; but in the Japanese installation,
`gsettings list-recursively` contained

org.gnome.desktop.input-sources sources [('xkb', 'jp'), ('ibus', 'mozc-jp')]

which seems like it's probably the desired result. Also, the option
selected in GNOME's menu of input methods by default is
"日本語 (Mozc)" which again seems plausibly correct.

[ Risks ]
The core change here is trivial: it's just replacing the name of one
IBus input method with another.

The hack to fall back to ibus-anthy if ibus-mozc isn't installed is
less trivial, but still straightforward. I wish we didn't have to do this,
but from what I understand of the problem, we need this for unconventional
CPU architectures.

If the accompanying gnome-initial-setup change (see separate unblock
request) is not accepted, then the UI will be sub-optimal (the ibus-mozc
option will appear as "mozc-jp" in the UI instead of the intended
"Japanese (Mozc)"), but that's not actually a regression: the same thing
happens today for ibus-anthy.

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

unblock gnome-desktop/43.2-2
diffstat for gnome-desktop-43.2 gnome-desktop-43.2

 debian/changelog   |   25 ++
 debian/control |6 -
 debian/control.in  |4 -
 debian/libgnome-desktop-doc.lintian-overrides  |2 
 debian/patches/Fall-back-to-ibus-anthy-if-ibus-mozc-jp-is-unavailable.patch|   39 ++
 debian/patches/Use-mozc-as-the-default-input-source-for-Japanese.patch |   34 
 debian/patches/languages-Look-at-LOCPATH-before-compile-time-LIBLOCALEDI.patch |8 +-
 debian/patches/series  |2 
 libgnome-desktop/default-input-sources.h   |2 
 libgnome-desktop/gnome-languages.c |9 ++
 10 files changed, 119 insertions(+), 12 deletions(-)

diff -Nru gnome-desktop-43.2/debian/changelog gnome-desktop-43.2/debian/changelog
--- gnome-desktop-43.2/debian/changelog	2023-02-15 16:15:51.0 +
+++ gnome-desktop-43.2/debian/changelog	2023-03-05 18:11:37.0 +
@@ -1,3 +1,28 @@
+gnome-desktop (43.2-2) unstable; urgency=medium
+
+  * Team upload
+  * d/control.in: Fix Vcs-Git and Vcs-Browser syntax
+  * d/p/Use-mozc-as-the-default-input-source-for-Japanese.patch:
+Change the default input method for Japanese to mozc-jp, matching
+tasksel.
+mozc is pulled in as the most-preferred input method by
+task-japanese-desktop (uim-mozc) and task-japanese-gnome-desktop
+(ibus-mozc) on the architectures where it is available, notably
+x86 and ARM. There seems to be consensus among Japanese-speaking
+Debian and Ubuntu users that mozc is the best default input method,
+so make the 

Bug#1032387: aide: Cron job does not send mail with new _aide user

[Marc Haber]

Control: retitle -1 non-root check in dailyaidecheck might be unnecessary
Control: tags -1 patch
Control: severity -1 normal

On Sun, Mar 05, 2023 at 07:14:14PM +0100, Guillem Jover wrote:
> Something like the attached patch might do I guess? Will test properly
> later today, and further check the README in case there is something
> else to update or so, and probably update the commit message with more
> information. Let me know whether I might have missed something obvious.

I am totally unsure with this topic at the moment. I cannot reproduce
the behavior that I experienced when building the code, and sadly I do
not have enough documentation about the exact environment that I
experienced this.

I am however reluctant to apply your patch in bookworm, there is quite
many possibility to add breakage by removing the check, and I'd rather
not do that at this time of the release schedule. I might revisit that
after the bookworm release, and am open to arguments.

Greetings
Marc

Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?

[Christian Kastner]

(debian-ai, apologies for re-sending, I hit the wrong reply button.)

On 2023-03-08 18:21, Simon McVittie wrote:
> There is *a* version of llvm-toolchain-15 in bookworm, version 1:15.0.6-4,
> which is used by the rocm-hipamd_5.2.3-1 and mesa_22.3.3-1 in bookworm.
> I'm not suggesting that 1:15.0.6-4 should be *removed*. What I'm asking
> here is whether it's intended to be upgraded to 1:15.0.7-1 (or presumably
> a later version where #1029010 has been fixed), or kept at 1:15.0.6-4
Are the upstream differences between 15.0.6 and 15.0.7 that big?

I think for rocm-hipamd, the main issue is that 5.2.3-5 depends on
libclang-rt-15-dev, which was introduced to unstable by means of a
package split in 1:15.0.7-1.

I'm pretty sure rocm-hipamd could live with the version in bookworm, but
it would need a new upload to change the dependency to reflect the
pre-split view.

In fact, we almost went so far as to implement just that, but we let it
as-is after all, because we assumed that #1029010 would be resolved in
due time, one way or another.

Best,
Christian