Unable to write to the serial port /dev/ttyS0 using QextSerialPort on Maemo device

2010-07-02 Thread Suyash.Kumar
Hi,

I am writing a simple Qt on Maemo application for serial communication between 
device and PC for which I am using QextSerialPort 1.2 library to write on the 
/dev/ttyS0 port so that it could be read by the COM1 port on my windows machine 
connected to the device via USB cable.

I am able to create the .so libraries and using the QESPTA example provided in 
QextSerialPort to write on the first serial port. Initially I was trying to 
write on the COM1 port and the device was creating a file named COM1 and 
writing everything there. Then I found the naming convention used for the first 
port on Linux/Maemo is /dev/ttyS0 and changed the port ame accordingly. but 
this is returning error when the API for writing on port is used although the 
API to open the port is returning Success.

Port Settings  open/ write calls (Code Snippet):
port = new QextSerialPort(/dev/ttyS0);
port-setBaudRate(BAUD9600);
port-setFlowControl(FLOW_HARDWARE);
port-setParity(PAR_NONE);
port-setDataBits(DATA_8);
port-setStopBits(STOP_1);
//set timeouts to 500 ms
port-setTimeout(500);

port-open(QIODevice::ReadWrite | QIODevice::Unbuffered);
// internally calls QFile-Open(..) as shown below and returs success
if (Posix_File-open(QIODevice::ReadWrite|QIODevice::Unbuffered)) {
  qDebug(Opened File succesfully);
  /*set open mode*/
  QIODevice::open(mode);

int i = port-write((message-text()).toAscii(),(message-text()).length());
qDebug(trasmitted : %d, i);
// internally calls QIODevice::Write(...) returns -1 as error

Has anyone used QextSerialPort before to write on the serial port on Maemo 
device and does it works? Also, please suggest the possible reason for 
QIODevice returning error even when the port opens successfully?

Regards,
Suyash.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Unable to write to the serial port /dev/ttyS0 using QextSerialPort on Maemo device

2010-07-02 Thread Rémi Denis-Courmont
On Friday 02 July 2010 10:15:25 ext suyash.ku...@tieto.com, you wrote:
 Hi,
 
 I am writing a simple Qt on Maemo application for serial communication
 between device and PC for which I am using QextSerialPort 1.2 library to
 write on the /dev/ttyS0 port so that it could be read by the COM1 port on
 my windows machine connected to the device via USB cable.

You do realize that /dev/ttyS0 is the device for a physical serial port on 
Linux. Unless you have your Maemo device on a development jig, your device 
does not have a serial port. So no wonder that it is not working.

-- 
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Suspended process

2010-07-02 Thread Kimmo Hämäläinen
On Thu, 2010-07-01 at 21:54 +0200, ext Demetris wrote:
 Hi all,
 
 the same (shell-based) app running on N810 under Maemo5 gets suspended on
 the N900 under Maemo5. Any idea why it would be so - I am running cvm
 (J2ME-CDC PhoneME for java runtime):
 
 Process #1667 received signal 4, suspending
 [1] + Stopped (signal)   /home/user/dgg/cdc/bin/cvm
 
 If I keep typing fg to bring the job to the foreground, it executes a 
 few more statements
 and then it gets suspended again. Anyone else has seen this behavior?

Signal 4 seems to be Illegal instruction. This probably means that you
need to recompile it for N900, due to the different processor.

-Kimmo

 
 Thanks very much
 ___
 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: How to compile in Scratchbox a project created with Nokia SDK?

2010-07-02 Thread Antonio Aloisio
Hi Andrea,

You have not use the *-build folders created by Creator.
Creator makes use of the -build folders in order to keep  the project
directory clean
moreover it makes the developer free to build the same project for
several targets without messing up
anything.

Robert's debian/rules file is correct, as you can see it generates the
Makefile. You can read more about debianizing a Qt app at:
http://wiki.maemo.org/Packaging_a_Qt_application.

Cheers,
Antonio

On Thu, Jul 1, 2010 at 6:00 PM, Andrea Grandi a.gra...@gmail.com wrote:
 Hi,

 On 1 July 2010 16:32, Robin Burchell virot...@viroteck.net wrote:
 Hi Andrea,

 On Thu, Jul 1, 2010 at 3:22 PM, Andrea Grandi a.gra...@gmail.com wrote:
 Could you please tell me how should I modify the debian/rules to call
 the server's qmake on my project?

 Perhaps you could try looking at the debian/ dir for e.g. rotatedaemon:

 http://github.com/rburchell/rotatedaemon

 yeah, I'm giving a look at this:
 http://github.com/rburchell/rotatedaemon/blob/master/debian/rules

 What I don't understand about Nokia SDK project folders is that they
 have TWO /debian/ directories and I don't know what do I have to refer
 to.
 Look at my project structure:
 http://dl.dropbox.com/u/835341/msoma.tar.gz (it doesn't matter you
 look at the code, just look at the files structure). You'll see that
 Nokia SDK creates two debian folders. It's important for me to know
 which directory I've to refer to.

 I'll try to play again with code, maybe I'll be able to fix it, let's 
 hope...

 --
 Andrea Grandi
 email: a.grandi [AT] gmail [DOT] com
 website: http://www.andreagrandi.it
 PGP Key: http://www.andreagrandi.it/pgp_key.asc

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Related to Contacts : Decoding .VCF File

2010-07-02 Thread Antonio Aloisio
On Thu, Jul 1, 2010 at 9:07 PM, Jörgen Scheibengruber
jorgen.scheibengru...@nokia.com wrote:
 Am Mittwoch, den 30.06.2010, 11:20 +0200 schrieb ext Antonio Aloisio:
 Hi,
 You can create EVCard objects using e-vcard-new-from-string. [1].

 If he wants an EContact, then he should use e_contact_new_from_vcard ()
 though ;-)
Correct. ;D

Regards,
Antonio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Simulate SIM memory and SD card on emulator

2010-07-02 Thread Pallavi Kandhare
Hello,
Can i simulate SIM memory and SD Card memory on emulator. So that i can access 
contacts from SIM and SD Card on emulator itself.

Thanks.


  

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Optification in MADDE, again

2010-07-02 Thread Martin Storsjö
Hi,

It seems I'm late to the discussion on optification in MADDE... In the 
earlier discussion, I saw this quote:

 You cannot use that with MADDE, because maemo-optify* commands use
 internally some dpkg* command options that are not implemented by MADDE.

When grepping through the source of maemo-optify 0.2.1, I see no such 
calls at all, anyone care to clarify this?


I tried adding the maemo-optify scripts outside of MADDE, in my path (on 
OS X), and it seems to work just fine, but the rest of the environment 
adds some complications.

dh_fixperms, which write the list of files for tarlisted, doesn't 
recognize symlinks at all, but this can be fixed with the attached patch. 
This would be an issue also if doing manual optification and using 
symlinks, I think?

The final problem, though, is that of the order of commands in 
debian/rules, which, for me, initially looked like this:

dh_strip
dh_compress
dh_fixperms
#   dh_perl
#   dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
maemo-optify
dh_builddeb

dh_fixperms is called a few steps before maemo-optify, so it creates a 
.tarlist that references files as they are at that point, but maemo-optify 
changes them later on. maemo-optify cannot be called before dh_installdeb, 
though. Moving dh_fixperms down to below maemo-optify does seem to work, 
although I'm not sure if that's an acceptable change in general.

// Martin--- dh_fixperms_orig	2010-07-02 11:58:45.0 +0300
+++ dh_fixperms	2010-07-02 12:04:34.0 +0300
@@ -47,6 +47,12 @@
 			next;
 		}
 
+		if (-l $src) {
+			my $dest = readlink($src);
+			tlline '---', $_ - $dest;
+			next;
+		}
+
 		# Programs in the bin and init.d dirs should be executable..
 		if (m,(^|/)bin/, || m,(^|/)sbin/, 
 			|| m,(^|/)usr/games/, || m,(^|/)etc/init.d/, ) {
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Tomi Ollila
On Fri 02 Jul 2010 12:31, Martin Storsjö mar...@martin.st writes:

 Hi,


 I tried adding the maemo-optify scripts outside of MADDE, in my path (on 
 OS X), and it seems to work just fine, but the rest of the environment 
 adds some complications.

 dh_fixperms, which write the list of files for tarlisted, doesn't 
 recognize symlinks at all, but this can be fixed with the attached
 patch. 

There is a reason for that: Windows (below 7) (NTFS) filesystem does not
regognize symbolic links (properly); Generally, any software packakeable
with MADDE on linux should be also packaeable on Windows too...

 This would be an issue also if doing manual optification and using 
 symlinks, I think?

 dh_fixperms is called a few steps before maemo-optify, so it creates a 
 .tarlist that references files as they are at that point, but maemo-optify 
 changes them later on. maemo-optify cannot be called before dh_installdeb, 
 though. Moving dh_fixperms down to below maemo-optify does seem to work, 
 although I'm not sure if that's an acceptable change in general.

Again, not knowing much of the things maemo-optify do, but replacing
dh_fixperms with version that does all the optification steps (that can be
done for data.tar.gz inside debian package) could do the trick:

i.e. instead of writing line:

755 root root . /usr/bin/cooltool debian/cooltool/usr/bin/cooltool

write lines

755 root root . opt/maddeoptify/bin/cooltool debian/cooltool/usr/bin/cooltool
--- root root . /usr/bin/cooltool - opt/maddeoptify/bin/cooltool

etc...

If this is too early (for other files, line md5sums etc), one could
manipulate .tarlist and DEBIAN directories in dpkg-deb for which there is
also a MADDE version shipped.


 // Martin

Tomi


 --- dh_fixperms_orig  2010-07-02 11:58:45.0 +0300
 +++ dh_fixperms   2010-07-02 12:04:34.0 +0300
 @@ -47,6 +47,12 @@
   next;
   }
  
 + if (-l $src) {
 + my $dest = readlink($src);
 + tlline '---', $_ - $dest;
 + next;
 + }
 +
   # Programs in the bin and init.d dirs should be executable..
   if (m,(^|/)bin/, || m,(^|/)sbin/, 
   || m,(^|/)usr/games/, || m,(^|/)etc/init.d/, ) {
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Related to Contacts : Decoding .VCF File

2010-07-02 Thread Graham Cobb
On Friday 02 July 2010 10:20:24 Jörgen Scheibengruber wrote:
 Which is exactly what e_contact_new_from_vcard, does. 

How does e_contact_new_from_vcard get told what charset the string is in?  Or 
does it require it to be in UTF-8?

 It's as easy as: 

 char *contents;
 if (g_file_get_contents (file.vcf, contents, NULL, NULL)) {
   EContact *contact;
   contact = e_contact_new_from_vcard (contents);
   g_free (contents).
 }

It's not really that easy.  Character sets are one of the hardest problems 
when importing and exporting v-format data as files do not have metadata to 
tell you the charset.

I don't recommend using g_file_get_contents to read the file unless you are 
prepared to write code to handle the charset conversions.  I use 
g_io_channel_new_file and g_io_channel_set_encoding to read a file I want to 
import so I can control the charset.

In GPE, I employ a heuristic to guess the charset:

1. I try to read the file using UTF-8 and then try to import the data.
2. If that fails, I try again using the user's default charset (using 
g_get_charset).
3. If that fails, I try again using ISO-8859-15.
4. If that fails, I give up.

When exporting I always use UTF-8.  But I have discovered that most other 
programs do not.  ISO-8859-15 is quite common but you have to allow some way 
for the user to control what is used, which is why the second step is to use 
the user's default charset.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Ville M. Vainio
Please review these:

https://bugs.maemo.org/show_bug.cgi?id=10826 (use the attached template)

http://wiki.forum.nokia.com/index.php/How_to_make_optification_with_MADDE

On Fri, Jul 2, 2010 at 12:31 PM, Martin Storsjö mar...@martin.st wrote:
 Hi,

 It seems I'm late to the discussion on optification in MADDE... In the
 earlier discussion, I saw this quote:

 You cannot use that with MADDE, because maemo-optify* commands use
 internally some dpkg* command options that are not implemented by MADDE.

 When grepping through the source of maemo-optify 0.2.1, I see no such
 calls at all, anyone care to clarify this?


 I tried adding the maemo-optify scripts outside of MADDE, in my path (on
 OS X), and it seems to work just fine, but the rest of the environment
 adds some complications.

 dh_fixperms, which write the list of files for tarlisted, doesn't
 recognize symlinks at all, but this can be fixed with the attached patch.
 This would be an issue also if doing manual optification and using
 symlinks, I think?

 The final problem, though, is that of the order of commands in
 debian/rules, which, for me, initially looked like this:

        dh_strip
        dh_compress
        dh_fixperms
 #       dh_perl
 #       dh_makeshlibs
        dh_installdeb
        dh_shlibdeps
        dh_gencontrol
        dh_md5sums
        maemo-optify
        dh_builddeb

 dh_fixperms is called a few steps before maemo-optify, so it creates a
 .tarlist that references files as they are at that point, but maemo-optify
 changes them later on. maemo-optify cannot be called before dh_installdeb,
 though. Moving dh_fixperms down to below maemo-optify does seem to work,
 although I'm not sure if that's an acceptable change in general.

 // Martin
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers





-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Marius Vollmer
ext Tomi Ollila tomi.oll...@guru.guru-group.fi writes:

 On Fri 02 Jul 2010 12:31, Martin Storsjö mar...@martin.st writes:

 dh_fixperms, which write the list of files for tarlisted, doesn't 
 recognize symlinks at all, but this can be fixed with the attached
 patch. 

 There is a reason for that: Windows (below 7) (NTFS) filesystem does not
 regognize symbolic links (properly); Generally, any software packakeable
 with MADDE on linux should be also packaeable on Windows too...

Wha??  You guys have ported debhelper to Windows?  The mind boggles...
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Tomi Ollila
On Fri 02 Jul 2010 13:56, Marius Vollmer marius.voll...@nokia.com writes:

 ext Tomi Ollila tomi.oll...@guru.guru-group.fi writes:


 There is a reason for that: Windows (below 7) (NTFS) filesystem does not
 regognize symbolic links (properly); Generally, any software packakeable
 with MADDE on linux should be also packaeable on Windows too...

 Wha??  You guys have ported debhelper to Windows?  The mind boggles...

debhelper (partially) works on Windows, under MSYS and with perl 4.6.1. See

http://meego.gitorious.org/meego-developer-tools/madde/trees/master/patches

for the changes.

Tomi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Unable to write to the serial port /dev/ttyS0 using QextSerialPort on Maemo device

2010-07-02 Thread Suyash.Kumar
OK, I understood, Thanks for the explanation Denis but I have one more 
question? 
IWe decided this approach as we have already implemented serial communication 
of Nokia N95 and PC (connected via USB cable). We simply used the symbian APIs 
for writing the information to the COM1 port and received the same on the 
windows PC's COM1 port and read it from there thus establishing a successful 
serial communication.

That's why I was trying the same for Maemo. The serial port is not visible 
physically on N95 also but somehow we managed the serial communication between 
device and PC using this approach.

Also, if the serial communication is not possible in this way, can you suggest 
me some other way/ sample code to achieve the same.

Regards,
Suyash.

-Original Message-
From: Rémi Denis-Courmont [mailto:remi.denis-courm...@nokia.com] 
Sent: Friday, July 02, 2010 4:44 PM
To: Kumar Suyash
Subject: Re: Unable to write to the serial port /dev/ttyS0 using QextSerialPort 
on Maemo device

On Friday 02 July 2010 12:10:11 ext suyash.ku...@tieto.com, you wrote:
 Hi Denis,
 
 Could not understand what you meant by:
 Unless you have your Maemo device on a development jig, your device does
 not have a serial port.

Where do you see a serial port on the N900?
...
Nowhere?

There _is_ actually a serial port. It is muxed on some of the electrical pins 
(gold colored dots) that you can see if you remove the battery from its 
compartment.

 I am testing my application on the N900 device itself.
 Also, the command ls -l /dev/ttyS0 gives proper output when run on the
 device terminal.

You would need to wire the above mentioned pins to see the output from ttyS0.

-- 
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki


On Friday 02 July 2010 10:15:25 ext suyash.ku...@tieto.com, you wrote:
 Hi,
 
 I am writing a simple Qt on Maemo application for serial communication 
 between device and PC for which I am using QextSerialPort 1.2 library 
 to write on the /dev/ttyS0 port so that it could be read by the COM1 
 port on my windows machine connected to the device via USB cable.

You do realize that /dev/ttyS0 is the device for a physical serial port on 
Linux. Unless you have your Maemo device on a development jig, your device does 
not have a serial port. So no wonder that it is not working.

--
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Martin Storsjö
On Fri, 2 Jul 2010, Tomi Ollila wrote:

 On Fri 02 Jul 2010 12:31, Martin Storsjö mar...@martin.st writes:
 
  I tried adding the maemo-optify scripts outside of MADDE, in my path (on 
  OS X), and it seems to work just fine, but the rest of the environment 
  adds some complications.
 
  dh_fixperms, which write the list of files for tarlisted, doesn't 
  recognize symlinks at all, but this can be fixed with the attached
  patch. 
 
 There is a reason for that: Windows (below 7) (NTFS) filesystem does not
 regognize symbolic links (properly); Generally, any software packakeable
 with MADDE on linux should be also packaeable on Windows too...

Yes, that's true, but even in that case, I think the deb packaging scripts 
should support symlinks, if I'd happen to run MADDE on a system that 
supports them. This is achieved with the patch I attached.

This also makes the MADDE dpkg build system compatible with normal dpkg 
build systems for packages that themselves create symlinks, but would of 
course only work on MADDE on those platforms that support symlinks.

What's the correct way of submitting this as a patch to 
http://meego.gitorious.org/meego-developer-tools/madde? I attached it as 
an git am'able patch here, too.

  This would be an issue also if doing manual optification and using 
  symlinks, I think?
 
  dh_fixperms is called a few steps before maemo-optify, so it creates a 
  .tarlist that references files as they are at that point, but maemo-optify 
  changes them later on. maemo-optify cannot be called before dh_installdeb, 
  though. Moving dh_fixperms down to below maemo-optify does seem to work, 
  although I'm not sure if that's an acceptable change in general.
 
 Again, not knowing much of the things maemo-optify do, but replacing
 dh_fixperms with version that does all the optification steps (that can be
 done for data.tar.gz inside debian package) could do the trick:
 
 i.e. instead of writing line:
 
 755 root root . /usr/bin/cooltool debian/cooltool/usr/bin/cooltool
 
 write lines
 
 755 root root . opt/maddeoptify/bin/cooltool debian/cooltool/usr/bin/cooltool
 --- root root . /usr/bin/cooltool - opt/maddeoptify/bin/cooltool

Yes, that would also be an option, but it would be slightly trickier to 
integrate in the packaging process if compatibility with scratchbox/normal 
deb tools is desired.

// MartinFrom 064b0f38220121e197a399eac53ac182f2bb1264 Mon Sep 17 00:00:00 2001
From: Martin Storsjo mar...@martin.st
Date: Fri, 2 Jul 2010 14:25:34 +0300
Subject: [PATCH] dh_fixperms: Support packaging symlinks

---
 src/debtools/dh_fixperms |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/debtools/dh_fixperms b/src/debtools/dh_fixperms
index 54b9834..998803b 100755
--- a/src/debtools/dh_fixperms
+++ b/src/debtools/dh_fixperms
@@ -47,6 +47,12 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 			next;
 		}
 
+		if (-l $src) {
+			my $dest = readlink($src);
+			tlline '---', $_ - $dest;
+			next;
+		}
+
 		# Programs in the bin and init.d dirs should be executable..
 		if (m,(^|/)bin/, || m,(^|/)sbin/,
 			|| m,(^|/)usr/games/, || m,(^|/)etc/init.d/, ) {
-- 
1.7.1

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Martin Storsjö
On Fri, 2 Jul 2010, Ville M. Vainio wrote:

 Please review these:
 
 https://bugs.maemo.org/show_bug.cgi?id=10826 (use the attached template)
 
 http://wiki.forum.nokia.com/index.php/How_to_make_optification_with_MADDE

Yes, I'm already planning to do something similar, but I'd like to package 
symlinks for my binaries, too, and that doesn't seem to be supported at 
the moment? The patch I posted is at least a first step towards supporting 
it, on platforms where symlinks are supported.

// Martin
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Unable to write to the serial port /dev/ttyS0 using QextSerialPort on Maemo device

2010-07-02 Thread Rémi Denis-Courmont
On Friday 02 July 2010 14:25:18 ext suyash.ku...@tieto.com, you wrote:
 OK, I understood, Thanks for the explanation Denis but I have one more
 question? IWe decided this approach as we have already implemented serial
 communication of Nokia N95 and PC (connected via USB cable).

If it is USB then it is not serial. N95 is the same as N900 w.r.t. the serial 
port: you will also find it hidden in the battery compartment.

If you want to transmit data on the USB cable, you need to use one of the USB 
interfaces. If you mean to use the EMULATED serial line, then you need to use 
the USB CDC ACM interface of the PC suite profile. That will LOOK LIKE a COM 
port on Windows if you have the Nokia connectivity device drivers. On Maemo 5, 
that is called /dev/ttyGS2 but that device node is reserved by the N900 built-
in AT commands handler.

-- 
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Tomi Ollila
On Fri 02 Jul 2010 14:28, Martin Storsjö mar...@martin.st writes:

 On Fri, 2 Jul 2010, Tomi Ollila wrote:

 
 There is a reason for that: Windows (below 7) (NTFS) filesystem does not
 regognize symbolic links (properly); Generally, any software packakeable
 with MADDE on linux should be also packaeable on Windows too...

 Yes, that's true, but even in that case, I think the deb packaging scripts 
 should support symlinks, if I'd happen to run MADDE on a system that 
 supports them. This is achieved with the patch I attached.

 This also makes the MADDE dpkg build system compatible with normal dpkg 
 build systems for packages that themselves create symlinks, but would of 
 course only work on MADDE on those platforms that support symlinks.

 What's the correct way of submitting this as a patch to 
 http://meego.gitorious.org/meego-developer-tools/madde? I attached it as 
 an git am'able patch here, too.

Well, partial solutions can be committed to anywhere but will not be
included in our MADDE releases. For consistency and support reasons we will
use the least common denominator principle (or whatever :) in the features

I've been thinking a solution where there is an 'ln' wrapper for windows,
which, instead of writing symlinks writes some kind of metafile which
describes it as a symlink... This has some risks, but just doing it during
installation phase (and just from a packager, maybe (triggered by env var))
could do the work. There is at least 3 options (+ combinations of these:

1) have a file 'symlinks' in directory. Maybe not good as rm:ing symlink
   would not work

2) make filename.symlink which contents describe symlink. same problem as
   above

2) make filename with magic content that describes that it is a symlink
   and what the symlink destination is. less problems than the above...

Then, dh_fixperms (and rrpmbuild.pl!) could know this magic and write
symbolic links to the packages accordingly.

In far future (2020) when we need not support symlinkless filesystems this
workaround can be removed (if written until that time ;)


 // Martin

Tomi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Martin Storsjö
On Fri, 2 Jul 2010, Tomi Ollila wrote:

 On Fri 02 Jul 2010 14:28, Martin Storsjö mar...@martin.st writes:
 
  On Fri, 2 Jul 2010, Tomi Ollila wrote:
 
  
  There is a reason for that: Windows (below 7) (NTFS) filesystem does not
  regognize symbolic links (properly); Generally, any software packakeable
  with MADDE on linux should be also packaeable on Windows too...
 
  Yes, that's true, but even in that case, I think the deb packaging scripts 
  should support symlinks, if I'd happen to run MADDE on a system that 
  supports them. This is achieved with the patch I attached.
 
  This also makes the MADDE dpkg build system compatible with normal dpkg 
  build systems for packages that themselves create symlinks, but would of 
  course only work on MADDE on those platforms that support symlinks.
 
  What's the correct way of submitting this as a patch to 
  http://meego.gitorious.org/meego-developer-tools/madde? I attached it as 
  an git am'able patch here, too.
 
 Well, partial solutions can be committed to anywhere but will not be
 included in our MADDE releases. For consistency and support reasons we will
 use the least common denominator principle (or whatever :) in the features

Ok, thanks for clarifying, then I'll stop trying to push for this kind of 
features. A proper, cross-platform solution, that is compatible with the 
original native build scripts, would of course be well appreciated. 
(Having to use a different tool for creating links depending on if 
building within MADDE or in a real environment would be problematic.)

Until then, I guess I just have to cope with building packages without 
symlinks.

// Martin___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Optification in MADDE, again

2010-07-02 Thread Martin Storsjö
On Fri, 2 Jul 2010, Martin Storsjö wrote:

 On Fri, 2 Jul 2010, Ville M. Vainio wrote:
 
  Please review these:
  
  https://bugs.maemo.org/show_bug.cgi?id=10826 (use the attached template)
  
  http://wiki.forum.nokia.com/index.php/How_to_make_optification_with_MADDE
 
 Yes, I'm already planning to do something similar, but I'd like to package 
 symlinks for my binaries, too, and that doesn't seem to be supported at 
 the moment? The patch I posted is at least a first step towards supporting 
 it, on platforms where symlinks are supported.

As a follow-up to this... For binaries, one can live without symlinks, as 
long as the .desktop if updated accordingly (as in the samples you linked 
to) - except for the minor inconvenience that the app isn't available in 
the path by default, but what about other files that the system wants in 
certain locations?

In particular, maemo-optify currently optifies some of my icons, too - is 
there any way to have them read from nonstandard locations? On the other 
hand, I guess I can skip optification of them, too.

// Martin___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Unable to write to the serial port /dev/ttyS0 using QextSerialPort on Maemo device

2010-07-02 Thread Ian Stirling

suyash.ku...@tieto.com wrote:
OK, I understood, Thanks for the explanation Denis but I have one more question? 
IWe decided this approach as we have already implemented serial communication of Nokia N95 and PC (connected via USB cable). We simply used the symbian APIs for writing the information to the COM1 port and received the same on the windows PC's COM1 port and read it from there thus establishing a successful serial communication.


That's why I was trying the same for Maemo. The serial port is not visible 
physically on N95 also but somehow we managed the serial communication between 
device and PC using this approach.

Also, if the serial communication is not possible in this way, can you suggest 
me some other way/ sample code to achieve the same.


That wasn't really USB, it was RS232, with a wierd connector.

There are some RS232-over-USB-port capable phones - but absolutely no 
desktop hosts support this.


Serial (RS232) and Universal Serial Bus - have about as much in common 
as man and manatee.


You need to configure the n900s USB port to emulate a RS232-USB 
converter - in some way.
http://www.kernel.org/doc/Documentation/usb/gadget_serial.txt is an 
overview of how it would be setup.


Unfortunately, I'm unaware of how this would interact with the default 
process that enables the requisite USB drivers.


I know hald-addon-usb-cable monitors the lowest level of this, and sends 
an event on dbus, but I'm unsure what watches for this event, and 
configures USB gadgets.



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers