Blueman RPMBUILD issue

Blueman is the default bluetooth manager in binaries are available for Ubuntu, which seems to have an impressive list of features. The runtime dependencies and build dependencies (Requires and BuildRequires in RPM terminology) are listed in the download page, which makes writing a proper SPEC file much easier. I decided to build RPM for blueman locally and try it out.

Unfortunately, the BuildRequires listed in the blueman page are not exhaustive, and I had to do a lot of manual dependency resolving before I finally manage to get them all right. I was able to build it in one of the test machines (fully updated F10 system), but that machine didn’t have bluetooth hardware to test it.

So I copied to SPEC file to another (fully updated F10, only difference is it uses DeltaRPMs to update regularly). That is where to trouble starts. RPMBUILD mysteriously fails with error on ‘pygtk’ requirement – see the build log:

checking for pyrexc... /usr/bin/pyrexc
checking for pyrexc executable... /usr/bin/pyrexc
checking for python module gtk... yes
checking if pygtk is >= 2.12... no
configure: error: pygtk must be version 2.12 or higher
error: Bad exit status from /var/tmp/rpm-tmp.BO3Mzo (%build)

But I do have pygtk2-2.13! So I decided to check if blueman builds locally – unzipped the tar ball, and did a ./configure (with all the parameters that RPMBUILD passes to it), which succeeds the ‘pygtk is >= 2.12′ check and builds perfectly ! WTH??

I’ve been sitting on the issue for couple of days, and this morning I gave it a closer look. The only difference between local build and RPMBUILD is that, RPMBUILD sets the environment variables LANG, CFLAGS, CXXFLAGS, FFLAGS; unsets DISPLAY and exports them all.

So, I set/unset and exported all the env variables accordingly on the local build also, and doh – the “./configure” fails with the same ‘pygtk2′ error! To narrow down the issue, I eliminated the env vars one by one, and managed to zero in on “unset DISPLAY”.

If I don’t unset DISPLAY, blueman builds perfectly. Any idea what’s going on?

Update 1:

OK, I confirmed that un-setting DISPLAY is the culprit. The configure script checks for pygtk version as follows:

python -c '
import gtk, sys
(maj, mid, min) = gtk.pygtk_version
if maj != 2 or mid < 12:
sys.exit(1) '

On un-setting the DISPLAY, it generates the following dump:

Traceback (most recent call last):
File "<string>", line 2, in <module>
File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line 79, in <module>
_init()
File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line 67, in _init
_gtk.init_check()
RuntimeError: could not open display

But why the heck doesn’t it show up in my other test box?

Update 2:

The other test box doesn’t do either “LANG=C; export LANG” or “unset DISPLAY” ! And that is why it is not failing. Once I do a local ‘./configure’ with DISPLAY unset, it fails there as well.

What puzzles me is that both machines have the same RPM/RPMBUILD version – 4.6.0-1.

Huh.

Update 3:

There is an upstream bug for this at https://bugs.edge.launchpad.net/blueman/+bug/337877, which is fixed now. The proper way to check pygtk dependency is to use pkg-config. I’ve adapted another hack directly to the configure script, now Blueman is built on my system and happily using it. A big boquet of thanks to Nushio !

blueman

About these ads

18 thoughts on “Blueman RPMBUILD issue

  1. Hi there,

    I actually built my very first RPM based on Blueman.

    I took the lazy route and didn’t softcode all paths, but so far most users have reported that my package works.

    Anyways, RPM’s available here: http://proyectofedora.org/mexico/2009/02/18/maneja-tu-bluetooth-con-blueman/

    If I recall correctly, I did have to mess with the src files a tiny bit.

    I’ll try to dig up the stuff I changed, I didn’t write it down…

    Hope to help get this officially into Fedora soon!

  2. Ok, I got my file, all I changed was the configure.

    I’m trying to remember which lines I changed, but I do have the configure file I changed if you want it.

    -Nushio

  3. Can you please explain where you got the impression that blueman is default bluetooth manager in Ubuntu. It is not even in repositories.

  4. @ Nushio:
    Thanks for the attention. I checked your source rpm, it seems to lack a lot of BuildRequires and Requires. Further, file listing can be simplified. I will upload my spec file tonight and send you a link. Please have a look. Thanks again!

    @ Onkar:
    Thanks for the correction – it is not default in Ubuntu 9.04 AFAICS. IIRC, I read from a news site sometime back that it is/will be. But, I can very well see that it is in launchapad repositories.

  5. @ Rajeesh: Its my first specfile and first RPM.

    I took the lazy route and hardcoded a lot of the paths to the files, instead of using the tags.

    I’ve installed that RPM in several laptops and my desktop, and if you install from yum (double click), it’ll install fine. That rpm had issues when installing from commandline “rpm -Ivh file.rpm”.

  6. Hi Rajeesh,

    According to walmis, the configure file was fixed in SVN and should come in 1.03: http://blueman-project.org/forum/viewtopic.php?f=6&t=164&p=572#p571

    As for your specfile…

    I got the following error:
    RPM build errors:
    Installed (but unpackaged) file(s) found:
    /usr/share/hal/fdi/information/20thirdparty/11-blueman-bnep.fdi

    So I added:
    %{_datadir}/hal/fdi/information/20thirdparty/11-blueman-bnep.fdi

    which seemed to be missing. Now it works :-) (Using my configure hack posted above)

    I’ve been comparing your SPEC to mine, I definitely have a ton to learn.

  7. Hey Rajeesh, inspired by your post, I decided to sign up as a Package Mantainer at Fedora and to manage Blueman!

    The one thing is that as you might’ve noticed, I’m very very new to building RPMs.

    Any links you might points me to besides those already in the Fedora Wiki would be greatly appreciated.

    I’m glad to be of service!

  8. Dear Nushio,
    Really glad to know that. Believe me, the Fedora wiki pages are the best for Package Management. And yes, surfing through lot of existing packages and see how they are written.
    Best of luck for your endeavour!

  9. Hey Rajeesh,

    I’ve been having some progress in RPM Building.
    I’ve followed the steps so far, and created this ticket: https://bugzilla.redhat.com/show_bug.cgi?id=489564

    My problem right now stands in compiling the package in non-i386 using Koji.
    This is the error I got: http://koji.fedoraproject.org/koji/getfile?taskID=1238868&name=build.log

    If you have a few minutes to check it out and can point me to the right direction, I’d greatly appreciate it.

    Thanks for your time!
    -Nushio

  10. Nushio,

    That build error was due to missing %{python-sitearch}/* in the %files section. Looks like you have fixed it in the SPEC file. Do you still face the problem?

  11. About the different rpmbuild behavior between your two machines: do you have redhat-rpm-config installed in one but not the other?

    Got me (and, independently, Martin Sourada) confused when the binaries in RPMs we build locally were not being stripped.

  12. @Michel:
    I’m using mock to build my packages. I do have redhat-rpm-config installed locally and it does compile here as i386, but not as 64 bits.

    @Rajeesh:
    I added the python-sitearch and even made python >= 2.5 and python-devel >= 2.5 as a dependency. No luck so far building packages…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s