Bug#1076564: pahole BTF processing seems flaky on powerpc
On Wed, Jul 24, 2024 at 11:04:51AM +0100, Alan Maguire wrote:
> On 19/07/2024 20:13, Arnaldo Carvalho de Melo wrote:
> > Adding Alan and Jiri to the CC list.
> >
>
> I'm late chiming in on this one, but judging by the output:
>
> BTF .btf.vmlinux.bin.o
> + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j
> --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func
> --lang_exclude=rust .tmp_vmlinux.btf
> [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error
> emitting BTF type
> Encountered error while encoding BTF.
>
>
> ...we hit an error in btf_encoder__add_array() as a result of
> btf__add_array() failing:
>
> btf__log_err(btf, BTF_KIND_ARRAY, NULL, true,
> "type_id=%u index_type_id=%u nr_elems=%u
> Error emitting BTF type",
> type, index_type, nelems);
>
>
> Unfortunately we don't preserve the negative id value (containing the
> error code) in btf__log_err(); I'm thinking one thing we should do is
> modify btf__log_err() to preserves errors for cases where the encoding
> errors out due to a libbpf-returned -errno, something like
>
>
> -__attribute ((format (printf, 5, 6)))
> +__attribute ((format (printf, 6, 7)))
> -static void btf__log_err(const struct btf *btf, int kind, const char *name,
> +static void btf__log_err(const struct btf *btf, int libbpf_err, int
> kind, const char *name,
> bool output_cr, const char *fmt, ...)
> {
> fprintf(stderr, "[%u] %s %s", btf__type_cnt(btf),
> btf_kind_str[kind], name ?: "(anon)");
>
> if (fmt && *fmt) {
> va_list ap;
>
> fprintf(stderr, " ");
> va_start(ap, fmt);
> vfprintf(stderr, fmt, ap);
> va_end(ap);
> }
>
> + if (libbpf_err)
> + fprintf(stderr, " libbpf error %d", libbpf_err);
> if (output_cr)
> fprintf(stderr, "\n");
> }
>
>
> So at least if this error recurs we'd have a clearer picture of what's
> happening in libbpf. What do you think? I'll submit a patch for this if
> it makes sense.
I agree completely that the error reporting we have is lacking, we
better go and add extra info for these cases so that we can more quickly
get a clue of what is taking place, so please submit patches for that
and I'll consider them.
Thanks,
- Arnaldo
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#1076564: pahole BTF processing seems flaky on powerpc
Adding Alan and Jiri to the CC list. On Fri, Jul 19, 2024 at 08:53:24AM +0200, Domenico Andreoli wrote: > Hi Arnaldo, > > On Thu, Jul 18, 2024 at 11:56:09PM +0200, Ben Hutchings wrote: > > Package: pahole > > Version: 1.27-1 > > Severity: normal > > X-Debbugs-Cc: debian-ker...@lists.debian.org > > > > Several kernel builds on powerpc have failed recently: > > > > 6.8.12-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.8.12-1=1717234422=1 > > 6.9.9-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.9.9-1=1720906547=1 > > 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.10-1%7Eexp1=1721287862=1 > > > > Note, these log files are up to 270 MB in size and should be > > downloaded; at least Firefox becomes unresponsive when trying to > > display them. > > > > For each of these, the failure seems to start with an error from > > pahole such as: > > > > [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error > > emitting BTF type > > Encountered error while encoding BTF. > > Does the above error ring any bell? Nope > Is there anything I can do to help? >From the 6.10-1~exp1: https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.10-1%7Eexp1=1721287862=1 file: + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func --lang_exclude=rust .tmp_vmlinux.btf Can I have access to that .tmp_vmlinux.btf file so that I can try to reproduce it here? - Arnaldo > > > > This does *not* happen consistently. Compare these successful > > builds: > > > > 6.8.12-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.8.12-1=1717278092=1 > > - This same version failed to build on the first try. > > 6.9.7-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.9.7-1=1719538806=1 > > - Earlier and later 6.9.x versions failed to build. > > > > Both pahole versions 1.26-1 and 1.27-1 have been used in both > > successful and failing builds. > > > > Ben. > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unstable-debug > > APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, > > 'stable-security'), (500, 'oldstable-updates'), (500, > > 'oldstable-security'), (500, 'oldoldstable-updates'), (500, > > 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), > > (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 6.9.9-amd64 (SMP w/12 CPU threads; PREEMPT) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages pahole depends on: > > ii libbpf1 1:1.4.3-1 > > ii libc6 2.39-4 > > ii libdw1t64 0.191-2 > > ii libelf1t64 0.191-2 > > ii zlib1g 1:1.3.dfsg+really1.3.1-1 > > > > pahole recommends no packages. > > > > pahole suggests no packages. > > > > -- debconf-show failed > > -- > rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 > ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
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 > 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#1076403: O: nss-updatedb -- Cache name service directories in DB format
Package: wnpp Severity: normal X-Debbugs-Cc: nss-updat...@packages.debian.org, ftob...@debian.org Control: affects -1 + src:nss-updatedb I intend to orphan the nss-updatedb package. The package description is: This package contains a script, nss_updatedb, which can be used to maintain local caches of user and group directories. These can then be used by the DB Name Service Switch module (libnss-db) to provide name service when the system is offline. . These tools are designed to work with libpam-ldap and libnss-ldap. I don't have the time and interest to keep working on this package anymore. The package is in good shape. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. -- ⢀⣴⠾⠻⢶⣦ ⣾⠁⢠⠒⠀⣿⡁ Fabio Augusto De Muzio Tobich ⢿⡄⠘⠷⠚⠋⠀ 9730 4066 E5AE FAC2 2683 D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074134: Re-introduce deborphan package (Alternative: Provide guidance for alternatives)
On Sun, 23 Jun 2024 17:46:40 +0200 satanic.surfer@web.de wrote: Unfortunately the package got removed completely from Debian testing leaving users without it behind (now for testing and later for the next stable). I agree, I knew deborphan had issues, but I haven't found an alternative. 2. Provide an alternative suggestion / migration to a tool having a similar / same functionality In bug #1065312 some people mentioned using something akin to: apt list '~i !~M' which is pretty much the same as: apt-mark showmanual However, `deborphan -a` doesn't show all manually installed packages, it shows the packages that aren't being depended on by other installed packages. It'd be nice to have an `apt list` or `dpkg-query` incantation that can do this. -- M
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.
Bug#1022311: python-stdnum: FTBFS: AssertionError: Failed doctest test for test_no_fodselsnummer.doctest
On Thu, 2024-05-23 at 13:36 +0200, Santiago Vila wrote: > Arthur: Would be ok for you if I fix this in bullseye via team > upload? Please do, thanks. I only have limited time available at the moment and have quite a big backlog of issues to pick up so any help is really welcome. Thanks, -- -- arthur - adej...@debian.org - https://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
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.
Bug#1073298: python3-stdlib-extensions: Version mismatch with python3 in Testing/Sid
Source: python3-stdlib-extensions Version: 3.12.3-3.1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I was running a Salsa CI job and noticed a failure with the arm64 cross-compile job due to the following error: ```sh Setting up python3.11-minimal:arm64 (3.11.9-1) ... /var/lib/dpkg/info/python3.11-minimal.postinst: 51: /usr/bin/python3.11: Exec format error dpkg: error processing package python3.11-minimal:arm64 (--configure): installed python3.11-minimal:arm64 package post-installation script subprocess returned error exit status 126 Errors were encountered while processing: python3.11-minimal:arm64 E: Sub-process /usr/bin/dpkg returned an error code (1) E: Failed to process build dependencies ``` As that job succeeded before, I looked a bit further and noticed this: ```sh Get:22 http://deb.debian.org/debian sid/main arm64 python3 arm64 3.11.8-1 [27.4 kB] ``` but also this: ```sh Get:451 http://deb.debian.org/debian sid/main amd64 python3-lib2to3 all 3.12.3-3.1 [77.7 kB] Get:452 http://deb.debian.org/debian sid/main amd64 python3-distutils all 3.12.3-3.1 [131 kB] ``` Based on that version number I *assume* it targets python3 version 3.12, while src:python3-defaults is at version 3.11.8-1 in Testing and Sid. Experimental has version 3.12.1 though. Shouldn't those versions be in sync with each other? Due to my assumption I didn't make it RC, but if my assumption is correct, then a RC severity seems appropriate. 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.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 -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZm7VQQAKCRDXblvOeH7b btDWAQDWPedCrXkK24zC0REJW7cDnxiGH4EmfbZwMXMkTabbvAD/ZLHjvFp4sJKP hXgp5xOobhP0hQD9h86Z7pY7gM9c1Qo= =/z5R -END PGP SIGNATURE-
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Thursday, 13 June 2024 23:00:51 CEST Leith Bade wrote: > Excellent, hopefully we can get the DTS stuff from OpenWrt upstreamed into > Linux for the OpenWrt and BPI-R3. I have (thus far) found one possible oddity, but otherwise it looks ok AFAICT for BPI-R3. When that's done, the OpenWrt One should be rather simple. But only *IF* they upstream it in time. > I am not sure what the process is for that. The first step would be to get involved with the community. I'm quite sure there's one or more threads about the BPI-R3 on the OpenWrt forums. > As for the MT7988 I can save up and get a BPI-R4 for testing in the future, > though I have a feeling that the Debian testing kernel might be too old, > the drivers were only added to Linux 5 months ago. So maybe I will wait > until there is a Debian version with a newer kernel. I did look (briefly) into MT7988 and the problem isn't on the Debian side, but on the upstream side. Looking at the mt7988a.dtsi and it seems there's *quite* a lot missing. And the BPI-R4 dts file includes that incomplete dtsi file and then specifies the model name and chassis-type. That's it. If you compare that with BPI-R3 then you'll see a huge difference. So it looks like there's quite some work to do before the BPI-R4 is supported upstream, which is a prerequisite for support in Debian. I haven't looked (at Mailing Lists), but I would be very surprised if we could get (proper) support in the Trixie kernel. If you're interested in this kind of thing, you have enough time to learn and contribute to get proper support for it in the Forky kernel. HTH, 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 Thursday, 13 June 2024 13:55:40 CEST Diederik de Haas wrote: > > Banana Pi released a public version of the MT7986 manual which has all the > > various register memory locations documented, though some stuff is > > missing. > > Only after writing the previous line, I realized you were talking about the > MT798*1*, not the MT7986. And that means the OpenWrt One thread will be > 'gold' as they intend to be as Open as possible, so check the Popular Links > in the opening post. > That should also lead you to https://mirror2.openwrt.org/docs/ What I forgot to mention: MediaTek (employees) seem to contribute actively to the upstream Linux kernel. And they agreed to publish those detailed docs related to the OpenWrt One. Which indicates to me they have a very friendly attitude towards Linux and FLOSS. So if you want a doc but can't find it (online), maybe just write them an email and ask for it? I don't know if they respond (positively), but certainly seems worth a try? 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 Wednesday, 12 June 2024 23:45:30 CEST Leith Bade wrote: > Also, has a public version of the MT7981 Reference Manual been published? I have no idea. I have not searched and actually don't know much/anything about MediaTek devices in general. All I'm using is what is described in the DTS file in the upstream Linux repo. > Google only finds me a pirated partial copy on Scribd. This will be needed > to get all the memory locations for the DTS file, otherwise we will need to > steal them from the DTS files in the Mediatek SDK or OpenWRT. It's probably a good idea to find out if there are differences in what OpenWrt has/uses and what's available in the upstream Linux repo. If there are, it would be great if those changes/improvements can be upstreamed (to the Linux kernel). Probably best to ask (and search) in the OpenWrt forums. There's a LOT of info there and quite a number of (very) knowledgeable people. They may also know about or have MT7981 TRM(s). > Banana Pi released a public version of the MT7986 manual which has all the > various register memory locations documented, though some stuff is missing. Only after writing the previous line, I realized you were talking about the MT798*1*, not the MT7986. And that means the OpenWrt One thread will be 'gold' as they intend to be as Open as possible, so check the Popular Links in the opening post. That should also lead you to https://mirror2.openwrt.org/docs/ Have fun ;-) 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 23:40:41 CEST Leith Bade wrote: > Ideally if in your new kernel build you enable support for MT7981, MT7986, > MT7988 at the same time that would be nice. I'll only add support for the MT7986 in my kernel build as that one can be tested (by you) to actually work as intended. Adding support for the other SoCs should then become much simpler as all the 'ground work' has already been done. But to add that to the Debian kernel, we'd need one with a device with that SoC so that it too can be tested to actually 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 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" I'm not sure but it could be Filogic 830 vs Filogic 820 platform? I wouldn't be surprised if there are some shared things, but those are different SoCs. 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 Tuesday, 11 June 2024 12:26:17 CEST Leith Bade wrote: > For the record the issues I noticed are (comparing with U-boot and OpenWRTs > versions of the device tree files): > - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load > https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa > 670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other > boards might use this Generally, `*.dtsi` files get included into other files, usually `.dts` files. The `mt7986a.dtsi` (likely) describes the SoC, not the full device. The device likely has the flash chip, not the SoC, so the dts file should have an entry for the flash chip (the dts file for OpenWrt One does f.e.). > - in OpenWRT device tree there are a lot more entries in the efuse map > related to the USB and PCIe ports - it seems the USB and PCIe device entries > then use these efuse values DeviceTree files describe the hardware, so *ideally* there should be no difference between what the Linux kernel has (which is generally considered the upstream project for DT files) and what OpenWrt has/uses. Unfortunately, we don't live in an ideal world ;-) If OpenWrt's DT are better (I don't know), then it would be great if they would upstream their improvements to the Linux kernel. But AFAIK, OpenWrt has/manages their own kernel and DT files. I know u-boot now has an OF_UPSTREAM (OF=OpenFirmware=DT) 'setting', which I *think* means they're (in the process of) switching to using the Linux kernel's DeviceTree files. > - no hnat device - though maybe this is only usable with the proprietary > Mediatek driver code I have no idea what that is (for). > - in OpenWRT device tree there is a different "compatible" string for spi0 > (quad) and spi1 (single) - I am not sure if that matters with the upstream > driver, hopefully there is a way to check that the MTD device is using the > quad SPI / SPIM mode The "compatible" string is used to find the appropriate driver (IIUC), so if spi0 and spi1 have different "compatible"s, then they (apparently) need different drivers from them. But as said before, (technically) OpenWrt is their own project, so it doesn't have to match what current upstream does/has. (OpenWrt doesn't track Linus' 'master' branch but the most recent LTS version, which they then patch) > - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have > partition definitions that don't match the device tree in U-boot and > OpenWRT - ideally these should match the partitions on a factory fresh > board which comes OpenWRT preloaded It (generally) doesn't sound good if different projects use/assume different partition layouts. It could be one (or more) projects have incorrect and/or incomplete implementation. I don't know. It could be worth investigating what the correct values are and submitting patches to those projects to get that fixed. > I noticed a few problems but I am not sure what normal protocol is - should > I report it as a bug to Linux directly? The best way to deal with it depends on the project (and could also depend on the subsystem of that project). AFAIK they all use Mailing Lists, but AFAIK OpenWrt also use Pull Requests on GH, which the (majority of the) Linux kernel does not. So you'll need to investigate how the project(s) you want to contribute too (generally) operates. And learn/verify whether what you found is actually a bug and in which project(s) the problem is, and not f.e. that you were looking in the wrong place (dtsi vs dts). HTH and have fun! Diederik PS: this bug report is probably not the right place for these kind of discussions signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Hi, On Tuesday, 11 June 2024 08:02:41 CEST Leith Bade wrote: > I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC for > its CPU. This is a router focussed board and currently has good support in > the OpenWRT distribution and in the upstream Linux for a few years. The > device tree for this board is > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/m > t7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable specific > flash chip options). I already have a local branch to add preliminary support for the OpenWrt One router [1] [2] which uses the same SoC :-) [1] https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684 [2] https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684/331 > There is a relevant discussion in https://salsa.debian.org/kernel- > team/linux/-/merge_requests/906#note_483427 which was the code change that > added the MT8xxx support about the various MT6xxx and MT7xxx modules being > disabled. This is a shame as it seems that without explicitly disabling them > then this code change would have added the modules I need. > > I am happy to do any testing required to get this board supported. And that was precisely about adding support for the OpenWrt One ;-) Happy to update my local branch and add support for the BPi R-3. I'm waiting for some (unrelated) other changes, but when that's posted I intend to build a 6.10-rcX based kernel with it and I can 'merge' my router branch into that. With that you could verify if it indeed works. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072239: bookworm-pu: package intel-microcode/3.20240514.1~deb12u1
I have uploaded it source-only a few days ago, but missed emailing this bug report about it :-( Thank you, and sorry for the delay! On Wed, Jun 5, 2024, at 18:19, Jonathan Wiltshire wrote: > Please go ahead. -- Henrique de Moraes Holschuh
Bug#1072238: bullseye-pu: package intel-microcode/3.20240514.1~deb11u1
I have uploaded it source-only a few days ago, but missed emailing this bug report about it :-( Thank you, and sorry for the delay! On Wed, Jun 5, 2024, at 18:18, Jonathan Wiltshire wrote: > Please go ahead. -- Henrique de Moraes Holschuh
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
Hi Andreas, Those locations work. But the correct environment variable turns out to be SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong. (I've no idea why suspend seemed to work for me yesterday with the wrong variable. Today it definitely didn't.) The overrides probably also need to be installed for the other service files that run systemd-sleep: systemd-hybrid-sleep.service, systemd-hibernate.service and systemd-suspend-then-hibernate.service. On Fri, Jun 7, 2024 at 10:05 PM Luca Boccassi wrote: > On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann wrote: > > > > On 07/06/2024 08.17, Peter De Wachter wrote: > > > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file > mentions: > > > > > > * The behavior of systemd-sleep and systemd-homed has been > updated to > > >freeze user sessions when entering the various sleep modes > or when > > >locking a homed-managed home area. This is known to cause > issues with > > >the proprietary NVIDIA drivers. Packagers of the NVIDIA > proprietary > > >drivers may want to add drop-in configuration files that set > > >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for > systemd-suspend.service > > >and related services, and > SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for > > >systemd-homed.service. > > > > Thanks for catching that. I'll try to include a fix with the upcoming > > uploads of the recent CVE series. > > > > As I'm not that familiar with configuring systemd bits, do you know what > > would be the correct locations and contents to ship the fix? > > > > If I read the documentation correctly, that should be > > > > /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf > > = 8< = > > [Service] > > Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" > > = >8 = > > > > and > > > > /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf > > = 8< = > > [Service] > > Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false" > > = >8 = > > > > Could you verify that this works (after unapplying your temporary > solution)? > > Hi Andreas, I can confirm those are the correct locations. You can > also omit the quotes. >
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
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 > > I was talking solely about TF-A for rk3566/rk3568 here; the situation > for rk3588 is unknown to me and could be totally different. > > AFAICT, there are 2 'MRs' for TF-A for rk356x: > 1) Addition to the (CI) build config > 2) The actual patch set for TF-A for rk356x > > ad 1) https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/20480 > ... > > ad 2) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952 > Depends on 1 AFAICT. It's missing a SCMI part, but the plan is to add > that in a subsequent patch. The latter one has just been merged \o/ Thanks Kever and shengfei! The former one is still 'Active' although I thought they were supposed to be merged together. And apparently 'Gerrit' is a bit confused (by TF-A's workflow?) 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. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072735: linux-image-6.7.12-amd64: graphics / KMS errors on AMD internal GPU
Control: tag -1 moreinfo On Friday, 7 June 2024 11:27:43 CEST Michael Kesper wrote: > With kernel 6.7.12-amd64, no GUI is getting started, also no console > gets opened automatically (boot seems to "hang"). External monitors > (connected via USB HUB) stay blank. > With kernel 6.6 everything works as expected. Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find older kernels from the 6.7 series, starting with 6.7+1~exp1. Can you try whether the problem is also present in older 6.7 kernel versions? signature.asc Description: This is a digitally signed message part.
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
Package: nvidia-driver Version: 545.23.06-1 Severity: normal systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions: * The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary drivers may want to add drop-in configuration files that set SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for systemd-homed.service. And indeed suspend would hang for me with either nvidia driver 545.23.06-1 or 535.161.08-2. For anybody stumbling on this bug report: The easiest way to do this by hand, is to run `systemctl edit systemd-suspend.service` and add the two lines: [Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" -- Package-specific info: uname -a: Linux fractal 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) x86_64 GNU/Linux /proc/version: Linux version 6.8.12-amd64 (debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 545.23.06 Sun Oct 15 17:43:11 UTC 2023 GCC version: gcc version 13.2.0 (Debian 13.2.0-25) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ZOTAC International (MCO) Ltd. Device [19da:a454] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Jun 7 07:45 /dev/dri/card0 crw-rw+ 1 root render 226, 128 Jun 7 07:45 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Jun 7 07:45 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Jun 7 07:45 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Jun 7 07:45 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Jun 7 07:45 pci-:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Jun 7 07:45 pci-:01:00.0-render -> ../renderD128 video:x:44:pdewacht Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy slave nvidia--nvidia-application-profiles-key-documentation is /usr/share/nvidia/nvidia-application-profiles-key-documentation slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf slave nvidia--nvidia-settings is /usr/bin/nvidia-settings slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz slave nvidia--nvidia-settings.desktop is /usr/share/applications/nvidia-settings.desktop slave nvidia--nvidia-smi is /usr/bin/nvidia-smi slave nvidia--nvidia-smi.1.gz is /usr/share/man/man1/nvidia-smi.1.gz slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so /usr/lib/nvidia/current - priority 545 slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/current/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu:
Bug#1072435: minidlna: FTBFS with ffmpeg 7.0 : libav.h:177:36: error: ‘AVCodecParameters ’ has no member named ‘channels’
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: > Source: minidlna > Version: 1.3.3+dfsg-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 an upstream bug for it, but not yet a solution. Updating metadata accordingly. signature.asc Description: This is a digitally signed message part.
Bug#1055157: duf version not shown
Will it be possible to improve the duf package to show the version? Danie de Jager
Bug#1060200: intel-microcode: diff for NMU version 3.20240531.1+nmu1
Hello Chris, Did you test the result? Does the system boots with an updated microcode after the change ? It has to be tested with mkinitramfs and Dracut, the resulting early-initramfs must be "almost" byte-equal (timestamps can change, but not the paths/filenames inside, nor the *offset* where the data starts relative to start-of-file. THIS IS IMPORTANT. I believe it should really just work with mkinitramfs, since we ask iucode_tool to generate the early-initramfs in that case, and iucode_tool doesn't care where the source data is, as long as it can read it. One should still test it to be sure. Dracut, I haven't looked into what it is doing. Hopefully it also uses iucode_tool nowadays... -- Henrique de Moraes Holschuh
Bug#1072538: dracut-core: systemd-cryptsetup missing from generated image
Package: dracut-core Version: 102-1 Severity: important Hi, As of version 102-1 the generated initrd leaves my system unbootable, as my root filesystem in luks-encrypted. After investigating it looks like the systemd-cryptsetup binary is simply missing. I looked through /usr/lib/dracut/modules.d/90crypt/module-setup.sh and couldn't find an instance where this binary is installed. I added the line: inst_multiple systemd-cryptsetup cryptsetup … to the install() function of that file, regenerated my initrd, and it works again. It'd be nice to get a proper fix. Thank you, -- Mourad DC -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dracut-core depends on: ii cpio2.15+dfsg-1 ii dracut-install 102-1 ii e2fsprogs 1.47.1-1 ii kmod32+20240327-1 ii libc6 2.38-12 ii libkmod232+20240327-1 ii udev256~rc3-7 Versions of packages dracut-core recommends: ii binutils 2.42-4 pn console-setup ii cryptsetup 2:2.7.2-2 pn dmraid ii dmsetup2:1.02.196-1+b1 ii kpartx 0.9.7-7 pn lvm2 pn mdadm ii pigz 2.8-1 ii pkgconf1.8.1-1+b2 ii systemd256~rc3-7 dracut-core suggests no packages. -- no debconf information
Bug#1027773: setting sysctl net.ipv4.ping_group_range
On Monday, 3 June 2024 13:29:48 CEST Luca Boccassi wrote: > as we get near the Trixie freeze (say, September) Wait, wut? Isn't that usually in/around January? signature.asc Description: This is a digitally signed message part.
Bug#1072458: wf-recorder: FTBFS with ffmpeg 7.0: ../src/frame-writer.cpp:458:19: error: ‘const AVCodec’ {aka ‘const struct AVCodec’} has no member named ‘channel_layouts’; did you mean ‘ch_layouts’?
Control: tag -1 upstream
Control: forwarded -1 https://github.com/ammen99/wf-recorder/pull/262
On zondag 2 juni 2024 15:27:52 CEST you wrote:
> Source: wf-recorder
> Version: 0.4.1-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
With the attached patch (taken from upstream PR, but adapted for Debian
packaging) it builds successfully against ffmpeg 7.0 (as well as 6.1).
Although ... for some reason the reprotest failed as it was unable to fulfill
the `ffmpeg (>= 7:7.0)` B-D in that job. Setting Salsa's CI release to
"experimental" didn't make it use ffmpeg from experimental, so 'forced' it via
an updated B-D, which worked ... for the most part.
Therefor I'm not adding the 'patch' tag.
https://salsa.debian.org/diederik/wf-recorder/-/pipelines/685183
HTH,
Diederik>From 0cd5917c9e1ee46685119922e3ec2d5392dccbf1 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Sun, 2 Jun 2024 15:47:16 +0200
Subject: [PATCH] d/patches: Add ffmpeg 7.0 compatibility
There's an upstream PR for ffmpeg 7.0 compatibility, so add the patch
from that PR to ``debian/patches``.
Closes: #1072458
Link: https://github.com/ammen99/wf-recorder/pull/262
---
debian/patches/ffmpeg-7-compat-pr262.patch | 109 +
debian/patches/series | 1 +
2 files changed, 110 insertions(+)
create mode 100644 debian/patches/ffmpeg-7-compat-pr262.patch
create mode 100644 debian/patches/series
diff --git a/debian/patches/ffmpeg-7-compat-pr262.patch b/debian/patches/ffmpeg-7-compat-pr262.patch
new file mode 100644
index 000..432ecf3
--- /dev/null
+++ b/debian/patches/ffmpeg-7-compat-pr262.patch
@@ -0,0 +1,109 @@
+From 239829231e6bf5da30c43413491a0a195b84101d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Robert-Andr=C3=A9=20Mauchin?=
+Date: Mon, 6 May 2024 17:03:08 +0200
+Subject: [PATCH] Add compatibility with FFMPEG 7.0
+Origin: upstream, https://github.com/ammen99/wf-recorder/pull/262
+
+channel_layout has been replaced with ch_layout
+---
+ src/frame-writer.cpp | 38 +-
+ 1 file changed, 37 insertions(+), 1 deletion(-)
+
+diff --git a/src/frame-writer.cpp b/src/frame-writer.cpp
+index ad21e49..2bd9d51 100644
+--- a/src/frame-writer.cpp
b/src/frame-writer.cpp
+@@ -12,6 +12,7 @@
+ #include "averr.h"
+ #include
+
++#define HAVE_CH_LAYOUT (LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(57, 28, 100))
+
+ static const AVRational US_RATIONAL{1,100} ;
+
+@@ -446,6 +447,22 @@ void FrameWriter::init_video_stream()
+ }
+
+ #ifdef HAVE_PULSE
++#if HAVE_CH_LAYOUT
++static uint64_t get_codec_channel_layout(const AVCodec *codec)
++{
++int i = 0;
++if (!codec->ch_layouts)
++return AV_CH_LAYOUT_STEREO;
++while (1) {
++if (!av_channel_layout_check(>ch_layouts[i]))
++break;
++if (codec->ch_layouts[i].u.mask == AV_CH_LAYOUT_STEREO)
++return codec->ch_layouts[i].u.mask;
++i++;
++}
++return codec->ch_layouts[0].u.mask;
++}
++#else
+ static uint64_t get_codec_channel_layout(const AVCodec *codec)
+ {
+ int i = 0;
+@@ -460,6 +477,7 @@ static uint64_t get_codec_channel_layout(const AVCodec *codec)
+ }
+ return codec->channel_layouts[0];
+ }
++#endif
+
+ static enum AVSampleFormat get_codec_auto_sample_fmt(const AVCodec *codec)
+ {
+@@ -533,10 +551,14 @@ void FrameWriter::init_audio_stream()
+ {
+ audioCodecCtx->sample_fmt = convert_codec_sample_fmt(codec, params.sample_fmt);
+ }
++#if HAVE_CH_LAYOUT
++av_channel_layout_from_mask(>ch_layout, get_codec_channel_layout(codec));
++#else
+ audioCodecCtx->channel_layout = get_codec_channel_layout(codec);
++audioCodecCtx->channels = av_get_channel_layout_nb_channels(audioCodecCtx->channel_layout);
++#endif
+ audioCodecCtx->sample_rate = params.sample_rate;
+ audioCodecCtx->time_base = (AVRational) { 1, 1000 };
+-audioCodecCtx->channels = av_get_channel_layout_nb_channels(audioCodecCtx->channel_layout);
+
+ if (fmtCtx->oformat->flags & AVFMT_GLOBALHEADER)
+ audioCodecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
+@@ -559,8 +581,14 @@ void FrameWriter::init_audio_stream()
+ av_opt_set_int(swrCtx, "out_sample_rate", audioCodecCtx->sample_rate, 0);
+ av_opt_set_sample_fmt(swrCtx, "in_sample_fmt", AV_SAMPLE_FMT_FLT, 0);
+ av_opt_set_sample_fmt(swrCtx, "out_sample_fmt", audioCodecCtx->sample_fmt, 0);
++#if HAVE_CH_LAYOUT
++AVChannelLayout in_chlayout = AV_CHANNEL_LAYOUT_STEREO;
++av_opt_set_chlayout(swrCtx, "in_chlayout", _chlayout, 0);
++av_opt_set_chlayout(swrCtx, "out_chlayout", >ch_layout, 0);
++#else
+ av_opt_set_channel_layout(swrCtx, "in_channel_layout",
Bug#1072355: nss-pam-ldapd: upload with maintainer-built binaries cannot migrate
On Sat, 2024-06-01 at 14:59 +0200, Chris Hofstaedtler wrote: > thanks for uploading to unstable. However the upload included > maintainer-built binaries (for Arch: all and amd64). Migration to > testing of these is forbidden by release team policy. > Please upload a new version (no further changes needed) without any > binaries to let the package migrate. Thanks. I always seem to be confused about which changes file to upload :/ Anyway, I've just uploaded 0.9.12-7 which should be source-only again. -- -- arthur - adej...@debian.org - https://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#1061701: nss-pam-ldapd: install PAM and NSS modules into /usr
On Wed, 2024-05-29 at 00:59 +0200, Chris Hofstaedtler wrote: > Please make sure this patch reaches unstable well before the trixie > transition freeze. Now would be a good time. Thanks for the reminder. I've uploaded 0.9.12-6 which includes this change. -- -- arthur - adej...@debian.org - https://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#1072239: bookworm-pu: package intel-microcode/3.20240514.1~deb12u1
, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08 +sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433 +sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808 +sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040 +sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240 +sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960 +sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230 + 2024-03-12: * New upstream microcode datafile 20240312 - Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368): diff --git a/debian/changelog b/debian/changelog index f156f68..92b7e2b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,52 @@ +intel-microcode (3.20240514.1~deb12u1) bookworm; urgency=medium + + * Build for bookworm (no changes) + + -- Henrique de Moraes Holschuh Wed, 29 May 2024 23:27:07 -0300 + +intel-microcode (3.20240514.1) unstable; urgency=medium + + * New upstream microcode datafile 20240514 +* Mitigations for INTEL-SA-01051 (CVE-2023-45733) + Hardware logic contains race conditions in some Intel Processors may + allow an authenticated user to potentially enable partial information + disclosure via local access. +* Mitigations for INTEL-SA-01052 (CVE-2023-46103) + Sequence of processor instructions leads to unexpected behavior in + Intel Core Ultra Processors may allow an authenticated user to + potentially enable denial of service via local access. +* Mitigations for INTEL-SA-01036 (CVE-2023-45745, CVE-2023-47855) + Improper input validation in some Intel TDX module software before + version 1.5.05.46.698 may allow a privileged user to potentially enable + escalation of privilege via local access. +* Fix for unspecified functional issues on 4th gen and 5th gen Xeon + Scalable, 12th, 13th and 14th gen Intel Core processors, as well as for + Core i3 N-series processors. +* Updated microcodes: + sig 0x000806f8, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0, size 581632 + sig 0x000806f7, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f6, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f5, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f4, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f8, pf_mask 0x10, 2024-02-05, rev 0x2c000390, size 614400 + sig 0x000806f6, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x000806f5, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x000806f4, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x00090672, pf_mask 0x07, 2023-12-05, rev 0x0035, size 224256 + sig 0x00090675, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08 + sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433 + sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808 + sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040 + sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240 + sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960 + sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230 + * source: update symlinks to reflect id of the latest release, 20240514 + + -- Henrique de Moraes Holschuh Thu, 16 May 2024 21:40:52 -0300 + intel-microcode (3.20240312.1~deb12u1) bookworm; urgency=medium * Build for bookworm (no changes) diff --git a/intel-ucode/06-8f-05 b/intel-ucode/06-8f-05 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-05 and b/intel-ucode/06-8f-05 differ diff --git a/intel-ucode/06-8f-06 b/intel-ucode/06-8f-06 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-06 and b/intel-ucode/06-8f-06 differ diff --git a/intel-ucode/06-8f-07 b/intel-ucode/06-8f-07 index 07ab364..d629737 100644 Binary files a/intel-ucode/06-8f-07 and b/intel-ucode/06-8f-07 differ diff --git a/intel-ucode/06-8f-08 b/intel-ucode/06-8f-08 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-08 and b/intel-ucode/06-8f-08 differ diff --git a/intel-ucode/06-97-02 b/intel-ucode/06-97-02 index 71c9c34..05450f8 100644 Binary files a/intel-ucode/06-97-02 and b/intel-ucode/06-97-02 differ diff --git a/intel-ucode/06-97-05 b/intel-ucode/06-97-05 index 71c9c34..05450f8 100644 Binary files a/intel-ucode/06-97-05 and b/intel-ucode/06-97-05 differ diff --git a/intel-ucode/06-9a-03 b/intel-ucode/06-9a-03 index a8339f9..b4f9b45 100644 Binary files a/intel-ucode/06-9a-03 and b/intel-ucode/06-9a-03 differ diff --git a/intel-ucode/06-9a-04 b/intel-ucode/06-9a-04 index 5917702..27bfc92 100644 Binary files a/intel-ucode/06-9a-04 and
Bug#1072238: bullseye-pu: package intel-microcode/3.20240514.1~deb11u1
, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035 +sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08 +sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433 +sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808 +sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040 +sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240 +sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960 +sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230 + 2024-03-12: * New upstream microcode datafile 20240312 - Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368): diff --git a/debian/changelog b/debian/changelog index 317fad2..10f37f4 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,53 @@ +intel-microcode (3.20240514.1~deb11u1) bullseye; urgency=medium + + * Backport to Debian Bullseye + * debian/control: revert non-free-firmware change + + -- Henrique de Moraes Holschuh Wed, 29 May 2024 23:31:29 -0300 + +intel-microcode (3.20240514.1) unstable; urgency=medium + + * New upstream microcode datafile 20240514 +* Mitigations for INTEL-SA-01051 (CVE-2023-45733) + Hardware logic contains race conditions in some Intel Processors may + allow an authenticated user to potentially enable partial information + disclosure via local access. +* Mitigations for INTEL-SA-01052 (CVE-2023-46103) + Sequence of processor instructions leads to unexpected behavior in + Intel Core Ultra Processors may allow an authenticated user to + potentially enable denial of service via local access. +* Mitigations for INTEL-SA-01036 (CVE-2023-45745, CVE-2023-47855) + Improper input validation in some Intel TDX module software before + version 1.5.05.46.698 may allow a privileged user to potentially enable + escalation of privilege via local access. +* Fix for unspecified functional issues on 4th gen and 5th gen Xeon + Scalable, 12th, 13th and 14th gen Intel Core processors, as well as for + Core i3 N-series processors. +* Updated microcodes: + sig 0x000806f8, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0, size 581632 + sig 0x000806f7, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f6, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f5, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f4, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0 + sig 0x000806f8, pf_mask 0x10, 2024-02-05, rev 0x2c000390, size 614400 + sig 0x000806f6, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x000806f5, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x000806f4, pf_mask 0x10, 2024-02-05, rev 0x2c000390 + sig 0x00090672, pf_mask 0x07, 2023-12-05, rev 0x0035, size 224256 + sig 0x00090675, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035 + sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08 + sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433 + sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808 + sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040 + sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240 + sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960 + sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230 + * source: update symlinks to reflect id of the latest release, 20240514 + + -- Henrique de Moraes Holschuh Thu, 16 May 2024 21:40:52 -0300 + intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium * Backport to Debian Bullseye diff --git a/intel-ucode/06-8f-05 b/intel-ucode/06-8f-05 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-05 and b/intel-ucode/06-8f-05 differ diff --git a/intel-ucode/06-8f-06 b/intel-ucode/06-8f-06 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-06 and b/intel-ucode/06-8f-06 differ diff --git a/intel-ucode/06-8f-07 b/intel-ucode/06-8f-07 index 07ab364..d629737 100644 Binary files a/intel-ucode/06-8f-07 and b/intel-ucode/06-8f-07 differ diff --git a/intel-ucode/06-8f-08 b/intel-ucode/06-8f-08 index bef4d36..ef5b752 100644 Binary files a/intel-ucode/06-8f-08 and b/intel-ucode/06-8f-08 differ diff --git a/intel-ucode/06-97-02 b/intel-ucode/06-97-02 index 71c9c34..05450f8 100644 Binary files a/intel-ucode/06-97-02 and b/intel-ucode/06-97-02 differ diff --git a/intel-ucode/06-97-05 b/intel-ucode/06-97-05 index 71c9c34..05450f8 100644 Binary files a/intel-ucode/06-97-05 and b/intel-ucode/06-97-05 differ diff --git a/intel-ucode/06-9a-03 b/intel-ucode/06-9a-03 index a8339f9..b4f9b45 100644 Binary files a/intel-ucode/06-9a-03 and b/intel-ucode/06-9a-03 differ diff --git a/intel-ucode/06-9a-04 b/intel-ucode/06-9a-04 index 5917702..27bfc92
Bug#1054093: monit: diff for NMU version 1:5.33.0-2.1
Em 29/05/2024 21:59, Chris Hofstaedtler escreveu: Control: tags 1054093 + pending Dear maintainer, I've prepared an NMU for monit (versioned as 1:5.33.0-2.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. Hi Chris, Your NMU is welcome, and feel free to reduce the delay if you see fit. Thanks. -- ⢀⣴⠾⠻⢶⣦ ⣾⠁⢠⠒⠀⣿⡁ Fabio Augusto De Muzio Tobich ⢿⡄⠘⠷⠚⠋⠀ 9730 4066 E5AE FAC2 2683 D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE
On Wednesday, 29 May 2024 03:22:50 CEST Mark Pearson wrote: > >> X-Debbugs-Cc: mpearson-len...@squebb.ca > > ... > > The MR for it (1062) has just been merged into master. > > Awesome - thanks! I did scan the bugs before submitting but missed that one. > Apologies. Should I close this issue then as it's a duplicate? I *assumed* the "X-Debbugs-Cc" meant that bug would've landed directly in your inbox, but I can be wrong. Sorry about that. No need to do anything. They're merged which means that when the kernel with that commit gets uploaded to the Debian archives, both will automatically be closed together. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE
Control: forcemerge -1 1071551 On Tuesday, 28 May 2024 20:20:11 CEST Mark Pearson wrote: > Package: src:linux > Version: 6.8.11-1 > Severity: important > X-Debbugs-Cc: mpearson-len...@squebb.ca > > Dear Maintainer, > > Please enable the CONFIG_PINCTRL_METEORLAKE kernel option. This is needed to > support Meteorlake based platforms. That was already requested in bug #1071551 with the following header: On Mon, 20 May 2024 22:19:16 -0300 Facundo Gaich wrote: > Package: src:linux > Version: 6.8.9-1 > Severity: important > X-Debbugs-Cc: mpearson-len...@squebb.ca ... The MR for it (1062) has just been merged into master. signature.asc Description: This is a digitally signed message part.
Bug#1072090: cannot use compile command
Package: gdb Version: 13.2-1+b1 Severity: normal As of recently, I cannot use the compile command anymore. (gdb) compile close(6); cc1: fatal error: libcc1plugin: unknown version in handshake compilation terminated. Compilation failed. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 gdb depends on: ii libbabeltrace1 1.5.11-3+b6 ii libc62.38-11 ii libdebuginfod1t640.191-1+b1 ii libexpat12.6.2-1 ii libgcc-s114.1.0-1 ii libgmp10 2:6.3.0+dfsg-2+b1 ii libipt2 2.0.6-1 ii liblzma5 5.6.1+really5.4.5-1 ii libmpfr6 4.2.1-1+b1 ii libncursesw6 6.5-2 ii libpython3.11t64 3.11.9-1 ii libreadline8t64 8.2-4 ii libsource-highlight4t64 3.1.9-4.3 ii libstdc++6 14.1.0-1 ii libtinfo66.5-2 ii libxxhash0 0.8.2-2+b1 ii libzstd1 1.5.5+dfsg2-2 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages gdb recommends: ii libc6-dbg [libc-dbg] 2.38-11 Versions of packages gdb suggests: pn gdb-doc ii gdbserver 13.2-1+b1 -- no debconf information
Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'
On Monday, 27 May 2024 17:25:02 CEST Tzafrir Cohen wrote: > Thanks for that. Just one note regarding the word "upstream". The > current upstream of the package is the osmo fork. At the time when > uploading previous version, that fork was looking more reliable than the > main branch. Yeah, it was/is a bit confusing, hence my next reply contained: On 27 May 2024 10:40:24 +0200 Diederik de Haas wrote: > Forgot to mention that that commit is part of upstream's 3.4.0~rc1, > but it's unclear to me what is considered upstream now. The ``debian/watch`` file points to one repo, but the ``upstream`` branch (indeed) indicated that came from another repo. signature.asc Description: This is a digitally signed message part.
Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'
On 27 May 2024 10:26:45 +0200 Diederik de Haas wrote: > Control: tag -1 upstream fixed-upstream patch > > On Tue, 21 May 2024 14:57:47 +0200 Andreas Beckmann wrote: > > Package: dahdi-dkms > > Version: 1:3.1.0+git20230717~dfsg-5 > > Severity: serious > > Attached is the upstream patch for compatibility with 6.8/6.9 kernels added > to ``debian/patches``. Forgot to mention that that commit is part of upstream's 3.4.0~rc1, but it's unclear to me what is considered upstream now. https://github.com/asterisk/dahdi-linux/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce signature.asc Description: This is a digitally signed message part.
Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'
Control: tag -1 upstream fixed-upstream patch On Tue, 21 May 2024 14:57:47 +0200 Andreas Beckmann wrote: > Package: dahdi-dkms > Version: 1:3.1.0+git20230717~dfsg-5 > Severity: serious > > DKMS make.log for dahdi-3.1.0+git20230717 for kernel 6.8.9-amd64 (x86_64) > Sun May 19 19:55:53 UTC 2024 > make -C /lib/modules/6.8.9-amd64/build KBUILD_EXTMOD=/var/lib/dkms/dahdi/ > 3.1.0+git20230717/build/drivers/dahdi DAHDI_INCLUDE=/var/lib/dkms/dahdi/ > 3.1.0+git20230717/build/include DAHDI_MODULES_EXTRA="dahdi_dummy.o > dahdi_echocan_oslec.o " HOTPLUG_FIRMWARE=yes m > ... > /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wct4xxp/base.c: > In function 'free_wc': > /usr/src/linux-headers-6.8.9-common/include/linux/workqueue.h:625:9: > warning: call to '__warn_flushing_systemwide_wq' declared with attribute > warning: Please avoid flushing system-wide workqueues. [-Wattribute-warning] > 625 | __warn_flushing_systemwide_wq(); > > \ > | ^~~ This is something upstream should take a look at, but is not the cause of the build failure. > CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/ > card_global.o > /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/card_global.c: > In function 'parse_chip_command': > /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/card_global.c > :344:9: error: implicit declaration of function 'strlcpy'; did you mean > 'strscpy'? [-Werror=implicit-function-declaration]> > 344 | strlcpy(buf, cmdline, MAX_PROC_WRITE); /* Save a copy */ > > | ^~~ > | strscpy > > cc1: some warnings being treated as errors But this is. Attached is the upstream patch for compatibility with 6.8/6.9 kernels added to ``debian/patches``. >From e032b7936b75400f039ae8dfd40b1fdfdd56f2ce Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Mon, 27 May 2024 10:18:08 +0200 Subject: [PATCH] d/patches: Add "Fix compilation issue for 6.8.y/6.9.y kernel" Link: https://github.com/asterisk/dahdi-linux/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce --- ...ilation-issue-for-6.8.y-6.9.y-kernel.patch | 231 ++ debian/patches/series | 2 + 2 files changed, 233 insertions(+) create mode 100644 debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch diff --git a/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch b/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch new file mode 100644 index 000..123428b --- /dev/null +++ b/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch @@ -0,0 +1,231 @@ +From: Pushkar Singh +Date: Thu, 4 Apr 2024 01:15:01 +0530 +Subject: Fix compilation issue for 6.8.y/6.9.y kernel +Origin: upstream, https://github.com/asterisk/dahdi-linux.git/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce + +--- + drivers/dahdi/dahdi-base.c | 40 ++--- + drivers/dahdi/dahdi_dynamic.c | 4 +-- + drivers/dahdi/dahdi_dynamic_eth.c | 4 +-- + drivers/dahdi/dahdi_dynamic_ethmf.c | 2 +- + drivers/dahdi/dahdi_transcode.c | 2 +- + drivers/dahdi/xpp/card_global.c | 2 +- + 6 files changed, 27 insertions(+), 27 deletions(-) + +diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c +index b96f72b..87177a6 100644 +--- a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c +@@ -4359,7 +4359,7 @@ static int dahdi_ioctl_getparams(struct file *file, unsigned long data) + param.pulsebreaktime = chan->pulsebreaktime; + param.pulseaftertime = chan->pulseaftertime; + param.spanno = (chan->span) ? chan->span->spanno : 0; +- strlcpy(param.name, chan->name, sizeof(param.name)); ++ strscpy(param.name, chan->name, sizeof(param.name)); + param.chanpos = chan->chanpos; + param.sigcap = chan->sigcap; + /* Return current law */ +@@ -4447,8 +4447,8 @@ static int dahdi_ioctl_spanstat(struct file *file, unsigned long data) + + spaninfo.spanno = s->spanno; /* put the span # in here */ + spaninfo.totalspans = span_count(); +- strlcpy(spaninfo.desc, s->desc, sizeof(spaninfo.desc)); +- strlcpy(spaninfo.name, s->name, sizeof(spaninfo.name)); ++ strscpy(spaninfo.desc, s->desc, sizeof(spaninfo.desc)); ++ strscpy(spaninfo.name, s->name, sizeof(spaninfo.name)); + spaninfo.alarms = s->alarms; /* get alarm status */ + spaninfo.rxlevel = s->rxlevel; /* get rx level */ + spaninfo.txlevel = s->txlevel; /* get tx level */ +@@ -4475,18 +4475,18 @@ static int dahdi_ioctl_spanstat(struct file *file, unsigned long data) + spaninfo.lineconfig = s->lineconfig; + spaninfo.irq = 0; + spaninfo.linecompat = s->linecompat; +- strlcpy(spaninfo.lboname, dahdi_lboname(s->lbo), ++ strscpy(spaninfo.lboname, dahdi_lbon
Bug#1071959: arm-trusted-firmware: New upstream versions (lts-v2.10.4 and v2.11)
Source: arm-trusted-firmware Version: 2.10.0+dfsg-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. 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.8.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/XblvOeH7bbgUCZlNFxAAKCRDXblvOeH7b bt0NAQCWZNqPRYkhlbRqsZm/q9eqj7ktyDa9b9gKG04+7bYpngEAlTjYOwCxzdWu fuEoYL6KFbWRhJfCzPr/FDiF3UBxlQo= =Ix6n -END PGP SIGNATURE-
Bug#1009802: Warning: The home dir /var/lib/usbmux you specified can't be accessed: No such file or directory
Control: found -1 1.1.1-2 Control: found -1 1.1.1-3+b1 On 18 Apr 2022 12:23:29 -0700 Scott Corcoran wrote: > Good catch: > > ~ # apt list | grep usbmuxd > > libusbmuxd-dev/testing 2.0.2-3 amd64 > libusbmuxd-tools/testing 2.0.2-3 amd64 > libusbmuxd6/testing,now 2.0.2-3 amd64 [installed,automatic] > usbmuxd/testing,now 1.1.1-2 amd64 [installed,automatic] Setting the found version to that version. And as I just ran into this problem too, add my version too. I installed upower and as one of its dependencies, usbmuxd got installed too: ``` Selecting previously unselected package usbmuxd. Preparing to unpack .../5-usbmuxd_1.1.1-3+b1_arm64.deb ... Unpacking usbmuxd (1.1.1-3+b1) ... Setting up libplist3:arm64 (2.2.0-7+b1) ... Setting up libusbmuxd6:arm64 (2.0.2-4+b1) ... Setting up libupower-glib3:arm64 (1.90.3-1) ... Setting up libimobiledevice6:arm64 (1.3.0-7.1+b1) ... Setting up upower (1.90.3-1) ... upower.service is a disabled or a static unit, not starting it. Setting up usbmuxd (1.1.1-3+b1) ... info: The home dir /var/lib/usbmux you specified can't be accessed: No such file or directory info: Selecting UID from range 100 to 999 ... info: Adding system user `usbmux' (UID 106) ... info: Adding new user `usbmux' (UID 106) with group `plugdev' ... info: Not creating home directory `/var/lib/usbmux'. ``` And indeed /var/lib/usbmux doesn't exist on the system where I installed it on. It's also installed on my main PC and that doesn't have that dir either. Shouldn't this bug have a higher severity? It creates a (system) user and it wants to create a home dir for it, but fails to do so. I haven't noticed any adverse affects, so I won't bump the severity, but as I don't have any iDevice I may not be considered a 'normal' user of the package. signature.asc Description: This is a digitally signed message part.
Bug#1071825: linux-image-6.8.9-amd64: Fails to build some module(s) during install
Control: found -1 0.4.4-1 Control: tag -1 upstream patch Control: forwarded -1 https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/commit/7f851f5fb8fbcd7b3a93aaedff90b27124e17a7e On Saturday, 25 May 2024 10:18:20 CEST Bastian Blank wrote: > Control: reassign -1 ddcci-dkms/0.4.4-1 Upstream has a commit for compatibility with 6.8 and I've set that at the 'forwarded' URL. There's no release/tag with that commit though. HTH signature.asc Description: This is a digitally signed message part.
Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium
I extracted a patch file from the commit you mentioned at https://salsa.debian.org/chromium-team/chromium/-/commit/e8b6bbd59aadf18e41ee98841da7fc4783036957 and applied it in our environment. The patch seems to be working correctly. At least for our use case, the --user-agent flag, it does not cause any further problems. Let me know if you need any additional information. Andres Salomon schreef op 2024-05-23 20:05: Can you please test out the following patch? https://salsa.debian.org/chromium-team/chromium/-/commit/e8b6bbd59aadf18e41ee98841da7fc4783036957 The easiest way to test would probably be to manually edit /usr/bin/chromium, and cut/paste the changes that are reflected in that commit for the debian/scripts/chromium file. On 5/23/24 12:42, Andres Salomon wrote: Thanks for the heads up. While I work on fixing this, a temporary workaround you can use is ' -- ' before --user-agent. Eg, chromium --headless --no-sandbox -- --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" On 5/23/24 07:11, Remco de Man wrote: Package: chromium Version: 125.0.6422.76-1~deb12u1 Severity: normal Dear Maintainer, When running 125.0.6422.76-1~deb12u1, when passing arguments to the chromium wrapper script included in the Debian package, not all arguments are passed correctly to the Chromium binary. This happens especially when the arguments need any type of quoting, like in the case of passing a custom User-Agent with --user-agent. A minimal reproduction sample for me is running the following command: chromium --headless --no-sandbox --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" It seems that because the user agent contains spaces, this is not correctly passed to the chromium binary. The regression was not present in the previous security release, 125.0.6422.60-1~deb12u1, and seems to be caused by change https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb Because of this, many of our headless usage scenarios do not work correctly anymore, since Chromium exits with the 'Multiple targets are not supported' message, because it parses some of the user agent as seperate arguments to its binary. Seems like the wrapper script should be patched to handle this scenario, or the change should be reverted. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages chromium depends on: ii chromium-common 125.0.6422.76-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u5 ii libdav1d6 1.0.0-2+deb12u1 ii libdbus-1-3 1.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm2 2.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm1 22.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libharfbuzz-subset0 6.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo 1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip1 1.1-8+deb12u1 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-16 1.6.39-2 ii libpulse0 16.1+dfsg1-2+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii libxnvctrl0 525.85.05-3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chr
Bug#1063161:
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote: > 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? Sure. Bit surprised it wouldn't be automatically selected though. signature.asc Description: This is a digitally signed message part.
Bug#966570: RFP: libamf -- Advanced Media Framework (AMF) SDK
On 30 Jul 2020 16:00:44 -0400 Louis-Philippe Véronneau wrote: > I'm happy to help or sponsor work for this, but I'm not confident I > understand the codebase enough to be packaging this myself. There has been a reply to this, but it didn't directly To/CC you, so I'm replying to make sure you're at least aware of it. signature.asc Description: This is a digitally signed message part.
Bug#1071666: ffmpeg: autopkgtest failure with ffmpeg 7.0
Package: ffmpeg
Version: 7:7.0-1+b1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The autopkgtest job [1] fails with ffmpeg 7.0 with the following error:
"no single success: something is definitely wrong"
AFAICT this is caused by an extra column in the ``ffmpeg -format``
command which results in an empty "muxers" list, which in turn causes
it to skip all the tests.
If I apply the attached patch then the muxers list is no longer empty
and then it does run all the tests.
There's still a failure though [2], but now it's only one test
that fails:
```
Test 674:
trying muxer 'nut' with 'a' encoder 'adpcm_ima_wav' for codec 'adpcm_ima_wav'
ffmpeg -threads 2 -f lavfi -i sine=d=0.1 -strict -2 -c:a adpcm_ima_wav -f nut
/tmp/autopkgtest-lxc.uwh7i80y/downtmp/autopkgtest_tmp/test/adpcm_ima_wav.nut -y
-hide_banner -nostdin
Input #0, lavfi, from 'sine=d=0.1':
Duration: N/A, start: 0.00, bitrate: 705 kb/s
Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s16le (native) -> adpcm_ima_wav (native))
Output #0, nut, to
'/tmp/autopkgtest-lxc.uwh7i80y/downtmp/autopkgtest_tmp/test/adpcm_ima_wav.nut':
Metadata:
encoder : Lavf61.1.100
Stream #0:0: Audio: adpcm_ima_wav ([17][0][0][0] / 0x0011), 44100 Hz, mono,
s16p, 176 kb/s
Metadata:
encoder : Lavc61.3.100 adpcm_ima_wav
[out#0/nut @ 0x556381aa17c0] video:0KiB audio:3KiB subtitle:0KiB other
streams:0KiB global headers:0KiB muxing overhead: 9.700521%
size= 3KiB time=00:00:00.10 bitrate= 269.6kbits/s speed=46.9x
FAILED: nut;a=adpcm_ima_wav; probing failed: 1
```
There are also several "SUCCESS" test which mention "streamcopying fails".
I don't know if that's expected though.
I don't know if the patch is correct (so didn't tag it as such) and it's
certainly incomplete as there's still a failure. I didn't look into why
that was though.
Hopefully it does help find a proper/complete fix for autopkgtest.
Cheers,
Diederik
[1] https://salsa.debian.org/diederik/ffmpeg/-/jobs/5762517
[2] https://salsa.debian.org/diederik/ffmpeg/-/jobs/5762735
- -- 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.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
Versions of packages ffmpeg depends on:
ii libavcodec-extra61 [libavcodec61]7:7.0-1+b1
ii libavdevice617:7.0-1+b1
ii libavfilter107:7.0-1+b1
ii libavformat-extra61 [libavformat61] 7:7.0-1+b1
ii libavutil59 7:7.0-1+b1
ii libc62.38-11
ii libplacebo3386.338.2-2
ii libpostproc587:7.0-1+b1
ii libsdl2-2.0-02.30.2+dfsg-1
ii libswresample5 7:7.0-1+b1
ii libswscale8 7:7.0-1+b1
ffmpeg recommends no packages.
Versions of packages ffmpeg suggests:
pn ffmpeg-doc
- -- no debconf information
-BEGIN PGP SIGNATURE-
iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZk84QQAKCRDXblvOeH7b
bvVIAQDA4LvXWWAPSZQwaqZlylM725y7ufLDUipcQjCdeAPB2wEAkt24mkzhrX4a
k4j1ha90YnCJ4osRP4cQB7zVM9NgPAE=
=T+qu
-END PGP SIGNATURE-
>From 7a9c17ed2508f9f4a3ac8e8fc104e1da07335935 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Thu, 23 May 2024 12:08:28 +0200
Subject: [PATCH] d/tests: Update list_formats for extra output column in
ffmpeg 7.0
The ``ffmpeg -formats`` command got an extra output column.
``ffmpeg -formats`` output header for ffmpeg 6.1:
```
File formats:
D. = Demuxing supported
.E = Muxing supported
```
``ffmpeg -formats`` output header for ffmpeg 7.0:
```
Formats:
D.. = Demuxing supported
.E. = Muxing supported
..d = Is a device
```
This caused problems with the ``sed`` statement and caused the list of
muxers to be empty, which caused the autopkgtests to fail.
Fix the ``sed`` statement in the ``list_formats`` function so that the
list of muxers is no longer empty.
---
debian/tests/encdec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tests/encdec b/debian/tests/encdec
index 377bd70d..97588833 100755
--- a/debian/tests/encdec
+++ b/debian/tests/encdec
@@ -160,7 +160,7 @@ list_formats() {
# Get the raw list
lines=$(ffmpeg -hide_banner -formats | grep "^ $match")
for line in $lines; do
-item=$(echo "$line" | sed "s/^ [D ][E ] \([^ ]*\) .*/\1/")
+item=$(echo "$line" | sed "s/^ [D ][E ][d ] \([^ ]*\) .*/\1/")
item=${item%%,*}
echo "$item"
done
--
2.45.1
Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium
Package: chromium Version: 125.0.6422.76-1~deb12u1 Severity: normal Dear Maintainer, When running 125.0.6422.76-1~deb12u1, when passing arguments to the chromium wrapper script included in the Debian package, not all arguments are passed correctly to the Chromium binary. This happens especially when the arguments need any type of quoting, like in the case of passing a custom User-Agent with --user-agent. A minimal reproduction sample for me is running the following command: chromium --headless --no-sandbox --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" It seems that because the user agent contains spaces, this is not correctly passed to the chromium binary. The regression was not present in the previous security release, 125.0.6422.60-1~deb12u1, and seems to be caused by change https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb Because of this, many of our headless usage scenarios do not work correctly anymore, since Chromium exits with the 'Multiple targets are not supported' message, because it parses some of the user agent as seperate arguments to its binary. Seems like the wrapper script should be patched to handle this scenario, or the change should be reverted. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages chromium depends on: ii chromium-common125.0.6422.76-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-02.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u5 ii libdav1d6 1.0.0-2+deb12u1 ii libdbus-1-31.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm22.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm122.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libharfbuzz-subset06.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip11.1-8+deb12u1 ii libnspr4 2:4.35-1 ii libnss32:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-161.6.39-2 ii libpulse0 16.1+dfsg1-2+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxml22.9.14+dfsg-1.3~deb12u1 ii libxnvctrl0525.85.05-3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 125.0.6422.76-1~deb12u1 Versions of packages chromium suggests: ii chromium-driver 125.0.6422.76-1~deb12u1 pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.36-9+deb12u7 ii libdrm2 2.4.114-1+b1 ii libjsoncpp25 1.9.5-4 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u2 ii libxnvctrl0 525.85.05-3~deb12u1 ii x11-utils 7.7+5 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages chromium-common recommends: ii chromium-sandbox 125.0.6422.76-1~deb12u1 pn fonts-liberation ii libgl1-mesa-dri22.3.6-1+deb12u1 pn notification-daemon pn system-config-printer pn udev pn upower Versions of packages chromium-driver depends on: ii libatomic1 12.2.0-14 ii libc6 2.36-9+deb12u7 ii libdouble-conversion3 3.2.1-1 ii libevent-2.1-7 2.1.12-stable-8 ii libglib2.0-0 2.74.6-2+deb12u2 ii libjsoncpp25 1.9.5-4 ii libminizip11.1-8+deb12u1 ii libnspr4 2:4.35-1 ii
Bug#1071258: linux-image-6.1.0-21-amd64: Mouse, trackpad, keyboard behave inconsistently
On Thursday, 23 May 2024 09:59:52 CEST Eduardo Casais wrote: > 4) Determining whether the bug was introduced by the passage from kernel > 5.10.0 to 6.1.0, or whether it was an error introduced between releases > of image 6.1.0-*. > > Attempted resolution: > > I looked at the image versions available in Synaptic, installed the > oldest one available: linux-image-6.1.0-11-amd64, and restarted the system. > > Result: > > The problem occurs again. I did not try installing other images between > 6.1.10-11 and 6.1.10-21. > > At this stage, I must leave it to you to investigate and suggest further > operations that may help diagnose the problem and ferret out the bug. Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find deb packages for all the versions released to Debian which includes kernels older then 6.1.10-11. With that you can find the latest version that still works and the next version where this bug occurs. signature.asc Description: This is a digitally signed message part.
Bug#1071559: linux-headers-6.8.9-amd64: error creating r8125 module with dkms
Control: reassign -1 r8125-dkms On Tuesday, 21 May 2024 10:41:54 CEST Pierpaolo Toniolo wrote: > Was installing the linux-image-6.8.9-amd64 and it's fellow linux- > headers-6.8.9-headers. > At modules creation with dkms I got an error building module r8125 (package > r8125-dkms) Which is a problem of r8125-dkms, thus reassigning signature.asc Description: This is a digitally signed message part.
Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate
On Monday, 20 May 2024 21:07:49 CEST Salvatore Bonaccorso wrote: > - I did read you cannot trigger with 5.15. If you build 6.1.90 from > upstream without Debian patches I assume you can trigger the issue > likewise? If so could you bisect the changes introducing the issue? If the test with the upstream 6.1.90 version also has this problem, there's another (series of) test(s) worth doing, which could shorten the bisect operation significantly. I got the impression that you have only tried it with version 6.1.90. Have you tried it with earlier versions in the 6.1 series to see if the issue is present there? Via https://snapshot.debian.org/package/linux-signed-arm64/ you can find earlier versions from the 6.1 series already compiled and packaged. To take version 6.1.52 as (random) example: - click on the ``6.1.52+1`` link - In the ``Binary packages`` list, click on the linux-image-6.1.0-X-arm64 link, where 'X' is 12 in this case - Click the ``linux-image-6.1.0-12-arm64_6.1.52-1_arm64.deb`` link to download the deb file which you can then install as root or with sudo by executing ``apt install ./linux-image-_arm64.deb`` If the problem does NOT occur with 6.1.52-1, then you try a higher version. Continue that process until you've found the latest version that works and the earliest version where it stopped working. If the problem also occurs with 6.1.52-1, then you try an (even) older version. This is to test whether it was a regression *within* the 6.1 series and if so, to get the narrowest range without having to compile yourself. HTH signature.asc Description: This is a digitally signed message part.
