My first thought on seeing this thread was "Is there some reason to compile from source, rather than from an SRPM, say those at http://dev.centos.org/centos/6/xen-c6/SRPMS/ ?" I went ahead and grabbed RHEL 7 beta from http://ftp.redhat.com/pub/redhat/rhel/beta/7/, where the actual bootable iso's and accessible yum epository actually live, without the burdensome RHEL registration process. I understand there are benefits to registering a temporary license, just to be able to submit your reports to the registered channels, but *sheesh*. The "you must permit our friends to spam you to register for a beta is nasty, which is why I dug around for that http://ftp.redhat.com/pub/redhat/rhel/beta/7 direct access. And it's a *lot* easier to use that website for installation, or setting up a local mirror, than to register with RHEL on this particular project. I love RHEL service and support pricing, aand their software attitudes, I use them along with CentOS and Scientific Linux for various projects, but their registratioin for this project scared me of becuase of the "let us spam you" agreeement required for registration. After trying to build the SRPM's on RHEL 7 Beta myself I found that the current CentOS Xen publisned SRPM's are quite good. And I say this as the guy who first published SRPM's for Xen, while I was working for the BBC some years back. I'd use the SRPM's over a source download and compilation in a heartbeat. Unfortunately, they don't build on RHEL 7 Beta yet, but it looks like that's a compiler change problem, not an SRPM problem per se. For any of the CentOS Xen project developers here, they're good: Just grab the SRPM's and build up the toolchan in the new environment. But trying to build from the SRPM's resolved all the build dependency, including satisfying the requirement for the openssl-devel and dev86 dependencies that you encountered. And the dev86 SRPM's published there worked well, with the caveat that it did not have a "gcc" dependencies, which I've added to a .spec file, and the .spec file for dev86 and for Xen both have badly formatted dates in the "%changelog" stanza. RHEL 7 is much less tolerant of this than RHEL 6 was. Again, I've edited some .spec files and will try to submit some patches if I can fiind time. Once I'd satisfied all the dependencies for the SRPM, I was able to build the Xen 4.3.1 tarball pretty easily. It just didn't work well to plug the tarball into the old SRPM and .spec file. A whole stack of the patches have already been incorporated, such as almost all of the xsa patches, and other patches that were designed to optimize RHEL/CentOS compilation just fail to install on the new codebase. Updating to Xen 4.3.1 is its own whole project, on RHEL 7 or CentOs 6, one I don't have time for myself and wish the project maintainers great success with. But with all that said: why are you bothering with Xen when RHEL and thus CentOS have KVM support built right in? Is there some feature you require that isn't available in the built-in KVM support? _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
