Re: Autobuilder and compiling against MCE
On Wed, Dec 16, 2009 at 8:06 AM, Michael Cronenworth m...@cchtml.com wrote: I'm attempting to compile an app with some MCE defines for portrait mode on the fremantle autobuilder. It seems that the mce-dev package is not installed on the autobuilder[1][2]. Is there an alternative to MCE that I am not aware of? All of the Fremantle examples for portrait mode show includes to mce. I'm a little confused. mce-dev added to Build-Depends in debian/control? regards Philipp ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone see this?
On Wed, Dec 16, 2009 at 2:34 AM, Thomas Waelti twae...@gmail.com wrote: Not only did I see your post, but I can confirm your problem, as I have the same: My own emails sent to the list never arrive in my mailing list inboxes, even though I have the settings in the subscriper page set as you describe. GMail filters that out automatically. The listserv is working fine; its a gmail thing. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Commands for adjusting screen brightness for N810
On ons, 2009-12-16 at 07:13 +0100, ext Jey Han Lau wrote: Hi all, I know there's an built-in application for managing the display (brightness, etc), although I am curious if there are any commands (I am guessing it'll be D-BUS commands if there's any) to manipulate the screen brightness directly, or commands to manipulate all the display settings for that matter. If there's none, are there any ways run the built-in display program (at Control panel) via commands? The display brightness control panel uses GConf for its brightness setting. You can simply change the relevant GConf key and have the brightness change immediately. The relevant GConf key in question is: /system/osso/dsm/display/display_brightness and valid values are 1-5. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
Denis-Courmont Remi (Nokia-D/Helsinki) remi.denis-courm...@nokia.com writes: On Tuesday 15 December 2009 22:10:39 ext Jeremiah Foster, you wrote: * 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 One of the huge advantages of moving to debhelper 7 compat is that you can have your debian/rules files look like this: #!/usr/bin/make -f %: dh $@ Simple. You pass everything off to debhelper. That takes care of the packaging part, but not the building part or does it? It also takes care of building. Check the documentation of the Build system options in man debhelper and look into /usr/share/perl5/Debian/Debhelper/Buildsystem. The dh program itself is a simple sequencer that runs a score of dh_* utilities in the right order, including the new dh_auto_configure, dh_auto_build, and dh_auto_install. These dh_auto_* utiltities can recognize a number of buildsystems, like autotools, Makefile.PL, setup.py, etc. AFAICT, if you really want short and implicit rules, you could use CDBS. That works fine with any debhelper from version 4 and up. It's a matter of taste, I guess. I personally find cdbs impenetrable, what with the million variables that you need to set. Debhelper really doesn't need to be wrapped up to make it easy. (The main thing missing from debhelper IMO is better support for -dbg packages.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Find out Maemo version from script
Marius Gedminas wrote: On Tue, Dec 15, 2009 at 07:50:48PM +0100, Cornelius Hald wrote: I think I will use the osso-product-info command as this seems to be the best way for me to do it. With the other solutions I have some problems: * /etc/osso_software_version does not exist on my N900. * pkg-config is only for *-dev packages and does not exist (by default) on the N900. * Checking for the feature is not possible, as the feature is a bug in some preinstalled library and I don't know in which one. I need this check because I need to figure out whether or not this bug exists and if yes change a couple of files to work around it. So checking for the OSSO_PRODUCT_RELEASE_VERSION with the osso-product-info command should work for me. This sounds very interesting. Can you tell use what the bug is and what files you need to change for the workaround? It´s this one: https://bugs.maemo.org/show_bug.cgi?id=6263 So I´m changing the uri-action-defaults.list in my postinst script if the script is installed on the current Maemo5 version. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Issues with autobuilder x86 bison
Hi, I've some problem building jam into the autobuilder for X86... and I can't understand where is the problem. I'm able to build it for both architectures on my Maemo5 SDK. Bison looks to work fine in ARMEL but it fails with the following error in X86: /scratchbox/tools/bin/bison: I/O error Complete log is here [1]. Any hints? Thanks, Antonio [1] https://garage.maemo.org/builder/fremantle/ftjam_2.5.2-1.1/i386.build.log.FAILED.txt -- Stephen Leacockhttp://www.brainyquote.com/quotes/authors/s/stephen_leacock.html - I detest life-insurance agents: they always argue that I shall some day die, which is not so. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
GtkWidget's unmap-event not generated [was: overlaid buttons]
Hi,
I've got some code that creates an undecorated window of type
GTK_WINDOW_POPUP as a transient of my main window. I've accomplished
the look I needed in my application, but I can't figure out how to get
this window to go away when the application window is minimized.
Such as when you bring up the dashboard or the desktop.
On my Ubuntu system I can use code like the following:
gboolean overlay_unmap(GtkWidget *window, GdkEvent *event, gpointer data)
{
gtk_widget_hide((GtkWidget *)data);
return FALSE;
}
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
GtkWidget *overlay = gtk_window_new(GTK_WINDOW_POPUP);
gtk_window_set_transient_for(GTK_WINDOW(overlay), GTK_WINDOW(window));
g_signal_connect(window, unmap-event, G_CALLBACK(overlay_unmap), overlay);
But when I try this in Maemo 5 the unmap event is never generated. Is
there some alternative?
Thanks,
Kyle Cronan
On Sun, Dec 13, 2009 at 4:29 AM, kyle cronan k...@pbx.org wrote:
On Fri, Dec 11, 2009 at 3:28 AM, Cornelius Hald h...@icandy.de wrote:
What you do is, you basically create a new window without decorations
and with transparent background. On that window you draw using Cairo. So
you're not using standard widgets but you paint everything by your self.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkWidget's unmap-event not generated [was: overlaid buttons]
Hi Kyle,
it's not related to your problem, but be aware of this bug [1] when
considering the use cases for your widget.
In short: HildonAppMenu doesn't appear if there's a top level widget around.
[1] https://bugs.maemo.org/show_bug.cgi?id=6545
--
Luca Donaggio
On Wed, Dec 16, 2009 at 11:14 AM, kyle cronan k...@pbx.org wrote:
Hi,
I've got some code that creates an undecorated window of type
GTK_WINDOW_POPUP as a transient of my main window. I've accomplished
the look I needed in my application, but I can't figure out how to get
this window to go away when the application window is minimized.
Such as when you bring up the dashboard or the desktop.
On my Ubuntu system I can use code like the following:
gboolean overlay_unmap(GtkWidget *window, GdkEvent *event, gpointer data)
{
gtk_widget_hide((GtkWidget *)data);
return FALSE;
}
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
GtkWidget *overlay = gtk_window_new(GTK_WINDOW_POPUP);
gtk_window_set_transient_for(GTK_WINDOW(overlay), GTK_WINDOW(window));
g_signal_connect(window, unmap-event, G_CALLBACK(overlay_unmap),
overlay);
But when I try this in Maemo 5 the unmap event is never generated. Is
there some alternative?
Thanks,
Kyle Cronan
On Sun, Dec 13, 2009 at 4:29 AM, kyle cronan k...@pbx.org wrote:
On Fri, Dec 11, 2009 at 3:28 AM, Cornelius Hald h...@icandy.de wrote:
What you do is, you basically create a new window without decorations
and with transparent background. On that window you draw using Cairo. So
you're not using standard widgets but you paint everything by your self.
___
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: Commands for adjusting screen brightness for N810
David Weinehall wrote: The relevant GConf key in question is: /system/osso/dsm/display/display_brightness and valid values are 1-5. There is also a kind of hack used by advanced brightness applet. The system below (=dsme daemon) has finer granularity. Brignthess can be changed (as root user) via command chroot /mnt/initfs dsmetest -l n n = 0-255 The hardware itself has only 127 levels so for dsmetest you need to multiply by two. Also running dsmetest with no paremeter prints a help, you might find -d,-b,-x useful too. All this is valid for OS2008 only (N8x0). Also when playing with brightness on this level it is useful to disable ambient light sensor or it will change it. This can be done by removing filter-brightness-als from Module line in /etc/mce/mce.ini (this works for N900 too). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Issues with autobuilder x86 bison
2009/12/16 Antonio Aloisio antonio.aloi...@gmail.com: Hi, I've some problem building jam into the autobuilder for X86... and I can't understand where is the problem. I'm able to build it for both architectures on my Maemo5 SDK. Most probably you've installed bison in your environment from Fremantle SDK repo. If you remove it you can reproduce the failure. In this case bison from scratchbox (/scratchbox/tools/bin/bision) is used. Bison looks to work fine in ARMEL but it fails with the following error in X86: /scratchbox/tools/bin/bison: I/O error Complete log is here [1]. Any hints? Adding build dependency to bison version from sdk repo 'bison (= 1:1.875d-1osso2)' should help. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo CLI application icon (take 2)...
Hi everyone, I've updated the proposed CLI icon/badge and posted them here: http://samoff.com/random/maemo/term_icon/ You should also notice that there's an Application Manager sample of how the icon might be used as a badge over other, pre-existing icons. Feedback, as usual, is appreciated. Thanks, Tim P.S. I know that Graham wanted this to go to the -developers list, but I remember others wanting the discussion to stay here. Please let me know where it should go and I will forward and continue the discussion there. -- http://samoff.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo CLI application icon (take 2)...
Randy, Randall Arnold wrote: In one example I can't even see the underscore... Must be your old eyes. :p Tim -- http://samoff.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo 5 SDK install on non-Debian systems
Has anybody found instructions on how to install the Maemo 5 SDK on a non-Debian system? Having had three consecutive disasters upgrading with Ubuntu releases, I've given up on that distro and gone back to Mandriva. Trouble is, that's RPM based and even with DEB installed on it, doesn't really like .deb installs. So I need to be able to install some other way if I'm to update MySQL and Apache so they're packaged for the N900. -- Tony Green Ipswich, Suffolk, England www.beermad.org.uk/ www.suffolkcamra.co.uk/pubs/ My PGP public key: www.beermad.org.uk/cgi-bin/pgp.cgi * No Micro$oft products were used in the generation of this communication ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Issues with autobuilder x86 bison
Hi Ed, Thanks a lot. It worked out! ;D Regards, Antonio On Wed, Dec 16, 2009 at 2:41 PM, Ed Bartosh bart...@gmail.com wrote: 2009/12/16 Antonio Aloisio antonio.aloi...@gmail.com: Hi, I've some problem building jam into the autobuilder for X86... and I can't understand where is the problem. I'm able to build it for both architectures on my Maemo5 SDK. Most probably you've installed bison in your environment from Fremantle SDK repo. If you remove it you can reproduce the failure. In this case bison from scratchbox (/scratchbox/tools/bin/bision) is used. Bison looks to work fine in ARMEL but it fails with the following error in X86: /scratchbox/tools/bin/bison: I/O error Complete log is here [1]. Any hints? Adding build dependency to bison version from sdk repo 'bison (= 1:1.875d-1osso2)' should help. -- BR, Ed -- Marie von Ebner-Eschenbachhttp://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html - Even a stopped clock is right twice a day. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 SDK install on non-Debian systems
Max Barnes on 12/16/2009 11:32 AM wrote: Has anybody found instructions on how to install the Maemo 5 SDK on a non-Debian system? The host distribution does not matter. The packages are not installed into the host machine, but into the /scratchbox chroot'd environment. I am using Fedora 12 x86_64 as my host distribution without a problem. I have the SDK on two Fedora machines now, in fact. I used the Python graphical installer on both occasions. ___ 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
Hello! I believe we can improve on this area: to have safer and optimized Do we have a problem? Does testing applications instead of enablers make us let problems go into extras that do not pass the extras criteria? 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 Yes, this might be a problem. Could we test this automatically by checking missing symbols of binaries against offered symbols of libraries (for hard linking errors). Not hard linking errors can only be detected by testing all depending applications? * 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. Yes. There were discussions in the past how to handle, manage, maintain libraries that have multiple dependend applications with different maintainers. I do not remember that a solution was found (besides talk to each other, make a bug) * 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. IMHO that does not solve above problems and such strong requirement will possibly keep a number of libraries ot of the repository (including mine). Possibly even once that are part of the platform? In fcat to solve above problems this would mean that I do not have to test my application but I must test in my application if all functions I call from foreign code is available and does what I expect it does. Of course if I would write tests for my library they would always pass and still could break applications anytime. If I drop functions I will drop the test, too. If I change the meaning of an function I will adapt the test, too. Same goes for applications. You want to test interactions between applications and libraries so you must have test cases for this interaction. And while I apreciate automatic test suits I and most other small problems cannot manage this because of lack of resources. I likely find 90% of my bugs using application functionality tests much faster (doing server development in my job things are different...). * 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. 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? * 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. * Promote usage of ABI check tools. Yes. As mentioned above. 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 -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Intercept camera slider open event to default camera app? (N900)
On Mon, 2009-12-14 at 23:32 +0100, Thomas Waelti wrote: Can anybody tell how an app can intercept the camera slider opening event, so that it does NOT call the default camera app? ... Sadly, currently the only way to stop the default camera app for getting such events would be to actually stop the camera app as I think it gets the lens cover status from HAL (and I suppose you will not stop the HAL service for that ;) ). The easiest way right now would be to run the command (as root, I suppose): $ dsmetool -k /usr/bin/camera-ui Once you are done, you can start the camera app again with: $ dsmetool -t /usr/bin/camera-ui I hope this helps. Br. -- Andrés Gómez García Computer Science Engineer Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto:ago...@igalia.com http://people.igalia.com/agomez IGALIA, S.L. http://www.igalia.com signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Changing available resolutions in camera app
On Mon, 2009-11-30 at 09:40 +0100, Cornelius Hald wrote: On Mon, 2009-11-30 at 10:25 +0200, Alexander Bokovoy wrote: Hi, On Mon, Nov 30, 2009 at 10:11 AM, Cornelius Hald h...@icandy.de wrote: Hi, by default the N900 camera application offers two resolutions. One with aspect ratio 16:10 and one with 4:3. I would like to get an aspect ratio of 3:2 (classic 35mm film). Did anyone find a config file or gconf key to change that? It's not super super important, but if you have informations I would be very happy to hear them. Currently supported resolutions by Camera UI are hardcoded in gdigicam. See ext/gst-camerabin/gdigicam-camerabin.c around line 53 onwards. Thank you, I found it. Along with the message FIXME: This should be customizable somehow :) ... Yes, well, you know, there is no time for everything ... We have it in the roadmap but we are open to contributions, though ;) Br. -- Andrés Gómez García Computer Science Engineer Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto:ago...@igalia.com http://people.igalia.com/agomez IGALIA, S.L. http://www.igalia.com signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
powertop missing from USA firmware
I'm on the N900 USA firmware. powertop is not on the device anywhere. find / -name 'powertop' does not return any results. I notice other users of the Global version of the firmware have it. I would make a package for Extras, but the autobuilder prevents it since it already exists in it's known list of binaries. How do I go about reporting this to Nokia to be fixed? I didn't seem to find any product or component that would match this sort of request. Thanks, Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: powertop missing from USA firmware
On 12/16/2009 10:51 PM, Michael Cronenworth wrote: I'm on the N900 USA firmware. powertop is not on the device anywhere. find / -name 'powertop' does not return any results. I notice other users of the Global version of the firmware have it. I would make a package for Extras, but the autobuilder prevents it since it already exists in it's known list of binaries. How do I go about reporting this to Nokia to be fixed? I didn't seem to find any product or component that would match this sort of request. P.S. Talk thread: http://talk.maemo.org/showthread.php?t=37102 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 SDK install on non-Debian systems
On 12/16/2009 11:21 PM, Sri wrote: Hi Michael. I am trying to install scratchbox maemo SDK using the scripts provided from maemo but its not getting continued as my machine is x86_64 and script is asking for i386 base. do you have any procedure to configure scratchbox maemo sdk on x86_64 environment? You must have a matching i386 lib setup for the SDK to work under x86_64. The scratchbox binaries are 32-bit only. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
