SynCE

On Sat, Jun 28, 2008 at 6:38 PM, Dr J A Gow <J.A.Gow@...>
wrote:

> On Sat, 2008-06-28 at 18:22 +0100, John Carr wrote:
>
> >
> > Those changes were made to support the version of pyrex in Debian
> > Unstable AFAIK. Pyrex sucks at compatibility :-)
> >
> But does the original syntax work with Debian pyrex? If so, we should
> perhaps reverse it. If not, it would seem that Debian pyrex is the
> oddball. Anybody with different distros than Debian or SuSE care to
> comment?
>
>        John.
>
>
It broke Ubuntu Hardy (r3466 is in the debian packages, so i had to patch
the patch), but the next Ubuntu will obviously be the same as Debian and so
OK. From reading the Debian bug report that lead to this change, I *think*
(was a while ago) this part of the change is only a warning in Debian right
now, so could be reverted.

I'm sure i've seen Gentoo suffer as well.

John

John

On Sat, Jun 28, 2008 at 06:14:09PM +0100, Dr J A Gow wrote:
> 	The commit of r3466 to librra breaks the build of the python
> extensions. Specifically the syntax 
> 
> for 0 <= i < count:
> 
> is not recognised by pyrex (at least the pyrex standard in OpenSuSE 11).

This did not break any builds. The use of the variable name "type" broke
Debian builds. It also warned about the "old syntax of for loops", so I
"fixed" both in that commit.

> Is there really anything so wrong with the old syntax that these parts
> of the patch should not be reversed?

Although it probably will eventually need changing to the new syntax I
used, I'm absolutely fine with it being changed back to the previous
syntax though. Feel free to commit this immediately.

I hope this helps,

-- 
Jonny Lamb, UK                                   jonnylamb@...
http://jonnylamb.com                                     GPG: 0x2E039402

On Sat, 2008-06-28 at 22:58 +0100, Jonny Lamb wrote:

> This did not break any builds. The use of the variable name "type" broke
> Debian builds. It also warned about the "old syntax of for loops", so I
> "fixed" both in that commit.
> 

Err - I'm staring at a stock unmodified openSuSE 11 system whose pyrex
won't build the python extensions with the 'new' syntax. Ergo, it breaks
builds.

I'll change this back. But you are right about the 'type' parameter -
poor choice of name there on my part. Wonder why problems did not
surface earlier with this? 

	John.

On Sun, Jun 29, 2008 at 12:23:27PM +0100, Dr J A Gow wrote:
> Err - I'm staring at a stock unmodified openSuSE 11 system whose pyrex
> won't build the python extensions with the 'new' syntax. Ergo, it breaks
> builds.

For the record, I did actually mean: the old for-loop syntax (that I
warned about on build in Debian) did not break building. I only changed
it because I was changing the "type" variable name, and saw some other
easy-to-fix warnings. I can see the ambiguity though, sorry.

-- 
Jonny Lamb, UK                                   jonnylamb@...
http://jonnylamb.com                                     GPG: 0x2E039402

On Sun, 2008-06-29 at 15:29 +0100, Jonny Lamb wrote:
> On Sun, Jun 29, 2008 at 12:23:27PM +0100, Dr J A Gow wrote:
> > Err - I'm staring at a stock unmodified openSuSE 11 system whose pyrex
> > won't build the python extensions with the 'new' syntax. Ergo, it breaks
> > builds.
> 
> For the record, I did actually mean: the old for-loop syntax (that I
> warned about on build in Debian) did not break building. I only changed
> it because I was changing the "type" variable name, and saw some other
> easy-to-fix warnings. I can see the ambiguity though, sorry.


Ah, I understand. Although does this mean that the 'old' for loop syntax
is likely to be deprecated in future python versions? Or is it just a
'cleaner' way of expressing the same thing.

	John.

On Sun, Jun 29, 2008 at 03:48:49PM +0100, Dr J A Gow wrote:
> Ah, I understand. Although does this mean that the 'old' for loop syntax
> is likely to be deprecated in future python versions? Or is it just a
> 'cleaner' way of expressing the same thing.

The warning is:

    Warning: Old-style integer for-loop is deprecated, use 'for x < i < y' instead

I guess this will answer your question, and show my reasons for
committing this change.

-- 
Jonny Lamb, UK                                   jonnylamb@...
http://jonnylamb.com                                     GPG: 0x2E039402

On Thu, 2008-06-19 at 22:19 +0200, Ilya Bakulin wrote:
> Today I've submitted several SynCE ports for approval, hope they will
> soon appear in Ports collection.
> I've also begun writing this wiki page:
> http://www.synce.org/moin/SynceInstallation/FreeBSD
> If you notice some mistakes, feel free to correct them! There are no
> links to this page yet.
> --
> Ilya Bakulin
> mailto:webmaster@...
> xmpp://kibab612@...>

Looks good ! With more testers, maybe we can work out some better hal
rules.

Mark

On Wed, 2008-06-18 at 01:05 +0200, Jonny Lamb wrote:
> Hi Mark,
> 
> I noticed your recent commit[0] adding recursive directory copy support
> to pcp. On a similar subject, how do you feel about fixing the longest
> open wishlist SynCE bug[1] on the Debian bugtracker? :-)
> 
> Regards,
> 
> 0. http://synce.svn.sourceforge.net/viewvc/synce?view=rev&revision=3491
> 1. http://bugs.debian.org/279945
> 

:) Can anyone say pandora's box...

I'm going to give a lot of the rapi tools a look over eventually, I'll
make pls top of the list.

I only started on pcp to get rid of the pcp-r bug on the sourceforge
tracker:)

Mark

On Mon, 2008-06-09 at 13:18 +0200, Daniel Frickemeier wrote:
> Hello,
> 
> I have attaced a few patches for sync-engine to work with opensync-0.36.
> 
> setup.py.patch is for sync-engine/setup.py 
> and fixes the old config.xml to syncengine.conf.xml
> 
> config.py.patch is for sync-engine/SyncEngine/config.py
> and fixes the opening of the configuration files
> 
> event-to-airsync.patch is for 
> sync-engine/SyncEngine/formats30/event-to-airsync.py and fixes an error I 
> made when I submited John the first patch for this file
> 
> task-to-airsync.patch is for 
> sync-engine/SyncEngine/formats30/task-to-airsync.py with the same error as 
> mentioned above.
> 
> bye Daniel

Do you want me to commit these in place of the patches you sent me - or
are they to be applied subsequently?

	John.

On Mon, 2008-06-09 at 13:18 +0200, Daniel Frickemeier wrote:
> Hello,
> 
> I have attaced a few patches for sync-engine to work with opensync-0.36.
> 
> setup.py.patch is for sync-engine/setup.py 
> and fixes the old config.xml to syncengine.conf.xml
> 
> config.py.patch is for sync-engine/SyncEngine/config.py
> and fixes the opening of the configuration files
> 
> event-to-airsync.patch is for 
> sync-engine/SyncEngine/formats30/event-to-airsync.py and fixes an error I 
> made when I submited John the first patch for this file
> 
> task-to-airsync.patch is for 
> sync-engine/SyncEngine/formats30/task-to-airsync.py with the same error as 
> mentioned above.
> 
> bye Daniel

All done in r3488. Sorry about the delay. I was going to commit them
with a bunch of other fixes I had coming up - but unforseen
circumstances got in the way :( So I have done them separately.

Nice to see you working on/testing formats30 - that's really helpful!

	John.

On Thu, 2008-06-05 at 11:46 +0930, Iain Buchanan wrote:
> Hi again,
> 
> sorry I'm a bit slow at trying this out atm...
> 

No problem - many thanks for your comprehensive analysis.


> First thing: config/config.xml is still listed in setup.py - I think
> it's change to config/syncengine.conf.xml and where is it supposed to go
> now? /etc?  I'm happy if you leave it out of setup.py, then the distro
> can do it.
> 

Mea culpa! Again :)

Not being a packager I tend to forget setup.py. I'll change this in the
next bunch of commits I have planned. That is right - it should go
in /etc to form the systemwide config.

> > There will be no change in functionality, but I have altered a debug
> > message to highlight the absolute path to the authorization tool. The
> > line 'auth: auth prog INTERNAL_GUI does not exist' should now read
> > 'auth: auth prog <filename> does not exist'. Can you check whether
> > <filename> is present on your system and let me know the result?
> 
> It says:
> 
> auth: auth prog /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py does not exist
> 
> and there is no authgiu.py installed anywhere.  Is this a packaging
> thing?
> 

It should be installed. It resides in 'tools'. Maybe this is not the
best place to put it as it is strictly called from sync-engine and not a
tool that can be called directly from the CLI, although it is a separate
program in its own right.

> I added
> 'tools/authgui.py',
> to setup.py, which installed it into /usr/bin (not sure if this is the
> right way), then changed AuthMethod in /etc/syncengine.conf.xml to
>       <AuthMethod>/usr/bin/authgui.py</AuthMethod>
> 
> But I see this from sync-engine:
> 2008-06-05 11:36:14,699 INFO engine.config.Config : UpdateConfig - unable to open system config file - using defaults
> 2008-06-05 11:36:14,699 INFO engine.config.Config : UpdateConfig - unable to open system config file - using defaults
> 2008-06-05 11:36:14,701 INFO engine.syncengine.kernel :  device IO2 connected
> 2008-06-05 11:36:14,702 INFO engine.syncengine.kernel : ProcessAuth : processing authorization for device 'IO2'
> auth: auth prog /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py does not exist
> 
> I checked the permissions on /etc/syncengine.conf.xml, and its readable
> by everyone.  I checked config.py and it seems to be building the
> path /etc/syncengine.conf.xml.
> 
> Finally I copied authgui.py
> to /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py and
> ran sync-engine again.  This time it worked - popping up the gui.
> 
> So in summarising, these are the questions I'm left with:
>      1. Where should syncengine.conf.xml go

The systemwide file in /etc and the user file in ~/.synce

>      2. Where should the internal authgui.py go

At the moment it sits in 'tools' and sync-engine expects it there. The
fact it is not installed sounds like a packaging problem combined with
the hardcoded relative path in sync-engine.

Packagers: Can any of the packagers reading this tell me where you would
prefer to place it? I can then adapt sync-engine to be able to see it.
>From the point of view of the source tree I think I will move it from
tools as it does not fit into the category of 'tools' as such.

>      3. Why did I see "unable to open system config file"

Normally should be because you don't have syncengine.conf.xml in /etc.
But you do :) So I should be able to repeat this problem and fix it.

>      4. Even without the internal auth gui, I was using synce-gnome to
>         authenticate - why didn't sync-engine like this?

I will have to investigate this. If sync-engine sees a pre-authenticated
device it should not try to re-authenticate. I am a kde user and do not
use gnome - could you elaborate on how synce-gnome authenticates (from a
user's perspective? I may pick up some clues from this.

	John.

On Thu, 2008-06-05 at 13:36 +0200, Dr J A Gow wrote:
> On Thu, 2008-06-05 at 11:46 +0930, Iain Buchanan wrote:
> > Hi again,
> >
> > sorry I'm a bit slow at trying this out atm...
> >
> 
> No problem - many thanks for your comprehensive analysis.
> 
> 
> > First thing: config/config.xml is still listed in setup.py - I think
> > it's change to config/syncengine.conf.xml and where is it supposed to go
> > now? /etc?  I'm happy if you leave it out of setup.py, then the distro
> > can do it.
> >
> 
> Mea culpa! Again :)
> 
> Not being a packager I tend to forget setup.py. I'll change this in the
> next bunch of commits I have planned. That is right - it should go
> in /etc to form the systemwide config.
> 
> > > There will be no change in functionality, but I have altered a debug
> > > message to highlight the absolute path to the authorization tool. The
> > > line 'auth: auth prog INTERNAL_GUI does not exist' should now read
> > > 'auth: auth prog <filename> does not exist'. Can you check whether
> > > <filename> is present on your system and let me know the result?
> >
> > It says:
> >
> > auth: auth prog /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py does not exist
> >
> > and there is no authgiu.py installed anywhere.  Is this a packaging
> > thing?
> >
> 
> It should be installed. It resides in 'tools'. Maybe this is not the
> best place to put it as it is strictly called from sync-engine and not a
> tool that can be called directly from the CLI, although it is a separate
> program in its own right.
> 
> > I added
> > 'tools/authgui.py',
> > to setup.py, which installed it into /usr/bin (not sure if this is the
> > right way), then changed AuthMethod in /etc/syncengine.conf.xml to
> >       <AuthMethod>/usr/bin/authgui.py</AuthMethod>
> >
> > But I see this from sync-engine:
> > 2008-06-05 11:36:14,699 INFO engine.config.Config : UpdateConfig - unable to open system config file - using defaults
> > 2008-06-05 11:36:14,699 INFO engine.config.Config : UpdateConfig - unable to open system config file - using defaults
> > 2008-06-05 11:36:14,701 INFO engine.syncengine.kernel :  device IO2 connected
> > 2008-06-05 11:36:14,702 INFO engine.syncengine.kernel : ProcessAuth : processing authorization for device 'IO2'
> > auth: auth prog /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py does not exist
> >
> > I checked the permissions on /etc/syncengine.conf.xml, and its readable
> > by everyone.  I checked config.py and it seems to be building the
> > path /etc/syncengine.conf.xml.
> >
> > Finally I copied authgui.py
> > to /usr/lib/python2.5/site-packages/SyncEngine/../tools/authgui.py and
> > ran sync-engine again.  This time it worked - popping up the gui.
> >
> > So in summarising, these are the questions I'm left with:
> >      1. Where should syncengine.conf.xml go
> 
> The systemwide file in /etc and the user file in ~/.synce
> 

Or for the source package stick it in somewhere
like /usr/share/sync-engine-doc, so it's available but not installed by
default. Or not, doesn't really matter.

> >      2. Where should the internal authgui.py go
> 
> At the moment it sits in 'tools' and sync-engine expects it there. The
> fact it is not installed sounds like a packaging problem combined with
> the hardcoded relative path in sync-engine.
> 
> Packagers: Can any of the packagers reading this tell me where you would
> prefer to place it? I can then adapt sync-engine to be able to see it.
> >From the point of view of the source tree I think I will move it from
> tools as it does not fit into the category of 'tools' as such.
> 

I'd say anywhere in the engine module tree. Although it's technically a
separate program it's very much part of sync-engine.

> >      3. Why did I see "unable to open system config file"
> 
> Normally should be because you don't have syncengine.conf.xml in /etc.
> But you do :) So I should be able to repeat this problem and fix it.
> 

Permissions ?

> >      4. Even without the internal auth gui, I was using synce-gnome to
> >         authenticate - why didn't sync-engine like this?
> 
> I will have to investigate this. If sync-engine sees a pre-authenticated
> device it should not try to re-authenticate. I am a kde user and do not
> use gnome - could you elaborate on how synce-gnome authenticates (from a
> user's perspective? I may pick up some clues from this.
> 

Not much time to investigate, so I'll take a guess at this.

Device is plugged in, sync-engine and synce-gnome see it needs a
password. synce-gnome provides the password, and unlocks the device.
Meanwhile, sync-engine fails to authenticate directly via _ProcessAuth,
but does see the auth state changes, and some confusion results ?

Mark

On Thu, 2008-06-05 at 19:15 +0100, Mark Ellis wrote:

> 
> Or for the source package stick it in somewhere
> like /usr/share/sync-engine-doc, so it's available but not installed by
> default. Or not, doesn't really matter.

This seems a sane approach - one for the packagers to implement.

> 
> > >      2. Where should the internal authgui.py go
> > 

> I'd say anywhere in the engine module tree. Although it's technically a
> separate program it's very much part of sync-engine.
> 

Agreed. I'll change this in the next bunch of commits.

> > >      3. Why did I see "unable to open system config file"
> > 
> > Normally should be because you don't have syncengine.conf.xml in /etc.
> > But you do :) So I should be able to repeat this problem and fix it.
> > 
> 
> Permissions ?

But these were checked and were world r/w  according to the original
message. It's worth me giving the code a once-over for hamfistedness :~)

> 
> > >      4. Even without the internal auth gui, I was using synce-gnome to
> > >         authenticate - why didn't sync-engine like this?
> > 
> > I will have to investigate this. If sync-engine sees a pre-authenticated
> > device it should not try to re-authenticate. I am a kde user and do not
> > use gnome - could you elaborate on how synce-gnome authenticates (from a
> > user's perspective? I may pick up some clues from this.
> > 
> 
> Not much time to investigate, so I'll take a guess at this.
> 
> Device is plugged in, sync-engine and synce-gnome see it needs a
> password. synce-gnome provides the password, and unlocks the device.
> Meanwhile, sync-engine fails to authenticate directly via _ProcessAuth,
> but does see the auth state changes, and some confusion results ?

Could be. I have never seen this behaviour with kde so I may have to
attempt to run it under a gnome environment to debug it. If you can
repeat this I would be interested to know, and to have a copy of your
log.

	John.

>>
>> Device is plugged in, sync-engine and synce-gnome see it needs a
>> password. synce-gnome provides the password, and unlocks the device.
>> Meanwhile, sync-engine fails to authenticate directly via _ProcessAuth,
>> but does see the auth state changes, and some confusion results ?
>
> Could be. I have never seen this behaviour with kde so I may have to
> attempt to run it under a gnome environment to debug it. If you can
> repeat this I would be interested to know, and to have a copy of your
> log.
>
>        John.
>

Just sticking my nose in. synce-gnome is tiny tiny tiny. It does
practically nothing, so you don't really need a GNOME setup to
experience it. It only depends on python, dbus and a tiny bit of gtk
to show a password box. Oh, and libnotify.

I'd actually like to see synce-gnome die and merge into tray icon or a
gnome GUI to synce-kpm.

John

On Thu, 2008-06-05 at 22:59 +0100, John Carr wrote:

> Just sticking my nose in. synce-gnome is tiny tiny tiny. It does
> practically nothing, so you don't really need a GNOME setup to
> experience it. It only depends on python, dbus and a tiny bit of gtk
> to show a password box. Oh, and libnotify.
> 
> I'd actually like to see synce-gnome die and merge into tray icon or a
> gnome GUI to synce-kpm.
> 

Hmm, interesting! I'll give it a try under kde and see if I can repeat
the problem.

	John.

On Tue, Jun 03, 2008 at 10:10:28PM +0100, Mark Ellis wrote:
> Hopefully something that will help anyone wanting to package synce-gvfs.
> 
> I've added a hack to make a self contained source package, explained in
> the README. There's a script that will copy required files from the main
> gvfs tree and fix the build system to allow a make dist, giving a
> stand-alone package.
> 
> Not ideal, but it's the best I can think of until gvfs provides for 3rd
> party backends. This is apparently planned, but I would guess not likely
> to happen soon.

I don't plan to package synce-gvfs for Debian soon for this reason:

    "The GNOME team has decided to delay the upload of nautilus 2.22 (and
    several other similar packages) to unstable. GNOME 2.22 introduced
    the new gvfs library, a replacement for the venerable gnome-vfs,
    which is, while introducing several new features, not yet completely
    regression-free. More complex file backends, such as smb, are still not
    ready for mass-deployment."[0]

Although I could prepare a package for experimental, I'm not sure if
there's really that much point.

Thanks,

0. http://lists.debian.org/debian-devel-announce/2008/06/msg00000.html

-- 
Jonny Lamb, UK                                   jonnylamb@...
http://jonnylamb.com                                     GPG: 0x2E039402

On Wed, 2008-06-04 at 04:29 +0200, Jonny Lamb wrote:
> On Tue, Jun 03, 2008 at 10:10:28PM +0100, Mark Ellis wrote:
> > Hopefully something that will help anyone wanting to package synce-gvfs.
> >
> > I've added a hack to make a self contained source package, explained in
> > the README. There's a script that will copy required files from the main
> > gvfs tree and fix the build system to allow a make dist, giving a
> > stand-alone package.
> >
> > Not ideal, but it's the best I can think of until gvfs provides for 3rd
> > party backends. This is apparently planned, but I would guess not likely
> > to happen soon.
> 
> I don't plan to package synce-gvfs for Debian soon for this reason:
> 
>     "The GNOME team has decided to delay the upload of nautilus 2.22 (and
>     several other similar packages) to unstable. GNOME 2.22 introduced
>     the new gvfs library, a replacement for the venerable gnome-vfs,
>     which is, while introducing several new features, not yet completely
>     regression-free. More complex file backends, such as smb, are still not
>     ready for mass-deployment."[0]
> 
> Although I could prepare a package for experimental, I'm not sure if
> there's really that much point.
> 

I can't fault Debian's reasoning, I think Ubuntu jumped the gun on this
one. It's a good piece of software, but not quite ready.

Mark

On Tue, 2008-06-03 at 22:10 +0100, Mark Ellis wrote:
> Hopefully something that will help anyone wanting to package synce-gvfs.
> 
> I've added a hack to make a self contained source package, explained in
> the README. There's a script that will copy required files from the main
> gvfs tree and fix the build system to allow a make dist, giving a
> stand-alone package.
> 
> Not ideal, but it's the best I can think of until gvfs provides for 3rd
> party backends. This is apparently planned, but I would guess not likely
> to happen soon.

Thanks for that, Mark. I'm currently working on synce-hal and WM2003
stuff for Mandriva, but once that's done, I'll package synce-gvfs. It's
not a major priority for me because frankly I just advise people to use
wm5torage :)
-- 
adamw