Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop
Control: tag -1 moreinfo On Mon, 12 Feb 2024 03:47:14 -0500 Bud Heal wrote: [...] > I scanned a few pages, then plugged into the USB cable, at which point > the wand shows "USB" and Bullseye mounts the SD as a USB disk. The first > time on Bullseye, it worked okay. The second and afterwards, not so > okay. > > The key before Bullseye was the thumbnails would show all black, usually > at the bottom of a folder. The images before the all black ones, usually > were apparently unaffected. By memory, there were screwy problems but > nothing like now. > > Under Bullseye, just inserting or mounting the SD leads to corruption. > The files are are "readable" but not as proper images. When I insert the > SD into a Windows (10) laptop, it asks to check the filesystem and will > toss the unreadable images and leave the ones that are all black. [...] If I experienced these problems, I would assume that my SD card was faulty (or even a counterfeit that has less storage than it claims to). Since the card appeared to work under Windows, please could you test it more thoroughly under Windows: 1. Copy files onto the card to fill it up. 2. Remove and reinsert the card. 3. Compare the files on the card with the files you copied from. and report back here. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Control: tag -1 moreinfo On Wed, 6 Dec 2023 21:36:53 +0100 Paul Gevers wrote: > Control: tags -1 - moreinfo > > Hi Ben and the rest, > > On 04-12-2023 15:10, Ben Hutchings wrote: > >> CPU: 6 PID: 15039 Comm: lxc-start Tainted: G D W L > >> 6.5.0-0.deb12.1-arm64 #1 Debian 6.5.3-1~bpo12+1 > > > > The D and W flags mean there were prior BUG and WARN errors logged. > > Please send those as well. > > Please find attached the content of the journal since the reboot. I > filtered out "debci". Apologies for leaving this bug for so long. Is this bug still occurring? I had a look for possibly related fixes, and found: commit 22e111ed6c83dcde3037fc81176012721bc34c0b Author: Al Viro Date: Sun Nov 19 20:25:58 2023 -0500 rename(): fix the locking of subdirectories [...] Cc: sta...@vger.kernel.org Fixes: 28eceeda130f "fs: Lock moved directories" This claims to a fix a bug introduced in 6.5. The fix went into 6.8-rc1 and was backported to 6.6.15, so Debian versions 6.6.15-1 onward should have it. The lockup might alternately be fixed by: commit a8b0026847b8c43445c921ad2c85521c92eb175f Author: Al Viro Date: Mon Nov 20 20:02:11 2023 -0500 rename(): avoid a deadlock in the case of parents having no common ancestor which went into 6.8 but was *not* backported. If the bug is still occurring, can you say what type of filesystem rsync is being run on? Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#1066942: Debugging xmrig FTBFS on armhf
I could not reproduce the issue on an armhf porterbox, which is concerning. I have just uploaded a new release that just tells cmake to force an ARMv7 build if DEB_HOST_ARCH is armhf. It also includes a handy patch that makes the build log give a couple clues so I can track down why my machine and the porterbox can't reproduce it but the buildd can. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: Debugging xmrig FTBFS on armhf
It seems that the maes flag is automatically added if the ARM_TARGET CMake var is not set, which happens in cmake/cpu.cmake. The first thing I saw when I opened that file looked promising: if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(XMRIG_64_BIT ON) add_definitions(-DXMRIG_64_BIT) else() set(XMRIG_64_BIT OFF) endif() I figured that maybe SIZEOF_VOID_P changed with the t64 transition and this caused it to get confused and think that we are building on x86_64. Then I looked closer at the buildd log and saw that XMRIG_64_BIT was (correctly) set to OFF, which means that this could not be the issue. The next lines of interest are here: if (CMAKE_SYSTEM_PROCESSOR MATCHES "^(aarch64|arm64|armv8-a)$") set(ARM_TARGET 8) elseif (CMAKE_SYSTEM_PROCESSOR MATCHES "^(armv7|armv7f|armv7s|armv7k|armv7-a|armv7l|armv7ve)$") set(ARM_TARGET 7) endif() There are no other functions modifying the ARM_TARGET other than the option to override this value by manually setting the ARM_V7 variable. This means that CMAKE_SYSTEM_PROCESSOR must not be matching one of the armv7* values on buildd and your machine, but does on all of mine. The build could be fixed by setting ARM_V7 in d/rules on armhf, but I would prefer properly resolving this issue instead of just working around it. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, Since my last message, I have tried to reproduce this in several ways, e.g. an sbuild chroot in both qemu-user-static and on actual hardware (Raspberry Pi 2), and also a direct build on an armhf VM. It always builds successfully. Since then, there has been a new upstream release of xmrig, so I figured I would just upload and see if it still fails buildd. On the buildd log, it indeed fails with the same maes error. This means xmrig thinks it's building on x86 and adds those flags, but this doesn't happen on arm64; only on armhf, only after the t64 transition. It also doesn't happen on any of my systems but does on buildd and apparently your system. I guess I'll request guest access to an armhf porterbox and hope FTBFS happens there so I can debug this. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Sebastian, I can't seem to reproduce this on an armhf chroot, VM, or actual hardware (all unstable). When were you last able to reproduce this? It's possible (since unstable has changed rapidly in recent days) that the problem was something external that fixed itself between then and now. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, The package builds fine on my armhf VM as well as a Raspberry Pi 2 running armhf Debian bare metal. Maybe some transitioning library caused this issue? If xmrig gets binNMU'd, it will probably build successfully. I would do it, but I'm not a Debian Developer. Could you do it? Thanks, -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
It turned out to just be a test expecting the 32 bit limit. This is patched in the newest version which I have just uploaded. Build fixed! -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
Hello, Arch Linux ARM supports armhf/armel just fine, so I think this can work with little to no patches. I haven't been able to take a look since the t64 transition because I have been busy with other things. I will likely have time tomorrow to fix this. -- Ben Westover
Bug#1054726: python-daemon: FTBFS: ValueError: ("Missing 'Version:' header and/or PKG-INFO file at path: /<>/python_daemon.egg-info/PKG-INFO", python-daemon [unknown version] (/<
Control: notfound -1 python-daemon/3.0.1-1.1 Control: reassign -1 dh-python Control: found -1 dh-python/6.20231025 Control: retitle -1 dh-python: Packages FTBFS because of missing metadata Control: fixed -1 dh-python/6.20231204 Control: fixed -1 dh-python/6.20231223 On 16-Dec-2023, s3v wrote: > I've just checked your package does build fine in a sid chroot > environment and reproducible-builds confirms that Thank you. When I build in an up-to-date ‘unstable’ (where ‘dh-python’ is at version “6.20231223”), I also get a successful build from source today. > it was built against dh-python/6.20231025 but the current version in sid is > dh-python/6.20231204. I can reproduce the failure with this commit reverted Agreed, this bug was in ‘dh-python’ and is now fixed. -- \ “I was stopped by the police for speeding; they said ‘Don't you | `\ know the speed limit is 55 miles an hour?’ I said ‘Yeah I know, | _o__) but I wasn't going to be out that long.’” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations)
Control: user helm...@debian.org Control: usertag -1 dep17p1 According to the classification in DEP-17 <https://subdivi.de/~helmut/dep17.html> this is problem type P1. libnfsidmap1 includes mitigation M7 (Conflicts with the other packages) since version 1:2.5.4-1~exp2, but although this usually avoids P1 we now know that this is not always the case. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations
Package: libnfsidmap1
Version: 1:2.5.4-1~exp1
Severity: serious
As receently disvovered by Helmut Grohne, a conflict between binary
packages does not ensure that the files of one will be removed before
the files of the other are installed. This can result in file loss
when the conflict involves aliased filenames rather than exactly the
same filenames.
This specific scenario exists when installing libnfsidmap1 as a
replacement for libnfsidmap{2,-regex} packages. I was able to
reproduce it with the following sequence of commands in a minimal
bullseye amd64 chroot:
# apt -y install usrmerge
# apt -y install libnfsidmap{2,-regex}
# sed -i 's/bullseye/bookworm/' /etc/apt/sources.list
# apt update
# apt -d -y install libnfsidmap1
# (cd /var/cache/apt/archives && \
dpkg -i libc{6,-bin}_2.36-9+deb12u3_amd64.deb \
libsasl2-{2,modules-db}_2.1.28+dfsg-10_amd64.deb \
libgmp10_2%3a6.2.1+dfsg1-1.1_amd64.deb \
libgnutls30_3.7.9-2_amd64.deb libldap-2.5-0_2.5.13+dfsg-5_amd64.deb)
# dpkg -i /var/cache/apt/archives/libnfsidmap1_1%3a2.6.2-4_amd64.deb
Ben.
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Control: reassign -1 src:linux 6.5.3-1~bpo12+1 Control: tag -1 moreinfo On Sat, 2023-12-02 at 18:11 +0100, Paul Gevers wrote: > Package: linux-image-6.5.0-0.deb12.1-arm64 > Version: 6.5.3-1~bpo12+1 > Severity: serious > Justification: system stops responding > > Dear kernel maintainers, > > Thursday 30 November I upgraded the ci.debian.net workers. We're running > the backports kernel there due to issues we discussed earlier, but after > upgrading, we lost access to our arm64 hosts one after the other. We're > running the 6.4 kernel again now, and I extracted some of the logs. > Please let me know if you need more info. The first error logged in this file has: > CPU: 6 PID: 15039 Comm: lxc-start Tainted: G D WL > 6.5.0-0.deb12.1-arm64 #1 Debian 6.5.3-1~bpo12+1 The D and W flags mean there were prior BUG and WARN errors logged. Please send those as well. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman signature.asc Description: This is a digitally signed message part
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. > > Yes, this will make the build unreproducible, but no better solution > currently exists. There are some plans, but no-one is working on them. > If a suitable replacement shows up, we can always switch to that > solution. Builds for the architectures involved are already unreproducible due to inconsistent generation of BTF in both the kernel and modules. Additionally, my "plan" would also get rid of signing modules with the Secure Boot CA, so I'm not going to object to this. [...] > ## Image packages contains more version info > > By renaming the kernel packages we try to make several kernels > installable at the same time. In contrast to rpm, where you can have > the same package installed multiple times in different versions, dpkg > only supports a single one at the same time. So the co-installable > versions needs to have different package names. > > The packages will include the full upstream version. There exists the > exception of devel builds and uploads to experimental, wich will contain > even less of the version, to avoid new names in that cases. > > Example: linux-image-6.5.3-cloud-arm64 > > There are some drawbacks. > > The same upstream version in testing and backports will have the same > package name. This is not OK, because they will be incompatible on architectures supporting SB (and sometimes incompatible on others due to compiler differences or required config changes). If someone upgrades from stable + backports to testing, and has OOT modules: - With DKMS, will a rebuild be triggered if the linux-image package name doesn't change? - With module-assistant, the new linux-image package will satisfy dependencies of the old modules even though they are incompatible. > Multiple uploads of the same upstream version will have > the same package name, but those rarely happens. Those happen fairly often for urgent security updates. > Those packages will > not be compatible and a reboot is necessary to be able to load modules > again. > > It will not longer be possible to reliably derive the package name from > kernel release (see above), as both values are not really related > anymore. Given all the drawbacks, I don't see the benefit of decoupling package names from release strings. In the same way that shared library packages must be renamed for every backward-incompatible ABI changes, I believe we should keep doing this for linux-image packages. > ## Header and tool packages will not longer contain version > > The headers packages will not longer include the version. It won't be > reliably possible to derive the package name anyway from the running > kernel. > > This means that only headers of one single version can be available on > the system at one time. This might be a bit inconvinient for dkms, as > it can't longer build modules for multiple versions. > > But we too often have the problem that image and headers go out of sync > and then you can't find the correct ones anyway. > > Example: linux-headers-cloud-arm64 This is all downside with no justification given. Please explain what the benefit is. > ## Installer packages will not longer contain too much version > > The installer can only ever handle one version of kernel. Also it got > an internal mechanism to detect which packages belong together > (the Kernel-Version control entry). So we have no need to rename them > and force a matching change in d-i itself just because a new kernel > exists. So it will not longer contain the full version in the package > names if not needed. [...] In the installer, netboot images break every time the kernel ABI is bumped. I think there's a specific check and error message for this, but I'm not exactly sure. It should be verified that this detection will work the way you expect, so that the error message doesn't change and create a support burden for the installer team. Currently kernel-wedge generates the udeb package names and would need to add an option to leave out the version part of the names. I'm happy to work on that once we have an agreement for what to do. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#1042978: Tests invalid package upgrades
On Thu, 2023-08-03 at 22:01 +0200, Paul Gevers wrote: > Control: reassign -1 release.debian.org > > Hi Ben, > > On 03-08-2023 18:01, Ben Hutchings wrote: > > ci.debian.net must therefore also test updating the binaries from all > > these source packages together, not just those built from linux. > > But ci.debian.net just does what it's been asked to do by the client, in > this case britney. So, if anything it's britney2 that needs to be > changed to support this. Thank you for redirecting this appropriately. > But, britney2 tries to deduce what needs to be > tested together from the package relations. Normally, what you're seeing > here is the result of a test where the signed packages haven't been > build yet. britney retries tests after 24 hours and normally it retries > with linux-signed-* in the list of pinned packages as you can see in the > dkms history. The question that now arises is why it doesn't do that now. I suspect that the difference is that most linux updates bump ABI (thus changing package names) and this last update did not need to. The package that linux-headers-amd64/unstable depends on typically don't exist in testing at all, but in this case it does (at the wrong version). Perhaps something in britney's invocation of debci isn't paying attention to all the version constraints. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#1042978: Acknowledgement (Tests invalid package upgrades)
The test log for reference: https://ci.debian.net/data/autopkgtest/testing/amd64/d/dkms/36392756/log.gz Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#1042978: Tests invalid package upgrades
Package: debci Severity: serious X-Debbugs-Cc: debian-ker...@lists.debian.org ci.debian.net is running dkms's autopkgtest with packages from testing except for linux's binaries updated from unstable. The test fails because linux-headers-amd64 is uninstallable in this scenario: * The available version of linux-headers-amd64 will be the latest, 6.4.4-2. It depends on (currently) linux-headers-6.4.0-1-amd64 at the same version. * The available version of linux-headers-6.4.0-1-amd64 (built from src:linux-signed-amd64) will be 6.4.4-1. This cross-source-package version lock is unusual but has been implemented deliberately to ensure that linux and linux-signed-* always migrate from unstable to testing together. ci.debian.net must therefore also test updating the binaries from all these source packages together, not just those built from linux. If it's not possible to do this in a general way then we need a specific workaround that can be used in dkms and any other affected packages to prevent this invalid test scenario. Ben. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debci depends on: ii adduser 3.137 pn amqp-tools ii bsdmainutils12.1.8 ii curl7.88.1-10 ii dctrl-tools 2.24-3+b1 ii debian-archive-keyring 2023.3 ii debootstrap 1.0.128+nmu5 ii devscripts 2.23.5 ii distro-info 1.5 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 ii jq 1.6-2.1 pn libjs-bootstrap ii libjs-jquery3.6.1+dfsg+~3.5.14-1 pn libjs-jquery-flot ii moreutils 0.67-1 ii netcat-openbsd 1.225-1 ii netcat-traditional 1.10-47 pn parallel ii patchutils 0.4.2-1 pn retry ii rsync 3.2.7-1 ii ruby1:3.1 pn ruby-activerecord pn ruby-bunny pn ruby-erubi pn ruby-kaminari-activerecord pn ruby-minitar pn ruby-omniauth-gitlab pn ruby-sinatra pn ruby-sinatra-contrib pn ruby-sqlite3 | ruby-pg pn ruby-thor ii sudo1.9.14p2-1 Versions of packages debci recommends: ii systemd-timesyncd [time-daemon] 254~rc3-3 Versions of packages debci suggests: pn apt-cacher-ng pn auto-apt-proxy
Bug#1041855: linux-image-6.4.0-1-amd64: IO wait regression
Control: severity -1 important On Mon, 2023-07-24 at 15:40 +0200, Christian Göttsche wrote: > Package: src:linux > Version: 6.4.4-1 > Severity: serious > > Dear Maintainer, > > Kernel 6.4.4 is affected by a regression causing one core be report > high IO wait utilization. > > See https://lore.kernel.org/lkml/12251678.o9o76zd...@natalenko.name/ There is no such thing as a CPU having "high IO wait utilization". When tasks are in I/O wait state, they are not using a CPU. Unfortunately, for historical reasons Linux includes such tasks in the load average and reports a CPU as being in I/O wait state when it's idle and the last task running on it went into I/O wait state (at least I think that's what the rule is). So this bug is about an unwanted change in task/CPU state reporting, not tasks suddenly using much more CPU time. For that reason, I don't think it should "serious", i.e. a blocker for testing propagation. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#1040901: linux modules must not be signed with CA key, bump ABI every upload
On Wed, 12 Jul 2023 10:05:03 +0200 Julian Andres Klode wrote: [...] > A reasonable compromise at a first step for a limited time is to > ensure that > > 1) the kernel refuses to load modules for a different ABI in lockdown, > for example, the modprobe --force-vermagic does not work anymore. [...] I already implemented that in 2016. Did it break? Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug signature.asc Description: This is a digitally signed message part
Bug#1040178: Kernel modules will not build, missing asm/orc_header.h
On Wed, 2023-07-05 at 13:52 +0200, Bastian Blank wrote: > Control: reassign -1 dkms > > On Wed, Jul 05, 2023 at 10:53:19AM +0200, Vincent Lefevre wrote: > > On 2023-07-04 16:13:56 +0200, Andreas Beckmann wrote: > > > This needs to be fixed before linux 6.3.0-2-* can migrate to testing, > > > otherwise it will break dkms module building for everyone still having > > > linux-headers-6.3.0-1-* installed (which is probably for the currently > > > running kernel). > > On one of my machines, the upgrade was fine, but this is because the > > NVIDIA kernel module wasn't rebuilt for the 6.3.0-1 kernel (despite > > I have autoinstall_all_kernels="1" in /etc/dkms/framework.conf). So > > I suppose that this bug would affect the machine only if the NVIDIA > > packages are upgraded. > > This is dkms failing to build a module for an incompatible kernel. > Nothing can be done by the kernel to fix this as the kernel internal > interfaces are not stable, the module needs to be upgrade accordingly to > support the new interface. No, this is modpost inserting a reference to a new header. The incompatibility is in our own packages. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Bug#1034190: More security bugs in game loading
On Thu, 2023-04-20 at 10:01 +0200, Paul Gevers wrote: > Hi Ben, > > On Mon, 10 Apr 2023 22:01:04 +0200 Ben Hutchings > wrote: > > Package: sgt-puzzles > > Severity: serious > > The fix for this bug will not automatically migrate to testing because > the package doesn't have autopkgtests and we're in the freeze. The > changes are massive, They're actually not that massive, but split into a lot of small patches. > so I'd like to confirm in an unblock bug that all > changes are indeed targeted fixes before unblocking. Can you file such > an unblock request if you don't want the package to be autoremoved (or > add a non-superficial autopkgtest if that makes sense)? Yes, I will file an unblock request. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Bug#1034190: More security bugs in game loading
Package: sgt-puzzles Version: 20230122.806ae71-1 Severity: serious Tags: security upstream fixed-upstream X-Debbugs-Cc: Debian Security Team Ben Harris found multiple issues in sgt-puzzles where a malformed game description or save file can lead to a buffer overflow, buffer overread, use of an uniniitialised pointer, integer overflow, null pointer dereference, division by zero, assertion failure, or memory leak. These were fixed upstream over the past few months. The Debian package doesn't register any media type handler for save files, so I think this can only be exploited by social-engineering a user into loading such a file or description. For most of these bugs, the impact is limited to a crash of the application. However, the various memory safety errors may be more serious. On some architectures, division by zero does not cause an exception and this might also be exploitable. Ben. -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sgt-puzzles depends on: ii libc62.36-8 ii libcairo21.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-1 ii libgtk-3-0 3.24.37-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 Versions of packages sgt-puzzles recommends: ii chromium [www-browser] 111.0.5563.64-1 ii firefox [www-browser] 111.0-3 ii lynx [www-browser] 2.9.0dev.12-1 ii xdg-utils 1.1.3-4.1 sgt-puzzles suggests no packages. -- debconf-show failed
Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk
It seems like this bug is related to GRUB lacking LUKS2 support. Back in buster, GRUB only supported LUKS1, so this bug could only be worked- around by using LUKS1 for /boot. Now GRUB has some support for LUKS2 at boot time, but grub-probe doesn't recognise LUKS2 devices properly so the necessary modules don't get loaded automatically. There is a separate bug report #1028301 explicitly relating to grub- probe. I found the upstream commits that seem to fix it and added them to that bug report. Perhaps they would also fix this? Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing
This appears to be the same as #1028301, for which I've attached upstream patchs. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#1013594: insubstantial: FTBFS: Caused by: : java.lang.VerifyError: Expecting a stackmap frame at branch target 33
The laf-widget library that's part of this package generates some Java
bytecode directly:
<https://sources.debian.org/src/insubstantial/7.3+dfsg3-5/laf-widget/src/main/java/org/pushingpixels/lafwidget/ant/LafMainClassAugmenter.java/?hl=174>.
Since Java 11, additional metadata (the "stackmap frame") appears to be
required for Java bytecode, and is not generated by laf-widget.
However, this code generation is apparently only used to "augment" the
rendering of other widget classes and does not seem to be essential for
the function of the library. In fact, it was completely removed in a
later version of laf-widget:
https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d
I patched the Gradle build files to disable this code generation and
the build succeeded. I tested triplea with the old and new binaries
built from insubstantial: start the program, install the "Tutorial"
map, and start a local game with that map. I didn't see any
regressions. As I expected, the GUI rendering is different but only
slightly; see the attached "old" and "new" screenshots.
scilab is already broken (#1030205) so I couldn't test it.
I will NMU with the attached changes shortly.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
diff -Nru insubstantial-7.3+dfsg3/debian/changelog insubstantial-7.3+dfsg3/debian/changelog
--- insubstantial-7.3+dfsg3/debian/changelog 2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/changelog 2023-03-03 23:42:05.0 +0100
@@ -1,3 +1,10 @@
+insubstantial (7.3+dfsg3-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Java 11: disable augmentation (fixes FTBFS) (Closes: #1013594)
+
+ -- Ben Hutchings Fri, 03 Mar 2023 23:42:05 +0100
+
insubstantial (7.3+dfsg3-5) unstable; urgency=medium
[ Andrius Merkys ]
diff -Nru insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch
--- insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch 1970-01-01 01:00:00.0 +0100
+++ insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch 2023-03-03 23:11:22.0 +0100
@@ -0,0 +1,51 @@
+From: Ben Hutchings
+Subject: Java 11: disable augmentation
+Date: Fri, 03 Mar 2023 23:11:14 +0100
+Bug-Debian: https://bugs.debian.org/1013594
+
+Since Java 11, Java bytecode is required to include some additional
+metadata. The bytecode generated by laf-widget for "augmentation" of
+other widget libraries does not follow this requirement, resulting in
+a build failure.
+
+A later version of laf-widget has removed this augmentation rather
+than fixing it:
+https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d
+
+This augmentation does not seem to be essential, so disable it until
+it is fixed or properly removed.
+
+---
+--- a/substance-flamingo/build.gradle
b/substance-flamingo/build.gradle
+@@ -24,6 +24,8 @@ dependencies {
+
+ task augmentation(dependsOn: classes) {
+ description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++ // Broken under Java 11 - see Debian bug #1013594
++ enabled = false
+
+ doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance-swingx/build.gradle
b/substance-swingx/build.gradle
+@@ -25,6 +25,8 @@ dependencies {
+
+ task augmentation(dependsOn: classes) {
+ description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++ // Broken under Java 11 - see Debian bug #1013594
++ enabled = false
+
+ doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance/build.gradle
b/substance/build.gradle
+@@ -28,6 +28,8 @@ dependencies {
+
+ task augmentation(dependsOn: classes) {
+ description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++ // Broken under Java 11 - see Debian bug #1013594
++ enabled = false
+
+ doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath
diff -Nru insubstantial-7.3+dfsg3/debian/patches/series insubstantial-7.3+dfsg3/debian/patches/series
--- insubstantial-7.3+dfsg3/debian/patches/series 2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/patches/series 2023-03-03 22:31:44.0 +0100
@@ -4,3 +4,4 @@
asm5.patch
java9-compatibility.patch
fix-56.patch
+java-11-disable-augmentation.patch
signature.asc
Description: This is a digitally signed message part
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Control: tag -1 upstream fixed-upstream patch
On Mon, 09 Jan 2023 12:12:19 +0100 Laurent Bigonville
wrote:
> Package: grub-common
> Version: 2.06-7
> Severity: serious
> File: /usr/sbin/grub-probe
>
> Hello,
>
> On a newly installed laptop, it seems that grub-probe is not able to
> detect that files are on an encrypted FS.
>
> New laptop:
>
> $ sudo grub-probe -t abstraction
> /usr/share/images/desktop-base/desktop-grub.png
> lvm
>
> $ sudo lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> nvme0n1 259:0 0 476,9G 0 disk
> ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
> ├─nvme0n1p2 259:2 0 488M 0 part /boot
> └─nvme0n1p3 259:3 0 476G 0 part
> └─nvme0n1p3_crypt 254:0 0 475,9G 0 crypt
> ├─new_laptop--vg-root 254:1 0 27,9G 0 lvm /
> ├─new_laptop--vg-swap_1 254:2 0 976M 0 lvm [SWAP]
> ├─new_laptop--vg-home 254:3 0 40G 0 lvm /home
> └─new_laptop--vg-libvirt 254:4 0 60G 0 lvm /var/lib/libvirt
[...]
I can reproduce this. What changed is that we now use LUKS2 instead of
LUKS1. Although GRUB has some LUKS2 support, it doesn't probe LUKS2
volumes automatically.
I found the 3 upstream commits that are enough to make the "grub-probe
..." line work and am attaching a debdiff with those. I don't know
whether this is enough to completely fix the problem.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
--- grub2-2.06/debian/changelog 2023-02-25 21:16:55.0 +0100
+++ grub2-2.06/debian/changelog 2023-03-03 19:21:28.0 +0100
@@ -1,3 +1,15 @@
+grub2 (2.06-8.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix probing of LUKS2 devices (Closes: #1028301):
+- disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+ device
+- osdep/devmapper/getroot: Have devmapper recognize LUKS2
+- osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
+ parameters
+
+ -- Ben Hutchings Fri, 03 Mar 2023 19:21:28 +0100
+
grub2 (2.06-8.1) experimental; urgency=medium
* Non-maintainer upload.
diff -Nru grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
--- grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch 1970-01-01 01:00:00.0 +0100
+++ grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch 2023-03-03 19:21:28.0 +0100
@@ -0,0 +1,72 @@
+From: Fabian Vogt
+Date: Thu, 12 Jan 2023 17:05:07 -0600
+Subject: disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+ device
+Origin: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739
+Bug-Debian: https://bugs.debian.org/1028301
+
+When using grub-probe with cryptodisk, the mapped block device from the host
+is used directly instead of decrypting the source device in GRUB code.
+In that case, the sector size and count of the host device needs to be used.
+This is especially important when using LUKS2, which does not assign
+total_sectors and log_sector_size when scanning, but only later when the
+segments in the JSON area are evaluated. With an unset log_sector_size,
+grub_device_open() complains.
+
+This fixes grub-probe failing with
+"error: sector sizes of 1 bytes aren't supported yet.".
+
+Signed-off-by: Fabian Vogt
+Reviewed-by: Patrick Steinhardt
+Tested-by: Glenn Washburn
+Reviewed-by: Glenn Washburn
+Reviewed-by: Patrick Steinhardt
+Reviewed-by: Daniel Kiper
+---
+ grub-core/disk/cryptodisk.c | 20 ++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/grub-core/disk/cryptodisk.c
b/grub-core/disk/cryptodisk.c
+@@ -694,16 +694,31 @@ grub_cryptodisk_open (const char *name,
+ if (!dev)
+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No such device");
+
+- disk->log_sector_size = dev->log_sector_size;
+-
+ #ifdef GRUB_UTIL
+ if (dev->cheat)
+ {
++ grub_uint64_t cheat_dev_size;
++ unsigned int cheat_log_sector_size;
++
+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ dev->cheat_fd = grub_util_fd_open (dev->cheat, GRUB_UTIL_FD_O_RDONLY);
+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ return grub_error (GRUB_ERR_IO, N_("cannot open `%s': %s"),
+ dev->cheat, grub_util_fd_strerror ());
++
++ /* Use the sector size and count of the cheat device. */
++ cheat_dev_size = grub_util_get_fd_size (dev->cheat_fd, dev->cheat, _log_sector_size);
++ if (cheat_dev_size
Bug#1014166: Is this still accurate?
Hello, On January 19, 2023 5:24:06 PM EST, Salvatore Bonaccorso wrote: > A CVE description might only refer to a specific point in time's state > and might not be accurate. It needs first to be confirmed the issue > would be fixed in 0.22.0. Oh, alright. I thought that since it listed a start and end version, the CVE was fixed past the end version. > What are the references confirming the CVE is fixed in 0.22.0? Can you > refer to them so we can re-check? None. I'm not familiar with the codebase or this CVE, just passing by and wondered about that start and end version listed in the description. Thanks, -- Ben Westover signature.asc Description: PGP signature
Bug#1014166: Is this still accurate?
Hello, The CVE description states that versions 0.12.0 - 0.21.1 are vulnerable, but this package is currently version 22.0. Can this bug be closed? Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1028986: Multiple integer overflow and buffer overflow issues in game loading
Package: sgt-puzzles Version: 20220801.89391ba-1 Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Ben Harris found multiple issues in sgt-puzzles where a malformed game description or save file can lead to integer overflow or buffer overflow. These were fixed upstream today, and I'll upload the changes to unstable shortly. The Debian package doesn't register any media type handler for save files, so I think this can only be exploited by social-engineering a user into loading such a file or description. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sgt-puzzles depends on: ii libc62.36-6 ii libcairo21.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libglib2.0-0 2.74.3-1 ii libgtk-3-0 3.24.35-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 Versions of packages sgt-puzzles recommends: ii chromium [www-browser] 108.0.5359.124-1 ii firefox [www-browser] 108.0-2 ii lynx [www-browser] 2.9.0dev.10-1+b1 ii xdg-utils 1.1.3-4.1 sgt-puzzles suggests no packages. -- debconf-show failed
Bug#1028498: pysha3: FTBFS, “error: lvalue required as left operand of assignment”
Source: pysha3
Version: 1.0.2-5
Severity: serious
Tags: upstream ftbfs
Justification: Policy 4.9, FTBFS
Howdy,
When attempting to build the package from source using the Python 3.11
development libraries, this package fails to build. The relevant build
process output is:
=
running build_ext
building '_pysha3' extension
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/Modules
creating build/temp.linux-x86_64-cpython-311/Modules/_sha3
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
-DPY_WITH_KECCAK=1 -I/usr/include/python3.11 -c Modules/_sha3/sha3module.c -o
build/temp.linux-x86_64-cpython-311/Modules/_sha3/sha3module.o
Modules/_sha3/sha3module.c: In function ‘PyInit__pysha3’:
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:744:5: note: in expansion of macro ‘init_sha3type’
744 | init_sha3type("sha3_224", _224type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:745:5: note: in expansion of macro ‘init_sha3type’
745 | init_sha3type("sha3_256", _256type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:746:5: note: in expansion of macro ‘init_sha3type’
746 | init_sha3type("sha3_384", _384type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:747:5: note: in expansion of macro ‘init_sha3type’
747 | init_sha3type("sha3_512", _512type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:749:5: note: in expansion of macro ‘init_sha3type’
749 | init_sha3type("keccak_224", _224type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:750:5: note: in expansion of macro ‘init_sha3type’
750 | init_sha3type("keccak_256", _256type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:751:5: note: in expansion of macro ‘init_sha3type’
751 | init_sha3type("keccak_384", _384type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:752:5: note: in expansion of macro ‘init_sha3type’
752 | init_sha3type("keccak_512", _512type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:754:5: note: in expansion of macro ‘init_sha3type’
754 | init_sha3type("shake_128", );
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:755:5: note: in expansion of macro ‘init_sha3type’
755 | init_sha3type("shake_256", );
| ^
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:388: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
=
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
\ “Marriage is a wonderful institution, but who would want to |
`\live in an institution
Bug#1028494: pysha3: FTBFS, expects Python header file ‘pystrhex.h’ removed in Python 3.11
Control: retitle -1 pysha3: FTBFS, expects Python header file ‘pystrhex.h’ removed in Python 3.11 Control: forwarded -1 https://github.com/tiran/pysha3/issues/15 Control: tags -1 + upstream confirmed Thanks Adrian, On 12-Jan-2023, Adrian Bunk wrote: > In file included from Modules/_sha3/sha3module.c:20: > Modules/_sha3/backport.inc:78:10: fatal error: pystrhex.h: No such file or > directory >78 | #include "pystrhex.h" This is reported at the upstream project as a known bug https://github.com/tiran/pysha3/issues/15>. Fortunately, the code base already has a fallback local implementation of the function, and upstream have already fixed this bug by using that local implementation unconditionally. I will incorporate that change in a new Debian release of this package. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding, 1973 | Ben Finney signature.asc Description: PGP signature
Bug#1024148: python3-coverage: Python 3.11 support incomplete due to ignored error during build
Howdy Stefano, On 16-Nov-2022, Debian Bug Tracking System wrote: > > forwarded 1024148 https://github.com/nedbat/coveragepy/issues/1367 > Bug #1024148 [python3-coverage] python3-coverage: Python 3.11 support > incomplete due to ignored error during build > Set Bug forwarded-to-address to > 'https://github.com/nedbat/coveragepy/issues/1367'. Thank you for finding the existing upstream bug report, and recording this metadata. On 16-Nov-2022, Stefano Rivera wrote: > I've prepared an NMU for python-coverage (versioned as 6.2+dfsg1-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I should delay > it longer. Yes, please delay that; in investigating this bug report I saw (as you have, by now) that upstream's current version “6.5.0” addresses this bug. I am working to package and release that for Debian. -- \ “Nothing is so common as to imitate one's enemies, and to use | `\ their weapons.” —Voltaire, _Dictionnaire Philosophique_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1019564: (during upgrade) grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
y previously-working system gets left
unchanged.
With this bug, I have officially had more boot problems with Debian stable
than I have on testing/sid machines. (though still nowhere near as much as
trying to make EFI work for install in the first place).
Thanks,
- Ben
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/titan--vg-root / btrfs
rw,relatime,space_cache,subvolid=256,subvol=/@rootfs 0 0
/dev/sda1 /boot ext2 rw,relatime,stripe=4 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod lvm
insmod btrfs
set
root='lvmid/nN3A1g-g1t5-2BcZ-tULj-DqDp-ZBCV-G1aVx8/ts4AD4-fHUP-jCRg-Zmxe-p73b-MvnY-h0t14z'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/nN3A1g-g1t5-2BcZ-tULj-DqDp-ZBCV-G1aVx8/ts4AD4-fHUP-jCRg-Zmxe-p73b-MvnY-h0t14z'
f1ba88a4-f4fd-4324-8157-acd5c53ce639
else
search --no-floppy --fs-uuid --set=root f1ba88a4-f4fd-4324-8157-acd5c53ce639
fi
font="/@rootfs/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod lvm
insmod btrfs
set
root='lvmid/nN3A1g-g1t5-2BcZ-tULj-DqDp-ZBCV-G1aVx8/ts4AD4-fHUP-jCRg-Zmxe-p73b-MvnY-h0t14z'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/nN3A1g-g1t5-2BcZ-tULj-DqDp-ZBCV-G1aVx8/ts4AD4-fHUP-jCRg-Zmxe-p73b-MvnY-h0t14z'
f1ba88a4-f4fd-4324-8157-acd5c53ce639
else
search --no-floppy --fs-uuid --set=root f1ba88a4-f4fd-4324-8157-acd5c53ce639
fi
insmod png
if background_image
/@rootfs/usr/share/desktop-base/homeworld-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-f1ba88a4-f4fd-4324-8157-acd5c53ce639' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
31247b29-2160-4fa1-9e6d-7055ab40e08d
else
search --no-floppy --fs-uuid --set=root
31247b29-2160-4fa1-9e6d-7055ab40e08d
fi
echo'Loading Linux 5.10.0-18-amd64 ...'
linux /vmlinuz-5.10.0-18-amd64 root=/dev/mapper/titan--vg-root ro
rootflags=subvol=@rootfs quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-5.10.0-18-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-f1ba88a4-f4fd-4324-8157-acd5c53ce639' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-18-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-5.10.0-18-amd64-advanced-f1ba88a4-f4fd-4324-8157-acd5c53ce639' {
Bug#1016936: dwz: fails while building assaultcube
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27375 OK, so it turns out this error is due to Clang's adoption of DWARFv5 [1] which dwz doesn't fully support yet [2]. Until that is fixed, the issue can be worked around by using DWARFv4 by adding `-gdwarf-4` to flags. -- Ben Westover [1] https://www.phoronix.com/news/LLVM-Clang-DWARFv5-Default [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24726 OpenPGP_signature Description: OpenPGP digital signature
Bug#1016936: dwz: fails while building assaultcube
Control: retitle 1016936 dwz: Unknown debugging section .debug_addr causes some builds to fail Control: tags 1016936 + upstream Hello, This error also occurred for me when building PolyMC under Clang, but not GCC. It seems this problem is common for many Clang builds [1]. Fedora also seems to be having issues with this; Thus, I'm retitling this bug to be more generic, and adding an upstream tag. I will create a bug when my Bugzilla account creation request is approved by the admin. Thanks, -- Ben Westover [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997080#41 OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: Upstream bug report
tags 1017499 + upstream -- I was about to report the bug upstream, but it looks like Leandro beat me to it. https://gitlab.freedesktop.org/mesa/mesa/-/issues/7117 -- Ben Westover signature.asc Description: PGP signature
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, 2022-08-19 at 13:01 +0200, Peter Zijlstra wrote: > On Fri, Aug 19, 2022 at 10:47:21AM +0200, Peter Zijlstra wrote: > > On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote: > > > From: Ben Hutchings > > > > > > The mitigation for PBRSB includes adding LFENCE instructions to the > > > RSB filling sequence. However, RSB filling is done on some older CPUs > > > that don't support the LFENCE instruction. > > > > > > > Wait; what? There are chips that enable the RSB mitigations and DONT > > have LFENCE ?!? > > So I gave in and clicked on the horrible bugzilla thing. Apparently this > is P3/Athlon64 era crud. > > Anyway, the added LFENCE isn't because of retbleed; it is because you > can steer the jnz and terminate the loop early and then not actually > complete the RSB stuffing. I know, I corrected that further down. > New insights etc.. So it's a geniune fix for the existing rsb stuffing. > > I'm not entirly sure what to do here. On the one hand, it's 32bit, so > who gives a crap, otoh we shouldn't break these ancient chips either I > suppose. > > How's something like so then? It goes on top of my other patch cleaning > up this RSB mess: > > > https://lkml.kernel.org/r/Yv9m%2FhuNJLuyviIn%40worktop.programming.kicks-ass.net [...] That should be: https://lore.kernel.org/all/yv9m%2fhunjluyv...@worktop.programming.kicks-ass.net/ (the redirector unescapes the URL-escaped /). So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and we can't have nested alternatives. That's unfortunate. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, 2022-08-19 at 10:47 +0200, Peter Zijlstra wrote: > On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote: > > From: Ben Hutchings > > > > The mitigation for PBRSB includes adding LFENCE instructions to the > > RSB filling sequence. However, RSB filling is done on some older CPUs > > that don't support the LFENCE instruction. > > > > Wait; what? There are chips that enable the RSB mitigations and DONT > have LFENCE ?!? Yes, X86_FEATURE_RSB_CTXSW is enabled if any other Spectre v2 mitigation is enabled. And all Intel family 6 (except some early Atoms) and AMD family 5+ get Spectre v2 mitigation by default. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
From: Ben Hutchings
The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence. However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.
Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .
Reported-by: Martin-Éric Racine
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon
Cc: Pawan Gupta
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings
---
Re-sending this with properly matched From address and server.
Apologies if you got 2 copies.
Ben.
arch/x86/include/asm/nospec-branch.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
#define RSB_CLEAR_LOOPS32 /* To forcibly overwrite all
entries */
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
/*
* Google experimented with loop-unrolling and this turned out to be
* the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b; \
/* barrier for jnz misprediction */ \
- lfence;
-
-#ifdef __ASSEMBLY__
+ BARRIER_NOSPEC;
/*
* This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
.Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
- lfence
+ BARRIER_NOSPEC
.endm
/*
signature.asc
Description: PGP signature
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence. However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.
Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .
Reported-by: Martin-Éric Racine
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon
Cc: Pawan Gupta
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings
---
arch/x86/include/asm/nospec-branch.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
#define RSB_CLEAR_LOOPS32 /* To forcibly overwrite all
entries */
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
/*
* Google experimented with loop-unrolling and this turned out to be
* the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b; \
/* barrier for jnz misprediction */ \
- lfence;
-
-#ifdef __ASSEMBLY__
+ BARRIER_NOSPEC;
/*
* This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
.Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
- lfence
+ BARRIER_NOSPEC
.endm
/*
signature.asc
Description: PGP signature
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, 2022-08-18 at 23:11 +0300, Martin-Éric Racine wrote: > On Thu, Aug 18, 2022 at 10:59 PM Ben Hutchings wrote: > > > > Control: retitle -1 [i386] Unconditional LFENCE instructions in > > FILL_RETURN_BUFFER > > Control: tag -1 confirmed upstream > > Control: found -1 5.18.14-1 > > > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > > boot. > > > > > > I suspect someone thought it would be a good idea to compile the kernel > > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > > instruction set. > > > > > > > That was a good guess, though we don't change the configuration like > > that in stable updates. > > > > The RETbleed mitigations, which are not needed on these CPUs or even > > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > > which *are* used on these CPUs. And unfortunately the RETbleed > > mitigations added some unconditional LFENCE instructions, which should > > be conditional since they are part of SSE2. > > > > As a temporary workaround, disabling the Spectre v2 mitigation with the > > kernel parameter "nospectre_v2" should allow this kernel version to run > > on older CPUs without SSE2. We'll fix this properly in a later update. > > That breakage affects Stable. > > Expecting people to go and use workarounds on what was meant to be a > stable update isn't acceptable. Martin, you know we're all volunteers here, so don't take that tone. I was trying to be helpful in offering an alternative to holding back the upgrade. > I really hope that the fix will be pushed within the next 24 hours > with high urgency. This is unlikely to happen. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, 2022-08-18 at 21:59 +0200, Ben Hutchings wrote: > Control: retitle -1 [i386] Unconditional LFENCE instructions in > FILL_RETURN_BUFFER > Control: tag -1 confirmed upstream > Control: found -1 5.18.14-1 > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > boot. > > > > I suspect someone thought it would be a good idea to compile the kernel > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > instruction set. > > > > That was a good guess, though we don't change the configuration like > that in stable updates. > > The RETbleed mitigations, which are not needed on these CPUs or even I mean PBRSB, not RETbleed. There are so many different issues to keep track of... Ben. > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > which *are* used on these CPUs. And unfortunately the RETbleed > mitigations added some unconditional LFENCE instructions, which should > be conditional since they are part of SSE2. > > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. > > Ben. > -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
Control: retitle -1 [i386] Unconditional LFENCE instructions in FILL_RETURN_BUFFER Control: tag -1 confirmed upstream Control: found -1 5.18.14-1 On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > boot. > > I suspect someone thought it would be a good idea to compile the kernel > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > instruction set. > That was a good guess, though we don't change the configuration like that in stable updates. The RETbleed mitigations, which are not needed on these CPUs or even functional on 32-bit kernels, interact with the Spectre v2 mitigations, which *are* used on these CPUs. And unfortunately the RETbleed mitigations added some unconditional LFENCE instructions, which should be conditional since they are part of SSE2. As a temporary workaround, disabling the Spectre v2 mitigation with the kernel parameter "nospectre_v2" should allow this kernel version to run on older CPUs without SSE2. We'll fix this properly in a later update. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1017499: Mentioned issue is not related
Correction: Issue #7071 is *not* related to this issue; it's a similar issue, but specific to Vivante hardware and the etnaviv driver. -- Ben Westover signature.asc Description: PGP signature
Bug#1014633: linux-headers-5.19.0-rc4-common: file check-local-export does not exist
On Sun, 2022-07-31 at 23:02 +0200, Andreas Beckmann wrote: > Followup-For: Bug #1014633 > > What about adding a superficial autopkgtest that tries to compile a > dummy third-party kernel module using kbuild? That should help noticing > such breakage earlier. This is such an obviously good idea that I already did it in version 5.18.14-1. :-) Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Bug#1013035: sgt-puzzles: ftbfs with GCC-12
On Fri, 2022-07-29 at 10:04 +0100, Simon Tatham wrote: > Ben Hutchings wrote: > > I should patch out the use of -Werror in this package though. > > FWIW, I've already done this upstream. Since commit 79a5378 I've > completely reworked the build system (it's now a unified cmake setup > rather than my own horrible mkfiles.pl cruft feeding into autotools), > and removed the default -Werror. And a test build with gcc 12 worked > fine for me just now with the current upstream code. Thanks for the reminder to update, and I appreciate the move to CMake. I've now uploaded version 20220613.387d323. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Mon, 2022-07-04 at 14:04 +0200, Ansgar wrote:
> On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > > they always zeroes).
> > [...]
> >
> > I wrote a script to try all possible byte values for 2 bytes before or
> > after the short signature. For this particular file, none of them
> > producd a valid signature. So the short signatures seem to be
> > corrupted in a more complex way.
>
> The "OCTET STRING" containing the actual signature is shorter for the
> seemingly corrupted signatures:
[...]
Yes I know, and my script uses a library to manipulate the ASN.1
structure when adding bytes. I'm attaching the script, so you can
check the logic.
Ben.
--
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
#!/usr/bin/python3
# Fix broken detached signatures
import os.path
import sys
import asn1crypto.algos
import asn1crypto.cms
import asn1crypto.core
from M2Crypto import BIO, SMIME, X509
# Signature algorithm should be RSA
SIG_ALGO_OID = asn1crypto.core.ObjectIdentifier('1.2.840.113549.1.1.1')
# Signature length should match key length (2048 bits)
SIG_LEN = 2048 // 8
def make_smime_context(cert):
# We don't verify against a CA, just one specific certificate
smime = SMIME.SMIME()
signer_key = X509.X509_Stack()
signer_key.push(X509.load_cert(cert))
smime.set_x509_stack(signer_key)
smime.set_x509_store(X509.X509_Store())
return smime
def verify_payload(smime, sig, data):
smime.verify(
SMIME.load_pkcs7_bio_der(BIO.MemoryBuffer(sig.dump(force=True))),
BIO.MemoryBuffer(data),
flags=(SMIME.PKCS7_BINARY | SMIME.PKCS7_DETACHED
| SMIME.PKCS7_NOVERIFY))
def brute_force_sig_2bytes(smime, sig, sig_os, data):
orig_raw_sig = bytes(sig_os)
for byte1 in range(256):
for byte2 in range(256):
sig_os.set(bytes((byte1, byte2)) + orig_raw_sig)
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'prepended {byte1}, {byte2} to start of sig')
return True
sig_os.set(bytes((byte1,)) + orig_raw_sig + bytes((byte2,)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'added {byte1}, {byte2} at start and end of sig resp.')
return True
sig_os.set(orig_raw_sig + bytes((byte1, byte2)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'appended {byte1}, {byte2} to end of sig')
return True
return False
def fix_detached_sig(smime, sig, bin_name):
# The ContentInfo should be a SEQUENCE with signed data at index 1
if len(sig) < 2 or not isinstance(sig[1], asn1crypto.cms.SignedData):
return 'no signed data found', False
sd = sig[1]
# The SignedData should be a SEQUENCE with signer infos at index 5
if len(sd) < 6 or not isinstance(sd[5], asn1crypto.cms.SignerInfos):
return 'no signer infos found', False
infos = sd[5]
# The SignerInfos should be a SET with 1 item
if len(infos) != 1:
return f'found { len(infos) } signer infos; expected 1', False
info = infos[0]
# The SignerInfo should be a SEQUENCE with the signature algorithm
# at index 4 and signature at index 5
if (len(info) < 6
or not isinstance(info[4], asn1crypto.algos.SignedDigestAlgorithm)
or len(info[4]) < 1
or not isinstance(info[5], asn1crypto.core.OctetString)):
return 'expected fields not found in signer info', False
# Check the signature algorithm and length (see bug #1012741)
if info[4][0] != SIG_ALGO_OID:
return f'unexpected signature algorithm { info[4][0].dotted }', False
actual_sig_len = len(bytes(info[5]))
with open(bin_name, 'rb') as f:
data = f.read()
if (actual_sig_len == SIG_LEN - 2
and brute_force_sig_2bytes(smime, sig, info[5], bin_name)):
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }; filled in missing 2 bytes',
True)
if actual_sig_len != SIG_LEN:
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }',
False)
verify_payload(smime, sig, data)
return None, False
def load_detached_sig(name):
with open(name, 'rb') as f:
return asn1crypto.cms.ContentInfo.load(f.read())
def save_detached_sig(sig, name):
with open(name, 'wb') as f:
f.write(sig.dump())
def main(sig_dir, bin_dir, cert):
err_count = 0
s
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Sun, 2022-06-26 at 10:30 -0500, Daniel Lewart wrote: > Ben, et al, > > On Mon, 13 Jun 2022 18:23:18 +0200 Ben Hutchings wrote: > > > Since the truncated signatures are in the source packages, this is a > > problem introduced by the code signing service and will need to be > > fixed there. > > Assuming that the code-signing service uses the kernel's scripts/sign-file > and calls PKCS7_sign() ... > > Which version of OpenSSL/libssl is used? I don't know that; you would have to ask the FTP team. > Are kernel build logs available for download or viewing? All package build logs are available from <https://buildd.debian.org>, but the code signing step is separate. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
On Wed, 2022-06-29 at 16:49 +0200, Diederik de Haas wrote: > On Wednesday, 29 June 2022 15:24:45 CEST Ben Hutchings wrote: > > Control: tag -1 patch > > Control: tag -1 - help > > > > On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote: > > > On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote: > > > > > So yes, this needs to also be fixed upstream (hence me including that > > > > > tag when reporbugging), but perhaps Debian can quickfix. > > > > > > > > What I have observed so far is that a commit needs to be accepted > > > > upstream > > > > (but doesn't have to have gone through the whole 'chain of command') > > > > before a temporary patch is accepted to quickly fix it in Debian. > > > > > > I made an initial attempt at a patch, see attachment. > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html# > > > s4.2.2 describes a way to test whether this patch fixes the issue. > > > (Just in case. I'm reasonably sure you already know this) > > > > Looks good to me. Can you send it on to sta...@vger.kernel.org? > > You'll need to add your Signed-off-by. > > I proposed my patch to expedite things and (much) prefer that Thorsten would > send it (that's why I explicitly omitted the Signed-off-by statement). > If there are follow up questions, they would also be directed to the person > who found the issue and is the right person to answer them. I'd have to relay > them and possibly introduce noise in the communication. As Thorsten's email is in the Reported-by pseudo-header, he should be cc'd on all discussions. > I can do it, but I would like Thorsten to test the patch and confirm it > actually does fix it. Having a Tested-By tag would be nice. > When submitting a MR to the Debian kernel, I'm rightfully expected to have > verified it does what it is supposed to do. For the upstream kernel, I'd > expect > the same at a minimum. > > Is the prefix I used for the patch, the correct one? "net/sched" seems to be preferred. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
Control: tag -1 patch Control: tag -1 - help On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote: > On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote: > > > So yes, this needs to also be fixed upstream (hence me including that tag > > > when reporbugging), but perhaps Debian can quickfix. > > > > What I have observed so far is that a commit needs to be accepted upstream > > (but doesn't have to have gone through the whole 'chain of command') before > > a temporary patch is accepted to quickly fix it in Debian. > > I made an initial attempt at a patch, see attachment. > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > describes a way to test whether this patch fixes the issue. > (Just in case. I'm reasonably sure you already know this) Looks good to me. Can you send it on to sta...@vger.kernel.org? You'll need to add your Signed-off-by. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Mon, 2022-06-20 at 04:38 -0500, Daniel Lewart wrote: > Ben, > > > I wrote a script to check for short signatures (and other unexpected > > things) in detached signature files: > > https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params > > Thank you for your excellent detective work! > > I tried running your script, but it generates an error (see below). > What am I doing wrong? [...] I don't know, but I'm running it on unstable. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote: > On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote: > [...] > > > linux-image-4.19.0-17-amd64 4.19.194-1 > > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko > > linux-image-4.19.0-17-amd64 4.19.194-2 > > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko > > linux-image-4.19.0-17-amd64 4.19.194-3 > > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko > [...] > > A significant pattern visible here is a short signature for the same > > module in multiple consecutive versions, where the module may have > > identical contents. That implies that this is a reproducible issue for > > certain inputs that cannot be worked around by re-running the signing > > process. > > > > However, I have *not* yet verified that all short signatures really are > > invalid. > > These module files are indeed identical, and their signatures are > rejected by the kernel. > > I'm now looking at whether the missing bytes are recoverable (e.g. are > they always zeroes). [...] I wrote a script to try all possible byte values for 2 bytes before or after the short signature. For this particular file, none of them producd a valid signature. So the short signatures seem to be corrupted in a more complex way. In the mean time, we have another security update coming which might not hit this bug again. But there are 28,679 signed binaries across the three architectures, so the probability is only about 65%. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote: [...] > Incidentally, this is a failure rate of 75 out of 4,967,591 signatures, > or 0.0015% [...] Or maybe not so incidentally: 4,967,591 / 2^16 ~= 75 Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote: [...] > linux-image-4.19.0-17-amd64 4.19.194-1 > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko > linux-image-4.19.0-17-amd64 4.19.194-2 > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko > linux-image-4.19.0-17-amd64 4.19.194-3 > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko [...] > A significant pattern visible here is a short signature for the same > module in multiple consecutive versions, where the module may have > identical contents. That implies that this is a reproducible issue for > certain inputs that cannot be worked around by re-running the signing > process. > > However, I have *not* yet verified that all short signatures really are > invalid. These module files are indeed identical, and their signatures are rejected by the kernel. I'm now looking at whether the missing bytes are recoverable (e.g. are they always zeroes). Incidentally, this is a failure rate of 75 out of 4,967,591 signatures, or 0.0015%, so it's not surprising that other source packages have not yet been affected. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
On Mon, 2022-06-13 at 18:23 +0200, Ben Hutchings wrote: [...] > I can confirm that this module does not load, and this means it has an > invalid signature. The detached signature present in the source > package seems to be truncated (408 bytes long, where for all other > modules the detached signature is 411 bytes long). > > The amd64 kernel package is also affected, but for a different module > (xt_l2tp). > > Since the truncated signatures are in the source packages, this is a > problem introduced by the code signing service and will need to be > fixed there. I wrote a script to check for short signatures (and other unexpected things) in detached signature files: https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params I've now run that over all linux-signed-* packages available on snapshot.debian.org. It found short signatures (in all cases, a raw signature length of 254 bytes rather than 256 bytes) for the following binary packages, versions, and files: linux-image-4.19.0-0.bpo.4-686-pae 4.19.28-2~bpo9+1 lib/modules/4.19.0-0.bpo.4-686-pae/kernel/drivers/usb/storage/ums-realtek.ko linux-image-4.19.0-0.bpo.4-amd64 4.19.28-2~bpo9+1 lib/modules/4.19.0-0.bpo.4-amd64/kernel/drivers/iio/gyro/bmg160_i2c.ko linux-image-4.19.0-0.bpo.4-rt-amd64 4.19.28-2~bpo9+1 lib/modules/4.19.0-0.bpo.4-rt-amd64/kernel/drivers/mtd/chips/map_ram.ko linux-image-4.19.0-0.bpo.5-amd64 4.19.37-4~bpo9+1 lib/modules/4.19.0-0.bpo.5-amd64/kernel/drivers/video/fbdev/via/viafb.ko linux-image-4.19.0-0.bpo.6-686 4.19.67-2+deb10u1~bpo9+1 lib/modules/4.19.0-0.bpo.6-686/kernel/drivers/media/usb/hackrf/hackrf.ko linux-image-4.19.0-4-rt-686-pae 4.19.28-1 lib/modules/4.19.0-4-rt-686-pae/kernel/drivers/media/tuners/fc2580.ko linux-image-4.19.0-4-rt-amd64 4.19.28-1 lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko linux-image-4.19.0-4-rt-amd64 4.19.28-2 lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko linux-image-4.19.0-5-686-pae 4.19.37-2 lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko linux-image-4.19.0-5-686-pae 4.19.37-3 lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko linux-image-4.19.0-5-amd64 4.19.37-1 lib/modules/4.19.0-5-amd64/kernel/drivers/net/wireless/ralink/rt2x00/rt2500usb.ko linux-image-4.19.0-5-rt-amd64 4.19.37-5+deb10u2 lib/modules/4.19.0-5-rt-amd64/kernel/net/ipv4/tcp_hybla.ko linux-image-4.19.0-17-686 4.19.194-1 lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko linux-image-4.19.0-17-686 4.19.194-2 lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko linux-image-4.19.0-17-686 4.19.194-3 lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko linux-image-4.19.0-17-amd64 4.19.194-1 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko linux-image-4.19.0-17-amd64 4.19.194-2 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko linux-image-4.19.0-17-amd64 4.19.194-3 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko linux-image-4.19.0-18-rt-686-pae 4.19.208-1 lib/modules/4.19.0-18-rt-686-pae/kernel/drivers/staging/comedi/drivers/jr3_pci.ko linux-image-4.19.0-19-rt-686-pae 4.19.232-1 lib/modules/4.19.0-19-rt-686-pae/kernel/fs/sysv/sysv.ko linux-image-4.19.0-20-amd64 4.19.235-1 lib/modules/4.19.0-20-amd64/kernel/sound/pci/echoaudio/snd-indigoio.ko linux-image-4.19.0-20-rt-arm64 4.19.235-1 lib/modules/4.19.0-20-rt-arm64/kernel/drivers/video/fbdev/arkfb.ko linux-image-5.2.0-0.bpo.2-amd64 5.2.9-2~bpo10+1 lib/modules/5.2.0-0.bpo.2-amd64/kernel/drivers/input/keyboard/max7359_keypad.ko linux-image-5.2.0-2-arm64 5.2.9-1 lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko linux-image-5.2.0-2-arm64 5.2.9-2 lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko linux-image-5.2.0-2-rt-686-pae 5.2.9-1 lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko linux-image-5.2.0-2-rt-686-pae 5.2.9-2 lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko linux-image-5.2.0-3-cloud-amd64 5.2.17-1 lib/modules/5.2.0-3-cloud-amd64/kernel/net/sched/act_skbmod.ko linux-image-5.3.0-1-amd64 5.3.7-1 lib/modules/5.3.0-1-amd64/kernel/sound/pci/hda/snd-hda-codec-hdmi.ko linux-image-5.3.0-2-arm64 5.3.9-3 lib/modules/5.3.0-2-arm64/kernel/drivers/usb/gadget/function/u_ether.ko linux-image-5.3.0-2-cloud-amd64 5.3.9-1 lib/modules/5.3.0-2-cloud-amd64/kernel/fs/nls/nls_koi8-u.ko linux-image-5.4.0-0.bpo.2-686-pae 5.4.8-1~bpo10+1 lib/modules/5.4.0-0.bpo.2-686-pae/kernel/drivers/net/phy/aquantia.ko linux-image-5.4.0-0.bpo.4-rt-arm64 5.4.19-1~bpo10+1 lib/modules/5.4.0-0.bpo.4-rt-arm64/kernel/drivers/hwmon/lm73.ko linux-image-5.4.0-3-cloud-amd64 5.4.13-1 lib/modules/5.4.0-3-cloud-amd64/kernel/net/netfilter/xt_NETMAP.ko linux-image-5.10.0-0.bpo.9-arm64 5.10.70-1~bpo10+1 lib/modules/5.10.0-0.bpo.9-arm64/kernel/sound/usb/line6/snd-usb-line6.ko linux-image-5.10.0-0.bpo.11-rt-686-p
Bug#1010904: jquery-at.js: replace node-gulp-util build dependency with node-fancy-log
Control: summary -1 0 Control: tags -1 - patch The ‘gulp-util’ source fails to build in Debian; that package will drop its ‘util’ module and dependent packages are advised to migrate to other libraries. For ‘jquery-at.js’, the API ‘util.log’ needs a replacement. On 12-May-2022, Pirate Praveen wrote: > Control: tags -1 patch > > Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010895 for > details about removing node-gulp-util from the archive Thanks for the report. As far as I can determine, the relevant infromation for this package is: * Debian ‘node-gulp-util’ is dropping its ‘util’ module. * The ‘jquery-at.js’ source package uses ‘util.log’, which will no longer be provided by ‘node-gulp-util’. * The ‘node-fancy-log’ Debian package provides a ‘fancylog’ API which is a sufficient replacement. > I have sent a merge request with a patch > https://salsa.debian.org/debian/pkg-jquery-at.js/-/merge_requests/2 Thank you; that merge request does not contain the changes needed. I have posted a review on that merge request. Meanwhile I will work on implementing a fix for this bug. -- \ “Now Maggie, I’ll be watching you too, in case God is busy | `\ creating tornadoes or not existing.” —Homer, _The Simpsons_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1009426: xkcdpass: FTBFS: test case raises “TypeError: … missing 1 required positional argument: 'self'”
Control: tags -1 + confirmed upstream Control: forwarded -1 https://github.com/redacted/XKCD-password-generator/issues/138 Control: retitle -1 xkcdpass: FTBFS: test case raises “TypeError: … missing 1 required positional argument: 'self'” Control: summary -1 0 The upstream test suite has a buggy test case that is raising TypeError in recent Python versions. On 12-Apr-2022, Lucas Nussbaum wrote: > Relevant part (hopefully): > > […] > >dh_auto_test -O--buildsystem=pybuild > > I: pybuild base:239: python3.10 setup.py test > > running test > > […] > > > > == > > ERROR: test_entropy_printout_valid_input > > (tests.test_xkcdpass.TestEntropyInformation) > > -- > > TypeError: TestEntropyInformation.test_entropy_printout_valid_input() > > missing 1 required positional argument: 'self' > > > > -- > > Ran 9 tests in 0.189s > > > > FAILED (errors=1) > > […] I have described this error in the test case in the upstream issue https://github.com/redacted/XKCD-password-generator/issues/138>. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1005404: Kernel modules fail to build with Linux 5.16 onward
On Sun, 2022-02-13 at 18:06 -0800, Benjamin Kaduk wrote: > Hi Ben, > > Thanks for detecting and reporting the build errors. > I'm a bit confused as to how this is "grave", though -- I would have > classified it as merely "serious" as for, e.g., 970258 and 995134. The current kernel version in unstable (and now also in testing) is 5.16. For those who don't choose another kernel version, this incompatibility "makes the package in question unusable". > For upstream, we went with a slightly different patch owing to the > unreliability of the linux version macros due to distros backporting many > patches -- > https://github.com/openafs/openafs/commit/3daa6e97330d23ae46c4389e4041c61c1a1d76d9 [...] That's great, feature testing is the right way to do this. I only wrote a version check because I didn't notice OpenAFS had the infrastructure for feature testing. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them. signature.asc Description: This is a digitally signed message part
Bug#1005419: Fails to build with xtables-addons 3.19
Package: west-chamber-source Version: 20100405+svn2007.r124-13 Severity: grave Tags: bookworm sid west-chamber-source extracts and uses the compat_xtnu.h header from /usr/src/xtables-addons.tar.bz2. xtables-addons 3.19 removed this header, so builds now fail. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages west-chamber-source depends on: ii bzip2 1.0.8-5 ii debhelper 13.6 pn libxtables-dev ii make 4.3-4.1 ii pkg-config 0.29.2-1 pn xtables-addons-source Versions of packages west-chamber-source recommends: ii module-assistant 0.11.10 west-chamber-source suggests no packages.
Bug#1005418: Fails to build modules for Linux 5.13 onward
Source: vpb-driver Version: 4.2.61-1 Severity: grave Tags: patch upstream A couple of source files for the kernel driver modules include the header . This header has never been needed, and was renamed in Linux 5.13 resulting in a build failure. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- a/src/vpb/vpb.c +++ b/src/vpb/vpb.c @@ -97,14 +97,6 @@ #define MODVERSIONS #endif -#ifdef MODVERSIONS -#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4)) -#include -#else -#include -#endif -#endif - #include #include #include --- a/src/vtcore/vtcommon.h +++ b/src/vtcore/vtcommon.h @@ -49,14 +49,6 @@ #endif #endif -#ifdef MODVERSIONS - #if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4)) - #include - #else - #include - #endif -#endif - #include
Bug#1005413: Build fixes
Control: tag -1 patch
The attached patch fixes both user-space and kernel builds. I haven't
used cloop before, but I briefly tested the kernel driver with these
changes.
I found that it was necessary to use the -r option to losetup when
setting up a cloop device; this might be the result of using
set_disk_ro() instead of set_device_ro(). If this is a change in
behaviour then the documentation should be updated.
losetup -d doesn't seem to work on cloop devices, and I don't know if
this is a regression.
Ben.
--
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.
--- a/advancecomp-1.15/file.cc
+++ b/advancecomp-1.15/file.cc
@@ -98,7 +98,7 @@
/**
* Check if a file exists.
*/
-bool file_exists(const string& path) throw (error)
+bool file_exists(const string& path)
{
struct stat s;
if (stat(path.c_str(), ) != 0) {
@@ -114,7 +114,7 @@
/**
* Write a whole file.
*/
-void file_write(const string& path, const char* data, unsigned size) throw (error)
+void file_write(const string& path, const char* data, unsigned size)
{
FILE* f = fopen(path.c_str(), "wb");
if (!f)
@@ -134,7 +134,7 @@
/**
* Read a whole file.
*/
-void file_read(const string& path, char* data, unsigned size) throw (error)
+void file_read(const string& path, char* data, unsigned size)
{
file_read(path, data, 0, size);
}
@@ -142,7 +142,7 @@
/**
* Read a whole file.
*/
-void file_read(const string& path, char* data, unsigned offset, unsigned size) throw (error)
+void file_read(const string& path, char* data, unsigned offset, unsigned size)
{
FILE* f = fopen(path.c_str(), "rb");
if (!f)
@@ -166,7 +166,7 @@
/**
* Get the time of a file.
*/
-time_t file_time(const string& path) throw (error)
+time_t file_time(const string& path)
{
struct stat s;
if (stat(path.c_str(), )!=0)
@@ -178,7 +178,7 @@
/**
* Set the time of a file.
*/
-void file_utime(const string& path, time_t tod) throw (error)
+void file_utime(const string& path, time_t tod)
{
struct utimbuf u;
@@ -192,7 +192,7 @@
/**
* Get the size of a file.
*/
-unsigned file_size(const string& path) throw (error)
+unsigned file_size(const string& path)
{
struct stat s;
if (stat(path.c_str(), )!=0)
@@ -204,7 +204,7 @@
/**
* Get the crc of a file.
*/
-crc_t file_crc(const string& path) throw (error)
+crc_t file_crc(const string& path)
{
unsigned size = file_size(path);
@@ -227,7 +227,7 @@
/**
* Copy a file.
*/
-void file_copy(const string& path1, const string& path2) throw (error)
+void file_copy(const string& path1, const string& path2)
{
unsigned size;
@@ -249,7 +249,7 @@
/**
* Move a file.
*/
-void file_move(const string& path1, const string& path2) throw (error)
+void file_move(const string& path1, const string& path2)
{
if (rename(path1.c_str(), path2.c_str())!=0
&& errno==EXDEV) {
@@ -271,7 +271,7 @@
/**
* Remove a file.
*/
-void file_remove(const string& path1) throw (error)
+void file_remove(const string& path1)
{
if (remove(path1.c_str())!=0) {
throw error() << "Failed remove of " << path1;
@@ -281,7 +281,7 @@
/**
* Rename a file.
*/
-void file_rename(const string& path1, const string& path2) throw (error)
+void file_rename(const string& path1, const string& path2)
{
if (rename(path1.c_str(), path2.c_str())!=0) {
throw error() << "Failed rename of " << path1 << " to " << path2;
@@ -400,7 +400,7 @@
/**
* Make a drectory tree.
*/
-void file_mktree(const std::string& path) throw (error)
+void file_mktree(const std::string& path)
{
string dir = file_dir(path);
string name = file_name(path);
--- a/advancecomp-1.15/file.h
+++ b/advancecomp-1.15/file.h
@@ -67,18 +67,18 @@
crc_t crc_compute(const char* data, unsigned len);
crc_t crc_compute(crc_t pred, const char* data, unsigned len);
-bool file_exists(const std::string& file) throw (error);
-void file_write(const std::string& path, const char* data, unsigned size) throw (error);
-void file_read(const std::string& path, char* data, unsigned size) throw (error);
-void file_read(const std::string& path, char* data, unsigned offset, unsigned size) throw (error);
-time_t file_time(const std::string& path) throw (error);
-void file_utime(const std::string& path, time_t tod) throw (error);
-unsigned file_size(const std::string& path) throw (error);
-crc_t file_crc(const std::string& path) throw (error);
-void file_copy(const std::string& path1, const std::string& path2) throw (error);
-void file_move(const std::string& path1, const std::string& path2) throw (error);
-void file_remove(const std::string& path1) throw (error);
-void file_mktree(const std::string& path1) throw (error);
+bool file_exists(const
Bug#1005414: Modules fail to build for Linux 5.11 onward
Source: cloop Version: 3.14.1.2 Severity: grave Various APIs used by cloop have changed or been removed in Linux 5.11, 5.15, or other recent versions. I'll try to provide a patch for this. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005413: FTBFS with gcc 11
Source: cloop Version: 3.14.1.2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) gcc 11 defaults to C++17, resulting in lots of errors like: file.h:70:43: error: ISO C++17 does not allow dynamic exception specifications 70 | bool file_exists(const std::string& file) throw (error); | ^~~~~ Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005405: Fails to build for Linux 5.16 onward
Source: nvidia-graphics-drivers-tesla-418 Version: 418.226.00-1 Severity: grave These modules fail to build, with the compiler reporting that is not found. This is due to an intentional change in Linux 5.16 removing user-space headers from the kernel include path: <https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>. Kernel code must use instead of . Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005406: Fails to build for Linux 5.16 onward
Source: nvidia-graphics-drivers-tesla-460 Version: 460.106.00-1 Severity: grave These modules fail to build, with the compiler reporting that is not found. This is due to an intentional change in Linux 5.16 removing user-space headers from the kernel include path: <https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>. Kernel code must use instead of . Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005404: Kernel modules fail to build with Linux 5.16 onward
Source: openafs Version: 1.8.2-1+deb10u1 Severity: grave Tags: patch upstream The openafs modules fail to build, with the compiler reporting that "stdarg.h" is not found. This is due to an intentional change in Linux 5.16 removing user-space headers from the kernel include path: <https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>. Kernel code must use instead of . The attached patch fixes this and allows the build to complete. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled From: Ben Hutchings Date: Sat, 12 Feb 2022 22:25:47 +0100 Subject: openafs: Fix inclusion on Linux There was an intentional change in Linux 5.16 removing user-space headers from the kernel include path: <https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>. Kernel code must use instead of . --- --- a/src/rx/rx_kcommon.h +++ b/src/rx/rx_kcommon.h @@ -145,6 +145,8 @@ typedef unsigned short etap_event_t; /* if sys/systm.h includes varargs.h some versions of solaris have conflicts */ # if defined(AFS_FBSD_ENV) # include "machine/stdarg.h" +# elif defined(AFS_LINUX26_ENV) && LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0) +# include # else # include "stdarg.h" # endif
Bug#1005401: Fails to build due to netfilter change in Linux 5.15
Source: iptables-netflow Version: 2.3-5 Severity: grave iptables-netflow fails to build modules for Linux 5.15 onward. This is due to changes in the netfilter ecache API; see <https://git.kernel.org/linus/b86c0e6429dac2458694495aeebf15f4fe6b269d>. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005399: Depends on kernel internal crypto API and no longer builds
Source: gost-crypto Version: 0.3.3-1 Severity: grave gost-crypto depends on the crypto_cipher API. Since Linux 5.12 this is internal to the crypto subsystem and is not available to out-of-tree modules. See <https://git.kernel.org/linus/0eb76ba29d16df2951d37c54ca279c4e5630b071>. Ben. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005390: Fails to build with Linux 5.16 onward
Source: dahdi-linux
Version: 1:2.11.1.0.20170917~dfsg-7.4
Severity: grave
Tags: patch
The dahdi modules fail to build, with thqis error:
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.4/build/drivers/dahdi/wct4xxp/base.c:45:10:
fatal error: stdbool.h: No such file or directory
45 | #include
| ^~~
This is due to an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.
Kernel code must use instead of .
The attached patch fixes this and allows the build to complete, but
there are still a lot of compiler warnings.
Ben.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Ben Hutchings
Date: Sat, 12 Feb 2022 19:32:52 +0100
Subject: dahdi: Do not use in kernel modules
There was an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.
Kernel code must use instead of .
---
--- a/drivers/dahdi/dahdi-base.c
+++ b/drivers/dahdi/dahdi-base.c
@@ -86,7 +86,7 @@
#include "hpec/hpec_user.h"
-#include
+#include
#if defined(EMPULSE) && defined(EMFLASH)
#error "You cannot define both EMPULSE and EMFLASH"
--- a/drivers/dahdi/wcaxx-base.c
+++ b/drivers/dahdi/wcaxx-base.c
@@ -34,7 +34,7 @@
#include
#include
-#include
+#include
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
--- a/drivers/dahdi/wct4xxp/base.c
+++ b/drivers/dahdi/wct4xxp/base.c
@@ -42,7 +42,7 @@
#include
#include
-#include
+#include
#include
#include "wct4xxp.h"
--- a/drivers/dahdi/wctc4xxp/base.c
+++ b/drivers/dahdi/wctc4xxp/base.c
@@ -39,7 +39,7 @@
#include
#include
-#include
+#include
#include
--- a/drivers/dahdi/wctdm24xxp/base.c
+++ b/drivers/dahdi/wctdm24xxp/base.c
@@ -58,7 +58,7 @@ Tx Gain - W/Pre-Emphasis: -23.99 to 0.00
#include
#include
-#include
+#include
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
/* Define this if you would like to load the modules in parallel. While this
--- a/drivers/dahdi/wcte12xp/base.c
+++ b/drivers/dahdi/wcte12xp/base.c
@@ -43,7 +43,7 @@
#include
-#include
+#include
#include
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
--- a/drivers/dahdi/wcte13xp-base.c
+++ b/drivers/dahdi/wcte13xp-base.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include
#include
#include "wct4xxp/wct4xxp.h" /* For certain definitions */
--- a/drivers/dahdi/wcte43x-base.c
+++ b/drivers/dahdi/wcte43x-base.c
@@ -43,7 +43,7 @@
#include
#include
-#include
+#include
#include
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
--- a/drivers/dahdi/wcxb.c
+++ b/drivers/dahdi/wcxb.c
@@ -38,7 +38,7 @@
#include
-#include
+#include
#include "wcxb.h"
#include "wcxb_spi.h"
--- a/drivers/dahdi/wct4xxp/vpm450m.c
+++ b/drivers/dahdi/wct4xxp/vpm450m.c
@@ -28,7 +28,7 @@
#include
#include
-#include
+#include
#include "vpm450m.h"
#include
--- a/drivers/dahdi/voicebus/vpmoct.h
+++ b/drivers/dahdi/voicebus/vpmoct.h
@@ -30,7 +30,7 @@
#include
#include "dahdi/kernel.h"
-#include
+#include
#define VPMOCT_FIRM_HEADER_LEN 32
#define VPMOCT_BOOT_RAM_LEN 128
--- a/drivers/dahdi/wcxb_spi.h
+++ b/drivers/dahdi/wcxb_spi.h
@@ -24,7 +24,7 @@
#define __WCXB_SPI_H
#include
-#include
+#include
struct wcxb_spi_transfer {
const void *tx_buf;
Bug#1004465: libklibc-dev: headers not installed
On Fri, 28 Jan 2022 18:13:03 + (UTC) Thorsten Glaser wrote: > found 1004465 2.0.10-1 > thanks > > Dixi quod… > > >Quite some files are missing: > […] > >/usr/lib/klibc/include/alloca.h > […] > >/usr/lib/klibc/include/arpa/inet.h > > /usr/lib/klibc/include/asm > > /usr/lib/klibc/include/asm-generic > >/usr/lib/klibc/include/assert.h > […] > > From this pattern, commit 8f680c0688151ce4d50072783a5b6fad7beabc1f > is suspect: > > Since debhelper 11, dh_install and dh_installman have automatically > searched for the listed files/directories relative to debian/tmp/ > as well as in the top directory. [...] That's not what broke things, it's the change to an out-of-tree build. Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Bug#1004311: [PATCH] add_cmake_libbpf_enabled_option.patch: Only check the macro HAVE_BPF
Control: tag -1 patch
The patch add_cmake_libbpf_enabled_option.patch is indeed the problem,
because it doesn't consistently use the same macro name. The fix is
below.
If you're not able to upload with this today, can I please NMU to
unblock linux?
Ben.
--- a/debian/patches/add_cmake_libbpf_enabled_option.patch
+++ b/debian/patches/add_cmake_libbpf_enabled_option.patch
@@ -5,6 +5,8 @@ Non-linux systems also can make good use of these tools. This
patch
adds option LIBBPF_ENABLED (default: on) so to opt-out BPF when needed.
Signed-off-by: Domenico Andreoli
+[bwh: Only check the macro HAVE_BPF, not HAVE_BTF]
+Signed-off-by: Ben Hutchings
---
CMakeLists.txt | 61
+
dwarves.c |2 ++
@@ -193,7 +195,7 @@ Index: b/pahole.c
cu__fprintf_ptr_table_stats_csv(cu, stderr);
}
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
if (btf_encode) {
static pthread_mutex_t btf_lock = PTHREAD_MUTEX_INITIALIZER;
@@ -241,7 +243,7 @@ Index: b/pahole.c
type_instance__delete(header);
header = NULL;
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
if (btf_encode) {
err = btf_encoder__encode(btf_encoder);
if (err) {
@@ -257,7 +259,7 @@ Index: b/pahole.c
#ifdef DEBUG_CHECK_LEAKS
cus__delete(cus);
structures__delete();
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
btf__free(conf_load.base_btf);
conf_load.base_btf = NULL;
#endif
signature.asc
Description: PGP signature
Bug#998161: closed by Debian FTP Masters (reply to Christian Marillat ) (Bug#998161: fixed in gourmand 1.0.0-3)
Yes it is. Identical exception / error message as I got for gourmet, referring to the attribute count, no id. Please read again the exception error message, and let me quote my bug report : ... gourmet fails to run with python3-sqlalchemy v 1.4.23 (in sid). Reason : removal of FromClause.count() (which was already deprecated in v 1.3). ... Cheers, Itaï Le lundi 06 décembre 2021 à 01:57 +0100, Christian Marillat a écrit : > On 06 déc. 2021 01:16, Itaï BEN YAACOV wrote: > > > Hi, > > > > Looks like the same bug persists in gourmand. > > > > ... > > File "/usr/lib/python3/dist-packages/gourmand/backends/db.py", line > > 759, in fetch_len > > return table.count().execute().fetchone()[0] > > AttributeError: 'Table' object has no attribute 'count' > > Not the same bug. > > Seems to be like this one : > > https://stackoverflow.com/questions/32067607/sqlalchemy-table-object-has-no-attribute-id > > Christian
Bug#998161: closed by Debian FTP Masters (reply to Christian Marillat ) (Bug#998161: fixed in gourmand 1.0.0-3)
Hi, Looks like the same bug persists in gourmand. ... File "/usr/lib/python3/dist-packages/gourmand/backends/db.py", line 759, in fetch_len return table.count().execute().fetchone()[0] AttributeError: 'Table' object has no attribute 'count' Chhers, Itaï Le dimanche 05 décembre 2021 à 19:03 +, Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the gourmet package: > > #998161: gourmet: Fails to run with sqlalchemy 1.4.23, due to removal > of FromClause.count() > > It has been closed by Debian FTP Masters > (reply to Christian Marillat > ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP > Masters (reply to Christian > Marillat ) by > replying to this email. > >
Bug#1000357: Module build is still failing
The module is still failing to build on my machine. I believe the problem is that ddcci_device_remove() returns in two different places. The new patch wraps the return at the end of the function in an #if, but does not fix the mid-function `return -EINVAL;`. (In case it is useful: there is a patch on the Ubuntu version of this bug that uses a wrapper function instead of conditional compilation within the function: https://bugs.launchpad.net/ubuntu/+source/ddcci-driver-linux/+bug/1951608 .) Here's my make.log from today: DKMS make.log for ddcci-0.4.1 for kernel 5.15.0-1-amd64 (x86_64) Tue 23 Nov 11:25:56 GMT 2021 make: Entering directory '/var/lib/dkms/ddcci/0.4.1/build' make -C "ddcci" make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.1/build/ddcci' make -C "/lib/modules/5.15.0-1-amd64/build" M="/var/lib/dkms/ddcci/0.4.1/build/ddcci" modules make[2]: Entering directory '/usr/src/linux-headers-5.15.0-1-amd64' CC [M] /var/lib/dkms/ddcci/0.4.1/build/ddcci/ddcci.o /var/lib/dkms/ddcci/0.4.1/build/ddcci/ddcci.c: In function ‘ddcci_device_remove’: /var/lib/dkms/ddcci/0.4.1/build/ddcci/ddcci.c:1283:24: error: ‘return’ with a value, in function returning void [-Werror=return-type] 1283 | return -EINVAL; |^ /var/lib/dkms/ddcci/0.4.1/build/ddcci/ddcci.c:1273:13: note: declared here 1273 | static void ddcci_device_remove(struct device *dev) | ^~~ cc1: some warnings being treated as errors make[3]: *** [/usr/src/linux-headers-5.15.0-1-common/scripts/Makefile.build:282: /var/lib/dkms/ddcci/0.4.1/build/ddcci/ddcci.o] Error 1 make[2]: *** [/usr/src/linux-headers-5.15.0-1-common/Makefile:1892: /var/lib/dkms/ddcci/0.4.1/build/ddcci] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-5.15.0-1-amd64' make[1]: *** [Makefile:38: ddcci.ko] Error 2 make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.1/build/ddcci' make: *** [Makefile:28: ddcci] Error 2 make: Leaving directory '/var/lib/dkms/ddcci/0.4.1/build'
Bug#998161: gourmet: Fails to run with sqlalchemy 1.4.23, due to removal of FromClause.count()
Package: gourmet Version: 1.0.1-2 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, gourmet fails to run with python3-sqlalchemy v 1.4.23 (in sid). Reason : removal of FromClause.count() (which was already deprecated in v 1.3). This is an upstream problem, of course. A quick look in https://github.com/kirienko/gourmet/tree/master/src/gourmet suggests this has not yet been corrected. Cheers, Itaï -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-3-amd64 (SMP w/12 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gourmet depends on: ii gir1.2-gtk-3.0 3.24.30-3 ii python3 3.9.2-3 ii python3-argcomplete 1.12.3-0.1 ii python3-bs4 4.10.0-2 ii python3-gi 3.42.0-1+b1 ii python3-gst-1.0 1.18.5-1 ii python3-lxml 4.6.3+dfsg-1 ii python3-pil 8.3.2-1 ii python3-reportlab3.6.1-1 ii python3-requests 2.25.1+dfsg-2 ii python3-sqlalchemy 1.4.23+ds1-2 ii python3-toml 0.10.2-1 Versions of packages gourmet recommends: pn kpython3-gtkspellcheck pn python3-pyglet Versions of packages gourmet suggests: pn python3-ebooklib -- no debconf information
Bug#991500: Missing modalias metadata needed for automatic installation
Source: firmware-nonfree Version: 20210315-2 Severity: serious Tags: pending X-Debbugs-Cc: k...@debian.org, debian-b...@lists.debian.org The binary firmware packages built from firmware-nonfree currently include metanfo.xml files with a list of filenames of the firmware in them. These files are indexed and allows firmware packages to be identified and installed based on the files requested. However, during system installation not all kernel drivers are installed and it is not known which files will be requested by the full system. The metainfo.xml files should include a list of Linux modalias strings for the related modules, so that it's possible to identify (possibly) needed firmware packages without the drivers loaded. Ben. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1
On Mon, 2021-05-17 at 18:58 +0900, Roger Shimizu wrote: > Dear Ben, > > Thanks for the report and NMU! > > On Mon, May 17, 2021 at 8:21 AM Ben Hutchings wrote: > > > > Control: tags 988562 + patch > > Control: tags 988562 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1) > > and uploaded it. > > > > The changes are attached as a debdiff, but you can also merge the > > "debian" branch of <https://salsa.debian.org/benh/broadcom-sta.git>. > > However I find this package cannot be source upload, due to non-free. > I'll upload with binary again with version -17 later. > After that, I'll amend your unblock request. Sorry about that, I have got too used to being able to do source-only uploads. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1
Control: tags 988562 + patch Control: tags 988562 + pending Dear maintainer, I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1) and uploaded it. The changes are attached as a debdiff, but you can also merge the "debian" branch of <https://salsa.debian.org/benh/broadcom-sta.git>. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. diff -Nru broadcom-sta-6.30.223.271/debian/changelog broadcom-sta-6.30.223.271/debian/changelog --- broadcom-sta-6.30.223.271/debian/changelog 2021-05-04 11:11:49.0 +0200 +++ broadcom-sta-6.30.223.271/debian/changelog 2021-05-17 01:06:42.0 +0200 @@ -1,3 +1,14 @@ +broadcom-sta (6.30.223.271-16.1) unstable; urgency=medium + + * Non-maintainer upload + * debian/control.modules.in: +- Declare debhelper compat level through a build-dependency + (Closes: #988562) + * debian/rules: +- Fix copying of Debian files in install-source rule + + -- Ben Hutchings Mon, 17 May 2021 01:06:42 +0200 + broadcom-sta (6.30.223.271-16) unstable; urgency=medium * Upload to unstable. diff -Nru broadcom-sta-6.30.223.271/debian/control.modules.in broadcom-sta-6.30.223.271/debian/control.modules.in --- broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-04 11:11:49.0 +0200 +++ broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-17 00:56:52.0 +0200 @@ -2,7 +2,7 @@ Section: non-free/kernel Priority: optional Maintainer: Cyril Lacoux -Build-Depends: debhelper (>= 8) +Build-Depends: debhelper-compat (= 12) Standards-Version: 3.9.4 Homepage: http://www.broadcom.com/support/802.11/linux_sta.php diff -Nru broadcom-sta-6.30.223.271/debian/rules broadcom-sta-6.30.223.271/debian/rules --- broadcom-sta-6.30.223.271/debian/rules 2021-05-04 11:11:49.0 +0200 +++ broadcom-sta-6.30.223.271/debian/rules 2021-05-17 00:56:28.0 +0200 @@ -45,8 +45,8 @@ # Copy Debian files install -D -m 0755 debian/rules.modules $(source_debdir)/rules - for file in changelog compat control control.modules.in copyright; do \ - install -m 644 debian/$$file $(source_debdir); \ + for file in changelog control control.modules.in copyright; do \ + install -m 644 debian/$$file $(source_debdir) || exit; \ done # Make suitable tarball for module-assisant and kernel-package signature.asc Description: PGP signature
Bug#988558: leds-alix: diff for NMU version 0.0.1-1.3
Control: tags 988558 + pending Dear maintainer, I've prepared an NMU for leds-alix (versioned as 0.0.1-1.3) and uploaded it. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. diff -u leds-alix-0.0.1/debian/changelog leds-alix-0.0.1/debian/changelog --- leds-alix-0.0.1/debian/changelog +++ leds-alix-0.0.1/debian/changelog @@ -1,3 +1,10 @@ +leds-alix (0.0.1-1.3) unstable; urgency=medium + + * Non-maintainer upload + * Fix build after removal of SUBDIRS support in Linux 5.3 (Closes: #988558) + + -- Ben Hutchings Mon, 17 May 2021 00:42:59 +0200 + leds-alix (0.0.1-1.2) unstable; urgency=medium * Non maintainer upload by the Reproducible Builds team. only in patch2: unchanged: --- leds-alix-0.0.1.orig/Makefile +++ leds-alix-0.0.1/Makefile @@ -19,10 +19,10 @@ all: $(MODULE) $(MODULE): $(SOURCE) - $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules + $(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules install: $(MODULE) - $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install + $(MAKE) -C $(KERNEL_DIR) M=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install depmod -ae uninstall: signature.asc Description: PGP signature
Bug#988564: Fails to build for Linux 5.6+
Package: vpb-driver-source Version: 4.2.61-1.1 Severity: grave Tags: bullseye sid vpb-driver-source fails to build for Linux kernel version 5.6 and later. This is due to a change in the proc_create_data() API. Ben -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vpb-driver-source depends on: ii bzip2 1.0.8-4 ii debhelper 13.3.4 ii make 4.3-4 ii module-assistant 0.11.10 vpb-driver-source recommends no packages. vpb-driver-source suggests no packages.
Bug#988562: Fails to build due to unspecified debhelper compatibility level
Package: broadcom-sta-source Version: 6.30.223.271-16 Severity: grave The source package embedded in broadcom-sta-source cannot be built. It does not define a debhelper compatibility level, which is mandatory since debhelper 9.20160618, so all debhelper commands fail. Ben. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages broadcom-sta-source depends on: ii debhelper [debhelper-compat] 13.3.4 ii make 4.3-4 ii xz-utils 5.2.5-2 Versions of packages broadcom-sta-source recommends: ii module-assistant 0.11.10 broadcom-sta-source suggests no packages.
Bug#988558: Fails to build against Linux version 5.3+
Source: leds-alix Version: 0.0.1-1.2 Severity: grave Tags: bullseye sid patch The Makefile in leds-alix invokes the kernel build system with the SUBDIRS variable set. This was deprecated long ago and is no longer supported since Linux 5.3. The patch below allows it to build again, though I don't know whether it *works*. Ben. --- a/Makefile +++ b/Makefile @@ -19,10 +19,10 @@ all: $(MODULE) $(MODULE): $(SOURCE) - $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules + $(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules install: $(MODULE) - $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install + $(MAKE) -C $(KERNEL_DIR) M=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install depmod -ae uninstall: --- END --- -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#943425: [klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
On Wed, 2021-05-05 at 20:24 +0200, Ben Hutchings wrote: > On Wed, 2021-05-05 at 17:32 +, Thorsten Glaser wrote: > [...] > > > > > @klibc list: as indicated earlier, I can provide a patch if needed > > > > > (though it should be obvious). > > > > hpa, maks, bwh: any of you taking these two or should I send patches > > and possibly NMU klibc in Debian? > > Please send patches. If you have a test base that could catch bugs test *case* > like this (without writing lists of registers in the test itself), that > would be really useful. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#943425: [klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
On Wed, 2021-05-05 at 17:32 +, Thorsten Glaser wrote: [...] > > > > @klibc list: as indicated earlier, I can provide a patch if needed > > > > (though it should be obvious). > > hpa, maks, bwh: any of you taking these two or should I send patches > and possibly NMU klibc in Debian? Please send patches. If you have a test base that could catch bugs like this (without writing lists of registers in the test itself), that would be really useful. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#987575: linux-kbuild-5.10: please add Breaks: sl-modem-dkms (<< 2.9.11~20110321-16.0)
Control: severity -1 important I don't believe this should be considered an RC bug in Linux packages, but we should still mitigate the problem. There are three different bugs involved: 1. linux-headers-*-common uses the upstream Makefile, which defaults to attempting a full kernel build. That will always fail, and potentially removes installed files as reported. 2. DKMS (and module-assistant?) do module builds as root by default. 3. Some OOT modules use the now-unsupported SUBDIRS variable instead of M or KBUILD_EXTMOD, triggering bug 1. Due to bug 2, this can remove root-owned files. Bug 3 does/did not only exist in the 2 known bad packages in Debian, but also probably in other older packages and unpackaged modules. So I think we cannot comprehensively fix it or avoid it by using "Breaks" relations. (And I would like to avoid the kernel team having to maintain a list of all currently broken OOT modules.) Bugs 1 and 2 should be fixed, but this probably isn't achievable before the bullseye release. So I propose a mitigation of bug 1: if the Makefile is invoked with SUBDIRS set but neither M nor KBUILD_EXTMOD is also set, we abort the build: https://salsa.debian.org/kernel-team/linux/-/merge_requests/353 Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#975476: Acknowledgement (SUM function sometimes includes cells outside the range)
Control: severity -1 normal Control: retitle -1 No error reported for self-referential formula Sorry, this is actually the result of a typo I couldn't see. The sum is of A1:A298, so it does include itself. But I think it's a bug that self-referential formulae are not detected as an error. LibreOffice Calc does report an error for this. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Bug#975476: SUM function sometimes includes cells outside the range
Package: gnumeric Version: 1.12.48-1+b1 Severity: serious In certain circumstances, that I haven't yet identified precisely, a cell containing the SUM function applied to a range of values above it appears to be recalculated including its own previous value! This results in the sum increasing on every recalculation. You should be able to see this in the attached sheet. A99 contains the formula =SUM(A1:A98) and is initially shown with a value of 4950. If you fill in the value 1 in A98, the sum changes to 9901. Ben. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.74 ii gnumeric-common1.12.48-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.4 ii libatk1.0-02.36.0-2 ii libc6 2.31-4 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.66.2-1 ii libgoffice-0.10-10 0.10.48-1 ii libgsf-1-114 1.14.47-1 ii libgtk-3-0 3.24.23-2 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libxml22.9.10+dfsg-6.2 ii procps 2:3.3.16-5 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gnumeric recommends: ii evince3.38.0-2 ii gnumeric-doc 1.12.48-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra pn libgsf-1-dev -- debconf information: gnumeric/existing-process-title: gnumeric/existing-process: false sum-bug.gnumeric Description: application/gzip
Bug#974939: machine does not boot
Control: tag -1 moreinfo Control: severity -1 important On Mon, 2020-11-16 at 19:41 +, Toni wrote: > Package: src:linux > Version: 4.19.152-1 > Severity: critical > > > Hi, > > with the two latest kernels, linux-image-4.19.0-12-amd64 and > linux-image-4.19.0-11-amd64, my machine does not boot, the reason being > that something with cryptsetup is amiss. I used to be asked for a > passphrase, but using these two kernels, I'm not, and the machine just > cycles trying to find the root partition. I am now running the -10 > kernel again, which I would like to get off of. I've tried recovery mode > without any success. This is probably an issue with the initramfs built for this kernel, and not with the kernel itself. Please send the output of the command: lsinitramfs /boot/initrd.img-4.19.0-12-amd64 > On the console, after dmesg, these three lines repeat ad nauseum: > > mdadm: No arrays found in config file or automatically > Volume group "ev0" not found > Cannot process volume group ev0 > mdadm: No arrays found in config file or automatically > Volume group "ev0" not found > Cannot process volume group ev0 [...] If you wait for about 30 seconds you should get a shell with the prompt "(initramfs)". At the shell prompt, run: ls -l /dev/nvme* Are the expected partitions listed? Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols
$ which kwin /usr/bin/kwin $ dpkg -S usr/bin/kwin kwin-x11: /usr/bin/kwin kwin-x11: /usr/bin/kwin_x11 $ ls -l /usr/bin/kwin /usr/bin/kwin -> kwin_x11 $ dpkg --list kwin-x11 ii kwin-11 4:5.17.5-4 amd64 KDE window manager, X11 version $ kwin --version kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv $ sudo apt clean $ sudo apt install --reinstall kwin-x11 libkscreenlocker5 ... finishes with no errors ... $ kwin --version kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv $ objdump -T /lib/x86_64-linux-gnu/libkwin.so.5 | grep greeterClientConnectionChanged 0 DF *UND* 0 _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv $ dpkg -S lib/x86_64-linux-gnu/libkwin.so.5 kwin-common: /lib/x86_64-linux-gnu/libkwin.so.5.17.5 kwin-common: /lib/x86_64-linux-gnu/libkwin.so.5 $ dpkg --list kwin-common ii kwin-common 4:5.17.5-4 amd64 KDE window manager, common files $ sudo apt install --reinstall kwin-x11 libkscreenlocker5 kwin-common ... finishes with no errors ... $ kwin --version kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv
Bug#974538:
It's quite interesting to submit a bug report without a working window manager, but I think this may be related to the commit https://salsa.debian.org/qt-kde-team/kde/kscreenlocker/-/commit/2320b40c8d6f3ba316c83a31bdba79dc8db6d208 not listing the symbol _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEvy . I am not sure if there are any other symbols which might be needed.
Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols
Package: libkscreenlocker5 Version: 5.19.5-4 Severity: serious Justification: Policy 8.1 X-Debbugs-Cc: bunge...@chromium.org $ kwin --replace kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEvy $ ldd /lib/x86_64-linux-gnu/libkwin.so.5 libKScreenLocker.so.5 => /lib/x86_64-linux-gnu/libKScreenLocker.so.5 (0x7f0adc697000) -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/32 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kpackagetool5 5.74.0-2 ii libc6 2.31-4 ii libkf5configcore5 5.74.0-2 ii libkf5configgui5 5.74.0-2 ii libkf5coreaddons5 5.74.0-2 ii libkf5crash5 5.74.0-2 ii libkf5declarative5 5.74.0-2 ii libkf5globalaccel-bin 5.74.0-2 ii libkf5globalaccel5 5.74.0-2 ii libkf5i18n55.74.0-3 ii libkf5idletime55.74.0-2 ii libkf5notifications5 5.74.0-2 ii libkf5package5 5.74.0-2 ii libkf5quickaddons5 5.74.0-2 ii libkf5waylandclient5 4:5.74.0-2 ii libkf5waylandserver5 4:5.74.0-2 ii libkf5windowsystem55.74.0-2 ii libkf5xmlgui5 5.74.0-2+b1 ii libpam0g 1.3.1-5 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5dbus55.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5network5 5.15.1+dfsg-2 ii libqt5qml5 5.15.1+dfsg-3 ii libqt5quick5 5.15.1+dfsg-3 ii libqt5widgets5 5.15.1+dfsg-2 ii libqt5x11extras5 5.15.1-2 ii libseccomp22.4.4-1+b1 ii libstdc++6 10.2.0-16 ii libwayland-client0 1.18.0-2~exp1.1 ii libwayland-server0 1.18.0-2~exp1.1 ii libx11-6 2:1.6.12-1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.14-2 ii libxi6 2:1.7.10-1 ii psmisc 23.3-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.19.5-4 libkscreenlocker5 suggests no packages. -- no debconf information
Bug#972468: nvidia-graphics-drivers-legacy-390xx: module build fails for kernel 5.9.0-1-amd64
I just ran apt upgrade on my Bullseye system upgrading to kernel 5.9.0-1 and got what looks like largely the same errors, but for nvidia-driver 450.66-1.
Bug#971871: installation-reports: bullseye wkly 20201005 - nouveau firmware
Control: severity -1 important Control: reassign -1 src:linux 5.8.10-1 Control: retitle -1 nouveau no longer fails cleanly when firmware is missing Debian does not include non-free software, including firmware. That's not a bug. You will need to install firmware-misc-nonfree to make the nouveau driver fully functional. However, the driver ought to fail cleanly when firmware is missing. At a minimum it should be possible to boot in text mode and then install a firmware package if wanted. > During a hung boot, I am able to SSH into the box to poke around and > send this report. [...] > Oct 8 10:36:52 petrarca kernel: [ 14.118750] nouveau :01:00.0: > firmware: failed to load nvidia/gp107/nvdec/scrubber.bin (-2) > Oct 8 10:36:52 petrarca kernel: [ 14.118753] firmware_class: See > https://wiki.debian.org/Firmware for information about missing firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118760] nouveau :01:00.0: > firmware: failed to load nvidia/gp107/acr/bl.bin (-2) > Oct 8 10:36:52 petrarca kernel: [ 14.118762] nouveau :01:00.0: acr: > failed to load firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118763] nouveau :01:00.0: acr: > failed to load firmware > Oct 8 10:36:52 petrarca kernel: [ 14.118764] nouveau :01:00.0: acr > ctor failed, -2 > Oct 8 10:36:52 petrarca kernel: [ 14.118771] nouveau: probe of > :01:00.0 failed with error -2 I think that boot did complete, but without a working video driver. nouveau may have disabled the basic video driver (probably efifb) before attempting to load firmware and then finding that it can't take over. Unfortunately the kernel doesn't have an API for re-enabling a basic video driver. There have been similar issues with the radeon and amdgpu drivers, which we patch to guard against this failure mode. We might need to apply a similar patch for nouveau. Ben. -- Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought. I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. - Maurice Wilkes, 1949 signature.asc Description: This is a digitally signed message part
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: unblock -1 by 933750 Control: tags -1 + pending Control: outlook -1 0 We will ignore the remaining reverse-dependencies. This release will break those reverse-dependencies, but they have already lost other Python dependencies which drop Python 2 support. On 17-Aug-2020, Jann Haber wrote: > paleomix was removed from testing in May for not supporting Python > 3. Since then, the following b-ds of paleomix have already been > dropped: python-nose, python-flexmock, python-pysam and > python-setproctitle - so it is already impossible to be build from > source in sid. That convinces me, then. I will remove that block on this bug report, and proceed with the Coverage 5.1 packaging. Thanks for investigating and documenting what you found. -- \ “I bought some batteries, but they weren't included; so I had | `\to buy them again.” —Steven Wright | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#963636: linux: FTBFS with Sphinx 3.1: Could not import extension cdomain (exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (/usr/lib/python3/dist-packages/sphinx/domains/c.
Control: clone -1 -2 Control: tag -2 - ftbfs Control: severity -2 important Control: submitter -2 ! Control: close -1 5.7.17-1 On Wed, 2020-06-24 at 22:51 +0200, Lucas Nussbaum wrote: > Source: linux > Version: 5.6.14-2 > Severity: important > Tags: ftbfs > User: python-modules-t...@lists.alioth.debian.org > Usertags: sphinx3.1 > > Hi, > > linux fails to build with Sphinx 3.1, currently available in > experimental. [...] This is fixed for now by disabling the cdomain extension, but we will need someone to update/rewrite it for Sphinx 3. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#968875: rss2email forges envelope sender
Package: rss2email Version: 1:3.12.1-1 Severity: serious Tags: upstream Today I learned that rss2email copies the email addresses from feed entries into both the From field and the envelope sender of messages. This is not acceptable behaviour in an email generator. The envelope sender *must* be sent to an address that the user configures, where *they* can receive bounce messages. The current behaviour results in bounces being sent to the authors of feed entries, which is what just happened to me. It can also result in messages being dropped if the forgery is detected by MTAs that check SPF. Ben. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rss2email depends on: ii python3 3.8.2-3 ii python3-feedparser 5.2.1-2 pn python3-html2text Versions of packages rss2email recommends: ii python3-bs4 4.9.1-1 Versions of packages rss2email suggests: pn esmtp -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: block 967200 by -1 On 17-Aug-2020, Ben Finney wrote: > The updated package is ready, and waiting for reverse-dependencies (as > described in bug reports blocking this one) to drop Python 2 support. -- \ “I have a map of the United States; it's actual size. It says | `\‘1 mile equals 1 mile’. Last summer, I folded it.” —Steven | _o__) Wright | Ben Finney signature.asc Description: PGP signature
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: forcemerge -1 967200 Control: block -1 by 933750 Control: outlook -1 0 The updated package is ready, and waiting for reverse-dependencies (as described in bug reports blocking this one) to drop Python 2 support. On 16-Aug-2020, Jann Haber wrote: > It seems like, there are no more rdeps of python-coverage now. Not > sure about pypy-coverage. Yes, I see no reverse dependencies for Python 2 ‘pypy-coverage’: $ aptitude search '~Dpypy-coverage' But one remaining for Python 2 ‘python-coverage’: $ aptitude search '~Dpython-coverage' p paleomix So, it seems we are waiting for ‘paleomix’ to drop Python 2 support. I am recording bug#933750 as a blocker for bug#933750. -- \ “When I wake up in the morning, I just can't get started until | `\ I've had that first, piping hot pot of coffee. Oh, I've tried | _o__)other enemas...” —Emo Philips | Ben Finney signature.asc Description: PGP signature
Bug#966515: scons: Some upstream sources are missing
On Thu, 2020-07-30 at 06:17 -0700, Bill Deegan wrote: > Ok > > Can you check the 4.0.1 tarballs and see if they provide in each what you > need? > We completely reimplemented packaging in 4.0.0 I can't find a scons-src tarball for 4.0.1. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Bug#966515: scons: Some upstream sources are missing
On Wed, 2020-07-29 at 16:26 -0700, Bill Deegan wrote: > So what is this issue? > Which tarball debian packages are using as their source? Yes, the Debian source package is based on the 'production' tarball, not the full source. Debian source packages (except in the non-free section) are required to include full source. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
