[pkg-eucalyptus-maintainers] [Debian] Re: Eucalyptus 2.0.3 build

[Rudy Godoy Guillén]

Hi,

On Tue, Jun 14, 2011 at 3:29 AM, Steffen Möller <steffen_moeller at gmx.de>wrote:

> Neil,
> On 06/08/2011 08:33 AM, graziano obertelli wrote:
> > On Tue, Jun 07, 2011 at 09:41:44AM +0200, Steffen Möller wrote:
> >> On 06/07/2011 04:35 AM, Rudy Godoy Guillén wrote:
> >>> Hello, I'm subscribed finally. I'm currently the guy working for GSoC
> >>> project: Compute clusters integration for Debian development. Which
> means
> >>> using Eucalyptus for cross-building.
> >>>
> >>> Over the weekend I've sucessfully built the Eucalyptus 2.0.3 offline
> version
> >>> from upstream. Although I haven't checked the debian-related patches
> you
> >>> could have done (cdn.d.n appears down), I observed many issues that
> might
> >>> need some work.
> >>>
> >>> I have some comments:
> >>> - Do you guys have set a repo for the packaging bits?
> >> There is the pkg-eucalyptus subversion repository. The one on
> >> pkg-escience is outdated and the git one that Charles I recall to have
> >> created was never adopted, really. Correct me if I am wrong ....
> >> The packages we can IMHO directly upload to unstable - we should just
> >> submit some bug to it that prevents its migration to testing for the
> >> start. Once that is up, let me then upload a version to
> >> backports.debian.org.
> >>> - How will be versions handled, upstream says it's 2.0.3 but the
> changelog
> >>> isn't updated accordingly, so the resulting binaries are versioned
> 1.6.2.
> >> Uuuuuuuuh, please adjust the changelog, then :)
> > neil is the authoritative answer here, but I think that what is in our
> > sources is actually obsolete, and not currently used. Before working on
> > those you may want to wait for him to confirm that we want to work off
> > those.
> I am not sure about who is subscribed to the pkg-eucalyptus mailing
> list. So I just explicitly added Rudy and yourself to the CC. Rudy has
> basically two tasks at hand
> a) allow Eucalyptus to start ARM images
>

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.
>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.



> b) update the Debian packaging.
>

Yes, this will have to happen at some point and I prefer to work with the
correct sources from the begining, if possible.


> For a), I had felt that the exact version of the source may not be too
> important, it should just not be too much off from what you are using.
> To have b) would help the development of a), and it all may have gotten
> some extra value for you since the last weeks. And indeed, with stronger
> differences in the source tree, this should better be started all on the
> right versions from the start.
>
>
Correct.

 thanks!


-- 
Rudy Godoy
http://stone-head.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/attachments/20110614/8d62d72a/attachment-0001.html>