Prepare to release xen (4.11.1~pre+1.733450b39b-1~exp1).

debian/changelog: mention the vwprintw compile fix

Update to 4.11.1-pre commit 733450b39b

debian/lib/python: Ahem, fix FTBFS

AttributeError: 'VersionXen' object has no attribute 'xen_version'

Since it's already in the master branch, we can't fix it up, whoops.

Add README.md

...so at least something shows up when entering the debian/ directory.

Point to README.source and to the wiki with general info.

README.source: update doc about changelog versions

Let's just mention the available options in here.

debian/lib/python: Again fix recognizing versions

In commit 55129e390c I changed this code to recognize a few patterns,
but it turns out the code was not fully functioning.

Also move determining the treeish to the same place with the version
regex.

See the numbered comments when determining the treeish for valid
patterns:

1. pre version in between stable releases with explicit commit
   e.g. 4.10.2~pre+1.25e0657ed4-1
   -> use commit 25e0657ed4
2. explicit commit while in rc
   e.g. 4.11.0~rc6+1.35fcb982ea-1~exp1
   -> use commit 35fcb982ea
3. release candidate
   e.g. 4.11.0~rc7-1~exp1
   -> use tag 4.11.0-rc7
4. regular release, like 4.10.2
   -> use tag RELEASE-4.10.2

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/patches: Fix 'vwprintw' is deprecated

From the xen-devel mailing list, not committed yet:
https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01718.html

Update to 4.11.0

And refresh patches, which is luckily not that much work this time.

Update to 4.10.2-pre commit b5e9f1e674

debian/changelog: mention init script qemu fix

init scripts: Do not kill per-domain qemu processes.

Drop 2nd start-stop-daemon from qemu_stop_real xen init script.
Closes:#879751.

This code was introduced in
  8ad8a8221d9884b76f6942acabd9465e11ca23bd
  Start a qemu process in dom0 to service the toolstacks loopback disk attaches.

Ie the commit which introduced the global qemu.  There is no
indication that there was any intent to do anything to the per-domain
qemus.

I think the 2nd s-s-d invocation is there to stop a qemu which is for
some reason not mentioned in the pidfile and somehow escaped.  That
seems like a thing we should try to prevent.  I don't think if it
comes to pass, that it can be cleaned up without trashing the domUs.

So remove it.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

debian/scripts/qemu-ifup: don't use ifconfig

ifconfig is from the past (tm), and we didn't depend on net-tools
anyway, so keep it like that.

README.source: genorig improvement

Some rewording etc to make it better readable.

Copy debian_linux python code in here

Add a copy of the contents of
/usr/share/linux-support-4.15.0-2/lib/python/debian_linux from the
linux-support-4.15.0-2 package.

Also, remove the KERNELVERSION from rules.defs and the code in the
debian_xen that checks for the old location of the code and fixup
cleaning in debian/rules.

Now, we don't have to annoy everyone any more with missing
linux-support-x.y.z packages, which change every few months, in order to
be able to work with this source package.

This is a first step in the process of cleaning up and simplifying this
part of the packaging.

debian/patches/misc/version.diff: refresh

Upstream commit aa96a59dc22 touched the context lines.

Update to 4.10.1-pre commit 0f92968bcf

Move grub config into xen-hypervisor-common

The grub config snippet is not arch dependent, neither version
dependent, so it has to move into a 'common' package.

The packages with a version number in their name only have contents that
do not conflict with a previous or next version. Having this file in the
version dependent xen-hypervisor package currently prevents us from
being able to co-install the current and next version of Xen.

Since users who install the whole set of hypervisor and utils via the
meta package undoubtedly also want to get the example grub config,
always install the xen-hypervisor-common package in that case, even if
the user ignores Recommends (like I always do).

Also see #852545

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/changelog: Close #853710: ftbfs with GCC-7

At the moment the new package hits the archive, this bug is not relevant
any more.

debian/bin/genorig.py: hard link orig tar

When building with pbuilder, I end up with a dangling symlink in my
result directory. Why not just hard link it...

debian/changelog: Revert entry about grub

Revert "Move grub config into xen-utils-common"

This reverts commit 8c378bc011fedb954578d8b55d48f0d196e37915.

We're going to do this differently.

Revert "d/t/control-*: bump grub config incompat for now"

This reverts commit b50eb9c0f378350bb1b34b7a0d4b8edec8e32b9e.

debian/templates/control.utils.in: suggest ovmf

Now we've enabled ovmf in the build, it makes sense to hint the user
which package is needed when using that. Only suggest it, since it's an
optional feature.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules.real: enable OVMF

Enable OVMF option. Has no side-effects and doesn't require compile-time
or run-time dependencies until you add bios='ovmf' in a domU cfg.

Also see #858962

debian/changelog: housekeeping

I was rushing a bit two days ago, and started a new version that's not
going to end up in Debian unstable and it's also not tagged, so let's
continue development.

* Cleanup all entries to not include versions that were never actually
  released.
* Add more summary information about the Spectre/Meltdown related
  upstream changes.
* Use an extra leading ~ during development, so that intermediate test
  builds never result in files with the same names as the actual build
  that will be released later.

debian/rules.defs: Update KERNELVERSION

This is the newer of the two versions currently in sid.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

debian/bin/genorig.py: Use assert rather than RuntimeError

That way, bad usage prints something slightly less opaque.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

debian/bin/genorig.py: Defuse `export-subst'

The Xen upstream tree has .gitattributes which cause `git archive' to
change things in .gitarchive-info.  This is troublesome because it
means that tarballs generated by genorig are not identical to the git
trees.

Work around this by temporarily creating a .gitattributes which
disables export-subst.  We move aside any existing .gitattributes, so
that this works whether we are in a Debian packaging branch with
upstream files in, or an upstream branch, or a bare-packaging branch.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Update to 4.10.1-pre commit 3921128fcb

debian/README.source -> debian/README.source.md

Just to have it rendered as markdown in the gitlab web view.

debian/patches: categorize patches in subdirs

Most of the patches are related to the prefix / abiname set.  Sort out
everything in sub directories, so it doesn't look completely like a big
pile of garbage.

Prepare to release xen (4.10.1~pre+1.728fadb586-1~exp1).

Update to 4.10.1-pre, changelog housekeeping

Jump forward to commit 728fadb586 in stable-4.10, which contains the
first few XSA-254 fixes.

Add all missing changelog information about what has happened in the
previous set of commits.

d/t/control-*: bump grub config incompat for now

In 8c378bc011 I moved the grub config file that was wrongly placed
inside the hypervisor package, and assumed that it would be fixed in a
stable update, and that the orig tar would not change before that.
However, we don't know yet what will happen in stretch security.

So, don't assume the fix would happen in a specific version in stable.
For now, bump the cutoff point all the way up to 4.10 so we can lower it
again when the actual fix did happen in stretch.

The end goal is to be able to upgrade from stretch to buster without
this problem.  As long as the fix didn't happen in stable, and we have a
newer xen in unstable, the upgrade will hit the conflict.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/bin/genorig.py: mkdir ../orig

First time someone does this the directory does not exist and you get an
ugly error. I copied this from the debian kernel genorig.py.

Note: currently my biggest annoyance with the placement of the orig file
in ../orig and the symlink to it is that if I run pbuilder, I will end
up with a symlink pointing nowhere in my pbuilder result location
instead of the actual orig, which makes including it into reprepro bork
of course.

For now, I'm making minimal changes to this. We can improve and change
it later. But this change prevents more lines in the README.source for
now.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

dh_shlibdeps: fix missing depend on libxentoolcore

xen-4.10 introduces a depends on libxentoolcore to the libxenstore3.0
package.  To keep the library support for the xenstore-utils minimal,
the libxentoolcore*.so* lib is added to the package, along with its
symbols into libxenstore3.0.symbols. This keeps d/control unchanged.

Signed-off-by: Mark Pryor <pryorm09@gmail.com>

d/t/control.main.in: mention other libraries

Besides the libraries that are mentioned, a bunch of new ones have been
included over time. Just name them in a generic way in the libxen-dev
description.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

New library: xentoolcore

There's a new library in Xen 4.10. It's xentoolcore, which centralizes
handling of open file descriptors for qemu.

Also see upstream b08da5859b,
"xentoolcore, _restrict_all: Introduce new library and implementation"

So:
- just apply the same patch magic for it as seen in other Makefiles
- include relevant things in libxen-dev

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

Refresh existing patches for 4.10

First part of dealing with the upstream changes...

- drop rerun-autogen.sh-stretch.patch, it's in the upstream code
- also include the new uninstall sections (regardless of the fact if
  it's used or not, let's keep things neat and tidy)

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

Update to 4.10

Let's try to see what happens when we throw the packaging code on top of
a 4.10 release!

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

Add debian/README.source

Well, see the text inside. ;-)

d/templates/control.main.in: fix whitespace

The dot would be appended to the first line, ending in:
    [...]interface to XenStore.  .

debian/.gitignore: improve filtering

After doing a full build, it seems there was still stuff not being
ignored correctly. This change should take care of that.

So after debian/rules orig, debian/rules debian/control-real and doing a
package build, there are no files in debian/ showing up as untracked
content. When cleaning out everything using git clean -dfx, there are no
files in debian/ which are listed when doing git status --ignored.

debian/bin/genorig.py: create orig tar for pre/rc

When using versions like 4.9.2~pre+1.32e364c4e7, I want to have an
archive made from commit 32e364c4e7. Same holds for 4.10~rc8+1.3e11e302a8

debian/bin/genorig.py: repair build orig from repo

By picking up the repo provided to the script and kicking the git
archive process into that direction, we can at least do this now:

   ~/build/xen/debian-xen (master) 6-$ debian/bin/genorig.py ~/src/git/xen
   Generate tarball ../orig/xen_4.9.1.orig.tar.xz

...given that the newest changelog entry is e.g. 4.9.1-1

There's probably more things that can be improved in here, but let's
take one step at a time.

Update to 4.9.2~pre+1.32e364c4e7

So, to reiterate... the orig tar will just be made from commit
32e364c4e7 in the upstream repo. And if we advance to a later point
before 4.9.3 is released, then it'll get 4.9.2~pre+2.<commitid> etc...

Update the packaging for Xen 4.9. I took these changes from the Xen 4.9
packaging in Ubuntu done by Stefan Bader. Thanks!

debian/patches: Use ab style filenames

debian/patches: Remove X-Dgit-Generated

I'm not going to use Dgit, but rather track all changes in a more
granular way. Remove the obsolete headers.

debian/rules: Add orig command

I copied this one from the linux team. It combines the orig file with
the packaging, so we can start using quilt to refresh the patches.

Move grub config into xen-utils-common

The grub config snippet is not arch dependent, neither version
dependent, so it has to move into a 'common' package.

The packages with a version number in their name only have contents that
do not conflict with a previous or next version. Having this file in the
version dependent xen-hypervisor package currently prevents us from
being able to co-install the current and next version of Xen.

So, I can do this here for new packages in unstable but that will only
fix upgrades from xen 4.9 to 4.10. The same change still needs to go
into a stable update to solve the problem for upgrades from Stretch to
Buster.

Also see https://bugs.debian.org/852545

debian/lib/python: Recognize pre / rc versions

    When tracking the latest upstream versions in Debian unstable, I'd
like to keep the packages updated with latest available security patches
which are available when working on a new upload. So that means not
always working with an exact tagged upstream release.

There are two possible approaches when doing this:

1. Use the latest official release as orig tar and keep the rest of the
changes in debian patches. This is also what we would do for security
updates to stable.
2. Just follow the upstream stable branch lines (they will always fix
forward) and keep the latest changes in the orig tar.

I think option 2 makes the most sense for uploads to unstable when we're
nowhere near to a freeze yet. This results in version numbers like
4.9.2~pre+1.32e364c4e7-1, where the 1 is simply a helper because git
commit ids are not sortable. 4.9.1+1.32e364c4e7-1 would also be an
option, but since xen will report itself als 4.9.2-pre (e.g. in xen info
output), I prefer the ~pre one.

    When testing new versions that are in rc state upstream, we might
put them in the Debian experimental distribution, so that we can find
out what needs to be done to the packaging already, and so that we
provide the opportunity for Debian users to help testing the new release
on their hardware.

These versions will usually look like e.g. 4.10~rc8-1~exp1, but
incidentally they could also include a few newer corrections, in which
case we end up with a git revision again, like seen above, but then with
rcX instead of pre and now the second pattern choice, because upstream
doesn't let us know if there will be a next rc, or the actual release.
So, that would be something like 4.10~rc8+1.3e11e302a8-1~exp1

    This change allows both of these version patterns. While only the
major.minor version is used from it all, it's a nice sanity checker to
prevent eventual mistakes.

Allowed:
 * 4.9.2-1
 * 4.9.2~pre+1.32e364c4e7
 * 4.10~rc8-1~exp1
 * 4.10~rc8+1.3e11e302a8-1~exp1

Not allowed:
 * 4.10-1

Adjust to linux-support-4.9.0-4

This package uses some code from the linux-support package to generate
files. The way in which this done in the packaging is similar to how the
linux source package is managed.

debian/rules.defs defines a KERNELVERSION which requires you to have the
linux-support-$KERNELVERSION package installed.

For now, update it to 4.9.0-4, since that's the current latest in
Stretch. I'm working on the packaging on a stretch system.

After doing so...
    -$ make -f debian/rules debian/control-real
    [...]
      File "/usr/src/linux-support-4.9.0-4/lib/python/debian_linux/gencontrol.py", line 124, in do_main_recurse
          for featureset in self.config['base', ]['featuresets']:
    KeyError: 'featuresets'

Apparently the newer linux-support requires featuresets to be set. We
simply add it with only the option none, since we don't use it.

debian/patches: Remove 4.8 security patches

I'm preparing a 4.9 or 4.10 release, so no need to keep these.

Import xen_4.8.2+xsa245-0+deb9u1

But, fix the .gitignore while doing so. It was ignoring way too much
(e.g. tree/xen-utils-common) and not ignoring some of the generated
content (e.g. control.md5sum).

The orig tar that belongs to this debian version is created from this
commit in xen/stable-4.8:

    commit 9ba6783e47db71379c5120039b878f605bdf31f3
    Author: Andrew Cooper <andrew.cooper3@citrix.com>
    Date:   Thu Nov 16 11:55:47 2017 +0100

    x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()