Uploading linux (6.8.9-1)

[Ben Hutchings]

I intend to upload linux 6.8.9-1 to unstable tomorrow (Thursday 16th
May).

This is a new upstream version with, as usual, many changes.

The pending changes in the package are:

  * d/templates/main.control.in: Add python3-dacite as linux-support Depends
  * [armhf] Improve Tegra Chromebook support (Closes: #1061680)
- [armhf] drivers/net/wireless/marvell/mwifiex: Enable MWIFIEX and
  MWIFIEX_SDIO as modules
- [armhf] drivers/power/supply: Enable CHARGER_BQ24735 as module
- [armhf] drivers/hwmon: Enable SENSORS_LM90 as module
- [armhf] drivers/media/cec/platform: Enable CEC_TEGRA as module
  * drivers/thermal: Enable THERMAL_NETLINK
  * [amd64] drivers/tee/amdtee: Enable AMDTEE as module
  * [amd64] drivers/platform/x86/amd/pmf: Enable AMD_PMF as module
(Closes: #1063161)
  * d/copyright: Exclude 'action-ebpf' as that's a binary blob
  * d/installer/modules: Remove modules removed from upstream kernel
  * [rt] Update to 6.8.2-rt11
  * [rt] Drop patches applied in 6.8.6
  * [arm64] net/rfkill: Enable RFKILL_GPIO as module
  * [arm64] Further improve support for SolidRun HoneyComb (Closes: #1065611):
- [arm64] drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
  SENSORS_LTC2978 as modules
- [arm64] drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
- [arm64] drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
- [arm64] drivers/soc/fsl: Enable FSL_RCPM
  * d/templates: Change firmware-linux-free from Recommends to Suggests
  * [arm64] Improve support for SolidRun Honeycomb Workstation:
- drivers/pci/controller/mobiveil: Enable PCIE_LAYERSCAPE_GEN4
  (Closes: #1061116)
- drivers/phy/freescale: Enable PHY_FSL_LYNX_28G as module
  (Closes: #1061117)
  * sound/virtio: Enable SND_VIRTIO as module (Closes: #1059089)
  * drivers/tty: Disable N_GSM
  * tipc: fix UAF in error path
  * tipc: fix a possible memleak in tipc_buf_append
  * d/salsa-ci.yml: Restore Python static checks on scripts
  * linux-doc: Add python3-yaml to Build-Depends, required from 6.8
  * sound: Enable TAS2781 Smart Amp modules
  * [arm64] Dynamically allocate cpumasks and increase supported CPUs to 512
  * [arm64,armhf] Enable SND_SOC_WM8804_I2C for the hifiberry-digi raspberry
hat.

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

Re: What to do with d-i on armel?

[Ben Hutchings]

On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote:
> On Sun, Jan 7, 2024, at 23:07, Bastian Blank wrote:
> > Hi
> > 
> > With Linux 6.6 we dropped the Marvell specific kernel image, as it
> > was not known to work on any of the available devices.  We still have
> > another armel kernel left, the one of the Raspberry Pi 0 and 1, which
> > uses an ARMv6 CPU.
> > 
> > This also removed all the udebs from armel, which makes many d-i
> > components not longer have fullfiled dependencies and the release stuff
> > of course acting up.
> > 
> > Do we have any armel subarch that can be installed via d-i?
> 
> A few ideas from the kernel's point of view:
> 
> The most important ARMv5 platform is now probably at91, as
> Microchip still releases new sam9 chips[1] and is going to
> keep supporting it for a while.
> I would guess that the latest ones are not even that far off
> the performance of the kirkwood/mv78xx0 or bcm2835 parts,
> but I don't have numbers.
> 
> Qemu versatilepb is probably the most accessible arm926
> platform, though there are a couple of other armv5/v6 (ast2400,
> ast2500, pxa27x, raspi1ap) in qemu that one should be able
> to get to work as well if anyone found the time.

We used to have a configuration for Versatile, but it got broken
accidentally; when I found out I removed it because no-one had
complained in 9 months.  (Maybe that was a bit quick!)

We do have a configuration for RPi 0/1, which is supported with images
at <https://raspi.debian.net/> rather than through d-i.

I don't think anyone has proposed configurations to support the other
platforms.

> Since armel userland should work fine with any armhf or
> arm64 kernel, it might still be useful to repackage
> one or both of those for the armel archive and use this
> to have an installation method for armel on modern
> hardware. [Side note: I would also like to see an arm64
> kernel image added to armhf, it's probably more useful
> than the armmp-lpae kernel in terms of enabling users.]

We used to do this for amd64 kernels on i386.  Then Debian implemented
multiarch and it became an unnecessary waste of build resources. 
Still, we are lacking support for adding a "foreign" architecture and
kernel package at installation time.

(This specific combination would also be hard to support in the current
linux packaging because arm64 and armhf have different kernel
architectures and toolchains, unlike amd64 and i386.)

> At the moment, it is possible to enable support for
> arm1176 (as in bcm2835) in a normal armhf kernel and
> have that boot on armv6k, armv7 and armv8 hardware.
> I actually want to change that in the kernel though:
> Now that we dropped SMP support in armv6, as it now
> makes more sense to have armv6k grouped with armv5
> and instead have a generic kernel for armel that
> works on bcm2835, versatilepb, at91, kirkwood and
> all the others that one might use.

If someone wants to make this work in Debian that would be great, but
without a specific maintainer it's not going to happen.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.



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

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

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Ben Hutchings]

On Sat, 2023-09-09 at 11:13 +0200, Paul Gevers wrote:
> Hi Salvatore,
> 
> On 09-09-2023 10:15, Salvatore Bonaccorso wrote:
> > but should have been support for armel been
> > dropped earlier and should we do it for trixie
> 
> The kernel for armel went over some hardware limits before (I was 
> affected with my NAS, where I couldn't upgrade the kernel to bullseye as 
> documented in the release notes [1]). Is the current situation reaching 
> the limit for all armel devices, or "just" for some and are the others 
> probably fine for some years to come?

The issue exists with many devices supported by the "marvell" flavour.
We also have an "rpi" flavour for armel that supports Raspberry Pi
models with Arm v6 CPUs, and that doesn't have any size limits that
we've needed to worry about yet.

> If we're now reaching the final limit and if it was foreseeable that we 
> would reach that limit, then yes it would have made sense to drop armel 
> *before* the bookworm release, but alas. If the kernel team can't 
> support the kernel on armel, than armel shouldn't be a release 
> architecture for trixie. If it's only some devices, than we "just" need 
> to communicate that clearly.
[...]

I would be quite happy to drop the "marvell" flavour for trixie.  The
size limits are a recurring problem, and the supported SoCs and devices
seem to have been out of production for a long time.  In contrast, the
Raspberry Pi models with v6 CPUs are still in production.

(I do have my doubts as to whether it will be possible to continue
supporting a useful user-space for armel, but I certainly can't speak
authoritatively about that.)

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


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

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

Re: Uploading linux (6.4.4-1)

[Ben Hutchings]

On Sat, 2023-07-22 at 22:57 +0200, Salvatore Bonaccorso wrote:
[...]
> Having 6.3.11-1 into testing would really have been preferred but I understand
> people do not want to have #1040178 exposed, so let's try to move ahead with
> the 6.4.y series.
> 
> Ben and Bastian, let me know loudly if you disagree on the plan to upload
> 6.4.4-1 for unstable.

No objection here.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

Re: Debian Kernel version and ABI in respect of #1040901

[Ben Hutchings]

On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote:
[...]
> ## Proposed behaviour
> 
> This tries to make sure everything apart from experimental gets new
> names and ABI on every upload.
> 
> * experimental:
> Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
> Keep ABI 6.1.0-0-arm64
[...]

Why would that still be acceptable in experimental?

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#1035769: unblock: kernel-handbook/1.0.21

[Ben Hutchings]

bk 2023-05-08 23:05:29.0 
+0200
@@ -67,7 +67,18 @@
 part of the kernel version to mark ABI changes that aren't due to a new
 upstream version.  This part comes from the abiname setting
 in debian/config/defines.  We use either a number or 
'trunk'
-(for experimental), but for a custom package it should be some other string.
+(for experimental).
+
+
+If you are rebuilding the package with local modifications, you should
+change the ABI name to some other string, for example
+0.local.  Then run the command
+
+
+$ debian/rules debian/control-real
+
+
+to regenerate the package definitions for this ABI name.
 
 
 
@@ -109,7 +120,7 @@
 debian/config/defines.  Then run the command
 
 
-$ fakeroot debian/rules 
debian/control-real
+$ debian/rules debian/control-real
 
 
 to regenerate the package definitions for this ABI name.
diff -Nru kernel-handbook-1.0.20/debian/changelog 
kernel-handbook-1.0.21/debian/changelog
--- kernel-handbook-1.0.20/debian/changelog 2022-10-03 01:56:35.0 
+0200
+++ kernel-handbook-1.0.21/debian/changelog 2023-05-08 23:17:30.0 
+0200
@@ -1,3 +1,20 @@
+kernel-handbook (1.0.21) unstable; urgency=medium
+
+  * Try to reduce pain points in rebuilding official kernel packages
+(Closes: #1022061):
+- Reorder sections in "Common kernel-related tasks" to reduce confusion
+- Deprecate older versions of test-patches
+- Recommend changing ABI name before rebuilding
+- Add command to enable parallel builds when invoking make directly
+- Avoid using fakeroot
+  * Remove obsolete text referring to "patchlevels" in source packages
+  * Remove redundant "bash" from debian/bin/test-patches command lines
+  * Update instructions for disabling debug info (Closes: #1023773)
+  * Update instructions for building linux-headers-common package
+  * Update copyright years
+
+ -- Ben Hutchings   Mon, 08 May 2023 23:17:30 +0200
+
 kernel-handbook (1.0.20) unstable; urgency=medium
 
   [ Tomasz Warniełło ]
diff -Nru kernel-handbook-1.0.20/debian/copyright 
kernel-handbook-1.0.21/debian/copyright
--- kernel-handbook-1.0.20/debian/copyright 2022-07-18 16:08:26.0 
+0200
+++ kernel-handbook-1.0.21/debian/copyright 2023-05-08 23:17:14.0 
+0200
@@ -1,7 +1,7 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 
 Files: *
-Copyright: 2005-2018, 2020, 2022 Debian Kernel Handbook Project
+Copyright: 2005-2018, 2020, 2022-2023 Debian Kernel Handbook Project
 License: GPL-2+
  This package is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff -Nru kernel-handbook-1.0.20/kernel-handbook.dbk 
kernel-handbook-1.0.21/kernel-handbook.dbk
--- kernel-handbook-1.0.20/kernel-handbook.dbk  2022-07-18 16:08:22.0 
+0200
+++ kernel-handbook-1.0.21/kernel-handbook.dbk  2023-05-08 23:16:37.0 
+0200
@@ -21,7 +21,7 @@
 
 
 
-2005-2018, 2020, 2022Debian Kernel Handbook 
Project
+2005-2018, 2020, 2022-2023Debian Kernel 
Handbook Project
 
 
 This handbook is free software; you may redistribute it and/or modify it under
diff -Nru kernel-handbook-1.0.20/po4a/kernel-handbook.ja.po 
kernel-handbook-1.0.21/po4a/kernel-handbook.ja.po
--- kernel-handbook-1.0.20/po4a/kernel-handbook.ja.po   2022-10-03 
00:55:55.0 +0200
+++ kernel-handbook-1.0.21/po4a/kernel-handbook.ja.po   2023-05-08 
23:05:29.0 +0200
@@ -1704,8 +1704,8 @@
 #. type: Content of: 
 #: chapter-versions.dbk:112
 #, no-wrap
-msgid "$ fakeroot debian/rules 
debian/control-real\n"
-msgstr "$ fakeroot debian/rules 
debian/control-real\n"
+msgid "$ debian/rules 
debian/control-real\n"
+msgstr "$ debian/rules 
debian/control-real\n"
 
 #. type: Content of: 
 #: chapter-versions.dbk:115
@@ -1908,11 +1908,9 @@
 #. type: Content of: 

 #: chapter-common-tasks.dbk:34
 msgid ""
-"# apt-get install build-essential fakeroot"
+"# apt-get install build-essential"
 msgstr ""
-"# apt-get install build-essential fakeroot"
+"# apt-get install build-essential"
 
 #. type: Content of: 
 #: chapter-common-tasks.dbk:35 chapter-common-tasks.dbk:221
@@ -2023,10 +2021,10 @@
 #, no-wrap
 msgid ""
 "# apt-get install devscripts\n"
-"$ bash debian/bin/test-patches 
../fix-bug123456.patch ../add-foo-driver.patch\n"
+"$ debian/bin/test-patches ../fix-bug123456.patch 
../add-foo-driver.patch\n"
 msgstr ""
 "# apt-get install devscripts\n"
-"$ bash debian/bin/test-patches 
../fix-bug123456.patch ../add-foo-driver.patch\n"
+"$ debian/bin/test-patches ../fix-bug123456.patch 
../add-foo-driver.patch\n"
 
 #. type: Content of: 
 #: chapter-common-tasks.dbk:98
@@ -2040,8 +2038,8 @@
 #. type: Content of: 
 #: chapter-common-tasks.dbk:102
 #, no-wrap
-msgid "$ bash 
debian/bin/test-patches\n"
-msgstr &qu

Re: linux migration to testing

[Ben Hutchings]

On Mon, 2022-08-15 at 22:15 +0200, Paul Gevers wrote:
> Hi Ben,
> 
> On 01-08-2022 23:09, Ben Hutchings wrote:
> > On Mon, 2022-08-01 at 22:53 +0200, Paul Gevers wrote:
> > > On 01-08-2022 22:46, Ben Hutchings wrote:
> > > > Could you please allow this version to enter testing despite the test
> > > > failures?
> > > 
> > > If you promise to fix it in the next upload.
> > 
> > Yes, the fix is already in the git repo.
> 
> For your info, s390x still fails:
> https://ci.debian.net/data/autopkgtest/testing/s390x/l/linux/24628411/log.gz

Also for ppc64el.  These two are fixed by:
https://salsa.debian.org/kernel-team/linux/-/commit/8d439f0beb3f97ff0e11dae3d70da33597642f9f

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

Re: linux migration to testing

[Ben Hutchings]

On Mon, 2022-08-01 at 22:53 +0200, Paul Gevers wrote:
> Hi Ben,
> 
> On 01-08-2022 22:46, Ben Hutchings wrote:
> > linux 5.18.14-1 is currently blocked from migration due to a test
> > regression on some architectures.
> > 
> > This is actually not a regression: there's a new test case, and it was
> > defined wrongly for architectures other than amd64 and arm64.  That
> > should be fixed with the next upload, but I'd rather not go through
> > another build/sign/build/wait cycle.
> > 
> > Could you please allow this version to enter testing despite the test
> > failures?
> 
> If you promise to fix it in the next upload.

Yes, the fix is already in the git repo.

> hint added.

Thanks,

Ben.

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


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

linux migration to testing

[Ben Hutchings]

linux 5.18.14-1 is currently blocked from migration due to a test
regression on some architectures.

This is actually not a regression: there's a new test case, and it was
defined wrongly for architectures other than amd64 and arm64.  That
should be fixed with the next upload, but I'd rather not go through
another build/sign/build/wait cycle.

Could you please allow this version to enter testing despite the test
failures?

Ben.

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


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

FUSE 3 transition

[Ben Hutchings]

Bug #1014925 was reported because some tasks depend on fuse while other
packages that may be installed later (specifically open-vm-tools)
depend on fuse3.  While fuse3 provides fuse, the installer normally
doesn't install anything that would require removal of another package.

Given that some packages specifically depend on fuse3, while it also
provides fuse, all reverse-dependencies on either can be satisfied by
fuse3, so it seems like we should prefer installation of that.

- Is there a plan to change reverse-dependencies to depend on fuse3, so
that such conflicts don't occur?

- Alternately, would it be simpler to build the fuse binary package
from the fuse3 source package instead?  (I know that having source
package A build binary B, while B is the name of another source
package, can confuse both software and people.  Maybe the fuse source
package could be renamed to fuse2 at the same time.)

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of. 


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

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Sat, 2022-07-16 at 18:03 +0300, Adrian Bunk wrote:
> On Sat, Jul 16, 2022 at 03:54:21PM +0200, Ben Hutchings wrote:
> > On Sat, 2022-07-16 at 06:23 +0300, Adrian Bunk wrote:
> > > On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote:
> > ...
> > > This is not limited to i386, it is also quite relevant for embedded arm
> > > where new products using 32-bit cpus are still being developed today.
> > 
> > New products can build user-space with 64-bit time_t.  They don't have
> > Debian's ABI constraints.
> > ...
> 
> Many people want to use Debian in embedded, and there are people
> who would like to have a Debian release architecture that is armhf
> with 64-bit time_t.
> 
> Not sure whether anyone will actually do the effort, but this is the 
> most likely 32-bit release architecture we will still have after 2038.

That may yet happen.  Steve McIntyre started, but didn't have time to
complete it.  Maybe as the deadline gets closer there will be more
resources available for this. :-)

> > > > This is not to say that i386, or 32-bit architectures, should be
> > > > dropped as a whole.  We've supported installing a 64-bit kernel on i386
> > > > since etch, though it now requires adding amd64 as a foreign
> > > > architecture.  I do think that at some time soon we should stop
> > > > releasing kernel binaries or an installer for i386.
> > > 
> > > Speaking with my i386 porter head on, I would rather ask for moving i386 
> > > to ports than dropping all support for i386 hardware.
> > 
> > I think we have the following use cases for i386 now:
> > 
> > 1. PCs with 64-bit CPUs, with i386 as the primary Debian architecture.
> >This might be the result of keeping an i386 installation through
> >hardware upgrades.
> > 2. PCs with 64-bit CPUs, that need to run i386 binaries that can't be
> >rebuilt for amd64 (proprietary, or unportable).  They might have
> >either amd64 or i386 as the primary Debian architecture.
> > 3. PCs with 32-bit CPUs.
> > 
> > Moving i386 to ports would clearly serve use case 3 better than
> > dropping the kernel and installer.  Keeping i386 as a release
> > architecture, but without a kernel and installer, seems to serve use
> > cases 1 and 2 better.
> > 
> > What's not clear is how many users fall into each of these use cases.
> > ...
> 
> What problem is building i386 bookworm kernel binaries causing for you 
> that are not present on other architectures like armhf or s390x?

Good question.  I think the problem is that those i386 binaries will
mostly work on 64-bit PCs and users will wrongly expect that they are
fully supported.  But various features aren't implemented (in the
kernel) or aren't available (architecturally) to a 32-bit kernel on a
64-bit CPU.

I suppose this can be mostly dealt with by sticking warnings around the
place:

- Installation manual for i386
- Release notes for i386
- Package installation (debconf)
- Kernel boot (log and taint flag)

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


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

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Sat, 2022-07-16 at 11:20 -0400, Timothy M Butterworth wrote:
[...]
> i386 is anchient in tech terms it was introduced in 1985. If debian wants
> to keep supporting 32 bit OS then it should bump up to i686.
[...]

We did that years ago.  We just didn't rename the architecture.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Sat, 2022-07-16 at 06:23 +0300, Adrian Bunk wrote:
> On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote:
> > 
> > For i386, I have some concerns about upstream support of the Linux
> > kernel.  CPU security mitigations for x86 are concentrated on amd64,
> > with i386 being left behind.  Mitigation of Meltdown required a
> > different implementation for i386 that was completed months after the
> > public disclosure and was never backported to stable branches.  More
> > recently it became clear that mitigation of RETbleed was never tested
> > on i386, since it didn't even compile there.
> 
> What is the status of RETbleed mitigation on other architectures like arm64?

Not known to be vulnerable.

> > More generally, on 32-bit systems Linux can only directly access about
> > 1 GiB of RAM, and support for large amounts of additional RAM (highmem)
> > has been steadily regressing.  This is not likely to be fixed.
> 
> Support for 32-bit systems is slowly crumbling away, and the effort that 
> would be required for the year 2038 problem will likely kill most/all of
> them in a few years.

That's also true.

> The relevant question is rather whether a point is already reached right 
> now where we can no longer support an architecture as release architecture.
> 
> This is not limited to i386, it is also quite relevant for embedded arm
> where new products using 32-bit cpus are still being developed today.

New products can build user-space with 64-bit time_t.  They don't have
Debian's ABI constraints.

> > This is not to say that i386, or 32-bit architectures, should be
> > dropped as a whole.  We've supported installing a 64-bit kernel on i386
> > since etch, though it now requires adding amd64 as a foreign
> > architecture.  I do think that at some time soon we should stop
> > releasing kernel binaries or an installer for i386.
> 
> Speaking with my i386 porter head on, I would rather ask for moving i386 
> to ports than dropping all support for i386 hardware.

I think we have the following use cases for i386 now:

1. PCs with 64-bit CPUs, with i386 as the primary Debian architecture.
   This might be the result of keeping an i386 installation through
   hardware upgrades.
2. PCs with 64-bit CPUs, that need to run i386 binaries that can't be
   rebuilt for amd64 (proprietary, or unportable).  They might have
   either amd64 or i386 as the primary Debian architecture.
3. PCs with 32-bit CPUs.

Moving i386 to ports would clearly serve use case 3 better than
dropping the kernel and installer.  Keeping i386 as a release
architecture, but without a kernel and installer, seems to serve use
cases 1 and 2 better.

What's not clear is how many users fall into each of these use cases.

> > (If we don't make that change for bookworm, then we should probably
> > strongly encourage users to use 64-bit kernels on 64-bit capable
> > hardware, and document how to install a foreign kernel package.)
> 
> Such users should also migrate to 64-bit userspace.

Generally, yes.  But this is an easier step than "you need to
reinstall" or "try crossgrading, it may or may not break your system
completely".

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Wed, 2022-06-22 at 10:05 +0200, Graham Inggs wrote:
> Hi,
> 
> As part of the interim architecture qualification for bookworm, we
> request that DSA, the security team, Wanna build, and the toolchain
> maintainers review and update their list of known concerns for bookworm
> release architectures.
> 
> If the issues and concerns from you or your team are not up to date,
> then please follow up to this email (keeping debian-release@l.d.o in CC
> to ensure we are notified).
> 
> In particular, we would like to hear any new concerns for riscv64
> (see below).
> 
> Whilst porters remain ultimately responsible for ensuring the
> architectures are ready for release, we do expect that you / your team
> are willing to assist with clarifications of the concerns and to apply
> patches/changes in a timely manner to resolve the concerns.
[...]

For i386, I have some concerns about upstream support of the Linux
kernel.  CPU security mitigations for x86 are concentrated on amd64,
with i386 being left behind.  Mitigation of Meltdown required a
different implementation for i386 that was completed months after the
public disclosure and was never backported to stable branches.  More
recently it became clear that mitigation of RETbleed was never tested
on i386, since it didn't even compile there.

More generally, on 32-bit systems Linux can only directly access about
1 GiB of RAM, and support for large amounts of additional RAM (highmem)
has been steadily regressing.  This is not likely to be fixed.

This is not to say that i386, or 32-bit architectures, should be
dropped as a whole.  We've supported installing a 64-bit kernel on i386
since etch, though it now requires adding amd64 as a foreign
architecture.  I do think that at some time soon we should stop
releasing kernel binaries or an installer for i386.

(If we don't make that change for bookworm, then we should probably
strongly encourage users to use 64-bit kernels on 64-bit capable
hardware, and document how to install a foreign kernel package.)

Ben.


-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#1014079: bullseye-pu: package wireless-regdb/2022.04.08-2~deb11u1

[Ben Hutchings]

 channels 1-6 EIRP=40dBm(43dBm peak)
diff -Nru wireless-regdb-2020.04.29/debian/changelog 
wireless-regdb-2022.04.08/debian/changelog
--- wireless-regdb-2020.04.29/debian/changelog  2020-06-30 19:34:44.0 
+0200
+++ wireless-regdb-2022.04.08/debian/changelog  2022-06-30 01:13:22.0 
+0200
@@ -1,3 +1,54 @@
+wireless-regdb (2022.04.08-2~deb11u1) bullseye; urgency=medium
+
+  * Backport to bullseye:
+- Revert "Remove support for loading through crda"
+- Add my signature for regulatory.bin
+- d/salsa-ci.yml: Set RELEASE to bullseye
+  * d/tests/check-signatures: Fix typo in openssl command line
+
+ -- Ben Hutchings   Thu, 30 Jun 2022 01:13:22 +0200
+
+wireless-regdb (2022.04.08-2) unstable; urgency=medium
+
+  * debian/tests: Add check that regulatory.db signatures are valid
+  * d/wireless-regdb.postinst: Remove regular files installed by d-i
+(Closes: #1012601)
+
+ -- Ben Hutchings   Thu, 30 Jun 2022 00:01:25 +0200
+
+wireless-regdb (2022.04.08-1) unstable; urgency=medium
+
+  * New upstream version:
+- Raise DFS TX power limit to 250 mW (24 dBm) for the US
+- Update regulatory rules for Croatia (HR) on 6GHz
+- Update regulatory rules for France (FR) on 6 and 60 GHz
+- add support for US S1G channels
+- add 802.11ah bands to world regulatory domain
+- Update regulatory rules for Spain (ES) on 6GHz
+- Update regulatory rules for South Korea (KR)
+- Update regulatory rules for China (CN) (Closes: #1006127)
+- Update regulatory rules for the Netherlands (NL) on 6GHz
+- Update regulatory rules for Israel (IL)
+- Update regulatory rules for Australia (AU)
+  * d/salsa-ci.yml: Add CI configuration for salsa.debian.org
+  * Remove support for loading through crda (Closes: #973551, #1004347)
+  * d/.gitignore: Ignore another debhelper temporary file
+
+ -- Ben Hutchings   Sat, 04 Jun 2022 23:59:01 +0100
+
+wireless-regdb (2021.08.28-1) unstable; urgency=medium
+
+  * New upstream version (Closes: #986208):
+- Update regulatory rules for Egypt (EG), Croatia (HR), Pakistan (PK)
+  on 5GHz, Great Britain (GB), Kazakhstan (KZ), Ukraine (UA), Cuba (CU)
+  on 5Ghz, Germany (DE) on 6GHz, Norway (NO) on 6 and 60 GHz, Ecuador (EC)
+- US: restore channel 12 & 13 limitation
+- US: remove PTMP-ONLY from 5850-5895 MHz
+- US: reduce bandwidth for 5730-5850 and 5850-5895 MHz
+- ES: Update CNAF regulation url
+
+ -- Romain Perier   Fri, 17 Sep 2021 18:30:37 +0200
+
 wireless-regdb (2020.04.29-2) unstable; urgency=medium
 
   * Re-upload without binary packages (SourceOnlyUpload)
Binary files 
/var/tmp/q2x0yR97II/wireless-regdb-2020.04.29/debian/regulatory.bin.sig and 
/var/tmp/t5Nn_4OFYr/wireless-regdb-2022.04.08/debian/regulatory.bin.sig differ
Binary files 
/var/tmp/q2x0yR97II/wireless-regdb-2020.04.29/debian/regulatory.db.p7s and 
/var/tmp/t5Nn_4OFYr/wireless-regdb-2022.04.08/debian/regulatory.db.p7s differ
diff -Nru wireless-regdb-2020.04.29/debian/salsa-ci.yml 
wireless-regdb-2022.04.08/debian/salsa-ci.yml
--- wireless-regdb-2020.04.29/debian/salsa-ci.yml   1970-01-01 
01:00:00.0 +0100
+++ wireless-regdb-2022.04.08/debian/salsa-ci.yml   2022-06-30 
00:53:42.0 +0200
@@ -0,0 +1,13 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'bullseye'
+  # We only build arch:all packages
+  SALSA_CI_DISABLE_BLHC: 'true'
+  SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 'true'
+  SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 'true'
+  SALSA_CI_DISABLE_CROSSBUILD_ARM64: 'true'
+  # Currently triggering falsely (bug #973313)
+  SALSA_CI_LINTIAN_SUPPRESS_TAGS: 'groff-message'
diff -Nru wireless-regdb-2020.04.29/debian/tests/check-signatures 
wireless-regdb-2022.04.08/debian/tests/check-signatures
--- wireless-regdb-2020.04.29/debian/tests/check-signatures 1970-01-01 
01:00:00.0 +0100
+++ wireless-regdb-2022.04.08/debian/tests/check-signatures 2022-06-30 
01:03:12.0 +0200
@@ -0,0 +1,136 @@
+#!/usr/bin/python3
+
+# Check that signatures on regulatory.db are valid and made by keys
+# trusted by the current kernel in the target suite
+
+import glob
+import io
+import os
+import os.path
+import re
+import subprocess
+import sys
+
+
+tmp_dir = os.getenv('AUTOPKGTEST_TMP')
+
+
+# Find current major/minor kernel version
+def get_linux_source_name():
+proc = subprocess.Popen(['dpkg', '-s', 'linux-source'],
+stdout=subprocess.PIPE)
+with io.open(proc.stdout.fileno(), encoding='utf-8') as pipe:
+for line in pipe:
+match = re.match(r'^Depends:.*\b(linux-source-[0-9.]*)\b', line)
+if match:
+return match.group(1)
+return None
+
+
+# Extract wireless regdb certificate sources
+def extract_certs_source(source_name):
+certs_subdir = f'{source_name}/net/wireless/certs'
+subpro

Re: Bug#989863: debian-installer: Firmware problems in bullseye

[Ben Hutchings]

On Sat, 2021-07-24 at 10:27 +0100, Simon McVittie wrote:
> On Sat, 24 Jul 2021 at 09:05:59 +0200, Cyril Brulebois wrote:
> > If we were to go the “(almost) all in” route, it might make sense to
> > either blacklist (some of) those, or to whitelist the known-ok ones,
> > which would require some monitoring of new additions over time (which
> > dillon, behind d-i.debian.org, could help us with).
> 
> As an 80% solution, would it be feasible to have the officially-unofficial
> media with firmware install the firmware-linux metapackage by default,
> or at least install it if a desktop task was chosen?
> 
> firmware-linux pulls in firmware-amd-graphics and firmware-misc-nonfree
> (which has the Nvidia firmware), and I think its rules for inclusion
> imply not needing an EULA or other special license-acceptance by the
> user.
[...]

Yes - nothing requiring a EULA should be accepted into the upstream
repository, and if it happens anyway we would put those files in a
separate binary package.

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#989509: buster-pu: package klibc/2.0.6-1+deb10u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-ker...@lists.debian.org, mirabilos 

[ Reason ]
There are open security issues that were triaged as no-dsa by the
security team.  These affect the heap functions (malloc and calloc)
and the cpio utility.

setjmp and longjmp are implemented incorrectly on s390x.

[ Impact ]
Some programs built using klibc may have potential heap overflows
that can be exploited for privilege escalation.

On s390x, programs using setjmp and longjmp may misbehave in
unpredictable ways.

[ Tests ]
malloc, calloc, setjmp, and longjmp are exercised by the test suite
that runs during build.  However the setjmp/longjmp test was not
sufficient to detect the bug.

Thorsten Glaser tested the s390x fix in unstable.  It has not (yet)
been manually tested in this version.

I have tested the cpio utility manually.

[ Risks ]
The changes are localised and seem comparatively low-risk to me.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
All but one of the patches fixes a single bug or CVE as detailed in
its patch header.

The patch "malloc: Set errno on failure" is applied as a dependency
of "malloc: Fail if requested size > PTRDIFF_MAX".

[ Other info ]
diff -Nru klibc-2.0.6/debian/changelog klibc-2.0.6/debian/changelog
--- klibc-2.0.6/debian/changelog2019-02-01 06:00:57.0 +0100
+++ klibc-2.0.6/debian/changelog2021-06-05 20:20:42.0 +0200
@@ -1,3 +1,19 @@
+klibc (2.0.6-1+deb10u1) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * Apply security fixes from 2.0.9 (Closes: #989505):
+- malloc: Set errno on failure
+- malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
+- calloc: Fail if multiplication overflows (CVE-2021-31870)
+- cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
+- cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
+
+  [ Thorsten Glaser ]
+  * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Ben Hutchings   Sat, 05 Jun 2021 20:20:42 +0200
+
 klibc (2.0.6-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch
--- klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
1970-01-01 01:00:00.0 +0100
+++ klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
2021-04-30 04:30:16.0 +0200
@@ -0,0 +1,32 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 03:57:39 +0200
+Subject: [klibc] malloc: Set errno on failure
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=7f6626d12daa2f1efd9953d1f4ba2065348dc5cd
+
+malloc() is specified to set errno = ENOMEM on failure, so do that.
+
+Signed-off-by: Ben Hutchings 
+---
+ usr/klibc/malloc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/usr/klibc/malloc.c b/usr/klibc/malloc.c
+index 413b7337..bb57c9f6 100644
+--- a/usr/klibc/malloc.c
 b/usr/klibc/malloc.c
+@@ -8,6 +8,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "malloc.h"
+ 
+ /* Both the arena list and the free memory list are double linked
+@@ -169,6 +170,7 @@ void *malloc(size_t size)
+ #endif
+ 
+   if (fp == (struct free_arena_header *)MAP_FAILED) {
++  errno = ENOMEM;
+   return NULL;/* Failed to get a block */
+   }
+ 
diff -Nru 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
--- 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   2021-04-30 04:30:16.00000 +0200
@@ -0,0 +1,41 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 04:03:49 +0200
+Subject: [klibc] malloc: Fail if requested size > PTRDIFF_MAX
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=a31ae8c508fc8d1bca4f57e9f9f88127572d5202
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-31873
+
+malloc() adds some overhead to the requested size, which may result in
+an integer overflow and subsequent buffer overflow if it is close to
+SIZE_MAX.  It should fail if size is large enough for this to happen.
+
+Further, it's not legal for a C object to be larger than
+PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could
+overflow.  So return failure immediately if size is greater than that.
+
+CVE-202

Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1

[Ben Hutchings]

On Thu, 2021-05-27 at 10:50 +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On 17-05-2021 02:12, Ben Hutchings wrote:
> > Please unblock package broadcom-sta
> > 
> > [ Reason ]
> > Fix the unusable broadcom-sta-source package.
> > 
> > [ Impact ]
> > It is not possible to build a package using module-assistant and the
> > version of broadcom-sta-source in bullseye.  However, dkms and
> > broadcom-sta-dkms can be used as an alternative.
> > 
> > [ Tests ]
> > Only the build processes are being changed.  I tested that:
> > - broadcom-sta can be built from source
> > - module-assistant can build a module package from broadcom-sta-source
> >   for the current kernel version in bullseye (5.10.0-6-amd64)
> > - the resulting binary module package looks like a module package
> >   built from broadcom-sta-source in buster, modulo version changes
> 
> * I wonder, broadcom-sta has seen quite some uploads the last couple of
> years and debhelper is even in oldstable newer than the version
> mentioned. How were all these uploads possible?

broadcom-sta has always properly declared its debhelper compatibility
level.  Earlier it was done through debian/compat, then since version
6.30.223.271-13~exp1 through a versioned B-D on debhelper-compat.

module-assistant creates a source and binary packages for modules using
a template that's included in packages such as broadcom-sta-source. 
That template was not updated along with broadcom-sta itself, so was
missing a debhelper compatibility level since version
6.30.223.271-13~exp1.

This probably wasn't noticed because DKMS is now more popular than
module-assistant.

> * What is/was the behavior of debhelper if the compat level was not
> specified? In the freeze we don't want debhelper compat bumps unless the
> package is proven to have no delta regardless of the old-vs-new level.

It's a fatal error.

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#988627: unblock: broadcom-sta/6.30.223.271-16.1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: bl...@debian.org, clac...@easter-eggs.com, r...@debian.org

Please unblock package broadcom-sta

[ Reason ]
Fix the unusable broadcom-sta-source package.

[ Impact ]
It is not possible to build a package using module-assistant and the
version of broadcom-sta-source in bullseye.  However, dkms and
broadcom-sta-dkms can be used as an alternative.

[ Tests ]
Only the build processes are being changed.  I tested that:
- broadcom-sta can be built from source
- module-assistant can build a module package from broadcom-sta-source
  for the current kernel version in bullseye (5.10.0-6-amd64)
- the resulting binary module package looks like a module package
  built from broadcom-sta-source in buster, modulo version changes

[ Risks ]
This seems like a low-risk change.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

unblock broadcom-sta/6.30.223.271-16.1
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

Bug#987808: unblock: klibc/2.0.8-6

[Ben Hutchings]

On Sat, 2021-05-01 at 21:46 +0200, Paul Gevers wrote:
> Hi,
> 
> On 30-04-2021 04:24, Ben Hutchings wrote:
> > Please unblock package klibc
> 
> unblocked.
> 
> Paul
> 
> PS: 0001-klibc-signal-Note-another-reason-to-define-_KLIBC_NE.patch
> looked a bit overdone for the freeze, but alas.

Sorry about that.  This was a result of my uploading the signal fixes
to experimental originally and failing to do an unstable upload until
now.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.


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

Bug#987808: unblock: klibc/2.0.8-6

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-ker...@lists.debian.org

Please unblock package klibc

[ Reason ]
Fix some possible integer overflows in the heap manager and the cpio
command.  These are probably not too serious considering how klibc is
normally used in Debian, but should still be fixed.

On s390x (plus some non-release architectures), remove the need for
programs to run with an executable stack.  This is a security
mitigation.

[ Impact ]
Close some possible security vulnerabilities.

[ Tests ]
The heap manager and signal handling are covered by automated tests
that run on every package build.

I have tested the changes to the cpio command manually.

[ Risks ]
klibc is used in the initramfs on most Debian systems that need one.
Regressions could result in boot failure.  However, I believe these
changes are adequately covered by tests.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

unblock klibc/2.0.8-6
diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2020-08-21 02:34:13.0 +0200
+++ klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
@@ -1,3 +1,46 @@
+klibc (2.0.8-6) unstable; urgency=medium
+
+  * Upload to unstable
+  * malloc: Set errno on failure
+  * malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
+  * calloc: Fail if multiplication overflows (CVE-2021-31870)
+  * cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
+  * cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
+
+ -- Ben Hutchings   Fri, 30 Apr 2021 03:05:23 +0200
+
+klibc (2.0.8-5) experimental; urgency=medium
+
+  * alpha: Fix definitions of _NSIG and struct sigaction
+  * ia64: Fix definition of struct sigaction
+
+ -- Ben Hutchings   Fri, 28 Aug 2020 17:41:47 +0100
+
+klibc (2.0.8-4) experimental; urgency=medium
+
+  * signal: Note another reason to define _KLIBC_NEEDS_SA_RESTORER
+  * signal: Add sysconfig setting to force SA_SIGINFO on
+  * s390: Force SA_SIGINFO on and use rt_sigreturn
+  * alpha: Force SA_SIGINFO on
+  * sparc: Force SA_SIGINFO on
+
+ -- Ben Hutchings   Tue, 25 Aug 2020 01:49:14 +0100
+
+klibc (2.0.8-3) experimental; urgency=medium
+
+  * s390: Define __sigreturn() on both s390 and s390x
+  * Revert "alpha: Set sa_restorer for signals and disable executable stack"
+  * alpha: Pass restorer to rt_sigaction() and disable executable stack
+
+ -- Ben Hutchings   Sun, 23 Aug 2020 15:24:00 +0100
+
+klibc (2.0.8-2) experimental; urgency=medium
+
+  * {alpha,s390,sparc}: Set sa_restorer for signals and disable executable
+stack
+
+ -- Ben Hutchings   Sat, 22 Aug 2020 21:35:52 +0100
+
 klibc (2.0.8-1) unstable; urgency=medium
 
   [ Ben Hutchings ]
diff -Nru 
klibc-2.0.8/debian/patches/0001-klibc-alpha-Fix-definitions-of-_NSIG-and-struct-siga.patch
 
klibc-2.0.8/debian/patches/0001-klibc-alpha-Fix-definitions-of-_NSIG-and-struct-siga.patch
--- 
klibc-2.0.8/debian/patches/0001-klibc-alpha-Fix-definitions-of-_NSIG-and-struct-siga.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0001-klibc-alpha-Fix-definitions-of-_NSIG-and-struct-siga.patch
  2021-04-30 02:55:10.0 +0200
@@ -0,0 +1,103 @@
+From: Ben Hutchings 
+Date: Thu, 27 Aug 2020 01:58:19 +0100
+Subject: [klibc] alpha: Fix definitions of _NSIG and struct sigaction
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=1cd11aaed1dece773c6b1ce2e99a0fe98b51321e
+
+We use the RT signals API, but include the kernel UAPI header
+that defines _NSIG and struct sigaction for the old API.
+
+Copy over all the definitions and fix those two.
+
+Signed-off-by: Ben Hutchings 
+---
+ usr/include/arch/alpha/klibc/archsignal.h | 78 ++-
+ 1 file changed, 76 insertions(+), 2 deletions(-)
+
+diff --git a/usr/include/arch/alpha/klibc/archsignal.h 
b/usr/include/arch/alpha/klibc/archsignal.h
+index 2193a352..78be832a 100644
+--- a/usr/include/arch/alpha/klibc/archsignal.h
 b/usr/include/arch/alpha/klibc/archsignal.h
+@@ -8,7 +8,81 @@
+ #ifndef _KLIBC_ARCHSIGNAL_H
+ #define _KLIBC_ARCHSIGNAL_H
+ 
+-#include 
+-/* No special stuff for this architecture */
++/*
++ * This is identical to , *except* for _NSIG and struct
++ * sigaction, where it has the old definition and we need the new (RT)
++ * definition.
++ */
++
++struct siginfo;
++
++#define NSIG  64
++
++typedef unsigned long sigset_t;
++
++#define SIGHUP 1
++#define SIGINT 2
++#define SIGQUIT3
++#define SIGILL 4
++#define SIGTRAP5
++#define SIGABRT6
++#define SIGEMT 7
++#define SIGFPE 8
++#define SIGKILL  

Re: Release status of i386 for Bullseye and long term support for 3 years?

[Ben Hutchings]

On Sun, 2020-12-13 at 01:53 -0800, Steve Langasek wrote:
[...]
> While the ongoing
> costs of maintaining a full port were a consideration, of equal concern was
> the fact that we believed we would not be able to provide security support
> for the architecture as a whole at par with other architectures, due to,
> among other things, lack of adequate support from the upstream
> kernel/toolchain community.  I'm not sure if i386 has caught up and now has
> adequate mitigation for Spectre etc, but it definitely wasn't available on
> an equivalent timeline as amd64.

I agree that kernel security support for i386 is seriously lacking.

The Spectre mitigations were actually available for both x86
architectures at the same time, but the initial Meltdown mitigation was
amd64-specific and was not extended to i386 until Linux 4.19.  The
implementation used in stable kernel branches (KAISER) was sufficiently
different from that used upstream, that i386 support has not been added
to it.

As a result, stretch:i386 is still vulnerable when running the default
(4.9-based) kernel.

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#975269: buster-pu: package linux/TBD - arm64 stolen time support

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: no...@debian.org

There are two parts to the proposed changes:

1. Support in arm64 KVM code for reporting stolen time to guests.
2. Support in arm64 paravirtualised guest code for requesting stolen
   time from the hypervisor and reporting it to user-space.

I think part 1 is not suitable for a stable update, but part 2 might
be.

[ Reason ]

Noah Meyerhans wrote in bug #969443:
> When used in virtual machine environments, Linux on amd64 is able to report
> "steal time" to the guest.  This functionality has been supported by Linux
> on amd64 for years, but was only added to arm64 with Linux 5.5.
> 
> As Debian and arm64 are increasingly used in virtual environments, including
> cloud environments, the ability to report steal time is increasingly
> important for system monitoring and performance analysis.  Thus, I'd like to
> request that CPU steal time accounting support for arm64 be backported to
> buster, if possible.

[ Impact ]

Without this, it's difficult to determine when VM performance is being
affected by stolen time.

[ Tests ]

Noah has tested the changes (at least part 2) in an arm64 KVM
environment with steal time reporting, presumably AWS EC2.

[ Risks ]

There is a potential to regress VM host and/or guest support on arm64
and armhf, depending on which part(s) are applied.

[ Changes ]

1. * KVM: arm64: Document PV-time interface
   * KVM: arm/arm64: Factor out hypercall handling from PSCI
   * KVM: arm64: Implement PV_TIME_FEATURES call
   * KVM: Implement kvm_put_guest()
   * KVM: arm64: Support stolen time reporting via shared
   * KVM: Allow kvm_device_ops to be const
   * KVM: arm64: Provide VCPU attributes for stolen time
2. * arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
   * arm/arm64: Provide a wrapper for SMCCC 1.1 calls
   * arm/arm64: Make use of the SMCCC 1.1 wrapper
   * arm64: Retrieve stolen time as paravirtualized guest

The actual patches are visible at
.

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

Uploading linux (5.7.10-1)

[Ben Hutchings]

I intend to upload linux version 5.7.10-1 to unstable tomorrow, 26th
July.

There will be an ABI bump.

Aside from the upstream stable updates, the following changes are
pending:

  * Enable perf on riscv64.
  * drivers/net/ethernet/intel: Enable IGC as module (Closes: #965931)
  * [x86] ioperm: Fix io bitmap invalidation on Xen PV (CVE-2020-15852,
XSA-329)
  * certs: Rotate to use the Debian Secure Boot Signer 2020 certificate
  * perf cs-etm: Move definition of 'traceid_list' global variable from header
file (Closes: #957491)
  * usbip: tools: fix build error for multiple definition
  * libtraceevent: Fix build with binutils 2.35
  * [sh4] Add patch to implement __get_user_u64()

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

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Ben Hutchings]

I don't know if this should be a blocker, but the MIPS builders are
still extremely slow for kernel builds.  In the worst case (mipsel:
mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
than the next slowest group of builders (armhf: hasse, henze, holby).
This can be a problem for getting security updates out promptly.

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

Uploading linux (5.6.7-1)

[Ben Hutchings]

I intend to upload linux version 5.6.7-1 to unstable later today
(Wednesday).

This is a new upstream version and therefore involves an ABI bump.

The pending changes in the package are:

  * [armhf,arm64] lockdown: Update arm Secure Boot patch for 5.6
(fixes FTBFS)
  * Use debhelper compatibility level 12:
- Build-Depend on debhelper-compat and remove debian/compat
- hyperv-daemons: Use dh_installsystemd instead of
  dh_systemd_{enable,start}
- hyperv-daemons: Add "Pre-Depends: ${misc:Pre-Depends}"
  * debian/README.source: Refer to upload checklist in kernel-team.git
  * [armel] Disable NETLABEL, since SECURITY_SELINUX is also disabled
  * Drop linux-headers--all and linux-headers--all- packages,
which are no longer needed
  * linux-libc-dev: Drop "Provides: linux-kernel-headers" which is no longer
needed
  * [s390x] mm: fix page table upgrade vs 2ndary address mode accesses
(CVE-2020-11884)
  *  Rebased patch firmware-remove-redundant-log-messages-from-drivers.patch
 onto 5.6.7.
  * [arm64] Enable CRYPTO_DEV_SUN8I_CE (closes: #958037)
  * [arm64] Enable SUN8I_THERMAL
  * [arm64] Enable ARMADA_37XX_WATCHDOG as module
  * [arm64] Enable SENSORS_PWM_FAN as a module.
  * Enable CONFIG_NETLABEL (Closes: #958804)

Changes in the previous upload to experimental were:

  * [mips*] Revert "staging: octeon-usb: delete the octeon usb host controller
driver"
  * [mips*] Revert "staging: octeon: delete driver"
  * [powerpc*] i2c: Enable I2C_PARPORT instead of I2C_PARPORT_LIGHT
  * aufs: Update support patchset to aufs5.x-rcN 20200302; no functional
change
  * linux-signed-*: Build-Depend on kernel-wedge 2.102 for consistency
  * aufs: Update support patchset to aufs5.6 20200413; no functional change
  * [rt] Update to 5.6.4-rt3 and re-enable
  * Enable SENSORS_DRIVETEMP
  * [riscv64] Enable SOC_VIRT
  * [riscv64] Enable GPIOLIB, GPIO_SIFIVE, POWER_RESET, POWER_RESET_GPIO,
POWER_RESET_GPIO_RESTART, POWER_RESET_RESTART, CONFIG_PWM,
CONFIG_PWM_SIFIVE, CONFIG_SIFIVE_L2
  * linux-kbuild: Stop building conmakehash
  * linux-cpupower: Add libcap to Build-Depends and turbostat linker flags
  * [x86] Drop EFI cold boot mitigation patch in favor of upstream
  * [amd64] Update "x86: Make x32 syscall support conditional ..." for 5.6
  * [x86] udeb: Add crc32_pclmul to crc-modules
  * udeb: Add crc32_generic to crc-modules
  * lockdown: set default (with Secure Boot) to LOCKDOWN_INTEGRITY_MAX
(Closes: #956197)

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.




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

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Ben Hutchings]

On Sun, 2020-04-26 at 20:59 +0200, Aurelien Jarno wrote:
[...]
> Well I am not sure it can be handled at the glibc level:
> - It's not clear to me how to detect the kernel support O32_FP64. We
>   indeed have a check for the kernel version in the glibc preinst check
>   in order to make sure all the syscalls used by the glibc are
>   available. New syscalls are only added in major upstream kernel
>   versions, so it's just fine to check for a minimum version.
>   Now we are talking about a change that is introduced only in Debian
>   kernels in a minor stable version. It's not clear to me which version
>   to use in the preinst check given people can use backport kernels or
>   use their own kernel.

Yes, I see the problem.  I think the kernel ought to expose the
supported ABIs through /proc, but even if that was added upstream and
in Debian kernels it wouldn't help people using older custom kernels
that do have the option enabled.

You could do a .config check (looking in /boot/config-$(uname -r) and
/proc/config.gz) but not all custom kernels will expose their config
either way.

> - Not all binaries depends on glibc. go binaries for example do not
>   depends on glibc. It's not clear to me if they will also start using
>   the new FP ABI. If so I guess we need to add the same check in all
>   their preinst scripts.

Yes I did wonder about that after writing this.

Ben.

> So overall it looks like something to me that should go in the release
> notes instead, just like we do for an ISA level raise.
> 
> Aurelien
> 
-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1

[Ben Hutchings]

On Sun, 2020-04-26 at 16:48 +0200, Julien Cristau wrote:
> On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote:
> > I failed to update wireless-regdb for some time, as it needed some
> > significant work to prepare for the regulatory database being directly
> > loaded by the kernel (instead of by crda).  This was introduced in
> > Linux 4.15, but is currently disabled in all Debian suites.  It will
> > be enabled starting with 5.5.
> > 
> > The version now in unstable has:
> > 
> > 1. regulatory.bin: loadable by crda, trusted by Debian crda
> > 2. regulatory.db-debian, regulatory.db.p7s-debian:
> >loadable by kernel, trusted by future Debian kernels
> > 3. regulatory.db-upstream, regulatory.db.p7s-upstream:
> >loadable by kernel, trusted by upstream and future Debian kernels
> > 4. regulatory.db, regulatory.db.p7s: alternative links for either
> >(2) or (3)
> > 
> > So this should be backward-compatible with all supported Debian
> > releases, with one exception:
> > 
> > On a system that has a recent kernel and (3) from elsewhere, *and*
> > also a currently unused wireless-regdb package, upgrading
> > wireless-regdb will effectively replace (3) with (2), which is not
> > trusted by their kernel.  They will need to run update-alternatives to
> > fix this (this is documented in README.Debian).

I didn't actually test this, but I have now.  In fact, update-
alternatives will *not* replace /lib/firmware/regulatory.db but will
issue warnings.  Package installation still succeeds.

> Is this something that can be detected from e.g. maintainer scripts, to
> show some kind of hint to the affected user?

I think that the current upgrade behaviour is safe.  However I should
probably implement replacement with the "upstream" alternative in case
regulatory.db is already present.

> > The update for (1) definitely should be delivered to all suites, but
> > I'm undecided whether the other files should be included.  Please
> > advise what I should do.
> > 
> I guess our options for stable are:
> a. ship 1/2/3/4 in a point release
> b. ship an update for 1 in a point release, ship 1/2/3/4 in backports
> 
> For option b, can we reasonably have the backports kernel Break old
> wireless-regdb,

It already does, in the version that's in backports-NEW.

> to nudge apt into updating that to the backport too?  Or
> is that more likely to get wireless-regdb removed than anything else?

I don't know.  I have updated wireless-regdb in buster-backports, so
the recommended "apt install -t buster-backports linux-image-amd64"
will work.  But upgrades might not.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Uploading linux (5.5.17-1)

[Ben Hutchings]

I intend to upload linux to unstable tomorrow (14th April).

Aside from the upstream stable updates, the following changes are
pending:

  * Fix autopkgtest failure due to pycodestyle violation
  * [cloud] Re-enable kernel page merge functionality (Closes: #955366)
  * [cloud] Apply a number of additional optimizations (Closes: #947759)
- Statically link nvme and ext4 drivers with the kernel
- [amd64] Re-enable SCHED_MC_PRIO
- Switch to LZ4 for compression
- Disable a number of additional drivers unlikely to be found in
  cloud environments
  * drm: Disable DRM_LEGACY (DRI1)
  * WireGuard: Update for renaming of skb_reset_tc() to skb_reset_redirect()
  * Remove libbpf. (See: #948041)
  * Provide wireguard-modules as stop-gap for packages.
  * linux-cpupower: Add libcap to Build-Depends and turbostat linker flags

There will be an ABI bump.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.




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

Uploading linux (5.5.13-1)

[Ben Hutchings]

I intend to upload linux version 5.5.13-1 to unstable this weekend.

This is a new upstream version, which implies an ABI bump.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.




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

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Ben Hutchings]

This was discussed on IRC with Julien Cristau, but unfortunately I
didn't save a log.  The main points that came up were:

* Executables built for the O32 FP64 ABI require this kernel config
  change and older kernel versions will refuse to load them.  So the
  kernel needs to be upgraded before installing any binaries built
  for the new FP ABI.

* Normally the support for an additional ABI would be included in
  release N.0 and used in N+1.  Since this was not present in 10.0, it
  would be possible for users to start upgrading to bullseye while
  still running a kernel that does not support O32 FP64.  We need to
  prevent them getting a broken system.

* Julien proposed that libc6 would have a preinst check on the kernel
  when it is changed to use the new FP ABI.  Presumably all binaries
  built for the new FP ABI should also have a versioned dependency on
  at least this version of libc6.

So I don't see any reason not to update the kernel configuration
already, as it will remain compatible with the O32 FPXX binaries in
buster.  Only the user-space changes in unstable (libc6 and toolchain)
need to be carefully coordinated.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.




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

Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

I failed to update wireless-regdb for some time, as it needed some
significant work to prepare for the regulatory database being directly
loaded by the kernel (instead of by crda).  This was introduced in
Linux 4.15, but is currently disabled in all Debian suites.  It will
be enabled starting with 5.5.

The version now in unstable has:

1. regulatory.bin: loadable by crda, trusted by Debian crda
2. regulatory.db-debian, regulatory.db.p7s-debian:
   loadable by kernel, trusted by future Debian kernels
3. regulatory.db-upstream, regulatory.db.p7s-upstream:
   loadable by kernel, trusted by upstream and future Debian kernels
4. regulatory.db, regulatory.db.p7s: alternative links for either
   (2) or (3)

So this should be backward-compatible with all supported Debian
releases, with one exception:

On a system that has a recent kernel and (3) from elsewhere, *and*
also a currently unused wireless-regdb package, upgrading
wireless-regdb will effectively replace (3) with (2), which is not
trusted by their kernel.  They will need to run update-alternatives to
fix this (this is documented in README.Debian).

The update for (1) definitely should be delivered to all suites, but
I'm undecided whether the other files should be included.  Please
advise what I should do.

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.4.0-2-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

Uploading linux (5.4.6-1)

[Ben Hutchings]

I intend to upload linux version 5.4.6-1 to unstable tomorrow (Friday).
This is a new upstream version with a consequent ABI bump.

The pending package changes w.r.t. 5.3.15-1 are:

  * [armel/marvell] lockdown: Disable Lockdown as it now selects MODULE_SIG
  * [m68k] Enable CONFIG_PATA_BUDDHA as module
  * [armhf] Add support for STM32MP1 SoC
  * [arm64] Re-enable BT_HCIUART_{BCM,LL} (arm64 version of #906048).
  * [arm64,armhf] Enable CLK_RASPBERRYPI and RASPBERRYPI_CPUFREQ.
  * md: Enable MD_CLUSTER as module (Closes: #927026)
  * [armhf] regulator: Really enable REGULATOR_STM32_PWR
  * [armhf,arm64] platform/chrome: Change chromeos drivers back to modules
  * linux-image: bug: Update taint list and use upstream descriptions
  * btrfs,fanotify: Use TAINT_AUX instead of TAINT_USER for unsupported
features
  * Enable VIRTIO_FS and VIRTIO_PMEM (Closes: #945853)
  * verity: enable DM_VERITY_VERIFY_ROOTHASH_SIG
  * [amd64/cloud-amd64] tpm: Enable TPM drivers for Cloud (Closes: #946237)
  * [armel/rpi,armhf,arm64] Enable DEBUG_WX
  * [armhf,arm64] Fix critical trip point on RPI 3.
  * [rt] Update to 5.4.5-rt3 and re-enable
  * [mipsel,mips64el/loongson-3] Enable AMDGPU.
  * [mips*] switch to vmlinuz from vmlinux except octeon.
  * [mips*] enable CONFIG_MIPS_O32_FP64_SUPPORT.
  * [mips*] enable CONFIG_CPU_HAS_MSA except octeon.
  * [arm64] drivers/gpu/drm/sun4i: Enable DRM_SUN8I_MIXER as a module.
(Closes: #946510). Thanks to Andrei POPESCU.

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

Uploading linux (5.3.9-1)

[Ben Hutchings]

I intend to upload linux version 5.3.9-1 to unstable tomorrow
(Saturday).

The pending changes include:

  * Update to upstream version 5.3.9
  * debian/bin/gencontrol_signed.py: Fix code style error
  * Add maint scripts to meta-packages to convert doc directories to symlinks
(Closes: #942861)
  * debian/README.source: Document code signing and how to test it
  * debian/tests/control: Mark python test as superficial
  * [arm64] linux-headers: Disable check for a 32-bit compiler
(Closes: #943953)
  * crypto: Enable PKCS8_PRIVATE_KEY_PARSER as module (Closes: #924705)
  * [amd64/cloud-amd64] Re-enable RTC drivers. (closes: #931341)
  * [x86] Enable missing modules and setting: CONFIG_HUAWEI_WMI,
 CONFIG_I2C_MULTI_INSTANTIATE, CONFIG_INTEL_TURBO_MAX_3
  * [arm64] udeb: Add i2c-rk3x to i2c-modules
  * [arm64,armhf] udeb: Add rockchip-io-domain to kernel-image
  * drivers/net/ethernet/amazon: Backport driver fixes from v5.4-rc5

Building a new version will probably fix #942881 (invalid signed
module).

There will be an ABI bump.

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

Re: Debian Linux kernel uploads

[Ben Hutchings]

On Sun, 2019-10-20 at 13:58 +0200, Hector Oron wrote:
> Hello,
> 
>   I would like to support Debian Linux kernel team by doing kernel
> package uploads.
> 
>   Initially, I would like to attempt timely (weekly or bi-weekly, it
> has not been discussed yet) updates for Debian Linux kernel package in
> SID and see how that works.
> 
>   In anycase, I would like to give a heads-up to the kernel and
> release team that I shall becoming a linux package uploader. Note,
> this has been discussed and agreed with Ben Hutchings and he suggested
> to inform you.
> 
>   I'll follow up with linux_5.2.17-2 upload real soon now.

The 5.2 series is EOL, so please don't upload that version.  Salvatore
has already updated the sid branch to 5.3.7 and you should coordinate
with him who will upload.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.




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

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ben Hutchings]

On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> Hi Ben,
> 
> Sorry for not getting back to you about this earlier.
> 
> On 7/7/19 3:43 PM, Ben Hutchings wrote:
> > On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
> > [...]
> > > No binary maintainer uploads for bullseye
> > > =
> > > 
> > > The release of buster also means the bullseye release cycle is about to 
> > > begin.
> > >  From now on, we will no longer allow binaries uploaded by maintainers to
> > > migrate to testing. This means that you will need to do source-only 
> > > uploads if
> > > you want them to reach bullseye.
> > 
> > I support this move in principle, but:
> > 
> > >Q: I already did a binary upload, do I need to do a new (source-only) 
> > > upload?
> > >A: Yes (preferably with other changes, not just a version bump).
> > > 
> > >Q: I needed to do a binary upload because my upload went to the NEW 
> > > queue,
> > >   do I need to do a new (source-only) upload for it to reach bullseye?
> > >A: Yes. We also suggest going through NEW in experimental instead of 
> > > unstable
> > >   where possible, to avoid disruption in unstable.
> > [...]
> > 
> > This is not going to fly for src:linux.  We can't stage ABI bumps in
> > experimental as we typically have a different upstream versions in
> > unstable and experimental.  We even need to do ABI bumps in stable from
> > time to time.
> 
> We are aware that src:linux is a special case here. I added an exception 
> for the arch:all binaries from src:linux. When the next ABI bump in 
> unstable happens, feel free to let me know, so that I can check if it 
> works as expected.

linux version 5.2.17-1 was the first version that included an ABI bump
and did not have any regressions that blocked it from testing.  It has
transitioned to testing including the developer-built arch:all
packages, so I believe that this exception works.  Thank you!

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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

Testing migration of linux

[Ben Hutchings]

We now have a version of linux (5.2.9-2) that builds on all release
architectures and doesn't seem to cause build regressions for other
packages.  I think that this should migrate to testing soon, as the
version in testing is missing important security fixes.

I'm aware of autopkgtest regressions for two packages:

* cross-toolchain-base 36: This appears to be a bug in that version of
the package.  cross-toolchain-base version 39 seems to be compatible
with Linux 5.2 and would need to migrate at the same time.

* glibc 2.28-10: This is a minor regression in the kernel uAPI headers,
which could *possibly* lead to build failures if programs define
conflicting macros.  (I fixed the larger regression which did cause
build failures.)  glibc 2.29 as packaged in experimental will stop
using these uAPI headers.

The excuses file mentions "new bug" #934483, but that was a bug in
virtualbox-guest-dkms which has now been fixed.  virtualbox is not in
testing.

So these packages should migrate to testing together:

cross-toolchain-base 39
linux 5.2.9-2
linux-latest 106
linux-signed-amd64 5.2.9+2
linux-signed-arm64 5.2.9+2
linux-signed-i386 5.2.9+2

cross-toolchain-base seems to be dependent on these packages, which
also inter-depend on each other, so that they'll also need to migrate
at the same time:

binutils
gcc-8
gcc-9-cross-ports
gcc-defaults-ports

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.



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

Bug#935480: buster-pu: package initramfs-tools/0.133+deb10u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

* Fix a regression that leads to a 30 second delay at boot if certain
  types of swap device are used (#916696).

* Fix a confusing boot progress message on systems using plymouth in text
  mode, which is currently the default (#928736).

* Fix a regression that prevents building an initramfs on systems using
  fsprotect (#928689).

* Fix lsinitramfs and unmkinitramfs when using lz4 compression (#930366).

* Fix outdated text in the update-initramfs manual page (#930366).

* Fix warning when building an initramfs using bzip2 or lzma compression
  (#930754).

* Include drivers needed for booting on some Chromebook models.

Ben.

diff -Nru initramfs-tools-0.133/debian/changelog 
initramfs-tools-0.133+deb10u1/debian/changelog
--- initramfs-tools-0.133/debian/changelog  2019-02-06 20:13:59.0 
+
+++ initramfs-tools-0.133+deb10u1/debian/changelog  2019-08-23 
02:16:37.0 +0100
@@ -1,3 +1,30 @@
+initramfs-tools (0.133+deb10u1) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * [998371a] hooks/resume: Disable resume when there are no suitable swap
+devices. Thanks to Trek  (Closes: #916696)
+  * [d653197] hook-functions: Include all keyboard driver modules when
+MODULES=most. Thanks to Alper Nebi Yasak 
+  * [5681ccb] hook-functions: Include cros_ec_spi and SPI drivers when
+MODULES=most. Thanks to Alper Nebi Yasak 
+  * [8d62542] resume: Set plymouth status only if there is a suspend image
+(Closes: #928736)
+  * [073586a] hook-functions: Fix copy_file with target of "/bin"
+(Closes: #928689)
+  * [a78d9a5] unmkinitramfs: Work around lz4cat filename check.
+Thanks to Dimitri John Ledkov  (Closes: #930366)
+  * [48a35de] update-initramfs(8): Update description of "-k all" option
+
+  [ Alper Nebi Yasak ]
+  * [1abb6f6] hook-functions: Include extcon-usbc-cros-ec when MODULES=most
+  * [db6d4e2] hook-functions: Include extcon drivers when MODULES=dep
+
+  [ Uwe Kleine-König ]
+  * [360fb48] mkinitramfs: suppress warning when using bzip2 or lzma
+(Closes: #930754)
+
+ -- Ben Hutchings   Fri, 23 Aug 2019 02:16:37 +0100
+
 initramfs-tools (0.133) unstable; urgency=medium
 
   [ Ben Hutchings ]
diff -Nru initramfs-tools-0.133/hook-functions 
initramfs-tools-0.133+deb10u1/hook-functions
--- initramfs-tools-0.133/hook-functions2019-02-06 03:48:49.0 
+
+++ initramfs-tools-0.133+deb10u1/hook-functions2019-08-23 
02:11:27.0 +0100
@@ -124,15 +124,15 @@
 
[ -f "${src}" ] || return 2
 
+   if [ -d "${DESTDIR}/${target}" ]; then
+   target="${target}/${src##*/}"
+   fi
+
# Canonicalise usr-merged target directories
case "${target}" in
/bin/* | /lib* | /sbin/*) target="/usr${target}" ;;
esac
 
-   if [ -d "${DESTDIR}/${target}" ]; then
-   target="${target}/${src##*/}"
-   fi
-
# check if already copied
[ -e "${DESTDIR}/${target}" ] && return 1
 
@@ -449,7 +449,7 @@
fi
 
# sys walk some important device classes
-   for class in gpio phy regulator rtc; do
+   for class in extcon gpio phy regulator rtc; do
for device in "/sys/class/$class"/*; do
device="$(readlink -f "$device")" \
&& sys_walk_mod_add "$device"
@@ -538,15 +538,17 @@
copy_modules_dir kernel/drivers/usb/musb
copy_modules_dir kernel/drivers/usb/renesas_usbhs
# and any extcon drivers for USB
-   modules="$modules extcon-usb-gpio"
+   modules="$modules extcon-usb-gpio extcon-usbc-cros-ec"
# Add the axp20x_usb_power power supply driver,
# required to initialize the USB host controllers
# on a number of armhf systems
modules="$modules axp20x_usb_power"
 
-   # Include all HID drivers unless we're sure they
-   # don't support keyboards.  hid-*ff covers various
-   # game controllers with force feedback.
+   # Include all keyboard drivers and all HID drivers
+   # unless we're sure they don't support keyboards.
+   # hid-*ff covers various game controllers with
+   # force feedback.
+   copy_modules_dir kernel/drivers/input/keyboard
copy_modules_dir kernel/drivers/hid \
'hid-*ff.ko' hid-a4tech.ko hid-cypress.ko \
hid-dr.ko hid-elecom.ko hid

Bug#935479: buster-pu: package firmware-nonfree/20190114-2

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

* Fix a longstanding bug that affects use of plymouth on systems with
  AMD GPUs (#928510).  Depending on the order of package installation,
  the initramfs might include the graphics driver but not firmware,
  resulting in the driver loading but not working.  Since plymouth is
  now installed by default as part of the "desktop" task, this affects
  many users.

  The fix is to trigger an initramfs build on installation of
  firmware-amd-graphics, as was already done from most packages
  containing firmware that might be needed in the initramfs.

* When I reviewed which of the binary packages did this, I noticed
  that firmware-cavium and firmware-netronome should also do so in
  case they are used for net-booting.  I applied the same fix to them.

* Revert an update to the QCA9377 firmware which seems to be
  incompatible with older kernel versions (#919632), and add a new
  version with a different filename that is preferred by the driver
  in Linux 4.19 (#903437, #919632, #927917).

* Add several new firmware files requested by drivers in Linux 4.19
  (#919452, #928672).

Ben.

diff -Nru firmware-nonfree-20190114/debian/changelog 
firmware-nonfree-20190114/debian/changelog
--- firmware-nonfree-20190114/debian/changelog  2019-01-15 22:51:01.0 
+
+++ firmware-nonfree-20190114/debian/changelog  2019-08-23 02:04:48.0 
+0100
@@ -1,3 +1,25 @@
+firmware-nonfree (20190114-2) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * Update to linux-support 4.19.0-5
+  * amd-graphics: Trigger update-initramfs when installed (Closes: #928510)
+  * cavium, netronome: Trigger update-initramfs when installed
+  * atheros: Add Qualcomm Atheros QCA9377 rev 1.0 firmware version
+WLAN.TF.2.1-00021-QCARMSWP-1 (Closes: #903437, #919632, #927917)
+  * realtek: Add Realtek RTL8822CU Bluetooth firmware
+  * atheros: Revert change of QCA9377 rev 1.0 firmware in 20180518-1
+(Closes: #919632)
+
+  [ Raphaël Hertzog ]
+  * misc-nonfree: Add firmware for MediaTek MT76x0/MT76x2u wireless chips
+(Closes: #919452)
+  * misc-nonfree: Add firmware for MediaTek MT7622/MT7668 bluetooth chips
+
+  [ Romain Perier ]
+  * misc-nonfree: Add GV100 signed firmware (Closes: #928672)
+
+ -- Ben Hutchings   Fri, 23 Aug 2019 02:04:48 +0100
+
 firmware-nonfree (20190114-1) unstable; urgency=medium
 
   [ Romain Perier ]
diff -Nru firmware-nonfree-20190114/debian/config/amd-graphics/defines 
firmware-nonfree-20190114/debian/config/amd-graphics/defines
--- firmware-nonfree-20190114/debian/config/amd-graphics/defines
2019-01-15 22:37:03.0 +
+++ firmware-nonfree-20190114/debian/config/amd-graphics/defines
2019-07-28 19:45:53.0 +0100
@@ -529,6 +529,7 @@
  radeon/verde_rlc.bin
  radeon/VERDE_smc.bin
  radeon/verde_smc.bin
+support: initramfs-tools
 
 [amdgpu/banks_k_2_smc.bin_base]
 desc: "Banks" K-2 SMC microcode
Binary files 
/var/tmp/5WQFaKfizp/firmware-nonfree-20190114/debian/config/atheros/ath10k/QCA9377/hw1.0/firmware-5.bin
 and 
/var/tmp/GBKOxvr1XD/firmware-nonfree-20190114/debian/config/atheros/ath10k/QCA9377/hw1.0/firmware-5.bin
 differ
diff -Nru firmware-nonfree-20190114/debian/config/atheros/defines 
firmware-nonfree-20190114/debian/config/atheros/defines
--- firmware-nonfree-20190114/debian/config/atheros/defines 2019-01-15 
02:02:27.0 +
+++ firmware-nonfree-20190114/debian/config/atheros/defines 2019-07-28 
19:49:52.0 +0100
@@ -35,6 +35,7 @@
  ath10k/QCA9377/hw1.0/board.bin
  ath10k/QCA9377/hw1.0/board-2.bin
  ath10k/QCA9377/hw1.0/firmware-5.bin
+ ath10k/QCA9377/hw1.0/firmware-6.bin
  ath10k/QCA9887/hw1.0/board.bin
  ath10k/QCA9887/hw1.0/firmware-5.bin
  ath10k/QCA9888/hw2.0/board-2.bin
@@ -211,7 +212,11 @@
 
 [ath10k/QCA9377/hw1.0/firmware-5.bin_base]
 desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
-version: WLAN.TF.1.0-2-QCATFSWPZ-5
+version: WLAN.TF.1.0-00267-1
+
+[ath10k/QCA9377/hw1.0/firmware-6.bin_base]
+desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
+version: WLAN.TF.2.1-00021-QCARMSWP-1
 
 [ath10k/QCA9887/hw1.0/board.bin_base]
 desc: Qualcomm Atheros QCA9887 rev 1.0 board configuration
diff -Nru firmware-nonfree-20190114/debian/config/cavium/defines 
firmware-nonfree-20190114/debian/config/cavium/defines
--- firmware-nonfree-20190114/debian/config/cavium/defines  2019-01-15 
02:02:27.0 +
+++ firmware-nonfree-20190114/debian/config/cavium/defines  2019-07-28 
19:20:32.0 +0100
@@ -8,6 +8,7 @@
  liquidio/lio_410nv_nic.bin
 longdesc: Cavium crypto and Ethernet adapters supported by the nitrox and
  liquidio drivers
+support: initramfs-tools
 
 [cavium/cnn55xx_se.fw_base]
 desc: Cavium CNN55XX firmware
diff -Nru firmware-nonfree-20190114/debian/config/misc-nonfree/defines 
firmware-nonfree-20190114/debian/config/misc-nonfree/defines
--- firmware-nonfree-20190114/debian/config/

Re: process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)

[Ben Hutchings]

On Mon, 2019-08-05 at 19:25 +0100, Adam D. Barratt wrote:
> [CC += ftpmaster]
> 
> On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> > On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> > [...]
> > > We are aware that src:linux is a special case here. I added an
> > > exception for the arch:all binaries from src:linux. When the next
> > > ABI bump in unstable happens, feel free to let me know, so that I
> > > can check if it works as expected.
> > 
> > I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> > the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> > in the NEW queue.
> 
> That looks like a problem on the archive side. The dak log suggests an
> issue logging an issue with a .changes file:
> 
> 20190805181929|process-upload|dak|exception|Traceback (most recent call last):
> 20190805181929|process-upload|dak|exception|  File "/usr/local/bin/dak", line 
> 228, in main
> 20190805181929|process-upload|dak|exception|module.main()
> 20190805181929|process-upload|dak|exception|  File 
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
> 20190805181929|process-upload|dak|exception|process_changes(changes_files)
> 20190805181929|process-upload|dak|exception|  File 
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in 
> process_changes
> 20190805181929|process-upload|dak|exception|Logger.log([filename, "Error 
> while loading changes: {0}".format(e)])
> 20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec 
> can't encode character u'\ufffd' in position 223: ordinal not in range(128)

Thanks for that.  Both my uploads last week seem to have been processed
successfully, but neither of them built on all release architectures so
we haven't yet been able to see whether the special case works.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.




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

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ben Hutchings]

On Fri, 2019-08-09 at 00:28 +0200, Aurelien Jarno wrote:
> On 2019-08-08 22:23, Ben Hutchings wrote:
[...]
> > 1a. Require 32-bit build environments to be multiarch with the
> > related 64-bit architecture also enabled.
> 
> Indeed, but that looks like the first step. From there do you think
> a) the package is responsible for build-depending on the 64-bit
>toolchain and calling it with the right option to generate 32-bit
>binaries?
> or
> b) the build environment should be already configured to make the
>64-bit toolchain available transparently
> 
> I had option b) in mind, but option a) looks way easier to implement on
> the infrastructure side, although a bit less on the packaging side. It
> can also be a first step towards b).

Yes - if relatively few packages are hitting the limits, I think it
makes sense to implement (a) in the short term fix for them, then work
on (b) as the longer term solution.

> In that case we should also make
> sure that using a 64-bit compiler doesn't switch the package build
> system to a cross-compilation mode, where notably the testsuite is
> disabled.

Right.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.




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

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ben Hutchings]

On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
[...]
> 1) Build a 64-bit compiler targeting the 32-bit corresponding
>architecture and install it in the 32-bit chroot with the other
>64-bit dependencies. This is still a kind of cross-compiler, but the
>rest of the build is unchanged and the testsuite can be run. I guess
>it *might* be something acceptable. release-team, could you please
>confirm?
>
>In the past it would have been enough to "just" do that for GCC, but
>nowadays, it will also be needed for rustc, clang and many more. The
>clang case is interesting as it is already a cross-compiler
>supporting all the architectures, but it default to the native
>target. I wonder if we should make mandatory the "-target" option,
>just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
>Alternatively instead of creating new packages, we might just want
>to use the corresponding multiarch 64-bit package and use a wrapper
>to change the native target, ie passing -m32 to gcc or -target to
>clang.
[...]
> Any comments, ideas, or help here?
[...]

1a. Require 32-bit build environments to be multiarch with the
related 64-bit architecture also enabled.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
- Carolyn Scheppner




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

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ben Hutchings]

On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
[...]
> We are aware that src:linux is a special case here. I added an exception 
> for the arch:all binaries from src:linux. When the next ABI bump in 
> unstable happens, feel free to let me know, so that I can check if it 
> works as expected.

I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
the upload was acknowledged (11:40 UTC) but it hasn't yet showed up in
the NEW queue.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein




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

Re: Dropping Release and Release.gpg support from APT

[Ben Hutchings]

On Wed, 2019-07-10 at 10:17 +0200, Julian Andres Klode wrote:
> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > On 2019-07-10 10:04, Julian Andres Klode wrote:
> > > On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> > > > On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> > > > 
> > > > > Timeline suggestion
> > > > > ---
> > > > > now add a warning to apt 1.9.x for repositories w/o 
> > > > > InRelease, but Release{,.gpg}
> > > > > Aug/Sep turn the warning into an error, overridable with an 
> > > > > option (?)
> > > > > Q1 2020 remove the code
> > [...]
> > > We do need them to ship InRelease files. I just filed an issue for OBS
> > > to do that. Given how long we had InRelease file, and how confusing it
> > > is to not provide InRelease files (not to mention that it doubles the
> > > traffic for no-change cases), I'm surprised they aren't using InRelease
> > > files yet.
> > 
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
> 
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

I currently have "deb-src ... jessie main" in my sources.list so I can
fetch packages that (might) need a security update.

Obviously I build them in a jessie chroot, but it seems like overkill
to do that for the initial source download too.  And back when I was
doing triage for Debian LTS I wouldn't build at all - I would only look
at the source to see if a bug was present in the old version.

Ben.

> But yes, I think it would make sense to ship an InRelease file
> with 9.10 now that we are capable of having those.
> 
-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.




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

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ben Hutchings]

On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
[...]
> No binary maintainer uploads for bullseye
> =
> 
> The release of buster also means the bullseye release cycle is about to begin.
> From now on, we will no longer allow binaries uploaded by maintainers to
> migrate to testing. This means that you will need to do source-only uploads if
> you want them to reach bullseye.

I support this move in principle, but:

>   Q: I already did a binary upload, do I need to do a new (source-only) 
> upload?
>   A: Yes (preferably with other changes, not just a version bump).
> 
>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.
[...]

This is not going to fly for src:linux.  We can't stage ABI bumps in
experimental as we typically have a different upstream versions in
unstable and experimental.  We even need to do ABI bumps in stable from
time to time.

I think that the requirement to upload binary packages for binary-NEW
(but not source-NEW) needs to go.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.




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

Re: fixing debian-security-support upgrades from stretch (for good)

[Ben Hutchings]

On Mon, 2019-05-13 at 19:08 +, Holger Levsen wrote:
> reassign -1 base-files
> retitle -1 base-files: please add a break on d-s-s < 2019.04.25
> thanks
> 
> On Mon, May 13, 2019 at 01:00:14PM +0100, Ben Hutchings wrote:
> > On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> > > So I think this can only be fixed properly (=without asking people to
> > > upgrade to the latest stretch pointrelease but instead allowing upgrades
> > > to buster from *any* stretch pointrelease) by adding a "pre-depends:
> > > debian-security-support (>= 2019.04.25)" to base-files in buster.
> > This makes debian-security-support transitively essential, whereas it
> > used to be optional.
> 
> thanks, Ben.
> 
> > Is "Conflicts" not strong enough?
>  
> after re-reading
> https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
> and
> https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
> (policy 7.3 and 7.4) I now also think that a "Breaks:
> debian-security-support (>= 2019.04.25)" in src:base-files is in order.

After re-reading, I concur that "Breaks" should be sufficient.  But
please do test this!

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Re: fixing debian-security-support upgrades from stretch (for good)

[Ben Hutchings]

On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> [re-sent with debian-release list address corrected...]
> 
> 
> hi,
> 
> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
> 
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.
[...]

This makes debian-security-support transitively essential, whereas it
used to be optional.

Is "Conflicts" not strong enough?

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Uploading linux (4.19.37-1)

[Ben Hutchings]

I intend to upload linux to unstable on Friday or Saturday.

The pending changes include upstream stable updates with a large number
of fixes, and:

  * [powerpc*] vdso: Make vdso32 installation conditional in vdso_install
(Closes: #785065)
  * [armhf,arm64] Revert "net: stmmac: Send TSO packets always from Queue 0"
  * [armel/marvell] Disable HW_RANDOM as no HWRNG drivers are usable here
  * udeb: Add all HWRNG drivers to kernel-image (see #923675)
  * lockdown: Refer to Debian wiki until manual page exists
  * [powerpc,ppc64,ppc64el] linux-image: Recommend grub-ieee1275
  * [i386] Add grub-efi-ia32 as an alternate recommended bootloader
  * linux-source: Recommend bison and flex, always needed to build the kernel
  * [armel/marvell,sh4] linux-image: Recommend apparmor, like all other configs
  * udeb: Drop unused ntfs-modules packages
  * ntfs: Disable NTFS_FS due to lack of upstream security support
(CVE-2018-12929, CVE-2018-12930, CVE-2018-12931)
  * [x86] platform: Enable INTEL_ATOMISP2_PM as module
  * [armhf] Enable SND_SOC_SPDIF for Cubietruck (Closes: #884562)
  * libbpf-dev: generate pkg-config file for libbpf by backporting
libbpf-generate-pkg-config.patch from bpf-next.
  * Don't longer recommend irqbalance. (closes: #926967)
  * xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
(CVE-2015-8553)
  * [x86] Disable R3964 due to lack of security support
  * [mips] Fix indirect syscall tracing & seccomp filtering for big endian
MIPS64 kernels with 32-bit userland.
  * [rt] Update to 4.19.37-rt19

These changes only affect non-release architectures:

  * [riscv64] linux-image-dbg: Include vdso debug symbols
  * [ia64]
linux-image: Recommend grub-efi-ia64 instead of (removed)
elilo
  *
[sparc64] linux-image: Recommend grub-ieee1275 instead of (removed)
   
silo
  * [sparc64] linux-image: Install uncompressed kernel image
  *
[mips*r6] Re-enable CONFIG_JUMP_LABEL, which has been fixed in
   
upstream.

There will be an ABI bump.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Dropping the ntfs kernel module

[Ben Hutchings]

Linux's ntfs kernel module, supporting Windows's native filesystem, has
three security issues open against it (CVE-2018-12929, CVE-2018-12930,
CVE-2018-12931) and there is no sign of progress towards fixing them
upstream.

This module is limited to read-only functionality by default; its write
support only covers overwriting existing files and has been disabled in
Debian kernel configurations since stretch.  The alternative FUSE-based 
implementation, ntfs-3g, is far more functional, though it may have
lower performance.  It is already used in the installer and included in
all the desktop tasks (unless installation of Recommends is disabled).

I intend to disable building this module in the next upload to sid,
targetting buster.

I think we should also disable building it in updates to jessie and
stretch, but would like to get an OK from the Stable Release Managers
before doing that.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.



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

Re: Please verify that buster related suites are functional

[Ben Hutchings]

On Sun, 2019-04-14 at 21:02 +, Niels Thykier wrote:
> Hi Security team and backports team,
> 
> According to the release team's checklist we have the following TODO for
> you:
> 
> """
> Check with security team and backports team that it is possible to build
> uploads for -security and -backports
> """
> 
> To our knowledge, the relevant suites have already been created
> (#917537) and ask that you kindly smoke test them to ensure they work as
> intended.
> 
>  * Please let us know when you have verified these relevant suites or if
>you have any issues with them.

We need to know that the signing service can also handle uploads to
buster-security, i.e. it can download embargoed binaries and then make
source uploads to the same suite.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.




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

Bug#925482: stretch-pu: package firmware-nonfree/20161130-5

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

This update fixes CVE-2018-5383 in firmware for some Bluetooth
adapters.  The security team already triaged this as not requiring a
DSA.

Ben.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 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

Bug#925441: unblock: linux/4.19.28-2

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package linux

* Upstream stable fixes for security, stability, and regressions
* Various other important fixes
* Enable additional hardware support
* Make more drivers available for use in the installer
* Enable RANDOM_TRUST_CPU to improve entropy availability
* Update trusted certificates and signing metadata to work with
  production signing service
* Fixes for build profiles and cross-builds
* [x86] Disable a.out support as it's obsolete and a security liability
* [x86] Drop fix for #865303, which no longer affects Debian's OpenJDK
* [ppc64el] Disable PCMCIA, as it was never available on this platform

The diff is too big to include, sorry.

unblock linux/4.19.28-2

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 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

Uploading linux (4.19.28-1)

[Ben Hutchings]

I intend to upload linux to unstable later today.

The pending changes include upstream stable updates with a large number
of fixes, fixes for the previous version's build failure on several
architectures, and:

  * [powerpc*] udeb: Add i2c-modules, mmc-core-modules, nic-wireless-modules
  * [arm64,armhf] udeb: Add mmc-core-modules to Provides of kernel-image
  * udeb: Add fb-modules and include drm and drm_kms_helper on most
architecures
  * udeb: Move basic PV modules from {hyperv,virtio}-modules to kernel-image
  * udeb: Move drivers from {hyperv,virtio}-modules to
{fb,input,nic,scsi}-modules
  * certs: Replace test signing certificate with production signing certificate
  * debian/bin/gencontrol_signed.py: Put all files.json fields under "packages"
  * linux-perf: Enable coresight trace (libopencsd) support in perf
(Closes: #895131)
  * [armhf] Add patch from upstream fixing stability issues when cpufreq
is enabled on Orange Pi Plus.
  * [armhf] Enable REGULATOR_SY8106A as module.
  * [arm64] Add patch working around A64 timer issues.
  * arm64: lockdown: Move init_lockdown() call after uefi_init()
  * Btrfs: fix corruption reading shared and compressed extents after hole
punching (Closes: #922306)
  * [arm64] Add patch from v4.20 to enable device-tree for Pine64-LTS.
  * [rt] Update to 4.19.25-rt16
  * [armel/rpi] Add flavour for Raspberry Pi and Raspberry Pi Zero
  * [armel, armhf] Enable CRASH_DUMP
  * [mips r6] Disable JUMP_LABEL for now: it will cause Reserved Instruction.
Enable SERIAL_OF_PLATFORM, if not, userland shows nothing.
Enable CPU_HAS_MSA, HIGHMEM, CRYPTO_CRC32_MIPS, and NR_CPUS to 16.
Support some boston drivers: IMG_ASCII_LCD, I2C_EG20T, PCH_PHUB, MMC,
  PCIE_XILINX, RTC_DRV_M41T80, SPI_TOPCLIFF_PCH.
  * [mipsel/mips64el] Backport MIPS: Loongson: Introduce and use
loongson_llsc_mb()

There will be an ABI bump.

Ben.

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




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

Re: Fixing stretch debian-installer on armhf

[Ben Hutchings]

On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
[...]
> > * Rebuild the debian-installer images, pulling in updates from
> >   stretch-updates, leaving only armhf netboot targets broken. 
> 
> Expanding a bit: rebuilding src:debian-installer from the stretch
> branch, which has s-p-u enabled, would fetch the fixed kernel and a
> couple of its udebs, at build time; the resulting netboot images
> wouldn't know about s-p-u though at run time, and would try to load
> udebs from stretch.
[...]

Why is that a problem?  The only change made in 4.9.144-3.1 is in the
kernel image, and the module udebs don't have versioned dependencies.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.




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

Uploading linux (4.19.20-1)

[Ben Hutchings]

I intend to upload linux version 4.19.20-1 to unstable this weekend.
This adds 4 stable updates including a number of security fixes.  The
other pending changes include:

  * [amd64] enable UIO_HV_GENERIC for Azure's VMBus access.
  * [cloud-amd64] enable UIO for Azure's VMBus access, and VFIO for guests
running on an hypervisor that exposes a vIOMMU.
  * [armhf,arm64] serial: 8250: Disable SERIAL_8250_DEPRECATED_OPTIONS
  * percpu: convert spin_lock_irq to spin_lock_irqsave (fixes boot failure with
alpha-generic flavour)
  * debian/tests/python: Fix spurious failure due to misuse of stderr
  * [arm64] enable ARM_CCI_PMU so ARM_CCI400_PMU and ARM_CCI5xx_PMU options
get really enabled.
  * [arm64] enable PCI_PRI, PCI_PASID as PCI can be behind IOMMU in servers.
  * udeb: Add virtio-gpu into d-i to get graphical output in VM instances.
  * [x86] kvmclock: set offset for kvm unstable clock (Closes: #918036)
  * [x86] Enable Touchpad support on Gemini Lake via CONFIG_PINCTRL_GEMINILAKE
(Closes: #917388)
  * [x86] Enable SND_SOC_ES8316 and Baytrail & Cherrytrail with ES8316 codec,
too (Closes: #918589)
  * hwmon: Enable CONFIG_SENSORS_NCT7802,NCT7904,NPCM7XX,ASPEED and W83773G
to use HWMON hardware (Closes: #912597)
  * net: can: Enable CONFIG_CAN_PEAK_PCIEFD for a PCI express CAN Bus adapter
(Closes: #920809)
  * [armhf] Enable CONFIG_SENSORS_LM75 for armhf (Closes: #918114)
  * [armhf] Enable CONFIG_MMC_SDHCI_OMAP=m, used on DRA7 and related SoCs.
  * [armel] add spi-orion to mtd.udeb to be able to access spi flash on e.g.
qnap ts-21x. (Closes: #920607)

There will be an ABI bump.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky




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

Uploading linux (4.19.16-1)

[Ben Hutchings]

I intend to upload linux version 4.19.16-1 to unstable tomorrow
(Thursday 17th).  Aside from the upstream stable updates, the pending
changes include:

  * Bump ABI to 2
  * ipv6: Consider sk_bound_dev_if when binding a socket to an address
(Closes: #918103)
  * posix-cpu-timers: Unbreak timer rearming (Closes: #919019, #919049)
  * [arm64] Enable Xilinx ZynqMP SoC and drivers
  * [mipsel, mips64el] Enable DRM_AST and FB_SM750 for loongson-3
install ast and sm750fb to loongson-3's fb-modules
  * [x86] Enable LEDS_APU to support leds on PC Engines APU SBC series
  * [rt] Update to 4.19.15-rt12
  * [ia64,m68k] Fix FTBFS on these
architectures

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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

Re: Proposal: Repository for fast-paced package backports

[Ben Hutchings]

On Mon, 2018-12-31 at 18:31 +0100, Jonas Meurer wrote:
> Pirate Praveen:
> > On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer  
> > wrote:
> > > Pirate Praveen:
> > > > On 12/28/18 11:06 AM, Thomas Goirand wrote:
> > > > > If the problem is hardware and connectivity, then IMO you can easily
> > > > > find a sponsor for it. My company could well offer it for example
> > > > > (hosted in Geneva with very nice connectivity to almost everywhere).
> > > > > 
> > > > > Setting-up a repository isn't hard. And for a start, I don't think
> > > you
> > > > > really need a buildd network, just amd64 is ok-ish.
> > > > 
> > > > I'd like go ahead with this offer and create rolling.debian.net (as
> > > > someone suggested already to avoid reusing volatile). I think we can
> > > > take the setup discussions offlist.
> > > 
> > > Please don't name it 'rolling'. This term is used a lot in the sense of
> > > 'rolling releases' by other distributions, and also in discussions
> > > about
> > > constantly usable testing.
> > 
> > Well, it only makes things clear as the packages in this repo will be 
> > rolling.
> 
> ... as packages do in unstable, testing and ${stable}-backports. So it's
> not a particularly good term to describe the unique feature of the new
> repo either. In my eyes, 'fastpaced' makes the point far better.
> 
> But as said, the main argument against calling it 'rolling' is that it
> would create confusion due to the name already being used in other
> (Debian-related) contexts.

At the risk of bikeshedding, some alternate names that might be less
confusing:

- fresh-apps
- evergreen
- rolling-apps

Ben.

--  
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman




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

Bug#906016: transition: gjs built with mozjs60

[Ben Hutchings]

On Mon, 2018-12-24 at 12:01 +, Simon McVittie wrote:
> On Sun, 23 Dec 2018 at 16:29:31 +0100, John Paul Adrian Glaubitz wrote:
> > Can we postpone the decision until after the holidays? Then I have enough
> > time for trying to whip up a patch.
> 
> That seems fine, but please note that most of the changes necessary to
> remove gjs from s390x happened some time ago (in late September and early
> October); so if you are able to make mozjs60 work correctly on s390x,
> we will likely already need to revert some changes to bring it back.
> If the d-i maintainers remove gjs/GNOME Shell on s390x and then you
> subsequently get mozjs60 working on s390x, the list of changes to revert
> to bring back gjs/s390x just becomes slightly longer.
> 
> I'm also not at all sure whether the GNOME Shell environment works
> on s390x hardware, which as far as I know doesn't have either a
> Mesa-supported GPU or the llvmpipe driver - if it never worked then we
> aren't actually losing anything. Presumably s390 porters would have a
> better idea of what works and what doesn't.

IBM Z (why do they keep renaming it?) supports PCI Express now, so I
think it's *possible* to install a Mesa-supported GPU, if unlikely.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.




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

Bug#912820: stretch-pu: package pkgsel/0.45+deb9u2

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

During installation with network sources enabled, security updates are
normally installed.  However, this currently doesn't include updates
that depend on a new binary package, due to a kernel or library ABI
change.  This is bug #908711.

This is fixed by adding the --with-new-pkgs option to the apt-get
command line.  The full debdiff is below.

Ben.

diff -Nru pkgsel-0.45/debian/changelog pkgsel-0.45+deb9u2/debian/changelog
--- pkgsel-0.45/debian/changelog2016-12-24 12:49:01.0 +
+++ pkgsel-0.45+deb9u2/debian/changelog 2018-10-27 23:58:05.0 +0100
@@ -1,3 +1,16 @@
+pkgsel (0.45+deb9u2) stretch; urgency=medium
+
+  * Fix target suite
+
+ -- Ben Hutchings   Sat, 27 Oct 2018 23:58:05 +0100
+
+pkgsel (0.45+deb9u1) unstable; urgency=medium
+
+  * Install new dependencies when safe-upgrade (default) is selected
+(Closes: #908711)
+
+ -- Ben Hutchings   Sat, 27 Oct 2018 23:27:26 +0100
+
 pkgsel (0.45) unstable; urgency=medium
 
   * Export DEBIAN_TASKS_ONLY=1 when running tasksel in target, to make
diff -Nru pkgsel-0.45/debian/postinst pkgsel-0.45+deb9u2/debian/postinst
--- pkgsel-0.45/debian/postinst 2016-12-24 03:07:09.0 +
+++ pkgsel-0.45+deb9u2/debian/postinst  2018-10-27 23:27:12.0 +0100
@@ -78,16 +78,16 @@
upgrade_type="$RET"
# Convert to apt-get command names.
case "$RET" in
-   safe-upgrade) upgrade_type=upgrade;;
+   safe-upgrade) upgrade_type='upgrade --with-new-pkgs';;
full-upgrade) upgrade_type=dist-upgrade;;
esac
db_progress INFO pkgsel/progress/upgrade
sleep 2 # allow the message to be seen
 
log "checking for (security) updates to the base system"
-   # Exclude Recommends to avoid installing new packages as part of
-# an upgrade.
-   in-target sh -c "debconf-apt-progress --from 50 --to 100 --logstderr -- 
apt-get -q --no-install-recommends -y -o DPkg::options=--force-confnew 
'$upgrade_type'" || aptfailed
+   # Exclude Recommends to avoid installing new recommended packages
+   # as part of an upgrade
+   in-target sh -c "debconf-apt-progress --from 50 --to 100 --logstderr -- 
apt-get -q --no-install-recommends -y -o DPkg::options=--force-confnew 
$upgrade_type" || aptfailed
tasksel_start=100
 fi
 


-- System Information:
Debian Release: buster/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 4.18.0-2-amd64 (SMP w/4 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

Bug#910969: stretch-pu: package firmware-nonfree/20161130-4

[Ben Hutchings]

 templates = 
self.process_templates(self.templates['templates.license'], vars)
 license_split = re.split(r'\n\s*\n', license)
 templates[0]['Description'].extend(license_split)
 templates_filename = "debian/firmware-%s.templates" % package
-self.write_rfc822(codecs.open(templates_filename, 'w', 'utf-8'), 
templates)
+self.write_rfc822(open(templates_filename, 'w'), templates)
 
 desc = packages_binary[0]['Description']
 desc.append(
@@ -336,7 +337,7 @@ You must agree to the terms of this license before it is 
installed."""
 vars['firmware-list'] = ''.join(firmware_meta_list)
 package_meta_temp = self.templates["metainfo.xml"]
 # XXX Might need to escape some characters
-codecs.open("debian/firmware-%s.metainfo.xml" % package, 'w', 
'utf-8').write(self.substitute(package_meta_temp, vars))
+open("debian/firmware-%s.metainfo.xml" % package, 
'w').write(self.substitute(package_meta_temp, vars))
 
 def process_template(self, in_entry, vars):
 e = Template()
@@ -370,10 +371,10 @@ You must agree to the terms of this license before it is 
installed."""
 self.write_makefile(makefile)
 
 def write_control(self, list):
-self.write_rfc822(codecs.open("debian/control", 'w', 'utf-8'), list)
+self.write_rfc822(open("debian/control", 'w'), list)
 
 def write_makefile(self, makefile):
-f = codecs.open("debian/rules.gen", 'w', 'utf-8')
+f = open("debian/rules.gen", 'w')
 makefile.write(f)
 f.close()
 
diff --git a/debian/changelog b/debian/changelog
index 745d4613345b..af2adeb54d68 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,26 @@
+firmware-nonfree (20161130-4) stretch; urgency=medium
+
+  * debian/bin/gencontrol.py: Set encoding to UTF-8 globally
+  * Add back firmware-{adi,ralink} as transitional packages (Closes: #907320)
+  * debian/control: Point Vcs URLs to Salsa
+  * Update to linux-support 4.9.0-8
+  * firmware-brcm80211: Update Broadcom wifi firmware to fix security issues
+(Closes: #869639):
+- BCM4339 (CVE-2016-0801)
+- BCM4354 (CVE-2016-0801, CVE-2017-0561, CVE-2017-9417, CVE-2017-13077,
+  CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081)
+- BCM4356-PCIe (CVE-2016-0801, CVE-2017-0561, CVE-2017-9417,
+  CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
+  CVE-2017-13081)
+- BCM43340 (CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
+  CVE-2017-13081) (also fixes issues when operating in 5GHz band)
+- BCM43362 (CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
+  CVE-2017-13081)
+- BCM43430 (CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
+  CVE-2017-13081)
+
+ -- Ben Hutchings   Sat, 13 Oct 2018 20:27:06 +0100
+
 firmware-nonfree (20161130-3) unstable; urgency=medium
 
   * misc-nonfree: Include Intel OPA Gen1 firmware (Closes: #862458)
diff --git a/debian/config/brcm80211/brcm/brcmfmac43340-sdio.bin 
b/debian/config/brcm80211/brcm/brcmfmac43340-sdio.bin
new file mode 100644
index ..a945f80dbeb6
Binary files /dev/null and 
b/debian/config/brcm80211/brcm/brcmfmac43340-sdio.bin differ
diff --git a/debian/config/brcm80211/brcm/brcmfmac43362-sdio.bin 
b/debian/config/brcm80211/brcm/brcmfmac43362-sdio.bin
new file mode 100644
index ..62b3643420ed
Binary files /dev/null and 
b/debian/config/brcm80211/brcm/brcmfmac43362-sdio.bin differ
diff --git a/debian/config/brcm80211/brcm/brcmfmac4339-sdio.bin 
b/debian/config/brcm80211/brcm/brcmfmac4339-sdio.bin
new file mode 100644
index ..bc8316d80f32
Binary files /dev/null and b/debian/config/brcm80211/brcm/brcmfmac4339-sdio.bin 
differ
diff --git a/debian/config/brcm80211/brcm/brcmfmac43430-sdio.bin 
b/debian/config/brcm80211/brcm/brcmfmac43430-sdio.bin
new file mode 100644
index ..4b2945eaca56
Binary files /dev/null and 
b/debian/config/brcm80211/brcm/brcmfmac43430-sdio.bin differ
diff --git a/debian/config/brcm80211/brcm/brcmfmac4354-sdio.bin 
b/debian/config/brcm80211/brcm/brcmfmac4354-sdio.bin
new file mode 100644
index ..e2f7b1f04fbb
Binary files /dev/null and b/debian/config/brcm80211/brcm/brcmfmac4354-sdio.bin 
differ
diff --git a/debian/config/brcm80211/brcm/brcmfmac4356-pcie.bin 
b/debian/config/brcm80211/brcm/brcmfmac4356-pcie.bin
new file mode 100644
index ..3bf706e08c3b
Binary files /dev/null and b/debian/config/brcm80211/brcm/brcmfmac4356-pcie.bin 
differ
diff --git a/debian/config/misc-nonfree/defines 
b/debian/config/misc-nonfree/defines
index 907c2e98a95e..c06c0a1d150c 100644
--- a/debian/config/misc-nonfree/defines
+++ b/debian/config/misc-nonfree/defines
@@ -3,8 +3,8 @@ desc: various drivers in the Linux kernel
 longdesc:
  various drivers in the Linux kernel. This is 

Uploading linux (4.18.10-1)

[Ben Hutchings]

I intend to upload linux version 4.18.10-1 to unstable on Monday.
This includes two upstream stable updates, including the fix for
CVE-2018-17182.

There will be an ABI bump (which resolves the FTBFS on arm64 and
armhf).

The other pending changes are:

  * debian/rules.real: Generate linux-source tarball with root user and
group specified, to fix reproducibility issues.
  * [arm64] ACPI: Change ACPI_NFIT from built-in to module
  * [i386/686] Enable MGEODE_LX instead of M686 (regression in 4.16)
- x86-32: Disable 3D-Now in generic config
  * [x86] enable PINCTRL_AMD for touchpad support on Lenovo IdeaPad.
  * [arm64] Add support for new server hardware (Closes: #900581)
  * [arm64] acpi: Add fixup for HPE m400 quirks
  * floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl
(CVE-2018-7755)
  * scsi: target: iscsi: Use hex2bin instead of a re-implementation
(CVE-2018-14633)
  * scsi: target: iscsi: Use bin2hex instead of a re-implementation

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Re: Re-evaluating architecture inclusion in unstable/experimental

[Ben Hutchings]

On Sat, 2018-09-29 at 17:05 +0200, John Paul Adrian Glaubitz wrote:
> On 9/29/18 8:48 AM, Ben Hutchings wrote:
> > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote:
> > [...]
> > > Furthermore, several of the ports are in very healthy condition and
> > > even surpass some release architectures. The powerpc and ppc64 ports,
> > > for example, build more packages than any of the mips* ports.
> > 
> > I would be very happy to never have to wait for MIPS builds again.
> 
> I don't have a problem with waiting for slow machines. I just think this
> shows that the decisions what becomes a release architecture and what
> doesn't isn't purely meritocratic.

It's been a long time since Debian could run infrastructure on donated
hardware.  We need hardware that is reliable and that can be quickly
replaced when (not if) it fails.  So commercial availability is, and
should continue to be, a release qualification.

It is also unacceptable that the release of an urgent security update
should have to wait a long time for builds.  So speed matters.

[...]
> I think the problem that I have is that the release qualifications are
> not practical in the sense that they don't necessarily meet our users
> expectations. As I said, I think a tier-based system would be more
> practical as it would allow ports to be degraded more gracefully instead
> of just kicking them out like it was done with 32-Bit PowerPC.
[...]

Could you be more specific?

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison




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

Re: Re-evaluating architecture inclusion in unstable/experimental

[Ben Hutchings]

On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote:
[...]
> Furthermore, several of the ports are in very healthy condition and
> even surpass some release architectures. The powerpc and ppc64 ports,
> for example, build more packages than any of the mips* ports.

I would be very happy to never have to wait for MIPS builds again.

> As for the kernel maintenance, except for Alpha, all the ports have
> at least one kernel maintainer:
> 
>  * hppa: actively maintained by two people who also maintain the toolchain

But the hardware is EOL since 2008.

>  * ia64: maintained by one paid developer at Intel

To the extent of 2 whole commits this year!  I'm pretty sure this is
not actually his job any more.

>  * m68k: maintained by multiple independent kernel maintainers, at least
>  five people involved upstream; port is also getting new drivers

But the available hardware is either too slow to be useful, or only
available through crowdfunding (maybe, eventually).

>  * powerpc/ppc64: maintained mostly by IBM people

IBM looks after 64-bit configurations, so ppc64 is covered but not
powerpc.

>  * sh4: maintained by two kernel maintainers

That may be, but the Debian port isn't stable enough to *build* a
kernel: https://buildd.debian.org/status/logs.php?pkg=linux=sh4

>  * sparc64: used to be maintained by a team at Oracle but Oracle recently
> changed their mind about Linux on SPARC; now it's back to
> David Miller and some additional volunteers

Oracle laid off their SPARC team.  Fujitsu has another SPARC processor
in development, but only for supercomputers (and they seem to be
switching to Aarch64 later).  So we can expect this architecture to
slowly fade away now.

>  * x32: maintained by the people who maintain the x86 port of the kernel

H. Peter Anvin did the original port in 2012, but so far as I can see
none of the x86 maintainers have done any development on it since then.
And yes, development work has been needed:

- x32 has 64-bit time_t and that never worked quite right.  This may
  have finally been fixed this year by Arnd Bergmann's work, but I'm
  not sure.
- syscall restart was broken until 2015 when someone actually tested
  it.
- There have been several regressions specific to x32, some of which
  stuck around for a year or so before someone and fixed them.

[...]

So, by all means have fun working on these ports, but aside from ppc64
I don't see any prospect of them meeting release qualifications.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison



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

Uploading linux (4.18.8-1)

[Ben Hutchings]

I intend to upload linux version 4.18.8-1 to unstable on Monday.  This
brings 2 upstream stable updates with many fixes, including a few
security fixes.

Other pending changes include:

  * [x86] wireless: Enable R8822BE as module (Closes: #908330)
  * linux-headers: Stop linking the doc directory, which is not binNMU-safe
  * mac80211: don't update the PM state of a peer upon a multicast frame
(Closes: #887045, #886292)
  * [x86] Enable TI TPS6598x USB Power Delivery controller family
  * [x86] crypto: ccp: add timeout support in the SEV command (Closes: #908248)
  * [rt] Update to 4.18.7-rt5

No ABI bump is required.

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

Uploading linux (4.18.6-1)

[Ben Hutchings]

I intend to upload linux to unstable in the next day or two.  This will
bring a new upstream version and associated ABI bump.

The packaging changes include:

  * Move config files from linux-source- to an arch-dependent
linux-config- package
  * Remove remaining Python 2 (build-)dependencies
  * [arm64] enable RTC_DRV_PCF8563 for Odroid-C2
  * spi: Enable CONFIG_SPI_SPIDEV (Closes: #904043
  * Build with KBUILD_VERBOSE=1 by default
  * Replace the private patch system used for the orig tarball with
support for the debian/copyright Files-Excluded field
  * [rt] Update to 4.18.5-rt3 and re-enable
  * [armhf, arm64] add the rt featureset, which adds support for
PREEMPT_RT

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

Upgrade issues with firmware-{adi,ralink}

[Ben Hutchings]

Between jessie and stretch I folded the contents of firmware-adi and
firmware-ralink packages into firmware-misc-nonfree.  However, I
mistakenly dropped those binary packages entirely rather than making
them transitional packages for the stretch release.  I noticed this
recently while looking at updating firmware-nonfree in jessie to
support linux-4.9.

Should I add those transitional packages to stretch in a stable update?

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#905340: stretch-pu: package linux/4.9.110-3

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Please copy linux version 4.9.110-3 to the stretch-updates suite.
It fixes several serious regressions in the latest point release.

Ben.

-- System Information:
Debian Release: buster/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 4.17.0-1-amd64 (SMP w/4 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

Uploading linux (4.17.6-1)

[Ben Hutchings]

I intend to upload linux to unstable once the 4.17.6 stable update is
available (probably on Thursday 12th).

Aside from the stable updates, the other committed changes are:

  * [armhf] DRM: Enable CONFIG_DRM_IMX_PARALLEL_DISPLAY
  * linux-tools: Fix cross-build of objtool
  * [powerpcspe] Fix build failures (thanks to James Clarke):
- powerpc/lib/sstep: Fix building for powerpcspe
- powerpc/lib/Makefile: Don't pull in quad.o for 32-bit kernels
- linux-perf: Disable building for powerpcspe
  * [powerpc,powerpcspe,ppc64] Fix cross-build (Closes: #903096):
- Introduce linux-bootwrapper- package containing boot wrapper
  tools for the host architecture
- linux-image: Install symlinks to boot wrapper tools instead of the
  native tools built by kbuild
   * fs: Fix up non-directory creation in SGID directories (CVE-2018-13405)
   * sound/pci/hda: Ignore ABI changes

This might require an ABI bump, but I think it's avoidable.  In any
case, it will require a trip through NEW to add the linux-bootwrapper
package.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.



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

Bug#902939: Retry linux 4.17.3-1 build on s390x

[Ben Hutchings]

Package: release.debian.org
Severity: normal

The build on s390x was aborted—the log shows:

E: ABORT: Received TERM signal (requesting cleanup and shutdown)

This doesn't seem to be a real build failure, so please retry it:

gb linux_4.17.3-1 . s390x .

Ben.

-- System Information:
Debian Release: buster/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 4.17.0-1-amd64 (SMP w/4 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

Uploading linux (4.17.3-1)

[Ben Hutchings]

I intend to upload linux version 4.17.3-1 to unstable later today
(Monday).

This is a new stable upstream version which means an ABI bump.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



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

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Fri, 2018-06-29 at 22:33 +0100, Ben Hutchings wrote:
> On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier wrote:
> > > If the issues and concerns from you or your team are not up to date,
> > > then please follow up to this email (keeping debian-release@l.d.o and
> > > debian-ports@l.d.o in CC to ensure both parties are notified).
> > 
> > Two issues that we discussed at the recent Security Team sprint wrt
> > problems affecting buster:
> > 
> > (1) Linux upstream security support for i386 seems at risk at this point.
> > E.g. KPTI for i386 still isn't merged in Linux master half a year later 
> > after
> > the public Meltdown disclosure in early January (and the development of KPTI
> > started months before that). Someone at SuSE actually developed patches
> > as an older SLES release using Linux 3.0 (!) still supports i386, but that
> > will also EOL at some point and if we don't have the manpower to
> > develop upstream fixes for future i386-specific flaws.
> > 
> > It's not a strict blocker, but we wanted to raise the discussion whether
> > it still makes sense to ship 32 bit kernels for buster, which means with
> > support until ~ 2022.
[...]

Also, if there is a question about the continued use of 32-bit x86
systems, it appears that the AMD Geode LX and VIA C7 processors are
still commercially available.

(I'm ignoring the Intel Quark since it can't run a standard i386 user-
space.)

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



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

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> Niels Thykier wrote:
> > If the issues and concerns from you or your team are not up to date,
> > then please follow up to this email (keeping debian-release@l.d.o and
> > debian-ports@l.d.o in CC to ensure both parties are notified).
> 
> Two issues that we discussed at the recent Security Team sprint wrt
> problems affecting buster:
> 
> (1) Linux upstream security support for i386 seems at risk at this point.
> E.g. KPTI for i386 still isn't merged in Linux master half a year later after
> the public Meltdown disclosure in early January (and the development of KPTI
> started months before that). Someone at SuSE actually developed patches
> as an older SLES release using Linux 3.0 (!) still supports i386, but that
> will also EOL at some point and if we don't have the manpower to
> develop upstream fixes for future i386-specific flaws.
> 
> It's not a strict blocker, but we wanted to raise the discussion whether
> it still makes sense to ship 32 bit kernels for buster, which means with
> support until ~ 2022.
[...]

The lack of Meltdown mitigation on i386 is concerning, though I remain
somewhat hopeful that it will get fixes eventually.  A quick look
through kernel-sec finds maybe 3 other i386-specific issues in the last
5 years (CVE-2013-0190, CVE-2014-4508, CVE-2016-3672), and none of the
fixes were difficult to backport.

It's worth noting that Meltdown also never got mitigated for any of the
other affected architectures (at least ppc64el and s390x) in jessie,
despite being addressed upstream.  So I don't think it makes sense to
pick on i386 as being particularly vulnerable.

Also, I don't think it is currently tenable to have a release
architecture without a kernel.  We still don't have a way to
interactively install multiarch amd64/i386 systems.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


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

Bug#862030: jessie-pu: package rar/2:4.2.0+dfsg.1-0.1

[Ben Hutchings]

On Fri, 2018-06-08 at 21:39 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2017-11-24 at 17:14 +0000, Ben Hutchings wrote:
> > On Tue, 2017-06-27 at 22:55 +0200, Cyril Brulebois wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > Ben Hutchings  (2017-05-07):
> > > > rar should be updated to fix #860952.
> > > > 
> > > > The orig tarballs need to be repacked to exclude
> > > > rar_static.  Then I
> > > > would apply the following source patch:
> > > > 
> 
> ...
> > > Based on the last line of context and the first line of the diff
> > > (marked
> > > with <=== above), I'm not sure whether you plan to remove
> > > default.sfx
> > > along with it, since the previous line still mentions it, and the
> > > rules
> > > file as well, see below.
> > 
> > That was intentional, although I forgot to mention it.  default.sfx
> > hasn't been statically linked since (I think) version 3.9.3-1.
> > 
> 
> Please go ahead; apologies for the long delay.

Done.

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

Re: Updating x86 microcode in stable

[Ben Hutchings]

On Wed, 2018-05-16 at 14:57 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 15 May 2018, Ben Hutchings wrote:
> > I notice that amd64-microcode and intel-microcode haven't been updated
> > in stable this year.  (Indeed, amd64-microcode hasn't been updated at
> > all this year, but I know AMD has issued an update!)
> 
> AMD did not issue any public updates AFAIK(!), the one we have [which is
> not in stable] is only for EPYC processors, and came from SuSE...
> 
> So far we do not have a *single* report from someone with an EPYC box
> whether it works or not, as far as I know.  I am not confortable with
> proposing a stable update for this one unless we get such a report,
> since that microcode update is *still* not available in linux-firmware
> upstream...
> 
> If I am wrong about this, please correct me (and point me to the AMD
> microcode release) and I will fix it ASAP.

According to <https://www.amd.com/en/corporate/security-updates>, "AMD
recommended mitigations for GPZ Variant 2 were made available to our
Linux partners and have been released to distribution earlier this
year."

Guess we're not important enough to be a partner. :-(

> > You have updated intel-microcode in backports suites instead.  What's
> > the reasoning behind this?  I would expect all microcode updates to
> 
> One of the stable release managers suggested to be more careful with
> this recent crop of microcode updates...
> 
> Given the fact that it triggered a number of issues in the kernels of
> some vendors (kernel bug, not microcode bug), I agree with their
> reasoning, so I did not send a SPU request after an one-month wait.

Yes, I understand that.

> However, I don't see any reason why we could not start the process for
> an upload of intel-microcode to stable right now.  It has been tested
> widely enough by Debian users and other distros by now, and the only
> kernels that regressed were Ubuntu's (related to apparmor and IBPB
> support, worked around by noibpb), AFAIK.

Thanks.

Ben.

> > As you probably know, updated microcode is needed to mitigate against
> > Spectre v2 when running code that has not been rebuilt with the
> > "retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
> > it's also needed to support Spectre v2 mitigation in KVM guests running
> > Windows.
> 
> Yes, that's correct.
> 
> > The Linux kernel in stretch has had support for the microcode-based
> > mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
> > backporting these changes to jessie, so microcode updates would be
> > useful there too.
> 
> ACK.  I usually send spu and ospu requests at the same time anyway,
> since the criteria for acceptance is mostly the same.
> 
-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.


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

Updating libvirt and qemu in stable

[Ben Hutchings]

In order to support Spectre v2 mitigation in Windows guests, I believe
the microcoded mitigation features (IBPB and IBRS) need to be exposed
to them.  This may also be useful for Linux guests using OVMF, unless
it is rebuilt with the retpoline mitigation.

The kernel side of this in KVM was already implemented in version
4.9.82-1+deb9u1, although the microcode updates are not yet in stable.

libvirt and qemu (and maybe other related packages) also need to be
updated so that they recognise and enable the new CPU feature bits for
guests.  Is this likely to be doable?

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Updating x86 microcode in stable

[Ben Hutchings]

I notice that amd64-microcode and intel-microcode haven't been updated
in stable this year.  (Indeed, amd64-microcode hasn't been updated at
all this year, but I know AMD has issued an update!)

You have updated intel-microcode in backports suites instead.  What's
the reasoning behind this?  I would expect all microcode updates to
meet the criteria for a stable update (fixing instability or data loss
bugs) or security update.

As you probably know, updated microcode is needed to mitigate against
Spectre v2 when running code that has not been rebuilt with the
"retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
it's also needed to support Spectre v2 mitigation in KVM guests running
Windows.

The Linux kernel in stretch has had support for the microcode-based
mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
backporting these changes to jessie, so microcode updates would be
useful there too.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Re: Fixing Linux getrandom() in stable

[Ben Hutchings]

On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote:
> On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote:
[...]
> > # Options for a new fix
> > 
> > It is unlikely that any further fix will be forthcoming on the kernel
> > side, so I believe that we need to do one of:
> > 
> > 1. Add entropy to the kernel during boot; either:
> >a. Improve systemd-random-seed
> >b. Recommend use of haveged
> 
> I don't see any solution above that both always works and never results
> in new CVEs.

Indeed.

> As an example, what happens if I debootstrap and deploy the resulting
> filesytem to a large number of identical embedded systems without
> entropy sources?

Then it is your fault when they turn into a botnet. :-)  Availability
of randomness must be considered in the design of embedded systems.

[...]
> /dev/urandom is documented in a very misleading way, quoting random(4):
>When read during early boot time, /dev/urandom may return data prior to
>the entropy pool being initialized.  If this  is  of  concern  in  your
>application, use getrandom(2) or /dev/random instead.
> 
> What is the worst case for "early boot time" here? "always"?

No, I don't think so.

> Due to the gdm bugs mentioned above we know that there are real-life 
> situations where gdm currently uses "random" data that might be 
> predictable.
> 
> grep tells me:
> daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes 
> (auth_entry.data_length, );
> daemon/gdm-display-access-file.c:*cookie = gdm_generate_random_bytes 
> (GDM_DISPLAY_ACCESS_COOKIE_SIZE,
> 
> Repeat the same for every package that uses /dev/urandom.

This is certain undesirable, but it's exploitable only by local users. 
(If you let the X server listen to the network, all authentication
cookies are sent in the clear so you've already lost.  If you use ssh X
forwarding, it generates a new authentication cookie for use with the X
proxy on the remote machine.)

> 
> >b. Tolerate a longer wait for getrandom() to return
> 
> I suspect there might be no guaranteed upper bound for the waiting time.

Interrupt timing feeds into the RNG, and as long as there's at least
one interrupt per second then I think the RNG will reach the fully
initialised state after a few minutes.  I just started a VM with a
serial console and only a shell running as pid 1, which is about as
idle a system as I can imagine, and it was seeing more than one
interrupt per second.  However, other architectures (e.g. s390x) might
achieve greater idleness.

> > ...
> > The libbsd maintainer (Guillem Jover) favours option 2a.
> > 
> > One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
> > also proposed that systemd could provide a wait-for-rng-ready unit to
> > support this.
> 
> I don't see any general solution that is both correct and easy.

Indeed.

> The proper way forward might be to deprecate /dev/urandom and add a 
> third option GRND_UNSAFE_RANDOM to getrandom() that is documented to 
> never block but might return predictable data in some cases.

This doesn't solve anything for us.  (It does help with the original
problem of device nodes possibly being absent from a minimal container
or chroot.)

> It would then be up to the application to decide whether predictable
> data is acceptable, and what to do in entropy-starved situations.
> 
> Regarding the suggested wait-for-rng-ready systemd unit for others to 
> wait on, this only makes sense for cases where "do not start at all"
> is the best handling for a "no entropy" situation.

Yes.

Ben.

> > Ben.
> 
> cu
> Adrian
> 
-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison



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

Re: Fixing Linux getrandom() in stable

[Ben Hutchings]

On Sun, 2018-05-13 at 11:27 +0200, Yves-Alexis Perez wrote:
> On Wed, 2018-05-09 at 23:46 +0100, Ben Hutchings wrote:
> > It is unlikely that any further fix will be forthcoming on the kernel
> > side, so I believe that we need to do one of:
> > 
> > 1. Add entropy to the kernel during boot; either:
> >a. Improve systemd-random-seed
> >b. Recommend use of haveged
> 
> There's also something which might be worth trying in coordination with
> upstream: credit entropy for platform RNG like RDRAND/RDSEED. It obviously
> won't fix the problem everywhere, but at least on “recent” Intel platforms
> there should be an entropy source available without any further initialization
> (unlike the TPM for example).
> 
> I know about the trust issues wrt. Intel, but maybe that should be revisited?

I think it would make sense to at least provide a run-time option for
trusting the platform RNG.

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

Fixing Linux getrandom() in stable

[Ben Hutchings]

# Background

The Linux kernel random number generator (RNG) historically supported
two character devices for reading random data:

* `/dev/urandom`: non-blocking, may be predictable if called soon after
  boot or based on other output
* `/dev/random`: blocking, intended to be cryptographically secure

Since Linux 3.19 it has also supported a `getrandom()` system call,
which provides flags for cryptographically secure behaviour
(`GRND_RANDOM`) and non-blocking behaviour (`GRND_NONBLOCK`). 
Crucially, this call should never return predictable data after boot -
it will either block or return an error, depending on whether
`GRND_NONBLOCK` is used.

# Security flaw and initial fix

Recently it was discovered that getrandom() could return successfully
before the RNG was really ready to produce unpredictable data.  This
issue was designated as CVE-2018-1108, and was fixed in Linux 4.17-rc2 
and various stable updates.

We fixed CVE-2018-1108 with an update to stretch last week
(DSA-4188-1).  The kernel versions in wheezy and jessie do not provide
getrandom().

# Regression

The version of glibc in stretch does not provide access to getrandom(),
but some packages in stable use syscall() to call it anyway, including:

* krb5: k5_get_os_entropy()
* libbsd: arc4_random_buf().  This is used by many other packages
  including libICE, and so indirectly by gnome-session.

Following DSA-4188-1, it turned out that the RNG did not become ready
on some systems until several minutes after boot, causing severe
regressions for GNOME/gdm (#897631, #897632) and Kerberos (#897599,
#897917).  We therefore reverted the fix in yesterday's update
(DSA-4196-1).

# Options for a new fix

It is unlikely that any further fix will be forthcoming on the kernel
side, so I believe that we need to do one of:

1. Add entropy to the kernel during boot; either:
   a. Improve systemd-random-seed
   b. Recommend use of haveged
2. For each affected userland package, either:
   a. Revert to using /dev/urandom
   b. Tolerate a longer wait for getrandom() to return

I asked about haveged on Twitter, and got into a discussion with Jann
Horn (who reported the original issue).  He pointed out that the
systemd-random-seed service already saves and restores some random data
between boots.  It currently doesn't tell the RNG that this should be
treated as adding to available entropy, so it doesn't help to unblock
getrandom().  It also doesn't fully protect against using the same
saved data twice, which would be a prerequisite.

The libbsd maintainer (Guillem Jover) favours option 2a.

One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
also proposed that systemd could provide a wait-for-rng-ready unit to
support this.

*If* these are the only users in stable, then it may be that it would
be sufficient to do stable updates for them and then for linux.  But
I'm not sure that they are, so we may need to pursue option 1 as well.

I would like to hear opinions from the release team and the systemd
maintainers on these options.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates


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

Uploading linux (4.16.5-1)

[Ben Hutchings]

I intend to upload linux version 4.16.5-1 to unstable during this
weekend.  This moves to a new upstream version, so it includes an ABI
bump.

Aside from that, there are the following Debian changes since
4.15.17-1:

* netfilter: enable NFT_FIB_NETDEV as module
* [powerpc,ppc64el,ppc64] Enable CRASH_DUMP (Closes: #883432)
* Drop note about Xen from long descriptions.
* [arm64] Enable ROCKCHIP_IODOMAIN as a module, to enable PCIe reset.
* [arm64] Enable REGULATOR_FAN53555 as a module, enabling cpufreq to
  work on rk3399 A72 cores.
* [arm64] Apply patch from linux-next to fix eMMC corruption on
  Odroid-C2 (Closes: #879072).
* Various build fixes
* [x86] Enable CONFIG_GPD_POCKET_FAN as a module (provides fan control
  on GPD Pocket UMPC systems) (Closes: #893451)
* [arm64] enable various drivers as module for teres-i OSHW laptop
  (Closes: #892786)
* [hppa] Re-enable 32-bit SMP kernel build. Qemu now supports it.
* [ia64] Re-add configuration for kernel and udebs
* [armhf] Enable ARCH_MESON and related drivers.
* [armhf] Add device-tree patches from linux-next to support USB and
  Ethernet on meson8b.
* [x86] Power management support for GPD Pocket UMPC systems
  (Closes: #895164)
* [armhf] Add dove cubox support, thanks to Josua Mayer
  (Closes: #876774)
* Enable DRM_DP_AUX_CHARDEV (Closes: #890235)
* Preparation for code signing (but this is disabled for now)
* integrity: Disable IMA until it works properly with lockdown
* Various security fixes (CVE-2018-1095, CVE-2018-1108, CVE-2018-10322,
  CVE-2018-10323)
* wireless: Add Debian wireless-regdb certificates (see #892229)
* udeb: Add algif_skcipher to crypto-modules (Closes: #896968)
* ext4: fix bitmap position validation (fixes regression in 4.15.17-1)
* [arm64] Add patches to support SATA on Tegra210/Jetson-TX1.
* [arm64] Enable features to support Pinebook and other A64 systems:
* [arm64] Add patch enabling simplefb LCD on A64.
* [hppa] Switch to self-decompressing kernel to save disk space in /boot
* [amd64] enable AMD 10GbE Ethernet driver (CONFIG_AMD_XGBE=m)

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

Uploading linux (4.15.17-1)

[Ben Hutchings]

I intend to upload linux version 4.15.17-1 to unstable on Wednesday or
Thursday of this week.

Aside from the upstream stable updates, the pending changes include:

- [armel] Configuration changes to shrink the kernel image and enable
  building it again
- Disabling the error message during boot about missing regulatory.db
- [armhf] Enable auto-loading of imx6q-cpufreq module where appropriate
- Security fixes for ext4 and libsas
- Bump ABI number to 3

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


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

Bug#894123: RM: nvidia-graphics-modules/oldstable -- RoQA; license problem; incompatible with current kernel ABI

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

See #815060 for the license issue.

The Linux kernel ABI in jessie was changed in January as a result of
the mitigation of the Meltdown security issue.  This package would
need to be updated to build new compatible modules, but that should
not be done due to the license issue.

For the same reasons, this package should also be removed from wheezy
- though I don't think that's practical no since there won't be any
further point releases.

Ben.

Bug#862030: jessie-pu: package rar/2:4.2.0+dfsg.1-0.1

[Ben Hutchings]

On Tue, 2017-06-27 at 22:55 +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
> 
> Ben Hutchings <b...@decadent.org.uk> (2017-05-07):
> > rar should be updated to fix #860952.
> > 
> > The orig tarballs need to be repacked to exclude rar_static.  Then I
> > would apply the following source patch:
> > 
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,12 @@
> > +rar (2:4.2.0+dfsg.1-0.1) jessie; urgency=medium
> > +
> > +  * Non-maintainer upload
> > +  * Repacked orig tarball excludes statically linked rar
> > +(Closes: #693396, #860952)
> > +  * Install dynamically linked rar
> > +
> > + -- Ben Hutchings <b...@decadent.org.uk>  Sun, 07 May 2017 16:00:26 +0100
> > +
> >  rar (2:4.2.0-1) unstable; urgency=low
> >  
> >* New upstream release (Closes: #661065)
> > --- a/debian/lintian
> > +++ b/debian/lintian
> > @@ -1,6 +1,2 @@
> >  rar: extra-license-file usr/share/doc/rar/license.txt.gz
> >  rar: binary-file-compressed-with-upx ./usr/lib/default.sfx <===
> > -rar: statically-linked-binary usr/lib/default.sfx  <===
> > -rar: statically-linked-binary usr/bin/rar
> > -# Statically linked file
> > -rar: missing-depends-line
> 
> Based on the last line of context and the first line of the diff (marked
> with <=== above), I'm not sure whether you plan to remove default.sfx
> along with it, since the previous line still mentions it, and the rules
> file as well, see below.

That was intentional, although I forgot to mention it.  default.sfx
hasn't been statically linked since (I think) version 3.9.3-1.

Ben.

> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -23,9 +23,9 @@
> > dh_installdirs
> >  
> > mkdir ./i386
> > -   cp ./rar_static ./i386
> > +   cp ./rar ./i386
> > cp ./default.sfx ./i386
> 
> ^
> 
> > -   install -o root -g root -s -m 0755 $(DEB_BUILD_ARCH)/rar_static 
> > debian/rar/usr/bin/rar
> > +   install -o root -g root -s -m 0755 $(DEB_BUILD_ARCH)/rar 
> > debian/rar/usr/bin/rar
> > 
> > dh_installdocs
> > dh_installman debian/rar.1
> 
> 
> KiBi.
-- 
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

Uploading linux (4.14.2-1)

[Ben Hutchings]

I intend to upload linux version 4.14.2-1 to unstable later this week.

As this is a new upstream release, there will be an ABI bump.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Uploading linux (4.13.13-1)

[Ben Hutchings]

I intend to upload linux version 4.13.13-1 to unstable on Tuesday or
Wednesday this week.

Aside from the upstream stable fixes, which include a number of
security fixes, the pending changes are:

  [ Salvatore Bonaccorso ]
  * netfilter: nft_set_hash: disable fast_ops for 2-len keys (Closes: #880145)

  [ Ben Hutchings ]
  * linux-image: Recommend apparmor, as systemd units with an AppArmor
profile will fail without it (Closes: #880441)
  * [powerpc*] kvm: Ignore ABI change in 4.13.6 (fixes FTBFS)
  * swap: Avoid ABI change in 4.13.12

I expect to add a few more bug fixes before uploading.

This should not require an ABI bump.

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

Uploading linux (4.13..4-1)

[Ben Hutchings]

I intend to upload linux version 4.13.4-1 to unstable today (Saturday)
or Sunday.  This is a new upstream version, so there's an ABI bump.

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

Re: Kernel ABI bump in stretch

[Ben Hutchings]

On Sun, 2017-09-03 at 18:51 +0200, Julien Cristau wrote:
> On Sun, Sep  3, 2017 at 01:45:48 +0100, Ben Hutchings wrote:
> 
> > There are several changes in the 4.9-stable branch which I don't think
> > we can take without changes to the kernel module ABI that will affect
> > out-of-tree modules.  This would mean an ABI bump, changing the names
> > of all linux-image and linux-headers packages.
> > 
> > Since we install meta-packages (such as linux-image-amd64) by default,
> > an 'apt full-upgrade' should result in installing the appropriate new
> > packages.  However, we have been able to avoid such an ABI bump in the
> > past 3 releases (so far) and this might come as a surprise to users.  I
> > think the point release announcement would need to draw attention to
> > this.
> > 
> > If this is totally unacceptable, I can revert the breaking changes, but
> > some of them fix use-after-free bugs that probably have security
> > impact.
> > 
> > Please let us know as soon as possible whether an ABI bump is OK, so
> > that we can prepare the update in time for the next point release.
> > 
> 
> This should be fine.  We don't ship any pre-built modules in stretch
> outside the linux source package, so the only other thing we need to do
> is update d-i at that point release.

Thanks.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.



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

Kernel ABI bump in stretch

[Ben Hutchings]

There are several changes in the 4.9-stable branch which I don't think
we can take without changes to the kernel module ABI that will affect
out-of-tree modules.  This would mean an ABI bump, changing the names
of all linux-image and linux-headers packages.

Since we install meta-packages (such as linux-image-amd64) by default,
an 'apt full-upgrade' should result in installing the appropriate new
packages.  However, we have been able to avoid such an ABI bump in the
past 3 releases (so far) and this might come as a surprise to users.  I
think the point release announcement would need to draw attention to
this.

If this is totally unacceptable, I can revert the breaking changes, but
some of them fix use-after-free bugs that probably have security
impact.

Please let us know as soon as possible whether an ABI bump is OK, so
that we can prepare the update in time for the next point release.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.



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

Bug#866692: stretch-pu: package linux-latest/80+deb9u1

[Ben Hutchings]

On Sat, 2017-07-01 at 16:10 +0100, Adam D. Barratt wrote:
[...]
> Overall the changes look okay to me, with the note below on unstable
> taken into account.
> 
> I was curious about this change though:
> 
> -Section: debug
> -Priority: extra
> 
> Should the -dbg packages not still be in the "debug" section?

Or metapackages?  I just reverted to the previous metadata.

> Is it intentional that there are still some dbgsym packages built by
> src:linux? Specifically:
> 
> hyperv-daemons-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, i386
> libcpupower1-dbgsym| 4.9.30-2+deb9u2 | stable-new | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> linux-cpupower-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, i386
> linux-kbuild-4.9-dbgsym| 4.9.30-2+deb9u2 | stable-new | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> linux-perf-4.9-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> usbip-dbgsym   | 2.0+4.9.30-2+deb9u2 | stable-new | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

Yes, it is intentional that userland packages get automatic debug
symbol packages.

> > (We'll need a higher version in unstable, too, but I see 82 was uploaded
> > and reached NEW already, so hopefully that'll be sorted out by the time
> > the point release happens.)
> 
> Well, it'll need to be. :-) To be entirely honest, I'd prefer to get the
> unstable situation sorted before we fix stable. Looking at the NEW page
> for the unstable upload, I can't imagine that there'll be any issues
> getting it sorted quickly.

That's now done.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#866692: stretch-pu: package linux-latest/80+deb9u1

[Ben Hutchings]

On Thu, 2017-07-13 at 07:42 +0100, Adam D. Barratt wrote:
> On Sat, 2017-07-01 at 16:10 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > Hi,
> > 
> > On Sat, 2017-07-01 at 06:07 +0200, Cyril Brulebois wrote:
> > > Hi Ben,
> > > 
> > > > > > Ben Hutchings <b...@decadent.org.uk> (2017-07-01):
> > > > src:linux-latest builds meta-packages depending on debug info packages
> > > > built from src:linux.  During the stretch release cycle, these were
> > > > changed to new-style dbgsym packages and then this change was reverted
> > > > to src:linux.  However, the change in src:linux-latest was *not*
> > > > reverted, leaving these meta-packages uninstallable.
> 
> [...]
> > -Section: debug
> > -Priority: extra
> > 
> > Should the -dbg packages not still be in the "debug" section?
> > 
> > Is it intentional that there are still some dbgsym packages built by
> > src:linux? Specifically:
> > 
> > hyperv-daemons-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, i386
> > libcpupower1-dbgsym| 4.9.30-2+deb9u2 | stable-new | amd64, 
> > arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> > linux-cpupower-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, i386
> > linux-kbuild-4.9-dbgsym| 4.9.30-2+deb9u2 | stable-new | amd64, 
> > arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> > linux-perf-4.9-dbgsym  | 4.9.30-2+deb9u2 | stable-new | amd64, 
> > arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> > usbip-dbgsym   | 2.0+4.9.30-2+deb9u2 | stable-new | amd64, 
> > arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> 
> Ping, both on the above questions and the upload.
> 
> If this is going to make it into 9.1, it needs to be uploaded _and
> through NEW_ by the weekend.

I can upload straight away if you're satisfied by the answers I just
sent.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#866692: stretch-pu: package linux-latest/80+deb9u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

src:linux-latest builds meta-packages depending on debug info packages
built from src:linux.  During the stretch release cycle, these were
changed to new-style dbgsym packages and then this change was reverted
to src:linux.  However, the change in src:linux-latest was *not*
reverted, leaving these meta-packages uninstallable.

The source changes are shown below, not including the files generated by
deian/bin/gencontrol.py.

Ben.

diff --git a/debian/bin/gencontrol.py b/debian/bin/gencontrol.py
index e2f031342b87..d2f87b9c6210 100755
--- a/debian/bin/gencontrol.py
+++ b/debian/bin/gencontrol.py
@@ -81,7 +81,7 @@ import os.path, re, codecs
 makeflags['DEBUG'] = True
 templates.extend(self.templates["control.image-dbg.latest"])
 substitute_file('lintian-overrides.image-dbg',
-'debian/linux-image-%s-dbgsym.lintian-overrides' %
+'debian/linux-image-%s-dbg.lintian-overrides' %
 vars['flavour'])
 substitute_file('lintian-overrides.source',
 'debian/source.lintian-overrides',
diff --git a/debian/changelog b/debian/changelog
index 867142c4a7d4..bd4e74d9f38d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+linux-latest (80+deb9u1) stretch; urgency=medium
+
+  * Revert changes to debug symbol meta-packages (Closes: #866691)
+
+ -- Ben Hutchings <b...@decadent.org.uk>  Sat, 01 Jul 2017 01:31:49 +0100
+
 linux-latest (80) unstable; urgency=medium
 
   * Re-introduce xen-linux-system-amd64 *again* as transitional package
diff --git a/debian/rules.real b/debian/rules.real
index 7c7cd11d50cb..5f17a23784f6 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -56,5 +56,5 @@ install-perf: DH_OPTIONS = -p$(PACKAGE_NAME)
dh_testroot
$(MAKE) -f debian/rules.real install-base 
DH_OPTIONS='-plinux-image$(LOCALVERSION) -plinux-headers$(LOCALVERSION)'
 ifeq ($(DEBUG),True)
-   $(MAKE) -f debian/rules.real install-base 
DH_OPTIONS='-plinux-image$(LOCALVERSION)-dbgsym' 
GENCONTROL_ARGS='$(GENCONTROL_ARGS) -DAuto-Built-Package=debug-symbols'
+   $(MAKE) -f debian/rules.real install-base 
DH_OPTIONS='-plinux-image$(LOCALVERSION)-dbg'
 endif
diff --git a/debian/templates/control.image-dbg.latest.in 
b/debian/templates/control.image-dbg.latest.in
index 72e93c663675..98f1bfbc965b 100644
--- a/debian/templates/control.image-dbg.latest.in
+++ b/debian/templates/control.image-dbg.latest.in
@@ -1,8 +1,6 @@
-Package: linux-image@localversion@-dbgsym
-Depends: linux-image-@abiname@@localversion@-dbgsym, ${misc:Depends}
+Package: linux-image@localversion@-dbg
+Depends: linux-image-@abiname@@localversion@-dbg, ${misc:Depends}
 Provides: linux-latest-image-dbg
-Section: debug
-Priority: extra
-Description: Debug symbols for Linux @flavour@ configuration (meta-package)
+Description: Debugging symbols for Linux @flavour@ configuration (meta-package)
  This package depends on the detached debugging symbols for the latest
  Linux kernel @flavour@ configuration.
diff --git a/debian/templates/lintian-overrides.image-dbg.in 
b/debian/templates/lintian-overrides.image-dbg.in
index b7378c2863ab..efebf21cce88 100644
--- a/debian/templates/lintian-overrides.image-dbg.in
+++ b/debian/templates/lintian-overrides.image-dbg.in
@@ -1,2 +1,2 @@
-linux-image-@flavour@-dbgsym: wrong-section-according-to-package-name 
linux-image-@flavour@-dbgsym => debug
-linux-image-@flavour@-dbgsym: debug-package-should-be-priority-extra 
linux-image-@flavour@-dbgsym
+linux-image-@flavour@-dbg: wrong-section-according-to-package-name 
linux-image-@flavour@-dbg => debug
+linux-image-@flavour@-dbg: debug-package-should-be-priority-extra 
linux-image-@flavour@-dbg
diff --git a/debian/templates/lintian-overrides.source.in 
b/debian/templates/lintian-overrides.source.in
index c6b7ca34676b..15b53f46915d 100644
--- a/debian/templates/lintian-overrides.source.in
+++ b/debian/templates/lintian-overrides.source.in
@@ -1 +1 @@
-linux-latest source: dbg-package-missing-depends linux-image-@flavour@-dbgsym
+linux-latest source: dbg-package-missing-depends linux-image-@flavour@-dbg


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 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)

Uploading linux (4.11.6-1)

[Ben Hutchings]

I intend to upload linux version 4.11.6-1 to unstable on Monday.
As this is a new upstream version, there is of course an ABI bump.

Some of the changes:

  * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE
  * [arm64] Enable support for Meson platform
  * debian/control: Fix compiler build-dependencies for cross-building
  * [armel] Adjust configuration to reduce image size (fixes FTBFS)
  * netfilter: Enable NF_SOCKET_IPV4, NF_SOCKET_IPV6 as modules
  * Enable BUG_ON_DATA_CORRUPTION
  * [arm64,x86] Replace securelevel patch set with lockdown patch set
  * [arm64] Enable support for Allwinner sunxi platform
  * [arm64] Enable REGULATOR_GPIO as module
  * block: Enable BLK_WBT, BLK_WBT_MQ
  * usbip: Fix FTBFS on 64-bit architectures with gcc-7
  * [m68k] udeb updates from John Paul Adrian Glaubitz
  * [x86] Enable SERIAL_8250_MID as built-in
  * debian/rules.real: Include rules.defs before using architecture variables
  * [rt] Update to 4.11.5-rt1 and reenable
  * fs: Reenable HPFS_FS as module
  * USB: serial: option: add two Longcheer device ids
  * [armhf] PCI: Enable PCI_HOST_GENERIC

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#864233: unblock: linux/4.9.30-1

[Ben Hutchings]

On Tue, 2017-06-06 at 01:24 +0100, Ben Hutchings wrote:
> On Tue, 2017-06-06 at 01:29 +0200, Axel Beckert wrote:
> > Hi,
> > 
> > Ben Hutchings wrote:
> > > This includes many important bug fixes, including security fixes.  It
> > > adds support for system reset on Malta boards, additional GPUs on
> > > ARM64 systems, and PL011 serial consoles on ARM64 systems.  It makes
> > > the efivarfs module available in the installer, which is important for
> > > supporting some x86 systems.
> > > 
> > > The debdiff would be too large for you to review, unfortunately.
> > > Instead, here are the changelog entries:
> > > 
> > > linux (4.9.30-1) unstable; urgency=medium
> > 
> > JFTR: This upload of linux 4.9.30-1 to unstable made at least one
> > package start to FTBFS in unstable, namely radvd. Please see
> > https://bugs.debian.org/864269 for details.
> 
> radvd's autoconf test for  has probably failed at least
> since Linux 2.6.32 when I made sure the kernel headers would never
> define struct sockaddr for userland:
> <https://git.kernel.org/linus/9c501935a3cdcf6b1d35aaee3aa11c7a7051a305>
> 
> But the conflict between  and  is far
> older than that, so if the test ever passed it should have resulted in
> this build failure.  I think that's a clear bug in radvd.  It should
> use either one or the other, and I think the sensible thing is to use
>  as it has been doing up until now.

I intend to drop the kernel patch that triggered this regression in the
first update for stretch.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.



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

Bug#864287: unblock: firmware-nonfree/20161130-3

[Ben Hutchings]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

Please unblock package firmware-nonfree

- Add some new firmware requested by drivers in Linux 4.9
- Fix two files that were not in the format expected by the driver
- Revert the Intel Pro Wireless 2200/2915 firmware to the same version
  in jessie (3.1).  Although the older version (3.0) worked better for
  some people, it seems to have a more serious bug.

The debdiff below excludes generated files (debian/control,
debian/rules.gen).

diff --git a/debian/changelog b/debian/changelog
index 5a694d19c135..745d4613345b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+firmware-nonfree (20161130-3) unstable; urgency=medium
+
+  * misc-nonfree: Include Intel OPA Gen1 firmware (Closes: #862458)
+  * misc-nonfree: Add Intel "Broxton" GuC firmware version 8.7 and
+Intel "Kabylake" GuC firmware version 9.14 (Closes: #854695)
+  * iwlwifi: Fix DDC file format for Intel Bluetooth 8260/8265
+(Closes: #854907)
+  * amd-graphics: Add radeon/si58_mc.bin (Closes: #856853)
+  * Revert "ipw2x00: Downgrade Intel Pro 2200/2915 firwmare to version 3.0"
+(Closes: #833551)
+  * Update to linux-support 4.9.0-1
+
+ -- Ben Hutchings <b...@decadent.org.uk>  Tue, 06 Jun 2017 00:56:25 +0100
+
 firmware-nonfree (20161130-2) unstable; urgency=medium
 
   * debian/control: Add XS-Autobuild field
diff --git a/debian/config/amd-graphics/defines 
b/debian/config/amd-graphics/defines
index b3d0d75e07d8..3c128d4f82ab 100644
--- a/debian/config/amd-graphics/defines
+++ b/debian/config/amd-graphics/defines
@@ -290,6 +290,7 @@ files:
  radeon/RV770_pfp.bin
  radeon/RV770_smc.bin
  radeon/RV770_uvd.bin
+ radeon/si58_mc.bin
  radeon/SUMO_me.bin
  radeon/SUMO_pfp.bin
  radeon/SUMO_rlc.bin
diff --git a/debian/config/amd-graphics/radeon/si58_mc.bin 
b/debian/config/amd-graphics/radeon/si58_mc.bin
new file mode 100644
index ..888398d07a66
Binary files /dev/null and b/debian/config/amd-graphics/radeon/si58_mc.bin 
differ
diff --git a/debian/config/ipw2x00/defines b/debian/config/ipw2x00/defines
index 66679de1583d..caae0ea9735c 100644
--- a/debian/config/ipw2x00/defines
+++ b/debian/config/ipw2x00/defines
@@ -27,13 +27,13 @@ version: 1.3
 
 [ipw2200-bss.fw_base]
 desc: Intel Pro Wireless 2200/2915 firmware (bss)
-version: 3.0
+version: 3.1
 
 [ipw2200-ibss.fw_base]
 desc: Intel Pro Wireless 2200/2915 firmware (ibss)
-version: 3.0
+version: 3.1
 
 [ipw2200-sniffer.fw_base]
 desc: Intel Pro Wireless 2200/2915 firmware (snf)
-version: 3.0
+version: 3.1
 
diff --git a/debian/config/ipw2x00/ipw2200-bss.fw 
b/debian/config/ipw2x00/ipw2200-bss.fw
index da88eca43b84..63d7af8ceb4b 100644
Binary files a/debian/config/ipw2x00/ipw2200-bss.fw and 
b/debian/config/ipw2x00/ipw2200-bss.fw differ
diff --git a/debian/config/ipw2x00/ipw2200-ibss.fw 
b/debian/config/ipw2x00/ipw2200-ibss.fw
index 71378a2f58b5..4809211d4979 100644
Binary files a/debian/config/ipw2x00/ipw2200-ibss.fw and 
b/debian/config/ipw2x00/ipw2200-ibss.fw differ
diff --git a/debian/config/ipw2x00/ipw2200-sniffer.fw 
b/debian/config/ipw2x00/ipw2200-sniffer.fw
index a0f0e18f8d8e..ae3767e0f413 100644
Binary files a/debian/config/ipw2x00/ipw2200-sniffer.fw and 
b/debian/config/ipw2x00/ipw2200-sniffer.fw differ
diff --git a/debian/config/iwlwifi/intel/ibt-11-5.ddc 
b/debian/config/iwlwifi/intel/ibt-11-5.ddc
new file mode 100644
index ..dff0824003e2
Binary files /dev/null and b/debian/config/iwlwifi/intel/ibt-11-5.ddc differ
Binary files /dev/null and b/debian/config/iwlwifi/intel/ibt-12-16.ddc differ
diff --git a/debian/config/misc-nonfree/copyright 
b/debian/config/misc-nonfree/copyright
index 70284fc4d955..9c0de13709ea 100644
--- a/debian/config/misc-nonfree/copyright
+++ b/debian/config/misc-nonfree/copyright
@@ -362,7 +362,47 @@ License: Redistributable (Micronas)
  WARRANTIES OF MERCHANTABILITY, SUPPORT, AND FITNESS FOR A PARTICULAR
  PURPOSE AND NON-INFRINGEMENT.
 
-Files: i915/*
+Files: hfi1_*
+Copyright: 2015, Intel Corporation
+License: Binary redistribution (Intel, narrower patent license)
+ All rights reserved.
+ .
+ Redistribution.
+ .
+ Redistribution and use in binary form, without modification, are permitted
+ provided that the following conditions are met:
+ *Redistributions must reproduce the above copyright notice and the
+  following disclaimer in the documentation and/or other materials provided
+  with the distribution.
+ *Neither the name of Intel Corporation nor the names of its suppliers may
+  be used to endorse or promote products derived from this software without
+  specific prior written permission.
+ *No reverse engineering, decompilation, or disassembly of this software is
+  permitted.
+ .
+ Limited patent license.
+ .
+ Intel Corporation grants a world-wide, royalty-free, non-exclusive license
+ un

Bug#864233: unblock: linux/4.9.30-1

[Ben Hutchings]

On Tue, 2017-06-06 at 08:26 +0200, Christoph Biedl wrote:
> Ben Hutchings wrote...
> 
> > radvd's autoconf test for  has probably failed at least
> > since Linux 2.6.32 when I made sure the kernel headers would never
> > define struct sockaddr for userland:
> > <https://git.kernel.org/linus/9c501935a3cdcf6b1d35aaee3aa11c7a7051a305>
> > 
> > But the conflict between  and  is far
> > older than that, so if the test ever passed it should have resulted in
> > this build failure.  I think that's a clear bug in radvd.  It should
> > use either one or the other, and I think the sensible thing is to use
> >  as it has been doing up until now.
> 
> Certainly I'm not going to advocate radvd's build system - my only
> concern is your change will break more packages out there, mere ten days
> prior to the scheduled release.
> 
> So to me it seems wiser to revert the changes to linux-libc-dev for
> stretch.

Do we still have time to do that?

> Else, someone(tm) would have to test-rebuild all the packages
> that build-depend on linux-libc-dev to check for damage, and provide
> help how to deal with something that technically is a library
> transition.

No it's not.

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#864233: unblock: linux/4.9.30-1

[Ben Hutchings]

On Tue, 2017-06-06 at 01:29 +0200, Axel Beckert wrote:
> Hi,
> 
> Ben Hutchings wrote:
> > This includes many important bug fixes, including security fixes.  It
> > adds support for system reset on Malta boards, additional GPUs on
> > ARM64 systems, and PL011 serial consoles on ARM64 systems.  It makes
> > the efivarfs module available in the installer, which is important for
> > supporting some x86 systems.
> > 
> > The debdiff would be too large for you to review, unfortunately.
> > Instead, here are the changelog entries:
> > 
> > linux (4.9.30-1) unstable; urgency=medium
> 
> JFTR: This upload of linux 4.9.30-1 to unstable made at least one
> package start to FTBFS in unstable, namely radvd. Please see
> https://bugs.debian.org/864269 for details.

radvd's autoconf test for  has probably failed at least
since Linux 2.6.32 when I made sure the kernel headers would never
define struct sockaddr for userland:
<https://git.kernel.org/linus/9c501935a3cdcf6b1d35aaee3aa11c7a7051a305>

But the conflict between  and  is far
older than that, so if the test ever passed it should have resulted in
this build failure.  I think that's a clear bug in radvd.  It should
use either one or the other, and I think the sensible thing is to use
 as it has been doing up until now.

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#864233: unblock: linux/4.9.30-1

[Ben Hutchings]

 check
- dib0700: fix NULL-deref at probe
- zr364xx: enforce minimum size when reading header
- dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops
- digitv: limit messages to buffer size
- dw2102: limit messages to buffer size
- cx231xx-audio: fix init error path
- cx231xx-audio: fix NULL-deref at probe
- cx231xx-cards: fix NULL-deref at probe
- [powerpc*] mm: Ensure IRQs are off in switch_mm()
- [powerpc*] eeh: Avoid use after free in eeh_handle_special_event()
- [powerpc*] book3s/mce: Move add_taint() later in virtual mode
- [powerpc*] pseries: Fix of_node_put() underflow during DLPAR remove
- [powerpc*] iommu: Do not call PageTransHuge() on tail pages
- [powerpc*] tm: Fix FP and VMX register corruption
- [arm64] KVM: Do not use stack-protector to compile EL2 code
- [armhf] KVM: Do not use stack-protector to compile HYP code
- [armhf] KVM: plug potential guest hardware debug leakage
- [armel,armhf] 8662/1: module: split core and init PLT sections
- [armhf] dts: imx6sx-sdb: Remove OPP override
- [arm64] dts: hi6220: Reset the mmc hosts
- [arm64] xchg: hazard against entire exchange variable
- [arm64] ensure extension of smp_store_release value
- [arm64] armv8_deprecated: ensure extension of addr
- [arm64] uaccess: ensure extension of access_ok() addr
- [arm64] documentation: document tagged pointer stack constraints
- [x86] staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out
  memory.
- [x86] staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
- [x86] staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of
  EPROM_CMD.
- [x86] staging: rtl8192e: GetTs Fix invalid TID 7 warning.
- [x86] iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings
- stackprotector: Increase the per-task stack canary's random range from 32
  bits to 64 bits on 64-bit platforms
- uwb: fix device quirk on big-endian hosts
- genirq: Fix chained interrupt data ordering
- nvme: unmap CMB and remove sysfs file in reset path
- [alpha] osf_wait4(): fix infoleak
- tracing/kprobes: Enforce kprobes teardown after testing
- [x86] PCI: hv: Allocate interrupt descriptors with GFP_ATOMIC
- [x86] PCI: hv: Specify CPU_AFFINITY_ALL for MSI affinity when >= 32 CPUs
- PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms
- PCI: Fix another sanity check bug in /proc/pci mmap
- PCI: Only allow WC mmap on prefetchable resources
- PCI: Freeze PME scan before suspending devices
- [armel,armhf] mtd: nand: orion: fix clk handling
- [armhf] mtd: nand: omap2: Fix partition creation via cmdline mtdparts
- mtd: nand: add ooblayout for old hamming layout
- [x86] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
- NFSv4: Fix a hang in OPEN related to server reboot
- NFS: Fix use after free in write error path
- NFS: Use GFP_NOIO for two allocations in writeback
- nfsd: fix undefined behavior in nfsd4_layout_verify
- nfsd: encoders mustn't use unitialized values in error cases
- drivers: char: mem: Check for address space wraparound with mmap()
- [x86] drm/i915/gvt: Disable access to stolen memory as a guest

  [ Aurelien Jarno ]
  * [mips*/*-malta] Enable POWER_RESET and POWER_RESET_SYSCON.

  [ Uwe Kleine-König ]
  * [arm64] Enable DRM modules (Closes: #863344)
  * Ignore ABI changes in chipidea driver

  [ Ben Hutchings ]
  * Ignore ABI changes in ccp and hid-sensors
  * [mips*el/loongson-3] Revert "MIPS: Loongson-3: Select
MIPS_L1_CACHE_SHIFT_6" to avoid ABI change
  * SUNRPC: Refactor svc_set_num_threads()
  * NFSv4: Fix callback server shutdown (CVE-2017-9059) (Closes: #862357)
  * uapi: fix linux/if.h userspace compilation errors (see #822393, #824442)
  * debian/control: Fix compiler build-dependencies for cross-building
(Closes: #863907)
  * Add Debian package version to "hung task" log messages
  * btrfs: warn about RAID5/6 being experimental at mount time (Closes: #863290)
  * [x86] pinctrl: cherryview: Add a quirk to make Acer Chromebook keyboard
work again (Closes: #862723)
  * [arm64] serial: pl011: add console matching function (Closes: #861898)
  * [rt] Add new GPG subkeys for Sebastian Andrzej Siewior
  * [rt] Update to 4.9.30-rt20:
- rtmutex: Deboost before waking up the top waiter
- sched/rtmutex/deadline: Fix a PI crash for deadline tasks
- sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update
- rtmutex: Clean up
- sched/rtmutex: Refactor rt_mutex_setprio()
- sched,tracing: Update trace_sched_pi_setprio()
- rtmutex: Fix PI chain order integrity
- rtmutex: Fix more prio comparisons
- rtmutex: Plug preempt count leak in rt_mutex_futex_unlock()
- futex: Avoid freeing an active timer
- futex: Fix small (and harmless looking) inconsistencies
- futex,rt_mutex: F

Re: Last chance for d-i changes in stretch

[Ben Hutchings]

On Fri, 2017-05-26 at 19:04 +0200, Cyril Brulebois wrote:
> Hi,
> 
> You might have noticed final preparations for d-i Stretch RC 4 are
> underways. A new debian-installer upload (or a binNMU) will need to
> happen before the first stretch release (aka. r0). If there's anything
> you want or would like to include in r0, now is the time to mention it.
[...]

I want to apply the change sent as
<20170423005601.gp4...@decadent.org.uk>, but still haven't found the
time to test it yet.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old
ones.


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