[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: build-debian-cloud python version preview



---------- Forwarded message ----------
From: Anders Ingemann <anders@ingemann.de>
Date: 16 September 2013 01:15
Subject: Re: build-debian-cloud python version preview
To: Jimmy Kaplowitz <jkaplowitz@google.com>


On 16 September 2013 01:12, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
>
> FWIW I'm hoping to find time to add Google Compute Engine support to the Python version soon, but due to other deadlines at work, it might have to wait beyond this month. I might also need to send a small number of additional PRs to the shell version, but hopefully not too many or for too long. Looking forward to the Pythonic future!
>
> - Jimmy
>
> On Sep 15, 2013 4:52 PM, "Anders Ingemann" <anders@ingemann.de> wrote:
>>
>> On 15 September 2013 22:11, Marcin Kulisz <debian@kulisz.net> wrote:
>>>
>>> On 2013-08-15 09:14:39, olivier sallou wrote:
>>> > Le 15 août 2013 08:58, "Marcin Kulisz" <debian@kulisz.net> a écrit :
>>> > > > Right now the "release" cycle of the python version is simply too
>>> > > > rapid to make a packaged version and I am unsure whether it is going
>>> > > > to slow down sufficiently over the next year to actually release a
>>> > > > packaged version.
>>> > >
>>> > > To be honest I started working on packaging python version and should have
>>> > > something once I'm back home from my holiday (another few weeks).
>>> > > Once it's build I'm going to drop it into alioth and mentors and will drop an
>>> > > info into this list that it's ready.
>>> >
>>> > Let's focus on a version considered stable by Anders (tagged in github) for
>>> > python version.
>>>
>>> If you're talking about shell version I my opinion it's no go as it's
>>> downloading resources from 3rd party sites like euca2ools, boto patches etc..
>>> I don't think it's appropriate or policy valid to put such kind of soft into
>>> archive. Of course we can remove those obstructions, but question is how far
>>> away are we from having python version available.
>>>
>>> Beside after short conversation with Anders I prefer not to put current
>>> 'stable' version into Debian archive.
>>>
>>> Hopefully I won't reveal any secret that Anders is very close to release alpha
>>> version for the python rewrite.
>>>
>>> > Once package is ready and dropped to mentors, put me in copy, I will try to
>>> > mentor the package.
>>>
>>> Np will do it.
>>> I the mean time if you want to use package I prepared for master branch I can
>>> reupload it to mentors just let me know.
>>> It's build on the latest commit from master with small patch to make Debian
>>> stuff working.
>>> --
>>>
>>> |_|0|_|                                          |
>>> |_|_|0|         "Heghlu'Meh QaQ jajVam"          |
>>> |0|0|0|         -------- kuLa ---------          |
>>>
>>> gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
>>> 3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3
>>
>>
>>
>> > Hopefully I won't reveal any secret that Anders is very close to release alpha version for the python rewrite.
>> No worries, you aren't :-)
>> My main focus has actually been on virtualbox, because it's perfect to test bootloading  etc. on.
>> This also brings the challenge of partitioning, which opened up a pandoras box of issues.
>> Right now I am working on a changeset that involves around +1000 lines and -400 lines.
>> Partitioning also means that we can get ec2 hvm images up and running (and partitioning is generally speaking not such a bad idea ^^).
>> I have not had a look at the kvm part yet, but I suspect that adjusting it is going to be quite easy.
>>
>> Also I am pulling quite a bit of dependencies into the host right now.
>> qemu-utils, parted, grub2, euca2ools and xfsprogs if you want to use XFS as a filesystem
>> The following python libraries are required:
>> boto, jsomschema v2, termcolor, fysom


*sigh, and once more for the mailing list. When will gmail have
mailing-list reply auto-detect figured out Jimmy? :-P

> it might have to wait beyond this month
No worries, I think it's actually for the better. This way I have some
time to get the architecture right before too many provider tasks
begin to lock it down.


Reply to: