On Wed, 2007-11-28 at 13:44 +0000, John Carr wrote: > 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. > > > 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. > > > 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 ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel