[PATCH 0/4] meta: 4 fixes

[PATCH 0/4] meta: 4 fixes

[Robert Yang]

The following changes since commit 2106a567820bad438ff78d54a49e3d87da428dcf:

  python3: python3: Fix build error x86->x86 (2019-06-19 13:15:55 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/4fixes
  http://cgit.openembedded.org//log/?h=rbt/4fixes

Robert Yang (4):
  linux-dummy: Add do_compile_kernelmodules
  make-mod-scripts: Depends on bison-native
  update-alternatives.bbclass: run update-alternatives firstly in
    postinst script
  gtk-icon-cache.bbclass: Depends on gtk+3

 meta/classes/gtk-icon-cache.bbclass                        | 14 ++++++++++----
 meta/classes/update-alternatives.bbclass                   |  7 +++++--
 meta/recipes-kernel/linux/linux-dummy.bb                   |  5 +++++
 .../make-mod-scripts/make-mod-scripts_1.0.bb               |  2 +-
 4 files changed, 21 insertions(+), 7 deletions(-)

-- 
2.7.4

[PATCH 1/4] linux-dummy: Add do_compile_kernelmodules

[Robert Yang]

Fixed:
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"

$ bitbake world
ERROR: Task do_compile in make-mod-scripts_1.0.bb depends upon non-existent task do_compile_kernelmodules in linux-dummy.bb
ERROR: Command execution failed: Exited with 1

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-kernel/linux/linux-dummy.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-dummy.bb b/meta/recipes-kernel/linux/linux-dummy.bb
index e1c7f76..62cf6f5 100644
--- a/meta/recipes-kernel/linux/linux-dummy.bb
+++ b/meta/recipes-kernel/linux/linux-dummy.bb
@@ -39,6 +39,10 @@ do_compile () {
 	:
 }
 
+do_compile_kernelmodules() {
+    :
+}
+
 do_shared_workdir () {
 	:
 }
@@ -58,3 +62,4 @@ do_deploy() {
 addtask bundle_initramfs after do_install before do_deploy
 addtask deploy after do_install
 addtask shared_workdir after do_compile before do_install
+addtask compile_kernelmodules
-- 
2.7.4

[PATCH 2/4] make-mod-scripts: Depends on bison-native

[Robert Yang]

Fixed do_configure error when use linux-dummy:
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"

/bin/sh: bison: command not found

Build make-mod-scripts doesn't make sense when use linux-dummy, but it breaks
"bitbake world", so add bison-native to DEPENDS to fix the problem.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 97c58c5..460e05a 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -12,7 +12,7 @@ S = "${WORKDIR}"
 do_configure[depends] += "virtual/kernel:do_shared_workdir openssl-native:do_populate_sysroot"
 do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
 
-DEPENDS += "bc-native"
+DEPENDS += "bc-native bison-native"
 
 EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""
 
-- 
2.7.4

[PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script

[Robert Yang]

Recipes like postfix run command newaliases in postinst, but newaliases is
installed newaliases.postfix, and need run update-alternatives to update it to
newaliases, so we would get the error when install postinst on target.

Fixed:
$ opkg install postfix
Configuring postfix.
///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command not found

Run update-alternatives firstly will fix the problem.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/classes/update-alternatives.bbclass | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index b702e77..8c2b66e 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -284,8 +284,11 @@ python populate_packages_updatealternatives () {
 
             bb.note('adding update-alternatives calls to postinst/prerm for %s' % pkg)
             bb.note('%s' % alt_setup_links)
-            postinst = d.getVar('pkg_postinst_%s' % pkg) or '#!/bin/sh\n'
-            postinst += alt_setup_links
+            postinst = d.getVar('pkg_postinst_%s' % pkg)
+            if postinst:
+                postinst = alt_setup_links + postinst
+            else:
+                postinst = '#!/bin/sh\n' + alt_setup_links
             d.setVar('pkg_postinst_%s' % pkg, postinst)
 
             bb.note('%s' % alt_remove_links)
-- 
2.7.4

Re: [PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script

[Richard Purdie]

On Thu, 2019-06-20 at 16:15 +0800, Robert Yang wrote:
> Recipes like postfix run command newaliases in postinst, but
> newaliases is
> installed newaliases.postfix, and need run update-alternatives to
> update it to
> newaliases, so we would get the error when install postinst on
> target.
> 
> Fixed:
> $ opkg install postfix
> Configuring postfix.
> ///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command
> not found
> 
> Run update-alternatives firstly will fix the problem.
> 
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>  meta/classes/update-alternatives.bbclass | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

This seemed to result in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/724

Cheers,

Richard

Re: [PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script

[Robert Yang]

Hi,

I can reproduce it now, sorry about that, I'm working on it.

// Robert

On 6/20/19 11:33 PM, Richard Purdie wrote:
> On Thu, 2019-06-20 at 16:15 +0800, Robert Yang wrote:
>> Recipes like postfix run command newaliases in postinst, but
>> newaliases is
>> installed newaliases.postfix, and need run update-alternatives to
>> update it to
>> newaliases, so we would get the error when install postinst on
>> target.
>>
>> Fixed:
>> $ opkg install postfix
>> Configuring postfix.
>> ///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command
>> not found
>>
>> Run update-alternatives firstly will fix the problem.
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>>   meta/classes/update-alternatives.bbclass | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> This seemed to result in:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/724
> 
> Cheers,
> 
> Richard
> 
> 

[PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Robert Yang]

The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/classes/gtk-icon-cache.bbclass | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index 66fe781..4e60fe6 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk
 
 PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
 
+inherit distro_features_check
+ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
+
+DEPENDS += "gtk+3"
+
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
 	$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} \
@@ -45,10 +50,11 @@ python populate_packages_append () {
         if not os.path.exists(icon_dir):
             continue
 
-        bb.note("adding hicolor-icon-theme dependency to %s" % pkg)
-        rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
-        d.appendVar('RDEPENDS_%s' % pkg, rdepends)
-    
+        for dep in ('hicolor-icon-theme', 'gtk+3'):
+            bb.note("Adding %s dependency to %s" % (dep, pkg))
+            rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
+            d.appendVar('RDEPENDS_%s' % pkg, rdepends)
+
         bb.note("adding gtk-icon-cache postinst and postrm scripts to %s" % pkg)
         
         postinst = d.getVar('pkg_postinst_%s' % pkg)
-- 
2.7.4

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Adrian Bunk]

On Thu, Jun 20, 2019 at 04:15:26PM +0800, Robert Yang wrote:
> The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.

gdk-pixbuf-query-loaders is provided by gdk-pixbuf,
which is not tied to a specific GTK version.

gtk-update-icon-cache is provided by both GTK 2 and GTK 3,
I haven't checked whether it will also be in GTK 4.

>...
> --- a/meta/classes/gtk-icon-cache.bbclass
> +++ b/meta/classes/gtk-icon-cache.bbclass
> @@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk
>  
>  PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
>  
> +inherit distro_features_check
> +ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
> +
> +DEPENDS += "gtk+3"
>...

This looks OK.

> @@ -45,10 +50,11 @@ python populate_packages_append () {
>          if not os.path.exists(icon_dir):
>              continue
>  
> -        bb.note("adding hicolor-icon-theme dependency to %s" % pkg)
> -        rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
> -        d.appendVar('RDEPENDS_%s' % pkg, rdepends)
> -    
> +        for dep in ('hicolor-icon-theme', 'gtk+3'):
> +            bb.note("Adding %s dependency to %s" % (dep, pkg))
> +            rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
> +            d.appendVar('RDEPENDS_%s' % pkg, rdepends)
>...

Why is this necessary?

I would expect there to always be a generated RDEPENDS on either
gtk+ or gtk+3 (or soon gtk4) that already covers this.
Anything I miss here?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Robert Yang]

On 6/20/19 4:28 PM, Adrian Bunk wrote:
> On Thu, Jun 20, 2019 at 04:15:26PM +0800, Robert Yang wrote:
>> The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.
> 
> gdk-pixbuf-query-loaders is provided by gdk-pixbuf,
> which is not tied to a specific GTK version.
> 
> gtk-update-icon-cache is provided by both GTK 2 and GTK 3,
> I haven't checked whether it will also be in GTK 4.

Thanks, I will update it.

> 
>> ...
>> --- a/meta/classes/gtk-icon-cache.bbclass
>> +++ b/meta/classes/gtk-icon-cache.bbclass
>> @@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk
>>   
>>   PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
>>   
>> +inherit distro_features_check
>> +ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
>> +
>> +DEPENDS += "gtk+3"
>> ...
> 
> This looks OK.
> 
>> @@ -45,10 +50,11 @@ python populate_packages_append () {
>>           if not os.path.exists(icon_dir):
>>               continue
>>   
>> -        bb.note("adding hicolor-icon-theme dependency to %s" % pkg)
>> -        rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
>> -        d.appendVar('RDEPENDS_%s' % pkg, rdepends)
>> -
>> +        for dep in ('hicolor-icon-theme', 'gtk+3'):
>> +            bb.note("Adding %s dependency to %s" % (dep, pkg))
>> +            rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
>> +            d.appendVar('RDEPENDS_%s' % pkg, rdepends)
>> ...
> 
> Why is this necessary?

Otherwise, gtk+3 won't be installed.

> 
> I would expect there to always be a generated RDEPENDS on either
> gtk+ or gtk+3 (or soon gtk4) that already covers this.
> Anything I miss here?

gtk2/3/4 is a problem, I checked DEPENDS in oe-core's recipes, most
of them depend on gtk+3, only one depends on gtk+:

meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb

Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
need something like virtual/gtk to fix these problems totally?

// Robert

> 
> cu
> Adrian
> 

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Adrian Bunk]

On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>...
> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
> need something like virtual/gtk to fix these problems totally?

GTK+2 is mostly obsolete.

I just checked the GTK4 sources, and there it is renamed to 
gtk4-update-icon-cache. Based on that I would say that your
patch is actually fine at least for now.

> // Robert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Alexander Kanavin]

I’d say virtual/gtk wouldn’t be helpful much as 2/3/4 versions have major api differences.

Alex

> On 20 Jun 2019, at 11.19, Adrian Bunk <bunk@stusta.de> wrote:
> 
>> On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>> ...
>> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
>> need something like virtual/gtk to fix these problems totally?
> 
> GTK+2 is mostly obsolete.
> 
> I just checked the GTK4 sources, and there it is renamed to 
> gtk4-update-icon-cache. Based on that I would say that your
> patch is actually fine at least for now.
> 
>> // Robert
> 
> cu
> Adrian
> 
> -- 
> 
>       "Is there not promise of rain?" Ling Tan asked suddenly out
>        of the darkness. There had been need of rain for many days.
>       "Only a promise," Lao Er said.
>                                       Pearl S. Buck - Dragon Seed
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Robert Yang]

On 6/20/19 5:19 PM, Adrian Bunk wrote:
> On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>> ...
>> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
>> need something like virtual/gtk to fix these problems totally?
> 
> GTK+2 is mostly obsolete.
> 
> I just checked the GTK4 sources, and there it is renamed to
> gtk4-update-icon-cache. Based on that I would say that your
> patch is actually fine at least for now.

Thanks, I updated the commit message in the PULL:

     The gtk-update-icon-cache is provided by gtk+3, gdk-pixbuf-query-loaders is
     provided by gdk-pixbuf, and gtk+3 depends on gdk-pixbuf, so depends on gtk+3
     can fix the problems.


// Robert

> 
>> // Robert
> 
> cu
> Adrian
> 

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Richard Purdie]

On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
> 
> On 6/20/19 5:19 PM, Adrian Bunk wrote:
> > On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
> > > ...
> > > Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think
> > > that we
> > > need something like virtual/gtk to fix these problems totally?
> > 
> > GTK+2 is mostly obsolete.
> > 
> > I just checked the GTK4 sources, and there it is renamed to
> > gtk4-update-icon-cache. Based on that I would say that your
> > patch is actually fine at least for now.
> 
> Thanks, I updated the commit message in the PULL:

Please resend patches rather than updating the branch as they get lost
really easily and also don't get reviewed properly this way.

Cheers,

Richard

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Burton, Ross]

Why DEPENDS on gtk?  The recipes will typically already do this, but
all this class needs is the rdepends.  Also, there's no explanation
for the hicolor addition.

Ross

On Thu, 20 Jun 2019 at 14:54, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
> >
> > On 6/20/19 5:19 PM, Adrian Bunk wrote:
> > > On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
> > > > ...
> > > > Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think
> > > > that we
> > > > need something like virtual/gtk to fix these problems totally?
> > >
> > > GTK+2 is mostly obsolete.
> > >
> > > I just checked the GTK4 sources, and there it is renamed to
> > > gtk4-update-icon-cache. Based on that I would say that your
> > > patch is actually fine at least for now.
> >
> > Thanks, I updated the commit message in the PULL:
>
> Please resend patches rather than updating the branch as they get lost
> really easily and also don't get reviewed properly this way.
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

[Robert Yang]

Hi Ross,

On 6/20/19 9:56 PM, Burton, Ross wrote:
> Why DEPENDS on gtk?  The recipes will typically already do this, but
> all this class needs is the rdepends.  Also, there's no explanation
> for the hicolor addition.

I got errors when running adwaita-icon-theme's postinst on target
(command gtk-update-icon-cache not found), the recipe doesn't depend
on gtk, and gtk-update-icon-cache is introduced by gtk-icon-cache.bbclass,
so I think that we should add this DEPENDS in the bbclass? If only add gtk
to RDEPENDS (no DEPENDS), there would be a warning like:

adwaita-icon-theme rdepends on gtk+3, but it isn't a build dependency?

For hicolor-icon-theme, it is an existed rdepends in gtk-icon-cache.bbclass,
so I left it there.

// Robert

> 
> Ross
> 
> On Thu, 20 Jun 2019 at 14:54, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>
>> On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
>>>
>>> On 6/20/19 5:19 PM, Adrian Bunk wrote:
>>>> On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>>>>> ...
>>>>> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think
>>>>> that we
>>>>> need something like virtual/gtk to fix these problems totally?
>>>>
>>>> GTK+2 is mostly obsolete.
>>>>
>>>> I just checked the GTK4 sources, and there it is renamed to
>>>> gtk4-update-icon-cache. Based on that I would say that your
>>>> patch is actually fine at least for now.
>>>
>>> Thanks, I updated the commit message in the PULL:
>>
>> Please resend patches rather than updating the branch as they get lost
>> really easily and also don't get reviewed properly this way.
>>
>> Cheers,
>>
>> Richard
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>