TL;DR: How do you think we should handle Python being out of date and can you be counted in?

As we all know, Python in Fremantle is quite old (2.5). But now we come to a moment where this quite starts to mean a lot.

Most of the currently developed packages depend on features of Python >2.5. Which means the developers need to take special steps to ensure Python2.5 compatibility, which won't be taken forever.

Practically, this means Fremantle is becoming incompatible with anything Python!

For instance: building matplotlib fails because of newer code in setup.py. python-webob won't run at all. mnemosyne needs special treatment for 2.5 compatibility. Such a list could be much longer.

This issue is present in glib-dependent apps but as multiple python version can be run on the same system easily, Python might be somehow handled. And there's a lot of python software. We can do packaging manually, but we can't run code with an outdated interpreter.

What are your ideas for handling this?

And the most important question: do you want to do something with it or do you want Fremantle to lose compatibility with anything new? We don't have enough manpower to do everything for scratch but we could port existing desktop apps. Can you be counted in?

IMHO, we need to take advantage of Python2.7 brought by AapoRantalainen (and even maybe 3.x). This means rebuilding modules, which is a too huge job for one person to do. Or adding some special code to packaging which would create packages for multiple versions at once. [details would have to be discussed]

Update: the team is

• marmistrz
• malfunctioning
• Android_808
• p̶i̶c̶h̶l̶o̶
• wazrus

Update2: the tasklist: https://etherpad.mozilla.org/NuyrWHuWVn

Seriously? I'd prefer one person saying "I'll help with it" than twelve saying sheer "thank you".

I hereby announce - I will do some of the porting provided someone decides to join this task. I won't take up such a big project on my own. When, what and how can be discussed once we have who.

I don't know if I can help, but I can try. I have no experience compiling for the N900, but I've been thinking about starting development for the N900 for a while.

What's the first step? Install the SDK in my Ubuntu box? What setup do you recommend?

At the moment (next few weeks) I can't commit to much, but I may be able to do a some after that. At that time I'd need to know what the plan is before knowing if I'm able to do anything.

IMO, Python 2.7 should be used (optified if not already) for now. Ideally I'd like python and python2 symlink to point to 2.7 when migration done. Any modules/apps/debian rules/etc should then specify python2 or python2.7 not python to avoid issues and more work later if later migrating to default version to python3.

I might be able to help too but I would have no idea where to start. I am a programmer by profession but focused primarily on archaic languages like C and C++. I have used Python for writing test scripts and that's about it. I am also a (nearly) full-time parent which means I have limited time to do something. However, I am happy to help if someone can give me a small number of small, well defined, very specific, self-contained tasks.

i suppose very first should be checking depenencies on closed source apps to see if there are any using 2.3 or 2.5 as we can't help but keep a version around for them, so it may effect how we approach everything else.

then, check aapo's 2.7 meets all requirements, optification, build options etc. get preferred version into devel.

identify 2.3/2.5 external modules, push new versions as python2.7-modname.

identify list of packages depending on python and those using it as builddep, update to use 2.7. build, test and push.

Hi, I will help with it.
I agree that we should target python 2.7, since I know no application/module that requires python 3.
What channels can we use for communications, to build a shared tasklist ?

1. A shared tasklist: here you go: https://etherpad.mozilla.org/NuyrWHuWVn
The list isn't full yet.

As for the sdk - my approach is:
1. download tarballs (deb install didn't work as it should a couple of years ago and when installing from tarballs you can have both apophis and hathor, which is necessary to thumb-build some of the packages)
2. unpack it, run run_me_first.sh
3. setup the armel target as in the wiki, remember this and voila

2, AFAIC, we first need to get a list of all modules which need to be ported to python2.7. We can leave the old apps as they are for the time being (not to break anything) because they will continue to work without update. But newer applications, e.g. mnemosyne need both py2.7 and the modules.

Please add all the python2.5 modules (by package names) you know that need to be ported to 2.7.
Notice the groups on the Pad. Essentials are like the very basic ones, the ones we need to run anything (such as pyqt) separately, the less important ones are in the second section. Extra stuff is stuff which is in the repos and would be useful for a particular new application, ultra extra is something which isn't in the repos yet.

I don't know what would be better - to create a separate source package for python2.7 or to add some code to handle both version. I'm sure, though, that a separate package might be easier - you would simply change each "2.5" to "2.7" in the ideal case.

Once we get to know what has to be done, we can divide work. As the MeeCoLay developer I can tell you that porting packages ain't innovative. It's just reusing what's already done and solving compilation errors if you use upstream packages. So tasks are indeed often small and very well defined and specific.

3.My time this very moment is really limited as I'm a full-time student I have a couple of deadlines next 2 weeks, so I'll be able to devote some sane amount of time after 11th Nov.

Based on thumb comment, are we looking to provide both thumb and non-thumb versions? If so, whats the hosting plan for thumb?

What's the point on Thumb when there isn't a common repository for it?

There are some thumb builds here and there, spread all over the forums, personal servers and even, somehow, the unofficial thumb repository, but unless someone steps up (and is able to fight any opposition) to create a real thumb repo in the Maemo infra, all those efforts are in vain.

Same applies to create applications depending on CSSU (Qt 4.7.4 for example).

Maybe an instance on OpenRepos might help.