Your message dated Thu, 29 May 2025 17:00:12 +0000
with message-id <e1ukgc0-00642s...@fasolo.debian.org>
and subject line Bug#1101733: fixed in linux 6.15-1~exp1
has caused the Debian Bug report #1101733,
regarding debian/templates/image.*.in: allow maint scripts in
/usr/share/kernel/*.d
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1101733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101733
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux
Version: 6.12.21-1
Severity: normal
Hello kernel team,
my last mail to debian-kernel list eight weeks ago has no replies. I'm sorry if
I have missed further discussions on this topic elsewhere. As upstream linux
6.14 (details below) was released last week, I'm moving this email thread to a
bug in the BTS so that it does not get lost. Here my original mail with a
summary of the situation:
Quoting Johannes Schauer Marin Rodrigues (2025-02-02 11:33:34)
> in an attempt to not step on anybody's foot again, let me try to use the
> mailinglist this time to discuss this topic. This is a follow up of this MR
> which is not ideal because it does in shell what I think should be part of
> run-parts from debianutils:
>
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1259
>
> as well as this MR which is better because it uses functionality available in
> debianutils since 5.21:
>
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1259
>
> Reading hooks from /usr/share/kernel is part of torvalds/linux.git since
> ac2c30f98f28a6606af89ce44bff77af5d558fe8 and I'd like to propose again to also
> add this functionality to the Debian kernel packaging.
>
> The transition plan would be to add support for reading /usr/share/kernel in
> addition to /etc/kernel in Trixie but forbid packages from relying on this
> interface (i.e. they are not allowed to ship files in /usr/share/kernel) for
> Trixie. This will allow one to backport packages from Forky to Trixie once
> Trixie is released. Starting with Forky, packages can rely on the kernel
> respecting hooks in /usr/share/kernel. To make this even safer, packages could
> still be forbidden from using this interface in Forky and only allowed to use
> it in Duke. In any case, I think the first step is for the kernel packaging to
> handle /usr/share/kernel.
>
> The idea behind this is to introduce a mechanism for packages to ship their
> hook scripts in /usr and allow the administrator to disable or override them
> in
> /etc. This mechanism is documented here:
> https://uapi-group.org/specifications/specs/configuration_files_specification/
>
> Shipping content in /etc instead of /usr is problematic for packages because
> package upgrades become a hassle in case the user changed the file in /etc. It
> is not anymore easy for packages to change or delete a maintainer script
> snippet without involving writing their own maintainer script magic. Other
> parts of Debian are also moving to the pattern of: vendor ships files in /usr
> and admin can override them in /etc if necessary. This change allows this for
> the kernel maintainer script snippets as well.
>
> Enabling this in the Debian linux kernel packaging would require to:
>
> - add a Depends on debianutils (>= 5.21)
> - call run-parts with /usr/share/kernel/... in addition to /etc/kernel/...
> maintainer scripts
>
> Since run-parts will throw an error if either of the directories is passed
> does
> not exist, either the linux-image-* package could ship these (empty)
> directories itself, or maintainer scripts could call run-parts with different
> directories depending on whether /usr/share/kernel/... or /etc/kernel/...
> directories exist or not.
>
> What do you think? What would you like me to do/provide next to move this
> topic
> forward?
The latest upstream release of linux 6.14 now includes commit
ac2c30f98f28a6606af89ce44bff77af5d558fe8:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac2c30f98f28a6606af89ce44bff77af5d558fe8
This means, that starting with linux 6.14, the builddeb packaging will look for
kernel hooks in /usr/share/kernel as well in addition to /etc/kernel. As a
result, packages in Debian derivatives or in 3rd party repositories might now
start placing their hooks into /usr/share/kernel instead. If users build
that software on their Debian installations or install these packages on their
Debian boxes, they will fail to work with the Debian linux packaging because
it only looks for hooks in /etc/kernel right now.
In https://salsa.debian.org/kernel-team/linux/-/merge_requests/1159 Bastian
Blank correctly pointed out that the hook mechanism is an unversioned
interface. This is why I brought up above argument. Since upstream linux Debian
packaging now supports /usr/share/kernel, the Debian kernel will stop to work
with packages that assume this interface to work.
I think it would make sense if the kernel package we ship with Trixie supports
that interface as people will start using /usr/share/kernel and they might
expect the kernel of their Debian stable box to support this. Doing this would
also mean that packages in Forky can start relying on this interface even
though it is unversioned because I guess we can assume that their kernel is at
least the version from Debian stable (Trixie)?
Please tell me if you would like to see patches from me that implement this.
Adding support for this is not very hard because run-parts in Trixie supports
multiple directories.
Thanks!
cheers, josch
signature.asc
Description: signature
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 6.15-1~exp1
Done: Salvatore Bonaccorso <car...@debian.org>
We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1101...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Salvatore Bonaccorso <car...@debian.org> (supplier of updated linux package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Thu, 29 May 2025 00:07:27 +0200
Source: linux
Architecture: source
Version: 6.15-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team <debian-ker...@lists.debian.org>
Changed-By: Salvatore Bonaccorso <car...@debian.org>
Closes: 1101733 1105865 1106070 1106135
Changes:
linux (6.15-1~exp1) experimental; urgency=medium
.
* New upstream release: https://kernelnewbies.org/Linux_6.15
- loop: don't require ->write_iter for writable files in loop_configure
(Closes: #1106070)
.
[ Uwe Kleine-König ]
* [armhf] Enable various kernel modules for the machines defined in the
device-trees st/stm32mp153c-lxa-tac-gen3,
st/stm32mp153c-lxa-fairytux2-gen1 and st/stm32mp153c-lxa-fairytux2-gen2
(Closes: #1105865)
.
[ Jianfeng Liu ]
* [loong64] drivers/gpu/drm/loongson: Enable DRM_LOONGSON as module
(Closes: #1106135)
.
[ Aurelien Jarno ]
* [riscv64] drivers/pinctrl: Enable PINCTRL_SOPHGO_SG2042 and
PINCTRL_SOPHGO_SG2044
* [riscv64] drivers/irqchip: Enable SOPHGO_SG2042_MSI
* [riscv64] drivers/pwm/Kconfig: Enable PWM_SOPHGO_SG2042 as module
.
[ Ben Hutchings ]
* d/rules: Include target suite as an input to gencontrol.py
* Move package revision and ABI name rules to configuration
* linux-image, linux-headers: Use linux-run-hooks instead of run-parts
(Closes: #1101733)
.
[ Salvatore Bonaccorso ]
* [s390x] udeb: Remove lcs from nic-modules (Fixes FTBFS on s390x)
.
[ Kevin P. Fleming ]
* test-patches: Add defaults for DEBEMAIL and DEBFULLNAME
Checksums-Sha1:
93038ed5a4bd1e08a1534bf3ada2c39a8a18c48d 192313 linux_6.15-1~exp1.dsc
1aab2111bc6118eab576d9fa51059388d0caa337 154223756 linux_6.15.orig.tar.xz
4584fb2264e2cc87d422505e5a56f4e9fdcd245a 1527556
linux_6.15-1~exp1.debian.tar.xz
7fa1ce41257f2a33ba36f7d5123089b8a36cb017 6632
linux_6.15-1~exp1_source.buildinfo
Checksums-Sha256:
487fb2fe7d882336f53760f547dc8d217fe0b82fa13f5882ba58e0e54eb93c4d 192313
linux_6.15-1~exp1.dsc
fc33809cd9d188375576fce43fef6441f80f2dcbad7ac4efcc153b6f32776f09 154223756
linux_6.15.orig.tar.xz
96a46628f290135c733055b658d76c58088f197f101d5dda622055eeb43c1776 1527556
linux_6.15-1~exp1.debian.tar.xz
a705bb06a79543c75d3187b25ecb81f318b7db4be58af2aa55d85f7a5726b3eb 6632
linux_6.15-1~exp1_source.buildinfo
Files:
982ffc17a2478cdf1db839c276e1271e 192313 kernel optional linux_6.15-1~exp1.dsc
9a6c160f0f86c700d9a0ef6562dd0ede 154223756 kernel optional
linux_6.15.orig.tar.xz
05625820397dc587e19b6a9bd9aeb55a 1527556 kernel optional
linux_6.15-1~exp1.debian.tar.xz
1e747a4b72e6388f8442482f75ca34fe 6632 kernel optional
linux_6.15-1~exp1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmg3jtlfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89E8gEQAIn1XwoA2M9yOa6W9astLCTf9ra45i6f
YOIJlzdknhx+MaSW68jiVJ0C6iwhzk3cLav9iqdwsgbv+/BsCiORApoJ51mvMC0T
dstj5TMGrhzQB0nby8Od6kZrGv1+PX6qvPvtqzjt4HJxinJiAMtslWvrHiFaXnDr
teetQBvRLip7dPcpNXCmX7u8K3JKtdWiOcgELsiqEs4m2Ugtwdt/A3P0HQL543Hs
7nCjfPI3m9bYgLQizxiCwtcGwtJDmLTHklFusoXErbEzqucZdp2EIEA/JuG66vwy
LR+4OgtoNwr5btU4aiVQNnyr9/VHdoYkgxvmT53DggCzaIbAWYIsnQ9jzNYSHSGO
Ej6LF5OYNoB+K3W3TO0q08Xk8m6qsUheX8lWH7ifiMJjNOrIjgSI8ep2prm8cO22
OtbgW10SjN4V1Qw/4HXa/Le6DnkYeIgKlk355Ho4vRH8dMQiT8jqqy2rsa3t3Xef
/djJoPEz9N3aVm0uiwImwsPP3ch7qAfvGVxg9V7WpsAXUblIeeflztDB5fo875Q+
crPsuHEAKGGfoewFAxU9C37sBIZJOmpz8cFAmMdTV0LHlxMWFs4gsRPPthb8y2S1
vQszatsC9YsolzpWc5RkzpSexWdjMOI/VE9FIGHfr2ExPp+AMcDq3Icj3uEYsfzH
hFRrzl2Y+WBm
=nJ9/
-----END PGP SIGNATURE-----
pgpCc0lFjKjsC.pgp
Description: PGP signature
--- End Message ---
