Re: Location services not available?
Hi Marco, Marco Tabini wrote: > I am just getting start working with Maemo; I have followed the > instructions and set up my development environment (at least, I > _think_ I did) using the 4.1.1 SDK, and I was trying to access the > liblocation functionality, but without much success. The location > libraries do not actually seem to be there, and I wonder whether I > should be apt-getting them through some metapackage. > > I looked through the docs and the mailing lists, and tried googling > for this problem, and the closest I got to my problem was a note in a > bug report [1], but otherwise no joy. The location stuff above gpsd is closed source and will not be installed by default. IIRC you need to answer yes in the installer when it asks about closed Nokia binaries, and later install "maemo-explicit" meta package inside a scratchbox target. - Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gtk Dialog box causing application to crash
Arvind1 K wrote:
>
> Hi All,
>
> I'm facing a strange problem while using GTK+ Dialog box
> I've used two dialogs one in IF and other in ELSE
>
> if (some condition)
> {
> GtkWidget *dialog1 = gtk_message_dialog_new (main_window,
> GTK_DIALOG_DESTROY_WITH_PARENT,
> GTK_MESSAGE_QUESTION,
> GTK_BUTTONS_YES_NO,
> "Send file to server %s?",
> filename);
> result = gtk_dialog_run (GTK_DIALOG (dialog1));
> gtk_widget_destroy (dialog1);
> }
>
> else
> {
> GtkWidget *dialog2 = gtk_message_dialog_new (main_window,
> GTK_DIALOG_DESTROY_WITH_PARENT,
> GTK_MESSAGE_QUESTION,
> GTK_BUTTONS_YES_NO,
> "Download file %s?",
> filename);
> result = gtk_dialog_run (GTK_DIALOG (dialog2));
> gtk_widget_destroy (dialog2);
> }
>
>
> However if I use just a single dialog box at a time, everything works fine.
> I've used gdk_threads_enter() and gdk_threads_leave() whereever
> possible. these dialog boxes are created on 'select' event of CList so i
> cannot use gdk_threads_enter() and gdk_threads_leave().
>
> I need to have few more dialog boxes, but using only 2 is causing
> problems of application crash.
> Can anybody address this issue?
I didn't really get what the actual problem here is, but some advice
that might help:
* Unless you really, really know that you need to use threads, you
probably don't... using threads to get basic UI working is almost
certainly a bad idea.
* gtk_dialog_run() makes the dialog modal, so you can't use several
dialogs at once. You'll have to connect to the "respose" signal and
and show the widget yourself.
HTH,
Jussi
--
Jussi Kukkonen <[EMAIL PROTECTED]>
OpenedHand Ltd <http://o-hand.com>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 as a home automation/monitoring remote
David Greaves wrote: > Jussi Kukkonen wrote: >> Mike Ferguson wrote: >>> Hi all. >>> >>> I think I'd like to try to use my N800 as a remote terminal > Not a server, right? > >> Have you considered Universal Plug and Play (UPnP)? Using a defined >> protocol and a nice library should simplify the implementation details >> quite a bit: someone else has already figured out how to deal with >> signals, multiple clients, etc... As an additional bonus anything you >> write would be compatible with other UPnP products and software, at >> least if your plans match any of the existing UPnP device/service >> standards: "Lighting Controls", "Security Camera" and "HVAC" should be >> interesting device categories to you. >> >> http://en.wikipedia.org/wiki/Universal_Plug_and_Play >> http://www.upnp.org/standardizeddcps/default.asp > > But would you want that on the N800? > > Surely uPnP would go on the HA server? (the one with the hardwires too) > The N800 should just be a client - then the server exposes a view on the > hardware (so, for example, it can control multiple actions like lights on, > curtains close). UPnP is basically a networking protocol that two or more devices use to communicate over. Obviously all of those devices need to implement the protocol, doesn't really matter if we're talking about a "client" (control point) or a device that provides services. - Jussi -- Jussi Kukkonen <[EMAIL PROTECTED]> OpenedHand Ltd <http://o-hand.com> ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 as a home automation/monitoring remote
Mike Ferguson wrote: > Hi all. > > I think I'd like to try to use my N800 as a remote terminal for home > automation/monitoring and would like some advice about whether I'm > thinking along the right lines. ... > My initial questions are: > > First off, does this whole idea seem OK? Any general thoughts or > advice? Hi Mike, Have you considered Universal Plug and Play (UPnP)? Using a defined protocol and a nice library should simplify the implementation details quite a bit: someone else has already figured out how to deal with signals, multiple clients, etc... As an additional bonus anything you write would be compatible with other UPnP products and software, at least if your plans match any of the existing UPnP device/service standards: "Lighting Controls", "Security Camera" and "HVAC" should be interesting device categories to you. http://en.wikipedia.org/wiki/Universal_Plug_and_Play http://www.upnp.org/standardizeddcps/default.asp If UPnP as an idea sounds good, take a look at GUPnP: It's an object-oriented open source framework for creating UPnP devices and control points. The server tutorial actually implements a UPnP controlled light, so should be interesting to you: http://gupnp.org/ http://gupnp.org/docs/gupnp/ Oh, and if C feels unpleasant: I'm just about to release Vala bindings to GUPnP, so you might be able to skip the unpleasantness (Vala is still evolving though, so don't jump in head first). http://live.gnome.org/Vala/ If any of the above made sense to you, join the gupnp mailing list and send your ideas, I'm sure you'll get feedback. - Jussi -- Jussi Kukkonen <[EMAIL PROTECTED]> OpenedHand Ltd <http://o-hand.com> ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
Niels Breet wrote: > Hi all, > > Here is my first suggestion to clean up the complete mess we have at the > moment when it comes to package categories in the maemo extras repository. > There is no official list of categories, which has brought us to state > we are in now. > > We have these nice categories for example: 'Boingo', 'Canola'. Those should > never be a category by themselves. We also have a lot of duplicates like > 'cli' ,'Commandline' and 'Web','www' and 'Utilities','utils'. I agree, but apparently many do not. You may remember I posted about this a few months ago: In addition to complaining I also filed dozens of bugs in various places. A few packages were fixed as a result (thanks to all the maintainers who did this), but during the same period many more broken packages appeared... The only visible result of my work: We now know that any guidelines on this category issue must be enforced, maintainers will not follow them otherwise. I would really hope the maintainers who oppose these category ideas step up now -- I know they exist since several of my bugs were marked as WONTFIX or just left unanswered. I've asked them to take their issues to this list, but this has not really happened AFAICT. An example reply from Canola bug database: * Eduardo Lima: This specific section was created with the idea in mind that we would have lots of plugins (not related to multimedia), themes and other packages such as i18n and we did not know how to label them. The application manager itself is flexible enough to let us create these specific sections so we did it. Eduardos concern about the hypothetical mass of packages is probably a real one but his solution (a category per application) makes the categories useless, IMO. > I also would like your feedback on this idea: > "For diablo we only accept packages in the extras/extras-devel > repositories when they have a valid category." Approve with comments: the i18n/plugin issue must be resolved, but I don't see it as show-stopper for diablo. Also, fixing categories probably cannot fix the underlying AM usability problem completely: debtags or something like it may well be needed additionally (I see Marius just commented on this): This should be taken into account when planning. Jussi -- Jussi Kukkonen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem compiling Hildon Desktop Apps How-To
Alias Node wrote: > I'm having trouble compiling the example code from the Hildon Desktop > Apps How-to at: > > http://maemo.org/development/documentation/how-tos/4-x/writing_hildon_desktop_plug-ins_for_maemo.html > > Following the instructions and running: >dpkg-buildpackage -rfakeroot > > I get the following error in the config: ># Add here commands to configure the package. >CFLAGS="-Wall -g -O2" ./configure --prefix=/usr --disable-static >configure: error: cannot find install-sh or install.sh in . ./.. ./../.. >make: *** [configure-stamp] Error 1 > There doesn't seem to be anything named "install" in the tar file. > > Any suggestions? > run ./autogen.sh to bootstrap the source. In my opinion this should be done automatically by debian/rules but apparently isn't (at the very least README should mention it). Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: long name package problem
Marcin Juszkiewicz wrote: > This does not have sense indeed. But AppManager is closed aplication so > workarounds have more chances to be done then fixing. http://hildon-app-mgr.garage.maemo.org/ Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement for maemo Eclipse Integration version 0.9 (Beta)
[EMAIL PROTECTED] wrote:
> Maemo team is happy to announce beta release of maemo Eclipse
> Integration. This beta version has been released to get feedback from
> maemo community before final release.
That looks pretty nice... will test soonish. In the mean time, a couple
of comments:
First, I can't help commenting on the Pluthon and Esbox websites. Ajax
may have its place, but breaking the back button on a normal web page is
a big no-no in my books (just try the top menus).
Second, I've been meaning to file a bug report on maemo-pc-connectivity
for a couple of days, but didn't know where [1]. Is there a bugzilla
component or a garage project?
And third, here's the bug:
> Maemo PC Connectivity components can be installed from maemo extras
> repository. e.g. install maemo-pc-connectivity version 0.1 package to
> the Internet Tablet.
Your package does not comply with packaging guidelines, specifically the
the part about Section-fields [2] and so is part of the problem that
makes Application Manager categories unusable [3]. I suggest changing
the current section ("user/devel") to something that is in line with the
guidelines.
Note that I'm not saying we don't need a "development" category. I'm
saying you should propose new categories on the list before using them.
Thanks,
Jussi
1: apologies if I actually have filed this somewehere already. I've
filed more than a dozen bugs on the same subject during the last few
days, so my memory my have failed.
2:
http://maemo.org/development/documentation/how-tos/4-x/making_application_packages.html#sections
3: http://www.mail-archive.com/[EMAIL PROTECTED]/msg08732.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
openssh (was Re: root password in OS 2008)
Basavaraj B wrote: > openssh does not work on N810 (might be built for OS2007) > Openssh is available from Extras repo for 2007 and 2008, and works fine on both systems. However, the .install-file on http://maemo.org/downloads/product/OS2008/openssh/ is missing the line for 2008. This probably threw you off. CCing Ed to make sure he sees this. HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Segmentation fault in callback functions - maemo 4.0
Jakov wrote: > Oops, installed the old deb file. Now I repack my app to new .deb file. > But I can't install with this file, the problem reported: > > > Unable to install testapp > Application packages missing: hildon-fm1 (>=1.14) > hildon-libs0 (>=0.14.11-1) > libdbus-1-2 (>=0.61) > - > > Does it mean N800 miss above packages? ITOS2008 / Maemo 4.0 does not have those packages, yes. See http://repository.maemo.org/stable/chinook/3.2_vs_4.0_content_comparison.html Maemo documentation will probably help with details, but I assume you'll want to use libdbus-1-3, hildon-1 and hildon-fm-2. HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to run an app (simply)
g wrote: > Is there a simple way of downloading and running an > application on Maemo2008? I tried copying a file and > simply double-clicking it, but no go. I then tried > using Xterm and using chmod to set excecution > permission, but it wouldn't let me. > > I was hoping there was a simpler method than having to > an instal package. It's not entirely clear what is an appropriate subject for this mailing list, but I'm fairly sure this is not a "maemo-developers" question. I'm not going to start arguing about what is "simple", but running copied executables is certainly possible. chmod may have failed because you're chmodding a file on the memory card: FAT does not support file attributes. HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox apt-get update problem
Juho I Valkonen wrote: > Failed to fetch > file:/home/maemo/maemo-sdk-nokia-binaries_4.0/dists/chinook/explicit/binary-i386/Packages.gz > File not found > Reading package lists... Done > W: Couldn't stat source package list file: chinook/explicit Packages > (/var/lib/apt/lists/_home_maemo_maemo-sdk-nokia-binaries%5f4.0_dists_chinook_explicit_binary-i386_Packages) > - stat (2 No such file or directory) > W: You may want to run apt-get update to correct these problems > E: Some index files failed to download, they have been ignored, or old ones > used instead. Have you maybe accidentally removed the local nokia binary-only repository? It was installed to ~/maemo-sdk-nokia-binaries_4.0/ (inside scratchbox) when you ran the SDK installer. running the binaries installer outside scratchbox should help if it is missing: http://repository.maemo.org/stable/chinook/maemo-sdk-nokia-binaries_4.0.sh See also http://tablets-dev.nokia.com/4.0/INSTALL.txt HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fullscreen and flash, new question
Frédéric Charrier wrote: > > 2) About the address field at the bottom of the screen, is there a way > to force it hidden without any user action ? By example, by changing an > option in a file ? Josh mentioned .browser already. I just wanted to add a piece of advice: Don't even think about modifying browser settings from your application. Your users will hate you for that. Embedding the mozilla engine is a better solution if you really want total control of the UI. Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras repository
Graham Cobb wrote: > As we sort out the repository mess and get more packages moved into extras > (and extras-devel) it would be useful to have any easy way to see what is in > those repositories. > Bug 2495: there should be a package search page (packages.maemo.org) https://bugs.maemo.org/show_bug.cgi?id=2495 It may not be the solution to all the problems you cited, but it would go a long way (and I assume the server software from packages.debian.org is available). Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Global Search
Thomas Viehmann wrote: > Hi, > > trying to follow the maemo tutorial[1], I have difficulties finding the > libogs-dev package. Could you give me a hint how to obtain it? > > Kind regards > > T. > > 1. > http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#ogs Maemo documentation never seems to mention when software packages are not actually part of (free) maemo, but Nokia binary packages. The chinook installation instuctions do cover installing the binary packages, even if it's a bit confusing in places. The installer script should have downloaded the packages to ~/maemo-sdk-nokia-binaries_4.0/ (inside scratchbox) and added the correct source line to /etc/apt/sources.list. After this it's just a matter of fakeroot apt-get update fakeroot apt-get install maemo-explicit HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Automake >1.8.5?
dmenns1 wrote: > I had successfully compiled 'libgphoto2' and 'gphoto2' from a tar/gz > package, but now I am attempting to go one step further by doing the > same thing using the SVN 'trunk' source. However, this requires that I > run the following command: > > autoreconf --install --symlink > > When I do so within my chinook scratchbox environment, I get the > following errors: > > configure.ac:15: require Automake 1.9, but have 1.8.5 > autoreconf2.50: automake failed with exit status: 1 scratchbox has several versions of automake, including 1.9. You can use them by setting environment variable SBOX_DEFAULT_AUTOMAKE (although there may be other ways too). This should work: export SBOX_DEFAULT_AUTOMAKE=1.9 Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: changing wallpaper
Damien Moore wrote: > is there an api or set of command line utilities for working with > background images on the device? i've noticed the image is specified in > home/user/.osso/hildon-desktop/home-background.conf > but if i change it, the image won't change until the device is reset. at > a minimum some way to force the update would do the job. You have the advantage of working with an open part of the platform... There seems to be a D-Bus service which I guess is not intended for this, but which you can maybe abuse: org.maemo.hildon.background_manager has method SetBackground. It's not documented, but looking at the source may help you out. https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-desktop/background-manager/background-manager.xml.in I assume you've seen the theming documentation: http://www.maemo.org/development/documentation/how-tos/4-x/customizing_maemo_and_creating_themes.html HTH, Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RFC: Proposal to solve multiple repository, poor QA situation
Andrew,
Thanks for the comprehensive proposal, nice to see some thought put into
this. I don't fully agree with you, though. Here are my objections:
* Proposal tries to solve two different problems: repository QA and
maintainer helper tools. Both are important, but solutions might not
be the same, and solution to one should not wait for solution to
the other.
* Signing and sources: a package should be signed by the person building
it. Otherwise the meaning ("I personally guarantee this package has
been built from these sources") is lost. Source packages should
definitely be included.
I'm not commenting on the maintainer helper tools and services here
(other than to say that the popcon idea is really good): they're no
doubt important, but I don't think they should be tied to repo QA --
both issues are complicated enough on their own.
About repository QA: I see these as the gatekeeper team tasks (in order
of importance):
* maintain a "Extras QA requirements" document (see e.g.
http://ftp-master.debian.org/REJECT-FAQ.html),
* communicate those requirements to maintainers and
* enforce the requirements if needed -- either check packages before
they're pushed to Extras or start with checking packages post-upload
None of these require much automated tools in the beginning (especially
if we get started with post-upload QA) -- I imagine the gatekeeper team
will only find out what they need by trying. Full testing coverage is
not needed either: the maintainers still have QA responsibility,
gatekeepers are just double-checking.
Some software will be needed when gatekeepers decide to start doing the
QA before new packages get to extras. The design of that package queue
should probably be left to whoever implements it (if something usable
does not exist already). As I see it, maintainers should upload to
garage.maemo.org and gatekeepers should "approve" on garage.maemo.org. I
don't see why other servers need to be involved, I assume Nokia is quite
willing to co-operate here.
> if Nokia are planning on any form of improvement to the extras
> process, based on the recent discussions, there is no point wasting
> time on this. Clarification of Nokia's position on this would be
> appreciated.
Yep. Mishas devel-mover is interesting and it would be good to know if
there's already some development going on regarding e.g. the package
queue we've talked about (or if Nokia may be willing to develop
something like that if the hypothetical gatekeeper team asks).
Jussi
--
Jussi Kukkonen
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where is the implementation of function hildon_home_window_get_type
Huang Gao wrote: > I am now looking into package Maemo-af-desktop, and some strange > points make me confused. For instance, hildon_home_window_get_type() > is declared as the object type of HOME_WINDOW: > >#define HILDON_TYPE_HOME_WINDOW > (hildon_home_window_get_type ()) > > However, this function is not implemented in this package, nor > can I find it in other any packages. > > Does anyone know what the mechanism behind this issue is? You'll probably find one of the G_DEFINE_* macros in the source file. That macro will expand to *_get_type() function. See GObject documentation: http://library.gnome.org/devel/gobject/unstable/gobject-Type-Information.html#G-DEFINE-TYPE:CAPS Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Function to check presents of WiFi connection
Michael Stepanov wrote: > Maybe you have some example of that functionality? Not of your exact case, no. The geoclue web service object does show you how to create the object and setup the signal callback (and there must be dozens of Garage projects with this functionality): http://gitweb.freedesktop.org/?p=geoclue.git;a=blob;f=backend/common/geoclue_web_service.c Take a look at the three first functions (inside "#ifdef HAVE_LIBCONIC"). Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Function to check presents of WiFi connection
Michael Stepanov wrote: > Hi, > > I'm not Maemo guru. So, that's why my question may sound stupid a bit. I > need to check WiFi connection before run my application. Is there some > function in the Maemo SDk to do that or it's better to use command line WiFi > utility? I assume you just want to know if there is an internet connection (not necessarily wifi)? If you are using C, libconic is the place you should be looking in: http://maemo.org/development/documentation/how-tos/3-x/howto_connectivity_guide_bora.html#LibConIC http://maemo.org/api_refs/3.0/connectivity/libconic/index.html If I remember correctly it goes like this (not exactly a one-liner): * create object with con_ic_connection_new() * connect to the connection event signal * run con_ic_connection_connect() with parameter CON_IC_CONNECT_FLAG_AUTOMATICALLY_TRIGGERED * your signal handler will get a en event that has connection status. If you want to constantly monitor changes instead of just checking once, set automatic-connection-events to true. IIRC one of the event objects also lets you check if the connection is a WLAN if you really are interested in that. HTH, -Jussi -- Jussi Kukkonen http://koti.welho.com/jkukkone/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dbus api for wlancond
nic wrote: > Hi Kalle, > > Thanks for the response. However I had looked at the source for > wlancond previously. In the source the strings for the DBUS api can't > be seen since they > are stored in header files (wlancond-dbus.h or wlancond.h) that aren't > included in the source osso-wlan. > > Do you know where these are? > > I saw a message by Patrik Flykt on this message > board saying these files were in fact in osso-wlan-dev. But this does not seem > to be in repository.maemo.org/ from what I could see. In that same discussion Kalle Valo promises to get back to the issue of missing header files (April 4th) :) Filed a bug: https://bugs.maemo.org/show_bug.cgi?id=1790 -- Jussi Kukkonen signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Browser source code?
Adilson Oliveira wrote: > Where can I find the source code for the browser released yesterday? > "svn checkout https://garage.maemo.org/svn/browser"; should work. -jussi signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Camera app video functions removed?
Andrew J. Barr wrote: > I went to use the (unfortunately closed-source) camera app today on > my N800 and it seems the ability to take video has been removed. What > was the reason for this and are there any replacements that have this > function? This has been discussed in maemo-users and in bugzilla already. The camera app you have is from Nokia (and it has never had video). The camera app you are thinking of is from the problematically named Garage project "camera". HTH, -jussi signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Some weird questions about speech2text, text2speech, GPS ...
Julius Luukko wrote: > gpsd is included in N800. Please see > > http://maemo.org/development/documentation/how-tos/3-x/howto_connectivity_guide_bora.html > http://maemo.org/community/wiki/howtousegpsframeworkinos2007/ > http://gpsd.berlios.de/ > > Please note, however, that there is an open bug > > https://bugs.maemo.org/show_bug.cgi?id=1621 > While triaging that bug I wrote a small test program. So, if you're interested in pretty much the shortest possible example of using gpsd and libgpsbt on maemo take a look at https://garage.maemo.org/plugins/scmsvn/viewcvs.php/gpstest/?root=geoclue You might also be interested in the geoinformation framework Geoclue (at least for future projects): http://www.freedesktop.org/wiki/Software/GeoClue https://garage.maemo.org/projects/geoclue/ HTH, Jussi signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Summer of Code update?
[EMAIL PROTECTED] wrote: > So please, could the students and mentors send a brief update about the > status of their projects? Sure. Geoclue progress so far: * Moved geoclue infrastructure to freedesktop.org (http://www.freedesktop.org/wiki/Software/GeoClue) * Got to know the geoclue code base. Did code cleanup, bug fixes (http://gitweb.freedesktop.org/?p=geoclue.git;a=summary) * Learned a _lot_ about packaging (thanks Inz for pointers). Debian packages are done, but not yet available. * Discussed features on the GeoClue mailing list, also prototyped some features (http://lists.freedesktop.org/mailman/listinfo/geoclue). I realize that I should have a pretty clear TODO list with date estimates that you could check, but the contents of the list have been evolving so far (as you can see if you read the mailing list)... I promise http://www.freedesktop.org/wiki/Software/GeoClue/SocPlan will have that checklist Real Soon Now. By the way, Google sent me the book "Producing Open Source Software" by Karl Fogel and I read it last week -- it was a lot better than I expected and has my endorsement: http://producingoss.com (available under Creative Commons BY-SA). -jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: about SoC organization reward
[EMAIL PROTECTED] wrote: > Using SoC money to sponsor trips to GUADEC sounds very good. The best > proposal (IMHO) I have heard so far. An open issue I failed to mention in the first post: As the rewards are linked to SoC project successes, we won't know what the actual amount is before autumn... Some possible solutions: * The sponsorships are defined as e.g. 1/4 of the total amount, whatever it ends up being * A philantrophic maemo-related commercial entity promises to sponsor the missing amount if a SoC project does not get finished. Anyway, if we're going to act on this, the time is _now_: booking flights at the last minute is mostly not a good idea. Quim, I assume you as the SoC program admin have the ball now? -Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
about SoC organization reward
Quim Gil wrote in his blog on April 14th: > One more thing: SoC organizations get also some money to run the > program. The only legal organization behind maemo is Nokia. For > obvious reasons, it doesn't make any sense that this company receives > a single SoC cent. I have been asking in maemo-developers for an > organization willing to receive this money, unsuccessfully. Do you > have a good idea? Let us know. Well, I was looking at the quite interesting GUADEC 2007 programme and thought how nice it would be to attend (and how impossible it is with my current budget)... So, here's my proposal: Give travel stipends upon request to maemo community members who'd like to go to a maemo-related conference during this year. A fixed amount per person, $400 or $500, would be easiest. GUADEC is probably the most wanted event and it is in July, so the stipend approvals should happen pretty fast. My off-the-cuff timeline: May 21-31: Discussion and a decision about this proposal June 7:Requests sent to whoever makes the decision June 14: Stipend receivers announced Practical details: The amount of money received from Google is 500 USD per completed SoC project (hopefully that's $2000) and it will be paid shortly after August 31, 2007. Open issues: who makes the decision about this? Links: * SoC FAQ about payments: http://code.google.com/support/bin/answer.py?answer=60322&topic=10731 * GUADEC http://www.guadec.org/ So, what do you think? -Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org update + call to bugzilla expertise
[EMAIL PROTECTED] wrote: > We are not happy with bugzilla closed. We simply don't want to expose > users email addresses. If someone knows a good and quick fix/patch > please share it. As soon as bugzilla is not showing email addresses we > will reopen it. Ok. A quick note on this: I don't know if you already run version 2.18 or newer, as the bugzilla doesn't advertize it... If the version you have is older than that, you should definitely look at the obfuscation feature introduced in that version. The obfuscation is very simple (replace "@" with "@"), but at least in the past it has been effective. The patch in bug 120030* is really short, so it's worth looking if it applies nicely to your version. Second point: at least Red Hat bugzilla** has a template that makes usernames appear as just text (without mailto link) when the user is anonymous. I'm not sure if this is available in upstream bugzilla code base. -jussi *) https://bugzilla.mozilla.org/show_bug.cgi?id=120030 Don't bother reading most of the comments -- 98% are not relevant, and the patch is simple. **) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org update + call to bugzilla expertise
[EMAIL PROTECTED] wrote: > - About maemo Bugzilla, the tool itself. We have upgraded the software > and integrated the design to the rest of the site. We have basically > closed the access to non-registered users to avoid spammers even if we > agree it's not the best option. I assume you don't mean bugzilla spammers -- as preventing anonymous searching and viewing doesn't really help there -- but e-mail spammers harvesting addresses from bugzilla? Personally I believe this is a bad solution for an issue tracking system: Although the fear of spam may prevent some people from submitting bugs, making the bugzilla practically invisible will probably do more damage (bugs won't show up in search results for example). The fact that new users may not know that their email address will be publicly viewable is a problem, but that can be fixed by adding a note to https://maemo.org/bugzilla/createaccount.cgi. As for older accounts... well, that milk's already spilled. ref: https://maemo.org/bugzilla/show_bug.cgi?id=1344 > We will integrate soon the users so same login will apply to the > core website, Garage and bugzilla. No integration is actually a good thing at the moment, as many garage accounts just do not work on the core website: now I can at least file bugs when things don't work. It would be nice to know if there is any progress on this (I'd like to work on the wiki). ref: https://maemo.org/bugzilla/show_bug.cgi?id=1152 - jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: SoC: 5 preliminary slots
P. Durante wrote: > On 4/12/07, Quim Gil <[EMAIL PROTECTED]> wrote: >> >> Now we need to talk about the project setup. A Garage project for every >> SoC project so everyone interested can join the discussion and follow >> the development? > > I tought this was the plan from the very beginning, no? > btw, the google soc FAQ states the code should be uploaded to > code.google.com, I don't know if they want all the development to take > place there (it's unlikely, tough) Uploading to code.google.com twice during the summer is enough. The only other requirement is that 'development must happen in the open', so Garage is fine. My proposal/plans are available at http://maemo.org/maemowiki/GeoClue (any improvements are welcome). Maybe the other soc-students could upload theirs also? I know there's still six weeks until the "official start" and some students may actually have busy schedules until that point, but it can't hurt to start communicating early... br, Jussi -- Jussi Kukkonen [EMAIL PROTECTED] jku in #maemo ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
RE: Final (?) list of SoC projects
Quim Gil wrote on monday: > We have received some projects after the deadline... Quim, Google extended the deadline some time last week -- the deadline's actually not passed yet. I submitted my GeoClue-proposal this afternoon and I'd appreciate it if my proposal is also taken into consideration (and I bet I'm not alone here...). -Jussi -- Jussi Kukkonen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] upgrading base packages from third party repositories
Hello, I finally managed to get ogg playback on my device, thanks to N770-Freak and the "Getting started with multimedia"-document at maemo.org. Now, I could upload the packages I put together out there (e.g. on Garage), but I'm wondering how upgrading Nokia-installed packages should be done. So the question: If I upload a gstreamer package with version number larger than the Nokia-provided-gstreamer has into the extras repository, the users of that repo would then install it on the next upgrade even if they hadn't installed a package that requires the new version of gstreamer, right? That does not sound like something I'd like -- Should I use another package name and a Conflicts-field? A slightly related followup: Any chance of getting a newer gstreamer package in the next OS update? TIA, -Jussi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] maemo/debian packaging tutorial (Helsinki, June 16. or 19.)
Hello all, Lars Wirzenius is organizing a debian packaging tutorial day in Helsinki. It'll be free and open to everyone. There will probably be a theory part and hands-on training -- take a look at the slides from his last tutorial, if you want a hint of the contents: http://liw.iki.fi/liw/talks/debian-packaging-tutorial.pdf Now, this is nice already but I was thinking: Why not include some maemo packaging in the same occasion? The timing is pretty much perfect considering that the new application installer will be released Real Soon Now... This is the deal: 1. If your interested in the debian packaging tutorial, let Lars ([EMAIL PROTECTED]) know ASAP, preferably by thursday -- you get to vote on the date too: friday, June 16. or monday, June 19. 2. If you're also interested in a maemo-specific addition, throw me a mail: [EMAIL PROTECTED] Note: the maemo part is _not_ organized yet, and I'm not promising anything. I will try to get someone from Nokia to talk either on the same day or maybe another day on the following week, if there is interest. (any Nokia packaging people reading this may also volunteer now ;) -- Jussi Kukkonen [EMAIL PROTECTED] 050-5637437 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] scratchbox installation (was: http://press.nokia.com:80/PR/200605/1051308_5.html)
Eero Tamminen wrote: > On Tue, May 16, 2006 at 03:55:48PM +0300, Tomi Ollila wrote: >>Also, the initial setup was so pain... > > Depends on what distro you're using. :-) > On Debian (or Ubuntu for that matter), it's just "apt-get install". This is only true if you disregard maemo installation instructions -- at least I have not found the recommended 0.9.8 versions available at the scratchbox.org repository. I wonder if there are any real problems with maemo and scratchbox 1.0.x? I haven't seen any so far... If no-one comes up with horror stories about using 1.0 for maemo development, maybe the recommendation could be upgraded -- it would make installation easier (damping the culture shock for new developers) and give everyone access to the new features*. How about it? *) Movial has changelogs, unlike some people :) http://www.scratchbox.org/download/scratchbox-1.0/changelog.html http://scratchbox.org/download/scratchbox-apophis/ -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
Murray Cumming wrote: > The Maemo community is alive, but not thriving as much as it could. This > is because the Nokia developers are so busy and are often unable to > respond to the simplest of requests for changes or information, and > often unable to even acknowledge that contributions have been accepted. > It's OK to be busy, so this isn't a personal attack on those developers. > It's a suggestion for how to take the weight off them. > > I think Nokia needs to assign a dedicated community liaison, full time > or part time, while still demanding that all developers are involved > with the community as much as possible. ... > Nokia will get a lot of the advantages of open source if they don't do > this, and the community will survive if they don't do this, but I think > the extra salary would be a good investment to get even more valuable > advantages. Good suggestion, I second this. There are probably other solutions too. Something that would go a long way is opening the development a little more: I've been really trying to follow what's happening in maemo development and have found it really difficult... * None of the development discussions/meetings/decisions seem to happen in public * The bugzilla doesn't seem to be actually used for bug tracking * I still don't even know who works on what The only way to follow anything seems to be maemo-commits. It could of course be that I'm just slow -- it's a large project, and I'm not that familiar with the components, after all. However, I have succesfully gotten familiar with other large projects before. This time I feel like I haven't progressed at all. I understand that keeping design docs in the wiki or having development discussions on public mailing lists or in IRC is more work and in some cases impossible. I also understand that some employees might not want to be 'in the public eye' and that some bugs need to be Nokia-only. Still, doing things in private is going to keep everyone else in the dark, and hinder community involvement... I fear one liaison won't help that. Best wishes to the developers -- don't burn yourselves on the release, we'll need you after that too :) -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] display problem
Ziqi He wrote: > Hi all: > I want to use Maemo as the GUI of my system, and the resolution of Maemo is > 800*480. The trouble I encountered is that my LCD is 320*240. How can I dl > with the problem? Can I display Maemo normally on my LCD? Hello, You have asked the same question three or four times. If someone had the answer you're looking for, he/she would probably have told you by now. To sum up the previous answers: * it's not possible just by a compile switch or something, currently Maemo is 800*480, period. * Making Maemo actually scalable is a big undertaking. Just making a new 320*240 version might be an easier job: Theme changes and modifications to statusbar are still definitely needed. My comments: Even if the OS itself worked, 95% of the apps won't -- Your resolution is only 20% of the maemo "standard". HTH, -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Application Catalog rewrite [was: Abuse on the ApplicationCatalog page]
Hi, Santeri Lindgren wrote: > As i proposed (might be a lot of typing errors), i propose that the > ApplicationCatalog -page, as other equivalents to this, Wip and > Wishlist. Should only be a list, maybe categorized more specifically. > > Making the list a really long, isn't very nice when using GPRS to browse > and search one app you know is in the page but you dont' remember the > homepage or something. > >> That way, once an app is added to the index page, the information on >> there does not need to be updated each time the detail page is >> updated. Makes it easier to maintain. > > > Yes, this is a good point, but also, if you make a detailed index page, > it gets cramped. > > If you want some details to the index page, something like: > > gategory > | app name| few centences nothing more > I've modified https://maemo.org/maemowiki/ApplicationCatalogMockup into a more minimal look, would that be an acceptable compromise? Go ahead and make the table continuous if you want, that would make the page more compact. I'm not sure it would enhance readability, though. >> Then each of those groups could be subdivided into functional groups >> (Network, PIM, etc.) like they are now. > > So, three pages? > > index -> group -> application. > Probably not what he meant. Currently they're on the same page, but under different headers. I think this approach is sensible (taking into account maintainability, ease of search and machine-readability Andrew mentioned). -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Application Catalog rewrite
Michael Wiktowy wrote: > I made a mockup of "All Maemo Applications" at > https://maemo.org/maemowiki/ApplicationCatalogMockup . Please comment > and/or modify the page. > > If there is going to be a more detailed page for each app, I would > replace the "Homepage" and "Download" links with a "Details" link > pointing to the more detailed application-specific page ... But this is the catch: some people want to update the info on their own web page (and want people to visit their page) and I think that's fair. I propose only creating application-specific pages when they're needed (when there's no outside resource) -- this also minimizes the work needed to keep the wiki up to date. > ... and a Status indicator to let people know if the app is a WIP, > Alpha, Beta, Stable release. I considered this, but I thought it too fine grained and subjective: Besides, we would already have "end-user ready" / "stable" / "WIP" indication implicitly with the different pages. > Two main groups of indicies should be "Maemo Applications" (apps that > run in the 770 itself) and "Maemo Support Applications" (apps that run > on a computer that connects to the 770 which has the primary purpose of > supporting the 770 in some way ... be it converting media, browser > plugins, sync tools) Support Apps on another page is a very good idea. -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Application Catalog rewrite [was: Abuse on the ApplicationCatalog page]
Tuomas Kuosmanen wrote: > What do you guys think of such a refactoring where the *main* > application catalog would contain software that has been "ported" a bit > further than just "wow, it runs! Here is a package to try out!" [ clip ] > I am thinking of a rough outline of a process what it takes to "fully" > port an application: > * basic "it works!" porting work to make it run, if changes are > even needed in the code itself > * packaging for the application installer (where to put it in the > menus, adding the dbus stuff to make the "starting foobar..." > -notifications work etc.. > * hildonizing the UI (menus, toolbars etc) > * Possibly rethinking the user interface even further to make it > work better in a tablet environment [*] > * Ideally working with the original maintainer (if not the same > person) to get maemo-specific changes integrated upstream, > ideally maintaining the "maemo port" in the same code tree as > the original to reduce forking and making sure the port "lives" > with the parent project if possible. > > Did I miss something? Does it make sense to you to have this kind of > "raised bar" for the main catalog? I think this is a very good idea, but it doesn't solve the problem of large pages: There are currently over 180 applications in ApplicationCatalog and ApplicationCatalogWip, and the total amount will only grow. If the current amount and structure of information for each application is preserved, there _will_ be monster pages that are difficult to edit and uncomfortable to even view on bandwidth and screen estate limited devices (which, I imagine, are quite common in the maemo.org reader base). The long-term solution is a https://addons.mozilla.org -like system, but I think we can still get by for some time with a wiki. I propose the following pages: * "All Maemo Applications" All usable applications can be listed here (including the ones above). The list has a strict format giving every application a few lines of space for a 3-sentence introduction and links. All other information should be moved to Application-specific wiki page or outside the wiki. * "Work-In-Progress Applications" All applications which are/have been worked on, but which are not ready for every-day use. Same format as above. * "Maemo best-of-breed end-user applications" (name subject to change) Applications should pass the requirements Tuomas suggested. Additionally the applications should be relevant to a large part of the user base: Having the possibility of installing a DNS server on the device is great, but I still don't think it should be on this list... The page could have about the same amount information per application as the current catalog. Large images, usage info, etc. should be moved to other, application specific pages, though. This page could follow the style of the other Catalogs, but have a longer introduction and a screenshot. I made a mockup of "All Maemo Applications" at https://maemo.org/maemowiki/ApplicationCatalogMockup . Please comment and/or modify the page. The work needed to change to the proposed setup: * Copy information from ApplicationCatalog and ApplicationCatalogWip to application specific pages (only when needed). * Create "All Maemo Applications" and "Work-In-Progress Applications" (just rewrite ApplicationCatalog and ApplicationCatalogWip in the proposed format). * Start the "Maemo best-of-breed end-user applications" page. The additional work needed to maintain the proposed setup: * Information in the best-of-breed list is partly overlapping with the all-applications list, and both must be kept updated. -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Abuse on the ApplicationCatalog page
Hi Ted, Could you set your mail program to use some kind of quoting, like ">"? Reading your response is quite difficult. Ted Teah wrote: > If you download the trial and extract the software in the installer run > stings | grep copyright on the dll's and you will see results for HP, > reference to the GPL and ffmpeg. For any one this is to complex for I > will send you the results of these commands. I don't think that maemo > should encourage the violation of the license which is the foundation > for the FOSS world. > ffmpeg itself is totally LGPL. So, using unmodified ffmpeg library in a proprietary application, without releasing any source, is fine. Of course this doesn't mean there aren't other license problems with the "Nokia" Media Studio, but let's be sure before accusing anyone... -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building maemo from cvs
[EMAIL PROTECTED] wrote: > Yup. We've been little by little moving components to open > development in the stage svn but still not everything required > to build Maemo (or even the HAF) from source (at the most > current releases) is available. There's still some way to go. > > We've been considering and experimenting with various options for > adapting and opening up our internal development processes to > allow the community to follow the bleeding edge and get involved. > We realize that this is a serious barrier making it too hard for > people to get involved now, the regular stable Maemo releases > are not sufficient. Access to the source code in development is > obviously a key part of that. But that's not enough. People also > need bleeding-edge (unstable) packages in sync with the source on > svn, in a repository they can track with apt, and much more. I'd like to specifically mention the public bugzilla as something that could be improved. At the moment it more resembles a customer feedback channel than a real tool that could be used to follow "the lifespan of a bug/enhancement". This is another hindrance to getting familiar with the development. > On a related issue, I've been for some time tracking the move > to open development of the HAF through a build bot working > (mostly) from publicly available sources, in order to identify > and address the gaps. I'll post some info on that soon. Great, looking forward to it. On a somewhat related note: Would it be a bad idea if the maemo-commits mailing list posts included the full diff? Following the changes via the list is currently a little tedious since it requires constantly changing from email-app to browser and back... -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building maemo from cvs
Koen Kooi wrote: > There is a .html file somewhere in stage.maemo.org with list the modules > + version present in the sdk and fiasco images, which would be real help > for filling in 1.0. Does anyone remember that URL? I believe you mean http://repository.maemo.org/stable/1.1/package_reference.html -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Hi...Please clarify my doubt
Crazy Boy wrote: > I am new for this group. Recently, I got Nokia 770 Internet tablet. Now, > I am using SuSe Linux 9.3 in my system. Just, I want to display "Hello > World" in my Nokia 770 device, which is developed in GTK (As > recommonded). How can I port the "hello world" program into my device. > Can you please tell me the step by step procedure to solve my problem. > This is very urgent. I will be waiting for your reply. For urgent cases I recommend using a search engine (e.g. with keywords "maemo" "hello world" or "maemo" "tutorial"). This will lead you to http://www.maemo.org/platform/docs/howtos/howto_making_an_application_package.html and http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html, respectively. HTH, -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL application compile problem
Michael wrote: > Hi, > > I try to compile an existing SDL application for Nokia770. I setup a > development environment as it's described in Maemo doc. The compilation > breaks with error > >SDL_ttf.h: No such file or directory > > Could somebody explain me how to install package SDL_ttf under scratchbox. > > Thank in advanced. > You probably do not have the -dev-library installed or you're not telling the compiler where your header files are. 1. If you're missing sdl-ttf or sdl-ttf-dev, try installing the .debs from indt.org* with dpkg or compile them yourself (this is not difficult IIRC). If you compile, your best bet is to use debian sources and do "dpkg-buildpackage" -- that way you can still install the libraries with dpkg. 2. If you have them already, add "-I/usr/include/SDL/" to your compile options *) http://www.indt.org.br/maemo/repository/pool/main/s/sdl-ttf/ HTH, -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] home applet styling
Hello, I'm playing with home applets and trying to get the same widget styling that the Nokia-provided applets use, with no luck. Looking at the applets mentioned in the Wiki, it seems I'm not the only one (or maybe other are just going for the simplistic style, dunno). Gtkrc says that I need to have a widget "hildon-home-applet-title-frame" inside widget "hildon-home-applet", or at least that's how I read it**: --- widget "*.hildon-home-applet" style "osso-home-applet" widget "*.hildon-home-applet.*hildon-home-applet-title-frame" \ style "osso-home-applet-title-frame" --- Now, I am not a serious GTK hacker by any standard, but I've got the impression that simply setting the name property of a GtkWidget should apply the style... I'm just not succeeding with that. Should I be using some specific widgets (I've tried combinations of boxes and frames)? Could someone kindly either: a) Show me where I'm wrong in the above b) post the few lines of code that create the needed widgets in hildon_home_applet_lib_initialize? Thanks for any input, -- Jussi Kukkonen <[EMAIL PROTECTED]> **) thanks to whoever helped me with this in #maemo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] dpkg blues
On Tue, 2006-01-10 at 22:58 -0500, Vladislav Grinchenko wrote: > Hi, > > I am trying to build arm debian package of libsigc++ installable > on nokia 770. dpkg-buildpackage builds it just fine: ... > However, in order for me to use AppInstaller, I have to make it > dependable on pseudo-package maemo: --- > However, installing it both on 770 and in scratchbox SDK_ARM fails > bitterly: ... > Can someone explain to me why I get this error? > > failed to chroot to `/var/lib/install' > It's been two weeks, but in case you're still wondering about this: You probably have maintainer scripts (eg. prerm, postinst) in your package. Those are not allowed with app-installer-tool, and may prevent the package from being correctly installed and uninstalled. There is a separate how-to about packaging: http://maemo.org/platform/docs/howtos/howto_making_an_application_package.html HTH, -- Jussi Kukkonen ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia 770 thinks my MMC card is corrupted
On Fri, 2006-01-13 at 18:07 +0100, Israel Herraiz wrote: > > > Also, I can mount /media/mmc1 in the device and look inside with a > terminal. In fact, I copied everything from the card to my computer > and > all the files are right. > > So MMC card seems to be right. > > If I try to format it with the File Manager, it tells me that "No card > is inserted". As I can mount the card, it does not seem to be a > hardware problem (it worked fine before the upgrade). I had very similar symptoms -- the mmc wouldn't mount when inserted, but sometimes would from terminal -- In the end it did turn out to be a hardware problem (sort of). Before sending the device to Nokia, try swiping the MMC contacts vigorously with a clean cloth. Someone at #maemo also suggested using contact spray, but the swiping did it for me. HTH, -- Jussi Kukkonen ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
