Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap
Hi, I skipped replying here earlier, because I felt like I would not add any content. Stefano indicated that my impression was wrong. Hence replying now. On Thu, Oct 24, 2024 at 01:31:32AM +0200, Ben Hutchings wrote: > On Sat, 2024-10-19 at 18:15 +0200, Helmut Grohne wrote: > > Hi Bastian, > > > > On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote: > [...] > > > > > But now you can have a port without hand patched linux that is built in > > > a non-standard way and relying on internal and unstable package API, > > > just be talking and getting it added to the package first. > > > > Fair enough. Please add arc, cksy, mipsr6el, sh3, sparc, and > > musl-linux-any. Thanks in advance. In retrospect, the use of irony was not the best of moves here as it did not add clarity to a discussion that was already heated. I'm sorry about that. > We would need to know the multiarch triplet for csky. Yes, exactly. Let me reiterate the reasons for why I prefer a different solution here. * In general terms, the multiarch triplet is something that can change (and has changed) during the early phase of an architecture bootstrap. * When an architecture becomes available in toolchain packages, it is not clear whether it takes off. or1k very much looked like the next thing and now it is deleted. The story for tilegx is similar. Initially, riscv64 looked a lot like or1k. In not adding these to src:linux (and removing them later), we avoid a pile of unnecessary interaction. The excessive addition of architectures also interacts with #1081826. * It is very useful to locally add a new architecture and try a bootstrap to give feedback to upstreams as to what piece is missing. Not requiring src:linux to cooperate significantly speeds up this evaluation process. I generally see src:linux as one of the later pieces relevant to architecture cross bootstrap in the sense that while it is one of the earliest packages needed for its headers, adding real support is often delayed, because too many out-of-tree patches are required during the initial bootstrap phase and thus everyone uses a self-built vendor kernel there. Automatically modifying src:linux is quite feasible. It has changed a couple of times and now roughly looks like this: cat >debian/config.local/defines.toml >/dev/null <
Processing of iproute2_6.12.0-1~bpo12+1_source.changes
iproute2_6.12.0-1~bpo12+1_source.changes uploaded successfully to localhost along with the files: iproute2_6.12.0-1~bpo12+1.dsc iproute2_6.12.0-1~bpo12+1.debian.tar.xz iproute2_6.12.0-1~bpo12+1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
iproute2_6.12.0-1~bpo12+1_source.changes ACCEPTED into stable-backports
Thank you for your contribution to Debian. Mapping bookworm-backports to stable-backports. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 28 Nov 2024 12:54:10 + Source: iproute2 Architecture: source Version: 6.12.0-1~bpo12+1 Distribution: bookworm-backports Urgency: medium Maintainer: Debian Kernel Team Changed-By: Luca Boccassi Changes: iproute2 (6.12.0-1~bpo12+1) bookworm-backports; urgency=medium . * Rebuild for bookworm-backports. . iproute2 (6.12.0-1) unstable; urgency=medium . [ Carles Pina i Estany ] * Update translations . [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.12.0' Checksums-Sha1: 597f2aa6ca6d8588f76505933c26e889567df348 2319 iproute2_6.12.0-1~bpo12+1.dsc adc94a74d539412d95426544469297b2ef8da7f4 39772 iproute2_6.12.0-1~bpo12+1.debian.tar.xz 01f3c0e2c81a19d65c44b2239e4d314e42413b44 6708 iproute2_6.12.0-1~bpo12+1_source.buildinfo Checksums-Sha256: 6d169f3a2cb3dd3397262ce8799a6dbb68bd538d5c0b2d197e932951580e 2319 iproute2_6.12.0-1~bpo12+1.dsc b8256765b83a425d31f0b268657cfb6002859762755219e6e2c4fb0cfcbaa541 39772 iproute2_6.12.0-1~bpo12+1.debian.tar.xz d999c0df7cf4fc257d76b1957bbf83997a87db6d3e0b72be449db4fa3b64cdbb 6708 iproute2_6.12.0-1~bpo12+1_source.buildinfo Files: bb5292bacca3327878bce357c5bcf5ad 2319 net optional iproute2_6.12.0-1~bpo12+1.dsc c37f731bc42e64b6e0026fc42720 39772 net optional iproute2_6.12.0-1~bpo12+1.debian.tar.xz e486ed947199d76e3df43f7c2d8524ee 6708 net optional iproute2_6.12.0-1~bpo12+1_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEErCSqx93EIPGOymuRKGv37813JB4FAmdIcIQRHGJsdWNhQGRl Ymlhbi5vcmcACgkQKGv37813JB5LzRAAxLp0u0wW3scQ+fJUwFX71FFl/ODfbMzs dMSwXEYJHIHGa+OU8IKcXTOcDQT/XRETWqcocNZielNwW1Z/busoGEfgS9Rcv7vg iBezrZ2gbfgDrJAFZYS+A3Tj1x0ZyyAQJxrvkVRcAjeEA5vgLnqnLRT6D73fOC/X Uo0soXhBrLlor7DZIgEaDHThma3onxinnQPjfliMWnb5cNu8xSQCG6s0xe38gk/n L3WxwZM7Fex3lkxEa3YQIBnIApF8ZWuCvdrNJe0QFK7xIZHtk2r8NgGD957k0zHQ JZ0jTs7c4oXLWJFCJJUnRnjXor4ip9i4lsxo2vlTdHAh4qOr0W3azJA8pQsWbnV7 UgukwrUf5MX4GhNck+/501f2DCuYQbHzhWnz5ak1AjnJyv0CA0X5YB6nv4EXd2F7 OxmETwoTShs3etK9ZGmwQ1TO4KPmN1jDqqNl7U1mG7l1JCW0owu7kxfirbXTBT70 rBX3K6uVjQm77CYvVyGKYPpS2jHBQWpQ/L9NEbxpm6fE9V9Xd7XTooJd1mmrjdBn 2Oj6FPvUnnreoAdQky91BHOugz+LKzoljz4ue0HnZb5RTzaFnO4V1BHGf0Be0+pG 72Qw8UJrzshlFtoFN4m1ZFwx4YDA4JFSITz7G4avMhrPTqX6D9tywwqEOHcjae+N 6+kOqiCOqms= =06KE -END PGP SIGNATURE- pgpHtsZdpQmMY.pgp Description: PGP signature
Bug#1087616: linux-image-6.11.7-amd64: Can't boot (boot freezes after [or maybe during] cryptsetup unlocks drive)
Dear Salvatore, that seems to be a wired thing!? No matter of temporarily within grub bootmenu e and F10 or permanently by changing /etc/default/grub and update-grub, as soon I replace kernel parameter quit by -- systemd.log_level=debug the system boots successfully on ever trie. I did more than 25 boots (warm and cold) and every single one was successfull then. On the first boot after restoring the default boot parameters and booting, the system has run into the hang situation again :( Also in some few cases where I only did remove quit (and not adding -- systemd.log_level=debug ), this suffices for correct booting. Can this be by coincidence, or timing behaviour/race conditions? Chris
Re: Bug#1065416: Bastian's offer in #1065416
Hi Ben (2024.09.19_16:08:07_-0400) > This change is included in version 6.11-1~exp1 which I am uploading to > experimental. Thanks for defusing the archive breakage with that upload. I've taken on the role of moderating this bug for the tech-ctte. So, I'll be reporting on it in the monthly tech-ctte meetings, and pinging people, when I see conversation stalling. I took this on 2 months ago, and then ignored the bug since then, sorry about that. :/ Now the next questions are where we want to go next. For those following this bug, I see a few concerns being raised: #1081826: linux-libc-dev ships header files not needed for 99% of it's users #1084908: arch:all linux-libc-dev causes problems to architecture bootstrap I think the main discussion of how to structure this package is now continuing in #1084908. We seem to be making some progress in understanding each others needs in there, although it has now stalled a month ago. Helmut: it looks like #1081826 is waiting on you for some replies. Ben, Bastian: #1081826 could benefit with a reply from the kernel team. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
