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@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@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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home