On 07/27/2012 12:12 AM, Burton, Ross wrote:
On 26 July 2012 14:17, Enrico Scholz enrico.sch...@sigma-chemnitz.de wrote:
Radu Moisan radu.moisan-ral2jqcrhueavxtiumw...@public.gmane.org
writes:
Followed suggestions from Bugz 2261:
1) remove the --with-x/--without-x configure arguments.
why?
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 Scholzenrico.sch...@sigma-chemnitz.de wrote:
Radu Moisanradu.moisan-ral2jqcrhueavxtiumw...@public.gmane.org
writes:
Followed suggestions from Bugz 2261:
1) remove the
On 27 July 2012 07:10, Radu Moisan radu.moi...@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
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
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
Op 26 jul. 2012, om 08:29 heeft Radu Moisan radu.moi...@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
On Thursday 26 July 2012 10:08:49 Koen Kooi wrote:
Op 26 jul. 2012, om 08:29 heeft Radu Moisan radu.moi...@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
Op 26 jul. 2012, om 10:42 heeft Paul Eggleton paul.eggle...@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.moi...@intel.com het
volgende geschreven:
it does not build, it complains about nothing
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.eggle...@linux.intel.com
het volgende
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
On 26 July 2012 10:51, Koen Kooi k...@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
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
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 k...@dominion.thruhere.net wrote:
What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not
questioning
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
On 26 July 2012 11:55, Radu Moisan radu.moi...@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
Op 26 jul. 2012, om 13:27 heeft Burton, Ross het volgende geschreven:
On 26 July 2012 11:55, Radu Moisan radu.moi...@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
On 26 July 2012 12:55, Koen Kooi k...@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
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 k...@dominion.thruhere.net wrote:
It would be nice if other layers that have RDEPENDS_foo = dbus-x11 keep
working till their maintainers
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, so the question arises what's the point of
PROVIDES?. I understand the compatibility argument, but it seems to me
more like an argument
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 k...@dominion.thruhere.net wrote:
It would be nice if other layers
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
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
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
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
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
Koen Kooi koen-qlwjdigv5ablmq1fohreccpxlwaov...@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
Radu Moisan radu.moisan-ral2jqcrhueavxtiumw...@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
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}
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
Radu Moisan radu.moisan-ral2jqcrhueavxtiumw...@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
On 26 July 2012 14:17, Enrico Scholz enrico.sch...@sigma-chemnitz.de wrote:
Radu Moisan radu.moisan-ral2jqcrhueavxtiumw...@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
On 26 July 2012 15:32, Enrico Scholz enrico.sch...@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
33 matches
Mail list logo
