[pkg-fso-maint] fso: state of packaging?

Heiko Stübner heiko at sntech.de
Mon Sep 14 19:42:09 UTC 2009


Hi,

Am Montag 14 September 2009 20:47:20 schrieb Nikita V. Youshchenko:
> > Another issue is that FSO changes everything ever now and again, and one
> > loses touch with what upstream is doing. Joachim mentioned that he "lost
> > the overlook a bit".
> >
> > I instead did not dare to look at the packages that Heiko has made
> > because I completely lost upstream. There is such a tangle of packages
> > and libraries with similar names, some of which are alternatives, some
> > of which are outdated, some of which are the future but do not work yet,
> > or break some application that everyone is using unless we update it to
> > somesuch version only found in someone's personal git plus the patch
> > posted in another mailing list a month ago. Or something like that.
> >
> > I would welcome a summary of what packages are now needed for what, and
> > I guess that it would help more than myself.
>
> Seconded.
Ok, I will try to summarise the parts that I'm working on at the moment.

As you know fso-frameworkd consists of some individual subsystems [e.g 
ousaged, odeviced, ogsmd, ...] that are implemented in python. Upstream 
replaces these subsystems step-by-step with in vala reimplemented versions.

The most notable one is fsousaged which replaces the similiar named original 
subsystem. This was sped up by upstream as the original one had bugs that 
could not easily be resolved in the python implementation.

-- 
So you need fso-frameworkd, fso-usaged, whatever libraries it depends on and 
the config-snapshot posted here and added to the openmoko-files-config git 
repository yesterday. (It deactivates ousaged and activates fsousaged instead)
--

I think the next step will be the odeviced to fsodeviced and then somewhere 
the osgmd to fsogsmd transition.

For completenes sake some words about the libraries as I understand it:
- libfso-glib: it seems to be some kind of interface-definition, as it is 
generated out of the xml-specification of the dbus-interface
- libfsobasics: like it says :-), basis for libfsoframework and 
libfsotransport [logging and such]
- libfsoframework: plugin-handling etc.

Libraries that are in some premature states but are working for me:
- libgsm0710: gsm-protocol implementation based on some code of Trolltech
- libfsotransport: something about serial communication
- libgsm0710mux: Muxer-Implementation, needs libgsm0710
fso-abyss is simply frontend for libgsm0710mux to communicate with ogsmd until 
fsogsmd is ready, which will then be linked directly against libgsm0710mux

The hardest problem is at the moment to always find stable combinations of 
libraries and programms that also work with current vala in debian.
Everytime a new vala-version is released and the vala-maintainers upload it 
the fso-guys have some catching-up to do for it most of the time. But when 
this is done, older (e.g officially released) versions of the libraries cannot 
be used anymore as they are then incompatible with the newer vala-version.
Vala seems to me to be highly volatile from version to version.

Just to ease Enricos fears: fsousaged can be deactivated any time by simply 
commenting out the fsousaged and reactivating ousaged :-)

Hope this explanations helped a little bit
Heiko



More information about the pkg-fso-maint mailing list