Development waiting for PR1.2, anyone else?
 

Hi,

Firstly I'd like to point out this isn't a "Waaaa, where is PR1.2?" thread. If you're looking for one of those then click in any direction and you should find one.

A few months back I started writing an app for UK Train Departures. I wanted to use Python and QT so I started off using PyQT.

Soon I ran into problems with wanting to use the QTMaemo5 module that was not available in PyQT so switched to PySide. I got most of the functionality up and running but ran into some interesting QT stability issues and wasn't to sure if it was something I was doing wrong or PySide. I also decided that I didn't really want to depend on PySide as I had no idea when it would make the move from Devel. By this point PyQT had released support for QT 4.6.2, the downside being that the QTMaemo5 module wouldn't be available until PR1.2. Just round the corner I thought, I can wait a a week or two.

So my questions are:
* Have I missed something? Is there a way to get to use the PyQT maemo 5 api on the phone?
* I've not moved to the latest SDK yet as I was worried about depending on things not yet available to the phone. However does anyone know if the PyQT Maemo5 module is available in it? It might be worth upgrading my SDK just so I can get back to working on the app.
* Are there any other devs waiting for PR1.2 (namely QT updates) to make a release?

Regards,

Alex

Re: Development waiting for PR1.2, anyone else?
 

you can download the bindings from here, and it works v nice

http://talk.maemo.org/showpost.php?p...&postcount=104

And here is ncalc with full rotation support
(Auto rotation will not work in PR1.1 firmware with these bindings)

http://talk.maemo.org/showpost.php?p...&postcount=112

Re: Development waiting for PR1.2, anyone else?
 

Hardcore, that will help.

Any chance you know if the latest SDK has these debs in x86 as I use both phone and SDK for development and testing work?

Regards,

Alex

Re: Development waiting for PR1.2, anyone else?
 

nope not in the SDK, These debs are specially made for PR1.1, so not sure how they will behave on the SDK.
have a look further up the thread by a few posts to see how to install

Re: Development waiting for PR1.2, anyone else?
 

Thanks to MikeC for the references.

The situation is as follows. The PR1.2 release process got borked, and developers (myself included) got caught in the gap. To avoid further mixups, delays, depending on the Qt packaging strategy, I will reconsider my decision to have a single packageset, so you will probably be seeing python2.5-qt4-* compiled for the current PR and a python2.5-qt4-devel-* which will be compiled against the Qt version in extras-devel. Sadly (unlike Qt) you will not be able to have both installed simultaneously. It's not too nice, but since it looks like the Qt4.7 release is going to use the same procedure as Qt4.6, that seems the lesser evil :(

Oh, and I did not make any X86 debs, sorry, will remedy that shortly (though it is more likely that I end up uploading it to extras-devel according to the scheme specified above).

Re: Development waiting for PR1.2, anyone else?
 

Thank you so much.

I'll look out for either the devel packages to hit repositories or the x86 debs to be uploaded somewhere. Hopefully this weekend I'll be back at the coding :)

Regards,

Alex

Re: Development waiting for PR1.2, anyone else?
 

I have a question about this.

Why can't I install multiple versions of the same library and have them running alongside each other?
That would fix a lot of things.

Windows solved this problem about 10 years ago, so I'm quite surprised Linux can't do it.

Re: Development waiting for PR1.2, anyone else?
 

It's not a Linux issue per se, it's the way Nokia decided to package Qt that is the problem (I'm sure they had their reasons, but that's not helping us in this particular case). If someone really-really wanted, they could make bindings installable in parallel, too, but it's very dirty with all sorts of pathmongering and changes to the import statements, likely to cause more trouble than it's worth.

Re: Development waiting for PR1.2, anyone else?
 

There are, at least, three levels to "installing": package managing (as in .deb or .rpm), resource sharing (as in config utilities) and actual storing on disk.

If not all these levels of installation are planned properly, using several versions of the same library might fail in many ways. This puts the responsibility on the maintainers/packagers.

So, Linux can handle as many versions as you want, they are loaded into memory and any application can pick and choose whatever it needs but if the product in itself isn't playing nice, that's the problem.

Re: Development waiting for PR1.2, anyone else?
 

Yes, it is a Linux issue, from my point of view.

For example, add the Debian ARM repository, and try to install something from it.
I, for one, wanted to try Mono, so I installed the mono-runtime package.
Apt-get also updated libc6 and libgcc1 during the process.

It seems however, that the Calendar application is not happy with it, and stopped working properly.
After I downgraded to the previos version of libc6, it worked again.

It would be much easier in terms of compatibility, if it would be possible to have both versions of that library.

Re: Development waiting for PR1.2, anyone else?
 

From my system:
It is not a linux problem - it handles multiple versions very well. The problem is with how the packages were prepared.

You're trying to install packages from a different distribution - it will fail. They were not designed to do that - they have dependencies which assume certain environment and if you cannot provide that, you'll have to download dependencies which match.

Libc updates are hard as it is. There are / were libc compat libraries when it was really needed afair (libc5/libc6), but migrating them between different distributions is suicide.

You're simply trying to do an unsupported thing.

Re: Development waiting for PR1.2, anyone else?
 

It's a distribution issue. Unlike the Microsoft world, where everyone does what MS says, distributions can and do update themselves on their own schedules. Dependencies and packages look internally for resolution, and this is why installing from other distributions is a bad idea. It has nothing to do with -Linux-, and everything to do with the fact that Debian and Maemo are not the same.

This is why Easy Debian exists.

Re: Development waiting for PR1.2, anyone else?
 

On Linux, everything is possible, the only question is how hard it is ;) In your case, I would suggest looking into dpkg --instdir and LD_LIBRARY_PATH, but mixing Debian ARM stuff into Maemo is rough terrain (that's in effect just like copying over things from c:\
windows\system32 between various SPs and editions - sort of works... but more often doesn't :) )

Re: Development waiting for PR1.2, anyone else?
 

About the Windows metaphor:
No, it's more like having 2 versions of the same .dll file, and referencing the right version.

So, I'd like to have the original version which comes from Maemo 5, and I'd like to install the other one for the apps I install from the Debian repo.

Is it possible?

Re: Development waiting for PR1.2, anyone else?
 

Yes, but you'd have to compile from sources and install to your home directory; not the system directory.

The apps that you want to use the different version of libraries you will have to either pass the right flags or environment variable such as the LD_LIBRARY_PATH... or recompile the software yourself using the alternative library path.

You won't be able to point-clicky install software from debian and software from meego and have both software use different versions of libraries... use easy debian for that.

ETA: As for the windows thing, you can't have the same filename in the same directory at the same time regardless of versions. So you'd have to name the dll two different things and the app would have to be written calling that name of dll.

Re: Development waiting for PR1.2, anyone else?
 

I wanted to learn Qt since before I got an N900, and since I got N900 I want to program for it... since it's all been such a moving target so far, I've not even bothered to begin until PR1.2, qt-creator with madde integration, etc. are released and stabilized. Not that I have any need for this particular setup, but it seems to be the "future best way" so I'll just wait for it to be the present. :)

Re: Development waiting for PR1.2, anyone else?
 

Thanks for your clarification.
I accept that it is not possible, then.

The part about filenames is correct, the rest is not.

For traditional COM dlls, you can register multiple versions of them.
The will reside in different physical locations, but an application requesting a specific version of a dll can get it easily.

For the managed programming model:
You can have every version of the .NET framework running alongside each other.
This is also true for your own assemblies, you can have multiple versions of the same assembly in the GAC.

And my point is: it is handled directly by the operating system, the developers don't have to do anything about it.

Re: Development waiting for PR1.2, anyone else?
 

It is very possible to try out MADDE right now.
I didn't regret it.

Re: Development waiting for PR1.2, anyone else?
 

I was unaware of this as, though I have been a windows administrator for many years - Software Development on windows was never something I got into.

Reading your description I decided too look it up and found:

http://tldp.org/HOWTO/Program-Librar...libraries.html

This part seems to suggest I'm correct:
The way libraries are in Linux is you'll usually have libraryname.so.1.2 (version).. and then a symlink from that to libraryname.so - That way the program just calls libraryname.so and you get whatever version is on the system. If you *need* an older version, you can re-link the libraryname.so to the older one and not the newer one to launch the app. But this is ugly.

However, down at the bottom there seems to be a bit of a contradiction:

Unless it's simply referring to the hack above, I don't know what it means.

Re: Development waiting for PR1.2, anyone else?
 

It works more like (not that you said it wrong, I just think you might typoed on the first sentence at least):
You install libstuff.so.1.2, and create a libstuff.so -> libstuff.so.1.2 symlink
You build application A on your system. It gets linked to "libstuff.so" which happens to be libstuff.so.1.2, and this latter name is the one the A binary "links with".
You install libstuff.so.1.3, you change the libstuff.so symlink -> libstuff.so.1.3.
You build application B, tries to link with "libstuff.so" which is "libstuff.so.1.3".
You try to run A. It uses libstuff.so.1.2, you still have it installed: no problem.
You try to run B. It uses libstuff.so.1.3: no problem.

This is how it theoretically should work.

But it doesn't matter since here we're talking about Python _and_ Debian packaging mostly.

Re: Development waiting for PR1.2, anyone else?
 

No, that's not the same. The difference is exactly that you used apt to _replace_ glibc with another version. As the two versions were ABI compatible, that is the default action (that way old applications can use newer libs without explicitly knowing about them)...

Yes, I already said how in my previous post :) See dpkg --inst and LD_LIBRARY_PATH, but be aware that you are mixing gcc versions, compiler switches, cpu options, etc.

Re: Development waiting for PR1.2, anyone else?
 

In answer to the original poster, yes. When I got my N900 I had a good root through all the particular available developer workflows (Pluthon, Scratchbox, MADDE, even Vala) and I've decided that MADDE + Qt is going to be the thing for me.

I had varying levels of success with sorting out various Python dependencies, but I think I was unluckily in the middle of various release cycles so it wasn't easy. In the end I found Qt 4.6 most attractive, and I'm more a C-style guy than Python anyway. (I was/am working on a London Tube Map application.)

Very shortly after, I totalled my device by accident, so after reflashing thought I'd wait for everything to settle down and align a little so my toolchain was more stable before I began again in earnest. I'm fairly sure that wait will soon be over.