[Synce-devel] debian svn packages

[Mark Ellis]

Hi All

I've put up some deb's I use, svn snapshots mostly of the packages I
work on and anything they depend on. If you want to give them a try, add
this to /etc/apt/sources.list

deb http://www.mpellis.org.uk/debian/ unstable main
deb-src http://www.mpellis.org.uk/debian/ unstable main

and to keep apt happy about keys

gpg --keyserver pgpkeys.mit.edu --recv-key EEA242F0
gpg -a --export EEA242F0 | sudo apt-key add -

Have fun, any comments more than welcome.

Mark

[John Carr]

Post by Mark Ellis
Hi All
I've put up some deb's I use, svn snapshots mostly of the packages I
work on and anything they depend on. If you want to give them a try, add
this to /etc/apt/sources.list
deb http://www.mpellis.org.uk/debian/ unstable main
deb-src http://www.mpellis.org.uk/debian/ unstable main
and to keep apt happy about keys
gpg --keyserver pgpkeys.mit.edu --recv-key EEA242F0
gpg -a --export EEA242F0 | sudo apt-key add -
Have fun, any comments more than welcome.
Mark

Hi Mark

Thanks for this, will save me some time later today :-) Other than them
being SVN snapshots do they do anything fancy that we can backport into the
official synce debs of 0.10 (and eventually 0.11) which jonnylamb is leading
towards debian proper? E.g. fancy start scripts, or things we havent already
packaged?

Note to ubuntu users on this list, the ubuntu gutsy packages are at:

deb http://ppa.launchpad.net/synce/ubuntu gutsy main
deb-src http://ppa.launchpad.net/synce/ubuntu gutsy main

John

[Mark Ellis]

Post by Mark Ellis
Hi All
I've put up some deb's I use, svn snapshots mostly of the packages I
work on and anything they depend on. If you want to give them a try, add
this to /etc/apt/sources.list
deb http://www.mpellis.org.uk/debian/ unstable main
deb-src http://www.mpellis.org.uk/debian/ unstable main
and to keep apt happy about keys
gpg --keyserver pgpkeys.mit.edu --recv-key EEA242F0
gpg -a --export EEA242F0 | sudo apt-key add -
Have fun, any comments more than welcome.
Mark
Hi Mark
Thanks for this, will save me some time later today :-) Other than
them being SVN snapshots do they do anything fancy that we can
backport into the official synce debs of 0.10 (and eventually 0.11)
which jonnylamb is leading towards debian proper? E.g. fancy start
scripts, or things we havent already packaged?
deb http://ppa.launchpad.net/synce/ubuntu gutsy main
deb-src http://ppa.launchpad.net/synce/ubuntu gutsy main
John

Hi John
Most of it follows Jonny's and/or the 0.9.x stuff in the debian
archive.

The most significant difference is an init script that gets installed
for odccm, but if it's used with odccm 0.10.0 it'll always show a fail
on startup, odccm has started ok but always returns failure, I've fixed
it in svn.
I tried some funky stuff to automatically set up start/stop links, but
upgrades require some careful planning so I disabled that. Oh and of
course my odccm is configured to --enable-legacy.

Since we're on this, I'll throw out some ideas for consideration.

1) Some stuff in svn has out of date debian dirs, I think this should
either be kept up to date or removed entirely, otherwise it confuses the
situation. The deb patches may be better kept somewhere else in svn.

2) There are a few small items in the current deb archive packages that
we could put into svn ie small fixes and man pages. I've done some, eg
with liborange I think, but if anyone else has the time, inclination and
unserstanding to have a quick look this could be useful.

Thoughts ?

Mark

[John Carr]

Hi Mark

Hi John

Post by Mark Ellis
Most of it follows Jonny's and/or the 0.9.x stuff in the debian
archive.
The most significant difference is an init script that gets installed
for odccm, but if it's used with odccm 0.10.0 it'll always show a fail
on startup, odccm has started ok but always returns failure, I've fixed
it in svn.

One thing i've been talking to ubuntu about (and oleavr) is triggering odccm
from udev (or a hal callout). Then it would attach to a hal removal event to
close itself. Any useful information about the device would be pushed in to
HAL, rather than accessed through odccm - that includes information needed
to connect to the device. Odccm would then just do keep alive. Thoughts on
this would be appreciated. For example, i'm not really sure how that would
work with multiple devices, although i'm not sure if odccm even supports
multiple devices anyway.

I tried some funky stuff to automatically set up start/stop links, but

Post by Mark Ellis
upgrades require some careful planning so I disabled that. Oh and of
course my odccm is configured to --enable-legacy.

On that note, I think legacy should be switched on by default out of the
box, with a --disable-legacy option instead... It won't hurt WM5/6 users and
could save support questions.

Since we're on this, I'll throw out some ideas for consideration.

Post by Mark Ellis
1) Some stuff in svn has out of date debian dirs, I think this should
either be kept up to date or removed entirely, otherwise it confuses the
situation. The deb patches may be better kept somewhere else in svn.

Conduit used to have its own debian dirs, and we were told that this is
sometimes frowned upon by packagers. So I'd vote to drop them...

2) There are a few small items in the current deb archive packages that

Post by Mark Ellis
we could put into svn ie small fixes and man pages. I've done some, eg
with liborange I think, but if anyone else has the time, inclination and
unserstanding to have a quick look this could be useful.

Agreed, although we maybe lacking on volunteers. We can't even muster a
documentation effort at the moment..

John

[Mark Ellis]

Post by Mark Ellis
The most significant difference is an init script that gets installed
for odccm, but if it's used with odccm 0.10.0 it'll always show a fail
on startup, odccm has started ok but always returns failure, I've fixed
it in svn.
One thing i've been talking to ubuntu about (and oleavr) is triggering
odccm from udev (or a hal callout). Then it would attach to a hal
removal event to close itself. Any useful information about the device
would be pushed in to HAL, rather than accessed through odccm - that
includes information needed to connect to the device. Odccm would then
just do keep alive. Thoughts on this would be appreciated. For
example, i'm not really sure how that would work with multiple
devices, although i'm not sure if odccm even supports multiple devices
anyway.

I thought about something like this, but not for long, too much else to
do :) As far as multiple devices with odccm, I've not tested anything,
but it's close. For ppp connections, ie pre WM5, some adjustments to
synce-serial will be needed, but odccm should deal with them after that.
For WM5, it'll only autoconfigure one interface at the moment.

Post by Mark Ellis
I tried some funky stuff to automatically set up start/stop links, but
upgrades require some careful planning so I disabled that. Oh and of
course my odccm is configured to --enable-legacy.
On that note, I think legacy should be switched on by default out of
the box, with a --disable-legacy option instead... It won't hurt WM5/6
users and could save support questions.

I would tend to agree, especially now I'm confident it works.

Post by Mark Ellis
Since we're on this, I'll throw out some ideas for
consideration.
1) Some stuff in svn has out of date debian dirs, I think this should
either be kept up to date or removed entirely, otherwise it confuses the
situation. The deb patches may be better kept somewhere else in svn.
Conduit used to have its own debian dirs, and we were told that this
is sometimes frowned upon by packagers. So I'd vote to drop them...
2) There are a few small items in the current deb archive packages that
we could put into svn ie small fixes and man pages. I've done some, eg
with liborange I think, but if anyone else has the time, inclination and
unserstanding to have a quick look this could be useful.
Agreed, although we maybe lacking on volunteers. We can't even muster
a documentation effort at the moment..

I think I might have a look at this now, hopefully shouldn't take too
long.

Mark

[Mark Ellis]

Post by Mark Ellis

Post by Mark Ellis
2) There are a few small items in the current deb archive packages that
we could put into svn ie small fixes and man pages. I've done some, eg
with liborange I think, but if anyone else has the time,
inclination and
unserstanding to have a quick look this could be useful.
Agreed, although we maybe lacking on volunteers. We can't even muster
a documentation effort at the moment..

I think I might have a look at this now, hopefully shouldn't take too
long.

Ok, so I've been going through this stuff, and I've come across
something I hope someone can help with. The deb diff for liborange
contains this snippet

@@ -190,7 +190,7 @@
#endif
} TSetupFileEntry;

-P typedef struct
+typedef struct
{
uint32_t FirstDisk;
uint32_t LastDisk;
@@ -201,7 +201,7 @@
uint32_t Date;
uint32_t FileVersionMS;
uint32_t FileVersionLS;
-} TSetupFileLocationEntry;
+} P TSetupFileLocationEntry;


where P has been defined as
#define P __attribute__((packed))

Now I have no idea about attributes, so does anyone know which of these
options are correct and/or superior ?

Ta
Mark

[David Eriksson]

Post by Mark Ellis

Post by Mark Ellis

Post by Mark Ellis
2) There are a few small items in the current deb archive
packages that
we could put into svn ie small fixes and man pages. I've done
some, eg
with liborange I think, but if anyone else has the time,
inclination and
unserstanding to have a quick look this could be useful.
Agreed, although we maybe lacking on volunteers. We can't even muster
a documentation effort at the moment..

I think I might have a look at this now, hopefully shouldn't take too
long.

Ok, so I've been going through this stuff, and I've come across
something I hope someone can help with. The deb diff for liborange
contains this snippet
@@ -190,7 +190,7 @@
#endif
} TSetupFileEntry;
-P typedef struct
+typedef struct
{
uint32_t FirstDisk;
uint32_t LastDisk;
@@ -201,7 +201,7 @@
uint32_t Date;
uint32_t FileVersionMS;
uint32_t FileVersionLS;
-} TSetupFileLocationEntry;
+} P TSetupFileLocationEntry;
where P has been defined as
#define P __attribute__((packed))
Now I have no idea about attributes, so does anyone know which of these
options are correct and/or superior ?

That's Inno Setup support, right? Is that file even included in the build?
I don't think it works very well anyway...

\David

[Mark Ellis]

Post by David Eriksson

Post by Mark Ellis
where P has been defined as
#define P __attribute__((packed))
Now I have no idea about attributes, so does anyone know which of these
options are correct and/or superior ?

That's Inno Setup support, right? Is that file even included in the build?
I don't think it works very well anyway...
\David

Thanks David, hadn't thought it wasn't built by default. After building
it (doh) answered my own question.

Mark

[Jonny Lamb]

Hi.

Sorry for only just noticing this! :-)

Post by Mark Ellis
The most significant difference is an init script that gets installed
for odccm, but if it's used with odccm 0.10.0 it'll always show a fail
on startup, odccm has started ok but always returns failure, I've fixed
it in svn.

Awesome! I failed at writing an init script for odccm and I thought it
was just me being an idiot!

Post by Mark Ellis
Since we're on this, I'll throw out some ideas for consideration.
1) Some stuff in svn has out of date debian dirs, I think this should
either be kept up to date or removed entirely, otherwise it confuses the
situation. The deb patches may be better kept somewhere else in svn.

These probably should go. Once I sort out why git isn't behaving
itself, my packaging repositories will be hosted on git.jonnylamb.com.
Once 0.11 is released (whenever that is), I will make a big push to get
these packages into Debian, which'll be cool.

Regards,