Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? As an approximation, I did run the example googletalk VOIP/IM commandline client shipped with google's libjingle and when connected to google talk and having buddylist loaded with no VOIP call going on, it took some 2.5Megs on ARM as resident size. Rough estimate I know, but gives some idea about the memory requirements of an IM running without GUI. To eliminate the process overhead, one could link the libjingle with a StatusBar plugin. Then the parts of the IM that are always running, would run in the same process with the desktop. :-) Of course it could then also crash the desktop too... But in this case one could use the plugin to show dialogs on incoming messages/calls etc. Then when needed, just launch the actual GUI. Might work, but does not have a beautifull architecture as your idea about a backend running. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, you want to write a power savvy application, then. Few basic advices, which are also useful from a performance point of view (sorry if i'm stating the obvious but there's really no trick involved): -avoid polling: polling is generally bad, it's useful only for very tight loops that usually are not involved when writing apps -avoid busy looping (see polling): a significant amount of power is saved only when the processor is really idle, therefore ever call to sleep functions is fine, when you need to wait for something. If it's an asynchronous event that you are waiting for, then you can probably execute some sort of blocking call that will effectively prevent execution of your app until the data it's waiting for is really available -don't perform unnecessary activity: if the screen is blank, there is no need to update it, if you can manage to quickly redraw it when it's unblanked; however you can surely stops animations effects, such as glowing blinking and similar -don't abuse of connectivity resources like bt or wlan I hope this few points will help you br, igor On Tue, 2005-12-20 at 00:28 -0500, ext Peter Kahle wrote: > Hi, > > I'm new to Maemo, and to developing for small/embedded devices in > general. I'm trying to wrap my head around the whole concept, > especially the 'killable' apps that Maemo enables. I'm trying to > figure how long-running but mostly ignored apps like IM clients fit > into the whole picture. Sure, you can just mark them killable=false, > but that seems inefficient. So I'd like someone to tell me what's > wrong with the following scenario: > > Instant Messaging Application, designed from the ground up for Maemo, > architected in 3 or 4 parts: > > Backend: No GUI but uses libosso, handles all the connection details, > buddy list, etc. Stores incoming IMs and uses auto-save to persist > them until they're seen. Auto-started on if-up if so configured, or > launched by dbus from the front end. killable=false. > > Frontend: Only GUI, receives dbus messages from backend and displays > them to user. Also handles management and configuration of the > accounts and buddy lists. killable=true. Launched by maemo-launcher, > if that saves memory/time. > > Statusbar and/or home applet: Displays some sign that there are (not) > new IM's that haven't been shown. launches frontend on click/ > doubleclick/whatever. > > So what am I missing? The most likely is that process overhead > overshadows the memory saved by only running the GUI portions when > needed. And the obvious complexity of the system. What else? > > Thanks, > > Peter > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Ideal way to develop a long-running app?
Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? Thanks, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Rhythmbox on Maemo
Hi guys finaly rhythmbox are runing on Nokia 770 for others information and download package, see http://tuxrecife.blogspot.com/. BR Renato Araujo (INdT) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building Maemo from scratch
Helo, Russell Geldmacher wrote: > So, as I'd assume, there are package-specific patches for Maemo? These > apply to the pristine tarballs I'm guessing? Where can one get these > patches? (Is that a dumb question showing I know nothing about OE?) well... you have two sorts of patches: The maemo source packages are Debian-style sources which sometimes contain patches to be applied before building the source. In addition you sometimes need patches to apply additional fixes to build the sources with OE. These patches are managed in OE, but so far OE doesn't have a mechanism to handle the patches included in the source package. Of course you can extract these patches and add them to OE manually, but it makes maintainance of it much more complicated. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Issues with using flasher utility on Linux and eventual solution
On Mon, Dec 19, 2005 at 10:23:52AM -0800, ext Aaron Levinson wrote: > 1. I turned of the 770 (switch off!). > 2. I plugged in the USB cable to the 770 and the computer. > 3. I turned on the 770 and held down the home key (to be more precise, > the hardware button that has the picture of a house on it). This worked > as described in the e-mail thread. > 4. I invoked flasher (as root) as follows: ./flasher --disable-rd-mode . > > And this worked! No more errors. A subsequent call to ./flasher --reboot > worked fine as well. I was able to repeat this process today, but it > seems that you have to be really quick with the home button press and then > really quick with issuing the flasher command. This technique may be > easier when already in RD mode. If the USB cable is connected when the device is powered up, there is approx. two-second timeout in waiting for flashing commands. If no flashing commands arrive during the time period, we start the booting process. If the home button is pressed while powering on, the timeout is removed. Looks like your problem is indeed because of the timeout. The timeout can also be removed by setting the "no-usb-timeout" R&D flag. Cheers, Juha ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Issues with using flasher utility on Linux and eventual solution
Yesterday, I spent some time trying to use flasher to flash the latest firmware, take the 770 into RD mode, and finally take the 770 out of RD mode. Please note that the latter step isn't really mentioned in the relevant Wiki entries, and it is probably advisable to turn off RD mode once the user is finished using RD mode. The first use of flasher, to flash the latest firmware, went flawlessly. However, the next attempt to use flasher, to take the 770 into RD mode, failed numerous times. Here are some of the messages that I saw: Suitable USB device not found, waiting USB device found found at bus 005, device address 046 NOLO_REQ_GET_STATUS: Cannot send after transport endpoint shutdown Device status query failed Suitable USB device not found, waiting USB device found found at bus 005, device address 051 NOLO_REQ_GET_STATUS: No such device Device status query failed Suitable USB device not found, waiting USB device found found at bus 005, device address 054 Error opening USB device: No such file or directory Suitable USB device not found, waiting USB device found found at bus 005, device address 055 Error setting alternate interface 2: Protocol error A search for the various error messages I encountered did not turn up on any of the maemo e-mail lists or on the Internet Tablet Talk forums, although some of them do turn up on in Google, having to do with USB. I was doing this on an FC2 system with updated components (I use it as a mythtv server), so it's possible that there were USB issues. This problem repeated over and over again, even after a reboot of the PC. I started to wonder if there were issues with the new firmware with respect to the flasher tool, as the first use of the flasher tool, when the firmware was at version 0.2005.45-7, went flawlessly. In addition, it appeared that even if I wanted to go back to the previous firmware, I was out of luck, because first, I didn't have the previous firmware and it doesn't seem to be available, and in addition, attempting to use flasher to reflash the latest firmware failed with the same errors. I ran apt-get update and apt-get dist-upgrade on the FC2 system to get the latest files. There were no new kernel updates. This didn't result in any changes with my flasher problems. I kept on trying to use flasher, and then the same steps that had been previously unsuccessful suddenly worked, and I was able to enter RD mode. I ran sudo gainroot and modified gainroot using vim to just invoke the shell. All right, two steps were complete, and it was time to turn off RD mode, but unfortunately, I found myself encountering the same issues. I started to suspect some sort of USB timing issue and that the first successful use of flasher was possibly a fluke and had nothing to do with the firmware version. At this point, I did yet another search through the maemo e-mail lists, and I discovered a thread that mentioned that if the home button is pressed and held at the beginning of the boot process, the boot process will be delayed until the button is released. So, I gave this a shot as follows: 1. I turned of the 770 (switch off!). 2. I plugged in the USB cable to the 770 and the computer. 3. I turned on the 770 and held down the home key (to be more precise, the hardware button that has the picture of a house on it). This worked as described in the e-mail thread. 4. I invoked flasher (as root) as follows: ./flasher --disable-rd-mode . And this worked! No more errors. A subsequent call to ./flasher --reboot worked fine as well. I was able to repeat this process today, but it seems that you have to be really quick with the home button press and then really quick with issuing the flasher command. This technique may be easier when already in RD mode. Anyway, I hope this has been helpful to some people out there, and it may be useful to include the new information in the relevant Wiki entries. Aaron Levinson ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] LDAP & 770
Mohsen Pahlevanzadeh wrote: > Dear all, > Does nokia 770 has LDAP for its phone-book?(import/export) > If it has import/export,which format? > yours, > Mohsen > Hi, what phone-book are you referring to? Secondly, questions like this should be sent to maemo-users list. This is a list about developing maemo itself. :) - Toni ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
On Mon, 2005-12-19 at 12:28 +0100, ext Erik Bågfors wrote: > > > And osso-applet-certman ? > > > > I don't know about osso-applet-certman. > > > > Since ./configure wants it, can you find out? :) I sent your request to the relevant people. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
> Does the email actually need the Certificate Applet at build-time? I > thought I only calls it during runtime with few parameters (?). The > applet sources are not published (now) AFAIK. > Yes, I removed the need for it in configure. Then it dies in smime_security.c where is needs cert-stuff... it looks like. So we still can't build it. /Erik ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Bluetooth headset - not really working?
Sorry, wrong hcidump file, that one wasn't verbose. This one is: HCI sniffer - Bluetooth packet analyzer ver 1.28< HCI Command: Read Voice Setting (0x03|0x0025) plen 0> HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 1 status 0x00 voice setting 0x0060 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:07:A4:03:33:33 ptype 0xcc18 rswitch 0x01 clkoffset 0x Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1> HCI Event: Link Key Request (0x17) plen 6 bdaddr 00:07:A4:03:33:33< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 bdaddr 00:07:A4:03:33:33 key 8F9AB53B0E669C0F7E324AA14A8DB535 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Reply (0x01|0x000b) ncmd 1 status 0x00 bdaddr 00:07:A4:03:33:33> HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 1 bdaddr 00:07:A4:03:33:33 type ACL encrypt 0x01 < ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 3 scid 0x0040< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4 handle 1 policy 0x0f Link policy: RSWITCH HOLD SNIFF PARK > HCI Event: Command Complete (0x0e) plen 6 Write Link Policy Settings (0x02|0x000d) ncmd 1 status 0x00 handle 1> HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 > ACL data: handle 1 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0048 scid 0x0040 result 1 status 2 Connection pending - Authorization pending> ACL data: handle 1 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0048 scid 0x0040 result 0 status 0 Connection successful< ACL data: handle 1 flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0048 flags 0x00 clen 4 MTU 1024 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 > ACL data: handle 1 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0 Success> ACL data: handle 1 flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4 MTU 1024 < ACL data: handle 1 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0048 flags 0x00 result 0 clen 0 Success< ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0048 len 4 [psm 3] RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 2> ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7 < ACL data: handle 1 flags 0x02 dlen 18 L2CAP(d): cid 0x0048 len 14 [psm 3] RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 dlci 2 frame_type 0 credit_flow 15 pri 7 ack_timer 0 frame_size 1019 max_retrans 0 credits 7> HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1> ACL data: handle 1 flags 0x02 dlen 18 L2CAP(d): cid 0x0040 len 14 [psm 3] RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8 dlci 2 frame_type 0 credit_flow 14 pri 7 ack_timer 0 frame_size 127 max_retrans 0 credits 0 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0048 len 4 [psm 3] RFCOMM(s): SABM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x59 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92 < ACL data: handle 1 flags 0x02 dlen 12 L2CAP(d): cid 0x0048 len 8 [psm 3] RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 0 b2 0 b3 0 len 0> ACL data: handle 1 flags 0x02 dlen 12 L2CAP(d): cid 0x0040 len 8 [psm 3] RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 0 b2 0 b3 0 len 0< ACL data: handle 1 flags 0x02 dlen 12 L2CAP(d): cid 0x0048 len 8 [psm 3] RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 0 b2 0 b3 0 len 0> HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 2 > ACL data: handle 1 flags 0x02 dlen 12 L2CAP(d): cid 0x0040 len 8 [psm 3] RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 0 b2 0 b3 0 len 0 < ACL data: handle 1 flags 0x02 dlen 9 L2CAP(d): cid 0x0048 len 5 [psm 3] RFCOMM(d): UIH: cr 1 dlci 2 pf 1 ilen 0 fcs 0x86 credits 33> HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1> ACL data: handle 1 flags 0x02 dlen 9 L2CAP(d): cid 0x0040 len 5 [psm 3] RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 15> HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 1 mode 0x02 interval 2048 Mode: Sniff< HCI Command: Add SCO Connection (0x01|0x0007) plen 4 handle 1 ptype 0x00e0 Packet type: HV1 HV2 HV3 > HCI Event: Command Status (0x0f) plen 4 Add SCO
Re: [maemo-developers] email source code available
> > > > So I tried to compile this, and it requires osso-ic.pc which I cannot > > > > find anywhere. I have osso-ic-lib installed and accordin to it, > > > > osso-ic is LGPL but I cannot find the source for it. It doesn't seam > > > > to be in the svn tree? > > > > > > You need osso-ic-dev, but for a reason unknown to me it's not included > > > in the SDK. I'll find out what happened and try to get it included. > > > Sorry about this. > > > > SDK people have now added the osso-ic-dev to maemo1.1rc7 repository. > > Here are the instructions how to install it: > > > > apt-get update; fakeroot apt-get install osso-ic-lib osso-ic-dev > > > > Thanks to the SDK team for the quick update. > > Good... now I get to > > checking for osso-applet-certman >= 0.0.23... Package > osso-applet-certman was not found in the pkg-config search path. > Perhaps you should add the directory containing `osso-applet-certman.pc' > to the PKG_CONFIG_PATH environment variable > No package 'osso-applet-certman' found > Does the email actually need the Certificate Applet at build-time? I thought I only calls it during runtime with few parameters (?). The applet sources are not published (now) AFAIK. Br, --jakub ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
2005/12/19, Kalle Valo <[EMAIL PROTECTED]>: > On Mon, 2005-12-19 at 11:42 +0200, ext Kalle Valo wrote: > > On Sun, 2005-12-18 at 17:50 +0100, Erik Bågfors wrote: > > > So I tried to compile this, and it requires osso-ic.pc which I cannot > > > find anywhere. I have osso-ic-lib installed and accordin to it, > > > osso-ic is LGPL but I cannot find the source for it. It doesn't seam > > > to be in the svn tree? > > > > You need osso-ic-dev, but for a reason unknown to me it's not included > > in the SDK. I'll find out what happened and try to get it included. > > Sorry about this. > > SDK people have now added the osso-ic-dev to maemo1.1rc7 repository. > Here are the instructions how to install it: > > apt-get update; fakeroot apt-get install osso-ic-lib osso-ic-dev > > Thanks to the SDK team for the quick update. Good... now I get to checking for osso-applet-certman >= 0.0.23... Package osso-applet-certman was not found in the pkg-config search path. Perhaps you should add the directory containing `osso-applet-certman.pc' to the PKG_CONFIG_PATH environment variable No package 'osso-applet-certman' found /Erik ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
On Mon, 2005-12-19 at 11:42 +0200, ext Kalle Valo wrote: > On Sun, 2005-12-18 at 17:50 +0100, Erik Bågfors wrote: > > So I tried to compile this, and it requires osso-ic.pc which I cannot > > find anywhere. I have osso-ic-lib installed and accordin to it, > > osso-ic is LGPL but I cannot find the source for it. It doesn't seam > > to be in the svn tree? > > You need osso-ic-dev, but for a reason unknown to me it's not included > in the SDK. I'll find out what happened and try to get it included. > Sorry about this. SDK people have now added the osso-ic-dev to maemo1.1rc7 repository. Here are the instructions how to install it: apt-get update; fakeroot apt-get install osso-ic-lib osso-ic-dev Thanks to the SDK team for the quick update. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
2005/12/19, Kalle Valo <[EMAIL PROTECTED]>: > On Mon, 2005-12-19 at 11:18 +0100, Erik Bågfors wrote: > > > BTW, osso-ic-lib and osso-ic-dev packages are LGPL but osso-ic is not. > > > > > > > And osso-applet-certman ? > > I don't know about osso-applet-certman. > Since ./configure wants it, can you find out? :) Regards, Erik ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
On Mon, 2005-12-19 at 11:18 +0100, Erik Bågfors wrote: > > BTW, osso-ic-lib and osso-ic-dev packages are LGPL but osso-ic is not. > > > > And osso-applet-certman ? I don't know about osso-applet-certman. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
2005/12/19, Kalle Valo <[EMAIL PROTECTED]>: > On Sun, 2005-12-18 at 17:50 +0100, Erik Bågfors wrote: > > So I tried to compile this, and it requires osso-ic.pc which I cannot > > find anywhere. I have osso-ic-lib installed and accordin to it, > > osso-ic is LGPL but I cannot find the source for it. It doesn't seam > > to be in the svn tree? > > You need osso-ic-dev, but for a reason unknown to me it's not included > in the SDK. I'll find out what happened and try to get it included. > Sorry about this. > > BTW, osso-ic-lib and osso-ic-dev packages are LGPL but osso-ic is not. > And osso-applet-certman ? /Eri ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] email source code available
On Sun, 2005-12-18 at 17:50 +0100, Erik Bågfors wrote: > So I tried to compile this, and it requires osso-ic.pc which I cannot > find anywhere. I have osso-ic-lib installed and accordin to it, > osso-ic is LGPL but I cannot find the source for it. It doesn't seam > to be in the svn tree? You need osso-ic-dev, but for a reason unknown to me it's not included in the SDK. I'll find out what happened and try to get it included. Sorry about this. BTW, osso-ic-lib and osso-ic-dev packages are LGPL but osso-ic is not. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
