Bug#993640: Please turn on the SimpleDRM driver in 6.11
Control: retitle -1 Please turn on the SimpleDRM driver in 6.11 Control: found -1 6.11.2-1 Hi, Since 6.11 entered unstable, I've noticed plymouth falling back to the 3 dot text-mode boot splash on some of my devices using amdgpu. The most likely reason was reported in: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/264 The proposed workaround is to use SimpleDRM, however this module isn't built in Debian's kernels. In /boot/config-6.11.2-amd64: # CONFIG_DRM_SIMPLEDRM is not set Would it be possible to include this module? Thanks, -- Mourad DC
Bug#1082906: linux-image-6.11-amd64: ipu6 camera is not working
Control: tag -1 moreinfo On Sat, 28 Sep 2024 03:09:54 + gabriel wrote: > Package: src:linux > Version: 6.11-1~exp1 > > ipu6 mipi camera drivers were not part of previous kernels, now they have > been upstreamed. > After upgrading kernel to 6.11 the ipu6 kernel modules are loaded, however > there are 32 video devices /dev/video0 to /dev/video32 and none of them is > working (gstreamer, vlc, firefox or cheese) Do you have firmware-intel-graphics installed? signature.asc Description: This is a digitally signed message part.
Bug#1078696: [PATCH 3/4] ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]
Thank you for reporting this. I have submitted a patch adding the DMI quirk for this upstream: https://lore.kernel.org/linux-acpi/20240927141606.66826-3-hdego...@redhat.com/
Bug#1082514: liblcms2-dev: Please upload version 2.16 to Unstable
Package: liblcms2-dev Version: 2.14-2+b1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Version 2.16-1 was uploaded to Experimental in the beginning of the year, but it would be great if it was uploaded to Unstable too. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.11-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liblcms2-dev depends on: ii liblcms2-2 2.14-2+b1 liblcms2-dev recommends no packages. liblcms2-dev suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZu7AQAAKCRDXblvOeH7b bgLqAPsFtkfygZSwmW4uF/CCVqBCdWCHdRGQybH/OAzL4u3n5AD/SqKRavmEMEXd Hy9rFhe22T1qoAOETKPIDtW7hiszNQs= =kLHj -END PGP SIGNATURE-
Bug#1082297: gnome-shell: Crashes gdm on startup
On 9/19/24 20:45, Jeremy Bícha wrote: Could you try plugging in a keyboard and see if that avoids the issue? Yes, makes no difference. If you revert to using gjs 1.80.2-1 from Unstable/Testing, does that avoid the issue? Also makes no difference. However, I managed to find a way to workaround and reproduce it: I moved the dconf settings in /var/lib/gdm3 (the Debian-gdm user's home) aside, and restarted gdm. This made it work again. Next, I enabled the OSK in the greeter's accessibility menu. On restart it crashed again. So it seems having the OSK enabled in gsettings/dconf when gdm starts makes it crash. -- M
Bug#1082297: gnome-shell: Crashes gdm on startup
Package: gnome-shell Version: 47.0-1 Severity: grave Justification: renders package unusable Upgrading Gnome-Shell to 47.0 makes GDM crash on boot. I've got almost the exact same set of packages (& versions) installed on two other machines that don't exhibit this issue. Two things are specific for the crashing machine, not sure if it's relevant: * It uses systemd-homed - but that shouldn't come into play I think because it crashes even before I can attempt to log in. * It doesn't have a keyboard, so the OSK usually pops up in GDM. Sep 19 19:42:32 belle systemd[1]: Starting gdm.service - GNOME Display Manager... Sep 19 19:42:32 belle systemd[1]: Started gdm.service - GNOME Display Manager. Sep 19 19:42:32 belle gdm-launch-environment][157876]: pam_systemd_home(gdm-launch-environment:account): New sd-bus connection (system-bus-pam-systemd-home-157876) opened. Sep 19 19:42:32 belle gdm-launch-environment][157876]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm(uid=280) by (uid=0) Sep 19 19:42:32 belle gdm-launch-environment][157876]: pam_systemd(gdm-launch-environment:session): New sd-bus connection (system-bus-pam-systemd-157876) opened. Sep 19 19:42:32 belle systemd-logind[1203]: New session c282 of user Debian-gdm. Sep 19 19:42:32 belle systemd[1]: Started session-c282.scope - Session c282 of User Debian-gdm. Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/ldac Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/aptx_hd Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx_hd Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/aptx Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/opus_g Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/opus_g Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/sbc Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/sbc Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx_ll_1 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx_ll_0 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/faststream Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/faststream_duplex Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/opus_05 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/opus_05 Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSink/opus_05_duplex Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint unregistered: sender=:1.2026 path=/MediaEndpoint/A2DPSource/opus_05_duplex Sep 19 19:42:32 belle wireplumber[7814]: spa.bluez5.midi: org.bluez.GattManager1.RegisterApplication() failed: GDBus.Error:org.bluez.Error.AlreadyExists: Already Exists Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/ldac Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSink/aptx_hd Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/aptx_hd Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSink/aptx Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/aptx Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSink/opus_g Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/opus_g Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSink/sbc Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/sbc Sep 19 19:42:32 belle bluetoothd[93401]: Endpoint registered: sender=:1.2030 path=/MediaEndpoint/A2DPSource/aptx_ll_1 Sep 19 19:42:32 belle blue
Bug#1038882: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)
On Sat, Sep 14, 2024, at 09:30, Daniel Gröber wrote: > 3) dhcpcd-base enables IPv6 privacy addressess by default. Please never do this *by silent default* when DHCPv6 is being used for stateful address assignment, privacy addresses are a big issue on non-home networks and even on home networks depending on firewall rules... Although I suppose a relevant note on NEWS.Debian *and* the Release Notes might be enough if.we consider it is desirable for most installs. > 3) Since ifupdown is mainly used in the server/embedded sorts of > enviornments I'm not sure privacy addressing is the right default. > (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217 > addressing). We can assume NM will be in use for most Desktop users so I > believe it's safe in principle to retain the current MAC based SLAAC > address behaviour we used to get from the kernel RA implementation. > Thoughts? Agreed, the less surprises here, the better. -- Henrique de Moraes Holschuh
Bug#508558: Add sloc2html to sloccount package
Hi Andreas,
Please find attached a revised version of 'sloc2html.py'. Some issues were
addressed and it's in full Python 3 now.
Kind regards
E.
On Sat, Sep 7, 2024 at 2:20 PM Andreas Tille wrote:
> Control: tags -1 moreinfo
> Thanks
>
> Hi,
>
> since package sloccount came up in the Bug of the Day[1] we tried to
> salvage this packege[2]. I followed your hint to add sloc2html in
> Git[3]. I've used 2to3 to convert the script to Python3. Unfortunately
> it does not work. If you can fix the script I'd happily add it to the
> package but for the moment I do not see any advantage for our users.
>
> Kind regards
> Andreas.
>
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] https://bugs.debian.org/1078785
> [3]
> https://salsa.debian.org/salvage-team/sloccount/-/tree/master/debian/sloc2html?ref_type=heads
>
> --
> https://fam-tille.de
>
>
--
Elie De Brauwer
#!/usr/bin/env python
"""
Written by Rasmus Toftdahl Olesen
Modified slightly by David A. Wheeler and Elie De Brauwer.
Brought into the year 2024 by Elie De Brauwer
Released under the GNU General Public License v. 2 or higher
"""
import sys
NAME = "sloc2html"
VERSION = "0.0.3"
if len(sys.argv) != 2:
print("Usage:")
print("\t" + sys.argv[0] + " ")
print("\nThe output of sloccount should be with --wide and --multiproject formatting")
sys.exit()
colors = { "python" : "blue",
"ansic" : "yellow",
"perl" : "purple",
"cpp" : "green",
"sh" : "red",
"yacc" : "brown",
"lex" : "silver",
# Feel free to make more specific colors.
"ruby" : "maroon",
"cs" : "gray",
"java" : "navy",
"javascript" : "navy",
"ada" : "olive",
"lisp" : "fuchsia",
"objc" : "purple",
"fortran" : "purple",
"cobol" : "purple",
"pascal" : "purple",
"asm" : "purple",
"csh" : "purple",
"tcl" : "purple",
"exp" : "purple",
"awk" : "purple",
"sed" : "purple",
"makefile" : "purple",
"sql" : "purple",
"php" : "purple",
"modula3" : "purple",
"ml" : "purple",
"haskell" : "purple",
"vhdl" : "purple",
"xml" : "purple"
}
print("")
print("")
print("Counted Source Lines of Code (SLOC)")
print("")
print("")
print("Counted Source Lines of Code")
with open(sys.argv[1], "r", encoding="utf-8") as file:
print("Projects")
line = ""
while line != "SLOC\tDirectory\tSLOC-by-Language (Sorted)\n":
line = file.readline()
print("")
print("LinesProjectLanguage distribution")
line = file.readline()
while line != "\n":
num, project, langs = line.split()
print("" + num + "" + project + "")
print("")
if langs != "(none)":
for lang in langs.split(","):
l, n = lang.split("=")
color = colors[l] if l in colors else "pink"
print("" + l + "=" + n + " (" + str(int(float(n) / float(num) * 100)) + "%)")
print("")
print("")
line = file.readline()
print("")
print("Languages")
while line != "Totals grouped by language (dominant language first):\n":
line = file.readline()
print("")
print("LanguageLines")
line = file.readline()
while line != "\n":
lang, lines, per = line.split()
lang = lang[:-1]
print("" + lang + "" + lines + " " + per + "")
line = file.readline()
print("")
print("Totals")
while line == "\n":
line = file.readline()
print("")
print("Total Physical Lines of Code (SLOC):" + line.split("=")[1].strip() + "")
line = file.readline()
print("Estimated development effort:" + line.split("=")[1].strip() + " person-years (person-months)")
line = file.readline()
line = file.readline()
print("Schedule estimate:" + line.split("=")[1].strip() + " years (months)")
line = file.readline()
line = file.readline()
print("Total estimated cost to develop:" + line.split("=")[1].strip() + "")
print("")
print("Please credit this data as \"generated using 'SLOCCount' by David A. Wheeler.\"\n")
print("")
print("")
Bug#1080278: python-autopage: diff for NMU version 0.4.0-3.1
On Mon, 9 Sep 2024 11:20:39 +0100 Colin Watson wrote: > On Mon, Sep 09, 2024 at 11:15:58AM +0100, Colin Watson wrote: > > I've prepared an NMU for python-autopage (versioned as 0.4.0-3.1) and > > uploaded it to DELAYED/2. Please feel free to tell me if I should delay > > it longer. > > This is also > https://salsa.debian.org/openstack-team/python/python-autopage/-/merge_requests/1 > for your convenience. > > -- > Colin Watson (he/him) [cjwat...@debian.org] > > Thanks Colin, Go ahead. I've been away due to health issues but as soon as your NMU is accepted I plan to update the package.
Bug#1057384: openresolv: Please don't change resolv.conf when it's a symlink
Daniel, Em 09/09/2024 10:28, Daniel Gröber escreveu: My understanding is that in the "Debian" salsa group we're all maintainers, that's the whole point of it :-) Consequently I was going to do this as a "Debian" Team upload. cf. https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group In case this is not what you want you should probably move the repo out of debian/. IMO your understanding is not correct, Salsa is a tool and the documentation you linked talking about collaborative maintenance is valid for use in Salsa itself, and in it, yes, we are all maintainers of all projects published in the Debian group, and you can make commits directly without needing to agree anything with anyone first, however it is a good practice to, at least, give a warning beforehand to the official maintainer of the package (I, personally, prefer the technique of forking and sending a merge request, so the maintainer will be more comfortable evaluating the proposed changes and taking the most appropriate action). And the fact that we are all seen as maintainers of packages published in the Debian group within Salsa, when it comes to packaging the maintainer continues to be whoever is declared as such in the Maintainer field, in debian/control, as defined in the Debian Policy [1] . The Developers Reference [2] further defines best practices for collaborative maintenance. Simply uploading the package, of which you are not the maintainer, and pushing it to Salsa just assuming that this is ok because the package is published in the Debian group on Salsa is, in my opinion, not the correct and recommended procedure . You, being a DD, can upload a package that you are not the maintainer of if necessary, that is what NMU exists for [3]. As I said before, your contribution is very welcome, and you can make a merge request, or you can push it directly to Salsa and I'll upload it without any problems, or I even suggested making an NMU with delay 0. I don't understand your resistance to adopting any of the options I suggested, but going around uploading any package (not NMUing) that has a Maintainer is not ok and, being a DD, I expected you to know that. Best regards. [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#collaborative-maintenance [3] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu -- ⢀⣴⠾⠻⢶⣦ ⣾⠁⢠⠒⠀⣿⡁ Fabio Augusto De Muzio Tobich ⢿⡄⠘⠷⠚⠋⠀ 9730 4066 E5AE FAC2 2683 D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057384: openresolv: Please don't change resolv.conf when it's a symlink
Em 09/09/2024 10:00, Daniel Gröber escreveu: I don't see a reason not to just upload to unstable and push to debian/openresolv. Do you have a reason? Making the fork was just a suggestion, you can do the direct push if you wish, without any problems. As for uploading, you are not the maintainer of the package, so if you want to upload it yourself I ask you to do it as an NMU, you can do it with delay 0, no problem. -- ⢀⣴⠾⠻⢶⣦ ⣾⠁⢠⠒⠀⣿⡁ Fabio Augusto De Muzio Tobich ⢿⡄⠘⠷⠚⠋⠀ 9730 4066 E5AE FAC2 2683 D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057384: openresolv: Please don't change resolv.conf when it's a symlink
Hi Daniel, Sorry for the long delay in responding. Yes, openresolv is in salsa and open to collaborative maintenance. If you decide to contribute, I suggest you fork it in your own userspace, make your changes, and then submit a merge request. Your contributions will be most welcome. Cheers. Em 12/08/2024 20:03, Daniel Gröber escreveu: Hi Fabio, a ping on this. Heads up: I notice openresolv is in the [salsa debian group], so I may decide to upload fixes for this bug and #1057387. [salsa debian group]: https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group --Daniel On Mon, Dec 04, 2023 at 12:30:03PM +0100, Daniel Gröber wrote: On Mon, Dec 04, 2023 at 11:41:57AM +0100, Daniel Gröber wrote: This is similar to how networkmanager and systemd-resolvd handle ownership conflicts and following this protocol will ensure only one (or none in my case :) managment system will try to change resolv.conf. Additional datapoint the old resolvconf package also follows this protocol. It prints a warning and doesn't touch resolv.conf: # resolvconf -u /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf It does however have logic in it's postinst to overwrite /etc/resolv.conf with it's symlink on installation. --Daniel -- ⢀⣴⠾⠻⢶⣦ ⣾⠁⢠⠒⠀⣿⡁ Fabio Augusto De Muzio Tobich ⢿⡄⠘⠷⠚⠋⠀ 9730 4066 E5AE FAC2 2683 D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080303: wlr-randr: New upstream release (0.4.1)
On Mon Sep 2, 2024 at 1:55 PM CEST, Guido Günther wrote: > On Sun, Sep 01, 2024 at 08:15:36PM +0200, Diederik de Haas via > Debian-on-mobile-maintainers wrote: > > Package: wlr-randr > > > > Upstreamed release version 0.4.1 some time ago ... > > > > I made an attempt at packaging that and you can find it here: > > https://salsa.debian.org/diederik/wlr-randr/-/tree/debian/experimental > > ... > > But hopefully my branch still contains something useful. > > Feel free to grab what is useful and ignore what isn't :-) > > I could cherry pick some things, thanks! I opted to wait for the manpage > to tickle in with the next upstream version. Great and thanks for uploading the new version; much appreciated :-) Cheers, Diederik signature.asc Description: PGP signature
Bug#1080303: wlr-randr: New upstream release (0.4.1)
Package: wlr-randr Version: 0.3.0-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! Upstreamed release version 0.4.1 some time ago and it would be great to have that in Debian. I made an attempt at packaging that and you can find it here: https://salsa.debian.org/diederik/wlr-randr/-/tree/debian/experimental I didn't turn it into a MR for the following reasons: 1. I'd need to make 3 MRs for 3 different branches (AFAIK) 2. I thought the `upstream/0.4.1` tag would be signed with my key, but maybe you'd want that to be from a maintainer. But it appears that tag hasn't been signed at all. 3. I first copied the `gbp.conf` from the `eg25-manager` project, but adapted it to this projects branch names. I don't know if you'd want to change the branch names and thereby make the `gbp.conf` files identical to each other. But hopefully my branch still contains something useful. Feel free to grab what is useful and ignore what isn't :-) Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wlr-randr depends on: ii libc6 2.40-2 ii libwayland-client0 1.23.0-1 wlr-randr recommends no packages. wlr-randr suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZtSvQQAKCRDXblvOeH7b blfoAP4gQzlJqR7Jw/uxyacanUMKUeNzzzi9MKtaRUc4uag5pAEA9tnLxnPUQw0b /XfzJgv7IJCofjw813atTkFllugYJw8= =Ouss -END PGP SIGNATURE-
Bug#1080072: fixed in wvkbd 0.15-1)
On Sun Sep 1, 2024 at 14:39 CEST, Debian Bug Tracking System wrote: > Source: wvkbd > Architecture: source > Version: 0.15-1 > Changed-By: Jochen Sprickerhof > Closes: 1080072 > Changes: > wvkbd (0.15-1) unstable; urgency=3Dmedium > . >* New upstream release (Closes: #1080072) >* Rediff patches >* Bump policy version (no changes) Awesome, thanks! Also for renaming the branch :-) signature.asc Description: PGP signature
Bug#1080072: wvkbd: New upstream release (0.15)
Package: wvkbd Version: 0.14.3-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Upstream has a new upstream version available, 0.15, and I'd like it a lot of that could be packaged for Debian. Could you possibly also rename your 'master' branch to 'upstream/latest' so that it's compatible with DEP-14? AFAICT it contains the upstream source, not the Debian packaging source which is in the already DEP-14 compatible 'debian/sid' branch. Cheers, Diederik Link: https://dep-team.pages.debian.net/deps/dep14/ - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wvkbd depends on: ii libc62.40-2 ii libcairo21.18.0-3+b1 ii libpango-1.0-0 1.54.0+ds-2 ii libpangocairo-1.0-0 1.54.0+ds-2 ii libwayland-client0 1.23.0-1 wvkbd recommends no packages. wvkbd suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZtGPSQAKCRDXblvOeH7b bgnVAP4oBG4+yCRFRqdllAC5ql0+TE5Nc1gkohr6kjgKadZ4QgD/YBpeozqJTWwI vpbuu32S3XbVj6XLSf5kDzEOMUSzdw0= =mMbi -END PGP SIGNATURE-
Bug#1080008: wlroots: Please review the B-Ds for wlroots 0.18
Source: wlroots
Version: 0.18.0-2
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Triggered by a comment from 'emersion' [1] (upstream maintainer for both
sway and wlroots) I started looking at wlroots 0.18 B-Ds.
Directly related to that, AFAICT wlroots needs a B-D on `liblcms2-dev`
to have color management support (in sway, but possibly all wlroot based
compositors).
I started to work on a patch, but by now I'm (too) confused, so I
figured I'd make it into a wishlist bug instead.
Some of the things I found:
1. Some B-Ds have different version requirements from the wlroots source
package compared to the Depends of the `libwlroots-0.18-dev` package.
This seems illogical to me, but could be intentional and I just didn't
find the reason behind it (possibly PEBKAC).
2. I (initially) thought that it would also need a B-D on `libudev`,
but while writing this bug I found that it's listed as a (B-)D for
*sway*, when wlroots has the libinput_backend feature, which is or
should be the case for the Debian package.
3. While looking through the upstream commits and various `meson.build`
files, I noticed that a lot of features have been made optional. Which
in turn IIUC means that some features that were available in f.e.
wlroots 0.17 are no longer available because a/some dependencies are not
available. Or in my opinion worse: they could be accidentally available.
4. Related to 3. I think that more features need to be explicitly
enabled. In `debian/rules` I saw that the 'drm', 'libinput' and 'x11'
backends are enabled, but maybe that should be extended?
It seems that it is unlikely that the wlroots build fails, but it could
be that it succeeds while it actually does NOT have certain features
that you actually want(ed) to have? Having a build failure in this case
seems preferable *to me*.
But while working on this I came to the conclusion that I need to learn
more about the meson build system to *fully* understand it.
And having an 'x11' backend while there's also an xwayland feature is
confusing too, so I concluded I'd better leave it up to the maintainers
of the Debian packages.
I will include my WIP patch in case it helps, but won't add the 'patch'
tag to this bug.
Cheers,
Diederik
[1] https://github.com/swaywm/sway/pull/7681#issuecomment-2308926702
- -- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZtBmnQAKCRDXblvOeH7b
bgZQAQCK7mP0m7ZtGrn7uaEFyMtQtElqLLVLqIxXdPRSVco89QEAk5LbdVV3qZVT
lplNL5vm+T3/iRg396h5dW5/83CmmwA=
=6SZw
-END PGP SIGNATURE-
>From 79b06c8ac9c8c0f983528e802cbe10ede153ade7 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Wed, 28 Aug 2024 16:36:31 +0200
Subject: [PATCH] d/control: Update Build Dependencies
>From ``meson.build``:
8bbe8624dfdb ("build: bump pixman version")
Upped the minimal required version of libpixman to version 0.42.0.
Note that this commit was already part of wlroots 0.17.
>From ``backend/drm/meson.build``:
22d9df2af483 ("backend/drm: send output layer feedback events")
Upped the minimal required version of libliftoff to 0.4.0, not 0.4.1.
The right version was set in libwlroots-0.18-dev binary package.
6e6c4408d36d ("backend/drm: add support for libliftoff v0.5.0")
OTOH prepared for version 0.5.0, but doesn't require it (yet).
0a79bc28c7eb ("build: require libinput v1.19")
Upped the minimal required version of libinput to 1.19.
Note that that version is available in Stable, but not older versions.
56c842fcde8a ("d/control: Drop version superfluous information")
Dropped the version requirement (of 1.9.0) because "We have recent
enough versions even in stable.", but even o-o-s has 1.12, so I do
consider this different enough to bring back the version requirement.
>From ``render/meson.build``:
895e3d18b903 ("render/color: introduce wlr_color_transform")
Added color management support to wlroots, but only if liblcms2-dev is
available. This can be used by sway if wlroots has this functionality.
Fixes: 89f88ab37a7f ("d/control: Update build-deps for new upstream version")
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/8bbe8624dfdb4fbf120aee3dd6f0f8d3bf7e
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/22d9df2af483bb862c24bcb973e8ab3475759ebe
Link:
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/6e6c4408d36ddad705458ca4b2e301192f7963fd
Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'
Control: tag -1 -patch -upstream -fixed-upstream Control: notforwarded -1 On 26 Aug 2024 17:22:19 +0200 Diederik de Haas wrote: > Control: tag -1 upstream fixed-upstream patch > Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 Oeps, my CC-ing this bug also modified the metadata ... incorrectly. Should now be fixed again. signature.asc Description: This is a digitally signed message part.
Bug#1061616: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'
Control: tag -1 upstream fixed-upstream patch Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 On 12 Jul 2024 13:38:30 +0900 Mike Hommey wrote: > Source: pixman > Version: 0.42.2-1 > Severity: serious > > The package fails to build on armhf on current sid/testing with: > > ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction > -- `bne 01f' > ../../pixman/pixman-arm-simd-asm.h:869: Info: macro invoked from here > ... > See https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 and bug > 1073870. https://gitlab.freedesktop.org/pixman/pixman/-/commit/865e6ce00bb79a6b925ed4c2c436e1533e4472aa is the commit where upstream fixed this bug and for your convenience attached. BUT this patch won't apply on top of 0.42.2, but it would apply on top version 0.43.4 which bug 1061616 requests for. So it would be great if both bugs can be fixed in 1 go. Cheers, Diederik>From 865e6ce00bb79a6b925ed4c2c436e1533e4472aa Mon Sep 17 00:00:00 2001 From: Mike Hommey Date: Fri, 12 Jul 2024 11:11:17 -0400 Subject: [PATCH] pixman: Adjust arm assembly for binutils change A change in the latest version of binutils broke building pixman for arm. The binutils change: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b Closes: https://gitlab.freedesktop.org/pixman/pixman/-/issues/96 --- pixman/pixman-arm-simd-asm.S | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/pixman/pixman-arm-simd-asm.S b/pixman/pixman-arm-simd-asm.S index 34d38f1f..3dfe723a 100644 --- a/pixman/pixman-arm-simd-asm.S +++ b/pixman/pixman-arm-simd-asm.S @@ -820,13 +820,13 @@ generate_composite_function \ .macro over_white___ca_1pixel_tail mvn TMP0, WK1 teq WK1, WK1, asr #32 -bne 01f -bcc 03f +bne 1f +bcc 3f mov WK3, WK1 -b 02f -01: over_white___ca_combine WK1, WK3 -02: pixst , 4, 3, DST -03: +b 2f +1: over_white___ca_combine WK1, WK3 +2: pixst , 4, 3, DST +3: .endm .macro over_white___ca_2pixels_head @@ -837,21 +837,21 @@ generate_composite_function \ pixld , 8, 3, DST mvn TMP0, WK1 teq WK1, WK1, asr #32 -bne 01f +bne 1f movcs WK3, WK1 -bcs 02f +bcs 2f teq WK2, #0 -beq 05f -b 02f -01: over_white___ca_combine WK1, WK3 -02: mvn TMP0, WK2 +beq 5f +b 2f +1: over_white___ca_combine WK1, WK3 +2: mvn TMP0, WK2 teq WK2, WK2, asr #32 -bne 03f +bne 3f movcs WK4, WK2 -b 04f -03: over_white___ca_combine WK2, WK4 -04: pixst , 8, 3, DST -05: +b 4f +3: over_white___ca_combine WK2, WK4 +4: pixst , 8, 3, DST +5: .endm .macro over_white___ca_process_head cond, numbytes, firstreg, unaligned_src, unaligned_mask, preload @@ -1067,9 +1067,9 @@ generate_composite_function \ .if \offset != 0 ldrbORIG_W, [SRC, #\offset] .endif -beq 01f +beq 1f teq STRIDE_M, #0xFF -beq 02f +beq 2f .endif uxtb16 SCRATCH, \d /* rb_dest */ uxtb16 \d, \d, ror #8 /* ag_dest */ @@ -1079,13 +1079,13 @@ generate_composite_function \ uxtab16 \d, \d, \d, ror #8 mov SCRATCH, SCRATCH, ror #8 sel \d, SCRATCH, \d -b 02f +b 2f .if \offset == 0 48: /* Last mov d,#0 of the set - used as part of shortcut for * source values all 0 */ .endif -01: mov \d, #0 -02: +1: mov \d, #0 +2: .endm .macro in_reverse___tail numbytes, reg1, reg2, reg3, reg4 -- GitLab signature.asc Description: This is a digitally signed message part.
Bug#1067709: FTBFS in armel/armhf: some symbols disappeared
On Tue, 26 Mar 2024 01:06:34 +0200 Peter Pentchev wrote: > Control: tag -1 + confirmed > > On Tue, Mar 26, 2024 at 01:29:08AM +0500, Andrey Rakhmatullin wrote: > > Source: dante > > Version: 1.4.3+dfsg-1 > > Severity: serious > > Tags: ftbfs > > > > https://buildd.debian.org/status/fetch.php?pkg=dante&arch=armhf&ver=1.4.3+dfsg-1&stamp=1710761774&raw=0 > > Thanks for reporting this. I noticed it as soon as I uploaded this > version of dante, and I started looking into it; it is, at least partly, > fallout from the new "implicit function declarations are errors" GCC > option setting. FTR, I believe this is a good idea, no complaints here. > However, it turns out to be a bit more complicated than sprinkling > a couple of #include directives here and there; I will hopefully be > able to upload a fixed version within the next couple of days. Friendly ping? https://release.debian.org/transitions/html/glibc-2.40.html seems to indicate it's a problem for glibc 2.40 which has just been uploaded to Unstable. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1079567: systemd: Should not raise errors when not (all) BPF features are available
Package: systemd Version: 256.5-1 Severity: normal X-Debbugs-Cc: debian-ker...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I build a custom (arm64) kernel based on Debian's config and in that I disabled debug info, which in turn disabled ``CONFIG_DEBUG_INFO_BTF``. Build was successful and I tried it out on my Rock64 and what I always do when testing kernels is check dmesg for errors/warnings etc: ```sh root@rock64-test:~# dmesg --level 0,1,2 root@rock64-test:~# dmesg --level 0,1,2,3 [9.807992] rockchip-pm-domain ff10.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220 [ 16.014046] systemd[1]: bpf-restrict-fs: Failed to load BPF object: No such process ``` Former is known (and in the works of being fixed), the latter is new. Looking for that error message led me to upstream issue 32968 [1] which led me to the upstream README with the following: ``` Required for RestrictFileSystems= in service units: CONFIG_BPF CONFIG_BPF_SYSCALL CONFIG_BPF_LSM CONFIG_DEBUG_INFO_BTF CONFIG_LSM="...,bpf" or kernel booted with lsm="...,bpf". ``` I (actually) do have most of those, but not CONFIG_DEBUG_INFO_BTF and that appears to be why systemd throws an error. Looking further I found another issue [2] which says that using ``lockdown=confidentiality`` will also be problematic. I think/assume it's great that systemd would use kernel features like BPF *if* they're available. But if not, it should not throw an ERROR. An informational message is fine and possibly a warning* if it's really important. But it should detect so at *runtime* and not assume what happens to be enabled in the (Debian) kernel at a certain point in time. I did grep my system for ``bpf-restrict-fs`` to see if I could disable that feature, but it only found ``libsystemd-core-256.so``. Cheers, Diederik *) Preferably not as I'm also trying to fix those as much as possible [1] https://github.com/systemd/systemd/issues/32968 [2] https://github.com/anthraxx/linux-hardened/issues/93#issuecomment-1974260571 - -- Package-specific info: - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii libacl12.3.2-2 ii libapparmor1 3.1.7-1+b1 ii libaudit1 1:4.0.1-1 ii libblkid1 2.40.2-7 ii libc6 2.39-7 ii libcap21:2.66-5 ii libmount1 2.40.2-7 ii libpam0g 1.5.3-7 ii libseccomp22.5.5-1+b1 ii libselinux13.7-1+b1 ii libssl3t64 3.3.1-7 ii libsystemd-shared 256.5-1 ii libsystemd0256.5-1 ii mount 2.40.2-7 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii libzstd11.5.6+dfsg-1 pn linux-sysctl-defaults ii ntpsec [time-daemon]1.2.3+dfsg1-3 pn systemd-cryptsetup Versions of packages systemd suggests: ii libcryptsetup12 2:2.7.4-1 ii libgcrypt20 1.11.0-6 ii libidn2-0 2.3.7-2 ii liblz4-11.9.4-3 ii liblzma55.6.2-2 pn libtss2-rc0t64 ii libtss2-tcti-device0t64 [libtss2-tcti-device0] 4.1.3-1 ii polkitd 125-2 pn systemd-boot ii systemd-container 256.5-1 pn systemd-homed pn systemd-repart pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.10-4+b1 pn dracut ii initramfs-tools0.145 pn libnss-systemd ii libpam-systemd 256.5-1 ii udev 256.5-1 - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZsoI3QAKCRDXblvOeH7b bpA2AQDrLI0m5V/IkTepJVF4NyIlRbnFEjdvRIqjAyWliyCBJAEAorba1BU9D3p4 u9nOA3NGJyY1qPzQbS2Guc1niBbImAg= =m50o -END PGP SIGNATURE-
Bug#1079543: bookworm-pu: package amd64-microcode/3.20240820.1~deb12u1
Uploaded! Thank you! On Sat, Aug 24, 2024, at 10:01, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2024-08-24 at 09:51 -0300, Henrique de Moraes Holschuh wrote: >> I would like to bring the *firmware* update level for AMD processors >> in Bullseye and Bookworm to match what we have in Sid and Trixie. >> This is the bug report for Bookworm, a separate one will be filled >> for Bullseye. >> >> The update is a security update for AMD-SEV (AMD-SB-3003). It does >> not change the processor microcode. > > Please go ahead. > > Regards, > > Adam -- Henrique de Moraes Holschuh
Bug#1079544: bullseye-pu: package amd64-microcode/3.20240820.1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] I would like to bring the *firmware* update level for AMD processors in Bullseye and Bookworm to match what we have in Sid and Trixie. This is the bug report for Bullseye, a separate one will be filled for Bookworm. The update is a security update for AMD-SEV (AMD-SB-3003). It does not change the processor microcode. [ Impact ] These updates fix security issues on AMD SEV. [ Tests ] The package was tested, but AMD-SEV was not specifically tested. I could not find any reports of AMD-SEV issues due to this firmware update though. This update only changed a few docs and the binary blob files, so it is as safe as what is already accepted for bullseye and bookworm. [ Risks ] AMD-SEV changes cannot cause boot regressions, but it could cause SEV functionality regressions. I am not aware of any regressions related to this SEV firmware update. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] * Documentation was updated with upstream information * Binary microcode blobs were updated with new upstream binary blobs. [ Extra Information ] Diff was generated from the git tree, in order to avoid excessive noise due to the changes to the binary blobs. diffstat: README | 20 amd/amd_sev_fam17h_model3xh.sbin |binary amd/amd_sev_fam19h_model0xh.sbin |binary amd/amd_sev_fam19h_model1xh.sbin |binary amd/amd_sev_fam19h_modelaxh.sbin |binary debian/changelog | 30 ++ 6 files changed, 50 insertions(+) -- Henrique Holschuh diff --git a/README b/README index 63c0879..67a4e0e 100644 --- a/README +++ b/README @@ -11,6 +11,26 @@ amdtee/ currently includes firmware for the amd_pmf driver. latest commits in this release: +commit ace84e6edc27bcba8e44ba8588e93a4c74a4fba1 +Author: John Allen +Date: Tue Aug 20 18:26:55 2024 + + +linux-firmware: Update AMD SEV firmware + +Update AMD SEV firmware to version 0.24 build 20 for AMD family 17h processors +with models in the range 30h to 3fh. + +Update AMD SEV firmware to version 1.55 build 21 for AMD family 19h processors +with models in the range 00h to 0fh. + +Update AMD SEV firmware to version 1.55 build 37 for AMD family 19h processors +with models in the range 10h to 1fh. + +Add AMD SEV firmware version 1.55 build 37 for AMD family 19h processors with +models in the range a0h to afh. + +Signed-off-by: John Allen + commit 091bd5adf19c7ab01214c64689952acb4833b21d Author: John Allen Date: Wed Jul 10 14:58:02 2024 + diff --git a/amd/amd_sev_fam17h_model3xh.sbin b/amd/amd_sev_fam17h_model3xh.sbin index ea49929..a1a59d4 100644 Binary files a/amd/amd_sev_fam17h_model3xh.sbin and b/amd/amd_sev_fam17h_model3xh.sbin differ diff --git a/amd/amd_sev_fam19h_model0xh.sbin b/amd/amd_sev_fam19h_model0xh.sbin index 9cde6ad..0e21813 100644 Binary files a/amd/amd_sev_fam19h_model0xh.sbin and b/amd/amd_sev_fam19h_model0xh.sbin differ diff --git a/amd/amd_sev_fam19h_model1xh.sbin b/amd/amd_sev_fam19h_model1xh.sbin index 529dcb5..5855e82 100644 Binary files a/amd/amd_sev_fam19h_model1xh.sbin and b/amd/amd_sev_fam19h_model1xh.sbin differ diff --git a/amd/amd_sev_fam19h_modelaxh.sbin b/amd/amd_sev_fam19h_modelaxh.sbin new file mode 100644 index 000..5855e82 Binary files /dev/null and b/amd/amd_sev_fam19h_modelaxh.sbin differ diff --git a/debian/changelog b/debian/changelog index 3b97a91..dc29a0e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,33 @@ +amd64-microcode (3.20240820.1~deb11u1) bullseye; urgency=medium + + * Rebuild for bullseye + * Revert merged-usr changes from unstable + * Revert move to non-free-firmware + + -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:28:39 -0300 + +amd64-microcode (3.20240820.1) unstable; urgency=high + + * Update package data from linux-firmware 20240820 +* New AMD-SEV firmware from AMD upstream (20240820) + + Updated SEV firmware: +Family 17h models 30h-3fh: version 0.24 build 20 +Family 19h models 00h-0fh: version 1.55 build 21 +Family 19h models 10h-1fh: version 1.55 build 37 + + New SEV firmware: +Family 19h models a0h-afh: version 1.55 build 37 + * SECURITY UPDATE (AMD-SB-3003): +* Mitigates CVE-2023-20584: IOMMU improperly handles certain special + address ranges with invalid device table entries (DTEs), which may allow + an attacker with privileges and a compromised Hypervisor to induce DTE + faults to bypass RMP checks in SEV-SNP, potentially leading to a loss of + guest integrity. +* Mitigates CVE-2023-31356: Incomplete system memory cleanup in SEV + firmware could
Bug#1079543: bookworm-pu: package amd64-microcode/3.20240820.1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu [ Reason ] I would like to bring the *firmware* update level for AMD processors in Bullseye and Bookworm to match what we have in Sid and Trixie. This is the bug report for Bookworm, a separate one will be filled for Bullseye. The update is a security update for AMD-SEV (AMD-SB-3003). It does not change the processor microcode. [ Impact ] These updates fix security issues on AMD SEV. [ Tests ] The package was tested, but AMD-SEV was not specifically tested. I could not find any reports of AMD-SEV issues due to this firmware update though. This update only changed a few docs and the binary blob files, so it is as safe as what is already accepted for bullseye and bookworm. [ Risks ] AMD-SEV changes cannot cause boot regressions, but it could cause SEV functionality regressions. I am not aware of any regressions related to this SEV firmware update. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] * Documentation was updated with upstream information * Binary microcode blobs were updated with new upstream binary blobs. [ Extra Information ] Diff was generated from the git tree, in order to avoid excessive noise due to the changes to the binary blobs. diffstat: README | 20 amd/amd_sev_fam17h_model3xh.sbin |binary amd/amd_sev_fam19h_model0xh.sbin |binary amd/amd_sev_fam19h_model1xh.sbin |binary amd/amd_sev_fam19h_modelaxh.sbin |binary debian/changelog | 28 6 files changed, 48 insertions(+) -- Henrique Holschuh diff --git a/README b/README index 63c0879..67a4e0e 100644 --- a/README +++ b/README @@ -11,6 +11,26 @@ amdtee/ currently includes firmware for the amd_pmf driver. latest commits in this release: +commit ace84e6edc27bcba8e44ba8588e93a4c74a4fba1 +Author: John Allen +Date: Tue Aug 20 18:26:55 2024 + + +linux-firmware: Update AMD SEV firmware + +Update AMD SEV firmware to version 0.24 build 20 for AMD family 17h processors +with models in the range 30h to 3fh. + +Update AMD SEV firmware to version 1.55 build 21 for AMD family 19h processors +with models in the range 00h to 0fh. + +Update AMD SEV firmware to version 1.55 build 37 for AMD family 19h processors +with models in the range 10h to 1fh. + +Add AMD SEV firmware version 1.55 build 37 for AMD family 19h processors with +models in the range a0h to afh. + +Signed-off-by: John Allen + commit 091bd5adf19c7ab01214c64689952acb4833b21d Author: John Allen Date: Wed Jul 10 14:58:02 2024 + diff --git a/amd/amd_sev_fam17h_model3xh.sbin b/amd/amd_sev_fam17h_model3xh.sbin index ea49929..a1a59d4 100644 Binary files a/amd/amd_sev_fam17h_model3xh.sbin and b/amd/amd_sev_fam17h_model3xh.sbin differ diff --git a/amd/amd_sev_fam19h_model0xh.sbin b/amd/amd_sev_fam19h_model0xh.sbin index 9cde6ad..0e21813 100644 Binary files a/amd/amd_sev_fam19h_model0xh.sbin and b/amd/amd_sev_fam19h_model0xh.sbin differ diff --git a/amd/amd_sev_fam19h_model1xh.sbin b/amd/amd_sev_fam19h_model1xh.sbin index 529dcb5..5855e82 100644 Binary files a/amd/amd_sev_fam19h_model1xh.sbin and b/amd/amd_sev_fam19h_model1xh.sbin differ diff --git a/amd/amd_sev_fam19h_modelaxh.sbin b/amd/amd_sev_fam19h_modelaxh.sbin new file mode 100644 index 000..5855e82 Binary files /dev/null and b/amd/amd_sev_fam19h_modelaxh.sbin differ diff --git a/debian/changelog b/debian/changelog index 72b76b1..26983aa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,31 @@ +amd64-microcode (3.20240820.1~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm (revert merged-usr changes from unstable) + + -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:24:14 -0300 + +amd64-microcode (3.20240820.1) unstable; urgency=high + + * Update package data from linux-firmware 20240820 +* New AMD-SEV firmware from AMD upstream (20240820) + + Updated SEV firmware: +Family 17h models 30h-3fh: version 0.24 build 20 +Family 19h models 00h-0fh: version 1.55 build 21 +Family 19h models 10h-1fh: version 1.55 build 37 + + New SEV firmware: +Family 19h models a0h-afh: version 1.55 build 37 + * SECURITY UPDATE (AMD-SB-3003): +* Mitigates CVE-2023-20584: IOMMU improperly handles certain special + address ranges with invalid device table entries (DTEs), which may allow + an attacker with privileges and a compromised Hypervisor to induce DTE + faults to bypass RMP checks in SEV-SNP, potentially leading to a loss of + guest integrity. +* Mitigates CVE-2023-31356: Incomplete system memory cleanup in SEV + firmware could allow a privileged attacker to corrupt guest
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
On 07 Jun 2024 15:44:14 +0200 Diederik de Haas wrote: > On Friday, 1 September 2023 12:02:30 CEST Diederik de Haas wrote: > > > > AFAICT, TF-A for *rk356x* is really close to being mergeable? > > > I'm not entirely sure about that. In any case, for the rk3588 in U-Boot > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 for > rk3588 > now has a Merge Conflict (due to merging the rk3568 stuff?), but that has > seen > activity in the last month too, so hopefully that'll progress (soon) too. Support for rk3588 has been merged upstream ... yesterday \o/ signature.asc Description: This is a digitally signed message part.
Bug#1071959: arm-trusted-firmware: New upstream versions (lts-v2.10.4 and v2.11)
On 26 May 2024 16:23:07 +0200 Diederik de Haas wrote: > Source: arm-trusted-firmware > Version: 2.10.0+dfsg-1 > > Upstream recently released two new versions: > - - lts-v2.10.4 > - - v2.11 > > If you want to stay on a LTS release, then updating to 2.10.4 gives > quite a number of workarounds for errata. > > If you want to switch to the latest upstream release, then you can drop > my patch for rk3328 as that's included upstream. That patch is actually (also) part of lts-v2.10.1 signature.asc Description: This is a digitally signed message part.
Bug#1079175: python3-pkg-resources: pkg_resources cannot be imported: No module named 'packaging'
On Tue Aug 20, 2024 at 11:45 PM CEST, Cyril Brulebois wrote:
> Emanuele Rocca (2024-08-20):
> > Package: python3-pkg-resources
> > Version: 72.2.0-1
> > Severity: serious
> >
> > Importing pkg_resources fails with the following error:
> >
> > (sid-amd64-sbuild)ema@ariel:~$ python3
> > Python 3.12.5 (main, Aug 7 2024, 13:49:14) [GCC 14.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import pkg_resources
> > Traceback (most recent call last):
> > File "", line 1, in
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 95, in
> > import packaging.specifiers
> > ModuleNotFoundError: No module named 'packaging'
> >
> > This is a regression in version 72.2.0-1, whereas 70.3.0-2 worked fine.
> >
> > For an example of d-i build failure caused by this problem, see:
> > https://salsa.debian.org/installer-team/debian-installer/-/jobs/6155545
> >
> > It seems that installing python3-packaging, python3-jaraco.text, and
> > python3-platformdirs fixes it.
>
> I couldn't replicate the FTBFS within a devel sid chroot that has tons of
> extra packages, including python3-packaging, and python3-platformdirs, but
> not python3-jaraco.text.
I'm not sure if this is related or will be helpful, but I just got an
error related to 'jaraco' in a CI pipeline in reprotest, while the build
itself succeeded:
```sh
$ su salsa-ci -c "timeout ${SALSA_CI_BUILD_TIMEOUT_ARGS} reprotest \
--min-cpus $(nproc --all) \
--store-dir ${WORKING_DIR}/reprotest \
--verbosity=2 \
--vary=-time \
--vary=user_group.available+=salsa-ci,domain_host.use_sudo=1 \
${SALSA_CI_DPKG_BUILDPACKAGE_ARGS:+--append-build-command=${SALSA_CI_DPKG_BUILDPACKAGE_ARGS}}
\
${SALSA_CI_REPROTEST_ARGS} \
${WORKING_DIR}/*.dsc -- null" |& OUTPUT_FILENAME=reprotest.log filter-output
Traceback (most recent call last):
File "/usr/bin/reprotest", line 33, in
sys.exit(load_entry_point('reprotest==0.7.27', 'console_scripts',
'reprotest')())
^
File "/usr/bin/reprotest", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 205, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1387, in _gcd_import
File "", line 1360, in _find_and_load
File "", line 1331, in _find_and_load_unlocked
File "", line 935, in _load_unlocked
File "", line 995, in exec_module
File "", line 488, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 20, in
import pkg_resources
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 96, in
from jaraco.text import (
ModuleNotFoundError: No module named 'jaraco'
```
src: https://salsa.debian.org/diederik/simplescreenrecorder/-/jobs/6158157
HTH,
Diederik
signature.asc
Description: PGP signature
Bug#1006027: jsjac: FTBFS: java.io.FileNotFoundException: jsjac.uncompressed.js (No such file or directory)
Source: jsjac Followup-For: Bug #1006027 Control: tags -1 ftbfs I tested this with sbuild and the package builds just fine. -- 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
Bug#1006027: jsjac: FTBFS: java.io.FileNotFoundException: jsjac.uncompressed.js (No such file or directory)
Source: jsjac Followup-For: Bug #1006027 Control: tags -1 ftbfs It does work on my current sid installation. I will check on a brand new chroot. -- 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
Bug#1079140: bookworm-pu: package intel-microcode/3.20240813.1~deb12u1
On Tue, Aug 20, 2024, at 13:28, Adam D. Barratt wrote: > Control: tags -1 + confirmed > Please go ahead. Uploaded, Thank you! > I was going to ask if we were affected by the issue mentioned in > https://www.openwall.com/lists/oss-security/2024/08/16/3 , but then I > read the upstream issue and saw you had already commented there. :-) Yeah, I was a bit late and that helped us this time :-) -- Henrique de Moraes Holschuh
Bug#1079141: bullseye-pu: package intel-microcode/3.20240813.1~deb11u1
On Tue, Aug 20, 2024, at 13:28, Adam D. Barratt wrote: > Control: tags -1 + confirmed > Please go ahead. Uploaded, thank you! -- Henrique de Moraes Holschuh
Bug#1079035: kmod: latest upgrade break system startup
On Tue Aug 20, 2024 at 5:55 PM CEST, Antonio wrote: > I tried to install the new version of kmod 33+20240816-2 but it seems to > remove essential packages: > > $ sudo apt install kmod > ... > > Upgrading: > kmod libkmod-dev libkmod2 > > REMOVING: > cryptsetup-initramfs initramfs-tools yubikey-luks > dracut-install initramfs-tools-core > > Summary: > Upgrading: 3, Installing: 0, Removing: 5, Not Upgrading: 0 > Download size: 182 kB > Freed space: 168 MB > > Continue? [S/n] n > Interrotto. Then the new package version is working as intended and you should NOT upgrade kmod until a new version of src:dracut has been uploaded, which would 'fix' the Breaks relation. So you gave the right response: 'n' (No) IIUC: When a new version of src:dracut is uploaded, it will build against the latest kmod version and then the 'undefined symbol' issue will be resolved, which in turn means that the generation of a new initramfs will do the right thing. At least that's the theory ;-) HTH signature.asc Description: PGP signature
Bug#1079141: bullseye-pu: package intel-microcode/3.20240813.1~deb11u1
++ 30 files changed, 244 insertions(+), 15 deletions(-) -- Henrique Holschuh diff --git a/changelog b/changelog index 83989c4..d5e45bc 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,60 @@ +2024-08-13: + * New upstream microcode datafile 20240813 (second release) +- Mitigations for INTEL-SA-01083 (CVE-2024-24853) + Incorrect behavior order in transition between executive monitor and SMI + transfer monitor (STM) in some Intel Processors may allow a privileged + user to potentially enable escalation of privilege via local access. +- Mitigations for INTEL-SA-01118 (CVE-2024-25939) + Mirrored regions with different values in 3rd Generation Intel Xeon + Scalable Processors may allow a privileged user to potentially enable + denial of service via local access. +- Mitigations for INTEL-SA-01100 (CVE-2024-24980) + Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel + Xeon Processors may allow a privileged user to potentially enable + escalation of privilege via local access. +- Mitigations for INTEL-SA-01038 (CVE-2023-42667) + Improper isolation in the Intel Core Ultra Processor stream cache + mechanism may allow an authenticated user to potentially enable + escalation of privilege via local access. +- Mitigations for INTEL-SA-01046 (CVE-2023-49141) + Improper isolation in some Intel® Processors stream cache mechanism may + allow an authenticated user to potentially enable escalation of + privilege via local access. +- Fix for unspecified functional issues on several processor models + * Updated microcodes: +sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936 +sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720 +sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224 +sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032 +sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688 +sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640 +sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328 +sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448 +sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472 +sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496 +sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480 +sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472 +sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496 +sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496 +sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304 +sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280 +sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544 +sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216 + +2024-05-31: + * New upstream microcode datafile 20240531 +- Fix unspecified functional issues on Pentium Silver N/J5xxx, + Celeron N/J4xxx + * Updated Microcodes: +sig 0x000706a1, pf_mask 0x01, 2024-04-19, rev 0x0042, size 76800 + 2024-05-14: * New upstream microcode datafile 20240514 - Mitigations for INTEL-SA-01051 (CVE-2023-45733) diff --git a/debian/changelog b/debian/changelog index 10f37f4..e8240e8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,75 @@ +intel-microcode (3.20240813.1~deb11u1) bullseye; urgency=medium + + * Build for bullseye (no changes from 3.20240813.1) + + -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 22:26:47 -0300 + +intel-microcode (3.20240813.1) unstable; urgency=medium + + * New upstream microcode datafile 20240813 (closes: #1078742) +- Mitigations for INTEL-SA-01083 (CVE-2024-24853) + Incorrect behavior order in transition between executive monitor and SMI + transfer monitor (STM) in some Intel Processors may allow a privileged + user to potentially enable escalation of privilege via local access. +- Mitigations for INTEL-SA-01118 (CVE-2024-25939) + Mirrored regions with different values in 3rd Generation Intel Xeon + Scalable Processors may allow a privileged user to potentially enable + denial of service via local access. +- Mitigations for INTEL-SA-01100 (CVE-2024-24980) + Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel + Xeon Processors may allow a privileged user to potentially enable
Bug#1079140: bookworm-pu: package intel-microcode/3.20240813.1~deb12u1
++ 30 files changed, 244 insertions(+), 15 deletions(-) -- Henrique Holschuh diff --git a/changelog b/changelog index 83989c4..d5e45bc 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,60 @@ +2024-08-13: + * New upstream microcode datafile 20240813 (second release) +- Mitigations for INTEL-SA-01083 (CVE-2024-24853) + Incorrect behavior order in transition between executive monitor and SMI + transfer monitor (STM) in some Intel Processors may allow a privileged + user to potentially enable escalation of privilege via local access. +- Mitigations for INTEL-SA-01118 (CVE-2024-25939) + Mirrored regions with different values in 3rd Generation Intel Xeon + Scalable Processors may allow a privileged user to potentially enable + denial of service via local access. +- Mitigations for INTEL-SA-01100 (CVE-2024-24980) + Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel + Xeon Processors may allow a privileged user to potentially enable + escalation of privilege via local access. +- Mitigations for INTEL-SA-01038 (CVE-2023-42667) + Improper isolation in the Intel Core Ultra Processor stream cache + mechanism may allow an authenticated user to potentially enable + escalation of privilege via local access. +- Mitigations for INTEL-SA-01046 (CVE-2023-49141) + Improper isolation in some Intel® Processors stream cache mechanism may + allow an authenticated user to potentially enable escalation of + privilege via local access. +- Fix for unspecified functional issues on several processor models + * Updated microcodes: +sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936 +sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720 +sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224 +sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032 +sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688 +sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640 +sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328 +sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448 +sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472 +sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496 +sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480 +sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472 +sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496 +sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496 +sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496 +sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304 +sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280 +sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280 +sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544 +sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216 + +2024-05-31: + * New upstream microcode datafile 20240531 +- Fix unspecified functional issues on Pentium Silver N/J5xxx, + Celeron N/J4xxx + * Updated Microcodes: +sig 0x000706a1, pf_mask 0x01, 2024-04-19, rev 0x0042, size 76800 + 2024-05-14: * New upstream microcode datafile 20240514 - Mitigations for INTEL-SA-01051 (CVE-2023-45733) diff --git a/debian/changelog b/debian/changelog index 92b7e2b..5038f31 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,75 @@ +intel-microcode (3.20240813.1~deb12u1) bookworm; urgency=medium + + * Build for bookworm (no changes from 3.20240813.1) + + -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 21:59:40 -0300 + +intel-microcode (3.20240813.1) unstable; urgency=medium + + * New upstream microcode datafile 20240813 (closes: #1078742) +- Mitigations for INTEL-SA-01083 (CVE-2024-24853) + Incorrect behavior order in transition between executive monitor and SMI + transfer monitor (STM) in some Intel Processors may allow a privileged + user to potentially enable escalation of privilege via local access. +- Mitigations for INTEL-SA-01118 (CVE-2024-25939) + Mirrored regions with different values in 3rd Generation Intel Xeon + Scalable Processors may allow a privileged user to potentially enable + denial of service via local access. +- Mitigations for INTEL-SA-01100 (CVE-2024-24980) + Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel + Xeon Processors may allow a privileged user to potentially enable
Bug#1079035: kmod: latest upgrade break system startup
Control: notfound -1 30+20230519-1 On Mon Aug 19, 2024 at 12:59 PM CEST, Antonio wrote: > because i did log report after system restore, so it took that version. > The affected version is 33+20240816-1. Thanks, updating/fixing the found versions then. > Il 19/08/24 12:54, Diederik de Haas ha scritto: > > Package: kmod > > Version: 30+20230519-1 > > Why did you report it against 30+20230519-1? > Because AFAICT 30+20230519-1 and 32+20240611-1 are fine. signature.asc Description: PGP signature
Bug#1079035: kmod: latest upgrade break system startup
On Mon, 19 Aug 2024 09:45:26 +0200 Antonio wrote: > Package: kmod > Version: 30+20230519-1 Why did you report it against 30+20230519-1? Because AFAICT 30+20230519-1 and 32+20240611-1 are fine. signature.asc Description: This is a digitally signed message part.
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
On Mon, 19 Aug 2024 11:41:59 +0200 Christoph Anton Mitterer wrote: > On Mon, 2024-08-19 at 05:12 +0200, Marco d'Itri wrote: > > > With the new version, initramfs generation gives: > > I know, the plan it to rebuild dracut-install. > > Thanks. Then I guess from my side we could also already close the bug. > Your choice :-) Please don't. At least not yet so that people get warned about this bug before they try to reboot into an unbootable system. signature.asc Description: This is a digitally signed message part.
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
Control: affects -1 dracut initramfs-tools On Mon, 19 Aug 2024 16:18:44 +1200 Ash Joubert wrote: > Control: severity -1 critical > > This bug is critical because the dracut failure results in a nonbootable > initrd when followed by "apt-get install -f": > > update-initramfs: Generating /boot/initrd.img-6.10.4-amd64 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 > /usr/lib/dracut/dracut-install: symbol lookup error: > /usr/lib/dracut/dracut-install: undefined symbol: > kmod_module_get_weakdeps, version LIBKMOD_5 I got the above error too, but I did my normal upgrade routine with just ``aptitude safe-upgrade`` Looks like I had a partial KDE (Frameworks) upgrade yesterday, so things look a bit 'funny', so the initial plan was to reboot immediately after today's upgrade ... when I saw the above error. It was only after I saw https://bugs.debian.org/1079031 that I realized how serious it was: ```sh root@bagend:~# ls -lh /boot/initrd.img-* -rw-r--r-- 1 root root 33M Apr 4 2022 /boot/initrd.img-5.10.0-13-amd64 -rw-r--r-- 1 root root 37M Aug 13 01:45 /boot/initrd.img-6.10.3-amd64 -rw-r--r-- 1 root root 9.5M Aug 19 11:10 /boot/initrd.img-6.10.4-amd64 -rw-r--r-- 1 root root 35M Jun 14 2023 /boot/initrd.img-6.1.0-9-amd64 -rw-r--r-- 1 root root 37M Jul 26 00:52 /boot/initrd.img-6.9.10-amd64 ``` So my original plan, reboot immediately, would've failed. But the last dracut upgrade was from 2024-07-25, so that couldn't be it. And that's when I noticed the kmod upgrade and found this bug. ``` aptitude install kmod/testing libkmod2/testing ``` Downgraded kmod and then my ``initrd.img-6.10.4-amd64`` was 37M again, so I'm pretty sure a reboot is NOW safe again. signature.asc Description: This is a digitally signed message part.
Bug#1078781: bookworm-pu: package amd64-microcode/3.20240710.2~deb12u1
Uploaded! Thank you! On Sat, Aug 17, 2024, at 13:46, Adam D. Barratt wrote: > Control: tags -1 + confirmed
Bug#1078782: bullseye-pu: package amd64-microcode/3.20240710.2~deb11u1
Uploaded. Thank you! On Sat, Aug 17, 2024, at 13:47, Adam D. Barratt wrote: > Control: tags -1 + confirmed -- Henrique de Moraes Holschuh
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
On Mon Aug 12, 2024 at 1:43 AM CEST, Henrique de Moraes Holschuh wrote: > > I got the *impression* that some heuristic was used to determine whether the > > microcode update should be applied. > > No. It has a simple heuristic to not increase the initramfs size by adding AMD > microcode updates unless either it is running on an AMD processor when the > amd64-microcode package is installed, OR you configure amd64-microcode to > always add the updates to the initramfs. It is an "all or nothing" thing, > and currently it has absolutely no "processor-model-aware" logic. Good to know, thanks :) And now I could also find that ``debian/initramfs.hook`` has it. The main thing that had me worried was from ``amd64-microcode-blacklist.conf``: > # The microcode module attempts to apply a microcode update when > # it autoloads. This is not always safe, so we block it by default. I had written a couple of paragraphs before I realized the check is for kernels *older* then 4.4. Since then the module is built-in (and not selectable), so that file no longer 'actually' does something. > *Uploading* the microcode update to the processor is handled by the kernel > ... [ interesting description on how it works ] ... It turns out that the problem is not with the CPU, but Asus BIOS/firmware: > It appears that the BIOS has blocked access to the MMIO range for the > CCP so that during initialization, when attempting to read the number of > queues available, 0x is read instead of the actual number of > queues available, which as Jason noted, results in the "broken BIOS" > message. https://lore.kernel.org/linux-crypto/c28836c4-e823-dc36-e753-1a5ee3831...@amd.com/ But it seems Asus isn't interested in fixing it because they consider AM4 an outdated platform and I should just accept that some things won't work... Which I ofc will never accept, so that'll be a RMA :-/ > > I'd like to know whether I'm actually running the latest microcode, but I > > haven't figured out a way how? > > /proc/cpuinfo should report the running microcode version on a recent enough > kernel. It will also log the microcode revision when it does a microcode > update. FWIW: That same version is also reported in ``dmesg``. > There is no facility to check whether what is in your system's > /lib/firmware/amd-ucode is the latest available microcode update that has been > issued by AMD to the linux-firmware project, That sucks as this was the thing I was looking for. But as written above, it seems irrelevant to the original problem I tried so solve. > I hope this information solves any lingering doubts about how it works? It does and was an interesting read, so thanks for that. AFAIC you can close this bug. I'll leave it up to you whether it's useful/worth it to maybe update some comments (like not applicable with kernels > 4.4). Cheers, Diederik signature.asc Description: PGP signature
Bug#1060200: intel-microcode: install files into /usr (DEP17)
> I reopened this bug report (which has become RC in the mean time [1]), > as the latest upload 3.20240813.1 did not incorporate the changes from > the NMU done by Chris in 3.20240531.1+nmu1. Ugh, yeah, I screwed up and forgot to merge the NMU. I had just noticed it from tracker.debian.org alerts that the upload had reintroduced bugs in Trixie, when I got your email on this bug report. I have uploaded 3.20240813.2 a few minutes ago merging in the NMU changes and hopefully fixing the oversight and closing this bug once again. Sorry about that! -- Henrique de Moraes Holschuh
Bug#1078871: some backlog from #1076952 (installer: reserve first 16 MiB space in default recipes for ARM devices?)
Copying my latest response on this subject into this bug (too) ... On Sat Aug 17, 2024 at 1:00 PM CEST, Holger Wansing wrote: > A summary from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug76952#65 > and follow-ups: > > > Pascal Hambourg wrote: > > On 16/08/2024 at 00:27, Diederik de Haas wrote: > > > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > > >> Then I guess a 16 MiB unused partition could be added to relevant > > >> recipes. Now, which are the relevant recipes ? In other words, which > > >> arch/subarch need it ? > > > > > >> recipes-armhf-efi (= recipes-amd64-efi) > > >> recipes-armhf > > >> recipes-arm64-efi (= recipes-amd64-efi) > > >> recipes-arm64 (= recipes-armhf) > > > > > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > > > relevant. > > > > If only Rockchip SoCs need the reserved partition and are detected as a > > specific subarchitecture by archdetect, new specific recipes for this > > subarchitecture could be added. I used Rockchip as an example as I'm familiar with that AND *afaik* they expect the U-Boot stuff to start at the furthest offset. But when U-Boot is used, every platform uses *some* offset and then needs some space/bytes for the U-Boot binary/bits. If that goes above the 2MB mark, then the current recipes overwrite part of whole of the U-Boot binary ... making the system unbootable. So you could special case Rockchip and only use the 16MB offset for the Operating System partitions and data for Rockchip SoCs. Or you could keep the first 16MB free for all ARM SoCs and then it should work for all ARM SoCs as long as they stay below the 16MB 'mark'. Which AFAIK are all of them. > > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > > it sounds 'weird' to add it to a recipe with AMD64 in its name... > > Indeed. If some ARM EFI platforms need the reserved partition, then one > of the recipes-arm*-efi symlinks could be replaced with a directory > containing new specific recipes and the other could be changed to point > to it. And the above principle also applies when EFI is being used with U-Boot as it's specific to U-Boot. signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Fri Aug 16, 2024 at 8:39 AM CEST, Pascal Hambourg wrote: > On 16/08/2024 at 00:27, Diederik de Haas wrote: > > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > >> Then I guess a 16 MiB unused partition could be added to relevant > >> recipes. Now, which are the relevant recipes ? In other words, which > >> arch/subarch need it ? > > > >> recipes-armhf-efi (= recipes-amd64-efi) > >> recipes-armhf > >> recipes-arm64-efi (= recipes-amd64-efi) > >> recipes-arm64 (= recipes-armhf) > > > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > > relevant. > > If only Rockchip SoCs need the reserved partition and are detected as a > specific subarchitecture by archdetect, new specific recipes for this > subarchitecture could be added. I used Rockchip as an example as I'm familiar with that AND *afaik* they expect the U-Boot stuff to start at the furthest offset. But when U-Boot is used, every platform uses *some* offset and then needs some space/bytes for the U-Boot binary/bits. If that goes above the 2MB mark, then the current recipes overwrite part of whole of the U-Boot binary ... making the system unbootable. So you could special case Rockchip and only use the 16MB offset for the Operating System partitions and data for Rockchip SoCs. Or you could keep the first 16MB free for all ARM SoCs and then it should work for all ARM SoCs as long as they stay below the 16MB 'mark'. Which AFAIK are all of them. > > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > > it sounds 'weird' to add it to a recipe with AMD64 in its name... > > Indeed. If some ARM EFI platforms need the reserved partition, then one > of the recipes-arm*-efi symlinks could be replaced with a directory > containing new specific recipes and the other could be changed to point > to it. And the above principle also applies when EFI is being used with U-Boot as it's specific to U-Boot. HTH, Diederik signature.asc Description: PGP signature
Bug#1078803: Please consider updating to 0.18
On Fri, 16 Aug 2024 13:37:48 +0200 Jonathan Carter wrote:
> Source: wlroots
> Version: 0.17.4-1
>
> Please consider updating wlroots to 0.18, as some new software need it
> as a dependency.
It's already available in Experimental. Note that the binary packages now have
"-0.18" in their names as upstream now supports multiple versions.
https://tracker.debian.org/pkg/wlroots shows that too and
https://release.debian.org/transitions/html/auto-wlroots.html shows there's
'even' a transition tracker for it.
But I assume you('d) know all this, so what am I missing?
signature.asc
Description: This is a digitally signed message part.
Bug#1078782: bullseye-pu: package amd64-microcode/3.20240710.2~deb11u1
zx9C5
+bisCiEwf4gg7ffQPLYW9MCsK3yjTaQ==
+=vQEt
-END PGP SIGNATURE-
diff --git a/amd-ucode/microcode_amd_fam19h.bin b/amd-ucode/microcode_amd_fam19h.bin
index 02a5d05..4dcdca8 100644
Binary files a/amd-ucode/microcode_amd_fam19h.bin and b/amd-ucode/microcode_amd_fam19h.bin differ
diff --git a/amd-ucode/microcode_amd_fam19h.bin.asc b/amd-ucode/microcode_amd_fam19h.bin.asc
index 8cff901..dcd5a23 100644
--- a/amd-ucode/microcode_amd_fam19h.bin.asc
+++ b/amd-ucode/microcode_amd_fam19h.bin.asc
@@ -1,11 +1,11 @@
-BEGIN PGP SIGNATURE-
-iQEzBAABCgAdFiEE/HxsUF2vzBRxg1fK5L5TOfMornMFAmTEYrcACgkQ5L5TOfMo
-rnN4IQf/QKbOezXZ4OYzaPANvsZQEAzLNfuylC/aQMwrPaO7daz5/zmCN4HU5XkH
-dDT8DYfPg+fQHIgxAw0/L24xPOm5Op/QuLVDyDqVr4qvL8+65eeI+JqxD/wXMXYN
-V34kkLM2p8iuyY1Nc8IDLXu4X75KGNPbKZlMRKMU3Pr7ai5O4ihmiAM+N6qv1KEJ
-YToNN6vrg0qt1cv0SLM8sa4e7L1+oblUrg/o0FViYE8pxsU3ZRRVSJMUg+lKjvl/
-1ZPGKOdD80fcNJ+ItYGHNNs3eCc3WgW7Kc/E668eH75Yu9Zt7ewWZX8Sg/mygleY
-OzMwhbPJg4bF4zm7C/Pku7i1T2Omcg==
-=km2X
+iQEzBAABCgAdFiEE/HxsUF2vzBRxg1fK5L5TOfMornMFAmX9xsgACgkQ5L5TOfMo
+rnP2aQf/QBOiKUZsrVIbnn0+Ls84yDYovoesYriy1rbK+K5CVRb/0iqoFn5xKIu6
+bvyHN0fnj7Ko+oedNvcRCmlu+jiw08s3WArQb6r3fK4QT/2Wj2f+qX14uoFuCGUd
+QgZTc4hZxNxSZBbQuKVbtDmT0iFtV0jKBp/ajdYD9++rA+VcIemKtwX/sxEZnUFi
+fXg016uAs/Q9LQ5KWvz3VhFz2G77BEXjDIJNAHSVCxmWCvsd05kf1SbXUswlj/T8
+JtuH840zfZicZEk8e3grO4fSywLyrZCjqATSXa+XY63thCIglM9c6V+EBL3jGXxh
+Cs2tZH8/ge+tL/UBBJ8FdOZcVSpkeQ==
+=HHoV
-END PGP SIGNATURE-
diff --git a/amd/amd_sev_fam19h_model0xh.sbin b/amd/amd_sev_fam19h_model0xh.sbin
index 141d5d0..9cde6ad 100644
Binary files a/amd/amd_sev_fam19h_model0xh.sbin and b/amd/amd_sev_fam19h_model0xh.sbin differ
diff --git a/amd/amd_sev_fam19h_model1xh.sbin b/amd/amd_sev_fam19h_model1xh.sbin
new file mode 100644
index 000..529dcb5
Binary files /dev/null and b/amd/amd_sev_fam19h_model1xh.sbin differ
diff --git a/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin b/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin
new file mode 100644
index 000..6b454bf
Binary files /dev/null and b/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin differ
diff --git a/amdtee/amd_pmf_v3.bin b/amdtee/amd_pmf_v3.bin
new file mode 12
index 000..e340752
--- /dev/null
+++ b/amdtee/amd_pmf_v3.bin
@@ -0,0 +1 @@
+773bd96f-b83f-4d52-b12dc529b13d8543.bin
\ No newline at end of file
diff --git a/debian/README.Debian b/debian/README.Debian
index b0116a4..cd91c25 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -44,13 +44,7 @@ the initramfs using dracut, and reboot. Note that since Linux kernel 4.4,
one must use dracut 044 or later.
Applying the microcode updates without the use of an early initramfs is
-not automatically supported anymore, due to future safety concerns.
-However, the local administrator may trigger an immediate microcode update
-attempt at any time, at her own risk:
-
- USING AN INITRAMFS+REBOOT IS SAFER. DO THIS ONLY WHEN YOU KNOW BETTER:
- as root:
- echo 1 > /sys/devices/system/cpu/microcode/reload
+not supported in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Holschuh , 2024-08-11
diff --git a/debian/amd64-microcode.dirs b/debian/amd64-microcode.dirs
index 0790bdb..60f0777 100644
--- a/debian/amd64-microcode.dirs
+++ b/debian/amd64-microcode.dirs
@@ -2,3 +2,4 @@ etc/default
etc/modprobe.d
lib/firmware/amd-ucode
lib/firmware/amd
+lib/firmware/amdtee
diff --git a/debian/amd64-microcode.install b/debian/amd64-microcode.install
index 40d0e9c..07af704 100644
--- a/debian/amd64-microcode.install
+++ b/debian/amd64-microcode.install
@@ -1,2 +1,3 @@
amd-ucode/*bin lib/firmware/amd-ucode
+amdtee/*lib/firmware/amdtee
amd/*sev*bin lib/firmware/amd
diff --git a/debian/amd64-microcode.postinst b/debian/amd64-microcode.postinst
index 453fd98..7fdc28b 100644
--- a/debian/amd64-microcode.postinst
+++ b/debian/amd64-microcode.postinst
@@ -19,11 +19,14 @@ set -e
case "$1" in
configure)
- # do it like udev and firmware-linux-*
- if [ -x /usr/sbin/update-initramfs ] && [ -e /etc/initramfs-tools/initramfs.conf ] ; then
- update-initramfs -u && {
+ RC=0
+ dpkg-trigger --no-await update-initramfs || RC=$?
+ [ "$RC" -ne 0 ] && [ -e /etc/initramfs-tools/initramfs.conf ] && {
+ RC=0
+ update-initramfs -u || RC=$?
+ }
+ if [ "$RC" -eq 0 ] ; then
echo "amd64-microcode: microcode will be updated at next boot" >&2
- }
else
echo "amd64-microcode: initramfs support missing" >&2
fi
diff --git a/debian/amd64-microcode.postrm b/debian/amd64-microcode.postrm
index c775b42..4b187d0 100644
--- a/debian/amd64-microcode.postrm
+++ b/debian/amd64-microcode.postrm
@@ -20,9 +20,10 @@ set -e
case "$1" in
purge|remove)
- if
Bug#1078781: bookworm-pu: package amd64-microcode/3.20240710.2~deb12u1
zx9C5
+bisCiEwf4gg7ffQPLYW9MCsK3yjTaQ==
+=vQEt
-END PGP SIGNATURE-
diff --git a/amd-ucode/microcode_amd_fam19h.bin b/amd-ucode/microcode_amd_fam19h.bin
index 02a5d05..4dcdca8 100644
Binary files a/amd-ucode/microcode_amd_fam19h.bin and b/amd-ucode/microcode_amd_fam19h.bin differ
diff --git a/amd-ucode/microcode_amd_fam19h.bin.asc b/amd-ucode/microcode_amd_fam19h.bin.asc
index 8cff901..dcd5a23 100644
--- a/amd-ucode/microcode_amd_fam19h.bin.asc
+++ b/amd-ucode/microcode_amd_fam19h.bin.asc
@@ -1,11 +1,11 @@
-BEGIN PGP SIGNATURE-
-iQEzBAABCgAdFiEE/HxsUF2vzBRxg1fK5L5TOfMornMFAmTEYrcACgkQ5L5TOfMo
-rnN4IQf/QKbOezXZ4OYzaPANvsZQEAzLNfuylC/aQMwrPaO7daz5/zmCN4HU5XkH
-dDT8DYfPg+fQHIgxAw0/L24xPOm5Op/QuLVDyDqVr4qvL8+65eeI+JqxD/wXMXYN
-V34kkLM2p8iuyY1Nc8IDLXu4X75KGNPbKZlMRKMU3Pr7ai5O4ihmiAM+N6qv1KEJ
-YToNN6vrg0qt1cv0SLM8sa4e7L1+oblUrg/o0FViYE8pxsU3ZRRVSJMUg+lKjvl/
-1ZPGKOdD80fcNJ+ItYGHNNs3eCc3WgW7Kc/E668eH75Yu9Zt7ewWZX8Sg/mygleY
-OzMwhbPJg4bF4zm7C/Pku7i1T2Omcg==
-=km2X
+iQEzBAABCgAdFiEE/HxsUF2vzBRxg1fK5L5TOfMornMFAmX9xsgACgkQ5L5TOfMo
+rnP2aQf/QBOiKUZsrVIbnn0+Ls84yDYovoesYriy1rbK+K5CVRb/0iqoFn5xKIu6
+bvyHN0fnj7Ko+oedNvcRCmlu+jiw08s3WArQb6r3fK4QT/2Wj2f+qX14uoFuCGUd
+QgZTc4hZxNxSZBbQuKVbtDmT0iFtV0jKBp/ajdYD9++rA+VcIemKtwX/sxEZnUFi
+fXg016uAs/Q9LQ5KWvz3VhFz2G77BEXjDIJNAHSVCxmWCvsd05kf1SbXUswlj/T8
+JtuH840zfZicZEk8e3grO4fSywLyrZCjqATSXa+XY63thCIglM9c6V+EBL3jGXxh
+Cs2tZH8/ge+tL/UBBJ8FdOZcVSpkeQ==
+=HHoV
-END PGP SIGNATURE-
diff --git a/amd/amd_sev_fam19h_model0xh.sbin b/amd/amd_sev_fam19h_model0xh.sbin
index 141d5d0..9cde6ad 100644
Binary files a/amd/amd_sev_fam19h_model0xh.sbin and b/amd/amd_sev_fam19h_model0xh.sbin differ
diff --git a/amd/amd_sev_fam19h_model1xh.sbin b/amd/amd_sev_fam19h_model1xh.sbin
new file mode 100644
index 000..529dcb5
Binary files /dev/null and b/amd/amd_sev_fam19h_model1xh.sbin differ
diff --git a/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin b/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin
new file mode 100644
index 000..6b454bf
Binary files /dev/null and b/amdtee/773bd96f-b83f-4d52-b12dc529b13d8543.bin differ
diff --git a/amdtee/amd_pmf_v3.bin b/amdtee/amd_pmf_v3.bin
new file mode 12
index 000..e340752
--- /dev/null
+++ b/amdtee/amd_pmf_v3.bin
@@ -0,0 +1 @@
+773bd96f-b83f-4d52-b12dc529b13d8543.bin
\ No newline at end of file
diff --git a/debian/README.Debian b/debian/README.Debian
index b0116a4..cd91c25 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -44,13 +44,7 @@ the initramfs using dracut, and reboot. Note that since Linux kernel 4.4,
one must use dracut 044 or later.
Applying the microcode updates without the use of an early initramfs is
-not automatically supported anymore, due to future safety concerns.
-However, the local administrator may trigger an immediate microcode update
-attempt at any time, at her own risk:
-
- USING AN INITRAMFS+REBOOT IS SAFER. DO THIS ONLY WHEN YOU KNOW BETTER:
- as root:
- echo 1 > /sys/devices/system/cpu/microcode/reload
+not supported in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Holschuh , 2024-08-11
diff --git a/debian/amd64-microcode.dirs b/debian/amd64-microcode.dirs
index 0790bdb..60f0777 100644
--- a/debian/amd64-microcode.dirs
+++ b/debian/amd64-microcode.dirs
@@ -2,3 +2,4 @@ etc/default
etc/modprobe.d
lib/firmware/amd-ucode
lib/firmware/amd
+lib/firmware/amdtee
diff --git a/debian/amd64-microcode.install b/debian/amd64-microcode.install
index 40d0e9c..07af704 100644
--- a/debian/amd64-microcode.install
+++ b/debian/amd64-microcode.install
@@ -1,2 +1,3 @@
amd-ucode/*bin lib/firmware/amd-ucode
+amdtee/*lib/firmware/amdtee
amd/*sev*bin lib/firmware/amd
diff --git a/debian/amd64-microcode.postinst b/debian/amd64-microcode.postinst
index 453fd98..7fdc28b 100644
--- a/debian/amd64-microcode.postinst
+++ b/debian/amd64-microcode.postinst
@@ -19,11 +19,14 @@ set -e
case "$1" in
configure)
- # do it like udev and firmware-linux-*
- if [ -x /usr/sbin/update-initramfs ] && [ -e /etc/initramfs-tools/initramfs.conf ] ; then
- update-initramfs -u && {
+ RC=0
+ dpkg-trigger --no-await update-initramfs || RC=$?
+ [ "$RC" -ne 0 ] && [ -e /etc/initramfs-tools/initramfs.conf ] && {
+ RC=0
+ update-initramfs -u || RC=$?
+ }
+ if [ "$RC" -eq 0 ] ; then
echo "amd64-microcode: microcode will be updated at next boot" >&2
- }
else
echo "amd64-microcode: initramfs support missing" >&2
fi
diff --git a/debian/amd64-microcode.postrm b/debian/amd64-microcode.postrm
index c775b42..4b187d0 100644
--- a/debian/amd64-microcode.postrm
+++ b/debian/amd64-microcode.postrm
@@ -20,9 +20,10 @@ set -e
case "$1" in
purge|remove)
- if
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > Then I guess a 16 MiB unused partition could be added to relevant > recipes. Now, which are the relevant recipes ? In other words, which > arch/subarch need it ? > Currently, partman-auto has the following recipes for ARM: > > recipes-armel-kirkwood > recipes-armel-orion5x > recipes-armhf-efikasb These ones are NOT relevant for this. > recipes-armhf-efi (=recipes-amd64-efi) > recipes-armhf > recipes-arm64-efi (=recipes-amd64-efi) > recipes-arm64 (=recipes-armhf) Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is relevant. I don't know if it's common, but AFAIK you can use U-Boot with EFI, but it sounds 'weird' to add it to a recipe with AMD64 in its name... signature.asc Description: PGP signature
Bug#1014593: Now with CVE-2023-31315 (amd64-microcode: Updated version for bullseye/stable?)
The current plan is that amd64-microcode will be updated through the next point release for both stable and oldstable, which should happen in a few weeks. I was about to file the two proposed-update requests, in fact. If you need them sooner, you could get them *now* from git: https://salsa.debian.org/hmh/amd64-microcode/-/tree/releases/bookworm?ref_type=heads https://salsa.debian.org/hmh/amd64-microcode/-/tree/releases/bullseye?ref_type=heads You could also try to build the source package already in unstable, or just plain copy the datafiles out of the linux-firmware git tree... -- Henrique de Moraes Holschuh
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 5:50 PM CEST, Pascal Hambourg wrote: > On 15/08/2024 at 16:25, Diederik de Haas wrote: > >> I do not know any way to reserve unallocated space in recipes. The > >> recipes could create a 16-MiB unused partition but the table in [2] > >> lists a lot of special partitions within the first 16 MiB. Are these > >> actual partitions ? If yes, how are they supposed to be created ? > > > > I think you technically could create those partitions, but those are not > > relevant. All that matter is that the first 16 MiB stay unused so that > > U-Boot can be put there. > > It is still unclear to me if it can be an unused partition or if it must > be unallocated space which can be used to create new partitions. > AFAIK, only the former can be done in recipes. Either would work. signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 3:46 PM CEST, Pascal Hambourg wrote: > On 15/08/2024 at 08:26, Holger Wansing wrote: > > Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas > > : > >> > >> I'm not 100% sure if this fits into this subject/discussion, but ... > > It is beyond the original scope (partition size limits) and I believe it > would deserve its own discussion involving people who are familiar with > ARM platforms. Ok. > Disclaimer: I have no experience nor knowledge about ARM (or any other > architectures than x86) and its boot process. For partitioning there's nothing special ... apart that the first 16MiB should not be used. > >> The U-Boot bootloader is normally put in the first part of the boot > >> device and for Rockchip based devices that can extend to the 16MB > >> 'mark'. AFAIK bootloaders for other SoCs are before that. > >> > >> If you use the current recipes you end up with an unbootable system as > >> the U-Boot bootloader get overwritten with the / (root) partition and > >> the data on it. > > AFAICS, the first partition in all non-EFI ARM recipes is /boot, not /. I shouldn't have written which partition, but the important thing is that the first 'real' partition starts at 16 MiB. > >> Right now, the instruction is to choose manual partitioning and create > >> a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the > >> normal partitions and after that you could remove that partition again. > >> And if you type in 16MB, then you need to 'hope' that it is actually > >> 16MB and not something (a bit) smaller. > > 16 MB (~15.3 MiB) or 16 MiB (~16.8 MB) ? > In partman, 1 MB really means 10^6 bytes, not 1 MiB (2^20 bytes). I think I've actually tried both and IIRC that didn't make a difference. > >> So it would be very helpful if the recipe(s) for ARM devices would > >> reserve the first 16MB automatically with plain partitioning. > > What do you mean exactly by "plain partitioning" ? Manual partitioning ? > Guiding partitioning with all files in one filesystem ? Other ? Partitioning NOT involving LVM. I 'jumped in' when the subject of creating blank/reserved partitions with LVM and then the question arose if that should also be used for "plain" partitioning, which I interpreted as not using LVM. > >> [1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian > >> [2] https://opensource.rock-chips.com/wiki_Partitions > > I do not know any way to reserve unallocated space in recipes. The > recipes could create a 16-MiB unused partition but the table in [2] > lists a lot of special partitions within the first 16 MiB. Are these > actual partitions ? If yes, how are they supposed to be created ? I think you technically could create those partitions, but those are not relevant. All that matter is that the first 16 MiB stay unused so that U-Boot can be put there. > > Looks like another incarnation of > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+770666> > > It looks like a different issue to me. IIUC these bug reports are about > parted_server erasing the boot loader location when creating a new > partition table, not the first partition overlapping with the boot > loader location. AIUI bug #770666 is the same/similar as this 'Rockchip' issue. Bug #751704 OTOH is related, but does deal with problems wrt partition table. But I don't know/understand which of parted* sub programs is responsible for which part. Cheers, Diederik signature.asc Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On Mon Aug 12, 2024 at 1:05 PM CEST, Faidon Liambotis wrote:
> On Sun, Aug 11, 2024 at 12:31:21PM -0400, Reinhard Tartler wrote:
> > But you are right, ultimately this decision is up to the maintainer to make.
>
> Maintainer here :)
>
> For this particular case, I think removing -Werror made sense as a quick
> fix to avoid kicking out the entire WasmEdge -> crun -> podman stack out
I wondered why wasmedge ended up on my radar, but that explains it ;-)
> of testing, for what is a bug that existed before (i.e. not a
> regression), and was just surfaced by a new compiler version. I had
> looked into the bug before Reinhard NMUed and the fix wasn't obvious to
> me. So taking a shortcut and prioritizing expediency over correctness
> made sense to me, in this particular case.
Yeah, makes a lot of sense.
> But, at the same time, I agree that addressing this properly means
> reporting this upstream so that the underlying bug gets fixed. I see
> this has happened now, and upstream is already responsive (as they
> usually are!).
And what happened is why I like FLOSS so much:
a bunch of people working together to solve a problem :-D
As you may have seen I was able to verify that the proposed fix indeed
solved the GCC-14 compiler issue, so I've DEP-3-ified that patch and
attached it here.
HTH,
Diederik
From: hydai
Date: Thu, 15 Aug 2024 13:59:51 +0800
Subject: [Loader] Fix GCC 14 maybe-uninitialized warning (#3659)
Origin: upstream, https://github.com/WasmEdge/WasmEdge/commit/e427a71c5a50982c35e124340fc4febcd7600226
Fix #3640
Signed-off-by: hydai
---
lib/loader/filemgr.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/loader/filemgr.cpp b/lib/loader/filemgr.cpp
index 14afba28..a6e2b95e 100644
--- a/lib/loader/filemgr.cpp
+++ b/lib/loader/filemgr.cpp
@@ -49,6 +49,11 @@ Expect FileMgr::setCode(Span CodeData) {
// Set code data. See "include/loader/filemgr.h".
Expect FileMgr::setCode(std::vector CodeData) {
reset();
+ // Tell GCC 14 that DataHolder has no data.
+ // Fix the false positive warning,
+ // which is reported by GCC 14 with `maybe-uninitialized`
+ assuming(!DataHolder);
+
DataHolder.emplace(std::move(CodeData));
Data = DataHolder->data();
Size = DataHolder->size();
--
2.45.2
signature.asc
Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Thu Aug 15, 2024 at 8:26 AM CEST, Holger Wansing wrote: > Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas > : > >On ARM devices it would be very useful if the first 16MB would be > >(automatically) reserved. > >The U-Boot bootloader is normally put in the first part of the boot > >device and for Rockchip based devices that can extend to the 16MB > >'mark'. AFAIK bootloaders for other SoCs are before that. > > > >So it would be very helpful if the recipe(s) for ARM devices would > >reserve the first 16MB automatically with plain partitioning. > > > >[1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian > >[2] https://opensource.rock-chips.com/wiki_Partitions > > Looks like another incarnation of > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+770666> Yep signature.asc Description: PGP signature
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Fri Aug 9, 2024 at 10:08 PM CEST, Pascal Hambourg wrote: > Guided partitioning with LVM already provides a feature to reserve space > in the VG. Maybe it could be extended to guided partitioning with plain > partitions. I'm not 100% sure if this fits into this subject/discussion, but ... On ARM devices it would be very useful if the first 16MB would be (automatically) reserved. The U-Boot bootloader is normally put in the first part of the boot device and for Rockchip based devices that can extend to the 16MB 'mark'. AFAIK bootloaders for other SoCs are before that. If you use the current recipes you end up with an unbootable system as the U-Boot bootloader get overwritten with the / (root) partition and the data on it. There should be a bug for it, but I didn't manage to find it. Right now, the instruction is to choose manual partitioning and create a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the normal partitions and after that you could remove that partition again. And if you type in 16MB, then you need to 'hope' that it is actually 16MB and not something (a bit) smaller. I like to think that I'm more advanced then most users and I found it quite difficult to do. So it would be very helpful if the recipe(s) for ARM devices would reserve the first 16MB automatically with plain partitioning. [1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian [2] https://opensource.rock-chips.com/wiki_Partitions signature.asc Description: PGP signature
Bug#1075263: Patch for MCPP GCC14 FTBFS
Hi all,
I have attached a patch for the MCPP FTBFS reported in #1075263 can
somebody upload the patch to debian?
Cheers,
José
--
José Gutiérrez de la Concha
ZeroC, Inc.
--- a/src/expand.c
+++ b/src/expand.c
@@ -710,7 +710,9 @@
} else {
m_inf->locs.start_col = m_inf->locs.start_line = 0L;
}
-m_inf->args = m_inf->loc_args = NULL; /* Default args */
+/* Default args */
+m_inf->args = NULL;
+m_inf->loc_args = NULL;
for (num = 1, recurs = 0; num < m_num; num++)
if (mac_inf[ num].defp == defp)
recurs++; /* Recursively nested macro */
--- a/src/configed.H
+++ b/src/configed.H
@@ -299,7 +299,7 @@
#define _POSIX_ 1
#define _POSIX_SOURCE 1
#ifndef _POSIX_C_SOURCE
-#define _POSIX_C_SOURCE 1
+#define _POSIX_C_SOURCE 200112L // Ensure readlink is available
#define _POSIX_C_SOURCE_defined 1
#endif
#include"limits.h"
Bug#1078688: Please use filecaps for /usr/sbin/unix_chkpwd instead of setgid shadow
Package: libpam-modules Version: 1.5.3-7 Dear Maintainer, As described in https://github.com/linux-pam/linux-pam/pull/373, unix_chkpwd does not need to be setuid or setgid anymore if it is given cap_dac_override via filecaps instead. I would like debian to use filecaps instead of setgid shadow for /usr/sbin/unix_chkpwd so that the file itself can be owned by root:root and the setgid bit can be removed from the file. Having all files in /usr owned by root:root is useful for image builders as it allows building debian images in a stripped down user namespace with only the root user and nothing else available. Cheers, Daan
Bug#1075633: wasmedge: ftbfs with GCC-14
On Sun Aug 11, 2024 at 6:31 PM CEST, Reinhard Tartler wrote: > I'm afraid we'll have to agree to disagree Agreed signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
On Mon Aug 12, 2024 at 8:42 AM CEST, Petter Reinholdtsen wrote:
>
> Control: tags -1 + patch
>
> The following debian/patches/1020-ffmpeg-7.patch seem to fix the build:
>
> Description: More fixes for ffmpeg 7.0
> Use class method GetChannels() as a wrapper to get the ffmpeg version
> dependent implementation instead of the channels method which
> disappeared with ffmpeg 7.
> Author: Petter Reinholdtsen
> Forwarded: no
Why not? This isn't specific to Debian and with forwarding everyone benefits.
And if a new upstream version gets released, you can likely drop the
patch.
> Last-Updated: 2024-08-12
> ---
> Index: simplescreenrecorder-salsa/src/AV/Output/AudioEncoder.cpp
> ==> ---
> simplescreenrecorder-salsa.orig/src/AV/Output/AudioEncoder.cpp
> 2024-08-12 06:33:54.881267389 +
> +++ simplescreenrecorder-salsa/src/AV/Output/AudioEncoder.cpp 2024-08-12
> 06:35:49.514541002 +
> @@ -42,7 +42,7 @@
> if(GetCodecContext()->frame_size <= 1) {
> // This is really weird, the old API uses the size of the
> *output* buffer to determine the number of
> // input samples if the number of input samples (i.e.
> frame_size) is not fixed (i.e. frame_size <= 1).
> - m_temp_buffer.resize(DEFAULT_FRAME_SAMPLES *
> GetCodecContext()->channels *
> av_get_bits_per_sample(GetCodecContext()->codec_id) / 8);
> + m_temp_buffer.resize(DEFAULT_FRAME_SAMPLES * GetChannels() *
> av_get_bits_per_sample(GetCodecContext()->codec_id) / 8);
> } else {
> m_temp_buffer.resize(std::max(FF_MIN_BUFFER_SIZE, 256 * 1024));
> }
> @@ -166,7 +166,11 @@
> assert((unsigned int) frame->GetFrame()->nb_samples ==
> GetFrameSize());
> #endif
> #if SSR_USE_AVFRAME_CHANNELS
> - assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> +# if LIBAVCODEC_VERSION_MAJOR < 61
> + assert(frame->GetFrame()->channels == GetChannels());
> +# else
> + assert(frame->GetFrame()->ch_layout.nb_channels ==
> GetChannels());
> +# endif /* LIBAVCODEC_VERSION_MAJOR < 61 */
> #endif
> #if SSR_USE_AVFRAME_SAMPLE_RATE
> assert(frame->GetFrame()->sample_rate ==
> GetCodecContext()->sample_rate);
Probably a PEBKAC issue, but it seems it didn't apply cleanly?
The Salsa CI pipeline now does succeed:
https://salsa.debian.org/diederik/simplescreenrecorder/-/pipelines/715297
(at time of writing at least the 'build' stage where it failed before)
signature.asc
Description: PGP signature
Bug#1078505: developers-reference: document corner case of debian version and rational
> salsa. Some user used +deb12u1~1 > but it is not safe against +deb12u1~debu11u1 upgrade for instance. So a > suffix > like ~pre should be used, and should be documented Maybe we could set aside "~~~" for such uses. ~pre is not going to be foolproof. I am *very* happy that ~deb sorts later than ~bpo, as that updates a backport to a stable / oldstable / oldoldstable update. But that was sheer luck. This is not true for ~pre, but would work for ~~pre or whatever... -- Henrique de Moraes Holschuh
Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
> I got the *impression* that some heuristic was used to determine whether > the microcode update should be applied. No. It has a simple heuristic to not increase the initramfs size by adding AMD microcode updates unless either it is running on an AMD processor when the amd64-microcode package is installed, OR you configure amd64-microcode to always add the updates to the initramfs. It is an "all or nothing" thing, and currently it has absolutely no "processor-model-aware" logic. For *Intel*, we have more heuristics, but that's because the full Intel microcode package is *very large*. The one for AMD is nowhere near large enough to justify the added complexity, yet. *Uploading* the microcode update to the processor is handled by the kernel during early boot, and it is done only if the processor signature matches one in a microcode update, and the new microcode revision in the update is strictly higher than whatever is already running in the processor. *Accepting* and *activating* the microcode update is on the processor. There are microcode updates that absolutely must be loaded very early during the reset (and sometimes even the power-up) sequence, and those can only be applied by the firmware itself, so they must be installed as a firmware update. These updates are *not* distributed by AMD to the general public (at least not on purpose), and Debian does not include them (at least not on purpose...). On some AMD processor models, there are microcode revisions from which you must NOT update the processor to some other microcode revision at all. I have no idea why, although i can come up with a few possible scenarios for this. The kernel driver for AMD microcode updates has logic that detects this situation, and does not send any microcode updates to the processor. Note that if the processor is not yet on any of those specific microcode revisions, it should apply the microcode update, that's why such updates are distributed even if some systems will have to detect that they must not apply them. > I'd like to know whether I'm actually running the latest microcode, > but I haven't figured out a way how? /proc/cpuinfo should report the running microcode version on a recent enough kernel. It will also log the microcode revision when it does a microcode update. There is no facility to check whether what is in your system's /lib/firmware/amd-ucode is the latest available microcode update that has been issued by AMD to the linux-firmware project, nor is there any facility to know whether there is a newer revision that is restricted to firmware vendors. I believe the needrestart package will actually warn if you need to reboot to update the microcode on your system processor, based on not-foolproof heuristics that look at /proc/cpuinfo and what has been installed by amd64-microcode (and intel-microcode). Oh, and the date-based versioning of the amd64-microcode package has no relationship to the dates on any of the microcode updates inside it. It is the date of the latest commit in linux-firmware that changed any of the several firmware files (AMD ucode, AMD SEV, AMD TEE) inside it. I hope this information solves any lingering doubts about how it works? -- Henrique de Moraes Holschuh
Bug#1075633: wasmedge: ftbfs with GCC-14
On Sun Aug 11, 2024 at 4:56 PM CEST, Reinhard Tartler wrote: > On 2024-08-11 08:55, Diederik de Haas wrote: > > On 03 Aug 2024 11:08:58 -0400 Reinhard Tartler > > wrote: > >> I noticed this package is listed as low-NMU. As such, I'm taking the > >> liberty of uploading the following patch as NMU to sid: > >> ... > >> new file debian/patches/don-t-fail-on-unknown-gcc-warnings.patch > >> @@ -0,0 +1,20 @@ > >> +From: Reinhard Tartler > >> +Date: Sat, 3 Aug 2024 10:46:50 -0400 > >> +Subject: don't fail on unknown gcc warnings > >> + > >> +--- > >> + cmake/Helper.cmake | 1 - > >> + 1 file changed, 1 deletion(-) > >> + > >> +diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake > >> +index f9cdcf2..126e93f 100644 > >> +--- a/cmake/Helper.cmake > >> b/cmake/Helper.cmake > >> +@@ -39,7 +39,6 @@ else() > >> + > >> + if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS) > >> + list(APPEND WASMEDGE_CFLAGS > >> +- -Werror > >> + -Wno-error=pedantic > >> + ) > >> + if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND > >> CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 13) > >> new file debian/patches/series > >> @@ -0,0 +1 @@ > >> +don-t-fail-on-unknown-gcc-warnings.patch > > > > Why do you consider this an appropriate solution? > > > > Upstream explicitly want all warnings to be treated as errors and now > > with gcc-14 it generates a new warning. > > This sounds like something upstream explicitly wants to know about? > > I think this is a reasonable stance to take upstream. I've now filed > https://github.com/WasmEdge/WasmEdge/issues/3640 to document this issue, > in the hope that someone with more expertise can have a look. Thanks for reporting it upstream :-) > For Debian, I do think that this workaround is acceptable, at least for > the purposes of allowing further testing in the "testing" Distribution, > so that we get additional datapoints whether there actually are runtime > issues that stem from unitialized variables that GCC claims to detect. I disagree, but I'll let it up to the maintainer to reopen this bug or not. Packages don't transition to Testing to get additional datapoints (even though that will happen), but because there are no RC bugs, like FTBFS, currently known. That's not the case here. If you can make the argument that a specific warning can be ignored, you could override that specific warning with a clear explanation why that's OK in this particular case. This patch OTOH essentially says to ignore ALL warnings. My 0.02 signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
Control: notforwarded -1 Control: tag -1 -fixed-upstream On Sun Aug 11, 2024 at 3:43 PM CEST, Petter Reinholdtsen wrote: > [Diederik de Haas] > >> during a rebuild of the reverse dependencies for the transition to > >> ffmpeg 7.0, your package failed to build > > > > Someone made a PR and that got merged upstream. Updated metadata > > accordingly. > > This is strange, as debian/patches/0020-ffmpeg-7.patch from > https://github.com/MaartenBaert/ssr/pull/1031/ > is already part > of version 0.4.4-5. Is the patch incomplete? The error seem to happen in > code protected by '#if LIBAVCODEC_VERSION_MAJOR < 61'. Which means my forwarded was incorrect, fixing metadata accordingly. signature.asc Description: PGP signature
Bug#1072451: simplescreenrecorder: FTBFS with ffmpeg 7.0: AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka ‘struct AVFrame’} has no member named ‘channels’ no member named ‘channels’
On Sun Aug 11, 2024 at 3:43 PM CEST, Petter Reinholdtsen wrote:
> [Diederik de Haas]
> >> during a rebuild of the reverse dependencies for the transition to
> >> ffmpeg 7.0, your package failed to build
> >
> > Someone made a PR and that got merged upstream. Updated metadata
> > accordingly.
>
> This is strange, as debian/patches/0020-ffmpeg-7.patch from
> https://github.com/MaartenBaert/ssr/pull/1031/ > is already part
> of version 0.4.4-5. Is the patch incomplete? The error seem to happen in
> code protected by '#if LIBAVCODEC_VERSION_MAJOR < 61'.
Yes, the patch is incomplete.
> /<>/src/AV/Output/AudioEncoder.cpp: In member function ‘virtual
> bool AudioEncoder::EncodeFrame(AVFrameWrapper*)’:
> /<>/src/AV/Output/AudioEncoder.cpp:169:43: error: ‘AVFrame’ {aka
> ‘struct AVFrame’} has no member named ‘channels’
> 169 | assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> | ^~~~
> /<>/src/AV/Output/AudioEncoder.cpp:169:74: error:
> ‘AVCodecContext’ {aka ‘struct AVCodecContext’} has no member named ‘channels’
> 169 | assert(frame->GetFrame()->channels ==
> GetCodecContext()->channels);
> |
>^~~~
Note the line numbers. The lines that were fixed in that file did NOT
include the ``bool AudioEncoder::EncodeFrame(AVFrameWrapper* frame)``
function.
HTH
signature.asc
Description: PGP signature
Bug#1075633: wasmedge: ftbfs with GCC-14
On 03 Aug 2024 11:08:58 -0400 Reinhard Tartler wrote: > I noticed this package is listed as low-NMU. As such, I'm taking the > liberty of uploading the following patch as NMU to sid: > ... > new file debian/patches/don-t-fail-on-unknown-gcc-warnings.patch > @@ -0,0 +1,20 @@ > +From: Reinhard Tartler > +Date: Sat, 3 Aug 2024 10:46:50 -0400 > +Subject: don't fail on unknown gcc warnings > + > +--- > + cmake/Helper.cmake | 1 - > + 1 file changed, 1 deletion(-) > + > +diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake > +index f9cdcf2..126e93f 100644 > +--- a/cmake/Helper.cmake > b/cmake/Helper.cmake > +@@ -39,7 +39,6 @@ else() > + > + if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS) > + list(APPEND WASMEDGE_CFLAGS > +- -Werror > + -Wno-error=pedantic > + ) > + if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND CMAKE_CXX_COMPILER_VERSION > VERSION_GREATER 13) > new file debian/patches/series > @@ -0,0 +1 @@ > +don-t-fail-on-unknown-gcc-warnings.patch Why do you consider this an appropriate solution? Upstream explicitly want all warnings to be treated as errors and now with gcc-14 it generates a new warning. This sounds like something upstream explicitly wants to know about? signature.asc Description: PGP signature
Bug#1037281: Support of Banana Pi R3
On Friday, 9 August 2024 08:02:42 CEST Bernhard Wörner wrote: > Hello Diederik > Hello Vagrant > > You wrote, that there are now the board configs in u-boot: > > configs/mt7986a_bpir3_emmc_defconfig configs/mt7986a_bpir3_sd_defconfig > > But the arm-trusted-firmware is missing. > > Is it possible, to boot the BananaPi without this firmware? > > > What is your opinion: > Is it time to order this BananaPi now? > Can we get the Banana Pi to work? I don't have an answer to any of your questions, but due to https://bugs.debian.org/1072968 the BPI-R3 is now properly supported in the Debian kernel since version 6.10. For the rest I suggest to search and/or participate in the BananaPi and OpenWrt forums where they likely know (a lot) more about BPI-R3 then I do. signature.asc Description: This is a digitally signed message part.
Bug#1077980: gnome-network-displays: Set Depends: to "wpasupplicant | iwd" as using iwd as an alternative is actually possible now
On 8/7/24 20:47, Matthias Geiger wrote: have you tested this ? I'm willing to go ahead enabling iwd if both Chromecast and miracast work. I've tested it with Miracast on a LG OLED55CX and it works. I haven't tried it with a Chromecast. -- M
Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
On Wednesday, 7 August 2024 20:33:02 CEST Holger Wansing wrote: > > > Could probably solve the long standing issue > > > "#987503 swap partition only 1 GB instead of at least 1 x RAM size" > > > stating that hibernation is broken for machines with RAM bigger than > > > 1G... > > > > Do you mean to create specific recipes for hibernation ? > > A recipe specific for server installations, which limits the swap to let's > say 1G or 2G, because the machine has enough RAM built-in. > The other (already existing) recipes could be focused on desktops/laptops, > which use something like Swap=RAM, to allow hibernation. > Having such concept, would probably allow to get rid of the > partman-auto/cap-ram thingy, which solved one problem by creating a new > one... FWIW: +1 I found it odd that the default was changed to cater for what I consider to be an exceptional situation (but could be common in server env?). signature.asc Description: This is a digitally signed message part.
Bug#1077980: gnome-network-displays: Set Depends: to "wpasupplicant | iwd" as using iwd as an alternative is actually possible now
Package: gnome-network-displays Severity: normal Hi, As I mentioned in upstream bug #392, using iwd instead of wpasupplicant is possible now. iwd implemented the necessary bits at the end of 2021, and I've verified Miracast functionality is working with the current Flatpak version of Gnome Network Displays. It'd be nice to be able to use the Debian version instead. 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.9.10-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 gnome-network-displays depends on: ii libadwaita-1-0 1.5.3-1 ii libavahi-common30.8-13+b2 pn libavahi-gobject0 ii libc6 2.39-6 ii libglib2.0-0t64 2.81.1-3 ii libgstreamer-plugins-base1.0-0 1.24.6-1 ii libgstreamer1.0-0 1.24.6-1 ii libgstrtspserver-1.0-0 1.24.6-1 ii libgtk-4-1 4.14.4+ds-8 ii libjson-glib-1.0-0 1.8.0-2+b1 ii libnm0 1.48.6-1 ii libportal-gtk4-10.7.1-5+b1 ii libportal1 0.7.1-5+b1 ii libprotobuf-c1 1.4.1-1+b2 ii libpulse-mainloop-glib0 16.1+dfsg1-5.1 ii libpulse0 16.1+dfsg1-5.1 ii libsoup-3.0-0 3.4.4-5+b1 ii network-manager 1.48.6-1 pn wpasupplicant gnome-network-displays recommends no packages. gnome-network-displays suggests no packages.
Bug#1072425: k3b: FTBFS with ffmpeg 7.0: k3bf fmpegwrapper.cpp:143:26: error: ‘AVCodecContext’ {aka ‘struct AVCodecContext’} has no member named ‘channels’ xt’ {aka ‘struct AVCodecContext’} has n o m
On dinsdag 23 juli 2024 17:56:34 CEST you wrote:
> > during a rebuild of the reverse dependencies for the transition to
> > ffmpeg 7.0, your package failed to build
>
> In the upstream git repo there are 2 commits on 2024-04-13 which probably do
> fix the FTBFS issue, but don't make it compatible with ffmpeg 7.0. F.e. it
> now just returns '0' for the number of channels with ffmpeg 7.0, while it
> does return the actual value when < 7.0 ...
>
> So, linking to those commits seems pointless.
No offense, but I don't consider the following a solution:
```
int K3bFFMpegFile::channels() const
{
#if LIBAVCODEC_VERSION_MAJOR < 61
return d->codecContext->channels;
#else
#pragma Unimplemented
return 0;
#endif
}
```
(Upstream commits 712ef4adc992 + 071535a79c3d)
I'm sure it does fix the FTBFS problem, so this is just to inform users
if they care about it.
signature.asc
Description: This is a digitally signed message part.
Bug#972396: Comment on «initramfs-tools: Installation fails (no space left on device)»
On Wednesday, 31 July 2024 16:37:48 CEST Pascal Hambourg wrote: > On 31/07/2024 at 00:38, Thomas Hahn wrote: > > On Fri, 26 Jul 2024 14:00:51 +0200 Pascal Hambourg > > > > wrote: > > > firmware-nvidia-graphics was installed on systems which already had > > > firmware-misc-nonfree because firmware-misc-nonfree recommends > > > firmware-misc-nonfree so that systems which rely on Nvidia firmware are > > > not disrupted. > > > > Is it possible to only install it on systems, which have a NVIDIA > > graphics card? > > Maybe firmware-misc-nonfree could check if a Nvidia GPU is present then > trigger installation of firmware-nvidia-graphics instead of recommending > firmware-nvidia-graphics. Sounds quite convoluted. Sounds more like a recipe for disaster. Just uninstall the recommended packages you don't need. signature.asc Description: This is a digitally signed message part.
Bug#1075633: wasmedge: ftbfs with GCC-14
On Wed, 03 Jul 2024 12:47:52 + Matthias Klose wrote:
> Package: src:wasmedge
> Version: 0.13.5+dfsg-1
> Usertags: ftbfs-gcc-14
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/wasmedge_0.13.5+dfsg-1_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
Those last lines don't contain the error though, but the build log does:
```
[ 34%] Building CXX object lib/aot/CMakeFiles/wasmedgeAOT.dir/cache.cpp.o
cd /<>/obj-x86_64-linux-gnu/lib/aot && /usr/bin/c++ -DFMT_SHARED
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB
-I/<>/obj-x86_64-linux-gnu/include
-I/<>/thirdparty/blake3 -I/<>/include
-I/<>/obj-x86_64-linux-gnu/lib/system -isystem
/usr/lib/llvm-16/include -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden
-fno-exceptions -Wall -Wextra -Werror -Wno-error=pedantic
-Wno-error=dangling-reference -Wno-psabi -MD -MT
lib/aot/CMakeFiles/wasmedgeAOT.dir/cache.cpp.o -MF
CMakeFiles/wasmedgeAOT.dir/cache.cpp.o.d -o
CMakeFiles/wasmedgeAOT.dir/cache.cpp.o -c /<>/lib/aot/cache.cpp
In file included from /usr/include/c++/14/vector:66,
from /usr/include/c++/14/functional:64,
from /usr/include/spdlog/common.h:16,
from /usr/include/spdlog/spdlog.h:12,
from /<>/include/common/log.h:18,
from /<>/include/common/enum_errcode.hpp:18,
from /<>/include/common/errcode.h:16,
from /<>/include/loader/filemgr.h:17,
from /<>/lib/loader/filemgr.cpp:4:
In destructor ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp =
unsigned char; _Alloc = std::allocator]’,
inlined from ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = unsigned
char; _Alloc = std::allocator]’ at
/usr/include/c++/14/bits/stl_vector.h:738:7,
inlined from ‘constexpr void std::_Optional_payload_base<_Tp>::_M_destroy()
[with _Tp = std::vector]’ at /usr/include/c++/14/optional:283:35,
inlined from ‘constexpr void std::_Optional_payload_base<_Tp>::_M_reset()
[with _Tp = std::vector]’ at /usr/include/c++/14/optional:314:14,
inlined from ‘constexpr void std::_Optional_base_impl<_Tp, _Dp>::_M_reset()
[with _Tp = std::vector; _Dp =
std::_Optional_base, false, false>]’ at
/usr/include/c++/14/optional:466:53,
inlined from ‘std::enable_if_t<((bool)is_constructible_v<_Tp, _Args ...>),
_Tp&> std::optional<_Tp>::emplace(_Args&& ...) [with _Args =
{std::vector >}; _Tp =
std::vector]’ at /usr/include/c++/14/optional:915:18,
inlined from ‘WasmEdge::Expect
WasmEdge::FileMgr::setCode(std::vector)’ at
/<>/lib/loader/filemgr.cpp:52:21:
/usr/include/c++/14/bits/stl_vector.h:369:59: error:
‘((std::_Vector_base
>*)((char*)this + 8))[2].std::_Vector_base >::_M_impl.std::_Vector_base >::_Vector_impl::std::_Vector_base >::_Vector_impl_data.std::_Vector_base >::_Vector_impl_data::_M_start’ may be used
uninitialized [-Werror=maybe-uninitialized]
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ^~~~
/usr/include/c++/14/bits/stl_vector.h:369:31: error:
‘((std::_Vector_base
>*)((char*)this + 8))[2].std::_Vector_base >::_M_impl.std::_Vector_base >::_Vector_impl::std::_Vector_base >::_Vector_impl_data.std::_Vector_base >::_Vector_impl_data::_M_end_of_storage’
may be used uninitialized [-Werror=maybe-uninitialized]
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ^
cc1plus: all warnings being treated as errors
make[3]: *** [lib/loader/CMakeFiles/wasmedgeLoaderFileMgr.dir/build.make:79:
lib/loader/CMakeFiles/wasmedgeLoaderFileMgr.dir/filemgr.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
```
HTH
signature.asc
Description: This is a digitally signed message part.
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
Control: reopen -1 Control: retitle -1 Please extend NEWS to clarify what users can and should do On Saturday, 27 July 2024 11:30:37 CEST Dan Jacobson wrote: > Yes. The news item needs to warn: > > ** Warning: if you take no action, upon the next boot you might > 1. Not be able to network. > 2. Not be able to see your screen. > 3. Not be able to boot. > and thus unable to install the new packages to fix it too. > Therefore be sure to install the new packages ... now, unless you are > sure you know what you are doing. I guess it won't hurt to expand the NEWS item to: - Make sure users have installed the Recommended packages they need - Inform them that they can remove the automatically installed Recommended packages they don't need (which may help with the initramfs-tools bug in 0.142 and the IMO too small default /boot partition) signature.asc Description: This is a digitally signed message part.
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
On Saturday, 27 July 2024 10:54:22 CEST Dan Jacobson wrote: > That's exactly what happened to me. > Not all users automatically install recommends. Those users are ofc allowed to make that choice, but they then also accept the consequences that go with it. What you asked for is exactly how it was implemented: misc-nonfree Recommends all the packages where firmware files which were in misc-nonfree before, but are now in one of the new packages. Which allows them to remove the Recommended packages they don't need. Next to the Recommends solution, you should have also received/seen a NEWS item, which explains what to do in the new situation. Did you not receive/see that? Or was the text unclear? signature.asc Description: This is a digitally signed message part.
Bug#1076372: Re.: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels
Control: found -1 6.3.7-1 On Friday, 26 July 2024 10:49:00 CEST Stefan wrote: > The complete sentence is: > > oldest non-working kernel is 6.3.7 (package linux-image-6.3.0-1-amd64), > 6.3.5 (latest version of package package linux-image-6.3.0-0-amd64) works. Excellent, that narrows down the 'suspect list' to 332 commits. me@pc:~/dev/kernel.org/linux$ git log --oneline v6.3.5..v6.3.7 | grep "ext4: " 9ca777c1ef9a ext4: enable the lazy init thread when remounting read/write 8664693a8ff2 ext4: add lockdep annotations for i_data_sem for ea_inode's 9d993659ed77 ext4: disallow ea_inodes with extended attributes 982f2501e753 ext4: set lockdep subclass for the ea_inode in ext4_xattr_inode_cache_find() 2f1dace530e8 ext4: add EA_INODE checking to ext4_iget() And those are all pretty close to the v6.3.7 tag: $ git log --oneline 2f1dace530e8..v6.3.7 | wc -l 28 Hopefully this means there a fast/short `git bisect` possible ... signature.asc Description: This is a digitally signed message part.
Bug#1076617: installation-guide: Severely outdated information wrt partitioning
On Thursday, 25 July 2024 20:50:23 CEST Holger Wansing wrote: > Diederik de Haas wrote (Tue, 23 Jul 2024 22:14:46 > +0200): > > > > >Or as I phrased it in https://bugs.debian.org/1076582#27 : > > > > >"Maybe that document should be updated for this CENTURY?" > > > > > > I have prepared a patch, to update the installation-guide (attached), > > > mostly a removal of outdated / no longer needed information. > > > > Much better! > > > > It may be possible to improve/extend the information further, but that > > could happen another time (too). > > The real problematic parts are gone now, so thanks for that :-) > > Just pushed to git. Thanks! signature.asc Description: This is a digitally signed message part.
Bug#1077049: libliftoff: Updated debian/watch file
On 25 Jul 2024 16:35:40 +0200 Diederik de Haas wrote: > Source: libliftoff > Version: 0.4.1-1 > Severity: minor > Tags: patch > > https://tracker.debian.org/pkg/libliftoff reported it had a problem with > finding a new upstream release, which does exist, so I updated the > ``debian/watch`` file so that it now does find new versions. > > When running ``uscan`` it does report the following: > > ``` > uscan warn: Possible OpenPGP signature found at: > > https://gitlab.freedesktop.org/emersion/libliftoff/-/tags-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc Updated patch which results in a (slightly) better output, attached. ``` => Newer package available from: => https://gitlab.freedesktop.org/emersion/libliftoff/-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2 uscan warn: Possible OpenPGP signature found at: https://gitlab.freedesktop.org/emersion/libliftoff/-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch * Add debian/upstream/signing-key.asc. ```>From b54309239a510a4a5e1574f17bf42fd25f8a961b Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Thu, 25 Jul 2024 16:27:11 +0200 Subject: [PATCH] d/watch: Update uscan params https://tracker.debian.org/pkg/libliftoff reported the following issue: "Problems while searching for a new upstream version" And it (apparently) didn't notice version 0.5.0 was released. With the new uscan parameters it does find the new version. --- debian/watch | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index dc3a39f..3bb3cc7 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,4 @@ version=4 -https://gitlab.freedesktop.org/emersion/libliftoff/-/tags archive/v?@ANY_VERSION@/.*@ARCHIVE_EXT@ +opts="searchmode=plain" \ + https://gitlab.freedesktop.org/emersion/@PACKAGE@/-/tags \ + archive/v?@ANY_VERSION@/@PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@ -- 2.45.2 signature.asc Description: This is a digitally signed message part.
Bug#1077049: libliftoff: Updated debian/watch file
Source: libliftoff Version: 0.4.1-1 Severity: minor Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 https://tracker.debian.org/pkg/libliftoff reported it had a problem with finding a new upstream release, which does exist, so I updated the ``debian/watch`` file so that it now does find new versions. When running ``uscan`` it does report the following: ``` uscan warn: Possible OpenPGP signature found at: https://gitlab.freedesktop.org/emersion/libliftoff/-/tags-/archive/v0.5.0/libliftoff-v0.5.0.tar.bz2.asc * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch * Add debian/upstream/signing-key.asc. ``` I did NOT add the upstream signing key or add ``uscan``'s suggestion for additional parameters. Cheers, Diederik - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZqJivAAKCRDXblvOeH7b bm2uAQDJoeaXr3Zm4gVKabqT4uP/mVDS4SSOcBI2YJi023EPlAD9HwJo0YKGVr2D /DbZn+1NV9JGblhXtiNNm9HIiM58dgA= =roS1 -END PGP SIGNATURE- >From 7a8628f6bad0dcbaeac7d34e92e7828c358bab5c Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Thu, 25 Jul 2024 16:27:11 +0200 Subject: [PATCH] d/watch: Update uscan params https://tracker.debian.org/pkg/libliftoff reported the following issue: "Problems while searching for a new upstream version" And it (apparently) didn't notice version 0.5.0 was released. With the new uscan parameters it does find the new version. --- debian/watch | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index dc3a39f..80eefa5 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,4 @@ version=4 -https://gitlab.freedesktop.org/emersion/libliftoff/-/tags archive/v?@ANY_VERSION@/.*@ARCHIVE_EXT@ +opts="searchmode=plain" \ + https://gitlab.freedesktop.org/emersion/@PACKAGE@/-/tags \ + -/archive/v?@ANY_VERSION@/@PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@ -- 2.45.2
Bug#1075180: libliftoff: ftbfs with GCC-14
Control: tag -1 upstream fixed-upstream patch
On Wed, 03 Jul 2024 12:33:34 + Matthias Klose wrote:
> Package: src:libliftoff
> Version: 0.4.1-1
> Usertags: ftbfs-gcc-14
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
https://gitlab.freedesktop.org/emersion/libliftoff/-/merge_requests/78 is the
upstream MR which fixes that issue. It has been merged and is part of the 0.5.0
release, which the tracker (apparently) doesn't see, but was tagged on
2024-05-28.
So the best solution seems to package version 0.5.0?
Alternatively, you can add the attached patch.
https://salsa.debian.org/diederik/libliftoff/-/tree/gcc-14-compat
can also be turned into a MR and via that you can see it does build
successfully with GCC-14, while without it, the build failed.
HTH,
Diederik>From 29a06add8ef184f85e37ff8abdc34fbaa2f4ee1e Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich
Date: Thu, 21 Dec 2023 20:15:29 +
Subject: [PATCH] layer.c: fix build against upcoming `gcc-14` (`-Werror=calloc-transposed-args`)
`gcc-14` added a new `-Wcalloc-transposed-args` warning recently. It
detected minor infelicity in `calloc()` API usage in `libliftoff`:
../layer.c: In function 'liftoff_layer_create':
../layer.c:20:48: error: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in t
ument [-Werror=calloc-transposed-args]
20 | layer->candidate_planes = calloc(sizeof(layer->candidate_planes[0]),
|^
../layer.c:20:48: note: earlier argument should specify number of elements, later size of each element
---
layer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/layer.c b/layer.c
index 73a8186..6510ea7 100644
--- a/layer.c
+++ b/layer.c
@@ -17,8 +17,8 @@ liftoff_layer_create(struct liftoff_output *output)
return NULL;
}
layer->output = output;
- layer->candidate_planes = calloc(sizeof(layer->candidate_planes[0]),
- output->device->planes_cap);
+ layer->candidate_planes = calloc(output->device->planes_cap,
+ sizeof(layer->candidate_planes[0]));
if (layer->candidate_planes == NULL) {
liftoff_log_errno(LIFTOFF_ERROR, "calloc");
free(layer);
--
GitLab
signature.asc
Description: This is a digitally signed message part.
Bug#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&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1 > > 6.9.9-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1 > > 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=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&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=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&arch=powerpc&ver=6.8.12-1&stamp=1717278092&raw=1 > > - This same version failed to build on the first try. > > 6.9.7-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.7-1&stamp=1719538806&raw=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.
