[Pkg-xen-devel] XCP and OpenXenCenter

[Mike McClurg]

On Sun, Jul 10, 2011 at 6:03 PM, Thomas Goirand <thomas at goirand.fr> wrote:
> On 07/10/2011 02:37 AM, Mike McClurg wrote:
>> On Thu, Jul 7, 2011 at 8:48 PM, Ritesh Raj Sarraf <rrs at debian.org> wrote:
>>>
>>> Hello Mike,
>>>
>>>
>>> On this topic, I noticed that Thomas had started the discussion earlier
>>> in May 2011. http://www.gossamer-threads.com/lists/xen/api/205934
>>>
>>
>> Yes, Thomas has offered to help us on the Debian packaging front.
>> We've just gotten our repositories to the state where we are ready for
>> external help for packaging. Thomas, Jon or I will email you next week
>> to show you what we have got so far.
>
> That's great! I'll start trying to build using the patches and
> instructions you gave on your previous message.
>
>> Fortunately, we don't need to upstream those packages for our Debian
>> port to work. So far, the only component that we'll have to modify
>> upstream is the Debian Xen package, and most of that work is exposing
>> the standard Xen OCaml libraries and backporting some changes from Xen
>> 4.1.1 -- no major surgery.
>
> If it's in 4.1.1, it will soon reach SID, no? I didn't check: is Xen
> 4.1.1 already released?
>

Yep! Here's the announcement:
http://blog.xen.org/index.php/2011/06/15/xen-4-1-1-maintenance-release-available/

> Anyway, if we need such features, we wont be able to upload the package
> into Debian unless we have the necessary build-dependency in. I would
> suggest you to at least send a bug report against the xen package in
> Debian, with the necessary patches attached, rather than just put
> patches in the pkg-xen-devel list.
>

Yes, we'll take care of filing these bug reports. We weren't sure of
the correct protocol.

>> There are four major components that will need to be turned into
>> Debian packages:
>>
>> - blktap2, which is a combination kernel module and userland daemon
>> for managing storage
>>
>> - xen-api, which contains a number of daemon and etc and init.d
>> scripts for starting and configuring the daemons
>>
>> - xen-api-libs, which is a set of OCaml libraries used to build xapi,
>> the main xen-api daemon
>>
>> - xen-api-sm, which contains a number of storage management backends,
>> typically written in Python
>>
>> Depending what the the Debian packaging guidelines say, there may be a
>> one-to-one correlation between those components and the packages that
>> we create. I'm betting, though, that we may have to split them up into
>> sub-packages (forgive me if I'm abusing terminology here).
>
> Can you give the corresponding "git clone" url for the above 4 packages?
> Or is it that they are all to be found in one unique source code, and we
> should only build multiple binary packages out of the sources?
>

Check out Jon Ludlam's github: https://github.com/jonludlam . The
repositories you'll be interested in are xen-debian (changes to the
debian xen package), xen-api-libs, xen-api, blktap (userland) and
blktap-ko (module).

The storage manager code is still in a mercurial repository called
xen-sm.hg, which you can find here: http://xenbits.xen.org/hg/XCP/ .
That's a mirror of Citrix's development repository that we push to
periodically. The repositories on github are our development branches.

>> Jon Ludlam and I will start filling out the wishlist bug reports. I
>> have no idea what an ITP is, so I would appreciate it if you would
>> file one for me ;) Please let me know what information you need from
>> us and I will get it to you.
>
> An ITP is a kind of bug we use to reserve a name for a (source) package,
> and also to let others that we are working on it. To do that, you'd do:
>
> reportbug -b wnpp
>
> "wnpp" means "work needed and prospective packages", and it's a
> pseudo-package that we use only in the bug tracker. You don't need to
> fill it, I'll do it.
>

Excellent, thanks!

Mike