This whole thing has been horrible from the start. I was happily coding, learning to use Qt in a mobile environment, and then the autobuilder got switched to a version NO ONE has on their phone. I can build my app locally and it will run great on my n900, but as soon as I download it from extras-devel, it seg faults. So I thought I would wait until PR 1.2 was released, which was supposed to be '2 weeks' ... now it's not coming until November ?!?!
It's obviously not working right (there are several apps that I use that are un-updatable or now crash), is causing a lot of bad press, frustrating developers, and making users confused and angry. Please put up a wiki page detailing EXACTLY what needs to be done for a package to work properly using the new autobuilder, if that is even possible. Otherwise -- please, please please just put it back the way it was. Just make it work. I'll wait a little longer for this to get resolved, but if it takes too long I just might ebay my n900 and go Android. Sorry for the rant but sometimes it feels good to get things off your chest ! Cheers, - ianaré sévi 2010/5/21 Attila Csipa <ma...@csipa.in.rs>: > On Friday 21 May 2010 01:42:43 you wrote: >> 1. As today what a developer needs to do to get an application that >> uses qt to the end user? Is there a way to tell the autobuilder to compile >> against the 4.5 qt and make the package only depend on it? > > In theory you just depend on the proper version of libqt4-dev, but it's tricky > as you might indirectly reference libs that are also newer in the SDK/new PR > so end up with a 4.6 dependency (or broken build), see below... > >> 2. What is the point of the (not so few) qt applications on the >> repository that were compiled against the qt4-core (4.6)? Unless pr1.2 will >> have a qt that is binary compatible to the libs on the autobuilder right >> now these packages will be completely useless, right? I thought the point >> of committing packages using qt4-core (4.6) now was to have them ready for >> day one when pr 1.2. gets out. > > Most of the applications got compiled for Qt4.6 'by accident', in terms that > they do not really depend on or need 4.6 (nor did the original author WANT > that specific version), but with current SDK setup they end up being linked > against 4.6 anyway. This is why in my previous post I said this is not > strictly a PR1.1 problem, a similar situation might arise with other packages > if not managed correctly. > >> 3. The qt applications not using qt4-maemo5 are "moved" to testing. How >> are they being tested right now? They can't be tested on the pr1.1, because >> they are compiled against qt 4.6. Are they not being tested at all >> (everything is at halt); or they are being tested by people that have "pre >> release" pr1.2; or are they being tested using scratchbox environment? > > AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense > to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid > platform for community QA purposes. > >> Thanks for taking the time to answer me. It has been very interesting and >> "illuminating" > > Hate to be the bearer of bad news :( What we managed to agree for the PR1.2 > release is that development releases starting with PR1.2 will not be called > libqt4-maemo5 as it's not that obvious that it's *really* just a version for > testing, prone to breakage and not necessarily the exact one that will end up > in the next PR. Future releases will sport the 'experimental' moniker (f.e. > libqt4-experimental, python-qt4-experimental) so it's more clear that it (and > stuff depending on it) are not meant to be promoted to end users. Not ideal, > but hopefully will reduce confusion until a better solution is found that is > acceptable for both Nokia and the community. > > > Regards, > Attila > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
