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

[Dustin Kirkland]

On Fri, 2010-03-12 at 17:42 +0100, Steffen Möller wrote:
> 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.

Understood.  We're committed to 1.9, and to fixing euca2ools in order to
work with 1.9.  We'll send those changes upstream, for sure.

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

Right, that's part of the reason why we had to split and do our own
euca2ools package...  We can't really wait.  Our deadlines are firm.

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

Great, thanks.

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

Will do.  I'll rename it to README.snapshot-merging.

> >  * We have a debian/README.source, which seems to make lintian slightly
> > happier.
> 
> This is because you have patches - we don't.

Ah, duh, right.  Sorry.

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

It comes straight from Amazon's website, in their ec2-ami-tools:
 *  http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.zip

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

Okay, I'll merge the two as best as I can.

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

Okay, well, I switched ours to 7.  I don't care much.  I don't think we
have any stated interest in backporting this to Hardy.  So I think 7 is
fine with us.

> >  * 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 they could be packaged for Debian easily.  You can have a look
for yourself and see if it's something Debian users would benefit from:
  bzr branch lp:cloud-utils

I suspect it's somewhat Ubuntu specific.  It's meant to talk to an
Ubuntu Enterprise Cloud, rather than just EC2.  But I'll leave that up
to you.

As for dropping to a suggests, we can probably do that.  I'll just need
to ensure that we seed cloud-utils in the appropriate places, because
we're currently using Recommends to ensure that cloud-utils gets
installed in places where euca2ools gets installed.

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

Okay, the cert...  We asked upstream Eucalyptus to take this, and they
said that they weren't comfortable with distributing Amazon's public
key.

I consulted various people in Canonical and we decided that:
 a) a public key is "public", and thus meant to be shared
 b) ultimately, it's just a really big prime number :-)
 c) this benefits Amazon by allowing people to sign images for upload to
their cloud -- only useful there

As to the security, I can't imagine any viable concern.  It's a public
key, not a private key.  You sign your image with this when you upload
to Amazon.  Only their private key can decrypt and verify the signature.
Unless you want to make euca2ools depend (recommend, suggest)
ec2-api-tools (non-free), or you want to point the user to go and
retrieve the zip file, extract the public key, and put it into place,
euca2ools is of limited usefulness with EC2.

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

Okay, can you give me a couple of instructions here, as I don't want to
screw up my first upload to Debian :-)

What should the version look like?  Should I add an appendage, like:
 * euca2ools (1.2-2~test1)

What does my dput line look like?  ie, where am I dputting to?

Is this going straight into unstable, or is this going to a "side"
repository like a PPA?

Would anyone be willing to take a look at my source package before
uploading?  Again, getting flamed by someone from Debian scares me :-o

Cheers,
:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/attachments/20100312/53fb03fa/attachment.pgp>