On Fri, Nov 01, 2013 at 07:42:16PM +0800, Hongxu Jia wrote: > On 11/01/2013 06:52 PM, Richard Purdie wrote: > > On Fri, 2013-11-01 at 10:39 +0100, Martin Jansa wrote: > >> On Fri, Nov 01, 2013 at 08:50:56AM +0000, Richard Purdie wrote: > >>> On Thu, 2013-10-31 at 19:50 +0800, Hongxu Jia wrote: > >>>> On 10/31/2013 06:41 PM, Martin Jansa wrote: > >>>>> On Thu, Oct 31, 2013 at 06:23:01PM +0800, Hongxu Jia wrote: > >>>>>> Use PACKAGECONFIG to explicitly address nss dependencies rather than > >>>>>> tested by configure. > >>>>>> > >>>>>> It avoided potential errors while multiple builds shared a common > >>>>>> state_cache. > >>>>> There are more floating dependencies in qemu.inc, see > >>>>> http://patchwork.openembedded.org/patch/56935/ > >>>>> > >>>>> and even this list isn't complete, there is also: > >>>>> WARN: packages/armv5te-oe-linux-gnueabi/qemu/qemu/latest lost > >>>>> dependency on cairo gdk-pixbuf gnutls gtk+ libvte > >>>>> > >>>>> Can you please improve it to fix them all? > >>>>> > >>>> OK, I will try to fix them as possible as I can. > >>>> > >>>> Drop this patch, wait for V2. > >>> Part of the problem here is that qemu-native has some "floating" > >>> dependencies by design. If the native system has graphics support, qemu > >>> will have too. If it doesn't it won't have. This works out to be quite > >>> useful for people. Some people have headless build machines they don't > >>> want to install X on, equally some have build machines which do have X > >>> and they do want graphical qemu. > >>> > >>> How do we support both? > >> Aren't reproducible builds more important than automagically enabled > >> graphics support, what if such automagically enabled qemu-native gets > >> reused from sstate on headless server without graphics support? > > I agree there is a problem here. Equally, there is an important use case > > which people do use and care about which this patch removes. > > > >> We can extend documentation to say that in order to enable graphics > >> support for qemu-native you need to set > >> PACKAGECONFIG_pn-qemu-native += "foo bar" > >> in local.conf (or to remove some to disable it, but enabling explicitly > >> is imho better because we don't have graphics native support in > >> ASSUME_PROVIDED). > > I think we'll have to do something like this, yes. I'd like to see the > > patches adding this documentation to local.conf before we change things > > though. > > OK, how about add the above documentation as comments in the patch. > ... > --- a/meta/recipes-devtools/qemu/qemu.inc > +++ b/meta/recipes-devtools/qemu/qemu.inc > @@ -79,6 +79,10 @@ do_install_append() { > } > # END of qemu-mips workaround > > +# Disable the following flags by default. Such as graphics is > +# disabled for qemu-native, if you need to enable them, set > +# PACKAGECONFIG_pn-qemu-native += "foo bar" in local.conf > +# or just comment out them to let configure do the test.
From this comment it's not clear that people need to comment out PACKAGECONFIG[foo] lines (not PACKAGECONFIG values) and I believe that setting right PACKAGECONFIG_pn-qemu-native is more reliable and easier (I don't know if you can easily remove PACKAGECONFIG varflag from local.conf. Once I explicitly enable graphics support in my local.conf I would prefer qemu-native configure to fail if my host distribution is changes and became incompatible. > PACKAGECONFIG ??= "" > PACKAGECONFIG[virtfs] = "--enable-virtfs > --enable-attr,--disable-virtfs,libcap attr," > PACKAGECONFIG[aio] = "--enable-linux-aio,--disable-linux-aio,libaio," > ... > > or add them to meta-yocto/conf/local.conf.sample.extended or some place > else? > > And I could not exactly figure out which flags affected the graphics. > > //Hongxu > > > > Cheers, > > > > Richard > > > -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core