Bug#1031754: ncmpc-lyrics: missing dependencies on python3-bs4 and python3-requests

[Diederik de Haas]

Package: ncmpc-lyrics
Version: 0.47-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On a barebones (arm64) system I installed (mpd,) ncmpc and ncmpc-lyrics
and when I switched to the lyrics tab/screen, I got the following error:

==
*** 20-azlyrics.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//20-azlyrics.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 30-karaoke_texty.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//30-karaoke_texty.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 40-tekstowo.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//40-tekstowo.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 50-genius.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//50-genius.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 51-supermusic.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//51-supermusic.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 52-zeneszoveg.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//52-zeneszoveg.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 60-google.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//60-google.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'
==

After installing the `python3-bs4` and `python3-requests` packages the lyrics
screen seem to work properly. It also installed several dependency packages
(and/or recommends), so it may be that more packages should be added
explicitly to its dependencies.

(This bug is reported from another system as that had reportbug already
properly installed and configured, so it was easier)

Cheers,
  Diederik

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

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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ncmpc-lyrics depends on:
ii  ncmpc  0.47-1
ii  python33.11.2-1
ii  python3-unidecode  1.3.6-1

ncmpc-lyrics recommends no packages.

ncmpc-lyrics suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY/VkwgAKCRDXblvOeH7b
bgthAQCT8uLwevUZwESKM+9/E6qgXd0i6YBgXJBHmW7jdo8wjgEA4dgyOaVOPE1C
NOCq6ZIdDl+dtWmBxZRWqE0S6/dMSQc=
=U/Vr
-END PGP SIGNATURE-

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Diederik de Haas]

On Monday, 20 February 2023 01:07:29 CET Samuel Thibault wrote:
> Diederik de Haas, le lun. 20 févr. 2023 00:38:28 +0100, a ecrit:
> > On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> > > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > > > Some people on debian-accessibility wanted to install debian in
> > > > > arm64 under the utm wrapped qemu on Macos. The current installation
> > > > > images however do not include sound drivers and speakup.
> > > > 
> > > > Currently working on a MR to achieve that, but ...
> > > > 
> > > > > ... indeed, it seems these modules are getting built only for
> > > > > amd64, 686, mips, sh4.
> > > > 
> > > > ... this architecture list seems rather random? Why not also add it to
> > > > f.e. armhf, which itself is also a rather random
> > > > not-previously-enabled-arch?
> > > 
> > > I don't see why we shouldn't indeed. If some drivers didn't make sense
> > > on these archs they would rather be disabled by the arch configuration
> > > anyway. Speakup itself is portable and should be working on any arch,
> > > provided it has a virtual console.
> > > 
> > > The only historical reason I can see is that it was enabled only for
> > > architectures which have a gtk installer image (for which we consider
> > > that size doesn't matter).
> > 
> > On https://www.debian.org/devel/debian-installer/ I checked the links
> > under "other images (netboot, USB stick, etc.)" for the presence of a
> > "netboot/gtk/" folder and that turned out to be arm64 and armhf, so I'll
> > only add those.
> > 
> > If other arches should be added too, that can be done later.
> 
> I'm just thinking that probably people won't actually do it. That's what
> happened for arm64: see commit ea37896526075fb9d0f453ec537536149ea97d16
> which copied over the gtk configuration, but left speakup/sound
> commented, most probably just because the package was not available, and
> only now, 4 years later, we notice the missing feature.

As mentioned in my other reply, I submitted a MR for the kernel side here:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/661

But it looks like something needs to be done on the d-i side as well.
But I'm not willing to do that. I'm not familiar with d-i's code/inner working 
and when comparing arm64.cfg with armhf.cfg in netboot/gtk folder I saw 
differences and I don't know why that is.

Diederik

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

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Diederik de Haas]

Control: tag -1 -moreinfo

On Monday, 20 February 2023 00:38:28 CET Diederik de Haas wrote:
> On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > > Some people on debian-accessibility wanted to install debian in arm64
> > > > under the utm wrapped qemu on Macos. The current installation images
> > > > however do not include sound drivers and speakup.
> > > 
> > > Currently working on a MR to achieve that, but ...
> > > 
> > > > ... indeed, it seems these modules are getting built only for
> > > > amd64, 686, mips, sh4.
> > > 
> > > ... this architecture list seems rather random?
> 
> On https://www.debian.org/devel/debian-installer/ I checked the links under
> "other images (netboot, USB stick, etc.)" for the presence of a
> "netboot/gtk/" folder and that turned out to be arm64 and armhf, so I'll
> only add those.
> 
> If other arches should be added too, that can be done later.

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

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

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Diederik de Haas]

On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > Some people on debian-accessibility wanted to install debian in arm64
> > > under the utm wrapped qemu on Macos. The current installation images
> > > however do not include sound drivers and speakup.
> > 
> > Currently working on a MR to achieve that, but ...
> > 
> > > ... indeed, it seems these modules are getting built only for
> > > amd64, 686, mips, sh4.
> > 
> > ... this architecture list seems rather random? Why not also add it to
> > f.e.
> > armhf, which itself is also a rather random not-previously-enabled-arch?
> 
> I don't see why we shouldn't indeed. If some drivers didn't make sense
> on these archs they would rather be disabled by the arch configuration
> anyway. Speakup itself is portable and should be working on any arch,
> provided it has a virtual console.
> 
> The only historical reason I can see is that it was enabled only for
> architectures which have a gtk installer image (for which we consider
> that size doesn't matter).

On https://www.debian.org/devel/debian-installer/ I checked the links under
"other images (netboot, USB stick, etc.)" for the presence of a "netboot/gtk/" 
folder and that turned out to be arm64 and armhf, so I'll only add those.

If other arches should be added too, that can be done later.

Cheers,
  Diederik

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

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Diederik de Haas]

Control: tag -1 +moreinfo

On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> Some people on debian-accessibility wanted to install debian in arm64
> under the utm wrapped qemu on Macos. The current installation images
> however do not include sound drivers and speakup.

Currently working on a MR to achieve that, but ...

> ... indeed, it seems these modules are getting built only for
> amd64, 686, mips, sh4.

... this architecture list seems rather random? Why not also add it to f.e. 
armhf, which itself is also a rather random not-previously-enabled-arch? 

(Explicitly) CC-ing debian-boot as there may be other factors I'm not aware of 
and/or other considerations to be taken into account.

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

Bug#287371: xsltproc: Probable memory leak (when using document()?)

[Diederik de Haas]

Control: tag -1 -security
Control: severity -1 wishlist

On vrijdag 17 februari 2023 23:47:55 CET you wrote:
> And the final message in this bug is that you run Out Of Memory, so the OOM
> killer does exactly what it needs to do: kill other programs.

It may be annoying, but the system is working as it should be/do, so I'm 
removing the 'security' tag.
If this bug turns out to be an actual security issue and there is thus a CVE, 
the tag can be added back.

> I'll leave changing the severity to the maintainer, but 'wishlist' seems
> appropriate to me.

It was earlier concluded, including by OP, that this was a wishlist type of 
bug and it was previously already set to that, so there is no need to postpone 
setting an appropriate severity level.

FTR: I'm not contesting that you may have found a valid bug.
In upstream's 1.1.36 there seems to be at least 1 fix for a potential memory 
leak (IIUC). 
But the lack of cooperation by OP combined with the severity and the age of 
the bug, did (apparently) bug me.

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

Bug#287371: xsltproc: Probable memory leak (when using document()?)

[Diederik de Haas]

Control: tag -1 unreproducible

On Wed, 9 Feb 2005 17:12:21 +0100 Mike Hommey  wrote:
> On Dec 27, 2004, Vincent Lefevre  wrote:
> > Package: xsltproc
> > Version: 1.1.8-5
> > 
> > Here xsltproc takes up to 138 MB, making the whole system slow down
> > due to swapping. This problem occurs when generating my blog page,
> > where a document() is used for each blog item (this will change in
> > the future, but the current behavior shouldn't occur). The sources
> > are in a DocBook-based DTD that can be downloaded from
> > 
> >   http://www.vinc17.org/DTD/website.dtd
> > 
> > I'm not including the XML sources since this is quite complicated
> > (lots of inclusions and dependencies). But if the bug is not known,
> > I could try to build a simpler example.
> 
> How big is the document you load with document() ? How many times it
> gets loaded ? Could you provide me the files ?

The year is 2023, which means that 18 YEARS ago you were asked to provide a 
sample document ... which still hasn't happened.
It was reported again xslt version 1.1.8-5 with some mention of version 
2.6.16-1 of libxml2 ... both are ANCIENT, but no newer 'found' version was 
reported.

Just for fun, I downloaded your dtd (attached) and noticed a MathML entity 
which refers to DTD: "http://www.w3.org/TR/MathML2/dtd/mathml2.dtd
Trying to load that document gives a 404, but I found the following:
https://www.w3.org/TR/MathML2/appendixa.html#parsing.usingdtdt

My XML knowledge is a bit rusty, but that means your *custom made* DTD is 
invalid? 

On Sat, 19 Feb 2022 18:28:00 +0100 Vincent Lefevre  wrote:
> I'll test again (I've been using a fake DTD for the past 15 years).

IOW: you're not using your own DTD ... otherwise you might have noticed it's 
no longer valid?

What I do recall from when I was full into XML and related technologies is 
that it indeed uses a lot of memory.
As mentioned in 2005, 138MB is not considered *that* much.
And in 2023 that is even more true.

But you have a machine with *unspecified* but apparently very limited resources 
and there you try to load a *custom made* DTD which is probably quite complex 
(MathML can't be simple AFAIK).
"What could possibly go wrong (tm)"

On Sat, 19 Feb 2022 18:01:52 +0100 Mattia Rizzolo  wrote:
> If you believe so, and you confirmed that it hasn't been fixed in the
> past 15 years, could you please either (or both):
>  * report it to mitre's CVE form
>  * report it in https://gitlab.gnome.org/GNOME/libxml2/-/issues
> ?

That request was made a YEAR ago, but I'm not seeing a 'forwarded'? Or a link 
to a CVE item?

And the final message in this bug is that you run Out Of Memory, so the OOM 
killer does exactly what it needs to do: kill other programs.
But yet, you conclude that this is all xsltproc's fault?

There was no action on this bug for ~ 17 years, any requested information was 
not provided, the issue was not made reproducible, it was not reported 
upstream and I'm probably 'forgetting' a few items.

How in the world could this possibly be considered Release Critical?

I'll leave changing the severity to the maintainer, but 'wishlist' seems 
appropriate to me.

website.dtd
Description: application/xml-dtd


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

Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices

[Diederik de Haas]

On Thu, 28 Apr 2022 20:47:02 +0200 Cyril Brulebois  wrote:
> Package: raspi-firmware
> Version: 1.20210303+ds-2
> Severity: important

It would be useful to know what the current status is (for Bookworm) with 
version 1.20220830+ds-1 and ideally also with upstream's 1.20230106.

(I really hope upstream releases another version as they've now also switched 
to the 6.1 kernel series)

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

Bug#1031356: pinctrl: linux-image-6.1.0-3-amd64 : kernel NULL pointer dereference with intel pinctrl driver

[Diederik de Haas]

On Wednesday, 15 February 2023 16:53:49 CET Frederic Buisson wrote:
> Package: src:linux
> Version: 6.1.8-1
> Severity: important
> File: pinctrl

Please try the 6.1.12-1 version when it becomes available to you.
There are several pinctrl fixes in that version.

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

Bug#1031229: libapache2-mod-svn: https:///svn returns 503 with SVNParentPath enabled

[Diederik de Haas]

Package: libapache2-mod-svn
Version: 1.14.2-4+b2
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I installed libapach2-mod-svn and configured it following the nicely
documented features :-)
However after I then browsed to https:///svn and
hoping/expecting to see a list of the available repositories,
I got a 503 error instead.

After adding `SVNListParentPath on`, I did see the list of repos.
So I made the following patch so it could be available for everyone:

```patch
diff --git a/debian/dav_svn.conf b/debian/dav_svn.conf
index 94098cb..a063fdb 100644
- --- a/debian/dav_svn.conf
+++ b/debian/dav_svn.conf
@@ -22,6 +22,10 @@
   # You need either SVNPath or SVNParentPath, but not both.
   #SVNParentPath /var/lib/svn

+  # To allow users to see/browse all repositories under '/svn',
+  # enable the following setting
+  #SVNListParentPath on
+
   # Access control is done at 3 levels: (1) Apache authentication, via
   # any of several methods.  A "Basic Auth" section is commented out
   # below.  (2) Apache  and , also commented out
```

Cheers,
  Diederik

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

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

Versions of packages libapache2-mod-svn depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.55-1
ii  libc6   2.36-8
ii  libsvn1 1.14.2-4+b2

libapache2-mod-svn recommends no packages.

Versions of packages libapache2-mod-svn suggests:
pn  db5.3-util  

- -- Configuration Files:
/etc/apache2/mods-available/dav_svn.conf changed:

  # Uncomment this to enable the repository
  DAV svn
  # Set this to the path to your repository
  #SVNPath /var/lib/svn
  # Alternatively, use SVNParentPath if you have multiple repositories under
  # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...).
  # You need either SVNPath or SVNParentPath, but not both.
  #SVNParentPath /var/lib/svn
  SVNParentPath /srv/data/svn
  SVNListParentPath on
  # Access control is done at 3 levels: (1) Apache authentication, via
  # any of several methods.  A "Basic Auth" section is commented out
  # below.  (2) Apache  and , also commented out
  # below.  (3) mod_authz_svn is a svn-specific authorization module
  # which offers fine-grained read/write access control for paths
  # within a repository.  (The first two layers are coarse-grained; you
  # can only enable/disable access to an entire repository.)  Note that
  # mod_authz_svn is noticeably slower than the other two layers, so if
  # you don't need the fine-grained control, don't configure it.
  # Basic Authentication is repository-wide.  It is not secure unless
  # you are using https.  See the 'htpasswd' command to create and
  # manage the password file - and the documentation for the
  # 'auth_basic' and 'authn_file' modules, which you will need for this
  # (enable them with 'a2enmod').
  #AuthType Basic
  #AuthName "Subversion Repository"
  #AuthUserFile /etc/apache2/dav_svn.passwd
  # To enable authorization via mod_authz_svn (enable that module separately):
  #
  #AuthzSVNAccessFile /etc/apache2/dav_svn.authz
  #
  # The following three lines allow anonymous read, but make
  # committers authenticate themselves.  It requires the 'authz_user'
  # module (enable it with 'a2enmod').
  
Require valid-user
   



- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY+pXnAAKCRDXblvOeH7b
boQCAQDziAdZG5joqOMPemltQYoMW0YoFbja/Pr54OBNMvqXqQD9H6ToUiyK+LJ6
GJ6NxLPiZmlZude+8Li3ixVhDnMtsAc=
=CJJs
-END PGP SIGNATURE-

Bug#1017977: Fails to load intel/ibt-20-1-3.sfi

[Diederik de Haas]

On Sunday, 12 February 2023 03:29:14 CET Olaf Meeuwissen wrote:
> Olaf Meeuwissen  writes:
> > Just checked again with 6.1.7-1 and still no joy :-(
> 
> Glad to report joy cold-booting linux-image-6.1.0-3-amd64.
> Currrently have the following installed

That's great!

> I checked the changelog but did not find anything obviously related, but
> maybe one of these upstream stable updates
> 
>   - wifi: iwlwifi: fw: skip PPAG for JF
>   - Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2
> 
> fixed it?

I looked into them, but didn't find a direct link. But hopefully the issue is 
fixed now.

If the issue does come back, then I'd suggest doing a `git bisect` between 
v5.18.14 and v5.18.16 as that's where the initial problem surfaced and it also 
has the benefit of being a reasonably small range.
https://wiki.debian.org/DebianKernel/GitBisect has instructions for it.

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

Bug#1029445: fixed

[Diederik de Haas]

On Thu, 2 Feb 2023 00:06:42 +0100 Santiago Garcia Mantinan  
wrote:
> fixed 1029445 1.7.1-1

Shouldn't it be also be send to -done as it's still listed as an open bug?

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

Bug#1031137: bridge-utils: No longer recognizes alternative NIC name (enp5s0)

[Diederik de Haas]

Package: bridge-utils
Version: 1.7.1-1
Severity: important

I have bridge-utils configured on my Xen server (with SysV-init) and
after today's upgrade round and subsequent reboot, networking did not
come up again.
With that upgrade round bridge-utils went from 1.7-1 to 1.7.1-1.
That server has an iKVM module so I could still access it and found that
`brctl show` did not show any interfaces.

While I do have `net.ifnames=0` in my cmdline I (somehow?) was still
using `enp5s0` in my /etc/network/interfaces file and that worked before.
When I did `brctl addif xenbr0 enp5s0` I did get an interface in
`brctl show`, but it was named `eth0`.

After changing /e/n/i to use `eth0` instead of `enp5s0` and doing
`/etc/init.d/networking restart` everything was working again.
I know there were some changes wrt IPv6 handling, but I'm using IPv4.

The previous kernel was 6.1.4 (6.1.0-1-amd64) so I doubt that that
upgrade triggered this issue, so my guess is that it's 1.7-1 to 1.7.1-1.

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

Kernel: Linux 6.1.0-4-amd64 (SMP w/32 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bridge-utils depends on:
ii  libc6  2.36-8

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.41

-- no debconf information

Bug#979977: [Pkg-raspi-maintainers] Bug#979977: raspi-firmware: Seems to ignore latest installed kernel (5.10.0-1-armmp-lpae) while the booting kernel is older (5.10.0-trunk-armmp-lpae)

[Diederik de Haas]

On Wednesday, 9 November 2022 14:42:01 CET Diederik de Haas wrote:
> On Thu, 28 Jan 2021 11:04:29 -0600 Gunnar Wolf  wrote:
> > Now... What to do here? I think dpkg --compare-versions here agreees
> > 
> > with the simplistic ordering set by ls:
> >  $ if dpkg --compare-versions 5.10.0-trunk-armmp-lpae gt
> >  5.10.0-1-armmp-lpae
> >  then
> > echo trunk is larger
> >  else
> >  echo 1 is larger
> >  fi
> >  trunk is larger
> > 
> > How would you suggest to check for this?
> 
> Merging https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/27 ?
> IOW: use the kernel tooling to compare kernel versions.

The kernel-team no longer uses '-trunk' for non-ABI-tracked kernels (usually 
uploaded to Experimental), but uses '-0' now.
Which means that simple comparison that is currently used, should no longer 
give the wrong result.

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

Bug#1030914: firmware-brcm80211 causes system to freeze and reboot

[Diederik de Haas]

On Thursday, 9 February 2023 05:17:24 CET Mathirajan S. Manoharan wrote:
> Package: firmware-brcm80211
> Version: 20221214-5
> 
> My system has the following network card
> 02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43225
> 802.11b/g/n [14e4:4357] (rev 01)
> 
> If i install the firmware for this card (firmware-brcm80211), the system
> freezes and reboots by itself.

Unstable has version 20230117-2. Does the problem still occur with that?
If so, via https://snapshot.debian.org/binary/firmware-brcm80211/ you can find 
older versions. It could/would be useful to know with which version it does 
work as expected.

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

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Diederik de Haas]

Hi Salvatore,

On Sunday, 5 February 2023 16:17:58 CET Salvatore Bonaccorso wrote:
> > > So I guess we can close this bug here, and the files can be shipped
> > > with a new dedicated source package containing the firmware files,
> > > since the last option of having them merged upstream in
> > > linux-firmware.git seems unrealistic for now?
> > 
> > We could do that, but wouldn't it make more sense to reassign it to wnpp
> > (?) and turn it into a RFP type bug?
> > 
> > That way we would preserve the history (and thus useful info) of this
> > issue.
> Sure, we can do that as well. Drawback is that the initial mail does
> not contain the details for the RFP, but it is a sensible idea.

Please follow your initial idea. If need be, we can always reference this bug 
in the new RFP bug. It's not like closing this bug will make it disappear from 
the face of the earth ;-)

You (seem to) know what can and needs to be done, while I don't.

Regards,
  Diederik

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

Bug#1030595: linux-image-6.1.0-3-amd64: impossible to install properly the kernel linux-image-6.1.0-3-amd64, and in facts, linux-image-6.1.0-2-amd64

[Diederik de Haas]

Control: reassign -1 dkms

On Sunday, 5 February 2023 14:19:43 CET Eric Streit wrote:
> Package: src:linux
> Version: 6.1.8-1
> **
> Paramétrage de linux-image-6.1.0-3-amd64 (6.1.8-1) ...
> I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-3-amd64
> /etc/kernel/postinst.d/dkms:
> dkms: running auto installation service for kernel 6.1.0-3-amd64:Sign
> command: /lib/modules/6.1.0-3-amd64/build/scripts/sign-file
> Binary /lib/modules/6.1.0-3-amd64/build/scripts/sign-file not found, modules
> won't be signed
> Error! Your kernel headers for kernel 6.1.0-3-amd64 cannot be found at
> /lib/modules/6.1.0-3-amd64/build or /lib/modules/6.1.0-3-amd64/source.
> Please install the linux-headers-6.1.0-3-amd64 package or use the
> --kernelsourcedir option to tell DKMS where it's located.
> Error! One or more modules failed to install during autoinstall.
> Refer to previous errors for more information.
>  failed!
> run-parts: /etc/kernel/postinst.d/dkms exited with return code 11

Not a kernel problem. You should install the appropriate kernel-headers and/or 
dkms should ensure that, instead of failing the kernel-image installation.

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

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Diederik de Haas]

On Saturday, 4 February 2023 22:12:24 CET Salvatore Bonaccorso wrote:
> > Right, I agree this should be a package of its own. I didn't know
> > raspi-nonfree came from a "coherent" set of firmware sources provided
> > by a single upstream. It is a distorsion that peopleinterested in
> > brcmfmac firmware have to install raspi-firmware if they have
> > different hardware.
> 
> So I guess we can close this bug here, and the files can be shipped
> with a new dedicated source package containing the firmware files,
> since the last option of having them merged upstream in
> linux-firmware.git seems unrealistic for now?

We could do that, but wouldn't it make more sense to reassign it to wnpp (?) 
and turn it into a RFP type bug?

That way we would preserve the history (and thus useful info) of this issue.

My 0.02

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

Bug#1029968: bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3e0/0x4d0

[Diederik de Haas]

On Saturday, 4 February 2023 02:06:02 CET Dr. David Alan Gilbert wrote:
> a) The patch I bisected to is not the root cause of the bug; it just
> triggers a ~9 year old bug in the v4l code - so this patch isn't going
> to get changed.
> 
> b) The ~9 year old bug is in a particularly hairy piece of memory management
> code  in v4l that I doubt anyone is going to fix.
> 
> c) The plan is all the drivers using that API are to either be retired
> or rewritten using a new API; that's already been done for some of the
> drivers and the bttv one is a few months out.  I'm not sure that's
> any use to this version of Debian though.
> 
> d) The work arounds are:
>   1) Disable iommu
>   2) some v4l tools can use an mmap interface rather than the read(2)
> interface; that seems to be OK.

Also reading the upstream conversation, that seems like a good summary :)

I could be wrong (ofc), but I doubt this issue will be fixed in kernel 6.1 
which is planned to be Bookworm's kernel.

What you could do is test any patch(es) they put out and provide feedback on 
those and if you find that the patch(es) fixes the/your issue, you could 
consider providing a "Tested-By: yourname " which can have a 
positive effect on the maintainer accepting the patch from which it then can 
procede further up the chain to Linus.
When it does end up in Linus' tree and it would need to have a new Kconfig 
option enabled in Debian's kernel, feel free to request that.

I think IOMMU is a really good thing, so disabling that does not sound ideal, 
but it could be an acceptable workaround (for now).
If you want to run Bookworm on your system, you'd probably have to wait till a 
suitable Backports kernel becomes available. If you go for Trixie, you should 
get (in time) the proper fix by just upgrading.

Thanks for all the investigative work and bringing it to upstream :-)

Cheers,
  Diederik

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

Bug#953790: quassel-client: Typo in spanish translation

[Diederik de Haas]

On 2 January 2023 20:21:04 CET Lisandro Damián Nicanor Pérez Meyer wrote:
> Control: forwarded -1 https://github.com/quassel/quassel-i18n/pull/2
> 
> On 29 Dec 2022 at 21:37, Diederik de Haas  wrote:
> > On Fri, 13 Mar 2020 10:31:57 -0300 Lisandro Damián Nicanor Pérez Meyer
> 
> > Could you try again at https://github.com/quassel/quassel-i18n/pulls ?
> > They recently did merge an update to German translation there.
> 
> Done, let's see how it goes.

A 'bit' disappointing that it's still not merged after a month ... :-/

Upstream quassel doesn't look good in general given there were only 12 commits 
last year ... of which a substantial part relating to CI.

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

Bug#1029968: Info received (Bug#1029968: Info received (Bug#1029968: Info received (Bug#1029968: Acknowledgement (bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/

On Wednesday, 1 February 2023 18:46:43 CET Dr. David Alan Gilbert wrote:
> I sent this upstream report:
> https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/T/#u

Thanks :-) Updated bug accordingly.

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

Bug#1029968: Acknowledgement (bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3e0/0x4d0)

[Diederik de Haas]

On Wednesday, 1 February 2023 02:52:13 CET Dr. David Alan Gilbert wrote:
> bisected:
> GOOD [37fcacb50be7071d146144a6c5c5bf0194b9a1cf] phy: PHY_FSL_LYNX_28G should
> depend on ARCH_LAYERSCAPE BAD [f5ff79fddf0efecca538046b5cc20fb3ded2ec4f]
> dma-mapping: remove CONFIG_DMA_REMAP GOOD
> [e62c17f0455a74b182ce6373e2777817256afaa1] MAINTAINERS: update maintainer
> list of DMA MAPPING BENCHMARK GOOD
> [0fb3436b4b36cf69f4544385aa2bb8c5a4913509] sparc: Remove usage of the
> deprecated "pci-dma-compat.h" API GOOD
> [fba09099c6e506608e05e08ac717bf34501f821b] media: v4l2-pci-skeleton: Remove
> usage of the deprecated "pci-dma-compat.h" API
> 
> dg@major:~/kernel/kernel-clone$ git bisect good
> f5ff79fddf0efecca538046b5cc20fb3ded2ec4f is the first bad commit
> commit f5ff79fddf0efecca538046b5cc20fb3ded2ec4f
> Author: Christoph Hellwig 
> Date:   Sat Feb 26 16:40:21 2022 +0100
> 
> dma-mapping: remove CONFIG_DMA_REMAP
> 
> That sounds like a believable cause given that it's IOMMU related
> and device related.

Thanks for that thorough analyses!
If you're 'penguin42' on IRC, then I'd suggest to present your findings to
io...@lists.linux.dev as both the author and the reviewer are highly likely 
subscribed to that list.

scripts/get_maintainer.pl drivers/iommu/dma-iommu.c
scripts/get_maintainer.pl kernel/dma/Makefile

list them both and both results have also that ML in their result.

HTH

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

Bug#1016919: lintian: bash-term-in-posix-shell false positive for `. "$(dirname "$0")/functions.sh"`

[Diederik de Haas]

On Tuesday, 31 January 2023 22:27:24 CET Russ Allbery wrote:
> Diederik de Haas  writes:
> > I looked a little deeper/further and specifically into
> > `lib/coresight.sh` and that file does contain `echo -n`, which
> > ShellCheck does flag as it's undefined in POSIX.  So maybe it was
> > actually triggered by the 'included' file?
> > 
> > I don't know if that could also be the case for the original reporter.
> 
> Although echo -n is undefined in POSIX, Debian requires it to work in all
> shells that are eligible to be /bin/sh.  See:
> 
> https://www.debian.org/doc/debian-policy/ch-files.html#scripts

Ah, yeah, then lintian shouldn't trip over that.
I lack any Perl knowledge to (properly) understand the code snippet you posted 
earlier or what lintian does in code, so I can't help with that.

Cheers,
  Diederik

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

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Diederik de Haas]

Hi Salvatore and Gunnar,

On Tuesday, 31 January 2023 19:17:43 CET Salvatore Bonaccorso wrote:
> > Gunnar indicated that he's willing to remove the files from
> > raspi-firmware,
> > but they still need to be added to firmware-brcm80211, so pretty please?
> 
> So I looked at this, and don't think the firmware-nonfree packages
> should take it over. Why?
> The firmware files are not part of linux-firmware.git .

I understand that reasoning and as said on IRC, that was the reason that I did 
not know how to deal with that and therefor couldn't make a MR myself.

> Would they fit into a separate source package not associated with
> raspi-config?

I do strongly think they do not belong in the raspi-firmware package for the 
reason I retitled this bug and retitled my response Subject. Another reason is 
that the raspi-firmware package makes (several) assumptions, namely that they 
are only used/usable on RPi devices and have a /boot/firmware directory (where 
a FAT partition is mounted, although that part is not checked for).
I have previously expressed my concerns/doubts about that, but that's outside 
the scope of this bug.
It also looks 'weird' to install the raspi-firmware package while you only care 
about the wifi firmware and not care about RPi's at all.

> The other option is that they get included upstream in
> linux-firmware.git by upstream?

Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that 
was confirmed once again by their typical reaction to this exact request. 

I'm too 'lazy' to look it up, so I'll paraphrase it:
"It works for us (so fsck off). Can't you just use our files?"

Regards,
  Diederik

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

Bug#1016919: lintian: bash-term-in-posix-shell false positive for `. "$(dirname "$0")/functions.sh"`

[Diederik de Haas]

On Tuesday, 31 January 2023 18:10:57 CET Russ Allbery wrote:
> > I: linux-perf: bash-term-in-posix-shell '. $(dirname
> > $0)/../lib/coresight.sh'
> > [usr/lib/perf-core/tests/shell/coresight/asm_pure_loop.sh:8]
> Yeah, I think it's a false positive in this check (check_line in
> Lintian::Check::Shell::NonPosix::BashCentric):

I looked a little deeper/further and specifically into `lib/coresight.sh` and 
that file does contain `echo -n`, which ShellCheck does flag as it's undefined 
in 
POSIX.  So maybe it was actually triggered by the 'included' file?

I don't know if that could also be the case for the original reporter.

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

Bug#1016919: lintian: bash-term-in-posix-shell false positive for `. "$(dirname "$0")/functions.sh"`

[Diederik de Haas]

Package: lintian
Version: 2.116.2
Followup-For: Bug #1016919

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While inspecting lintian's output wrt (several) kernel builds I did, I
found the following warning, which seems to be a false positive?

I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/../lib/coresight.sh' 
[usr/lib/perf-core/tests/shell/coresight/asm_pure_loop.sh:8]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/../lib/coresight.sh' 
[usr/lib/perf-core/tests/shell/coresight/memcpy_thread_16k_10.sh:8]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/../lib/coresight.sh' 
[usr/lib/perf-core/tests/shell/coresight/thread_loop_check_tid_10.sh:8]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/../lib/coresight.sh' 
[usr/lib/perf-core/tests/shell/coresight/thread_loop_check_tid_2.sh:8]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/../lib/coresight.sh' 
[usr/lib/perf-core/tests/shell/coresight/unroll_loop_thread_10.sh:8]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/lib/probe.sh' 
[usr/lib/perf-core/tests/shell/probe_vfs_getname.sh:7]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/lib/probe.sh' 
[usr/lib/perf-core/tests/shell/record+probe_libc_inet_pton.sh:13]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/lib/probe.sh' 
[usr/lib/perf-core/tests/shell/record+script_probe_vfs_getname.sh:12]
I: linux-perf: bash-term-in-posix-shell '. $(dirname $0)/lib/probe.sh' 
[usr/lib/perf-core/tests/shell/trace+probe_vfs_getname.sh:13]
I: linux-perf: bash-term-in-posix-shell '. $(dirname 
$0)/lib/probe_vfs_getname.sh' 
[usr/lib/perf-core/tests/shell/probe_vfs_getname.sh:11]
I: linux-perf: bash-term-in-posix-shell '. $(dirname 
$0)/lib/probe_vfs_getname.sh' 
[usr/lib/perf-core/tests/shell/record+script_probe_vfs_getname.sh:16]
I: linux-perf: bash-term-in-posix-shell '. $(dirname 
$0)/lib/probe_vfs_getname.sh' 
[usr/lib/perf-core/tests/shell/trace+probe_vfs_getname.sh:18]

Looking at the first item:
```sh
$ cat tools/perf/tests/shell/coresight/asm_pure_loop.sh
#!/bin/sh -e
# CoreSight / ASM Pure Loop

# SPDX-License-Identifier: GPL-2.0
# Carsten Haitzler , 2021

TEST="asm_pure_loop"
. $(dirname $0)/../lib/coresight.sh
ARGS=""
DATV="out"
DATA="$DATD/perf-$TEST-$DATV.data"

perf record $PERFRECOPT -o "$DATA" "$BIN" $ARGS

perf_dump_aux_verify "$DATA" 10 10 10

err=$?
exit $err
```

Shellcheck does not flag this as having bashisms.
Searching for both `.` and `dirname` and they both seem to be POSIX compliant.
https://unix.stackexchange.com/a/253527
https://unix.stackexchange.com/a/17885

Which leads me to believe this is a false positive indeed.

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

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

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.19
ii  dpkg-dev1.21.19
ii  file1:5.44-3
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.19
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  

Bug#1029548: Warnings about collation version mismatch

[Diederik de Haas]

On 29 January 2023 18:35:14 CET, Julian Gilbey  wrote:
>> A (major) libc6 upgrade is not something that will happen on Stable, so this 
>> issue may only occur with people running Testing or Unstable.
>
>But it will happen when people upgrade their stable machines to
>bookworm once it is released.

AFAIK, that upgrade procedure is different and those users will not run into 
this issue.

Bug#1029548: Warnings about collation version mismatch

[Diederik de Haas]

On Tue, 24 Jan 2023 10:22:28 + Julian Gilbey  wrote:
> Package: postgresql-15
> Version: 15.1-1+b1
> 
> I recently started getting warnings such as the following from my
> postgresql backup script:
> 
> WARNING:  database "postgres" has a collation version mismatch
> DETAIL:  The database was created using collation version 2.35, but
> the operating system provides version 2.36.
> HINT:  Rebuild all objects in this database that use the default
> collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION,
> or build PostgreSQL with the right library version.
> 
> I don't know exactly where the source of this problem is, and there's
> no guidance as to how to fix it; for example, how do I rebuild all the
> objects in the database that use the default collation?

The fix is in the HINT and you just need to run that command:
ALTER DATABASE postgres REFRESH COLLATION VERSION

The cause for that (IIUC) is that the database was created when libc6 was at 
version 2.35 and it has since been upgraded to 2.36.

See also https://bugs.debian.org/1021074

> Something in a NEWS file or in README.Debian giving guidance would be
> very helpful here.

A (major) libc6 upgrade is not something that will happen on Stable, so this 
issue may only occur with people running Testing or Unstable.
OTOH: There are now (at least) 2 people who ran into it and didn't know what 
to do with/about it.

HTH,
  Diederik

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

Bug#889313: O: directfb -- direct frame buffer graphics library

[Diederik de Haas]

Control: affects -1 src:directfb

On 3 Feb 2018 15:42:21 +0100 Sebastian Ramacher  wrote:
> Package: wnpp
> 
> Note that upstream appears to MIA.

https://web.archive.org/web/20170603093935/http://www.directfb.net/ seems to 
be the last capture which at least shows a working home page, after that it 
seems to be all redirects to non-existing/spam stuff.

But it seems like all the links in the sidebar still don't work, including the 
link to the Source Code ...

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

Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)

[Diederik de Haas]

Hi Stuart!

On Saturday, 28 January 2023 05:18:34 CET Stuart Prescott wrote:
> On 27/01/2023 21:23, Diederik de Haas wrote:
> Your suggestion is entirely sensible and it does no harm to start with
> the updated version as you say. I'm not sure there's any functionality
> in recent commits to help with the mass conversion you describe, but it
> does no harm.

I saw you already uploaded the new version, thanks!

> > 7) Actually do the conversion
> 
> my experience was that this was not easy in itself with quite a few
> repos that were broken in some way, such as tags not being on branches,
> main not being continuous in strange ways.

Yeah, it'll probably be a headache. But better a big headache one time then 
giving each person who'd try such a thing a headache.

> create a fresh git repo with all the historical uploads using 
> gbp import-dscs --debsnap.

I'd have to import changes since the svn repos were archived, but still had to 
learn/figure out how to do that. You just made that easy, thanks!

> There are some people who did some mass conversions of repos (python
> team, qt team for instance) - perhaps it is worth reaching out to them

Great tip :-)

> > So I've now concluded that it's probably best to propose a mass-migration
> > of the Alioth repos which haven't been converted yet (and uploaded to
> > salsa). And that the Debian QA group is likely the best place to propose
> > that. Hopefully there are also ppl there with more current Subversion
> > knowledge and maybe even with converting SVN to Git.
> 
> That's a huge task! That's definitely something to discuss on the
> mailing list before you get too far into it. It would be worth
> considering what to do with packages that are no longer in Debian at
> all, for instance.

It was already a huge task for 1 repo and it's actually motivating it won't be 
for just 1, but 'all' of them. And that then no one has to care anymore.

https://lists.debian.org/debian-qa/2023/01/msg00031.html
Already got a positive reaction from a person (I met at a BSP and) who is 
knowledgeable with programmatically querying/modifying Debian infra \o/

Cheers!
  Diederik

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

Bug#1029816: wifi: mt76: mt7612u/mt7610u - 6.1.x hard locking systems

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream

On Saturday, 28 January 2023 07:22:11 CET Stuart Read wrote:
> I found this upstream bug report:
> http://lists.infradead.org/pipermail/linux-mediatek/2022-December/054010.ht
> ml
> 
> However it is unclear to me if or when the fix will be applied to the
> kernel.

It is already applied upstream and is part of upstream's 6.1.8 release:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
h=linux-6.1.y=a57c981d9f24d2bd89eaa76dc477e8ca252e22e8

Version 6.1.8 is already part of Debian kernel's git repo, but it hasn't been 
released yet. So it's coming.

HTH

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

Bug#1024831: Acknowledgement (xorg: xserver fails to resume after suspend-to-disk)

[Diederik de Haas]

Control: tag -1 moreinfo

On 26 Nov 2022 20:31:25 +0100 Klaus Singvogel  wrote:
> This issue only happens only with linux-image-6.0.0-0.deb11.2-amd64
> After I booted the old linux-image-5.19.0-0.deb11.2-amd64, the issue does
> not occur.

Does this issue still occur with version 6.0.12-1~bpo11+1 which I guess is 
linux-image-6.0.0-0.deb11.6-amd64?

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

Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)

[Diederik de Haas]

Hi Stuart!

On Friday, 27 January 2023 04:40:47 CET Stuart Prescott wrote:
> On 27/01/2023 09:17, Diederik de Haas wrote:
> > Package: svn-all-fast-export
> > Version: 1.0.18+git20200501-1
> > Severity: wishlist
> > 
> > It would be great if the latest version could be packaged for Debian.
> > I recently had the need to retrieve a repo from the alioth archive and
> > convert it to git. And this sounds like a great tool for that where
> > upstream has even worked on the code in the last couple of years ;-)
> > 
> > Anything that could make that task easier would be appreciated and a
> > newer version of svn-all-fast-export may just help.
> 
> Upstream doesn't often make releases and so the "new upstream"
> notification from the watch file is only about new commits being made to
> the upstream repo, not a new version being available.

I did deliberately use 'version', while I'd normally use 'release' for these 
type of bugs ;-)

> Most of the recent upstream activity has been about CI on GitHub and not
> actual changes to the package.

Yep, I did see that. But I did see there were also non-GH-CI related commits.
I filed the bug for 2 reasons:
- I think it's generally good to have the latest release/version in for the 
next Stable release (and I assumed it wouldn't be too difficult in this case).
- What I described in the initial report and will expand on below ...

> Is there anything in the recent commits that would help you? I hadn't
> seen anything to justify updating the package but if there's something
> specific, please say and we can do it.

TL;DR: I lack the knowledge to determine that, so I don't *know*.
If you determine there isn't anything useful, feel free to close this bug.

I'll (very) likely try to make the issue(s) I ran into wider and send a mail 
about it to the debian-qa ML, but (the long version is) ...

In order to adopt 'id3lib' (src:id3lib3.8.3):
1) I need to learn about Subversion, which hopefully is a bit easier *for me* 
as I had used and set up a Subversion server myself ... 
but that was certainly >10 YEARS ago, possibly close to 20.
2) I had rightly *guessed* there was an archive and 'muon' kindly pointed me 
to it ... the 'collab-maint' archive was (ofc) ~880 MB in size.
3) I did know about (TurtoiseSVN and) kdesvn and I found out (yesterday) that 
I could indeed see the repo, which hopefully will help a bit
4) Then the big thing: I want/need to convert it to git and I (highly) prefer 
if I can restore as much of its history as possible.
But I don't know which tools are available and which are in a decent enough 
shape, hence why I used 'recent commits' as a criteria. I generally think 
using CI is a good thing, but also concluded that the recent GH CI commits 
were irrelevant for my purpose. But I completely lack the knowledge to 
evaluate the commits that were done before those.
They may be irrelevant, but the issue is: I don't *know*.
5) I already learned I should (try to) create some mapping file to translate 
svn committers into git committers. And that I need to learn about the 
configuration file I should give to svn-all-fast-export as it (apparently) 
needs 
more info to make the conversion to git.
6) I should probably do the same for other svn-to-git-conversion-tools 
precisely as I don't know how good one tools is, which IIUC also depends on 
how SVN was used ...
7) Actually do the conversion
8) Upload it to salsa, which should be easy.
9) Oh wait, yeah, I almost forgot: the goal was to potentially adopt a 
package, so actually do something with the package ;-P

And all that to potentially adopt 1 package!

And everyone who thinks about adopting a package which was previously stored 
on Alioth, will have to go through that too.
And I have previous knowledge about SVN, a reasonably fast internet connection 
which is (AFAIK) also unmetered/unlimited, which not everyone has.

Any sane person would've long bailed out, likely already at step 1;-)

So I've now concluded that it's probably best to propose a mass-migration of 
the Alioth repos which haven't been converted yet (and uploaded to salsa).
And that the Debian QA group is likely the best place to propose that.
Hopefully there are also ppl there with more current Subversion knowledge and 
maybe even with converting SVN to Git.

But it would still be useful if the potential tools for that are in the best 
shape possible, so having the latest commit(s) of svn-all-fast-export packaged 
*may* be useful. But as said before: I lack the knowledge to determine that.

Regards,
  Diederik


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

Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)

[Diederik de Haas]

Package: svn-all-fast-export
Version: 1.0.18+git20200501-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It would be great if the latest version could be packaged for Debian.
I recently had the need to retrieve a repo from the alioth archive and
convert it to git. And this sounds like a great tool for that where
upstream has even worked on the code in the last couple of years ;-)

Anything that could make that task easier would be appreciated and a
newer version of svn-all-fast-export may just help.

Cheers,
  Diederik

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

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

Versions of packages svn-all-fast-export depends on:
ii  git   1:2.39.0-1
ii  libapr1   1.7.0-8
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libqt5core5a  5.15.8+dfsg-2
ii  libstdc++612.2.0-14
ii  libsvn1   1.14.2-4+b1

svn-all-fast-export recommends no packages.

svn-all-fast-export suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY9L73QAKCRDXblvOeH7b
btM6AQC8bi1gBYJt05Yr2ktw2pBmv7H2ppBPFcfR9VsFSmzKRAEAp+BgjVQLPkMq
yY5WjM1b0inaVc2s1SeKHWZVPp1hsQk=
=GJht
-END PGP SIGNATURE-

Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Diederik de Haas]

On Wednesday, 25 January 2023 23:01:01 CET Diederik de Haas wrote:
> This sounds like a nice solution for the SD card images.
> I myself always use a wired connection, but I saw yesterday that someone
> tried to use d-i for RockPro64 but didn't get any output on screen and then
> tried again using their TV ... but then it needed to use a wireless
> connection and I actually had no idea how that could/should be provided
> during install.
> 
> Giving ppl the option to concat a firmware archive if they need it, sounds
> like an elegant solution to me :-)

Please ignore me. Apparently I didn't fully and/or properly understand.
The ('wireless') firmware archive is likely to be very involved to construct, 
let alone other issues (like size) it may add.

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

Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Diederik de Haas]

On Wednesday, 25 January 2023 20:22:33 CET Cyril Brulebois wrote:
> # SD card images (might also be applicable to the upcoming ChromeOS images)
> ...
> All of this assuming that the end results can be appended as the third
> part of the  +  +  combination!

This sounds like a nice solution for the SD card images.
I myself always use a wired connection, but I saw yesterday that someone tried 
to use d-i for RockPro64 but didn't get any output on screen and then tried 
again using their TV ... but then it needed to use a wireless connection and I 
actually had no idea how that could/should be provided during install.

Giving ppl the option to concat a firmware archive if they need it, sounds like 
an elegant solution to me :-)

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

Bug#1029584: Info received (Bug#1029584: Info received (Bug#1029584: Acknowledgement (linux-image-6.1.0-1-amd64: Mouswheel reports way too many events with Debian kernel config)))

[Diederik de Haas]

Control: tag -1 upstream
Control: forwarded -1 
https://gitlab.freedesktop.org/libinput/libinput/-/issues/852

On 25 January 2023 17:52:10 CET, Tobias Klausmann  
wrote:
>Also reported to libinput upstream:
>
>https://gitlab.freedesktop.org/libinput/libinput/-/issues/852

Thanks! Updated bug metadata accoedingly

Bug#1029602: vmwgfx: kernel oops when using fbterm in vmware

[Diederik de Haas]

Control: found -1 5.10.162-1

On Wednesday, 25 January 2023 11:18:35 CET Keyu Tao wrote:
> [  214.783069] CPU: 0 PID: 372 Comm: kworker/0:4 Kdump: loaded Not tainted
> 5.10.0-21-amd64 #1 Debian 5.10.162-1



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

Bug#1029507: linux-image-6.1.0-1-amd64 isn't installable

[Diederik de Haas]

Control: reassign -1 dkms
Control: forcemerge 1029063 -1

On Monday, 23 January 2023 14:53:18 CET Stefano Simonucci wrote:
> Building module:
> Cleaning build area...
> make -j8 KERNELRELEASE=6.1.0-1-amd64 all
> KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b uild...(bad exit status: 2)
> Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
> Consult /var/lib/dkms/anbox-binder/1/build/make.log for more information.

This isn't a kernel issue, but an issue with anbox-binder which apparently is 
incompatible with kernel 6.1. Reassigning/merging accordingly.

It could be https://github.com/anbox/anbox-modules/issues/104 or if you're 
using https://github.com/Barronli/anbox_binder then it already says in the 
README.md: "Note it is already out of sync from Linux kernel tree, but it is 
still useful in certain situations."

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

Bug#968757: command-not-found: breaks apt-get update

[Diederik de Haas]

Package: command-not-found
Version: 20.10.1-1
Severity: critical
Justification: Breaks unrelated software
Followup-For: Bug #968757

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 01 Sep 2020 15:59:09 +0800 Paul Wise  wrote:
> Control: severity -1 important
> 
> Downgrading this because it does not happen in Debian, only in Debian
> derivatives other than Ubuntu. This happens because it hard-codes
> component priorities and does not have priority values for components
> other than the ones that Debian and Ubuntu use.

Upping the severity (hopefully) as it now does happen in Debian, since 2
days with the following error:

root@bagend:~# aptitude update
Hit http://deb.debian.org/debian bullseye InRelease
Get: 1 http://deb.debian.org/debian testing InRelease [164 kB]
Get: 2 http://deb.debian.org/debian sid InRelease [161 kB]
Get: 3 http://deb.debian.org/debian experimental InRelease [97.5 kB]
Get: 4 http://deb.debian.org/debian testing/main amd64 Packages.diff/Index 
[63.6 kB]
Get: 5 http://security.debian.org/debian-security bullseye-security InRelease 
[48.4 kB]
Get: 6 http://debug.mirrors.debian.org/debian-debug unstable-debug InRelease 
[56.7 kB]
Get: 7 http://deb.debian.org/debian testing/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get: 8 http://deb.debian.org/debian sid/main Sources.diff/Index [63.6 kB]
Get: 9 http://deb.debian.org/debian sid/non-free Sources.diff/Index [63.3 kB]
Get: 10 http://deb.debian.org/debian sid/main amd64 Packages.diff/Index [63.6 
kB]
Get: 11 http://deb.debian.org/debian sid/main Translation-en.diff/Index [63.6 
kB]
Get: 12 http://deb.debian.org/debian sid/main all Contents (deb).diff/Index 
[63.8 kB]
Get: 13 http://deb.debian.org/debian sid/main amd64 Contents (deb).diff/Index 
[63.8 kB]
Get: 14 http://deb.debian.org/debian sid/contrib Translation-en.diff/Index 
[63.3 kB]
Get: 15 http://deb.debian.org/debian sid/non-free amd64 Packages.diff/Index 
[63.3 kB]
Get: 16 http://deb.debian.org/debian experimental/main amd64 
Packages.diff/Index [63.3 kB]
Get: 17 http://deb.debian.org/debian experimental/main 
Translation-en.diff/Index [63.3 kB]
Get: 18 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get: 19 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get: 20 http://deb.debian.org/debian experimental/contrib amd64 
Packages.diff/Index [63.3 kB]
Get: 21 http://deb.debian.org/debian experimental/contrib 
Translation-en.diff/Index [63.3 kB]
Get: 22 http://deb.debian.org/debian experimental/contrib amd64 Contents 
(deb).diff/Index [62.8 kB]
Get: 23 http://deb.debian.org/debian experimental/non-free 
Translation-en.diff/Index [63.3 kB]
Get: 24 http://deb.debian.org/debian experimental/non-free all Contents 
(deb).diff/Index [61.4 kB]
Get: 25 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages.diff/Index [63.6 kB]
Get: 26 http://deb.debian.org/debian testing/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [458 B]
Get: 27 http://deb.debian.org/debian testing/main amd64 Contents (deb) 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [70 B]
Get: 28 http://deb.debian.org/debian sid/main Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [22.9 kB]
Get: 29 http://deb.debian.org/debian sid/non-free Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [346 B]
Get: 30 http://deb.debian.org/debian testing/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [458 B]
Get: 31 http://deb.debian.org/debian sid/non-free Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [346 B]
Get: 32 http://deb.debian.org/debian sid/main Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [22.9 kB]
Get: 33 http://deb.debian.org/debian testing/main amd64 Contents (deb) 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [70 B]
Get: 34 http://deb.debian.org/debian sid/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.0 kB]
Get: 35 http://deb.debian.org/debian sid/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.0 kB]
Get: 36 http://debug.mirrors.debian.org/debian-debug unstable-debug/main 
Translation-en.diff/Index [63.3 kB]
Get: 37 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Contents (deb).diff/Index [63.3 kB]
Get: 38 http://deb.debian.org/debian sid/main Translation-en 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [3,772 B]
Get: 39 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.2 kB]
Get: 40 http://debug.mirrors.debian.org/debian-debug unstable-debug/main 
Translation-en T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [223 B]
Get: 41 http://deb.debian.org/debian sid/main Translation-en 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [3,772 B]
Get: 42 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff 

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64) Inbox

[Diederik de Haas]

FTR: There is already an alternative fix committed in the Debian Kernel repo:
https://salsa.debian.org/kernel-team/linux/-/commit/4a65ff78c6be9208bfc9232886a7a2d199ebcac7

So what I'll describe below is how you would do it.

On Thursday, 19 January 2023 18:46:57 CET Markus Kramer wrote:
> How do I boot from this kernel?  Using dpkg -i arch/x86/boot/bzImage ?

To use `dpkg -i` you'd need a .deb file (ie Debian package)

> How could GRUB show this kernel as e.g. "before-patch", or will it
> show the creation time?
> 
> Where do I get the .patch file mentioned in
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4
> .2.2 ?

The 'problematic' commit was c34db0d6b88b and we need a revert of that:

diederik@prancing-pony:~/dev/kernel.org/linux$ git revert c34db0d6b88b
Auto-merging sound/soc/soc-pcm.c
[linux-5.10.y 3ed496982f55] Revert "ASoC: soc-pcm: Don't zero TDM masks in 
__soc_pcm_open()"
 1 file changed, 5 insertions(+)
diederik@prancing-pony:~/dev/kernel.org/linux$ git format-patch HEAD~1 -o 
../patches/
../patches/0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch

And that's how you'd get the .patch file which I have attached as a convenience.

If you then follow the procedure at #s4.2.2 and provide that patch file as an
argument, it would build a .deb file of the patched kernel.
That .deb file you can then install with `dpkg -i `.

Currently, (unfortunately?), it would replace your existing 5.10.0-20-amd64
kernel and there is no (easy) way to see that you would be booting into
your new patched kernel from GRUB.

HTH,
  Diederik>From 3ed496982f556d17a87f830acaf5023d4f5d9a9b Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Thu, 19 Jan 2023 18:32:38 +0100
Subject: [PATCH] Revert "ASoC: soc-pcm: Don't zero TDM masks in
 __soc_pcm_open()"

This reverts commit c34db0d6b88b1da95e7ab3353e674f4f574cccee.
---
 sound/soc/soc-pcm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index fb874f924bbe..9a60d62f12fe 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -723,6 +723,11 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
 		ret = snd_soc_dai_startup(dai, substream);
 		if (ret < 0)
 			goto err;
+
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			dai->tx_mask = 0;
+		else
+			dai->rx_mask = 0;
 	}
 
 	/* Dynamic PCM DAI links compat checks use dynamic capabilities */
-- 
2.39.0



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

Bug#1029063: reportbug: linux-image-6.0.0-6-amd64 remains unconfigured because of errors

[Diederik de Haas]

On Thursday, 19 January 2023 13:19:32 CET Diederik de Haas wrote:
> It generally takes me a few *seconds* to spot the issue.

One reason for that is that the cause and the solution of the issue tends to 
be the same, pretty much every single time.
Namely a new kernel version with which their dkms module is not made 
compatible yet, so we could be extra helpful by pointing that out and request 
they contact the maintainer of their dkms module to make it compatible with 
the new kernel version.

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

Bug#1029063: reportbug: linux-image-6.0.0-6-amd64 remains unconfigured because of errors

[Diederik de Haas]

On 19 January 2023 10:32:04 CET, Andreas Beckmann  wrote:
>On 17/01/2023 18.27, Diederik de Haas wrote:
>> It seems fine to print (in all caps afaic) that there is an issue.
>
>That tends to get overlooked ... in the middle of a thousand packages being 
upgraded ...

I said ALL CAPS and there are more ways to decorate it which make it REALLY 
stands out.
Does that mean that someone will still miss it?
Yes. And that would be entirely their fault. 

The number of times I've seen people on #debian-next break their Sid system is 
truly mindboggling. And every time it's because they couldn't be arsed to read 
the feedback the system gave them. 
"This action* will remove your entire DE. Do you want to continue?" 

*) usually dist-upgrade

"Hey! I just did an upgrade and now my DE is broken! What should I do?"
"Downgrade to the version in Testing"
"No. I run Sid, not Testing"
"Yeah. You probably shouldn't bc you apparently don't know how to do that. 
Still, the solution is to downgrade to the Testing version. Alternatively you 
can get the older version from snapshot.d.o, but getting them from Testing 
tends to be much easier"
"I'm not going to do that, because I run Sid!"
"Enjoy your broken Sid system then. Sid, where if it breaks you get to keep 
all the pieces."

I really wish this was some fictional story I pulled out of my arse.
But no, this is a paraphrasing of several actual conversations I had in the 
last few weeks. And yesterday someone's Sid system was broken because of some 
(aufs) dkms module whose source needs to be updated for the brand new kernel 
that was uploaded to Sid.

So this problem only occurs to people who run Sid, but REALLY shouldn't.
And it would be good if they actually end up with a broken system as that's 
likely the only way they'll learn.

btw: upgrading a *1000* packages is not a realistic scenario.

It might happen when people dist-upgrade from one Stable release to the next.
And then the following 2 things are also true:
- The dkms module should be compatible for a while now as the Stable kernel 
version exists for a while
- They do such an upgrade without looking for potential issues ?!?

>We must not silently create an unbootable system.

Agreed. Hence my suggestion to use ALL CAPS so the issue is shouted at them.

**
* WARNING:*
* Potentially UNBOOTABLE  issue occurred: *
*   *
**

And IMO for those l33t h@xx0rs who're running Sid, because running a Rolling 
Release is what their fellow Reddit-l33r-h@xx0rs do too, really are best 
served with an unbootable system (in this case). Recovering from that is a 
really useful exercise and they should learn to actually read the (generally 
very clear) feedback the system gives them.
It generally takes me a few *seconds* to spot the issue.

My 0.02


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

Bug#1029130: after kernel update to linux-image-6.1.0-1-amd64 6.1.4-1 - mount.cifs fails with "CIFS: VFS: bogus file nlink value 0"

[Diederik de Haas]

Control: tag -1 fixed-upstream

On Wednesday, 18 January 2023 11:35:30 CET only4com wrote:
> Package: linux-image-6.1.0-1-amd64
> Version: 6.1.4-1
> 
> After updating the linux image from linux-image-6.0.0-6-amd64 to
> linux-image-6.1.0-1-amd64 Version 6.1.4-1 I cannot mount a samba share from
> an older server any more:

Thanks for the report. In the meantime that issue is/should be fixed upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=d54a3ef8b8bdb9e12dc5ff97d44b9827416eed54
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=5a574327d1c5f7036af84ebe99cddba88f7d2038

Both are part of upstream's 6.1.7 release.

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

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Diederik de Haas]

Control: tag -1 help

Hi,

On Wednesday, 18 January 2023 09:22:03 CET Didier 'OdyX' Raboud wrote:
> Control: retitle -1 Thinkpad: amd_pmc module required for on 6.1 for correct 
> suspend
> Le mardi, 17 janvier 2023, 22.53:54 h CET Didier 'OdyX' Raboud a écrit :
> > Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit :
> > > On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> > > > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> > > > light up", so feel free to close the bug; I'll test if I get the same
> > > > symptoms on an unpatched kernel anyway :-)
> > > 
> > > If that issue doesn't occur with the unpatched kernel, could you add
> > > your finding to that upstream/forwarded issue?
> > ...
> > 
> > All three 6.1 kernels (whether patched or not) don't bring the laptop to
> > the suspended state (power led 'breathing', fans off), but it's kept in
> > an "on" state (power led on, fans on), from which I found that I *can*
> > wake the laptop up by short-pressing the power button; the screens gets
> > back to life and show my lockscreen. But from there, I can't move the
> > mouse nor do anything else. Alt-SysRq-r + ctrl-alt-f2 give me a tty, but
> > any comeback to tty1 only blank (not even a blank screen, just a freeze).
> > 
> > This seems to point to a quite severe regression in amdgpu or other amd-
> > related code; I can't suspend-and-resume the laptop anymore on any 6.1
> > kernel, on battery, without anything attached to it.
> > 
> > I'll forward the above findings to the bug you pointed to, hoping it could
> > help upstream too!
> 
> OK. I've gone and done this:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1727281

Awesome, thanks.

> It turns out to get suspend to work, the `amd_pmc` module needs to be
> enabled (_AND_ the BIOS needs to have the "Sleep State" toggled to Windows
> (from Linux).
> 
> I _think_ Debian should make sure amd_pmc is loaded on (all?) modern AMD
> laptops. I have no idea (yet) what the mechanism to make this happen is
> though.

Due to https://bugs.debian.org/992832 the AMD_PMC module got enabled and
I and IIUC you too, verified that it is present in the kernel.

I agree it should be auto-loaded, but I don't know why that didn't happen.
Tagging this bug with 'help' to request the help from ppl who know more
about this then I do.

Cheers,
  Diederik

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

Bug#1029063: reportbug: linux-image-6.0.0-6-amd64 remains unconfigured because of errors

[Diederik de Haas]

On Tuesday, 17 January 2023 18:12:30 CET Andreas Beckmann wrote:
> On Tue, 17 Jan 2023 10:56:33 +0100 Bastian Blank  wrote:
> > > Error! Bad return status for module build on kernel: 6.0.0-6-amd64
> > > (x86_64)
> > > Consult /var/lib/dkms/anbox-binder/1/build/make.log for more
> > > information.
> 
> That does not look like a module packaged in Debian ...

These kind of issues get regularly filed against the Debian kernel and it does 
not matter whether the dkms module is packaged in Debian or not. If the dkms 
module is packaged in Debian, we assign it to the specific dkms package.

> > dkms fails the installation if anything it tries to build does not work.
> > This must go, reassigning accordingly.
> 
> What should dkms do instead? Out-of-tree modules break frequently on new
> kernel upstream major versions, that is completely out of dkms' control.
> 
> There are two points in time where these errors could show up:
> * ) at package installation/upgrade time because building the module
>  failed (there is a small chance of the build succeeding ater reboot
>  if a badly packaged module only supports building against the
>  running kernel)
> * ) at reboot due to a missing kernel module
> 
> A failing module could build be 'harmless' if it's e.g. just the
> soundcard driver missing (unless you depend on text-to-speech) but in
> the worst case it's the root file system that is not supported...

It seems fine to print (in all caps afaic) that there is an issue.

But it should not cause the kernel package install/upgrade to fail.
And that does seem in dkms' control afaict.

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

Bug#1029080: linux-image-5.10.0-20-amd64: Boot failure "PM: Image not found (code -22)" where power management is NOT used

[Diederik de Haas]

Control: tag -1 moreinfo

On Tuesday, 17 January 2023 14:20:19 CET Claire Osborne wrote:
> Booting in recovery mode on 5.10.0.20 also failed
> 
> I have fallen back to the previously installed kernel 5.10.19 - with the
> same effect.
> 
> Booting in recovery mode on 5.10.0.19 also fails.

What was the latest 5.10.x kernel which did boot correctly?

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

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Diederik de Haas]

Hi OdyX,

On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> light up", so feel free to close the bug; I'll test if I get the same
> symptoms on an unpatched kernel anyway :-)

If this issue doesn't occur with the unpatched kernel, that would be VERY 
important extra information!
https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be the 
same or similar finding?

If that issue doesn't occur with the unpatched kernel, could you add your 
finding to that upstream/forwarded issue?

Thanks!

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

Bug#1027682: closed by Debian FTP Masters (Bug#1027682: fixed in wlroots 0.16.1-1)

[Diederik de Haas]

On dinsdag 17 januari 2023 13:09:57 CET you wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:wlroots package:
> 
> #1027682: wlroots: New upstream release (0.16.1)
> 
> It has been closed by Debian FTP Masters 
> (reply to Guido Günther ).

Thanks!



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

Bug#1028965: RFS: linux/6.1.6-1~exp1 [ITP] -- Linux for multiprocessor

[Diederik de Haas]

On Sun, 15 Jan 2023 15:59:13 +0100 vmxevils...@gmail.com wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "linux":
> 
>  * Package name : linux
>Version  : 6.1.6-1~exp1
>Upstream contact : Salvatore Bonaccorso 
>  * URL  : https://www.kernel.org/
>  * License  : Unicode-data, LGPL-2.1, GPL-2+-or-X11, CRYPTOGAMS, 
LGPL-2.1 or BSD-2-clause, GPL-2 or BSD-2-clause, GPL-2, Xen-interface
>  * Vcs  : https://salsa.debian.org/kernel-team/linux
>Section  : kernel

JFTR: This isn't the way and Salvatore isn't the Upstream contact and was not 
made aware of this (prior).

6.1.6 is already present in salsa and earlier today an email was send out 
about the intention for an upload of 6.1.6
https://salsa.debian.org/kernel-team/linux/-/commit/
f44a493cc158a227718de2689434bb6db107edd8

IOW: in sofar it wasn't already completely obvious, ignore this RFS.

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

Bug#1028451: 2nd DisplayPort doesn't get video

[Diederik de Haas]

On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote:
> On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote:
> > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
> > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
> > > 
> > > upstream here:
> > >   https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> > 
> > Thanks! About an hour ago the suggested fix was to revert commit
> > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1
> > 
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
> > s4.2.2 describes a procedure to build a kernel with the proposed patch
> > (attached).
> > 
> > OdyX: Can you try to see whether that resolves the issue?
> 
> Should we keep 6.1.y based kernel out of testing until this is clear?
> As we aim though to have 6.1.y into bookworm I would see it as more
> preferable to get 6.1.4 in for testing, we will need to followup as
> well soonish with another interation for e.g. for fixing
> CVE-2023-0266.

As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I 
believe is ready to be uploaded already.
That should keep 6.1.y out of testing for a few more days.

> Now if it turns out that this is the same issue as the referenced
> upstream, reverting I think we only should really revert the commit if
> that's queued up for 6.1. There is currently some furhter discussion
> on
> https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com
> /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40
> 
> Given the size of the revert, there is as well a chance to re-break
> other parts. So preferring to closely follow upstream here, whatever
> the decision will be.

Agreed.

I asked 'OdyX' to test the revert to make sure it would indeed fix *this* 
issue, IOW what I consider standard bug triaging.

But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other 
people who weren't happy about it. So *I* wouldn't suggest applying it to 
Debian (although I don't think my opinion should have much weight).

As for letting this bug _continue_ to prevent a migration, ie keep the RC 
status, I'm against it and for downgrading it to 'important'.
You could opt to add a NEWS item to warn people about this potential issue.

But the original report is about the *2nd* DisplayPort being 'broken'.

On zaterdag 14 januari 2023 17:04:52 CET you wrote:
> Basically this issue breaks all usage of Displayport MST on amdgpu systems.
> Which roughly translates to breaking external monitors for everyone using
> an USB-C docks with multiple display outputs (which is pretty common these
> days) on AMD laptops. As  well as those like myself who daisy-chain display
> port monitors with an amdgpu using graphics card.

I understand that would be annoying for you, but I don't think that it would 
affect the majority of our users. 

On 2023-01-13 10:25  Daniel Vetter wrote (in that thread):
> Like yes it's a regression, but apparently not a blantantly obvious one

The revert may cause much wider issues which upstream may or may not care 
(much) about. And it would be a divergence from upstream.

Getting wider testing of the 6.1 kernel is something I find much more 
important. There could be other issues lurking which would not get exposure 
and therefor wouldn't get fixed until this bug would be fixed.

Uploading 6.1.6 now would give (us/)upstream a couple of more days to figure 
out a potential *better* way to deal with it. One which should be acceptable 
for the upstream Stable Kernel maintainers.

But I wouldn't let this bug cause further delays to Testing.
Testing is meant to test things for the next Stable release and things can and 
will break from time to time.
If people can't deal with that, they should not be running Testing.

My 0.02

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

Bug#1028601: linux: DeviceTree files (*.dtb) should not have the executable bit set

[Diederik de Haas]

Source: linux
Version: 6.1.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The DeviceTree files (*.dtb) as shipped with the Debian kernel have the
executable bit set, but there is absolutely no need for that.
Lintian rightfully complains about it (executable-not-elf-or-script).

$ ls -lh /usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328*.dtb
- -rwxr-xr-x 1 root root 35K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-a1.dtb
- -rwxr-xr-x 1 root root 34K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-evb.dtb
- -rwxr-xr-x 1 root root 36K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-nanopi-r2s.dtb
- -rwxr-xr-x 1 root root 36K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-roc-cc.dtb
- -rwxr-xr-x 1 root root 36K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-rock64.dtb
- -rwxr-xr-x 1 root root 36K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-rock-pi-e.dtb
- -rwxr-xr-x 1 root root 37K jan  7 14:53 
/usr/lib/linux-image-6.1.0-1-arm64/rockchip/rk3328-roc-pc.dtb

The sources for them (*.dts) don't have the executable bit set though.

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY8FhggAKCRDXblvOeH7b
boB2AQDcW2ROAiGx8YU7prBbLQHPj4OYQf9PJXLgK/tzc3nnwwEAtfzPWkCnhYB5
+J41AbRiCUbT6SEaqVg5S9MP9DkW/gI=
=M+b1
-END PGP SIGNATURE-

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

Hi Julian,

On Thursday, 12 January 2023 12:11:57 CET Julian wrote:
> The message to linux-nvme finally came through and the thread is here:
> http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

The following paragraph may not be ideally formulated:

"Currently, I am using git bisect to narrow down the window of possible 
commits, but since the issue appears seemingly random, it will take many 
months to identify the offending commit this way."

Why? It *could* be that the maintainers will wait for the result of the
`git bisect` before responding/acting upon it.

Hopefully I'm wrong, but if they don't respond in a 'reasonable' time frame, 
you may want to clarify that you actually don't want to do the `git bisect` 
exactly because it could take many months.

Cheers,
  Diederik

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

Bug#1028451: 2nd DisplayPort doesn't get video

[Diederik de Haas]

On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
> upstream here:
>   https://gitlab.freedesktop.org/drm/amd/-/issues/2171

Thanks! About an hour ago the suggested fix was to revert commit
4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
describes a procedure to build a kernel with the proposed patch (attached).

OdyX: Can you try to see whether that resolves the issue?diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 77277d90b6e2..674f5dc1102b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 	const struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
 	struct drm_dp_mst_topology_mgr *mst_mgr;
 	struct drm_dp_mst_port *mst_port;
-	struct drm_dp_mst_topology_state *mst_state;
 	enum dc_color_depth color_depth;
 	int clock, bpp = 0;
 	bool is_y420 = false;
@@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 	if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
 		return 0;
 
-	mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
-	if (IS_ERR(mst_state))
-		return PTR_ERR(mst_state);
-
-	if (!mst_state->pbn_div)
-		mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
-
 	if (!state->duplicated) {
 		int max_bpc = conn_state->max_requested_bpc;
 		is_y420 = drm_mode_is_420_also(>display_info, adjusted_mode) &&
@@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 		clock = adjusted_mode->clock;
 		dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
 	}
-
-	dm_new_connector_state->vcpi_slots =
-		drm_dp_atomic_find_time_slots(state, mst_mgr, mst_port,
-	  dm_new_connector_state->pbn);
+	dm_new_connector_state->vcpi_slots = drm_dp_atomic_find_time_slots(state,
+	   mst_mgr,
+	   mst_port,
+	   dm_new_connector_state->pbn,
+	   dm_mst_get_pbn_divider(aconnector->dc_link));
 	if (dm_new_connector_state->vcpi_slots < 0) {
 		DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", (int)dm_new_connector_state->vcpi_slots);
 		return dm_new_connector_state->vcpi_slots;
@@ -6654,14 +6647,17 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
 			dm_conn_state->vcpi_slots = slot_num;
 
 			ret = drm_dp_mst_atomic_enable_dsc(state, aconnector->port,
-			   dm_conn_state->pbn, false);
+			   dm_conn_state->pbn, 0, false);
 			if (ret < 0)
 return ret;
 
 			continue;
 		}
 
-		vcpi = drm_dp_mst_atomic_enable_dsc(state, aconnector->port, pbn, true);
+		vcpi = drm_dp_mst_atomic_enable_dsc(state,
+		aconnector->port,
+		pbn, pbn_div,
+		true);
 		if (vcpi < 0)
 			return vcpi;
 
@@ -9497,6 +9493,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 	struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
 #if defined(CONFIG_DRM_AMD_DC_DCN)
 	struct dsc_mst_fairness_vars vars[MAX_PIPES];
+	struct drm_dp_mst_topology_state *mst_state;
+	struct drm_dp_mst_topology_mgr *mgr;
 #endif
 
 	trace_amdgpu_dm_atomic_check_begin(state);
@@ -9744,6 +9742,33 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 		lock_and_validation_needed = true;
 	}
 
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+	/* set the slot info for each mst_state based on the link encoding format */
+	for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+		struct amdgpu_dm_connector *aconnector;
+		struct drm_connector *connector;
+		struct drm_connector_list_iter iter;
+		u8 link_coding_cap;
+
+		if (!mgr->mst_state )
+			continue;
+
+		drm_connector_list_iter_begin(dev, );
+		drm_for_each_connector_iter(connector, ) {
+			int id = connector->index;
+
+			if (id == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+			}
+		}
+		drm_connector_list_iter_end();
+
+	}
+#endif
 	/**
 	 * Streams and planes are reset when there are changes that affect
 	 * bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6994c9a1ed85..ac5a8cad0695 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -120,27 +119,40 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 }
 
 static void

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

Control: forwarded -1 
http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

On Thursday, 12 January 2023 12:11:57 CET Julian wrote:
> The message to linux-nvme finally came through and the thread is here:
> http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

Thanks!

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

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

On Wednesday, 11 January 2023 19:28:25 CET Julian Groß wrote:
> On Mon, 09 Jan 2023 14:09:30 +0100 Diederik de Haas
>  wrote:
>  > https://wiki.debian.org/DebianKernel/GitBisect describes a procedure
>  > to find the exact commit which introduced the issue you reported, but it's
>  > often faster to first narrow down the range using snapshot.d.o.
> 
> The way I understand the `git bisect`, and with the issue taking
> sometimes days to happen, I will be sitting on this for months by the way.

Yep, that would/could be the consequence, which I can fully understand is not 
desirable or very useful.
Having the exact offending commit is ideal, but not a '100%' requirement.
As you've determined that it already happened with 6.0~rc7 and not with 
5.19.x, that's already a reasonably small range (likely introduced in the 6.0 
merge window).

So the next thing to do, is present the issue to the relevant upstream 
maintainers. Searching for "nvme controller is down" brought up another bug 
(but that happened pretty instantly) and in there the request was made to 
report the issue (via email) to the linux-...@vger.kernel.org and 
linux-n...@lists.infradead.org lists.
And that seems like the next best step for you too.

Use the information you provided in your initial bug report and add the extra 
findings (ie 6.1-rc7) to that too.
When you've done that, please inform this bug report where you did that so 
that we can track it's progress too.

Cheers,
  Diederik

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

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

Control: found -1 6.0~rc7-1~exp1

On Wednesday, 11 January 2023 15:04:30 CET Julian wrote:
> 6.0~rc7-1~exp1 is also broken.
> 
> I will go through https://wiki.debian.org/DebianKernel/GitBisect and see
> what I can find. Thankfully the documentation is quite comprehensive.

That would be great, thanks!

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

Bug#1028451: 2nd DisplayPort doesn't get video

[Diederik de Haas]

On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote:
> Package: src:linux
> Version: 6.1.4-1
> Severity: serious
> 
> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
> Station doesn't get any output.

Can you try the previous versions of the 6.1.x series which you can get via 
snapshot.debian.org? I recommend to start with the first 6.1-rcX version.

A `git bisect` is the best way to figure out what caused it, but the above 
procedure is the quickest way to narrow down the search space.

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

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Diederik de Haas]

On Tue, 23 Nov 2021 07:58:32 +0100 Ard Biesheuvel  wrote:
> I don't see a reason to revert the default upstream. The feature
> remains deprecated (and in the longer term, the EFI handover protocol
> may be deprecated and removed as well), so the earlier the bootloaders
> adapt, the better it is.
> 
> In the meantime, keeping it enabled in the distros for arm64 makes
> sense because there is an established installed base. But that doesn't
> mean this should be the upstream default.

FYI: In 6.2 things changed (IIUC):

In https://git.kernel.org/linus/75e1a2460d79566bf1e43e5a3a7a9039510a82e0 
the setting got un-deprecated.

In https://git.kernel.org/linus/e346bebbd36b1576a3335331fed61bb48c6d8823 
the configuration option got removed.
Full commit message:
efi: libstub: Always enable initrd command line loader and bump version
In preparation for setting a cross-architecture baseline for EFI boot
support, remove the Kconfig option that permits the command line initrd
loader to be disabled. Also, bump the minor version so that any image
built with the new version can be identified as supporting this.

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

Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/all/877f41ovlu@free-electrons.com/

Hi Ben,

On 07 Mar 2017 18:16:45 +0100 Gregory CLEMENT 
 wrote:
>  On lun., févr. 20 2017, Ben Hutchings  wrote:
> > On Mon, 2017-02-20 at 17:50 +0100, Thomas Petazzoni wrote:
> >> On Mon, 20 Feb 2017 16:40:25 +, Ben Hutchings wrote:
> >> 
> >> > That is precisely what I intended.  20-23 are used by the second
> >> > Ethernet port.  The old board code doesn't assign 4 or 5 at all.
> >> 
> >> Then I believe it would be more explicit to have separate pin muxing
> >> configurations for SATA on this board.
> >
> > You mean, define additional pinmux nodes and override the pinctrl-0
> > property of ?  more like this:
> >
> > --- a/arch/arm/boot/dts/kirkwood-ts419.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood-ts419.dtsi
> > @@ -73,3 +73,19 @@
> > phy-handle = <>;
> > };
> >  };
> > +
> > + {
> > +   pmx_sata0_ts419: pmx-sata0-ts419 {
> > +   marvell,pins = "mpp15";
> > +   marvell,function = "sata0";
> > +   };
> > +
> > +   pmx_sata1_ts419: pmx-sata1-ts419 {
> > +   marvell,pins = "mpp16";
> > +   marvell,function = "sata1";
> > +   };
> > +};
> > +
> > + {
> > +   pinctrl-0 = <_sata0_ts419 _sata1_ts419>;
> > +};
> 
> If you send a new version of your patch, then I will be able to apply
> it on mvebu/dt.
> 
> Thanks,
> 
> Gregory

Would it be an idea to send the updated patch for inclusion in upstream?
It's almost 6 years old, but it seems that it can still be applied cleanly.


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

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

Control: found -1 6.0.10-1

On Monday, 9 January 2023 13:20:08 CET Julian Groß wrote:
> when running Linux Kernel version 6.0.12 or 6.0.10, my system seemingly
> randomly freezes due to the filesystem being set to read-only due to an
> issue with my nvme controller. 
> The issue does *not* appear on Linux Kernel version 5.19.11 or lower. 
> 
> If there is any more information I might be able to provide, do not hesitate
> to ask.

Unstable currently has version 6.1.4-1, could you try that to see whether the 
issue is already resolved?

If not, then we need to figure out when the issue first occurred.
Via https://snapshot.debian.org/binary/linux-image-amd64/ you can find several 
other kernel versions from the 6.0.x series, could you try those?
It's probably quickest to try 6.0~rc7-1~exp1 first.

https://wiki.debian.org/DebianKernel/GitBisect describes a procedure to find 
the exact commit which introduced the issue you reported, but it's often 
faster to first narrow down the range using snapshot.d.o.

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

Bug#984307: qpxtool: ftbfs with GCC-11

[Diederik de Haas]

Control: tag -1 upstream patch

On Wed, 03 Mar 2021 16:16:49 + Matthias Klose  wrote:
> Package: src:qpxtool
> Version: 0.8.1-1
> Usertags: ftbfs-gcc-11
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10.
> 
> [...]
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:123:80: note: declared here
>   123 | QT_DEPRECATED_X("Use default constructor instead")
>   Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}

The QFlag issue was a warning, (but) not the cause of the build failure.
The build failure was caused by this:

> src/mainwindow.cpp: In member function ‘void QPxToolMW::selectTab()’:
> src/mainwindow.cpp:430:16: error: ordered comparison of pointer with integer
> zero (‘QAction*’ and ‘int’)> 
>   430 | if (act<0) return;
>   | ~~~^~

In https://salsa.debian.org/debian/qpxtool/-/merge_requests/2 I submitted a 
patch fixing that issue and with that, the build does succeed.
Also in Salsa's CI (MR 1).

I have a bunch of other patches to be submitted in another MR which among 
others fix the QFlags(Zero) warning. But to fix this RC bug only MR 2 is needed.

Cheers,
  Diederik

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

Bug#1026973: rrdtool FTBFS on 32-bit arches (may fail in testcase)

[Diederik de Haas]

On Thursday, 5 January 2023 22:16:15 CET Helge Deller wrote:
> But it seems to fail differently for you
> https://salsa.debian.org/diederik/rrdtool/-/jobs/3746600 :
> 
>   /builds/diederik/rrdtool/debian/output/source_dir/src/rrdtool list
> FAILED: (rc=1) list without parameters displays Usage
> FAIL list1 (exit status: 1)

Thanks, I can take a look at that.

> this is from the rrdtool-1.7.2/tests/list1 script, which executes:
> 
> LC_ALL=C $RRDTOOL list | grep -c Usage
> 
> Can you maybe run it manually on i386 with strace?
> This should give you some insight

Then I have to learn how to set up a i386 chroot (or sth like that) and how to 
run strace ... and do sth with its output. So I'll leave that for now.

My request/question was mostly in the hope that you'd have an instant "Oh 
wait, then that must be it", which unfortunately isn't the case.

Cheers,
  Diederik

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

Bug#1026973: rrdtool FTBFS on 32-bit arches (may fail in testcase)

[Diederik de Haas]

On Sun, 25 Dec 2022 12:49:27 +0100 Helge Deller  wrote:
> Package: rrdtool
> Version: 1.7.2-4
> Tags: hppa, patch, ftbfs
> Severity: important
> 
> The command "rrdtool list /some/dir/" fails on 32-bit arches at runtime
> if those are running on huge discs, e.g. see failing "list1" testcase
> on hppa:
> https://buildd.debian.org/status/fetch.php?
pkg=rrdtool=hppa=1.7.2-4+b7=1671837818=0
> 
> This can be fixed by building rrdtool with LFS (large file support).
> Simply change in debian/rules this line (line 19):
> export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
> to
> export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow future=+lfs

I cloned the rrdtool repo, added/enabled Salsa's CI and added the patch you 
proposed, but the `build i386` job still failed (it also failed without the 
patch): https://salsa.debian.org/diederik/rrdtool/-/pipelines/479591

FTR: This is based on the 1.8.0 version which is in the repo, but not 
released, but the failure is still in the "list1" testcase.
https://buildd.debian.org/status/logs.php?pkg=rrdtool=hppa shows that a 
new build on 2022-12-24 did succeed on hppa (without the patch) ...

Do you have more ideas as to what may be causing the build failure?

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

Bug#1027979: fwupd: failed to get public key using /fpf/OemCred: generic failure [0xb]

[Diederik de Haas]

Package: fwupd
Version: 1.8.9-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When I check the status of `fwupd.service` I see the (error?) message as
mentioned in the Subject.
It doesn't sound good, although I have no idea if this has any effect on
the workings of `fwupd`. I haven't noticed any.
As I don't know if it has an effect on its working, I put severity at
'normal' instead of minor. But if it's a harmless/useless message, then
I'd prefer to not see it when asking for the service's status.

root@prancing-pony:~# systemctl status fwupd.service 
○ fwupd.service - Firmware update daemon
 Loaded: loaded (/lib/systemd/system/fwupd.service; static)
 Active: inactive (dead)
   Docs: https://fwupd.org/

Jan 04 18:45:03 prancing-pony systemd[1]: Starting Firmware update daemon...
Jan 04 18:45:04 prancing-pony fwupd[56044]: 17:45:04.555 FuPluginIntelMe  
failed to get public key using /fpf/OemCred: generic failure [0xb]
Jan 04 18:45:04 prancing-pony systemd[1]: Started Firmware update daemon.
Jan 04 20:45:05 prancing-pony systemd[1]: fwupd.service: Deactivated 
successfully.
Jan 04 20:45:05 prancing-pony systemd[1]: fwupd.service: Consumed 1.306s CPU 
time.
Jan 05 09:41:33 prancing-pony systemd[1]: Starting Firmware update daemon...
Jan 05 09:41:34 prancing-pony fwupd[64373]: 08:41:34.514 FuPluginIntelMe  
failed to get public key using /fpf/OemCred: generic failure [0xb]
Jan 05 09:41:35 prancing-pony systemd[1]: Started Firmware update daemon.
Jan 05 11:41:35 prancing-pony systemd[1]: fwupd.service: Deactivated 
successfully.
Jan 05 11:41:35 prancing-pony systemd[1]: fwupd.service: Consumed 1.232s CPU 
time.

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

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

Versions of packages fwupd depends on:
ii  adduser3.130
ii  libarchive13   3.6.2-1
ii  libc6  2.36-7
ii  libcbor0.8 0.8.0-2+b1
ii  libcurl3-gnutls7.87.0-1
ii  libefiboot137-6
ii  libflashrom1   1.2-5
ii  libfwupd2  1.8.9-2
ii  libgcab-1.0-0  1.5-1
ii  libglib2.0-0   2.74.4-1
ii  libgnutls303.7.8-4
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblzma5   5.4.0-0.1
ii  libmbim-glib4  1.28.2-1
ii  libmbim-proxy  1.28.2-1
ii  libmm-glib01.20.2-1
ii  libpolkit-gobject-1-0  122-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.32.2-1
ii  libqmi-proxy   1.32.2-1
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.40.1-1
ii  libsystemd0252.4-1
ii  libtss2-esys-3.0.2-0   3.2.1-2
ii  libxmlb2   0.3.10-2
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
ii  bolt   0.9.4-1
ii  dbus   1.14.4-1
ii  fwupd-amd64-signed [fwupd-signed]  1:1.2+3
ii  jq 1.6-2.1
ii  python33.10.6-3+b1
pn  secureboot-db  
ii  udisks22.9.4-4

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

- -- Configuration Files:
/etc/fwupd/redfish.conf [Errno 13] Permission denied: '/etc/fwupd/redfish.conf'
/etc/fwupd/remotes.d/lvfs-testing.conf changed:
[fwupd Remote]
Enabled=false
Title=Linux Vendor Firmware Service (testing)
MetadataURI=https://cdn.fwupd.org/downloads/firmware-testing.xml.xz
ReportURI=
OrderBefore=lvfs,fwupd
AutomaticReports=false
ApprovalRequired=false

/etc/fwupd/remotes.d/lvfs.conf changed:
[fwupd Remote]
Enabled=true
Title=Linux Vendor Firmware Service
MetadataURI=https://cdn.fwupd.org/downloads/firmware.xml.xz
ReportURI=
SecurityReportURI=https://fwupd.org/lvfs/hsireports/upload
OrderBefore=fwupd
AutomaticReports=false
AutomaticSecurityReports=false
ApprovalRequired=false


- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7bOywAKCRDXblvOeH7b
bhfJAP9H/kwVk2VuDhYW6F5wflKwv/XvcU1l5i07SRh9JDkPYQEApahYqqBy5eIJ
tNSUn3fCBgAjuHvnBJJSI3u17WCXCgY=
=sQgN
-END PGP SIGNATURE-

Bug#1027891: linux-image-6.2.0-rc2: cannot connect via ethernet

[Diederik de Haas]

Control: tag -1 upstream
Control: severity -1 normal

On Wed, 04 Jan 2023 12:04:52 +0100 xevilstar  wrote:
> Package: linux-image-6.2.0-rc2
> Version: 6.2.0-rc2-1
> 
> I am testing linux kernel 6.2-rc2

That is great, but you should report any issues you find to the relevant 
upstream maintainers.

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

Bug#1027933: aerc: New upstream release (0.14.0)

[Diederik de Haas]

Package: aerc
Version: 0.13.0-1+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Earlier today the release of version 0.14.0 was announced:
https://lists.sr.ht/~rjarry/aerc-announce/%3C20230104163910.PQQOJR7R3JWE%40ringo%3E

And hereby the request to update the aerc package in Debian.

Thanks!
  Diederik

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

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

Versions of packages aerc depends on:
ii  libc62.36-7
ii  libnotmuch5  0.37-1+b1

Versions of packages aerc recommends:
pn  dante-client  
ii  gnupg 2.2.40-1
ii  w3m   0.5.3+git20220429-1+b1

Versions of packages aerc suggests:
pn  notmuch  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7XJFQAKCRDXblvOeH7b
bnTRAP4yUCMZfp4I6WFAeL4dU5/mGWoGGU8vgzCuz/39PgE/7AEA2ymUNQicQF1z
XVlZQE7joUYdEX/I27lQyi8uUsBILwI=
=sn25
-END PGP SIGNATURE-

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Diederik de Haas]

On Tuesday, 3 January 2023 22:14:10 CET Santiago Vila wrote:
> --
>  From this definition it follows that packages of required priority are not
> necessarily build essential, as it is possible for some them not to be

... for some *of* them ... ?

> needed at all to compile, link and put in a Debian package a Hello World
> program written in C or C++.
> --



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

Bug#1027921: linux-image-5.10.0-20-amd64: aacraid's expose_physicals=-1 is not functional

[Diederik de Haas]

On Wednesday, 4 January 2023 15:38:32 CET Tim Düsterhus wrote:
> Unfortunately the setting `1` allows direct write access to the devices,
> whereas the previous and to my understanding the default setting of `-1`
> only allows read access, making this a safer option.
> 
> It appears that aacraid's `expose_physicals=-1` option got broken
> somewhere between Linux 4.19 and 5.10.

https://git.kernel.org/linus/e3cc268fe4a0ad1cbefbc53cee35c80281e609b8 seems 
relevant, although I do not fully understand it.
One thing that stood out for me is the check `expose_physicals > 0` instead of 
`expose_physicals != 0`. But that commit exists since 2.6.35 ...

This very much looks like an upstream kernel issue and therefor it's better to 
bring it to the attention of those maintainers.

Those are:
$ scripts/get_maintainer.pl drivers/scsi/aacraid/aachba.c 
Adaptec OEM Raid Solutions  (supporter:AACRAID SCSI 
RAID DRIVER)
"James E.J. Bottomley"  (maintainer:SCSI SUBSYSTEM)
"Martin K. Petersen"  (maintainer:SCSI SUBSYSTEM)
linux-s...@vger.kernel.org (open list:AACRAID SCSI RAID DRIVER)
linux-ker...@vger.kernel.org (open list)

When you do forward your question, please inform this bug report of the URL.

HTH

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

Bug#1027921: linux-image-5.10.0-20-amd64: aacraid's expose_physicals=-1 is not functional

[Diederik de Haas]

On Wednesday, 4 January 2023 16:39:33 CET Renato Gallo wrote:
> 5.10 should be EOL by now

Please refrain from comments like that.
It doesn't help at all and is also plain false.

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

Bug#985187: ffmpeg: reproducible builds: Embeds build path in binaries generated with cl2c

[Diederik de Haas]

On Tuesday, 3 January 2023 19:06:41 CET Vagrant Cascadian wrote:
> Looks like some new source of non-determinism was added in 5.0.x, you
> can see bookworm (which does not test build paths) was reproducible
> until 5.0.x started getting tested in bookworm in June of 2022:
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffosco
> pe-results/ffmpeg.html
> 
> Fixing the build path issue mentioned in this patch may dramatically
> reduce the size of the diffoscope output from ~71MB to ~29KB ... so
> might be nice to apply still even if it does not fix all the
> reproducibility issues. I'll take another stab at it...

I just added "SALSA_CI_REPROTEST_ENABLE_DIFFOSCOPE: 1" to my salsa-ci.yml file 
which I assume means it'll now also produce a diffoscope output.

Feel free to use it if it helps:
https://salsa.debian.org/diederik/ffmpeg/-/pipelines
https://salsa.debian.org/diederik/ffmpeg/-/commits/fix-reprotest-issue

Cheers,
  Diederik

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

Bug#985187: ffmpeg: reproducible builds: Embeds build path in binaries generated with cl2c

[Diederik de Haas]

On 14 Apr 2022 15:45:26 -0700 Vagrant Cascadian  wrote:
> On 2021-08-08, Sebastian Ramacher wrote:
> > On 2021-03-13 20:05:47 -0800, Vagrant Cascadian wrote:
> >> Source: ffmpeg
> >> Severity: normal
> >> Tags: patch
> >> User: reproducible-bui...@lists.alioth.debian.org
> >> 
> >> The build path is embedded in various files generated with tools/cl2c:
> >> 
> >>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/
> >>   diffoscope-results/ffmpeg.html

FWIW, in https://salsa.debian.org/diederik/ffmpeg/-/pipelines/478274 I added 
your patch, but the 'reprotest' job still failed.
I don't know how to read diffoscope's result (and currently don't have time to 
learn it), but it looks like more is needed to make it reproducible.
Happy to add more patches to my branch and if 'reprotest' then succeeds, 
you're free to add a "Tested-By: " tag with my name+email

> >> The attached patch fixes this by patching tools/cl2c to use a basename
> >> in the generated file rather than the full path.
> >
> > As this patch touches upstream's build system, please submit it
> > upstream:
> 
> Did so, haven't really heard anything back:
> 
>   https://patchwork.ffmpeg.org/project/ffmpeg/patch/87sfwyotmg.fsf@yucca/
> 
> Any suggestions?

I have no particular knowledge wrt ffmpeg-devel, but with the kernel patches 
sometimes fall through the cracks and the best way is just to resend them.

I did notice that the patch itself looks better then the email I saw on the 
'Forwarded' link. I _think_ that with 'git send-email' it would look cleaner.

I would suggest to slightly reword the commit message so that it doesn't 
contain "Without this patch". Maybe it's just me, but if the secondary commit 
message starts with "To make builds reproducible ..." that would heighten my 
interest in the patch. 'But' I really like the reproducible builds effort :-)

And possibly update the reference to ffmpeg-4.3.2 to point to 5.1 or something.
And I'd replace "Originally submitted to Debian as:\n\n https://b.d.o/985187; 
with a "Link:" tag.

HTH,
  Diederik

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

Bug#1027692: installation-reports: successful with some wifi and encrypted /boot difficulties

[Diederik de Haas]

On Monday, 2 January 2023 07:03:10 CET Vagrant Cascadian wrote:
> Also wifi related, on first boot, there was no wifi device configured,
> and I did not happen to install anything that pulled in
> network-manager or something similar. I am not sure I even did an
> install using wifi before, so this was a bit of a surprise. There were
> wpasupplicant and maybe sufficient things to actually manually set up
> wifi, but I worked around having to do that by plugging in a USB
> ethernet adapter and installed network-manager, and then wifi just
> worked fine via network-manager.

Sounds like https://bugs.debian.org/694068

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

Bug#1027682: wlroots: New upstream release (0.16.1)

[Diederik de Haas]

Source: wlroots
Version: 0.16.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just saw that upstream released wlroots 0.16.1 last week.
AFAICT it has some important fixes, so if the package could be upgraded
to that version, that would be appreciated.

Cheers,
  Diederik

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7HfNwAKCRDXblvOeH7b
bprGAP4kmmDqYHLVkgHro6fGeoNQikdK9Wvvtn4+yHeTi9praQD/Wo2YjLU/lAh0
REGMAnlX//a7lREphKQc1q+L2S5G6gw=
=iy0d
-END PGP SIGNATURE-

Bug#1027478: repo: New upstream release (2.31)

[Diederik de Haas]

Package: repo
Version: 2.28-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Version 2.31 is available upstream.
Could that be packaged and uploaded to Debian, please?

TIA,
  Diederik

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

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

Versions of packages repo depends on:
ii  git   1:2.39.0-1
ii  gnupg 2.2.40-1
ii  python3   3.10.6-3+b1
ii  python3-kerberos  1.1.14-3.1+b6

Versions of packages repo recommends:
ii  git  1:2.39.0-1

repo suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7GCrwAKCRDXblvOeH7b
bpqAAQDG42UCjG1bTEhOcW49eZFj3WzsrC640M9dbK6VB9/ESAD9E6HWUfdJ+/Kq
ZjPMWwuo7Nx1uTaAiKcIJ8W9M1Lh0Qk=
=h69N
-END PGP SIGNATURE-

Bug#1027410: u-boot: Please add support for Asus TF101

[Diederik de Haas]

On Saturday, 31 December 2022 01:41:52 CET Vagrant Cascadian wrote:
> On 2022-12-31, Diederik de Haas wrote:
> > Does this mean that u-boot upstream supports the Asus TF101?
> > If so, what is needed to get it enabled in Debian?
> 
> It does not look like it is supported upstream...

Ok. Thanks for checking.

> > I haven't tried it yet, but apparently postmarketos supports it:
> > https://wiki.postmarketos.org/wiki/ASUS_Eee_Pad_Transformer_(asus-tf101)
> 
> I would guess postmarketos is more willing to support vendor forks to
> get specific boards enabled...
> 
> Reading some of the links referenced, sounds like the closest board
> supported in upstream u-boot might be configs/ventana_defconfig:
> 
>   https://github.com/grate-driver/linux/pull/23
> 
> The post was a little old (~2021), but referenced some things that might
> be useful in an upstream porting effort...

Because of a defective wall plug, the device was unused for some years, but 
recently got a working one from a friend. Charged it and it just worked :-D

I found that link too ... and then some :-O
Amongst other things, it looks like the device is supported in the upstream 
Linux kernel \o/
And only a few days ago, people were actively working on improving things for 
the TF101!

> So, in short, get it supported in upstream u-boot and then we can enable it
> in Debian. :)

I got quite a few things to learn, so it may take a while.
But what I found these last few days has got me super-charged :-)
So I'm going to try to help out too and will let you know when there are some 
results which are also usable for Debian.

> live well,
>   vagrant

You too,
  Diederik

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

Bug#1027438: rrdtool: Please release version 1.8.0 to Debian

[Diederik de Haas]

Package: rrdtool
Version: 1.7.2-4+b7
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I saw on salsa that version 1.8.0 is already there (since 9 months), but
it looks like it never got uploaded to the Debian archive?
Could you do that? In time for the freeze?

TIA,
  Diederik

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

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

Versions of packages rrdtool depends on:
ii  libc6 2.36-7
ii  libglib2.0-0  2.74.4-1
ii  librrd8   1.7.2-4+b7

rrdtool recommends no packages.

Versions of packages rrdtool suggests:
pn  librrds-perl  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7BFTAAKCRDXblvOeH7b
brgYAQD1Jk0ULIV6e4BDgL0nWIrTndhEzpEPZZlUDDPZoFyLnwEA1u0dKVxM3FlJ
x+cAzkP4vm7ED5Ou90mT5kBs0w6Fegc=
=caxy
-END PGP SIGNATURE-

Bug#1027410: u-boot: Please add support for Asus TF101

[Diederik de Haas]

Source: u-boot
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Grepping through the source of u-boot (upstream), I found the following:
arch/arm/include/asm/mach-types.h:#define MACH_TYPE_TF1013640

Does this mean that u-boot upstream supports the Asus TF101?
If so, what is needed to get it enabled in Debian?

I haven't tried it yet, but apparently postmarketos supports it:
https://wiki.postmarketos.org/wiki/ASUS_Eee_Pad_Transformer_(asus-tf101)

Cheers,
  Diederik

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY693agAKCRDXblvOeH7b
btSiAQDxeNPJslHeQBiuEo2LRBk6nVw04YVyeT7+WKayXeh9PgEA8INWNaoCvkC1
ok2btcf2TbE7VHRI9TEqouk0N+9JYg8=
=R/z2
-END PGP SIGNATURE-

Bug#1000013: Bug #1000013:nginx: depends on obsolete pcre3 library

[Diederik de Haas]

On Friday, 30 December 2022 17:38:43 CET Jan Mojzis wrote:
> Currently nginx is compiled with the PCRE3 library and all modules
> using PCRE must be compiled with the same version (PCRE3).
> 
> I made practical test,
> nginx compiled with PCRE2 and lua compiled with PCRE3 and didn't work.

Ah ok, thanks for the response. It was worth a shot :)

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

Bug#1000013: Bug #1000013:nginx: depends on obsolete pcre3 library

[Diederik de Haas]

On Fri, 11 Nov 2022 15:59:38 +0100 Jan Mojzis  wrote:
> currently,
> nginx and all modules distributed with it are compatible with PCRE2.
> 
> The last problem is with the libnginx-mod-http-lua module,
> which PCRE2 does not support.
> Issue here: https://github.com/openresty/lua-nginx-module/issues/1984 


Is it possible to have only libnginx-mod-http-lua (? not sure if that's the 
exact right one) depend on pcre3, while the rest depends on pcre2?
Right now nginx-core depends on pcre3 (and not pcre2?!?), while IIUC that's 
not needed (or possibly even incorrect?).

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

Bug#976118: [Pkg-raspi-maintainers] Bug#976118: Bug Status?

[Diederik de Haas]

On Friday, 30 December 2022 14:03:03 CET Matthias Urlichs wrote:
> > Do you have a link to that fix?
> 
> https://github.com/gpiozero/gpiozero/pull/929

Thanks

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

Bug#1027325: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: inaccessible or not found

[Diederik de Haas]

On Friday, 30 December 2022 12:42:53 CET Thorsten Glaser wrote:
> I think I reported the same thing against experimental some time ago,
> but it now is a regression in stable. Building kernel modules shows:
> 
> tglase@tglase-edge:~/lnx/master/janz $ make
> make -C '/lib/modules/5.10.0-20-amd64/build'
> M='/home/tglase/lnx/master/janz' modules make[1]: Entering directory
> '/usr/src/linux-headers-5.10.0-20-amd64' W: /bin/sh:
> /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh:
> inaccessible or not found

That's likely https://bugs.debian.org/1008501 that was fixed here:
https://salsa.debian.org/kernel-team/linux/-/commit/ee29a5e231886d26cef901285bf46a1f929ad4eb

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

Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang

[Diederik de Haas]

On Friday, 30 December 2022 01:48:53 CET Stefan Pietsch wrote:
> >> Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and
> >> linux-image-5.6.0-2-amd64 (5.6.14-1).> 
> > This also affects 5.5.0-rc5-amd64.
> > 
> > (https://snapshot.debian.org/archive/debian/20200106T211159Z/pool/main/l/l
> > inux/)
> > 
> > The kernel boot option "intel_iommu=igfx_off" prevents the error message.
> 
> This seems to be resolved in newer kernel versions.
> I'm not able to reproduce this with kernel version 5.14.0-4-amd64
> (5.14.16-1).

Great that it is resolved :-)

As many people are affected and the Stable kernel version still seems to 
exhibit the problem, I want to ask a question:
Are you willing to help out to narrow down as much as possible which version 
introduced the error and in which is was fixed? Wrt the latter, does 5.14.12-1 
still show the issue?

Via https://snapshot.debian.org/binary/linux-image-amd64/ you get (easily) get 
all the kernel versions that were released.
If we know a (reasonably) small range of kernel versions in which it surfaced 
and a small range in which it was fixed, then we could make some educated 
guesses as to which commit caused the issue in the first place.

TIA,
  Diederik

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

Bug#953790: quassel-client: Typo in spanish translation

[Diederik de Haas]

On Fri, 13 Mar 2020 10:31:57 -0300 Lisandro Damián Nicanor Pérez Meyer 
 wrote:
> Package: quassel-client
> Version: 1:0.13.1-3
> 
> Hi! In the spanish translation there is a typo: it says mesnaje instead of
> mensaje.
> 
> I've tried creating a pull request on quassel's github only to be closed and
> redirected to an even more proprietary system for doing translations on

Could you try again at https://github.com/quassel/quassel-i18n/pulls ?
They recently did merge an update to German translation there.

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

Bug#1016963: Help with testing u-boot!

[Diederik de Haas]

On Thursday, 29 December 2022 04:33:51 CET Rick Thomas wrote:
> Rebooting while watching the serial console output says "U-Boot SPL
> 2016.05-rc2+dfsg0~20160423~1-1 (Apr 24 2016 - 04:24:21)"  So the firmware
> does not correspond to what aptitude says.   

The main difference with your other Cubox-i output is the 'SPL' part.
I have no clue about Cubox-i, but on Rockchip/Pine64 devices you (often) can 
boot from SPI, eMMC and SDcard and its preference is also in that order.

So if you have u-boot on SPI (flash), then it'll use that (if it also 
preferences SPI above others).
Which likely means that you could also completely remove the u-boot packages 
and that has no effect on your ability to boot the device.

If you want to try newer u-boot versions, then you need to find out how to 
either update u-boot in SPI or how to clear the contents of SPI, so it would 
'fall back' on u-boot found somewhere else, like SDcard.

HTH

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

Bug#1016963: Help with testing u-boot!

[Diederik de Haas]

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
> and experimental (2023.01-rc*)
>
> # arm64
> ...
> rock64-rk3328

I don't recall ever having issues with u-boot on my Rock64's, so for me 
2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I generate my own images for Rock64 and that uses 'dd ... seek=' of 
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen 
an issue since then.

HTH,
  Diederik

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

Bug#1019665: ruby-safe-yaml: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: ArgumentError:

[Diederik de Haas]

Control: affects -1 src:jekyll

On Mon, 26 Dec 2022 17:54:13 +0100 Lucas Nussbaum  wrote:
> On 17/12/22 at 14:51 +0100, Diederik de Haas wrote:
> > There is an upstream PR: https://github.com/dtao/safe_yaml/pull/101
> > which tried to address this, but someone who tried it still got errors.
> > 
> > Last upstream commit was from 2019-02-22 and there are several PRs open
> > and it looks like the maintainer hasn't responded to any of them for > 5
> > YEARS
> 
> Since ruby-crack no longer depends on ruby-safe-yaml, ruby-safe-yaml
> should probably just be removed from testing (and Debian)...

And with that jekyll: https://tracker.debian.org/pkg/jekyll
https://bugs.debian.org/1026427 is a bug about that.

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

Bug#1027070: linux-image-amd64: resume from hibernate fails, no keyboard or mouse, no screen or frozen screen

[Diederik de Haas]

Control: reassign -1 src:linux 6.0.3-1~bpo11+1

On Tuesday, 27 December 2022 15:42:31 CET Wolf-Dieter Groll wrote:
> Package: linux-image-amd64
> Version: 6.0.3-1~bpo11+1

Stable backports now has 6.0.12-1~bpo11+1, could you try that too?

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

Bug#993640: Please turn on the SimpleDRM driver in 5.14

[Diederik de Haas]

On Tuesday, 9 November 2021 01:30:03 CET nerdopolis wrote:
> +++ b/debian/config/kernelarch-x86/config
> @@ -75,6 +75,7 @@ CONFIG_IA32_EMULATION=y
>  ## file: arch/x86/Kconfig.cpu
>  ##
>  # CONFIG_PROCESSOR_SELECT is not set
> +CONFIG_X86_SYSFB=y

It is now in a different location and quoting the relevant part of the Kconfig 
file for easier evaluation. 8633ef82f101c040427b57d4df7b706261420b94 seems to 
be the commit that changed it.

~/dev/kernel.org/linux$ grep -A 28 "config SYSFB" drivers/firmware/Kconfig 
config SYSFB
bool
select BOOT_VESA_SUPPORT

config SYSFB_SIMPLEFB
bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
depends on X86 || EFI
select SYSFB
help
  Firmwares often provide initial graphics framebuffers so the BIOS,
  bootloader or kernel can show basic video-output during boot for
  user-guidance and debugging. Historically, x86 used the VESA BIOS
  Extensions and EFI-framebuffers for this, which are mostly limited
  to x86 BIOS or EFI systems.
  This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
  framebuffers so the new generic system-framebuffer drivers can be
  used instead. If the framebuffer is not compatible with the generic
  modes, it is advertised as fallback platform framebuffer so legacy
  drivers like efifb, vesafb and uvesafb can pick it up.
  If this option is not selected, all system framebuffers are always
  marked as fallback platform framebuffers as usual.

  Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will
  not be able to pick up generic system framebuffers if this option
  is selected. You are highly encouraged to enable simplefb as
  replacement if you select this option. simplefb can correctly deal
  with generic system framebuffers. But you should still keep vesafb
  and others enabled as fallback if a system framebuffer is
  incompatible with simplefb.

  If unsure, say Y.


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

Bug#1026870: linux-image-6.0.0-6-amd64 - significant performance degradation

[Diederik de Haas]

On Thursday, 22 December 2022 22:20:44 CET Kamila Szewczyk wrote:
> [  297.413358] vboxdrv: loading out-of-tree module taints kernel.

If you're indeed testing this inside VirtualBox, do look whether there's an
update for that (too).

> [ 3025.190695] ACPI Error: No handler for Region [ECSI] (6dd86190)
> [EmbeddedControl] (20220331/evregion-130) [ 3025.190747] ACPI Error: Region
> EmbeddedControl (ID=3) has no handler (20220331/exfldio-261) [ 3025.190781]
> ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error
> (AE_NOT_EXIST) (20220331/psparse-529) [ 3025.190830] ACPI Error: Aborting
> method \_SB.UBTC.NTFY due to previous error (AE_NOT_EXIST)

I also noticed several ACPI errors. I don't know if that's on the host or also
inside VirtualBox, but it may be worth looking into that.
And also comparing that with the 'old' kernel which did perform 'properly'.

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

Bug#1026834: linux-image-5.10.0-20-amd64: no audio with device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 11)

[Diederik de Haas]

Control: reassign src:linux 5.10.158-2

On Wednesday, 21 December 2022 22:45:12 CET sapcie wrote:
> Package: linux-image-5.10.0-20-amd64
> Version: latest
> Severity: normal

Bug https://bugs.debian.org/1010733 also mentions that same audio device, 
although that seems to have failed with 5.10.0-13 already ...

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

Bug#1026804: WIFI doesn't work for kernel 6.1

[Diederik de Haas]

On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> a self-built kernel from current master, it seems more likely to be an
> upstream issue/regression.

I just noticed the following part from that linux-amlogic post:
> I native build kernel from debian's kernel repo:
> https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> ures/arm64/meson all follow debian's kernel config.

That path doesn't seem to exist anymore, but got redirected to 'just' the 
master branch and noticed the latest commit "update patches from khadas".
When I looked into that, I saw there were a LOT of additional patches :-O
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
features/khadas

The test I suggested in my previous reply would still be useful, but it could 
also be that your patch-set is at fault.


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

Bug#1026804: WIFI doesn't work for kernel 6.1

[Diederik de Haas]

On Wednesday, 21 December 2022 12:47:45 CET Zhang Ning wrote:
> Package: linux-image-arm64
> Version: 6.1-1~exp1
> 
> WIFI works well for my Arm64 SBCs (Khadas VIM1 & VIM3), both are Amlogic
> SBC, S905x and A311D, with kernel 6.0 and early versions.
> 
> these two boards are well supported by debian kernel, with all functions
> work out of box.
> 
> After update to 6.1, it stops work.
> 
> WIFI doesn't response, please check attached logs.
> 
> before send this bug to debian, I have asked upsteam[0], and device
> vendor, whether they observe same issue, but the answers are no.
> 
> thus I suspect this is the problem of debian kernel.
> 
> [0]
> http://lists.infradead.org/pipermail/linux-amlogic/2022-December/014544.htm
> l

Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is a 
self-built kernel from current master, it seems more likely to be an upstream 
issue/regression.

In the linux-amlogic post [0] it was tested with 6.1-rc8.
https://tracker.debian.org/pkg/linux shows there have been several uploads of 
6.1-rcX to experimental, so could you test those first?

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

Bug#1019665: ruby-safe-yaml: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: ArgumentError:

[Diederik de Haas]

On 13 Sep 2022 09:00:07 -0300 Antonio Terceiro  wrote:
> Source: ruby-safe-yaml
> Version: 1.0.5-2
> Justification: FTBFS
> Usertags: ruby3.1
> 
> We are about to start the ruby3.1 transition in unstable. While trying to
> rebuild ruby-safe-yaml with ruby3.1 enabled, the build failed.
> 
> Relevant part of the build log (hopefully):
> >   ArgumentError:
> > wrong number of arguments (given 2, expected 1)
> >   # ./lib/safe_yaml/load.rb:149:in `load'
> >   # ./lib/safe_yaml.rb:29:in `safe_load'
> >   # ./spec/safe_yaml_spec.rb:7:in `safe_load_round_trip'
> >   # ./spec/safe_yaml_spec.rb:745:in `block (4 levels) in  >   (required)>'
> > 
> > Finished in 0.08109 seconds (files took 0.12613 seconds to load)
> > 134 examples, 20 failures
> > 
> > Failed examples:
> > 
> > rspec ./spec/safe_yaml_spec.rb:29 # Psych unsafe_load allows exploits 
> > through objects defined in YAML w/ !ruby/hash via custom :[]= methods

There is an upstream PR: https://github.com/dtao/safe_yaml/pull/101
which tried to address this, but someone who tried it still got errors.

Last upstream commit was from 2019-02-22 and there are several PRs open and it 
looks like the maintainer hasn't responded to any of them for > 5 YEARS

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

Bug#1017780: Version bump: 1.4.230

[Diederik de Haas]

Hi Jonas,

On Tuesday, 13 December 2022 10:55:18 CET Jonas Smedegaard wrote:
> perhaps I can point you to other examples as well

I'd love to have several examples to look at :-)
Especially if you know of one (or more) who write extensive commit messages 
explaining the reasons/rational of their changes. This should help me get an 
understanding of how, what and why to do (packaging) things.

TIA,
  Diederik

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

Bug#1026174: linux: Please enable CONFIG_X86_SGX_KVM=y

[Diederik de Haas]

found 1026174 linux/6.0.10-2



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

Bug#988966: /boot/vmlinuz-5.10.0-6-armmp-lpae: lamobo-r1 ethernet/bridge failure

[Diederik de Haas]

On Saturday, 22 May 2021 00:46:55 CET Vagrant Cascadian wrote:
> Package: src:linux
> Version: 5.10.28-1
> File: /boot/vmlinuz-5.10.0-6-armmp-lpae
> Control: block 986767 by -1
> 
> The ethernet bridge fails to work on 5.10.x (also tried 5.10.38-1),
> but works fine on 4.19.x from buster. (This was also reported in
> https://bugs.debian.org/986767)
> 
> I noticed these messages when booting up:
> 
> [6.254047] bcm53xx stmmac-0:1e: failed to register switch: -517
> [6.339663] bcm53xx stmmac-0:1e: failed to register switch: -517

The best way to determine what caused the change from working to not working 
is `git bisect`: https://wiki.debian.org/DebianKernel/GitBisect

It's probably possible to speed that process up by narrowing the range to 
search. Usually the quickest way is to use snapshot.debian.org and use that to 
retrieve kernels between 4.19 and 5.10 and test with that.

I've also made some observations which could also help in narrowing things 
down.
Kernel 5.10 has CONFIG_NET_DSA_TAG_BRCM_COMMON=m while it's absent in 4.19.
That setting determines whether `tag_bcrm` gets build. Bug #986767 also seems 
to indicate that that is a relevant change. It may be that lamobo-r1 needs 
additional kernel options enabled.
It appears that the networking code made a significant change between 4.19 and 
5.10 and it _could_ be DSA related.

I know OpenWrt is in the process of switching networking to DSA.
https://openwrt.org/toh/lamobo/bananapi_r1?s[]=lamobo[]=r1 indicates that 
the device is supported by OpenWrt version 22.03.2. It's probably worth trying 
their image and see whether it works properly. And then note which kernel 
they're using. And possibly search and/or ask for help on their forum.
https://github.com/openwrt/openwrt/issues/7817 is still open and is titled 
"sunxi / lamobo-r1: switch not working with kernel 5.4", so their issue 
tracker may also provide more info/hints.

HTH

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

Bug#1022126: mpt3sas broken with xen dom0

[Diederik de Haas]

On Thursday, 15 December 2022 11:47:11 CET Diederik de Haas wrote:
> On Thursday, 15 December 2022 10:43:22 CET Adi Kriegisch wrote:
> > after the discussion about the root cause of this issue on the linux-scsi
> > mailing list[1] there was one simple patch submitted to this list[2] that
> > just changes the logic of the selection of the dma mask: in case of a
> > 64bit
> > host operating system, the driver chooses a 63/64bit mask.
> 
> Was Juergen Gross part of that discussion? I didn't see his name.
> I do know he's one of the main Xen contributors and he seemed to have some
> good input in [1].

Probably better to (also) send it to xen-de...@lists.xenproject.org as there 
are more smart people with a lot of Xen knowledge there.

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

Bug#1022126: mpt3sas broken with xen dom0

[Diederik de Haas]

On Thursday, 15 December 2022 10:43:22 CET Adi Kriegisch wrote:
> after the discussion about the root cause of this issue on the linux-scsi
> mailing list[1] there was one simple patch submitted to this list[2] that
> just changes the logic of the selection of the dma mask: in case of a 64bit
> host operating system, the driver chooses a 63/64bit mask.

Was Juergen Gross part of that discussion? I didn't see his name.
I do know he's one of the main Xen contributors and he seemed to have some 
good input in [1].

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

Bug#988966: lamobo-r1 ethernet/bridge failure: Bug still exist in Daily images (2022-12-15)

[Diederik de Haas]

Control: found -1 6.0.12-1

On Thursday, 15 December 2022 10:09:27 CET Bernhard wrote:
> This bug still exist in Daily image from today (2022-12-15).

That's using the 6.0.0-6-armmp kernel.


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