Re: Unified map tile storage
Hi, hmm, i added a debian/optify with content auto to exactly that version. But the resulting binary is still in /usr/bin. I am confused ... Till Am Samstag 09 Januar 2010 schrieb Jeff Moe: On Friday 08 January 2010 17:01:10 Till Harbaum / Lists wrote: Hi, maep 1.1 is currently in the autobuilder and is supposed to store tiles where you suggested. It is supposed to ask the user whether he wants to move the existing cache etc ... Please give it a try and check that you can live with the result. WORKSFORME. The tile maps appear to have moved. I just did a quick test of disconnecting net and then looking at previous places and they were there and also switching from Hybrid to Google maps, etc. I didn't dig deeper, but it appears to have worked. Thanks for Maep, it's my favorite mapping program. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
On Sat, Jan 9, 2010 at 08:49, Till Harbaum / Lists li...@harbaum.org wrote: hmm, i added a debian/optify with content auto to exactly that version. But the resulting binary is still in /usr/bin. I am confused ... auto will only optify the package if certain criteria are met. One of these (the key one in fact) is whether it's already optified. This is important for when auto becomes the default. Since you've got stuff in /opt/maep, maemo-optify-deb will not do any further optification, as it considers that you're aware of optification and done it yourself. HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder is broken again
Hi guys, Do you happen to know who switched off armel builds and why? As I can see from yesterday evening autobuilder performs only i386 builds. If i386 packages are uploaded to the extras-devel it would lead to even more confusion among developers, because armel versions are not built, but reuploading would not be possible, because of i386 versions in the repo. I'd propose to switch autobuilder off while you do your work instead of breaking it so often. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Python and pygst development only on device?
Hello, yesterday I tried to dig a little bit into python and gstreamer development. I downloaded the source of the mediaplayer panucci and wanted to run it inside scratchbox - without luck. I didn't found the package containing pygst. The python developer howto suggests developing on the device - is this (more or less) the only way to go? Or did I miss something? Yours, Klaus -- Klaus Rotter * klaus at rotters dot de * www.rotters.de ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
debian/optify not sufficient
Hi, i just added a debian/optify file containing nothing but the word auto to Maep 1.1. Unfortunately the resulting deb package still has the binary in /usr/bin Why? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
Hi, can i force it to optify the remaining stuff, anyway? I consider optification to be so ugly that i rather have the script doing something nasty than spending even more time with it myself. Till Am Samstag 09 Januar 2010 schrieb Andrew Flegg: On Sat, Jan 9, 2010 at 08:49, Till Harbaum / Lists li...@harbaum.org wrote: hmm, i added a debian/optify with content auto to exactly that version. But the resulting binary is still in /usr/bin. I am confused ... auto will only optify the package if certain criteria are met. One of these (the key one in fact) is whether it's already optified. This is important for when auto becomes the default. Since you've got stuff in /opt/maep, maemo-optify-deb will not do any further optification, as it considers that you're aware of optification and done it yourself. HTH, Andrew ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
Till wrote: can i force it to optify the remaining stuff, anyway? I consider optification to be so ugly that i rather have the script doing something nasty than spending even more time with it myself. NAFAIK. You've three options, I think: 1) Don't do any optification yourself and let the builder handle it. 2) Put the binary under /opt/maep and create a symlink to /usr/bin yourself. 3) Put the binary under /opt/maep and change the .desktop file to invoke it from there. HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Saturday 09 January 2010 03:40:29 Qole wrote: So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? Quickly gotta run... Well, it may not all be open: * It fires up the Maemo phone GUI--I'd have to investigate what parts of that are open/closed. * It calls pulseaudio which may be using a proprietary codec for GSM audio. * It's only voice calls, no SMS etc, so it's not a full stack yet. I will be trying all this under Fedora 12 on N900 as that gives me a clean slate to work from to track down what all is really involved. But progress no doubt. :) -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging applet causing hildon-home crash
On Thursday 07 January 2010 15:48:34 Anderson Lizardo wrote: 2010/1/7 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: 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) ... 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. Thanks for the hints -- very useful. I have already found and fixed several bugs with unloading the plugin! A couple of notes for future reference for anyone who is searching for hildon-home crashes when unloading an HDHomePluginItem home widget... 1) HDHomePluginItem provides a useful optimised timer capability (hd_home_plugin_item_heartbeat_signal_add) but if you use this, you WILL crash hildon-home when your plugin is unloaded, unless you destroy the event source in your class finalize function. For example, in gpesummary I have added: if (current_timer) g_source_destroy(g_main_context_find_source_by_id(NULL,current_timer)); This should really be added to the documentation for hd_home_plugin_item_heartbeat_signal_add (reported in bug 4337). 2) Make sure that any libraries you use are not running any timers (or any other callbacks) which could fire later. For example, in gpesummary, I have to explicitly close the event database as otherwise libeventdb leaves a timer running which will cause a crash when it fires (of course, that is good practice anyway in order to free up the memory!). Maybe hildon-home should be using a separate GMainContext for each plugin -- would that mean it could automatically destroy all the event sources associated with the plugin before unloading it? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging applet causing hildon-home crash
On Thursday 07 January 2010 15:48:34 Anderson Lizardo wrote: 2010/1/7 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: On Wed, 2010-01-06 at 22:46 +0100, ext Graham Cobb wrote: In Fremantle, the GPE Summary applet causes hildon-home to crash if it is removed and then re-added. I have not been able to work out what the problem is. We had several of this kind of crashes that happen when you remove and add it back. Usually the problem was in the Glib types that the applet uses: if it tries to register new types that are already there, or something similar. I guess Glib should print out some warnings for you? (notice that hildon-home probably closes stdout by default) As a side note, python-hildon suffered from these issues because the latest hildon-home (or hildon-desktop?) versions seemed to incorporate some gtype registration functions which were missing before (i.e. ones usually generated by glib-mkenums). The python bindings tried to register the same types again, which caused problems (the errors shown on console gave a hint about this). I can now reliably unload my plugin but I cannot add it back again. I hit this GType problem. My plugin (actually some of the libraries it relies on) use GTypes. So, of course, they register them. When reloaded, the attempt to register them again fails (and generates warning messages). But the functions for the type are now associated with code which has been unmapped from memory! So, when I use one of the types it crashes. As there is no way (that I am aware of) for GTypes to be unregistered, or to be reregistered, is there some way for me to stop hildon-home actually unmapping my code? At least that would mean that the plugin could be re-added to the desktop, although no newer version would be usable until a reboot. This seems to be an unsolvable problem: no desktop plugin can use (or use a library which uses) GTypes! Am I missing something? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging applet causing hildon-home crash
Hi,
On 01/09/2010 02:52 PM, Graham Cobb wrote:
On Thursday 07 January 2010 15:48:34 Anderson Lizardo wrote:
2010/1/7 Kimmo Hämäläinenkimmo.hamalai...@nokia.com:
On Wed, 2010-01-06 at 22:46 +0100, ext Graham Cobb wrote:
In Fremantle, the GPE Summary applet causes hildon-home to crash if it
is removed and then re-added. I have not been able to work out what the
problem is.
We had several of this kind of crashes that happen when you remove and
add it back. Usually the problem was in the Glib types that the applet
uses: if it tries to register new types that are already there, or
something similar. I guess Glib should print out some warnings for you?
(notice that hildon-home probably closes stdout by default)
As a side note, python-hildon suffered from these issues because the
latest hildon-home (or hildon-desktop?) versions seemed to incorporate
some gtype registration functions which were missing before (i.e. ones
usually generated by glib-mkenums). The python bindings tried to
register the same types again, which caused problems (the errors shown
on console gave a hint about this).
I can now reliably unload my plugin but I cannot add it back again.
I hit this GType problem. My plugin (actually some of the libraries it relies
on) use GTypes. So, of course, they register them. When reloaded, the
attempt to register them again fails (and generates warning messages). But
the functions for the type are now associated with code which has been
unmapped from memory! So, when I use one of the types it crashes.
As there is no way (that I am aware of) for GTypes to be unregistered, or to
be reregistered, is there some way for me to stop hildon-home actually
unmapping my code? At least that would mean that the plugin could be re-added
to the desktop, although no newer version would be usable until a reboot.
You could define a g_module_check_init like this:
const gchar *
g_module_check_init (GModule *module)
{
g_module_make_resident(module);
return NULL;
}
to prevent the module of being unloaded (see
http://maemo.org/api_refs/5.0/5.0-final/glib/glib-Dynamic-Loading-of-Modules.html#glib-Dynamic-Loading-of-Modules.description).
Best regards,
Jan Arne
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: oFono
For the SMS portion, I'd encourage you to check out PyMaemoSMS I've tweaked it and used it succesfully to send SMS messages from Python on my N900 For more info, check out #n900 mbarcode, python, SMS and sqlite3 http://www.orient-lodge.com/node/3896 I really look forward to playing with oFono. Aldon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org]on Behalf Of Jeff Moe Sent: Saturday, January 09, 2010 7:36 AM To: maemo-developers@maemo.org Subject: Re: oFono On Saturday 09 January 2010 03:40:29 Qole wrote: So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? Quickly gotta run... Well, it may not all be open: * It fires up the Maemo phone GUI--I'd have to investigate what parts of that are open/closed. * It calls pulseaudio which may be using a proprietary codec for GSM audio. * It's only voice calls, no SMS etc, so it's not a full stack yet. I will be trying all this under Fedora 12 on N900 as that gives me a clean slate to work from to track down what all is really involved. But progress no doubt. :) -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
On Saturday 09 January 2010 11:47:24 Till Harbaum / Lists wrote: can i force it to optify the remaining stuff, anyway? I consider optification to be so ugly that i rather have the script doing something nasty than spending even more time with it myself. No. It is a good suggestion for a further feature, but we need to get the basic capability into full use first. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder is broken again
On Saturday 09 January 2010 06:36:12 Ed Bartosh wrote: Hi guys, Do you happen to know who switched off armel builds and why? May I humbly suggest using something like `git` to track configuration changes? In this case it may not have helped (e.g. if someone did a `/etc/init.d/foo stop`), but it will help you keep track of what changes are going on in the system if you have multiple admins. Quick dirty example: Have each user set up a ~/.gitconfig like: [user] name = Jeff Moe email = m...@blagblagblag.org [color] branch = auto diff = auto status = auto sudo bash apt-get install git-core cd /etc # make a /etc/.gitignore file along the lines of this: ld.so.cache prelink.cache *.swp ld.so.cache adjtime blkid.tab blkid.tab.old mtab adjtime ld.so.cache git init chmod og-rwx .git git add . EDITOR=vim git commit -a Then do `git add foo` when new files are added and `git commit -a` when finished making config changes. Then if you want to know WTF is going on, you can cd to /etc (as root) and run `git log`. If someone made changes, but didn't commit them, it's easy to check with `git diff`. You can also keep track of who made what changes too. This can be done with any directory, of course. Really works only with text files. If there's binaries in the sub dirs, you can add them to .gitignore or just never `git add` them. To blow out the whole git repo just `rm -r /etc/.git` and you can start fresh. Check `git status` often too (in /etc dir). If you really want to go gung ho managing lots of systems configurations, you could check out puppet (I've never used it, but looks good): http://projects.reductivelabs.com/projects/puppet Thanks, -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
builder: gzip: stdin: invalid compressed data--crc error
Any idea what does this mean? The package built fine for armel.. https://garage.maemo.org/builder/fremantle/mafw-lastfm_0.0.3-1/i386.root.log.FAILED.txt Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: builder: gzip: stdin: invalid compressed data--crc error
Just try it again, some problems with the builder. I had them some days ago. Am Samstag, den 09.01.2010, 23:14 +0200 schrieb Claudio Saavedra: Any idea what does this mean? The package built fine for armel.. https://garage.maemo.org/builder/fremantle/mafw-lastfm_0.0.3-1/i386.root.log.FAILED.txt Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and pygst development only on device?
The name of the package you're looking for (Python bindings for GStreamer) is python-gst0.10 [1]. [1] http://maemo.org/packages/view/python-gst0.10 On Sat, Jan 9, 2010 at 5:42 AM, Klaus Rotter kl...@rotters.de wrote: Hello, yesterday I tried to dig a little bit into python and gstreamer development. I downloaded the source of the mediaplayer panucci and wanted to run it inside scratchbox - without luck. I didn't found the package containing pygst. The python developer howto suggests developing on the device - is this (more or less) the only way to go? Or did I miss something? Yours, Klaus -- Klaus Rotter * klaus at rotters dot de * www.rotters.de ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- __ Bruno Araújo, MSc openBossa Labs - Instituto Nokia de Tecnologia Manaus, Brazil Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
