Bug#1069572: firmware-nonfree: activate update-initramfs trigger declaratively
Source: firmware-nonfree Version: 20230625-2 Severity: wishlist Tags: patch This is the same bug as #1069571 (firmware-linux-free). The update-initramfs trigger is activated procedurally and in postinst only. Hence, removing a firmware package does not update the initramfs. I propose activating the trigger declaratively to have dpkg figure out when to activate. Helmut diff -Nru firmware-nonfree-20230625/debian/changelog firmware-nonfree-20230625/debian/changelog --- firmware-nonfree-20230625/debian/changelog 2023-12-19 18:01:10.0 +0100 +++ firmware-nonfree-20230625/debian/changelog 2024-04-20 18:11:28.0 +0200 @@ -1,3 +1,10 @@ +firmware-nonfree (20230625-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Activate update-initramfs trigger declaratively. (Closes: #-1) + + -- Helmut Grohne Sat, 20 Apr 2024 18:11:28 +0200 + firmware-nonfree (20230625-2) unstable; urgency=medium [ Diederik de Haas ] diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst --- firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 2023-12-19 18:01:10.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 1970-01-01 01:00:00.0 +0100 @@ -1,19 +0,0 @@ -#!/bin/sh - -set -e - -case "$1" in - configure) - dpkg-trigger --no-await update-initramfs - ;; - - abort-upgrade|abort-remove|abort-deconfigure) - ;; - - *) - echo "postinst called with unknown argument \`$1'" 1>&2 - exit 1 - ;; -esac - -#DEBHELPER# diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers --- firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 1970-01-01 01:00:00.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 2024-04-20 18:11:28.0 +0200 @@ -0,0 +1 @@ +activate-noawait update-initramfs diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.postinst firmware-nonfree-20230625/debian/firmware-bnx2.postinst --- firmware-nonfree-20230625/debian/firmware-bnx2.postinst 2023-12-19 18:01:10.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-bnx2.postinst 1970-01-01 01:00:00.0 +0100 @@ -1,19 +0,0 @@ -#!/bin/sh - -set -e - -case "$1" in - configure) - dpkg-trigger --no-await update-initramfs - ;; - - abort-upgrade|abort-remove|abort-deconfigure) - ;; - - *) - echo "postinst called with unknown argument \`$1'" 1>&2 - exit 1 - ;; -esac - -#DEBHELPER# diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.triggers firmware-nonfree-20230625/debian/firmware-bnx2.triggers --- firmware-nonfree-20230625/debian/firmware-bnx2.triggers 1970-01-01 01:00:00.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-bnx2.triggers 2024-04-20 18:11:28.0 +0200 @@ -0,0 +1 @@ +activate-noawait update-initramfs diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.postinst firmware-nonfree-20230625/debian/firmware-bnx2x.postinst --- firmware-nonfree-20230625/debian/firmware-bnx2x.postinst2023-12-19 18:01:10.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-bnx2x.postinst1970-01-01 01:00:00.0 +0100 @@ -1,19 +0,0 @@ -#!/bin/sh - -set -e - -case "$1" in - configure) - dpkg-trigger --no-await update-initramfs - ;; - - abort-upgrade|abort-remove|abort-deconfigure) - ;; - - *) - echo "postinst called with unknown argument \`$1'" 1>&2 - exit 1 - ;; -esac - -#DEBHELPER# diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.triggers firmware-nonfree-20230625/debian/firmware-bnx2x.triggers --- firmware-nonfree-20230625/debian/firmware-bnx2x.triggers1970-01-01 01:00:00.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-bnx2x.triggers2024-04-20 18:11:28.0 +0200 @@ -0,0 +1 @@ +activate-noawait update-initramfs diff -Nru firmware-nonfree-20230625/debian/firmware-cavium.postinst firmware-nonfree-20230625/debian/firmware-cavium.postinst --- firmware-nonfree-20230625/debian/firmware-cavium.postinst 2023-12-19 18:01:10.0 +0100 +++ firmware-nonfree-20230625/debian/firmware-cavium.postinst 1970-01-01 01:00:00.0 +0100 @@ -1,19 +0,0 @@ -#!/bin/sh - -set -e - -case "$1" in - configure) - dpkg-trigger --no-await update-initramfs - ;; - - abort-upgrade|abort-remove|abort-deconfigure) - ;; - - *) - echo "postinst called with unknown argument \`$1'" 1>&2 - exit 1 - ;; -esac - -#DEBHELPER# diff -Nru firmware-nonfree-20230625/debian/firmw
Bug#1069571: firmware-linux-free: activate update-initramfs trigger declaratively
Package: firmware-linux-free Version: 20200122-4 Severity: wishlist Tags: patch Removing firmware-linux-free does not activate the update-initramfs trigger. This is due to being done procedurally in postinst without matching postrm. I propose using declarative activation let dpkg figure out when to activate the trigger. Helmut diff -Nru firmware-free-20200122/debian/changelog firmware-free-20200122/debian/changelog --- firmware-free-20200122/debian/changelog 2024-02-18 20:56:32.0 +0100 +++ firmware-free-20200122/debian/changelog 2024-04-20 17:27:53.0 +0200 @@ -1,3 +1,10 @@ +firmware-free (20200122-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Activate trigger declaratively. (Closes: #-1) + + -- Helmut Grohne Sat, 20 Apr 2024 17:27:53 +0200 + firmware-free (20200122-4) unstable; urgency=medium * Update to linux-support 6.6.15 diff -Nru firmware-free-20200122/debian/firmware-linux-free.postinst firmware-free-20200122/debian/firmware-linux-free.postinst --- firmware-free-20200122/debian/firmware-linux-free.postinst 2024-02-18 20:56:32.0 +0100 +++ firmware-free-20200122/debian/firmware-linux-free.postinst 1970-01-01 01:00:00.0 +0100 @@ -1,19 +0,0 @@ -#!/bin/sh - -set -e - -case "$1" in - configure) - dpkg-trigger --no-await update-initramfs - ;; - - abort-upgrade|abort-remove|abort-deconfigure) - ;; - - *) - echo "postinst called with unknown argument \`$1'" 1>&2 - exit 1 - ;; -esac - -#DEBHELPER# diff -Nru firmware-free-20200122/debian/firmware-linux-free.triggers firmware-free-20200122/debian/firmware-linux-free.triggers --- firmware-free-20200122/debian/firmware-linux-free.triggers 1970-01-01 01:00:00.0 +0100 +++ firmware-free-20200122/debian/firmware-linux-free.triggers 2024-04-20 17:27:36.0 +0200 @@ -0,0 +1 @@ +activate-noawait update-initramfs
Bug#1065214: NMU iproute2
Control: tags -1 + pending Hi Luca, this bug causes issues to /usr-move. iproute2 pulls libtirpc3 and nothing pulls libtirpc3t64. Hence, the we still include libtirpc3, which is aliased rather than libtirpc3t64, which is /usr-moved. To fix this, I'd need a binNMU of iproute2, but this bug would cause that binNMU to be broken. Hence, I rather fix this bug. I used reproducible builds to see that iproute2 really only uses tirpc and not nsl. Hence I'm uploading the simple fix of explicitly depending on libtirpc-dev. NMU diff attached. No delay in accordance with DevRef (rc bug older than 7 days with no maintainer activity). Helmut diff -Nru iproute2-6.7.0/debian/changelog iproute2-6.7.0/debian/changelog --- iproute2-6.7.0/debian/changelog 2024-01-22 13:24:29.0 +0100 +++ iproute2-6.7.0/debian/changelog 2024-03-12 09:03:30.0 +0100 @@ -1,3 +1,10 @@ +iproute2 (6.7.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Explicitly depend on libtirpc-dev. (Closes: #1065214) + + -- Helmut Grohne Tue, 12 Mar 2024 09:03:30 +0100 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output diff -Nru iproute2-6.7.0/debian/control iproute2-6.7.0/debian/control --- iproute2-6.7.0/debian/control 2024-01-12 22:09:28.0 +0100 +++ iproute2-6.7.0/debian/control 2024-03-12 09:02:10.0 +0100 @@ -22,6 +22,7 @@ libelf-dev, libmnl-dev, libselinux1-dev, + libtirpc-dev, linux-libc-dev, pkg-config, po-debconf,
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > Arguably, a cross toolchain build should probably search > > /usr/include/. I went back and forth a bit with Matthias > > about whether we could add this and did not fully understand his > > reasons, but there is one technical reason we want to avoid it for now. > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > and these packages can have differing versions. When that happens and we > > search both /usr//include and /usr/include/, we'd > > mix two glibc versions with usually bad results (been there). > > But this is a search path. If a file exists in one, the second one is > not found. So nothing can happen even from version skew. The problem arises in the reverse sense. If a file does not exist in one, it is searched in the second and erroneously may be found. That may make tests pass that should not pass and typically causes a link failure later. While I do not have a concrete example at hand, I have seen this pattern repeatedly and generally favour moving stuff out of /usr/include to avoid this kind of confusion that causes difficult to debug problems. This also motivates #798955 (in addition to the problem with file conflicts). > > The other aspect here is that it is not sufficient to add > > /usr/include/ to the search path as you also need > > /usr/include to get a complete linux kernel headers experience. We > > definitely do not want to add /usr/include, because that is known to > > misguide configure tests performed for the target architecture. > > We are talking about the toolchain itself. What configure tests could > that be? Or is that premature optimization of the gcc build? The one case I really do remember quite well is sanitizers. These should not be enabled in the earlier toolchain stages and failing to disable them tends to cause linker failures. I don't think it matches the concrete situation exactly though. You also make a good case in your followup reporting that gcc-13-cross actually builds. > You just said that the search path used during the build of the > toolchain and the one for everything else are unrelated. So you are > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > linux. > > The toolchain as installed already finds all headers. So I still don't > see why we need this in the final system. I find this argument fairly convincing and hope Matthias also does. Thank you Helmut
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote: > On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > > On 04.03.24 11:29, Bastian Blank wrote: > > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > > > Please be a bit more precise, there are no symlinks in this directory. > > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > > | # find /usr/alpha-linux-gnu/include/ -type l > > > | # > > yes, that is the problem. the cross gcc expects these headers in > > /usr/alpha-linux-gnu/include, not in the header location for the host. > > Please show your problem with a log, my crystal ball is broken. This very much was not obvious to me either. I've now talked to Matthias and believe I can explain the problem. The packaged gcc cross toolchain uses a sysroot during its own build still. As it is implemented now, it searches /usr//include, but not /usr/include/. So quite fundamentally, the Provides that we two agreed do break the build of cross toolchains right now. Arguably, a cross toolchain build should probably search /usr/include/. I went back and forth a bit with Matthias about whether we could add this and did not fully understand his reasons, but there is one technical reason we want to avoid it for now. We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed and these packages can have differing versions. When that happens and we search both /usr//include and /usr/include/, we'd mix two glibc versions with usually bad results (been there). While we might consider adding /usr/include/ to the cross toolchain build search path later, it is not something we can do now and before doing that, we need to better understand Matthias' reasons for keeping these separate as well. The other aspect here is that it is not sufficient to add /usr/include/ to the search path as you also need /usr/include to get a complete linux kernel headers experience. We definitely do not want to add /usr/include, because that is known to misguide configure tests performed for the target architecture. In principle, we could extend the symlink farm in linux-libc-dev to also have a lot of /usr/include//linux -> ../linux symlinks (assuming that no other package ever installs to /usr/include/linux, which is a property violated by aufs-dev and oss4-dev). So at least for now, I am convinced that we will need /usr//include to be provided by the package providing linux-libc-dev-arch-cross. As these are only necessary for building the cross toolchains, we probably don't want these in the main linux-libc-dev package. So how about adding a linux-libc-dev-cross package with yet more symlinks? Then we can move the provides over to the linux-libc-dev-cross package and that way repair the cross toolchain builds. I requested that linux-libc-dev provides these for bootstrapping to know which architectures linux-libc-dev actually supports. I don't need these provides exactly, I just need a mechanism to answer the question "Does linux-libc-dev work for a particular architecture?" from the binary package metadata, so we might just change the Provides there to linux-libc-dev-arch dropping the -cross suffix that traditionally identified packages putting stuff into /usr/. Does that sound reasonable to you? That still leaves the question of which package would have to build that new linux-libc-dev-cross. The two obvious answers are linux and cross-toolchain-base. Do you have a preference here? I hope this all makes more sense now. Helmut
Bug#1063554: firmware-linux-free: move files to /usr (DEP17)
Package: firmware-linux-free
Version: 20200122-2
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
Hi,
we want to finalize the /usr-merge transition by moving all aliased
files from / to /usr via DEP17 to avoid any negative effects arising
from aliasing. firmware-linux-free is involved, because it installs
firmware files below /lib/firmware. Since it cannot be converted
automatically using dh-sequence-movetousr, I'm attaching a patch. This
patch should not be uploaded to bookworm-backports or earlier. Also note
that firmware-carl9170 is in the process of taking over firmware from
firmware-linux-free and doing so will cause a file loss (DEP17 P1). This
is tracked as #1050989. I do not expect that firmware-linux-free needs
to support firmware-carl9170 in mitigating this.
Helmut
diff --minimal -Nru firmware-free-20200122/debian/changelog
firmware-free-20200122/debian/changelog
--- firmware-free-20200122/debian/changelog 2023-08-20 21:56:54.0
+0200
+++ firmware-free-20200122/debian/changelog 2024-02-09 15:42:17.0
+0100
@@ -1,3 +1,10 @@
+firmware-free (20200122-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Move files to /usr (DEP17). (Closes: #-1)
+
+ -- Helmut Grohne Fri, 09 Feb 2024 15:42:17 +0100
+
firmware-free (20200122-2) unstable; urgency=medium
[ Ben Hutchings ]
diff --minimal -Nru firmware-free-20200122/debian/rules.real
firmware-free-20200122/debian/rules.real
--- firmware-free-20200122/debian/rules.real2023-08-20 21:39:29.0
+0200
+++ firmware-free-20200122/debian/rules.real2024-02-09 15:42:07.0
+0100
@@ -15,7 +15,7 @@
dh_prep
@for i in $(FILES); do \
s="$${i%:*}"; \
- d=/lib/firmware/"$${i#*:}"; \
+ d=/usr/lib/firmware/"$${i#*:}"; \
echo install -m644 -D "$$s" debian/$(PACKAGE_NAME)"$$d"; \
install -m644 -D "$$s" debian/$(PACKAGE_NAME)"$$d"; \
done
Bug#1058937: Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
On Fri, Jan 12, 2024 at 01:31:18PM +0100, Helmut Grohne wrote: > The relevant situation is not entirely trivial to construct: > > * Package $first contains an aliased file $file and this is moved to >package $second in an update. >OR >Package $first diverts aliased location $file normally owned by >package $second. > > * An update to package $second moves $file to its physical location >below /usr. > > * Package $second declares a versioned conflict for package $first with >any version that contains or diverts the aliased $file. > > Then we can construct a file loss scenario: > > * Install package $first. > * Schedule $first for removal: >echo "$first remove" | dpkg --set-selections > * Install the updated $second: >dpkg --unpack $second.deb I somehow missed how Ben's libnfsidmap bug #1058937 works slightly simpler. Given that $second has a conflict with the installed version of $first, one can skip that second step and instead install $second directly with dpkg -i. So no, this weird selections stuff is not technically necessary. In general, when doing these dances there are two outcomes. Either, $first is unpacked (or removed) before $second is unpacked or the other way round. The latter case always shows a message like this: dpkg: considering removing $first in favour of $second ... dpkg: yes, will remove $first in favour of $second It is these cases that exhibit the buggy behaviour. > In most upgrade scenarios, apt will remove/upgrade package $first before > performing the unpack of $second. In these cases, no loss happens. I tried to get an idea of what "most" means precisely. For one thing, I constructed various bullseye->bookworm and bookworm->unstable upgrades followed by dpkg --verify. This included large installations such as task-gnome-desktop with recommends and targeted cases where I hoped to find problems such as upgrading molly-guard or nfs-ganesha or and a few more. In none of the cases (where doing plain apt-get dist-upgrade), I was able to make dpkg --verify unhappy. Another route was searching for existing evidence. piuparts has lots of logs of upgrading packages and in >= bookworm, I found exactly one having that "yes, will remove" content. It was https://piuparts.debian.org/testing2sid/pass/rubber_1.6.0-2.log and that's due to texlive-base declaring a versioned Conflict with texlive-latex-base and texlive-latex-base declaring versioned Breaks with texlive-base. This is the mutual Conflicts case that also broke stuff in a draft patch for molly-guard. This data point confirms what David Kalnischkies said about this earlier: In the absence of mutual conflicts, apt removes $first before unpacking $second. I also tried a web search for "yes, will remove" and really most of logs I found, dpkg was used directly (though without --set-selections). That texlive mutual conflict was an exception. Evidently, this is rarely happening on real installations. > Therefore, I hope that the loss cannot be experienced when upgrading > with apt or frontends using apt such as aptitude, but there is no proof > of this. So all the evidence I found confirms the guess that the problem cannot be observed with apt unless mutual conflicts exist. On the flip side, simply installing a package that declares Conflicts occasionally triggers this and if you happen to do this to a package that replaces aliased files, then your files vanish. In particular, this raises the question whether we consider the upgrade that Ben describes in #1058937 as supported or whether we can close the bug. In effect, that's the question to ask here. I note that netplan.io/0.107.1-2/#1060661 just opted for not doing Conflicts and instead employed protective diversions (M8). In principle, we could generally prefer M8 (for P1, but not for P7) and thereby reduce the problem at the cost of making the mitigation more complex. At least for the essential set, there is not much choice as employing Conflicts is known to lead to bad things. > One takeaway from the CTTE meeting was that this loss should be > mitigated when it may make a system unbootable. That is a property that > is difficult to capture and would likely require mitigating half of the > conflicts. While this may seem like an obvious rule-of-thumb, it very much is not. For many of the packages, one can plausibly construct crazy boot schemes involving them. Though cryptsetup quite clearly falls within scope. > The way of mitigation also is non-trivial. In the window between unpack > of files that will be lost and actual loss, no maintainer script is run > reliably. Hence, copies of affected files have to be installed > elsewhere: > * systemd-sysv looses only symlinks whose target is specified in >postinst. > * gzip looses shell scripts that
Re: consolidate linux-libc-dev headers
Hi Dimitri and Bastian,
On Thu, Nov 16, 2023 at 06:28:13PM +, Dimitri John Ledkov wrote:
> Currently in both Debian and Ubuntu we ship like close to 40 .deb packages
> that have linux-libc-dev (for native/multiarch, cross, ports, mipses).
>
> Each one of them is like 1.5MB, however they actually all have the same and
> repeated content.
>
> the bulk of headers are the same on all arches (and enforced via
> multi-arch:same), asm-generic is also the same for all of them, and then
> kernel-arch asm headers are unique - but only for given kernel arches (not
> all of the debian arch names).
>
> Currently there are only 13 kernel archs for unique asm-arch headers, but
> in Debian we have multiple reuses of the same kernel archs with different
> userspace abi properties (arm = armel armhf, mips = 12 mips archs, powerpc
> = 4, x86 = 3, and so on).
>
> It seems wasteful on disk, build-time, and derivative build time to package
> all of these separately. Especially since there is a chain of src:linux
> building native ones + linux-source as a .deb; which is then used by
> cross-toolchain-base{,-ports,-mips} to unpack and rebuild linux headers
> again, and publish. When in practice src:linux itself could build an
> efficient libc-dev packages for all arches as an arch:all package and
> Multi-Arch:foreign.
Thanks for working on this. I would have appreciated copying
debian-cr...@lists.debian.org as I am not following d-kernel@l.d.o.
> The linux-libc-dev is native & multiarch uapi headers for all arches. The
> linux-libc-dev-alpha-cross is all debian arch crosses. It is implemented
> using hardlinks to maintain all the same paths that are currently being
> used by all the arch:any linux-libc-dev packages, and the
> linux-libc-dev-*-cross packages. In total they provide equivalent
> functionality as 40+ linux-libc-dev* current debs in either Debian or
> Ubuntu.
> Is this something that the debian kernel team could consider supporting /
> building as either standalone source package, or out of src:linux directly?
> as this would reduce 40+ .deb duplication in the mirror pools of the same
> content; and will eliminate build-depends on linux-source (and thus
> built-using) from src:cross-toolchain-base* and will actually ensure that
> all kernel headers for native / multiarch / cross arches are updated
> simultaneously, without need to wait for all arch:any builds to catch up
> first. It also gives ability to trivially create freestanding toolchains to
> any of the arches without actually building a full debian port for or
> having a working kernel for a given port.
I agree with this in principle, but I see a number of shortcomings and
hope you can address them.
When creating a new port, linux is one the pieces that comes first.
Hence building a new linux-lib-dev package was a natural with custom
changes was a very natural thing to do. Until now, we never needed to
build architecture-independent packages, so this is a noticeable
deviation. I'll be looking to support this in rebootstrap.
An example where this kinda fails is musl-linux-any. I'm still vaguely
trying to bootstrap this even though it kinda is stuck really hard on
musl vs systemd being unable to cooperate in any meaningful way. I'm not
sure it is reasonable to add these links the regular linux-libc-dev
package as 99% of people will never use them.
The same goes for esoteric architectures such as sh3, s390 (without x),
arc, loong64, and others.
I guess that the list of architectures will always be incomplete for
some, so we probably still need a process for building a modified
linux-libc-dev package only. This probably requires some build profiles.
Is pkg.linux.nokernel pkg.linux.notools pkg.linux.quick a sensible set
of profiles for this? Is there an easily patchable way to add an
architecture?
Let me also summarize how I see this change affecting various
infrastructure.
Bootstrapping will have to branch on whether the default linux-libc-dev
is usable and for many architectures it will be usable thus speeding up
bootstrap there.
For cross building we completely eliminate multi-arch skews of
linux-libc-dev that used to happen every so often. Cool.
For c-t-b, I guess that we can simply cut out linux-libc-dev and remove
all the -cross packages. I hope there is no devil in the detail.
So if the shortcomings end up having viable solutions, this seems like a
rather positive change to me.
Helmut
Bug#1058937: /usr-move: Do we support upgrades without apt?
Hi Matthew, On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote: > On 21/12/2023 09:41, Helmut Grohne wrote: > > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? Let me thank David for clarifying what "using apt" means in exactly the way I intended it. As a result, I think the only "no" reply, I've seen thus far is from Matthew here. > I incline towards "no"; if an upgrade has failed part-way (as does happen), > people may then reasonably use dpkg directly to try and un-wedge the upgrade > (e.g. to try and configure some part-installed packages, or try installing > some already-downloaded packages). I incline to agreeing with the scenario you depict. This can reasonably happen. I also think that David made a good case for it being unlikely to manage oneself into the buggy situation that way. And then the consequence is that you lost some possibly important files. If you ended up fiddling with dpkg in a failed upgrade, would it be too much to ask for running dpkg --verify? In the event you see missing files, you may reinstall affected packages and thus have cured the symptoms for your installation. Say we extended release-notes saying that you should dpkg --verify after the upgrade and more so if you happened to use dpkg directly in the process and review the output. Would that address your concern? > It may be that the mitigations necessary are worse than the risk, but I > think the behaviour as described in #1058937 is definitely buggy. I hope we all agree this is buggy. That's not the question. The question at hand is whether this is a bug worth fixing or mitigating. We face a lot of bugs in Debian and assign different severities. Here, the preliminary analysis assigned a rc-severity which generally means it is worth fixing. That's the thing I'm questioning here. Also keep in mind that probably the majority of bullseye -> bookworm upgrades have been performed already. In all those upgrades, nobody ran into the issue and reported it. As David pointed out, it was encountered by actively trying to make it break. It's the silent kind of failure, so it may just have happened without people noticing. Maybe we can all run dpkg --verify on our installations (in particular those upgraded to bookworm or later) and report if they show anything suspicious. Then we can better quantify how likely these issues happen in practice. I note that dpkg --verify does not currently work with --path-exclude. I'm not sure whether that's a bug. Being a user of --path-exclude, I note that I ran dpkg --verify on 5 very different systems and didn't spot unusual things. This is anecdotal evidence and cannot prove the absence of problems though. I'd be very keen to see at least one user reporting such problems in a real upgrade rather than me trying to find problems. Helmut
Bug#1058937: /usr-move: Do we support upgrades without apt?
Hi, this installment serves a dual purpose. Let me first give an update of the status quo and then pose a consensus question on how we want to deal with a particular problem. I Cc d-release@l.d.o as upgrades are an integral part of releases. I Cc d-ctte@l.d.o for advisory feedback with experience due to earlier decisions on merged-/usr. # Status As I detailed earlier, diversions have been proving more difficult than anticipated. I spent significant time on molly-guard to get to a working mitigation and thanks to Francois and Daniel, all of the diverters of /sbin/halt and others have been updated in experimental for wider testing. This is looking promising and passing all testing that has been performed thus far. Meanwhile Chris Hofstaedler and kind folks in Cambridge worked a lot on M-A:same shared file loss (DEP17 P7) and got us down to one (reintroduced) issue. Pending further reintroductions, this aspect is done. Cool! I've since uploaded debhelper and dh_installudev will now also install to /usr. udevdir in udev.pc has been changed in a NEW upload to experimental as well and is expected to hit unstable before too long (thanks Michael and Luca). Earlier, I requested a pause of /usr merges. Since we have a better understanding and solutions that seem to be working now, I am happy for you to move stuff again more widely. For moves involving diversions in any way, consider having me review your change ahead of upload. At the time of this writing, there are 1237 source packages in unstable that still ship something aliased. This is the number we need to get down to 0 for trixie. Of these 860 involve a systemd unit and of these 761 only have systemd units aliased many of which can be converted by a no-change upload due to changed debhelper and systemd.pc behaviour. # The problem with conflicts The idea in DEP17 was to use Conflicts as a mitigation strategy in agreement with a naive reading of Debian policy. As it turns out, that doesn't exactly match reality (#1057199 debian-policy) and there are situations where files can be lost despite Conflicts having been declared. In theory, this subtlety should be irrelevant and unobservable, but aliasing (which breaks dpkg's assumptions) makes this observable. We move a file from / to /usr in $PKGA. AND one of The file is also being moved to a different package (causing DEP17 P1). OR The file is being diverted (causing DEP17 P3). AND The mitigation involves declaring a Conflict for unpack ordering (i.e. M7 for P1 or M18 for P3). AND one of The upgrade is being performed using a direct dpkg invocation without apt in a way that unpacks the package declaring the conflict before the conflicted package is removed. Example: #1058937 (Ben's libnfsidmap1 bug) OR The involved packages declare a mutual conflict (or mutual conflicts + breaks) and therefore apt invokes dpkg as in the earlier point. Example: An earlier version of the molly-guard mitigation declared versioned Breaks for systemd-sysv. This condition is complex, so let me try to break it down into something simpler. We'll have somewhere between 20 and 100 instances of P1 + P3 I guess and we aimed for mitigating most of them using Conflicts (i.e. first two conditions). The horny part is the last one. It basically says that as long as we only ever use apt and avoid mutual conflicts, the issue is not practically observable. That mutual conflict condition is delicate on its own. There are basically two ways to trigger it. The way my molly-guard patch did it was having two versioned Conflicts or Breaks declarations. I checked the archive and there is no instance of any package combination doing this. Hypothetically, another way to trigger this is unversioned Conflicts combined with a package that drops Provides in a later version (thanks David), but we haven't seen any practical instance and I haven't figured a good way to gauge this problem yet. ## Options (combinations possible) When mitigating P1, we can opt for protective diversions (M8) instead of Conflicts (M7), though that is more fragile. When mitigating P3, we can avoid the mutual conflicts. For molly-guard that has been more involved, but it seems manageable. For other packages (that do not need to access diverted files), it becomes simpler. We can restore lost files in a postinst. For this to work, we must duplicate (e.g. hard link) affected files in the data.tar. Example: #1057220 (systemd-sysv upgrade file loss) Note that this approach is not policy compliant for essential packages as they must work when unpacked and this is relevant for gzip being diverted by zutils for instance. We can introduce "barrier" packages (one or more) and have them enforce conflicting packages removed before the conflictor being unpacked (thanks Julian). We can - and this is the crux of the matter - argue that upgrading with bare dpkg is unsupported and you get to keep the pieces if you do so anyway.
Bug#1057121: dpkg: warning: unable to delete old directory '/lib/firmware/...
Control: reassign -1 release-notes Control: retitle -1 document expected warnings for the bookworm to trixie upgrade On Thu, Nov 30, 2023 at 02:26:07PM +0800, Dan Jacobson wrote: > Package: firmware-misc-nonfree > Version: 20230625-1 > > Saw tons of these. > Unpacking firmware-misc-nonfree (20230625-1) over (20230515-3) ... > dpkg: warning: unable to delete old directory '/lib/firmware/wfx': Directory > not empty > dpkg: warning: unable to delete old directory '/lib/firmware/ueagle-atm': > Directory not empty > dpkg: warning: unable to delete old directory '/lib/firmware/tigon': > Directory not empty > dpkg: warning: unable to delete old directory '/lib/firmware/tehuti': > Directory not empty > > Due to > /lib/firmware/tehuti/bdx.bin etc. I fear these warnings are to be expected when upgrading from bookworm to trixie or within development releases as trixie is being prepared. This is a result of the way we choose to finalize the /usr-merge transition and the only way to not have such warnings would have been to spread the transition to forky. Consensus has been to accept the warnings in favour of finishing sooner rather than later. That said, I see how these warnings cause confusion. We should document them in the release-notes as being specifically expected in a bookworm to trixie upgrade, but not beyond. Helmut
Bug#1051824: linux-patch-VER-rt.patch.xz went missing
Package: linux-source-6.1 Version: 6.1~rc3-1~exp1 X-Debbugs-Cc: wa...@debian.org Hi, I noticed that linux-patch-VER-rt.patch.xz is missing from linux-source-VER lately. I tracked this down to having gone missing exactly when we moved from 6.0 to 6.1, i.e. all 6.0 builds include it and all 6.1 builds lack it. Digging deeper, I couldn't identify a regressing git commit, but Bastian's work on restructuring makefile targets stands out. If looking at build logs, you can see that in current builds ALL_FEATURESETS is no longer set and this is why the relevant dependency is skipped. gencontrol.py def do_main_makefile is probably relevant here. It ends with: makeflags = makeflags.copy() makeflags['ALL_FEATURESETS'] = ' '.join(iter_featuresets(self.config)) super().do_main_makefile(makeflags, extra) In former kernels, the super method was non-empty and consumed the updated makeflags, but this is no longer the case, the super method now simply says "pass", so this code block has effectively become a no-op. On the flip side, I tried to see what would happen if we'd update the global makeflags with ALL_FEATURESETS (e.g. by deleting the dict copy). And indeed, once doing that the rt patch is included in the -source package again. This probably is not the right solution, but I hope this bit helps pin down the cause. In any case, it seems evident that the deletion of linux-patch-VER-rt.patch.xz is accidental rather than intentional. Would you be able to restore its presence? Helmut
Bug#1051365: linux: drop stage1 profile?
Source: linux Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Hi, I recently captured a conversation involving Bastain saying that the stage1 build profile was deprecated. He's right! So I went searching for users of this profile. The most obvious user to me is rebootstrap. It turns out that stage1 is sufficiently similar to pkg.linux.nokernel,pkg.linux.nosource,pkg.linux.notools that I can just use that profile combination instead and changed rebootstrap. Another obvious candidate is cross-toolchain-base as it also produces packages that resemble a linux-libc-dev. Looking into it, I found that it doesn't use linux' packaging at all and just does make headers_install, so it does not use stage1 either. And with that I'm lost locating users of linux' stage1 profile. Is it time to delete it? If your answer is "no", please close this bug without further action. Helmut
Bug#1037938: linux FTCBFS: perf builds a python extension for the build architecture
Source: linux Version: 6.3.7-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs linux fails to cross build from source again. It seems like the perf build gained a python extension and that extension happens to be built for the build architecture, which doesn't go well. Please export the magic python cross building environment variable to make this work. I'm attaching a patch for your convenience. Helmut --- linux-6.3.7/debian/changelog2023-06-12 08:25:26.0 +0200 +++ linux-6.3.7/debian/changelog2023-06-14 16:09:09.0 +0200 @@ -1,3 +1,11 @@ +linux (6.3.7-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Pass _PYTHON_SYSCONFIGDATA_NAME to the perf build. +(Closes: #-1) + + -- Helmut Grohne Wed, 14 Jun 2023 16:09:09 +0200 + linux (6.3.7-1) unstable; urgency=medium * New upstream stable update: --- linux-6.3.7/debian/rules.real 2023-06-12 08:25:16.0 +0200 +++ linux-6.3.7/debian/rules.real 2023-06-14 16:09:09.0 +0200 @@ -632,6 +632,10 @@ dh_md5sums dh_builddeb -- $(BUILDDEB_ARGS) +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +binary_perf build_perf: export _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_MULTIARCH) +endif + build_perf: $(STAMPS_DIR)/build-tools-headers $(call make-tools,tools/perf)
Bug#1019118: patch for rtla regression
Control: tags -1 + patch Control: forwarded -1 https://lore.kernel.org/all/20230120070809.6169-1-jo...@mister-muffin.de/ Hi, Johannes tried upstreaming the necessary change and that was rejected with a note that this is the responsibility of the builder. I'm attaching the appropriate Debian patch as requested. Please consider applying it. Helmut diff --minimal -Nru linux-6.1.8/debian/changelog linux-6.1.8/debian/changelog --- linux-6.1.8/debian/changelog2023-01-29 13:33:36.0 +0100 +++ linux-6.1.8/debian/changelog2023-02-07 07:55:34.0 +0100 @@ -1,3 +1,10 @@ +linux (6.1.8-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Supply the host pkg-config to the rtla build. (Closes: #1019118) + + -- Helmut Grohne Tue, 07 Feb 2023 07:55:34 +0100 + linux (6.1.8-1) unstable; urgency=medium * New upstream stable update: diff --minimal -Nru linux-6.1.8/debian/rules.d/Makefile.inc linux-6.1.8/debian/rules.d/Makefile.inc --- linux-6.1.8/debian/rules.d/Makefile.inc 2022-11-20 16:33:47.0 +0100 +++ linux-6.1.8/debian/rules.d/Makefile.inc 2023-02-07 07:55:34.0 +0100 @@ -7,6 +7,7 @@ CC = $(CROSS_COMPILE)gcc CXX = $(CROSS_COMPILE)g++ +PKG_CONFIG = $(CROSS_COMPILE)pkg-config CFLAGS := $(shell dpkg-buildflags --get CFLAGS) -Wall CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) \ -I$(top_srcdir)/$(OUTDIR) \ diff --minimal -Nru linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile --- linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile 2023-01-28 14:24:06.0 +0100 +++ linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile 2023-02-07 07:55:34.0 +0100 @@ -5,7 +5,7 @@ echo '$(UPSTREAMVERSION)' >VERSION rsync -a $(top_srcdir)/tools/tracing/rtla/ . rsync -a $(top_srcdir)/Documentation/tools/rtla/ Documentation/ - $(MAKE) EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)' EXTRA_LDFLAGS='$(LDFLAGS)' + $(MAKE) EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)' EXTRA_LDFLAGS='$(LDFLAGS)' PKG_CONFIG='$(PKG_CONFIG)' install: $(MAKE) install
Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB
Hi Helge,
On Tue, Jan 24, 2023 at 10:30:37PM +0100, Helge Deller wrote:
> On 1/24/23 06:27, Helmut Grohne wrote:
> > On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:
> > > --- ./init.org2023-01-23 21:40:33.079738389 +
> > > +++ ./init2023-01-23 21:40:45.983861851 +
> > > @@ -205,6 +205,15 @@ else
> > > resume=${RESUME:-}
> > > fi
> > >
> > > +if [ -z "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then
> >
> > This is as bashism and init runs with dash as far as I can see.
>
> Hmm... I did tested it, at it seemed to work...
> Which part of that line exactly do you think is problematic?
> I'm open for any other idea how to code it.
The lexicographic comparison is outside the realm of POSIX shell, but to
my surprise this actually is supported by dash. So fixing this would be
academic.
> Both will work, because I assume that on such systems you probably have more
> than 200MB RAM
> and thus my patch won't touch the user-provided value at all.
Fair enough.
> > > + read MemTotal mem_kb rest < /proc/meminfo
> > > + # systemd requires at minumum 16MB for /run, so reserve
> > > + # 20MB for machines which have less than 200MB RAM
> > > + if [ "$mem_kb" -lt "20" ]; then
> > > + RUNSIZE=20M # for machines <= 200MB RAM
else
: "${RUNSIZE:=10%}"
> >
> > Given that you initialize a default here, I think it would make the code
> > more obvious if you pulled the 10% default 4 lines later into an else
> > branch.
>
> Not sure I understand this...?
>
> > > + fi
> > > +fi
> > > +
> > > mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755"
> > > tmpfs /run
This is the other line that contains a default. I suggested moving this
default up to make it more obvious, but this is really only a cosmetic
improvement.
As such LGTM, but I am not an initramfs maintainer.
Helmut
Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB
Hi Helge,
On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:
> --- ./init.org2023-01-23 21:40:33.079738389 +
> +++ ./init2023-01-23 21:40:45.983861851 +
> @@ -205,6 +205,15 @@ else
> resume=${RESUME:-}
> fi
>
> +if [ -z "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then
This is as bashism and init runs with dash as far as I can see.
Also note that RUNSIZE may legitimately be given as "1g" or "19%", both
of which should work. I suggest just not handling the case where RUNSIZE
is set by the user and letting them break their system however they
like rather than risk breaking legitimate configuration.
> + read MemTotal mem_kb rest < /proc/meminfo
> + # systemd requires at minumum 16MB for /run, so reserve
> + # 20MB for machines which have less than 200MB RAM
> + if [ "$mem_kb" -lt "20" ]; then
> + RUNSIZE=20M # for machines <= 200MB RAM
Given that you initialize a default here, I think it would make the code
more obvious if you pulled the 10% default 4 lines later into an else
branch.
> + fi
> +fi
> +
> mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs
> /run
> mkdir -m 0700 /run/initramfs
Helmut
Bug#1029270: linux-image-6.1.0-2-686-pae fails to boot in qemu
Control: severity -1 normal On Fri, Jan 20, 2023 at 03:55:53PM +0100, Helmut Grohne wrote: > A CI job of debvm started failing. debvm creates a minimalistic virtual > machine based on Debian unstable i386 and tries to run it in qemu. With > the previous kernel package that worked. Once updating to 6.1.7-1, it > fails to boot: I have one more data point. If you pass -enable-kvm to qemu, it actually boots. It only fails to boot when disabling kvm. That shouldn't affect that many users. It's still unclear what causes the issue. I'm also pulling qemu maintainer mjt into the discussion for possible input. Helmut
Bug#1029270: linux-image-6.1.0-2-686-pae fails to boot in qemu
Package: linux-image-6.1.0-2-686-pae Version: 6.1.7-1 Severity: important Control: affects -1 + debvm A CI job of debvm started failing. debvm creates a minimalistic virtual machine based on Debian unstable i386 and tries to run it in qemu. With the previous kernel package that worked. Once updating to 6.1.7-1, it fails to boot: https://salsa.debian.org/helmutg/debvm/-/jobs/3824112 | [1.158184] traps: PANIC: double fault, error_code: 0x0 | [1.158184] double fault: [#1] PREEMPT SMP PTI | [1.158184] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-2-686-pae #1 Debian 6.1.7-1 | [1.158184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 | [1.158184] EIP: __kmem_cache_alloc_node+0xc4/0x350 | [1.158184] Code: 85 c9 0f 84 6e 02 00 00 8b 75 f0 8b 47 1c 01 f0 89 c1 8b 00 33 47 78 0f c9 31 c8 8d 4a 20 89 c3 89 f0 8b 37 64 0f c7 0e 75 ba <8b> 75 e8 8b 47 1c 8d 74 26 00 3e 8d 74 26 00 3e 8d 74 26 00 8b 47 | [1.158184] EAX: c11ed0c0 EBX: c11ed300 ECX: 0301 EDX: 02e1 | [1.158184] ESI: d6e1e978 EDI: c10013c0 EBP: c1145e4c ESP: c1145e30 | [1.158184] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: c11ed2c2 | [1.158184] CR0: 80050033 CR2: CR3: 16e2c000 CR4: 06b0 | [1.158184] Call Trace: | [1.158184] __kmalloc+0x42/0x140 | [1.158184] ? cache_random_seq_create+0x81/0x130 | [1.158184] ? cache_random_seq_create+0x81/0x130 | [1.158184] cache_random_seq_create+0x81/0x130 | [1.158184] init_cache_random_seq+0x39/0x80 | [1.158184] __kmem_cache_create+0x10f/0x470 | [1.158184] kmem_cache_create_usercopy+0x158/0x2a0 | [1.158184] kmem_cache_create+0x17/0x20 | [1.158184] proto_register+0x183/0x240 | [1.158184] ? ipv4_offload_init+0x6e/0x6e | [1.158184] inet_init+0x37/0x261 | [1.158184] do_one_initcall+0x4b/0x1e0 | [1.158184] kernel_init_freeable+0x1a5/0x1e5 | [1.158184] ? rest_init+0xb0/0xb0 | [1.158184] kernel_init+0x17/0x100 | [1.158184] ret_from_fork+0x1c/0x28 | [1.158184] Modules linked in: | [1.158184] ---[ end trace ]--- | [1.158184] EIP: __kmem_cache_alloc_node+0xc4/0x350 | [1.158184] Code: 85 c9 0f 84 6e 02 00 00 8b 75 f0 8b 47 1c 01 f0 89 c1 8b 00 33 47 78 0f c9 31 c8 8d 4a 20 89 c3 89 f0 8b 37 64 0f c7 0e 75 ba <8b> 75 e8 8b 47 1c 8d 74 26 00 3e 8d 74 26 00 3e 8d 74 26 00 8b 47 | [1.158184] EAX: c11ed0c0 EBX: c11ed300 ECX: 0301 EDX: 02e1 | [1.158184] ESI: d6e1e978 EDI: c10013c0 EBP: c1145e4c ESP: c1145e30 | [1.158184] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: c11ed2c2 | [1.158184] CR0: 80050033 CR2: CR3: 16e2c000 CR4: 06b0 | [1.158184] Kernel panic - not syncing: Fatal exception in interrupt You can easily reproduce this by installing debvm, running `debvm-create -a i386` (which will create a rootfs.ext4) and then `debvm-run`. The only other packages changed since the last successful run are: * openssl * glib2.0 * mmdebstrap We can rule out mmdebstrap as a cause by adding `-r bookworm` to the invocation and seeing that things boot. The other packages shouldn't be able to cause a kernel panic. Let me know if you need anything else. Helmut
Bug#1028184: unsatisfiable cross Build-Depends: python3-jinja2
Source: linux Version: 6.1.4-1 Tags: patch Severity: important Justification: breaks architecture bootstrap User: helm...@debian.org Usertags: rebootstrap User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Hi, the addition of the python3-jinja2 build dependency happens to break architecture bootstrap. It's not as bad as it may sound initially though. python3-jinja2 is an architecture-dependent package due to being a C extension. As such it is installed for the host architecture by default. Thus apt tries to install the whole python stack for the host architecture and that doesn't go well. We cannot make python3-jinja2 Multi-Arch: foreign, because it really isn't, so consumers (like linux) have to choose how they use it instead. In this case, it's meant to be run during build and that means it should be annotated :native. While at it, I think that it is more honest to also apply this to python3 as well in order to disallow a host architecture Python interpreter. This happens to be easy to work around in rebootstrap, so don't upload linux just for this bug, but please include the patch in your next regular upload to unstable. Helmut diff --minimal -Nru linux-6.1.4/debian/changelog linux-6.1.4/debian/changelog --- linux-6.1.4/debian/changelog2023-01-07 14:53:00.0 +0100 +++ linux-6.1.4/debian/changelog2023-01-08 07:29:36.0 +0100 @@ -1,3 +1,11 @@ +linux (6.1.4-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix cross Build-Depends: Annotate python3 and python3-jinja2 +dependencies :native. (Closes: #-1) + + -- Helmut Grohne Sun, 08 Jan 2023 07:29:36 +0100 + linux (6.1.4-1) unstable; urgency=medium * New upstream stable update: diff --minimal -Nru linux-6.1.4/debian/control linux-6.1.4/debian/control --- linux-6.1.4/debian/control 2023-01-07 14:53:00.0 +0100 +++ linux-6.1.4/debian/control 2023-01-08 07:29:33.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Debian Kernel Team Uploaders: Bastian Blank , maximilian attems , Ben Hutchings , Salvatore Bonaccorso Standards-Version: 4.2.0 -Build-Depends: debhelper-compat (= 12), dh-exec, python3:any, python3-jinja2, quilt, cpio , xz-utils , dh-python , bison , flex (>= 2.6.1-1.1~) +Build-Depends: debhelper-compat (= 12), dh-exec, python3:native, python3-jinja2:native, quilt, cpio , xz-utils , dh-python , bison , flex (>= 2.6.1-1.1~) Build-Depends-Arch: kernel-wedge (>= 2.102~) , kmod , bc , libssl-dev:native , libssl-dev , openssl (>= 1.1.0-1~) , libelf-dev:native , libelf-dev , rsync, lz4 [amd64 arm64] , pahole | dwarves:native (>= 1.16~) , gcc-12 [alpha amd64 arm64 armel armhf hppa i386 ia64 m68k mips mips64 mips64el mips64r6 mips64r6el mipsel mipsr6 mipsr6el powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64] , gcc-12-alpha-linux-gnu [alpha] , gcc-12-x86-64-linux-gnu [amd64] , gcc-12-aarch64-linux-gnu [arm64] , gcc-arm-linux-gnueabihf [arm64] , gcc-12-arm-linux-gnueabi [armel] , gcc-12-arm-linux-gnueabihf [armhf] , gcc-12-hppa-linux-gnu [hppa] , binutils-hppa64-linux-gnu [hppa] , gcc-12-hppa64-linux-gnu [hppa] , gcc-12-i686-linux-gnu [i386] , gcc-12-ia64-linux-gnu [ia64] , gcc-12-m68k-linux-gnu [m68k] , gcc-12-mips-linux-gnu [mips] , gcc-12-mips64-linux-gnuabi64 [mips64] , gcc-12-mips64el-linux-gnuabi64 [mips64el] , gcc-12-mipsisa64r6-linux-gnuabi64 [mips64r6] , gcc-12-mipsisa64r6el-linux-gnuabi64 [mips64r6el] , gcc-12-mipsel-linux-gnu [mipsel] , gcc-12-mipsisa32r6-linux-gnu [mipsr6] , gcc-12-mipsisa32r6el-linux-gnu [mipsr6el] , gcc-12-powerpc-linux-gnu [powerpc] , gcc-12-powerpc64-linux-gnu [ppc64] , gcc-12-powerpc64le-linux-gnu [ppc64el] , gcc-12-riscv64-linux-gnu [riscv64] , gcc-12-s390x-linux-gnu [s390x] , gcc-12-sh4-linux-gnu [sh4] , gcc-12-sparc64-linux-gnu [sparc64] , python3-docutils [linux-any] , zlib1g-dev [linux-any] , libcap-dev [linux-any] , libpci-dev [linux-any] , asciidoctor [alpha amd64 arm64 armel armhf hppa i386 mips mips64 mips64el mips64r6 mips64r6el mipsel mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64] , gcc-multilib [amd64 mips64 mips64el mips64r6 mips64r6el ppc64 s390x sparc64] , libaudit-dev [alpha amd64 arm64 armel armhf hppa i386 mips mips64 mips64el mips64r6 mips64r6el mipsel mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64] , libbabeltrace-dev [alpha amd64 arm64 armel armhf hppa i386 mips mips64 mips64el mips64r6 mips64r6el mipsel mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64] , libdw-dev [alpha amd64 arm64 armel armhf hppa i386 mips mips64 mips64el mips64r6 mips64r6el mipsel mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64] , libiberty-dev [alpha amd64 arm64 armel armhf hppa i386 mips mips64 mips64el mips64r6 mi
Bug#1027174: linux-image-*-cloud-amd64: please add support for the 9p filesystem
Package: linux-image-6.0.0-6-cloud-amd64 Version: 6.0.12-1 Severity: wishlist X-Debbugs-Cc: jo...@debian.org Hi, I already talked with Bastian on #debian-devel about this, but that was inconclusive, so I'm taking it to email. I request adding support for the 9p filesystem to the cloud image. While Bastian pointed out that the primary use case of cloud kernels is AWS, Azure and GCE, I think that these kernels should be generally useful in virtualisation environments such as kvm. As far as I understand it, they significantly reduce the size by removing hardware drivers that are not usually available in virtualised environments. While none of the mentioned cloud providers provide 9p filesystems to their guests, the -virtfs option to kvm/qemu is by far the simplest way to share a host filesystem with a virtual machine. The cloud kernel image already covers virtiofs, but virtiofsd comes with significant additional complexity on the host - most significant is the requirement for being run as root. Given the similarity of virtiofs and 9p, the latter should be included as well. Adding 9p would increase the Installed-Size by about 600kb, i.e. less than 0.5%. Of course, one can always install the non-cloud kernel to use 9p. Helmut
Re: Dependencies of linux-headers- packages
Hi Felix, On Mon, Mar 14, 2022 at 10:33:22AM +, Moessbauer, Felix wrote: > In general I agree, but here the situation is a bit different: > The dependency to the host compiler (e.g. arm64) is too narrow. Wrong. It certainly is not and beyond that, this aspect is not weakened. It still requires a particular version of gcc for the relevant architecture. > In general, any gcc compiler in the correct version should do. Wrong. Ben explained why this is not desired and his patch does not relax this aspect. > As discussed earlier the linux-headers -> compiler dependency is just a > convenience dep. > I proposed to remove it or move it to the "recommends" section. Yes, you proposed that. But it was not an accepted solution and it is not what Ben's patch does. > But the proposed solution might be better as it maintains backwards > compatibility. Ben's solution is a workaround. The linux packaging is already complex in this regard. We need to reduce complexity, not add to it. > For users that just want to cross-compile a module, there is simply no reason > why the have to install the compiler for the host architecture (e.g. arm64). The essence of cross compilation is a compiler that targets the host architecture. Of course, you do need it for cross compiling a kernel module. > And this use-case is perfectly solved in the patch from Ben. We seem to be in disagreement of what "perfect" means. Any time, you iterate over architectures in your dependencies, things are certainly not perfect as every new architecture will require manual work. Manual per-architecture work does not qualify as "perfect" to me. While it solves your use case, it incurs a maintenance cost where a solution with less cost is available. Helmut
Re: Dependencies of linux-headers- packages
Hi, On Thu, Mar 10, 2022 at 02:13:34PM +, Moessbauer, Felix wrote: > Many thanks for the patch. > I just (manually) backported that to Debian bullseye, tested it for arm64 and > it worked like a charm. Can we please stop piling up workarounds and instead fix this once and for all? I see us mirroring the "LTS problem" here: Everyone maintains their own stuff with local patches and it barely works. LTS now has a solution in the form of freexian where the effort is centralized and made available for the benefit of everyone. Helmut
Bug#996906: klibc FTBFS on armhf: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
Source: klibc Version: 2.0.8-6.1 Severity: serious Tags: ftbfs klibc fails to build from source in unstable on armhf. I suppose this is fallout from gcc-11. Reproduced by reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/klibc_2.0.8-6.1.rbuild.log.gz | /usr/bin/make all INSTALLROOT=debian/tmp ARCH=arm CONFIG_AEABI=y CPU_ARCH=armv7-a CPU_TUNE=cortex-a8 CONFIG_KLIBC_THUMB=y KBUILD_VERBOSE=1 CONFIG_DEBUG_INFO=y | make[2]: Entering directory '/build/1st/klibc-2.0.8' | /usr/bin/make -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=klcc | rm -f klcc/klibc.config | echo 'ARCH=arm' >> klcc/klibc.config | echo 'ARCHDIR=arm' >> klcc/klibc.config | echo 'CROSS=' >> klcc/klibc.config | echo 'KCROSS=' >> klcc/klibc.config | echo 'CC=gcc' >> klcc/klibc.config | echo 'LD=ld' >> klcc/klibc.config | echo 'REQFLAGS=-D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-PIE -fno-builtin-bcmp -fcommon -ggdb -fno-exceptions -mthumb -mabi=aapcs-linux -nostdinc -iwithprefix include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=32' >> klcc/klibc.config | echo 'OPTFLAGS=-Os -march=armv7-a -mtune=cortex-a8' >> klcc/klibc.config | echo 'LDFLAGS=--thumb-entry _start --build-id=sha1' >> klcc/klibc.config | echo 'STRIP=strip' >> klcc/klibc.config | echo 'STRIPFLAGS=-R .ARM.exidx --strip-all -R .comment -R .note' >> klcc/klibc.config | echo 'EMAIN=--thumb-entry main' >> klcc/klibc.config | echo 'BITSIZE=32' >> klcc/klibc.config | echo 'VERSION=2.0.8' >> klcc/klibc.config | echo 'prefix=/usr/lib/klibc' >> klcc/klibc.config | echo 'bindir=/usr/lib/klibc/bin' >> klcc/klibc.config | echo 'libdir=/usr/lib/klibc/lib' >> klcc/klibc.config | echo 'includedir=/usr/lib/klibc/include' >> klcc/klibc.config | perl klcc/makeklcc.pl /build/1st/klibc-2.0.8/klcc/klcc.in klcc/klibc.config /usr/bin/perl > klcc/klcc || ( rm -f klcc/klcc ; exit 1 ) && chmod a+x klcc/klcc | : | /usr/bin/make -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=. | /usr/bin/make -rR -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=scripts/basic | gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c | : | /usr/bin/make -rR -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=usr/klibc | gcc -Wp,-MD,usr/klibc/.__static_init.o.d -nostdinc -iwithprefix include -I/build/1st/klibc-2.0.8/usr/include/arch/arm -Iusr/include/arch/arm -I/build/1st/klibc-2.0.8/usr/include/bits32 -Iusr/include/bits32 -I/build/1st/klibc-2.0.8/usr/klibc/../include -Iusr/klibc/../include -I/build/1st/klibc-2.0.8/usr/include -Iusr/include -I/build/1st/klibc-2.0.8/linux/include -Ilinux/include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-PIE -fno-builtin-bcmp -fcommon -ggdb -fno-exceptions -mthumb -mabi=aapcs-linux -Os -march=armv7-a -mtune=cortex-a8 -W -Wall -Wno-sign-compare -Wno-unused-parameter -c -o usr/klibc/__static_init.o usr/klibc/__static_init.c | cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU | make[4]: *** [/build/1st/klibc-2.0.8/scripts/Kbuild.klibc:261: usr/klibc/__static_init.o] Error 1 | make[3]: *** [/build/1st/klibc-2.0.8/./Kbuild:9: all] Error 2 | make[2]: *** [Makefile:121: klibc] Error 2 | make[2]: Leaving directory '/build/1st/klibc-2.0.8' | make[1]: *** [debian/rules:51: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/build/1st/klibc-2.0.8' | make: *** [debian/rules:45: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Also seen by crossqa: http://crossqa.debian.net/build/klibc_2.0.8-6.1_armhf_20211019164552.log Helmut
Bug#994798: util-linux FTBFS: configure: error: raw selected, but required raw.h header file not available
Source: util-linux
Version: 2.37.2-2
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: debian-kernel@lists.debian.org
util-linux fails to build from source in unstable on amd64. I think the
relevant bits are:
| dh_auto_configure -- --enable-raw --with-selinux --with-smack --enable-partx
--with-systemd --with-udev --with-audit --with-cryptsetup=dlopen --enable-write
--enable-static-programs=fdisk,sfdisk,blkid --without-python --disable-login
--disable-nologin --disable-kill --disable-chfn-chsh --disable-cal
--disable-hwclock-gplv3
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --enable-raw
--with-selinux --with-smack --enable-partx --with-systemd --with-udev
--with-audit --with-cryptsetup=dlopen --enable-write
--enable-static-programs=fdisk,sfdisk,blkid --without-python --disable-login
--disable-nologin --disable-kill --disable-chfn-chsh --disable-cal
--disable-hwclock-gplv3
...
| checking for linux/raw.h... no
...
| configure: error: raw selected, but required raw.h header file not available
I suspect that linux dropped the header and that way makes util-linux
FTBFS.
Helmut
Bug#970011: linux: missing build dependency on kernel-wedge in stage1 build
Source: linux Version: 5.8.7-1 Severity: important User: helm...@debian.org Usertags: rebootstrap Hi, I'm run into a bootstrap failure caused by linux: https://jenkins.debian.net/job/rebootstrap_hppa_gcc10/9/ | dh_prep | dh_prep: warning: All requested packages have been excluded (e.g. via a Build-Profile or due to architecture restrictions). | kernel-wedge install-files 5.8.0-1 | bash: kernel-wedge: command not found | make[2]: Leaving directory '/tmp/buildd/linux/linux-5.8.7' | make[2]: *** [debian/rules.real:573: install-udeb_hppa] Error 127 | make[1]: Leaving directory '/tmp/buildd/linux/linux-5.8.7' | make[1]: *** [debian/rules.gen:89: binary-arch_hppa] Error 2 | make: *** [debian/rules:43: binary-arch] Error 2 | dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 What we see here is that kernel-wedge is not found while cross building linux with the stage1 profile for hppa. This seems to be a recent thing. It used to work earlier. I'm not sure yet, how many other architectures are affected. A kernel-wedge dependency is there, but it is tagged . That used to be true. Do note that the failing target is install-udeb_hppa and that in a stage1 build, we don't produce any udebs. So in reality it seems more likely that the whole target should be skipped, but isn't. The target seems to be pulled in by debian/rules.gen, but that's about where I stopped understanding the logic. Can I ask you to look into this? In the mean time, I guess installing kernel-wedge is a viable workaround. While looking into linux' build profiles I was wondering whether we still need stage1. linux gained a number of functional profiles including pkg.linux.nokernel, pkg.linux.notools and pkg.linux.nosource. Their combination does not exactly reproduce stage1, but it is close. I'm wondering whether we can simply switch any stage1 user to using the combination of these three and be done. I haven't tried whether this actually works yet, but I believe it is feasible and you get the idea. Helmut
Bug#959225: libcap-ng FTBFS: Build-Depends: linux-kernel-headers is no longer provided
Source: libcap-ng Version: 0.7.9-2.1 Severity: serious Tags: ftbfs patch User: helm...@debian.org Usertags: rebootstrap libcap-ng fails to build from source, because linux-libc-dev no longer provides linux-kernel-headers, which is what libcap-ng Build-Depends on. Please transition your dependency to linux-libc-dev: sed -i -e 's/linux-kernel-headers/linux-libc-dev/' debian/control Helmut
Bug#908438: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on Cubietruck and Banana Pro
Control: tags -1 + patch Hi, On Sun, Sep 30, 2018 at 04:58:52PM +0200, Hans de Goede wrote: > While doing some brcmfmac driver work I needed to test this also on some > devicetree based boards. So I fired up the good old Cubietruck and when > that would not work a Banana Pro. > > With an unmodified 4.17 kernel both boards intermittently would come up > with non working wifi with the following errors: > > brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout > brcmfmac: brcmf_bus_started: failed: -110 > brcmfmac: brcmf_attach: dongle is not responding: err=-110 > brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed I confirm the observation on a Banana Pro booting the buster 4.19 kernel. The problem happend reliably for me. I also confirm that your workaround solves the symptoms on my board. > Using an OOB IRQ instead of the sdio-IRQ mechanism is mostly important to > allow the MMC controller to go into runtime-suspend which is not really an > issue on these boards since they are (usually) not battery powered. I agree that this is a reasonable trade-off (power saving vs working device). Helmut
Re: Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler
On Thu, Jan 24, 2019 at 04:38:19PM +0100, Helmut Grohne wrote:
> Ultimately, this means that marking binutils- M-A:foreign was
> wrong. It means that binutils plays the same role as ruby, perl, python
> and even make: you can load shared objects into it, but much of the time
> you don't. All of the other examples are M-A:allowed, so I guess
> binutils- needs to become M-A:allowed as well. Given that gcc
> Depends on binutils, binutils is M-A:no, and binutils Depends:
> binutils- without :any, the switch from M-A:foreign to
> M-A:allowed should fix this this bug, but at the same time it would
> break a fair number of use cases. We specifically have binutils-for-host
> to allow using foreign binutils. Likely binutils-for-host should
> Depends: binutils-:any then. On the flip side, that means that
> whenever you need plugins, you cannot use binutils-for-host.
>
> Now marking anything M-A:allowed is basically irreversible, because
> people are going to use :any and all those deps break when removing
> M-A:allowed. Therefore we should think hard about whether this is the
> right route. I've added debian-cross@l.d.o to Cc to elicit some
> feedback.
You can find the patch for binutils attached. binutils- will
become Multi-Arch: allowed. With this patch applied there are the
following ways to depend on binutils:
A Source package.
A.A You want binutils for the host architecture -> binutils-for-host
A.A You want binutils for the build architecture -> binutils-for-build
B Binary package of architecture $ARCH.
B.A You want binutils targeting the $ARCH.
B.A.A Your package contains a plugin to load into binutils ->
binutils-$ARCH
B.A.B No plugin -> binutils-$ARCH:any
B.B You want binutils targeting some executable architecture.
B.B.A Your package contains a plugin to load into binutils ->
binutils
B.B.B No plugin -> binutils-for-build
In #895251, I requested that gcc use triplet-prefixed tools to allow
coinstalling binutils. It also made the architecture of binutils opaque
(which is what this bug is about). After causing repeated problems, the
relevant change was finally reverted via #915194. Now gcc uses
unprefixed tools again. But it still prefers prefixed tools in
/usr/ (which is what this bug is about). We'll should change
that using triplet-prefixed tools explicitly at some point. gcc-8
presently Depends on "binutils". gcc-8- will have to Depends
binutils- without a :any. With the patch, binutils will Depends:
binutils- without :any, so using gcc-8:amd64 with
binutils-x86-64-linux-gnu:i386 will no longer be possible. So on the gcc
side, the attached patch will work.
src:arch-test uses binutils-, but it is Architecure: all, so it
pretty much doesn't matter whether the dependencies are annotated or
not.
src:cross-toolchain-base{,-port} conflicts with a number of
binutils-. That will continue to work.
src:gcc-8-cross (and similar packages) Build-Depends binutils-.
The binutils patch will render these dependencies cross-unsatisfiable.
They will need to be annotated :any or switched to binutils-for-host if
we want to cross build gcc-8-cross. Matthias, will you handle these?
src:linux Build-Depends binutils-. The binutils patch will
render these dependencies cross-unsatisfiable. They will need to be
switched to binutils-for-host or annotated with :any (after checking
that it doesn't use plugins). Maintainers Cced.
So the attached patch will break cross building of gcc and linux. It
won't break any native stuff and it'll fix the bug at hand.
Helmut
diff --minimal -Nru binutils-2.31.1/debian/changelog
binutils-2.31.1/debian/changelog
--- binutils-2.31.1/debian/changelog2019-02-27 22:30:21.0 +0100
+++ binutils-2.31.1/debian/changelog2019-03-19 14:25:35.0 +0100
@@ -1,3 +1,13 @@
+binutils (2.31.1-15.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ * Demote binutils- from Multi-Arch: foreign to Multi-Arch: allowed.
+ (Closes: #920286)
+ * Let binutil-for-host Depends: binutils-:any.
+
+ -- Helmut Grohne Tue, 19 Mar 2019 14:25:35 +0100
+
binutils (2.31.1-15) unstable; urgency=high
* Fix PR ld/24276, taken from the trunk. Closes: #923246.
diff --minimal -Nru binutils-2.31.1/debian/control
binutils-2.31.1/debian/control
--- binutils-2.31.1/debian/control 2019-02-19 13:39:31.0 +0100
+++ binutils-2.31.1/debian/control 2019-03-19 14:25:22.0 +0100
@@ -34,7 +34,7 @@
Package: binutils-for-host
Architecture: any
-Depends: ${binutils:native} (>= ${binutils:minver}),
+Depends: ${binutils:native}:any (>= ${binutils:minver}),
binutils-common (= ${binary:Version}),
Multi-Arch: same
Description: GNU assembler, linker and binary utilities for the host
architecture
@@ -192,7 +192,7 @@
Package: binutils-x86-64-linux-gnu
Priority: optional
Architecture: amd64 arm64 i386 ppc64el x32
Bug#898743: breaks when #included after
Package: linux-libc-dev,libc6-dev Severity: serious Justification: makes systemd ftbfs User: helm...@debian.org Usertags: rebootstrap Control: affects -1 + src:systemd libmount-dev systemd FTBFS here, because compiling load-fragment.c fails. I spent a while minimizing that file and it boils down to: $ cat test.c #include #include $ gcc -c test.c In file included from test.c:1:0: /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier before numeric constant MS_RDONLY = 1, /* Mount read-only. */ ^ $ linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an enum containing MS_RDONLY. That's a problem. This is also known in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1497501 That bug hints that sometimes headers need to #included in a certain order. If that is the case, this bug should be reassigned to src:systemd asking that or must be #included before . It also means that should #include before defining its own copies of these macros. Helmut PS: Let me briefly curse systemd for their use of cyclic #includes (unit.h <-> cgroup.h) and #pragma once as that works pretty badly with creduce. Thank you.
Bug#873176: linux-image-armmp-lpae: Please add module for DHT11/DHT22 sensors
Hi Ben, On Mon, Sep 25, 2017 at 04:14:43PM +0200, Harald Geyer wrote: > Ben Hutchings writes: > > Control: reassign -1 src:linux tag -1 moreinfo > > This driver appears to depend on Device Tree properties, but none of the > > DTBs we build set those properties. It's not clear to me how it would be > > usable. The situation is quite similar to #858975 where I asked for enabling CONFIG_W1_MASTER_GPIO. In both cases, a device tree needs to supply the information. > That's a fair point. The user will need to either add a node to the DTB on > his system or have the bootloader apply a device tree fragment on top of > the DTB installed by debian, which would work well with automatic updates > of the kernel. (Or load a device tree fragment from userspace once > debian supports dynamic DT.) I am actually using such a system and my present method is to update Debian's device tree after installing kernels. It's not pretty, but good enough for me. > Since updating the DTB is a lot easier then compiling the module for > every update of the debian linux package (and security updates usually > don't change the DTB anyway), I still feel providing the module would > be useful. I fully agree here and second the request for CONFIG_DHT11. Enabling this driver is another piece to shrinking the gap with Raspbian and making Debian a viable alternative on these devices. If you disagree here, you should revert #858975 for consistency's sake. Helmut
Bug#887211: initramfs-tools-core should depend on e2fsprogs explicitly
Package: initramfs-tools-core Version: 0.130 User: helm...@debian.org Usertags: nonessentiale2fsprogs Dear maintainer, We want to make removing e2fsprogs from installations possible. For standard installations this is not useful, but embedded applications and chroots benefit from such an option. For getting there all packages that use e2fsprogs must be identified and gain a dependency on it as e2fsprogs currently is essential. initramfs-tools-core was identified as potentially needing such a dependency, because it mentions tool names from e2fsprogs in the following files: /usr/share/initramfs-tools/hooks/fsck contains logsave. According to file it is a POSIX shell script, ASCII text executable /usr/share/initramfs-tools/scripts/functions contains logsave. According to file it is a ASCII text Please investigate whether these cases are actually uses of a tool from e2fsprogs. Care has been taken to shrink the number of candidates as much as possible, but a few false positives will remain. After doing so, do one of the following: * Add e2fsprogs to Depends. * Add e2fsprogs to Recommends. * Close this bug explaining why e2fsprogs is not used by this package. Once e2fsprogs drops the "Essential: yes" flag, this bug will be upgraded to RC severity. Please note that lintian will warn about such a dependency before lintian 2.5.56. Thanks for your help Helmut
Bug#887198: linux-kbuild-4.14 should depend on e2fsprogs explicitly
Package: linux-kbuild-4.14 Version: 4.14.12-2 User: helm...@debian.org Usertags: nonessentiale2fsprogs Dear maintainer, We want to make removing e2fsprogs from installations possible. For standard installations this is not useful, but embedded applications and chroots benefit from such an option. For getting there all packages that use e2fsprogs must be identified and gain a dependency on it as e2fsprogs currently is essential. linux-kbuild-4.14 was identified as potentially needing such a dependency, because it mentions tool names from e2fsprogs in the following files: /usr/lib/linux-kbuild-4.14/scripts/ver_linux contains tune2fs. According to file it is a awk script, ASCII text executable Please investigate whether these cases are actually uses of a tool from e2fsprogs. Care has been taken to shrink the number of candidates as much as possible, but a few false positives will remain. After doing so, do one of the following: * Add e2fsprogs to Depends. * Add e2fsprogs to Recommends. * Close this bug explaining why e2fsprogs is not used by this package. Once e2fsprogs drops the "Essential: yes" flag, this bug will be upgraded to RC severity. Please note that lintian will warn about such a dependency before lintian 2.5.56. Thanks for your help Helmut
Bug#858975: enable CONFIG_W1_MASTER_GPIO for arm kernels?
Source: linux Severity: wishlist Would it be reasonable to enable CONFIG_W1_MASTER_GPIO as a module for arm kernels? I understand that the w1-gpio module can only be used with a suitable device tree, that device tree overlays (CONFIG_OF_CONFIGFS) are not yet mainline and that none of the precompiled device trees contain configuration for w1-gpio. Thus it is only useable with a handcrafted device tree at the moment. Still enabling the module helps closing the gap to derivatives such as Raspbian and makes Debian an easier choice on such systems. Together with the already enabled modules (wire, w1-therm) this can be used drive e.g. the popular DS18B20 from a stock Debian without requiring custom kernels or like that. Thanks for considering. Helmut
Bug#836542: nfs-utils FTCBFS: uses build architecture compiler, uses pre-built ELF object files
Source: nfs-utils
Version: 1:1.2.8-9.2
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
nfs-utils fails to cross build from source, because it doesn't pass
--host to ./configure and thus uses the build architecture compiler. The
attached patch uses dh_auto_configure, which automatically supplies
those flags as needed. Then I found that the build would reuse existing
ELF object files (e.g. exportfs.o) instead of building them from source,
which is why I mark this bug as important. Reusing those objects causes
the build to fail for any host architecture that is not amd64.
Helmut
diff --minimal -Nru nfs-utils-1.2.8/debian/changelog
nfs-utils-1.2.8/debian/changelog
--- nfs-utils-1.2.8/debian/changelog2016-08-11 18:50:24.0 +0200
+++ nfs-utils-1.2.8/debian/changelog2016-09-03 22:30:39.0 +0200
@@ -1,3 +1,12 @@
+nfs-utils (1:1.2.8-9.3) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure provide cross flags.
++ Remove pre-built object files.
+
+ -- Helmut Grohne <hel...@subdivi.de> Sat, 03 Sep 2016 22:26:25 +0200
+
nfs-utils (1:1.2.8-9.2) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru nfs-utils-1.2.8/debian/rules nfs-utils-1.2.8/debian/rules
--- nfs-utils-1.2.8/debian/rules2016-06-27 23:13:41.0 +0200
+++ nfs-utils-1.2.8/debian/rules2016-09-03 22:35:23.0 +0200
@@ -24,8 +24,7 @@
build-stamp:
dh_testdir
dh_autoreconf
- CFLAGS="$(CFLAGS)" ./configure \
- --mandir='$${prefix}/share/man' \
+ CFLAGS="$(CFLAGS)" dh_auto_configure -- \
--enable-nfsv41 \
--enable-ipv6 \
--enable-libmount-mount \
@@ -41,6 +40,7 @@
[ ! -f Makefile ] || $(MAKE) distclean
dh_autoreconf_clean
dh_clean
+ find . -name "*.o" -delete
binary-indep: build
binary-arch: build
Bug#824524: please support building linux-libc-dev for the tilegx architecture
Source: linux Version: 4.5.3-2 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Ben et al, could you carry the attached patch adding minimla support for the tilegx architecture to the linux source package? The architecture is pending inclusion into dpkg (#823167), but thus far the prospective port looks good as it is upstreamed in many places (binutils/gcc/glibc/linux/...) already. After applying the patch debian/control needs to be regenerated. If you prefer having dpkg add the architecture before linux, we can block the bug. For a fully working linux-libc-dev:tilegx, I'd also need #823632 fixed. Helmut diff --minimal -Nru linux-4.5.3/debian/changelog linux-4.5.3/debian/changelog --- linux-4.5.3/debian/changelog2016-05-08 16:03:45.0 +0200 +++ linux-4.5.3/debian/changelog2016-05-17 06:21:11.0 +0200 @@ -1,3 +1,10 @@ +linux (4.5.3-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Enable building linux-libc-dev for tilegx. (Closes: #-1) + + -- Helmut Grohne <hel...@subdivi.de> Tue, 17 May 2016 06:20:55 +0200 + linux (4.5.3-2) unstable; urgency=medium * [s390x] PCI: Ignore zpci ABI changes; these functions are not used by diff --minimal -Nru linux-4.5.3/debian/config/defines linux-4.5.3/debian/config/defines --- linux-4.5.3/debian/config/defines 2016-05-08 12:56:03.0 +0200 +++ linux-4.5.3/debian/config/defines 2016-05-17 06:22:27.0 +0200 @@ -30,6 +30,7 @@ sh4 sparc sparc64 + tilegx x32 compiler: gcc-5 featuresets: diff --minimal -Nru linux-4.5.3/debian/config/tilegx/defines linux-4.5.3/debian/config/tilegx/defines --- linux-4.5.3/debian/config/tilegx/defines1970-01-01 01:00:00.0 +0100 +++ linux-4.5.3/debian/config/tilegx/defines2016-05-17 06:22:08.0 +0200 @@ -0,0 +1,4 @@ +[base] +kernel-arch: tile +featuresets: +# empty; just building headers yet
Bug#823632: linux-libc-dev: architecture-dependent header in non-multiarch directory
Package: linux-libc-dev Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Ben et al, While looking into bootstrapping tilegx (#823167), I noticed that linux installs some architecture dependent headers directly into /usr/include. Exampes include: /usr/include/arch/abi.h /usr/include/arch/opcode.h These should be moved to /usr/include/tilegx-linux-gnu. I am attaching an architecture-generic patch. Please consider applying it. Helmut --- a/debian/rules.real +++ b/debian/rules.real @@ -341,6 +341,8 @@ # Move include/asm to arch-specific directory mkdir -p $(OUT_DIR)/include/$(DEB_HOST_MULTIARCH) mv $(OUT_DIR)/include/asm $(OUT_DIR)/include/$(DEB_HOST_MULTIARCH)/ + test -d $(OUT_DIR)/include/arch && \ + mv $(OUT_DIR)/include/arch $(OUT_DIR)/include/$(DEB_HOST_MULTIARCH)/ +$(MAKE_SELF) install-base
Bug#718297: linux-source-3.10: broken binary package contains uncompressed member data.tar.gz
Package: linux-source-3.10 Version: 3.10.3-1 Severity: important The binary package linux-source-3.10 does not comply to man 5 deb. It contains a data.tar.gz, that is not a valid gzip file. While the cause is in dpkg (see #718295). I ask you to work around this issue, by passing -z1 instead of -z0. Helmut -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130729194117.ga26...@alf.mars
Bug#707583: initramfs-tools: clarify documentation on break parameter
Package: initramfs-tools Version: 0.112 Severity: minor Tags: patch When reading man 8 initramfs-tools I was wondering whether the shell spawned due to break=something would be spawned before or after the corresponding scripts. I suggest to apply the attached patch to clarify this. Helmut --- initramfs-tools.8.orig 2013-05-09 16:09:38.0 +0200 +++ initramfs-tools.8 2013-05-09 16:28:07.0 +0200 @@ -107,7 +107,9 @@ .TP \fB\fI break spawns a shell in the initramfs image at chosen run-time -(top, modules, premount, mount, mountroot, bottom, init). +(top, modules, premount, mount, mountroot, bottom, init) +before actually executing the corresponding scripts +(see section boot scripts) or action. The default is premount without any arg. Beware that if both panic and break are present, initramfs will not spawn any shells but reboot instead.
Re: fix for #682964 is incomplete, maybe related to #630581
On Thu, Nov 08, 2012 at 10:13:59AM +0100, Uwe Kleine-König wrote: So copy_exec behaves like cp(1). Maybe introduce a warning for wheezy if the 2nd argument is a directory in /? This isn't 100% fail-safe but should catch most cases (among them all of the above instances). No, copy_exec does not behave like cp. If I give cp a destination where directory components are missing, cp will not create them, but copy_exec will. Given that the documentation of copy_exec clearly says that the second parameter must be a filename I am all for emitting that warning (after wheezy). Maybe also keep the cp semantics for copy_exec and only warn in the failing cases? (i.e. test -d $2 test ! -d $pathtoinitramfs/$2) I tend to prefer the original semantics. + They are easy to understand. + They are already documented. + The suggested warning can cause false positives which calls for more workarounds. On the other hand I am not maintaining that stuff, so this is not my call. Helmut -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109120807.ga30...@alf.mars
Re: fix for #682964 is incomplete, maybe related to #630581
So I had a further look into the dropbear initramfs issue. The code
where the breakage occurs is dropbear's hook:
| LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* =
\(/lib.*\)/libc\.so\..*,\1,p')
| for so in $(find ${LIBC_DIR} -name 'libnss_compat*'); do
| copy_exec ${so} ${LIBC_DIR}
| done
The error lies in the innocent looking copy_exec line. The target is a
directory here, but the documentation of copy_exec says it should be a
file:
| # $1 = file to copy to ramdisk
| # $2 (optional) Name for the file on the ramdisk
| # Location of the image dir is assumed to be $DESTDIR
| # We never overwrite the target if it exists.
| copy_exec() {
So if the target directory happens to not exist which is the case for
LIBC_DIR=/lib/i386-linux-gnu/i686/cmov in my case, the source will be
copied to that name. So cmov ends up being a regular file and not a
directory containing the file.
Now really whose bug is this? Let us have a look at other users that
pass a second parameter to copy_exec.
Those that pass a directory:
/usr/share/initramfs-tools/hooks/keymap:copy_exec /bin/loadkeys /bin
/usr/share/initramfs-tools/hooks/keymap:copy_exec /usr/bin/kbd_mode /bin
/usr/share/initramfs-tools/hooks/dropbear: copy_exec
/usr/sbin/dropbear /sbin/
/usr/share/initramfs-tools/hooks/dropbear: copy_exec
${so} ${LIBC_DIR}
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevd /sbin
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevadm/sbin
/usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/$program /lib/udev
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/blkid /sbin
/usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/vio_type /lib/udev
/usr/share/initramfs-tools/hooks/mdadm:copy_exec $MDADM /sbin
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec /lib/cryptsetup/scripts/$KEYSCRIPT /lib/cryptsetup/scripts 2
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec $KEYSCRIPT /lib/cryptsetup/scripts 2
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec ${KSTYPE#$KEYSCRIPT is } /lib/cryptsetup/scripts 2
The one gets it right:
/usr/share/initramfs-tools/hooks/busybox: copy_exec ${BUSYBOXDIR}/busybox
/bin/busybox
It seems like most users actually get this wrong. Out of sheer (bad)
luck this has not been discovered thus far.
How do we proceed now? The current API of copy_exec is bad, because it
relies on auxiliary state (the target being a directory or not). It
should be fixed, but this is likely too late for wheezy, given the
number of packages that need to be changed as well.
The particular dropbear issue can be avoided by actually omitting the
second parameter and letting copy_exec sort it out correctly. I believe
that this change should fix both bugs #682964 and #630581.
Thanks to Tino Keitel for assisting in sorting this out.
Helmut
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108085157.GA19423@localhost
Bug#627669: linux-image-2.6.38-2-amd64: [brcm80211] oops on iwlist wlan0 scanning
Hi Moritz, On Tue, May 24, 2011 at 06:46:58PM +0200, Moritz Mühlenhoff wrote: Please retest with 2.6.39-1 from unstable. I just did that while you wrote this mail and it at least no longer oopses on either iwlist wlan0 scanning or iwlist wlan0 essid something. Thanks for the work (or forward those thanks to the proper people). Helmut -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524164921.ga28...@alf.mars
Bug#627669: linux-image-2.6.38-2-amd64: [brcm80211] oops on iwlist wlan0 scanning
Package: linux-image-2.6.38-2-amd64 Version: 2.6.38-5 Severity: normal I do know that brcm80211 comes from the staging tree. Nevertheless I hereby document one of its problems. firmware-brcm80211 version is 0.29 # lspci -v -s 05:00.0 05:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) Subsystem: Askey Computer Corp. Device 7179 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f010 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 ? Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 00-00-de-ff-ff-66-4c-ed Capabilities: [16c] Power Budgeting ? Kernel driver in use: brcm80211 # [ 153.268345] netconsole: network logging started # ifconfig wlan0 up [ 168.843577] wl0: wlc_wme_setparams : no-clock [ 168.845719] wl0: wlc_wme_setparams : no-clock [ 168.847818] wl0: wlc_wme_setparams : no-clock [ 168.849889] wl0: wlc_wme_setparams : no-clock [ 168.851577] ADDRCONF(NETDEV_UP): wlan0: link is not ready # iwlist wlan0 scanning [ 181.504059] ops-tx called while down [ 181.506653] ops-tx called while down [ 181.509277] ops-tx called while down [ 181.511893] ops-tx called while down [ 181.514525] ops-tx called while down [ 181.517167] ops-tx called while down [ 181.519790] ops-tx called while down [ 181.522330] ops-tx called while down [ 181.524748] ops-tx called while down [ 181.527045] ops-tx called while down [ 181.529250] ops-tx called while down [ 181.531412] [ cut here ] [ 181.533725] WARNING: at /build/buildd-linux-2.6_2.6.38-5-amd64-MAWrSr/linux-2.6-2.6.38/debian/build/source_amd64_none/net/mac80211/tx.c:1506 ieee80211_tx+0x1b3/0x1d9 [mac80211]() [ 181.539044] Hardware name: N150P/N210P/N220P [ 181.541798] tx refused but queue active [ 181.544501] Modules linked in: netconsole configfs acpi_cpufreq mperf cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_stats btusb bluetooth snd_hda_codec_realtek uvcvideo option videodev usb_wwan usbserial usb_storage v4l2_compat_ioctl32 uas snd_hda_intel snd_hda_codec arc4 i915 ecb brcm80211(C) snd_hwdep drm_kms_helper snd_pcm drm uhci_hcd mac80211 tpm_tis ehci_hcd joydev tpm i2c_algo_bit cfg80211 i2c_i801 tpm_bios usbcore snd_timer i2c_core snd pcspkr rfkill psmouse evdev soundcore ac battery snd_page_alloc serio_raw power_supply sky2 nls_base processor button video ext3 jbd mbcache sha256_generic aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [ 181.567949] Pid: 167, comm: kworker/u:3 Tainted: G C 2.6.38-2-amd64 #1 [ 181.572210] Call Trace: [ 181.576409] [81046e10] ? warn_slowpath_common+0x78/0x8c [ 181.580741] [81046ec3] ? warn_slowpath_fmt+0x45/0x4a [ 181.585044] [a026041d] ? ieee80211_tx+0x1b3/0x1d9 [mac80211] [ 181.589346] [810ec250] ? virt_to_head_page+0x9/0x2d [ 181.593751] [a02605c7] ? ieee80211_xmit+0x184/0x193 [mac80211] [ 181.598286] [a026061e] ? ieee80211_tx_skb+0x48/0x51 [mac80211] [ 181.602889] [a024e85e] ? ieee80211_scan_work+0x35e/0x47f [mac80211] [ 181.607437] [81325adb] ? schedule+0x55b/0x588 [ 181.611944] [a024e500] ? ieee80211_scan_work+0x0/0x47f [mac80211] [ 181.616498] [8105b17a] ? process_one_work+0x1d1/0x2ee [ 181.621058] [8105d0c0] ? worker_thread+0x12d/0x247 [ 181.625604] [8105cf93] ? worker_thread+0x0/0x247 [ 181.630110] [8105cf93] ? worker_thread+0x0/0x247 [ 181.634538] [8105fef7] ? kthread+0x7a/0x82 [ 181.639015] [8100a764] ? kernel_thread_helper+0x4/0x10 The machine goes unresponsive at this point. If I can help with debugging the issue, please let me know. Helmut -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523130006.ga20...@alf.mars
Bug#472409: mkinitramfs: please mention that -d config_dir option requires an absolute path
Package: initramfs-tools Version: 0.91e Severity: normal Invoking mkinitramfs using -d conf where conf is a relative path results in cpio bailing out: cpoio: ./conf/initramfs.conf: Cannot stat: No such file or directory Providing an absolute path makes this go away. I therefore suggest adding a note to the mkinitramfs manpage or internally finding the real path. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445510: initramfs-tools: please fail gracefully for ENOSPC
Package: initramfs-tools Version: 0.85h Severity: wishlist I recently set up a system with /boot being too small. While this is my fault update-initramfs could handle this in a better way than backup the old (working) initramfs and leave a truncated one for the next reboot will fail. (Yes, it told me that my initramfs was broken afterwards!) (According to my understanding of the scripts the bug also applies to 0.91b.) I therefore suggest not creating the new initramfs directly, but create a new file with a different name and then in the last step rename the stuff if and only if no error occurred. By doing so the system will more often be in a bootable state. Furthermore this will prevent making a system unbootable by suspending the machine while updating the initramfs (a DD reported this on planet.d.o). Helmut [extra info wiped as this bug occurred on a different system] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
