Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

Control: tag -1 unreproducible moreinfo

Hi Bud,

Please understand that when I aksed you to carry out a specific test, I
had a good reason for doing exactly that.  The tests that you have
carried out so far, while useful, don't provide the same information.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



signature.asc
Description: This is a digitally signed message part

Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

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

[Ben Hutchings]

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#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations)

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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)

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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#1028986: Multiple integer overflow and buffer overflow issues in game loading

[Ben Hutchings]

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#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[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 
---
 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]

[Ben Hutchings]

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]

[Ben Hutchings]

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]

[Ben Hutchings]

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#1014633: linux-headers-5.19.0-rc4-common: file check-local-export does not exist

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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#1005404: Kernel modules fail to build with Linux 5.16 onward

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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:
.

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

[Ben Hutchings]

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:
.

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

[Ben Hutchings]

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

[Ben Hutchings]

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
.

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

[Ben Hutchings]

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
.

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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#991500: Missing modalias metadata needed for automatic installation

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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+

[Ben Hutchings]

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

[Ben Hutchings]

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+

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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)

[Ben Hutchings]

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)

[Ben Hutchings]

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

[Ben Hutchings]

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

[Ben Hutchings]

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#971871: installation-reports: bullseye wkly 20201005 - nouveau firmware

[Ben Hutchings]

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#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.

[Ben Hutchings]

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

[Ben Hutchings]

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#966515: scons: Some upstream sources are missing

[Ben Hutchings]

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

[Ben Hutchings]

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

Bug#966515: scons: Some upstream sources are missing

[Ben Hutchings]

On Wed, 2020-07-29 at 16:11 -0700, Bill Deegan wrote:
> Note there's a bug for this on SCons tracker.
> https://github.com/SCons/scons/issues/3759
> 
> Please add any comments there.

No, that's an entirely different issue.

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

[Ben Hutchings]

Source: scons
Version: 3.1.2-2
Severity: serious

Dear Maintainer,

The current source package uses the 'production' tarballs
(scons-.tar.gz) as the orig tarball, whereas the upstream
source tarballs are released as scons-src-.tar.gz.

The 'production' tarballs contain many generated or preprocessed files.
In particular, the manual pages there are generated from the doc/man/
subdirectory of the upstream source, which is *not* included in the
production tarballs.

Ben.

-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: notfixed 942861 5.3.9-1
Control: forcemerge 942861 -1

On Tue, 2020-06-16 at 17:44 +0100, Ben Hutchings wrote:
> Control: found -1 5.3.2-1~exp1
> 
> On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> > Package: linux-image-amd64
> > Version: 5.6.14-2
> > Severity: serious
> > Justification: Policy 2.3
> > 
> > tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> > total 0
> > tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> > drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/
> 
> This is the dpkg bug where it fails to replace a directory with a
> symlink.  For some reason that requires workarounds in every other
> package instead of being fixed in dpkg.
> 
> This instance was introduced by:
> 
> commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
> Author: Ben Hutchings 
> Date:   Tue Oct 1 22:27:29 2019 +0100
> 
> Require metapackage dependencies to be the same version, and link doc dirs

Actually you already reported this as #942861 and I applied the
workaround, but it looks like I specified the wrong prior-version to
dpkg-maintscript-helper.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



signature.asc
Description: This is a digitally signed message part

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: found -1 5.3.2-1~exp1

On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> Package: linux-image-amd64
> Version: 5.6.14-2
> Severity: serious
> Justification: Policy 2.3
> 
> tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> total 0
> tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/

This is the dpkg bug where it fails to replace a directory with a
symlink.  For some reason that requires workarounds in every other
package instead of being fixed in dpkg.

This instance was introduced by:

commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
Author: Ben Hutchings 
Date:   Tue Oct 1 22:27:29 2019 +0100

Require metapackage dependencies to be the same version, and link doc dirs

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



signature.asc
Description: This is a digitally signed message part

Bug#962197: buildstream: Event loop broken on Python 3.8

[Ben Hutchings]

Control: tag -1 upstream fixed-upstream patch

Although there are still some issues with 3.8 upstream, this one is
actually fixed.  Here's the patch.

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom
From: Chandan Singh 
Date: Mon, 21 Oct 2019 14:38:07 +0100
Subject: _scheduler/scheduler.py: Enforce SafeChildWatcher
Origin: https://gitlab.com/BuildStream/buildstream/-/commit/0eca9e6a4a01d1094987773bce58d9d3e501f1e8
Bug-Debian: https://bugs.debian.org/962197

In Python 3.8, `ThreadedChildWatcher` is the default watcher that causes
issues with our scheduler. Enforce use of `SafeChildWatcher`.

[benh: Backported to 1.4.1: adjust filename]
---
 buildstream/_scheduler/scheduler.py | 6 ++
 1 file changed, 6 insertions(+)

--- a/buildstream/_scheduler/scheduler.py
+++ b/buildstream/_scheduler/scheduler.py
@@ -137,6 +137,12 @@ class Scheduler():
 # Hold on to the queues to process
 self.queues = queues
 
+# NOTE: Enforce use of `SafeChildWatcher` as we generally don't want
+# background threads.
+# In Python 3.8+, `ThreadedChildWatcher` is the default watcher, and
+# not `SafeChildWatcher`.
+asyncio.set_child_watcher(asyncio.SafeChildWatcher())
+
 # Ensure that we have a fresh new event loop, in case we want
 # to run another test in this thread.
 self.loop = asyncio.new_event_loop()

Bug#962205: buildstream: Missing dependency on bubblewrap

[Ben Hutchings]

Package: buildstream
Version: 1.4.1-1
Severity: serious

Dear Maintainer,

bubblewrap is a run-time dependency for BuildStream on Linux, but is
not included in the package dependencies.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-
8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages buildstream depends on:
ii  python3  3.8.2-3
ii  python3-buildstream  1.4.1-1

Versions of packages buildstream recommends:
ii  python3-bst-external  0.18.0-1

buildstream suggests no packages.

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962197: buildstream: Event loop broken on Python 3.8

[Ben Hutchings]

Package: buildstream
Version: 1.4.1-1
Severity: grave

Dear Maintainer,

Un-cached builds with builstream currently fail like this:

[--:--:--][][] BUG no running event loop

Traceback (most recent call last):
  File "/usr/bin/bst", line 8, in 
sys.exit(cli())
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/buildstream/_frontend/cli.py", line 
173, in override_main
original_main(self, args=args, prog_name=prog_name, complete_var=None,
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 27, in 
new_func
return f(get_current_context().obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/buildstream/_frontend/cli.py", line 
340, in build
app.stream.build(elements,
  File "/usr/lib/python3/dist-packages/buildstream/_stream.py", line 211, 
in build
self._run()
  File "/usr/lib/python3/dist-packages/buildstream/_stream.py", line 1022, 
in _run
_, status = self._scheduler.run(self.queues)
  File 
"/usr/lib/python3/dist-packages/buildstream/_scheduler/scheduler.py", line 153, 
in run
self._sched()
  File 
"/usr/lib/python3/dist-packages/buildstream/_scheduler/scheduler.py", line 427, 
in _sched
self._sched_queue_jobs()
  File 
"/usr/lib/python3/dist-packages/buildstream/_scheduler/scheduler.py", line 401, 
in _sched_queue_jobs
self._spawn_job(job)
  File 
"/usr/lib/python3/dist-packages/buildstream/_scheduler/scheduler.py", line 281, 
in _spawn_job
job.spawn()
  File "/usr/lib/python3/dist-packages/buildstream/_scheduler/jobs/job.py", 
line 162, in spawn
self._watcher.add_child_handler(self._process.pid, 
self._parent_child_completed)
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 1293, in 
add_child_handler
loop = events.get_running_loop()
RuntimeError: no running event loop

This was reported upstream as:
https://gitlab.com/BuildStream/buildstream/-/issues/1246

but is now tracked in:
https://gitlab.com/BuildStream/buildstream/-/issues/1173

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages buildstream depends on:
ii  python3  3.8.2-3
ii  python3-buildstream  1.4.1-1

Versions of packages buildstream recommends:
ii  python3-bst-external  0.18.0-1

buildstream suggests no packages.

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#961851: Processed: make-dfsg breaks cross-toolchain-base autopkgtest: debian/kernelarch.make:5: *** empty variable name

[Ben Hutchings]

On Sun, 2020-05-31 at 18:06 -0700, Manoj Srivastava wrote:
>   Error verifying signature: security library: improperly formatted 
> DER-encoded message. (-8183) - Decoder failed
> notfound 961851 make-dfsg/4.3-1
> thanks
> 
> Hi,
> 
> The file NEWS.Debian for make-dfsg states:
> ,
> >   * WARNING: Backward-incompatibility!
> > Previously appending using '+=' to an empty variable would result in a 
> > value
> > starting with a space.  Now the initial space is only added if the 
> > variable
> > already contains some value.  Similarly, appending an empty string does 
> > not
> > add a trailing space.
> `

It's pretty sad that make upstream keeps making incompatible changes
without a compelling reason for them.

> The bug lies here:
> ,[ debian/kernelarch.make ]
> > # Black-belt magic
> > , := ,
> > space :=
> > space +=
> > $(space) := 
> > $(space) +=
> `----

Anyway, this is what Kbuild does; hopefully this hasn't broken too:

empty   :=
space   := $(empty) $(empty)

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#959451: Acknowledgement (am-utils: Build-Depends on obsolete package linux-kernel-headers)

[Ben Hutchings]

Actually, since linux-libc-dev is (transitively) build-essential, you
do not need to Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959453: Acknowledgement (dvbstream: Build-Depends on obsolete package linux-kernel-headers)

[Ben Hutchings]

Actually, since linux-libc-dev is (transitively) build-essential, you
do not need to Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




signature.asc
Description: This is a digitally signed message part

Bug#959454: Acknowledgement (dvbtune: Build-Depends on obsolete package linux-kernel-headers)

[Ben Hutchings]

Actually, since linux-libc-dev is (transitively) build-essential, you
do not need to Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




signature.asc
Description: This is a digitally signed message part

Bug#959452: Acknowledgement (array-info: Build-Depends on obsolete package linux-kernel-headers)

[Ben Hutchings]

Actually, since linux-libc-dev is (transitively) build-essential, you
do not need to Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




signature.asc
Description: This is a digitally signed message part

Bug#959460: paxtest: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:paxtest
Version: 1:0.9.15-1
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959461: raidutils: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:raidutils
Version: 0.0.6-22
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959458: matchbox-panel: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:matchbox-panel
Version: 0.9.3-10
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959459: netsend: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:netsend
Version: 0.0~svnr250-1.3
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959225: libcap-ng FTBFS: Build-Depends: linux-kernel-headers is no longer provided

[Ben Hutchings]

On Fri, 1 May 2020 09:18:20 +0200 Helmut Grohne  wrote:
> Source: libcap-ng
> Version: 0.7.9-2.1
> Severity: serious
> Tags: ftbfs patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> libcap-ng fails to build from source, because linux-libc-dev no longer
> provides linux-kernel-headers, which is what libcap-ng Build-Depends on.
> Please transition your dependency to linux-libc-dev:
> 
> sed -i -e 's/linux-kernel-headers/linux-libc-dev/' debian/control

I will restore this Provides temporarily as I had failed to see that
there were still build-dependencies on it.  But please do remove linux-
kernel-headers, as it's not a documented virtual package.

linux-libc-dev is (transitively) build-essential, so there is no need
to explicitly Build-Depend on it.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




signature.asc
Description: This is a digitally signed message part

Bug#959455: fakeroot-ng: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:fakeroot-ng
Version: 0.18-4
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959456: inotify-tools: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:inotify-tools
Version: 3.14-8
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959457: isakmpd: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:isakmpd
Version: 20041012-8
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.

linux-libc-dev is (transitively) build-essential, so you do not need to
Build-Depend on it at all.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959453: dvbstream: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:dvbstream
Version: 0.6+cvs20090621-2
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.  Please change the dependency to linux-libc-dev.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959454: dvbtune: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:dvbtune
Version: 0.5.ds-1.1
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.  Please change the dependency to linux-libc-dev.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959452: array-info: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:array-info
Version: 0.16-4
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.  Please change the dependency to linux-libc-dev.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#959451: am-utils: Build-Depends on obsolete package linux-kernel-headers

[Ben Hutchings]

Package: src:am-utils
Version: 6.2+rc20110530-3.2
Severity: serious

linux-kernel-headers was removed from unstable in 2007 (I think).  It
is now effectively a virtual package provided by linux-libc-dev, but
it's not a documented virtual package name and I would like to stop
providing it.  Please change the dependency to linux-libc-dev.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.



signature.asc
Description: This is a digitally signed message part

Bug#956661: /usr/sbin/update-initramfs: update-initramfs hangs forever when trying to update

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo unreproducible

On Mon, 2020-04-13 at 20:54 -0400, Frank McCormick wrote:
> Package: initramfs-tools
> Version: 0.136
> Severity: grave
> File: /usr/sbin/update-initramfs
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Not much to report. Update-initramfs hangs forever when trying to create a new
> file or update a current one.
> This happened after this afternoons update on Debian Sid. It's pretty much
> useless
> now.
[...]

initramfs-tools hasn't been changed for a while, so the bug is probably
elsewhere.

I tried to reproduce this on unstable, with all the same packages you
have that include initramfs hooks, but update-initramfs completes in
about 15 seconds.

Please run this (as root) and send the output:

mkinitramfs -v -o initrd.img

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
  - Albert Einstein




signature.asc
Description: This is a digitally signed message part

Bug#867067: create directory for nfsdcltrack

[Ben Hutchings]

Control: severity -1 important

On Mon, 2020-02-24 at 16:01 +0100, Elimar Riesebieter wrote:
> Control: found -1 1.3.4-2.5
> Control: severity -1 grave
> 
> Hi all,
> 
> this bug causes kernel panics at least on i386 and x86-64 running
> nfsv4 servers so set severity to grave.
[...]

This bug is assigned to nfs-kernel-server, which only contains the
programs used to *configure* the NFS server in the kernel.

The kernel crash needs to be assigned to the kernel, i.e. src:linux. 
You should open a separate bug for that, using "reportbug kernel".

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.




signature.asc
Description: This is a digitally signed message part

Bug#951771: linux-source-5.4: linux 5.4.0-4 does not boot on this pc

[Ben Hutchings]

Control: reassign -1 src:linux 5.4.19-1
Control: severity -1 important
Control: tag -1 moreinfo

On Fri, 2020-02-21 at 15:39 +0100, TS wrote:
> Package: linux-source-5.4
> Version: linux 5.4.0-4
> Severity: serious
> Justification: 1
> 
> Hi
> 
> did upgrade to sid. linux 5.4.0-4 does not boot on this pc.
> Booting 4.19.0-8-amd64 instead brings up running system.
> 
> The boot prozess breaks after grub. Blank screen, nothing happens.
> With 4.19.0-8-amd64 system boots up as expected.

Are we supposed to guess what "this pc" is?

Run "reportbug kernel" and add the information that it gathers to this
bug report.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




signature.asc
Description: This is a digitally signed message part

Bug#947340: kernel-package: diff for NMU version 13.018+nmu2

[Ben Hutchings]

Control: tags 947340 + patch
Control: tags 947340 + pending

I've uploaded the previously prepared NMU for kernel-package
(versioned as 13.018+nmu2), with a reference to this bug report.  My
changes are also available at
<https://salsa.debian.org/benh/kernel-package>.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.
diff -Nru kernel-package-13.018+nmu1/Makefile kernel-package-13.018+nmu2/Makefile
--- kernel-package-13.018+nmu1/Makefile	2016-02-16 23:35:18.0 +
+++ kernel-package-13.018+nmu2/Makefile	2019-03-24 22:18:52.0 +
@@ -110,7 +110,6 @@
done)
 	$(install_file)debian/copyright  	  $(DOCDIR)/copyright
 	$(install_file)kernel-pkg.conf.5 	  $(MAN5DIR)/kernel-pkg.conf.5
-	$(install_file)kernel-img.conf.5 	  $(MAN5DIR)/kernel-img.conf.5
 	$(install_file)kernel-package.5  	  $(MAN5DIR)/kernel-package.5
 	$(install_file)make-kpkg.8   	  $(MAN1DIR)/make-kpkg.1
 	$(install_file)kernel-packageconfig.8 $(MAN8DIR)/
@@ -119,10 +118,6 @@
  mkdir -p $(MANTOP)/$$lang/man5;   \
   test ! -f kernel-pkg.conf.$$lang.5  ||   \
$(install_file) kernel-pkg.conf.$$lang.5   $(MANTOP)/$$lang/man5/kernel-pkg.conf.5; \
-  test ! -f kernel-img.conf.$$lang.5  || test -d $(MANTOP)/$$lang/man5||   \
- mkdir -p $(MANTOP)/$$lang/man5;   \
-  test ! -f kernel-img.conf.$$lang.5  ||   \
-   $(install_file) kernel-img.conf.$$lang.5   $(MANTOP)/$$lang/man5/kernel-img.conf.5; \
   test ! -f kernel-package.$$lang.5   || test -d $(MANTOP)/$$lang/man5||   \
  mkdir -p $(MANTOP)/$$lang/man5;   \
   test ! -f kernel-package.$$lang.5   ||   \
@@ -163,8 +158,6 @@
 	for lang in de fr; do\
   test ! -f kernel-pkg.conf.$$lang.5 ||  \
 rm  kernel-pkg.conf.$$lang.5  ;  \
-	  test ! -f kernel-img.conf.$$lang.5 ||  \
-rm  kernel-img.conf.$$lang.5  ;  \
 	  test ! -f kernel-package.$$lang.5 ||   \
 rm  kernel-package.$$lang.5   ;  \
 	  test ! -f make-kpkg.$$lang.8 ||\
diff -Nru kernel-package-13.018+nmu1/debian/changelog kernel-package-13.018+nmu2/debian/changelog
--- kernel-package-13.018+nmu1/debian/changelog	2017-07-16 09:52:57.0 +0100
+++ kernel-package-13.018+nmu2/debian/changelog	2019-12-25 22:27:29.0 +
@@ -1,3 +1,13 @@
+kernel-package (13.018+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * kernel-common: Remove kernel-img.conf(5) and recommend linux-base
+instead (Closes: #947340; see #925415)
+  * Refresh translation files for removal of kernel-img.conf(5)
+  * debian/control: Point Vcs-{Browser,Git} at Salsa
+
+ -- Ben Hutchings   Wed, 25 Dec 2019 22:27:29 +
+
 kernel-package (13.018+nmu1) unstable; urgency=medium
 
   [ Tobias Frost ]
diff -Nru kernel-package-13.018+nmu1/debian/control kernel-package-13.018+nmu2/debian/control
--- kernel-package-13.018+nmu1/debian/control	2016-02-16 23:35:18.0 +
+++ kernel-package-13.018+nmu2/debian/control	2019-03-24 22:21:47.0 +
@@ -1,6 +1,6 @@
 Source: kernel-package
-VCS-Git: https://anonscm.debian.org/git/users/srivasta/debian/kernel-package.git
-VCS-Browser: https://anonscm.debian.org/gitweb/?p=users/srivasta/debian/kernel-package.git;a=summary
+VCS-Git: https://salsa.debian.org/srivasta/kernel-package.git
+VCS-Browser: https://salsa.debian.org/srivasta/kernel-package
 Priority: optional
 Section: kernel
 Build-Depends-Indep: po4a (>= 0.31), debhelper (>= 9)
@@ -29,6 +29,7 @@
 Package: kernel-common
 Architecture: all
 Depends: ${misc:Depends}
+Recommends: linux-base (>= 4.6~)
 Suggests: kernel-package
 Enhances: kernel-package, linux-image
 Replaces: kernel-package (<= 13.008)
diff -Nru kernel-package-13.018+nmu1/debian/kernel-common.manpages kernel-package-13.018+nmu2/debian/kernel-common.manpages
--- kernel-package-13.018+nmu1/debian/kernel-common.manpages	2016-02-16 23:35:18.0 +
+++ kernel-package-13.018+nmu2/debian/kernel-common.manpages	1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-kernel-img.conf.5
-kernel-img.conf.de.5
-kernel-img.conf.fr.5
diff -Nru kernel-package-13.018+nmu1/kernel-img.conf.5 kernel-package-13.018+nmu2/kernel-img.conf.5
--- kernel-package-13.018+nmu1/kernel-img.conf.5	2016-02-16 23:35:18.0 +
+++ kernel-package-13.018+nmu2/kernel-img.conf.5	1970-01-01 01:00:00.0 +0100
@@ -1,266 +0,0 @@
-.\" Hey, Emacs! This is an -*

Bug#947340: linux-base: can't be upgraded

[Ben Hutchings]

Control: reassign -1 src:kernel-package 13.018+nmu1
Control: retitle -1 kernel-common conflicts with current linux-base
Control: affects -1 linux-base

On Wed, 2019-12-25 at 03:06 +0100, Christoph Anton Mitterer wrote:
> Package: linux-base
> Version: 4.6
> Severity: grave
> Justification: renders package unusable
> 
> 
> Hi.
> 
> Since last April, the package can't be upgraded as it conflicts with
> the current version of kernel-common.
> 
> Would be nice if this could be resolved.
> 
> Probably it's this change:
>   * Take over kernel-img.conf(5) manual page from kernel-common   
>   
>  ▒
> (Closes: #925415) 
>   
>  ▒
> but then this should be reflected in kernel-common, or it should have
> been coordinated with its maintainer in the first place.

Manoj suggested that the kernel team should take over kernel-img.conf,
and I prepared updates to both linux-base and kernel-package (see <
https://salsa.debian.org/benh/kernel-package>).  However I never got a
response from him as to whether he or I should upload kernel-package.

I suppose I should just go ahead and do that now.

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#944254: ocaml-nox: Files overwrite /usr/lib/ocaml/bigarray.cmi in ocaml-base-nox package

[Ben Hutchings]

Control: notfixed 944126 4.08.1-3
Control: forcemerge 944126 -1

On Sun, 2019-11-10 at 02:56 +0100, Vincent Lefevre wrote:
> On 2019-11-10 01:34:14 +0000, Ben Hutchings wrote:
> > On Sun, 2019-11-10 at 01:12 +0000, Ben Hutchings wrote:
> > > On Sun, 2019-11-10 at 02:11 +0100, Vincent Lefevre wrote:
> > > > On 2019-11-10 00:48:12 +, Ben Hutchings wrote:
> > > > > Control: retitle -1 ocaml-base-nox: Replaces 
> > > > > /usr/lib/ocaml/libasmrun_shared.so in older ocaml-nox
> > > > > 
> > > > > On Sun, 2019-11-10 at 01:41 +0100, Vincent Lefevre wrote:
> > > > [...]
> > > > > > Is this the same bug as #944126 (the bug title is the same) or
> > > > > > is it still present in 4.08.1-4?
> > > > > 
> > > > > It appears that files have been moved both ways between ocaml-base-nox
> > > > > and ocaml-nox.  The original bug report showed two file conflicts, but
> > > > > only one of them was fixed.
> > > > 
> > > > ocaml-base-nox 4.08.1-4 has:
> > > > 
> > > > Replaces: ocaml-base (<< 4.08), ocaml-nox (<< 4.08)
> > > > Breaks: ocaml-base (<< 4.08), ocaml-nox (<< 4.08)
> > > > 
> > > > Isn't that sufficient?
> > > 
> > > Well, the upgrade still failed for me with this version.
> > 
> > Sorry, the version I found this in is 4.08.1-3, as recored on the bug
> > report.  Version 4.08.1-4 probably does fix this, but I've already
> > removed the ocaml packages since I didn't actually need them.
> 
> I've just done the upgrade from 4.05.0-12 to 4.08.1-4, and I did not
> get any error.

Great.  Since the changelog for -4 closed #944126, I'm merging these
reports back together and marking them as both fixed in -4, not -3.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



signature.asc
Description: This is a digitally signed message part