Re: 0xFFFF 0.5 released
Hi, On Tue, Sep 18, 2012 at 11:25 AM, Pali Rohár 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 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?
On Thu, Jul 7, 2011 at 3:16 PM, Anderson Lizardo 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: Can anyone tell me how the N900 vibrator driver works?
Hi Jonathan, On Thu, Jul 7, 2011 at 1:06 PM, Jonathan Wilson 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: Canola's main website
On Wed, Apr 28, 2010 at 3:09 AM, Fabio Leal 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 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 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 : > 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
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: Request: Tutorials & use-cases for documentation
On Thu, Feb 11, 2010 at 7:44 PM, Dave Neary 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
Re: Broken Qt Packages?
On Wed, Feb 10, 2010 at 5:03 AM, Antonio Aloisio 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 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 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 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: Hildon-Desktop: added Widget not shown
On Mon, Jan 11, 2010 at 4:18 PM, Thomas Waelti 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: Telephone API question - answering a call.
Hi, On Wed, Jan 27, 2010 at 5:07 AM, Dave Neary 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: Build Server Configuration
On Tue, Jan 26, 2010 at 8:05 AM, Ed Bartosh 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 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 1:21 PM, Nathan Anderson 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: Maemo extras repository package uploader/maintainer verification?
On Fri, Jan 22, 2010 at 1:08 PM, Eero Tamminen 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 12:40 PM, Jeremiah Foster 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: Garage mailing lists still down?
Hi, On Tue, Jan 19, 2010 at 10:55 AM, Ferenc Szekely 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 was undeliverable. The reason for the problem: 5.1.0 - Unknown address error 554-'5.7.1 : 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 : 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
Re: Problems when trying to enter a new bug in Bugzilla
On Tue, Jan 19, 2010 at 12:36 PM, Andre Klapper wrote: > Am Dienstag, den 19.01.2010, 12:24 -0400 schrieb Anderson Lizardo: >> [sorry if this is not the correct channel for such reports, but in >> this case I obviously can't open a bug report > > (You can, it's just the bugmail which is not working.) Hmm, time to close my duplicated bug report then (I tried submitting the same bug twice to make sure it was not a temporary problem). >> the error mentions bugzi...@maemo.org, but I don't know if it is valid] > > In general feel free to try an address before assuming that it fails > anyway. ;-) Well, after getting a server failure response only the next day after I sent an e-mail (as described in my other message), I tend to not trust my mail server to try this. :( Not maemo.org's fault, though. > Yes, see https://bugs.maemo.org/show_bug.cgi?id=7854 Thanks, as I thought it was not a bugmail problem, I did not think on searching the bugzilla. 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 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
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
Re: D-Bus signals in python
On Sat, Jan 16, 2010 at 5:34 AM, Matan Ziv-Av 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 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 : > 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: Hildon-Desktop: added Widget not shown
2010/1/13 Kimmo Hämäläinen : > 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
On Tue, Jan 12, 2010 at 8:22 PM, Anderson Lizardo wrote: > On Tue, Jan 12, 2010 at 5:08 PM, Mikko Vartiainen > wrote: >> On Tue, Jan 12, 2010 at 10:51 PM, Anderson Lizardo >> 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 Tue, Jan 12, 2010 at 5:08 PM, Mikko Vartiainen wrote: > On Tue, Jan 12, 2010 at 10:51 PM, Anderson Lizardo > 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 5:00 PM, Thomas Wälti 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 6:06 PM, Brent Chiodo 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 4:47 PM, Mikko Vartiainen 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: [Fremantle] Creating gconf keys upon installation
2010/1/12 Faheem Pervez : > 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 "--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 Mon, Jan 14, 2008 at 7:13 PM, Thomas Waelti 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 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: Auto builder - Maemo-Optify
On Thu, Jan 7, 2010 at 11:34 AM, Marius Vollmer
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: Debugging applet causing hildon-home crash
2010/1/7 Kimmo Hämäläinen : > 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: Drag & Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
On Thu, Jan 7, 2010 at 5:37 AM, Claudio Saavedra 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
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
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_
Re: Translating "Description" field in debian/control
2010/1/4 Cornelius Hald : > 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: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 11:16 AM, Marius Vollmer wrote: > ext Anderson Lizardo 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: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 8:11 AM, Marius Vollmer wrote: > ext Ed Bartosh 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: Semi-transparent background for Desktop Widget (Python + Cairo)
On Thu, Dec 24, 2009 at 1:40 PM, Anderson Lizardo 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: Semi-transparent background for Desktop Widget (Python + Cairo)
Hi,
On Wed, Dec 23, 2009 at 5:28 PM, Brent Chiodo 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.
Re: Auto builder - Maemo-Optify
2009/12/24 Andrew Flegg : > 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)
On Sat, Dec 19, 2009 at 3:41 PM, Brent Chiodo 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: sbdmock sample config
On Wed, Dec 23, 2009 at 11:54 AM, Jeff Moe 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: sbdmock sample config
On Wed, Dec 23, 2009 at 9:38 AM, Jeff Moe 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: sdl-mixer >= 1.2.7 && libboost on Fremantle
On Wed, Dec 23, 2009 at 5:37 AM, Gibro Vacco 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: Pushing optified Python libs
On Fri, Dec 18, 2009 at 2:44 PM, Niels Breet 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: Pushing optified Python libs
On Fri, Dec 18, 2009 at 4:00 PM, Mikko Vartiainen wrote: > On Fri, Dec 18, 2009 at 9:44 PM, Niels Breet 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: Pushing optified Python libs
On Fri, Dec 18, 2009 at 3:14 PM, Niels Breet 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: Debhelper 7
On Fri, Dec 18, 2009 at 9:46 AM, Eero Tamminen 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 Thu, Dec 17, 2009 at 5:43 PM, Mikko Vartiainen 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
Re: Pushing optified Python libs
On Thu, Dec 17, 2009 at 6:16 AM, 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: QA process for "middleware" (libfoo, python-bar) packages: some ideas
On Thu, Dec 17, 2009 at 8:28 AM, Anderson Lizardo 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: QA process for "middleware" (libfoo, python-bar) packages: some ideas
lation of packages (maybe using piuparts? See >> http://packages.debian.org/sid/piuparts), if possible on a real >> device. > > I think the maemo version of lintian does/will do such stuff but not by > installing but by checking package for known failures. A working > installation is not good enough. You would need to start 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
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: pymaemo-optify: upgrading to the newer 0.3 version on Maemo 5
On Tue, Dec 15, 2009 at 7:53 AM, Anderson Lizardo 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
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: Debhelper 7
On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer 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: How to make python2.5 default in scratchbox?
On Mon, Dec 14, 2009 at 7:59 AM, Till Harbaum / Lists 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
[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 (was: Re: extras-devel -> extras-testing auto-promotion not working?)
On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl 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
Re: maemo-optify, autobuilder & /opt
On Thu, Dec 3, 2009 at 6:46 AM, Andrew Flegg wrote: > 2009/12/2 Anderson Lizardo : >> >> 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: maemo-optify, autobuilder & /opt
On Wed, Dec 2, 2009 at 5:20 PM, Nathan Anderson 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
Re: maemo-optify, autobuilder & /opt
On Wed, Dec 2, 2009 at 12:56 PM, Marius Vollmer wrote: > ext Anderson Lizardo 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: 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 : > 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 9:43 AM, Ed Bartosh wrote: > 2009/12/2 Anderson Lizardo : >> 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: maemo-optify, autobuilder & /opt
On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh wrote: > 2009/11/9 Marius Vollmer : > >>> 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: QA Process for non user/* packages and how Application Manager handles upgrades
On Tue, Dec 1, 2009 at 11:55 AM, Mikko Vartiainen wrote: > On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo > 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: 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 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
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 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: extras-devel -> extras-testing auto-promotion not working?
On Tue, Dec 1, 2009 at 9:18 AM, Mikko Vartiainen 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
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: Problems with extras-devel repository on N900 ("No Hash entry in Release file")
On Mon, Nov 30, 2009 at 2:32 PM, Anderson Lizardo 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: Problems with extras-devel repository on N900 ("No Hash entry in Release file")
On Mon, Nov 30, 2009 at 10:44 AM, Anderson Lizardo wrote: > On Mon, Nov 30, 2009 at 10:51 AM, Kate Alhola 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 10:51 AM, Kate Alhola 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
Problems with extras-devel repository on N900 ("No Hash entry in Release file")
Hi, I've noticed a problem with extras-devel repository. Its Release file is missing the hashes for the indexes files. Compare this (broken) Release file: http://repository.maemo.org/extras-devel/dists/fremantle/Release with the one from extras: http://repository.maemo.org/extras/dists/fremantle/Release or even from Diablo extras-devel: http://repository.maemo.org/extras-devel/dists/diablo/Release Because of this, "apt-get update" is failing to update the extras-devel indexes on N900, with the following error: W: Failed to fetch http://repository.maemo.org/extras-devel/dists/fremantle/Release No Hash entry in Release file /var/lib/apt/lists/repository.maemo.org_extras-devel_dists_fremantle_Release E: Some index files failed to download, they have been ignored, or old ones used instead. This means that extras-devel packages cannot be currently installed on the N900. Strangely, this problem only happens on the N900. Scratchbox seems happy with the incomplete Release file (probably the apt-get version in Scratchbox ignore the error). Can someone confirm this on N900? If so, I'll open a bug report about it. 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: 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 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 Fri, Nov 27, 2009 at 3:19 AM, Marcell Lengyel wrote: >> Mine (which works) is 1.0.12-12 >> autobuilder one (which breaks my build) is 1.0.12-10 > > I have upgraded the toolchain on the autobuilder machine. Please try again. Wow, that was fast :) I was even preparing a bug report to actually update the autobuilders. Fortunately, I found a workaround which allowed me to upload my packages even on the older toolchain. On a next upload I'll try removing the workaround and see what happens: For those interested, the issue with the older version is that it didn't like manipulation of the RPATH using the -rpath parameter for the linker. It seemed to remove the /usr/lib directory from the library path when using the parameter. My workaround consisted on also adding /usr/lib using -rpath, so I had : -Wl,-rpath,/custom/dir:/usr/lib The 1.0.12-12 fixed this problem. 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: Scratchbox package versions on autobuilder?
On Thu, Nov 26, 2009 at 4:23 AM, Marcell Lengyel 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
Re: Scratchbox package versions on autobuilder?
On Thu, Nov 26, 2009 at 4:23 AM, Marcell Lengyel 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 5:40 AM, Cornelius Hald 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
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
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
"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: You can have a /usr/lib/python2.5/site-packages/my_app.py with: def main(): 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 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 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 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: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
2009/11/10 Benoît HERVIER : > 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
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 wrote: > On Tue, Nov 10, 2009 at 16:00, Anderson Lizardo > 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 : > "(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
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: maemo-release
On Tue, Nov 10, 2009 at 9:16 AM, Frantisek Dufka 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
Re: python-dbus Re: Autobuilder repository priority ?
On Wed, Nov 4, 2009 at 8:25 AM, Johannes Schmid 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 Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa 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
