Avahi recipe

GoogleGroups
1

Hey all,

For the last several days, I've been trying to figure out how to get task-base to produce a minimal image. Currently the problem I'm experiencing is the following dependency chain,

task-base -> avahi-daemon -> avahi-python -> pygtk -> gtk+ -> xorg

Now, I'm it seems that avahi-python provides avahi-daemon because it builds all of avahi but with --enable-python, which the usual avahi-daemon package lacks. This is fine however bitbake seems to want to pull in avahi-python despite my stated preferences to do otherwise,

> $ bitbake -DD -n task-base
> ...

DEBUG: providers for avahi-daemon are: ['avahi-python', 'avahi']
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-daemon due to PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-daemon are: ['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb', '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to satisfy runtime 'avahi-daemon'

> ...

DEBUG: Added runtime recommendation avahi for /mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy runtime 'avahi-daemon'
DEBUG: Added dependency pkgconfig-native for /mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb

> ...

A similar thing happens when processing avahi-autoipd,

DEBUG: providers for avahi-autoipd are: ['avahi-python', 'avahi']
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-autoipd due to PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-autoipd are: ['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb', '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to satisfy runtime 'avahi-autoipd'
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy runtime 'avahi-autoipd'

After this, hilarity ensues as avahi-python adds python-pygtk, which in turn adds gtk+ which in turn adds most of Xorg (which I seek to avoid). Why does bitbake decide to add both avahi-python and avahi when satisfying avahi-daemon and avahi-autoipd? Isn't it supposed to only pick one of the providing packages (preferably the preferred package)? I'm quite confused. Any input you could provide you be greatly appreciated. Thanks,

- Ben

2

Furthermore, I just attempted to remove the dependency on avahi
altogether by adding the following to task-base.bb,

BAD_RECOMMENDATIONS = "avahi-daemon avahi-autoipd"

Despite this, it pulled in both packages. This I am truly baffled by. Ideas?

- Ben

3

Ben Gamari wrote:

Furthermore, I just attempted to remove the dependency on avahi
altogether by adding the following to task-base.bb,

BAD_RECOMMENDATIONS = "avahi-daemon avahi-autoipd"

Despite this, it pulled in both packages. This I am truly baffled by. Ideas?

I am not sure whether it will not break Zeroconf support in full builds
of the same distro.

Another possible solutions:

- Branch a new minimal avahi-less distribution.

- Split avahi to more parts (or even better, to more stages to allow
complete build and prevent build loops), just to avoid unwanted build
loops and dependencies. (core, stuff that require glib&gtk, mono stuff,
qt3 stuff, qt4 stuff) and then include only low level avahi parts.

The trick:
http://avahi.org/ticket/222#comment:2

Avahi contains both low level and high level utilities.

Library is required by many low level libraries.

Low level daemons require only dbus.

Python is required for avahi-bookmarks and other python utilities.

GTK is required for avahi GUI.

glib is required for avahi glib bindings.

mono is required for avahi C# bindings.

qt* is required for avahi qt* bindings.

4

Ben Gamari wrote:

Furthermore, I just attempted to remove the dependency on avahi
altogether by adding the following to task-base.bb,

BAD_RECOMMENDATIONS = "avahi-daemon avahi-autoipd"

Despite this, it pulled in both packages. This I am truly baffled
by. Ideas?

BAD_RECOMMENDATIONS works at image time, not at dependency time.

I am not sure whether it will not break Zeroconf support in full
builds
of the same distro.

Another possible solutions:

- Branch a new minimal avahi-less distribution.

by 'distribution' you mean 'image', right?

5

So in that case there is absolutely nothing that can be done to eliminate about a days worth of unnecessary compilation without editing task-base.bb? Something doesn't seem right with this picture. Why is there no way to eliminate recommendations at build time? Building all of Gnome just for the sake of building it seems a little absurd. Is this just a known limitation of BAD_RECOMMENDATIONS?

6

Can you start your image from task-boot?

Have you tried using || make? That can make a huge difference in build time?

Is your concern the size of the final image you are getting from OE,
or the time it takes to create the image?

Philip

7

Ben Gamari wrote:

Hey all,

For the last several days, I've been trying to figure out how to get
task-base to produce a minimal image. Currently the problem I'm
experiencing is the following dependency chain,

> NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
> NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8

I guess I got the problem:

Version 0.6.24 is already decently split and you can install
avahi-autoipd without triggering additional dependencies. This is not
valid for version 0.6.21 triggered in your build.

I guess that it's caused by
distro/include/preferred-om-2008-versions.inc.

Remove three avahi related lines from it and try again.

8

Can you start your image from task-boot?

I have started with task-boot but I would like something closer to task-base.

Have you tried using || make? That can make a huge difference in build time?

Not entirely sure what you mean by this. You mean the bashism,
" || make"?

Is your concern the size of the final image you are getting from OE,
or the time it takes to create the image?

Honestly, a little bit of both. The amount of time it takes to create the image is a bit of an (as far as I can see, unnecessary) annoyance, but isn't the end of the world. Really, I would just like a clean image. It's just unnerving when things are being built that I don't have any intention of using.

None of this is that big of a deal (it's only for a school project), however I would like to try and get this issue resolved cleanly. It seems ridiculous that there isn't a more precise way of specifying one's requirements for the image. If BAD_RECOMMENDATIONS were effective at dependency time, I think that would be an ideal solution.

- Ben

9

I guess I got the problem:

Version 0.6.24 is already decently split and you can install
avahi-autoipd without triggering additional dependencies. This is not
valid for version 0.6.21 triggered in your build.

I guess that it's caused by
distro/include/preferred-om-2008-versions.inc.

Remove three avahi related lines from it and try again.

Nope, no dice. In fact, things are getting even stranger:

DEBUG: providers for avahi-daemon are: ['avahi-python', 'avahi']
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-daemon due to PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-daemon are: ['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb', '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to satisfy runtime 'avahi-daemon'

> ...

DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy runtime 'avahi-daemon'

> ...

DEBUG: providers for avahi-autoipd are: ['avahi-python', 'avahi']
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-autoipd due to PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-autoipd are: ['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb', '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to satisfy runtime 'avahi-autoipd'
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy runtime 'avahi-autoipd'

It's apparently still trying to install 0.6.21 for some reason, but this time in addition to 0.6.24. Odd. Any ideas?

- Ben

10

Hi,

replacing openembedded-users with openembedded-devel
(http://lists.linuxtogo.org/pipermail/openembedded-users/2009-March/000978.html).

I guess I got the problem:

Version 0.6.24 is already decently split and you can install
avahi-autoipd without triggering additional dependencies. This is not
valid for version 0.6.21 triggered in your build.

I guess that it's caused by
distro/include/preferred-om-2008-versions.inc.

Remove three avahi related lines from it and try again.

Nope, no dice. In fact, things are getting even stranger:

DEBUG: providers for avahi-daemon are: ['avahi-python', 'avahi']
DEBUG: update_data()
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-daemon due to
PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-daemon are:
['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb',
'/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to
satisfy runtime 'avahi-daemon'

...

DEBUG: adding
'/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy
runtime 'avahi-daemon'

...

DEBUG: providers for avahi-autoipd are: ['avahi-python', 'avahi']
DEBUG: update_data()
DEBUG: update_data()
NOTE: checking PREFERRED_PROVIDER_avahi-python
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21
NOTE: checking PREFERRED_PROVIDER_avahi-python-0.6.21-r8
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: checking PREFERRED_PROVIDER_avahi
NOTE: selecting avahi to satisfy runtime avahi-autoipd due to
PREFERRED_PROVIDER_avahi = avahi
DEBUG: sorted providers for avahi-autoipd are:
['/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb',
'/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb']
DEBUG: adding '/mnt/oe/oe/openembedded/packages/avahi/avahi_0.6.24.bb' to
satisfy runtime 'avahi-autoipd'
DEBUG: adding
'/mnt/oe/oe/openembedded/packages/avahi/avahi-python_0.6.21.bb' to satisfy
runtime 'avahi-autoipd'

It's apparently still trying to install 0.6.21 for some reason, but this
time in addition to 0.6.24. Odd. Any ideas?

Those messages do not mean that the recipes will be actually built. If
I'm not mistaken, bitbake is just considering alternatives here.
Especially this ...

NOTE: selecting avahi to satisfy runtime avahi-autoipd due to
PREFERRED_PROVIDER_avahi = avahi

... part sounds like it's going to do the right thing.

I have the same messages in my -DD log. When I call "DISTRO=angstrom
bitbake task-base" on a clean tmp, it just builds avahi (0.6.24), not
avahi-python (0.6.21) or any of its additional dependencies.

regards
Philipp

11

pHilipp Zabel wrote:

>> I guess that it's caused by
>> distro/include/preferred-om-2008-versions.inc.
>>
>> Remove three avahi related lines from it and try again.
>>
>
> Nope, no dice. In fact, things are getting even stranger:

Ben, what will happen, it you remove avahi_0.6.21.bb from the tree?
Maybe it poisons the dependency checker?

12

Can you start your image from task-boot?

I have started with task-boot but I would like something closer to
task-base.

Have you tried using || make? That can make a huge difference in build time?

Not entirely sure what you mean by this. You mean the bashism,
" || make"?

I am lazy, parallel make, I have a dual core machine and have:

PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

set.

Philip

13

I am lazy, parallel make, I have a dual core machine and have:

PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Might be a bit off topic, but can OE utilize building on several different
PCs in parallel?
  Søren

14

angstrom doesn't use openmoko config files.

regards,

Koen

15

I was going to say you could use distcc but the use a cross compiler would definitely complicate things. This use-case is probably a little beyond distcc's capabilities. That being said, if you mounted the OpenEmbedded root over NFS, you might be able to jury-rig something but I shutter to think of all of the things that might go wrong. Sounds like a bad idea.

- Ben

16

Ahhh, clever reference. Yes, I have parallel make enabled (although I didn't set BB_NUMBER_THREADS, is that necessary?). Nevertheless, I would really like to see the underlying issue fixed.

- Ben

17

Indeed, after removing all of the avahi recipes other than _0.6.24.bb
things work roughly as expected (i.e. no gtk+). Still 2000 packages with
a few Xorg packages (libsm required by gstreamer, etc), but I probably
just have high expectations. Would it be possible to remove avahi
versions prior to 0.6.24 from the repository?

- Ben

18

Ben Gamari wrote in Fri 03/13 2009 at 15:20 -0400:

> Ben, what will happen, it you remove avahi_0.6.21.bb from the tree?
> Maybe it poisons the dependency checker?

Indeed, after removing all of the avahi recipes other than _0.6.24.bb

It sounds like a bug of dependency checker.

things work roughly as expected (i.e. no gtk+). Still 2000 packages with
a few Xorg packages (libsm required by gstreamer, etc), but I probably
just have high expectations.

It's almost surely fixable. Only few modules need X libraries. You
should just exclude these.

Would it be possible to remove avahi
versions prior to 0.6.24 from the repository?

Ask maintainers of distros with:

PREFERRED_VERSION_avahi-python ?= "0.6.21"

Note: Preferring different versions of particular avahi sub-packages is
almost surely incorrect.

It's Openmoko. I guess that upgrade of avahi is sane. There is just one
important issue to check or fix (bug in libdaemon which triggers dead
loop in avahi):
https://bugzilla.novell.com/show_bug.cgi?id=469342