The packages we should build are restricted by:
* Package configuration in debian/config (limits which binary packages are
included in debian/control)
* Architecture (specified per package in debian/templates/control.* and
then in debian/control)
* Build profile (specified per package in debian/templates/control.* and
then in debian/control)
The logic for these restrictions is currently repeated in
debian/rules.real, but sometimes it becomes inconsistent with
debian/control (as with my recent changes for libbpf).
dh_listpackages reads debian/control and filters it by the current
host architecture and build profiles, so that it reliably reports
which packages we should build.
Therefore:
* Replace the logic in debian/rules.real with checks for package names
in the output of dh_listpackages
* Remove the redundant flag variables passed by debian/rules and
debian/rules.gen
* Remove the special-casing of stage1 in debian/rules and
debian/rules.gen
Drop iomap-Revert-fs-iomap.c-get-put-the-page-in-iomap_pa.patch
Drop usb-hso-fix-oob-memory-access-in-hso_probe-hso_get_config_data.patch
Add bug closer for #917569
Cleanup debian/changelog file
Python 3.7 warns:
.../debian/lib/python/debian_linux/debian.py:403: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
class PackageArchitecture(collections.MutableSet):
On powerpc architectures that may use a bootwrapper, we create a
temporary build_<arch>_<featureset>_<flavour>_bootwrapper directory
for each kernel configuration to hold the related tools which we won't
install for real (because they are always native).
This directory is then matched by the wildcard used in building
linux-config, causing linux-config packages to contain spurious
(empty) kconfig files based on these directories in addition to the
real kconfig files.
Rename the temporary directory to avoid matching that wildcard.
In unstable, linux-image-*-unsigned packages and any corresponding
metapackage updates tend to be available a few hours before the
corresponding signed packages. An automatic upgrade with aptitude (at
least) may then install the unsigned kernel where a signed kernel
was previously used, resulting in boot failure.
I gave the linux-image-*-unsigned packages a Provides relation to the
unsuffixed (i.e. signed) package name because I thought packages built
by module-assistant generally depended on the corresponding kernel
package. That may have been true once but doesn't appear to be so
now.
So the Provides field can be harmful and doesn't appear to be useful,
and should be removed.
The current check has never worked because the find -path predicate
matches against the whole path, including the given root. In this
case that is $DESTDIR which always includes the version string.
Change to use cd before find.
Also, check all non-directories rather than all entries with "perf" in
the name.
Backport Amazon ENA ethernet driver version 2.0.2 from Linux 4.20
This mostly ammounts to cherry-picking the commits in the range described by
git log v4.19.5..v4.20-rc7 drivers/net/ethernet/amazon
Change e641e99f261f5203a911a9e0db54a214460d2cc4 introduced changes outside the
ena directory, but only removed a redundant #include and was trivial to scope
down.
Upstream dealt with merge conflicts in
d864991b220b7c62e81d21209e1fd978fd67352c; the resolution here was identical to
upstream.
tl;dr: Xen PVH is the perfect upgrade path from PV and in combination
with grub2 support, it's the Xen "killer feature" we really should have
in Buster.
Background info about Xen PVH:
https://wiki.xen.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode
PVH mode in Xen, a.k.a. "HVM without having to run qemu" is a Xen guest
type best supported since Xen 4.11 and Linux kernel 4.17. Just like when
using PV mode, the guest does not have an emulated BIOS and the guest
kernel is directly started by the dom0. Buster will ship with Xen 4.11.
Why is PVH interesting?
1. When the whole Meltdown/Spectre story started, it quickly became
apparent that 64-bit PV is the most problematic virtualization mode to
protect and to protect from, since address space from the hypervisor and
other guests (including dom0) is reachable from a 64-bit PV domU. To
mitigate this, XPTI (the Xen variant of PTI) has been implemented in the
hypervisor, but with a performance hit. HVM (so, also PVH) guests are
better isolated from the hypervisor and other guests. Inside the guest a
choice can be made about which mitigations to enable or not. Also see
https://xenbits.xen.org/xsa/advisory-254.html
2. Unlike HVM, it's not needed to have a boot loader/sector, partitions,
and a qemu process in the dom0 (using cpu and memory and having an
attack surface). Also, when running a largeish amount of domUs on a
physical server, not having all the qemu processes is an advantage.
3. Unlike PV, PVH makes use of all hardware features that accelerate
virtualization.
The upgrade path from PV to PVH is super optimal. It's just setting
type='pvh' in the guest file and doing a full restart of the domU!
Unless... (insert Monty Python's Dramatic Chord!)
Unless... grub2 was used to boot the PV guests.
Why is it interesting to be able to use grub?
Without using grub in between, the guest kernel and initrd have to be
copied out of the guest onto the dom0 filesystem, because the guest has
to be booted with them directly. Currently, we already have the
grub-xen packages in Debian, which provide grub images which can be used
as kernel for a PV guest, after which it can load the actual linux
kernel that is symlinked from /vmlinuz on the guest filesystem at that
moment.
The final changes to the Linux kernel for grub+PVH are in Linux 4.20.
This request, to carry a few patches from Linux 4.20, provides one half
of the dots that need to be connected to make the full thing happen for
Buster.
Since we'll have Xen 4.11 in Buster, PVH is supported. The related grub2
patchset was committed to the grub master branch on Dec 12 2018 (yup,
today). So, I'll also start contacting the debian grub team soon to ask
(and help) to get the current grub-xen functionality in Debian to be
extended with PVH capabilities as well.
Test reports:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01913.htmlhttps://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03312.html
Ben Hutchings
John Paul Adrian Glaubitz
Salvatore Bonaccorso
Romain Perier
Uwe Kleine-König
Romain Perier
Bastian Blank
Noah Meyerhans
Hans van Kranenburg
Christoph Anton Mitterer
Hilko Bengen