Re: CVS/JHBuild complaints

["Elijah Newren" <newren gmail com>]

On 7/23/06, Luca Ferretti <elle uca libero it> wrote:
> Il giorno sab, 22/07/2006 alle 12.48 -0600, Brent Smith ha scritto:
> > * avahi depends on dbus-python and dbus-glib bindings set; dbus-python
> > and dbus-glib are now in a git repository (bug 347674); need to add to
> > modulesets and add appropriate dependencies
>
> I've commited the patch just now. Unfortunately no way to build a python
> (setup.py) module in jhbuild.. Or not? Any info?
>
> > * dbus-python depends on Pyrex for bindings which aren't included in
> > jhbuild bootstrap
>
> I don't think we need to put it in bootstrap, but yes, we need it.
> Unfortunately, as above, installation based on setup.py :-(

I don't know if James' recent refactoring included a fix to handle
such python modules or not, but I'm guessing it didn't and so building
such modules with jhbuild is not yet possible (see also
http://bugzilla.gnome.org/show_bug.cgi?id=311563#c3)

> My suggestion (and the proper solution, I think) is write this info in
> live.gnome.org/JhbuildIssues/* pages. Please create a new page for
> dbus-python and add here relevant info. (download Pyrex, unpack and run
> `jhbuild run python setup.py install`)

I'd just call that helping others with workarounds (which is
definitely a good thing), not a solution by any means.

> > * PolicyKit needs --disable-docbook-docs, or make fails due to missing
> > command "no" (f.d.o. bug 7161)
> >
> > * PolicyKit needs --with-pam-module-dir=prefix + '/lib' so it doesn't
> > try to install into /lib
>
> Add custom rules to general moduleset is not good IMHO. When, for
> istance, bug 7161 will be fixed, the custom rule to general moduleset
> will be deprecated.

Uh... (freedesktop) bug 7161 is just about making the build error
understandable by humans; it wouldn't deprecate or change any kind of
build rules.  Personally, I see nothing wrong with adding either of
these rules to the modulesets -- I was considering doing so myself a
few weeks ago.

I think the real fix here, though, is that we need to get to the point
where we only depend on stable versions of hal and dbus (i.e.
vendor-provided versions) and remove them from the (default) build
altogether.  Our dependencies on unstable freedesktop modules,
especially ones going relatively deep in the stack, is getting kind of
insane -- especially since they all have their own "release cycles"
and rules.

> > * libvolume_id needs to be installed for hal; should this be part of
> > jhbuild bootstrap or should the user be responsible for installing the
> > development package from their distro?  I ended up getting around this
> > by doing the following:
> >
> > cvs -d :pserver:anonymous anoncvs freedesktop org:/cvs/hal co -D 'Jul 10
> > 18:30:00 2006 UTC' hal
>
> This is a serious issue. libvolume_id should be in udev > 0.9x (or
> similar). So you should install it, maybe breaking your distro.
>
> Should we depend on latest HAL package? I suggest you to open a bug
> about it.

I hope we can say no to that question, at least in time for future
releases if not currently.  Do any modules currently depend on it?
Would it cause problems to any modules to cap the version of hal on
which modules can depend early on in the release cycle, and preferably
even just use distributor versions of hal?  I know dbus is getting
close to the point where we can do that, which will be a great relief.