[Pkg-xen-devel] [PATCH 0/3] More work towards viable Xen cross-builds

[Elliott Mitchell]

I guess we're starting a series of you (Hans van Kranenburg) do some
updates, and then I do some updates.

The first patch is a small packaging bug.  The Xen build needs Python
for 2 distinct purposes.  First, it is needed for portions of the build
process itself (notably building the runtime Python
interface/"distutils").  Second, it is needed for linking the runtime
portion together.  The first needs *any* variant of the python3-dev
package (build machine variant is fine), second needs the host machine
libpython3-dev package.  Having seen other packages, this is
"python3-dev:any" and "libpython3-dev", *not* "python3-dev".

Next is a portion I've passed to xen-devel.  When doing cross-building
the compiler/linker selection is crucial.  The default search for them
will get the build versions, rather than the host versions.  Similar to
the Debian package, the upstream source wasn't passing the chosen linker
to the Python build and hence was attempt to link for the build machine
rather than the host machine.  Also turned out linker options for
linking an executable were being passed instead of for linking a shared
object.

Last patch is an update of the "Disable OCAML build when cross-building"
patch.  During some searching I ran across the "Debian Build Profile
Specification" (https://wiki.debian.org/BuildProfileSpec) this covers one
of the OCAML issues I've been running into.  Notably the dependancy on
ocaml-nox/ocaml-findlib should only be enforced if *not* cross-building.

The actual mechanism is the profile spec has a "noocaml" profile.  If
this is active, simply skip the OCAML portions or for the two expected
files create empty ones.  Question is how bug #774129 will be fixed?
Potentially there is a need to turn this on in presence of the "cross"
profile, but `dpkg-dev` could readily take care of this for Xen and most
other packages, but #774129 may not be resolved this way.


Given the situation it really looks like the Xen packages should be
broken up further.  Several pieces included in the main packages are
optional or have other options.  oxenstored is one such extra which is
pretty well entirely optional.

Notably pvgrub is rather better than pygrub in most situations, yet
pygrub remains built-in and you have to search for pvgrub.  I would tend
to propose creating a virtual package "xen-domu-bootloader" and have
"xen-pygrub" provide that (instead of xen-utils-X.Y directly
recommending, what if something else showed up?).


Some of the recommendations on the Debian Wiki appear not to match
reality.  Reducing the number of vCPUs given to Domain 0 on start reduces
some overhead on Domain 0.  On the flip side Xen won't initialize ACPI
C-states on processors which lack an associated Domain 0 vCPU.  Also
need to modify the init script to load xen_acpi_processor.


Elliott Mitchell (3):
  debian/control: Fix python dependancy
  tools/python: Pass linker to Python build process
  debian/rules: Setup use of noOCAML profile

 debian/control        |  7 ++++---
 debian/rules          | 17 +++++++++++++++--
 tools/pygrub/Makefile |  8 ++++----
 tools/python/Makefile |  9 +++++----
 4 files changed, 28 insertions(+), 13 deletions(-)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445