Bug#1032405: installation-reports: missing nvidia nouveau firmware: nvac_fuc084 & nvac_fuc084d

[Cyril Brulebois]

Hi,

Fab Stz  (2023-03-06):
> Package: installation-reports
> Severity: normal
> 
> I couldn't try on the real system which is an iMac 9.1 (because I don't have
> physical access to it presently), but there is no package shipping these
> firmware files which are required by nouveau.
> 
> firmware: failed to load nouveau/nvac_fuc084 (-2)
> firmware: failed to load nouveau/nvac_fuc084d (-2)
> 
> Boot method: DVD
> Image version: 
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso
> Date: 2023-03-06
> 
> Machine: imac 9.1
> 
> Until now, I installed them this way as per
> https://nouveau.freedesktop.org/VideoAcceleration.html
> 
> mkdir /tmp/nouveau
> cd /tmp/nouveau
> wget https://raw.github.com/envytools/firmware/master/extract_firmware.py
> wget 
> http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
> sh NVIDIA-Linux-x86-325.15.run --extract-only
> python2.7 extract_firmware.py  # this script is for python 2 only
> mkdir /lib/firmware/nouveau
> cp -d nv* vuc-* /lib/firmware/nouveau/
> 
> 
> It would be nice if there were a firmware package for it in bookworm

I can't really check license etc. right now, but that looks like
something that should be filed against src:firmware-nonfree, which ships
some nvidia-related firmware files in its firmware-misc-nonfree binary
package.

It'd be nice if someone else from debian-boot@ could triage this
further.


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


signature.asc
Description: PGP signature

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

[Marc Haber]

On Sun, Mar 05, 2023 at 11:26:06PM +0100, Guillem Jover wrote:
> On Sun, 2023-03-05 at 20:36:01 +0100, Marc Haber wrote:
> > On Sun, Mar 05, 2023 at 05:31:16PM +0100, Guillem Jover wrote:
> > > The daily aide cron job warns that it cannot send mail as non-root
> > > user. Was wondering why or how to change or workaround that, and saw
> > > commit e82b5c9112d95b5c813ee29c3234733ae0f2c862, but it is not clear
> > > why mail from non-root was disabled
> > 
> > See README.Debian.gz, chapter "Sending the report per mail" and re-open
> > this bug if the explanation is not satisfactory. Documentation patch is
> > appreciated.
> > 
> > tl;dr: suid root on /usr/lib/sendmail doesn't work when capsh is used.
> 
> See my earlier followup mail, it seems to be working for me though?
> With bsd-mailx, exim4 (which is suid-root) and capsh installed. So
> I'm not sure I'm doing something "wrong", or the case that's not
> supposed to work is something else?

Sorry for not reading up on the entire bug history before replying
yesterday. I just did very superficial testing of the non-systemd code
paths since I don't have a big fleet of non-systemd machines at all. My
diagnosis was that on my test systems, the exim4 the message ended up
with by virtue of the /usr/lib/sendmail symlink didn't run as root
despite being suid root as soon as capsh was used. I don't know why you
made a different experience.

Maybe it would be a good idea to make the "do not run as root" code a
bit less automagic and offer a "alwas run as root" option in
/etc/default/aide. I am not sure whether this would qualify as a "small,
targeted fix" as per release policy, so I would probably be more happy
with documenting a working way to get the current code working for
bookworm.

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#1032405: installation-reports: missing nvidia nouveau firmware: nvac_fuc084 & nvac_fuc084d

[Fab Stz]

Package: installation-reports
Severity: normal

I couldn't try on the real system which is an iMac 9.1 (because I don't have
physical access to it presently), but there is no package shipping these
firmware files which are required by nouveau.

firmware: failed to load nouveau/nvac_fuc084 (-2)
firmware: failed to load nouveau/nvac_fuc084d (-2)

Boot method: DVD
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso
Date: 2023-03-06

Machine: imac 9.1

Until now, I installed them this way as per
https://nouveau.freedesktop.org/VideoAcceleration.html

mkdir /tmp/nouveau
cd /tmp/nouveau
wget https://raw.github.com/envytools/firmware/master/extract_firmware.py
wget 
http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
sh NVIDIA-Linux-x86-325.15.run --extract-only
python2.7 extract_firmware.py  # this script is for python 2 only
mkdir /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/


It would be nice if there were a firmware package for it in bookworm


-- Package-specific info:

I removed it because it was not related to the system for which I report the 
issue.

Bug#1032343: curl: FTBFS on amd64, arm64: stunnel fails to connect to backend: Connection refused

[Adrian Bunk]

On Sat, Mar 04, 2023 at 10:50:52AM +, Simon McVittie wrote:
> Source: curl
> Version: 7.88.1-2
> Severity: important
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=curl=amd64=7.88.1-2=1677835010=0
> https://buildd.debian.org/status/fetch.php?pkg=curl=arm64=7.88.1-2=1677835482=0
> 
> > TESTFAIL: These test cases failed: 300 301 303 304 306 309 310 325 364 400 
> > 401 403 406 407 408 409 410 414 417 560 678 1112 1272 1561 1562 1630 1631 
> > 1632 2034 2037 2041 3000 3001
> 
> I've given these builds back in the hope that it's only an intermittent
> failure. If I'm understanding the failure correctly, the test suite is
> running stunnel to provide SSL/TLS in front of a backend server, but the
> test is connecting to stunnel before the backend is ready, leading to
> "Connection refused" errors:

Based on what buildds it failed on, the pattern is "FTBFS on IPV6-only buildds".

>...
> >  2023.03.03 09:09:05 LOG5[0]: Service [curltest] accepted connection from 
> > :::127.0.0.1:51722
> >  2023.03.03 09:09:05 LOG3[0]: s_connect: connect ::1:34321: Connection 
> > refused (111)
>...
> smcv

cu
Adrian

Bug#1013668: RFP: openseachest -- utilities for operations on SATA/SAS/NVMe/USB storage devices

[Gürkan Myczko]

On 03.03.2023 17:31, Christoph Anton Mitterer wrote:

On Fri, 2023-03-03 at 08:38 +0100, Gürkan Myczko wrote:

I have some packaging of it here, but I'm not yet sure how to fix
remaining lintian problems,
their manpages are of non optimal quality:

http://sid.ethz.ch/debian/openseachest/


Looks nice...


Thanks


have you asked a sponsor for help with the lintian
problems?


I can be my own sponsor, but here's this issue which has some more 
information:

https://github.com/Seagate/openSeaChest/issues/104



Cheers,
Chris.


Cheers,

Bug#1032404: webkit2gtk: Please add m68k to the list of architectures with limited address space

[John Paul Adrian Glaubitz]

Source: webkit2gtk
Version: 2.38.5-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

webkit2gtk needs to built with reduced optimizations on m68k for the build to
succeed as gcc runs out of memory at some point.

Thus, please add m68k to the following list of architectures in debian/rules:

--- debian/rules.orig   2023-02-15 18:10:55.0 +0100
+++ debian/rules2023-03-06 07:45:52.437878152 +0100
@@ -63,7 +63,7 @@
 endif
 
 # Lower memory requirements on architectures with only 2 GB address space
-ifneq (,$(filter $(DEB_HOST_ARCH),mips mipsel sh4))
+ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4))
CFLAGS := $(CFLAGS:-g1=-g0)
CFLAGS := $(CFLAGS:-O2=-Os)
CPPFLAGS += --param ggc-min-expand=10

I'm also attaching a patch.

Note: There is a second issue on m68k which makes the build fail due to 
incorrect
  alignment. This issue will be addressed in a different manner hopefully 
soon
  by switching the default alignment on m68k to 32 bits.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2023-02-15 18:10:55.0 +0100
+++ debian/rules2023-03-06 07:45:52.437878152 +0100
@@ -63,7 +63,7 @@
 endif
 
 # Lower memory requirements on architectures with only 2 GB address space
-ifneq (,$(filter $(DEB_HOST_ARCH),mips mipsel sh4))
+ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4))
CFLAGS := $(CFLAGS:-g1=-g0)
CFLAGS := $(CFLAGS:-O2=-Os)
CPPFLAGS += --param ggc-min-expand=10

Bug#992823: takes long time to analyse perl processes

[Paul Wise]

On Mon, 23 Aug 2021 23:42:14 +0200 Timo Weingärtner wrote:

> The time needrestart takes to analyse processes is to a great amount
> influenced by the existence and count of perl processes:

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

   sudo apt install libdevel-nytprof-perl
   sudo env NYTPROF=trace=2:start=init:file=`pwd`/nytprof.out perl -d:NYTProf 
/usr/sbin/needrestart
   sudo chown "$USER"
   nytprofhtml --open

I found that on my system there are a couple of Perl processes
and one of them takes a lot more time to scan than the other one.

   $ ps auxf | grep perl | grep -oE '/usr/s?bin/[^ ]*' | sort -u
   /usr/bin/parcimonie
   /usr/bin/perl
   /usr/sbin/spamd

   $ time scandeps /usr/sbin/spamd > /dev/null
   
   real 0m1.430s
   user 0m1.350s
   sys  0m0.080s
   
   $ time scandeps /usr/bin/parcimonie > /dev/null
   # Use of runtime loader module Module::Runtime detected.  Results of static 
scanning may be incomplete.
   # Use of runtime loader module Module::Implementation detected.  Results of 
static scanning may be incomplete.
   
   real 0m8.155s
   user 0m7.006s
   sys  0m0.999s
   
Researching the landscape of such tools, I found these other ones:

   Perl::PrereqScanner
   Perl::PrereqScanner::NotQuiteLite
   Perl::PrereqScanner::Lite
   
   
https://stackoverflow.com/questions/358891/how-do-i-find-the-module-dependencies-of-my-perl-script

These all complete a *lot* faster but do not produce the same
results and so they are probably *not* useful for this situation.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1032403: calendar: Outdated entry "Mar 05 Mother-in-Law Day, USA"

[andrew bezella]

Package: calendar
Version: 12.1.8
Severity: minor

Dear Maintainer,

i noticed that `calendar` reports:
Mar 05  Mother-in-Law Day, USA

cf. `/usr/share/calendar/calendar.usholiday`.

it appears that while the first observance was celebrated on March 5,
1934[1] it is currently the fourth Sunday in October[2].

1. 
https://web.archive.org/web/20230306051540/https://nationaldaycalendar.com/national-mother-in-law-day-fourth-sunday-in-october/
2. https://www.google.com/search?q=Mother-in-Law+Day%2C+USA

thank you.

andy

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

Kernel: Linux 6.1.0-3-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.UTF-8:en.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calendar depends on:
ii  cpp  4:12.2.0-3
ii  libbsd0  0.11.7-2
ii  libc62.36-8

calendar recommends no packages.

calendar suggests no packages.

-- no debconf information

Bug#982299: vlc: seems related to https://github.com/aler9/rtsp-simple-server/issues/223

[Bryant Eadon]

Can you point me to the non-free code ?  RTSP has been a really nice
feature in VLC for some time.

I really would like to see the support continue.  Right now it's difficult
to tell what's happening with the client because there are very vague error
messages in the console :

Your input can't be opened:

VLC is unable to open the MRL 'rtsp://ubnt:admin@192.168.2.76:554/s1'.
Check the log for details.

^ This doesn't give the user a reason without looking deeper...

so we go on to enabling the environment variable to see what's going on :

export VLC_VERBOSE=3

Example:

[7fc288001850] main stream debug: connection succeeded (socket = 43)
[7fc288001850] main stream debug: net: opening 0.0.0.0 datagram port
9048
[7fc288001850] main stream debug: net: opening 0.0.0.0 datagram port
9049
[7fc29c002080] lua art finder debug: Trying Lua scripts in
/usr/share/vlc/lua/meta/art
[7fc29c002080] main art finder debug: no art finder modules matched
[7fc288001850] satip stream error: Failed to setup RTSP session
[7fc288001850] main stream debug: net: connecting to 192.168.2.76 port
554
[7fc288001850] main stream debug: connection succeeded (socket = 43)
[7fc288001850] access_realrtsp stream warning: Cseq mismatch, got 1,
assumed 0
[7fc288001850] access_realrtsp stream debug: rtsp connected

*[7fc288001850] access_realrtsp stream warning: only real/helix rtsp
servers supported for now*[7fc288001850] main stream debug: no access
modules matched
[5624f664e600] main playlist debug: dead input
[5624f6695330] qt interface debug: IM: Deleting the input
[5624f664e600] main playlist debug: changing item without a request
(current 1/2)
[5624f664e600] main playlist debug: nothing to play
[5624f6695330] qt interface debug: Video is not needed anymore


The bolded error message is, also, very vague.I need you to tell use which
codecs are rejected and WHY.  Please modify the error message to include
the set of rejected pieces of code, I might even suggest a quick link on
the topic.

Otherwise, since we're talking about free/non-free code, what parts need to
be written as free ?  I'd love to see it as a bounty, write it myself, or
post a bounty for it to be written.


Thanks,

Bryant Eadon
ᐧ

Bug#1031267: debmany: shell injection

[Salvatore Bonaccorso]

Control: retitle -1 debmany: CVE-2023-27635: shell injection

On Sun, Feb 19, 2023 at 05:47:20AM +0100, Axel Beckert wrote:
> Control: tag -1 + patch pending
> 
> Hi Jakub,
> 
> found time to analyse this closer.
> 
> Axel Beckert wrote:
> > Given that the full path including the exploit code is always shown to
> > the user before the exploit actually runs, I consider the impact
> > rather low:
> > 
> > ┌┤ Select a file (file:./injection.deb) 
> > ├┐
> > │   
> >  │
> > │  usr/share/doc/$(cowsay${IFS}pwned>/dev/tty;sleep${IFS}inf)/changelog.gz 
> > changelog.gz  │
> > │   
> >  │
> > │   
> >  │
> > │   
> >  │
> > └┘
> 
> And this even though $manpages (which holds a space separated list of
> all files to offer) is — on purpose — unquoted when passing to the
> selection program.
> 
> But the real culprit is the use of eval in lines 415, 422 and 424:
> 
>   414   debug "Opening manpage file: "`printf "$mancmdline" "$PWD/$file"` 
> # comment
>   415   eval $(printf "$mancmdline" "$PWD/$file")
>   416   cd - >/dev/null
>   417 else
>   418   # other file (usr/share/doc)
>   419   debug "Opening other file: "`printf "$othercmdline" 
> "$PWD/$return"` # comment
>   420   if [[ "$return" =~ \.gz$ ]]
>   421   then
>   422   eval $(printf "gzip -dc $PWD/$return | $othercmdline")
>   423   else
>   424   eval $(printf "$othercmdline" "$PWD/$return")
>   425   fi
> 
> Eval is evil. Once again.
> 
> My first thought was to just exclude all files with shell special
> characters, especially '$(' and friends. But
> 
>   apt-file search -n \$\( | fgrep /usr/share/doc/
> 
> shows that these are actually used (and fail with debmany due to the
> issue reported by Jakub):
> 
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Maths/hex$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/chr$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/insert$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/lCase$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/lTrim$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/left$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/mid$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/replace$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/replaceSubstr$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/reverse$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/right$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/space$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/str$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/string$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/trim$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/typeOf$().html
>   sdlbasic: 
> /usr/share/doc/sdlbasic/english/sections/commands/Strings/uCase$().html
> 
> Additionally there are tons of files with just $ or any kind of brackets.
> 
> Just quoting them "properly" inside the eval and printf won't help as
> you can always escape from there by just ending the according
> quotation by adding a closing quote character into your file path.
> 
> In case of the ".gz" case in your example, it's easier to fix as you
> can simply move "gzip -dc $PWD/$return |" out of the eval/printf.
> 
> But in the other cases it's less simple.
> 
> So I came up with the following fix which uses command instead of
> eval, and bash pattern substitution to replace %s with the file name
> instead letting printf inside an $() doing the substitution:
> 
> diff --git a/debmany/debmany b/debmany/debmany
> index 7eeb68b..dfea6e9 100755
> --- a/debmany/debmany
> +++ b/debmany/debmany
> @@ -96,6 +96,19 @@ Examples: debmany foo.deb  show manpages from a local 
> package file foo.deb
>fi
>  }
>  
> +replace_percent_s_and_execute() {
> +  replacement="$1"
> +  shift
> +  declare -a cmdarr
> +  cmdarr=($@)
> +  debug "cmdarr before; ${cmdarr[@]}"
> +  for i in ${!cmdarr[@]}; do
> +cmdarr[$i]="${cmdarr[$i]/\%s/$replacement}"
> +  done
> +  debug "cmdarr after; ${cmdarr[@]}"
> +  command "${cmdarr[@]}"
> +}
> +
>  while [ $# -gt 0 ]

Bug#1031905: riseup-vpn: fails to connect, when pressing cancel some the ui elements will dissapear.

[Nilesh Patra]

Hi Giorgos,

On 3/6/23 00:13, Giorgos wrote:

[...]


Thanks for providing me the answers to my questions.


$ riseup-vpn
[...]
2023/03/05 20:42:21 Error while running bitmask-root:
2023/03/05 20:42:21 args:  [/usr/sbin/bitmask-root firewall stop]


Looks like bitmask-root has some problems starting up. Could you please
provide me the output of these commands?

$ pkexec /usr/sbin/bitmask-root firewall stop
$ echo $?
$ pkexec /usr/sbin/bitmask-root firewall start 195.154.106.118 51.159.55.86 
163.172.90.118
$ echo $?

Please consider to get back to me soonish, as we (debian) are currently in 
freeze and it'd get
more difficult to do further changes going ahead.

Thank you!

Nilesh

Bug#1032402: calcurse: New upstream since 2022-04-16

[Nick Hastings]

Package: calcurse
Version: 4.6.0-2
Severity: normal
X-Debbugs-Cc: nicholaschasti...@gmail.com

Dear Maintainer,

unstable contains calcurse 4.7.1-1, howver a new version, 4.8.0 of
calcurse was released 11 months ago. Could the calcurse version in
Debian please be updated?

Thanks,

Nick.

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

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

Versions of packages calcurse depends on:
ii  libc6 2.31-13+deb11u5
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2
ii  python3   3.9.2-3

calcurse recommends no packages.

calcurse suggests no packages.

-- no debconf information

Bug#1032401: r8169 wired network stopped working: unknown chip XID 481, contact r8169 maintainers.

[Jimmy K.]

Package: src:linux
Version: 6.1.4-1
Severity: important
File: r8169.ko
X-Debbugs-Cc: ledecha...@gmail.com

Dear Maintainer,

   * What led up to the situation?
This chip was "known" and working before the update.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
sudo apt-get upgrade
   * What was the outcome of this action?
symphony kernel: [1.522054] r8169 :02:00.0: unknown chip XID 481,
contact r8169 maintainers (see MAINTAINERS file)
   * What outcome did you expect instead?
symphony kernel: [1.503167] r8169 :02:00.0 eth0: RTL8168f/8111f,
f8:0f:41:62:07:db, XID 481, IRQ 26
symphony kernel: [1.503175] r8169 :02:00.0 eth0: jumbo features
[frames: 9194 bytes, tx checksumming: ko]

To fix that you have to:
-get another computer
-get r8168-dkms from here:
https://packages.debian.org/sid/all/r8168-dkms/download
-transfer it to your computer with a usb stick or whatever
-install it, then, to be sure:
-sudo apt-mark hold r8168-dkms
-create "/etc/modprobe.d/blacklist-r8169"
-write "blacklist r8169" in it.
-reboot

Ta-da! LAN port lights up again.


-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 
root=UUID=f0756be9-fe79-4561-8595-8239d1d390a3 ro quiet video=1920x1080 
amdgpu.dc=1 amdgpu.ppfeaturemask=0x drm.edid_firmware=edid/edid.bin 
usbcore.autosuspend=0 usbcore.autosuspend_delay_ms=-1 
usb-storage.quirks=152d:0578:u quiet video=1920x1080 amdgpu.dc=1 
amdgpu.ppfeaturemask=0x drm.edid_firmware=edid/edid.bin 
usbcore.autosuspend=0 usbcore.autosuspend_delay_ms=-1 
usb-storage.quirks=152d:0578:u

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gateway
product_name: SX2380
product_version: 
chassis_vendor: Gateway
chassis_version: 
bios_vendor: American Megatrends Inc.
bios_version: P11-A1
board_vendor: Gateway
board_name: SX2380
board_version: 

** Loaded modules:
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
cfg80211
rfkill
qrtr
ip6t_REJECT
nf_reject_ipv6
xt_hl
cpufreq_conservative
ip6_tables
ip6t_rt
cpufreq_ondemand
cpufreq_powersave
cpufreq_userspace
xt_LOG
nf_log_syslog
ipt_REJECT
nf_reject_ipv4
nft_limit
xt_limit
xt_addrtype
xt_tcpudp
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_compat
sunrpc
nf_tables
libcrc32c
nfnetlink
binfmt_misc
edac_mce_amd
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
kvm_amd
snd_hda_intel
snd_intel_dspcfg
ccp
snd_intel_sdw_acpi
snd_hda_codec
rng_core
snd_hda_core
snd_hwdep
kvm
snd_pcm
snd_timer
sp5100_tco
irqbypass
evdev
pcspkr
k10temp
wmi_bmof
watchdog
snd
soundcore
amdgpu
button
acpi_cpufreq
sg
gpu_sched
drm_buddy
video
drm_display_helper
cec
rc_core
drm_ttm_helper
ttm
drm_kms_helper
i2c_algo_bit
it87
hwmon_vid
parport_pc
ppdev
lp
parport
drm
fuse
efi_pstore
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
ums_realtek
uas
usb_storage
crc32_pclmul
crc32c_intel
sd_mod
t10_pi
crc64_rocksoft_generic
crc64_rocksoft
crc_t10dif
crct10dif_generic
crct10dif_pclmul
crc64
crct10dif_common
ghash_clmulni_intel
sha512_ssse3
ata_generic
sha512_generic
ohci_pci
aesni_intel
xhci_pci
ahci
libahci
crypto_simd
pata_atiixp
xhci_hcd
cryptd
ohci_hcd
ehci_pci
ehci_hcd
libata
scsi_mod
usbcore
i2c_piix4
scsi_common
r8168(OE)
usb_common
wmi

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Complex [1022:1410]
DeviceName: Onboard Realtek LAN
Subsystem: Acer Incorporated [ALI] Family 15h (Models 10h-1fh) 
Processor Root Complex [1025:070a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1417] (prog-if 00 [Normal decode])
Subsystem: Acer Incorporated [ALI] Family 15h (Models 10h-1fh) 
Processor Root Port [1025:070a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:10.0 USB 

Bug#459260: slim: Should not be centered on two-screen setups

[Rob Pearce]

This bug is still present in all versions up to V1.4.0 from the fork 
project. There is an upstream ticket for it at 
https://sourceforge.net/p/slim-fork/tickets/3/


I've just committed a change upstream that should fix it for the next 
release.


Rob

--
Maintainer of the https://sourceforge.net/projects/slim-fork/;>SLiM Login 
Manager fork

Bug#1032104: linux: ppc64el iouring corrupted read

[Daniel Black]

Since revering to linux-image-5.10.0-20 we've been free of the same errors.

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[Gunnar Hjalmarsson]

James Addison wrote:

I agree that '@as []' is written to the 'xkb-options' config entry
momentarily after disabling the Compose Key.

However, a divergence/repro does appear (repeatably) on this system:

After logging out and back in again, the entry has been rewritten:

  $ dconf read /org/gnome/desktop/input-sources/xkb-options
  ['compose:lwin']


That indicates a problem with the ~/.config/dconf/user file, doesn't it? 
Maybe try to rename it to e.g. user.bak, relogin, and see how it behaves 
with a fresh ~/.config/dconf/user file.


--
Gunnar

Bug#1032400: virt-manager: Windows 11 VM starts to cause system lock-up after upgrading to Bookworm

[Xiyue Deng]

Package: virt-manager
Version: 1:4.1.0-2
Severity: important

Dear Maintainer,

I have been using a virt-manager created Windows 11 VM on Bullseye for a few
years without problem.  Recently after upgrading to Bookworm after soft freeze,
it starts to cause my system to freeze and it does not accept any input.  I've
also created a cronjob that checks for network access every 5 minutes and the
script stopped working once this happens, which kind of confirms that the system
is locked up.  The only way to solve this is to force shutdown and restart the
system.

Right be for I upgrade to Bookworm, I was using packages with the following 
versions:
* virt-manager 1:3.2.0-3
* qemu 7.1+dfsg~2-bpo11+3
* Linux kernel 5.19.11-1~bpo11+1

Now
* qemu 1:7.2+dfsg-4
(with other package versions below).

I'm not sure whether this is an issue of virt-manager, qemu-system, or a Linux
kernel.  Please help triage this issue, and I'm willing to provide more
information and test to further diagnose this as instructed.

Thanks in advance.


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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-vnc-2.0   1.3.1-1
ii  gir1.2-gtksource-4   4.8.4-4
ii  gir1.2-libosinfo-1.0 1.10.0-2
ii  gir1.2-libvirt-glib-1.0  4.0.0-2
ii  gir1.2-vte-2.91  0.70.3-1
ii  python3  3.11.2-1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
ii  python3-libvirt  9.0.0-1
ii  virtinst 1:4.1.0-2

Versions of packages virt-manager recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.92-1
ii  gir1.2-spiceclientglib-2.0   0.41-2
ii  gir1.2-spiceclientgtk-3.00.41-2
ii  libvirt-daemon-system9.0.0-1

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.20.5-3
ii  gnome-keyring42.1-1+b1
pn  python3-guestfs  
pn  ssh-askpass  
ii  virt-viewer  11.0-2

Versions of packages virt-manager is related to:
ii  libvirt-clients  9.0.0-1
ii  libvirt-daemon   9.0.0-1
ii  libvirt0 9.0.0-1
ii  osinfo-db0.20221130-2

-- no debconf information

Bug#1032399: linux-image-6.0.0-0.deb11.6-amd64: Please provide think-lmi.ko module.

[LeJacq, Jean Pierre]

Package: src:linux
Version: 6.0.12-1~bpo11+1
Severity: wishlist

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 ***


-- Package-specific info:
** Version:
Linux version 6.0.0-0.deb11.6-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP PREEMPT_DYNAMIC Debian 6.0.12-1~bpo11+1 (2022-12-19)

** Command line:
BOOT_IMAGE=/@/vmlinuz-6.0.0-0.deb11.6-amd64 
root=UUID=ce14d94e-5f4c-4b1e-9ba7-1f39243a40de ro rootflags=subvol=@ quiet

** Tainted: O (4096)
 * externally-built ("out-of-tree") module was loaded

** Kernel log:
[   39.729511] sof-audio-pci-intel-cnl :00:1f.3: firmware: direct-loading 
firmware intel/sof-tplg/sof-hda-generic-4ch.tplg
[   39.729517] sof-audio-pci-intel-cnl :00:1f.3: Topology: ABI 3:18:1 
Kernel ABI 3:23:0
[   39.729740] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not 
yet available, widget card binding deferred
[   39.812365] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC285: 
line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker
[   39.812368] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   39.812369] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   39.812370] snd_hda_codec_realtek ehdaudio0D0:mono: mono_out=0x0
[   39.812371] snd_hda_codec_realtek ehdaudio0D0:inputs:
[   39.812372] snd_hda_codec_realtek ehdaudio0D0:  Mic=0x19
[   39.947121] systemd-journald[971]: Received client request to flush runtime 
journal.
[   39.988802] audit: type=1400 audit(1678077048.865:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=1311 
comm="apparmor_parser"
[   39.989068] audit: type=1400 audit(1678077048.865:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1313 
comm="apparmor_parser"
[   39.989073] audit: type=1400 audit(1678077048.865:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=1313 
comm="apparmor_parser"
[   39.989075] audit: type=1400 audit(1678077048.865:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=1313 
comm="apparmor_parser"
[   39.989142] audit: type=1400 audit(1678077048.865:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1312 
comm="apparmor_parser"
[   39.989145] audit: type=1400 audit(1678077048.865:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=1312 comm="apparmor_parser"
[   39.990052] audit: type=1400 audit(1678077048.869:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=1321 
comm="apparmor_parser"
[   39.990538] audit: type=1400 audit(1678077048.869:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/freshclam" 
pid=1314 
comm="apparmor_parser"
[   39.990709] audit: type=1400 audit(1678077048.869:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=1316 
comm="apparmor_parser"
[   39.991069] audit: type=1400 audit(1678077048.869:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mysqld_akonadi" pid=1317 
comm="apparmor_parser"
[   40.315240] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   40.315244] Bluetooth: BNEP filters: protocol multicast
[   40.315249] Bluetooth: BNEP socket layer initialized
[   40.412458] loop: module loaded
[   40.412836] loop0: detected capacity change from 0 to 8
[   40.484966] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[   40.523267] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX 
overwritten
[   40.523273] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX 
overwritten
[   40.523387] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 
overwritten
[   40.523391] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 
overwritten
[   40.523394] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 
overwritten
[   40.523397] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Codec Output Pin1 overwritten
[   40.523400] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Codec Input Pin1 overwritten
[   40.523404] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Analog Codec Playback overwritten
[   40.523408] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Digital Codec Playback overwritten
[   40.523412] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt 
Analog Codec Playback overwritten
[   40.523416] skl_hda_dsp_generic 

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

[Todor Tsankov]

On 05/03/2023 20:11, Simon McVittie wrote:
> Control: reassign -1 src:mutter 43.3-4
> Control: affects -1 + gnome-shell
> 
> On Sun, 05 Mar 2023 at 18:23:06 +0100, Todor Tsankov wrote:
>> Since a recent update
> 
> gnome-shell 43.3-2 was only a translation update, so it's
> unlikely to be that.
> 
> Based on the timing of your report, this is probably a regression in
> mutter 43.3-4. Please look at /var/log/apt/history.log: what version of
> libmutter-11-0 would you have been using at the time you most recently
> restarted gnome-shell before this regression?
> 

I did some tests: the problem is present with mutter 43.3-4, 43.3-3, and
43.3-2 and also with gnome-shell 43.3-2 and 43.2-2. (I logged out and
back in between all tests.) So, basically, I have no idea when it
appeared. Maybe it is older and I just noticed it recently.

> Are you using gnome-shell in X11 mode ("GNOME on Xorg") or in Wayland mode?
> 

I am using Xorg. I tested with Wayland and there it works fine.

> 
>> I have the option "Switch input sources individually for each window"
>> set to "on"
> 
> If you turn off that option, does that make a difference?
> 

Yes, it does. If I turn it off, changing the layout works fine.

--Todor

Bug#1032398: xapian-core: Risk of database corruption on disk full

[Olly Betts]

Source: xapian-core
Version: 1.4.18-3
Severity: critical
Tags: patch upstream
Justification: causes serious data loss
Control: fixed -1 1.4.22-1

Xapian database corruption on disk full is possible.  It doesn't happen
in every case as ENOSPC needs to happen on a particular operation during
the commit but then not happen on a repeat attempt at that operation.
Filing systems with more complex freespace handling may be more
susceptible to this (it was reported on btrfs).

Only glass databases are affected - the commit code for the older chert
format is significantly different.

I've filed this with severity based on the worst case where the data in
the Xapian database is not simply an index of data from elsewhere.  This
is the situation for user-applied tags in notmuch, for example.  In many
cases the Xapian database is an index of data stored elsewhere so can be
recreated from scratch (albeit this may take some time).

This was fixed upstream in 1.4.22, which is the version now in unstable
and testing.  It looks like all previous 1.4.x releases are affected.
I'm intending to submit a stable update for this, and will see if the
LTS team are interested too.  The upstream patch is a single line
change:

https://git.xapian.org/?p=xapian;a=commitdiff;h=9f9aad17893bde4acb3a98e60dde397c346fcd9a

Details from upstream commit message:

If renaming to switch the new version file live fails (e.g. due to
ENOSPC) we discard the changes, try to write and switch to a different
new version file with an increased revision (on failure of this too we
close the database), and throw DatabaseError.

Unfortunately the roll-back of state is not complete, and if switching
to the different new version file succeeds that bad state persists on
disk.

Thanks to Uwe Kleine-König for reporting upstream and coming up with the
idea to reproduce using strace to inject a rename() failure - this is a
simple reproducer:

rm -rf enospc.db
strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db < 
INSTALL
xapian-check enospc.db

Cheers,
Olly

Bug#1022006: Acknowledgement (New version fixes a warning)

[Thomas Dickey]

- Original Message -
| From: "Bjarni Ingi Gislason" 
| To: 1022...@bugs.debian.org
| Cc: "Bjarni Ingi Gislason" 
| Sent: Sunday, March 5, 2023 4:24:44 PM
| Subject: Bug#1022006: Acknowledgement (New version fixes a warning)

| The new version did not fix the observed behaviour.

For the given bug-report, I don't recall any relevant changes.

-- 
Thomas E. Dickey 
https://invisible-island.net

Bug#1032397: lists.debian.org: Spam review offers already removed spam

[Guillem Jover]

Package: lists.debian.org
Severity: normal

When reviewing lists, I get offered to review messages that have
already been categorized as spam and removed from the archives, so
in review2.pl I see:

  ,---
  

  Spam message removed

  The spam message that used to be here has been removed.

  Return to the index of messages.
  `---

Because I have not seen the contents, I always leave it categorized
as "Unsure", and it disappears from the current review batch until the
site regenerates its indices (?) on the next Sunday. Then they reappear
again, potentially intermingled with fresh messages to review.

I'm always tempted to mark them as "Spam" to try to get them to go away,
but as that seems wrong, I never do that. :) Also because this seems like
something that should not be presented for review.

(I checked the bug list and while #678817 seemed similar, I don't
think it's the same, but then maybe I don't understand that report.)

Thanks,
Guillem

Bug#1032385: Acknowledgement (smtp: SSL_CTX_load_verify_locations: No such file or directory)

[Ryan Kavanagh]

Control: merge 1032384 1032385

On Sun, Mar 05, 2023 at 04:52:35PM +0100, Felix Dietrich wrote:
> Sorry, I accidentally sent the report twice (duplicate is #1032384 with
> a minor typo).  How do I fix this?

Using the merge command:
https://www.debian.org/Bugs/server-control#merge

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#1032396: build-rdeps does not work in bookworm

[Gioele Barabucci]

Package: devscripts
Version: 2.23.2

build-rdeps cannot read the source files currently distributed in 
bookworm. At the same time it works fine with sid.


To reproduce:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm main
deb-src http://deb.debian.org/debian/ bookworm main

$ build-rdeps --sudo --update systemtap
Hit:1 http://deb.debian.org/debian bookworm InRelease
Reading package lists... Done
W: http://deb.debian.org/debian/dists/bookworm/InRelease: The key(s) in 
the keyring /etc/apt/trusted.gpg.d/debian-archive-testing-stable.gpg are 
ignored as the file has an unsupported filetype.

build-rdeps: unable to find sources files.
Did you forget to run apt-get update (or add --update to this command)? 
at /usr/bin/build-rdeps line 520.


Regards,

--
Gioele Barabucci

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

[Guillem Jover]

On Sun, 2023-03-05 at 20:36:01 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 05:31:16PM +0100, Guillem Jover wrote:
> > The daily aide cron job warns that it cannot send mail as non-root
> > user. Was wondering why or how to change or workaround that, and saw
> > commit e82b5c9112d95b5c813ee29c3234733ae0f2c862, but it is not clear
> > why mail from non-root was disabled
> 
> See README.Debian.gz, chapter "Sending the report per mail" and re-open
> this bug if the explanation is not satisfactory. Documentation patch is
> appreciated.
> 
> tl;dr: suid root on /usr/lib/sendmail doesn't work when capsh is used.

See my earlier followup mail, it seems to be working for me though?
With bsd-mailx, exim4 (which is suid-root) and capsh installed. So
I'm not sure I'm doing something "wrong", or the case that's not
supposed to work is something else?

Thanks,
Guillem

Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message

[Felix Geyer]

On Sun, 05 Mar 2023 18:50:06 +0100 Arnout Vandecappelle 
 wrote:

This still fails to address the original issue: an irrelevant warning is 
printed when performing a fairly mundane thing (requesting a nonexistent 
timezone).


That part could be easily fixed. We can just remove the fallback from dateutil.tz.gettz() to 
get_zonefile_instance() since we know that the system database is available.



I repeat: I don't think anyone really wants to use the bundled database.


That's probably true but there are direct users of the dateutil.zoneinfo API which intrinsically 
uses the bundled database.


For example within Debian packages:
https://sources.debian.org/src/python-hypothesis/6.67.1-1/hypothesis-python/src/hypothesis/extra/dateutil.py/?hl=56#L56
https://sources.debian.org/src/python-sqlalchemy-utils/0.38.2-2/sqlalchemy_utils/types/timezone.py/?hl=44#L44

These are currently broken. Just silencing the warning will leave them broken.

We could patch the implementation to use the system database but that means deviating from the 
upstream behavior and carrying that patch forever.

The API even includes the metadata dictionary that would have to be faked as 
well:
https://sources.debian.org/src/python-dateutil/2.8.2-1/dateutil/zoneinfo/__init__.py/#L46

Therefore shipping the bundled zoneinfo tarball seems like the better solution 
to me.
The timezone database is clearly DFSG-free. We would have to repackage the upstream tarball to 
include the timezone database source though.

Thankfully upstream ships the script to (re-)generate the zoneinfo tarball.

Felix

Bug#961731: fixed

[Aurélien COUDERC]

control: fixed -1 0.19.0-5

Bug#1032395: Please make setting up regulators optional on sun50i_h6 platform

[harry88]

Package: arm-trusted-firmware
Version: 2.8.0+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

Commit fb23b104 to TF-A introduced setting up power regulators on the
H6. Unfortunately this broke Ethernet on some H6 boards such as the
Orange Pi One Plus and the Orange Pi 3, because the Ethernet PHY
requires certain regulators to be brought up together, not the way TF-A
does it.

For that reason, commit 67412e4d introduced a build option
SUNXI_SETUP_REGULATORS to be set to 0 for those boards. In that case
TF-A leaves the regulators alone and the kernel sets them up later. It's
documented in docs/plat/allwinner.rst.

Please could we introduce a subplatform of sun50i_h6 with the regulator
setup disabled, to allow Ethernet to work on those boards? I've included
a suggested patch below.

Thanks very much,
Harold.

diff --git a/debian/rules b/debian/rules
index 10bafab74..66ecf8bab 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,6 +25,13 @@ platforms_nodebug := sun50i_a64 imx8mq
 imx8mn_subplatforms := imx8mn imx8mn_uart4
 imx8mn_uart4_assigns := IMX_BOOT_UART_BASE=0x30a6

+# TF-A's regulator setup breaks Ethernet on some H6 boards,
+# so make it optional by having two subplatforms:
+#   * sun50i_h6: default configuration
+#   * sun50i_h6_leave_regulators: skip regulator setup
+sun50i_h6_subplatforms := sun50i_h6 sun50i_h6_leave_regulators
+sun50i_h6_leave_regulators_assigns := SUNXI_SETUP_REGULATORS=0
+
 # Always set CROSS_COMPILE, which also works for native builds.
 define build_platform
$(eval platform := $(1))

Bug#1022006: Acknowledgement (New version fixes a warning)

[Bjarni Ingi Gislason]

The new version did not fix the observed behaviour.

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

[Jon Beniston]

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)

Thanks.

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

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

Versions of packages libqt5positioning5-plugins depends on:
ii  libc6   2.31-13+deb11u4
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5dbus5 5.15.2+dfsg-9
ii  libqt5positioning5  5.15.2+dfsg-2
ii  libstdc++6  10.2.1-6

libqt5positioning5-plugins recommends no packages.

libqt5positioning5-plugins suggests no packages.

-- no debconf information

Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)

[Nicolas Schier]

On Thu 02 Mar 2023 10:39:45 GMT, Dr. Thomas Orgis wrote:
> I also sent this already directly to Joey, but later found this bug
> report. My take is this:
> 
> --- /usr/bin/ts   2019-02-20 22:03:31.0 +0100
> +++ ./ts  2023-03-01 21:06:41.177886024 +0100
> @@ -53,6 +53,7 @@
>  use strict;
>  use POSIX q{strftime};
>  no warnings 'utf8';
> +use open q{:locale};
>  
>  $|=1;
>  
> 
> This should ensure that the I/O is treated with the encoding indicated
> by the locale, be it UTF-8 or something else.

Thanks a lot!  I hope, Joey will pick this up, soon.

Kind regards,
Nicolas

-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#1032357: shorewall6: sysvinit script for Shorewall6 is broken

[Jeremy Sowden]

This has been fixed in the version of Shorewall in the upcoming release,
Bookworm.

J.


signature.asc
Description: PGP signature

Bug#1023700: Confirmed

[Guy Rutenberg]

On Fri, 24 Feb 2023 10:25:29 -0500 micah anderson  wrote:
>
> I've tried the same thing, and get the same results. It appears that the
> systemd support is there, the cryptsetup support is ithere, but just
> cryptsetup-initramfs is not somehow there also.

The old/regular cryptsetup is a different binary than the
systemd-cryptsetup. Only systemd-cryptsetup supports fido2 unlocking.

> It would be a shame to release bookworm with just the initramfs feature
> missing, when all the other pieces are there. Do you have any idea what
> might be blocking this?
>
> For what it is worth, dracut does work.
>

dracut works because it's based on systemd, so it uses systemd-cryptsetup.

See
https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/.

Thanks,
Guy

Bug#980087: release.debian.org: autopkgtest fails trying to install packages not in arch

[Paul Gevers]

Hi,

On Thu, 14 Jan 2021 12:08:20 +0100 Hans-Christoph Steiner  
wrote:

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


android-platform-art as this in debian/tests/control:
https://salsa.debian.org/android-tools-team/android-platform-art/-/blob/master/debian/tests/control

Tests: dexdump-dexlist
Depends: dexdump, dexlist


Which are stripped by dpkg when put in the Testsuite-Trigger field 
because they come from the source.



dexdump and dexlist are part of src:android-platform-art but are not
built for ppc64el.


Ack


britney should automatically know that Depends:
dexdump, dexlist cannot be fulfilled on ppc64el and skip the test.


But britney doesn't (in the current infrastructure) have that 
information, so it currently can't do that.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 

These dependencies were added upstream recently.

Signed-off-by: Alejandro Colomar 
Cc: Iker Pedrosa 
Cc: Serge Hallyn 
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 3cc66f8d..75015c35 100644
--- a/debian/control
+++ b/debian/control
@@ -11,11 +11,13 @@ Build-Depends: bison,
gettext,
itstool,
libaudit-dev [linux-any],
+   libbsd-dev,
libcrypt-dev,
libpam0g-dev,
libselinux1-dev [linux-any],
libsemanage-dev [linux-any],
libxml2-utils,
+   pkgconf,
quilt,
xsltproc
 Standards-Version: 4.6.1
-- 
2.39.2

Bug#1032393: [PATCH v2 1/2] debian/control: Sort alphabetically package lists

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 

Signed-off-by: Alejandro Colomar 
Cc: Iker Pedrosa 
Cc: Serge Hallyn 
---
 debian/control | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/debian/control b/debian/control
index 88198468..3cc66f8d 100644
--- a/debian/control
+++ b/debian/control
@@ -4,20 +4,20 @@ Uploaders: Balint Reczey ,
Serge Hallyn 
 Section: admin
 Priority: required
-Build-Depends: debhelper-compat (= 13),
-   gettext,
-   libcrypt-dev,
-   libpam0g-dev,
-   quilt,
-   xsltproc,
+Build-Depends: bison,
+   debhelper-compat (= 13),
docbook-xsl,
docbook-xml,
-   libxml2-utils,
+   gettext,
+   itstool,
+   libaudit-dev [linux-any],
+   libcrypt-dev,
+   libpam0g-dev,
libselinux1-dev [linux-any],
libsemanage-dev [linux-any],
-   itstool,
-   bison,
-   libaudit-dev [linux-any]
+   libxml2-utils,
+   quilt,
+   xsltproc
 Standards-Version: 4.6.1
 Vcs-Git: https://salsa.debian.org/debian/shadow.git -b master
 Vcs-Browser: https://salsa.debian.org/debian/shadow
@@ -43,8 +43,8 @@ Multi-Arch: foreign
 Essential: yes
 Pre-Depends: ${shlibs:Depends},
  ${misc:Depends},
- libpam-runtime,
- libpam-modules
+ libpam-modules,
+ libpam-runtime
 Breaks: hurd (<< 20140206~) [hurd-any]
 Conflicts: python-4suite (<< 0.99cvs20060405-1)
 Replaces: hurd (<< 20140206~) [hurd-any]
-- 
2.39.2

Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 
To: sub...@bugs.debian.org

Hi Balint,

This is my first patch set sent to Debbugs.  Let's see if I do it
correctly :).

I can't open a MR in Salsa, since my account is still to be approved
(I opened it yesterday).  BTW, if you have any contacts there, please
have a look at it; the identifier is 'alx' and the associated email is
.  I sent a mail to the Salsa admin a week ago but
received no response (but I guess they might be busy).

Cheers,

Alex

---

Alejandro Colomar (2):
  debian/control: Sort alphabetically package lists
  debian/control: Add libbsd-dev and pkg-config

 debian/control | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

Range-diff against v1:
-:   > 1:  3d079bd9 debian/control: Sort alphabetically package lists
1:  48ac3d10 ! 2:  9e323b50 debian/control: Add libbsd-dev and pkg-config
@@ debian/control: Build-Depends: bison,
 libselinux1-dev [linux-any],
 libsemanage-dev [linux-any],
 libxml2-utils,
-+   pkg-config,
++   pkgconf,
 quilt,
 xsltproc
  Standards-Version: 4.6.1
-- 
2.39.2

Bug#998105: Fix published (see pull request)

[Sven Geuer]

Hi Christian,

On Sun, 2023-03-05 at 19:18 +, c.bu...@posteo.jp wrote:
> Dear Sven,
> 
> this is one of the upstream maintainers (@buhtz).
> 
> Thanks a lot for your contribution. Keep in mind the the upstream PR
> isn't merged yet.
> 
> And wouldn't it be better to use the next upstream release instead of
> a Debian specific patch?

A new upstream release would definitely be the better approach.

> 
> We have no problem to prepare a upstream 1.3.4 if Jonathon (or Fabio)
> tell us that this is used for Debian 12 and not blocked because of
> the
> current freeze.
> 
> We'll wait for advice.

I just wanted to offer what I did anyway to test in Debian the changes
the PR would bring. Let's see how Jonathan (or Fabio) wants to proceed
with this bug.

Cheers,
Sven


-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1032256: blueman: auto-connect incomplete, needs additional "bluetoothctl connect " to work

[Christopher Schramm]

those protocols are completely run by the audio server, which in your 
case seems to be PipeWire. blueman does not have any stake in it.


Hi Christopher,

does that also apply to the creation of these missing nodes as reported 
back to bluetoothctl after the second connect command?


[Hama Freedom Light]# connect 3C:F8:A8:B9:CE:A1
Attempting to connect to 3C:F8:A8:B9:CE:A1
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
Connection successful
[CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: yes
[CHG] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0 Volume: 
0x0060 (96)


Yes, those BlueZ endpoints are ultimately provided by the audio server.

Bug#1032392: python3-scikit-rf: import fails: AttributeError: module 'collections' has no attribute 'Sequence'

[s3v]

Package: python3-scikit-rf
Version: 0.15.4-2
Severity: serious

Dear Maintainer,

This import fails in a sid chroot:

Python 3.11.2 (main, Feb 12 2023, 00:48:52) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from skrf import Network
Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python3/dist-packages/skrf/__init__.py", line 14, in 
   from . import frequency
 File "/usr/lib/python3/dist-packages/skrf/frequency.py", line 39, in 
   from .util import slice_domain,find_nearest_index
 File "/usr/lib/python3/dist-packages/skrf/util.py", line 289, in 
   class HomoList(collections.Sequence):
  
AttributeError: module 'collections' has no attribute 'Sequence'

Kind Regards

Bug#998105: Fix published (see pull request)

[c.buhtz]

On 2023-03-05 19:52 Sven Geuer  wrote:
> On Fri, 2023-03-03 at 01:46 +0100, BiT dev wrote:
> > [...]
> > https://github.com/bit-team/backintime/pull/1413
> > [...]
> 
> I created a patch to backintime 1.3.3-4 and tested it successfully.
> 
> Here is the merge request for a backintime 1.3.3-5:
> https://salsa.debian.org/jmw/pkg-backintime/-/merge_requests/9

Dear Sven,

this is one of the upstream maintainers (@buhtz).

Thanks a lot for your contribution. Keep in mind the the upstream PR
isn't merged yet.

And wouldn't it be better to use the next upstream release instead of a
Debian specific patch?

We have no problem to prepare a upstream 1.3.4 if Jonathon (or Fabio)
tell us that this is used for Debian 12 and not blocked because of the
current freeze.

We'll wait for advice.

Kind
Christian Buhtz

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

[Simon McVittie]

Control: reassign -1 src:mutter 43.3-4
Control: affects -1 + gnome-shell

On Sun, 05 Mar 2023 at 18:23:06 +0100, Todor Tsankov wrote:
> Since a recent update

gnome-shell 43.3-2 was only a translation update, so it's
unlikely to be that.

Based on the timing of your report, this is probably a regression in
mutter 43.3-4. Please look at /var/log/apt/history.log: what version of
libmutter-11-0 would you have been using at the time you most recently
restarted gnome-shell before this regression?

Are you using gnome-shell in X11 mode ("GNOME on Xorg") or in Wayland mode?

I can reproduce something similar in a test VM using gnome-text-editor
and gnome-terminal as my sample applications, but only in Xorg, not
in Wayland.

Upstream has been tracking some issues involving focus handling which are
probably related to this.

> I have the option "Switch input sources individually for each window"
> set to "on"

If you turn off that option, does that make a difference?

smcv

Bug#998105: Fix published (see pull request)

[Sven Geuer]

On Fri, 2023-03-03 at 01:46 +0100, BiT dev wrote:
> [...]
> https://github.com/bit-team/backintime/pull/1413
> [...]

I created a patch to backintime 1.3.3-4 and tested it successfully.

Here is the merge request for a backintime 1.3.3-5:
https://salsa.debian.org/jmw/pkg-backintime/-/merge_requests/9

Cheers,
Sven

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

[Jussi Pakkanen]

On Tue, 28 Feb 2023 at 22:44, Helmut Grohne  wrote:

> Would you agree to either include the PR in your upload or pass
> --debarch=$DEB_HOST_ARCH instead of --debarch=auto in debcrossgen?

Because of #1032168 the current priority is to get 1.0.1 to testing.
Thus I'm not going to do any changes to the packaging (apart from
fixing that one issue if needed) until that has happened. I'll
re-evaluate this once 1.0.1 is in testing.

Thanks,

Bug#944871: docbook-xsl: readds catalogs to the super catalog on every upgrade

[Abdelhakim Qbaich]

Hi,

I’ve looked at this tentatively and the issue is rather in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910841

As mentioned in a reply, 
https://lists.debian.org/debian-qa/2015/08/msg00015.html gives an overall plan 
of what needs to be done.

Abdelhakim

Bug#1021434: gnome-initial-setup: No current input method settings (ibus-mozc) in list (then default choise deletes current sources)

[Simon McVittie]

Control: tags -1 + moreinfo

On Sat, 08 Oct 2022 at 22:23:26 +0900, Hideki Yamane wrote:
> So, why there is no input method source as ibus-mozc on gnome-initial-setup?

I don't really know how Japanese input methods work, but I think this
could have been a combination of #1032382 (see
)
and #1029821 (see
).

On a test VM with en_GB.UTF-8 and ja_JP.UTF-8 locales, after upgrading
libgnome-desktop-4-2 to 43.2-2 to fix #1032382, and also upgrading
gnome-initial-setup to 43.2-3 to fix #1029821, I can run

/usr/libexec/gnome-initial-setup --existing-user

and select Japanese followed by Next.

In the next page, if I have ibus-mozc installed, I get Japanese (Mozc)
as the default.

If I have ibus-anthy but not ibus-mozc, I get Japanese (Anthy) as the
default instead.

I can't read Japanese, but if I run it as

LANG=ja_JP.UTF-8 LANGUAGE=ja_JP /usr/libexec/gnome-initial-setup 
--existing-user

I get one language option which looks like "日本語" in the default
list, and then in the next page, the default is either
"日本語 (Mozc)" or "日本語 (Anthy)", depending on whether I have
ibus-mozc installed or not. I think that means the right things are
now happening?

smcv

Bug#1032390: src:cppad: fails to migrate to testing for too long: FTBFS building arch:all

[Paul Gevers]

Source: cppad
Version: 2022.00.00.4-1
Severity: serious
Control: close -1 2023.00.00.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1027954

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:cppad has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build 
while building arch:all, which was reported in bug 1027954.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=cppad



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032166: do not release in bookworm

[Ana Guerrero Lopez]

On Fri, Mar 03, 2023 at 12:17:28AM +0100, Petter Reinholdtsen wrote:
> [Ana Guerrero Lopez]
> > Please, keep debian-timeline out of bookworm, the installed HTML doesn't
> > show the timeline like it should so the package is useless.
> 
> Are you talking about the issue in #655664?

Yes, that's one of the issues.

Ana

Bug#1030991: lintian: checking intel-mkl takes 18 hours

[Axel Beckert]

Hi Andreas,

Axel Beckert wrote:
> Andreas Beckmann wrote:
> > Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> > slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> > to check with
> >   lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> > on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).

Took about 4 hours here (with about the same specs, but a quite recent
CPU: i7-11700 with 8 cores, 16 threads, 64 GB RAM and all NVMe
storage, including /tmp/), but still far too long.

> I'll check if --perf-debug brings up anything helpful.

Here's the break down on any check that took more than 10 seconds,
sorted by Lintian check:

Binary checks:

Check binaries/corrupted for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2494.134s)
Check binaries/corrupted for binary:libmkl-interface-dev_2020.4.304-4_amd64 
done (104.566s)
Check binaries/corrupted for binary:libmkl-threading-dev_2020.4.304-4_amd64 
done (34.574s)
Check binaries/hardening for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2233.613s)
Check binaries/hardening for binary:libmkl-interface-dev_2020.4.304-4_amd64 
done (98.522s)
Check binaries/hardening for binary:libmkl-threading-dev_2020.4.304-4_amd64 
done (34.621s)
Check binaries/obsolete/crypt for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2206.171s)
Check binaries/obsolete/crypt for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (99.777s)
Check binaries/obsolete/crypt for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.487s)
Check libraries/static for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2176.996s)
Check libraries/static for binary:libmkl-interface-dev_2020.4.304-4_amd64 done 
(124.188s)
Check libraries/static for binary:libmkl-threading-dev_2020.4.304-4_amd64 done 
(38.784s)
Check libraries/static/link-time-optimization for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2062.453s)
Check libraries/static/link-time-optimization for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (106.561s)
Check libraries/static/link-time-optimization for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.848s)
Check libraries/static/no-code for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2209.059s)
Check libraries/static/no-code for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (128.671s)
Check libraries/static/no-code for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (42.731s)

Source check:

Check debian/control/field/rules-requires-root for 
source:intel-mkl_2020.4.304-4 done (499.496s)

So basically the long-taking tests all took about the same time for
each package. So I assume they all had the same issues for each
package, just to different amounts:

* 2000-2500s for libmkl-computational-dev
*  100-130s  for libmkl-interface-dev
*   30-45s   for libmkl-threading-dev

So I've ran Lintian under a profiler on the smallest of these
packages.

perl -d:NYTProf lintian/bin/lintian libmkl-threading-dev_2020.4.304-4_amd64.deb

And indeed, all three checks stayed approximately the same time in
Lintian::Index::Item::elf_by_member() which took up to 158 seconds
(under the profiler) in 162407 calls.

So if we want to speed up analysing binaries with large .a files (up
to 640 MB in this case), we should clearly speed elf_by_member().

And inside it, it's this line which took all but 1 second of it:

my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };

So basically copying data in RAM around seems to be the main cause for
taking so long on these binary packages.

Accordingly I've made this temporary local change to check what it
would be without copying around that data:

diff --git a/lib/Lintian/Index/Item.pm b/lib/Lintian/Index/Item.pm
index 7ef6c0994..87d766cbe 100644
--- a/lib/Lintian/Index/Item.pm
+++ b/lib/Lintian/Index/Item.pm
@@ -1434,9 +1434,10 @@ sub elf_by_member {
 return ();
 }
 
-my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
+#my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
 
-return \%copy;
+#return \%copy;
+return $self->index->elf_storage_by_member->{$self->name} // {};
 }
 
 =item pointer

(Patch and all tests based on the 2.116.3 release.) 

Not copying that data and just returning the original cuts the run
time down from 5m 7s to 1m 56s, i.e. by about 60%.

On the largest package (libmkl-computational-dev) it went down even a
much bigger percentage, from close to 3 hours (178 minutes) down to only 3
minutes and 32 seconds.

The question is now: Do we really need a separate copy of that data
for each call? Sure, if it's modified afterwards, this makes sense.
But I have no idea where this might happen.

So I've run the test suite on the above mentioned modification and to
my surprise it passed. 

Since the variable was explicitly called %copy, I'm sure, the copying
was on purpose. But which 

Bug#1032389: unblock: libdate-manip-perl/6.91-1

[gregor herrmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libdate-manip-p...@packages.debian.org, 
debian-p...@lists.debian.org
Control: affects -1 + src:libdate-manip-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdate-manip-perl/6.91-1 to unstable, and I think this
should go into bookworm. If I'm doing the math correctly, it won't
migrate before the start of the hard freeze and then needs a manual
review and unblock, as it's considered a key package.

6.91 is a bugfix release, it has only one small change but that one
fixes a bug:

#v+
commit e68bafb046aee9b34763b0e8207ce8359467b83a
Author: Sandi Wallendahl 
Date:   Thu Feb 23 17:52:14 2023 +0200

Check also the Alias hash from Zones.pm for the zone verification.

diff --git a/lib/Date/Manip/TZ.pm b/lib/Date/Manip/TZ.pm
index f2aad0f7b..0fb41287e 100644
- --- a/lib/Date/Manip/TZ.pm
+++ b/lib/Date/Manip/TZ.pm
@@ -762,7 +762,8 @@ sub _zoneinfo_file_name_to_zone {
my($file,$zoneinfo) = @_;
require File::Spec;
my $zone = File::Spec->abs2rel($file,$zoneinfo);
- -   return $zone  if (exists $Date::Manip::Zones::ZoneNames{lc($zone)});
+   return $zone  if (exists $Date::Manip::Zones::ZoneNames{lc($zone)} ||
+ exists $Date::Manip::Zones::Alias{lc($zone)});
return;
 }
#v-

That's https://github.com/SBECK-github/Date-Manip/pull/43


I'm attaching a stripped down debdiff with all relevant changes (the
rest are bumped versions and copyright years in each and every of the
upstream files).


unblock libdate-manip-perl/6.91-1


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmQE3W9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaclQ/+JOfMpUffQ02FC2ToXQ0ac6APplUw5Gy8fxJjGcWP9x8sW+EZMZUm2O81
je+WHkxcGoASQyK7IleK9hp+A7VQnSgDt2UvQbxhGfVO8bQrptgF0XxJ60EWMVDB
nzhrgcfei7Qhk51QOhm0HFvc5rHj+MECrCM0939sg03lz4z/Lomq6oHZwgYfo246
OmNhN9+2aE2HnLQit0McgFgx41IT8Uc4OkYsZ0mXC+pjjWEItHTxgUNf0pDFXBt4
VE1aZEcOTrS1QthMvpbp21FvO2FuSveE1d1PafgGQ3UNS65oTCXi+v9urLIsfTjk
JuRUTpoFzM1pY78HuMFuUT6UWIxG2H3MFNf8Ao1DJUH0Aj4/fKlJPJ7y8/8A+YDJ
+ymmi2EsMe2Nd9OmfvpLkFqyj9721veoxGMW4vmmZL5hfDPWal+AAyLy8fbVd7Ml
PloCYm4MngVAZWub1CmfKD8KfoQtej73i0fyZJnc+sDPh5x/8CfwwAGzaRE4b6J0
v6MmuddRT09Dn6TtaVhuECaBCDsTA4HtgiWOHJfU5YI0E4jzqnjHxIG5yVFh1Tvq
ZNq+JFrucjJ4oISWjjYb1USkqT8fpXBv54rLy2zs3Q5j+WoIvLxPljQrECOm4Yp7
tXC4Wf1ms10PcCeBBOmFFtvsmA/FZEknKsBeCD7sQol7bslMP3k=
=wHu2
-END PGP SIGNATURE-
diff -Nru libdate-manip-perl-6.90/Changes libdate-manip-perl-6.91/Changes
--- libdate-manip-perl-6.90/Changes 2022-12-02 18:58:17.0 +0100
+++ libdate-manip-perl-6.91/Changes 2023-03-01 17:56:24.0 +0100
@@ -15,6 +15,12 @@
 and that document should be considered the canonical source for all change
 related information.
 
+6.91  2023-03-01
+  -  Fixed bug where timezone alias wasn't handled
+ On linux systems configured to be in a timezone that is an alias,
+ the system timezone wasn't recognized, and it defaulted to GMT.
+ This is now fixed. Patch supplied by Sandi Wallendahl (GitHub #43)
+
 6.90  2022-12-02
   -  Time zone fixes
  Aliases in the tzdata database were not being added to the timezone
diff -Nru libdate-manip-perl-6.90/README.first 
libdate-manip-perl-6.91/README.first
--- libdate-manip-perl-6.90/README.first2022-03-02 21:19:25.0 
+0100
+++ libdate-manip-perl-6.91/README.first2023-03-01 17:55:59.0 
+0100
@@ -1,4 +1,4 @@
-Copyright (c) 1995-2022 Sullivan Beck. All rights reserved.
+Copyright (c) 1995-2023 Sullivan Beck. All rights reserved.
 This program is free software; you can redistribute it and/or
 modify it under the same terms as Perl itself.
 
diff -Nru libdate-manip-perl-6.90/debian/changelog 
libdate-manip-perl-6.91/debian/changelog
--- libdate-manip-perl-6.90/debian/changelog2022-12-03 18:44:50.0 
+0100
+++ libdate-manip-perl-6.91/debian/changelog2023-03-05 19:06:02.0 
+0100
@@ -1,3 +1,11 @@
+libdate-manip-perl (6.91-1) unstable; urgency=medium
+
+  * Import upstream version 6.91.
+  * Update years of upstream and packaging copyright.
+  * Declare compliance with Debian Policy 4.6.2.
+
+ -- gregor herrmann   Sun, 05 Mar 2023 19:06:02 +0100
+
 libdate-manip-perl (6.90-1) unstable; urgency=medium
 
   * Fix typo in changelog entry for 6.89-1.
diff -Nru libdate-manip-perl-6.90/debian/control 
libdate-manip-perl-6.91/debian/control
--- libdate-manip-perl-6.90/debian/control  2022-12-03 18:44:50.0 
+0100
+++ libdate-manip-perl-6.91/debian/control  2023-03-05 19:06:02.0 
+0100
@@ -9,7 +9,7 @@
 Build-Depends: debhelper-compat (= 13)
 Build-Depends-Indep: libtest-inter-perl (>= 1.09) ,
  perl
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Vcs-Browser: 

Bug#840888: Pre-ITA: a2ps

[Roland Rosenfeld]

Hi!

I think about adopting a2ps package.
My thoughts are not final (so this is not an ITA), but I want to let
you know that I started working on it (especially on an upgrade to
upstream alpha version 4.14.95).  I created an unofficial GIT repo for
this at https://salsa.debian.org/roland/a2ps (see especially the alpha
branch).

Greetings
Roland

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

[Guillem Jover]

Hi!

On Sun, 2023-03-05 at 17:31:16 +0100, Guillem Jover wrote:
> Package: aide
> Version: 0.18-2
> Severity: important

> The daily aide cron job warns that it cannot send mail as non-root
> user. Was wondering why or how to change or workaround that, and saw
> commit e82b5c9112d95b5c813ee29c3234733ae0f2c862, but it is not clear
> why mail from non-root was disabled, as I don't see why that would not
> work. In any case I did a local test in case there was something I was
> missing, with:
> 
>   # echo test | sudo -u _aide mail -s "test mail as aide user" root
> 
> And got a mail to root resembling this anonymized fragment:
> 
>   ,---
>   Date: Sun, 05 Mar 2023 17:23:07 +0100
>   From: Advanced Intrusion Detection Environment <_aide@$hostname>
>   To: root@$fqdn
>   Subject: test mail as aide user
>   Message-Id: <$msgid>
> 
>   test
>   `---
> 
> Could that check be removed to restore daily mails? Perhaps the
> intention was to disable that too for autopkgtests instead?

Ah, after pointing out the README.Debian on the other report, read
that, but it was still not clear why set-uid-root would be an issue,
as users should be able to send mails that way normally.

Rechecking this, I guess the problem might have been with the capsh
call, but just tested to make sure and it seems to work, and it seems
to be adding the required POSIX capabilities to the invocation?
Disabling the non-root check on the system and directly invoking the
cron.daily script correctly sends the mail, and also the following two
test programs send a correct mail too (while using exim4 and capsh):

  ,--- send-mail ---
  #!/bin/sh
  echo "test body" | mail -s "test sending mail as non-root" root
  `---

  ,--- exec-mail ---
  #!/bin/sh
  capsh --caps="cap_dac_read_search,cap_audit_write+eip 
cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user=_aide 
--addamb=cap_dac_read_search,cap_audit_write -- -c "./send-mail"
  `---

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.

Thanks,
Guillem
From 6a48f5666b7cc24e991509366570592136c277a5 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 5 Mar 2023 18:47:30 +0100
Subject: [PATCH] Do not prevent using mail(1) from non-root

Closes: #1032387
---
 debian/aide-common.README.Debian | 10 +-
 debian/bin/dailyaidecheck|  9 ++---
 2 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/debian/aide-common.README.Debian b/debian/aide-common.README.Debian
index b7a8ef8..a2a7d66 100644
--- a/debian/aide-common.README.Debian
+++ b/debian/aide-common.README.Debian
@@ -125,9 +125,6 @@ If neither is the case, aide runs as root. A non-root aide is
 augmented with the cap_dac_read_search capability which allows the
 non-root user to read anywhere.
 
-Running aide as non-root also affects the daily aide check to send out
-mail. See below for details.
-
 A significant part of the shell scripts that surround the aide calls
 in Debian will still run as root.  Patches accepted.
 
@@ -224,12 +221,7 @@ if systemd is used or is sent via e-mail by the cron daemon). Set
 SILENTREPORTS=yes to confirm that you really want the daily aide check
 to be silent. Logs are written in either case.
 
-Some implementations of mail(1) use /usr/lib/sendmail to deliver the
-outgoing message. /usr/lib/sendmail is suid root with some MTAs, and
-this way of privilege escalation is not available when the daily aide
-job is invoked as non-root user.
-
-Hence, the script prefers using s-nail to send out the message via
+The script prefers using s-nail to send out the message via
 SMTP to localhost. A working MTA is expected on localhost. With
 s-nail, an unqualified recipient address is qualified with the
 contents of /etc/mailname to make it acceptable over SMTP.
diff --git a/debian/bin/dailyaidecheck b/debian/bin/dailyaidecheck
index b5b2ac7..f24e9b9 100755
--- a/debian/bin/dailyaidecheck
+++ b/debian/bin/dailyaidecheck
@@ -118,13 +118,8 @@ elif command -v s-nail >/dev/null; then
 MAILTO="${MAILTO}@${MAILNAME:-localhost}"
 fi
 elif command -v mail >/dev/null; then
-if [ "$(id -u)" -eq 0 ]; then
-# we have root and mail(1) is useable
-MAILCMD="mail"
-else
-MAILCMD="true"
-printf >&2 "WARN: it is not possible to use mail(1) unless aide is run as root\n"
-fi
+# we use mail(1)
+MAILCMD="mail"
 else
 MAILCMD="true"
 printf >&2 "WARN: mail or s-nail not installed, cannot send mail\n"
-- 
2.39.2

Bug#1032223: fbb: Segmentation fault when listing subdirectories using FBBDOS

[tony mancill]

On Sat, Mar 04, 2023 at 11:37:38AM -0800, tony mancill wrote:
> > > Revised 05-fix-compile-warnings patch attached.
> > > 
> > > —
> > > Mike Quin
> > > <05-fix-compile-warnings>
> 
> So I think their deletion in the prior patch was inadvertent and the
> patch is good.  I can commit and upload if that's helpful.

I went ahead with the upload and pushed to the packaging repo.

Cheers,
tony


signature.asc
Description: PGP signature

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

[Todor Tsankov]

Package: gnome-shell
Version: 43.3-2
Severity: important

Dear Maintainer,

Since a recent update, switching keyboard layouts from the menu in the
topbar (clicking the language symbol in the topbar and choosing a
keyboard layout) does not work any more, i.e., the action has no effect.
Switching layouts works fine with the keyboard shortcut as well as with
the mouse in the overview.

I have the option "Switch input sources individually for each window"
set to "on" and I am using three different keyboard layouts. I have also
disabled all gnome-shell extensions to test this.

Another related problem is that if the current window and the overview
are using different keyboard layouts, the animation for switching to the
overview visibly stutters.

This worked fine before the update.

Best wishes,
Todor


-- 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/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.3-4
ii  gir1.2-nm-1.01.42.0-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.5-1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.3-2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-1
ii  libedataserver-1.2-273.46.4-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.5-1
ii  libglib2.0-bin   2.74.5-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.36-4
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.3-4
ii  libnm0   1.42.0-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  122-3
ii  libpolkit-gobject-1-0122-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.20.5-3
ii  libsystemd0  252.5-2
ii  libwayland-server0 

Bug#967010: Un Switch perdu dans l'avion

[bakhti sarra]

Bonjour je suis Madame bakhti sarra

Je viens oublié un Nintendo switch dans l'avion numéro AH1004  air Algérie 
merci si vous l'avez trouvé me contacter 0769555188 merci
Cordialement

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/221

On Sat, 04 Mar 2023 at 14:42:06 +0900, Hideki Yamane wrote:
> On Thu, 2 Mar 2023 09:42:36 +
> Simon McVittie  wrote:
> > Is there consensus among Japanese-speaking users of Debian that mozc is
> > a better default for all Japanese speakers, including new users who are
> > not familiar with GNOME or Debian?
...
> > Please talk to upstream about this: if mozc is a better default for Debian,
> > then it's probably also a better default for upstream.
> 
>  Okay, I'll do.

I've opened https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/221,
please follow up there with more information.

smcv

Bug#1025239:

[Md Mohon]

Hi

Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message

[Arnout Vandecappelle]

James Addison  schreef op 5 maart 2023 17:24:58 CET:
>Followup-For: Bug #1003044
>
>On Tue, 21 Feb 2023 14:46:01 -0500, morph wrote:
>> On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer  wrote:
>> > How exactly does this break matplotlib?
>> it produces output on stderr, which many tools consider it an error
>> and fails build.

Please take note of this: matplotlib does *not* use the bundled database, it 
just asks for a timezone.


>
>On Fri, 3 Mar 2023 15:05:03 -0500, morph wrote:
>> Either we reintroduce the timezone file (that may not be a good idea)
>> or translate these deprecated APIs into the recommended one, or we do
>> something else entirely, it's up for debate.
>
>On Sun, 05 Mar 2023 15:37:43 +0100, Arnout wrote:
>>  AFAICS, the API is not deprecated. It is also not really broken. Is just 
>> that if you ask explicitly for the bundled database, you get an empty 
>> database. Currently, you get an empty database and a warning is printed; my 
>> patch just removes that warning.
>
>This isn't ideal, but if we're not comfortable bundling the database or coding
>a compatibility interface... perhaps helping people to fix the warnings in
>their own environments (re: stderr) could be a next-best-option?
>
>
>We could extend the warning messaging; something like:
>
>  "An error occurred while attempting to read {0}.\n"
>  +
>  "To resolve this warning, please ensure that a dateutil-compatible timezone "
>  "data tarball exists and is readable at {1}.\n"
>  +
>  "Note: an empty tarball is considered valid and will silence this warning, "
>  "but you should check the code path(s) that emitted these warnings before "
>  "supplying that, since it will not provide any timezone information."
>
>
>The intended effect of that would be:
>
>  * Do not hide that a failure occurred
>  * Provide more explanation about what went wrong
>  * Provide solution options to sysadmin (although sometimes user != sysadmin)
>  * Attempt to use messaging that python-dateutil upstream could merge

This still fails to address the original issue: an irrelevant warning is 
printed when performing a fairly mundane thing (requesting a nonexistent 
timezone).

I repeat: I don't think anyone really wants to use the bundled database.

Regards,
Armour

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

[Guillem Jover]

On Sun, 2023-03-05 at 17:18:00 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:
> > Package: aide
> > Version: 0.18-2
> > Severity: serious
> 
> Justification?

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.

> > This specific system is using sysvinit. Checking the postinst I notice
> > it is conditionally using systemd-sysusers if available, but then
> > unconditionally tries to chown files and does not fail if it cannot
> > perform the operation.
> 
> Yes, that is expected, please see
> /usr/share/doc/aide-common/README.Debian.gz and consider sending a
> tested patch.

Ah, ok thanks. I'm attaching the patch that I've prepared, I'll be
testing it later today. Let me know if you see any issue with its
direction, and I'm happy to amend stuff.

> > So ideally this would get adduser support, and depend on either that
> > or systemd-standalone-sysusers.
> 
> It is my intention to have aide degrade gracefully to using root on
> non-systemd systems,

I did have libcap2-bin installed so I guess that's why it broke these
expectations.

> since non-systemd users obviously dont care much about security.

(This seems like a gratuitous comment, but it does not seem productive
to get into this.)

Thanks,
Guillem
From 2f394a8b1e24b1bd0cef22cb2891c69f07820643 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 5 Mar 2023 18:16:17 +0100
Subject: [PATCH] Fix _aide user handling

Add dependencies on adduser | systemd-sysusers to guarantee either of
the commands are around and the user can be created.

Add libcap2-bin to aide-common Recommends so that it is obvious it will
be optionally used.

Call adduser to create the user, by using the old options to guarantee
smooth partial upgrades, as a versioned dependency would not guarantee
the options are around given the alternative dependency.

We also need to fix the ownership of the aideinit.* log files, and update
the version where all ownership and permissions get applied to the
current version, otherwise with a previous version where the user was
not created these will remain with the wrong metadata.

Closes: #1032381
---
 debian/aide-common.postinst | 11 +--
 debian/control  |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/debian/aide-common.postinst b/debian/aide-common.postinst
index 6cf4be6..05f7eed 100755
--- a/debian/aide-common.postinst
+++ b/debian/aide-common.postinst
@@ -42,16 +42,23 @@ esac
 SRCDIR="/usr/share/$PKGNAME/config"
 TRGDIR="/etc"
 
-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
 
 # 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
 # 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
 fi
diff --git a/debian/control b/debian/control
index 4730c43..c7a8438 100644
--- a/debian/control
+++ b/debian/control
@@ -49,8 +49,10 @@ Architecture: all
 Depends: aide (>= 0.17),
  liblockfile1,
  ucf (>= 2.0020),
+ adduser | systemd-sysusers,
  ${misc:Depends}
 Recommends: cron,
+ libcap2-bin,
  bsd-mailx | mailx | s-nail
 Description: Advanced Intrusion Detection Environment - Common files
  AIDE is an intrusion detection system that detects changes to files on
-- 
2.39.2

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Simon McVittie]

On Mon, 06 Mar 2023 at 00:12:38 +0900, YOSHINO Yoshihito wrote:
> Anyway, I have just updated the patch to limit architectures.

I don't think that version would be accepted upstream, because having
a compile-time option per locale for the default input method wouldn't
scale well at all, and GNOME generally prefers having a correct default
rather than a "fix my desktop" option.

Also, I don't think we want to have to update gnome-desktop every time mozc
is changed to compile successfully on an additional architecture.

I'm testing a patch to do this as a runtime rather than compile-time
switch, so that we can use mozc-jp if that's installed, or anthy if not:
if we're doing a Debian-specific patch *anyway*, then that seems more like
what we want.

smcv

Bug#1032383: [Pkg-utopia-maintainers] Bug#1032383: loopback interface (lo) no longer ignored

[Michael Biebl]

Hi

Am 05.03.23 um 16:38 schrieb Didier 'OdyX' Raboud:

This is apparently a new feature of NM 1.42, but I'm arguing that in
most usual cases, having 'lo' appear (as it appears in KDE's Plasma NM
applet for example) is quite confusing to most users who will never
customize anything with regards to the 'lo' interface.


GNOME and nm-applet do not present the loopback device in the UI.
Maybe plasma-nm should do the same?

I'm perfectly fine with it being shown in nmcli, fwiw.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Simon McVittie]

On Sun, 05 Mar 2023 at 15:49:51 +0100, Martin Steigerwald wrote:
> Simon McVittie - 05.03.23, 12:58:48 CET:
> > How is your `dbus-daemon --session` process started? Is it started by
> > /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching?
> > What is its current working directory?
> 
> It seems to be run with:
> 
> % cat run
> #!/usr/bin/env /lib/runit/invoke-run
> #Copyright: 2022-2023 Lorenzo Puliti <[…]>

This script does not start a session bus (notice the --system argument and
the absence of a --session argument):

> exec dbus-daemon --system --nofork --nopidfile

so it would be incorrect for $DBUS_SESSION_BUS_ADDRESS to point to
the socket it is listening on (which should be /run/dbus/system_bus_socket
rather than /tmp/anything).

This looks like a runit-specific script to start the *system* bus: a
runit equivalent of the /lib/systemd/system/dbus.service and
/etc/init.d/dbus in the dbus package.

The system bus, `dbus-daemon --system`, is a system-wide bus (one per
machine) for system services like elogind, polkit and NetworkManager. The
session bus, `dbus-daemon --session`, is a per-session bus (one per
X11 session or one per (machine,uid) pair) for per-user services like
kwallet. They're implemented by running the same code with different
configuration, but they are not interchangeable. Practical desktop
systems need both.

> % ps aux | grep "[d]bus"

If you were using systemd I'd suggest using systemd-cgls to get a logical
overview of how the various processes in the system fit together. There's
an obvious flaw in that suggestion for a runit user, but perhaps the
non-default-init community has something equivalent that can keep track of
how processes relate to each other even in the presence of daemonization?

> sddm  6587  0.0  0.0   6652  2316 ?SMär04   0:00 dbus-launch 
> --autolaunch 3d6f92a09aa53b38614887db63ce99a6 --binary-syntax --close-stderr
> sddm  6614  0.0  0.0   4404  2128 ?Ss   Mär04   0:00 
> /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 
> --session

You are correct to say that those two are unlikely to be involved in
the issue you reported, because this is the per-user or per-X11-display
session bus for uid "sddm", and is not involved with the management of
per-user processes for uid "martin".

The arguments passed to sddm's dbus-launch are consistent with it having
been started by X11 autolaunching by some sddm component.

I suspect that this means sddm's login screen is implemented as a
miniature version of an ordinary X11 GUI session, with some special
settings to make it behave differently. It's a reasonable design to use,
and the "greeter" in GNOME's gdm behaves similarly.

> martin9106  0.0  0.0   6740  2424 ?SMär04   0:00 
> /usr/bin/dbus-launch --exit-with-session --sh-syntax
> martin9107  0.0  0.0   7096  4696 ?Ss   Mär04   0:12 
> /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session

*Those* look like the implementation of your per-user or
per-X11-display session bus for uid "martin". I can't tell how they
were started (and it's up to you to find out), but the arguments
that were passed to dbus-launch are the same ones it would get from
/etc/X11/Xsession.d/75dbus_dbus-launch, and the consecutive process IDs
are reasonably strong evidence that dbus-daemon process 9107 was started
by dbus-launch process 9106 (or at least around the same time).

/etc/X11/Xsession.d/75dbus_dbus-launch inherits its execution environment
from whatever component runs the Xsession script (often a display manager,
and in your case presumably sddm). If you want "session stuff" to be
started with your home directory as the current working directory, then
making sure the Xsession script runs with that same working directory
is a good idea.

Editing or adding some scripts in Xsession.d so they write their current
working directory and other relevant information to the system log using
logger(1) might be a good direction for debugging this.

> > On a non-systemd-based system, when not using dbus-user-session, or
> > for a session service that does not have a corresponding
> > SystemdService, the dbus-daemon forks and execs the service as a
> > child process (or it might be a "daemonized" grandchild process, it's
> > a while since I looked at that code path). The session service will
> > probably inherit the dbus-daemon's current working directory,
> > whatever that happens to be.
> 
> I just wonder how that worked out in pre-systemd times in Debian. Cause
> KRunner definitely did not have "/" as its current working directory at the
> time.

Perhaps you could bring up a pre-systemd Debian system (wheezy or older)
in a VM, and find out? An older live-CD image is probably the easiest
way, since that avoids the need to have a working mirror for EOL suites
that were moved to archive.debian.org already.

(Of course, pre-systemd Debian systems booted with sysv-rc and sysvinit,
so 

Bug#1032256: blueman: auto-connect incomplete, needs additional "bluetoothctl connect " to work

[Alf]

Am 04.03.23 um 23:08 schrieb Christopher Schramm:

Hi Alf,

those protocols are completely run by the audio server, which in your case 
seems to be PipeWire. blueman does not have any stake in it.


Hi Christopher,

does that also apply to the creation of these missing nodes as reported back to 
bluetoothctl after the second connect command?

[Hama Freedom Light]# connect 3C:F8:A8:B9:CE:A1
Attempting to connect to 3C:F8:A8:B9:CE:A1
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
Connection successful
[CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: yes
[CHG] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0 Volume: 0x0060 
(96)

If yes, could you please assign/move this bug to pipewire

Regards, Alf

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

[Guillem Jover]

Package: aide
Version: 0.18-2
Severity: important

Hi!

The daily aide cron job warns that it cannot send mail as non-root
user. Was wondering why or how to change or workaround that, and saw
commit e82b5c9112d95b5c813ee29c3234733ae0f2c862, but it is not clear
why mail from non-root was disabled, as I don't see why that would not
work. In any case I did a local test in case there was something I was
missing, with:

  # echo test | sudo -u _aide mail -s "test mail as aide user" root

And got a mail to root resembling this anonymized fragment:

  ,---
  Date: Sun, 05 Mar 2023 17:23:07 +0100
  From: Advanced Intrusion Detection Environment <_aide@$hostname>
  To: root@$fqdn
  Subject: test mail as aide user
  Message-Id: <$msgid>

  test
  `---

Could that check be removed to restore daily mails? Perhaps the
intention was to disable that too for autopkgtests instead?

Thanks,
Guillem

Bug#1031677: More information -- problem specifying ext4 as the chroot-filesystem

[Chris Ward]

I can reproduce the problem with just lb commands.

lb config --distribution=bookworm --chroot-filesystem=ext4

lb build

shows the problem, but if I remove the "--chroot-filesystem=ext4" (to 
give me a squashfs root file system) the build runs to its normal 
completion.



When it fails, the build gives a message

ln: failed to create symbolic link '/etc/mtab': File exists


Chris Ward

Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message

[James Addison]

Followup-For: Bug #1003044

On Tue, 21 Feb 2023 14:46:01 -0500, morph wrote:
> On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer  wrote:
> > How exactly does this break matplotlib?
> it produces output on stderr, which many tools consider it an error
> and fails build.

On Fri, 3 Mar 2023 15:05:03 -0500, morph wrote:
> Either we reintroduce the timezone file (that may not be a good idea)
> or translate these deprecated APIs into the recommended one, or we do
> something else entirely, it's up for debate.

On Sun, 05 Mar 2023 15:37:43 +0100, Arnout wrote:
>  AFAICS, the API is not deprecated. It is also not really broken. Is just 
> that if you ask explicitly for the bundled database, you get an empty 
> database. Currently, you get an empty database and a warning is printed; my 
> patch just removes that warning.

This isn't ideal, but if we're not comfortable bundling the database or coding
a compatibility interface... perhaps helping people to fix the warnings in
their own environments (re: stderr) could be a next-best-option?


We could extend the warning messaging; something like:

  "An error occurred while attempting to read {0}.\n"
  +
  "To resolve this warning, please ensure that a dateutil-compatible timezone "
  "data tarball exists and is readable at {1}.\n"
  +
  "Note: an empty tarball is considered valid and will silence this warning, "
  "but you should check the code path(s) that emitted these warnings before "
  "supplying that, since it will not provide any timezone information."


The intended effect of that would be:

  * Do not hide that a failure occurred
  * Provide more explanation about what went wrong
  * Provide solution options to sysadmin (although sometimes user != sysadmin)
  * Attempt to use messaging that python-dateutil upstream could merge

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:
> Package: aide
> Version: 0.18-2
> Severity: serious

Justification?

> This specific system is using sysvinit. Checking the postinst I notice
> it is conditionally using systemd-sysusers if available, but then
> unconditionally tries to chown files and does not fail if it cannot
> perform the operation.

Yes, that is expected, please see
/usr/share/doc/aide-common/README.Debian.gz and consider sending a
tested patch.

> So ideally this would get adduser support, and depend on either that
> or systemd-standalone-sysusers.

It is my intention to have aide degrade gracefully to using root on
non-systemd systems, since non-systemd users obviously dont care much
about security.

Greetings
Marc

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Daniel Kahn Gillmor]

On Fri 2023-03-03 21:01:58 +0100, Salvatore Bonaccorso wrote:
> DSA 5368-1 is released with your update. Thank you!
>
> On a related note: I saw the 4.10-1 upload, but wouldn't it have been
> better to make first 4.9-2 move to bookworm? Can you get in touch with
> the release team so that the fix enters as well bookworm asking for an
> unblock?

Unfortunately, libreswan isn't going to migrate into bookwork at all
until nspr resolves #854472, due to FTBFS on mipsel.  About 11 days ago
i uploaded the fix for nspr to DELAYED/15, due to lack of feedback from
anyone maintaining nspr in Debian about whether it would be acceptable.

There has since been movement on the patch to resolve it in upstream
nspr (including attention from Mike Hommey, who has been maintaining it
in Debian), so i guess his plan is either to get nspr to explicitly
adopt the fix befoe shipping it in debian, or maybe to get more feedback
about it from other upstream folks.

I welcome any other suggestions about how to move forward too!

  --dkg


signature.asc
Description: PGP signature

Bug#1032386: ITP: libaribcaption -- portable caption decoder / renderer for handling ARIB STD-B24 based TV broadcast captions

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-de...@lists.debian.org, sramac...@debian.org

* Package name: libaribcaption
  Version : 1.0.0
* URL : https://github.com/xqq/libaribcaption
* License : MIT
  Programming Lang: C++
  Description : portable caption decoder / renderer for handling ARIB 
STD-B24 based TV broadcast captions

>From upstream:

libaribcaption provides decoder and renderer for handling ARIB STD-B24
based broadcast captions, making it possible for general players to
render ARIB captions with the same effect (or even better) as
Television.

libaribcaption is written in C++17 but also provides C interfaces to
make it easier to integrate into video players. It is a lightweight
library that only depends on libfreetype and libfontconfig in the worst
case.


Cheers
-- 
Sebastian Ramacher

Bug#1032385: Acknowledgement (smtp: SSL_CTX_load_verify_locations: No such file or directory)

[Felix Dietrich]

Sorry, I accidentally sent the report twice (duplicate is #1032384 with
a minor typo).  How do I fix this?
-- 
Felix Dietrich

Bug#1032385: smtp: SSL_CTX_load_verify_locations: No such file or directory

[Felix Dietrich]

Package: opensmtpd
Version: 6.8.0p2-3
Severity: normal
Tags: patch

On Debian Bullseye attempting to send a test mail from the command line
using the “smtp” program included in the “opensmtpd” package results in
the error message:

smtp: SSL_CTX_load_verify_locations: No such file or directory

The cause of this error message is a missing “/usr/lib/ssl/cert.pem”
file, which was, according to its changelog, only added to the “openssl”
package in version 3.0.5-3 [1]; this version is not available in the stable
archive.  The path “/usr/lib/ssl/cert.pem” is passed to
“SSL_CTX_load_verify_locations in “smtpc.c:145” (it is the result of the
call to “X509_get_default_cert_file” [2]):

if (!SSL_CTX_load_verify_locations(ssl_ctx,
X509_get_default_cert_file(), NULL))
fatal("SSL_CTX_load_verify_locations");

One solution to this issue would be to backport the addition of the
“/usr/lib/ssl/cert.pem” symlink to the “openssl” package to the older
version available in stable.  This would likely also require an
additional dependency on the “ca-certificates” package so that the
symlink “/usr/lib/ssl/cert.pem” to “/etc/ssl/certs/ca-certificates.crt”
can actually be correctly resolved to a file.  For this solution,
presumably, a bug report against the “openssl” has to be created.

Another solution would call instead of “SSL_CTX_load_verify_locations”
the function “SSL_CTX_set_default_verify_paths” as it does not consider
missing default locations an error [3].  It also has the advantage of
allowing the user to customise the certificates used by setting the
environment variables SSL_CERT_DIR and SSL_CERT_FILE.  For this solution
I have attached a patch.

Footnotes:
[1]  openssl (3.0.5-3) unstable; urgency=medium

   * Add cert.pem symlink pointing to ca-certificates' ca-certificates.crt
 (Closes: #805646).
   * Compile with OPENSSL_TLS_SECURITY_LEVEL=2 (Closes: #918727).

  -- Sebastian Andrzej Siewior   Sun, 18 Sep 2022 
21:48:05 +0200

[2]  Compilation of this mini program to print the default certificate
 file requires linking against libcrypto
 (gcc src.c -o print_cert_file -lcrypto):

 #include 
 #include 

 #include 

 int main(int argc, char *argv[])
 {
 printf("%s\n", X509_get_default_cert_file());
 return EXIT_SUCCESS;
 }

[3]  



Index: opensmtpd-6.8.0p2/usr.sbin/smtpd/smtpc.c
===
--- opensmtpd-6.8.0p2.orig/usr.sbin/smtpd/smtpc.c	2020-12-24 14:42:21.0 +0100
+++ opensmtpd-6.8.0p2/usr.sbin/smtpd/smtpc.c	2023-03-05 12:49:26.390962737 +0100
@@ -142,9 +142,8 @@
 	event_init();
 
 	ssl_ctx = ssl_ctx_create(NULL, NULL, 0, NULL);
-	if (!SSL_CTX_load_verify_locations(ssl_ctx,
-	X509_get_default_cert_file(), NULL))
-		fatal("SSL_CTX_load_verify_locations");
+	if (!SSL_CTX_set_default_verify_paths(ssl_ctx))
+		fatal("SSL_CTX_set_default_verify_paths");
 	if (!SSL_CTX_set_ssl_version(ssl_ctx, SSLv23_client_method()))
 		fatal("SSL_CTX_set_ssl_version");
 	SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE , NULL);

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Jeremy" == Jeremy Bícha  writes:

Jeremy> Open the GNOME Tweaks app.  Scroll down the left sidebar to
Jeremy> the panel named Windows.  In the main panel, scroll down to
Jeremy> the Window Focus section.  Click to Focus should be
Jeremy> selected.

Jeremy> I haven't spent much time trying to navigate the GNOME
Jeremy> Tweaks app with the keyboard and screen reader. It may not
Jeremy> be a great experience.

It's not great, but it's not horrible until you get to the end.
I can find the focus control, but I cannot figure out the current value.
I hit tab to where it should be and it simply announces "label."
I can however expand the options and use the orca review keys to select
click to focus with the orca mouse click.
I *assume* that probably makes things click to focus,
And I'm assuming that  the command Simon gave me should work.
But as I indicated in my signed response, even on a fresh install (which
presumably has the default focus), I can reproduce.

--Sam

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On the upstream issue, a bug reporter mentions that to
Simon> reproduce the bug, you need two things: the focus mode needs
Simon> to be set to "sloppy focus", and there needs to be at least
Simon> one window open on the current workspace.

I'd like to push back on the idea that sloppy focus is required.

I tried the following:

* Install task-gnome-desktop on top of  effectively debian:bookworm out
  of docker (roughly debootstrap --varient=minbase)

* adduser --uid 8042 hartmans

* systemctl restart gdm

* At the console alt-super-s to enable orca and then log in

* alt-f2 run gnome-terminal

* Confirm I'm in the terminal

* ctrl-alt-tab to get to the top bar [fails to stay there]

I then confirmed that if I hit super  to get to overview panel and then
ctrl-alt-tab to the top it works.

I also confirmed your work around of going to an empty workspace; that
does work.
But I cannot verify the claim that sloppy focus is required.
I also tried resetting the focus preference you indicated and that did
not help.

--Sam


signature.asc
Description: PGP signature

Bug#1032384: smtp: SSL_CTX_load_verify_locations: No suck file or directory

[Felix Dietrich]

Package: opensmtpd
Version: 6.8.0p2-3
Severity: normal
Tags: patch

On Debian Bullseye attempting to send a test mail from the command line
using the “smtp” program included in the “opensmtpd” package results in
the error message:

smtp: SSL_CTX_load_verify_locations: No suck file or directory

The cause of this error message is a missing “/usr/lib/ssl/cert.pem”
file, which was, according to its changelog, only added to the “openssl”
package in version 3.0.5-3 [1]; this version is not available in the stable
archive.  The path “/usr/lib/ssl/cert.pem” is passed to
“SSL_CTX_load_verify_locations in “smtpc.c:145” (it is the result of the
call to “X509_get_default_cert_file” [2]):

if (!SSL_CTX_load_verify_locations(ssl_ctx,
X509_get_default_cert_file(), NULL))
fatal("SSL_CTX_load_verify_locations");

One solution to this issue would be to backport the addition of the
“/usr/lib/ssl/cert.pem” symlink to the “openssl” package to the older
version available in stable.  This would likely also require an
additional dependency for the “opensmtpd” package on “ca-certificates”
so that the symlink “/usr/lib/ssl/cert.pem” to
“/etc/ssl/certs/ca-certificates.crt” can actually be correctly resolved
to a file.  For this solution, presumably, a bug report against the
“openssl” has to be created.  An ad-hoc solution creates the symlink
manually:

ln -s /etc/ssl/certs/ca-certificates.crt /usr/lib/ssl/cert.pem

Another solution would call instead of “SSL_CTX_load_verify_locations”
the function “SSL_CTX_set_default_verify_paths” as it does not consider
missing default locations an error [3].  It also has the advantage of
allowing the user to customise the certificates used by setting the
environment variables SSL_CERT_DIR and SSL_CERT_FILE.  For this solution
I have attached a patch.  There may, however, have been reasonable
motivation for the use of one function over the other and for producing
an error in the absence of a certificates file, that I am not aware of.

Footnotes:
[1]  The changelog entry:

 openssl (3.0.5-3) unstable; urgency=medium

   * Add cert.pem symlink pointing to ca-certificates' ca-certificates.crt
 (Closes: #805646).
   * Compile with OPENSSL_TLS_SECURITY_LEVEL=2 (Closes: #918727).

  -- Sebastian Andrzej Siewior   Sun, 18 Sep 2022 
21:48:05 +0200

[2]  Compilation of this mini program to print the default certificate
 path requires linking against libcrypto:

gcc print_cert_file.c -o print_cert_file -lcrypto

 /* print_cert_file.c start */
 #include 
 #include 

 #include 

 int main(int argc, char *argv[])
 {
 printf("%s\n", X509_get_default_cert_file());
 return EXIT_SUCCESS;
 }
 /* print_cert_file.c end */

[3]  



-- 
Felix Dietrich

Index: opensmtpd-6.8.0p2/usr.sbin/smtpd/smtpc.c
===
--- opensmtpd-6.8.0p2.orig/usr.sbin/smtpd/smtpc.c	2020-12-24 14:42:21.0 +0100
+++ opensmtpd-6.8.0p2/usr.sbin/smtpd/smtpc.c	2023-03-05 12:49:26.390962737 +0100
@@ -142,9 +142,8 @@
 	event_init();
 
 	ssl_ctx = ssl_ctx_create(NULL, NULL, 0, NULL);
-	if (!SSL_CTX_load_verify_locations(ssl_ctx,
-	X509_get_default_cert_file(), NULL))
-		fatal("SSL_CTX_load_verify_locations");
+	if (!SSL_CTX_set_default_verify_paths(ssl_ctx))
+		fatal("SSL_CTX_set_default_verify_paths");
 	if (!SSL_CTX_set_ssl_version(ssl_ctx, SSLv23_client_method()))
 		fatal("SSL_CTX_set_ssl_version");
 	SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE , NULL);

Bug#1032383: loopback interface (lo) no longer ignored

[Didier 'OdyX' Raboud]

Package: network-manager
Version: 1.42.2-2
Severity: normal

Hello there,

the loopback interface seems no longer ignored by NetworkManager by
default;

$ LANG=C nmcli | grep -A5 ^lo
lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e8618f03d7d8735946a82de8ce4257dd92328b20

This is apparently a new feature of NM 1.42, but I'm arguing that in
most usual cases, having 'lo' appear (as it appears in KDE's Plasma NM
applet for example) is quite confusing to most users who will never
customize anything with regards to the 'lo' interface.

I'd propose that src:network-manager adds a conffile with that content:

[keyfile]
unmanaged-devices=interface-name:lo

This would let the loopback interface be ignored, while allowing experts
needing this to get the new 'lo' managed interface.

Best,

OdyX

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

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

Versions of packages network-manager depends on:
ii  adduser 3.131
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1
ii  libc6   2.36-8
ii  libcurl3-gnutls 7.88.1-2
ii  libglib2.0-02.74.6-1
ii  libgnutls30 3.7.9-1
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.2-2
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b5
ii  libsystemd0 252.6-1
ii  libteamdctl01.31-1
ii  libudev1252.6-1
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.6-1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.6-1
ii  modemmanager 1.20.4-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-12

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-1.1

-- no debconf information

Bug#1029821: change gnome-desktop's default choice of Japanese input methods

[Simon McVittie]

Control: clone -1 -2
Control: severity -2 important
Control: retitle -2 gnome-initial-setup: Label for a default non-xkb ibus input 
method remains a placeholder
Control: forwarded -2 
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/180
Control: reassign -2 gnome-initial-setup 43.2-1

On Wed, 22 Feb 2023 at 15:09:15 +0900, ken...@xdump.org wrote:
> * NOTE: There may be a potential bug that ibus-mozc is not listed 
>   with engine's display name correctly.
>   Thus with attached patch, gnome-initial-setup will not
>   show label for mozc-jp as "日本語 (Mozc)" by default.

This seems to be a separate bug which is not related to whether the
default is mozc or anthy. The bug is: if the default input method is
an ibus engine, then its label is the internal name of the ibus engine
instead of the expected display name.

If I *don't* apply the patch proposed on #1029821, then the non-default
mozc-jp engine is correctly shown as "Japanese (Mozc)" in an English
locale, but the default anthy engine is wrongly shown as "anthy" instead
of the expected "Japanese (Anthy)".

If I *do* apply the patch proposed on #1029821, then the situation is
reversed: the non-default anthy is correctly shown as "Japanese (Anthy)",
but the default mozc-jp is wrongly shown as "mozc-jp" instead of the
expected "Japanese (Mozc)".

If I run gnome-initial-setup as
"LANG=ja_JP.UTF-8 LANGUAGE=ja_JP /usr/libexec/gnome-initial-setup"
then I get similar results, but with Japanese text (and in particular
"日本語" instead of "Japanese").

smcv

Bug#1032238: linux-image-6.1.0-5-amd64: cryptsetup 2:2.6.1-1 password not recognized

[Salvatore Bonaccorso]

Hi,

On Sun, Mar 05, 2023 at 03:51:11PM +0100, Sylvain wrote:
> Hello,
> 
> Yes it's same as #1032221
> 
> It's working well now after cryptsetup update

Many thanks for confirming!

Regards,
Salvatore

Bug#1021601: vlc: VAAPI hardware acceleration no more available

[bob_smith_1337]

This is also the case for me with VLC 3.0.18-2 (current debian bookworm version)
Is there any workaround ?
Thanks a lot

Bug#1031864: bazel-bootstrap: Please re-enable building on mips64el

[Olek Wojnar]

Hi Adrian,

On March 3, 2023 11:02:53 AM UTC, Adrian Bunk  wrote:
>On Thu, Mar 02, 2023 at 12:44:42AM -0500, Olek Wojnar wrote:
>>...
>> I disabled mips64el leading up to the soft freeze since -4 was not building
>> correctly at that time on that architecture. Lacking the time to
>> troubleshoot, I made the decision to sacrifice the one problem architecture
>> in favor of all the others that were working correctly.
>>...
>
>#1030783 was also required for that to work,

I had meant to thank you for filing that bug on my behalf but I got a little 
busy. So, belated but thank you!

>I am not blaming you for
>trying to get your package into testing before the freeze deadline.

I didn't think you were. :) I was just explaining for posterity for future 
people reading this bug and wondering why the architecture was removed and then 
replaced. But thanks still for the clarification. :)

-Olek

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[YOSHINO Yoshihito]

Hi,

On Thu, Mar 2, 2023 at 10:49 PM Osamu Aoki  wrote:
> Yoshino-san, did you check how mozc maintainers think about your proposal.
>
> If they agree, I think promoting mozc for little endian platform may be good
> idea for better user experience.

I am trying to reach them.

Anyway, I have just updated the patch to limit architectures.

Regards,
-- 
YOSHINO Yoshihito 


use_mozc_jp.debdiff
Description: Binary data

Bug#1032375: memtest86+: fails to work with Secure Boot enabled

[Felix Zielcke]

Control: severity -1 wishlist

Am Sonntag, dem 05.03.2023 um 23:20 +1100 schrieb Russell Coker:
> Package: memtest86+
> Version: 6.10-4
> Severity: normal
> 
> If you select the EFI version of memtest86+ from GRUB when Secure
> Boot is
> enabled then it gives the message "error: bad shim signature" and
> fails back
> to GRUB.
> 
> Please provide a signed version so Secure Boot doesn't have to be
> disabled to
> run it.
> 

Hi,

this has been already talked on IRC in #debian-efi.
First step is to get the ok from the shim-review process.
I created already an issue here:

https://github.com/rhboot/shim-review/issues/314

Bug#1032377: firmware loading tests with bookworm-DI-alpha2

[Cyril Brulebois]

Pascal Hambourg  (2023-03-05):
> I am afraid that when the firmware is missing the driver is not
> attached to the device so there is no direct way to retrieve it
> through /sys.

Alright, nice to know which part of the lookup was failing anyway
(single 2-4:1.0 below 2-4, but missing driver symlink).

> An indirect way may be to list loaded USB driver modules in
> /sys/bus/usb/drivers or /proc/modules and search in their firmware
> fields with modinfo ? Heavy and not 100% reliable though...

Since the existing code seems to work in at least some cases, it
wouldn't seem crazy to me to implement a fallback plan in case it
doesn't (as opposed to replacing the existing lookup entirely). After
all, we're quite certain that reloading usb* isn't going to work anyway,
so anything else we can try can't really be worse.

And I suppose iterating over a (uniquified) list of basename for
/sys/bus//drivers/*/module might work on more buses than just usb
(see mhi for the qrtr-mhi thing in #1032140), so it should even be
possible to reuse this outside this specific usb usecase.


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


signature.asc
Description: PGP signature

Bug#1032374: installation-reports

[Florian Zimmermann]

Thanks Holger!

>  GRUB_DISABLE_OS_PROBER=false

this works now with GRUB showing both Win and Debian/GNU. And both boot 
fine, pfew.
In the meantime before fixing the above, in my case I had a BIOS option 
"UEFI Hard Disk Drive BBS Priorities",
that allowed me to find the Debian partition and could start from there 
"manually".
I was so glad I labelled it "debian" during the manual partitioning so I 
could find it! :-)


Three other observations (and I hope the mailing list is still OK to use 
here? Newbie here).


1) I tried Debian 11.6 after no success with 12 in-between. For 11.6 
after manually partitioning,
the installer said something along "No EFI partition found, please go 
back". I had a EFI Windoze partition, so
I guess the installer was smart enough to not be allowed to touch that 
one. But the Debian 12 installer did not show this warning at all!


2) the main user not being in the "sudo" group and adding it manually I 
find quite user-unfriendly...


3) After the first boot, I checked with "top" and no activity! This is 
in great contrast to other distros,
that fill in their (useless) databases and what not after the 1st boot. 
Very responsive system from the get go! :-)


Thanks,
 Florian

On 3/5/23 15:27, Holger Wansing wrote:

Hi,

Holger Wansing  wrote (Sun, 5 Mar 2023 15:02:28 +0100):

mindfsck  wrote (Sun, 5 Mar 2023 12:16:48 +0100):

Package: installation-reports

Boot method: USB stick
Image version: debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 2023/03/05

[...]

Comments/Problems:
The PC contained a full-sized Windows 10 partition, so I resized this
in Debian installer. After successful Debian installation,
the reboots never resulted in landing into GRUB, but rather Windows is
loaded :-(

Can I manually solve this?

This has already been reported several times, sadly. For example

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

Re-assigning both above bugs to grub.



@mindfsck: you should be able to fix your problem like this:
- as root, edit /etc/default/grub: find a line like
#GRUB_DISABLE_OS_PROBER=false
   Change it into
GRUB_DISABLE_OS_PROBER=false
   (means: remove the # at the beginning of the line.)

- as root, execute "update-grub"

This should find your Windows installation and add an entry to the
bootloader menu, to boot Windows.


Uups, sorry, I misread your report.
Your problem is, you can only boot Windows, and NOT boot Debian.
I mixed that up with reports, where a start entry for Windows is missing
in the grub menu.



In your case, my best guess would be, to start the debian-installer
again, but from the installer menu choose the "Rescue" entry, to not perform
another installation, but start a recovery environment, where you get the
possibility to fix such things.

There, mount the corresponding partition (the partition, where you installed
Debian on; I guess this might be /dev/sda2) as /root, and then do similar
as written above:
execute "TERM=bterm nano /etc/default/grub"
to make a line containing "GRUB_DISABLE_OS_PROBER=false" in that file

Then call "update-grub".

Please report, how it goes.


Holger

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

[Guillem Jover]

Package: aide
Version: 0.18-2
Severity: serious

Hi!

Just upgraded a server to Debian bookworm, and noticed that aideinit
was not working anymore, giving the following error:

  ,---
  # aideinit --yes --force
  Running aide --init...
  User [_aide] not known
  AIDE --init return code 1
  `---

This specific system is using sysvinit. Checking the postinst I notice
it is conditionally using systemd-sysusers if available, but then
unconditionally tries to chown files and does not fail if it cannot
perform the operation.

So ideally this would get adduser support, and depend on either that
or systemd-standalone-sysusers.

After having manually created the user with adduser, then aideinit
still failed with:

  ,---
  # aideinit --force --yes
  Running aide --init...
  /bin/bash: line 1: /var/log/aide/aideinit.log: Permission denied
  AIDE --init return code 1
  `---

Checking «/var/log/aide/» I saw that at least aideinit.log and
aideinit.errors were indeed still owned by root:adm, fixing the
ownership for those files made aideinit work again. So I guess this is
also missing in the postinst handling.

Thanks,
Guillem

Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Martin Steigerwald]

Hi Simon and Lorenzo.

First off: Kudos and appreciation that you took the time to respond this
thoroughly. Thank you!

Dear Lorenzo, I am also CC'ing you since some of the findings may point
at that it may make sense to resolve this within the runit-services package.
However I am certainly not sure yet about that. Especially as it would
require a solution for other init systems than Runit as well. Indeed there
are several options to fix the issue that Simon outlined. One of them would
involve upstream activity in KDE. And another one could probably work
from dbus-x11. So much choice to get a clue about!

Simon McVittie - 05.03.23, 12:58:48 CET:
> On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote:
> > This is with Devuan Ceres with Runit and Elogind. I am reporting
[…]
> This bug tracking system is for Debian, not Devuan. Is this
> reproducible on a Debian system with elogind, KDE and some
> non-systemd init system, perhaps by using a virtual machine?

I appreciate that. And I admit I did not yet test it in Debian. I consider
setting up a virtual machine to make sure.

> (In particular, I am not responsible for decisions made by the Devuan
> maintainers of dbus. The version number 1.14.6-1devuan1 indicates that

Fair enough! I could install the Debian Experimental version of the package,
but that still would not make this Devuan installation a Debian, so rather
going for the virtual machine approach.

> In my experience, sysv-rc and openrc (sysvinit as process 1) are
> generally better-integrated in Debian than runit. Is this
> reproducible with sysv-rc or openrc?

Lorenzo confirmed this for SysVInit as well:

https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2023-February/005929.html

I asked for confirmation whether this confirmation is from a Devuan or a
Debian based system.

Also the KDE bug report I mentioned that this happens across distributions
and across different init systems¹. It originally has been reported for Gentoo.

[1] https://bugs.kde.org/432975

> How is your `dbus-daemon --session` process started? Is it started by
> /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching?
> What is its current working directory?

I bet you mean the dbus service which

DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-uwFj[…],guid=9aaf[…]'

refers to. According to lsof this is running as PID 9107 currently.

Its parent process is runit. Its working directory is "/".

It seems to be run with:

% cat run
#!/usr/bin/env /lib/runit/invoke-run
#Copyright: 2022-2023 Lorenzo Puliti <[…]>
#License: CC0-1.0

exec 2>&1

if [ ! -d /var/run/dbus ]; then
install -d /var/run/dbus -o messagebus -g messagebus
fi
mountpoint -q /proc/ || exit 162
if [ -x /usr/bin/dbus-uuidgen ]; then
/usr/bin/dbus-uuidgen --ensure
fi

if [ -e /etc/runit/verbose ]; then
echo "invoke-run: starting ${PWD##*/}"
fi
exec dbus-daemon --system --nofork --nopidfile

Well I bet basically that would explain its current working directory being
"/". However it would not explain it for a SysVInit based system.

Also above runit service comes from the runit-services package and the
issue has been already there before Lorenzo brought this package
into Debian and before I had it installed.

Grepping for processes with dbus in their name or arguments also reveals
one dbus service that appears to have been launched by sddm which
is the display manager I use:

% ps aux | grep "[d]bus"
root  1991  0.0  0.0   2344  1268 ?Ss   Mär04   0:00 runsv dbus
root  1992  0.0  0.0   2344  1368 ?Ss   Mär04   0:00 runsv 
dbus.dep-fixer
_runit-+  2015  0.0  0.0   2492  1452 ?SMär04   0:00 svlogd -tt -b 
2048 /var/log/runit/dbus
message+  2016  0.0  0.0   6536  4896 ?SMär04   0:04 dbus-daemon 
--system --nofork --nopidfile
sddm  6587  0.0  0.0   6652  2316 ?SMär04   0:00 dbus-launch 
--autolaunch 3d6f92a09aa53b38614887db63ce99a6 --binary-syntax --close-stderr
sddm  6614  0.0  0.0   4404  2128 ?Ss   Mär04   0:00 
/usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 
--session
martin9106  0.0  0.0   6740  2424 ?SMär04   0:00 
/usr/bin/dbus-launch --exit-with-session --sh-syntax
martin9107  0.0  0.0   7096  4696 ?Ss   Mär04   0:12 
/usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
martin9317  0.0  0.0 234536 25088 ?Sl   Mär04   0:03 
/usr/bin/gmenudbusmenuproxy

The working directory of PID 6614 is also /. I bet it is not related to the
bug I reported. It seems to be a special dbus service just for the display
manager and "/" as working directory may just be about right for that
one.

> /etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant
> to be started on most Debian-derived systems that are not using
> `systemd --user`. It starts the `dbus-daemon --session` as part of X
> session startup, inheriting its current working directory and various
> other 

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[Arnout Vandecappelle]

Sandro Tosi  schreef op 3 maart 2023 21:05:03 CET:
>> This bug is about the warning, not about the fact that the bundled zoninfo
>> database is missing.
>
>not exactly
>
>even if these APIs are deprecated upstream, i think breaking them on
>purpose (by removing the bundled timezone file) is uncalled for.

 AFAICS, the API is not deprecated. It is also not really broken. Is just that 
if you ask explicitly for the bundled database, you get an empty database. 
Currently, you get an empty database and a warning is printed; my patch just 
removes that warning.


>Either we reintroduce the timezone file (that may not be a good idea)

 I can't really comment on that. Other distros don't seem to remove it 

>or translate these deprecated APIs into the recommended one,

 I don't see how it would be possible to do that. There are two deprecated 
functions, but those already have a fallback in the function we're fixing here 
(and which is the one that issues the warning).


> or we do
>something else entirely, it's up for debate.

 One thing we could do is to regenerate the bundled database based on actual 
zoneinfo. But then the package should be rebuilt every time zoneinfo is 
updated...

Another option would be to remove the fallback on the bundled database, which 
probably solves the initially reported matplotlib issue (see also below). 
However, I don't see this as an improvement over


>simply silencing the warning message is providing 0 value to a proper solution.

 IMHO, it is a perfectly valid solution for the relatively common case of 
requesting a nonexistent timezone. As mentioned a few times in this bug, the 
warning also triggers if a nonexistent timezone is requested without requesting 
explicitly for the bundled database, because there's a fallback on the bundled 
one if it can't be found in the system one. I believe that that is in fact the 
originally reported issue with matplotlib (though the report isn't too clear on 
it).

In my view, no actual user is asking for the possibility of using the bundled 
database, or anything nebulous like using the system database even if the 
bundled one is requested explicitly. They're simply asking for an irrelevant 
warning to be removed.

That said, if it makes people happy, I'm willing to rewrite the patch to remove 
the fallback instead of removing the warning.

Regards,
Armour



-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

Bug#1032374: installation-reports

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 5 Mar 2023 15:02:28 +0100):
> 
> mindfsck  wrote (Sun, 5 Mar 2023 12:16:48 +0100):
> > Package: installation-reports
> > 
> > Boot method: USB stick
> > Image version: debian-bookworm-DI-alpha2-amd64-netinst.iso
> > Date: 2023/03/05
> [...]
> > Comments/Problems:
> > The PC contained a full-sized Windows 10 partition, so I resized this
> > in Debian installer. After successful Debian installation,
> > the reboots never resulted in landing into GRUB, but rather Windows is
> > loaded :-(
> > 
> > Can I manually solve this?
> 
> This has already been reported several times, sadly. For example
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031594
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012865
> 
> Re-assigning both above bugs to grub.
> 
> 
> 
> @mindfsck: you should be able to fix your problem like this:
> - as root, edit /etc/default/grub: find a line like
>   #GRUB_DISABLE_OS_PROBER=false
>   Change it into
>   GRUB_DISABLE_OS_PROBER=false
>   (means: remove the # at the beginning of the line.)
> 
> - as root, execute "update-grub"
> 
> This should find your Windows installation and add an entry to the 
> bootloader menu, to boot Windows.


Uups, sorry, I misread your report.
Your problem is, you can only boot Windows, and NOT boot Debian.
I mixed that up with reports, where a start entry for Windows is missing
in the grub menu.



In your case, my best guess would be, to start the debian-installer
again, but from the installer menu choose the "Rescue" entry, to not perform
another installation, but start a recovery environment, where you get the 
possibility to fix such things.

There, mount the corresponding partition (the partition, where you installed
Debian on; I guess this might be /dev/sda2) as /root, and then do similar
as written above:
execute "TERM=bterm nano /etc/default/grub"
to make a line containing "GRUB_DISABLE_OS_PROBER=false" in that file

Then call "update-grub".

Please report, how it goes.


Holger

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

Bug#1032377: firmware loading tests with bookworm-DI-alpha2

[Pascal Hambourg]

On 05/03/2023 at 13:49, Cyril Brulebois wrote:



Mar  5 08:55:33 kernel: [  184.568261] usb 2-4: Loading firmware file isl3886usb
Mar  5 08:55:33 kernel: [  184.568284] usb 2-4: firmware: failed to load 
isl3886usb (-2)
Mar  5 08:55:33 kernel: [  184.568294] usb 2-4: firmware: failed to load 
isl3886usb (-2)
Mar  5 08:55:33 kernel: [  184.568295] usb 2-4: Direct firmware load for 
isl3886usb failed with error -2
Mar  5 08:55:33 kernel: [  184.568298] p54usb 2-4:1.0: failed to initialize 
device (-2)
Mar  5 08:55:33 kernel: [  184.568352] usbcore: registered new interface driver 
p54usb



Mar  5 08:55:34 check-missing-firmware: looking at dmesg for the first time
Mar  5 08:55:34 check-missing-firmware: saving timestamp for a later use: [  
184.647143]
Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup (no 
driver found)
Mar  5 08:55:34 check-missing-firmware: => sticking with the usb module
Mar  5 08:55:34 check-missing-firmware: using module usb instead of usb 2-4
Mar  5 08:55:34 check-missing-firmware: looking for firmware file isl3886usb 
requested by usb
Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup (no 
driver found)
Mar  5 08:55:35 check-missing-firmware: => sticking with the usb module


Please share the contents of that device's directory, so that the lookup
can be adjusted. I could only test with one single device, so I haven't
tried to be clever and think about all possible cases. Feel free to
spawn a specific hw-detect bug report for that.


See attached files with and without firmware. The following links and 
directories exist only with firmware:


lrwxrwxrwx1 root root 0 Mar  5 13:29 driver -> 
../../../../../../bus/usb/drivers/p54usb

drwxr-xr-x3 root root 0 Mar  5 13:29 ieee80211
drwxr-xr-x6 root root 0 Mar  5 13:29 leds
drwxr-xr-x3 root root 0 Mar  5 13:29 net

I am afraid that when the firmware is missing the driver is not attached 
to the device so there is no direct way to retrieve it through /sys.


An indirect way may be to list loaded USB driver modules in 
/sys/bus/usb/drivers or /proc/modules and search in their firmware 
fields with modinfo ? Heavy and not 100% reliable though...# with firmware

# ls -l /sys/bus/usb/devices/2-4/
drwxr-xr-x   18 root root 0 Mar  5 08:54 2-4:1.0
-rw-r--r--1 root root  4096 Mar  5 08:55 authorized
-rw-r--r--1 root root  4096 Mar  5 08:55 avoid_reset_quirk
-rw-r--r--1 root root  4096 Mar  5 08:55 bConfigurationValue
-r--r--r--1 root root  4096 Mar  5 08:55 bDeviceClass
-r--r--r--1 root root  4096 Mar  5 08:55 bDeviceProtocol
-r--r--r--1 root root  4096 Mar  5 08:55 bDeviceSubClass
-r--r--r--1 root root  4096 Mar  5 08:55 bMaxPacketSize0
-r--r--r--1 root root  4096 Mar  5 08:55 bMaxPower
-r--r--r--1 root root  4096 Mar  5 08:55 bNumConfigurations
-r--r--r--1 root root  4096 Mar  5 08:55 bNumInterfaces
-r--r--r--1 root root  4096 Mar  5 08:54 bcdDevice
-r--r--r--1 root root  4096 Mar  5 08:55 bmAttributes
-r--r--r--1 root root  4096 Mar  5 08:55 busnum
-r--r--r--1 root root  4096 Mar  5 08:55 configuration
-r--r--r--1 root root 65553 Mar  5 08:54 descriptors
-r--r--r--1 root root  4096 Mar  5 08:55 dev
-r--r--r--1 root root  4096 Mar  5 08:55 devnum
-r--r--r--1 root root  4096 Mar  5 08:55 devpath
-r--r--r--1 root root  4096 Mar  5 08:55 devspec
lrwxrwxrwx1 root root 0 Mar  5 08:55 driver -> 
../../../../../bus/usb/drivers/usb
drwxr-xr-x3 root root 0 Mar  5 08:55 ep_00
lrwxrwxrwx1 root root 0 Mar  5 08:55 firmware_node -> 
../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b/device:2c/device:30
-r--r--r--1 root root  4096 Mar  5 08:54 idProduct
-r--r--r--1 root root  4096 Mar  5 08:54 idVendor
-r--r--r--1 root root  4096 Mar  5 08:55 ltm_capable
-r--r--r--1 root root  4096 Mar  5 08:55 maxchild
drwxr-xr-x2 root root 0 Mar  5 08:55 physical_location
lrwxrwxrwx1 root root 0 Mar  5 08:55 port -> 
../2-0:1.0/usb2-port4
drwxr-xr-x2 root root 0 Mar  5 08:55 power
-r--r--r--1 root root  4096 Mar  5 08:55 quirks
-r--r--r--1 root root  4096 Mar  5 08:55 removable
--w---1 root root  4096 Mar  5 08:55 remove
-r--r--r--1 root root  4096 Mar  5 08:55 rx_lanes
-r--r--r--1 root root  4096 Mar  5 08:55 speed
lrwxrwxrwx1 root root 0 Mar  5 08:55 subsystem -> 
../../../../../bus/usb
-r--r--r--1 root root  4096 Mar  5 08:55 

Bug#1031690: Regression in wayland mixed DPI setups

[Aurélien COUDERC]

Dear Odyx,

Le lundi 20 février 2023, 18:10:58 CET Didier 'OdyX' Raboud a écrit :
> Package: plasma-workspace-wayland
> Version: 4:5.27.0-1
> Severity: important
> Tags: upstream
> 
> Hello there,
> 
> it looks like there's a regression in mixed DPI setups (one hiDPI screen
> at "150%", a lower-DPI screen at "100%"), on Wayland, for some non-KDE
> applications. In my case, flatpak firefox has too small tabs depending
> on which screen it initially got launched.

This has been marked as fixed upstream in 5.27.1.

Could you retest on 5.27.2 that we have in unstable and close this bug if it is 
indeed fixed ?


Thanks,
--
Aurélien

Bug#1032380: arriero: AttributeError: module 'collections' has no attribute 'MutableSet'

[s3v]

Package: arriero
Version: 0.7~20161228-1.1
Severity: serious


Dear Maintainer,

This command fails:

$:> arriero --help
/usr/lib/python3/dist-packages/arriero/version.py:35: FutureWarning: Possible 
nested set at position 14
 vendor_re = re.compile(r'\d(?P[[:alpha:]]*)?[1-9][0-9.~]*$')
Traceback (most recent call last):
 File "/usr/bin/arriero", line 33, in 
   sys.exit(load_entry_point('Arriero==0.7', 'console_scripts', 'arriero')())
^^
 File "/usr/bin/arriero", line 25, in importlib_load_entry_point
   return next(matches).load()
  
 File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
   module = import_module(match.group('module'))

 File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
   return _bootstrap._gcd_import(name[level:], package, level)
  
 File "", line 1206, in _gcd_import
 File "", line 1178, in _find_and_load
 File "", line 1128, in _find_and_load_unlocked
 File "", line 241, in _call_with_frames_removed
 File "", line 1206, in _gcd_import
 File "", line 1178, in _find_and_load
 File "", line 1149, in _find_and_load_unlocked
 File "", line 690, in _load_unlocked
 File "", line 940, in exec_module
 File "", line 241, in _call_with_frames_removed
 File "/usr/lib/python3/dist-packages/arriero/__init__.py", line 4, in 
   from .arriero import Arriero, main
 File "/usr/lib/python3/dist-packages/arriero/arriero.py", line 32, in 
   from . import util
 File "/usr/lib/python3/dist-packages/arriero/util.py", line 188, in 
   class OrderedSet(deb822.OrderedSet, collections.MutableSet):
   ^^
AttributeError: module 'collections' has no attribute 'MutableSet'

"arriero {build, clone, exec, list, pull, push, ...} foo" also fails.


Kind Regards

Bug#1032070: seems this is included only on 3.2.1

[Pirate Praveen]

On Mon, 27 Feb 2023 16:53:19 +0530 Pirate Praveen 
 wrote:

> Control: affects -1 gitlab

Since gitlab is in contrib, as a workaround we are installing openssl 
3.0.2 gem in postinst.


https://salsa.debian.org/ruby-team/gitlab/-/commit/08fe0d965d01db3f4ece15c664b54c169890eda7

We can remove the workaround once this is fixed in libruby3.1

Bug#1032252: baloo-kf5: baloo displays search results multiple times.

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401863

Dear olaf,

Le jeudi 2 mars 2023, 12:44:24 CET olaf a écrit :
> Package: baloo-kf5
> Version: 5.103.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> The problem should be well known, e.g. it has been reported here over the 
> years:
> - https://bugs.kde.org/show_bug.cgi?id=419302

Indeed, and it’s most recent follow-up up upstream bug seems to be [1] so I’m 
linking your Debian bug report to it.

Unfortunately it doesn’t look like upstream has worked fix for it yet.


[1] https://bugs.kde.org/show_bug.cgi?id=401863


Happy hacking,
--
Aurélien

Bug#1032374: installation-reports

[Holger Wansing]

Control: reassign -1 grub2
Control: reassign 1031594 grub2



Hi,

mindfsck  wrote (Sun, 5 Mar 2023 12:16:48 +0100):
> Package: installation-reports
> 
> Boot method: USB stick
> Image version: debian-bookworm-DI-alpha2-amd64-netinst.iso
> Date: 2023/03/05
[...]
> Comments/Problems:
> The PC contained a full-sized Windows 10 partition, so I resized this
> in Debian installer. After successful Debian installation,
> the reboots never resulted in landing into GRUB, but rather Windows is
> loaded :-(
> 
> Can I manually solve this?

This has already been reported several times, sadly. For example

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

Re-assigning both above bugs to grub.



@mindfsck: you should be able to fix your problem like this:
- as root, edit /etc/default/grub: find a line like
#GRUB_DISABLE_OS_PROBER=false
  Change it into
GRUB_DISABLE_OS_PROBER=false
  (means: remove the # at the beginning of the line.)

- as root, execute "update-grub"

This should find your Windows installation and add an entry to the 
bootloader menu, to boot Windows.

Sorry, that you experienced this kind of trouble.


Regards
Holger


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

Bug#1032379: Crash when modale dialog opens

[Klaus Ethgen]

Package: xserver-xorg-video-nvidia-tesla-470
Version: 470.161.03-2
Severity: important

When some modal dialog opens, X is crashing reliable with the following
message in kernel log:
   [So Mär  5 14:15:21 2023] resource sanity check: requesting [mem 
0x000c-0x000f], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
   [So Mär  5 14:15:21 2023] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping 
multiple BARs

Some dialog I had that:
- Geeqie create new folder while moving
- GnuPG open a pinentry (/usr/bin/pinentry-qt)

So, yes, that bug is of some importance.

-- Package-specific info:
uname -a:
Linux ikki 6.1.12 #2.ikki SMP Sat Feb 18 17:01:30 CET 2023 x86_64 GNU/Linux

/proc/version:
Linux version 6.1.12 (klaus@ikki) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #2.ikki SMP Sat Feb 18 17:01:30 CET 2023

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  470.161.03  Wed Oct 19 00:10:36 
UTC 2022
GCC version:  gcc version 12.2.0 (Debian 12.2.0-14) 

lspci 'display controller [030?]':
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 
680] [10de:1180] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GK104 [GeForce GTX 680] [1043:83f6]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[686634.467004] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs
[952340.137949] [drm] [nvidia-drm] [GPU ID 0x0300] Unloading driver
[952340.145401] nvidia-modeset: Unloading
[952340.151817] nvidia-nvlink: Unregistered the Nvlink Core, major device 
number 246
[952340.233770] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 246
[952340.234708] nvidia :03:00.0: vgaarb: changed VGA decodes: 
olddecodes=none,decodes=none:owns=io+mem
[952342.842228] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  470.161.03  Wed 
Oct 19 00:10:36 UTC 2022
[952342.886075] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  470.161.03  Wed Oct 19 00:05:15 UTC 2022
[952342.928356] [drm] [nvidia-drm] [GPU ID 0x0300] Loading driver
[952342.928377] [drm] Initialized nvidia-drm 0.0.0 20160202 for :03:00.0 on 
minor 1
[952343.255512] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs
[1086178.470723] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs
[1134493.414170] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs
[1280539.784671] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs
[1283555.530815] caller _nv000720rm+0x1ad/0x200 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw 1 root video 226,   0 Feb 18 17:42 /dev/dri/card0
crw-rw 1 root video 226,   1 Mar  1 18:15 /dev/dri/card1
crw-rw-rw- 1 root video 226, 128 Mar  1 18:15 /dev/dri/renderD128
crw-rw-rw- 1 root root  195, 254 Feb 18 17:44 /dev/nvidia-modeset
crw-rw-rw- 1 root root  195,   0 Feb 18 17:44 /dev/nvidia0
crw-rw-rw- 1 root root  195, 255 Feb 18 17:44 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Mar  1 18:15 pci-:03:00.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Mar  1 18:15 pci-:03:00.0-render -> ../renderD128
lrwxrwxrwx 1 root root  8 Feb 18 17:42 platform-simple-framebuffer.0-card -> 
../card0
video:x:44:klaus

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/tesla-470
  link currently points to /usr/lib/nvidia/tesla-470
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libcuda.so.1
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-i386-linux-gnu is 

Bug#1030095: hplip is broken as reported by hp-check (see below). This renders

[Thorsten Alteholz]

Hi Michael,

thanks for your bug report.

What makes you think that hplip is broken instead of hp-check?

For example in "General Dependencies" packages cups-devel and cups-image 
are required. Both do not exist. Though this has been reported several 
times, HP does not want to change this.


This is not a bug, this is a feature.

  Thorsten

Bug#1032378: mozc is not compiled on all little-endian platforms, should it be?

[Simon McVittie]

Source: mozc
Version: 2.28.4715.102+dfsg-2.2
Severity: normal

>From discussion on #1029821, it seems that mozc only supports little-endian
CPU architectures (for example i386 and arm64) and does not support
big-endian CPU architectures (for example powerpc and s390x).

At the moment, mozc is only compiled on some little-endian architectures:

* amd64
* arm64
* armel
* armhf,
* i386
* riscv64

but not on others, such as:

* mips64el
* mipsel
* ppc64el
* hurd-i386
* kfreebsd-amd64
* kfreebsd-i386
* sh4 (?)
* x32

Should mozc be compiled on *all* little-endian architectures, or are there
other reasons why it needs to be restricted to a subset of them?

If the intention is to compile mozc on all little-endian platforms, the
easiest way is probably:

# debian/control
...
Build-Depends: ..., architecture-is-little-endian, ...

...

Package: ibus-mozc
Architecture: any
...

Package: uim-mozc
Architecture: any
...

and so on, so that it builds successfully on all LE architectures (past,
present and future) but is BD-Uninstallable on all BE architectures.

If we change GNOME's idea of the default input method for Japanese locales
from anthy to mozc as requested in #1029821, then any changes here might
need to be coordinated with src:gnome-desktop (although I'm investigating
whether we can make that decision dynamically at runtime). Please keep
the GNOME team informed on what happens here.

Thanks,
smcv

Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

[bob_smith_1337]

So, I figured out my case, I hope this helps anyone else with the same issue

for some forsaken reason I had
# intelworkaround
export MESA_LOADER_DRIVER_OVERRIDE=i965

in my ~/.profile, which forced mesa to look for i965, failing since it has been 
removed in testing, and falling back to SW rendering. you can check if you have 
the same issue by using MESA_LOADER_DRIVER_OVERRIDE=iris (if iris is the one 
corresponding to your intel graphics):

:~$ xdriinfo
libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot 
open shared object file: No such file or directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: i965
Screen 0: swrast
:~$ MESA_LOADER_DRIVER_OVERRIDE=iris xdriinfoScreen 0: iris

now HW acceleration is back and my sanity has been restored.

there should be a way of tracking insidious workarounds like that. one day 
something breaks, you slap a quick workaround to have a working computer, but 
the non-standard config stays there to bite you in the rear months/years later

Bug#1032377: firmware loading tests with bookworm-DI-alpha2

[Cyril Brulebois]

Pascal Hambourg  (2023-03-05):
> I tested firmware detection and loading with various (mostly old)
> hardware I have. I did not complete all installations.

Thanks for that.

> 1) Things that went well:
> 
> GPU AMD/ATI (radeon+firmware-amd-graphics): OK
> GPU Intel (i915+firmware-misc-nonfree): OK
> PCI SCSI QLogic ISP1020 (qla1280+firmware-qlogic): OK
> PCI Ethernet Intel PRO/100 (e100+firmware-misc-nonfree): OK
> PCI Ethernet Broadcom BCM5901 (tg3+firmware-misc-nonfree): OK
> PCIe wifi Intel Centrino Advanced-N 6205 (iwlwifi+firmware-iwlwifi): OK

Great.

> 2) Things that did not go so well:
> 
> PCI SCSI Advansys ASC 1300/3300 (advansys+firmware-misc-nonfree): KO/OK
> - i386: OK
> - amd64: KO. This is a kernel driver bug, cf. bug #1032271.

OK.

> * PCI wifi Intel PRO/Wireless 2200BG (ipw2200+firmware-ipw2x00): KO/OK
> The firmware package was found, installed and used but not copied in
> /var/cache/firmware. IIUC install_firmware_pkg() in check-missing-firmware
> ,it is because its preinst script requires a license acceptance (is that
> really needed ?). However the firmware files are left because of a typo
> (".md5sum" should be ".md5sums"):
> 
> > # Remove non-accepted firmware package
> > remove_pkg() {
> > pkgname="$1"
> > # Remove all files listed in /var/lib/dpkg/info/$pkgname.md5sum
> > for file in $(cut -d" " -f 2- /var/lib/dpkg/info/$pkgname.md5sum) ; do
> > rm /$file
> > done
> > }

Fixed the typo for now. I don't have enough bandwidth to actually think
about the license acceptance part. Might be worth filing separately
against hw-detect for later consideration.

> As a result, the interface works in the installer but IIUC the package
> will not be installed in the target system.
> 
> 
> * CardBus wifi Intersil Prism54 (p54pci+isl3886pci): KO/OK
> The firmware is not included in any Debian package, so I provided it either
> as loose file or hand-made .deb on a second USB stick.
> But check-missing-firmware never runs mount-media. Looking at the code:
> 
> > if [ "$loop" -lt 1 ]; then
> > # second, look for loose firmware files on the media device.
> 
> shouldn't the condition be "-gt" ? After changing it,
> - loose file: KO (not found, known bug)
> - .deb: OK

Definitely a typo/thinko, fixed.

> * USB wifi Intersil Prism54 (p54usb+isl3886usb): KO
> The firmware is not included in any Debian package, so I provided it either
> as loose file or hand-made .deb on a second USB stick.
> It seems that check-missing-firmware failed to find the real module name
> despite hw-detect commit ab087adedd738d8b6bfb7e785c591a1aa982b7f2.
> 
> Messages recorded in /var/log/syslog:
> 
> > Mar  5 08:54:09 kernel: [  100.782749] usb 2-4: new high-speed USB device 
> > number 3 using xhci_hcd
> > Mar  5 08:54:09 kernel: [  100.930970] usb 2-4: New USB device found, 
> > idVendor=0db0, idProduct=6826, bcdDevice= 2.02
> > Mar  5 08:54:09 kernel: [  100.930982] usb 2-4: New USB device strings: 
> > Mfr=0, Product=0, SerialNumber=0
> 
> > Mar  5 08:55:33 kernel: [  184.568261] usb 2-4: Loading firmware file 
> > isl3886usb
> > Mar  5 08:55:33 kernel: [  184.568284] usb 2-4: firmware: failed to load 
> > isl3886usb (-2)
> > Mar  5 08:55:33 kernel: [  184.568294] usb 2-4: firmware: failed to load 
> > isl3886usb (-2)
> > Mar  5 08:55:33 kernel: [  184.568295] usb 2-4: Direct firmware load for 
> > isl3886usb failed with error -2
> > Mar  5 08:55:33 kernel: [  184.568298] p54usb 2-4:1.0: failed to initialize 
> > device (-2)
> > Mar  5 08:55:33 kernel: [  184.568352] usbcore: registered new interface 
> > driver p54usb
> 
> > Mar  5 08:55:34 check-missing-firmware: looking at dmesg for the first time
> > Mar  5 08:55:34 check-missing-firmware: saving timestamp for a later use: [ 
> >  184.647143]
> > Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup 
> > (no driver found)
> > Mar  5 08:55:34 check-missing-firmware: => sticking with the usb module
> > Mar  5 08:55:34 check-missing-firmware: using module usb instead of usb 2-4
> > Mar  5 08:55:34 check-missing-firmware: looking for firmware file 
> > isl3886usb requested by usb
> > Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup 
> > (no driver found)
> > Mar  5 08:55:35 check-missing-firmware: => sticking with the usb module

Please share the contents of that device's directory, so that the lookup
can be adjusted. I could only test with one single device, so I haven't
tried to be clever and think about all possible cases. Feel free to
spawn a specific hw-detect bug report for that.


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


signature.asc
Description: PGP signature

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

[Marc]

On March 5, 2023 11:01:02 AM UTC, Diederik de Haas  
wrote:
>Control: tag -1 moreinfo
>
>On Sunday, 5 March 2023 09:26:20 CET Marc wrote:
>> Package: firmware-brcm80211
>> Version: 20210315-3
>> 
>> The firmware for the wifi hardware found on the GPD Pocket 1 is missing in
>> latest firmware package. Installing an old package from bullseyes fixes the
>> issue.
>
>You are running not running the latest version of the firmware package.
>Can you try it with the latest version?
>Updated package is now in the non-free-firmware archive area, so make sure 
>that's enabled in your sources.list.
That's the reason my WiFi broke... I've enabled the non-free-firmware 
repository (for another unrelated issue with audio not working). It installed 
several packages and after reboot, wifi was not working anymore with kernel 
complaining about missing .bin file. A search in the archive pointed to 
bullseyes package as anything more recent doesn't include it.

I'll test it again for completeness and send the result here.

Thanks

Bug#1032377: firmware loading tests with bookworm-DI-alpha2

[Pascal Hambourg]

Package: installation-reports

Boot method: USB stick
Image version: debian-bookworm-DI-alpha2-amd64-netinst.iso
   debian-bookworm-DI-alpha2-i386-netinst.iso
Date: 2023-03-05

Machine: various PC
Processor: various Intel from Pentium 4 to Core i7
Memory: 1.25 to 16 GiB

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

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

Comments/Problems:

I tested firmware detection and loading with various (mostly old) 
hardware I have. I did not complete all installations.



1) Things that went well:

GPU AMD/ATI (radeon+firmware-amd-graphics): OK
GPU Intel (i915+firmware-misc-nonfree): OK
PCI SCSI QLogic ISP1020 (qla1280+firmware-qlogic): OK
PCI Ethernet Intel PRO/100 (e100+firmware-misc-nonfree): OK
PCI Ethernet Broadcom BCM5901 (tg3+firmware-misc-nonfree): OK
PCIe wifi Intel Centrino Advanced-N 6205 (iwlwifi+firmware-iwlwifi): OK


2) Things that did not go so well:

PCI SCSI Advansys ASC 1300/3300 (advansys+firmware-misc-nonfree): KO/OK
- i386: OK
- amd64: KO. This is a kernel driver bug, cf. bug #1032271.


* PCI wifi Intel PRO/Wireless 2200BG (ipw2200+firmware-ipw2x00): KO/OK
The firmware package was found, installed and used but not copied in 
/var/cache/firmware. IIUC install_firmware_pkg() in 
check-missing-firmware ,it is because its preinst script requires a 
license acceptance (is that really needed ?). However the firmware files 
are left because of a typo (".md5sum" should be ".md5sums"):



# Remove non-accepted firmware package
remove_pkg() {
pkgname="$1"
# Remove all files listed in /var/lib/dpkg/info/$pkgname.md5sum
for file in $(cut -d" " -f 2- /var/lib/dpkg/info/$pkgname.md5sum) ; do
rm /$file
done
}


As a result, the interface works in the installer but IIUC the package 
will not be installed in the target system.



* CardBus wifi Intersil Prism54 (p54pci+isl3886pci): KO/OK
The firmware is not included in any Debian package, so I provided it 
either as loose file or hand-made .deb on a second USB stick.

But check-missing-firmware never runs mount-media. Looking at the code:


if [ "$loop" -lt 1 ]; then
# second, look for loose firmware files on the media device.


shouldn't the condition be "-gt" ? After changing it,
- loose file: KO (not found, known bug)
- .deb: OK


* USB wifi Intersil Prism54 (p54usb+isl3886usb): KO
The firmware is not included in any Debian package, so I provided it 
either as loose file or hand-made .deb on a second USB stick.
It seems that check-missing-firmware failed to find the real module name 
despite hw-detect commit ab087adedd738d8b6bfb7e785c591a1aa982b7f2.


Messages recorded in /var/log/syslog:


Mar  5 08:54:09 kernel: [  100.782749] usb 2-4: new high-speed USB device 
number 3 using xhci_hcd
Mar  5 08:54:09 kernel: [  100.930970] usb 2-4: New USB device found, 
idVendor=0db0, idProduct=6826, bcdDevice= 2.02
Mar  5 08:54:09 kernel: [  100.930982] usb 2-4: New USB device strings: Mfr=0, 
Product=0, SerialNumber=0



Mar  5 08:55:33 kernel: [  184.568261] usb 2-4: Loading firmware file isl3886usb
Mar  5 08:55:33 kernel: [  184.568284] usb 2-4: firmware: failed to load 
isl3886usb (-2)
Mar  5 08:55:33 kernel: [  184.568294] usb 2-4: firmware: failed to load 
isl3886usb (-2)
Mar  5 08:55:33 kernel: [  184.568295] usb 2-4: Direct firmware load for 
isl3886usb failed with error -2
Mar  5 08:55:33 kernel: [  184.568298] p54usb 2-4:1.0: failed to initialize 
device (-2)
Mar  5 08:55:33 kernel: [  184.568352] usbcore: registered new interface driver 
p54usb



Mar  5 08:55:34 check-missing-firmware: looking at dmesg for the first time
Mar  5 08:55:34 check-missing-firmware: saving timestamp for a later use: [  
184.647143]
Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup (no 
driver found)
Mar  5 08:55:34 check-missing-firmware: => sticking with the usb module
Mar  5 08:55:34 check-missing-firmware: using module usb instead of usb 2-4
Mar  5 08:55:34 check-missing-firmware: looking for firmware file isl3886usb 
requested by usb
Mar  5 08:55:34 check-missing-firmware: failed to perform usb 2-4 lookup (no 
driver found)
Mar  5 08:55:35 check-missing-firmware: => sticking with the usb module
Mar  5 08:55:35 check-missing-firmware: using module usb instead of usb 2-4
Mar  5 08:55:35 check-missing-firmware: looking for firmware file isl3886usb 
requested by usb
Mar  5 08:55:35 check-missing-firmware: missing firmware files (isl3886usb 
isl3886usb) for iwlwifi usb
Mar  5 08:55:35 check-missing-firmware: mainloop iteration #1
Mar  5 08:55:35