[Pkg-xen-devel] XCP and OpenXenCenter

[Thomas Goirand]

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?

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.

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

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

Cheers,

Thomas