[Pkg-xen-devel] [Xen-devel] HVM support to be removed from Debian Squeeze: call for volunteers

[Thomas Goirand]

Ian Jackson wrote:
>> Yes, because Debian uses versionned folders for /usr/lib/xen. Maybe we
>> could overwrite this in the Makefile with a variable. That's what I did
>> for numerous projects so that "make install" could be used by a spec
>> file using "make install MANUAL_DIR=%{_mandir}" for example. What do you
>> think? Could this apply to this project?
> 
> I've been thinking about this and I'm not sure the versioned folders
> still make sense.  But if you want to send sensible patches to the Xen
> build system to allow the interposing of a version number, I guess we
> would accept them (after review).

I don't think it does either, but since Bastian and others want it, I
don't see why we shouldn't support it. I'll try to make a patch, yes.

>>> But partitioning the output of `make dist-tools' etc. to provide
>>> something that can be used for qemu-dm build should be easy enough.
>> What do you mean here here? What's the use of "make dist-tools"?
> 
> It's one of the targets in the upstream top-level Makefile.  The Xen
> top-level Makefile doesn't use the conventional target names.
> "dist-foo" means install "foo" in dist/install/.

Strange! :)

> To build qemu-dm you need two things: the actual source code to
> qemu-dm which is in a separate repository.  When we make the official
> Xen tarballs we don't provide a separate tarball; we include it in the
> same tree.  But the xen-unstable tree downloads the qemu-dm source
> from the git repository.
> 
> So I would suggest you invent an orig.tar.gz by using git-archive
> after fetching a suitably tagged qemu tree from
>  git://xenbits.xensource.com/qemu-xen-VERSION.git

Ok, I'll start from that. In fact, I'm quite happy xen-qemu is on Git
and not hg, as it's been years that I am used to git. But however...

In Lenny:

zigo at GPLHost:buzzig>_ /usr/src/xen$ git clone
http://xenbits.xensource.com/qemu-xen-3.4-testing.git
Initialized empty Git repository in /usr/src/xen/qemu-xen-3.4-testing/.git/
warning: remote HEAD refers to nonexistent ref, unable to checkout.

In SID:

root at GPLHost:xen018407>_ ~/sources/gplhost# git clone
http://xenbits.xensource.com/qemu-xen-3.4-testing.git
Initialized empty Git repository in
/root/sources/gplhost/qemu-xen-3.4-testing/.git/
fatal: http://xenbits.xensource.com/qemu-xen-3.4-testing.git/info/refs
not found: did you run git update-server-info on the server?

What's wrong here?

> The other thing you need is the development headers and libraries
> whose source code is in the Xen hg tree.  The qemu-dm source code
> isn't set up for building from an "installed" copy of those libraries.
> For example it includes, at build-time, fragments of makefiles from
> the Xen build tree.
>
> It would probably be possible to make a build work given a version of
> these libraries and headers.  I can help with this but first we need a
> libxen-dev package that contains libxc, libxs, libxenguest, etc.

That sounds, indeed, the way to go.

>> Can you start a project on Alioth, with a git repo? Would it be useful
>> (I never used alioth or gforge yet)?
> 
> I'm happy to do that.  I'll try to get that set up.  I find Alioth's
> git support confusing at times so it may not happen right away.
> 
> Ian.

I really don't know gforge, so again, it might not be the way to go. I
do have a public git myself, so if you can use the one of xensource,
that could be enough. Just please, let me know why I can't clone! :)

Thomas