Hi guys,
As we discussed in the last CentOS SIG Virt meeting below the steps that we do to rebuild the qemu-kvm from http://vault.centos.org to enable the rhev-features like live snapshot for CentOS.
1. Download the last qemu-kvm from http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/
2. mock -D "${build_version}" -r epel-6-x86_64 --with=rhev-features --rebuild "${WORKSPACE}"/rpms/${qemu_kvm} --resultdir="${WORKSPACE}"/rpms --cleanup-after
As you can see we don't bump the release at moment, please let me know your thoughts. If there is any volunteer to take owner of this package in the SIG group please let me know, otherwise I can take it.
Here the jenkins URL: http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/
Thanks!
Is the plan to get the qemu-kvm build provided by CentOS to include the "rhev-features"? I recently updated to oVirt 4.1 and while my hypervisors were in maintenance I performed an update of all packages, including qemu-kvm and noticed the latest version (0.12.1.2-2.415.el6_5.8) in the CentOS repos still does not include live snapshot capability.
Any suggestion on how to version my internal rebuild of qemu-kvm to prevent CentOS's RPM being installed? My initial attempt is the following:
mock -D "dist .el6_5" -D "buildid .local" -r epel-6-x86_64 --with=rhev-features \ --rebuild /home/treydock/qemu-kvm/qemu-kvm-0.12.1.2-2.415.el6_5.8.src.rpm \ --resultdir=/home/treydock/qemu-kvm/rpms/local \ --cleanup-after
The resulting RPMs still contain the same version as CentOS's builds. Do I need to extract the SRPM, modify the spec, then rebuild a SRPM built using the modified spec?
Thanks - Trey
On Thu, May 22, 2014 at 12:30 PM, Douglas Schilling Landgraf dougsland@redhat.com wrote:
Hi guys,
As we discussed in the last CentOS SIG Virt meeting below the steps that we do to rebuild the qemu-kvm from http://vault.centos.org to enable the rhev-features like live snapshot for CentOS.
- Download the last qemu-kvm from
http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/
- mock -D "${build_version}" -r epel-6-x86_64 --with=rhev-features
--rebuild "${WORKSPACE}"/rpms/${qemu_kvm} --resultdir="${WORKSPACE}"/rpms --cleanup-after
As you can see we don't bump the release at moment, please let me know your thoughts. If there is any volunteer to take owner of this package in the SIG group please let me know, otherwise I can take it.
Here the jenkins URL: http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/
Thanks!
-- Cheers Douglas _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Hello Trey,
On 05/23/2014 11:32 AM, Trey Dockendorf wrote:
Is the plan to get the qemu-kvm build provided by CentOS to include the "rhev-features"?
Yes, we have been discussing about provide this rebuild via CentOS Virt SIG. Thanks for joining this thread, this shows how required this rebuild is.
I recently updated to oVirt 4.1 and while my hypervisors were in maintenance I performed an update of all packages, including qemu-kvm and noticed the latest version (0.12.1.2-2.415.el6_5.8) in the CentOS repos still does not include live snapshot capability.
Correct, sorry about that.
Any suggestion on how to version my internal rebuild of qemu-kvm to prevent CentOS's RPM being installed? My initial attempt is the following:
mock -D "dist .el6_5" -D "buildid .local" -r epel-6-x86_64 --with=rhev-features \ --rebuild /home/treydock/qemu-kvm/qemu-kvm-0.12.1.2-2.415.el6_5.8.src.rpm \ --resultdir=/home/treydock/qemu-kvm/rpms/local \ --cleanup-after
The resulting RPMs still contain the same version as CentOS's builds. Do I need to extract the SRPM, modify the spec, then rebuild a SRPM built using the modified spec?
What do you meant the same version? This command don't bump the release, so it should generate the same rpm version. However, oVirt team already provides rebuilds from all qemu-kvm packages provided by CentOS enabling this feature, every day we check for new version of qemu-kvm package and rebuild if it exists, please go to: http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/lastSuccessfulBui...
===== In case you would like to run a script === WORKSPACE="your-workspace-dir" for version in '6.5' # '6.6' '6.7' '6.8' '6.9' do QEMU_KVM_LATEST_SRC_RPM=`curl -s http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/ |grep -o -E 'href="([^"#]+)"' | cut -d'"' -f2 | sort -r | uniq | grep qemu-kvm`
for qemu_kvm in ${QEMU_KVM_LATEST_SRC_RPM} do QEMU_KVM_LATEST_RPM=`basename ${qemu_kvm} .src.rpm`.x86_64.rpm if [ ! -f "${WORKSPACE}"/rpms/${qemu_kvm} ]; then wget -P "${WORKSPACE}"/rpms http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/$%7Bqemu_kvm... fi dist='dist .el' build_version=${dist}${version//[.]/_} if [ ! -f "${WORKSPACE}"/rpms/${QEMU_KVM_LATEST_RPM} ]; then sudo mock -D "${build_version}" -r epel-6-x86_64 --with=rhev-features --rebuild "${WORKSPACE}"/rpms/${qemu_kvm} --resultdir="${WORKSPACE}"/rpms --cleanup-after fi done done ==============
I would love to see this script or similar one (bumping the release?) running on CentOS SIG and after that executing createrepo command.
On 05/23/2014 03:45 PM, Douglas Schilling Landgraf wrote:
Hello Trey,
On 05/23/2014 11:32 AM, Trey Dockendorf wrote:
Is the plan to get the qemu-kvm build provided by CentOS to include the "rhev-features"?
Yes, we have been discussing about provide this rebuild via CentOS Virt SIG. Thanks for joining this thread, this shows how required this rebuild is.
I recently updated to oVirt 4.1 and while my hypervisors were in maintenance I performed an update of all packages, including qemu-kvm and noticed the latest version (0.12.1.2-2.415.el6_5.8) in the CentOS repos still does not include live snapshot capability.
Correct, sorry about that.
Any suggestion on how to version my internal rebuild of qemu-kvm to prevent CentOS's RPM being installed? My initial attempt is the following:
mock -D "dist .el6_5" -D "buildid .local" -r epel-6-x86_64 --with=rhev-features \ --rebuild /home/treydock/qemu-kvm/qemu-kvm-0.12.1.2-2.415.el6_5.8.src.rpm \ --resultdir=/home/treydock/qemu-kvm/rpms/local \ --cleanup-after
The resulting RPMs still contain the same version as CentOS's builds. Do I need to extract the SRPM, modify the spec, then rebuild a SRPM built using the modified spec?
What do you meant the same version? This command don't bump the release, so it should generate the same rpm version. However, oVirt team already provides rebuilds from all qemu-kvm packages provided by CentOS enabling this feature, every day we check for new version of qemu-kvm package and rebuild if it exists, please go to: http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/lastSuccessfulBui...
===== In case you would like to run a script === WORKSPACE="your-workspace-dir" for version in '6.5' # '6.6' '6.7' '6.8' '6.9' do QEMU_KVM_LATEST_SRC_RPM=`curl -s http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/ |grep -o -E 'href="([^"#]+)"' | cut -d'"' -f2 | sort -r | uniq | grep qemu-kvm`
for qemu_kvm in ${QEMU_KVM_LATEST_SRC_RPM} do QEMU_KVM_LATEST_RPM=`basename ${qemu_kvm} .src.rpm`.x86_64.rpm if [ ! -f "${WORKSPACE}"/rpms/${qemu_kvm} ]; then wget -P "${WORKSPACE}"/rpms
http://vault.centos.org/$%7Bversion%7D/updates/Source/SPackages/$%7Bqemu_kvm... fi dist='dist .el' build_version=${dist}${version//[.]/_} if [ ! -f "${WORKSPACE}"/rpms/${QEMU_KVM_LATEST_RPM} ]; then sudo mock -D "${build_version}" -r epel-6-x86_64 --with=rhev-features --rebuild "${WORKSPACE}"/rpms/${qemu_kvm} --resultdir="${WORKSPACE}"/rpms --cleanup-after fi done done ==============
I would love to see this script or similar one (bumping the release?) running on CentOS SIG and after that executing createrepo command.
Hello,
I would like to continue this process in the SIG Virt. Any advice/steps which I should follow?
Thanks!
On 04/06/2014 20:17, Douglas Schilling Landgraf wrote:
Hello,
I would like to continue this process in the SIG Virt. Any advice/steps which I should follow?
Thanks!
Douglas, we are not ignoring you. As it turns out there are quite a few unknown pieces related to the libvirt version for this SIG and there was also a discussion with Dan Kenigsberg at last week's Hackathon. I don't have the technical depth to go through your proposal. Added George. Lars