Hi, <br><br><div class="gmail_quote">On Tue, Jun 14, 2011 at 3:29 AM, Steffen Möller <span dir="ltr"><<a href="mailto:steffen_moeller@gmx.de">steffen_moeller@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Neil,<br>
<div><div></div><div class="h5">On 06/08/2011 08:33 AM, graziano obertelli wrote:<br>
> On Tue, Jun 07, 2011 at 09:41:44AM +0200, Steffen Möller wrote:<br>
>> On 06/07/2011 04:35 AM, Rudy Godoy Guillén wrote:<br>
>>> Hello, I'm subscribed finally. I'm currently the guy working for GSoC<br>
>>> project: Compute clusters integration for Debian development. Which means<br>
>>> using Eucalyptus for cross-building.<br>
>>><br>
>>> Over the weekend I've sucessfully built the Eucalyptus 2.0.3 offline version<br>
>>> from upstream. Although I haven't checked the debian-related patches you<br>
>>> could have done (cdn.d.n appears down), I observed many issues that might<br>
>>> need some work.<br>
>>><br>
>>> I have some comments:<br>
>>> - Do you guys have set a repo for the packaging bits?<br>
>> There is the pkg-eucalyptus subversion repository. The one on<br>
>> pkg-escience is outdated and the git one that Charles I recall to have<br>
>> created was never adopted, really. Correct me if I am wrong ....<br>
>> The packages we can IMHO directly upload to unstable - we should just<br>
>> submit some bug to it that prevents its migration to testing for the<br>
>> start. Once that is up, let me then upload a version to<br>
>> <a href="http://backports.debian.org" target="_blank">backports.debian.org</a>.<br>
>>> - How will be versions handled, upstream says it's 2.0.3 but the changelog<br>
>>> isn't updated accordingly, so the resulting binaries are versioned 1.6.2.<br>
>> Uuuuuuuuh, please adjust the changelog, then :)<br>
> neil is the authoritative answer here, but I think that what is in our<br>
> sources is actually obsolete, and not currently used. Before working on<br>
> those you may want to wait for him to confirm that we want to work off<br>
> those.<br>
</div></div>I am not sure about who is subscribed to the pkg-eucalyptus mailing<br>
list. So I just explicitly added Rudy and yourself to the CC. Rudy has<br>
basically two tasks at hand<br>
a) allow Eucalyptus to start ARM images<br></blockquote><div><br>For this item, I've identified where the source node would need to be tweaked. node/handler_kvm.{h,c} is the place. I would like you to confirm this, and point me to any other source that I might need to touch.<br>
>From what I've seen most of the job is on the libvirt side, which works quite nicely under Debian, so this makes feasible to hook-up arm as an Euca node. I'm still have to test my updated arm image in a CPU with kvm extensions so it uses qemu-kvm hypervisor as host that is able to run guests using qemu-system-<any>. I welcome any help on that side. If you can provide access to a host where I can run qemu-kvm as hypervisor.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
b) update the Debian packaging.<br></blockquote><div><br>Yes, this will have to happen at some point and I prefer to work with the correct sources from the begining, if possible.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

For a), I had felt that the exact version of the source may not be too<br>
important, it should just not be too much off from what you are using.<br>
To have b) would help the development of a), and it all may have gotten<br>
some extra value for you since the last weeks. And indeed, with stronger<br>
differences in the source tree, this should better be started all on the<br>
right versions from the start.<br>
<br></blockquote><div><br>Correct.<br><br> thanks!<br></div></div><br clear="all"><br>-- <br>Rudy Godoy<br><a href="http://stone-head.org" target="_blank">http://stone-head.org</a><br><br>