kde4/qt4 port of kio_rapip

[Tejas Guruswamy]

Hello everyone!

New subscriber to the mailing list, long time SynCE user, I am
consistently impressed by how much you've been able to accomplish :) But
enough of the flattery.

Firstly, I was bored and so I ported kio_rapip to KDE4/Qt4. I noticed a
few others were asking for it and I wanted it myself so instead of
bugging you guys I had a go at it. I've currently been using Google code
(mostly just to see what they were offering) to host it, check it out at
http://code.google.com/p/kde4-kio-rapip/.
Now I'm no C/C++ developer, what I've done is read the Porting to KDE4
and Porting to Qt4.4 pages on the web and just fixed stuff until the
compiler stopped complaining (extensive use of find+replace), so it's
not perfect, but it WFM :) The changes are quite minor, in most cases
just renames, no logic changes. One major change is that it builds using
cmake as with the rest of KDE4, look at the installation instructions if
you are unsure.
I've got it working with WM2003 and WM2005 devices in Dolphin and
Konqueror, read, write, delete, etc. I've tested mainly with
KDE4.0(release)/Qt4.4 on openSUSE 10.3 and 11.0. If you experience any
issues, let me know. BTW I haven't yet tried with KDE4.1betas. What I
would love to see is some basic integration into synce-kpm since that
seems to be the frontend for stuff now. Just a link to open
rapip://DEVICENAME/ for every device you have connected, like raki did.

Second, I had a query about the ppp options used to connect WM2003
serial devices in synce-hal. When I first installed it on openSUSE 11.0
it didn't work, a little digging around showed that ppp wasn't giving up
control, i.e. "updetach" wasn't being used. Looking at the code in
hal/hal-synce-serial showed that it was there, but separate from the
other options inside an "if [ -t 1 ]" (see line 62). Moving it outside
the if-block makes it work for me. Is there any harm done by doing that?

In any case I've got my system running subversion builds of libsynce,
librapi2, hal, and my kde4-kio-rapip, and since I don't do much actual
syncing, just file transfer, I'm a happy bunny. Great work :)

Regards,

Tejas Guruswamy
<***@gmail.com>

[Mark Ellis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everyone!
New subscriber to the mailing list, long time SynCE user, I am
consistently impressed by how much you've been able to accomplish :) But
enough of the flattery.
Firstly, I was bored and so I ported kio_rapip to KDE4/Qt4. I noticed a
few others were asking for it and I wanted it myself so instead of
bugging you guys I had a go at it. I've currently been using Google code
(mostly just to see what they were offering) to host it, check it out at
http://code.google.com/p/kde4-kio-rapip/.
Now I'm no C/C++ developer, what I've done is read the Porting to KDE4
and Porting to Qt4.4 pages on the web and just fixed stuff until the
compiler stopped complaining (extensive use of find+replace), so it's
not perfect, but it WFM :) The changes are quite minor, in most cases
just renames, no logic changes. One major change is that it builds using
cmake as with the rest of KDE4, look at the installation instructions if
you are unsure.
I've got it working with WM2003 and WM2005 devices in Dolphin and
Konqueror, read, write, delete, etc. I've tested mainly with
KDE4.0(release)/Qt4.4 on openSUSE 10.3 and 11.0. If you experience any
issues, let me know. BTW I haven't yet tried with KDE4.1betas. What I
would love to see is some basic integration into synce-kpm since that
seems to be the frontend for stuff now. Just a link to open
rapip://DEVICENAME/ for every device you have connected, like raki did.

Excellent ! I was hoping some kde'er would do that. I'll try and have a
look soon, and probably update our svn.

Second, I had a query about the ppp options used to connect WM2003
serial devices in synce-hal. When I first installed it on openSUSE 11.0
it didn't work, a little digging around showed that ppp wasn't giving up
control, i.e. "updetach" wasn't being used. Looking at the code in
hal/hal-synce-serial showed that it was there, but separate from the
other options inside an "if [ -t 1 ]" (see line 62). Moving it outside
the if-block makes it work for me. Is there any harm done by doing that?

As far as I know, you're the only one having this problem. I can't see
how it would make that much difference, I'll ruminate on it.

Mark

[Mark Ellis]

Post by Mark Ellis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everyone!
New subscriber to the mailing list, long time SynCE user, I am
consistently impressed by how much you've been able to accomplish :) But
enough of the flattery.
Firstly, I was bored and so I ported kio_rapip to KDE4/Qt4. I noticed a
few others were asking for it and I wanted it myself so instead of
bugging you guys I had a go at it. I've currently been using Google code
(mostly just to see what they were offering) to host it, check it out at
http://code.google.com/p/kde4-kio-rapip/.
Now I'm no C/C++ developer, what I've done is read the Porting to KDE4
and Porting to Qt4.4 pages on the web and just fixed stuff until the
compiler stopped complaining (extensive use of find+replace), so it's
not perfect, but it WFM :) The changes are quite minor, in most cases
just renames, no logic changes. One major change is that it builds using
cmake as with the rest of KDE4, look at the installation instructions if
you are unsure.
I've got it working with WM2003 and WM2005 devices in Dolphin and
Konqueror, read, write, delete, etc. I've tested mainly with
KDE4.0(release)/Qt4.4 on openSUSE 10.3 and 11.0. If you experience any
issues, let me know. BTW I haven't yet tried with KDE4.1betas. What I
would love to see is some basic integration into synce-kpm since that
seems to be the frontend for stuff now. Just a link to open
rapip://DEVICENAME/ for every device you have connected, like raki did.

Excellent ! I was hoping some kde'er would do that. I'll try and have a
look soon, and probably update our svn.

Or as Jonny said, you could do it :)

Post by Mark Ellis

Second, I had a query about the ppp options used to connect WM2003
serial devices in synce-hal. When I first installed it on openSUSE 11.0
it didn't work, a little digging around showed that ppp wasn't giving up
control, i.e. "updetach" wasn't being used. Looking at the code in
hal/hal-synce-serial showed that it was there, but separate from the
other options inside an "if [ -t 1 ]" (see line 62). Moving it outside
the if-block makes it work for me. Is there any harm done by doing that?

As far as I know, you're the only one having this problem. I can't see
how it would make that much difference, I'll ruminate on it.

Tried this with and without, makes no difference for me. Can you put in
some log output around the call to pppd to see what happens ?

Mark

[Tejas Guruswamy]

Mark Ellis wrote:
|>> Second, I had a query about the ppp options used to connect
|>> WM2003 serial devices in synce-hal. When I first installed it on
|>> openSUSE 11.0 it didn't work, a little digging around showed that
|>> ppp wasn't giving up control, i.e. "updetach" wasn't being used.
|>> Looking at the code in hal/hal-synce-serial showed that it was
|>> there, but separate from the other options inside an "if [ -t 1
|>> ]" (see line 62). Moving it outside the if-block makes it work
|>> for me. Is there any harm done by doing that?
|>>
|> As far as I know, you're the only one having this problem. I can't
|> see how it would make that much difference, I'll ruminate on it.
|>
|
| Tried this with and without, makes no difference for me. Can you put
| in some log output around the call to pppd to see what happens ?
|
| Mark

I changed the log level in the hal-synce-serial script to 6 (debug).
I've attached all the relevant output with and without the updetach pppd
option, but I'm covering the key part here. After connecting the WM2003
device, the usb stuff happens fine and hal starts the addons fine.

Jul 4 11:19:42 susebeta hal-synce-serial[3210]: hal-synce-serial:
running as addon for synce-device0.
Jul 4 11:19:42 susebeta hal-synce-serial[3210]: Bringing up serial
link: /usr/sbin/pppd /dev/ttyUSB0 115200 connect
/usr/lib/synce/synce-serial-chat 192.168.131.1:192.168.131.129 ms-dns
192.168.131.1 linkname synce-device0 nodefaultroute noauth local crtscts
Jul 4 11:19:42 susebeta pppd[3222]: pppd 2.4.4 started by root, uid 0
Jul 4 11:19:43 susebeta pppd[3222]: Serial connection established.
Jul 4 11:19:43 susebeta pppd[3222]: Using interface ppp0
Jul 4 11:19:43 susebeta pppd[3222]: Connect: ppp0 <--> /dev/ttyUSB0
Jul 4 11:19:43 susebeta pppd[3222]: local IP address 192.168.131.1
Jul 4 11:19:43 susebeta pppd[3222]: remote IP address 192.168.131.129
Jul 4 11:19:44 susebeta pppd[3222]: Script /etc/ppp/ip-up finished (pid
3225), status = 0x0
Jul 4 11:19:49 susebeta poll.tcpip: no server configured

At this point everything stops, a message box appears on my WM2003
device saying "Could not start communications with desktop computer".
pls/pstatus does not work and gives the following error:

| ** (process:27814): CRITICAL **: synce_info_from_hal: Failed to
| obtain property pda.pocketpc.name for device
|
/org/freedesktop/Hal/devices/usb_device_413c_4003_noserial_if0_serial_usb_0_4:
| org.freedesktop.Hal.NoSuchProperty: No property pda.pocketpc.name on
| device with id
|
/org/freedesktop/Hal/devices/usb_device_413c_4003_noserial_if0_serial_usb_0_4

As soon as I OK the message box on the device (there is no other option)
the link gets disconnected.

Jul 4 11:20:11 susebeta pppd[3222]: LCP terminated by peer
Jul 4 11:20:11 susebeta pppd[3222]: Connect time 0.5 minutes.
Jul 4 11:20:11 susebeta pppd[3222]: Sent 680 bytes, received 1369 bytes.
Jul 4 11:20:11 susebeta pppd[3222]: Script /etc/ppp/ip-down finished
(pid 3273), status = 0x0
Jul 4 11:20:13 susebeta pppd[3222]: Connection terminated.
Jul 4 11:20:13 susebeta pppd[3222]: Modem hangup
Jul 4 11:20:13 susebeta pppd[3222]: Exit.
Jul 4 11:20:13 susebeta hal-synce-serial[3210]: Failed to initialize
ppp connection

If I add the updetach option to the $ppp_opts it works great, as you can
see in the other log.
Could it be something distro specific? Some difference in
/etc/ppp/options? My (SUSE 11.0 and 10.3) /etc/ppp/options has
"nodetach" enabled. I also noticed that in the script you included
$SYNCE_PPP_OPTIONS after $ppp_opts in the pppd call but that's empty on
my machine.

Hopefully this information will help.

Regards,

Tejas Guruswamy <***@gmail.com>

[Mark Ellis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|>> Second, I had a query about the ppp options used to connect
|>> WM2003 serial devices in synce-hal. When I first installed it on
|>> openSUSE 11.0 it didn't work, a little digging around showed that
|>> ppp wasn't giving up control, i.e. "updetach" wasn't being used.
|>> Looking at the code in hal/hal-synce-serial showed that it was
|>> there, but separate from the other options inside an "if [ -t 1
|>> ]" (see line 62). Moving it outside the if-block makes it work
|>> for me. Is there any harm done by doing that?
|>>
|> As far as I know, you're the only one having this problem. I can't
|> see how it would make that much difference, I'll ruminate on it.
|>
|
| Tried this with and without, makes no difference for me. Can you put
| in some log output around the call to pppd to see what happens ?
|
| Mark
I changed the log level in the hal-synce-serial script to 6 (debug).
I've attached all the relevant output with and without the updetach pppd
option, but I'm covering the key part here. After connecting the WM2003
device, the usb stuff happens fine and hal starts the addons fine.
running as addon for synce-device0.
Jul 4 11:19:42 susebeta hal-synce-serial[3210]: Bringing up serial
link: /usr/sbin/pppd /dev/ttyUSB0 115200 connect
/usr/lib/synce/synce-serial-chat 192.168.131.1:192.168.131.129 ms-dns
192.168.131.1 linkname synce-device0 nodefaultroute noauth local crtscts
Jul 4 11:19:42 susebeta pppd[3222]: pppd 2.4.4 started by root, uid 0
Jul 4 11:19:43 susebeta pppd[3222]: Serial connection established.
Jul 4 11:19:43 susebeta pppd[3222]: Using interface ppp0
Jul 4 11:19:43 susebeta pppd[3222]: Connect: ppp0 <--> /dev/ttyUSB0
Jul 4 11:19:43 susebeta pppd[3222]: local IP address 192.168.131.1
Jul 4 11:19:43 susebeta pppd[3222]: remote IP address 192.168.131.129
Jul 4 11:19:44 susebeta pppd[3222]: Script /etc/ppp/ip-up finished (pid
3225), status = 0x0
Jul 4 11:19:49 susebeta poll.tcpip: no server configured
At this point everything stops, a message box appears on my WM2003
device saying "Could not start communications with desktop computer".
| ** (process:27814): CRITICAL **: synce_info_from_hal: Failed to
| obtain property pda.pocketpc.name for device
|
| org.freedesktop.Hal.NoSuchProperty: No property pda.pocketpc.name on
| device with id
|
/org/freedesktop/Hal/devices/usb_device_413c_4003_noserial_if0_serial_usb_0_4
As soon as I OK the message box on the device (there is no other option)
the link gets disconnected.
Jul 4 11:20:11 susebeta pppd[3222]: LCP terminated by peer
Jul 4 11:20:11 susebeta pppd[3222]: Connect time 0.5 minutes.
Jul 4 11:20:11 susebeta pppd[3222]: Sent 680 bytes, received 1369 bytes.
Jul 4 11:20:11 susebeta pppd[3222]: Script /etc/ppp/ip-down finished
(pid 3273), status = 0x0
Jul 4 11:20:13 susebeta pppd[3222]: Connection terminated.
Jul 4 11:20:13 susebeta pppd[3222]: Modem hangup
Jul 4 11:20:13 susebeta pppd[3222]: Exit.
Jul 4 11:20:13 susebeta hal-synce-serial[3210]: Failed to initialize
ppp connection
If I add the updetach option to the $ppp_opts it works great, as you can
see in the other log.
Could it be something distro specific? Some difference in
/etc/ppp/options? My (SUSE 11.0 and 10.3) /etc/ppp/options has
"nodetach" enabled. I also noticed that in the script you included
$SYNCE_PPP_OPTIONS after $ppp_opts in the pppd call but that's empty on
my machine.

I think you might have it there. The only detach related option in my
(ubuntu) /etc/ppp/options is commented out, as the following


# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach

which would imply that the standard behaviour is to detach, whereas
yours is to not detach. I will therefore make detaching standard in
synce-hal.

Thanks for the help !

Mark

[Mark Ellis]

Post by Mark Ellis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having updetach as default in synce-hal has resulted in breakage on a
gentoo build, and I'm trying to track down how this should work.

Tejas, can you post your entire /etc/ppp/options ?

Mark

Post by Mark Ellis

|>> Second, I had a query about the ppp options used to connect
|>> WM2003 serial devices in synce-hal. When I first installed it on
|>> openSUSE 11.0 it didn't work, a little digging around showed that
|>> ppp wasn't giving up control, i.e. "updetach" wasn't being used.
|>> Looking at the code in hal/hal-synce-serial showed that it was
|>> there, but separate from the other options inside an "if [ -t 1
|>> ]" (see line 62). Moving it outside the if-block makes it work
|>> for me. Is there any harm done by doing that?
|>>
|> As far as I know, you're the only one having this problem. I can't
|> see how it would make that much difference, I'll ruminate on it.
|>
|
| Tried this with and without, makes no difference for me. Can you put
| in some log output around the call to pppd to see what happens ?
|
| Mark
I changed the log level in the hal-synce-serial script to 6 (debug).
I've attached all the relevant output with and without the updetach pppd
option, but I'm covering the key part here. After connecting the WM2003
device, the usb stuff happens fine and hal starts the addons fine.
running as addon for synce-device0.
Jul 4 11:19:42 susebeta hal-synce-serial[3210]: Bringing up serial
link: /usr/sbin/pppd /dev/ttyUSB0 115200 connect
/usr/lib/synce/synce-serial-chat 192.168.131.1:192.168.131.129 ms-dns
192.168.131.1 linkname synce-device0 nodefaultroute noauth local crtscts
Jul 4 11:19:42 susebeta pppd[3222]: pppd 2.4.4 started by root, uid 0
Jul 4 11:19:43 susebeta pppd[3222]: Serial connection established.
Jul 4 11:19:43 susebeta pppd[3222]: Using interface ppp0
Jul 4 11:19:43 susebeta pppd[3222]: Connect: ppp0 <--> /dev/ttyUSB0
Jul 4 11:19:43 susebeta pppd[3222]: local IP address 192.168.131.1
Jul 4 11:19:43 susebeta pppd[3222]: remote IP address 192.168.131.129
Jul 4 11:19:44 susebeta pppd[3222]: Script /etc/ppp/ip-up finished (pid
3225), status = 0x0
Jul 4 11:19:49 susebeta poll.tcpip: no server configured
At this point everything stops, a message box appears on my WM2003
device saying "Could not start communications with desktop computer".
| ** (process:27814): CRITICAL **: synce_info_from_hal: Failed to
| obtain property pda.pocketpc.name for device
|
| org.freedesktop.Hal.NoSuchProperty: No property pda.pocketpc.name on
| device with id
|
/org/freedesktop/Hal/devices/usb_device_413c_4003_noserial_if0_serial_usb_0_4
As soon as I OK the message box on the device (there is no other option)
the link gets disconnected.
Jul 4 11:20:11 susebeta pppd[3222]: LCP terminated by peer
Jul 4 11:20:11 susebeta pppd[3222]: Connect time 0.5 minutes.
Jul 4 11:20:11 susebeta pppd[3222]: Sent 680 bytes, received 1369 bytes.
Jul 4 11:20:11 susebeta pppd[3222]: Script /etc/ppp/ip-down finished
(pid 3273), status = 0x0
Jul 4 11:20:13 susebeta pppd[3222]: Connection terminated.
Jul 4 11:20:13 susebeta pppd[3222]: Modem hangup
Jul 4 11:20:13 susebeta pppd[3222]: Exit.
Jul 4 11:20:13 susebeta hal-synce-serial[3210]: Failed to initialize
ppp connection
If I add the updetach option to the $ppp_opts it works great, as you can
see in the other log.
Could it be something distro specific? Some difference in
/etc/ppp/options? My (SUSE 11.0 and 10.3) /etc/ppp/options has
"nodetach" enabled. I also noticed that in the script you included
$SYNCE_PPP_OPTIONS after $ppp_opts in the pppd call but that's empty on
my machine.

I think you might have it there. The only detach related option in my
(ubuntu) /etc/ppp/options is commented out, as the following
# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach
which would imply that the standard behaviour is to detach, whereas
yours is to not detach. I will therefore make detaching standard in
synce-hal.
Thanks for the help !
Mark

[MasterPatricko]

Post by Mark Ellis
Having updetach as default in synce-hal has resulted in breakage on a
gentoo build, and I'm trying to track down how this should work.
Tejas, can you post your entire /etc/ppp/options ?
Mark

Attached as requested. Just to check I looked at the ppp call done by
the old synce-serial/vdccm and it used updetach on my machine.
Let me know what you find out :)


Tejas Guruswamy

[Mark Ellis]

Hi all

Heads up on synce-hal, particularly for packagers. The result of this
thread some time ago was that I added updetach to the default ppp
options for serial connections, which appeared to be necessary for
openSuse pppd. I have since encountered a problem on Gentoo where this
option specifically fouls the works.

I have removed updetach from default ppp options. If packagers find
particular options are necessary for a distro, I recommend they are
added for that package, either in the serial script (which is now
python) or in the optional config file.

Mark

Post by MasterPatricko

Post by Mark Ellis
Having updetach as default in synce-hal has resulted in breakage on a
gentoo build, and I'm trying to track down how this should work.
Tejas, can you post your entire /etc/ppp/options ?
Mark

Attached as requested. Just to check I looked at the ppp call done by
the old synce-serial/vdccm and it used updetach on my machine.
Let me know what you find out :)
Tejas Guruswamy

[Jonny Lamb]

Post by Tejas Guruswamy
Firstly, I was bored and so I ported kio_rapip to KDE4/Qt4. I noticed a
few others were asking for it and I wanted it myself so instead of
bugging you guys I had a go at it. I've currently been using Google code
(mostly just to see what they were offering) to host it, check it out at
http://code.google.com/p/kde4-kio-rapip/.

This is cool, thanks for doing this. Would you be interested in
moving/mirroring this in SynCE's SVN? I think keeping such tightly-knit
modules in different places isn't a great idea, and I'm sure most will agree
with me.

If you're interested, tell me your SourceForge username and I'll add you
as a committer.

Thanks,

[Tejas Guruswamy]

Jonny Lamb wrote:
| On Tue, Jul 01, 2008 at 09:35:55PM +0100, Tejas Guruswamy wrote:
|> Firstly, I was bored and so I ported kio_rapip to KDE4/Qt4. I noticed a
|> few others were asking for it and I wanted it myself so instead of
|> bugging you guys I had a go at it. I've currently been using Google code
|> (mostly just to see what they were offering) to host it, check it out at
|> http://code.google.com/p/kde4-kio-rapip/.
|
| This is cool, thanks for doing this. Would you be interested in
| moving/mirroring this in SynCE's SVN? I think keeping such tightly-knit
| modules in different places isn't a great idea, and I'm sure most will
agree
| with me.
|
| If you're interested, tell me your SourceForge username and I'll add you
| as a committer.

Sounds good to me. I was just using googlecode to experiment, no long
term plans.

My sourceforge username is masterpatricko. Since I was the only person
to ever do anything with the code, are you happy for me to just check in
a new copy as the initial import and not worry about the ~10 revisions I
had? I assume trunk/kde4-kio_rapip is OK as far as the naming goes.

Once the code is in the synce svn I'm happy to ask google to get rid of
the project on their servers.

I'll split my discussion with Mark about my hal/ppp problems into
another thread if that's ok, since this title is a bit misleading for
that discussion.

Regards,

Tejas Guruswamy <***@gmail.com>

[Jonny Lamb]

Post by Tejas Guruswamy
My sourceforge username is masterpatricko.

You have been added as a developer to the project.

Post by Tejas Guruswamy
Since I was the only person to ever do anything with the code, are you
happy for me to just check in a new copy as the initial import and not
worry about the ~10 revisions I had?

No, that's absolutely fine.

One thing: your trunk/COPYING says GPLv2, but your Google Code front page
says MIT. The former will take precedence, but after reading the front
page, I'm wondering whether you deliberately put the GPL in your
COPYING? Please make the license very clear upon importing into our SVN.

Post by Tejas Guruswamy
I assume trunk/kde4-kio_rapip is OK as far as the naming goes.

I prefer trunk/kde4-kio-rapip to be honest, but if you are stuck on that
name, then go ahead.

Post by Tejas Guruswamy
Once the code is in the synce svn I'm happy to ask google to get rid of
the project on their servers.

Cool; that's up to you.

Post by Tejas Guruswamy
I'll split my discussion with Mark about my hal/ppp problems into
another thread if that's ok, since this title is a bit misleading for
that discussion.

Great! Welcome to the project! Nudge me when/if you want a release of it
done. I'm planning on doing a 0.12 some time next week anyway, so if you
want, I could include it there?

Thanks,

[Adam Williamson]

Post by Jonny Lamb
One thing: your trunk/COPYING says GPLv2, but your Google Code front page
says MIT. The former will take precedence, but after reading the front
page, I'm wondering whether you deliberately put the GPL in your
COPYING? Please make the license very clear upon importing into our SVN.

As resident Mandriva licensing geek, I should chip in that the preferred
way to do this is to include an explicit declaration of the applicable
license at the top of each source file, along with a full copy of the
relevant license(s) in the top-level directory. For GNU licenses
remember to specify the version(s) of the license that you want to
apply.

[Tejas Guruswamy]

Post by Adam Williamson

Post by Jonny Lamb
One thing: your trunk/COPYING says GPLv2, but your Google Code front page
says MIT. The former will take precedence, but after reading the front
page, I'm wondering whether you deliberately put the GPL in your
COPYING? Please make the license very clear upon importing into our SVN.

As resident Mandriva licensing geek, I should chip in that the preferred
way to do this is to include an explicit declaration of the applicable
license at the top of each source file, along with a full copy of the
relevant license(s) in the top-level directory. For GNU licenses
remember to specify the version(s) of the license that you want to
apply.

The confusion actually stems from the original kio-rapip code I started
with (from synce svn). There are two files present, COPYING (GPLv2) and
LICENSE (MIT). The MIT license is then in the header of the source
files. But then to confuse things further there is a rapip.lsm which has
the license listed as GPL. I really wasn't sure which one was intended,
but most of the SynCE project is under MIT so I just chose that in
Google. The author was Volker Christian; is he still around? I don't
feel I have changed the code enough for it to be a completely separate
project, so if he did want it to be under GPL I'm happy to stick with
that. Anyone know either way?

And trunk/kde4-kio-rapip is fine with me if that's preferred.

Regards,

Tejas Guruswamy <***@gmail.com>

[Jonny Lamb]

[You need not CC me. I read lists I write to regularly.]

Post by Tejas Guruswamy
The confusion actually stems from the original kio-rapip code I started
with (from synce svn). There are two files present, COPYING (GPLv2) and
LICENSE (MIT). The MIT license is then in the header of the source
files. But then to confuse things further there is a rapip.lsm which has
the license listed as GPL. I really wasn't sure which one was intended,
but most of the SynCE project is under MIT so I just chose that in
Google. The author was Volker Christian; is he still around? I don't
feel I have changed the code enough for it to be a completely separate
project, so if he did want it to be under GPL I'm happy to stick with
that. Anyone know either way?

Ah, that's interesting. I completely failed to notice the presence of
both COPYING and LICENSE. I've never seen an lsm file before, but it
looks like some KDE desktop/menu file. I'd say the mention of GPL in
that file is in error, and the GPL COPYING file should also not be
there.

If no-one objects by this time tomorrow, or thereabouts, I'll update
this, removing all mention of GPL. The code itself is MIT, and without
contacting Volker (which I think would be difficult) it will not change.

If you look at what I do tomorrow and mirror it in your KDE4 version,
then that'll be cool.

Hopefully this is clear.

Thanks,

[Jonny Lamb]

Post by Jonny Lamb
If you look at what I do tomorrow and mirror it in your KDE4 version,
then that'll be cool.

See r3508.

I think the reason the GPL COPYING file was present was because some
files under admin/ (conf.change.pl, am_edit, doxygen.sh) are licensed
under the GPL. However, and please do correct me if I'm wrong, these are
generic KDE/doxygen files and therefore do not need a specific COPYING
file for them.

[Tejas Guruswamy]

Post by Jonny Lamb
See r3508.
I think the reason the GPL COPYING file was present was because some
files under admin/ (conf.change.pl, am_edit, doxygen.sh) are licensed
under the GPL. However, and please do correct me if I'm wrong, these are
generic KDE/doxygen files and therefore do not need a specific COPYING
file for them.

Checked in as trunk/kde4-kio-rapip without the COPYING file. I'll be
traveling for the next few weeks so won't be able to contribute any code
but do try out what's there and let me know how it works for you.

Regards,

Tejas Guruswamy <***@gmail.com>

[Mark Ellis]

Post by Tejas Guruswamy

Post by Jonny Lamb
See r3508.
I think the reason the GPL COPYING file was present was because some
files under admin/ (conf.change.pl, am_edit, doxygen.sh) are licensed
under the GPL. However, and please do correct me if I'm wrong, these are
generic KDE/doxygen files and therefore do not need a specific COPYING
file for them.

Checked in as trunk/kde4-kio-rapip without the COPYING file. I'll be
traveling for the next few weeks so won't be able to contribute any code
but do try out what's there and let me know how it works for you.

I finally got around to looking at this, good job ! As a gnomer I won't
use it much personally, but it's good that the 'other side' :) is kept
going.

In your adventures with cmake, did you get any idea how to roll source
packages ? Obviously with autotools we just run a make dist and get a
nice ready to configure tarball. I've had a bit of a browse for what the
procedure is, but got a bit lost.

Mark

[John Carr]

Post by Mark Ellis

Post by Tejas Guruswamy

Post by Jonny Lamb
See r3508.
I think the reason the GPL COPYING file was present was because some
files under admin/ (conf.change.pl, am_edit, doxygen.sh) are licensed
under the GPL. However, and please do correct me if I'm wrong, these are
generic KDE/doxygen files and therefore do not need a specific COPYING
file for them.

Checked in as trunk/kde4-kio-rapip without the COPYING file. I'll be
traveling for the next few weeks so won't be able to contribute any code
but do try out what's there and let me know how it works for you.

I finally got around to looking at this, good job ! As a gnomer I won't
use it much personally, but it's good that the 'other side' :) is kept
going.
In your adventures with cmake, did you get any idea how to roll source
packages ? Obviously with autotools we just run a make dist and get a
nice ready to configure tarball. I've had a bit of a browse for what the
procedure is, but got a bit lost.
Mark

I added support for CMake to jhbuild a while ago, and when needing to
do a "./configure && make dist" for a cmake build system, jhbuild
would issue:

cmake -DCMAKE_INSTALL_PREFIX=/usr
make package_source

Doubt that the prefix thing is strictly neccesary, but i never got
round to trying it without.

[Mark Ellis]

Post by John Carr

Post by Mark Ellis

Post by Tejas Guruswamy

Post by Jonny Lamb
See r3508.
I think the reason the GPL COPYING file was present was because some
files under admin/ (conf.change.pl, am_edit, doxygen.sh) are licensed
under the GPL. However, and please do correct me if I'm wrong, these are
generic KDE/doxygen files and therefore do not need a specific COPYING
file for them.

Checked in as trunk/kde4-kio-rapip without the COPYING file. I'll be
traveling for the next few weeks so won't be able to contribute any code
but do try out what's there and let me know how it works for you.

I finally got around to looking at this, good job ! As a gnomer I won't
use it much personally, but it's good that the 'other side' :) is kept
going.
In your adventures with cmake, did you get any idea how to roll source
packages ? Obviously with autotools we just run a make dist and get a
nice ready to configure tarball. I've had a bit of a browse for what the
procedure is, but got a bit lost.
Mark

I added support for CMake to jhbuild a while ago, and when needing to
do a "./configure && make dist" for a cmake build system, jhbuild
cmake -DCMAKE_INSTALL_PREFIX=/usr
make package_source
Doubt that the prefix thing is strictly neccesary, but i never got
round to trying it without.

Thanks John, that's a step in the right direction. I can now build a
source package, it just doesn't build :( Something to do with having the
correct cpack directives I think.

Mark

[Tejas Guruswamy]

I've just checked in modifications to CMakeLists.txt that enable cpack.
Everything in that file is pretty self-explanatory, the documentation on
the cmake wiki covers most stuff.
The procedure for using cpack is as follows:

In a separate BUILD_DIR (anywhere on your system, one of the main ideas
behind cmake is out-of-source builds)
this should ideally NOT be a subdirectory of the source dir, as
otherwise build files get mixed with source files.
cmake {whatever cmake flags you want, none really necessary for just
making the tarball as it will be rerun later anyway} $SOURCE_DIR

then:
make package
will make binary packages, everything from windows installers to
self-extracting tgz to Mac packages is available out-of-the-box from cpack
or
make package_source
will make a source tarball. The format is in the CMakeLists.txt file
as CPACK_SOURCE_GENERATOR; right now tar.gz and tar.bz2 are on.
All it really does is compress and rename the source dir. As I
understand it unlike with autotools there is nothing to actually do
before distribution. The disadvantage is that end-users must have also
have cmake installed.

The end-user then has to decompress the source, run cmake (again, an
out-of-source build is possible), then make && make install.

Tejas Guruswamy

Post by Mark Ellis

Post by John Carr
I added support for CMake to jhbuild a while ago, and when needing to
do a "./configure && make dist" for a cmake build system, jhbuild
cmake -DCMAKE_INSTALL_PREFIX=/usr
make package_source
Doubt that the prefix thing is strictly neccesary, but i never got
round to trying it without.

Thanks John, that's a step in the right direction. I can now build a
source package, it just doesn't build :( Something to do with having the
correct cpack directives I think.
Mark

[Mark Ellis]

Post by Tejas Guruswamy
I've just checked in modifications to CMakeLists.txt that enable
cpack. Everything in that file is pretty self-explanatory, the
documentation on the cmake wiki covers most stuff.
In a separate BUILD_DIR (anywhere on your system, one of the main
ideas behind cmake is out-of-source builds)
this should ideally NOT be a subdirectory of the source dir, as
otherwise build files get mixed with source files.
cmake {whatever cmake flags you want, none really necessary for just
making the tarball as it will be rerun later anyway} $SOURCE_DIR
make package
will make binary packages, everything from windows installers to
self-extracting tgz to Mac packages is available out-of-the-box from cpack
or
make package_source
will make a source tarball. The format is in the CMakeLists.txt
file as CPACK_SOURCE_GENERATOR; right now tar.gz and tar.bz2 are on.
All it really does is compress and rename the source dir. As I
understand it unlike with autotools there is nothing to actually do
before distribution. The disadvantage is that end-users must have also
have cmake installed.
The end-user then has to decompress the source, run cmake (again, an
out-of-source build is possible), then make && make install.
Tejas Guruswamy

Nice one !

I know we've already had the name conversation, but I was just thinking
maybe it should be kio-rapip-kde4 instead of kde4-kio-rapip, and should
the package actually be synce-kio-rapip-kde4 ?

Mark

Post by Tejas Guruswamy

Post by Mark Ellis

Post by John Carr
I added support for CMake to jhbuild a while ago, and when needing to
do a "./configure && make dist" for a cmake build system, jhbuild
cmake -DCMAKE_INSTALL_PREFIX=/usr
make package_source
Doubt that the prefix thing is strictly neccesary, but i never got
round to trying it without.

Thanks John, that's a step in the right direction. I can now build a
source package, it just doesn't build :( Something to do with having the
correct cpack directives I think.
Mark

[MasterPatricko]

Post by Mark Ellis
Nice one !
I know we've already had the name conversation, but I was just thinking
maybe it should be kio-rapip-kde4 instead of kde4-kio-rapip, and should
the package actually be synce-kio-rapip-kde4 ?
Mark

Not that I mind too much, but the package naming scheme for SuSE (and
Mandriva?) has kde4 as a prefix for kde4 versions of packages. Is the
issue that Ubuntu uses kde4 as a suffix?

Tejas

[Mark Ellis]

Post by MasterPatricko

Post by Mark Ellis
Nice one !
I know we've already had the name conversation, but I was just thinking
maybe it should be kio-rapip-kde4 instead of kde4-kio-rapip, and should
the package actually be synce-kio-rapip-kde4 ?
Mark

Not that I mind too much, but the package naming scheme for SuSE (and
Mandriva?) has kde4 as a prefix for kde4 versions of packages. Is the
issue that Ubuntu uses kde4 as a suffix?
Tejas

That's what made me think of it, didn't know if there was a "standard"
so I thought I'd bring it up. Obviously there is no standard :) so we'll
keep it as it is.

Ta
Mark

[Mark Ellis]

Post by Jonny Lamb

Post by Tejas Guruswamy
My sourceforge username is masterpatricko.

You have been added as a developer to the project.

Post by Tejas Guruswamy
Since I was the only person to ever do anything with the code, are you
happy for me to just check in a new copy as the initial import and not
worry about the ~10 revisions I had?

No, that's absolutely fine.
One thing: your trunk/COPYING says GPLv2, but your Google Code front page
says MIT. The former will take precedence, but after reading the front
page, I'm wondering whether you deliberately put the GPL in your
COPYING? Please make the license very clear upon importing into our SVN.

Post by Tejas Guruswamy
I assume trunk/kde4-kio_rapip is OK as far as the naming goes.

I prefer trunk/kde4-kio-rapip to be honest, but if you are stuck on that
name, then go ahead.

Can I suggest renaming kio-rapip to kio-rapip-kde3, and making kde4 the
standard kio-rapip ? I don't really do kde, but I get the impression
kde3 is now a bit old.

Post by Jonny Lamb

Post by Tejas Guruswamy
Once the code is in the synce svn I'm happy to ask google to get rid of
the project on their servers.

Cool; that's up to you.

Post by Tejas Guruswamy
I'll split my discussion with Mark about my hal/ppp problems into
another thread if that's ok, since this title is a bit misleading for
that discussion.

Great! Welcome to the project! Nudge me when/if you want a release of it
done. I'm planning on doing a 0.12 some time next week anyway, so if you
want, I could include it there?
Thanks,
--
http://jonnylamb.com GPG: 0x2E039402

[Tejas Guruswamy]

Mark Ellis wrote:
| On Fri, 2008-07-04 at 13:43 +0200, Jonny Lamb wrote:
|> On Fri, Jul 04, 2008 at 11:12:24AM +0100, Tejas Guruswamy wrote:
|> One thing: your trunk/COPYING says GPLv2, but your Google Code front page
|> says MIT. The former will take precedence, but after reading the front
|> page, I'm wondering whether you deliberately put the GPL in your
|> COPYING? Please make the license very clear upon importing into our SVN.
|>
|>> I assume trunk/kde4-kio_rapip is OK as far as the naming goes.
|> I prefer trunk/kde4-kio-rapip to be honest, but if you are stuck on that
|> name, then go ahead.
|>
|
| Can I suggest renaming kio-rapip to kio-rapip-kde3, and making kde4 the
| standard kio-rapip ? I don't really do kde, but I get the impression
| kde3 is now a bit old.
|

So what's the decision on the naming and licensing issues? Should I wait
for a consensus or go ahead and do a checkin?

At this point both kde3 and kde4 are widely used. Maybe just rename them
both to avoid any confusion.

Also has anyone gotten the chance to test it on their machines?

Tejas Guruswamy <***@gmail.com>

[David Eriksson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|> One thing: your trunk/COPYING says GPLv2, but your Google Code front page
|> says MIT. The former will take precedence, but after reading the front
|> page, I'm wondering whether you deliberately put the GPL in your
|> COPYING? Please make the license very clear upon importing into our SVN.
|>
|>> I assume trunk/kde4-kio_rapip is OK as far as the naming goes.
|> I prefer trunk/kde4-kio-rapip to be honest, but if you are stuck on that
|> name, then go ahead.
|>
|
| Can I suggest renaming kio-rapip to kio-rapip-kde3, and making kde4 the
| standard kio-rapip ? I don't really do kde, but I get the impression
| kde3 is now a bit old.
|
So what's the decision on the naming and licensing issues? Should I wait
for a consensus or go ahead and do a checkin?

Hi!

About the licensing:

All modules I started in SynCE (libsynce, librapi2, rra, serial, dccm,
dynamite, unshield, and some others) are MIT licensed because of my
personal preference, but I have not required contributors of new modules
to use this license. This means that some other modules use the GPL. The
important thing is that there are not different licenses in the same
module! :-)

Best Regards,

David
--

[MasterPatricko]

Hi!
All modules I started in SynCE (libsynce, librapi2, rra, serial, dccm,
dynamite, unshield, and some others) are MIT licensed because of my
personal preference, but I have not required contributors of new modules
to use this license. This means that some other modules use the GPL. The
important thing is that there are not different licenses in the same
module! :-)
Best Regards,
David

The problem is that's the current state of kio-rapip. The
trunk/kio-rapip directory has COPYING = GPLv2, LICENSE = MIT, MIT
license at the header of each source file, and GPL listed as the license
in rapip.lsm.

What do I do !?!?

Tejas Guruswamy <***@gmail.com>