| Submitter | Radu Moisan |
|---|---|
| Date | July 26, 2012, 6:17 a.m. |
| Message ID | <1343283462-25435-1-git-send-email-radu.moisan@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/33103/ |
| State | New |
| Headers | show |
Comments
it does not build, it complains about nothing providing dbus-x11 Radu On 07/26/2012 09:17 AM, Radu Moisan wrote: > Followed suggestions from Bugz 2261: > > 1) remove the --with-x/--without-x configure arguments. If you want to force > no-discovery for native builds the correct argument is --disable-x11-autolaunch. > This ensures that DBus looks at the build environment to determine whether to > enable X11 bus discovery or not. > > 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature. > This makes the build dependencies reflect the feature list. > > 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency > is now back in dbus where is belongs. > > 4) Potentially make dbus provide dbus-x11, for compatibility. > > Fixes [Yocto #2261] > > Signed-off-by: Radu Moisan <radu.moisan@intel.com> > --- > meta/recipes-core/dbus/dbus.inc | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc > index a75583d..9559f6f 100644 > --- a/meta/recipes-core/dbus/dbus.inc > +++ b/meta/recipes-core/dbus/dbus.inc > @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session > > DEBIANNAME_${PN} = "dbus-1" > > -PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}" > +PACKAGES =+ "${PN}-lib ${PN}-systemd" > > -FILES_${PN}-x11 = "${bindir}/dbus-launch" > -RDEPENDS_${PN}-x11 = "${PN}" > +# for compatibility > +RREPLACES_${PN} += "dbus-x11" > > FILES_${PN}-systemd = "${systemd_unitdir}/system/" > > @@ -43,6 +43,7 @@ FILES_${PN} = "${bindir}/dbus-daemon* \ > ${bindir}/dbus-cleanup-sockets \ > ${bindir}/dbus-send \ > ${bindir}/dbus-monitor \ > + ${bindir}/dbus-launch \ > ${libexecdir}/dbus* \ > ${sysconfdir} \ > ${localstatedir} \ > @@ -58,8 +59,8 @@ pkg_postinst_dbus() { > fi > } > > -EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}" > -EXTRA_OECONF_X_virtclass-native = "--without-x" > +EXTRA_OECONF_X = "" > +EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch" > > EXTRA_OECONF = "--disable-tests \ > --disable-checks \
Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven: > it does not build, it complains about nothing providing dbus-x11 > > Radu > > On 07/26/2012 09:17 AM, Radu Moisan wrote: >> Followed suggestions from Bugz 2261: >> >> 1) remove the --with-x/--without-x configure arguments. If you want to force >> no-discovery for native builds the correct argument is --disable-x11-autolaunch. >> This ensures that DBus looks at the build environment to determine whether to >> enable X11 bus discovery or not. >> >> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature. >> This makes the build dependencies reflect the feature list. >> >> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency >> is now back in dbus where is belongs. >> >> 4) Potentially make dbus provide dbus-x11, for compatibility. >> >> Fixes [Yocto #2261] >> >> Signed-off-by: Radu Moisan <radu.moisan@intel.com> >> --- >> meta/recipes-core/dbus/dbus.inc | 11 ++++++----- >> 1 file changed, 6 insertions(+), 5 deletions(-) >> >> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc >> index a75583d..9559f6f 100644 >> --- a/meta/recipes-core/dbus/dbus.inc >> +++ b/meta/recipes-core/dbus/dbus.inc >> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session >> DEBIANNAME_${PN} = "dbus-1" >> -PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}" >> +PACKAGES =+ "${PN}-lib ${PN}-systemd" >> -FILES_${PN}-x11 = "${bindir}/dbus-launch" >> -RDEPENDS_${PN}-x11 = "${PN}" >> +# for compatibility PROVIDES += "dbus-x11" >> +RREPLACES_${PN} += "dbus-x11" RPROVIDES_${PN} += "dbus-x11"
On Thursday 26 July 2012 10:08:49 Koen Kooi wrote: > Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het > > volgende geschreven: > > it does not build, it complains about nothing providing dbus-x11 > > > > Radu > > > > On 07/26/2012 09:17 AM, Radu Moisan wrote: > >> Followed suggestions from Bugz 2261: > >> > >> 1) remove the --with-x/--without-x configure arguments. If you want to > >> force no-discovery for native builds the correct argument is > >> --disable-x11-autolaunch. This ensures that DBus looks at the build > >> environment to determine whether to enable X11 bus discovery or not. > >> > >> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro > >> feature. This makes the build dependencies reflect the feature list. > >> > >> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 > >> dependency is now back in dbus where is belongs. > >> > >> 4) Potentially make dbus provide dbus-x11, for compatibility. > >> > >> Fixes [Yocto #2261] > >> > >> Signed-off-by: Radu Moisan <radu.moisan@intel.com> > >> --- > >> > >> meta/recipes-core/dbus/dbus.inc | 11 ++++++----- > >> 1 file changed, 6 insertions(+), 5 deletions(-) > >> > >> diff --git a/meta/recipes-core/dbus/dbus.inc > >> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644 > >> --- a/meta/recipes-core/dbus/dbus.inc > >> +++ b/meta/recipes-core/dbus/dbus.inc > >> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf > >> ${sysconfdir}/dbus-1/session>> > >> DEBIANNAME_${PN} = "dbus-1" > >> > >> -PACKAGES =+ "${PN}-lib ${PN}-systemd > >> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> > >> +PACKAGES =+ "${PN}-lib ${PN}-systemd" > >> > >> -FILES_${PN}-x11 = "${bindir}/dbus-launch" > >> > >> -RDEPENDS_${PN}-x11 = "${PN}" > >> +# for compatibility > > PROVIDES += "dbus-x11" > > >> +RREPLACES_${PN} += "dbus-x11" > > RPROVIDES_${PN} += "dbus-x11" For the sake of clarity, you mean both of these, not RPROVIDES instead of adding RREPLACES - right? Cheers, Paul
Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven: > On Thursday 26 July 2012 10:08:49 Koen Kooi wrote: >> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het >>> volgende geschreven: >>> it does not build, it complains about nothing providing dbus-x11 >>> >>> Radu >>> >>> On 07/26/2012 09:17 AM, Radu Moisan wrote: >>>> Followed suggestions from Bugz 2261: >>>> >>>> 1) remove the --with-x/--without-x configure arguments. If you want to >>>> force no-discovery for native builds the correct argument is >>>> --disable-x11-autolaunch. This ensures that DBus looks at the build >>>> environment to determine whether to enable X11 bus discovery or not. >>>> >>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro >>>> feature. This makes the build dependencies reflect the feature list. >>>> >>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 >>>> dependency is now back in dbus where is belongs. >>>> >>>> 4) Potentially make dbus provide dbus-x11, for compatibility. >>>> >>>> Fixes [Yocto #2261] >>>> >>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com> >>>> --- >>>> >>>> meta/recipes-core/dbus/dbus.inc | 11 ++++++----- >>>> 1 file changed, 6 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/meta/recipes-core/dbus/dbus.inc >>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644 >>>> --- a/meta/recipes-core/dbus/dbus.inc >>>> +++ b/meta/recipes-core/dbus/dbus.inc >>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf >>>> ${sysconfdir}/dbus-1/session>> >>>> DEBIANNAME_${PN} = "dbus-1" >>>> >>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd >>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> >>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd" >>>> >>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch" >>>> >>>> -RDEPENDS_${PN}-x11 = "${PN}" >>>> +# for compatibility >> >> PROVIDES += "dbus-x11" >> >>>> +RREPLACES_${PN} += "dbus-x11" >> >> RPROVIDES_${PN} += "dbus-x11" > > For the sake of clarity, you mean both of these, not RPROVIDES instead of > adding RREPLACES - right? Correct, you need both (or rather all 3 if you include PROVIDES).
What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it). Radu On 07/26/2012 11:43 AM, Koen Kooi wrote: > Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven: > >> On Thursday 26 July 2012 10:08:49 Koen Kooi wrote: >>> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het >>>> volgende geschreven: >>>> it does not build, it complains about nothing providing dbus-x11 >>>> >>>> Radu >>>> >>>> On 07/26/2012 09:17 AM, Radu Moisan wrote: >>>>> Followed suggestions from Bugz 2261: >>>>> >>>>> 1) remove the --with-x/--without-x configure arguments. If you want to >>>>> force no-discovery for native builds the correct argument is >>>>> --disable-x11-autolaunch. This ensures that DBus looks at the build >>>>> environment to determine whether to enable X11 bus discovery or not. >>>>> >>>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro >>>>> feature. This makes the build dependencies reflect the feature list. >>>>> >>>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 >>>>> dependency is now back in dbus where is belongs. >>>>> >>>>> 4) Potentially make dbus provide dbus-x11, for compatibility. >>>>> >>>>> Fixes [Yocto #2261] >>>>> >>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com> >>>>> --- >>>>> >>>>> meta/recipes-core/dbus/dbus.inc | 11 ++++++----- >>>>> 1 file changed, 6 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/meta/recipes-core/dbus/dbus.inc >>>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644 >>>>> --- a/meta/recipes-core/dbus/dbus.inc >>>>> +++ b/meta/recipes-core/dbus/dbus.inc >>>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf >>>>> ${sysconfdir}/dbus-1/session>> >>>>> DEBIANNAME_${PN} = "dbus-1" >>>>> >>>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd >>>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> >>>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd" >>>>> >>>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch" >>>>> >>>>> -RDEPENDS_${PN}-x11 = "${PN}" >>>>> +# for compatibility >>> PROVIDES += "dbus-x11" >>> >>>>> +RREPLACES_${PN} += "dbus-x11" >>> RPROVIDES_${PN} += "dbus-x11" >> For the sake of clarity, you mean both of these, not RPROVIDES instead of >> adding RREPLACES - right? > Correct, you need both (or rather all 3 if you include PROVIDES). > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven: > What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it). This morning you said: "it does not build, it complains about nothing providing dbus-x11" That's what the PROVIDES is for. > > Radu > > On 07/26/2012 11:43 AM, Koen Kooi wrote: >> Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven: >> >>> On Thursday 26 July 2012 10:08:49 Koen Kooi wrote: >>>> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het >>>>> volgende geschreven: >>>>> it does not build, it complains about nothing providing dbus-x11 >>>>> >>>>> Radu >>>>> >>>>> On 07/26/2012 09:17 AM, Radu Moisan wrote: >>>>>> Followed suggestions from Bugz 2261: >>>>>> >>>>>> 1) remove the --with-x/--without-x configure arguments. If you want to >>>>>> force no-discovery for native builds the correct argument is >>>>>> --disable-x11-autolaunch. This ensures that DBus looks at the build >>>>>> environment to determine whether to enable X11 bus discovery or not. >>>>>> >>>>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro >>>>>> feature. This makes the build dependencies reflect the feature list. >>>>>> >>>>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 >>>>>> dependency is now back in dbus where is belongs. >>>>>> >>>>>> 4) Potentially make dbus provide dbus-x11, for compatibility. >>>>>> >>>>>> Fixes [Yocto #2261] >>>>>> >>>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com> >>>>>> --- >>>>>> >>>>>> meta/recipes-core/dbus/dbus.inc | 11 ++++++----- >>>>>> 1 file changed, 6 insertions(+), 5 deletions(-) >>>>>> >>>>>> diff --git a/meta/recipes-core/dbus/dbus.inc >>>>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644 >>>>>> --- a/meta/recipes-core/dbus/dbus.inc >>>>>> +++ b/meta/recipes-core/dbus/dbus.inc >>>>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf >>>>>> ${sysconfdir}/dbus-1/session>> >>>>>> DEBIANNAME_${PN} = "dbus-1" >>>>>> >>>>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd >>>>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> >>>>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd" >>>>>> >>>>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch" >>>>>> >>>>>> -RDEPENDS_${PN}-x11 = "${PN}" >>>>>> +# for compatibility >>>> PROVIDES += "dbus-x11" >>>> >>>>>> +RREPLACES_${PN} += "dbus-x11" >>>> RPROVIDES_${PN} += "dbus-x11" >>> For the sake of clarity, you mean both of these, not RPROVIDES instead of >>> adding RREPLACES - right? >> Correct, you need both (or rather all 3 if you include PROVIDES). >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 26 July 2012 10:51, Koen Kooi <koen@dominion.thruhere.net> wrote: >> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it). > > This morning you said: > > "it does not build, it complains about nothing providing dbus-x11" > > That's what the PROVIDES is for. Without seeing the logs, I expect the error was when building the image. Nothing will build-depend on dbus-x11 because it isn't a source package. Radu, as a follow-up patch please remove all instances of dbus-x11, replacing with dbus if required. Ross
the build issue was solved by RPROVIDES, while PROVIDES did not fix the build or influence the error in any way. Radu On 07/26/2012 12:51 PM, Koen Kooi wrote: > Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven: > >> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it). > This morning you said: > > "it does not build, it complains about nothing providing dbus-x11" > > That's what the PROVIDES is for. >
should I create a single patch that changes dbus-x11 to dbus, or one for each package? Radu On 07/26/2012 01:23 PM, Burton, Ross wrote: > On 26 July 2012 10:51, Koen Kooi <koen@dominion.thruhere.net> wrote: >>> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it). >> This morning you said: >> >> "it does not build, it complains about nothing providing dbus-x11" >> >> That's what the PROVIDES is for. > Without seeing the logs, I expect the error was when building the > image. Nothing will build-depend on dbus-x11 because it isn't a > source package. > > Radu, as a follow-up patch please remove all instances of dbus-x11, > replacing with dbus if required. > > Ross > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
I see no build-time dependencies on dbus-x11 (only runtime dependencies), so, assuming PROVIDES is used at build-time, I don't see it's point. Radu On 07/26/2012 01:31 PM, Radu Moisan wrote: > the build issue was solved by RPROVIDES, while PROVIDES did not fix > the build or influence the error in any way. > > Radu > > On 07/26/2012 12:51 PM, Koen Kooi wrote: >> Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven: >> >>> What's the point of PROVIDES += dbus-x11, it build fine without it >>> (I'm not questioning the correctness of this, just want to >>> understand the need for it). >> This morning you said: >> >> "it does not build, it complains about nothing providing dbus-x11" >> >> That's what the PROVIDES is for. >> > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 26 July 2012 11:55, Radu Moisan <radu.moisan@intel.com> wrote: > I see no build-time dependencies on dbus-x11 (only runtime dependencies), > so, assuming PROVIDES is used at build-time, I don't see it's point. We've just removed dbus-x11 because it's pointless, the provides is only for compatibility. Ross
Op 26 jul. 2012, om 13:27 heeft Burton, Ross het volgende geschreven: > On 26 July 2012 11:55, Radu Moisan <radu.moisan@intel.com> wrote: >> I see no build-time dependencies on dbus-x11 (only runtime dependencies), >> so, assuming PROVIDES is used at build-time, I don't see it's point. > > We've just removed dbus-x11 because it's pointless, the provides is > only for compatibility. It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.
On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.
Yes, and isn't that what the RPROVIDES is for?
Ross
Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven: > On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote: >> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors. > > Yes, and isn't that what the RPROVIDES is for? I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember that it doesn't, but it will pick it up *after* do_package has run. I broke OE way too many times doing things like that :)
On Thursday 26 July 2012 14:29:14 Koen Kooi wrote: > Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven: > > On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote: > >> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep > >> working till their maintainers get around fixing them. Note that you > >> might need to do a -c cleansstate on dbus first to trigger any errors.> > > Yes, and isn't that what the RPROVIDES is for? > > I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember > that it doesn't, but it will pick it up *after* do_package has run. I broke > OE way too many times doing things like that :) Why would it need to if we're talking about RDEPENDS and more specifically RDEPENDS defined before do_package? Cheers, Paul
Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven: > On Thursday 26 July 2012 14:29:14 Koen Kooi wrote: >> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven: >>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep >>>> working till their maintainers get around fixing them. Note that you >>>> might need to do a -c cleansstate on dbus first to trigger any errors.> >>> Yes, and isn't that what the RPROVIDES is for? >> >> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember >> that it doesn't, but it will pick it up *after* do_package has run. I broke >> OE way too many times doing things like that :) > > Why would it need to if we're talking about RDEPENDS and more specifically > RDEPENDS defined before do_package? Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :) regards, Koen
Op 26 jul. 2012, om 14:36 heeft Radu Moisan het volgende geschreven:
> I understand the reasoning behind RPROVIDES. I've grep'ed the sources and none of the packages that depend on dbus-x11 have build time dependencies on it,
You grepped all the layers out there for 'dbus-x11' or only oe-core?
On Thursday 26 July 2012 14:38:59 Koen Kooi wrote: > Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven: > > On Thursday 26 July 2012 14:29:14 Koen Kooi wrote: > >> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven: > >>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote: > >>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" > >>>> keep > >>>> working till their maintainers get around fixing them. Note that you > >>>> might need to do a -c cleansstate on dbus first to trigger any errors.> > >>> > >>> Yes, and isn't that what the RPROVIDES is for? > >> > >> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember > >> that it doesn't, but it will pick it up *after* do_package has run. I > >> broke > >> OE way too many times doing things like that :) > > > > Why would it need to if we're talking about RDEPENDS and more specifically > > RDEPENDS defined before do_package? > > Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do > RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :) Without being too concerned with implementation details, I think it's as simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in RPROVIDES_${PN} then the runtime dependency is considered satisfied and things will work. You don't have to specify foo in PROVIDES unless something else has foo in DEPENDS. Cheers, Paul
only in meta & meta-intel. Radu On 07/26/2012 03:51 PM, Koen Kooi wrote: > Op 26 jul. 2012, om 14:36 heeft Radu Moisan het volgende geschreven: > >> I understand the reasoning behind RPROVIDES. I've grep'ed the sources and none of the packages that depend on dbus-x11 have build time dependencies on it, > You grepped all the layers out there for 'dbus-x11' or only oe-core? > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
This was also my understanding. Ok so we want PROVIDES in there just for the case in which someone in some layer created a dependency on dbus-x11 (in some recipe) with DEPENDS and we don't want to break his build - this argument will suffice, as far as I am concerned. Radu On 07/26/2012 03:56 PM, Paul Eggleton wrote: > > Without being too concerned with implementation details, I think it's as > simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in > RPROVIDES_${PN} then the runtime dependency is considered satisfied and things > will work. You don't have to specify foo in PROVIDES unless something else has > foo in DEPENDS. > > Cheers, > Paul >
Op 26 jul. 2012, om 14:56 heeft Paul Eggleton het volgende geschreven: > On Thursday 26 July 2012 14:38:59 Koen Kooi wrote: >> Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven: >>> On Thursday 26 July 2012 14:29:14 Koen Kooi wrote: >>>> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven: >>>>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" >>>>>> keep >>>>>> working till their maintainers get around fixing them. Note that you >>>>>> might need to do a -c cleansstate on dbus first to trigger any errors.> >>>>> >>>>> Yes, and isn't that what the RPROVIDES is for? >>>> >>>> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember >>>> that it doesn't, but it will pick it up *after* do_package has run. I >>>> broke >>>> OE way too many times doing things like that :) >>> >>> Why would it need to if we're talking about RDEPENDS and more specifically >>> RDEPENDS defined before do_package? >> >> Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do >> RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :) > > Without being too concerned with implementation details, I think it's as > simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in > RPROVIDES_${PN} then the runtime dependency is considered satisfied and things > will work. You don't have to specify foo in PROVIDES unless something else has > foo in DEPENDS. If that's so, great, but please check :)
Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>
writes:
> RPROVIDES_${PN} += "dbus-x11"
This is wrong because 'dbus' does not provide dbus-x11 when x11 is
disabled by distro. Packages which require dbus-launch from 'dbus-x11'
will install fine but will fail at runtime.
Enrico
On Thursday 26 July 2012 15:07:42 Koen Kooi wrote: > > Without being too concerned with implementation details, I think it's as > > simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo > > in RPROVIDES_${PN} then the runtime dependency is considered satisfied > > and things will work. You don't have to specify foo in PROVIDES unless > > something else has foo in DEPENDS. > > If that's so, great, but please check :) I did, prior to sending that... :) Cheers, Paul
Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes: > Followed suggestions from Bugz 2261: > > 1) remove the --with-x/--without-x configure arguments. why? They are valid ./configure options and common when evaluating the x11 distro-feature. Selecting them explicitly makes the build more predictable and detects configuration errors earlier. Sense of '--without-x' was disabling of x11 dependency, but not turning off the x11-autolaunch feature. Enrico
Op 26 jul. 2012, om 15:12 heeft Paul Eggleton het volgende geschreven: > On Thursday 26 July 2012 15:07:42 Koen Kooi wrote: >>> Without being too concerned with implementation details, I think it's as >>> simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo >>> in RPROVIDES_${PN} then the runtime dependency is considered satisfied >>> and things will work. You don't have to specify foo in PROVIDES unless >>> something else has foo in DEPENDS. >> >> If that's so, great, but please check :) > > I did, prior to sending that... :) great, I'll shut up now :)
it does not crash at runtime. You can try dbus-launch --auto-syntax it'll start a bus and print out the information like: DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-N48lpeD2TP,guid=0f3cd66fdbdc2f436a9356790002eaa1'; export DBUS_SESSION_BUS_ADDRESS; DBUS_SESSION_BUS_PID=23640; Radu On 07/26/2012 04:08 PM, Enrico Scholz wrote: > Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org> > writes: > >> RPROVIDES_${PN} += "dbus-x11" > This is wrong because 'dbus' does not provide dbus-x11 when x11 is > disabled by distro. Packages which require dbus-launch from 'dbus-x11' > will install fine but will fail at runtime. > > > Enrico > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:
> it does not crash at runtime.
I do not speak about crash; I guess 'dbus-launch' has some extra
functionality when compiled with x11 support, and packages which
depend on dbus-x11 might expect this functionality.
Providing 'dbus-x11' although no x11 functionality is provided sounds
wrong to me. Either remove the 'dbus-x11' property completely or provide
it only when x11 support is built in.
Enrico
On 26 July 2012 14:17, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote: > Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > writes: > >> Followed suggestions from Bugz 2261: >> >> 1) remove the --with-x/--without-x configure arguments. > > why? They are valid ./configure options and common when evaluating the > x11 distro-feature. Selecting them explicitly makes the build more > predictable and detects configuration errors earlier. > > Sense of '--without-x' was disabling of x11 dependency, but not turning > off the x11-autolaunch feature. That's my fault, and I can't remember my reasoning. Probably best to bring it back so the recipe is explicit. Radu, bring back this fragment, but correct the options EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}" Ross
On 26 July 2012 15:32, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote: > I do not speak about crash; I guess 'dbus-launch' has some extra > functionality when compiled with x11 support, and packages which > depend on dbus-x11 might expect this functionality. > > Providing 'dbus-x11' although no x11 functionality is provided sounds > wrong to me. Either remove the 'dbus-x11' property completely or provide > it only when x11 support is built in. I disagree. Currently dbus-launch is packaged in dbus-x11 which may or may not have a dependency on X11. *That* makes no sense. Moving dbus-launch into dbus which conditionally has X11 autolaunch support depending on whether X11 is being used or not makes sense to me. Ross
On 07/27/2012 12:12 AM, Burton, Ross wrote: > On 26 July 2012 14:17, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote: >> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> >> writes: >> >>> Followed suggestions from Bugz 2261: >>> >>> 1) remove the --with-x/--without-x configure arguments. >> why? They are valid ./configure options and common when evaluating the >> x11 distro-feature. Selecting them explicitly makes the build more >> predictable and detects configuration errors earlier. >> >> Sense of '--without-x' was disabling of x11 dependency, but not turning >> off the x11-autolaunch feature. > That's my fault, and I can't remember my reasoning. Probably best to > bring it back so the recipe is explicit. > > Radu, bring back this fragment, but correct the options > > EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', > '--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}" > > Ross > I've looked into the configure script and found that autolaunch feature is depending on x11, in other words using --with-x/--without-x implies --enable-x11-autolaunch/--disable-x11-autolaunch, so I guess the initial EXTRA_OECONF_X line will do pretty much the same thing. EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}" Radu
On 07/27/2012 09:10 AM, Radu Moisan wrote: > > On 07/27/2012 12:12 AM, Burton, Ross wrote: >> On 26 July 2012 14:17, Enrico Scholz<enrico.scholz@sigma-chemnitz.de> wrote: >>> Radu Moisan<radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> >>> writes: >>> >>>> Followed suggestions from Bugz 2261: >>>> >>>> 1) remove the --with-x/--without-x configure arguments. >>> why? They are valid ./configure options and common when evaluating the >>> x11 distro-feature. Selecting them explicitly makes the build more >>> predictable and detects configuration errors earlier. >>> >>> Sense of '--without-x' was disabling of x11 dependency, but not turning >>> off the x11-autolaunch feature. >> That's my fault, and I can't remember my reasoning. Probably best to >> bring it back so the recipe is explicit. >> >> Radu, bring back this fragment, but correct the options >> >> EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', >> '--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}" >> >> Ross >> > I've looked into the configure script and found that autolaunch > feature is depending on x11, in other words using --with-x/--without-x > implies --enable-x11-autolaunch/--disable-x11-autolaunch, so I guess > the initial EXTRA_OECONF_X line will do pretty much the same thing. > > EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', > '--with-x', '--without-x', d)}" > and the same applies for EXTRA_OECONF_X_virtclass-native disabling X will disable autolaunch feature, so I'll keep the initial line as well. Radu
On 27 July 2012 07:10, Radu Moisan <radu.moisan@intel.com> wrote: > I've looked into the configure script and found that autolaunch feature is > depending on x11, in other words using --with-x/--without-x implies > --enable-x11-autolaunch/--disable-x11-autolaunch, so I guess the initial > EXTRA_OECONF_X line will do pretty much the same thing. Using --enable-x11-autolaunch (and --disable) make it obvious what the intention is, and is the option exposed by DBus. --with-x is an artifact of using AC_PATH_XTRA, so if dbus decided to use pkg-config to find the X headers --with-x will disappear. Ross
Patch
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644 --- a/meta/recipes-core/dbus/dbus.inc +++ b/meta/recipes-core/dbus/dbus.inc @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session DEBIANNAME_${PN} = "dbus-1" -PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}" +PACKAGES =+ "${PN}-lib ${PN}-systemd" -FILES_${PN}-x11 = "${bindir}/dbus-launch" -RDEPENDS_${PN}-x11 = "${PN}" +# for compatibility +RREPLACES_${PN} += "dbus-x11" FILES_${PN}-systemd = "${systemd_unitdir}/system/" @@ -43,6 +43,7 @@ FILES_${PN} = "${bindir}/dbus-daemon* \ ${bindir}/dbus-cleanup-sockets \ ${bindir}/dbus-send \ ${bindir}/dbus-monitor \ + ${bindir}/dbus-launch \ ${libexecdir}/dbus* \ ${sysconfdir} \ ${localstatedir} \ @@ -58,8 +59,8 @@ pkg_postinst_dbus() { fi } -EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}" -EXTRA_OECONF_X_virtclass-native = "--without-x" +EXTRA_OECONF_X = "" +EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch" EXTRA_OECONF = "--disable-tests \ --disable-checks \
Followed suggestions from Bugz 2261: 1) remove the --with-x/--without-x configure arguments. If you want to force no-discovery for native builds the correct argument is --disable-x11-autolaunch. This ensures that DBus looks at the build environment to determine whether to enable X11 bus discovery or not. 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature. This makes the build dependencies reflect the feature list. 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency is now back in dbus where is belongs. 4) Potentially make dbus provide dbus-x11, for compatibility. Fixes [Yocto #2261] Signed-off-by: Radu Moisan <radu.moisan@intel.com> --- meta/recipes-core/dbus/dbus.inc | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)