Re: [OE-core] Yocto : Need help in building latest openembedded branch code

2021-11-16 Thread Mark Hatle
The variable syntax has changed between older and newer versions of bitbake. See: https://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-syntax-changes On 11/15/21 11:59 PM, mohammed aqdam wrote: Hi There, I am working on a yocto image for the imx8 board, for this I have

Re: [OE-core] [PATCH] openssh: openssh-dev shouldn't depend on openssh

2021-09-29 Thread Mark Hatle
On 9/29/21 3:36 AM, Matt Johnston wrote: > On Wed, 2021-09-29 at 09:24 +0100, Richard Purdie wrote: >>> +RDEPENDS:${PN}-dev = "" >> >> At that point what is the point of the -dev package? I think you could make >> this argument about a lot of the -dev packages and I'm not sure I'd want to >> see

Re: [OE-core] user/group XXX does not exist, using root with RPM/DNF packaging in Hardknott and Honister

2021-09-24 Thread Mark Hatle
On 9/24/21 9:02 AM, Zoltan Boszormenyi via lists.openembedded.org wrote: > Hi, > > I have a special package that creates users and groups > via inherit useradd. This package doesn't depend on any > others but it is depended on, both via DEPENDS and RDEPENDS > by packages using those

[OE-core] [PATCH] tcf-agent: Move to the latest master version

2021-09-16 Thread Mark Hatle
There has not been a release since 2018, the 1.7.0 release. A number of recent improvements around thumb and clang debugging prompted this move to a newer version. The patch is no longer necessary as it was a backport patch. Signed-off-by: Mark Hatle --- .../0001-Fixed-copyright

[OE-core][PATCH v3 2/2] externalsrc: Work with reproducible_build

2021-09-09 Thread Mark Hatle
From: Mark Hatle Externalsrc removes do_fetch, do_unpack, and do_patch. The system normally discovers the correct reproducible date as a postfuncs of do_unpack, so this date is never found, so it falls back to the default epoch. Instead we can move the discovery function to a prefuncs

[OE-core][PATCH v3 0/2] Fixes for reproducible build and externalsrc

2021-09-09 Thread Mark Hatle
but it was not desired to explain how to 'disable' the behavior for a single recipe. For the externalsrc, the code was moved from the reproducible_build into the externalsrc and made contingent on the do_unpack being removed. Mark Hatle (2): reproducible_build: Remove

[OE-core][PATCH v3 1/2] reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking

2021-09-09 Thread Mark Hatle
From: Mark Hatle Previously if BUILD_REPRODUCIBLE_BINARIES was set to 0, the system would fall back and select the default epoch (April 2011), but still perform the reproducible build actions. This resulted in binaries that had an unusually old date. Simplify the functions and remove

[OE-core][PATCH v2 0/2] Fixes for reproducible build and externalsrc

2021-09-09 Thread Mark Hatle
. For the externalsrc, the code was moved from the reproducible_build into the externalsrc and made contingent on the do_unpack being removed. Mark Hatle (2): reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking externalsrc: Work with reproducible_build meta/classes/externalsrc.bbclass

[OE-core][PATCH v2 1/2] reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking

2021-09-09 Thread Mark Hatle
From: Mark Hatle Previously if BUILD_REPRODUCIBLE_BINARIES was set to 0, the system would fall back and select the default epoch (April 2011), but still perform the reproducible build actions. This resulted in binaries that had an unusually old date. Simplify the functions and remove

[OE-core][PATCH v2 2/2] externalsrc: Work with reproducible_build

2021-09-09 Thread Mark Hatle
From: Mark Hatle Externalsrc removes do_fetch, do_unpack, and do_patch. The system normally discovers the correct reproducible date as a postfuncs of do_unpack, so this date is never found, so it falls back to the default epoch. Instead we can move the discovery function to a prefuncs

[OE-core][PATCH 1/2] reproducible_build: Honor BUILD_REPRODUCIBLE_BINARIES

2021-09-08 Thread Mark Hatle
From: Mark Hatle A variable BUILD_REPRODUCIBLE_BINARIES is set to '1' by default and was used to control if the postfuncs were added. However, it didn't actually disable the reproducible_build (date) logic. This resulted in the program falling back to the default date. This change fully

[OE-core][PATCH 0/2] Fixes for reproducible build and externalsrc

2021-09-08 Thread Mark Hatle
expected results. Mark Hatle (2): reproducible_build: Honor BUILD_REPRODUCIBLE_BINARIES reproducible_build: Work with externalsrc meta/classes/reproducible_build.bbclass | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You

[OE-core][PATCH 2/2] reproducible_build: Work with externalsrc

2021-09-08 Thread Mark Hatle
From: Mark Hatle Externalsrc removes do_fetch, do_unpack, and do_patch. The system normally discovers the correct reproducible date as a postfuncs on do_unpack, so this date is never found, so it goes back to the default epoch. Instead we can move the discovery function to a prefuncs

Re: [OE-core] should recipes not come with their own systemd/user/group info?

2021-08-05 Thread Mark Hatle
On 8/5/21 6:01 AM, Robert P. J. Day wrote: > > style question here, but i'm perusing an OE/YP (actually wind river, > but effectively the same thing) layer that was handed to me, and i'm > puzzled by how the internally-written systemd-controlled services are > implemented. > > on the one

Re: [OE-core] [PATCH 6/9] shadow: update 4.8.1 -> 4.9

2021-08-04 Thread Mark Hatle
On 8/4/21 1:13 PM, Khem Raj wrote: > > > On 8/4/21 3:12 AM, Alexander Kanavin wrote: >> Yes, plaintext passwords can no longer be there, which is a good thing >> I'd say? The hashed/salted passwords can still be provided through the >> same class, but this needs to be documented, and perhaps

Re: [OE-core] Image creation using RPM/DNF and adding a third party repository configuration

2021-07-15 Thread Mark Hatle
On 7/15/21 4:24 PM, Mark Hatle wrote: > We have the desire to add a 3rd party repository to our standard images > generated by OE image generation. We do this by adding a recipe > (my-external-repo.bb) that creates a package that adds a repository > configuration file to

[OE-core] [PATCH] populate_sdk_ext: Error if trying to generate an eSDK from a mulitconfig

2021-06-29 Thread Mark Hatle
as the eSDK is constructed based on the primary library, it works fine. Signed-off-by: Mark Hatle --- meta/classes/populate_sdk_ext.bbclass | 5 + 1 file changed, 5 insertions(+) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 517b4e45ff0

Re: [OE-core] should the same recipe have two different WORKDIRs?

2021-06-16 Thread Mark Hatle
Part of the WORKDIR component is the target (package) architecture. If the recipe or one of it's inherits sets PACKAGE_ARCH = "${MACHINE_ARCH}" it will move the component. Where I've seen both directories used is when someone is building for multiple target boards.. and some of the targets use

Re: [OE-core] [PATCH] mklibs-native: Fix build with gcc 11

2021-05-17 Thread Mark Hatle
On 5/17/21 2:46 PM, Andre McCurdy wrote: > On Mon, May 17, 2021 at 10:05 AM Jacob Kroon wrote: >> >> In gcc 11 the default mode for C++ is now -std=gnu++17 instead of >> -std=gnu++14, >> in which support for dynamic exception specifications has been removed. > > As much as I'd like to see

[OE-core] Multiconfig - sstate-cache re-use and error

2021-05-05 Thread Mark Hatle
I'm cross posting this cause I suspect it's a bitbake bug, but it requires sstate-cache / setscene stuff which is from the oe-core side of things. I really don't know what is causing the problem, but I can at least reproduce it, even if it ends up taking a while. The configuration. I'm building

Re: [OE-core] master eSDK hash problem with METADATA_REVISION and base-files:do_install

2021-03-29 Thread Mark Hatle
481d79264db920dee1f7deda18230133fff8f36 in > SIGGEN_LOCKEDSIGS_t-qemux86-64 >     >     So we record METADATA_REVISION in eSDK generation time to fix this > problem. >     >     Signed-off-by: Chen Qi >     Signed-off-by: Richard Purdie > """ > > Best

Re: [OE-core] [PATCH] populate_sdk_ext: Avoid copying and producing .pyc files

2021-03-26 Thread Mark Hatle
toms.. we are indeed fixing the underlying issues in the implementation. It just happened to be that I was able to reproduce the build failure reliably for a time vs it just going away on it's own. --Mark > Alex > > On Thu, 25 Mar 2021 at 23:44, Mark Hatle <mailto:mark.ha...@kernel

[OE-core] [PATCH 0/1] Enable PR Service support in eSDK

2021-03-25 Thread Mark Hatle
This is the first attempt at enabling the PR service in the eSDK. It appears to work for me, but I expect I'm missing corner cases. Any feedback is appreciatd. Mark Hatle (1): populate_sdk_ext: Add support for PR service meta/classes/populate_sdk_ext.bbclass | 25

[OE-core] [PATCH 1/1] populate_sdk_ext: Add support for PR service

2021-03-25 Thread Mark Hatle
From: Mark Hatle In the classes/populate_sdk_ext.bbclass the system already copies a number of configurations, such as the hash equivalency data. However, the PR service was being handled. The new code works by checking if PRSERV_HOST is defined, if it is, use the existing export functions

[OE-core] master eSDK hash problem with METADATA_REVISION and base-files:do_install

2021-03-25 Thread Mark Hatle
Building an eSDK (all stock config): MACHINE=qemuarm bitbake core-image-minimal -c populate_sdk_ext I then install it, and get: Checking sstate mirror object availability: 100%

[OE-core] [PATCH] populate_sdk_ext: Avoid copying and producing .pyc files

2021-03-25 Thread Mark Hatle
Since pyc cache files are really system specific, no real reason to copy or generate them during the eSDK build process. Also generating them has the possibility of re-using inodes that pseudo may have been tracking, leading a build failure. Signed-off-by: Mark Hatle --- meta/classes

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

2021-03-25 Thread Mark Hatle
On 3/25/21 9:08 AM, Robert P. J. Day wrote: > > kind of a philosophical question, but i'm having a discussion with > some new colleagues about how to customize an OE (actually, wind river > linux) build, and these colleagues have, until now, used (whitelisted) > environment variables to pass

Re: [OE-core] PR Service and eSDK

2021-03-23 Thread Mark Hatle
On 3/23/21 5:45 PM, Richard Purdie wrote: > On Tue, 2021-03-23 at 17:34 -0500, Mark Hatle wrote: >> For some reason I thought if PR service was enabled, when the eSDK was >> generated >> it would export the pr service information and include it within the eSDK. >>

[OE-core] PR Service and eSDK

2021-03-23 Thread Mark Hatle
For some reason I thought if PR service was enabled, when the eSDK was generated it would export the pr service information and include it within the eSDK. I'm not finding the file, or even code that does this. Am I having a fever dream, or is there code that should be doing this? What I'm

Re: [OE-core] [PATCH 1/1] extrausers: Add ability to force password change on first login

2021-03-09 Thread Mark Hatle
Best Regards, > Chen Qi > > On 03/09/2021 02:08 AM, Mark Hatle wrote: >> As documented in shadow(5), the third parameter is the last login time. A >> special value of '0' is defined which causes the password system to force >> a password change on next login. >> >&g

Re: [OE-core] [PATCH 1/1] extrausers: Add ability to force password change on first login

2021-03-08 Thread Mark Hatle
On 3/8/21 12:50 PM, Khem Raj wrote: > > > On 3/8/21 10:08 AM, Mark Hatle wrote: >> From: Mark Hatle >> >> As documented in shadow(5), the third parameter is the last login time. A >> special value of '0' is defined which causes the password system to force &

[OE-core] [PATCH 0/1] Enable the ability to force a password change on boot

2021-03-08 Thread Mark Hatle
nqemu Login as root, and it should prompt for a password change. This was further verified by setting a default root password, as well as adding a new user to the system. In both cases it worked as expected. Finally adding an invalid user to the list, and an appropriate error is genera

[OE-core] [PATCH 1/1] extrausers: Add ability to force password change on first login

2021-03-08 Thread Mark Hatle
From: Mark Hatle As documented in shadow(5), the third parameter is the last login time. A special value of '0' is defined which causes the password system to force a password change on next login. Adding the variable "EXTRA_FORCE_PASSWORD_CHANGE", a space separated list of user nam

[OE-core] Sudo CVE-2021-3156 -- was Re: [yocto-security] OE-core CVE metrics for master on Sun 31 Jan 2021 07:15:01 AM HST

2021-02-05 Thread Mark Hatle
I didn't see Sudo issue CVE-2021-3156 in any of the unpatched lists. >From a quick look, it appears to be that Master is patched (package is new enough), but Gatesgarth and older are not. So with the next set, we should check if it shows up in the unpatched set. --Mark On 1/31/21 11:18 AM,

Re: [OE-core] [yocto-security] [PATCH] openssl: drop support for deprecated algorithms

2020-12-21 Thread Mark Hatle
On 12/19/20 12:04 PM, Konrad Weihmann wrote: > > > On 19.12.20 18:58, Richard Purdie wrote: >> On Sat, 2020-12-19 at 18:53 +0100, Konrad Weihmann wrote: >>> On 19.12.20 18:36, Richard Purdie wrote: PACKAGECONFIG[cryptodev-linux] =

Re: [OE-core] How to create a directory in multiple packages?

2020-12-15 Thread Mark Hatle
On 12/15/20 8:24 AM, Peter Kjellerstedt wrote: >> -Original Message- >> From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Mark Hatle >> Sent: den 15 december 2020 02:02 >> To: openembedded-core@lists.openembedded.org

Re: [OE-core] How to create a directory in multiple packages?

2020-12-14 Thread Mark Hatle
On 12/14/20 11:43 AM, Peter Kjellerstedt wrote: > Say we have a recipe that creates an empty /etc/foo directory. Now we > want to add a new file in that directory /etc/foo/bar and package it as > ${PN}-bar. This means the creation of the /etc/foo directory is moved > from the ${PN} package to

Re: [OE-core] [PATCH] file /etc/ethertypes conflicts between netbase-1:6.2-r0.corei7_64 and ebtables-2.0.10+4-r4.corei7_64

2020-12-14 Thread Mark Hatle
The version in netbase is the correct one. For a comparison, see the followng for the netbase version: https://salsa.debian.org/md/netbase/-/blob/master/etc/ethertypes and see the following for the ebtables version: http://git.netfilter.org/ebtables/tree/ethertypes?h=ebtables-2.0.10-4 So the

Re: [OE-core] [PATCH] file /etc/ethertypes conflicts between netbase-1:6.2-r0.corei7_64 and ebtables-2.0.10+4-r4.corei7_64

2020-12-14 Thread Mark Hatle
I agree. Netbase is the required for all installs. ebtables is only used in some installs. So unless ebtables has a more up-to-date version of the file, it seems like the bug is that ebtables needs to either remove the file or sync to the netbase version. (You won't get a conflict if both

Re: [OE-core] [PATCH 7/7] sstate: set mode explicitly when creating directories in sstate-cache

2020-09-28 Thread Mark Hatle
I worry that this could be problematic for other ways. Security requirements for an org or even users who want to share the sstate case 0777 etc. Wouldn't it be better to warn the user that their umask won't allow them to share this with others, and give them instructions and opening the umask?

Re: [OE-core] [PATCH 2/2] ssh-regen-hostkeys: Add a recipe with pregenerated ssh host keys

2020-09-28 Thread Mark Hatle
I'm worried about this from a product security perspective. I think this is very valid case for an autobuilder/autotest infrastructure, however if this ends up in a release product it will lead to huge problems. Is there a way we can ensure this can only be used for the autobuilder/autotest

Re: [OE-core] [PATCH] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF

2020-09-17 Thread Mark Hatle
... The user is responsible for providing their own BBMULTICONFIG. However, if you want to provide a default one, you can already including the BBMULTICONFIG for the setting in your layer set. --Mark > On Thu, Sep 17, 2020 at 12:42 AM Mark Hatle > wrote: >> >> In my configura

Re: [OE-core] [PATCH] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF

2020-09-16 Thread Mark Hatle
In my configurations, we refernce the multiconfig directories inside of our many layers. I definitely don't want the copied into the conf/* directory structure, since I don't want users modifying the prebuilt ones. --Mark On 9/16/20 12:08 PM, gr embeter wrote: >> Why copy this from TEMPLATECONF

Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg

2020-09-15 Thread Mark Hatle
On 9/15/20 9:38 AM, Martin Jansa wrote: > On Mon, Sep 14, 2020 at 06:54:14PM -0400, Jon Mason wrote: >> On Mon, Sep 14, 2020 at 11:32 AM Martin Jansa wrote: >>> This reduces the number of files from 12 to 2 for ARMv8a, and that is excluding the 13 I am adding in this series that

Re: [OE-core] [meta-oe][RFC 1/6] arm64: set BASE_LIB to lib64

2020-09-10 Thread Mark Hatle
On 9/10/20 10:11 AM, Jon Mason wrote: > On Thu, Sep 10, 2020 at 12:57 AM Mark Hatle > wrote: >> >> >> >> On 9/9/20 6:29 PM, Jon Mason wrote: >>> On Wed, Sep 9, 2020 at 6:55 PM Mark Hatle >>> wrote: >>>> >>>> >>>&g

Re: [OE-core] [meta-oe][RFC 1/6] arm64: set BASE_LIB to lib64

2020-09-09 Thread Mark Hatle
On 9/9/20 6:29 PM, Jon Mason wrote: > On Wed, Sep 9, 2020 at 6:55 PM Mark Hatle > wrote: >> >> >> >> On 9/9/20 5:45 PM, Jon Mason wrote: >>> Set BASE_LIB for all arm64 systems to be lib64 by default. This can be >>> overridden for those

Re: [OE-core] [meta-oe][RFC 2/6] arch-armv8-2a.inc: Add Cortex-A55 tunings

2020-09-09 Thread Mark Hatle
On 9/9/20 6:21 PM, Jon Mason wrote: > On Wed, Sep 9, 2020 at 6:59 PM Mark Hatle > wrote: >> >> I like the direction of this work, but one comment.. (down below) >> >> On 9/9/20 5:45 PM, Jon Mason wrote: >>> Migrate the settings in tune-cortexa55.inc to

Re: [OE-core] [meta-oe][RFC 2/6] arch-armv8-2a.inc: Add Cortex-A55 tunings

2020-09-09 Thread Mark Hatle
I like the direction of this work, but one comment.. (down below) On 9/9/20 5:45 PM, Jon Mason wrote: > Migrate the settings in tune-cortexa55.inc to arch-armv8-2a.inc. This > will allow for a single file to include all of the tunings of a family > of processors. This will reduce the

Re: [OE-core] [meta-oe][RFC 1/6] arm64: set BASE_LIB to lib64

2020-09-09 Thread Mark Hatle
On 9/9/20 5:45 PM, Jon Mason wrote: > Set BASE_LIB for all arm64 systems to be lib64 by default. This can be > overridden for those that want something else (see tune-cortexa32.inc). > > Signed-off-by: Jon Mason > --- > meta/conf/machine/include/arm/arch-arm64.inc | 3 +-- >

Re: [OE-core] [meta-oe][PATCH 3/4] tune-cortexa57-cortexa53.inc: add CRC and set march

2020-09-09 Thread Mark Hatle
On 9/9/20 5:16 PM, Jon Mason wrote: > Add CRC to the default tuning of big.LITTLE Cortex-A57-A53. This puts > it inline with all other ARMv8a tunings. Also, reference > PACKAGE_EXTRA_ARCHS_tune-armv8a-crc instead of > PACKAGE_EXTRA_ARCHS_tune-aarch64, which sets the -march to armv8 and >

[OE-core] [master][PATCH v8 1/1] package.bbclass: hash equivalency and pr service

2020-09-02 Thread Mark Hatle
. Various assert messages were also updated to make it easier to figure out where/why a problem occured. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 58 +++ meta/conf/bitbake.conf| 1 + meta/lib/oeqa/selftest/cases/prservice.py | 8

[OE-core] [master][PATCH v8 0/1]

2020-09-02 Thread Mark Hatle
le testing the various package_*.bbclass files, it was noted that package_tar.bbclass was not working the same way as the others. This was correct as a standalone patch. Mark Hatle (1): package.bbclass: hash equivalency and pr service meta/classes/package.bbclass | 58 +++

Re: [OE-core] [master][PATCH v7 3/3] package.bbclass: hash equivalency and pr service

2020-09-01 Thread Mark Hatle
Just an FYI.. To reproduce the failure you HAVE to use the 'poky' distro. I had switched to 'nodistro' because the system complained about "SANITY_TESTED_DISTROS".. Working on this now... --Mark On 9/1/20 3:44 PM, Mark Hatle wrote: > > > On 8/28/20 1:05 AM, Richard Purd

Re: [OE-core] [master][PATCH v7 3/3] package.bbclass: hash equivalency and pr service

2020-09-01 Thread Mark Hatle
On 8/28/20 1:05 AM, Richard Purdie wrote: > On Thu, 2020-08-27 at 17:12 -0500, Mark Hatle wrote: >> When the PR service is enabled a number of small changes may happen >> to variables. In the do_package step a call to package_get_auto_pr >> will end up setting PRAU

[OE-core] [master][PATCH v7 3/3] package.bbclass: hash equivalency and pr service

2020-08-27 Thread Mark Hatle
copying the data from pkgdata to pkgdata-pdata-input. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 58 +++- meta/conf/bitbake.conf | 1 + 2 files changed, 51 insertions(+), 8 deletions(-) diff --git a/meta/classes/package.bbclass b/meta/classes

[OE-core] [master][PATCH v7 2/3] kernel.bbclass: Move away from calling package_get_auto_pr

2020-08-27 Thread Mark Hatle
issue, but it could cause problems. Moving to read_subpackage_metadata ensures that the values used in do_package will be read in and used for kernel deployment. Signed-off-by: Mark Hatle --- meta/classes/kernel.bbclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta

[OE-core] [master][PATCH v7 0/3] Allow PR Service and hash equiv together

2020-08-27 Thread Mark Hatle
le testing the various package_*.bbclass files, it was noted that package_tar.bbclass was not working the same way as the others. This was correct as a standalone patch. Mark Hatle (3): buildhistory.bbclass: Rework to use read_subpackage_metadata kernel.bbclass: Move away from calling package_ge

[OE-core] [master][PATCH v7 1/3] buildhistory.bbclass: Rework to use read_subpackage_metadata

2020-08-27 Thread Mark Hatle
Using this mechanism ensures that we have a single point to implement the loading of the package and subpackage meta data. This also then allows the buildhistory class to use the regular datastore vs it's own custom arrays for processing history items. Signed-off-by: Mark Hatle --- meta

[OE-core] [master][PATCH v6 0/3] Allow PR Service and hash equiv together

2020-08-27 Thread Mark Hatle
noted that package_tar.bbclass was not working the same way as the others. This was correct as a standalone patch. Mark Hatle (3): buildhistory.bbclass: Rework to use read_subpackage_metadata kernel.bbclass: Move away from calling package_get_auto_pr package.bbclass: hash equival

[OE-core] [master][PATCH v6 2/3] kernel.bbclass: Move away from calling package_get_auto_pr

2020-08-27 Thread Mark Hatle
issue, but it could cause problems. Moving to read_subpackage_metadata ensures that the values used in do_package will be read in and used for kernel deployment. Signed-off-by: Mark Hatle --- meta/classes/kernel.bbclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta

[OE-core] [master][PATCH v6 3/3] package.bbclass: hash equivalency and pr service

2020-08-27 Thread Mark Hatle
copying the data from pkgdata to pkgdata-pdata-input. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 58 +++- meta/conf/bitbake.conf | 1 + 2 files changed, 51 insertions(+), 8 deletions(-) diff --git a/meta/classes/package.bbclass b/meta/classes

[OE-core] [master][PATCH v6 1/3] buildhistory.bbclass: Rework to use read_subpackage_metadata

2020-08-27 Thread Mark Hatle
Using this mechanism ensures that we have a single point to implement the loading of the package and subpackage meta data. This also then allows the buildhistory class to use the regular datastore vs it's own custom arrays for processing history items. Signed-off-by: Mark Hatle --- meta

Re: [OE-core] [master][PATCH v2 0/6] Allow PR Service and hash equiv togther

2020-08-26 Thread Mark Hatle
On 8/26/20 6:48 AM, Richard Purdie wrote: > On Wed, 2020-08-26 at 06:27 -0500, Mark Hatle wrote: >> v2: >> >> Most comments have been addressed to create a v2 version. I've refactored >> the commits to make a few things more clear, basically moving code around >&g

Re: [OE-core] [master][PATCH v2 4/6] package.bbclass: Move package_get_auto_pr to packagedata.bbclass

2020-08-26 Thread Mark Hatle
On 8/26/20 6:44 AM, Richard Purdie wrote: > On Wed, 2020-08-26 at 06:27 -0500, Mark Hatle wrote: >> Running package_get_auto_pr during do_package is 'too early' when we >> need to evaluate the do_package output to get it's unihash to look up >> the right value in the PR

[OE-core] [master][PATCH v2 2/6] kernel.bbclass: Remove do_install[prefunc] no longer needed

2020-08-26 Thread Mark Hatle
Prior work has refactored the do_install task multiple times, and any references to PKGV and PKGR (even indirect ones) have been removed. Signed-off-by: Mark Hatle --- meta/classes/kernel.bbclass | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes

[OE-core] [master][PATCH v2 4/6] package.bbclass: Move package_get_auto_pr to packagedata.bbclass

2020-08-26 Thread Mark Hatle
in which it's called. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 50 --- meta/classes/packagedata.bbclass | 59 2 files changed, 59 insertions(+), 50 deletions(-) diff --git a/meta/classes/package.bbclass b/meta

[OE-core] [master][PATCH v2 0/6] Allow PR Service and hash equiv togther

2020-08-26 Thread Mark Hatle
the various package_*.bbclass files, it was noted that package_tar.bbclass was not working the same way as the others. This was correct as a standalone patch. Mark Hatle (6): package_tar.bbclass: Sync to the other package_* classes kernel.bbclass: Remove do_install[prefunc] no l

[OE-core] [master][PATCH v2 3/6] buildhistory.bbclass: Rework to use read_subpackage_metadata

2020-08-26 Thread Mark Hatle
Using this mechanism ensures that we have a single point to implement the loading of the package and subpackage meta data. This also then allows the buildhistory class to use the regular datastore vs it's own custom arrays for processing history items. Signed-off-by: Mark Hatle --- meta

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

2020-08-26 Thread Mark Hatle
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 | 6 ++ 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/meta/classes/nopackages.bbclass

[OE-core] [master][PATCH v2 5/6] kernel.bbclass: Move away from calling package_get_auto_pr

2020-08-26 Thread Mark Hatle
issue, but it could cause problems. Moving to read_subpackage_metadata ensures that the values used in do_package will be read in and used for kernel deployment. Signed-off-by: Mark Hatle --- meta/classes/kernel.bbclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta

[OE-core] [master][PATCH v2 6/6] package.bbclass: hash equivalency and pr service

2020-08-26 Thread Mark Hatle
, but in the per package files. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 69 +--- meta/classes/packagedata.bbclass | 19 ++--- meta/conf/bitbake.conf | 1 + 3 files changed, 69 insertions(+), 20 deletions(-) diff --git a/meta/classes

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

2020-08-25 Thread 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

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

2020-08-25 Thread 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

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

2020-08-25 Thread 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

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

2020-08-25 Thread 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

Re: [OE-core] ✗ patchtest: failure for Allow PR Service and hash equiv together

2020-08-24 Thread Mark Hatle
On 8/24/20 6:32 PM, Patchwork wrote: > == Series Details == > > Series: Allow PR Service and hash equiv together > Revision: 1 > URL : https://patchwork.openembedded.org/series/25758/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core.

[OE-core] [master][PATCH 5/5] buildhistory.bbclass: Rework to use read_subpackage_metadata

2020-08-24 Thread Mark Hatle
and sometimes PRAUTO do not get expanded properly within the buildhistory which can leave to error messages about package versions/releases going backwards. Signed-off-by: Mark Hatle --- meta/classes/buildhistory.bbclass | 60 +++ 1 file changed, 21 insertions(+), 39

[OE-core] [master][PATCH 0/5] Allow PR Service and hash equiv together

2020-08-24 Thread Mark Hatle
quivalency database or PR server database (located in the cache directory) is removed, the values may not be the same as the previous run. Additionally while testing the various package_*.bbclass files, it was noted that package_tar.bbclass was not working the same way as the others. This

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

2020-08-24 Thread Mark Hatle
o 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. Signed-off-by: Mark Hatle --

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

2020-08-24 Thread Mark Hatle
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

[OE-core] [master][PATCH 3/5] package.bbclass: Move package_get_auto_pr to packagedata.bbclass

2020-08-24 Thread Mark Hatle
in which it's called. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 50 --- meta/classes/packagedata.bbclass | 59 2 files changed, 59 insertions(+), 50 deletions(-) diff --git a/meta/classes/package.bbclass b/meta

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

2020-08-24 Thread Mark Hatle
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 c

[OE-core] hash equivalency and PR service - RFC

2020-08-19 Thread Mark Hatle
I've been working recently to try to get hash equivalency and PR service to work together properly. Earlier today I sent a patch to address one of the issues I found (un-related to PR service). In order to replicate the condition, I've been using poky master (oe should work fine) with the

[OE-core] [PATCH] package.bbclass: Sort shlib2 output for hash equivalency

2020-08-19 Thread Mark Hatle
The output was unsorted, so different versions of python, different input ordering could have have changed the files, and thus changed the hashes making the system think the output was different, even when unmodified. Signed-off-by: Mark Hatle --- meta/classes/package.bbclass | 2 +- 1 file

Re: [OE-core] [bitbake-devel] Backtrace in bitbake with OE archiver

2020-05-27 Thread Mark Hatle
One more note.. Adding the following and then it works fine: INITRAMFS_IMAGE = "core-image-minimal" I suspect it works simply because the task processing order has changed in some way.. On 5/27/20 2:44 PM, Mark Hatle wrote: > Cross posting cause I'm not sure where the bug is, I su

[OE-core] Backtrace in bitbake with OE archiver

2020-05-27 Thread Mark Hatle
Cross posting cause I'm not sure where the bug is, I suspect bitbake -- but it could be in OE's archiver class. I have been able to reproduce this in both Zeus and master. When I start a new project, and add the following to the local.conf: INHERIT += "archiver" ARCHIVER_MODE[src] = "original"

Re: [OE-core] [PATCH v2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-27 Thread Mark Hatle
Ping I noticed this hasn't been integrated or commented on yet. On 5/13/20 11:12 AM, Mark Hatle wrote: > From: Mark Hatle > > Prior to fetching, the system checks if the sstate file is present > either locally or on the mirror. If it is, then it goes to the fetch > stage. Up

[OE-core] [PATCH v2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle
From: Mark Hatle Prior to fetching, the system checks if the sstate file is present either locally or on the mirror. If it is, then it goes to the fetch stage. Up to three files can be fetched, sstate, sstate.siginfo and sstate.sig (if signature validation is enabled). The previous

[OE-core] [zeus][ 1/2] sstatesig: Optimise get_taskhash for hashequiv

2020-05-13 Thread Mark Hatle
: de98cfe3cde4b8d5f4b163b5fba3f129651ef06a) Signed-off-by: Richard Purdie Signed-off-by: Mark Hatle --- meta/lib/oe/sstatesig.py | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py index b2316b12b8..f1abff0c45 100644 --- a/meta/lib/oe

[OE-core] [zeus][ 0/2] Fix for two issues related to sstate-cache

2020-05-13 Thread Mark Hatle
lly strips those) it won't fail. Mark Hatle (1): sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors Richard Purdie (1): sstatesig: Optimise get_taskhash for hashequiv meta/classes/sstate.bbclass | 6 +- meta/lib/oe/sstatesig.py| 13 +++-- 2 files c

[OE-core] [zeus][ 2/2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle
From: Mark Hatle Prior to fetching, the system checks if the sstate file is present either locally or on the mirror. If it is, then it goes to the fetch stage. Up to three files can be fetched, sstate, sstate.siginfo and sstate.sig (if signature validation is enabled). The previous

[OE-core] [PATCH] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle
From: Mark Hatle Prior to fetching, the system checks if the sstate file is present either locally or on the mirror. If it is, then it goes to the fetch stage. Up to three files can be fetched, sstate, sstate.siginfo and sstate.sig (if signature validation is enabled). The previous

Re: [OE-core] [oe][yocto][bitbake] Fetching source using different protocols

2020-05-11 Thread Mark Hatle
On 5/11/20 4:17 AM, Quentin Schulz wrote: > Hi Mohamed, > > On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote: >> Hello, >> >> I need to fetch a git repo using 2 different protocols ( ssh & https ) >> So that when I run bitbake, It will fetch using ssh protocol first and if >> it fails to

Re: [OE-core] [PATCH 2/5] archiver.bbclass: Make do_deploy_archives a recursive dependency

2020-04-01 Thread Mark Hatle
On 4/1/20 9:49 AM, Mark Hatle wrote: > (I know this is an old thread, but I ran into this as well..) > > ... > > On 3/11/20 6:40 AM, Paul Barker wrote: >> On Tue, 10 Mar 2020 23:18:33 + >> Richard Purdie wrote: >> >>> On Mon, 2020-03-09 at 14:2

Re: [OE-core] [PATCH 2/5] archiver.bbclass: Make do_deploy_archives a recursive dependency

2020-04-01 Thread Mark Hatle
(I know this is an old thread, but I ran into this as well..) ... On 3/11/20 6:40 AM, Paul Barker wrote: > On Tue, 10 Mar 2020 23:18:33 + > Richard Purdie wrote: > >> On Mon, 2020-03-09 at 14:21 +, Paul Barker wrote: >>> To ensure that archives are captured for all dependencies of a

Re: [OE-core] [v2 PATCH] base.bbclass: Add COMPATIBLE_OS, useful for non-Linux target recipes

2020-03-26 Thread Mark Hatle
}${ABIEXTENSION}" COMPATIBLE_HOST ?= "${COMPATOS}" Then in each of the baremetal -only- recipes: COMPATIBLE_HOST = ".*-elf" COMPATIBLE_HOST_arm = "[^-]*-[^-]*-eabi" In the recipes for BOTH baremetal and Linux: COMPATIBLE_HOST = "${HOST_SYS}" (Setting to "

Re: [OE-core] [v2 PATCH] base.bbclass: Add COMPATIBLE_OS, useful for non-Linux target recipes

2020-03-26 Thread Mark Hatle
> On Thu, 2020-03-26 at 10:25 -0500, Mark Hatle wrote: >> Add the ability to generate non-Linux based components, such as >> baremetal, FreeRTOS, Zypher, etc, exist. There is a need for a way >> to take components as specific to a given OS. >> >> This is espe

[OE-core] [v2 PATCH] base.bbclass: Add COMPATIBLE_OS, useful for non-Linux target recipes

2020-03-26 Thread Mark Hatle
h specific compatibility. For a baremetal recipes, the following was used to test this code: COMPATIBLE_OS = "elf" COMPATIBLE_OS_arm = "eabi" Signed-off-by: Mark Hatle --- V2: Only difference to V1 is typograhic fixes to the commit message. meta/classes/base.bbc

[OE-core] [PATCH] base.bbclass: Add COMPATIBLE_OS, useful to for non-Linux target recipes

2020-03-26 Thread Mark Hatle
h specific compatibility. For a baremetal recipes, the following was used to test this code: COMPATIBLE_OS = "elf" COMPATIBLE_OS_arm = "eabi" Signed-off-by: Mark Hatle --- meta/classes/base.bbclass| 7 +++ meta/conf/documentation.conf | 1 + 2 files changed, 8 insertions

Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage

2020-03-26 Thread Mark Hatle
> On Wed, Mar 25, 2020 at 02:27:37PM -0500, Mark Hatle wrote: >> > To be honest, I would just take the entire recipe out. It's causing >> > trouble >> > during updates, isn't being tested neither for builds nor at runtime, >> and >> > is supposed

  1   2   3   4   5   6   7   8   9   10   >