Patchwork [1/1] qemu: use PACKAGECONFIG to address nss dependencies

login
register
mail settings
Submitter Hongxu Jia
Date Nov. 1, 2013, 11:42 a.m.
Message ID <52739398.4070402@windriver.com>
Download mbox | patch
Permalink /patch/60959/
State New
Headers show

Comments

Hongxu Jia - Nov. 1, 2013, 11:42 a.m.
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.
...
...

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 Jansa - Nov. 1, 2013, 12:16 p.m.
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
> >
>

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.
  PACKAGECONFIG ??= ""
  PACKAGECONFIG[virtfs] = "--enable-virtfs 
--enable-attr,--disable-virtfs,libcap attr,"
  PACKAGECONFIG[aio] = "--enable-linux-aio,--disable-linux-aio,libaio,"