On 09/07/2012 12:25 AM, Marcus Sorensen wrote:
You can disable it in the default build, but still allow it in waf
build, correct? Or at the very least it seems that the RPM build
should ship building the agent with a message saying 'do x y z to
enable KVM first' or some such.

Nobody is going to build an RPM and not want KVM support, it's not
like the citrix or Vmware resources can be used with RHEL/CentOS.


I agree with you.

libvirt-java 0.4.9 isn't far away and that will be MIT licensed.

So everything we do will probably be just be very temporary.

Wido

On Thu, Sep 6, 2012 at 3:40 PM, David Nalley <[email protected]> wrote:
On Thu, Sep 6, 2012 at 4:30 PM, Wido den Hollander <[email protected]> wrote:


On 09/06/2012 08:05 PM, Marcus Sorensen wrote:

Trying to get a working RPM build of 4.0 going... I assume my latest
issue is related to this.  "class not found:
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource", if
someone is building RPMs isn't it safe to assume they want the
kvm/libvirt pieces?  What was Wido's fix? I don't see this patch
applied to maven-waf, just 623f199b0378683e6f5f0c2b2b5c692b6504d16f as
latest.


Sorry, I completely missed this review!

The legal issue with KVM was approved like Elan posted, see LEGAL-144 as I
mentioned in the commit message.

I saw Elan's post on the ml, checked out the legal status and enabled KVM
again since we were allowed to do so :)

Wido



I am not sure that this is my understanding.
Doesn't the 'default build option' have to miss KVM because it
currently doesn't have a license that permits it? Or did we decide to
identify this as a system dependency?

I know we got blessing to produce KVM-inclusive convenience binaries,
but point 1 of the accepted proposal in LEGAL-144 says:
  Disable KVM support in the default build, as per policy.

--David

Reply via email to