[OE-core] [PATCH] Checksums for local files now stored using partial recipe path

This allows sstate-cache to be shared between builds in different directories. Differences in the full path were triggering a false positive when there were actually no changes. Signed-off-by: Jate Sujjavanich jate.sujjavan...@myfuelmaster.com --- bitbake/lib/bb/fetch2/__init__.py | 14

Re: [OE-core] [PATCH] Checksums for local files now stored using partial recipe path

will have to see about the other local file cases that I don't know about. :) -Jate From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Wednesday, June 19, 2013 11:45 AM To: Jate Sujjavanich Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE

Re: [OE-core] [PATCH] Checksums for local files now stored using partial recipe path

As far as I can tell though that won't actually fix the issue triggering rebuilds in your case. Something else must be changing. It would be interesting if you could dig into what that might be as I can't reproduce the rebuilding issue here. I discovered that different versions of Dylan from

[OE-core] [PATCH] Change resolv.conf generation for sysvinit

Move /etc/resolv.conf link generation a volatiles file. Then use update-alternatives to choose the correct one. This is for sysvinit and resolvconf. --- .../resolvconf/files/volatiles_resolv-conf |1 + .../resolvconf/resolvconf_1.75.bb | 15 ++-

[OE-core] [PATCH] resolvconf/initscripts: Change resolv.conf generation for sysvinit

The resolv.conf link generated by initscripts causes a warning with resolvconf. The resolvconf script expects a different target. Use the ALTERNATIVES system to create the link via populate-volatiles.sh. Signed-off-by: Jate Sujjavanich jate...@gmail.com --- .../resolvconf/files/volatiles_resolv

[OE-core] [PATCH] python2: Add PACKAGECONFIG for tkinter to support tk from meta-oe

Previously, the python recipe did not have a way to add a DEPENDS on tk. This makes the option available for users of the meta-oe/meta-oe layer. Signed-off-by: Jate Sujjavanich jate...@gmail.com --- meta/recipes-devtools/python/python_2.7.3.bb |2 ++ 1 file changed, 2 insertions(+) diff

[OE-core] [PATCH] useradd: Add setscene dep on pseudo-native

A recipe will sometimes be rebuilt unnecessarily if it adds users via useradd and the pseudo-native task has not been populated. This patch adds the correct dependency. Signed-off-by: Jate Sujjavanich jate...@gmail.com --- meta/classes/useradd.bbclass |2 +- 1 file changed, 1 insertion

Re: [OE-core] [PATCH] resolvconf/initscripts: Change resolv.conf generation for sysvinit

Patch ping follow up On Thu, Jun 26, 2014 at 10:03 AM, Jate Sujjavanich jate...@gmail.com wrote: The resolv.conf link generated by initscripts causes a warning with resolvconf. The resolvconf script expects a different target. Use the ALTERNATIVES system to create the link via populate

Re: [OE-core] [PATCH] useradd: Add setscene dep on pseudo-native

Ping On Sun, Aug 10, 2014 at 5:00 PM, Jate Sujjavanich jate...@gmail.com wrote: A recipe will sometimes be rebuilt unnecessarily if it adds users via useradd and the pseudo-native task has not been populated. This patch adds the correct dependency. Signed-off-by: Jate Sujjavanich jate

Re: [OE-core] [PATCH] useradd: Add setscene dep on pseudo-native

There's a commit in poky's master-next with the message bitbake: runqueue: Fix setscene tasks not running. Should it fix the problem fixed by my patch? Thanks, - Jate S. On Sun, Aug 10, 2014 at 5:00 PM, Jate Sujjavanich jate...@gmail.com wrote: A recipe will sometimes be rebuilt

Re: [OE-core] [PATCH] resolvconf/initscripts: Change resolv.conf generation for sysvinit

Anybody using resolvconf? Ping On Sun, Aug 10, 2014 at 8:46 PM, Jate Sujjavanich jate...@gmail.com wrote: Patch ping follow up On Thu, Jun 26, 2014 at 10:03 AM, Jate Sujjavanich jate...@gmail.com wrote: The resolv.conf link generated by initscripts causes a warning with resolvconf

[OE-core] [2/2] image.bbclass/rootfs.py: PREFERRED_PROVIDER for rdepends

in bug #6149, bitbake looks for PREFERRED_PROVIDER_openssh and PREFERRED_provider_dropbear. This change allows PREFERRED_PROVIDER_sshd=dropbear. Signed-off-by: Jate Sujjavanich jate...@gmail.com The following changes since commit efe5b0940a6abc7348d8c60c456d93f5de8dda89: providers.py: Add

[OE-core] [1/2] providers.py: Add package name to PREFERRED_PROVIDER search

Add rootfs_process_preferred_providers to image.bbclass. In PACKAGE_INSTALL, this substitutes the requested package with the provider. Change regex in RpmRootfs._log_check_error to allow log message about PREFERRED_PROVIDER. Signed-off-by: Jate Sujjavanich jate...@gmail.com The following

[OE-core] [0/2] Yocto Bug #6149, #5044

I came across these bugs in poky 1.6.3 (daisy) with multiple package providers. I fixed bug 6149 with just bitbake patch. I came across another bug with this when I tried the bitbake fix on master. With the test case IMAGE_INSTALL_append = sshd PREFERRED_PROVIDER_sshd=dropbear

[OE-core] [PATCH v2][2/2] image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package

to 832a47ff79a06a797ddd39db86c792a43cdf0865: image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package (2015-05-13 12:24:02 -0400) Jate Sujjavanich (1): image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package meta

[OE-core] [PATCH v2][1/2] providers.py: Add PREFERRED_RPROVIDER

to 55bd8d189f647443b28f988ccfc9eebffaec84d1: providers.py: Add PREFERRED_RPROVIDER (2015-05-13 11:29:52 -0400) Jate Sujjavanich (1): providers.py: Add PREFERRED_RPROVIDER bitbake/lib/bb/providers.py |7 --- 1 file

[OE-core] [PATCH v2][0/2] Yocto Bug #6149

Richard, This version uses PREFERRED_RPROVIDER instead of PREFERRED_PROVIDER to reduce confusion. These patches add PREFERRED_RPROVIDER which specifies a preferred runtime provider for a package when multiple RPROVIDER's are available. It selects the preferred recipe to build and installs the

Re: [OE-core] [PATCH v2][2/2] image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package

On Thu, May 14, 2015 at 5:46 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2015-05-13 at 18:47 -0400, Jate Sujjavanich wrote: +python rootfs_process_preferred_rproviders() { +inst_pkgs = d.getVar(PACKAGE_INSTALL, True).split() +pref_pkgs = list() +for pkg

[OE-core] [PATCH v3][0/2] Yocto Bug #6149

These patches add code to handle a PREFERRED_PROVIDER for a runtime item. The providers.py code chooses a recipe based on a runtime package to resolve the multiple providers warning. Then during package generation, the new image.bbclass code substitutes the package into PACKAGE_INSTALL that

[OE-core] [PATCH v3][2/2] image.bbclass: Add support for runtime PREFERRED_PROVIDER

changes up to 6ade6807288ad318355bb77e43df87dfc15a9e90: image.bbclass: Add support for runtime PREFERRED_PROVIDER (2015-07-23 17:29:04 -0400) Jate Sujjavanich (1): image.bbclass: Add support for runtime PREFERRED_PROVIDER meta

[OE-core] [PATCH] rm_work.bbclass: Exclude do_rootfs stamp removal

This prevents unneeded rootfs rebuilds if the metadata has not changed while using rm_work. Signed-off-by: Jate Sujjavanich <jate...@gmail.com> --- meta/classes/rm_work.bbclass |4 1 file changed, 4 insertions(+) diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.b

[OE-core] Official sstate premirrors and builds

I setup a machine on AWS and wanted to use the sstate cache mirror at sstate.yoctoproject.org in my site.conf. Bitbake does not pull the artifacts from the mirror despite the uninative C library. I have tried checking out several tags and then pointed to the appropriate directory on sstate

[OE-core] [PATCH v2] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zip/zip-3.0/zipnote-crashes-with-segfault.patch | 20 meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 21 insertions(+) create mode 100644 meta

[OE-core] [PATCH v3] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zip/zip-3.0/zipnote-crashes-with-segfault.patch | 20 meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 21 insertions(+) create mode 100644 meta

[OE-core] [PATCH] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zip/zip-3.0/zipnote-crashes-with-segfault.patch | 20 meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 21 insertions(+) create mode 100644 meta

[OE-core] [PATCH v5] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zipnote-crashes-with-segfault.patch | 22 +++ meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 23 insertions(+) create mode 100644 meta/recipes

[OE-core] [PATCH v4] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zipnote-crashes-with-segfault.patch | 20 +++ meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 21 insertions(+) create mode 100644 meta/recipes

[OE-core] [PATCH v6] zip: Add patch fixing zipnote segfault

This patch has been applied in several Linux distributions Signed-off-by: Jate Sujjavanich --- .../zipnote-crashes-with-segfault.patch | 22 +++ meta/recipes-extended/zip/zip_3.0.bb | 1 + 2 files changed, 23 insertions(+) create mode 100644 meta/recipes

Re: [OE-core] [PATCH 4/6] reproducible_build: clamp the rootfs tarball mtime to the epoch

I have started using the following code to set the mtimes of files written after the build timestamp. It assumes that SOURCE_DATE_EPOCH of packages are never in the future. # Set to empty to allow custom function below to run REPRODUCIBLE_TIMESTAMP_ROOTFS ?= "" # Use DATETIME of build as

[OE-core] [PATCH] sysvinit: Add bootlogd patch restoring console detection

The bootlogd program will skip any non-standard serial ports specified in the kernel parameters, so restore the detection of the device underlying /dev/console. This allows the serial console on some embedded systems to work again. Signed-off-by: Jate Sujjavanich --- ...ogd-c--Restore-dev

[OE-core] eudev and the variable not_first_boot

Reviewing the eudev recipe, I found a conditional for the udevadm trigger/settle code. The variable "not_first_boot" determines whether to exclude several subsystems during the trigger. Looking at the recipe history, it appears that this is leftover from the dev cache code. I cannot find

[OE-core] [PATCH v4] iputils: Fix cap_net_raw for installed binaries

negative case This will prevent possible non-determinism for the setuid case. Signed-off-by: Jate Sujjavanich --- meta/recipes-extended/iputils/iputils_s20200821.bb | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-extended/iputils/iputils_s20200821.bb b/meta

Re: [OE-core] [PATCH v3 2/2] iputils: Fix setcap/setuid of executables

ichard.pur...@linuxfoundation.org> wrote: > On Mon, 2021-02-22 at 17:39 +, Jose Quaresma wrote: > > Hi, > > > > Jate Sujjavanich escreveu no dia segunda, > 22/02/2021 à(s) 15:58: > > > If libcap is disabled in PACKAGECONFIG, then arguments two and three > me

Re: [OE-core] [PATCH v3 2/2] iputils: Fix setcap/setuid of executables

uses a simple chown and chmod. I *think* these are >> universal in posix and that we don't have to worry about host contamination. >> setuid) >> _log "changing '$exec_path' to be setuid root executable" >> chown -v root "$exec_path&

[OE-core] [PATCH] iputils: Use STAGING_DIR_NATIVE for setcap detection

Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add DEPENDS for libcap-native to supply this if we select libcap for PACKAGECONFIG. The previous setting of NO_SETCAP_OR_SUID broke setuid or setcap of /bin/ping Signed-off-by: Jate Sujjavanich --- meta/recipes-extended

Re: [OE-core] [PATCH v2 2/2] iputils: Use STAGING_DIR_NATIVE for setcap detection

I think we need the revert patch, the libcap-native DEPENDS, and then some logic to exclude the hard-coded paths to setcap if we are cross-compiling. This seems more mesonic and may be submittable upstream. Your hypothesis that they hard code the setcap paths for non-root users makes sense,

[OE-core] [PATCH v3 1/2] Revert "iputils: Fix build determinism"

This reverts commit d10da5f6e6d6d3600645dbe43ed412ff23b55095. --- meta/recipes-extended/iputils/iputils_s20200821.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta/recipes-extended/iputils/iputils_s20200821.bb b/meta/recipes-extended/iputils/iputils_s20200821.bb index

[OE-core] [PATCH v3 2/2] iputils: Fix setcap/setuid of executables

Limit setcap search to PATH for cross builds preventing host contamination. Add DEPENDS for libcap-native to supply this for PACKAGECONFIG libcap. The previous setting of NO_SETCAP_OR_SUID broke setuid or setcap of /bin/ping and other executables. Signed-off-by: Jate Sujjavanich --- ...tcap

Re: [OE-core] [PATCH] iputils: Use STAGING_DIR_NATIVE for setcap detection

pur...@linuxfoundation.org> wrote: > On Thu, 2021-02-18 at 00:11 +0000, Jate Sujjavanich wrote: > > Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add > > DEPENDS for libcap-native to supply this if we select libcap for > > PACKAGECONFIG. > > Why does it nee

[OE-core] [PATCH v2 2/2] iputils: Use STAGING_DIR_NATIVE for setcap detection

Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add DEPENDS for libcap-native to supply this if we select libcap for PACKAGECONFIG. The previous setting of NO_SETCAP_OR_SUID broke setuid or setcap of /bin/ping and other executables. Signed-off-by: Jate Sujjavanich

[OE-core] [PATCH v2 1/2] Revert "iputils: Fix build determinism"

This reverts commit d10da5f6e6d6d3600645dbe43ed412ff23b55095. --- meta/recipes-extended/iputils/iputils_s20200821.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta/recipes-extended/iputils/iputils_s20200821.bb b/meta/recipes-extended/iputils/iputils_s20200821.bb index

Re: [OE-core] [PATCH v3 2/2] iputils: Fix setcap/setuid of executables

g> wrote: > On Fri, 2021-02-19 at 17:53 +, Jate Sujjavanich wrote: > > Limit setcap search to PATH for cross builds preventing host > > contamination. Add DEPENDS for libcap-native to supply this for > > PACKAGECONFIG libcap. > > > > The previous setting of NO_

Re: [OE-core] [PATCH v3 2/2] iputils: Fix setcap/setuid of executables

for. > This is meant to be used for cases where the program may have many > alternative names, such as foo and foo.py. > The function will check for the arguments one by one and the first one > that is found is returned. > > Jose > > Jate Sujjavanich escreveu no dia sexta, 19/02/2

Re: [OE-core] SYSROOTS_EXCLUDEDEPS_SYSROOT changing more hashes than I expect

Sorry about the crucial mistyping. I tested this out with a local.conf setting. After building again, adding the meta-java layer resulted in a much cleaner build on dunfell. Thanks - Jate S. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

[OE-core] SYSROOTS_EXCLUDEDEPS_SYSROOT changing more hashes than I expect

I added meta-java to my bblayers.conf file, and the next build invalidated much of my sstate cache. This included such recipes as perl, which I thought would be unrelated to that layer. Through some digging, it appears that the addition to SYSROOTS_EXCLUDEDEPS_SYSROOT in meta-java affects that

Re: [OE-core] SYSROOTS_EXCLUDEDEPS_SYSROOT changing more hashes than I expect

The ones in meta/conf/layer.conf are much more global. This one in meta-java/conf/layer.conf certainly does not apply to perl and other irrelevant recipes. SSTATE_EXCLUDEDEPS_SYSROOT += "\

[OE-core] [PATCH 1/2] libdnf: Backport bugfix for upgrade calc

Mark goal.upgrade with sltr as targeted This allows a bugfix in dnf to work Signed-off-by: Jate Sujjavanich --- ...job-goal.upgrade-with-sltr-as-target.patch | 58 +++ .../libdnf/libdnf_0.28.1.bbappend | 3 + 2 files changed, 61 insertions(+) create mode 100644

[OE-core] [PATCH 2/2] dnf: Backport bugfix for upgrade

Keep installed packages in upgrade job This prevents duplicate identical packages from being reinstalled with each upgrade Signed-off-by: Jate Sujjavanich --- ...ackages-in-upgrade-job-RhBug-1728252.patch | 60 +++ meta/recipes-devtools/dnf/dnf_4.2.2.bbappend | 3 + 2 files

Re: [OE-core] [PATCH 1/2] libdnf: Backport bugfix for upgrade calc

Meant to add a [dunfell] to the subject. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158652): https://lists.openembedded.org/g/openembedded-core/message/158652 Mute This Topic: https://lists.openembedded.org/mt/87274565/21656 Group Owner:

Re: [OE-core] [PATCH 2/2] dnf: Backport bugfix for upgrade

Meant to add a [dunfell] to the subject. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158653): https://lists.openembedded.org/g/openembedded-core/message/158653 Mute This Topic: https://lists.openembedded.org/mt/87274566/21656 Group Owner:

Re: [OE-core] [dunfell 36/42] dnf: Backport bugfix for upgrade

Sorry about that. I will send you a v2 update. - Jate -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158940): https://lists.openembedded.org/g/openembedded-core/message/158940 Mute This Topic: https://lists.openembedded.org/mt/87365202/21656

[OE-core] [dunfell][PATCH v2 1/2] libdnf: Backport bugfix for upgrade calc

Mark goal.upgrade with sltr as targeted This allows a bugfix in dnf to work Signed-off-by: Jate Sujjavanich --- ...job-goal.upgrade-with-sltr-as-target.patch | 58 +++ meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 1 + 2 files changed, 59 insertions(+) create mode 100644

[OE-core] [dunfell][PATCH v2 2/2] dnf: Backport bugfix for upgrade

Keep installed packages in upgrade job This prevents duplicate identical packages from being reinstalled with each upgrade Signed-off-by: Jate Sujjavanich --- ...ackages-in-upgrade-job-RhBug-1728252.patch | 60 +++ meta/recipes-devtools/dnf/dnf_4.2.2.bb| 1 + 2 files

Re: [OE-core] Question of Yocto dunfell LTS period

I received the answer to this question in IRC on 10/29/2021. 16:06 < jatedev> I saw a wiki edit that said dunfell's LTS period is now through April 2024, but I've seen no announcements. Any truth to this rumor? 16:20

Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install

I have performed a major distribution upgrade in the past. This was with rpm which requires bash. I did not have issues with utilities required by the upgrade disappearing. I believe rpm installs the new file, and then removes old files. Does opkg remove the old binary before installing the new

[OE-core] [dunfell][PATCH] IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation

From: Jate Sujjavanich [YOCTO #14851] Under some circumstances it is not desirable to create a combined locale archive (/usr/lib/locale/locale-archive). The new variable IMAGE_LOCALES_ARCHIVE defaults to '1', so the default behaviour is not changed. Modified to work with code before move

[OE-core] Hash Equivalency Server

I would like to use the read-only hashserv with a dunfell build. To test, I created one based on kirkstone and built the dunfell image using that hashserv creating a new sstate-cache. Then, I created a read-only hashserv which used the database of that first hashserv instance. I started a new

[OE-core][dunfell][PATCH 1/1] sstatesig: Allow exclusion of the root directory for do_package

don't need it there or care about it in this case. Signed-off-by: Jate Sujjavanich (cherry picked from commit 9cceeb906527f90d8dd3aad75aa3a8805e2a1df5) Signed-off-by: Richard Purdie --- meta/lib/oe/sstatesig.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe

[OE-core][dunfell][PATCH 0/1] Backport do_package sstatesig fix

I found out that this backport is applicable to dunfell. This increased sstate reuse. Richard Purdie (1): sstatesig: Allow exclusion of the root directory for do_package meta/lib/oe/sstatesig.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=-