Re: Garage project takeover
Hello, Hi, I am currently doing some maintainance work on DOSBox for Maemo (and I am the author of the current package in -devel). In order to fulfill the extras QA bugtracker requeriment and my own need for a VCS repo, I considered registering a new project in Garage, but found that the project was already registered. Quite a few months ago I contacted the maintainer, but he hasn't answered yet, and the Garage interface won't let me spam him again until he accepts or declines the current request. So, a week ago, I sent him an email, with still no reply. I could register a dosbox2 project, or just ignore Garage and go straight to a b.m.o component and a gitorius project, but since the Garage project already exists and is virtually empty, I'd like to know if there's any policy about takeover of empty/abandoned Garage projects by new maintainers, or to kickstart discussions about one if it does not exist yet. The project is completely empty and doesn't seem to be used since it has been created on 2007-12-08. I can set you as admin for that project as you seem to be a lot more active than the current admin. I'd like to get an OK from the council so we all agree on this. If there had been data in the project it was a more difficult decision, but now it seems completely empty. A policy on this kind of takeovers doesn't exist, but I guess common sense and communication would help solve issues like this. DOSBox garage link: https://garage.maemo.org/projects/dosbox -- Javier -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Touch Screen input capture
Hi, I am working on a OpenGL ES application (based on PowerVR framework) on Maemo and want to capture touch screen input for the application. I did not find any touch screen capture in PowerVR libs. Is there any other lib that could capture touch screen input for OpenGL ES apps? Thanks Charles ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
On Wednesday 24 February 2010 08:12:05 Niels Breet wrote: I'd like to get an OK from the council so we all agree on this. If there had been data in the project it was a more difficult decision, but now it seems completely empty. I agree that this is probably the correct thing to do. However, I would like to make sure the current admin has a fair chance to object. After all, maybe he is on holiday? I suggest a formal email from Niels, in the name of the council, notifying him that someone else wants to take over his project and that the council agrees. As the project is currently empty, and so nothing will be lost, I would give him 1 more week to respond to that email. If the project had content but seemed to be abandonned I would say the process should be to give him 2 weeks to respond, then archive the project before handing it over (is there a way to rename an existing project so it could be named project-old or something?). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo 5 PR1.2 and Extras
Hi, Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. We have prevented SDK upgrades in the past to keep software in Extras backwards compatible, but with this change this does not seem possible. I want to propose the following changes: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. I proposed not to update fremantle Extras, because we would then need to setup separate builders and more importantly different QA queues. This will bring a lot of work and confusion to testers and developers, I want to prevent that. Nokia will encourage people to upgrade to the latest release as much as possible and we expect people to switch to PR1.2 at a high rate. Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24 February 2010 11:21, Niels Breet ni...@maemo.org wrote: Nokia will encourage people to upgrade to the latest release as much as possible and we expect people to switch to PR1.2 at a high rate. Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. Off-topic question - would I be able to upgrade to PR1.2 if I'm still missing PR1.1.1? For some strange reason I didn't receive that update OTA and I don't feel like flashing my device. -- Dawid 'evad' Lorenz * http://adl.pl null://there is no place like 127.0.0.1 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi Niels, Am 24.02.2010 um 12:21 schrieb Niels Breet: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 I think that's a good idea. Separate builders an QA queues would bring little benefit but cause a lot of work and confusion. Cheers, Stephan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, On 24 February 2010 12:21, Niels Breet ni...@maemo.org wrote: Hi, Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. after all the main/official way to write applications for N900 is using C+Gtk. Developers who are using Qt (both C++ and Python) know that are using something still experimental (even if already so good). There are pro/cons using Qt right now. Ok, we'll have to rebuild/adapt our applications when PR 1.2 is out, but for sure we'll be ready for Harmattan/MeeGo development :) So, go on! -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: reloading a status bar plugin
On Tue, 2010-02-23 at 20:06 +0100, ext b0unc3 wrote: Hello, I've created a statusbar plugin, now I want to reload it (eg. when the configuration file changes). What is the best way to do that ? If the plugin can be unloaded and reloaded cleanly (meaning, it does not crash hildon-status-menu :)), you could touch the .desktop file in some way (e.g. increase version number inside the file) to make HSM unload and reload you. If your plugin is not unloadable, you can do this ugly trick (other plugins can react to this somehow): dsmetool -k /usr/bin/hildon-status-menu dsmetool -t /usr/bin/hildon-status-menu -Kimmo Best Regards, Daniele Maio. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 12:21:45 Niels Breet wrote: Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Touch Screen input capture
On Wed, 2010-02-24 at 10:04 +0100, ext Charles wrote: Hi, I am working on a OpenGL ES application (based on PowerVR framework) on Maemo and want to capture touch screen input for the application. I did not find any touch screen capture in PowerVR libs. Is there any other lib that could capture touch screen input for OpenGL ES apps? The normal way is to use libx11. I.e. call XSelectInput(dpy, window, ButtonReleaseMask | ButtonPressMask | PointerMotionMask) and then handle the incoming X events ButtonRelease, ButtonPress, MotionNotify. (See http://tronche.com/gui/x/xlib/events/types.html) -Kimmo Thanks Charles ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
hi, Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 12:21:45 Niels Breet wrote: Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? A different .install file can be offered based on your browser string. Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? There is not a lot we can do there. If a user adds the repository on an 'old' device, some applications just won't install because dependencies are missing. This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
I don't know whether this has been discussed before: what is wrong with forcing users that have the necessary Internet access to download applications from Extras, to also upgrade to the lastest firmware, which is supposed to fix bugs anyway. Why would anybody not upgrade the firmware? Why is backwards compatibility necessary for Fremantle minor releases? Enforcing the requirement could make our life so much easier. We could have a package maemo-extras which enables the extras repository and which always depends on the latest firmware version. Or we could add the current firmware version to the dependencies of packages build on autobuilder. Users who don't want to upgrade would have to stick with the on-device applications. cheers On 24.02.10 12:21, Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases - 'older' devices will continue to fetch from distribution: fremantle This will effectively mean that the 'old' Extras will not get any updates. ... Nokia will encourage people to upgrade to the latest release as much as possible and we expect people to switch to PR1.2 at a high rate. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
If renaming is possible would be a better option IMO. Unfortunately gforge doesn't let you rename projects as lists, scm etc are also linked to it. Best regards, -- Valério Valério http://www.valeriovalerio.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: reloading a status bar plugin
2010/2/24 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Tue, 2010-02-23 at 20:06 +0100, ext b0unc3 wrote: Hello, I've created a statusbar plugin, now I want to reload it (eg. when the configuration file changes). What is the best way to do that ? If the plugin can be unloaded and reloaded cleanly (meaning, it does not crash hildon-status-menu :)), you could touch the .desktop file in some way (e.g. increase version number inside the file) to make HSM unload and reload you. I cannot change the .desktop contents by user. If your plugin is not unloadable, you can do this ugly trick (other plugins can react to this somehow): dsmetool -k /usr/bin/hildon-status-menu dsmetool -t /usr/bin/hildon-status-menu This is the current way I'm doing that, but, as you said, it's ugly. -Kimmo Best Regards, Daniele Maio. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
Hi, On Wed, Feb 24, 2010 at 10:27 AM, Graham Cobb g+...@cobb.uk.netg%2b...@cobb.uk.net wrote: On Wednesday 24 February 2010 08:12:05 Niels Breet wrote: I'd like to get an OK from the council so we all agree on this. If there had been data in the project it was a more difficult decision, but now it seems completely empty. I agree that this is probably the correct thing to do. However, I would like to make sure the current admin has a fair chance to object. After all, maybe he is on holiday? I suggest a formal email from Niels, in the name of the council, notifying him that someone else wants to take over his project and that the council agrees. As the project is currently empty, and so nothing will be lost, I would give him 1 more week to respond to that email. Yup, agree with these rules, is not the first time that someone wants to takeover a garage project, can't recall correctly who asked me the same thing, but that person got a reply from the 'old' administrator. If the project had content but seemed to be abandonned I would say the process should be to give him 2 weeks to respond, then archive the project before handing it over (is there a way to rename an existing project so it could be named project-old or something?). If renaming is possible would be a better option IMO. Best regards, -- Valério Valério http://www.valeriovalerio.org Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 12:29:02 Andrea Grandi wrote: Developers who are using Qt (both C++ and Python) know that are using something still experimental (even if already so good). That is incorrect. Even though Nokia calls Qt 4.5.x 'community supported', it is shipped with all N900 devices from day 1 and is used by applications in both Extras and the Ovi store. It misses the 4.6 goodies, but it does work and IS based on a stable release of Qt. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: reloading a status bar plugin
2010/2/24 b0unc3 b0u...@email.it: 2010/2/24 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Tue, 2010-02-23 at 20:06 +0100, ext b0unc3 wrote: Hello, I've created a statusbar plugin, now I want to reload it (eg. when the configuration file changes). What is the best way to do that ? If the plugin can be unloaded and reloaded cleanly (meaning, it does not crash hildon-status-menu :)), you could touch the .desktop file in some way (e.g. increase version number inside the file) to make HSM unload and reload you. I cannot change the .desktop contents by user. You could touch it with sudo some-helper-script added to the sudoers file. But I wonder, why do you need to reload the plugin at all? Can't you just reload the configuration from the running status menu applet and adapt it accordingly? regards Philipp ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
I would prefer if devs could get the PR1.2 update a week or so earlier than the general release. This way most of the necessary updates from Qt 4.5 to 4.6 could be done before the general public gets the new firmware. Also the normal 10 day quarantine should not apply to these case. Thanks, Sascha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hallo! What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. No, what happens witht he packages currently ine extras? * Will they automatically moved to fremantle-1.2 Extras? Sounds like this is not possible. * Will they automatically rebuild against then current SDK? f yes, how do we find out it will work? * Will fremantle-1.2 Extras be intially empty and we have to get all packages in it again trhought he extras-testing process (Ooohhh, n, that will take ages!) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 11:21:45 Niels Breet wrote: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 I can't say I like this. My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? Can we keep track of stats showing how many people are accessing the old repository? However, as I don't have any evidence, I don't object to this approach. It at least leaves the door open for the community to decide later that we do need to update the fremantle extras, if necessary. Let's go with it for now. We do need to have a plan for exactly when the changeovers will happen. When will the autobuilder switch over and when will the promotion interface change? Developers need to know so they know what they need to do if they need to get a final update out to PR1.1 users. For example, I have the GPE stuff sitting in extras-testing. I would really like this to make it into the PR1.1 repository, even though the next update will only make it to PR1.2. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, On 24 February 2010 13:27, Sascha Mäkelä sascha.mak...@gmail.com wrote: I would prefer if devs could get the PR1.2 update a week or so earlier than the general release. This way most of the necessary updates from Qt 4.5 to 4.6 could be done before the general public gets the new firmware. Also the normal 10 day quarantine should not apply to these case. it would be a nice idea imho :) I would like it too! -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: reloading a status bar plugin
On Wed, 2010-02-24 at 13:21 +0100, ext b0unc3 wrote: ... dsmetool -k /usr/bin/hildon-status-menu dsmetool -t /usr/bin/hildon-status-menu This is the current way I'm doing that, but, as you said, it's ugly. Yes, because The Right Way is for your plugin to load the new settings without requiring reloading of the plugin. That should be doable for all settings, no? You can look e.g. hildon-desktop that reloads its /usr/share/hildon-desktop/transitions.ini configuration on-the-fly. Using Gconf settings (and handling change notifications for them) is another alternative. -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hello, On Wednesday 24 of February 2010, Niels Breet wrote: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 IMHO, it may be better to have a distribution name like freemantle-2 just to not cause confusions if/when PR1.3 (or other) is released. Having 1.2 in name implies that it should be changed in every new PR. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
hi, Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? That would be forward compatible in my book ;) Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Applications built on PR1.2 won't work on older versions. There are exceptions, some applications might work, but those make this very complicated. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 11:21:45 Niels Breet wrote: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 I can't say I like this. My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? Can we keep track of stats showing how many people are accessing the old repository? Nokia retail figures - ask Nokia. I'm pretty sure that getting that info will not be easy. I have the Extras downloads figures now. So we can check the percentages after the switch. However, as I don't have any evidence, I don't object to this approach. It at least leaves the door open for the community to decide later that we do need to update the fremantle extras, if necessary. Let's go with it for now. We do need to have a plan for exactly when the changeovers will happen. When will the autobuilder switch over and when will the promotion interface change? Developers need to know so they know what they need to do if they need to get a final update out to PR1.1 users. The same day as the SDK will be released seems to be a right time for me. I don't know the exact release date of course. I'll make sure things are prepared in advance, so the actual switch can be done relatively quickly. For example, I have the GPE stuff sitting in extras-testing. I would really like this to make it into the PR1.1 repository, even though the next update will only make it to PR1.2. True, this is something we need to think of. It is clear for every promotion happening before the PR1.2 release, but when we switch it will go to fremantle-1.2 by default. (Unless we do something to prevent that) Graham -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hallo! What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. No, what happens witht he packages currently ine extras? fremantle-1.2 will just be a copy with applications which don't work removed. * Will they automatically moved to fremantle-1.2 Extras? All apps that are not touching the changed APIS are expected to work just fine. Nokia people are running Extras apps on PR1.2 test images just fine. * Will they automatically rebuild against then current SDK? if yes, how do we find out it will work? Testing shows not a lot of problems, only the obvious Qt apps. * Will fremantle-1.2 Extras be intially empty and we have to get all packages in it again trhought he extras-testing process (Ooohhh, n, that will take ages!) No, don't worry. -- GruÃ... Tim -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
I would prefer if devs could get the PR1.2 update a week or so earlier than the general release. This way most of the necessary updates from Qt 4.5 to 4.6 could be done before the general public gets the new firmware. It looks like there is a chance to get the SDK out before the actual device OS update, but the discussion is still going on. I hope to have more information on that later. Also the normal 10 day quarantine should not apply to these case. I'm not sure if that is a good idea. The quarantine is there for a reason, the switch between these Qt releases can actually introduce issues. If we have the SDK in time, then the overlap will be minimal anyway. Thanks, Sascha -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo - zoom2 - worldclock
I'm learning about maemo using zoom2 hardware. I have a bug where worldclock hangs when I make a certain sequence of user-input. I have used gdb to see what is going on, but without source, since this is a closed package, the clock-ui package. It looks as if the app spawns a thread to do something and then starts pthread_cond_timedwait. And then the thread quits very quickly and the originating thread never progresses. My question is whether it is worth raising this as an issue, since the zoom2 is only for development hacking and, further, my build is not anything like an official maemo release? -- View this message in context: http://n2.nabble.com/maemo-zoom2-worldclock-tp4625849p4625849.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo - zoom2 - worldclock
I'm going to make an educated guess that it is due to the lack of clockd on Zoom2 (check with dpkg -l) /Carsten maemo.org distmaster 2010/2/24 John Beattie john.beat...@accenture.com: I'm learning about maemo using zoom2 hardware. I have a bug where worldclock hangs when I make a certain sequence of user-input. I have used gdb to see what is going on, but without source, since this is a closed package, the clock-ui package. It looks as if the app spawns a thread to do something and then starts pthread_cond_timedwait. And then the thread quits very quickly and the originating thread never progresses. My question is whether it is worth raising this as an issue, since the zoom2 is only for development hacking and, further, my build is not anything like an official maemo release? -- View this message in context: http://n2.nabble.com/maemo-zoom2-worldclock-tp4625849p4625849.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ 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
Re: Maemo 5 PR1.2 and Extras
On Wed, Feb 24, 2010 at 15:30, Niels Breet ni...@maemo.org wrote: Also the normal 10 day quarantine should not apply to these case. I'm not sure if that is a good idea. The quarantine is there for a reason, the switch between these Qt releases can actually introduce issues. If we have the SDK in time, then the overlap will be minimal anyway. I was under the impression that for many Qt apps a simple repackaging will do the trick. If this is the case, would it not make sense to make those updates available? After all, before the updates are released to Extras, many users are going to have Qt apps that won't work on their N900. Surely we want to correct that as soon as possible. And what about existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2 is released? About that SDK. Could we have something on MADDE too? Cheers, Sascha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo - zoom2 - worldclock
OK, I've just checked that: OMAPZOOM2:~# dpkg -l | grep clock ii clock-ui0.5.32-1+0m5 UI part of the clock ii clockd 0.0.36+0m5 Clock daemon ii libclockcore0-0 0.5.15-1+0m5 Back-end library for Clock Application ii libtime-dev 0.0.36+0m5 Development files for clockd services ii libtime00.0.36+0m5 API for clockd service [plus lots of language packages for the clock] OMAPZOOM2:~# ps | grep clockd 1143 root 3336 S/usr/bin/clockd 3257 root 2092 Sgrep clockd OMAPZOOM2:~# The following is way more information than you asked for :-) For completeness, the hang is obtained by selecting the clock, then the dropdown menu, then the alarm settings, then alarm tine, then select one of the clock alarm buttons. If gdb is attached to the app first, then at the time that the final select is done, there is a message that a new LWP has been started and immediately that it quits. The hang is fixed in the end by a monitor whch observes that the task is not responding and asks of you want to quit. And this is some of the trace from gdb: (note that there may be spurious linefeeds in this) gdb) bt #0 0x401896ec in poll () from /lib/libc.so.6 #1 0x402f80a0 in g_poll () from /usr/lib/libglib-2.0.so.0 #2 0x402ead74 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x402ead74 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) c Continuing. [New LWP 1990] [LWP 1990 exited] Program received signal SIGINT, Interrupt. 0x401852f8 in chown () from /lib/libc.so.6 0x401852f8 chown+16: cmn r0, #4096 ; 0x1000 (gdb) bt #0 0x401852f8 in chown () from /lib/libc.so.6 #1 0x41142a70 in pa_make_secure_dir () from /usr/lib/libpulsecommon-0.9.15.so #2 0x41142bcc in pa_get_runtime_dir () from /usr/lib/libpulsecommon-0.9.15.so #3 0x4114313c in ?? () from /usr/lib/libpulsecommon-0.9.15.so #4 0x4114313c in ?? () from /usr/lib/libpulsecommon-0.9.15.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x40081da4 in pthread_cond_timedwait () from /lib/libpthread.so.0 0x40081da4 pthread_cond_timedwait+452:mov r8, r0 (gdb) bt #0 0x40081da4 in pthread_cond_timedwait () from /lib/libpthread.so.0 #1 0x429e60dc in gstreamer_driver_play () from /usr/lib/libcanberra-0.14/libcanberra-gstreamer.so #2 0x411d7438 in ?? () from /usr/lib/libcanberra.so.0 #3 0x411d7438 in ?? () from /usr/lib/libcanberra.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x40081da4 in pthread_cond_timedwait () from /lib/libpthread.so.0 0x40081da4 pthread_cond_timedwait+452:mov r8, r0 (gdb) bt #0 0x40081da4 in pthread_cond_timedwait () from /lib/libpthread.so.0 #1 0x429e60dc in gstreamer_driver_play () from /usr/lib/libcanberra-0.14/libcanberra-gstreamer.so #2 0x411d7438 in ?? () from /usr/lib/libcanberra.so.0 #3 0x411d7438 in ?? () from /usr/lib/libcanberra.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x400fb4b8 in raise () from /lib/libc.so.6 0x400fb4b8 raise+68: cmn r0, #4096 ; 0x1000 (gdb) -Original Message- From: Carsten Munk [mailto:carsten.m...@gmail.com] Sent: 24 February 2010 13:56 To: Beattie, John Cc: maemo-developers@maemo.org Subject: Re: maemo - zoom2 - worldclock I'm going to make an educated guess that it is due to the lack of clockd on Zoom2 (check with dpkg -l) /Carsten maemo.org distmaster 2010/2/24 John Beattie john.beat...@accenture.com: I'm learning about maemo using zoom2 hardware. I have a bug where worldclock hangs when I make a certain sequence of user-input. I have used gdb to see what is going on, but without source, since this is a closed package, the clock-ui package. It looks as if the app spawns a thread to do something and then starts pthread_cond_timedwait. And then the thread quits very quickly and the originating thread never progresses. My question is whether it is worth raising this as an issue, since the zoom2 is only for development hacking and, further, my build is not anything like an official maemo release? -- View this message in context: http://n2.nabble.com/maemo-zoom2-worldclock-tp4625849p4625849.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers This message is for
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 13:20:40 Thomas Tanner wrote: Why would anybody not upgrade the firmware? Why is backwards compatibility necessary for Fremantle minor releases? Enforcing the requirement could make our life so much easier. There can be a number of reasons, ranging from various regressions (like sticking to 42-11 because of WiFi issues in 51-1), policies (if it ain't broken, don't fix it, not all bugs affect all people), cost/stability (I might not want to upgrade when roaming) or simply firmware non-availability (firmwares are not rolled out simultaneously for all countries, ask UK folks :). Forced upgrades are usually a last-resort measure, done only if there is a legal reason (like compliance with some regulations, maybe things related to emergency calls, etc). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24.02.10 15:18, Attila Csipa wrote: On Wednesday 24 February 2010 13:20:40 Thomas Tanner wrote: Why would anybody not upgrade the firmware? Why is backwards compatibility necessary for Fremantle minor releases? Enforcing the requirement could make our life so much easier. There can be a number of reasons, ranging from various regressions (like sticking to 42-11 because of WiFi issues in 51-1), policies (if it ain't broken, don't fix it, not all bugs affect all people), cost/stability (I might not want to upgrade when roaming) or simply firmware non-availability (firmwares are not rolled out simultaneously for all countries, ask UK folks :). Forced upgrades are usually a last-resort measure, done only if there is a legal reason (like compliance with some regulations, maybe things related to emergency calls, etc). Forced upgrades of some components for installation of a new package is standard practice for all package management systems (keyword version dependencies). I think the main problem is that the mp-fremantle-pr packages hardcodes the exact version of all PR packages instead of specifying the minimum version. If a user could selectively upgrade a core package without conflicting with mp-fremantle-pr they would not be forced to completely upgrade the firmware for new extras apps. (BTW, the broken dependency specification in the PR also makes it impossible to remove unnecessary language packs) In a (Debian based) distribution the proper way to handle such conflicts would be to specify the minimum required version in each extras apps (e.g. qt4.5) and to switch to a new package name if the new package is no longer backwards compatible (qt4.6). If it not possible to install both qt4.5 and qt4.6 due to space constraints the user should have the option to either deinstall old qt4.5 apps or wait until all his extras apps are upgraded 4.6. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? A different .install file can be offered based on your browser string. How are you going to make sure you catch all of them ? For MicroB, okay, but Firefox, Tear, Midori, whatnot ? Does not really sound like a foolprof solution (you also need to sync with Maemo Select, and just hope that there are not too many links floating around) :( Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? There is not a lot we can do there. If a user adds the repository on an 'old' device, some applications just won't install because dependencies are missing. There are a few more troublesome scenarios that can present themselves - like if someone adds the old repo, and has a repo-refresh issue with the new one afterwards (I often have this problem with extras-testing and extras-devel). In both this and the scenario you mention, H-A-M/apt will prevent downgrades, luckily, but it's easy to cut off your own upgrade path if you DO manage to install something from the wrong repo. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. It would be helpful if this would be visible from the testing page, too (not just for 4.6). I have several Qt4.5 dependent packages in the QA queue nearing required quarantine delay fulfillment. It's just a waste of tester and developer time then. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Okay, so we basically ditch Qt4.5-compiled applications currently in Extras. Is the Ovi team aware of this as there are quite a few Qt 4.5 applications in Ovi repositories,too ? Will they get their fremantle1.2 repo, too (I know, ask them - wait for a meaningful response so long that it becomes moot :) ) or will they hope Qt ABI compatibility gets them through ? And if you think Ovi has no bearing on Extras downloads, take into consideration Firefox is in Ovi, so if browser string based info is used, it will bite you if it's not handled in a timely manner :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, Niels Breet wrote: Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? That would be forward compatible in my book ;) Tomayto-tomahto. backwards compatible usually means that new interfaces support old applications. Windows 95 was backwards compatible with Windows 3.1, so old .exes still ran unchanged. You didn't even have to recompile. That's what I'm asking - will PR 1.0 packages executables continue to work on PR1.2? Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Applications built on PR1.2 won't work on older versions. There are exceptions, some applications might work, but those make this very complicated. All applications? That seems unusual - especially since the GNOME project (and thus a bunch of the libraries in the API) work very hard to ensure API ABI compatibility. If I compile, unchanged, an application with the PR1.2 API which previously worked on PR1.0, I would expect the new package to continue to work correctly. I would expect it to stop working only after I started using interfaces not available in the old platform. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[OFF-Topic] Developers corner in Helsinki-Finland
Hi all, The reason of this e-mail is to purpose creating some developer corner in Helsinki. I am available to arrange the meeting place and to organize this unofficial gatherings in Helsinki. The main idea is to gather developers interested in MeeGo / Maemo and share information about projects and other kind of activities related to these technologies. Any idea is welcome. Cheers, Adrian Yanes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, Sascha Mäkelä wrote: I was under the impression that for many Qt apps a simple repackaging will do the trick. If this is the case, would it not make sense to make those updates available? After all, before the updates are released to Extras, many users are going to have Qt apps that won't work on their N900. Surely we want to correct that as soon as possible. And what about existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2 is released? I know of at least one case where Maemo-specific changes were made in Qt 4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon integration). So it is entirely possible that some apps which previously compiled will not do so after the upgrade. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24 February 2010 14:18, Attila Csipa ma...@csipa.in.rs wrote: simply firmware non-availability (firmwares are not rolled out simultaneously for all countries, ask UK folks :). Me me me! I really wish to know officially why PR1.1.1 still hasn't been rolled as OTA update for my device... -- Dawid 'evad' Lorenz * http://adl.pl null://signatures are for wimps ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 15:43:47 Thomas Tanner wrote: In a (Debian based) distribution the proper way to handle such conflicts would be to specify the minimum required version in each extras apps (e.g. qt4.5) and to switch to a new package name if the new package is no longer backwards compatible (qt4.6). If it not possible to install both qt4.5 and qt4.6 due to space constraints the user should have the option to either deinstall old qt4.5 apps or wait until all his extras apps are upgraded 4.6. The complications stem from the way this is handled in Maemo, at least for Qt. I just hope this slightly complex PR1.2 Qt transition is not a snowball effect of how some Maemoisms were added (hacked :) ) into Qt4.5/4.6 and even more that this is not a sign of how these things will be handled in the future. Backwards compatibility was something Qt4 was very well known for, and desktop environments often bump their Qt versions for backports (hell, even LTS versions of Ubuntu did that), without requiring repository/application hoop-jumping. Forced upgrades of some components for installation of a new package is standard practice for all package management systems (keyword version dependencies). It seems we have a different definition of forced upgrade :) (I would use the required term for what you described) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hello, On Wednesday 24 of February 2010, Dave Neary wrote: Sascha Mäkelä wrote: I was under the impression that for many Qt apps a simple repackaging will do the trick. If this is the case, would it not make sense to make those updates available? After all, before the updates are released to Extras, many users are going to have Qt apps that won't work on their N900. Surely we want to correct that as soon as possible. And what about existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2 is released? I know of at least one case where Maemo-specific changes were made in Qt 4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon integration). So it is entirely possible that some apps which previously compiled will not do so after the upgrade. Is this a library-only issue or a system issue? i.e. is the problem in the new qt library or (let's say) in the capabilities of the new system's components (e.g. removed dbus interfaces). If this is a library-only issue, then there is no reason (except from disk space, but /opt should be a viable solution) why you could not have the newer versions of problematic libraries coexist with their old versions. For example, one could have both libqt4-core and libqt4-6-core. Old apps will still be linked against libqt4-core while new apps will be linked against libqt4-6-core. Then, at some point at the future (PR1.3 ?) you could completely remove those old libraries. ... then again I do not have much experience on doing such things. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [MeeGo-dev] [OFF-Topic] Developers corner in Helsinki-Finland
hello, The main idea is to gather developers interested in MeeGo / Maemo and share information about projects and other kind of activities related to these technologies. count on me. Any idea is welcome. how about encouraging students to learn these technologies even more, organizing events like the following: http://mobiledevcamp.fi/ I dont know how many students/developers are in this mailist and in the helsinki area (apart from myself) but I think we can always take the advantage of getting support from Nokia people and other companies. Cheers, Adrian Yanes. ___ MeeGo-dev mailing list meego-...@meego.com http://lists.meego.com/listinfo/meego-dev best, -- Gibran Rodriguez ---apt-get install maemo-meego-dev*--- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Graham Cobb wrote: I can't say I like this. My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? Can we keep track of stats showing how many people are accessing the old repository? How can you not like this? What is your reasoning? You brought this same response to the last Maemo update, and I still do not understand it. If a user has access to downloading apps, then they will be notified of the Maemo update. If they want a new app, they must update Maemo, but they can continue using their old apps as long as they want. Refusing to update because of a personal preference should be discounted. Security updates, new features, and significant bug fixes should trump any personal preference about updates to Maemo itself. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? Why not have 2 repos for Extras 1 called Extras Legacy (aka current Extras) 1 called Extras (aka fremantle-1.2 Extras) The only inconvenience I can think of is users have an addtional repo on the list, shouldn't do any harm! Cheers -- View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626546.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Thomas Tanner wrote: Forced upgrades of some components for installation of a new package is standard practice for all package management systems (keyword version dependencies). I think the main problem is that the mp-fremantle-pr packages hardcodes the exact version of all PR packages instead of specifying the minimum version. If a user could selectively upgrade a core package without conflicting with mp-fremantle-pr they would not be forced to completely upgrade the firmware for new extras apps. (BTW, the broken dependency specification in the PR also makes it impossible to remove unnecessary language packs) I agree with you completely with your first post, however, you touched on why Maemo doesn't work this way. For the time being, the proposal Niels suggested is the least messy. We're not creating a new Maemo 5 sub-version this way. Maemo/Nokia folks - is there any plans on implementing the brainstorm idea[1] on open-source packages any time before MeeGo? This would alleviate some of the update mess. Closed binaries could then be included into a smaller Maemo 5 update that can work with the Extras repo without having to branch it. [1] http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 16:42:16 Michael Cronenworth wrote: the Maemo update. If they want a new app, they must update Maemo, but they can continue using their old apps as long as they want. Refusing to update because of a personal preference should be discounted. Security updates, new features, and significant bug fixes should trump any personal preference about updates to Maemo itself. Still, that does not address the question of regressions. For example WiFi (which I use a lot) in 51-1 had a regression that was in my particular case so bad I had to revert to 42-11 until a fix was introduced with 2-8. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, On Wed, Feb 24, 2010 at 5:06 PM, Attila Csipa ma...@csipa.in.rs wrote: The complications stem from the way this is handled in Maemo, at least for Qt. I just hope this slightly complex PR1.2 Qt transition is not a snowball effect of how some Maemoisms were added (hacked :) ) into Qt4.5/4.6 and even more that this is not a sign of how these things will be handled in the future. Backwards compatibility was something Qt4 was very well known for, and desktop environments often bump their Qt versions for backports (hell, even LTS versions of Ubuntu did that), without requiring repository/application hoop-jumping. Qt packaging now is managed by Qt team and this will be first official Qt-supported version of Qt to Maemo platform. So many two-letter acronyms in one sentence... Anyway, this is a bit different from desktop case as package maintainers are changed for Qt delivery (from community volunteers to Nokia Trolls) and apparently the way to package is changed as well. I have not compared it with the Debian or other distributions' builds though. Whatever is included in Qt build for Maemo is maintained by Trolltech team. This should leave questions regarding the compatibility answered, I hope. And actual source code is in qt.gitorious.org. -- / Alexander Bokovoy ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Venomrush wrote: Why not have 2 repos for Extras 1 called Extras Legacy (aka current Extras) 1 called Extras (aka fremantle-1.2 Extras) The only inconvenience I can think of is users have an addtional repo on the list, shouldn't do any harm! They will fragment the Maemo 5 community unless the auto-builder will build across both repos, as I will not be updating my apps on a Legacy repo if one is created. The way you propose makes it seem like Nokia is releasing a whole new Maemo version (Maemo 5 - Maemo 5.99), which is not what should be visible to the end-user. Maemo 5 should continue being Maemo 5. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo 5 PR1.2 and Extras
-Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of ext Niels Breet Sent: 24 February, 2010 14:19 To: Attila Csipa Cc: maemo-developers@maemo.org Subject: Re: Maemo 5 PR1.2 and Extras On Wednesday 24 February 2010 12:21:45 Niels Breet wrote: What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Some may and some don't. Some Qt apps compiled against 4.5 will work with 4.6 without any issues. I do not know which part of the ABI has changed, so no idea what would break. Sorry, no statistics on this one, just some small personal tests. To be safe it would make sense to recompile the Qt apps with the 1.2 SDK when letting them to Fremantle-1.2. Tero Regards, Attila -- Niels Breet maemo.org webmaster ___ 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
Re: Maemo 5 PR1.2 and Extras
Hi, Michael Cronenworth wrote: How can you not like this? What is your reasoning? You brought this same response to the last Maemo update, and I still do not understand it. Let's say that there are 10,000 applications in Extras. Now every N900 owner can get all of those apps. Then a new version of the SDK comes out, which is not backwards compatible. A number of potentially bad things can happen: 1. New uploads get compiled with the new SDK, and get downloaded onto phones with the old OS, where they don't work. 2. Developers working with the old SDK upload applications which don't even build with the new SDK 3. To mitigate 2, we decide that all Extras apps need to be recompiled with the new SDK, resulting in a number of applications which fit into both the categories above - some apps stop working until the user upgrades the firmware, other apps don't build require changes and an SDK upgrade from the developer. All of these push inconvenience to the phone user application developer - all unnecessary overhead, especially if the APIs haven't changed and there are issues with run-time library versions (as we saw with PR 1.0 to 1.1). The only way to avoid badness when upgrading the SDK in a not-backwards-compatible way is to have scratchbox, every developer copy of the SDK, and the N900 firmware all upgrade at the same time. I imagine that this is why Graham's not happy about an SDK which isn't backwards compatible. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? A different .install file can be offered based on your browser string. How are you going to make sure you catch all of them ? For MicroB, okay, but Firefox, Tear, Midori, whatnot ? Does not really sound like a foolprof solution (you also need to sync with Maemo Select, and just hope that there are not too many links floating around) :( I see no way to support other browsers if they don't expose the installed OS version. But I think this is how Ovi checks it too? Maemo Select links directly to us, so there is no issue with .install files there. Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? There is not a lot we can do there. If a user adds the repository on an 'old' device, some applications just won't install because dependencies are missing. There are a few more troublesome scenarios that can present themselves - like if someone adds the old repo, and has a repo-refresh issue with the new one afterwards (I often have this problem with extras-testing and extras-devel). In both this and the scenario you mention, H-A-M/apt will prevent downgrades, luckily, but it's easy to cut off your own upgrade path if you DO manage to install something from the wrong repo. If you break something, you get to keep both pieces. Being able to break things yourself is a powerful thing. I don't see how we can prevent installing something from a wrong repo. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. It would be helpful if this would be visible from the testing page, too (not just for 4.6). I have several Qt4.5 dependent packages in the QA queue nearing required quarantine delay fulfillment. It's just a waste of tester and developer time then. Well, no. They can still end up in fremantle for PR1.1 and lower. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Okay, so we basically ditch Qt4.5-compiled applications currently in Extras. Is the Ovi team aware of this as there are quite a few Qt 4.5 applications in Ovi repositories,too ? Will they get their fremantle1.2 repo, too (I know, ask them - wait for a meaningful response so long that it becomes moot :) ) or will they hope Qt ABI compatibility gets them through ? And if you think Ovi has no bearing on Extras downloads, take into consideration Firefox is in Ovi, so if browser string based info is used, it will bite you if it's not handled in a timely manner :) Don't know what Ovi is going to do, but my bet is that Nokia aims at Qt4.6 anyway to in line with Symbian? Just trying to do the best thing for everybody, easiest would be just to not care about older OS versions. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
They will fragment the Maemo 5 community unless the auto-builder will build across both repos, as I will not be updating my apps on a Legacy repo if one is created. The way you propose makes it seem like Nokia is releasing a whole new Maemo version (Maemo 5 - Maemo 5.99), which is not what should be visible to the end-user. Maemo 5 should continue being Maemo 5. It's such a big change that we're discussing about it right now. You do not need to update any apps in Legacy. Apps in Legacy remains the same and does not get any further development work. It's there so: 1. Users can browse pre-PR1.2 apps that are already working (apps without needing to update to work with PR1.2) 2. Apps in Legacy repo not working in PR1.2 gets updated and put into the new Extras get removed from Legacy repo too Post-PR1.2, all development effort should be put into updating apps for the new Extras. I hope it's abit clearer now. Cheers -- View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626768.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Dave Neary on 02/24/2010 10:01 AM wrote: 1. New uploads get compiled with the new SDK, and get downloaded onto phones with the old OS, where they don't work. How? The only way that could happen is if a power-user downloaded the file manually and attempted to use dpkg manually. This should be frowned upon. 2. Developers working with the old SDK upload applications which don't even build with the new SDK The auto-builder builds our apps. Their builds would fail and never make it to Extras. 3. To mitigate 2, we decide that all Extras apps need to be recompiled with the new SDK, resulting in a number of applications which fit into both the categories above - some apps stop working until the user upgrades the firmware, other apps don't build require changes and an SDK upgrade from the developer. It happens all the time in other Linux distributions. Fedora just went through the Qt4.5 to 4.6 transition itself! I don't see why there is resistance to this when it is a very minor change. If such resistance is warranted, let's call this Maemo 5.2 instead of Maemo 5. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wed, Feb 24, 2010 at 6:01 PM, Dave Neary dne...@maemo.org wrote: 2. Developers working with the old SDK upload applications which don't even build with the new SDK That's their own screwup, I guess (which they notice immediately when trying to upload). The group most impacted are the Qt users, which are quite likely to be eagerly waiting for 4.6.2 anyway (so it won't come as a surprise). The only way to avoid badness when upgrading the SDK in a not-backwards-compatible way is to have scratchbox, every developer copy of the SDK, and the N900 firmware all upgrade at the same time. I Undoubtedly there will be certain degree of badness. Niels' current suggestion at least avoids the badness on user end. Barring regressions, we can probably expect everybody to upgrade to 1.2 in timely manner. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Venomrush wrote: You do not need to update any apps in Legacy. Apps in Legacy remains the same and does not get any further development work. That's what Niels is proposing, unless I am mistaken. fremantle = Legacy fremantle-1.2 = The new Extras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
You do not need to update any apps in Legacy. Apps in Legacy remains the same and does not get any further development work. Hmm sorry for the confusion, I should say if apps in Legacy are getting updates, they'll be move to Extras. It's not exactly what Niels's proposing, but just my suggestion. -- View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626893.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 17:25:20 Michael Cronenworth wrote: Dave Neary on 02/24/2010 10:01 AM wrote: 1. New uploads get compiled with the new SDK, and get downloaded onto phones with the old OS, where they don't work. How? The only way that could happen is if a power-user downloaded the file manually and attempted to use dpkg manually. This should be frowned upon. .install files, which have been increasingly stated as the preferred method of installing software, also contain repository information. That's how Ovi works, that's how Maemo Select works, and that's how maemo.org/downloads works, so it's not unfathomable that users end up with the wrong repositories. Regard, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 15:42:16 Michael Cronenworth wrote: Graham Cobb wrote: I can't say I like this. My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? Can we keep track of stats showing how many people are accessing the old repository? How can you not like this? What is your reasoning? You brought this same response to the last Maemo update, and I still do not understand it. I am sure we wil have to agree to differ but you asked my reasoning, so here it is... I think that many users will never upgrade the OS, and of those who do, their upgrades will be spread over a period of many months. As a hobbyist developer I release and support my software because I like to make it available to people. I don't think the Maemo infrastructure should prevent me from supporting my users who choose not to upgrade, and nor should it prevent some new app I create from having access to those users. Why do I think many people will not upgrade? This device is a phone. I never upgraded my last phone, I have never upgraded my work-provided Blackberry, I don't know a single person amongst my friends who has ever upgraded their phone OS, for any reason. Many people will be very worried about upgrading the phone OS -- this is an expensive device: if it ain't broke, don't fix it. I don't have any data but my guess is that 50% of people who buy an N900 will never upgrade the OS on it. We have some very limited data from the earlier Maemo devices. Those were not phones -- they were much more like computers. I think most people upgraded them but still some chose not to (even though the first version of the 770 software had a serious data corruption bug). I still support those users and I would like to be able to continue to support my N900 users who choose not to upgrade. More seriously, I believe that there is still no Vodafone UK release of PR1.1.1 (is there of PR1.1 yet?). The customised software releases are not released at the same time as the general release -- those users cannot upgrade until their operator chooses to release the new version (which may be never!). If a user has access to downloading apps, then they will be notified of the Maemo update. If they want a new app, they must update Maemo, but they can continue using their old apps as long as they want. Refusing to update because of a personal preference should be discounted. Security updates, new features, and significant bug fixes should trump any personal preference about updates to Maemo itself. Sorry, no. I choose not to discount personal preferences. I'm not expecting you to agree but you asked why. You are free to choose that you will not support users running on anything other than the latest OS. Just don't force the same decision on me. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 16:26:44 Ville M. Vainio wrote: Barring regressions, we can probably expect everybody to upgrade to 1.2 in timely manner. I disagree, but I may be completely wrong. It will be very interesting to see. What do you consider timely? 3 months? My prediction: in 3 months time, 50% of N900 devices will still be checking the fremantle, not the fremantle-1.2 repository. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wed, Feb 24, 2010 at 7:08 PM, Graham Cobb g+...@cobb.uk.net wrote: On Wednesday 24 February 2010 16:26:44 Ville M. Vainio wrote: Barring regressions, we can probably expect everybody to upgrade to 1.2 in timely manner. I disagree, but I may be completely wrong. It will be very interesting to see. What do you consider timely? 3 months? My prediction: in 3 months time, 50% of N900 devices will still be checking the fremantle, not the fremantle-1.2 repository. My guess would be few weeks. N900 is an enthusiast device, for better or worse. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QMainWindow crashes when it closes while the menu is visible
Greetings; I have a little bit strange crash that occurs in my Qt application. I have a QMainWindow Object that has a QMediaObject object inside it to play sound. When the sound player finishes, the QMainWindow sends a signal to its parent, so the parent can close it (programatically, by calling window-close(); and my QMainWindow is set to DeleteOnClose). Everything works fine with no problems at all. But when I view the menu in that window, and it closes (when sound player returns), the application crashes I don't know what is wrong with that issue. why does it crash when the menu is shown? and how to avoid that issue ?? is there's a way to detect the open menubar and close it programatically before destroying the application ??? any assistance is higly appreciated; thanks in advance; ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24.02.10 18:04, Graham Cobb wrote: Why do I think many people will not upgrade? This device is a phone. The N900 is a mobile computer. If you want to use it as a phone, i.e. without applications from extras or Ovi, then there is no need to upgrade the firmware. If you want to use it as a computer by installing applications, you should upgrade your OS, especially to get security updates for a Internet-centric device. Maintaining software and working around bugs for every minor release is a nightmare. Only for different major releases and devices it is justified. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QMainWindow crashes when it closes while the menu is visible
Hi ibrahim, Are you using 4.5 or 4.6? Could you show us a backtrace? Thanks, Antonio On Wed, Feb 24, 2010 at 7:10 PM, ibrahim ibrahim@asgatech.com wrote: Greetings; I have a little bit strange crash that occurs in my Qt application. I have a QMainWindow Object that has a QMediaObject object inside it to play sound. When the sound player finishes, the QMainWindow sends a signal to its parent, so the parent can close it (programatically, by calling window-close(); and my QMainWindow is set to DeleteOnClose). Everything works fine with no problems at all. But when I view the menu in that window, and it closes (when sound player returns), the application crashes I don't know what is wrong with that issue. why does it crash when the menu is shown? and how to avoid that issue ?? is there's a way to detect the open menubar and close it programatically before destroying the application ??? any assistance is higly appreciated; thanks in advance; ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Ted Turner http://www.brainyquote.com/quotes/authors/t/ted_turner.html - Sports is like a war without the killing. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wed, Feb 24, 2010 at 7:04 PM, Graham Cobb g+...@cobb.uk.net wrote: I'm not expecting you to agree but you asked why. You are free to choose that you will not support users running on anything other than the latest OS. Just don't force the same decision on me. Not upgrading (again, barring regressions that are a sad exception) is a sort of statement about willingness to disconnect from the mainstream of community (their bugreports are worthless, they won't be checking out the new Qt apps etc). I don't think it's community's (here, I mean extras infrastructure) to keep catering for people that don't want to go where the platform is going. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 17:23:19 Ville M. Vainio wrote: On Wed, Feb 24, 2010 at 7:04 PM, Graham Cobb g+...@cobb.uk.net wrote: I'm not expecting you to agree but you asked why. You are free to choose that you will not support users running on anything other than the latest OS. Just don't force the same decision on me. Not upgrading (again, barring regressions that are a sad exception) is a sort of statement about willingness to disconnect from the mainstream of community (their bugreports are worthless, they won't be checking out the new Qt apps etc). I don't think it's community's (here, I mean extras infrastructure) to keep catering for people that don't want to go where the platform is going. That is completely different. Maemo Extras is not about community members. It is about the hundreds of thousands of ordinary users of the device who don't even know there is a Maemo community -- they just want to enjoy the apps they can download to their phone. I don't make my apps available for community members -- most community members could do that for themselves -- I make them available for the people who are NOT community members but are just users of the device! These are people who have never (ever) logged into a forum (yes, I realise that people on this list under 20 years old won't believe such people actually exist, but they do!). They are the ones who won't see any point in upgrading. And the ones I have in mind when talking about how Extras should work. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 17:18:29 Thomas Tanner wrote: On 24.02.10 18:04, Graham Cobb wrote: Why do I think many people will not upgrade? This device is a phone. The N900 is a mobile computer. I am talking about the people who perceive it to be a phone. Like the iPhone. Maintaining software and working around bugs for every minor release is a nightmare. Only for different major releases and devices it is justified. You are welcome to your view. Mine is different. And the infrastructure should not prevent me from supporting users who choose not to upgrade, if I wish. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Twitter client for Maemo in Qt + Python: let's make the point
Hello guys, first of all I want to thank all the people who replied to my previous email, I really didn't expect so much interest! I've gathered all the informations you gave me, making a list of all developers interested in helping in this project and another list of similar projects. These are the people interested in working to this project: - Sivan Greenberg - Gibran Rodriguez - Nicola De Filippo - Nirav Ranpara - Adrian Yanes - Amir B - Randall Arnold and these are the currently available similar projects: - Witter - http://garage.maemo.org/projects/witter (Python/Gtk) - Twitter-local - http://gitorious.org/twitter-local (C++/Qt) - qTwitter - http://www.qt-apps.org/content/show.php/qTwitter?content=99087 (not a Maemo project) - twcano - http://gitorious.org/twcano (Python/Qt) My personal idea is to join the twcano project, since it's Python/Qt based and, having tested it on Scratchbox, it's already very nice! So, talking to the people who told me to be interested, why don't we join the twcano project? Regards, -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QMainWindow crashes when it closes while the menu is visible
Antonio Aloisio wrote: Hi ibrahim, Are you using 4.5 or 4.6? Could you show us a backtrace? i am using 4.5.3. and iam afraid i don't know how to produce the backtrace. Thanks, Antonio On Wed, Feb 24, 2010 at 7:10 PM, ibrahim ibrahim@asgatech.com mailto:ibrahim@asgatech.com wrote: Greetings; I have a little bit strange crash that occurs in my Qt application. I have a QMainWindow Object that has a QMediaObject object inside it to play sound. When the sound player finishes, the QMainWindow sends a signal to its parent, so the parent can close it (programatically, by calling window-close(); and my QMainWindow is set to DeleteOnClose). Everything works fine with no problems at all. But when I view the menu in that window, and it closes (when sound player returns), the application crashes I don't know what is wrong with that issue. why does it crash when the menu is shown? and how to avoid that issue ?? is there's a way to detect the open menubar and close it programatically before destroying the application ??? any assistance is higly appreciated; thanks in advance; ___ maemo-developers mailing list maemo-developers@maemo.org mailto:maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Ted Turner http://www.brainyquote.com/quotes/authors/t/ted_turner.html - Sports is like a war without the killing. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
UK Maemo firmware location = Rapidshare??!
Hey there, Does anyone know why the current N900 UK firmware is only available on rapidshare? http://wiki.maemo.org/Maemo_UK_variant_firmware I installed stuff from extras-devel and thus my n900 wants me to flash it - I'd be happy to do so, however downloading the firmware has proved somewhat of a challenge. Someone has been using Rapidshare as a usable file host. http://rapidshare.com/files/346892600/RX-51_2009SE_2.2009.51-1.203.2_PR_F5_203_ARM.bin which is meant to allow one to download the latest UK generic firmware won't allow me to download the relevant file due to rapidshare being completely unhelpful and fail and wanting me to pay to download from it. Considering I bought the bleeding device (which I love dearly!) does anyone know of a reason these files aren't available from a *.maemo.org or *.nokia.com site...? :) I'd really really like to upgrade my phone soon! :) Any help or pointers is always appreciated. :) Cheers, Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing for Maemo 5 using Qt
Ville, now it's official :) http://labs.trolltech.com/blogs/2010/02/24/qt-for-maemo-5-home-screen-widgets/ Thanks for your help. Now... i just need to check QMobility and it's use in Maemo 5. Cheers 2010/2/23 Ville M. Vainio vivai...@gmail.com On Tue, Feb 23, 2010 at 11:53 AM, Sun Yalong yalong@digia.com wrote: No, hybrid application is more like an application composed of web view + javascript that talks to C++ through QObjects exposed to it. Got a question that: is it possible to add hybrid application on Home screen like Widget does. Yes, there is nothing special about them. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: UK Maemo firmware location = Rapidshare??!
Someone has been using Rapidshare as a usable file host. http://rapidshare.com/files/346892600/RX-51_2009SE_2.2009.51-1.203.2_PR_F5_203_ARM.bin which is meant to allow one to download the latest UK generic firmware won't allow me to download the relevant file due to rapidshare being completely unhelpful and fail and wanting me to pay to download from it. I'm pretty sure Rapidshare is free and does not require you to pay to download. AFAIK you have to wait a minute or two when downloading. Rapidshare was used as a temporally option. Chris Pitchford has offered to provide hosting for UK firmwares. The main point being, MD5/SHA1 information should be available for all firmware versions/variants in tablets-dev not just the one currently listed in there, so for those firmwares Nokia 'refuse' to put/host in tablets-dev they can be mirrored elsewhere + when tablets-dev is down, tablets-dev has been down for several occasions. See https://bugs.maemo.org/show_bug.cgi?id=6878 for discussion. Cheers -- View this message in context: http://n2.nabble.com/UK-Maemo-firmware-location-Rapidshare-tp4628086p4628377.html Sent from the maemo-developers mailing list archive at Nabble.com. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: UK Maemo firmware location = Rapidshare??!
Hi, Am Mittwoch, den 24.02.2010, 19:43 + schrieb Tim Dobson: Does anyone know why the current N900 UK firmware is only available on rapidshare? In short: Because some people inside of Nokia simply haven't gotten their job done yet in this case, which is quite annoying for a large number of customers. andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing for Maemo 5 using Qt
Thanks for the links. Seems that platform compatibility chart is a bit out of date, as AFAIK Maemo 6 will never appear with that name. Anyway, i will check the APIs. 2010/2/24 Daniil Ivanov daniil.iva...@gmail.com Hi Jose! QtMobility is already available. API should be quite stable at the moment. http://qt.nokia.com/developer/new-qt-apis The only problem with Maemo 5 backend: http://qt.nokia.com/doc/qtmobility-1.0-beta/index.html#platform-compatability Thanks, Daniil. On Wed, Feb 24, 2010 at 10:06 PM, Jose Maria Garcia-Valdecasas jgvaldeca...@gmail.com wrote: Ville, now it's official :) http://labs.trolltech.com/blogs/2010/02/24/qt-for-maemo-5-home-screen-widgets/ Thanks for your help. Now... i just need to check QMobility and it's use in Maemo 5. Cheers 2010/2/23 Ville M. Vainio vivai...@gmail.com On Tue, Feb 23, 2010 at 11:53 AM, Sun Yalong yalong@digia.com wrote: No, hybrid application is more like an application composed of web view + javascript that talks to C++ through QObjects exposed to it. Got a question that: is it possible to add hybrid application on Home screen like Widget does. Yes, there is nothing special about them. -- Ville M. Vainio http://tinyurl.com/vainio ___ 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
Problem running ogles2 program on Nokia N900
I have successfully compiled an OpenGL ES 2.0 program on scratchbox for
the FREMANTILE_ARMEL plattform. However, when running the program on Nokia
N900 the compilation of the vertex and fragment shaders fails. This is the
error code:
Failed to compile fragment shader: Compile failed.
ERROR: 0:1: 'varying' : syntax error; parse error
ERROR: 1 compilation errors. No code generated.
Failed to compile fragment shader: Compile failed.
ERROR: 0:1: 'attribute' : syntax error; parse error
ERROR: 1 compilation errors. No code generated.
Failed to link program: Link Error: Vertex shader is missing.
Link Error: Fragment shader is missing.
--
This is my vertex shader:
const char* pszVertShader = \
highp attribute vec4 myVertex;\
lowp attribute vec4 fargKod;\
mediump attribute vec2 myUV;\
highp uniform mat4 yRotMatris;\
highp uniform mat4 xRotMatris;\
highp uniform mat4 frustMatris;\
lowp varying vec4 outColor;\
mediump varying vec2 myTextCoord;\
void main(void)\
{\
outColor = fargKod;\
myTextCoord = myUV;\
gl_Position = myVertex * yRotMatris * xRotMatris;\
};
and this is my fragment shader:
const char* pszFragShader = \
uniform sampler2D sampler2d;\
mediump varying vec2 myTextCoord;\
void main (void)\
{\
gl_FragColor = texture2D(sampler2d,myTextCoord);\
};
These shader compile successfully and works fine when I run the same
OGLES2 program in the simulation environment.
Does anyone have a clue what could be wrong? Is there perhaps something
that need to be installed on the Nokia N900 to add shader compilation
support to it???
/Jonny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Twitter client for Maemo in Qt + Python: let's make the point
Hi guys. It would be nice to get some help on Twcano, we can discuss the current architecture and propose changes if necessary. If someone want more information about the project or help to test this on n900 (debian packages still missing, I want fix some bugs before produce one), visit the #pyside channel at freenode. These are some images of Twcano running on n900: http://img696.imageshack.us/img696/6971/screenshot02.png http://img682.imageshack.us/img682/9239/screenshot03c.png BR Renato Araujo Oliveira Filho On Wed, Feb 24, 2010 at 4:12 PM, Andrea Grandi a.gra...@gmail.com wrote: Hello guys, first of all I want to thank all the people who replied to my previous email, I really didn't expect so much interest! I've gathered all the informations you gave me, making a list of all developers interested in helping in this project and another list of similar projects. These are the people interested in working to this project: - Sivan Greenberg - Gibran Rodriguez - Nicola De Filippo - Nirav Ranpara - Adrian Yanes - Amir B - Randall Arnold and these are the currently available similar projects: - Witter - http://garage.maemo.org/projects/witter (Python/Gtk) - Twitter-local - http://gitorious.org/twitter-local (C++/Qt) - qTwitter - http://www.qt-apps.org/content/show.php/qTwitter?content=99087 (not a Maemo project) - twcano - http://gitorious.org/twcano (Python/Qt) My personal idea is to join the twcano project, since it's Python/Qt based and, having tested it on Scratchbox, it's already very nice! So, talking to the people who told me to be interested, why don't we join the twcano project? Regards, -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ 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
Re: UK Maemo firmware location = Rapidshare??!
On Wednesday 24 February 2010, Tim Dobson wrote: Hey there, Does anyone know why the current N900 UK firmware is only available on rapidshare? http://wiki.maemo.org/Maemo_UK_variant_firmware I installed stuff from extras-devel and thus my n900 wants me to flash it - I'd be happy to do so, however downloading the firmware has proved somewhat of a challenge. If you're going to flash, why not flash the global firmware? Or will Bad Things(TM) happen from that? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Graham Cobb wrote: My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? FYI My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov. The device never reminded her again. She only got pr1.1.1 because she noticed my device made a sound on account connections and hers didn't... I did 2 upgrades in succession. Normal users wouldn't have even noticed. I've filed a bug but if this is normal behaviour then I guess a *lot* of devices will never be upgraded. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Developing for Maemo 5 using Qt
From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Jose Maria Garcia-Valdecasas [jgvaldeca...@gmail.com] Sent: Wednesday, February 24, 2010 11:15 PM To: Daniil Ivanov Cc: maemo-developers@maemo.org Subject: Re: Developing for Maemo 5 using Qt Thanks for the links. Seems that platform compatibility chart is a bit out of date, as AFAIK Maemo 6 will never appear with that name. It is also out of the date for Maemo 5 features. Messaging, Contacts and Multimedia is going in pipeline and should appear with most features in external repo very soon. Bearer managementhas some dependency problem but they should be resolved also soon. Kate Anyway, i will check the APIs. 2010/2/24 Daniil Ivanov daniil.iva...@gmail.commailto:daniil.iva...@gmail.com Hi Jose! QtMobility is already available. API should be quite stable at the moment. http://qt.nokia.com/developer/new-qt-apis The only problem with Maemo 5 backend: http://qt.nokia.com/doc/qtmobility-1.0-beta/index.html#platform-compatability Thanks, Daniil. On Wed, Feb 24, 2010 at 10:06 PM, Jose Maria Garcia-Valdecasas jgvaldeca...@gmail.commailto:jgvaldeca...@gmail.com wrote: Ville, now it's official :) http://labs.trolltech.com/blogs/2010/02/24/qt-for-maemo-5-home-screen-widgets/ Thanks for your help. Now... i just need to check QMobility and it's use in Maemo 5. Cheers 2010/2/23 Ville M. Vainio vivai...@gmail.commailto:vivai...@gmail.com On Tue, Feb 23, 2010 at 11:53 AM, Sun Yalong yalong@digia.commailto:yalong@digia.com wrote: No, hybrid application is more like an application composed of web view + javascript that talks to C++ through QObjects exposed to it. Got a question that: is it possible to add hybrid application on Home screen like Widget does. Yes, there is nothing special about them. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.orgmailto: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
Re: Developing for Maemo 5 using Qt
Thanks for the update Kate. One question regarding QMobility, just in case you know the answer. Will QMobility API allow access to phone info? For example, check lost calls, last call, time of each call and so on. There seems to be an API for messages, but have not seen anything about specific phone features. Cheers, Jose 2010/2/24 kate.alh...@nokia.com From: maemo-developers-boun...@maemo.org [ maemo-developers-boun...@maemo.org] On Behalf Of ext Jose Maria Garcia-Valdecasas [jgvaldeca...@gmail.com] Sent: Wednesday, February 24, 2010 11:15 PM To: Daniil Ivanov Cc: maemo-developers@maemo.org Subject: Re: Developing for Maemo 5 using Qt Thanks for the links. Seems that platform compatibility chart is a bit out of date, as AFAIK Maemo 6 will never appear with that name. It is also out of the date for Maemo 5 features. Messaging, Contacts and Multimedia is going in pipeline and should appear with most features in external repo very soon. Bearer managementhas some dependency problem but they should be resolved also soon. Kate Anyway, i will check the APIs. 2010/2/24 Daniil Ivanov daniil.iva...@gmail.commailto: daniil.iva...@gmail.com Hi Jose! QtMobility is already available. API should be quite stable at the moment. http://qt.nokia.com/developer/new-qt-apis The only problem with Maemo 5 backend: http://qt.nokia.com/doc/qtmobility-1.0-beta/index.html#platform-compatability Thanks, Daniil. On Wed, Feb 24, 2010 at 10:06 PM, Jose Maria Garcia-Valdecasas jgvaldeca...@gmail.commailto:jgvaldeca...@gmail.com wrote: Ville, now it's official :) http://labs.trolltech.com/blogs/2010/02/24/qt-for-maemo-5-home-screen-widgets/ Thanks for your help. Now... i just need to check QMobility and it's use in Maemo 5. Cheers 2010/2/23 Ville M. Vainio vivai...@gmail.commailto:vivai...@gmail.com On Tue, Feb 23, 2010 at 11:53 AM, Sun Yalong yalong@digia.com mailto:yalong@digia.com wrote: No, hybrid application is more like an application composed of web view + javascript that talks to C++ through QObjects exposed to it. Got a question that: is it possible to add hybrid application on Home screen like Widget does. Yes, there is nothing special about them. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.orgmailto: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
Re: reloading a status bar plugin
2010/2/24 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Wed, 2010-02-24 at 13:21 +0100, ext b0unc3 wrote: ... dsmetool -k /usr/bin/hildon-status-menu dsmetool -t /usr/bin/hildon-status-menu This is the current way I'm doing that, but, as you said, it's ugly. Yes, because The Right Way is for your plugin to load the new settings without requiring reloading of the plugin. That should be doable for all settings, no? You can look e.g. hildon-desktop that reloads its /usr/share/hildon-desktop/transitions.ini configuration on-the-fly. Using Gconf settings (and handling change notifications for them) is another alternative. Yes GConf is the best alternative nowdays (it works like a charm now :)). I didn't know why I haven't think to use it before. Btw, thanks for your help. -Kimmo Best Regards, Daniele Maio. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
change the geotag server
hello in my country the info for ovimaps an google/maps is very poor, can i change this map service for openstreetmap? i need this for photo geotaging and gtalk status update. thks freed -- http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Twitter client for Maemo in Qt + Python: let's make the point
Hi, On 24 February 2010 22:41, Renato Araujo rena...@gmail.com wrote: Hi guys. It would be nice to get some help on Twcano, we can discuss the current architecture and propose changes if necessary. If someone want more information about the project or help to test this on n900 (debian packages still missing, I want fix some bugs before produce one), visit the #pyside channel at freenode. These are some images of Twcano running on n900: http://img696.imageshack.us/img696/6971/screenshot02.png http://img682.imageshack.us/img682/9239/screenshot03c.png feel free to add me to the project, my user is this: http://gitorious.org/~andreagrandi -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
qmake
I'm having problems building my package using qmake on extra-devels. make[1]: Entering directory `/home/builder1/maemo-fremantle-armel-extras-devel/work/tipqalc-0.3.0/src' make[1]: *** No rule to make target `/usr/share/qt4/mkspecs/linux-g++/qmake.conf', needed by `Makefile'. Stop. make[1]: Leaving directory `/home/builder1/maemo-fremantle-armel-extras-devel/work/tipqalc-0.3.0/src' Any suggestions? Thanks. - ianaré sévi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 upgrades
Never mind on the first question _ I think this is the link: https://www.nokiausa.com/get-support-and-software/product-support/nokia-n810-wimax/software However, any hints on the second question below? Also is the only way to upgrade the tables via USB connectivity? Can it be done over WiFi? Thanks again Hi all, A while back I upgraded my N800 to a newer versions of Maemo (Diablo) and I just got an N810 that I want to upgrade as well. First off I don't remember the procedure I followed to upgrade my N800 so if anyone has a link to some docs on this I will appreciate it. Second, is Maemo 5 runnable on the N810 or should I try for previous versions? Thanks very much in advance ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 upgrades
Hi, the N810 supports over-the-air updates since Diablo OS. So there's no need for flashing for an update. Maemo5 does not run on the N810. The closest you can get is the alternative Mer OS which tries to backport Maemo5 stuff onto a Ubuntu based OS running on the N810. It's still in an early stage, though. Martin 2010/2/25, Demetris demet...@ece.neu.edu: Never mind on the first question _ I think this is the link: https://www.nokiausa.com/get-support-and-software/product-support/nokia-n810-wimax/software However, any hints on the second question below? Also is the only way to upgrade the tables via USB connectivity? Can it be done over WiFi? Thanks again Hi all, A while back I upgraded my N800 to a newer versions of Maemo (Diablo) and I just got an N810 that I want to upgrade as well. First off I don't remember the procedure I followed to upgrade my N800 so if anyone has a link to some docs on this I will appreciate it. Second, is Maemo 5 runnable on the N810 or should I try for previous versions? Thanks very much in advance ___ 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
Re: qmake
ext ianaré sévi wrote: I'm having problems building my package using qmake on extra-devels. make[1]: Entering directory `/home/builder1/maemo-fremantle-armel-extras-devel/work/tipqalc-0.3.0/src' make[1]: *** No rule to make target `/usr/share/qt4/mkspecs/linux-g++/qmake.conf', needed by `Makefile'. Do you have libqt4-dev as a build-dependency? Daniel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext Michael Cronenworth m...@cchtml.com writes: If a user has access to downloading apps, then they will be notified of the Maemo update. If they want a new app, they must update Maemo, but they can continue using their old apps as long as they want. Refusing to update because of a personal preference should be discounted. Security updates, new features, and significant bug fixes should trump any personal preference about updates to Maemo itself. I agree, but the Application manager is unfortunately less than helpful in guiding the user through a required OS update. If a OS update is needed to install an application, the Application manager will only give a cryptic error message. This needs to be fixed, obviously. There are plans, but neither commitment nor schedules... :( ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
