[OE-core] [PATCH] lttng-tools: Do not build for riscv64

[Khem Raj]

Since lttng-modules are not buildable, there is no point of building
tools either

Signed-off-by: Khem Raj 
---
 .../packagegroups/packagegroup-core-tools-profile.bb   | 1 +
 meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb| 3 +++
 2 files changed, 4 insertions(+)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index ca35af1ec3..608e406f83 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -41,6 +41,7 @@ LTTNGUST_arc = ""
 
 LTTNGTOOLS = "lttng-tools"
 LTTNGTOOLS_arc = ""
+LTTNGTOOLS_riscv64 = ""
 
 LTTNGMODULES = "lttng-modules"
 LTTNGMODULES_arc = ""
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
index e9c8e18e22..0614e86713 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
@@ -162,3 +162,6 @@ do_install_ptest () {
 esac
 done
 }
+
+COMPATIBLE_HOST_riscv64 = "null"
+
-- 
2.28.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141839): 
https://lists.openembedded.org/g/openembedded-core/message/141839
Mute This Topic: https://lists.openembedded.org/mt/76422926/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] local.conf.sample: Document memory resident bitbake

[Richard Purdie]

On Tue, 2020-08-25 at 23:10 +0100, Richard Purdie via lists.openembedded.org 
wrote:
> Add an example of how to enable this to local.conf.sample
> 
> Signed-off-by: Richard Purdie 
> ---
>  {meta => metay}/conf/local.conf.sample | 10 ++
>  1 file changed, 10 insertions(+)
>  rename {meta => metay}/conf/local.conf.sample (96%)
> 
> diff --git a/meta/conf/local.conf.sample b/metay/conf/local.conf.sample
> similarity index 96%
> rename from meta/conf/local.conf.sample
> rename to metay/conf/local.conf.sample
> index 783d2c4c16d..efb3100d9bd 100644
> --- a/meta/conf/local.conf.sample
> +++ b/metay/conf/local.conf.sample
> @@ -226,6 +226,16 @@ PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
>  #BB_HASHSERVE = "auto"
>  #BB_SIGNATURE_HANDLER = "OEEquivHash"
>  
> +#
> +# Memory Resident Bitbake
> +#
> +# Bitbake's server component can stay in memory after the UI for the current 
> command
> +# has completed. This means subsequent commands can run faster since there 
> is no need
> +# for bitbake to reload cache files and so on. Number is in seconds, after 
> which the
> +# server will shut down.
> +#
> +BB_SERVER_TIMEOUT = "60"

This is meant to have this commented, I've fixed the patches queued.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141838): 
https://lists.openembedded.org/g/openembedded-core/message/141838
Mute This Topic: https://lists.openembedded.org/mt/76417256/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] oeqa/selftest: Apply patch to fix cpio build with -fno-common

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/lib/oeqa/selftest/cases/meta_ide.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/meta_ide.py 
b/meta/lib/oeqa/selftest/cases/meta_ide.py
index 809142559a..4dcebc5a06 100644
--- a/meta/lib/oeqa/selftest/cases/meta_ide.py
+++ b/meta/lib/oeqa/selftest/cases/meta_ide.py
@@ -43,7 +43,7 @@ class MetaIDE(OESelftestTestCase):
 "https://ftp.gnu.org/gnu/cpio/cpio-2.13.tar.gz";,
 self.tmpdir_metaideQA, self.td['DATETIME'], 
dl_dir=dl_dir)
 self.project.download_archive()
-self.assertEqual(self.project.run_configure(), 0,
+
self.assertEqual(self.project.run_configure('--disable-maintainer-mode','sed -i 
-e "/char \*program_name/d" src/global.c;'), 0,
 msg="Running configure failed")
 self.assertEqual(self.project.run_make(), 0,
 msg="Running make failed")
-- 
2.28.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141836): 
https://lists.openembedded.org/g/openembedded-core/message/141836
Mute This Topic: https://lists.openembedded.org/mt/76417402/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] kexec-tools: Fix build with -fno-common on ppc

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../0001-kexec-Fix-build-with-fno-common.patch | 10 ++
 1 file changed, 10 insertions(+)

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-Fix-build-with-fno-common.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-Fix-build-with-fno-common.patch
index a3ba0912d4..31f4d00b53 100644
--- 
a/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-Fix-build-with-fno-common.patch
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-Fix-build-with-fno-common.patch
@@ -66,3 +66,13 @@ Signed-off-by: Khem Raj 
  
  int bzImage64_probe(const char *buf, off_t len)
  {
+--- a/kexec/arch/ppc/kexec-elf-ppc.c
 b/kexec/arch/ppc/kexec-elf-ppc.c
+@@ -33,7 +33,6 @@
+ static const int probe_debug = 0;
+ 
+ unsigned char reuse_initrd;
+-const char *ramdisk;
+ int create_flatten_tree(struct kexec_info *, unsigned char **, unsigned long 
*,
+   char *);
+ 
-- 
2.28.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141837): 
https://lists.openembedded.org/g/openembedded-core/message/141837
Mute This Topic: https://lists.openembedded.org/mt/76417403/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Mark Hatle]

On 8/25/20 12:04 PM, Richard Purdie wrote:
> On Tue, 2020-08-25 at 11:52 -0500, Mark Hatle wrote:
>>
>> On 8/25/20 9:14 AM, Mark Hatle wrote:
>>>
>>> On 8/25/20 5:56 AM, Richard Purdie wrote:
 On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
> A related change was also needed for the kernel.bbclass.  The
> kernel
>
> needs to get the AUTOINC values used by the various PV/PKGV,
> but with
> this new system we don't want to call auto_pr each time --
> instead
> call the read_subpackage_metadata to ensure a consistent
> result.
>
> This also fixes an issue in the old version where the kernel
> sometimes
> caused the PR to be incremented twice, as the auto_pr was
> called
> multiple times from different tasks.

 [...]

> diff --git a/meta/classes/kernel.bbclass
> b/meta/classes/kernel.bbclass
> index e2ceb6a333..4449452065 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -416,7 +416,7 @@ kernel_do_install() {
>   install -d ${D}${sysconfdir}/modules-load.d
>   install -d ${D}${sysconfdir}/modprobe.d
>  }
> -do_install[prefuncs] += "package_get_auto_pr"
> +do_install[prefuncs] += "read_subpackage_metadata"
>>
>> I talked with Bruce on this.  We see no reason do_install[prefuncs]
>> is required
>> any longer.
>>
>> It was when that line was written, but when the kernel was refactored
>> to permit multiple kernel builds and such the need for this went
>> away.
> 
> Ok, lets start with a patch to remove that call.
> 
>  # Must be ran no earlier than after do_kernel_checkout or else
> Makefile won't be in ${S}/Makefile
>  do_kernel_version_sanity_check() {
> @@ -749,7 +749,7 @@ kernel_do_deploy() {
>   done
>   fi
>  }
> -do_deploy[prefuncs] += "package_get_auto_pr"
> +do_deploy[prefuncs] += "read_subpackage_metadata"
>  
>  addtask deploy after do_populate_sysroot do_packagedata

 I don't think this can be right. I understand why the kernel was
 expanding these early but at this point do_package hasn't
 happened so
 reading the subpackage metadata is a null op at best and
 potentially
 changes a lot more in the data store.

 I suspect this is not doing the right thing and will be something
 that
 comes back to bite us so we need something more careful here and
 I'd
 like to better understand exactly what change to the variables
 do_install and do_deploy need.
>>>
>>> I don't know exactly why it's doing this.  But I believe it is so
>>> that the
>>> PV/PKGV is expanded (AUTOINC translated).  I don't see any other
>>> reason for it
>>> to be expanded in either do_install or do_deploy.
>>>
>>> Best I can find is:
>>>
>>> kernel-artifact-names.bbclass:KERNEL_ARTIFACT_NAME ?=
>>> "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
>>>
>>> (That is then used in other places.)
>>>
>>> So the PKGV replacement is desired to be that early.
>>>
>>> I'll look into it further.
>>
>> In do_deploy, I see multiple usages of the KERNEL_ARTIFACT_NAME
>> (sometimes with
>> alternative variables.. but in the end both PKGV and PKGR are used
>> here.)
>>
>> do_deploy is after do_package/do_packagedata (where the values are
>> assigned and
>> stored).  So it should be safe for us to use the
>> read_subpackage_metadata (or
>> something new if desired) to read back in the stored PKGV (AUTOINC)
>> and PKGR
>> (PRAUTO) values.
> 
> That sounds reasonable. FWIW do_deploy doesn't have to be after
> do_package but we can arrange that in the kernel case.

Still working on the refactor, but the kernel.bbclass "do_deploy" runs after
do_packagedata, and do_packagedata is when the PKGV/PKGR dynamic items are
written.  So it's safe to do it here.

All of the other users I found were after do_package (and didn't care about PKGV
and PKGR) or were after do_packagedata.

> I'd prefer to have a more granular function to call here than
> read_subpackage_metadata, just to make it clear what is happening and
> why.

My concern is that if we don't load all of the subpackage metadata, that the
PKGV and PKGR won't be loaded -exactly- they were they were defined in
(combination of) do_package and do_packagedata.

We can limit the load to just what was written by do_packagedata, but I don't
believe this is significant less efficient or will cause issues... and doing it
this way ensures we have a single routine for future modifications.

--Mark

> Cheers,
> 
> Richard
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141835): 
https://lists.openembedded.org/g/openembedded-core/message/141835
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] local.conf.sample: Document memory resident bitbake

[Richard Purdie]

Add an example of how to enable this to local.conf.sample

Signed-off-by: Richard Purdie 
---
 {meta => metay}/conf/local.conf.sample | 10 ++
 1 file changed, 10 insertions(+)
 rename {meta => metay}/conf/local.conf.sample (96%)

diff --git a/meta/conf/local.conf.sample b/metay/conf/local.conf.sample
similarity index 96%
rename from meta/conf/local.conf.sample
rename to metay/conf/local.conf.sample
index 783d2c4c16d..efb3100d9bd 100644
--- a/meta/conf/local.conf.sample
+++ b/metay/conf/local.conf.sample
@@ -226,6 +226,16 @@ PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
 #BB_HASHSERVE = "auto"
 #BB_SIGNATURE_HANDLER = "OEEquivHash"
 
+#
+# Memory Resident Bitbake
+#
+# Bitbake's server component can stay in memory after the UI for the current 
command
+# has completed. This means subsequent commands can run faster since there is 
no need
+# for bitbake to reload cache files and so on. Number is in seconds, after 
which the
+# server will shut down.
+#
+BB_SERVER_TIMEOUT = "60"
+
 # CONF_VERSION is increased each time build/conf/ changes incompatibly and is 
used to
 # track the version of this file when it was generated. This can safely be 
ignored if
 # this doesn't mean anything to you.
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141834): 
https://lists.openembedded.org/g/openembedded-core/message/141834
Mute This Topic: https://lists.openembedded.org/mt/76417256/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] lttng-modules: Disable on riscv64

[Khem Raj]

Kernel 5.8+ and lttng requires kprobes and riscv64 lacks kprobes
Invert the COMPATIBLE_HOST regexp, as we support most of arches

Signed-off-by: Khem Raj 
---
 meta/recipes-kernel/lttng/lttng-modules_2.12.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.12.2.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.12.2.bb
index 49b7a116bc..b9b3643001 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.12.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.12.2.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
 
 inherit module
 
-COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
+COMPATIBLE_HOST_riscv64 = "null"
 
 SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
-- 
2.28.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141833): 
https://lists.openembedded.org/g/openembedded-core/message/141833
Mute This Topic: https://lists.openembedded.org/mt/76415958/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 2/5] hash equivalency and pr service

[Richard Purdie]

On Tue, 2020-08-25 at 09:16 -0500, Mark Hatle wrote:
> On 8/25/20 7:50 AM, Joshua Watt wrote:
> > On Mon, Aug 24, 2020 at 6:29 PM Mark Hatle
> >  wrote:
> > > +PKGDATA_VARS_NOHASH = "EXTENDPRAUTO"
> > 
> > There are so many hashes to keep track of, can we make it more
> > specific than just "HASH"? How about "PKGDATA_VARS_NOOUTHASH" ?
> 
> After talking with RP, I'm getting rid of the oe_nohash file
> completely.  It's
> not needed any longer (after the second part of the patch.)
> 
> We still need a way to do this clearing of the variable and such --
> and I'm not
> particular about the name.. but NOTOUTHASH doesn't seem to be any
> better to me
> then NOHASH in this case.

Except we do call this "outhash" in various places...

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141832): 
https://lists.openembedded.org/g/openembedded-core/message/141832
Mute This Topic: https://lists.openembedded.org/mt/76396877/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] libubootenv: inherit uboot-config

[Ming Liu]

From: Ming Liu 

This mainly aims to involve in the sanity check of UBOOT_CONFIG and
UBOOT_MACHINE, it will throw a error message at recipe parsing time if
neither of them is set, and libubootenv would be skipped.

Signed-off-by: Ming Liu 
---
 meta/recipes-bsp/u-boot/libubootenv_0.3.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.3.bb
index 47e64f9114..07711484ac 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.3.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.bb
@@ -15,7 +15,7 @@ SRCREV = "ad253cfdb07c8492f2ee46a52fbc607ad0b96414"
 
 S = "${WORKDIR}/git"
 
-inherit cmake lib_package
+inherit uboot-config cmake lib_package
 
 EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
 
-- 
2.28.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141831): 
https://lists.openembedded.org/g/openembedded-core/message/141831
Mute This Topic: https://lists.openembedded.org/mt/76412466/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Richard Purdie]

On Tue, 2020-08-25 at 11:52 -0500, Mark Hatle wrote:
> 
> On 8/25/20 9:14 AM, Mark Hatle wrote:
> > 
> > On 8/25/20 5:56 AM, Richard Purdie wrote:
> > > On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
> > > > A related change was also needed for the kernel.bbclass.  The
> > > > kernel
> > > > 
> > > > needs to get the AUTOINC values used by the various PV/PKGV,
> > > > but with
> > > > this new system we don't want to call auto_pr each time --
> > > > instead
> > > > call the read_subpackage_metadata to ensure a consistent
> > > > result.
> > > > 
> > > > This also fixes an issue in the old version where the kernel
> > > > sometimes
> > > > caused the PR to be incremented twice, as the auto_pr was
> > > > called
> > > > multiple times from different tasks.
> > > 
> > > [...]
> > > 
> > > > diff --git a/meta/classes/kernel.bbclass
> > > > b/meta/classes/kernel.bbclass
> > > > index e2ceb6a333..4449452065 100644
> > > > --- a/meta/classes/kernel.bbclass
> > > > +++ b/meta/classes/kernel.bbclass
> > > > @@ -416,7 +416,7 @@ kernel_do_install() {
> > > > install -d ${D}${sysconfdir}/modules-load.d
> > > > install -d ${D}${sysconfdir}/modprobe.d
> > > >  }
> > > > -do_install[prefuncs] += "package_get_auto_pr"
> > > > +do_install[prefuncs] += "read_subpackage_metadata"
> 
> I talked with Bruce on this.  We see no reason do_install[prefuncs]
> is required
> any longer.
> 
> It was when that line was written, but when the kernel was refactored
> to permit multiple kernel builds and such the need for this went
> away.

Ok, lets start with a patch to remove that call.

> > > >  # Must be ran no earlier than after do_kernel_checkout or else
> > > > Makefile won't be in ${S}/Makefile
> > > >  do_kernel_version_sanity_check() {
> > > > @@ -749,7 +749,7 @@ kernel_do_deploy() {
> > > > done
> > > > fi
> > > >  }
> > > > -do_deploy[prefuncs] += "package_get_auto_pr"
> > > > +do_deploy[prefuncs] += "read_subpackage_metadata"
> > > >  
> > > >  addtask deploy after do_populate_sysroot do_packagedata
> > > 
> > > I don't think this can be right. I understand why the kernel was
> > > expanding these early but at this point do_package hasn't
> > > happened so
> > > reading the subpackage metadata is a null op at best and
> > > potentially
> > > changes a lot more in the data store.
> > > 
> > > I suspect this is not doing the right thing and will be something
> > > that
> > > comes back to bite us so we need something more careful here and
> > > I'd
> > > like to better understand exactly what change to the variables
> > > do_install and do_deploy need.
> > 
> > I don't know exactly why it's doing this.  But I believe it is so
> > that the
> > PV/PKGV is expanded (AUTOINC translated).  I don't see any other
> > reason for it
> > to be expanded in either do_install or do_deploy.
> > 
> > Best I can find is:
> > 
> > kernel-artifact-names.bbclass:KERNEL_ARTIFACT_NAME ?=
> > "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
> > 
> > (That is then used in other places.)
> > 
> > So the PKGV replacement is desired to be that early.
> > 
> > I'll look into it further.
> 
> In do_deploy, I see multiple usages of the KERNEL_ARTIFACT_NAME
> (sometimes with
> alternative variables.. but in the end both PKGV and PKGR are used
> here.)
> 
> do_deploy is after do_package/do_packagedata (where the values are
> assigned and
> stored).  So it should be safe for us to use the
> read_subpackage_metadata (or
> something new if desired) to read back in the stored PKGV (AUTOINC)
> and PKGR
> (PRAUTO) values.

That sounds reasonable. FWIW do_deploy doesn't have to be after
do_package but we can arrange that in the kernel case.

I'd prefer to have a more granular function to call here than
read_subpackage_metadata, just to make it clear what is happening and
why.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141830): 
https://lists.openembedded.org/g/openembedded-core/message/141830
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Mark Hatle]

On 8/25/20 9:14 AM, Mark Hatle wrote:
> 
> 
> On 8/25/20 5:56 AM, Richard Purdie wrote:
>> On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
>>> A related change was also needed for the kernel.bbclass.  The kernel
>>>
>>> needs to get the AUTOINC values used by the various PV/PKGV, but with
>>> this new system we don't want to call auto_pr each time -- instead
>>> call the read_subpackage_metadata to ensure a consistent result.
>>>
>>> This also fixes an issue in the old version where the kernel
>>> sometimes
>>> caused the PR to be incremented twice, as the auto_pr was called
>>> multiple times from different tasks.
>>
>> [...]
>>
>>>
>>> diff --git a/meta/classes/kernel.bbclass
>>> b/meta/classes/kernel.bbclass
>>> index e2ceb6a333..4449452065 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -416,7 +416,7 @@ kernel_do_install() {
>>> install -d ${D}${sysconfdir}/modules-load.d
>>> install -d ${D}${sysconfdir}/modprobe.d
>>>  }
>>> -do_install[prefuncs] += "package_get_auto_pr"
>>> +do_install[prefuncs] += "read_subpackage_metadata"

I talked with Bruce on this.  We see no reason do_install[prefuncs] is required
any longer.

It was when that line was written, but when the kernel was refactored to permit
multiple kernel builds and such the need for this went away.

>>>  # Must be ran no earlier than after do_kernel_checkout or else
>>> Makefile won't be in ${S}/Makefile
>>>  do_kernel_version_sanity_check() {
>>> @@ -749,7 +749,7 @@ kernel_do_deploy() {
>>> done
>>> fi
>>>  }
>>> -do_deploy[prefuncs] += "package_get_auto_pr"
>>> +do_deploy[prefuncs] += "read_subpackage_metadata"
>>>  
>>>  addtask deploy after do_populate_sysroot do_packagedata
>>
>> I don't think this can be right. I understand why the kernel was
>> expanding these early but at this point do_package hasn't happened so
>> reading the subpackage metadata is a null op at best and potentially
>> changes a lot more in the data store.
>>
>> I suspect this is not doing the right thing and will be something that
>> comes back to bite us so we need something more careful here and I'd
>> like to better understand exactly what change to the variables
>> do_install and do_deploy need.
> 
> I don't know exactly why it's doing this.  But I believe it is so that the
> PV/PKGV is expanded (AUTOINC translated).  I don't see any other reason for it
> to be expanded in either do_install or do_deploy.
> 
> Best I can find is:
> 
> kernel-artifact-names.bbclass:KERNEL_ARTIFACT_NAME ?=
> "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
> 
> (That is then used in other places.)
> 
> So the PKGV replacement is desired to be that early.
> 
> I'll look into it further.

In do_deploy, I see multiple usages of the KERNEL_ARTIFACT_NAME (sometimes with
alternative variables.. but in the end both PKGV and PKGR are used here.)

do_deploy is after do_package/do_packagedata (where the values are assigned and
stored).  So it should be safe for us to use the read_subpackage_metadata (or
something new if desired) to read back in the stored PKGV (AUTOINC) and PKGR
(PRAUTO) values.

--Mark

> --Mark
> 
>> Cheers,
>>
>> Richard
>>
>>
>> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141829): 
https://lists.openembedded.org/g/openembedded-core/message/141829
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3] bluez5: fix builds that require ell support

[Peter A. Bigot]

Shortly after the recipe was updated to add ell as a mesh dependency
the way ell was integrated into bluez5 was changed.  BlueZ requires
ell only for mesh and for btpclient (external test programs).  It will
be ignored unless either mesh or btpclient are selected.

ell can be supplied externally, or it can be copied into the bluez
build directory from an existing sibling source directory.  Since
bitbake builds do not provide a sibling source directory tell bluez to
look for it as an external library in the conditions where it's
required.

Signed-off-by: Peter A. Bigot 
---

v3: Follow request to not make dependency unconditional, but also not
introduce conflict when only one package variant requires it

v2: Follow request to make dependency unconditional with DEPENDS

 meta/recipes-connectivity/bluez5/bluez5.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index eee7a53cd61..367c85ea120 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -42,8 +42,8 @@ PACKAGECONFIG[sixaxis] = "--enable-sixaxis,--disable-sixaxis"
 PACKAGECONFIG[tools] = "--enable-tools,--disable-tools"
 PACKAGECONFIG[threads] = "--enable-threads,--disable-threads"
 PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
-PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c ell"
-PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient, ell"
+PACKAGECONFIG[mesh] = "--enable-mesh --enable-external-ell,--disable-mesh, 
json-c ell"
+PACKAGECONFIG[btpclient] = "--enable-btpclient 
--enable-external-ell,--disable-btpclient, ell"
 PACKAGECONFIG[udev] = "--enable-udev,--disable-udev,udev"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141828): 
https://lists.openembedded.org/g/openembedded-core/message/141828
Mute This Topic: https://lists.openembedded.org/mt/76409122/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS

[Adrian]

Hi Richard,

Thank you for your reply.

On 25.08.2020 15:05, Richard Purdie wrote:
> On Tue, 2020-08-25 at 14:47 +0200, Adrian wrote:
>> Hi,
>>
>> After recent update of poky, I started to experience an issue with
>> devtool. Currently, I am using the latest zeus version. I have a
>> multiconfig environment (Xilinx ZynqMP+ with ARM64 and Microblaze). I
>> am
>> modifying my recipe compiled from local sources. The custom target
>> machine configuration sets DEAULTTUNE="cortexa53"
>>
>> When I call:
>>
>> $> devtool build peary
>> $>devtool deploy-target peary root@192.168.33.167
>>
>> I get the error:
>>
>> ERROR: No files to deploy - have you built the peary recipe? If so,
>> the
>> install step has not installed any files.
>>
>> In fact, I see that 'devtool build' creates image under
>> '/home/afiergol/poky/build/tmp/work/aarch64-poky-
>> linux/peary/1.0+git999-r0/image',
>> while 'devtool deploy-target' search for files under
>> '/home/afiergol/poky/build/tmp/work/cortexa53-poky-linux-
>> gnueabi/peary/1.0+git999-r0/image'
>>
>> If in the 'peary' recipe I add a line
>>
>> PACKAGE_ARCH = "${MACHINE_ARCH}"
>>
>> 'devtool deploy-target' starts to search under
>> '/home/afiergol/poky/build/tmp/work/aarch64-poky-linux-
>> gnueabi/peary/1.0+git999-r0/image'
>>
>> If further, I fix in the 'peary' recipe:
>>
>> TARGET_OS = "linux"
>>
>> 'devtool deploy-target' properly deploys the binaries to the target
>> machine.
>>
>> However, as I explained, I had to fix in the recipe PACKAGE_ARCH and
>> TARGET_OS variables. It is required only for devtool to work, as
>> bitbake
>> builds properly my custom Linux image containing the recipe without
>> those variables being set anywhere in my layer.
>>
>> Has anybody else experienced a similar issue? Could somebody give a
>> reference (I didn't find) to documentation which explains why and how
>> those variables need to be set (I especially concerned about
>> TARGET_OS)?
> devtool is working for other recipes in oe-core so this peary recipe is
> probably doing something which is confusing devtool. Or its perhaps the
> machine configuration. Is that a public recipe? If not, is there a
> recipe you could share which shows the issue?
>
> Basically we need some way to reproduce the issue to be able to
> comment. You certainly should not have to set those variables.
>
> Cheers,
>
> Richard
>
I am enclosing the recipe to this message (peary.bb).

When it comes to the machine configuration, its an extension of
meta-xilinx
(https://github.com/adrianf0/meta-xilinx/tree/rel-v2020.1_fastree3d).
Though, I can't share with you the full conf file, the issue related parts:

#@TYPE: Machine
#@NAME: falcon-zynqmp
#@DESCRIPTION: Machine support for Fastree SoC board.
#
SOC_VARIANT ?= "eg"
DEFAULTTUNE_falcon-zynqmp = "cortexa53"
require conf/machine/include/soc-zynqmp.inc
require conf/machine/include/machine-xilinx-default.inc

MACHINE_FEATURES = "rtc ext2 ext3 vfat"

SERIAL_CONSOLE = "115200 ttyPS0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"

EXTRA_IMAGEDEPENDS += " \
        u-boot-zynq-scr \
        arm-trusted-firmware \
        virtual/boot-bin \
        virtual/bootloader \
        virtual/bitstream \
        "

The local.conf, has nothing special, probably this is the most related
to the issue: MACHINE ??= "falcon-zynqmp"

Regards,

Adrian

DESCRIPTION = "DAQ framework for the Caribou DAQ System"

LICENSE = "LGPLv3"
LIC_FILES_CHKSUM = "file://LICENSE.md;md5=c160dd417c123daff7a62852761d8706"

SRC_URI = "git://gitlab.cern.ch/Caribou/peary.git;protocol=https;"

PV = "1.0+git${SRCPV}"
SRCREV = "2274c0873453dcd667b30ea61779b1273b329f80"

S = "${WORKDIR}/git"

inherit cmake pkgconfig

DEPENDS = "i2c-tools readline libiio"

# Specify any options you want to pass to cmake using EXTRA_OECMAKE:
EXTRA_OECMAKE = " -DBUILD_example=ON \
  -DINSTALL_PREFIX=/usr/ \
  -DCMAKE_SKIP_RPATH=ON \
  -DCMAKE_BUILD_TYPE=Release \
  -DBUILD_server=ON \
   "
FILES_${PN} += "${FILES_SOLIBSDEV}"
FILES_${PN} += "${libdir}/*"
FILES_${PN} += "usr/etc/*"

FILES_${PN}-dev = "${includedir} usr/share/*"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141827): 
https://lists.openembedded.org/g/openembedded-core/message/141827
Mute This Topic: https://lists.openembedded.org/mt/76405762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Status WW34'20

[Stephen Jolley]

Current Dev Position: YP 3.2 M3

Next Deadline: YP 3.2 M3 build date 2020/8/31 - FEATURE FREEZE

 

Next Team Meetings:

*   Bug Triage meeting Thursday  Aug. 27th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Sept. 1st at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday  Aug. 25th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.0.4 was released
*   M3 is due to close at the end of the week and this is the feature
freeze point for 3.2
*   After much debugging, we've concluded the bitbake cooker/server
launch process is terminally flawed, you can't fork a python process into
two independent python processes and have the internal python state
machinery work correctly. As such, we're going to have to make some major
changes to the way the bitbake cooker/server startup happens.
*   On a positive note, those server changes have forced many of the
memory resident bitbake bugs to the surface and the new code appears to fix
them, bringing memres bitbake much closer to being usable, maybe even
becoming a default in this release if testing goes well.
*   There is concern about invasive changes like this with regard to
LTS/dunfell where these bitbake bugs are also present. Ultimately we will
make a decision about backporting based upon patch stability and user
feedback from the LTS users.
*   We may delay M3 slightly to enable the bitbake server changes to
merge since these are important for release and work making/merging.
*   The number of autobuilder intermittent bugs has continued to rise
unfortunately.

You can see the list of failures we're continuing to see by searching for
the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is
proving hard to find anyone interested in helping figure these out and they
significantly hamper our testing.

*   One way to help the project is to help us with bugs that are
currently unassigned but ideally needed during YP 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   There is a proposal on the bitbake list to remove globbing support
from file:// urls. Usage of these urls currently breaks source file
checksumming which users don't realize, it can't be fixed in a sane way so
and the most common use cases has easy alternatives such as referencing a
directory as a file:// url without globs so removing globbing support
appears to be the best way forward.
*   We have switched to the 5.8 kernel by default, it's taken a while to
get through all the different issues but we appear to be there now, thanks
to Bruce for working through many of them!
*   Some long standing musl SDK issues should be resolved now.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.4 was released
*   YP 3.1.3 build date 2020/9/14
*   YP 3.1.3 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2424 (last week 2429) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1273 (last week 1271)
*   Patches in the Pending State: 502 (39%) [last week 495 (39%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141826): 
https://lists.openembedded.org/g/openembedded-core/message/141826
Mute This Topic: https://lists.openembedded.org/mt/76408034/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] kernel.bbclass: run do_symlink_kernsrc before do_patch

[Rasmus Villemoes]

There's a race between do_symlink_kernsrc and do_populate_lic, since
the latter is ordered "after do_patch"; so the two may run in
parallel. In some cases, that actually causes do_populate_lic to fail
if it happens to look for a license file somewhere under ${S} in the
short window after shutil.move and before the symlink has been
created.

Fix that by simply ordering symlink_kernsrc before do_patch. Any task
that pokes around in ${S} looking for files should be ordered after
do_patch, so this should also fix similar latent races with other ad
hoc tasks.

Signed-off-by: Rasmus Villemoes 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e2ceb6a333..cba77daa7a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -172,7 +172,7 @@ python do_symlink_kernsrc () {
 shutil.move(s, kernsrc)
 os.symlink(kernsrc, s)
 }
-addtask symlink_kernsrc before do_configure after do_unpack
+addtask symlink_kernsrc before do_patch after do_unpack
 
 inherit kernel-arch deploy
 
-- 
2.23.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141825): 
https://lists.openembedded.org/g/openembedded-core/message/141825
Mute This Topic: https://lists.openembedded.org/mt/76407816/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] [dunfell 3/3] libubootenv: uprev to v0.3

[Steve Sakoman]

On Sun, Aug 23, 2020 at 8:56 PM Ming Liu  wrote:
>
> Hi, Anuj:
>
> Thanks for the review, I think this is a good suggestion, maybe we can let it 
> inherit uboot-config bbclass. Will send a patch to master.

Yes, good suggestion! I'll hold off on taking this patch series for
dunfell until I can cherry-pick your new patch from master.

Steve


> //Ming Liu
>
> Mittal, Anuj  於 2020年8月24日 週一 上午2:03寫道：
>>
>> On Sat, 2020-08-22 at 17:22 +0200, Ming Liu wrote:
>> > From: Ming Liu 
>> >
>> > Update libubootenv to the latest 0.3 release, which comprises the
>> > following commits:
>> >
>> > ```
>> > 1efed83 Increase max length for device name
>> > 6f4fc1c uboot_env: Use canonicalized pathname when reading device
>> > 23b3086 Fix bug introduced by commit 52a70114
>> > ed1a53e Dont store to device if no value changes
>> > 4a0a466 Merge pull request #7 from TomzBench/cmake-fix
>> > 6117831 Added Coverity badge
>> > 49372a1 Fix coverity #293496
>> > 69a6819 Fix coverity #293503 and #293507
>> > 258bf52 Fix coverity #293501
>> > aa52e61 Fix coverity #293505
>> > 52a7011 Fix coverity #293504 and #293506
>> > e822218 Fix coverity #293495 and #293497
>> > 23b305f Fix coverity #293499
>> > 25ef1f6 Add coverity setup for Travis
>> > 41b5188 fixed install for static target, fixed BUILD_DOC
>> > acknowledgement
>> > 86bd30a Restore ability to feed script file via stdin, using `-s -`.
>> > c91dcca ubi, write: fix invalid envsize ptr to UBI_IOCVOLUP
>> > f4b9cde Allow negative offsets
>> > 45bf92a Detect sector size if not found in config
>> > 9f59db6 uboot_env: remove unused variables
>> > 65d243e README: libubootenv is now in oe-core
>> > ba952d0 BUG: variable lists not released in close()
>> > 690f868 Variables are not removed when loading from file
>> > 9e3586a Make sure there's no file descriptor leakage in case of error
>> > 03647c4 Check config file defines a non-zero Sector size
>> > 3b2d4f1 Check environment size from fw_env.config
>> > 879c073 Do not hardcode path for install
>> > d9c639b libubootenv: add pkg-config support
>> > cc628ee libuboot: wrap libuboot in extern "C" for C++
>> > ```
>> >
>> > Also add u-boot-default-env to RRECOMMENDS since
>> > /etc/u-boot-initial-env is being referred in libubootenv source, and
>> > turns libubootenv's PACKAGE_ARCH to be MACHINE_ARCH since
>> > u-boot-default-env is a machine-arch package.
>> >
>> > Signed-off-by: Ming Liu 
>> > Signed-off-by: Richard Purdie 
>> > (cherry picked from commit 02d55cd35aac15095fc44f0cf8f9e7a71638f485)
>> > ---
>> >  .../u-boot/{libubootenv_0.2.bb => libubootenv_0.3.bb}  | 7
>> > +--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >  rename meta/recipes-bsp/u-boot/{libubootenv_0.2.bb =>
>> > libubootenv_0.3.bb} (82%)
>> >
>> > diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> > b/meta/recipes-bsp/u-boot/libubootenv_0.3.bb
>> > similarity index 82%
>> > rename from meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> > rename to meta/recipes-bsp/u-boot/libubootenv_0.3.bb
>> > index ea29b668e8..47e64f9114 100644
>> > --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> > +++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.bb
>> > @@ -10,9 +10,8 @@ LICENSE = "LGPL-2.1"
>> >  LIC_FILES_CHKSUM = "file://Licenses/lgpl-
>> > 2.1.txt;md5=4fbd65380cdd255951079008b364516c"
>> >  SECTION = "libs"
>> >
>> > -PV = "0.2+git${SRCPV}"
>> >  SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
>> > -SRCREV = "f4b9cde3815abe84a98079cedd515283ea08c16b"
>> > +SRCREV = "ad253cfdb07c8492f2ee46a52fbc607ad0b96414"
>> >
>> >  S = "${WORKDIR}/git"
>> >
>> > @@ -24,4 +23,8 @@ DEPENDS = "zlib"
>> >  PROVIDES += "u-boot-fw-utils"
>> >  RPROVIDES_${PN}-bin += "u-boot-fw-utils"
>> >
>> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> > +
>> > +RRECOMMENDS_${PN}-bin_append_class-target = " u-boot-default-env"
>> > +
>>
>> This causes world builds to fail when uboot build is skipped for a
>> MACHINE value for example when UBOOT_CONFIG or UBOOT_MACHINE is not
>> defined. Perhaps this recipe should also be skipped in those cases?
>>
>> Thanks,
>>
>> Anuj
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141824): 
https://lists.openembedded.org/g/openembedded-core/message/141824
Mute This Topic: https://lists.openembedded.org/mt/76349013/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 2/5] hash equivalency and pr service

[Mark Hatle]

On 8/25/20 7:50 AM, Joshua Watt wrote:
> On Mon, Aug 24, 2020 at 6:29 PM Mark Hatle
>  wrote:
>>
>> When the PR service is enabled a number of small changes happen to variables.
>>
>> During the do_package task, EXTENDPRAUTO will get a value placed into it that
>> is intended to be used to extend the PR.  This value will get written to
>> various intermediate files and will result in the computed hash never being
>> equivalent.
>>
>> To resolve this issue, we create a new file with the extension ".oe_nohash".
>> This extension contains various values that need to be passed from task to
>> task, but NOT calculated within the scope of the task hash.  The items
>> placed into the nohash are captured in package.bbclass in PKGDATA_VAR_NOHASH.
>>
>> The PKGDATA_VAR_NOHASH is also used to prevent expansion of the value when
>> users are written to the various pkgdata files.  This expansion is prevented
>> by removeing the variables, resulting in the system printing the literal
>> ${VAR} when used.
>>
>> Additionally package dependencies rely on variables that also eventually
>> include EXTENDPRAUTO.  So instead of resolving the variable at getVar time,
>> we keep them as references by using the same technique as above.
>>
>> Due to this change, buildhistory needs a few minor modifications to
>> know how to deal with EXTENDPRAUTO not always being available for comparison.
>>
>> Signed-off-by: Mark Hatle 
>> ---
>>  meta/classes/buildhistory.bbclass | 29 ++
>>  meta/classes/package.bbclass  | 63 ---
>>  meta/lib/oe/packagedata.py|  8 +++-
>>  meta/lib/oe/sstatesig.py  |  2 +
>>  4 files changed, 80 insertions(+), 22 deletions(-)
>>
>> diff --git a/meta/classes/buildhistory.bbclass 
>> b/meta/classes/buildhistory.bbclass
>> index 805e976ac5..2bccdfc953 100644
>> --- a/meta/classes/buildhistory.bbclass
>> +++ b/meta/classes/buildhistory.bbclass
>> @@ -99,6 +99,7 @@ python buildhistory_emit_pkghistory() {
>>  import json
>>  import shlex
>>  import errno
>> +import oe.packagedata
>>
>>  pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE')
>>  oldpkghistdir = d.getVar('BUILDHISTORY_OLD_DIR_PACKAGE')
>> @@ -127,6 +128,7 @@ python buildhistory_emit_pkghistory() {
>>  self.pkge = ""
>>  self.pkgv = ""
>>  self.pkgr = ""
>> +self.extendprauto = ""
>>  self.size = 0
>>  self.depends = ""
>>  self.rprovides = ""
>> @@ -163,6 +165,8 @@ python buildhistory_emit_pkghistory() {
>>  pkginfo.pkgv = value
>>  elif name == "PKGR":
>>  pkginfo.pkgr = value
>> +elif name == "EXTENDPRAUTO":
>> +pkginfo.extendprauto = value
>>  elif name == "RPROVIDES":
>>  pkginfo.rprovides = value
>>  elif name == "RDEPENDS":
>> @@ -260,18 +264,24 @@ python buildhistory_emit_pkghistory() {
>>
>>  pkgdest = d.getVar('PKGDEST')
>>  for pkg in packagelist:
>> -pkgdata = {}
>> -with open(os.path.join(pkgdata_dir, 'runtime', pkg)) as f:
>> -for line in f.readlines():
>> -item = line.rstrip('\n').split(': ', 1)
>> -key = item[0]
>> -if key.endswith('_' + pkg):
>> -key = key[:-len(pkg)-1]
>> -pkgdata[key] = 
>> item[1].encode('latin-1').decode('unicode_escape')
>> +pkgdata = oe.packagedata.read_pkgdatafile(os.path.join(pkgdata_dir, 
>> 'runtime', pkg))
>> +
>> +npkgdata = {}
>> +for key in pkgdata.keys():
>> +if key.endswith('_' + pkg):
>> +nkey = key[:-len(pkg)-1]
>> +npkgdata[nkey] = pkgdata[key]
>> +
>> +for key in npkgdata.keys():
>> +  pkgdata[key] = npkgdata[key]
>>
>>  pkge = pkgdata.get('PKGE', '0')
>>  pkgv = pkgdata['PKGV']
>>  pkgr = pkgdata['PKGR']
>> +try:
>> +extendprauto = pkgdata['EXTENDPRAUTO']
>> +except IndexError:
>> +extendprauto = d.getVar('EXTENDPRAUTO')
>>  #
>>  # Find out what the last version was
>>  # Make sure the version did not decrease
>> @@ -295,6 +305,7 @@ python buildhistory_emit_pkghistory() {
>>  pkginfo.pkge = pkge
>>  pkginfo.pkgv = pkgv
>>  pkginfo.pkgr = pkgr
>> +pkginfo.extendprauto = extendprauto
>>  pkginfo.rprovides = 
>> sortpkglist(oe.utils.squashspaces(pkgdata.get('RPROVIDES', "")))
>>  pkginfo.rdepends = 
>> sortpkglist(oe.utils.squashspaces(pkgdata.get('RDEPENDS', "")))
>>  pkginfo.rrecommends = 
>> sortpkglist(oe.utils.squashspaces(pkgdata.get('RRECOMMENDS', "")))
>> @@ -398,6 +409,8 @@ def write_pkghistory(pkginfo, d):
>>  f.write(u"PKGV = %s\n" % pkginfo.pkgv)
>>  if pkginfo.pkgr != pkginfo.pr:
>>  f.write(u"PKGR = %s\n" % pkgin

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Mark Hatle]

On 8/25/20 5:56 AM, Richard Purdie wrote:
> On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
>> A related change was also needed for the kernel.bbclass.  The kernel
>>
>> needs to get the AUTOINC values used by the various PV/PKGV, but with
>> this new system we don't want to call auto_pr each time -- instead
>> call the read_subpackage_metadata to ensure a consistent result.
>>
>> This also fixes an issue in the old version where the kernel
>> sometimes
>> caused the PR to be incremented twice, as the auto_pr was called
>> multiple times from different tasks.
> 
> [...]
> 
>>
>> diff --git a/meta/classes/kernel.bbclass
>> b/meta/classes/kernel.bbclass
>> index e2ceb6a333..4449452065 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -416,7 +416,7 @@ kernel_do_install() {
>>  install -d ${D}${sysconfdir}/modules-load.d
>>  install -d ${D}${sysconfdir}/modprobe.d
>>  }
>> -do_install[prefuncs] += "package_get_auto_pr"
>> +do_install[prefuncs] += "read_subpackage_metadata"
>>  
>>  # Must be ran no earlier than after do_kernel_checkout or else
>> Makefile won't be in ${S}/Makefile
>>  do_kernel_version_sanity_check() {
>> @@ -749,7 +749,7 @@ kernel_do_deploy() {
>>  done
>>  fi
>>  }
>> -do_deploy[prefuncs] += "package_get_auto_pr"
>> +do_deploy[prefuncs] += "read_subpackage_metadata"
>>  
>>  addtask deploy after do_populate_sysroot do_packagedata
> 
> I don't think this can be right. I understand why the kernel was
> expanding these early but at this point do_package hasn't happened so
> reading the subpackage metadata is a null op at best and potentially
> changes a lot more in the data store.
> 
> I suspect this is not doing the right thing and will be something that
> comes back to bite us so we need something more careful here and I'd
> like to better understand exactly what change to the variables
> do_install and do_deploy need.

I don't know exactly why it's doing this.  But I believe it is so that the
PV/PKGV is expanded (AUTOINC translated).  I don't see any other reason for it
to be expanded in either do_install or do_deploy.

Best I can find is:

kernel-artifact-names.bbclass:KERNEL_ARTIFACT_NAME ?=
"${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"

(That is then used in other places.)

So the PKGV replacement is desired to be that early.

I'll look into it further.

--Mark

> Cheers,
> 
> Richard
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141822): 
https://lists.openembedded.org/g/openembedded-core/message/141822
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] file checksums versus SRC_URI globs

[Richard Purdie]

On Thu, 2020-07-09 at 21:31 +0200, Rasmus Villemoes wrote:
> On 02/07/2020 08.42, Rasmus Villemoes via lists.openembedded.org wrote:
> > On 01/07/2020 16.03, Quentin Schulz wrote:
> > > Hi Rasmus,
> > > 
> > > On Wed, Jul 01, 2020 at 03:51:19PM +0200, Rasmus Villemoes wrote:
> > > > Hi,
> > > > 
> > > > We have a recipe that uses
> > > > 
> > > >   SRC_URI += "file://somedir/*"
> > > > 
> > > 
> > > Glob aren't supported. Use "file://somedir/" instead.
> > 
> > Thanks, that actually works for one of the cases we have (there are
> > others that use globs which cannot be solved quite that simply, but for
> > now I'm just listing files explicitly instead).
> > 
> > However, I'm not sure that "globs aren't supported". The commit I
> > referenced clearly tried to make that work (better), it also "works" in
> > the sense of unpacking the expected things when building from scratch -
> > there's even
> > 
> > def test_local_wildcard(self):
> > tree = self.fetchUnpack(['file://a', 'file://dir/*'])
> > self.assertEqual(tree, ['a',  'dir/c', 'dir/d', 'dir/subdir/e'])
> > 
> > in bitbake/lib/bb/tests/fetch.py. And the two upstream recipes
> > connman-gnome_0.7.bb and matchbox-desktop_2.2.bb both use that exact
> > pattern.
> > 
> > So either
> > 
> > - this is a plain bug in the signature computation,
> 
> I'm guessing the culprit is
> 
> commit 6c0706a28d72c591f1b75b6e3f3b645859387c7e
> Author: Richard Purdie 
> Date:   Mon Dec 8 21:25:23 2014 +
> 
> cache/fetch2/siggen: Ensure we track include history for file checksums
> 
> which was the one that introduced the ":True: or ":False" suffixing via
> 
> +filelist.append(f + ":" + str(os.path.exists(f)))
> 
> and then also did
> 
> @@ -981,6 +980,10 @@ def get_file_checksums(filelist, pn):
> 
>  checksums = []
>  for pth in filelist.split():
> +exist = pth.split(":")[1]
> +if exist == "False":
> +continue
> +pth = pth.split(":")[0]
>  if '*' in pth:
>  # Handle globs
>  for f in glob.glob(pth):
> 
> which practically guaranteed that the "if '*' in pth" would be dead code.
> 
> Richard, do you agree that this is a bug in the signature computation?
> 
> As I wrote previously, there's no warning anywhere that using globs in
> SRC_URI will fail to take the contents of the referenced file into
> account in hashes, but there's obviously still a some code that makes
> file://*.c work wrt. unpacking (and a test case for that).

Sorry about the delay in replying to this, it was flagged in my inbox,
I've just lacked time to investigate and resolve it.

I agree its a bug but my patch above didn't break globing support for
file checksums, its simply never worked even before that change. After
a lot of thought, I've also concluded that I don't think it can work in
a sane way (which is why it was never implemented).

The checksum code needs to know about the files that were searched that
didn't exist as well as those that existed and were checksumed. For the
simple file://xxx/* url that is possible but for more imaginative
globs, its hard. In the file://xxx/* case it may as well be file://xxx/
 in the url which works and is already checksumed correctly.

I've therefore sent out patches to remove the globbing support and
clean up the couple of existing references in OE-Core which are
trivially adapted.

I appreciate this isn't the answer you want but I can't realistically
see how to make this work properly in a sane way that scales. I do
agree the pretence it works is bad though so want to fix that.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141821): 
https://lists.openembedded.org/g/openembedded-core/message/141821
Mute This Topic: https://lists.openembedded.org/mt/75235594/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bluez5: fix builds that require ell support

[Alexander Kanavin]

This doesn't make it clear, is ell (external or internal) required for all
bluez builds now, or is it still optional? Adding mandatory dependencies
should be better justified.

Alex

On Tue, 25 Aug 2020 at 15:43, Peter A. Bigot  wrote:

> Shortly after the recipe was updated to add ell as a mesh dependency
> the way ell was integrated into bluez5 was changed.  Use the external
> ell dependency rather than the default to build one internal to
> bluez5.
> ---
>  meta/recipes-connectivity/bluez5/bluez5.inc | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index eee7a53cd61..9b38bda5a79 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -6,7 +6,7 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
>
>  file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
>
>  
> file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
> -DEPENDS = "dbus glib-2.0"
> +DEPENDS = "dbus ell glib-2.0"
>  PROVIDES += "bluez-hcidump"
>  RPROVIDES_${PN} += "bluez-hcidump"
>
> @@ -42,8 +42,8 @@ PACKAGECONFIG[sixaxis] =
> "--enable-sixaxis,--disable-sixaxis"
>  PACKAGECONFIG[tools] = "--enable-tools,--disable-tools"
>  PACKAGECONFIG[threads] = "--enable-threads,--disable-threads"
>  PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
> -PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c ell"
> -PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient, ell"
> +PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c"
> +PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient"
>  PACKAGECONFIG[udev] = "--enable-udev,--disable-udev,udev"
>
>  SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> @@ -63,6 +63,7 @@ EXTRA_OECONF = "\
>--enable-test \
>--enable-datafiles \
>--enable-library \
> +  --enable-external-ell \
>--without-zsh-completion-dir \
>  "
>
> --
> 2.25.1
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141820): 
https://lists.openembedded.org/g/openembedded-core/message/141820
Mute This Topic: https://lists.openembedded.org/mt/76406740/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for bluez5: fix builds that require ell support (rev2)

[Patchwork]

== Series Details ==

Series: bluez5: fix builds that require ell support (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/25757/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[v2] bluez5: fix builds that require ell support
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141818): 
https://lists.openembedded.org/g/openembedded-core/message/141818
Mute This Topic: https://lists.openembedded.org/mt/76407116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for "connman-gnome/matchbox-desktop..." and 1 more

[Patchwork]

== Series Details ==

Series: "connman-gnome/matchbox-desktop..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/25770/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Errors in your Python code were encountered [test_pylint] 
  Suggested fixCorrect the lines introduced by your patch
  Output   Please, fix the listed issues:
   meta/lib/oeqa/selftest/cases/recipetool.py does not exist



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141819): 
https://lists.openembedded.org/g/openembedded-core/message/141819
Mute This Topic: https://lists.openembedded.org/mt/76407118/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] selftest/recipetool: Drop globbing SRC_URI test, no longer supported

[Richard Purdie]

Globbing is a bad idea in SRC_URI, it breaks the task checksums and
can't really be fixed. Since we're removing it, drop the test for
its interaction with recipetool.

Signed-off-by: Richard Purdie 
---
 .../files/selftest-replaceme-src-globfile   |  1 -
 .../recipetool/selftest-recipetool-appendfile.bb|  2 --
 meta/lib/oeqa/selftest/cases/recipetool.py  | 13 -
 3 files changed, 16 deletions(-)
 delete mode 100644 
meta-selftest/recipes-test/recipetool/files/selftest-replaceme-src-globfile

diff --git 
a/meta-selftest/recipes-test/recipetool/files/selftest-replaceme-src-globfile 
b/meta-selftest/recipes-test/recipetool/files/selftest-replaceme-src-globfile
deleted file mode 100644
index 1e20a2b03eb..000
--- 
a/meta-selftest/recipes-test/recipetool/files/selftest-replaceme-src-globfile
+++ /dev/null
@@ -1 +0,0 @@
-A file matched by a glob in SRC_URI
diff --git 
a/meta-selftest/recipes-test/recipetool/selftest-recipetool-appendfile.bb 
b/meta-selftest/recipes-test/recipetool/selftest-recipetool-appendfile.bb
index 7375c479330..b5f976708f4 100644
--- a/meta-selftest/recipes-test/recipetool/selftest-recipetool-appendfile.bb
+++ b/meta-selftest/recipes-test/recipetool/selftest-recipetool-appendfile.bb
@@ -10,7 +10,6 @@ SRC_URI = "file://installscript.sh \
file://file1 \
file://add-file.patch \
file://subdir \
-   file://selftest-replaceme-src-glob* \
file://selftest-replaceme-inst-globfile \
file://selftest-replaceme-inst-todir-globfile \
file://selftest-replaceme-inst-func"
@@ -27,7 +26,6 @@ do_install() {
install -m 0644 ${WORKDIR}/selftest-replaceme-todir ${D}${datadir}
install -m 0644 ${WORKDIR}/file1 
${D}${datadir}/selftest-replaceme-renamed
install -m 0644 ${WORKDIR}/subdir/fileinsubdir 
${D}${datadir}/selftest-replaceme-subdir
-   install -m 0644 ${WORKDIR}/selftest-replaceme-src-globfile 
${D}${datadir}/selftest-replaceme-src-globfile
cp ${WORKDIR}/selftest-replaceme-inst-glob* 
${D}${datadir}/selftest-replaceme-inst-globfile
cp ${WORKDIR}/selftest-replaceme-inst-todir-glob* ${D}${datadir}
install -d ${D}${sysconfdir}
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index c2ade2543a3..6bac53cf3da 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -226,19 +226,6 @@ class RecipetoolTests(RecipetoolBase):
 _, output = 
self._try_recipetool_appendfile('selftest-recipetool-appendfile', 
'/usr/share/selftest-replaceme-subdir', self.testfile, '', expectedlines, 
['testfile'])
 self.assertNotIn('WARNING: ', output)
 
-def test_recipetool_appendfile_src_glob(self):
-# A file that's in SRC_URI as a glob
-expectedlines = ['FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"\n',
- '\n',
- 'SRC_URI += "file://testfile"\n',
- '\n',
- 'do_install_append() {\n',
- 'install -d ${D}${datadir}\n',
- 'install -m 0644 ${WORKDIR}/testfile 
${D}${datadir}/selftest-replaceme-src-globfile\n',
- '}\n']
-_, output = 
self._try_recipetool_appendfile('selftest-recipetool-appendfile', 
'/usr/share/selftest-replaceme-src-globfile', self.testfile, '', expectedlines, 
['testfile'])
-self.assertNotIn('WARNING: ', output)
-
 def test_recipetool_appendfile_inst_glob(self):
 # A file that's in do_install as a glob
 expectedlines = ['FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"\n',
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141817): 
https://lists.openembedded.org/g/openembedded-core/message/141817
Mute This Topic: https://lists.openembedded.org/mt/76406981/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] connman-gnome/matchbox-desktop: Remove file:// globbing

[Richard Purdie]

A directory can be specified in SRC_URI, there is no need to use
globbing. This means that the files are checksummed correctly and
the recipe rebuilds when the files change as globbing breaks that.

We're about to remove the use of globbing in SRC_URI so improve these.

Signed-off-by: Richard Purdie 
---
 meta/recipes-connectivity/connman/connman-gnome_0.7.bb | 2 +-
 meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.2.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb 
b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
index 778bf501918..af986c4eab3 100644
--- a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
+++ b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
@@ -13,7 +13,7 @@ SRCREV = "cf3c325b23dae843c5499a113591cfbc98acb143"
 SRC_URI = "git://github.com/connectivity/connman-gnome.git \
file://0001-Removed-icon-from-connman-gnome-about-applet.patch \
file://null_check_for_ipv4_config.patch \
-   file://images/* \
+   file://images/ \
file://connman-gnome-fix-dbus-interface-name.patch \
file://0001-Port-to-Gtk3.patch \
   "
diff --git a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.2.bb 
b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.2.bb
index 5c23e852021..e7d8a284bb6 100644
--- a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.2.bb
+++ b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.2.bb
@@ -13,7 +13,7 @@ SECTION = "x11/wm"
 # SRCREV tagged 2.2
 SRCREV = "6bc67d09da4147e5552fe30011a05a2c59d2f777"
 SRC_URI = "git://git.yoctoproject.org/${BPN}-2 \
-   file://vfolders/* \
+   file://vfolders/ \
"
 
 EXTRA_OECONF = "--enable-startup-notification --with-dbus"
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141816): 
https://lists.openembedded.org/g/openembedded-core/message/141816
Mute This Topic: https://lists.openembedded.org/mt/76406978/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] bluez5: fix builds that require ell support

[Peter A. Bigot]

Shortly after the recipe was updated to add ell as a mesh dependency
the way ell was integrated into bluez5 was changed.  Use the external
ell dependency rather than the default to build one internal to
bluez5.
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index eee7a53cd61..9b38bda5a79 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -6,7 +6,7 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
 file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
 
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
-DEPENDS = "dbus glib-2.0"
+DEPENDS = "dbus ell glib-2.0"
 PROVIDES += "bluez-hcidump"
 RPROVIDES_${PN} += "bluez-hcidump"
 
@@ -42,8 +42,8 @@ PACKAGECONFIG[sixaxis] = "--enable-sixaxis,--disable-sixaxis"
 PACKAGECONFIG[tools] = "--enable-tools,--disable-tools"
 PACKAGECONFIG[threads] = "--enable-threads,--disable-threads"
 PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
-PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c ell"
-PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient, ell"
+PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c"
+PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient"
 PACKAGECONFIG[udev] = "--enable-udev,--disable-udev,udev"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
@@ -63,6 +63,7 @@ EXTRA_OECONF = "\
   --enable-test \
   --enable-datafiles \
   --enable-library \
+  --enable-external-ell \
   --without-zsh-completion-dir \
 "
 
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141815): 
https://lists.openembedded.org/g/openembedded-core/message/141815
Mute This Topic: https://lists.openembedded.org/mt/76406740/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS

[Richard Purdie]

On Tue, 2020-08-25 at 14:47 +0200, Adrian wrote:
> Hi,
> 
> After recent update of poky, I started to experience an issue with
> devtool. Currently, I am using the latest zeus version. I have a
> multiconfig environment (Xilinx ZynqMP+ with ARM64 and Microblaze). I
> am
> modifying my recipe compiled from local sources. The custom target
> machine configuration sets DEAULTTUNE="cortexa53"
> 
> When I call:
> 
> $> devtool build peary
> $>devtool deploy-target peary root@192.168.33.167
> 
> I get the error:
> 
> ERROR: No files to deploy - have you built the peary recipe? If so,
> the
> install step has not installed any files.
> 
> In fact, I see that 'devtool build' creates image under
> '/home/afiergol/poky/build/tmp/work/aarch64-poky-
> linux/peary/1.0+git999-r0/image',
> while 'devtool deploy-target' search for files under
> '/home/afiergol/poky/build/tmp/work/cortexa53-poky-linux-
> gnueabi/peary/1.0+git999-r0/image'
> 
> If in the 'peary' recipe I add a line
> 
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> 
> 'devtool deploy-target' starts to search under
> '/home/afiergol/poky/build/tmp/work/aarch64-poky-linux-
> gnueabi/peary/1.0+git999-r0/image'
> 
> If further, I fix in the 'peary' recipe:
> 
> TARGET_OS = "linux"
> 
> 'devtool deploy-target' properly deploys the binaries to the target
> machine.
> 
> However, as I explained, I had to fix in the recipe PACKAGE_ARCH and
> TARGET_OS variables. It is required only for devtool to work, as
> bitbake
> builds properly my custom Linux image containing the recipe without
> those variables being set anywhere in my layer.
> 
> Has anybody else experienced a similar issue? Could somebody give a
> reference (I didn't find) to documentation which explains why and how
> those variables need to be set (I especially concerned about
> TARGET_OS)?

devtool is working for other recipes in oe-core so this peary recipe is
probably doing something which is confusing devtool. Or its perhaps the
machine configuration. Is that a public recipe? If not, is there a
recipe you could share which shows the issue?

Basically we need some way to reproduce the issue to be able to
comment. You certainly should not have to set those variables.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141814): 
https://lists.openembedded.org/g/openembedded-core/message/141814
Mute This Topic: https://lists.openembedded.org/mt/76405762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 2/5] hash equivalency and pr service

[Joshua Watt]

On Mon, Aug 24, 2020 at 6:29 PM Mark Hatle
 wrote:
>
> When the PR service is enabled a number of small changes happen to variables.
>
> During the do_package task, EXTENDPRAUTO will get a value placed into it that
> is intended to be used to extend the PR.  This value will get written to
> various intermediate files and will result in the computed hash never being
> equivalent.
>
> To resolve this issue, we create a new file with the extension ".oe_nohash".
> This extension contains various values that need to be passed from task to
> task, but NOT calculated within the scope of the task hash.  The items
> placed into the nohash are captured in package.bbclass in PKGDATA_VAR_NOHASH.
>
> The PKGDATA_VAR_NOHASH is also used to prevent expansion of the value when
> users are written to the various pkgdata files.  This expansion is prevented
> by removeing the variables, resulting in the system printing the literal
> ${VAR} when used.
>
> Additionally package dependencies rely on variables that also eventually
> include EXTENDPRAUTO.  So instead of resolving the variable at getVar time,
> we keep them as references by using the same technique as above.
>
> Due to this change, buildhistory needs a few minor modifications to
> know how to deal with EXTENDPRAUTO not always being available for comparison.
>
> Signed-off-by: Mark Hatle 
> ---
>  meta/classes/buildhistory.bbclass | 29 ++
>  meta/classes/package.bbclass  | 63 ---
>  meta/lib/oe/packagedata.py|  8 +++-
>  meta/lib/oe/sstatesig.py  |  2 +
>  4 files changed, 80 insertions(+), 22 deletions(-)
>
> diff --git a/meta/classes/buildhistory.bbclass 
> b/meta/classes/buildhistory.bbclass
> index 805e976ac5..2bccdfc953 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -99,6 +99,7 @@ python buildhistory_emit_pkghistory() {
>  import json
>  import shlex
>  import errno
> +import oe.packagedata
>
>  pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE')
>  oldpkghistdir = d.getVar('BUILDHISTORY_OLD_DIR_PACKAGE')
> @@ -127,6 +128,7 @@ python buildhistory_emit_pkghistory() {
>  self.pkge = ""
>  self.pkgv = ""
>  self.pkgr = ""
> +self.extendprauto = ""
>  self.size = 0
>  self.depends = ""
>  self.rprovides = ""
> @@ -163,6 +165,8 @@ python buildhistory_emit_pkghistory() {
>  pkginfo.pkgv = value
>  elif name == "PKGR":
>  pkginfo.pkgr = value
> +elif name == "EXTENDPRAUTO":
> +pkginfo.extendprauto = value
>  elif name == "RPROVIDES":
>  pkginfo.rprovides = value
>  elif name == "RDEPENDS":
> @@ -260,18 +264,24 @@ python buildhistory_emit_pkghistory() {
>
>  pkgdest = d.getVar('PKGDEST')
>  for pkg in packagelist:
> -pkgdata = {}
> -with open(os.path.join(pkgdata_dir, 'runtime', pkg)) as f:
> -for line in f.readlines():
> -item = line.rstrip('\n').split(': ', 1)
> -key = item[0]
> -if key.endswith('_' + pkg):
> -key = key[:-len(pkg)-1]
> -pkgdata[key] = 
> item[1].encode('latin-1').decode('unicode_escape')
> +pkgdata = oe.packagedata.read_pkgdatafile(os.path.join(pkgdata_dir, 
> 'runtime', pkg))
> +
> +npkgdata = {}
> +for key in pkgdata.keys():
> +if key.endswith('_' + pkg):
> +nkey = key[:-len(pkg)-1]
> +npkgdata[nkey] = pkgdata[key]
> +
> +for key in npkgdata.keys():
> +  pkgdata[key] = npkgdata[key]
>
>  pkge = pkgdata.get('PKGE', '0')
>  pkgv = pkgdata['PKGV']
>  pkgr = pkgdata['PKGR']
> +try:
> +extendprauto = pkgdata['EXTENDPRAUTO']
> +except IndexError:
> +extendprauto = d.getVar('EXTENDPRAUTO')
>  #
>  # Find out what the last version was
>  # Make sure the version did not decrease
> @@ -295,6 +305,7 @@ python buildhistory_emit_pkghistory() {
>  pkginfo.pkge = pkge
>  pkginfo.pkgv = pkgv
>  pkginfo.pkgr = pkgr
> +pkginfo.extendprauto = extendprauto
>  pkginfo.rprovides = 
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RPROVIDES', "")))
>  pkginfo.rdepends = 
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RDEPENDS', "")))
>  pkginfo.rrecommends = 
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RRECOMMENDS', "")))
> @@ -398,6 +409,8 @@ def write_pkghistory(pkginfo, d):
>  f.write(u"PKGV = %s\n" % pkginfo.pkgv)
>  if pkginfo.pkgr != pkginfo.pr:
>  f.write(u"PKGR = %s\n" % pkginfo.pkgr)
> +if pkginfo.extendprauto:
> +f.write(u"EXTENDPRAUTO = %s\n" % pkginfo.extendprauto)
>  f.write(u"RPROVIDES = %s\n" %  p

[OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS

[Adrian]

Hi,

After recent update of poky, I started to experience an issue with
devtool. Currently, I am using the latest zeus version. I have a
multiconfig environment (Xilinx ZynqMP+ with ARM64 and Microblaze). I am
modifying my recipe compiled from local sources. The custom target
machine configuration sets DEAULTTUNE="cortexa53"

When I call:

$> devtool build peary
$>devtool deploy-target peary root@192.168.33.167

I get the error:

ERROR: No files to deploy - have you built the peary recipe? If so, the
install step has not installed any files.

In fact, I see that 'devtool build' creates image under
'/home/afiergol/poky/build/tmp/work/aarch64-poky-linux/peary/1.0+git999-r0/image',
while 'devtool deploy-target' search for files under
'/home/afiergol/poky/build/tmp/work/cortexa53-poky-linux-gnueabi/peary/1.0+git999-r0/image'

If in the 'peary' recipe I add a line

PACKAGE_ARCH = "${MACHINE_ARCH}"

'devtool deploy-target' starts to search under
'/home/afiergol/poky/build/tmp/work/aarch64-poky-linux-gnueabi/peary/1.0+git999-r0/image'

If further, I fix in the 'peary' recipe:

TARGET_OS = "linux"

'devtool deploy-target' properly deploys the binaries to the target machine.

However, as I explained, I had to fix in the recipe PACKAGE_ARCH and
TARGET_OS variables. It is required only for devtool to work, as bitbake
builds properly my custom Linux image containing the recipe without
those variables being set anywhere in my layer.

Has anybody else experienced a similar issue? Could somebody give a
reference (I didn't find) to documentation which explains why and how
those variables need to be set (I especially concerned about TARGET_OS)?

Regards,

Adrian

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141812): 
https://lists.openembedded.org/g/openembedded-core/message/141812
Mute This Topic: https://lists.openembedded.org/mt/76405762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] do_populate_lic problems

[Richard Purdie]

On Tue, 2020-08-25 at 11:13 +0200, Rasmus Villemoes wrote:
> There are a couple of problems with do_populate_lic, especially
> around
> the kernel and u-boot recipes.
> 
> First, we have a race condition in kernel recipes:
> 
> addtask populate_lic after do_patch before do_build
> addtask symlink_kernsrc before do_configure after do_unpack
> 
> so there's no ordering between those two tasks. I have in fact seen
> do_populate_lic fail because (part of) it runs just between the two
> lines
> 
> shutil.move(s, kernsrc)
> os.symlink(kernsrc, s)
> 
> WARNING: Could not copy license file /mnt/...
> ...
> ERROR: QA Issue: ...: LIC_FILES_CHKSUM points to an invalid file:
> 
> and it's fairly easy to reproduce with a monkey-patch:
> 
> @@ -148,7 +148,9 @@ python do_symlink_kernsrc () {
>  os.symlink(s, kernsrc)
>  else:
>  import shutil
> +import time
>  shutil.move(s, kernsrc)
> +time.sleep(15)
>  os.symlink(kernsrc, s)
>  }
> 
> I think this could be fixed by making symlink_kernsrc run before
> do_patch rather than do_configure - in fact, AFAICT, there's the exact
> same lack of ordering with do_patch, it's just that nobody usually has
> any .patch files for the kernel when it's maintained in git.

I agree with that solution, please send a patch for that.

> Second, as I've reported previously [1], creating hard-links to files in
> kernel or u-boot source repositories, as do_populate_lic does, leads
> to scripts/setlocalversion falsely appending a "-dirty" string. It
> doesn't happen if one is building a kernel containing ff64dd485730 or
> a backport of it (e.g. v5.0+, v4.19.82+) _and_ one has git >= 2.14.
> U-Boot hasn't
> copied ff64dd485730 yet, so it can always happen for U-Boot. Since
> there's no ordering between do_populate_lic and do_compile, it's not
> even deterministic whether that -dirty string is appended. So while
> appropriate tools and patched upstream projects will make the problem
> go
> away, I'm wondering the hardlink optimization is really worth the
> trouble it causes.
> 
> [1] https://lists.openembedded.org/g/openembedded-core/message/137702

We use hardlinks a lot and it does help for disk IO and performance.
Has this issue been raised with u-boot upstream? They're usually
helpful and there are a few of the maintainers using OE so I think
they'd want to fix this if they know about it.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141811): 
https://lists.openembedded.org/g/openembedded-core/message/141811
Mute This Topic: https://lists.openembedded.org/mt/76403349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] bluez5: fix builds that require ell support

[Adrian Bunk]

On Mon, Aug 24, 2020 at 02:44:51PM -0500, Peter A. Bigot wrote:
> Shortly after the recipe was updated to add ell as a mesh dependency
> the way ell was integrated into bluez5 was changed.  Add the new
> configuration options required for an external ell.
>...
> -PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c ell"
> -PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient, ell"
> +PACKAGECONFIG[mesh] = "--enable-mesh --enable-external-ell,--disable-mesh 
> --disable-external-ell, json-c ell"
> +PACKAGECONFIG[btpclient] = "--enable-btpclient 
> --enable-external-ell,--disable-btpclient --disable-external-ell, ell"
>...

This won't work if exactly one these two options is enabled.

What about unconditional --enable-external-ell and ell DEPENDS instead?
It seems to link with the external ell only when necessary.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141810): 
https://lists.openembedded.org/g/openembedded-core/message/141810
Mute This Topic: https://lists.openembedded.org/mt/76393018/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Richard Purdie]

On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
@@ -2396,6 +2399,14 @@ addtask do_package_setscene
>  python do_packagedata () {
>  src = d.expand("${PKGDESTWORK}")
>  dest = d.expand("${WORKDIR}/pkgdata-pdata-input")
> +
> +bb.build.exec_func("package_get_auto_pr", d)
> +# Store this for later retrieval
> +data_file = src + d.expand("/${PN}_prservice.oe_nohash")
> +with open(data_file, 'w') as fd:
> +fd.write('PRAUTO: %s\n' % d.getVar('PRAUTO'))
> +fd.write('PRSERV_PV_AUTOINC: %s\n' % d.getVar("PRSERV_PV_AUTOINC"))
> +
>  oe.path.copyhardlinktree(src, dest)
>  }

My instinct here is to drop this oe_nohash file and instead, run a 

sed -i -e "s@${PRSERV_PV_AUTOINC}@val@g" -e "s@${PRAUTO}@val2@g"

over the files in dest to expand out the values.

You can then drop much of the other changes trying to expand these
things out. We don't know what out of tree things are also using the
pkgdata files and I'm not sure we should force everything through the
API either.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141809): 
https://lists.openembedded.org/g/openembedded-core/message/141809
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 4/5] package / packagedata bbclass: Change the way PRAUTO and AUTOINC are handled

[Richard Purdie]

On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
> A related change was also needed for the kernel.bbclass.  The kernel
> 
> needs to get the AUTOINC values used by the various PV/PKGV, but with
> this new system we don't want to call auto_pr each time -- instead
> call the read_subpackage_metadata to ensure a consistent result.
> 
> This also fixes an issue in the old version where the kernel
> sometimes
> caused the PR to be incremented twice, as the auto_pr was called
> multiple times from different tasks.

[...]

> 
> diff --git a/meta/classes/kernel.bbclass
> b/meta/classes/kernel.bbclass
> index e2ceb6a333..4449452065 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -416,7 +416,7 @@ kernel_do_install() {
>   install -d ${D}${sysconfdir}/modules-load.d
>   install -d ${D}${sysconfdir}/modprobe.d
>  }
> -do_install[prefuncs] += "package_get_auto_pr"
> +do_install[prefuncs] += "read_subpackage_metadata"
>  
>  # Must be ran no earlier than after do_kernel_checkout or else
> Makefile won't be in ${S}/Makefile
>  do_kernel_version_sanity_check() {
> @@ -749,7 +749,7 @@ kernel_do_deploy() {
>   done
>   fi
>  }
> -do_deploy[prefuncs] += "package_get_auto_pr"
> +do_deploy[prefuncs] += "read_subpackage_metadata"
>  
>  addtask deploy after do_populate_sysroot do_packagedata

I don't think this can be right. I understand why the kernel was
expanding these early but at this point do_package hasn't happened so
reading the subpackage metadata is a null op at best and potentially
changes a lot more in the data store.

I suspect this is not doing the right thing and will be something that
comes back to bite us so we need something more careful here and I'd
like to better understand exactly what change to the variables
do_install and do_deploy need.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141808): 
https://lists.openembedded.org/g/openembedded-core/message/141808
Mute This Topic: https://lists.openembedded.org/mt/76396872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [master][PATCH 1/5] package_tar.bbclass: Sync to the other package_* classes

[Richard Purdie]

On Mon, 2020-08-24 at 18:29 -0500, Mark Hatle wrote:
> Sync up the task definitions with the other package classes.  This may not
> have been strictly necessary but will make overall maintenance easier as
> the various package classes are now in sync.
> 
> Additional, there was a missing deltask in the nopackages.bbclass related
> to the package_tar which has been corrected.  This could cause problems on
> native recipes when package_tar was enabled.
> 
> Signed-off-by: Mark Hatle 
> ---
>  meta/classes/nopackages.bbclass  |  1 +
>  meta/classes/package_tar.bbclass | 11 ++-
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/classes/nopackages.bbclass b/meta/classes/nopackages.bbclass
> index 559f5078bd..7a4f632d71 100644
> --- a/meta/classes/nopackages.bbclass
> +++ b/meta/classes/nopackages.bbclass
> @@ -2,6 +2,7 @@ deltask do_package
>  deltask do_package_write_rpm
>  deltask do_package_write_ipk
>  deltask do_package_write_deb
> +deltask do_package_write_tar
>  deltask do_package_qa
>  deltask do_packagedata
>  deltask do_package_setscene

This part makes sense.

> diff --git a/meta/classes/package_tar.bbclass 
> b/meta/classes/package_tar.bbclass
> index ce3ab4c8e2..8946bc212a 100644
> --- a/meta/classes/package_tar.bbclass
> +++ b/meta/classes/package_tar.bbclass
> @@ -57,10 +57,8 @@ python do_package_tar () {
>  
>  python () {
>  if d.getVar('PACKAGES') != '':
> -deps = (d.getVarFlag('do_package_write_tar', 'depends') or 
> "").split()
> -deps.append('tar-native:do_populate_sysroot')
> -deps.append('virtual/fakeroot-native:do_populate_sysroot')
> -d.setVarFlag('do_package_write_tar', 'depends', " ".join(deps))
> +deps = ' tar-native:do_populate_sysroot 
> virtual/fakeroot-native:do_populate_sysroot'
> +d.appendVarFlag('do_package_write_tar', 'depends', deps)

This is effectively no change but standardises so ok...

>  d.setVarFlag('do_package_write_tar', 'fakeroot', "1")
>  }
>  
> @@ -70,4 +68,7 @@ python do_package_write_tar () {
>  bb.build.exec_func("do_package_tar", d)
>  }
>  do_package_write_tar[dirs] = "${D}"
> -addtask package_write_tar before do_build after do_packagedata do_package
> +do_package_write_tar[depends] += 
> "${@oe.utils.build_depends_string(d.getVar('PACKAGE_WRITE_DEPS'), 
> 'do_populate_sysroot')}"

Does package_tar need those dependencies? it doesn't handle postinsts
so it basically doesn't.

> +addtask package_write_tar after do_packagedata do_package
> +
> +do_build[recrdeptask] += "do_package_write_tar"

This is also incorrect since tar's have no dependencies on other things
and I suspect this difference is deliberate.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141807): 
https://lists.openembedded.org/g/openembedded-core/message/141807
Mute This Topic: https://lists.openembedded.org/mt/76396875/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] do_populate_lic problems

[Rasmus Villemoes]

There are a couple of problems with do_populate_lic, especially around
the kernel and u-boot recipes.

First, we have a race condition in kernel recipes:

addtask populate_lic after do_patch before do_build
addtask symlink_kernsrc before do_configure after do_unpack

so there's no ordering between those two tasks. I have in fact seen
do_populate_lic fail because (part of) it runs just between the two lines

shutil.move(s, kernsrc)
os.symlink(kernsrc, s)

WARNING: Could not copy license file /mnt/...
...
ERROR: QA Issue: ...: LIC_FILES_CHKSUM points to an invalid file:

and it's fairly easy to reproduce with a monkey-patch:

@@ -148,7 +148,9 @@ python do_symlink_kernsrc () {
 os.symlink(s, kernsrc)
 else:
 import shutil
+import time
 shutil.move(s, kernsrc)
+time.sleep(15)
 os.symlink(kernsrc, s)
 }

I think this could be fixed by making symlink_kernsrc run before
do_patch rather than do_configure - in fact, AFAICT, there's the exact
same lack of ordering with do_patch, it's just that nobody usually has
any .patch files for the kernel when it's maintained in git.

Second, as I've reported previously [1], creating hard-links to files in
kernel or u-boot source repositories, as do_populate_lic does, leads to
scripts/setlocalversion falsely appending a "-dirty" string. It doesn't
happen if one is building a kernel containing ff64dd485730 or a backport
of it (e.g. v5.0+, v4.19.82+) _and_ one has git >= 2.14. U-Boot hasn't
copied ff64dd485730 yet, so it can always happen for U-Boot. Since
there's no ordering between do_populate_lic and do_compile, it's not
even deterministic whether that -dirty string is appended. So while
appropriate tools and patched upstream projects will make the problem go
away, I'm wondering the hardlink optimization is really worth the
trouble it causes.

[1] https://lists.openembedded.org/g/openembedded-core/message/137702

Rasmus
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141806): 
https://lists.openembedded.org/g/openembedded-core/message/141806
Mute This Topic: https://lists.openembedded.org/mt/76403349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-