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

Steffen Möller steffen_moeller at gmx.de
Fri Mar 12 17:57:56 UTC 2010

Dustin Kirkland wrote:
> 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. To me this reads a bit like you should be for a couple of hours on
skype together already today.

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

Uuuuuuuh. Well, let's hope to undo at least that part of your reason. My
hunch is that you are paid to do that packaging work and can reserve
respective time for that. This is tough to beat by Charles, me and since
Chris still has to go through us for the uploads there is not much he
could help with.


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

Well, seems like we will have patches very soon.

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

Would there be a way to have the user retrieve that file? Or postinst?
Us hard core Eucalyptus users don't really want to use it :)  (( a lie,
but it sounds good for a moment ))

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

Many thanks

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

More thanks

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

Well, I could imagine also Debian users to be intested in Ubuntu clouds,
so I am fine with that. Also, I am preferring sending money to Canonical
over sending it to Amazon, btw.

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

Hm. Is the dependency not rather from the cloud-utils to euca2ools?

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

Same with me.

> 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

Still, I am uncomfortable. I can well understand (given all the legal
    craziness around) that it is not shipped with upstream.

What about the file being outdated?

 > As to the security, I can't imagine any viable concern.  It's a public
> key, not a private key.

The key could be changed in some larger series of patches remaining
unnoticed and allowing some other site to claim to be Amazon.

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

I'd feel like providing a script "install_amazon_public_key.sh" which
would do exactly that.

>> 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 :-)

Until you are accepted as a DM, it is Charles or me to do the upload.
See some extra notes further down.

> What should the version look like?  Should I add an appendage, like:
>  * euca2ools (1.2-2~test1)
No, I would just go straight for euca2ools (1.2-2) or whatever the next
version is. You are one of the uploaders after all.

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

I don't use dput, I am a dupload guy:

$cfg{'anonymous-ftp-master'} = {
        fqdn => "ftp-master.debian.org",
        incoming => "/pub/UploadQueue/",
        # files pass on to dinstall on ftp-master which sends emails itself
        dinstall_runs => 1,

We need to get you through the Debian Maintainership process first. This
will take 2-12 weeks of a consecutive change of emails waiting in various
inboxes. You'll start that chain, then Charles and I say something nice
about you, and then eventually  someone from the front desk will read
and like that and add your key to the debian-keyring.

Please read yourself through wiki.debian.org/Maintainer and ask me
whenever you do get stuck - you have your key signed by some DD already?
Of his Highness (pun on his space flight intended) MS himself, possibly?

> 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
Haha, sure, well, you are improving what is there, so, relax.  What also
helps is to consider yourself a part of Debian - with so many packages
of yours (?) and Thierry (!) in Debian already, you definitely are.

Many greetings


More information about the pkg-eucalyptus-maintainers mailing list