Re: 0xFFFF 0.5 released
Hi, On Tue, Sep 18, 2012 at 11:25 AM, Pali Rohár pali.ro...@gmail.com wrote: Now I'm rewriting 0x source code for better Fiasco image support, future protocol support (cold flashing, eMMC flashing). When it is finished it will be full replacement for proprietary i386 Nokia flasher-3.5. Development source code: https://github.com/radare/0x Good to see 0x still being developed! Do you have plans to add support for N9 as well? Not sure how much effort is needed. Best Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: information required to replace Maemo5 wlan bits
Hi, Jonathan, On Thu, Jul 19, 2012 at 4:13 PM, Jonathan Wilson jfwf...@tpgi.com.au wrote: Here is the information on the things you need to know about/provide/use/etc in order to replace the Maemo5 ICD WLAN plugin with something better (e.g. based on wpa-supplicant) and have every other package on the stock install continue to work properly. [snip] Just to let you know, that IMHO the analysis and information you are collecting are even more important than rewriting the proprietary components. It helps both understanding the inner workings of the system (what about writing a Maemo 5 Internals document for the proprietary parts? :)) and help people interacting with these components, customizing them (e.g. binary patching) or replacing them when necessary. Anyway, I appreciate reading these RE analysis, even though I'm not actively using my N900 (now playing with N9). Maybe it could be added to some wiki section as well? Best Regards, -- Anderson Lizardo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can anyone tell me how the N900 vibrator driver works?
Hi Jonathan, On Thu, Jul 7, 2011 at 1:06 PM, Jonathan Wilson jfwf...@tpgi.com.au wrote: I am looking for information on the driver the responds to /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse and in particular details of just what it does with the numbers. Pointers to the source code for the driver in question may also help although I dont know the first thing about linux kernel drivers :P I am attempting to create a clone of the N900 mce vibrator plugin (so that it can be extended and improved) and having this info would help me understand what is going on. Are you keeping your reimplementation efforts public somewhere (e.g. code repository, blog posts)? Which component(s) are you currently working on (and the status of each one)? There could be people interested on helping out as well, so some sort of status report and code sharing (even if non-working) is valuable (IMHO). For now, I am interested at least on monitoring the ongoing efforts on reimplementing proprietary code from Maemo 5. Thanks! -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can anyone tell me how the N900 vibrator driver works?
On Thu, Jul 7, 2011 at 3:16 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Are you keeping your reimplementation efforts public somewhere (e.g. code repository, blog posts)? Which component(s) are you currently working on (and the status of each one)? Some components I could find so far related to you (by a quick search on google): * ICD2 policy plugins * Cell broadcast SMS * vibra Can you provide a quick status on these? Anything else missing? Thanks, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Canola's main website
On Wed, Apr 28, 2010 at 3:09 AM, Fabio Leal sousaleal.fa...@gmail.com wrote: Hi all, Who is mantaining, nowadays, Canola's main website? Things seems to be quite outdated there... I'm planning to start to work on a new plugin and I'll probably write some new tutorials. Who should I contact in order to have it exposed on Canola's website? Try sending an e-mail to the canola mailing list: https://garage.maemo.org/mailman/listinfo/canola-devel Or talking on IRC (#canola at freenode) HTH, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python hildon.Button -problem
On Fri, Apr 9, 2010 at 5:09 AM, Timo Pelkonen pelt...@gmail.com wrote: Hi! I don't know what I am doing wrong with this. I have two buttons configured like this: button_1 = hildon.Button(gtk.HILDON_SIZE_AUTO,hildon.BUTTON_ARRANGEMENT_VERTICAL, Button 1) and when I run the program, only one button is shown. If would help if you provide a more complete snippet of your code. A few possibilities: 1) Do you use a VBox/HBox container to hold these buttons ? 2) did you use window.show_all() to show the objects added to the window? HTH, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK and Qt4.5/4.6 pyside/pyside-qt4 confusion
On Wed, Mar 24, 2010 at 9:05 AM, Luca Donaggio donag...@gmail.com wrote: I'm a little bit confused: after upgrading my Scratchbox SDK installation to PR1.2, I removed all the libqt4-maem5* packages, as now Qt4.6 is the default version (libqt4* packages). What is the situation of the various pyside* packages? They seem to have remained the same: the pyside* ones depending on libqt* packages (which pre PR1.2 used to be Qt4.5) and the pyside-qt4* packages depending on libqt4-maemo5* (Qt4.6 before PR1.2). Do the pyside* packages bring all the necessary bindings to work with Qt4.6? Or should I wait for an update? PySide will be updated to regain compatibility with PR1.2 , but that will be done together with the upload of the recently released shiboken based bindings (http://www.pyside.org/2010/03/pyside-shiboken-technical-preview-release/). PS: feel free to ask PySide specific questions on the PySide mailing list: http://lists.openbossa.org/listinfo/pyside . There is also the #pyside IRC channel on freenode. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
2010/1/13 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: Notice that hildon-desktop does not have any plugins, all plugins are in hildon-home. What you need is killall hildon-home -- it will restart automatically and no reboot is needed. Yesterday I uploaded an updated version of the Python loader that uses this workaround, thus closing https://bugs.maemo.org/show_bug.cgi?id=8586 See also the broader bug report : https://bugs.maemo.org/show_bug.cgi?id=9370 (not fixed yet, that's why we added the workaround) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Request: Tutorials use-cases for documentation
On Thu, Feb 11, 2010 at 7:44 PM, Dave Neary dne...@maemo.org wrote: So what's next? We want to gather suggestions for use-cases that need documenting, then we'll create a wiki page for each one, then we (and by we, I mean the Maemo Community will answer the questions. The answers will include code snippets, and brief introductions to the purpose of any libraries we use. The end result should be a library of code snippets that could potentially become a Maemo cookbook. I think it is also a good idea to collect the use case line tutorials found on Maemo talk. There are popular threads on the Development forum which fill this pattern... Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
About legacy Maemo 5 documentation on the wiki
While fixing a few bugs on the supposedly official developer documentation on the wiki, I just noticed I made a mistake and was actually editing this one: http://wiki.maemo.org/Legacy_Maemo_5_Documentation The problem is that it is often getting high results while searching for documentation (at least for me). Can it be moved to a different place, archived, or even removed completely (as it has been superseded by other documentation as mentioned on the link above)? I think it is too easy to not notice the Legacy on the title. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken Qt Packages?
On Wed, Feb 10, 2010 at 5:03 AM, Antonio Aloisio antonio.aloi...@gmail.com wrote: FYI new packages (20100210) are being uploaded now by Harald. Antonio BTW, is it expected to have the ABI of these snapshot releases stabilized anytime soon? The PySide packages are being bitten by the fact from time to time an exported symbol vanishes :/. Someone suggested using exact versioned dependency (e.g. Depends: libqt4-maemo5-gui == x.y.z) as a temporary solution. So far we have been using = versioned dependency. Do you think this is reasonable? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
On Sat, Feb 6, 2010 at 5:11 PM, Ed Bartosh bart...@gmail.com wrote: As far as I remember autobuilder doesn't use 'Maintainer' or any other field to prevent spamming of innocent people from upstream projects. It uses email from /etc/passed instead. Your email should be put in there by admins when they gave you upload rights. IIRC an e-mail is sent to the address in the Maintainer: field once the package is imported into the extras-devel repository (and again when it is promoted to other repositories like extras-testing and extras). I know that because I always see these e-mails on the pymaemo-developers mailing list moderation queue because PyMaemo packages have the mailing list address in the Maintainer field and autobuilder address is not subscribed to the list. Not sure if this has changed after the server migration, though. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPA's?
On Fri, Feb 5, 2010 at 4:28 AM, Marius Vollmer marius.voll...@nokia.com wrote: - All PPAs are known to the maemo.org community, and their maintainers allow NMUs to them, subject to the same rules as NMUs in extras-devel. Sorry to hijack the thread, but where are these NMU rules in extras-devel ? Until now I never knew there were NMU rules for Maemo... Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upload to fremantle-extras-builder broken?
On Wed, Jan 20, 2010 at 3:00 PM, Niels Breet ni...@maemo.org wrote: This changed. It should be drop.maemo.org. If you replace garage.maemo.org with drop.maemo.org, everything should work fine. Not sure if this has already been reported, but I see this (apparently harmless) error when using dput: sh: /tmp/xxx: Permission denied Seems to come from some script on the server side. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Telephone API question - answering a call.
Hi, On Wed, Jan 27, 2010 at 5:07 AM, Dave Neary dne...@maemo.org wrote: You can see a Python example for listening to a DBus signal with Python here: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/DBus_in_Freemantle While at it: * The link above is not under the Python category, and is not linked from the Upper DBus page. * The title is incorrect (fremantle vs. freemantle) Ok, I know it's a wiki motto :), but I want to ask first: isn't better to move this content to a Python specific location, e.g. http://wiki.maemo.org/PyMaemo ? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Mon, Jan 11, 2010 at 4:18 PM, Thomas Waelti twae...@gmail.com wrote: (Resent with correct time/date) Hello all I've uploaded an alpha version of my shutter home widget (IR shutter for Nikon DSLR) to extras-devel. Functionaly, it works. But now I have a small problem in my installer that I'm unable to resolve: After running the deb, the widget gets installed. It can then be added to the desktop by the user through the normal Desktop Config Add Widget process. It shows up in the list and is selectable. But then it does not show up on the desktop! However, once the device is rebooted, the added widget is cleary visible and works well. Heads up: I have created a PyMaemo specific bug to summarize and track the issue: https://bugs.maemo.org/show_bug.cgi?id=8586 Please add any further information/solutions to the problem there. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Tue, Jan 26, 2010 at 8:05 AM, Ed Bartosh bart...@gmail.com wrote: - support for building tags from garage VCS(svn and git) Would be nice to also allow fetching code from external VCS hosting services (gitorious for instance). Is that feasible? Maybe using the Vcs-* fields line in Debian?) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: up-to-date debhelper and cdbs
On Sun, Jan 24, 2010 at 6:54 AM, Thomas Tanner tan...@gmx.de wrote: PROBLEM: autobuilder should automatically install these build-depends but currently it fails with The following packages will be REMOVED: debhelper The following NEW packages will be installed: bsdmainutils bsdutils debhelper7 groff-base man-db E: Packages need to be removed but remove is disabled. see the buildlog of a package used for testing the workaround https://garage.maemo.org/builder/fremantle/dpkg-repack_1.31maemo1/i386.root.log.FAILED.txt Would it be possible to allow package removal in autobuilder? Ideally, it would be nice to allow this modified debhelper7 and the original debhelper from the devkit to coexist on the same SDK installation (so that users interested on trying it out can easily do so without breaking their current target). That would require some more changes to your debhelper7 and cdbs-dh7 packages though (e.g. to not install files at conflicting paths). What do you think? -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Fri, Jan 22, 2010 at 12:40 PM, Jeremiah Foster jerem...@jeremiahfoster.com wrote: The changelog is a must, but changing the maintainer name in the debian/control file is also a must, according to maemo packaging policy. Here is the policy in pdf: WARNING PDF! https://maemo.org/forrest-images/pdf/maemo-policy.pdf Another important thing is that I noticed (and I believe there should have been a note about this somewhere...) that the autobuilder mailer sends an e-mail to the address in the Maintainer: field when the package is imported to the repository (and when it moves between extras-* repositories). Not changing the Maintainer: field means that the *original* maintainer (e.g. someone from Debian or Ubuntu) will get the e-mail and most of the time will not know anything about it. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Fri, Jan 22, 2010 at 1:08 PM, Eero Tamminen eero.tammi...@nokia.com wrote: There must be somebody who is responsible for the uploaded package and some way to contact him. The uploader must have somehow verified that the package isn't e.g. malicious (even if it's just taken from a trusted source). If it's a team, they might even share the ssh-key. But I think it would be better to have some configuration thing where Maintainer can grant upload rights for his package to others he trusts. [snip] I (personally) think that the Maintainer field doesn't need to match a valid user in garage, but I also think that we should have a obligatory PGP signing (authenticated by the autobuilder), which can then be shared by members of a team (for team maintained packages). The e-mail itself is IMHO only a small percent of what can be manipulated on a package... Ok we have md5 sums, but PGP gives both integrity and authorship guarantees, and any rebuilds by third parties (intentional or not) will invalidate the PGP signature. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Fri, Jan 22, 2010 at 1:21 PM, Nathan Anderson nat...@andersonsplace.net wrote: Jeremiah, Thanks -- I have no issues with dropping my name into the maintainer field; I just didn't want to steal any credit from the real authors of those things that I just repackaged. I do know the language of everything I've repackages; and could probably muddle my way through something I didn't know. ;-) The Maintainer field says specifically about the package maintainer, not the original author. If you are repackaging something for Maemo and wants to maintain credits for the original maintainer, just move the original field to the XSBC-Original-Maintainer field, as Ubuntu maintainers do (see https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#What%20does%20XSBC-Original-Maintainer%20mean?) If you don't change the Maintainer field, users might think that they should contact the original maintainers for any problems with your packaging modifications (for instance), and that person might not be prepared for giving this support. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage mailing lists still down?
Hi, On Tue, Jan 19, 2010 at 10:55 AM, Ferenc Szekely fer...@maemo.org wrote: I made requests for a DNS change and an SMTP server config change. After these we should be able to send mails to lists hosted on garage.maemo.org. Now I'm getting a different error: ### The following message to pymaemo-develop...@garage.maemo.org was undeliverable. The reason for the problem: 5.1.0 - Unknown address error 554-'5.7.1 pymaemo-develop...@garage.maemo.org: Relay access denied' Final-Recipient: rfc822;pymaemo-develop...@garage.maemo.org Action: failed Status: 5.0.0 (permanent failure) Remote-MTA: dns; [10.129.133.36] Diagnostic-Code: smtp; 5.1.0 - Unknown address error 554-'5.7.1 pymaemo-develop...@garage.maemo.org: Relay access denied' (delivery attempts: 0) ### Any ideas? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Garage mailing lists still down?
Hi, I sent an e-mail to a garage mailing (specifically the pymaemo-developers one) yesterday, and got the following today: Delivery to the following recipient has been delayed: pymaemo-develop...@garage.maemo.org Message will be retried for 2 more day(s) Technical details of temporary failure: The recipient server did not accept our requests to connect. Learn more at http://mail.google.com/support/bin/answer.py?answer=7720 [garage.maemo.org (1): Connection timed out] I wonder if the garage mailing lists are still offline due to the server migration? I remember reading that the maemo.org mailing lists were migrated some time ago, but how about the garage ones? TIA, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Problems when trying to enter a new bug in Bugzilla
[sorry if this is not the correct channel for such reports, but in this case I obviously can't open a bug report; the error mentions bugzi...@maemo.org, but I don't know if it is valid] When I try to submit a new bug report, I get the following error (after pressing the submit button): ### Bugzilla has suffered an internal error. Please save this page and send it to bugzi...@maemo.org with details of what you were doing at the time this message appeared. URL: https://bugs.maemo.org/post_bug.cgi undef error - Insecure dependency in exec while running with -T switch at /usr/share/perl5/Mail/Mailer/sendmail.pm line 22. ### Any known problems? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: D-Bus signals in python
On Sat, Jan 16, 2010 at 5:34 AM, Matan Ziv-Av ma...@svgalib.org wrote: can someone please translate this to python for me: dbus-send --type=signal --session /com/nokia/hildon_desktop com.nokia.hildon_desktop.set_state int32:128 I found how to call methods, but sending signals does not appear to work. Take a look at this: http://cgit.freedesktop.org/dbus/dbus-python/tree/examples/example-signal-emitter.py Hope that helps, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Thu, Jan 14, 2010 at 3:47 PM, Thomas Waelti twae...@gmail.com wrote: So would it make sense to add a killall hildon-home to the postinstall of the hildon-desktop-python-loader as an interim fix? Who could do that? (I refrain from adding that to my app, as I think this would be the wrong place :-) The PyMaemo team (which includes myself) can, but what we didn't hear from the Hildon desktop developers whether this is a reliable workaround or not :/. The only thing we know is that it should work, but may affect some widgets. What I'm most afraid is if watchdog may reboot the device. It seems it does not happen, but it would be nice to know (from Hildon developers) if it is indeed safe to kill hildon-home with SIGTERM during a package installation or not. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
2010/1/13 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: Notice that hildon-desktop does not have any plugins, all plugins are in hildon-home. What you need is killall hildon-home -- it will restart automatically and no reboot is needed. That's good to know. So does that mean we can put this on a postinst script and it will not affect running applications and other C applets? Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
2010/1/13 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: On Wed, 2010-01-13 at 12:03 +0100, ext Anderson Lizardo wrote: It's better to fix hildon-home so that it does not require a restart. Report a bug and attach your patch there :) Well, hildon-home already uses a notification (inotify?) mechanism for the applets, I just don't know why the same code was not used for the loaders :/ I'll open a bug report in any case and, if time and PyMaemo planning permits, prepare a patch, but do you think it is feasible to use killall hildon-home on the Python loader postinst script as a workaround? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Fremantle] Creating gconf keys upon installation
2010/1/12 Faheem Pervez tripp...@gmail.com: Talking of schemas, it would be nice if dh_gconf could be made not to put the rmdir -p --ignore-fail-on-non-empty line into the postrm of a package using it, since the BusyBox shipped with the N900 doesn't appear to support to support the --ignore-fail-on-non-empty option which causes dpkg --purge package having the the clause containing --ignore-fail-on-non-empty to fail. This is a bug IMHO. We fixed many of these occurrences on PyMaemo packages, replacing with rmdir || true. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 4:47 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: I think it's still possible that hildon-desktop python-loader doesn't work after it's insalled until device (or hildon-desktop) is restarted. I've seen similar reports related to other python based widgets. Since it happens only once it's hard to really notice. Does any python developer know anything about this? Well, we have never got reports on this (it's the first report I see about this). If you could point to the other reports of python widgets not working without a reboot that would be nice. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 6:06 PM, Brent Chiodo bchi...@gmail.com wrote: I have had this issue reported for TouchSearch in both forums and formally as bug #6264: https://bugs.maemo.org/show_bug.cgi?id=6264 Thanks, it is now easier to try to reproduce it (I have a spare N900 that can be reflashed). It was also my thought that the Python - HildonDesktop interface is responsible for this. A possibility is that the the just installed Python loader (/usr/lib/hildon-desktop/loaders/libpythonpluginloader.so) only becomes active when hildon-desktop is restarted (which I suppose only occurs when the device is rebooted). If that's the case, I don't know a way to force hildon-desktop to detect the new loader. Also it will probably happen only when hildon-desktop-python-loader is first installed, other applets installed after (or the same applet being reinstalled) will not show the problem. Can some Hildon Desktop developer confirm this is the case? And if so, is there any way of avoiding a reboot (e.g. by sending some signal to the hildon-desktop process maybe?) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 5:00 PM, Thomas Wälti twae...@gmail.com wrote: It could indeed be that python-loader does not startup correctly after its installation. I get the following errors, once right at the end of the installation, a second time when trying to add the widget to the desktop: hildon-home[14183]: GLIB WARNING ** default - Unknown Plugin Loader type: python hildon-home[14183]: GLIB WARNING ** default - Error loading plugin: /usr/share/applications/hildon-home/shutter.desktop On both the test device and the scratchbox it failed, and on both I didn't have any python widgets installed before. This is the expected behavior. You need the Python loader (provided by the hildon-desktop-python-loader) installed *and* loaded in order to have Python applets recognized. The problem (as I mentioned on the other message) is probably that the hildon-desktop process is not being aware of the new loader until it is restarted. A possible test case (which I cannot test ATM) is: 1) apt-get remove hildon-desktop-python-loader 2) Restart N900 3) apt-get install hildon-desktop-python-loader 4) Install some Python applet The let us know if the applet is shown or not. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 5:08 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: On Tue, Jan 12, 2010 at 10:51 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Problem is that there isn't reliable bug reports (about openvpn-applet and touchsearch for example), just random forum messages. I've been following talk.maemo.org, but it is hard to notice if some application is written in Python or not (just by looking at the thread subject). It would be nice if the people following the threads properly tag then with the python tag so it can be easily found in searches. But I've experienced it myself, but I thought that it was fixed with the latest versions. To make a reliable test I would need to reflash whole device (rootfs+emmc) and I'm not very keen to do that. I posted on another message a possible test case which does not require a reboot. Could you try that? Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 8:22 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: On Tue, Jan 12, 2010 at 5:08 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: On Tue, Jan 12, 2010 at 10:51 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Problem is that there isn't reliable bug reports (about openvpn-applet and touchsearch for example), just random forum messages. I've been following talk.maemo.org, but it is hard to notice if some application is written in Python or not (just by looking at the thread subject). It would be nice if the people following the threads properly tag then with the python tag so it can be easily found in searches. BTW, It is very simple to see any Python related threads, if properly tagged: http://talk.maemo.org/tags.php?tag=python Unfortunately, only a few people use this feature. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Mon, Jan 14, 2008 at 7:13 PM, Thomas Waelti twae...@gmail.com wrote: Hello all I've uploaded an alpha version of my shutter home widget (IR shutter for Nikon DSLR) to extras-devel. Functionaly, it works. But now I have a small problem in my installer that I'm unable to resolve: After running the deb, the widget gets installed. It can then be added to the desktop by the user through the normal Desktop Config Add Widget process. It shows up in the list and is selectable. But then it does not show up on the desktop! However, once the device is rebooted, the added widget is cleary visible and works well. Now I really don't want to forece my users to reboot just because of a widget. Therefore my question: what am I missing? Any special postinstall script to run? Your applet might be crashing for some reason on first load. Can you test it on Scratchbox/X86 (using Xephyr) and tell us if you are able to reproduce the problem there? If yes, you might try to debug the crash by looking at the messages printed by hildon-desktop. Or is it a problem of my .desktop file? [Desktop Entry] Name=shutter Comment=Issues a single IR command using LIRC Type=python X-Path=shutter.py X-Multiple=true Except for this X-Multiple entry (which I don't know what is) I don't see a problem with it. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and pygst development only on device?
On Sat, Jan 9, 2010 at 5:42 AM, Klaus Rotter kl...@rotters.de wrote: The python developer howto suggests developing on the device - is this (more or less) the only way to go? Or did I miss something? Not really. You have various options for Python development for Maemo, see http://wiki.maemo.org/PyMaemo/QuickStartGuide (make sure to take a look at the Alternative development environments section at the end). Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging applet causing hildon-home crash
2010/1/7 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: On Wed, 2010-01-06 at 22:46 +0100, ext Graham Cobb wrote: In Fremantle, the GPE Summary applet causes hildon-home to crash if it is removed and then re-added. I have not been able to work out what the problem is. We had several of this kind of crashes that happen when you remove and add it back. Usually the problem was in the Glib types that the applet uses: if it tries to register new types that are already there, or something similar. I guess Glib should print out some warnings for you? (notice that hildon-home probably closes stdout by default) As a side note, python-hildon suffered from these issues because the latest hildon-home (or hildon-desktop?) versions seemed to incorporate some gtype registration functions which were missing before (i.e. ones usually generated by glib-mkenums). The python bindings tried to register the same types again, which caused problems (the errors shown on console gave a hint about this). The fix consisted on not running glib-mkenums for hildon types. Maybe not related to this problem, but anyway. Any hints on how best to debug this hildon-home crash? It could help to disable all other plugins than the one that you are debugging and using gdb or good old printfs I guess. I usually also debug on scratchbox/x86 , where I can kill hildon-home and restart it again with hildon-home which then shows debug messages on the console. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
On Thu, Jan 7, 2010 at 11:34 AM, Marius Vollmer
marius.voll...@nokia.com wrote:
Currently, is_python_package looks like this:
sub is_python_package {
my ($dir) = @_;
# XXX - some input from Pythonistas is required here.
return (-d $dir/usr/lib/python2.5
|| -d $dir/usr/share/pyshared
|| -d $dir/usr/share/pyshared-data
|| -d $dir/usr/lib/pyshared
|| -d $dir/usr/share/python-support
|| -d $dir/usr/lib/python-support);
}
I will change that to something closer to what has actually been
proposed. Concrete patches are most welcome, of course!
That's almost the same directories currently handled by pymaemo-optify:
https://garage.maemo.org/svn/pymaemo/packages/pymaemo-optify/trunk/debian/default/pymaemo-optify
As a test, you could run it on all python-* .deb packages currently in
the repository, and see if it catches all/most of them. If it works,
and is used only to skip Python packages from automatic optification,
I *personally* see no problem.
It would be nice to have a option to force optification, even if the
heuristics says to ignore the package. I've seen some Python packages
that had no problems with automatic optification, so that way they can
still use maemo-optify.
BTW, if/when autobuilder changes to automatically optify packages with
no debian/optify entry, will it be done only for the newer uploaded
packages?
IMHO running optify on the live packages might break things. If it is
run only on newer packages, developers have the chance to report
auto-optify related problems.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Drag Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
On Thu, Jan 7, 2010 at 5:37 AM, Claudio Saavedra csaave...@igalia.com wrote: There is no drag 'n drop in Maemo GTK+. This has been deliberately disabled. I believe that pretty much answers Jeff's issue... Was this done for Maemo 5 ? Because according to Jeff it used to work on the N810 (Diablo). I haven't tested it myself on N810 , though. A stacktrace on the critical warning would be useful to find out the cause. How to get that stack trace (some glib/gtk function?) ? it does not crash the application , so I think gdb cannot be used in this case. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Drag Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
[I'm CC'ing maemo-developers as it is clearly not a Python specific
issue; see below for details]
On Wed, Jan 6, 2010 at 2:11 PM, Jeffrey Barish
jeff_bar...@earthlink.net wrote:
Well, it took a little more than a few days, but here is a test program. It
works on Ubuntu and N810, but not N900.
Well, I tested your example on Maemo and Ubuntu, and indeed the drag
drop only worked on Ubuntu. Additionally, this error is shown on
console:
/tmp/dndtest.py:77: Warning: g_object_set_data_full: assertion
`G_IS_OBJECT (object)' failed
gtk.main()
So I went further and translated your example to C (please note I'm no
GTK expert, I'm only trying to help debugging the problem). And the
same behavior is presented: the drag does not work and this message is
shown on console:
dndtest[9349]: GLIB CRITICAL ** GLib-GObject - g_object_set_data_full:
assertion `G_IS_OBJECT (object)' failed
That means the problem is not related to Python or PyGTK at all, but
some GTK limitation/bug on Maemo 5.
The translated C example is attached.
Any ideas anyone? Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
#include gtk/gtk.h
gboolean on_delete_event(GtkWidget *widget, GdkEvent *event, gpointer data)
{
gtk_main_quit();
return FALSE;
}
void on_drag_data_received(GtkWidget *treeview,
GdkDragContext *drag_context,
gint x,
gint y,
GtkSelectionData *data,
guint info,
guint time,
gpointer user_data)
{
gboolean ret;
GtkWidget *source_widget = gtk_drag_get_source_widget(drag_context);
GtkTreeModel *model;
gchar *source_row[2];
if (source_widget == treeview) {
GtkTreeSelection *selection = gtk_tree_view_get_selection(GTK_TREE_VIEW(treeview));
GtkTreeIter iter;
ret = gtk_tree_selection_get_selected(selection, model, iter);
g_assert(ret == TRUE);
gtk_tree_model_get(model, iter, 0, source_row[0], 1, source_row[1], -1);
} else {
model = gtk_tree_view_get_model(GTK_TREE_VIEW(treeview));
source_row[0] = 9;
source_row[1] = newrow;
}
GtkTreePath *path;
GtkTreeViewDropPosition position;
ret = gtk_tree_view_get_dest_row_at_pos(GTK_TREE_VIEW(treeview), x, y, path, position);
if (ret) {
GtkTreeIter iter;
ret = gtk_tree_model_get_iter(model, iter, path);
if (position == GTK_TREE_VIEW_DROP_BEFORE || position == GTK_TREE_VIEW_DROP_INTO_OR_BEFORE) {
GtkTreeIter new_iter;
gtk_list_store_insert_before(GTK_LIST_STORE(model), new_iter, iter);
gtk_list_store_set(GTK_LIST_STORE(model), new_iter, 0, source_row[0], 1, source_row[1], -1);
} else {
GtkTreeIter new_iter;
gtk_list_store_insert_after(GTK_LIST_STORE(model), new_iter, iter);
gtk_list_store_set(GTK_LIST_STORE(model), new_iter, 0, source_row[0], 1, source_row[1], -1);
}
} else {
GtkTreeIter iter;
gtk_list_store_append(GTK_LIST_STORE(model), iter);
gtk_list_store_set(GTK_LIST_STORE(model), iter, 0, source_row[0], 1, source_row[1], -1);
}
if (drag_context-action == GDK_ACTION_MOVE) {
gtk_drag_finish(drag_context, TRUE, TRUE, (guint32)data);
}
}
int main(int argc, char **argv)
{
gtk_init(argc, argv);
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), DND Test);
gtk_widget_set_size_request(window, 200, 300);
g_signal_connect(G_OBJECT(window), delete_event, G_CALLBACK(on_delete_event), NULL);
GtkWidget *button = gtk_button_new_with_label(Text on the button);
GtkListStore *liststore = gtk_list_store_new(2, G_TYPE_STRING, G_TYPE_STRING);
GtkTreeIter iter;
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 0, 1, zero, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 1, 1, one, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 2, 1, two, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 3, 1, three, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 4, 1, four, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 5, 1, five, -1);
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter, 0, 6, 1, six, -1);
GtkWidget *treeview = gtk_tree_view_new_with_model(GTK_TREE_MODEL(liststore));
g_signal_connect(G_OBJECT(treeview), drag-data-received, G_CALLBACK(on_drag_data_received), NULL);
GtkCellRenderer *renderer = gtk_cell_renderer_text_new();
GtkTreeViewColumn *column = gtk_tree_view_column_new_with_attributes(Int
Re: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 8:11 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? If so, checking whether pymaemo-optify is installed on the scratchbox target would be one heuristic to detect indirect dependencies, given that (theoretically) the scratchbox target is cleaned before each package build. Sample shell script snippet: if dpkg -s pymaemo-optify | grep -q not-installed; then echo pymaemo-optify is not installed else echo pymaemo-optify is installed fi This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). This is just an idea, more testing is needed. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 11:16 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Maybe pymaemo-optify could even just echo none debian/optify... I'll have to have a closer look at how pymaemo-optify actually works... pymaemo-optify currently works on run-time (using the bind mount trick), so it does not modify any packages. Only python2.5 was changed to depend on pymaemo-optify, so it is guaranteed to be installed along with python applications. (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) Given that pymaemo-optify currently does not manipulate the packages themselves, but works at low level by bind-mounting Python directories, I think the _current_ version cannot be merged with maemo-optify. This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) Yes, having pymaemo-optify installed after .deb's have been created would be a indication of that package depending (directly or indirectly) on some Python package during build. But it does not guarantee the package which maemo-deb-optify is running on actually depends on python during runtime. But I agree having just one heuristic would be better (IMHO), others could be added if/where necessary. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Translating Description field in debian/control
2010/1/4 Cornelius Hald h...@icandy.de: Hi, I'm trying to provide a localized package description in debian/control. I was finding this[1] document. Is it still valid? Because somehow it's not working. (Only tested with Fremantle) It looks like something strips out the additional fields. E.g. in my original control file I have lines like: Description-de_DE: German description here Description-fi_FI: Finish description On the document you sent the URL, it says: The way to get these fields into your .deb files is to include them with a XB- prefix in your debian/control file, see the Debian Policy Manual, section 5.7. So I *think* (I never tried), that you should use: XB-Description-de_DE XB-Description-fi_FI and so on. The XB- prefix will be removed automatically by dpkg-gencontrol. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
2009/12/24 Andrew Flegg and...@bleb.org: Yes. And there's a change needed in maemo-optify: auto should mean don't do anything if it packages to /opt already OR it has a dependency on pymaemo-optify. Just a correction: no Python packages currently need to explicitely depend on pymaemo-optify to become optified. This is taken care by python2.5-minimal (and its dependency on pymaemo-optify). Packages need just to depend (and usually Build-Depend too) on python. One idea for a possible generic heuristic (not tested on the maemo-optify context) is to check that the package Build-Depends on python *and* install files to any directories listed by the command below: echo -e import sys\nfor d in sys.path: print d | python2.5 (note the explicit python2.5 call; calling just python will not work; also note that some entries might not exist or might not be a directory) In any case, as I said before, it is still a *heuristic*. False positives (or false negatives) will happen. So it is still safer to add none to debian/optify if you are sure the automatic optification will break your application. How to know? Try maemo-optify locally. I believe the current Maemo QA will catch the affected applications easily, because the application will break in obvious ways (i.e. will not open). If the chosen heuristic fails, simply explicitly disable optification. Also there is the situation of Python applications that contain big data files, images etc. Those still need some partial optification. I think that no matter how maemo-optify works, the QA team needs to look closely where the application installs files. This can be even made more easy by providing some script that looks for big files (where big is the threshold selected for maemo-optify) being installed outside /opt (and outside directories managed by pymaemo-optify). My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Semi-transparent background for Desktop Widget (Python + Cairo)
Hi, On Wed, Dec 23, 2009 at 5:28 PM, Brent Chiodo bchi...@gmail.com wrote: Hi, The code I've been looking at is a fairly simple widget in Extras called countdown-home. 95% of it is fluff and has nothing to do with this problem so I've attached a working Python Desktop Widget (very simple, just a couple gtk.Label's). countdown-home is available from here: http://repository.maemo.org/extras/pool/fremantle/free/source/c/countdown-home/ (I tried attaching the C file, but the list said it was too big). If you could try to translate the cairo code from coundown-home into the Python example, that would be awesome! I didn't translate the code above, but the simpler example Marc sent (example_clock_widget), because it was just easier to experiment with (and I will probably add to the examples section on the PyMaemo wiki page). But from this translation experiment, I noticed a few points you must be aware when implementing python widgets using cairo: * Use do_expose_event() and do_realize() methods instead of realize() and screen_changed() ones you used (just rename def expose(self, widget, event) to def do_expose_event(self, event) and def screen_changed(self, widget) to def do_realize(self) * Remember to call hildondesktop.HomePluginItem.do_realize(self) at the end of your do_realize() implementation (**very important**). This is needed because hildondesktop has its own internal implementation that must be called. The code is attached. Merry Christmas :) PS: I didn't translate the settings dialog part yet. Will do so later. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil # Example based on C code from: # https://garage.maemo.org/svn/maemoexamples/trunk/example_desktop_widget/src/example_clock_desktop_widget.c import math import time import sys import gtk import glib import cairo import hildon import hildondesktop def on_timeout(widget): widget.time = time.localtime() if not widget.window: return True region = widget.window.get_clip_region() if not region: return True widget.window.invalidate_region(region, True) widget.window.process_updates(True) return True def on_destroy(object): glib.source_remove(object.timeout_handler) def on_button_press_event(widget, event): text = Current Time: %s % time.asctime(widget.time) hildon.hildon_banner_show_information(widget, , text) return True class HelloHomePlugin(hildondesktop.HomePluginItem): def __init__(self): hildondesktop.HomePluginItem.__init__(self) self.timeout_handler = glib.timeout_add(1000, on_timeout, self) self.color = gtk.gdk.color_parse(white) self.time = time.localtime() mask = self.get_events() | gtk.gdk.BUTTON_PRESS_MASK self.set_events(mask) self.connect(button-press-event, on_button_press_event) # TODO: add settings dialog #self.set_settings(True) #self.connect(show-settings, on_show_settings) # FIXME: is there any equivalent of the dispose callback? self.connect(destroy, on_destroy) def _draw(self, cr): cr.set_source_rgba(1.0, 1.0, 1.0, 0.0) cr.set_operator(cairo.OPERATOR_SOURCE) cr.paint() x = self.allocation.width / 2 y = self.allocation.height / 2 radius = min(x, y) - 5 cr.arc(x, y, radius, 0, 2 * math.pi) cr.set_source_rgb(self.color.red / 65535, self.color.green / 65535, self.color.blue / 65535) cr.fill_preserve() cr.set_source_rgb(0, 0, 0) cr.stroke() for i in range(0, 12): inset = 0 cr.save() if i % 3 == 0: inset = 0.2 * radius else: inset = 0.1 * radius cr.set_line_width(0.5 * cr.get_line_width()) cr.move_to(x + (radius - inset) * math.cos(i * math.pi / 6), y + (radius - inset) * math.sin(i * math.pi / 6)) cr.line_to(x + radius * math.cos(i * math.pi / 6), y + radius * math.sin(i * math.pi / 6)) cr.stroke() cr.restore() hours, minutes, seconds = self.time[3:6] cr.save() cr.set_line_width(2.5 * cr.get_line_width()) cr.move_to(x, y) cr.line_to(x + radius / 2 * math.sin(math.pi / 6 * hours + math.pi / 360 * minutes), y + radius / 2 * -math.cos(math.pi / 6 * hours + math.pi / 360 * minutes)) cr.stroke() cr.restore() cr.move_to(x, y) cr.line_to(x + radius * 0.75 * math.sin(math.pi / 30 * minutes), y + radius * 0.75 * -math.cos(math.pi / 30 * minutes)) cr.stroke() cr.save() cr.set_source_rgb(1, 0, 0) cr.move_to(x, y) cr.line_to(x + radius * 0.7 * math.sin(math.pi / 30 * seconds), y + radius * 0.7 * -math.cos
Re: Semi-transparent background for Desktop Widget (Python + Cairo)
On Thu, Dec 24, 2009 at 1:40 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: * Use do_expose_event() and do_realize() methods instead of realize() and screen_changed() ones you used (just rename def expose(self, widget, event) to def do_expose_event(self, event) and def screen_changed(self, widget) to def do_realize(self) I forgot to mention: you should not connect these methods (do_expose_event() and do_realize()) to any signal, they are virtual methods called automatically by PyGTK. I got the idea partially from http://ralph-glass.homepage.t-online.de/clock/clock.py and from interpreting the example clock widget C code. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sdl-mixer = 1.2.7 libboost on Fremantle
On Wed, Dec 23, 2009 at 5:37 AM, Gibro Vacco gibrova...@gmail.com wrote: Hi, in an attempt to port Wesnoth to Fremantle I found that two dependencies (as in the subject) are currently not available as standard packages, even though compilation and execution seem to work fine. Is somebody planning -or performing- the enhancements? There is at least boost1.38 packages on fremantle already. I don't know about sdl-mixer. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
On Wed, Dec 23, 2009 at 9:38 AM, Jeff Moe m...@blagblagblag.org wrote: Per the wiki: http://wiki.maemo.org/Building_packages_with_sbdmock Do: sudo aptitude install git-core python-pip python-setuptools python-virtualenv pip install -E sbdmock minideblib pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock I tried to find an equivalent, but in the end it wound up faster just rebuilding the package and it worked fine. According to the pip documentation, it is a replacement for easy_install. Have you tried using easy_install ? (AFAIK it is installed by default on most python installations). I just don't know if easy_install supports installing directly from git repositories, like shown above. And I don't understand why you need python-setuptools and python-virtualenv to install sbdmock... For sure I didn't need them to install sbdmock. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
On Wed, Dec 23, 2009 at 11:54 AM, Jeff Moe m...@blagblagblag.org wrote: I was just following the wiki. Perhaps you could update it? I still haven't used sbdmock, so I don't know all that is needed to install so I was just RTFMing... http://wiki.maemo.org/Building_packages_with_sbdmock Now after reading the page, I see why it requires those packages: it uses virtualenv so you don't pollute your system Python installation (i.e. /usr/lib/pythonX.Y) with manually installed modules. It is a good idea if you are installing sbdmock in non-Debian based systems or if you do not want to build debian packages for sbdmock, as Ed suggested. BTW, I just added the instructions for building Debian packages on that page. I did just minimal testing, so feel free to correct any errors there. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Semi-transparent background for Desktop Widget (Python + Cairo)
On Sat, Dec 19, 2009 at 3:41 PM, Brent Chiodo bchi...@gmail.com wrote: Hi, I'm trying to make the background of a Desktop Widget semi-transparent using the cairo graphics library. The widget is written in Python and the only examples of this I've found are using C (I don't know much C -- I wasn't even able to apply the examples to Python). If you send the links to the C examples you found, I can try translating them to Python for you (I'll be able to try only on scratchbox though, as I'll not have a N900 accessible until next year). Regards, -- Anderson Lizardo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, Dec 18, 2009 at 2:44 PM, Niels Breet ni...@maemo.org wrote: The question is why it shows up in Downloads as it is in section devel and not in a user/* section. This is something I need to check more closely as that seems to be a bug in the importer for Downloads. is it possible to remove it manually from Downloads? it is getting comments there as it were an application. And even if the Maintainer field is set correctly, the package interface insists on using either the uploader or the last changelog entry as maintainer. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On Fri, Dec 18, 2009 at 9:46 AM, Eero Tamminen eero.tammi...@nokia.com wrote: ext Jussi Hakala wrote: You can also try the debian-squeeze devkit available from scratchbox.org. Note that this is not (yet) supported by Fremantle SDK and you need to create your scratchbox targets by hand instead of the installation script, but should be enough to allow you to use debhelper 7. But I think using something like that would require that Maemo auto-builder supports it too... I wonder if it is possible to dynamically select different devkits from inside a target (using some SBOX_* environment variable), just like it's possible for selecting a different compiler ? I've managed to do something similar (using the SBOX_SCRATCHBOX_CONFIG as documented on /scratchbox/doc/variables.txt) to dynamically change compilers without requiring to change the target configuration, but I don't know if tha's possible for devkits too. If that would at all be possible, it would just be a matter of having the devkits installed on the autobuilder, without changing the target setup. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, Dec 18, 2009 at 3:14 PM, Niels Breet ni...@maemo.org wrote: Developers have python available in SDK and also know how to handle either red-pill or apt-get. So, If I understand correctly, developers (even newcomers to the Maemo world) should have extras-devel enabled on their devices for development? Otherwise they would not have access to e.g. bindings that are not used yet (and thus did not get promoted to extras). I did this on a N900 and I saw many updates appearing for applications not related to my development work. Most probably the new versions were coming from extras-devel. Wouldn't that be confusing to new N900 developers? Until we have the repository/library maintainer track sorted out, I propose to follow these steps: - If you are not listed as maintainer for an existing library and still want to have it updated, contact the maintainer. If the maintainer is not available or doesn't respond, mail to maemo-developers list. *** Please don't update a library maintained by anybody else without consent or public discussion*** - The maintainer/author uploads new version, checks if applications using the app still work correctly. - Ping me or mail -developers to push it through manually to testing. Here we can all do a final test to see if nothing breaks. Sounds reasonable IMHO. Is that also the case if some package needs to be demoted from extras-testing? I hope to have an interface for maintainers available in the beginning of the new year. Good to hear that! Will it be not restricted just to user/* applications? This doesn't solve the problem that the Application manager doesn't update libraries on their own though. That problem should be a separate discussion. Agreed. One thing I noticed is that removing some application using Application Manager does not remove its unused dependencies (e.g. like apt-get autoremove does). So the device tends to get filled up with unused dependencies, with no user-friendly way of removing them. Did anyone else notice this? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, Dec 18, 2009 at 4:00 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: On Fri, Dec 18, 2009 at 9:44 PM, Niels Breet ni...@maemo.org wrote: The question is why it shows up in Downloads as it is in section devel and not in a user/* section. This is something I need to check more closely as that seems to be a bug in the importer for Downloads. Seems very similar than XB-Maemo-Upgrade-Description is displayed way too soon https://bugs.maemo.org/show_bug.cgi?id=6187 Maybe it is getting the information from the wrong version of the package (e.g. the one from extras-devel). The version auto promoted to extras (0.2) does not have the Section: user/hidden. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process for middleware (libfoo, python-bar) packages: some ideas
the application but how do you check that it works? We should solve easy problems first and extending such mechanism possibly fixes/finds more problems faster? Not that I was thinking more about bugs on the installation/removal/upgrade stage itself, not on the application functionality. Installation/removal/upgrade bugs are better detected by actually installing packages on the target rootfs, because they involve running maintainer scripts, which might contain bugs. One such case I found where QA failed was on the rootsh package (I copied Faheem who maintains the package). I found that the rootsh version in the extras repository could not be removed using the Application Manager. So I tried on the command line, I noticed there was a syntax error on the postrm script (missing a then), preventing the removal of the package. I just noticed it looks like https://bugs.maemo.org/show_bug.cgi?id=6014, I will comment more there. * Test disk-full conditions, and randon errors during package installation of packages from Extras. Disk full on installation is a problem of the packaging mechnism and normally not a problem of the package (if it does not run space using scripts on its own during installation). For checking disk full conditions on the application you must install it, run it and trigger its writing functionality. To do this automatically is somewhere between difficult and impossible. Well, I truly think packaging problems to be very important because they might render the device unusable or badly broken requiring a reflash. And in most cases it is caused by bugs in the postrm/prerm/preinst/postinst maintainer scripts. The disk-full condition just triggers these bugs more easily, so if we could at least simulate this condition during package installation, we might detect potential bugs in the installation process. I would suggest to the tester to collect reoccuring testing failures they have the feeling that could found automatically and contact the build masters in such case (by filing an bug/enhacement request) - if they are not doing this anyway already I believe opening bugs with automation requests (if possible even with the automation script itself) is a nice idea. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process for middleware (libfoo, python-bar) packages: some ideas
On Thu, Dec 17, 2009 at 8:28 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: One such case I found where QA failed was on the rootsh package (I copied Faheem who maintains the package). I found that the rootsh version in the extras repository could not be removed using the Application Manager. So I tried on the command line, I noticed there was a syntax error on the postrm script (missing a then), preventing the removal of the package. I just noticed it looks like https://bugs.maemo.org/show_bug.cgi?id=6014, I will comment more there. Correction: this is not the same bug, it just shows the same error on the logs attached there (in a different context). I'll open a separate bug report on it. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Thu, Dec 17, 2009 at 6:16 AM, quim@nokia.com wrote: Hi, it seems that more users than wished are still reaching the rootfs limit only with the Nokia and Extras repos installed. Most (all?) Apps in Extras seem to be correctly optified, so one possibility is that the problem relies in the libraries. Sorry if I have missed something but I remember a post mentioning that optified libraries were available in Extras-devel but still not Extras. if true, and if the libraries have been tested, would there be a possibility to push them to Extras forcing an update in the background? I wonder how the push from extras-testing to extras works? I read http://wiki.maemo.org/Extras_repository_process_definition but I don't see a final resolution on this. And while at it, how to we know whether the optified libraries are tested enough to be uploaded? For the PyMaemo optified packages we got a few success reports (and a few bug reports, that we believe are fixed now), but given that there is no extras-testing queue for these package I'm not sure how the QA works in this case (I even opened a thread on this, see QA process for 'middleware' ... Also, if you know or suspect other causes for Extras users filling their rootfs partitions please let us know. If the user has Python applications and only extras enabled, the fact of the optified packages not being in extras is most probably the cause. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Thu, Dec 17, 2009 at 5:43 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: would there be a possibility to push them to Extras forcing an update in the background? It may be again noted that pushing library updates for end users is practically impossible because Application Manager doesn't update packages which are not in user/* category. BTW, I tested putting packages in user/hidden category and indeed (albeit autobuilder complaining about the unknown category) application manager recognizes new versions of packages in that category (showing the update notification and allowing to upgrade). Not sure if it is the best/correct solution though, as it looks like undocumented. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
pymaemo-optify: upgrading to the newer 0.3 version on Maemo 5
Hi all, This message is intended for those users already using the PyMaemo optification solution on Maemo 5. You are probably using it if you have extras-testing or extras-devel enabled on your N900. The extras repository does not contain pymaemo-optifier yet. A bug was identified (see https://bugs.maemo.org/show_bug.cgi?id=6886) which breaks Python packages when pymaemo-optify is upgraded on the command line using apt-get upgrade and some other Python package is upgraded at the same time. I uploaded a fixed package to extras-devel, but any upgrade from an older version, if done with some another Python package upgrade at the same time, will again trigger the bug. Therefore you need to upgrade only the pymaemo-optify package; later you can upload other Python packages without problem. From the command line == # apt-get install pymaemo-optify This will upgrade *only* pymaemo-optify. Using Application Manager Once the new version enters the repositories you have enabled, you should see a package upgrade notification for the pymaemo-optify package (version 0.3). If you don't see it, you don't have to do anything; it will appear at some point. Once you see the upgrade notification, upgrade *only* the pymaemo-optify package. Later you can upgrade any other packages. If you had already been affected by the bug = Run these commands on the terminal to cleanup your Python installation: # apt-get purge pymaemo-optify Then install *only* pymaemo-optify first (make sure you are installing 0.3 version): # apt-get update # apt-get install pymaemo-optify Now you can reinstall other Python applications you want. That's it. You have any problems with the upgrade, you can comment on the bug, or send an e-mail to the pymaemo-developers mailing list: https://garage.maemo.org/mailman/listinfo/pymaemo-developers/ Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: pymaemo-optify: upgrading to the newer 0.3 version on Maemo 5
On Tue, Dec 15, 2009 at 7:53 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: I uploaded a fixed package to extras-devel, but any upgrade from an older version, if done with some another Python package upgrade at the same time, will again trigger the bug. Therefore you need to upgrade only the pymaemo-optify package; later you can upload other Python packages without problem. Unfortunately, while this version fixed the upgrade issue, it broke clean installations... I sent a fixed version (0.4) that should fix this. So please, give as more testing to this new version (once it becomes available to extras-devel) as possible: clean installations, recovery from backup, upgrades through the installation manager. The same instructions from the rest of the e-mail applies, but use 0.4 instead. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA process for middleware (libfoo, python-bar) packages: some ideas
Hi, I'm not sure if there's a better list to send this (or even if it is better to user talk.maemo.org), so feel free to redirect me to the write channel. In lack of a better name for the packages the packages that exist solely as enablers for developing our great GUI applications. So far, looks like the QA process is gearing towards the user/GUI applications. For instance, the thumbs up/down system is restricted to applications is user/* categories, and the QA testers are not instructed to check for possible problems in packages outside this category. I believe we can improve on this area: to have safer and optimized middleware packages, such as libraries, language bindings, data packages, build tools, and so on. While the user will obviously notice bugs with on the UI, problems with the middleware (for instance, some unknown symbol bug or a segfault due to unexpected ABI changes) are likely to be the most serious ones IMHO. Let me give some examples of such possible bugs: * A new version of libfoo is uploaded with unexpected ABI (Application Binary Interface) changes. At the same time some application is compiled against it and it works fine, so the package (together with libfoo) is promoted to extras. OTOH, this new version libfoo does not play well with the existing packages in extras, which will break or even fail to start * A new version of python-foo (some binding for libfoo) is uploaded to extras-devel, but contains a serious flaw that makes it segfault when calling method xyz(). At the same time, GUI application is uploaded which depends on that newer version, but does not use xyz() at all. In this case, the current QA checks would basically allow the application and python-foo to enter extras, but some future application which tries to use xyz() will segfault, blocking it from entering extras until python-foo is fixed. I have some ideas to improve (and assure) the quality of middleware packages: * Require (or strongly recommend) *all* packages to have at least some sort of unit/functional testing. In fact, most packages imported from Debian has tests, but what usually happens is that they are disabled so the package can build on scratchbox. * Have some way to run these tests automatically from the package sources when uploading packages to the autobuilder. * Exercise installation of packages (maybe using piuparts? See http://packages.debian.org/sid/piuparts), if possible on a real device. * Test disk-full conditions, and randon errors during package installation of packages from Extras. * Promote usage of ABI check tools. Any other ideas? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to make python2.5 default in scratchbox?
On Mon, Dec 14, 2009 at 7:59 AM, Till Harbaum / Lists li...@harbaum.org wrote: Hi, i am trying to port some software that requires scons at build time and which in turn needs python2.5. There is a python 2.5 in the repository, but scratchbox comes with its own python 2.3. Now the question: How do i make python2.5 the default? And this needs to be in a way that also works with the autobuilder. I am trying to port the latest version of widelands to maemo5. See the last two answers in http://pymaemo.garage.maemo.org/faq.html It is exactly like Faheem solution, but be warned that it may (in some rare circumstances) break some Scratchbox wrappers that depend on python2.3. So it is not a definitive solution for every package, but should work in your case. If it does not work, feel free to post the errors and preferably the debian/rules. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: On balance, I think it is better to just stick to debhelper 5 in Fremantle. And from our experience in PyMaemo backporting various (but not that many) packages from debhelper compatibility level 7 to 5, in most cases you need just to change: * debian/compat: 7 - 5 * debian/control: Build-Depends: debhelper (= 7) - debhelper (= 5) * And maybe comment out a few dh_* calls from debian/rules, which might not exist on level 5 Now things might get complex if the packaging already uses some new features of level 7, like those CDBS-like helper rules. In such cases, looking at versions prior to the compatibility level upgrade might help doing the downgrade (and most Debian packages are kept in public SCMs like svn.debian.org). Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
On Thu, Dec 3, 2009 at 6:46 AM, Andrew Flegg and...@bleb.org wrote: 2009/12/2 Anderson Lizardo anderson.liza...@openbossa.org: All files installed under e.g. /usr/lib/python2.5 go automatically to /opt. But note that the package itself is unchanged (because pymaemo-optify takes care of handling these mount binds), so there is no way for maemo-optify to know whether to optify some Python package simply by looking at where it installs files. Short version of the required heuristics for NOT invoking maemo-optify: * any package including /opt * any package with debian/optify containing 'none' * any package with a direct, or indirect, dependency on pymaemo-optify. That indirect dependency part may be tricky to implement, maybe just check for dependency on python or python2.5 ? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl th.p...@gmail.com wrote: Maybe a meta-package that depends on all new PyMaemo packages would do the trick? AFAIK there is a user/hidden section that lets the package appear in upgrade and uninstall views, but not in the normal install view. So users won't see it in the normal application list, but would have the option to remove or upgrade the package: http://maemo.gitorious.org/hildon-application-manager/mainline/commit/f7b4542b3c77114a95e2803708cec8eeff3409f7 As I said on a previous message this solves the promote packages to extras issue, but still doesn't solve: * how to convince the user of installing this meta pacakge (does he ever have to know about Python to install e.g. gPodder?) * installing this metapackage will obviously install *all* PyMaemo packages, which will take unnecessarily precious storage even if not all packages are used. * If I understood Mikko's explanation right, HAM will not upgrade a dependency automatically (unlike apt-get upgrade), unless a installed (or to be installed) user/* application exclicitely Depends on that new version (i.e. uses Depends: package (= x.y), where x.y is the newer version). If that's correct, each new version of a dependency that contains a important fix will require *all* Python applications updating their versions to include the new required version in debian/control, if we want the user to have that fix. Mikko: feel free to correct me if I made a mistake. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[ANN] Python bindings for Location API - python-location
[cross posted to both maemo-developers and pymaemo-developers; please cut one of the lists if not subscribed to both] Hi all, The PyMaemo team is proud announce the immediate availability of Python bindings for the Location API (used for GPS access) in Maemo 5, provided by the python-location package. The package is currently available in extras-devel, but should arrive in extras-testing/extras once some application which depends on it is promoted. A tutorial-like documentation is available[1] with a complete example, based on the existing section from the Maemo 5 Developer Guide. We also have a reference manual[2] based on the C documentation. Feel free to report bugs and doubts to our mailing list: https://garage.maemo.org/mailman/listinfo/pymaemo-developers/ (or here as well). Known issues: * The satellites and cell_info attributes of GPSDevice class are still not available in Python. References: [1] http://wiki.maemo.org/PyMaemo/Using_Location_API [2] http://pymaemo.garage.maemo.org/python_location_manual/ Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades
On Tue, Dec 1, 2009 at 11:55 AM, Mikko Vartiainen mvartiai...@gmail.com wrote: On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: The other solution is to fix Application Manager :o) IMO Application Manager is broken from community (Extras) perspective. From Nokia's perspective it's probably not broken because they can control that single meta package for SSU. How could we get that fixed? I'm trying to get attention from community to problem by changing the subject... Unfortunately they seem busy with other topics :/ IMHO, I can't understand why the HAM can't be used to upgrade single packages (i.e. do a simple apt-get upgrade), and still support the meta-packages for SSU. Is it possible to write some plugin to handle upgrades of packages from extras repository in HAM? Regarding the promotion of non user/* packages to extras-testing, I really don't have other ideas besides creating a user/* metapackage and push it to extras-testing (hoping the current QA process accepts a meta-package that does nothing besides pulling new versions of important packages to extras-testing together with it, and are not supposed to be installed on the device). What developers and people involved with the QA process feel about that? Can some of the guys working on the QA process please shed some light on that? The problem is becoming more critical, and people on #maemo are saying some Python packages are broken or that Python is not optified, while the fixes have already been put on extras-devel a long time ago. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh bart...@gmail.com wrote: 2009/11/9 Marius Vollmer marius.voll...@nokia.com: When autobuilder expected to start to optify packages without debian/optify in them? I don't know. We certainly need to tune the heuristic of maemo-optify first to handle Python. As far as I see Python is optified now. When we should do next step? Correct. But, in Python's case, we didn't add such debian/optify file, and we relied on the fact that the (current) default optify policy was none. If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
On Wed, Dec 2, 2009 at 9:43 AM, Ed Bartosh bart...@gmail.com wrote: 2009/12/2 Anderson Lizardo anderson.liza...@openbossa.org: If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). I hope you'll see everything in this thread. Yes, I read the thread and I know it *will* be enabled by default, but I ask *when* because last time I checked it was still not enabled by default. (sorry because my e-mail did not make that clear). I think a simple heads up e-mail would be enough, because many people might have forgotten this rather old and long thread by now. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
2009/12/2 Benoît HERVIER kher...@khertan.net: What happen if i push something for testing like PyGTKEditor for example ... but once this one has been push, a new version of a python binding used by PyGTKEditor exist in the extras-devel, we cannot push it to extras-testing manually ? But as there isn't any new version of PyGTKEditor, i ll recreate one package in extras-devel with a greater number just to push the python binding. What happen now if this binding is a important update ? That's what is happening at the moment with python-osso. The version in extras extras-testing (0.4.0-0maemo1) has a bug where the __init__.py file is not generated (because it lacked the python-central dependency). The issue has been fixed in 0.4.0-0maemo2 some time ago, but it does not go to extras-testing because there is no package depending _explicitely_ on that new version. So unless someone promotes a user/* package to extras-testing that has Depends: python-osso (= 0.4.0-0maemo2) , python-osso will remain broken on extras extras-testing. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
On Wed, Dec 2, 2009 at 12:56 PM, Marius Vollmer marius.voll...@nokia.com wrote: ext Anderson Lizardo anderson.liza...@openbossa.org writes: If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). If a package already contains a /opt directory, no further optification is done by the maemo-optify tools in any case. Is that enough to protect you? No, because the optification was done by creating a pymaemo-optify package which bind mounts the relevant Python directories from /usr/... to /opt/pymaemo. These mounts are done during device boot by /etc/init.d/pymaemo-optify (they are not mounted inside scratchbox, of course). This means that there is no change required for python packages to become optified, they just need to depend on python. We can put additional checks into maemo-optify to disable optification. I don't know enough about Python packages to suggest a good one, but maybe just looking for /usr/lib/py* in a package and stopping to do anything would work. Actually the list of directories handled by pymaemo-optify is variable (but not expected to change). They are defined in /etc/default/pymaemo-optify and currently is: /usr/lib/python2.5 /usr/share/pyshared /usr/lib/pyshared /usr/share/python-support /usr/lib/python-support One idea might be to check whether this file exists and ignore any packages which install files to the directories listed on the BIND_MOUNTS directory (note that this file is a snippet of shell script read by /etc/init.d/pymaemo-optify). Or you can hard code this list somewhere, and you will get at least most Python packages ignored. As with every heuristics, we can't get 100% of cases, and others will need to have to be manually opted-out. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
On Wed, Dec 2, 2009 at 5:20 PM, Nathan Anderson nat...@andersonsplace.net wrote: Anderson Lizardo, Unless I misunderstood; if the package itself has a /opt path in it the maemo-optify won't run on it. So if you are installing anything (even one file) under the /opt path (which based on what I see you saying below it appears you are); it should cause the maemo-optify to not run. Not really. All Python packages (unless they were manually optified) continue to install files under /usr (you can check that with e.g. dpkg -L python2.5), but given that pymaemo-optify bind mount directories with a command like: mount --bind /opt/pymaemo/usr/lib/python2.5 /usr/lib/python2.5 All files installed under e.g. /usr/lib/python2.5 go automatically to /opt. But note that the package itself is unchanged (because pymaemo-optify takes care of handling these mount binds), so there is no way for maemo-optify to know whether to optify some Python package simply by looking at where it installs files. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
extras-devel - extras-testing auto-promotion not working?
Hi, A long time ago I was informed by Niels on this list that packages dependencies (i.e. not user application or packages under user/* categories) would be automatically promoted from extras-devel to extras-testing (and to extras FWIW) if an application that depends on it is promoted. Well, it *used* to work like that some time ago, but in the last weeks I've noticed that no newer versions of PyMaemo packages (which are all dependencies from various user/* application) got promoted as before. I don't know if it has been a manual operation of if the autopromotion system is actually broken. There has been some kind of pressure to get the optified Python packages into extras, and that depends on this auto promotion mechanism. Can someone with powers check that? I can open a bug report if necessary. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-devel - extras-testing auto-promotion not working?
On Tue, Dec 1, 2009 at 9:18 AM, Mikko Vartiainen mvartiai...@gmail.com wrote: Well, it *used* to work like that some time ago, but in the last weeks I've noticed that no newer versions of PyMaemo packages (which are all dependencies from various user/* application) got promoted as before. Packages don't get updated in promotion process if earlier version satisfies dependency. Many packages have direct dependency only for python package, which hasn't been updated lately, not for python2.5 which is the actual optified version. python2.5 isn't probably promoted because no package hasn't had dependency python2.5 (=2.5.2-3maemo3). If packagers like to keep their Depends line clean they are unlikely to put python2.5 directly there. So what should we do here to have newer version of dependencies promoted ? Obviously, we will not recommend depending on python2.5 directly (that was the whole idea of the python meta package). Also depending on a specific version just to force promotion seems odd IMHO. Should I proceed and promote the missing PyMaemo packages to extras-testing ? IMHO ideally, the auto promotion should be aware of newer versions of dependencies, otherwise how are we (the maintainers) supposed to provide bugfixes ? (.e.g the new optified packages). Thanks in advance, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
On Tue, Dec 1, 2009 at 9:51 AM, Mikko Vartiainen mvartiai...@gmail.com wrote: You can promote PyMaemo packages to extras-testing but it's not the solution, because it doesn't help getting them to Extras (you can't promote them there). Even if newer versions of non user/ packages were promoted to Extras it doesn't help much getting them to end users devices if they had earlier version of them installed because of how Application Manager works. Currently getting something to updated requires that update is somehow visible through user/ package both in Application Manager and packages interface autopromotion algorithm. Sorry but it is still not clear to me how to get fixes to non user/* packages to the users' devices. If I understand correctly, Application Manager does not follow the same behavior as apt-get on this case, i.e. it will not upgrade non user/* packages on Device even if there are new versions in extras, is that right? Promotion system could probably be changed that it always promotes newer version of non user/ package. One option would be that package maintainer can promote updates of non user/ package to extras manually, but that circumvents the whole qa process. If I remember correctly, the QA process is currently very user/* centered. I followed the discussions on last meeting too, and the process does not seem to cover the updates for non user/* packages. So right now we have a serious problem (IMHO) where we can get non user/* package updates delivered to final users through a clean process. Some user suggested once creating meta user/* packages for libraries, python modules etc. that need updates, but I think this just too hackish, and even if we proceed and do this, how do we convince the end user to install it? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
On Tue, Dec 1, 2009 at 11:32 AM, Mikko Vartiainen mvartiai...@gmail.com wrote: I still suggest meta user/* packages. Nokia is actually using meta user/* packages (for example, Maemo 5 package is a meta package pulling the platform non user/* packages when upgraded). Meta packages are unfortunately the only working way get library updates to users. I still would hate to see all libraries in Application Manager, even if they were semi hidden to some category. Only _good_ solution that I can see is that Application Manager would work the same way as apt-get and upgrade all packages (except the Nokia meta package). The problem being that the meta-package will pull *all* PyMaemo packages and not just what the user wants/needs :/ Unless Application Manager honours Suggests: fields ? in this case we could put all non-core Python packages under that field. The other solution is to fix Application Manager :o) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with extras-devel repository on N900 (No Hash entry in Release file)
On Mon, Nov 30, 2009 at 10:51 AM, Kate Alhola kate.alh...@nokia.com wrote: I can confirm it. I tried today with several devices. This bug has some random nature. One hour ago, I was able to get extras-devel but now I tried again and got same bug. Looks like someone fixed it a few minutes ago :) The Release file now is complete, and apt-get does not complain anymore on the device. Should I still open a bug report on it, or is it definitely fixed or some known issue? Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with extras-devel repository on N900 (No Hash entry in Release file)
On Mon, Nov 30, 2009 at 10:44 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: On Mon, Nov 30, 2009 at 10:51 AM, Kate Alhola kate.alh...@nokia.com wrote: I can confirm it. I tried today with several devices. This bug has some random nature. One hour ago, I was able to get extras-devel but now I tried again and got same bug. Looks like someone fixed it a few minutes ago :) The Release file now is complete, and apt-get does not complain anymore on the device. Should I still open a bug report on it, or is it definitely fixed or some known issue? Problem is back. Looks like on every repository update the Release file again is truncated. I'll open a bug report about it. -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with extras-devel repository on N900 (No Hash entry in Release file)
On Mon, Nov 30, 2009 at 2:32 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Problem is back. Looks like on every repository update the Release file again is truncated. I'll open a bug report about it. Done: https://bugs.maemo.org/show_bug.cgi?id=6460 Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: coding in python using os.system , (works on scratchbox but not on N900), Urgent pls help
On Sun, Nov 29, 2009 at 11:36 AM, shampavman shampavma...@gmail.com wrote: if anyone can confirm that something like this.. os.system(ls process_output.log) would work , it would be of really great help.. Also if there are any alternatives to using os.system. I would like to know.. If all you want is to get a list of files of a directory, try os.listdir(): listdir(...) listdir(path) - list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Scratchbox package versions on autobuilder?
On Thu, Nov 26, 2009 at 5:40 AM, Cornelius Hald h...@icandy.de wrote: Anderson Lizardo wrote: Hi, Could someone with access to the autobuilder machine send to me the output of dpkg -l scratchbox* ? I'm getting a build error that I'm unable to reproduce on my own installation: http://pastebin.com/m4f98186 Do you have glib included in your build-depends? It looks like it´s missing... It is not in build-depends, because it does not depend on it (but Qt does). On the other hand, you can see the package is installed (I even added some debug messages between XXX lines to make sure of that). The problem does not happen on a cleanly created ARMEL target I create locally, but only on the autobuilder. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Scratchbox package versions on autobuilder?
On Thu, Nov 26, 2009 at 4:23 AM, Marcell Lengyel marcell.leng...@nokia.com wrote: Hi, Could someone with access to the autobuilder machine send to me the output of dpkg -l scratchbox* ? I'm getting a build error that I'm unable to reproduce on my own installation: marc...@corsola:~$ dpkg -l scratchbox* [...] Ok, comparing the version list I see I have some more up-to-date Scratchbox packages (because I use the stable repository from scratchbox and not the maemo5-sdk one). I will try the same versions above and see if I can reproduce the problem. If so, I'll open a bug report on scratchbox. Does the i386 build goes fine for you and failing only on ARMEL? I guickly checked the log you pasted and this line looks to be the root cause to me: gnueabi/bin/ld: warning: libglib-2.0.so.0, needed by /opt/qt4-maemo5/lib/libQtCore.so, not found Yes, this error is misleading. My application depends only on Qt, which in turn depends on glib. But even with libglib installed by Qt, the linker does not seem to find it (it is in /usr/lib). I'm not sure yet if this problem happens only on ARMEL target , because the X86 build does not occur if the ARMEL one fails. I'll see If I can reproduce it locally, because the waiting for the autobuilder queue is too boring :) Thanks for your help! -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Scratchbox package versions on autobuilder?
On Thu, Nov 26, 2009 at 4:23 AM, Marcell Lengyel marcell.leng...@nokia.com wrote: Hi, Could someone with access to the autobuilder machine send to me the output of dpkg -l scratchbox* ? I'm getting a build error that I'm unable to reproduce on my own installation: ii scratchbox-too 1.0.12-10 cs2007q3-glibc2.5-arm7 compiler for Scratchb Ok I found the issue. It is related to the scratchbox-toolchain-cs2007q3-glibc2.5-arm7 version. Mine (which works) is 1.0.12-12 autobuilder one (which breaks my build) is 1.0.12-10 After downgrading the version here, I could reproduce the bug. I'll open a bug report (with a simple test case) for this on bugs.maemo.org. I'll also test x86. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Problems with extras-devel and outdated Packages.bz2
Hi, I uploaded a package to fremantle extras-devel (some hours ago), and it even hit the extras-devel repo already: http://repository.maemo.org/extras-devel/pool/fremantle/free/a/apiextractor/ (look by the date of today) But it is still not installable, because the Package index was not updated: http://repository.maemo.org/extras-devel/dists/fremantle/free/binary-i386/Packages.bz2 (it does not contain the version I uploaded) The problem is that without an up-to-date Package index I can't upload a package that depends on this new version :( Is there any problem with the Index update , or it just takes so long? Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Scratchbox package versions on autobuilder?
Hi, Could someone with access to the autobuilder machine send to me the output of dpkg -l scratchbox* ? I'm getting a build error that I'm unable to reproduce on my own installation: http://pastebin.com/m4f98186 (This is armel.build.log.FAILED.txt pasted into pastebin because the log may disappear anytime soon). The problem seems to be related to some QEMU bug, but I'm not sure. Thanks in advance :) -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
401 Unauthorized errors while fetching packages from repository.maemo.org
Hi, I'm getting 401 Unauthorized errors while fetching packages from repository.maemo.org using apt-get. Strangely the problem happens at random (and with random packages), and trying again sometimes work. The problem also happens with not just one repository , but at least with SDK and extras-devel repositories. Is anyone having this problem? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
PyMaemo now optified (in extras-devel)!
Hi, I uploaded to fremantle extras-devel a new package called pymaemo-optify and an updated version of python2.5 that depends on this package. It basically implements the idea proposed by Andrew Flegg of using mount --bind to relocate the biggest Python directories to /opt: /usr/lib/python2.5/site-packages /usr/share/pyshared /usr/lib/pyshared /usr/share/python-support /usr/lib/python-support This does not cover all files installed by PyMaemo packages, juts the biggest ones. Only handling the above already cuts more than 20MB from root filesystem, just for a simple apt-get install python-gtk2. More directories can be added later if necessary, through updates to the pymaemo-optify package. pymaemo-optify should correctly handle upgrades, migrating the above directories to /opt/pymaemo and mount --bind ing them back to their location. So for most users, simply run update on the Application Manager and all these directories will magically go to /opt (and any packages that install files under these directories will be automatically optified too), thus freeing up precious storage on root filesystem. The optified Python installation will naturally migrate to extras-testing once some Python application gets promoted. For now, use extras-devel to try it. How to optify a Python application? If your application is already modular and installs modules to /usr/lib/python2.5/site-packages, your application will be automatically optified. If your application consists of a single script installed under /usr/bin, the recommended way is to make it into a module installed to /usr/lib/python2.5/site-packages , with a main method that can be called from the /usr/bin script. Example: Instead of a single /usr/bin/my_app script with: application_code main_code You can have a /usr/lib/python2.5/site-packages/my_app.py with: application_code def main(): main_code And have a /usr/bin/my_app with something like: import my_app my_app.main() This is just a suggestion though, developers are free to design their code as they like. TODO: - optify /usr/bin/python2.5 (it seems a symlink should work, after some testing we will upload a new version of python2.5 to reduce around 1 MB from root fs usage. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Fri, Nov 13, 2009 at 3:18 AM, Yves-Alexis Perez cor...@debian.org wrote: On mar., 2009-11-10 at 12:33 -0400, Anderson Lizardo wrote: Nice to hear that! We decided to leave out the optification for the final release, just not to delay it even more. But now I believe we can work on it as an update through extras-devel (I just hope that that QA process will take any possible regressions with the new packages we upload). Hmhm so everything will install on OneNAND ? Or everything will install on eMMC ? The current release installs on the flash root device, but we are already working on a new version that will install into the eMMC. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Thu, Nov 12, 2009 at 11:30 AM, Eero Tamminen eero.tammi...@nokia.com wrote: ext Anderson Lizardo wrote: Do you think it can be made a generic dh_* like tool that handles this automatically? This way it could be called from debian/rules as e.g.: maemo-python-optify /usr/lib/python2.5 and the init scripts be generated automatically. What do you think? Are you suggesting that each python package would themselves do the bind mount? And hide anything that was before in that directory? Saner solution is that the bind mount is done by something from which the package depends from (be it python package itself or something else). No no, I'm just suggesting make it a generic, more automatic tool (like maemo-optifier itself) that can be used by other bigger packages that maemo-optify cannot handle generically (although I'm not aware of any other cases). This is optional though, and for Python we will handle it now instead of waiting for this tool to be written. For Python, we will bind mount just the core python2.5 package. This way, all packages that depend on python2.5 and install modules/extensions to /usr/lib/python2.5 will benefit from it transparently. I should also remember that we have to handle packages that use python-central/python-support too, as they move the extensions to other places (directories under /usr/share/... and /var/lib/... IIRC). They will be handled similarly as well. We will also make sure all possible installation paths (fresh install, upgrade from optified package, downgrade to non-optified package, removal) are properly handled so that we can cleanly move in/out from the bind mount solution and avoid upgrade breakages. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get n900 IMEI code in C
On Wed, Nov 11, 2009 at 7:28 AM, Faheem Pervez tripp...@gmail.com wrote: My method is quite low-tech: I discovered get_imei by looking at the strings in the About product applet (I have a pre-production device) and putting the required pieces together to make a dbus-send command line with --print-reply so I can see the exact type of what is returned. get_imsi was even easier... /etc/event.d/tonegen has it blatantly listed... There is also the d-feet tool: https://fedorahosted.org/d-feet/ I used it on scratchbox and desktop to find available D-Bus services/methods for running process. In theory it might work on the NXXX devices as well (it is written in python) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
On Tue, Nov 10, 2009 at 9:16 AM, Frantisek Dufka duf...@seznam.cz wrote: But still it could be useful to set different compiler flags for arm (vfp, thumb mode) [...] For that I think the standard way is to use dpkg-architecture in debian/rules, e.g.: HOST = $(shell dpkg-architecture -qDEB_HOST_ARCH) ... ifeq ($(HOST),armel) # some ARM specific commands go here endif [...] or workaround some stuff not available in stratchbox environment. I see some packages checking for scratchbox environment by looking for presence of /targets/links/scratchbox.config. This file is only available when you are inside a scratchbox target. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
Hi, The PyMaemo team is pleased to announce the final release of PyMaemo for Maemo 5! For users, no manual installation steps are necessary. If you want to enjoy Python on your tablet, simply install a Python application from the repository. For developers which want to try the latest versions of PyMaemo packages, make sure to add extras-devel repository to the Scratchbox target and/or tablet. For instructions, see http://pymaemo.garage.maemo.org/installation.html. Due to the auto promotion of dependencies in Fremantle, many packages have their latest versions in extras-testing/extras already, but some are still on extras-devel only. What is it? -- Python for Maemo (PyMaemo for short) main objective is to make possible to use Python programming language as the scripting and development language for Maemo Platform, providing a better alternative for fast prototyping and programming in Maemo environment besides the C programming language. Python is for serious programming and to have fun. Python has a nice syntax, it is easy to learn and powerful enough for a vast range of applications, this is why we choose Python for Maemo. What has changed? --- Removed packages: * libffi + Now installed by default on N900 * pyid3lib + Unmaintained upstream, not used by any package in Fremantle Updated packages: * pygobject 2.16.1-1maemo1 + Update to latest version from Ubuntu jaunty * pygtk 2.12.1-6maemo9 + Update gtk.Dialog with Maemo changes * python-hildondesktop 0.1.0-1maemo1 + Bump version due to (unavoidable) API changes. + Fix current maintainers in AUTHORS and debian/copyright. * python-setuptools 0.6c9-1maemo2 + make easy_install always be called with the default Python version (/usr/bin/pythonX.Y) * python-xml 0.8.4-10.1maemo4 + Integrate fixes for python2.6 (taken from Ubuntu jaunty) (NOTE: this is just a compatibility fix, Fremantle will only have python2.5) Bugs fixed: MB#5091, MB#5141, MB#5154, MB#5232, MB#5275, MB#5467 Known issues - python-mafw (Python bindings for MAFW) is still considered alpha quality, and there are a couple of known issues on it: MB#4824: python-mafw: source_browsing.py example does not work MB#4839: python-mafw: mafw.Registry lacks list_plugins() method MB#4849: python-mafw: MafwPluginDescriptorPublic structure is missing MB#4919: python-mafw: list of missing types to complete methods bindings MB#4932: python-mafw: mafw.Source.browse() method is missing MB#4934: python-mafw: MetaData class missing There are no bindings for GUPnP (MB#4829), libhildonmime (MB#5157), liblocation (MB#5748) as well for various other Maemo 5 components. We plan to work on providing bindings for these components during the Maemo 5 life cycle. The PyMaemo base set of packages take considerable storage space (MB#5364). We already started experiments with the maemo-optify tool to install biggest things out of root fs, and we also plan to reduce a plenty of storage usage by cutting unnecessary things (such as some remaining documentation). Expect next releases to reduce storage usage gradually. We will not migrate to python2.6 in Maemo 5 due to a (unresolved) bug (MB#4734), where a core SDK package explicitly conflicts with python = 2.6, preventing any further upgrades from the 2.5.x series. This release is supposed to be compatible with previous releases. If you have any issues regarding building or running your Python application on Maemo 5, feel free to contact us (see below for how to contact the PyMaemo team and report bugs). Acknowledgments: - Thanks to everybody who helped making this release possible. Bug reports, as always, should go to our Bugzilla [1]. Use the pymaemo-developers mailing list [2] for help, feedback or suggestions. References -- [1] https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo [2] https://garage.maemo.org/mailman/listinfo/pymaemo-developers Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
2009/11/10 Benoît HERVIER kher...@khertan.net: (such as some remaining documentation) Oh no Please no Did you think it s possible to keep it in a separate package as for example there is still some python modules which has an interactive help() and it s really usefull for onboard developpers like me (i don't know if i not the only one :) ) I was referring specifically to the static documentation (HTML, PDF) which have no need to be installed on the device. The built-in documentation from the docstrings are still there, and would only be removed if it can be proven they take considerable space. Unfortunately you will notice that, except for Python standard modules, other PyMaemo bindings lack useful built-in documentation accessible through help(). BTW, you might want to try ipython if you like to develop on the device, helps a lot IMHO :) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Tue, Nov 10, 2009 at 12:11 PM, Andrew Flegg and...@bleb.org wrote: On Tue, Nov 10, 2009 at 16:00, Anderson Lizardo anderson.liza...@openbossa.org wrote: The PyMaemo team is pleased to announce the final release of PyMaemo for Maemo 5! BTW, I've tested with bind mounts and /opt. [...] Nice to hear that! We decided to leave out the optification for the final release, just not to delay it even more. But now I believe we can work on it as an update through extras-devel (I just hope that that QA process will take any possible regressions with the new packages we upload). I've done the following and it seems to work well: * Created /opt/python2.5/lib * Moved the contents of /usr/lib/python2.5 to /opt/python2.5/lib * Created an init script, symlinked to S20python-optify, which does (on start): mount --bind /opt/python2.5/lib /usr/lib/python2.5 This freed up lots of space on the rootfs and does not seem to have impacted start-up time of Python apps particularly noticably. I can share the startup/shutdown script and maybe even package this as a Python Optifier if you want. Do you think it can be made a generic dh_* like tool that handles this automatically? This way it could be called from debian/rules as e.g.: maemo-python-optify /usr/lib/python2.5 and the init scripts be generated automatically. What do you think? I think this is one of the best ways of optifying Python and without any patches. I'd suggest this gets included in the next release of PyMaemo. Did you do any kind of upgrade tests? I'm worried how that would work if you are upgrading from an older non-optitified python installation. I also suppose that this implicitly moves files from other packages to /opt/python2.5 ? E.g. from python-hildon, python-gtk2 etc. ? What about the /usr/bin/python2.5 binary (which takes some MB) did you move it to /opt too? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
2009/11/10 Benoît HERVIER kher...@khertan.net: https://bugs.maemo.org/show_bug.cgi?id=5871 Is it fixed ? (i ll try :) At least two people tried but could not reproduce this bug on N900 (using the latest 0.10 package). Can you please try again and check if you are using the 0.10-1maemo1 version ? Thanks! -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
python-dbus Re: Autobuilder repository priority ?
On Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa ma...@csipa.in.rs wrote: Foreword: My particular problem is not that big of an issue, in the end I went for extras-devel compatibility, no big deal, it's not yet for end users anyway. It's the generic approach that is at question here - tomorrow someone else will fall through the same manhole and it might become a recurring issue. On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote: Did you mean -1maemo1 instead of -1maemo0? (there is no maemo0 IIRC) Yes, indeed, -1maemo1. To add to the confusion there *IS* a python2.5-0maemo0 in *extras-testing* (see http://maemo.org/packages/view/python2.5-dbus/ ) This is certainly a bug. Someone else uploaded this package without knowing there was already a python-dbus package in fremantle extras-devel (apparently some months ago). This created two entries for virtually the same package: http://maemo.org/packages/view/python-dbus/ (the newer one) http://maemo.org/packages/view/python2.5-dbus/ (the older) I'm CC'ing the original uploader of this package (Johannes) and Jeremy as well, so that we can remove the older package from extras* repositories. As you can see the version number of this package (0.83-0maemo0) is actually smaller than the one maintained by the PyMaemo team (0.83.0-1maemo1), so we can safely remove it, I suppose. Johannes: any problems with that? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa ma...@csipa.in.rs wrote: On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote: Can you be more specific? Which paths are those? How does this affect your package? Okay, I backtracked my steps as far as I could, and it *seems* the actual source of the problem is python-support (which I pull in through python-dbus). 1maemo1 (from the SDK) pulls in python-support 0.6.4 (from the SDK). 1maemo3, on the other hand, pulls in python-support 1.0.2maemo1 (from extras-devel). Depending on which python-support module got pulled in, the paths for the dbus module change: [...] This path has changed due to the new python-support 1.0.2 version. They decided to change this path for some reason. Unfortunately, we can't keep compatibility in this case, as it was an upstream change. Ideally, your package should not depend on that path being the same forever. In my opinion, the best way to handle it is to have your package Build-Depend on python-support (= 1.0.2maemo1), given that you rely on this private path (which BTW comes from installedpath variable in /usr/share/python-support/private/movemodules). And since the paths change, the .so will go (or rather won't go, as the autobuilder bombs) to the wrong path. Yes, I know, I can introduce a downstream patchset and start depending on python-support myself, but that is not the point here. :) I can see that it is not the main point of the discussion (I myself had problems with some broken libraries being uploaded to extras-devel that shadowed working ones from the SDK), but keep in mind that in case of any python* packages in the SDK, it is legitimate for the PyMaemo team to upload up-to-date versions to the extras* repositories, and you should not rely on any Python packages that come from the SDK tools repository when doing Python development on Maemo, as they are outdated and they are there just for satisfying dependencies of some SDK tools. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python-dbus Re: Autobuilder repository priority ?
On Wed, Nov 4, 2009 at 8:25 AM, Johannes Schmid johannes.sch...@openismus.com wrote: Hi! Johannes: any problems with that? Sure, so I must admit I cannot remeber uploading this package. But I suppose something is depending on python2.5-dbus which should be fixed. Can you check this in the repository? python-dbus (the newer package) has this in debian/control: Provides: python2.5-dbus This should satisfy dependencies for those packages that Depend: on python2.5-dbus. It works very well for other packages we currently maintain in PyMaemo. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Sat, Oct 31, 2009 at 7:45 AM, Attila Csipa ma...@csipa.in.rs wrote: I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? I'm interested to know what problems you are having with python-dbus. Can you please fill a bug report under https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ? As you might know, Python is not officially supported on Maemo. The PyMaemo team provides most of the Python components used by Python development on Maemo. Some Python packages happen to be present on the SDK, but that does not mean that they are officially supported. They are there to satisfy dependencies for some *SDK* tools, which are not present on the N900 device. Also note that the python packages that are on the SDK were packaged by the PyMaemo team (the -1maemo1 version was packaged by myself and other PyMaemo team members, as you can see on the debian/changelog). The Maemo developers just took the packages and integrated into the SDK to satisfy the dependencies mentioned below. But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. And last but not the least, the python-dbus version you are referring (-1maemo3) is not supposed to be unstable. We had no bug reports about it, so if you are having problems with it, please report a bug so we can fix it ASAP. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tue, Nov 3, 2009 at 11:30 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. That also means you MUST have at least the extras-testing repository enabled on your scratchbox targets for any Python development under Maemo, otherwise you will use very outdated versions of some Python packages, which lack important fixes. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
