[pkg-eucalyptus-maintainers] Updated euca2ools to version 1.2 in Debian.

Fri Mar 12 16:42:38 UTC 2010

Dustin Kirkland wrote:
> On Fri, 2010-03-12 at 15:22 +0100, Steffen Möller wrote:
>> Hello Dustin,
>>
>> have many thanks for your friendly and constructive email.
> 
> Cheers :-)

Well, this last message is now barely beatable by the aforementioned
criteria.

>> Dustin Kirkland wrote:
>>> We will likely continue filing/fixing/upstreaming/cherrypicking such
>>> bugs all the way up until the Lucid release slated for April 30, 2010.
>>> For this reason, we will not be able to be "downstream" of Debian for
>>> the euca2ools package.  However, I'm very keen on sharing the changes we
>>> make to the euca2ools packages with Debian in any way that makes sense.
>> Hm. What you describe makes perfect sense to me. There is no point to
>> keep unstable in complete sync with the trunk, so having patches on top
>> of 1.2 is already extremely nice. You can upload to Debian (and become a
>> Debian Maintainer for that rather easily) what you upload to Ubuntu if
>> you want, I presume Charles to agree. Now we have this git repository
>> set up. I am not sure how to use that, probably one just adds the latest
>> version number and checks for possibly differently named dependencies
>> over what you have with Ubuntu.
>>
>> I am very excided about the positive vibrations that you send to Debian.
>> Is there any particular way in that you would profit from our
>> activities? We have updated a few packages over what is in Ubuntu, Chris
>> is doing a lot on his upstream end to accomodate for the various
>> differences between versions. But I do not see how you directly profit
>> from being nice to us but very much like to see that.
> 
> I'm quite interested in collaborating here.
> 
> From my side, I would expect to benefit from Debian users running
> euca2ools 1.2 along with python-boto 1.9, which is the combination we
> have in Ubuntu Lucid right now.  This forms a bit of separation, though
> between us and upstream Eucalyptus, who still recommend python-boto 1.8.
> We consciously chose python-boto 1.9 to solve a few other known issues.
> But right now, we're a bit "on our own" to solve euca2ools issues that
> arise due to the new python-boto version.  That's one place where I
> think we stand to cooperate and benefit.

Please talk to Chris about this all. He is aware of those issues and I
am confident that he would have already fixed them if that was
sufficiently easy.

Charles and I are waiting for a final signal to upload python-boto1.8,
just to remain functional until all the changes have been addressed and
tested for 1.9. That signal has not yet arrived. The -boto maintainer is
much in sync with you Ubuntuans and stressing that 1.9 is the way to go.

> As for converging, let's look at two diffs...
>  1) The diff of the upstream code (minus debian/)
>  2) The diff of our debian/ packaging directories
> 
> As I said before, our euca2ools (1.2-0ubuntu6) is basically 1.2
> cherry-picked up to bzr r262 (minus the packaging changes).
> 
> I'm looking at (1) right now, and it appears that our bzr branch is just
> a couple of commits ahead of yours.

Hm, hm, hm, hm. I don't know about how much I should care at the very
moment. The official maintainer is Chris, even though he is too busy
these days to write some "upload this now" mails. So, if something is
sufficiently bad to be reuploaded to the distributions, then Chris
should come up with a new public release first.

> Our packaging directory, though is a bit different.
> 
> diff -uprN euca2ools-1.2/ ubuntu/ | filterdiff -i "*/debian/*" | diffstat
>  README.debian         |   27 -------
>  README.source         |    9 ++
>  README.ubuntu-merging |   83 +++++++++++++++++++++++
>  cert-ec2.pem          |   23 ++++++
>  changelog             |  175 ++++++++++++++++++++++++++++++++++++++++----------
>  compat                |    2 
>  control               |   22 ++----
>  copyright             |   33 ++++++++-
>  install               |    1 
>  links                 |    1 
>  manpages              |    2 
>  rules                 |    8 --
>  watch                 |    6 -
>  13 files changed, 300 insertions(+), 92 deletions(-)
> 
> Of these:
> 
>  * Why does your package have both a README.debian and a README.Debian?
>    - If you converge on one of these two I'll gladly sync that to the
> Ubuntu package.

I have just fixed that. Many thinks for spotting this.

>  * The README.ubuntu-merging is a set of instruction that I used
> (copy-n-paste) to merge euca2ools up to the latest bzr snapshot *prior*
> to the 1.2 release.  Up until Ubuntu's Feature Freeze, we basically
> tracked upstream commit-for-commit.  After Feature Freeze (and after
> euca2ools 1.2 released, we shifted into bug-fix/cherry-pick only mode).
> I'll probably keep that around, because it's really damn useful to us,
> at least.  The file can be renamed to something more appropriate,
> obviously.  Probably README.snapshot-merging, or some such.

I don't mind to have it in. Would you feel like pushing it yourself? You
have commit rights.

>  * We have a debian/README.source, which seems to make lintian slightly
> happier.

This is because you have patches - we don't.

>  * cert-ec2.pem is Amazon's public key, which let's users build and sign
> images for upload to EC2.  Fixes LP: #479836.  This is also reflected in
> the differences for debian/copyright, debian/install, debian/links

Ah, ok, so you took that from the Amazon's distribution. I had both,
Amayon's and Eucalyptus, installed and probably did not run into that
problem for that reason.

>  * changelog obviously differs.  On convergence, we could have a
> changelog.Debian and changelog.Ubuntu around for historical purposes.
> Or we could somehow try to interleave them.  Whatever works.

I would prefer the interleaving.

>  * compat is 5 for us, 7 for you.  I'm happy to bump up to 7, but I
> think our packaging right now is 5-compatible.  In any case, I'm happy
> to bump up to get in sync.  Just let me know...

I am not sure. If it works as 5, then we can use 5. I don't know what
the cdbs is doing internally, really.

>  * debian/control has some minor differences.  Maintainers list,
> obviously can be synced.  The build-deps are a bit different, but I
> think we can converge there.  Minor dependency difference on
> python-boto.

> And we have recommends on an Ubuntu-specific package
> called cloud-utils, which provides some Ubuntus-specific wrappers around
> euca2ools commands (such as uec-publish-tarball).

Hm. I don't know. We'd then need to package those wrappers, too. Do you
like your wrappers? Or can one live without? I am fairly emotionless
here. How about rendering that a "suggest"? From what you describe, a
suggest is a better fit in the first place and then I don't mind to
suggest a package that is not (yet) in the distribution.

>  * I think your debian/rules changes are correct, and better than our
> process.  I've been fighting the manpage building for a while now.  I'll
> merge this to Ubuntu.

Nice.

>  * And your debian/watch file looks good.

Also nice. Chris sent this link around a few days ago.

> So I just made a few changes based on the above review, and committed to
> our bzr.  We're a bit closer now:
> 
> $ diff -uprN euca2ools-1.2/ ubuntu/ | filterdiff -i "*/debian/*" | diffstat
>  README.debian         |   27 -------
>  README.source         |    9 ++
>  README.ubuntu-merging |   83 +++++++++++++++++++++
>  cert-ec2.pem          |   23 ++++++
>  changelog             |  190 ++++++++++++++++++++++++++++++++++++++++----------
>  control               |   18 +---
>  copyright             |   33 ++++++++
>  install               |    1 
>  links                 |    1 
>  9 files changed, 309 insertions(+), 76 deletions(-)
> 
> I think we can totally get in sync if:
> 
>  * You sort out your debian/README.*ebian issue

done

>  * You take the cert-ec2.pem changes

I am too much of a coward to adopt this from the diff you kindly
provided. And, I am somewhat concerned about that being a security risk.
 Two things come to mind:
 * we should have the same for the Eucalyptus open servers, if
appropriate, Chris will know.
 * no matter if this is a good thing to have or a bad, we should agree
on this and come up with a joint decision. May I suggest you to upload
it to the repository?

Please give a push a chance, just remember to add -guest to what you may
otherwise think to be your ID when specifying the developername.

Best,

Steffen