[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] HVM support to be removed from Debian Squeeze: call for volunteers
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |