Bug#1082906: linux-image-6.11-amd64: ipu6 camera is not working
Control: tag -1 moreinfo On Sat, 28 Sep 2024 03:09:54 + gabriel wrote: > Package: src:linux > Version: 6.11-1~exp1 > > ipu6 mipi camera drivers were not part of previous kernels, now they have > been upstreamed. > After upgrading kernel to 6.11 the ipu6 kernel modules are loaded, however > there are 32 video devices /dev/video0 to /dev/video32 and none of them is > working (gstreamer, vlc, firefox or cheese) Do you have firmware-intel-graphics installed? signature.asc Description: This is a digitally signed message part.
Bug#1082514: liblcms2-dev: Please upload version 2.16 to Unstable
Package: liblcms2-dev Version: 2.14-2+b1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Version 2.16-1 was uploaded to Experimental in the beginning of the year, but it would be great if it was uploaded to Unstable too. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.11-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 liblcms2-dev depends on: ii liblcms2-2 2.14-2+b1 liblcms2-dev recommends no packages. liblcms2-dev suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZu7AQAAKCRDXblvOeH7b bgLqAPsFtkfygZSwmW4uF/CCVqBCdWCHdRGQybH/OAzL4u3n5AD/SqKRavmEMEXd Hy9rFhe22T1qoAOETKPIDtW7hiszNQs= =kLHj -END PGP SIGNATURE-
Bug#1080303: wlr-randr: New upstream release (0.4.1)
On Mon Sep 2, 2024 at 1:55 PM CEST, Guido Günther wrote: > On Sun, Sep 01, 2024 at 08:15:36PM +0200, Diederik de Haas via > Debian-on-mobile-maintainers wrote: > > Package: wlr-randr > > > > Upstreamed release version 0.4.1 some time ago ... > > > > I made an attempt at packaging that and you can find it here: > > https://salsa.debian.org/diederik/wlr-randr/-/tree/debian/experimental > > ... > > But hopefully my branch still contains something useful. > > Feel free to grab what is useful and ignore what isn't :-) > > I could cherry pick some things, thanks! I opted to wait for the manpage > to tickle in with the next upstream version. Great and thanks for uploading the new version; much appreciated :-) Cheers, Diederik signature.asc Description: PGP signature
Bug#1080303: wlr-randr: New upstream release (0.4.1)
Package: wlr-randr Version: 0.3.0-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! Upstreamed release version 0.4.1 some time ago and it would be great to have that in Debian. I made an attempt at packaging that and you can find it here: https://salsa.debian.org/diederik/wlr-randr/-/tree/debian/experimental I didn't turn it into a MR for the following reasons: 1. I'd need to make 3 MRs for 3 different branches (AFAIK) 2. I thought the `upstream/0.4.1` tag would be signed with my key, but maybe you'd want that to be from a maintainer. But it appears that tag hasn't been signed at all. 3. I first copied the `gbp.conf` from the `eg25-manager` project, but adapted it to this projects branch names. I don't know if you'd want to change the branch names and thereby make the `gbp.conf` files identical to each other. But hopefully my branch still contains something useful. Feel free to grab what is useful and ignore what isn't :-) Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.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 wlr-randr depends on: ii libc6 2.40-2 ii libwayland-client0 1.23.0-1 wlr-randr recommends no packages. wlr-randr suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZtSvQQAKCRDXblvOeH7b blfoAP4gQzlJqR7Jw/uxyacanUMKUeNzzzi9MKtaRUc4uag5pAEA9tnLxnPUQw0b /XfzJgv7IJCofjw813atTkFllugYJw8= =Ouss -END PGP SIGNATURE-
Bug#1080072: fixed in wvkbd 0.15-1)
On Sun Sep 1, 2024 at 14:39 CEST, Debian Bug Tracking System wrote: > Source: wvkbd > Architecture: source > Version: 0.15-1 > Changed-By: Jochen Sprickerhof > Closes: 1080072 > Changes: > wvkbd (0.15-1) unstable; urgency=3Dmedium > . >* New upstream release (Closes: #1080072) >* Rediff patches >* Bump policy version (no changes) Awesome, thanks! Also for renaming the branch :-) signature.asc Description: PGP signature
Bug#1080072: wvkbd: New upstream release (0.15)
Package: wvkbd Version: 0.14.3-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Upstream has a new upstream version available, 0.15, and I'd like it a lot of that could be packaged for Debian. Could you possibly also rename your 'master' branch to 'upstream/latest' so that it's compatible with DEP-14? AFAICT it contains the upstream source, not the Debian packaging source which is in the already DEP-14 compatible 'debian/sid' branch. Cheers, Diederik Link: https://dep-team.pages.debian.net/deps/dep14/ - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.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 wvkbd depends on: ii libc62.40-2 ii libcairo21.18.0-3+b1 ii libpango-1.0-0 1.54.0+ds-2 ii libpangocairo-1.0-0 1.54.0+ds-2 ii libwayland-client0 1.23.0-1 wvkbd recommends no packages. wvkbd suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZtGPSQAKCRDXblvOeH7b bgnVAP4oBG4+yCRFRqdllAC5ql0+TE5Nc1gkohr6kjgKadZ4QgD/YBpeozqJTWwI vpbuu32S3XbVj6XLSf5kDzEOMUSzdw0= =mMbi -END PGP SIGNATURE-
Bug#1080008: wlroots: Please review the B-Ds for wlroots 0.18
Source: wlroots
Version: 0.18.0-2
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Triggered by a comment from 'emersion' [1] (upstream maintainer for both
sway and wlroots) I started looking at wlroots 0.18 B-Ds.
Directly related to that, AFAICT wlroots needs a B-D on `liblcms2-dev`
to have color management support (in sway, but possibly all wlroot based
compositors).
I started to work on a patch, but by now I'm (too) confused, so I
figured I'd make it into a wishlist bug instead.
Some of the things I found:
1. Some B-Ds have different version requirements from the wlroots source
package compared to the Depends of the `libwlroots-0.18-dev` package.
This seems illogical to me, but could be intentional and I just didn't
find the reason behind it (possibly PEBKAC).
2. I (initially) thought that it would also need a B-D on `libudev`,
but while writing this bug I found that it's listed as a (B-)D for
*sway*, when wlroots has the libinput_backend feature, which is or
should be the case for the Debian package.
3. While looking through the upstream commits and various `meson.build`
files, I noticed that a lot of features have been made optional. Which
in turn IIUC means that some features that were available in f.e.
wlroots 0.17 are no longer available because a/some dependencies are not
available. Or in my opinion worse: they could be accidentally available.
4. Related to 3. I think that more features need to be explicitly
enabled. In `debian/rules` I saw that the 'drm', 'libinput' and 'x11'
backends are enabled, but maybe that should be extended?
It seems that it is unlikely that the wlroots build fails, but it could
be that it succeeds while it actually does NOT have certain features
that you actually want(ed) to have? Having a build failure in this case
seems preferable *to me*.
But while working on this I came to the conclusion that I need to learn
more about the meson build system to *fully* understand it.
And having an 'x11' backend while there's also an xwayland feature is
confusing too, so I concluded I'd better leave it up to the maintainers
of the Debian packages.
I will include my WIP patch in case it helps, but won't add the 'patch'
tag to this bug.
Cheers,
Diederik
[1] https://github.com/swaywm/sway/pull/7681#issuecomment-2308926702
- -- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.10.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/XblvOeH7bbgUCZtBmnQAKCRDXblvOeH7b
bgZQAQCK7mP0m7ZtGrn7uaEFyMtQtElqLLVLqIxXdPRSVco89QEAk5LbdVV3qZVT
lplNL5vm+T3/iRg396h5dW5/83CmmwA=
=6SZw
-END PGP SIGNATURE-
>From 79b06c8ac9c8c0f983528e802cbe10ede153ade7 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Wed, 28 Aug 2024 16:36:31 +0200
Subject: [PATCH] d/control: Update Build Dependencies
>From ``meson.build``:
8bbe8624dfdb ("build: bump pixman version")
Upped the minimal required version of libpixman to version 0.42.0.
Note that this commit was already part of wlroots 0.17.
>From ``backend/drm/meson.build``:
22d9df2af483 ("backend/drm: send output layer feedback events")
Upped the minimal required version of libliftoff to 0.4.0, not 0.4.1.
The right version was set in libwlroots-0.18-dev binary package.
6e6c4408d36d ("backend/drm: add support for libliftoff v0.5.0")
OTOH prepared for version 0.5.0, but doesn't require it (yet).
0a79bc28c7eb ("build: require libinput v1.19")
Upped the minimal required version of libinput to 1.19.
Note that that version is available in Stable, but not older versions.
56c842fcde8a ("d/control: Drop version superfluous information")
Dropped the version requirement (of 1.9.0) because "We have recent
enough versions even in stable.", but even o-o-s has 1.12, so I do
consider this different enough to bring back the version requirement.
>From ``render/meson.build``:
895e3d18b903 ("render/color: introduce wlr_color_transform")
Added color management support to wlroots, but only if liblcms2-dev is
available. This can be used by sway if wlroots has this functionality.
Fixes: 89f88ab37a7f ("d/control: Update build-deps for new upstream version")
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/8bbe8624dfdb4fbf120aee3dd6f0f8d3bf7e
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/22d9df2af483bb862c24bcb973e8ab3475759ebe
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/6e6c4408d36ddad705458ca4b2e301192f7963fd
Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'
Control: tag -1 -patch -upstream -fixed-upstream Control: notforwarded -1 On 26 Aug 2024 17:22:19 +0200 Diederik de Haas wrote: > Control: tag -1 upstream fixed-upstream patch > Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 Oeps, my CC-ing this bug also modified the metadata ... incorrectly. Should now be fixed again. signature.asc Description: This is a digitally signed message part.
Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'
Control: tag -1 upstream fixed-upstream patch Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 On 12 Jul 2024 13:38:30 +0900 Mike Hommey wrote: > Source: pixman > Version: 0.42.2-1 > Severity: serious > > The package fails to build on armhf on current sid/testing with: > > ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction > -- `bne 01f' > ../../pixman/pixman-arm-simd-asm.h:869: Info: macro invoked from here > ... > See https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 and bug > 1073870. https://gitlab.freedesktop.org/pixman/pixman/-/commit/865e6ce00bb79a6b925ed4c2c436e1533e4472aa is the commit where upstream fixed this bug and for your convenience attached. BUT this patch won't apply on top of 0.42.2, but it would apply on top version 0.43.4 which bug 1061616 requests for. So it would be great if both bugs can be fixed in 1 go. Cheers, Diederik>From 865e6ce00bb79a6b925ed4c2c436e1533e4472aa Mon Sep 17 00:00:00 2001 From: Mike Hommey Date: Fri, 12 Jul 2024 11:11:17 -0400 Subject: [PATCH] pixman: Adjust arm assembly for binutils change A change in the latest version of binutils broke building pixman for arm. The binutils change: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b Closes: https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 --- pixman/pixman-arm-simd-asm.S | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/pixman/pixman-arm-simd-asm.S b/pixman/pixman-arm-simd-asm.S index 34d38f1f..3dfe723a 100644 --- a/pixman/pixman-arm-simd-asm.S +++ b/pixman/pixman-arm-simd-asm.S @@ -820,13 +820,13 @@ generate_composite_function \ .macro over_white___ca_1pixel_tail mvn TMP0, WK1 teq WK1, WK1, asr #32 -bne 01f -bcc 03f +bne 1f +bcc 3f mov WK3, WK1 -b 02f -01: over_white___ca_combine WK1, WK3 -02: pixst , 4, 3, DST -03: +b 2f +1: over_white___ca_combine WK1, WK3 +2: pixst , 4, 3, DST +3: .endm .macro over_white___ca_2pixels_head @@ -837,21 +837,21 @@ generate_composite_function \ pixld , 8, 3, DST mvn TMP0, WK1 teq WK1, WK1, asr #32 -bne 01f +bne 1f movcs WK3, WK1 -bcs 02f +bcs 2f teq WK2, #0 -beq 05f -b 02f -01: over_white___ca_combine WK1, WK3 -02: mvn TMP0, WK2 +beq 5f +b 2f +1: over_white___ca_combine WK1, WK3 +2: mvn TMP0, WK2 teq WK2, WK2, asr #32 -bne 03f +bne 3f movcs WK4, WK2 -b 04f -03: over_white___ca_combine WK2, WK4 -04: pixst , 8, 3, DST -05: +b 4f +3: over_white___ca_combine WK2, WK4 +4: pixst , 8, 3, DST +5: .endm .macro over_white___ca_process_head cond, numbytes, firstreg, unaligned_src, unaligned_mask, preload @@ -1067,9 +1067,9 @@ generate_composite_function \ .if \offset != 0 ldrbORIG_W, [SRC, #\offset] .endif -beq 01f +beq 1f teq STRIDE_M, #0xFF -beq 02f +beq 2f .endif uxtb16 SCRATCH, \d /* rb_dest */ uxtb16 \d, \d, ror #8 /* ag_dest */ @@ -1079,13 +1079,13 @@ generate_composite_function \ uxtab16 \d, \d, \d, ror #8 mov SCRATCH, SCRATCH, ror #8 sel \d, SCRATCH, \d -b 02f +b 2f .if \offset == 0 48: /* Last mov d,#0 of the set - used as part of shortcut for * source values all 0 */ .endif -01: mov \d, #0 -02: +1: mov \d, #0 +2: .endm .macro in_reverse___tail numbytes, reg1, reg2, reg3, reg4 -- GitLab signature.asc Description: This is a digitally signed message part.
Bug#1067709: FTBFS in armel/armhf: some symbols disappeared
On Tue, 26 Mar 2024 01:06:34 +0200 Peter Pentchev wrote: > Control: tag -1 + confirmed > > On Tue, Mar 26, 2024 at 01:29:08AM +0500, Andrey Rakhmatullin wrote: > > Source: dante > > Version: 1.4.3+dfsg-1 > > Severity: serious > > Tags: ftbfs > > > > https://buildd.debian.org/status/fetch.php?pkg=dante&arch=armhf&ver=1.4.3+dfsg-1&stamp=1710761774&raw=0 > > Thanks for reporting this. I noticed it as soon as I uploaded this > version of dante, and I started looking into it; it is, at least partly, > fallout from the new "implicit function declarations are errors" GCC > option setting. FTR, I believe this is a good idea, no complaints here. > However, it turns out to be a bit more complicated than sprinkling > a couple of #include directives here and there; I will hopefully be > able to upload a fixed version within the next couple of days. Friendly ping? https://release.debian.org/transitions/html/glibc-2.40.html seems to indicate it's a problem for glibc 2.40 which has just been uploaded to Unstable. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1079567: systemd: Should not raise errors when not (all) BPF features are available
Package: systemd Version: 256.5-1 Severity: normal X-Debbugs-Cc: debian-ker...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I build a custom (arm64) kernel based on Debian's config and in that I disabled debug info, which in turn disabled ``CONFIG_DEBUG_INFO_BTF``. Build was successful and I tried it out on my Rock64 and what I always do when testing kernels is check dmesg for errors/warnings etc: ```sh root@rock64-test:~# dmesg --level 0,1,2 root@rock64-test:~# dmesg --level 0,1,2,3 [9.807992] rockchip-pm-domain ff10.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220 [ 16.014046] systemd[1]: bpf-restrict-fs: Failed to load BPF object: No such process ``` Former is known (and in the works of being fixed), the latter is new. Looking for that error message led me to upstream issue 32968 [1] which led me to the upstream README with the following: ``` Required for RestrictFileSystems= in service units: CONFIG_BPF CONFIG_BPF_SYSCALL CONFIG_BPF_LSM CONFIG_DEBUG_INFO_BTF CONFIG_LSM="...,bpf" or kernel booted with lsm="...,bpf". ``` I (actually) do have most of those, but not CONFIG_DEBUG_INFO_BTF and that appears to be why systemd throws an error. Looking further I found another issue [2] which says that using ``lockdown=confidentiality`` will also be problematic. I think/assume it's great that systemd would use kernel features like BPF *if* they're available. But if not, it should not throw an ERROR. An informational message is fine and possibly a warning* if it's really important. But it should detect so at *runtime* and not assume what happens to be enabled in the (Debian) kernel at a certain point in time. I did grep my system for ``bpf-restrict-fs`` to see if I could disable that feature, but it only found ``libsystemd-core-256.so``. Cheers, Diederik *) Preferably not as I'm also trying to fix those as much as possible [1] https://github.com/systemd/systemd/issues/32968 [2] https://github.com/anthraxx/linux-hardened/issues/93#issuecomment-1974260571 - -- Package-specific info: - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.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 systemd depends on: ii libacl12.3.2-2 ii libapparmor1 3.1.7-1+b1 ii libaudit1 1:4.0.1-1 ii libblkid1 2.40.2-7 ii libc6 2.39-7 ii libcap21:2.66-5 ii libmount1 2.40.2-7 ii libpam0g 1.5.3-7 ii libseccomp22.5.5-1+b1 ii libselinux13.7-1+b1 ii libssl3t64 3.3.1-7 ii libsystemd-shared 256.5-1 ii libsystemd0256.5-1 ii mount 2.40.2-7 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii libzstd11.5.6+dfsg-1 pn linux-sysctl-defaults ii ntpsec [time-daemon]1.2.3+dfsg1-3 pn systemd-cryptsetup Versions of packages systemd suggests: ii libcryptsetup12 2:2.7.4-1 ii libgcrypt20 1.11.0-6 ii libidn2-0 2.3.7-2 ii liblz4-11.9.4-3 ii liblzma55.6.2-2 pn libtss2-rc0t64 ii libtss2-tcti-device0t64 [libtss2-tcti-device0] 4.1.3-1 ii polkitd 125-2 pn systemd-boot ii systemd-container 256.5-1 pn systemd-homed pn systemd-repart pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.10-4+b1 pn dracut ii initramfs-tools0.145 pn libnss-systemd ii libpam-systemd 256.5-1 ii udev 256.5-1 - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZsoI3QAKCRDXblvOeH7b bpA2AQDrLI0m5V/IkTepJVF4NyIlRbnFEjdvRIqjAyWliyCBJAEAorba1BU9D3p4 u9nOA3NGJyY1qPzQbS2Guc1niBbImAg= =m50o -END PGP SIGNATURE-
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
On 07 Jun 2024 15:44:14 +0200 Diederik de Haas wrote: > On Friday, 1 September 2023 12:02:30 CEST Diederik de Haas wrote: > > > > AFAICT, TF-A for *rk356x* is really close to being mergeable? > > > I'm not entirely sure about that. In any case, for the rk3588 in U-Boot > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 for > rk3588 > now has a Merge Conflict (due to merging the rk3568 stuff?), but that has > seen > activity in the last month too, so hopefully that'll progress (soon) too. Support for rk3588 has been merged upstream ... yesterday \o/ signature.asc Description: This is a digitally signed message part.
Bug#1071959: arm-trusted-firmware: New upstream versions (lts-v2.10.4 and v2.11)
On 26 May 2024 16:23:07 +0200 Diederik de Haas wrote: > Source: arm-trusted-firmware > Version: 2.10.0+dfsg-1 > > Upstream recently released two new versions: > - - lts-v2.10.4 > - - v2.11 > > If you want to stay on a LTS release, then updating to 2.10.4 gives > quite a number of workarounds for errata. > > If you want to switch to the latest upstream release, then you can drop > my patch for rk3328 as that's included upstream. That patch is actually (also) part of lts-v2.10.1 signature.asc Description: This is a digitally signed message part.
Bug#1079175: python3-pkg-resources: pkg_resources cannot be imported: No module named 'packaging'
On Tue Aug 20, 2024 at 11:45 PM CEST, Cyril Brulebois wrote:
> Emanuele Rocca (2024-08-20):
> > Package: python3-pkg-resources
> > Version: 72.2.0-1
> > Severity: serious
> >
> > Importing pkg_resources fails with the following error:
> >
> > (sid-amd64-sbuild)ema@ariel:~$ python3
> > Python 3.12.5 (main, Aug 7 2024, 13:49:14) [GCC 14.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import pkg_resources
> > Traceback (most recent call last):
> > File "", line 1, in
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 95, in
> > import packaging.specifiers
> > ModuleNotFoundError: No module named 'packaging'
> >
> > This is a regression in version 72.2.0-1, whereas 70.3.0-2 worked fine.
> >
> > For an example of d-i build failure caused by this problem, see:
> > https://salsa.debian.org/installer-team/debian-installer/-/jobs/6155545
> >
> > It seems that installing python3-packaging, python3-jaraco.text, and
> > python3-platformdirs fixes it.
>
> I couldn't replicate the FTBFS within a devel sid chroot that has tons of
> extra packages, including python3-packaging, and python3-platformdirs, but
> not python3-jaraco.text.
I'm not sure if this is related or will be helpful, but I just got an
error related to 'jaraco' in a CI pipeline in reprotest, while the build
itself succeeded:
```sh
$ su salsa-ci -c "timeout ${SALSA_CI_BUILD_TIMEOUT_ARGS} reprotest \
--min-cpus $(nproc --all) \
--store-dir ${WORKING_DIR}/reprotest \
--verbosity=2 \
--vary=-time \
--vary=user_group.available+=salsa-ci,domain_host.use_sudo=1 \
${SALSA_CI_DPKG_BUILDPACKAGE_ARGS:+--append-build-command=${SALSA_CI_DPKG_BUILDPACKAGE_ARGS}}
\
${SALSA_CI_REPROTEST_ARGS} \
${WORKING_DIR}/*.dsc -- null" |& OUTPUT_FILENAME=reprotest.log filter-output
Traceback (most recent call last):
File "/usr/bin/reprotest", line 33, in
sys.exit(load_entry_point('reprotest==0.7.27', 'console_scripts',
'reprotest')())
^
File "/usr/bin/reprotest", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 205, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1387, in _gcd_import
File "", line 1360, in _find_and_load
File "", line 1331, in _find_and_load_unlocked
File "", line 935, in _load_unlocked
File "", line 995, in exec_module
File "", line 488, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 20, in
import pkg_resources
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 96, in
from jaraco.text import (
ModuleNotFoundError: No module named 'jaraco'
```
src: https://salsa.debian.org/diederik/simplescreenrecorder/-/jobs/6158157
HTH,
Diederik
signature.asc
Description: PGP signature
Bug#1079035: kmod: latest upgrade break system startup
On Tue Aug 20, 2024 at 5:55 PM CEST, Antonio wrote: > I tried to install the new version of kmod 33+20240816-2 but it seems to > remove essential packages: > > $ sudo apt install kmod > ... > > Upgrading: > kmod libkmod-dev libkmod2 > > REMOVING: > cryptsetup-initramfs initramfs-tools yubikey-luks > dracut-install initramfs-tools-core > > Summary: > Upgrading: 3, Installing: 0, Removing: 5, Not Upgrading: 0 > Download size: 182 kB > Freed space: 168 MB > > Continue? [S/n] n > Interrotto. Then the new package version is working as intended and you should NOT upgrade kmod until a new version of src:dracut has been uploaded, which would 'fix' the Breaks relation. So you gave the right response: 'n' (No) IIUC: When a new version of src:dracut is uploaded, it will build against the latest kmod version and then the 'undefined symbol' issue will be resolved, which in turn means that the generation of a new initramfs will do the right thing. At least that's the theory ;-) HTH signature.asc Description: PGP signature
Bug#1079035: kmod: latest upgrade break system startup
Control: notfound -1 30+20230519-1 On Mon Aug 19, 2024 at 12:59 PM CEST, Antonio wrote: > because i did log report after system restore, so it took that version. > The affected version is 33+20240816-1. Thanks, updating/fixing the found versions then. > Il 19/08/24 12:54, Diederik de Haas ha scritto: > > Package: kmod > > Version: 30+20230519-1 > > Why did you report it against 30+20230519-1? > Because AFAICT 30+20230519-1 and 32+20240611-1 are fine. signature.asc Description: PGP signature
Bug#1079035: kmod: latest upgrade break system startup
On Mon, 19 Aug 2024 09:45:26 +0200 Antonio wrote: > Package: kmod > Version: 30+20230519-1 Why did you report it against 30+20230519-1? Because AFAICT 30+20230519-1 and 32+20240611-1 are fine. signature.asc Description: This is a digitally signed message part.
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
On Mon, 19 Aug 2024 11:41:59 +0200 Christoph Anton Mitterer wrote: > On Mon, 2024-08-19 at 05:12 +0200, Marco d'Itri wrote: > > > With the new version, initramfs generation gives: > > I know, the plan it to rebuild dracut-install. > > Thanks. Then I guess from my side we could also already close the bug. > Your choice :-) Please don't. At least not yet so that people get warned about this bug before they try to reboot into an unbootable system. signature.asc Description: This is a digitally signed message part.
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
Control: affects -1 dracut initramfs-tools On Mon, 19 Aug 2024 16:18:44 +1200 Ash Joubert wrote: > Control: severity -1 critical > > This bug is critical because the dracut failure results in a nonbootable > initrd when followed by "apt-get install -f": > > update-initramfs: Generating /boot/initrd.img-6.10.4-amd64 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 I got the above error too, but I did my normal upgrade routine with just ``aptitude safe-upgrade`` Looks like I had a partial KDE (Frameworks) upgrade yesterday, so things look a bit 'funny', so the initial plan was to reboot immediately after today's upgrade ... when I saw the above error. It was only after I saw https://bugs.debian.org/1079031 that I realized how serious it was: ```sh root@bagend:~# ls -lh /boot/initrd.img-* -rw-r--r-- 1 root root 33M Apr 4 2022 /boot/initrd.img-5.10.0-13-amd64 -rw-r--r-- 1 root root 37M Aug 13 01:45 /boot/initrd.img-6.10.3-amd64 -rw-r--r-- 1 root root 9.5M Aug 19 11:10 /boot/initrd.img-6.10.4-amd64 -rw-r--r-- 1 root root 35M Jun 14 2023 /boot/initrd.img-6.1.0-9-amd64 -rw-r--r-- 1 root root 37M Jul 26 00:52 /boot/initrd.img-6.9.10-amd64 ``` So my original plan, reboot immediately, would've failed. But the last dracut upgrade was from 2024-07-25, so that couldn't be it. And that's when I noticed the kmod upgrade and found this bug. ``` aptitude install kmod/testing libkmod2/testing ``` Downgraded kmod and then my ``initrd.img-6.10.4-amd64`` was 37M again, so I'm pretty sure a reboot is NOW safe again. signature.asc Description: This is a digitally signed message part.
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
On Mon Aug 12, 2024 at 1:43 AM CEST, Henrique de Moraes Holschuh wrote: > > I got the *impression* that some heuristic was used to determine whether the > > microcode update should be applied. > > No. It has a simple heuristic to not increase the initramfs size by adding AMD > microcode updates unless either it is running on an AMD processor when the > amd64-microcode package is installed, OR you configure amd64-microcode to > always add the updates to the initramfs. It is an "all or nothing" thing, > and currently it has absolutely no "processor-model-aware" logic. Good to know, thanks :) And now I could also find that ``debian/initramfs.hook`` has it. The main thing that had me worried was from ``amd64-microcode-blacklist.conf``: > # The microcode module attempts to apply a microcode update when > # it autoloads. This is not always safe, so we block it by default. I had written a couple of paragraphs before I realized the check is for kernels *older* then 4.4. Since then the module is built-in (and not selectable), so that file no longer 'actually' does something. > *Uploading* the microcode update to the processor is handled by the kernel > ... [ interesting description on how it works ] ... It turns out that the problem is not with the CPU, but Asus BIOS/firmware: > It appears that the BIOS has blocked access to the MMIO range for the > CCP so that during initialization, when attempting to read the number of > queues available, 0x is read instead of the actual number of > queues available, which as Jason noted, results in the "broken BIOS" > message. https://lore.kernel.org/linux-crypto/c28836c4-e823-dc36-e753-1a5ee3831...@amd.com/ But it seems Asus isn't interested in fixing it because they consider AM4 an outdated platform and I should just accept that some things won't work... Which I ofc will never accept, so that'll be a RMA :-/ > > I'd like to know whether I'm actually running the latest microcode, but I > > haven't figured out a way how? > > /proc/cpuinfo should report the running microcode version on a recent enough > kernel. It will also log the microcode revision when it does a microcode > update. FWIW: That same version is also reported in ``dmesg``. > There is no facility to check whether what is in your system's > /lib/firmware/amd-ucode is the latest available microcode update that has been > issued by AMD to the linux-firmware project, That sucks as this was the thing I was looking for. But as written above, it seems irrelevant to the original problem I tried so solve. > I hope this information solves any lingering doubts about how it works? It does and was an interesting read, so thanks for that. AFAIC you can close this bug. I'll leave it up to you whether it's useful/worth it to maybe update some comments (like not applicable with kernels > 4.4). Cheers, Diederik signature.asc Description: PGP signature
Bug#1078871: some backlog from #1076952 (installer: reserve first 16 MiB space in default recipes for ARM devices?)
Copying my latest response on this subject into this bug (too) ... On Sat Aug 17, 2024 at 1:00 PM CEST, Holger Wansing wrote: > A summary from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug76952#65 > and follow-ups: > > > Pascal Hambourg wrote: > > On 16/08/2024 at 00:27, Diederik de Haas wrote: > > > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > > >> Then I guess a 16 MiB unused partition could be added to relevant > > >> recipes. Now, which are the relevant recipes ? In other words, which > > >> arch/subarch need it ? > > > > > >> recipes-armhf-efi (= recipes-amd64-efi) > > >> recipes-armhf > > >> recipes-arm64-efi (= recipes-amd64-efi) > > >> recipes-arm64 (= recipes-armhf) > > > > > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > > > relevant. > > > > If only Rockchip SoCs need the reserved partition and are detected as a > > specific subarchitecture by archdetect, new specific recipes for this > > subarchitecture could be added. I used Rockchip as an example as I'm familiar with that AND *afaik* they expect the U-Boot stuff to start at the furthest offset. But when U-Boot is used, every platform uses *some* offset and then needs some space/bytes for the U-Boot binary/bits. If that goes above the 2MB mark, then the current recipes overwrite part of whole of the U-Boot binary ... making the system unbootable. So you could special case Rockchip and only use the 16MB offset for the Operating System partitions and data for Rockchip SoCs. Or you could keep the first 16MB free for all ARM SoCs and then it should work for all ARM SoCs as long as they stay below the 16MB 'mark'. Which AFAIK are all of them. > > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > > it sounds 'weird' to add it to a recipe with AMD64 in its name... > > Indeed. If some ARM EFI platforms need the reserved partition, then one > of the recipes-arm*-efi symlinks could be replaced with a directory > containing new specific recipes and the other could be changed to point > to it. And the above principle also applies when EFI is being used with U-Boot as it's specific to U-Boot. signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Fri Aug 16, 2024 at 8:39 AM CEST, Pascal Hambourg wrote: > On 16/08/2024 at 00:27, Diederik de Haas wrote: > > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > >> Then I guess a 16 MiB unused partition could be added to relevant > >> recipes. Now, which are the relevant recipes ? In other words, which > >> arch/subarch need it ? > > > >> recipes-armhf-efi (= recipes-amd64-efi) > >> recipes-armhf > >> recipes-arm64-efi (= recipes-amd64-efi) > >> recipes-arm64 (= recipes-armhf) > > > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > > relevant. > > If only Rockchip SoCs need the reserved partition and are detected as a > specific subarchitecture by archdetect, new specific recipes for this > subarchitecture could be added. I used Rockchip as an example as I'm familiar with that AND *afaik* they expect the U-Boot stuff to start at the furthest offset. But when U-Boot is used, every platform uses *some* offset and then needs some space/bytes for the U-Boot binary/bits. If that goes above the 2MB mark, then the current recipes overwrite part of whole of the U-Boot binary ... making the system unbootable. So you could special case Rockchip and only use the 16MB offset for the Operating System partitions and data for Rockchip SoCs. Or you could keep the first 16MB free for all ARM SoCs and then it should work for all ARM SoCs as long as they stay below the 16MB 'mark'. Which AFAIK are all of them. > > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > > it sounds 'weird' to add it to a recipe with AMD64 in its name... > > Indeed. If some ARM EFI platforms need the reserved partition, then one > of the recipes-arm*-efi symlinks could be replaced with a directory > containing new specific recipes and the other could be changed to point > to it. And the above principle also applies when EFI is being used with U-Boot as it's specific to U-Boot. HTH, Diederik signature.asc Description: PGP signature
Bug#1078803: Please consider updating to 0.18
On Fri, 16 Aug 2024 13:37:48 +0200 Jonathan Carter wrote:
> Source: wlroots
> Version: 0.17.4-1
>
> Please consider updating wlroots to 0.18, as some new software need it
> as a dependency.
It's already available in Experimental. Note that the binary packages now have
"-0.18" in their names as upstream now supports multiple versions.
https://tracker.debian.org/pkg/wlroots shows that too and
https://release.debian.org/transitions/html/auto-wlroots.html shows there's
'even' a transition tracker for it.
But I assume you('d) know all this, so what am I missing?
signature.asc
Description: This is a digitally signed message part.
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > Then I guess a 16 MiB unused partition could be added to relevant > recipes. Now, which are the relevant recipes ? In other words, which > arch/subarch need it ? > Currently, partman-auto has the following recipes for ARM: > > recipes-armel-kirkwood > recipes-armel-orion5x > recipes-armhf-efikasb These ones are NOT relevant for this. > recipes-armhf-efi (=recipes-amd64-efi) > recipes-armhf > recipes-arm64-efi (=recipes-amd64-efi) > recipes-arm64 (=recipes-armhf) Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is relevant. I don't know if it's common, but AFAIK you can use U-Boot with EFI, but it sounds 'weird' to add it to a recipe with AMD64 in its name... signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 5:50 PM CEST, Pascal Hambourg wrote: > On 15/08/2024 at 16:25, Diederik de Haas wrote: > >> I do not know any way to reserve unallocated space in recipes. The > >> recipes could create a 16-MiB unused partition but the table in [2] > >> lists a lot of special partitions within the first 16 MiB. Are these > >> actual partitions ? If yes, how are they supposed to be created ? > > > > I think you technically could create those partitions, but those are not > > relevant. All that matter is that the first 16 MiB stay unused so that > > U-Boot can be put there. > > It is still unclear to me if it can be an unused partition or if it must > be unallocated space which can be used to create new partitions. > AFAIK, only the former can be done in recipes. Either would work. signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 3:46 PM CEST, Pascal Hambourg wrote: > On 15/08/2024 at 08:26, Holger Wansing wrote: > > Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas > > : > >> > >> I'm not 100% sure if this fits into this subject/discussion, but ... > > It is beyond the original scope (partition size limits) and I believe it > would deserve its own discussion involving people who are familiar with > ARM platforms. Ok. > Disclaimer: I have no experience nor knowledge about ARM (or any other > architectures than x86) and its boot process. For partitioning there's nothing special ... apart that the first 16MiB should not be used. > >> The U-Boot bootloader is normally put in the first part of the boot > >> device and for Rockchip based devices that can extend to the 16MB > >> 'mark'. AFAIK bootloaders for other SoCs are before that. > >> > >> If you use the current recipes you end up with an unbootable system as > >> the U-Boot bootloader get overwritten with the / (root) partition and > >> the data on it. > > AFAICS, the first partition in all non-EFI ARM recipes is /boot, not /. I shouldn't have written which partition, but the important thing is that the first 'real' partition starts at 16 MiB. > >> Right now, the instruction is to choose manual partitioning and create > >> a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the > >> normal partitions and after that you could remove that partition again. > >> And if you type in 16MB, then you need to 'hope' that it is actually > >> 16MB and not something (a bit) smaller. > > 16 MB (~15.3 MiB) or 16 MiB (~16.8 MB) ? > In partman, 1 MB really means 10^6 bytes, not 1 MiB (2^20 bytes). I think I've actually tried both and IIRC that didn't make a difference. > >> So it would be very helpful if the recipe(s) for ARM devices would > >> reserve the first 16MB automatically with plain partitioning. > > What do you mean exactly by "plain partitioning" ? Manual partitioning ? > Guiding partitioning with all files in one filesystem ? Other ? Partitioning NOT involving LVM. I 'jumped in' when the subject of creating blank/reserved partitions with LVM and then the question arose if that should also be used for "plain" partitioning, which I interpreted as not using LVM. > >> [1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian > >> [2] https://opensource.rock-chips.com/wiki_Partitions > > I do not know any way to reserve unallocated space in recipes. The > recipes could create a 16-MiB unused partition but the table in [2] > lists a lot of special partitions within the first 16 MiB. Are these > actual partitions ? If yes, how are they supposed to be created ? I think you technically could create those partitions, but those are not relevant. All that matter is that the first 16 MiB stay unused so that U-Boot can be put there. > > Looks like another incarnation of > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+770666> > > It looks like a different issue to me. IIUC these bug reports are about > parted_server erasing the boot loader location when creating a new > partition table, not the first partition overlapping with the boot > loader location. AIUI bug #770666 is the same/similar as this 'Rockchip' issue. Bug #751704 OTOH is related, but does deal with problems wrt partition table. But I don't know/understand which of parted* sub programs is responsible for which part. Cheers, Diederik signature.asc Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On Mon Aug 12, 2024 at 1:05 PM CEST, Faidon Liambotis wrote:
> On Sun, Aug 11, 2024 at 12:31:21PM -0400, Reinhard Tartler wrote:
> > But you are right, ultimately this decision is up to the maintainer to make.
>
> Maintainer here :)
>
> For this particular case, I think removing -Werror made sense as a quick
> fix to avoid kicking out the entire WasmEdge -> crun -> podman stack out
I wondered why wasmedge ended up on my radar, but that explains it ;-)
> of testing, for what is a bug that existed before (i.e. not a
> regression), and was just surfaced by a new compiler version. I had
> looked into the bug before Reinhard NMUed and the fix wasn't obvious to
> me. So taking a shortcut and prioritizing expediency over correctness
> made sense to me, in this particular case.
Yeah, makes a lot of sense.
> But, at the same time, I agree that addressing this properly means
> reporting this upstream so that the underlying bug gets fixed. I see
> this has happened now, and upstream is already responsive (as they
> usually are!).
And what happened is why I like FLOSS so much:
a bunch of people working together to solve a problem :-D
As you may have seen I was able to verify that the proposed fix indeed
solved the GCC-14 compiler issue, so I've DEP-3-ified that patch and
attached it here.
HTH,
Diederik
From: hydai
Date: Thu, 15 Aug 2024 13:59:51 +0800
Subject: [Loader] Fix GCC 14 maybe-uninitialized warning (#3659)
Origin: upstream, https://github.com/WasmEdge/WasmEdge/commit/e427a71c5a50982c35e124340fc4febcd7600226
Fix #3640
Signed-off-by: hydai
---
lib/loader/filemgr.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/loader/filemgr.cpp b/lib/loader/filemgr.cpp
index 14afba28..a6e2b95e 100644
--- a/lib/loader/filemgr.cpp
+++ b/lib/loader/filemgr.cpp
@@ -49,6 +49,11 @@ Expect FileMgr::setCode(Span CodeData) {
// Set code data. See "include/loader/filemgr.h".
Expect FileMgr::setCode(std::vector CodeData) {
reset();
+ // Tell GCC 14 that DataHolder has no data.
+ // Fix the false positive warning,
+ // which is reported by GCC 14 with `maybe-uninitialized`
+ assuming(!DataHolder);
+
DataHolder.emplace(std::move(CodeData));
Data = DataHolder->data();
Size = DataHolder->size();
--
2.45.2
signature.asc
Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 8:26 AM CEST, Holger Wansing wrote: > Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas > : > >On ARM devices it would be very useful if the first 16MB would be > >(automatically) reserved. > >The U-Boot bootloader is normally put in the first part of the boot > >device and for Rockchip based devices that can extend to the 16MB > >'mark'. AFAIK bootloaders for other SoCs are before that. > > > >So it would be very helpful if the recipe(s) for ARM devices would > >reserve the first 16MB automatically with plain partitioning. > > > >[1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian > >[2] https://opensource.rock-chips.com/wiki_Partitions > > Looks like another incarnation of > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+770666> Yep signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Fri Aug 9, 2024 at 10:08 PM CEST, Pascal Hambourg wrote: > Guided partitioning with LVM already provides a feature to reserve space > in the VG. Maybe it could be extended to guided partitioning with plain > partitions. I'm not 100% sure if this fits into this subject/discussion, but ... On ARM devices it would be very useful if the first 16MB would be (automatically) reserved. The U-Boot bootloader is normally put in the first part of the boot device and for Rockchip based devices that can extend to the 16MB 'mark'. AFAIK bootloaders for other SoCs are before that. If you use the current recipes you end up with an unbootable system as the U-Boot bootloader get overwritten with the / (root) partition and the data on it. There should be a bug for it, but I didn't manage to find it. Right now, the instruction is to choose manual partitioning and create a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the normal partitions and after that you could remove that partition again. And if you type in 16MB, then you need to 'hope' that it is actually 16MB and not something (a bit) smaller. I like to think that I'm more advanced then most users and I found it quite difficult to do. So it would be very helpful if the recipe(s) for ARM devices would reserve the first 16MB automatically with plain partitioning. [1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian [2] https://opensource.rock-chips.com/wiki_Partitions signature.asc Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On Sun Aug 11, 2024 at 6:31 PM CEST, Reinhard Tartler wrote: > I'm afraid we'll have to agree to disagree Agreed signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
On Mon Aug 12, 2024 at 8:42 AM CEST, Petter Reinholdtsen wrote:
>
> Control: tags -1 + patch
>
> The following debian/patches/1020-ffmpeg-7.patch seem to fix the build:
>
> Description: More fixes for ffmpeg 7.0
> Use class method GetChannels() as a wrapper to get the ffmpeg version
> dependent implementation instead of the channels method which
> disappeared with ffmpeg 7.
> Author: Petter Reinholdtsen
> Forwarded: no
Why not? This isn't specific to Debian and with forwarding everyone benefits.
And if a new upstream version gets released, you can likely drop the
patch.
> Last-Updated: 2024-08-12
> ---
> Index: simplescreenrecorder-salsa/src/AV/Output/AudioEncoder.cpp
> ==> ---
> simplescreenrecorder-salsa.orig/src/AV/Output/AudioEncoder.cpp
> 2024-08-12 06:33:54.881267389 +
> +++ simplescreenrecorder-salsa/src/AV/Output/AudioEncoder.cpp 2024-08-12
> 06:35:49.514541002 +
> @@ -42,7 +42,7 @@
> if(GetCodecContext()->frame_size <= 1) {
> // This is really weird, the old API uses the size of the
> *output* buffer to determine the number of
> // input samples if the number of input samples (i.e.
> frame_size) is not fixed (i.e. frame_size <= 1).
> - m_temp_buffer.resize(DEFAULT_FRAME_SAMPLES *
> GetCodecContext()->channels *
> av_get_bits_per_sample(GetCodecContext()->codec_id) / 8);
> + m_temp_buffer.resize(DEFAULT_FRAME_SAMPLES * GetChannels() *
> av_get_bits_per_sample(GetCodecContext()->codec_id) / 8);
> } else {
> m_temp_buffer.resize(std::max(FF_MIN_BUFFER_SIZE, 256 * 1024));
> }
> @@ -166,7 +166,11 @@
> assert((unsigned int) frame->GetFrame()->nb_samples ==
> GetFrameSize());
> #endif
> #if SSR_USE_AVFRAME_CHANNELS
> - assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> +# if LIBAVCODEC_VERSION_MAJOR < 61
> + assert(frame->GetFrame()->channels == GetChannels());
> +# else
> + assert(frame->GetFrame()->ch_layout.nb_channels ==
> GetChannels());
> +# endif /* LIBAVCODEC_VERSION_MAJOR < 61 */
> #endif
> #if SSR_USE_AVFRAME_SAMPLE_RATE
> assert(frame->GetFrame()->sample_rate ==
> GetCodecContext()->sample_rate);
Probably a PEBKAC issue, but it seems it didn't apply cleanly?
The Salsa CI pipeline now does succeed:
https://salsa.debian.org/diederik/simplescreenrecorder/-/pipelines/715297
(at time of writing at least the 'build' stage where it failed before)
signature.asc
Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On Sun Aug 11, 2024 at 4:56 PM CEST, Reinhard Tartler wrote: > On 2024-08-11 08:55, Diederik de Haas wrote: > > On 03 Aug 2024 11:08:58 -0400 Reinhard Tartler > > wrote: > >> I noticed this package is listed as low-NMU. As such, I'm taking the > >> liberty of uploading the following patch as NMU to sid: > >> ... > >> new file debian/patches/don-t-fail-on-unknown-gcc-warnings.patch > >> @@ -0,0 +1,20 @@ > >> +From: Reinhard Tartler > >> +Date: Sat, 3 Aug 2024 10:46:50 -0400 > >> +Subject: don't fail on unknown gcc warnings > >> + > >> +--- > >> + cmake/Helper.cmake | 1 - > >> + 1 file changed, 1 deletion(-) > >> + > >> +diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake > >> +index f9cdcf2..126e93f 100644 > >> +--- a/cmake/Helper.cmake > >> b/cmake/Helper.cmake > >> +@@ -39,7 +39,6 @@ else() > >> + > >> + if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS) > >> + list(APPEND WASMEDGE_CFLAGS > >> +- -Werror > >> + -Wno-error=pedantic > >> + ) > >> + if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND > >> CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 13) > >> new file debian/patches/series > >> @@ -0,0 +1 @@ > >> +don-t-fail-on-unknown-gcc-warnings.patch > > > > Why do you consider this an appropriate solution? > > > > Upstream explicitly want all warnings to be treated as errors and now > > with gcc-14 it generates a new warning. > > This sounds like something upstream explicitly wants to know about? > > I think this is a reasonable stance to take upstream. I've now filed > https://github.com/WasmEdge/WasmEdge/issues/3640 to document this issue, > in the hope that someone with more expertise can have a look. Thanks for reporting it upstream :-) > For Debian, I do think that this workaround is acceptable, at least for > the purposes of allowing further testing in the "testing" Distribution, > so that we get additional datapoints whether there actually are runtime > issues that stem from unitialized variables that GCC claims to detect. I disagree, but I'll let it up to the maintainer to reopen this bug or not. Packages don't transition to Testing to get additional datapoints (even though that will happen), but because there are no RC bugs, like FTBFS, currently known. That's not the case here. If you can make the argument that a specific warning can be ignored, you could override that specific warning with a clear explanation why that's OK in this particular case. This patch OTOH essentially says to ignore ALL warnings. My 0.02 signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
Control: notforwarded -1 Control: tag -1 -fixed-upstream On Sun Aug 11, 2024 at 3:43 PM CEST, Petter Reinholdtsen wrote: > [Diederik de Haas] > >> during a rebuild of the reverse dependencies for the transition to > >> ffmpeg 7.0, your package failed to build > > > > Someone made a PR and that got merged upstream. Updated metadata > > accordingly. > > This is strange, as debian/patches/0020-ffmpeg-7.patch from > https://github.com/MaartenBaert/ssr/pull/1031/ > is already part > of version 0.4.4-5. Is the patch incomplete? The error seem to happen in > code protected by '#if LIBAVCODEC_VERSION_MAJOR < 61'. Which means my forwarded was incorrect, fixing metadata accordingly. signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
On Sun Aug 11, 2024 at 3:43 PM CEST, Petter Reinholdtsen wrote:
> [Diederik de Haas]
> >> during a rebuild of the reverse dependencies for the transition to
> >> ffmpeg 7.0, your package failed to build
> >
> > Someone made a PR and that got merged upstream. Updated metadata
> > accordingly.
>
> This is strange, as debian/patches/0020-ffmpeg-7.patch from
> https://github.com/MaartenBaert/ssr/pull/1031/ > is already part
> of version 0.4.4-5. Is the patch incomplete? The error seem to happen in
> code protected by '#if LIBAVCODEC_VERSION_MAJOR < 61'.
Yes, the patch is incomplete.
> /<>/src/AV/Output/AudioEncoder.cpp: In member function ‘virtual
> bool AudioEncoder::EncodeFrame(AVFrameWrapper*)’:
> /<>/src/AV/Output/AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka
> ‘struct AVFrame’} has no member named ‘channels’
> 169 | assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> | ^~~~
> /<>/src/AV/Output/AudioEncoder.cpp:169:74: error:
> ‘AVCodecContext’ {aka ‘struct AVCodecContext’} has no member named ‘channels’
> 169 | assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> |
>^~~~
Note the line numbers. The lines that were fixed in that file did NOT
include the ``bool AudioEncoder::EncodeFrame(AVFrameWrapper* frame)``
function.
HTH
signature.asc
Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On 03 Aug 2024 11:08:58 -0400 Reinhard Tartler wrote: > I noticed this package is listed as low-NMU. As such, I'm taking the > liberty of uploading the following patch as NMU to sid: > ... > new file debian/patches/don-t-fail-on-unknown-gcc-warnings.patch > @@ -0,0 +1,20 @@ > +From: Reinhard Tartler > +Date: Sat, 3 Aug 2024 10:46:50 -0400 > +Subject: don't fail on unknown gcc warnings > + > +--- > + cmake/Helper.cmake | 1 - > + 1 file changed, 1 deletion(-) > + > +diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake > +index f9cdcf2..126e93f 100644 > +--- a/cmake/Helper.cmake > b/cmake/Helper.cmake > +@@ -39,7 +39,6 @@ else() > + > + if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS) > + list(APPEND WASMEDGE_CFLAGS > +- -Werror > + -Wno-error=pedantic > + ) > + if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND CMAKE_CXX_COMPILER_VERSION > VERSION_GREATER 13) > new file debian/patches/series > @@ -0,0 +1 @@ > +don-t-fail-on-unknown-gcc-warnings.patch Why do you consider this an appropriate solution? Upstream explicitly want all warnings to be treated as errors and now with gcc-14 it generates a new warning. This sounds like something upstream explicitly wants to know about? signature.asc Description: PGP signature
Bug#1037281: Support of Banana Pi R3
On Friday, 9 August 2024 08:02:42 CEST Bernhard Wörner wrote: > Hello Diederik > Hello Vagrant > > You wrote, that there are now the board configs in u-boot: > > configs/mt7986a_bpir3_emmc_defconfig configs/mt7986a_bpir3_sd_defconfig > > But the arm-trusted-firmware is missing. > > Is it possible, to boot the BananaPi without this firmware? > > > What is your opinion: > Is it time to order this BananaPi now? > Can we get the Banana Pi to work? I don't have an answer to any of your questions, but due to https://bugs.debian.org/1072968 the BPI-R3 is now properly supported in the Debian kernel since version 6.10. For the rest I suggest to search and/or participate in the BananaPi and OpenWrt forums where they likely know (a lot) more about BPI-R3 then I do. signature.asc Description: This is a digitally signed message part.
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Wednesday, 7 August 2024 20:33:02 CEST Holger Wansing wrote: > > > Could probably solve the long standing issue > > > "#987503 swap partition only 1 GB instead of at least 1 x RAM size" > > > stating that hibernation is broken for machines with RAM bigger than > > > 1G... > > > > Do you mean to create specific recipes for hibernation ? > > A recipe specific for server installations, which limits the swap to let's > say 1G or 2G, because the machine has enough RAM built-in. > The other (already existing) recipes could be focused on desktops/laptops, > which use something like Swap=RAM, to allow hibernation. > Having such concept, would probably allow to get rid of the > partman-auto/cap-ram thingy, which solved one problem by creating a new > one... FWIW: +1 I found it odd that the default was changed to cater for what I consider to be an exceptional situation (but could be common in server env?). signature.asc Description: This is a digitally signed message part.
Bug#1072425: k3b: FTBFS with ffmpeg 7.0: k3bf fmpegwrapper.cpp:143:26: error: ‘AVCodecContext’ {aka ‘struct AVCodecContext’} has no member named ‘channels’ xt’ {aka ‘struct AVCodecContext’} has n o m
On dinsdag 23 juli 2024 17:56:34 CEST you wrote:
> > during a rebuild of the reverse dependencies for the transition to
> > ffmpeg 7.0, your package failed to build
>
> In the upstream git repo there are 2 commits on 2024-04-13 which probably do
> fix the FTBFS issue, but don't make it compatible with ffmpeg 7.0. F.e. it
> now just returns '0' for the number of channels with ffmpeg 7.0, while it
> does return the actual value when < 7.0 ...
>
> So, linking to those commits seems pointless.
No offense, but I don't consider the following a solution:
```
int K3bFFMpegFile::channels() const
{
#if LIBAVCODEC_VERSION_MAJOR < 61
return d->codecContext->channels;
#else
#pragma Unimplemented
return 0;
#endif
}
```
(Upstream commits 712ef4adc992 + 071535a79c3d)
I'm sure it does fix the FTBFS problem, so this is just to inform users
if they care about it.
signature.asc
Description: This is a digitally signed message part.
Bug#972396: Comment on «initramfs-tools: Installation fails (no space left on device)»
On Wednesday, 31 July 2024 16:37:48 CEST Pascal Hambourg wrote: > On 31/07/2024 at 00:38, Thomas Hahn wrote: > > On Fri, 26 Jul 2024 14:00:51 +0200 Pascal Hambourg > > > > wrote: > > > firmware-nvidia-graphics was installed on systems which already had > > > firmware-misc-nonfree because firmware-misc-nonfree recommends > > > firmware-misc-nonfree so that systems which rely on Nvidia firmware are > > > not disrupted. > > > > Is it possible to only install it on systems, which have a NVIDIA > > graphics card? > > Maybe firmware-misc-nonfree could check if a Nvidia GPU is present then > trigger installation of firmware-nvidia-graphics instead of recommending > firmware-nvidia-graphics. Sounds quite convoluted. Sounds more like a recipe for disaster. Just uninstall the recommended packages you don't need. signature.asc Description: This is a digitally signed message part.
Bug#1075633: wasmedge: ftbfs with GCC-14
On Wed, 03 Jul 2024 12:47:52 + Matthias Klose wrote:
> Package: src:wasmedge
> Version: 0.13.5+dfsg-1
> Usertags: ftbfs-gcc-14
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/wasmedge_0.13.5+dfsg-1_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
Those last lines don't contain the error though, but the build log does:
```
[ 34%] Building CXX object lib/aot/CMakeFiles/wasmedgeAOT.dir/cache.cpp.o
cd /<>/obj-x86_64-linux-gnu/lib/aot && /usr/bin/c++ -DFMT_SHARED
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB
-I/<>/obj-x86_64-linux-gnu/include
-I/<>/thirdparty/blake3 -I/<>/include
-I/<>/obj-x86_64-linux-gnu/lib/system -isystem
/usr/lib/llvm-16/include -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden
-fno-exceptions -Wall -Wextra -Werror -Wno-error=pedantic
-Wno-error=dangling-reference -Wno-psabi -MD -MT
lib/aot/CMakeFiles/wasmedgeAOT.dir/cache.cpp.o -MF
CMakeFiles/wasmedgeAOT.dir/cache.cpp.o.d -o
CMakeFiles/wasmedgeAOT.dir/cache.cpp.o -c /<>/lib/aot/cache.cpp
In file included from /usr/include/c++/14/vector:66,
from /usr/include/c++/14/functional:64,
from /usr/include/spdlog/common.h:16,
from /usr/include/spdlog/spdlog.h:12,
from /<>/include/common/log.h:18,
from /<>/include/common/enum_errcode.hpp:18,
from /<>/include/common/errcode.h:16,
from /<>/include/loader/filemgr.h:17,
from /<>/lib/loader/filemgr.cpp:4:
In destructor ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp =
unsigned char; _Alloc = std::allocator]’,
inlined from ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = unsigned
char; _Alloc = std::allocator]’ at
/usr/include/c++/14/bits/stl_vector.h:738:7,
inlined from ‘constexpr void std::_Optional_payload_base<_Tp>::_M_destroy()
[with _Tp = std::vector]’ at /usr/include/c++/14/optional:283:35,
inlined from ‘constexpr void std::_Optional_payload_base<_Tp>::_M_reset()
[with _Tp = std::vector]’ at /usr/include/c++/14/optional:314:14,
inlined from ‘constexpr void std::_Optional_base_impl<_Tp, _Dp>::_M_reset()
[with _Tp = std::vector; _Dp =
std::_Optional_base, false, false>]’ at
/usr/include/c++/14/optional:466:53,
inlined from ‘std::enable_if_t<((bool)is_constructible_v<_Tp, _Args ...>),
_Tp&> std::optional<_Tp>::emplace(_Args&& ...) [with _Args =
{std::vector >}; _Tp =
std::vector]’ at /usr/include/c++/14/optional:915:18,
inlined from ‘WasmEdge::Expect
WasmEdge::FileMgr::setCode(std::vector)’ at
/<>/lib/loader/filemgr.cpp:52:21:
/usr/include/c++/14/bits/stl_vector.h:369:59: error:
‘((std::_Vector_base
>*)((char*)this + 8))[2].std::_Vector_base >::_M_impl.std::_Vector_base >::_Vector_impl::std::_Vector_base >::_Vector_impl_data.std::_Vector_base >::_Vector_impl_data::_M_start’ may be used
uninitialized [-Werror=maybe-uninitialized]
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ^~~~
/usr/include/c++/14/bits/stl_vector.h:369:31: error:
‘((std::_Vector_base
>*)((char*)this + 8))[2].std::_Vector_base >::_M_impl.std::_Vector_base >::_Vector_impl::std::_Vector_base >::_Vector_impl_data.std::_Vector_base >::_Vector_impl_data::_M_end_of_storage’
may be used uninitialized [-Werror=maybe-uninitialized]
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ^
cc1plus: all warnings being treated as errors
make[3]: *** [lib/loader/CMakeFiles/wasmedgeLoaderFileMgr.dir/build.make:79:
lib/loader/CMakeFiles/wasmedgeLoaderFileMgr.dir/filemgr.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
```
HTH
signature.asc
Description: This is a digitally signed message part.
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
Control: reopen -1 Control: retitle -1 Please extend NEWS to clarify what users can and should do On Saturday, 27 July 2024 11:30:37 CEST Dan Jacobson wrote: > Yes. The news item needs to warn: > > ** Warning: if you take no action, upon the next boot you might > 1. Not be able to network. > 2. Not be able to see your screen. > 3. Not be able to boot. > and thus unable to install the new packages to fix it too. > Therefore be sure to install the new packages ... now, unless you are > sure you know what you are doing. I guess it won't hurt to expand the NEWS item to: - Make sure users have installed the Recommended packages they need - Inform them that they can remove the automatically installed Recommended packages they don't need (which may help with the initramfs-tools bug in 0.142 and the IMO too small default /boot partition) signature.asc Description: This is a digitally signed message part.
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
On Saturday, 27 July 2024 10:54:22 CEST Dan Jacobson wrote: > That's exactly what happened to me. > Not all users automatically install recommends. Those users are ofc allowed to make that choice, but they then also accept the consequences that go with it. What you asked for is exactly how it was implemented: misc-nonfree Recommends all the packages where firmware files which were in misc-nonfree before, but are now in one of the new packages. Which allows them to remove the Recommended packages they don't need. Next to the Recommends solution, you should have also received/seen a NEWS item, which explains what to do in the new situation. Did you not receive/see that? Or was the text unclear? signature.asc Description: This is a digitally signed message part.
Bug#1076372: Re.: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels
Control: found -1 6.3.7-1 On Friday, 26 July 2024 10:49:00 CEST Stefan wrote: > The complete sentence is: > > oldest non-working kernel is 6.3.7 (package linux-image-6.3.0-1-amd64), > 6.3.5 (latest version of package package linux-image-6.3.0-0-amd64) works. Excellent, that narrows down the 'suspect list' to 332 commits. me@pc:~/dev/kernel.org/linux$ git log --oneline v6.3.5..v6.3.7 | grep "ext4: " 9ca777c1ef9a ext4: enable the lazy init thread when remounting read/write 8664693a8ff2 ext4: add lockdep annotations for i_data_sem for ea_inode's 9d993659ed77 ext4: disallow ea_inodes with extended attributes 982f2501e753 ext4: set lockdep subclass for the ea_inode in ext4_xattr_inode_cache_find() 2f1dace530e8 ext4: add EA_INODE checking to ext4_iget() And those are all pretty close to the v6.3.7 tag: $ git log --oneline 2f1dace530e8..v6.3.7 | wc -l 28 Hopefully this means there a fast/short `git bisect` possible ... signature.asc Description: This is a digitally signed message part.
Bug#1076617: installation-guide: Severely outdated information wrt partitioning
On Thursday, 25 July 2024 20:50:23 CEST Holger Wansing wrote: > Diederik de Haas wrote (Tue, 23 Jul 2024 22:14:46 > +0200): > > > > >Or as I phrased it in https://bugs.debian.org/1076582#27 : > > > > >"Maybe that document should be updated for this CENTURY?" > > > > > > I have prepared a patch, to update the installation-guide (attached), > > > mostly a removal of outdated / no longer needed information. > > > > Much better! > > > > It may be possible to improve/extend the information further, but that > > could happen another time (too). > > The real problematic parts are gone now, so thanks for that :-) > > Just pushed to git. Thanks! signature.asc Description: This is a digitally signed message part.
Bug#1077049: libliftoff: Updated debian/watch file
On 25 Jul 2024 16:35:40 +0200 Diederik de Haas wrote: > Source: libliftoff > Version: 0.4.1-1 > Severity: minor > Tags: patch > > https://tracker.debian.org/pkg/libliftoff reported it had a problem with > finding a new upstream release, which does exist, so I updated the > ``debian/watch`` file so that it now does find new versions. > > When running ``uscan`` it does report the following: > > ``` > uscan warn: Possible OpenPGP signature found at: > > https://gitlab.freedesktop.org/emersion/libliftoff/-/tags-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc Updated patch which results in a (slightly) better output, attached. ``` => Newer package available from: => https://gitlab.freedesktop.org/emersion/libliftoff/-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2 uscan warn: Possible OpenPGP signature found at: https://gitlab.freedesktop.org/emersion/libliftoff/-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch * Add debian/upstream/signing-key.asc. ```>From b54309239a510a4a5e1574f17bf42fd25f8a961b Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Thu, 25 Jul 2024 16:27:11 +0200 Subject: [PATCH] d/watch: Update uscan params https://tracker.debian.org/pkg/libliftoff reported the following issue: "Problems while searching for a new upstream version" And it (apparently) didn't notice version 0.5.0 was released. With the new uscan parameters it does find the new version. --- debian/watch | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index dc3a39f..3bb3cc7 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,4 @@ version=4 -https://gitlab.freedesktop.org/emersion/libliftoff/-/tags archive/v?@ANY_VERSION@/.*@ARCHIVE_EXT@ +opts="searchmode=plain" \ + https://gitlab.freedesktop.org/emersion/@PACKAGE@/-/tags \ + archive/v?@ANY_VERSION@/@PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@ -- 2.45.2 signature.asc Description: This is a digitally signed message part.
Bug#1077049: libliftoff: Updated debian/watch file
Source: libliftoff Version: 0.4.1-1 Severity: minor Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 https://tracker.debian.org/pkg/libliftoff reported it had a problem with finding a new upstream release, which does exist, so I updated the ``debian/watch`` file so that it now does find new versions. When running ``uscan`` it does report the following: ``` uscan warn: Possible OpenPGP signature found at: https://gitlab.freedesktop.org/emersion/libliftoff/-/tags-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch * Add debian/upstream/signing-key.asc. ``` I did NOT add the upstream signing key or add ``uscan``'s suggestion for additional parameters. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.10-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/XblvOeH7bbgUCZqJivAAKCRDXblvOeH7b bm2uAQDJoeaXr3Zm4gVKabqT4uP/mVDS4SSOcBI2YJi023EPlAD9HwJo0YKGVr2D /DbZn+1NV9JGblhXtiNNm9HIiM58dgA= =roS1 -END PGP SIGNATURE- >From 7a8628f6bad0dcbaeac7d34e92e7828c358bab5c Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Thu, 25 Jul 2024 16:27:11 +0200 Subject: [PATCH] d/watch: Update uscan params https://tracker.debian.org/pkg/libliftoff reported the following issue: "Problems while searching for a new upstream version" And it (apparently) didn't notice version 0.5.0 was released. With the new uscan parameters it does find the new version. --- debian/watch | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index dc3a39f..80eefa5 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,4 @@ version=4 -https://gitlab.freedesktop.org/emersion/libliftoff/-/tags archive/v?@ANY_VERSION@/.*@ARCHIVE_EXT@ +opts="searchmode=plain" \ + https://gitlab.freedesktop.org/emersion/@PACKAGE@/-/tags \ + -/archive/v?@ANY_VERSION@/@PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@ -- 2.45.2
Bug#1075180: libliftoff: ftbfs with GCC-14
Control: tag -1 upstream fixed-upstream patch
On Wed, 03 Jul 2024 12:33:34 + Matthias Klose wrote:
> Package: src:libliftoff
> Version: 0.4.1-1
> Usertags: ftbfs-gcc-14
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
https://gitlab.freedesktop.org/emersion/libliftoff/-/merge_requests/78 is the
upstream MR which fixes that issue. It has been merged and is part of the 0.5.0
release, which the tracker (apparently) doesn't see, but was tagged on
2024-05-28.
So the best solution seems to package version 0.5.0?
Alternatively, you can add the attached patch.
https://salsa.debian.org/diederik/libliftoff/-/tree/gcc-14-compat
can also be turned into a MR and via that you can see it does build
successfully with GCC-14, while without it, the build failed.
HTH,
Diederik>From 29a06add8ef184f85e37ff8abdc34fbaa2f4ee1e Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich
Date: Thu, 21 Dec 2023 20:15:29 +
Subject: [PATCH] layer.c: fix build against upcoming `gcc-14` (`-Werror=calloc-transposed-args`)
`gcc-14` added a new `-Wcalloc-transposed-args` warning recently. It
detected minor infelicity in `calloc()` API usage in `libliftoff`:
../layer.c: In function 'liftoff_layer_create':
../layer.c:20:48: error: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in t
ument [-Werror=calloc-transposed-args]
20 | layer->candidate_planes = calloc(sizeof(layer->candidate_planes[0]),
|^
../layer.c:20:48: note: earlier argument should specify number of elements, later size of each element
---
layer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/layer.c b/layer.c
index 73a8186..6510ea7 100644
--- a/layer.c
+++ b/layer.c
@@ -17,8 +17,8 @@ liftoff_layer_create(struct liftoff_output *output)
return NULL;
}
layer->output = output;
- layer->candidate_planes = calloc(sizeof(layer->candidate_planes[0]),
- output->device->planes_cap);
+ layer->candidate_planes = calloc(output->device->planes_cap,
+ sizeof(layer->candidate_planes[0]));
if (layer->candidate_planes == NULL) {
liftoff_log_errno(LIFTOFF_ERROR, "calloc");
free(layer);
--
GitLab
signature.asc
Description: This is a digitally signed message part.
Bug#1076372: Re.: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels
Control: found -1 6.9.7-1~bpo12+1 On Wednesday, 24 July 2024 17:24:44 CEST Stefan wrote: > I ran a few other tests: > > 1. tried package "linux-image-6.1.0-22-amd64": works > 2. tried package "linux-image-6.9.7+bpo-amd64": does not work Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find older (bpo) kernels then 6.5.10+1~bpo12+1 (where it was initially filed against) and it's useful to know what the last kernel version after 6.1 was where it worked properly and the first one where it broke. signature.asc Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
On Wednesday, 24 July 2024 13:21:36 CEST Vincent Lefevre wrote:
> On 2024-07-24 10:58:24 +0200, Diederik de Haas wrote:
> > Uninstalling firmware YOU DON'T NEED is a perfectly valid solution.
>
> How can one do that? I mean, get only the Nvidia firmware for my
> particular Nvidia card, not everything of all the existing cards
> (which is really the issue).
No, uninstalling firmware *packages* you don't need.
firmware-misc-nonfree recommends firmware-nvidia-graphics, firmware-intel-
graphics, firmware-intel-misc and firmware-mediatek because firmware *files*
which were previously in misc-nonfree got moved into their own package.
But if you don't have mediatek hardware, you don't have a reason to install
the firmware-mediatek package and when you did, you can remove/uninstall
it again.
> > What IS a general solution is upgrading initramfs-tools to version 0.143
> > currently available in Experimental as that can handle symlinks to
> > *directories*, whereas 0.142 could only deal with symlinks to files.
>
> Will it be uploaded to unstable soon?
> Installing core packages from Experimental is rather scary.
There's nothing scary about Experimental, it's just another archive area.
The only difference is that it has priority: 1 (by default), which means that
when a new version is uploaded to Experimental, it won't ('even') upgrade
to that new version. And you only get packages from Experimental when
you explicitly request them, which is what you need to do in this case.
> BTW, why doesn't compression make the symlink limitation disappear?
> I mean that if there are several copies of the same firmware, why
> doesn't compression remove all the redundancies?
The bug, afaik fixed in 0.143, is that it didn't maintain the directory
symlinks, but instead copied the linked directory in full ... resulting in
a MUCH larger size.
signature.asc
Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
On Sunday, 21 July 2024 13:13:23 CEST Simon John wrote: > Realistically we need a fix for whatever happened here and it can't be > any of: > > * remove plymouth or firmware (not practical for desktop) Plymouth is not the problem. It turns out it's installed on my laptop and I don't have this problem. Uninstalling firmware YOU DON'T NEED is a perfectly valid solution. > * make /boot bigger (not upgrade friendly) Changes to make /boot bigger by default are already in the works, but this will only affect NEW installations. There is no (easy) fix for existing systems. > * MODULES=dep (not effective) This can be useful way to tweak things in individual situations, but I don't consider that a general solution. What IS a general solution is upgrading initramfs-tools to version 0.143 currently available in Experimental as that can handle symlinks to *directories*, whereas 0.142 could only deal with symlinks to files. I already mentioned this in message #44, so it's rather disappointing that people insist on ranting about the problem, but not willing to try the suggested solution. Or they did and just didn't care to report the results back, which normally means it did fix the problem. I already closed https://bugs.debian.org/1076539 because of that and I'm inclined to do the same/similar here too, soon. (Probably just force-merging all those reports into 1) signature.asc Description: This is a digitally signed message part.
Bug#1076617: installation-guide: Severely outdated information wrt partitioning
Hi, On Tuesday, 23 July 2024 20:34:25 CEST Holger Wansing wrote: > > Am 19. Juli 2024 20:54:24 MESZ schrieb Diederik de Haas : > > >In bug #1076582 it was pointed out that the documentation at > > >https://www.debian.org/releases/stable/amd64/apcs05.en.html > > > > > >has the following line: > > >"create a small (25–50MB should suffice) partition at the beginning > > >of the disk to be used as the boot partition" > > > > > >Earlier in that bug and also in #1076539 (which likely is the same > > >issue) I made the argument that 512MB (the current d-i default) for the > > >``/boot`` partition is already problematic. > > > > > >https://bugs.debian.org/960181#15 contains the following line: > > >> There may be a bug here, in that the /boot partition was too small. > > >> That has been fixed in the installer, but unfortunately we don't have > > >> a general way to grow the partition on installed systems. > > > > > >And there have been other reports that the kernel is getting too big. > > > > > >Plymouth is installed by default and that includes the GPU modules and > > >the firmware for it. And the firmware files have been getting bigger > > >too, especially for nvidia where they just added firmware files which > > >are respectively 23MB and 38MB in size ... (sigh) > > > > > >So the recommendation of a 25-50MB ``/boot`` partition is BAD. > > >REALLY BAD as "we don't have a general way to grow the partition > > >on installed systems." > > > > > >But then I read a bit further on the above referenced page and found the > > >following: > > > > > >- - "If you have a large IDE disk" > > >- - "This restriction doesn't apply if you have a BIOS newer than around > > >1995–98" - - Seeing the word "cylinder" all over the place ... > > >- - "CHS translation mode (“Large”)" = Cylinder/Head/Sector I presume? > > > > > >At that point I fell off my chair :-O > > > > > >Or as I phrased it in https://bugs.debian.org/1076582#27 : > > >"Maybe that document should be updated for this CENTURY?" > > I have prepared a patch, to update the installation-guide (attached), > mostly a removal of outdated / no longer needed information. Much better! It may be possible to improve/extend the information further, but that could happen another time (too). The real problematic parts are gone now, so thanks for that :-) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
Control: forwarded -1 https://github.com/MaartenBaert/ssr/pull/1031/ Control: tag -1 +upstream +fixed-upstream On 2 Jun 2024 15:26:24 +0200 Sebastian Ramacher wrote: > Source: simplescreenrecorder > Version: 0.4.4-5 > Severity: important > Tags: trixie sid ftbfs > Usertags: ffmpeg-7.0 > > Hi, > > during a rebuild of the reverse dependencies for the transition to > ffmpeg 7.0, your package failed to build Someone made a PR and that got merged upstream. Updated metadata accordingly. signature.asc Description: This is a digitally signed message part.
Bug#1072425: k3b: FTBFS with ffmpeg 7.0: k3bf fmpegwrapper.cpp:143:26: error: ‘AVCodecContext’ {aka ‘struct AVCodecContext’} has no member named ‘channels’ xt’ {aka ‘struct AVCodecContext’} has n o m
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=485432 Control: tag -1 +upstream On 2 Jun 2024 15:20:46 +0200 Sebastian Ramacher wrote: > Source: k3b > Version: 23.08.3-1 > Severity: important > Tags: trixie sid ftbfs > Usertags: ffmpeg-7.0 > > Hi, > > during a rebuild of the reverse dependencies for the transition to > ffmpeg 7.0, your package failed to build In the upstream git repo there are 2 commits on 2024-04-13 which probably do fix the FTBFS issue, but don't make it compatible with ffmpeg 7.0. F.e. it now just returns '0' for the number of channels with ffmpeg 7.0, while it does return the actual value when < 7.0 ... So, linking to those commits seems pointless. signature.asc Description: This is a digitally signed message part.
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
Control: reassign -1 src:initramfs-tools 0.142 Control: fixed -1 0.143 On Friday, 19 July 2024 20:05:52 CEST Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Friday, 19 July 2024 17:27:39 CEST Diederik de Haas wrote: > They are symlinks in the firmware-nvidia-graphics package, which leads > to initramfs-tools being the problem. > > In *Experimental* there's version 0.143 and there's at least 1 report > that that keeps the symlinks (IOW: fixes the problem most likely) > > Can you test whether the problem is indeed fixed with initramfs-tools > version 0.143? No response, so I guess that means the problem is fixed with initramfs-tools version 0.143, so closing the bug with that version. signature.asc Description: This is a digitally signed message part.
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
On Tuesday, 23 July 2024 10:02:57 CEST Diederik de Haas wrote: > On 22 Jul 2024 11:52:36 +0200 Diederik de Haas wrote: > > Package: amd64-microcode > > Version: 3.20240116.2+nmu1 > > > > I was testing with `rngtest` on arm64 devices and wanted to know the > > results on my amd64 AMD (Ryzen) CPU/APU. > > > > System 1: > > CPU: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, > > stepping: 0x1) > > CPU family: 23 (in decimal) > > microcode revision: 0x08001138 (according to dmesg) > > > > System 2: > > CPU/APU: AMD Ryzen 5 5500GT with Radeon Graphics (family: 0x19, model: > > 0x50, stepping: 0x0) > > CPU family: 25 (in decimal) > > microcode revision: 0x0a5f (according to dmesg) > > > > While `rngtest` results looked excellent on System 1, it revealed that > > the HWRNG on System 2 is broken. > > I'm currently triaging it (with Asus; MB manufacturer) and they asked me > > to test with the latest microcode. So hereby a '+1' on bug #1076128. > > I looked closely how previous updates were done and made a 20240710.1+nmu1 > release myself and then used the .deb file created by Salsa's CI: > https://salsa.debian.org/diederik/amd64-microcode/-/commits/release-3.202407 > 10.1+nmu1 > > Before: > root@cknowsvr04:~# dmesg | grep microcode > [0.587262] microcode: Current revision: 0x0a5f > > After: > root@cknowsvr04:~# dmesg | grep microcode > [0.587102] microcode: Current revision: 0x0a5f > > I'm pretty sure I did the 'nmu' correctly, but it seems the microcode > update isn't applied (at all). Set ``AMD64UCODE_INITRAMFS=early`` in ``/etc/default/amd64-microcode`` and regenerated the initramfs: same result. With that changed file did an ``apt reinstall ./ Tue, 23 Jul 2024 09:26:50 +0200 ``` System 2: "family: 0x19, model: 0x50, stepping: 0x0" ... which isn't listed in the changelog, so it didn't get an update ... thus AFAIUI the reported microcode revision shouldn't have changed. Guess I can report to Asus/AMD that I either need a new microcode update or that the CPU needs a RMA ... (The original request of this bug report still stands though). Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
On 22 Jul 2024 11:52:36 +0200 Diederik de Haas wrote: > Package: amd64-microcode > Version: 3.20240116.2+nmu1 > > I was testing with `rngtest` on arm64 devices and wanted to know the > results on my amd64 AMD (Ryzen) CPU/APU. > > System 1: > CPU: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, > stepping: 0x1) > CPU family: 23 (in decimal) > microcode revision: 0x08001138 (according to dmesg) > > System 2: > CPU/APU: AMD Ryzen 5 5500GT with Radeon Graphics (family: 0x19, model: 0x50, > stepping: 0x0) > CPU family: 25 (in decimal) > microcode revision: 0x0a5f (according to dmesg) > > While `rngtest` results looked excellent on System 1, it revealed that > the HWRNG on System 2 is broken. > I'm currently triaging it (with Asus; MB manufacturer) and they asked me > to test with the latest microcode. So hereby a '+1' on bug #1076128. > > I am running the latest amd64-microcode package on both and looked > further into all the package files and actually got confused. > I got the *impression* that some heuristic was used to determine whether > the microcode update should be applied. > That impression was based on what I saw in ``/etc/default/amd64-microcode`` > and ``/etc/modprobe.d/amd64-microcode-blacklist.conf``. > > I also went looking for the microcode revision number reported by > ``dmesg`` in the upstream repo, but the relevant data seems to be part > of ``/usr/share/doc/amd64-microcode/README.gz``. > But no where did I find those microcode revision codes. > > I'd like to know whether I'm actually running the latest microcode, > but I haven't figured out a way how? > So hereby a request to clarify/document how I (and others) can verify > whether they're (actually) *running* the latest (amd64-)microcode. I looked closely how previous updates were done and made a 20240710.1+nmu1 release myself and then used the .deb file created by Salsa's CI: https://salsa.debian.org/diederik/amd64-microcode/-/commits/release-3.20240710.1+nmu1 Before: root@cknowsvr04:~# dmesg | grep microcode [0.587262] microcode: Current revision: 0x0a5f root@cknowsvr04:~# apt install ./amd64-microcode_3.20240710.1+nmu1+salsaci+20240723+2_amd64.deb Note, selecting 'amd64-microcode' instead of './amd64-microcode_3.20240710.1+nmu1+salsaci+20240723+2_amd64.deb' Upgrading: amd64-microcode ... Setting up amd64-microcode (3.20240710.1+nmu1+salsaci+20240723+2) ... update-initramfs: deferring update (trigger activated) amd64-microcode: microcode will be updated at next boot Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 root@cknowsvr04:~# reboot After: root@cknowsvr04:~# dmesg | grep microcode [0.587102] microcode: Current revision: 0x0a5f I'm pretty sure I did the 'nmu' correctly, but it seems the microcode update isn't applied (at all). signature.asc Description: This is a digitally signed message part.
Bug#1059854: libdrm2: New upstream available for libdrm
On 02 Jan 2024 07:49:47 -0500 Richard Ayotte wrote: > Package: libdrm2 > Version: 2.4.117-1 > Severity: wishlist > > A new upstream version of available for the libdrm2 package is available and > needed to run Hyprland. I guess this bug has technically be fixed, but as it hasn't been marked as such (and closed), I hope it's ok to 'reuse' this bug to request 2.4.122 which is needed for wlroots 0.18? signature.asc Description: This is a digitally signed message part.
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
Package: amd64-microcode Version: 3.20240116.2+nmu1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I was testing with `rngtest` on arm64 devices and wanted to know the results on my amd64 AMD (Ryzen) CPU/APU. System 1: CPU: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1) CPU family: 23 (in decimal) microcode revision: 0x08001138 (according to dmesg) System 2: CPU/APU: AMD Ryzen 5 5500GT with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0) CPU family: 25 (in decimal) microcode revision: 0x0a5f (according to dmesg) While `rngtest` results looked excellent on System 1, it revealed that the HWRNG on System 2 is broken. I'm currently triaging it (with Asus; MB manufacturer) and they asked me to test with the latest microcode. So hereby a '+1' on bug #1076128. I am running the latest amd64-microcode package on both and looked further into all the package files and actually got confused. I got the *impression* that some heuristic was used to determine whether the microcode update should be applied. That impression was based on what I saw in ``/etc/default/amd64-microcode`` and ``/etc/modprobe.d/amd64-microcode-blacklist.conf``. I also went looking for the microcode revision number reported by ``dmesg`` in the upstream repo, but the relevant data seems to be part of ``/usr/share/doc/amd64-microcode/README.gz``. But no where did I find those microcode revision codes. I'd like to know whether I'm actually running the latest microcode, but I haven't figured out a way how? So hereby a request to clarify/document how I (and others) can verify whether they're (actually) *running* the latest (amd64-)microcode. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.10-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 amd64-microcode depends on no packages. Versions of packages amd64-microcode recommends: ii initramfs-tools 0.142 amd64-microcode suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZp4r3QAKCRDXblvOeH7b bq07AP9eCVDDdE8Wvz/NUeibJ+PJCFObGyF93qO/i/I4ZizjNwEAgpSK/CBUAoZX B+IEmONl1FxVeKNCs2aaWOKMzim5rwQ= =2pIO -END PGP SIGNATURE-
Bug#1076617: installation-guide: Severely outdated information wrt partitioning
On Saturday, 20 July 2024 17:07:18 CEST Holger Wansing wrote: > This bug seems firstly a documentation issue, but one could also argue, > that there's another topic with the /boot partition being to small these > days in the light of bigger initrds due to firmware includes etc. Agreed. > So, before changing the doc, we should first evaluate, if the default size > should be increased. > > Thoughts? For my thoughts, I'll just quote what I said in the submission: On vrijdag 19 juli 2024 20:54:24 CEST Diederik de Haas wrote: > For ``/boot`` size it should minimally follow d-i's default, but I > actually think both should be updated to 1G in size, which should > (generally) not be a problem with current TBs NVMe drives. signature.asc Description: This is a digitally signed message part.
Bug#1076617: installation-guide: Severely outdated information wrt partitioning
Source: installation-guide Version: 20230623 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In bug #1076582 it was pointed out that the documentation at https://www.debian.org/releases/stable/amd64/apcs05.en.html has the following line: "create a small (25–50MB should suffice) partition at the beginning of the disk to be used as the boot partition" Earlier in that bug and also in #1076539 (which likely is the same issue) I made the argument that 512MB (the current d-i default) for the ``/boot`` partition is already problematic. https://bugs.debian.org/960181#15 contains the following line: > There may be a bug here, in that the /boot partition was too small. > That has been fixed in the installer, but unfortunately we don't have > a general way to grow the partition on installed systems. And there have been other reports that the kernel is getting too big. Plymouth is installed by default and that includes the GPU modules and the firmware for it. And the firmware files have been getting bigger too, especially for nvidia where they just added firmware files which are respectively 23MB and 38MB in size ... (sigh) So the recommendation of a 25-50MB ``/boot`` partition is BAD. REALLY BAD as "we don't have a general way to grow the partition on installed systems." But then I read a bit further on the above referenced page and found the following: - - "If you have a large IDE disk" - - "This restriction doesn't apply if you have a BIOS newer than around 1995–98" - - Seeing the word "cylinder" all over the place ... - - "CHS translation mode (“Large”)" = Cylinder/Head/Sector I presume? At that point I fell off my chair :-O Or as I phrased it in https://bugs.debian.org/1076582#27 : "Maybe that document should be updated for this CENTURY?" I actually think this bug should be RC, but couldn't (quickly) find which (if any) Policy rules it violated. And 'critical' is possibly a bit much? But I think these recommendations ought to be updated before Trixie is released and possibly current Stable docs updated in case someone follows the Installation Guide recommendation (which is normally and otherwise a good thing). For ``/boot`` size it should minimally follow d-i's default, but I actually think both should be updated to 1G in size, which should (generally) not be a problem with current TBs NVMe drives. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.9-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/XblvOeH7bbgUCZpq2WQAKCRDXblvOeH7b bkzhAQCWg9McvuTHGa23GOMygGw1kBk7ubr+U1aawm5e1vtmHAEAwHSzQBAzAft+ iKW6W2syMOTg4dcAncK5uO7k2QCe1AI= =+qN2 -END PGP SIGNATURE-
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
Control: tag -1 moreinfo On Friday, 19 July 2024 17:27:39 CEST Diederik de Haas wrote: > Today I learned something new and that is that plymouth includes > GPU modules AND their firmware in the initramfs. And learned something else via https://bugs.debian.org/1076582#37 : On vrijdag 19 juli 2024 17:56:30 CEST Chris Hofstaedtler wrote: > One of the things I've noticed: > > /usr/lib/firmware/nvidia/tu104/gsp is supposed to be a symlink to > /usr/lib/firmware/nvidia/tu102/gsp. However, in initrd.img, this is > a copy of the directory; accounting for 25M on its own. > > No wonder the initrd is way too large. They are symlinks in the firmware-nvidia-graphics package, which leads to initramfs-tools being the problem. In *Experimental* there's version 0.143 and there's at least 1 report that that keeps the symlinks (IOW: fixes the problem most likely) Can you test whether the problem is indeed fixed with initramfs-tools version 0.143? signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Control: tag -1 pending On Friday, 28 June 2024 08:47:52 CEST Diederik de Haas wrote: > Control: tag -1 patch > > I submitted a MR to fix this bug with my changes here: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 And that MR has been merged into master and thus should land in the next 6.10 upload \o/ signature.asc Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
Control: affects -1 firmware-nvidia-graphics On Friday, 19 July 2024 17:56:30 CEST Chris Hofstaedtler wrote: > Control: retitle -1 initramfs-tools: duplicates nvidia firmware files > > On Fri, Jul 19, 2024 at 04:43:47PM +0200, Diederik de Haas wrote: > > > In any case, the upgrade should work for any user, including when > > > all these packages are needed. > > > > The real problem seems to be the size of /boot/ ... > > Not really. It's nice that we can *postpone* that problem a while longer. > A large part of the problem is that initramfs explodes > the size of the nvidia firmware. > > On the root file system, in /usr/lib/firmware, the nvidia firmware > files are 66MB (uncompressed!). > However, the initrd.img grows from 64M to 250M (compressed!) when > firmware-nvidia-graphics is installed. There is something seriously > wrong here. > > One of the things I've noticed: > > /usr/lib/firmware/nvidia/tu104/gsp is supposed to be a symlink to > /usr/lib/firmware/nvidia/tu102/gsp. However, in initrd.img, this is > a copy of the directory; accounting for 25M on its own. > > No wonder the initrd is way too large. Nice find! Adding firmware-nvidia-graphics as affects (which hopefully will warn users of that package of this problem) > There are probably more cases where the symlinks are not preserved. > This needs to be fixed in initramfs (or whatever hook script copies > the firmware files). There was a relatively recent upload of initramfs-tools 0.143 to *Experimental* and I'm curious if that would help in this case. signature.asc Description: This is a digitally signed message part.
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
Control: severity -1 important On Thursday, 18 July 2024 10:54:48 CEST Diederik de Haas wrote: > Control: severity -1 minor > > On 18 Jul 2024 09:43:38 +0200 Bastian Venthur wrote: > > Package: plymouth > > Version: 24.004.60-2 > > Severity: important > > X-Debbugs-Cc: vent...@debian.org > > > > Dear Maintainer, > > > > trying to update plymouth fails with "No space left on device": > > > > sudo aptitude -u > > Performing actions... > > Setting up initramfs-tools (0.142) ... > > update-initramfs: deferring update (trigger activated) > > Setting up plymouth (24.004.60-2) ... > > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > > ... > > W: Possible missing firmware /lib/firmware/amdgpu/smu_14_0_2.bin for > > module amdgpu zstd: error 70 : Write error : cannot write block : No > > space left on device E: mkinitramfs failure zstd -q -9 -T0 70 > > update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. > > > > dpkg: error processing package plymouth (--configure): > > installed plymouth package post-installation script subprocess returned > > error exit status 1> > > dpkg: dependency problems prevent configuration of plymouth-label: > > plymouth-label depends on plymouth (= 24.004.60-2); however: > > Package plymouth is not configured yet. > > > > /boot still has 170MB free: > > > > # df -h /boot > > Filesystem Size Used Avail Use% Mounted on > > /dev/nvme0n1p2 471M 275M 172M 62% /boot > > I fail to see how this is any package's problem. > Your boot partition is too small to perform the requested operation. > > During compression it needs the space for the uncompressed files and > the space needed for the compressed archive, so it generally needs > (much) more space then it finally needs as the uncompressed files will > be removed again once the compressed archive is complete. Looks like I was incorrect on that one; from 929424#10 : "initramfs-tools doesn't store temporary files on /boot" Apologies for that. Today I learned something new and that is that plymouth includes GPU modules AND their firmware in the initramfs. And with the now much larger firmware packages/files, that made the actual problem much more urgent. > Solution: make your boot partition larger. Or remove older/other > kernels, but IMO this will only delay the inevitable. And that is IMO still the actual issue. Due to a VERY similar bug report, I was made aware of some rather horrific advise ... in the official Debian documentation: https://bugs.debian.org/1076582#27 On the d-i size (in code) things were apparently already evolved into this century, but I still think 512MB for /boot partition is problematic. And even more so when plymouth is in the mix, where (too many?) firmware files get included in initramfs. > Reducing severity to minor, but I actually think it should just be closed. So I bumped up the severity, but not reassigned it as I think it's useful if all these reports came in on the same Mailing List, which in this case is the debian-kernel ML ... > On 18 Jul 2024 10:17:20 +0200 Laurent Bigonville wrote: > > It's related to firmware-misc-nonfree that is now pulling > > firmware-nvidia-graphics that contains a lot of (non-free) firmwares. > > > > With firmware-nvidia-graphics installed, my initramfs grows to something > > like 200M compared to 64M without it. > > The firmware-nvidia-graphics package was created exactly because its size > got big(ger) and (partially therefor) deserved its own package instead of > making the firmware-misc-nonfree extremely large. That package is meant > for 'the other' firmware which don't deserve their own package. > The firmware-nvidia-graphics is recommended by firmware-misc-nonfree as > the nvidia graphics firmware files were moved from the latter to the former. > > Solution: If you don't need firmware-nvidia-graphics, don't install it. > If you do need it, but don't have the space for it, then increase your > storage size. That's still correct (though). But it may be useful to extend the NEWS to be more explicit and verbose about the potential consequences. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
[ not including debian-release for this ] On Friday, 19 July 2024 15:54:57 CEST Vincent Lefevre wrote: > On 2024-07-19 14:32:28 +0200, Diederik de Haas wrote: > > On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > > > When upgrading the firmware: > > > > > > [...] > > > Setting up firmware-intel-graphics (20240610-1) ... > > > Setting up firmware-iwlwifi (20240610-1) ... > > > Setting up firmware-misc-nonfree (20240610-1) ... > > > Setting up firmware-nvidia-graphics (20240610-1) ... > > > Setting up firmware-intel-misc (20240610-1) ... > > > Setting up firmware-mediatek (20240610-1) ... > > > Processing triggers for initramfs-tools (0.142) ... > > > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > > > zstd: error 70 : Write error : cannot write block : No space left on > > > device > > > > If you do not need all that firmware, try removing the ones you > > don't need. Especially if you don't need nvidia-graphics firmware, > > remove that because that is BIG (and the reason it got split out > > from misc-nonfree). It's a RECOMMENDS, so you can remove it (if you > > don't need it). > > The graphics card is a Nvidia one, so I probably need this firmware. Agreed, you should have that firmware package installed. I learned something new today: Are you using plymouth? Because plymouth does include GPU kernel modules and the firmware for it. > In any case, the upgrade should work for any user, including when > all these packages are needed. The real problem seems to be the size of /boot/ ... > > On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > > > This is wrong. There's plenty of space: > > > > > > FilesystemSize Used Avail Use% Mounted on > > > ... > > > > > > 456M 243M 189M 57% /boot > > > > While generating the initramfs it needs a LOT more space then what's > > needed > > when the generation completes successfully. It's all the uncompressed > > files + the size of the compressed archived/initramfs. > > When done, it can remove all the uncompressed files. > > But it would be silly to use the /boot partition (which is typically > small) for storing the temporary uncompressed files. Smaller then the root partition, but it's problematic when /boot partition is actually 'small' ... > Note that https://www.debian.org/releases/stable/amd64/apcs01.en.html > does not recommend anything for the /boot partition. > > https://www.debian.org/releases/stable/amd64/apcs05.en.html says > "25–50MB should suffice" (though this is probably not sufficient > for most uses). > > https://linuxhint.com/boot-partition-size-debian/ says > 256 MB / 512 MB for Debian 11. > > Mine has 512 MB (more that 10 times the recommended 25–50MB). You may have guessed by my previous reply (which did include debian-release) that those recommendations are ABSURD. A 512 MB /boot/ partition *can* work nowadays, but it gets problematic when you use plymouth which then includes firmware for GPU modules ... and those have exploded in size ... mainly nvidia though. See f.e. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f4a3c72e5c413a601d1e21f9606f1c94a610d05d But IIUC, the default size for /boot/ partition by d-i is 512 MB and I think that's problematic, especially since enlarging the /boot partition is not easy to do for 'average' users. The kernels themselves have got bigger over time which was previously already reported as (being/becoming) problematic, especially if you have several kernels installed. But it seems the initrd file sizes increase now really causes problems. Especially if GPU firmware files get included in them. I don't use plymouth and (therefor) I don't have GPU modules nor GPU firmware files in them ... and my initrd is 37M in size (for 6.9.9). And when I installed my system, I made the /boot/ partition 2G in size... signature.asc Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
[ adding debian-release to the list for some troubling observations ] On Friday, 19 July 2024 15:54:57 CEST Vincent Lefevre wrote: > On 2024-07-19 14:32:28 +0200, Diederik de Haas wrote: > > On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > > > When upgrading the firmware: > > > > > > [...] > > > Setting up firmware-intel-graphics (20240610-1) ... > > > Setting up firmware-iwlwifi (20240610-1) ... > > > Setting up firmware-misc-nonfree (20240610-1) ... > > > Setting up firmware-nvidia-graphics (20240610-1) ... > > > Setting up firmware-intel-misc (20240610-1) ... > > > Setting up firmware-mediatek (20240610-1) ... > > > Processing triggers for initramfs-tools (0.142) ... > > > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > > > zstd: error 70 : Write error : cannot write block : No space left on > > > device > > > > If you do not need all that firmware, try removing the ones you > > don't need. Especially if you don't need nvidia-graphics firmware, > > remove that because that is BIG (and the reason it got split out > > from misc-nonfree). It's a RECOMMENDS, so you can remove it (if you > > don't need it). > > The graphics card is a Nvidia one, so I probably need this firmware. > > In any case, the upgrade should work for any user, including when > all these packages are needed. > > > On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > > > This is wrong. There's plenty of space: > > > > > > FilesystemSize Used Avail Use% Mounted on > > > ... > > > > > > 456M 243M 189M 57% /boot > > > > While generating the initramfs it needs a LOT more space then what's > > needed > > when the generation completes successfully. It's all the uncompressed > > files + the size of the compressed archived/initramfs. > > When done, it can remove all the uncompressed files. > > But it would be silly to use the /boot partition (which is typically > small) for storing the temporary uncompressed files. > > Note that https://www.debian.org/releases/stable/amd64/apcs01.en.html > does not recommend anything for the /boot partition. > > https://www.debian.org/releases/stable/amd64/apcs05.en.html says > "25–50MB should suffice" (though this is probably not sufficient > for most uses). > > https://linuxhint.com/boot-partition-size-debian/ says > 256 MB / 512 MB for Debian 11. > > Mine has 512 MB (more that 10 times the recommended 25–50MB). Holy crap! Some quotes from the Stable documentation: "If you have a large IDE disk" "This restriction doesn't apply if you have a BIOS newer than around 1995–98" Seeing the word "cylinder" all over the place ... "CHS translation mode (“Large”)" = Cylinder/Head/Sector I presume? And then indeed "25–50MB should suffice" (for /boot/ partition). Maybe that document should be updated for this CENTURY? signature.asc Description: This is a digitally signed message part.
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
Control: tag -1 moreinfo On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > When upgrading the firmware: > > [...] > Setting up firmware-intel-graphics (20240610-1) ... > Setting up firmware-iwlwifi (20240610-1) ... > Setting up firmware-misc-nonfree (20240610-1) ... > Setting up firmware-nvidia-graphics (20240610-1) ... > Setting up firmware-intel-misc (20240610-1) ... > Setting up firmware-mediatek (20240610-1) ... > Processing triggers for initramfs-tools (0.142) ... > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > zstd: error 70 : Write error : cannot write block : No space left on device If you do not need all that firmware, try removing the ones you don't need. Especially if you don't need nvidia-graphics firmware, remove that because that is BIG (and the reason it got split out from misc-nonfree). It's a RECOMMENDS, so you can remove it (if you don't need it). On Friday, 19 July 2024 13:08:50 CEST Vincent Lefevre wrote: > This is wrong. There's plenty of space: > > FilesystemSize Used Avail Use% Mounted on > ... > 456M 243M 189M 57% /boot While generating the initramfs it needs a LOT more space then what's needed when the generation completes successfully. It's all the uncompressed files + the size of the compressed archived/initramfs. When done, it can remove all the uncompressed files. signature.asc Description: This is a digitally signed message part.
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
On Thursday, 18 July 2024 11:11:23 CEST Laurent Bigonville wrote: > Well you change expectation from users that have firmware-misc-nonfree > installed by pulling that huge package I fail to see how. If those files weren't split into their own packages, the updated/new firmware-misc-nonfree would've contained the firmware of the 'old' misc-nonfree + nvidia-graphics + intel-graphics + mediatek/ralink + new files that would otherwise have been added for misc-nonfree. See also https://bugs.debian.org/1057786 > IMVHO, a lot of people with firmware-misc-nonfree installed will > experience an issue when updating. You should've seen a NEWS entry informing you of the changes. If that didn't happen, that's a problem/bug. On donderdag 18 juli 2024 11:14:35 CEST you wrote: > On 18.07.24 11:11, Laurent Bigonville wrote: > > The /boot partition size I've here is the default one from the > > debian-installer > > This seems to be the core of the problem. In my case it is 500MB, and > was the default from the install. So many users will be affected by default. I do agree with that. And the kernel size growing bigger contributed to that becoming a (bigger) problem. (There are bug reports about that) When I set up my system, I made /boot 2G because I foresaw this problem (and I intended to do a bit more with kernels then the average user). I think a very valid argument can be made to change the default in d-i, but to be blunt: you *accepted* the *defaults*. But most people are probably not as experienced with Debian as the two of you which in turn would make me point out the same problem, but be more subtle/ gentle about it. Still, "No space left on device" is not a packaging problem. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
Control: severity -1 minor On 18 Jul 2024 09:43:38 +0200 Bastian Venthur wrote: > Package: plymouth > Version: 24.004.60-2 > Severity: important > X-Debbugs-Cc: vent...@debian.org > > Dear Maintainer, > > trying to update plymouth fails with "No space left on device": > > sudo aptitude -u > Performing actions... > Setting up initramfs-tools (0.142) ... > update-initramfs: deferring update (trigger activated) > Setting up plymouth (24.004.60-2) ... > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > ... > W: Possible missing firmware /lib/firmware/amdgpu/smu_14_0_2.bin for module > amdgpu > zstd: error 70 : Write error : cannot write block : No space left on device > E: mkinitramfs failure zstd -q -9 -T0 70 > update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. > dpkg: error processing package plymouth (--configure): > installed plymouth package post-installation script subprocess returned > error exit status 1 > dpkg: dependency problems prevent configuration of plymouth-label: > plymouth-label depends on plymouth (= 24.004.60-2); however: > Package plymouth is not configured yet. > > > /boot still has 170MB free: > > # df -h /boot > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p2 471M 275M 172M 62% /boot I fail to see how this is any package's problem. Your boot partition is too small to perform the requested operation. During compression it needs the space for the uncompressed files and the space needed for the compressed archive, so it generally needs (much) more space then it finally needs as the uncompressed files will be removed again once the compressed archive is complete. Solution: make your boot partition larger. Or remove older/other kernels, but IMO this will only delay the inevitable. Reducing severity to minor, but I actually think it should just be closed. On 18 Jul 2024 10:17:20 +0200 Laurent Bigonville wrote: > It's related to firmware-misc-nonfree that is now pulling > firmware-nvidia-graphics that contains a lot of (non-free) firmwares. > > With firmware-nvidia-graphics installed, my initramfs grows to something > like 200M compared to 64M without it. The firmware-nvidia-graphics package was created exactly because its size got big(ger) and (partially therefor) deserved its own package instead of making the firmware-misc-nonfree extremely large. That package is meant for 'the other' firmware which don't deserve their own package. The firmware-nvidia-graphics is recommended by firmware-misc-nonfree as the nvidia graphics firmware files were moved from the latter to the former. Solution: If you don't need firmware-nvidia-graphics, don't install it. If you do need it, but don't have the space for it, then increase your storage size. > I'm reassigning this to firmware-misc-nonfree As said above, this is IMO not any package's problem. signature.asc Description: This is a digitally signed message part.
Bug#1043273: amd64-microcode: AMD SEV firmware files not loaded on matching systems
On Tuesday, 12 September 2023 01:23:05 CEST Diederik de Haas wrote: > On Tue, 8 Aug 2023 13:41:56 +0300 Marko Karppinen wrote: > > It seems nothing will make you understand an issue faster than filing your > > first ever Debian bug about it :) > > > > I noticed just now that the firmware loading *will* fall back to the > > correct file, it just happens after it has emitted the error lines: > > > [4.069026] ccp :4a:00.1: firmware: failed to load > > > amd/amd_sev_fam17h_model31h.sbin (-2) [4.069293] firmware_class: > > > See https://wiki.debian.org/Firmware for information about missing > > > firmware [4.069597] ccp :4a:00.1: firmware: failed to load > > > amd/amd_sev_fam17h_model31h.sbin (-2) [4.070002] ccp :4a:00.1: > > > firmware: direct-loading firmware amd/amd_sev_fam17h_model3xh.sbin [ > > > 4.102461] ccp :4a:00.1: SEV API:0.24 build:16 > > AFAICT this is actually https://bugs.debian.org/1040738, which makes it a > kernel bug. As the maintainer has reassigned/merged #1051635 into this one > and thus to the amd64-microcode package, I'll leave reassigning it to > src:linux over to (one of) the maintainer(s). FYI (and now also with you in To): Bug 1040738 has been fixed in kernel 6.9.2-1~exp1, which means you should no longer receive those firmware error messages when they aren't actual errors. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1076419: Please enable SND_HDA_SCODEC_TAS2781_I2C
On Tuesday, 16 July 2024 07:16:29 CEST Thomas Goirand wrote: > I have a Legion Pro 7 laptop, which I made my company buy because > it has 16 cores, so I can build stuff faster. I love the hardware, > but it produces no sound: sound board is supported, but it looks > like the current Debian kernel doesn't have its speaker driver > enabled. > > It took me a lot of research to find this patch: > https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1208376/tas2781-t > as2781s-linux-drivers-for-lenovo-laptops/4603230?tisearch=e2e-sitesearch&key > match=tas2781 The kernel module is now enabled, but you'll likely run into another problem as it currently is impossible for Debian to distribute the firmware. See https://salsa.debian.org/kernel-team/linux/-/merge_requests/1033#note_471473 There have already been attempts to get the licensing problem fixed: https://lore.kernel.org/linux-firmware/95023a6158e1359c18797d7ed10a6914cf781f84.ca...@irl.hu/ but so far without any success. Maybe try it via that support forum? signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Wednesday, 12 June 2024 15:59:27 CEST Diederik de Haas wrote: > On Tuesday, 11 June 2024 09:01:20 CEST Diederik de Haas wrote: > > I already have a local branch to add preliminary support for the OpenWrt > > One router [1] [2] which uses the same SoC :-) > > I was wrong. > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts > #include "mt7986a.dtsi" > > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts > #include "mt7981b.dtsi" On the bright side, initial support for OpenWrt One is coming in 6.11 \o/ https://lore.kernel.org/all/20240527115933.7396-1-zaj...@gmail.com/ https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/tag/?h=mtk-dts64-for-v6.11 signature.asc Description: This is a digitally signed message part.
Bug#1075784: tracker.debian.org: Tracker is not sending email notifications for subscriptions
On Friday, 5 July 2024 06:12:58 CEST J Mo wrote: > Recently I signed up a new account on https://tracker.debian.org. > However, I am not receiving notifications when I expect that I should have. > > I set up subscriptions for multiple packages, including > linux-image-amd64, openssh-server, and openssh-sftp-server, all of which > have been updated in recent weeks, during the time the new account and > subscriptions existed. I should have recieved some kind of notification, > but nothing has come in. In my case it it seemed to have worked for a while, but then after a while I got a notification with the following content: "The email didi.deb...@cknow.org bounces too much, it has been unsubscribed from the Debian Package Tracker." No idea why it received bounces, nor did I receive a message that they happened, in which case I could've tried to do something about it. signature.asc Description: This is a digitally signed message part.
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
On Thursday, 4 July 2024 13:19:59 CEST Cyril Brulebois wrote: > It just seems to me that, at least with qemu packages currently found in > Debian 12, earlier versions of the installer (based on 6.8.y) didn't > need that particular module to get X up and running, while newer > versions of the installer (based on 6.9.y) do. At least based on two > spot checks: one with the earliest version available, one with last > night's. There have been commits in ``drivers/gpu/drm/qxl/`` merged in 6.9 (and fwiw also in 6.10), so it's possible that plays a factor as well. signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Monday, 1 July 2024 17:17:46 CEST Nathan MALO wrote: > It seems to me that it is working as expected ! Awesome :-) signature.asc Description: This is a digitally signed message part.
Bug#1061321: marked as done (firmware-nonfree: Important changes coming up with upstream version 20230919)
On Monday, 1 July 2024 09:17:43 CEST Diederik de Haas wrote: > On zondag 30 juni 2024 22:33:03 CEST you wrote: > > I don't know the details anymore, but I recently ran into an interesting > > problem though as the 'physical' firmware file was put in the atheros > > packages instead of a link to the place of the qcom-soc package. Could be > > a > > PEBKAC issue, but you might verify whether it's doing the right thing. > > Not a PEBKAC issue. ``ath10k/WCN3990/hw1.0/wlanmbsp.mbn`` file (3.6MB) is in > firmware-atheros while that file ought to be in firmware-qcom-soc (and a > *link* to that file in firmware-atheros) Forgot to mention that I checked the .deb files produced by MR 96 (but that is consistent with the deb files that I build locally with which I noticed the issue) signature.asc Description: This is a digitally signed message part.
Bug#1061321: marked as done (firmware-nonfree: Important changes coming up with upstream version 20230919)
On zondag 30 juni 2024 22:33:03 CEST you wrote: > I don't know the details anymore, but I recently ran into an interesting > problem though as the 'physical' firmware file was put in the atheros > packages instead of a link to the place of the qcom-soc package. Could be a > PEBKAC issue, but you might verify whether it's doing the right thing. Not a PEBKAC issue. ``ath10k/WCN3990/hw1.0/wlanmbsp.mbn`` file (3.6MB) is in firmware-atheros while that file ought to be in firmware-qcom-soc (and a *link* to that file in firmware-atheros) 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
On Saturday, 4 February 2023 22:12:24 CEST Salvatore Bonaccorso wrote: > Hi, > > On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote: > > Hi! > > > > Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]: > > > > 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. > > > > 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? > > Regards, > Salvatore > > p.s.: sorry misstyped initially the origin source package, was obviously > not meaning raspi-config, so raspi-firmware. Just quoting this here as AFAICT Salvatore's solution (new source package) is the right one (and removed from the raspi-firmware package). I'll not remove the 'upstream' tag as it's set by the maintainer, but if you think the RPi Foundation will do the work to send it to the linux-firmware repo, then I have a bridge I'd like to sell you. signature.asc Description: This is a digitally signed message part.
Bug#1074505: dpkg: warning: while removing linux-image-6.8.11-amd64, directory '/lib/modules/6.8.11-amd64' not empty so not removed
Control: reassign -1 src:linux Control: forcemerge -1 1093998 On Sunday, 30 June 2024 06:07:55 CEST Dan Jacobson wrote: > Package: linux-image-amd64 > > dpkg: warning: while removing linux-image-6.8.11-amd64, directory > '/lib/modules/6.8.11-amd64' not empty so not removed # ls -l > /lib/modules/6.8.11-amd64 > total 4 > -rw-r--r-- 1 root root 55 05-27 14:48 modules.weakdep See https://bugs.debian.org/1073998 signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:40:50 CEST Mario Limonciello wrote: > > As this will normally be a headless system, I'm actually looking if I can > > turn the GPU off, *unless* there's an HDMI cable plugged in. > > So (at least for now), the GPUs only function is to have a display when I > > need it for troubleshooting. > > With nothing plugged in, modern AMD GPUs will go into runtime PM and > depending on the motherboard design either D3hot or D3cold. I need to figure out how I can query the various things and learn what they actually mean. F.e. on the frame.work forum I found: `cat /sys/class/drm/card0/device/power/runtime_status` and that returns 'active', but I have no idea what that means. Like I said before: lots of research to do ;-) > D3cold is as close to off as you can get. Good to know :-) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:24:58 CEST Mario Limonciello wrote: > On 6/28/2024 12:05, Diederik de Haas wrote: > > On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > >> On 6/28/2024 11:18, Diederik de Haas wrote: > >>>> I don't think so. I've never heard of this actually used in a desktop > >>>> board. It's for mobile designs AFAIK. > >>> > >>> I can understand that the initial/original goal/target was mobile. > >>> But is there a(ny) technical reason why it couldn't also support > >>> 'desktop' > >>> systems? > >>> IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> > >> It needs information about the hardware thermal design to change the > >> correct coefficients. > > > > Isn't that something that AMD would know? > > I have software interfaces that I can use to tell you what APU > coefficient is currently programmed. I can tell you what the MAX an APU > can support is but I can't tell you what the "rest" of the hardware > design can support. > > This depends on hardware stuff. For example: > 1) how big of a heat pipe there is > 2) how big of a power supply there is > 3) how many fans there are > 4) is there a beefy GPU sharing power > 5) etc. > > Even if you have the thermal headroom if you turn PPT limits up too much > your GPU performance might suffer. As this will normally be a headless system, I'm actually looking if I can turn the GPU off, *unless* there's an HDMI cable plugged in. So (at least for now), the GPUs only function is to have a display when I need it for troubleshooting. > Designers do thermal simulations to come up with the numbers for all > this stuff and it's proprietary information to go with their design. > > That's why it's encoded in BIOS or EC and OS will read it and offer the > interface to the user. I really don't think it makes sense in a design > it yourself desktop. Ah, ok. Clear :-) I (initially) thought you meant hardware thermal design *of the CPU*, but I now know it's 'a bit' more then that. Thanks, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > On 6/28/2024 11:18, Diederik de Haas wrote: > >> I don't think so. I've never heard of this actually used in a desktop > >> board. It's for mobile designs AFAIK. > > > > I can understand that the initial/original goal/target was mobile. > > But is there a(ny) technical reason why it couldn't also support 'desktop' > > systems? > > IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > > It needs information about the hardware thermal design to change the > correct coefficients. Isn't that something that AMD would know? > For example just changing the sPPT or fPPT without the appropriate > thermal headroom will cause the SOC to go into thermal throttling > prematurely and hurt your performance. > > That's why OEMs encode this information in their EC or in the BIOS and > advertise it in the PMF ACPI tables what they can do. > > > Ok. I might be able to convince Asus to add it, but I can also configure > > my system to 'modprobe' it on boot up. > > Loading it with modprobe doesn't do anything if there is no ACPI device > to bind to. It's just like having it compiled into your kernel and it > not binding to any device. Ok, understood. I'm not too positive I could convince Asus to add that to their 'BIOS', but I can try. > Like I said; I've never seen it on a desktop. Because of what it's > intended to do in it's current form, I think it's unlikely that it would > be added there. Understood. Hopefully this does make AMD aware that non-laptop/mobile devices could (or should!) be a potential target too. Even if it won't directly benefit me now, that would still be a win :) > >> The way that it works is that the OEM will set bits in their BIOS for > >> that ACPI device indicating which "AMD_PMF" features they support. > >> That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > >> notifications. > > > > I have no idea what those things are, but I can research it ... > > > > But I think everyone and the planet would benefit from a (more) energy > > efficient system, regardless if it (normally) runs on batteries or not. > > In my case, this system will likely be my NAS, so idle 99(.9)% of the time > > and (in the future) on 24/7, so I'm extra motivated to make it consume as > > little energy as possible. > > > > Keep in mind PPD does multiple things based on what the hardware > advertises support for. > > For your system, you are using amd-pstate in active mode. I can see > this from your powerprofilesctl output. This will make sure the SoC is > properly biased towards efficiency or performance based on your preference. > > It will operate under the limitations of the coefficients programmed by > the firmware at max load (so you can't change PPT), but when idle it > shouldn't consume more power than needed. > > There is a kernel patch series coming in kernel 6.11 for "Core > performance boost" which will let you turn on/off boost above nominal > frequency. You can turn it off, and then CPU cores won't ever go above > nominal frequency. > > I'm proposing that we would leave boost on for PPD balanced and > performance states. For PPD power-saver we would turn it off. > > This is merged in the PPD tree and unless anyone complains will be part > of the next PPD release. > > The other thing that could be really interesting to do for power savings > purposes is to put certain tasks only the non-preferred cores or tune > EPP towards efficiency on cores running long running tasks that don't > need to finish quickly. > > In my opinion this is going to open up a lot of potential for sched-ext. > and for systemd. Userspace can read the core rankings and when starting > up and moving tasks around adjust EPP, boost and which cores tasks run > on. It's a lot of complicated work ahead though with a lot of profiling > needed. I hadn't used PPD before, so I'll experiment with it. Looks like I have lots of research to do ;-) Thanks for your detailed response :-) Hack (and Save) the Planet! Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 17:49:40 CEST Mario Limonciello wrote: > On 6/28/2024 10:41, Diederik de Haas wrote: > > On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > >> AMD has introduced a feature called Power Management Framework. > > > > With the upload of 6.9.7 this module now is available in the kernel. > > > AFAIK one of my systems should benefit from this too: > > MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 > > CPU(/APU?): AMD Ryzen 5 5500GT > > amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) > > firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) > > power-profiles-daemon: 0.21-2 > > > > So I think I'm all set... > > I don't think so. I've never heard of this actually used in a desktop > board. It's for mobile designs AFAIK. I can understand that the initial/original goal/target was mobile. But is there a(ny) technical reason why it couldn't also support 'desktop' systems? IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> The power-profiles-daemon software gained recently support for amd-pstate > >> driver, and also gained support to handle simultaneously cpu driver > >> (amd-pstate) and platform driver (amd-pmf). > > > > The version in that PPA is 0.21-1, so the Debian Testing/Unstable version > > should be fine now? > > Yes. Excellent > >> And when I list the existing power-profiles I get the following: > >> > >> user@machine:> sudo powerprofilesctl > >> > >>performance: > >> CpuDriver:amd_pstate > >> Degraded: no > >> > >> * balanced: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >>power-saver: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >> This (PlatformDriver: placeholder) indicates that the AMD_PMF module is > >> not included in the kernel. > > > > So I booted into the 6.9.7 kernel and ran that command ... only to be > > greeted with the exact same output ... > > > > So I verified whether AMD_PMF was indeed included ... and it was. > > Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I > > did > > NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... > > > > So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it > > was: > > ... > > Ran ``powerprofilesctl`` again ... and saw no change (thus still > > 'placeholder')> > >> There may be technical limitations that I am not aware of. > > > > I would have expected that amd_pmf and related modules would be loaded > > automatically. And ofc that it would actually work. > > > > The only real thing that I can think off that could interfere (from my > > side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. > > > > What other causes could there be that makes it not work properly? > > If there is no matching PMF ACPI device the driver won't automatically load. Ok. I might be able to convince Asus to add it, but I can also configure my system to 'modprobe' it on boot up. > The way that it works is that the OEM will set bits in their BIOS for > that ACPI device indicating which "AMD_PMF" features they support. > That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > notifications. I have no idea what those things are, but I can research it ... > I think someone with a laptop that supports PMF would be best to confirm > this. Framework 13 AMD and Framework 16 both support it. It would be great if someone with such a system can confirm whether it now can/ does work for the original target. But I think everyone and the planet would benefit from a (more) energy efficient system, regardless if it (normally) runs on batteries or not. In my case, this system will likely be my NAS, so idle 99(.9)% of the time and (in the future) on 24/7, so I'm extra motivated to make it consume as little energy as possible. Cheers and thanks for your fast response, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > AMD has introduced a feature called Power Management Framework. > See here for more info: https://www.phoronix.com/news/AMD-PMF-Linux-Driver > > It seems that this module is not included in the Debian Linux Kernel. With the upload of 6.9.7 this module now is available in the kernel. AFAIK one of my systems should benefit from this too: MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 CPU(/APU?): AMD Ryzen 5 5500GT amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) power-profiles-daemon: 0.21-2 So I think I'm all set... > A bit of context: > The power-profiles-daemon software gained recently support for amd-pstate > driver, and also gained support to handle simultaneously cpu driver > (amd-pstate) and platform driver (amd-pmf). > (https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_request > s/127). It seems that the power-profiles-daemon in unstable do not include > the commit that allows to handle both drivers at the same time. > So I've installed the power-profile-daemons for jammy from this Ubuntu PPA > (https://launchpad.net/~superm1/+archive/ubuntu/ppd/+packages). The version in that PPA is 0.21-1, so the Debian Testing/Unstable version should be fine now? > And when I list the existing power-profiles I get the following: > > user@machine:> sudo powerprofilesctl > performance: > CpuDriver:amd_pstate > Degraded: no > > * balanced: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > power-saver: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > This (PlatformDriver: placeholder) indicates that the AMD_PMF module is not > included in the kernel. So I booted into the 6.9.7 kernel and ran that command ... only to be greeted with the exact same output ... So I verified whether AMD_PMF was indeed included ... and it was. Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I did NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it was: ```sh # lsmod | grep amd amd_pmf61440 0 amdtee 28672 0 amd_sfh49152 1 amd_pmf tee45056 2 amd_pmf,amdtee amdgpu 12845056 0 amd_atl40960 1 edac_mce_amd 28672 0 kvm_amd 184320 0 kvm 1343488 1 kvm_amd amdxcp 12288 1 amdgpu drm_exec 12288 1 amdgpu gpu_sched 65536 1 amdgpu drm_buddy 20480 1 amdgpu drm_suballoc_helper12288 1 amdgpu drm_display_helper262144 1 amdgpu drm_ttm_helper 12288 1 amdgpu ttm 102400 2 amdgpu,drm_ttm_helper drm_kms_helper249856 2 drm_display_helper,amdgpu platform_profile 12288 2 amd_pmf,asus_wmi i2c_algo_bit 12288 1 amdgpu ccp 155648 2 kvm_amd,amdtee video 73728 2 asus_wmi,amdgpu button 24576 1 amd_pmf drm 737280 11 gpu_sched,drm_kms_helper,drm_exec,drm_suballoc_helper,drm_display_helper,drm_buddy,amdgpu,drm_ttm_helper,ttm,amdxcp hid 172032 3 usbhid,hid_generic,amd_sfh gpio_amdpt 16384 0 gpio_generic 20480 1 gpio_amdpt ``` Ran ``powerprofilesctl`` again ... and saw no change (thus still 'placeholder') > There may be technical limitations that I am not aware of. I would have expected that amd_pmf and related modules would be loaded automatically. And ofc that it would actually work. The only real thing that I can think off that could interfere (from my side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. What other causes could there be that makes it not work properly? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Control: tag -1 -patch
On Friday, 28 June 2024 09:55:24 CEST Michel Dänzer wrote:
> > This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
> > ("dri: Fix BGR format exclusion"), which I attached for your convenience.
>
> Beware that this commit caused a regression on little endian platfors:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/11398
Thanks for that. Let's remove the patch tag then.
The discussion has been reopened in the forwarded MR:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837#note_2470033
signature.asc
Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Control: tag -1 patch On Wednesday, 26 June 2024 03:04:15 CEST Leith Bade wrote: > Diederik provided me with a new v6.10 kernel build to try: > [0.00] Linux version 6.10-rc5+unreleased-arm64 ( > debian-ker...@lists.debian.org) (aarch64-linux-gnu-gcc-13 (Debian > 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP Debian > 6.10~rc5-1~cknow (2024-04-24) > > I can confirm the NAND flash chip is now recognised, and shows up in > /dev/mtd*: > [ 11.027448] spi-nand spi0.0: Winbond SPI NAND was found. > [ 11.027469] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: > 2048, OOB size: 64 > > I also finished testing the other UART ports on the CON1 header and can > confirm both work. I am working on getting more bits and pieces so I can > test the I2C, SPI, and audio codec pins. I submitted a MR to fix this bug with my changes here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 signature.asc Description: This is a digitally signed message part.
Bug#1072971: mesa: fails to initialize OpenGL on s390x: Unexpected format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Control: tag -1 upstream, fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/11360
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29837
On 14 Jun 2024 13:36:54 +0200 Emilio Pozuelo Monfort wrote:
> Control: reassign -1 mesa 24.1.1-2
> Control: affects -1 kuserfeedback
> Control: retitle -1 mesa: fails to initialize OpenGL on s390x: Unexpected
> format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
>
> Actually this looks like a regression in mesa in 24.1. A few rdeps are
> failing their autopkgtests with the same PIPE_FORMAT_X8B8G8R8_SRGB error,
> e.g.:
>
> https://ci.debian.net/packages/k/kodi/testing/s390x/47675600/
> https://ci.debian.net/packages/o/openscad/testing/s390x/47689316/
This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
("dri: Fix BGR format exclusion"), which I attached for your convenience.
I haven't tried it as I don't have access to a s390x machine, so if
someone can verify it, that would be most welcome.
Cheers,
Diederik>From 5ca85d75c05de9df7c3170122dfdb04bc795b43a Mon Sep 17 00:00:00 2001
From: Daniel Stone
Date: Fri, 21 Jun 2024 11:24:31 +0100
Subject: [PATCH] dri: Fix BGR format exclusion
Origin: upstream, https://gitlab.freedesktop.org/mesa/mesa/-/commit/5ca85d75c05de9df7c3170122dfdb04bc795b43a
Bug-Debian: https://bugs.debian.org/1072971
The check we had for BGR vs. RGB formats was testing completely the
wrong thing. Fix it so we can restore the previous set of configs we
expose to the frontend, which also fixes surfaceless platform on s390x.
Signed-off-by: Daniel Stone
Fixes: ad0edea53a73 ("st/dri: Check format properties from format helpers")
Closes: mesa/mesa#11360
Part-of:
---
src/gallium/frontends/dri/dri_screen.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/frontends/dri/dri_screen.c b/src/gallium/frontends/dri/dri_screen.c
index 97d11f324ee0b..2e9ce01147a89 100644
--- a/src/gallium/frontends/dri/dri_screen.c
+++ b/src/gallium/frontends/dri/dri_screen.c
@@ -386,17 +386,21 @@ dri_fill_in_modes(struct dri_screen *screen)
uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
/* Expose only BGRA ordering if the loader doesn't support RGBA ordering. */
- if (!allow_rgba_ordering &&
- util_format_get_component_shift(pipe_formats[f],
- UTIL_FORMAT_COLORSPACE_RGB, 0)
+ if (!allow_rgba_ordering) {
+ unsigned sh_ax = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+ unsigned sh_b = util_format_get_component_shift(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
#if UTIL_ARCH_BIG_ENDIAN
- >
+ unsigned sz_b = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 2);
+
+ if (sz_b + sh_b == sh_ax)
+ continue;
#else
- <
+ unsigned sz_ax = util_format_get_component_bits(pipe_formats[f], UTIL_FORMAT_COLORSPACE_RGB, 3);
+
+ if (sz_ax + sh_ax == sh_b)
+ continue;
#endif
- util_format_get_component_shift(pipe_formats[f],
- UTIL_FORMAT_COLORSPACE_RGB, 2))
- continue;
+ }
if (!allow_rgb10 &&
util_format_get_component_bits(pipe_formats[f],
--
GitLab
signature.asc
Description: This is a digitally signed message part.
Bug#1035655: /usr/bin/startplasmamobile: 22: [[: not found
On Wed, 11 Oct 2023 01:53:04 -0400 Yifei Zhan wrote: > It seems like this issue has been addressed by upstream and the next release > will be depending on bash: > > startplasmamobile: Specify bash in the shebang > https://invent.kde.org/plasma/plasma-mobile/-/commit/cdeba03d5ea807d8cfc30661f7437c5db8770ebe And rightfully reverted later and later still, properly fixed: https://invent.kde.org/plasma/plasma-mobile/-/commit/7b310c8076eaccd9bce5366cd80933be7e948e11 signature.asc Description: This is a digitally signed message part.
Bug#1072435: minidlna: FTBFS with ffmpeg 7.0 : libav.h:177:36: error: ‘AVCodecParameters ’ has no member named ‘channels’
Control: forwarded -1 https://sourceforge.net/p/minidlna/bugs/363/
https://sourceforge.net/p/minidlna/git/merge-requests/58/
Control: tag -1 patch
On Wednesday, 5 June 2024 14:43:17 CEST Diederik de Haas wrote:
> Control: tag -1 upstream
> Control: forwarded -1 https://sourceforge.net/p/minidlna/bugs/363/
>
> On 2 Jun 2024 15:22:21 +0200 Sebastian Ramacher wrote:
> > during a rebuild of the reverse dependencies for the transition to
> > ffmpeg 7.0, your package failed to build
>
> There's an upstream bug for it, but not yet a solution.
> Updating metadata accordingly.
And there's also an upstream merge request for it.
Attaching a patch to add that patch to the Debian package.
Or you can use https://salsa.debian.org/debian/minidlna/-/merge_requests/7
which is a MR with the attach patch applied.
Cheers,
Diederik>From 1a77e07ca0f2dce15b756ac45d192ea12e8ecace Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Wed, 26 Jun 2024 13:12:09 +0200
Subject: [PATCH] d/patches: Add 16-Add-compatibility-with-FFMPEG-7.0.patch
Closes: #1072435
Link: https://bugs.debian.org/1072435
---
...16-Add-compatibility-with-FFMPEG-7.0.patch | 40 +++
debian/patches/series | 1 +
2 files changed, 41 insertions(+)
create mode 100644 debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
diff --git a/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch b/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
new file mode 100644
index 000..f56de1c
--- /dev/null
+++ b/debian/patches/16-Add-compatibility-with-FFMPEG-7.0.patch
@@ -0,0 +1,40 @@
+From 243cf2dd27ebcaf4ef1093c79b96077378d52018 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Robert-Andr=C3=A9=20Mauchin?=
+Date: Sat, 4 May 2024 18:36:58 +0200
+Subject: [PATCH] Add compatibility with FFMPEG 7.0
+Origin: other, https://sourceforge.net/u/eclipseo/minidlna/ci/243cf2dd27ebcaf4ef1093c79b96077378d52018/
+Bug-Debian: https://bugs.debian.org/1072435
+
+channel_layout has been replaced with ch_layout
+---
+ libav.h | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libav.h b/libav.h
+index b69752c..fae094b 100644
+--- a/libav.h
b/libav.h
+@@ -117,6 +117,8 @@ typedef AVMetadataTag AVDictionaryEntry;
+ # endif
+ #endif
+
++#define HAVE_CH_LAYOUT (LIBAVUTIL_VERSION_INT >= ((57<<16)+(28<<8)+100))
++
+ static inline int
+ lav_open(AVFormatContext **ctx, const char *filename)
+ {
+@@ -174,7 +176,11 @@ lav_get_interlaced(AVStream *s)
+ #define lav_codec_tag(s) s->codecpar->codec_tag
+ #define lav_sample_rate(s) s->codecpar->sample_rate
+ #define lav_bit_rate(s) s->codecpar->bit_rate
++#if HAVE_CH_LAYOUT
++#define lav_channels(s) s->codecpar->ch_layout.nb_channels
++#else
+ #define lav_channels(s) s->codecpar->channels
++#endif
+ #define lav_width(s) s->codecpar->width
+ #define lav_height(s) s->codecpar->height
+ #define lav_profile(s) s->codecpar->profile
+--
+2.45.2
+
diff --git a/debian/patches/series b/debian/patches/series
index 05164a6..83ea738 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@
13-spelling-and-typos.patch
14-autoupdate.patch
15-thumbnails.patch
+16-Add-compatibility-with-FFMPEG-7.0.patch
--
2.45.2
signature.asc
Description: This is a digitally signed message part.
Bug#1072459: wxsvg: FTBFS with ffmpeg 7.0: me diadec_ffmpeg.cpp:168:75: error: ‘AVCodecPa rameters’ {aka ‘struct AVCodecParameters ’} has no member named ‘channels’
Control: tag -1 +upstream +fixed-upstream On 2 Jun 2024 15:27:58 +0200 Sebastian Ramacher wrote: > Source: wxsvg > Version: 2:1.5.24+dfsg-2.1 > Severity: important > Tags: trixie sid ftbfs > Usertags: ffmpeg-7.0 > > during a rebuild of the reverse dependencies for the transition to > ffmpeg 7.0, your package failed to build There's a new upstream version 1.5.25 which contains a compatibility with ffmpeg 7.0 fix, so releasing a new upstream version would fix this bug. https://sourceforge.net/p/wxsvg/git/ci/7e7f7cd017591da772399125669c402dce9bbea2/ signature.asc Description: This is a digitally signed message part.
Bug#1063161:
Control: reopen -1
Control: found -1 6.8.9-1
Control: found -1 6.9.2-1~exp1
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote:
> Le 2024-05-23 17:12, Nathan MALO a écrit :
> > Thank you very much for enabling those two features in the kernel.
> > Your work is much appreciated !
> >
> > Maybe I am missing something but I've download the 6.8.9-1 package from
> > and while fiddling with it, I was not able to find the keys
> > CONFIG_AMDTEE and CONFIG_AMD_PMF in the /boot/config file.
> >
> > Am I missing something ?
> > Maybe the package was not rebuilt with this new configuration ?
>
> We are just lacking a configuration symbol. Diederik, starting with
> linux 6.8 AMD PMF requires TEE. Do you want me to send a MR?
As Vincent remarked, that means the bug is not fixed, so reopening it.
@Vincent: Can you add a Closes: #1063161 to ``debian/changelog``?
And while you're at it, add the following line to the commit message?
Fixes: 7399dff4b4af ("[amd64] drivers/platform/x86/amd/pmf: Enable AMD_PMF as
module")
> Thanks for the report,
Indeed. Sorry for missing that.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1074253: hut: Upstream moved to https://sr.ht/~xenrox/hut/
Package: hut Version: 0.5.0-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The 'homepage' now has the following warning: Warning: this project has migrated to https://git.sr.ht/~xenrox/hut But without the ``.git`` part fits better as (new) homepage. - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-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 hut depends on: ii libc6 2.38-13 hut recommends no packages. hut suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZnqVKwAKCRDXblvOeH7b bgpeAQD9VSpiw9M0e7i0HMQv8YZsEAi6Qp5vejfSpcTslfJkqgD/To0G6QxGF2V4 IrEeNEe4KM/YSWh7kxaZVLIKs6w24Qo= =ks5Z -END PGP SIGNATURE-
Bug#1067858: reset SuperSpeed USB device number 2 using xhci_hcd
On Saturday, 22 June 2024 13:02:24 CEST Pierre Tomon wrote: > Control: tags -1 + fixed-upstream > > This bug is now fixed upstream. > > Commit: 7926d51f73e0 - scsi: sd: Use READ(16) when reading block zero on > large capacity disks Releases: v6.1.95, v6.6.35 and v6.9.6 That's awesome. Great work! signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:10:18 CEST Leith Bade wrote: > On 24 Jun 2024 at 20:32, Diederik de Haas wrote: > > > This likely due to my unfamiliarity with building the Debian kernel. > > I will eventually manage to figure it out. Part of the problem is that > there is a lot of different advice around the place and a lot of it is out > of date. https://kernel-team.pages.debian.net/kernel-handbook/ or the offline version in the debian-kernel-handbook package *should* give you the proper advice. If not, then that's a bug. > > > The device tree is a modified version of the > > > upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb" > > > > Can you share those changes? I analyzed and enabled modules purely on > > what's available upstream. > > Yes, I just need to tidy them up into a series of git commits. I don't > think I had to change anything module related, Ok, I use the "compatible" string to figure out what modules are needed. > the main issue was the GPIO pin conflicts. I plan to coordinate with the > original author of the file (who is on the Banana Pi forum) to work towards > getting them submitted to Linux. Awesome > Thanks for the advice. The patches I have seen are fairly minor - mainly > adding another special case to match the SFP name string. > > I think the upstream concern stems from the way these vendors of these > cheap SFP modules are just programming so many different model strings to > rebadge them as they see fit. There is even a documented case where two > devices from two different vendors have the exact same ID strings, but two > different incompatible PHY chips inside. sigh. I can understand upstream's concern. > > I'm still missing a "Tested-by:" tag for my changes ;-P > > Tested-by: Leith Bade Haha, thanks :) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:43:38 CEST Leith Bade wrote:
> On Mon, 24 Jun 2024 at 22:10, Leith Bade wrote:
> > > After inspecting the /lib/firmware directory, it seems the APT package
> > >
> >> > "firmware-misc-nonfree" has firmware for older MediaTek chips, but is
> >> > missing files for ant MT79xx including MT7981 and MT7986.
> >>
> >> d1c24e6cfa18 ("mediatek: Synchronize with 20230625's WHENCE file")
> >> added those files and has been released to *experimental* in version
> >> 20230625-3~exp2. You'd need the firmware-mediatek package though.
> >
> > Thanks for finding this. The various firmware packages and their differing
> > names is highly confusing. I wonder if there is some sort of script that
> > can go find the right packages for your initrd.
``apt-file search ``
is the usual way to find which file is in what package
> So I removed linux-firmware-upstream, then installed firmware-mediatek
> from experimental, then did an update-initramfs. After rebooting the WiFi
> is still working.
Cool :)
> What other testing is required before this can make its way into unstable?
I don't know; that's up to the kernel team.
(The above mentioned commit is from me as well as the commit that split out
the mediatek firmware into its own package, but I'm not part of the team)
signature.asc
Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 07:10:48 CEST Leith Bade wrote:
> I finished my first round of testing the new kerned on my BPI-R3 board.
This is more extensive testing then I normally see. Nice :-)
> This likely due to my unfamiliarity with building the Debian kernel.
Given your interest (similar to mine ~2 y/o) and skill set (higher then mine),
it's probably worth learning that ;-)
> So instead after constructing a working testing/sid root filesystem on an
> SD card via debootstrap I have installed and tested a v6.10 kernel build
> that Diederik supplies me with. The kernel version string for this is:
> Linux version 6.10-rc3+unreleased-arm64 (debian-ker...@lists.debian.org)
> (aarch64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils
> for Debian) 2.42) #1 SMP Debian 6.10~rc3-1~cknow (2024-04-24)
I plan to build a 6.10~rc5 soon ...
> The device tree is a modified version of the
> upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb"
Can you share those changes? I analyzed and enabled modules purely on what's
available upstream.
> The device tree requires applying various overlay files
> ("mt7986a-bananapi-bpi-r3-nor.dtbo", "mt7986a-bananapi-bpi-r3-nand.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-sd.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-emmc.dtbo") to select the correct
> configuration for the attached storage chips. These chips are
> enabled/disabled by the boot selection DIP switch labelled "SW1" on the
> board. You can choose between the NOR or NAND chip, as well as the SD card
> slot or eMMC chip. So the combinations are: NOR + SD, NOR + eMMC, NAND +
> SD, NAND + eMMC. Since I was booting from an SD card I have not yet tested
> the eMMC chip.
I forgot to analyze the dtbo files and consequently added the needed kernel
modules for it. Will include that in my 6.10~rc5 build.
> The kernel boots successfully and I make it all the way to the login screen
> via serial as well as the SSH server working.
\o/
> All tested devices work except for:
>
> SoC Hardware Accelerated Cryptography
> Device Tree name: "crypto: crypto@1032"
> DT compatible: "inside-secure,safexcel-eip97"
> Issue:
>
> In the kernel dmesg boot log there are a variety of errors like:
> > [8.910388] alg: ahash: safexcel-sha384 test failed (wrong result) on
> > test vector 1, cfg="init+update+final aligned buffer"
> > [8.921577] alg: self-tests for sha384 using safexcel-sha384 failed
> > (rc=-22)
>
> These errors are repeated for: "safexcel-sha384" "safexcel-sha512"
> "safexcel-hmac-sha384" "safexcel-hmac-sha512"
> ...
> I did not see this error in the Ubuntu v6.8 kernel, so I will be interested
> to test the Debian v6.8 kernel once I get it building to see if this is a
> regression in the v6.10 kernel.
There have been *no* upstream commits to ``drivers/crypto/inside-secure/``
since 6.8, so that would surprise me. Possible causes:
- Ubuntu has a patch for this
- Ubuntu's kernel config enables options which the Debian kernel doesn't
The latter is more likely, which can mean that upstream's kernel module is
missing some depends/selects? This is speculation though.
> SoC SNFI Serial Flash Bus
> ...
> The fix here is to build the "spi-mtk-snfi" module from the MTD drivers.
Ack. CONFIG_SPI_MTK_SNFI (tristate)
> SPIM NAND Chip
> ...
> The fix here is to build the "spi-nand" module from the MTD drivers.
Ack. CONFIG_MTD_SPI_NAND (tristate)
> SFP RJ45 2.5 GbE Modules
> ...
> kernel finds them in the boot log:
> > [2.744506] sfp sfp-1: Host maximum power 3.0W
> > [2.768976] sfp sfp-2: Host maximum power 3.0W
> > [3.105275] sfp sfp-2: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070133 dc 240507
> > [3.135654] sfp sfp-1: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070134 dc 240507
>
> But the resulting eth0/eth1 devices do not work. Searching on the Banana Pi
> forum, and then the kernel net mailing list it appears that patches to
> support these devices have not yet been accepted upstream.
Note that for inclusion in the Debian kernel the device should be *usable*.
It does not require that everything works perfectly.
If you learn to build a Debian kernel, there's ``debian/patches`` where you
could put those patches in so they get included in your build. You could then
share your test finding with the upstream discussion of those patches and
ideally add a "Tested-by: you " which helps to get things
merged upstream (which then will find its way into a future Debian kernel)
> 2.4 GHz & 5 GHz WiFi
> Device Tree name: "wifi: wifi@1800"
> DT compatible: "mediatek,mt7986-wmac"
> Issue:
> Initially the kernel boot log was saying the required firmware files could
> not be found:
> ...
> > [ 33.775740] mt798x-wmac 1800.wifi: probe with driver mt798x-wmac
> > failed with error -110
>
> I then installed the "linux-firmware" package from testing/sid APT
... so close ...
> repository, but the error message persisted. Addi
Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file
Control: found -1 6.6.15-1 On Friday, 21 June 2024 13:41:38 CEST Christoph Berg wrote: > I just had the same problem on linux-image-6.6.15-amd64. Updating found version accordingly. > > It seems to me that at least with purging that file should be removed > > and subsequently the ``/lib/modules/`` dir. > > TBH, I'd even argue plain "remove" should remove the debris from the > modules directory, it's not like there's anything of value in the > modules.* files left behind. I didn't have that many kernels installed, so I only verified it with 1 and for that I used 'purge'. But I'm inclined to agree that remove should remove that file too. signature.asc Description: This is a digitally signed message part.
Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file
Source: linux Version: 6.9.2-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 When removing or 'even' purging a linux-image- package, it reports the following issue: rmdir: failed to remove '/lib/modules/': Directory not empty The reason for that is that there's still a ``modules.weakdep`` file. It seems to me that at least with purging that file should be removed and subsequently the ``/lib/modules/`` dir. FWIW: I do not have any DKMS package which could also result in the inability to remove the modules dir. - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9-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/XblvOeH7bbgUCZnVlCwAKCRDXblvOeH7b bvdqAPwOCZQoQ5xXUbW+FkytY5Ovj5xoPizPFOWdFTvtaXro0QD/RhTTHvmL4cZ4 GfAOEDPN4Rv+vnze+lNZt+xCrTSa4AY= =QCxl -END PGP SIGNATURE-
Bug#973364: firmware-linux-free: Maybe missing soft dependency on wireless-regdb
On Thu, 29 Oct 2020 14:22:16 +0100 Axel Beckert wrote: > Package: firmware-linux-free > Version: 20200122-1 > > now that "iw" dropped the dependency on "crda" (see > https://bugs.debian.org/972994), "wireless-regdb" gets uninstalled, too, > as it was only pulled in via dependency by crda, at least on some of my > machines. FWIW: iw 5.9-3 added wireless-regdb as Recommends signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Sunday, 16 June 2024 15:20:05 CEST Leith Bade wrote: > I need to work out how to submit these fixes to the Linux device tree > maintainers. My experience is primarily/only with Rockchip based devices/SoCs and their upstream development process, but it may help wrt MediaTek's. - If you think something is wrong, determine with ``git blame`` which commit added that (presumably) incorrect statement(s) - In the commit message, you'll often find a ``Link: `` line which points to the discussion of that change and should point to https://lore.kernel.org/ - If there isn't a ``Link: `` line, you can put the title of the commit in the 'lore' search box and search through all the archives; reasonable chance that'll point you to the discussion thread(s) - Read through the whole discussion as it may already provide answers to questions you may have - At the bottom of each 'lore' page, you'll find instructions on how to reply in case you have further questions/disagree/etc https://lists.infradead.org/mailman/listinfo/linux-mediatek is where patch discussion takes place (which gets 'archived' on lore.k.o). You may want to subscribe to that list to get an idea how the upstreaming process takes place. Keep in mind that the volume of that/those list(s) can be huge and that your email address will be publicly/wildly known (just like on Debian bug reports). https://git-send-email.io/ is probably worth a look and also the ``b4`` tool. HTH, Diederik signature.asc Description: This is a digitally signed message part.
