Date   

Re: Package names in IMAGE_MANIFEST and PACKAGES

Richard Purdie
 

On Fri, 2021-02-26 at 14:18 +0000, Mikko Murto wrote:
Hello,

I'm developing a meta layer to save details about an image created by Yocto to an 
SPDX document ( https://github.com/doubleopen-project/meta-doubleopen).

I've encountered two issues regarding package names in IMAGE_MANIFEST 
and PACKAGES variables,  

https://github.com/doubleopen-project/meta-doubleopen/issues/2 and
https://github.com/doubleopen-project/meta-doubleopen/issues/3.

The crux of the matter is that I need to find packages created by recipes 
and to link the packages listed in image's manifest files to these packages.

First, the PACKAGES variable of all recipes doesn't seem to include all 
packages created. For example util-linux's PACKAGES doesn't include 
util-linux-sulogin, but util-linux-sulogin may be included in an image's 
manifest and it has a directory in the packages-split directory of util-linux. 
What would be the correct way to get information about all packages?

Second, the package names in the image manifest may differ from those in 
the PACKAGES variable or in packages-split directory. As an example, a
manifest file may include libkmod2, but recipe for kmod creates package 
named libkmod. How to make the link from libkmod2 to libkmod?
I'd suggesting looking at packagedata which is how do_package and friends 
internally looks up things like which recipe provides which package and 
what the final package name is.

An example of this in action is scripts/oe-pkgdata-util.

There is also meta/lib/oe/packagedata.py. Sadly the API is horrible, it
was never really designed for "public" use but I would love to see a better
API around that (maybe one oe-pkgdata-util could use too).

Cheers,

Richard


Re: [licensing] [yocto] Package names in IMAGE_MANIFEST and PACKAGES

Mikko Rapeli
 

Hi,

On Fri, Feb 26, 2021 at 10:08:47AM -0500, Jérôme Carretero wrote:
On Fri, 26 Feb 2021 14:18:59 +0000
"Mikko Murto" <mikko.murto@hhpartners.fi> wrote:

The crux of the matter is that I need to find packages created by recipes and to link the packages listed in image's manifest files to these packages.
The way I've been doing it, which is probably not optimal and specific
to one package format, is to lookup .ipk packages from the image
manifest, then use the .ipk control info "OE" key to find the
originating recipe.
FWIW, the mapping from binary package names recipes and recipe metadata like
LICENSE is available from buildhistory. Also binary package content of images
is available from buildhistory. With some scripting it is possible to list
recipes which produce binaries to images, except for static linking and
header-only recipes but I hope these cought via some other way.

Cheers,

-Mikko


Re: Package names in IMAGE_MANIFEST and PACKAGES

Jérôme Carretero
 

Hi Mikko,


On Fri, 26 Feb 2021 14:18:59 +0000
"Mikko Murto" <mikko.murto@hhpartners.fi> wrote:

The crux of the matter is that I need to find packages created by recipes and to link the packages listed in image's manifest files to these packages.
The way I've been doing it, which is probably not optimal and specific
to one package format, is to lookup .ipk packages from the image
manifest, then use the .ipk control info "OE" key to find the
originating recipe.

Here's a link of this method in use in order to try and identify
license-related obligations from an image:
https://gitlab.com/exmakhina/xm_oe/-/blob/47183b74/licenses.py#L24


Hoping to help,

--
Jérôme


Re: [PATCH] lib/oeqa/selftest/cases/reproducible.py : updated test to faketime in future when buiding the second test build.

Alexander Kanavin
 

Wait, this needs to be explained a bit better. What reproducibility issues does this address that the existing test does not?

Alex


On Fri, 26 Feb 2021 at 15:27, Sangeeta Jain <sangeeta.jain@...> wrote:

This update will ensure that recipes are not including time stamps by creating an image with modified system

 time. It uses libfaketime recipe to fake system time to advance by 34308122 seconds.

Signed-off-by: sangeeta jain <sangeeta.jain@...>
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py b/meta/lib/oeqa/selftest/cases/reproducible.py
index 8849c95..831a304 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -180,6 +180,7 @@ class ReproducibleTests(OESelftestTestCase):
     # will test that and also make the test run faster. If your sstate is not
     # reproducible, disable this in your derived test class
     build_from_sstate = True
+    use_faketime = False

     def setUpLocal(self):
         super().setUpLocal()
@@ -227,7 +228,7 @@ class ReproducibleTests(OESelftestTestCase):
         bb.utils.mkdirhier(os.path.dirname(dest))
         shutil.copyfile(source, dest)

-    def do_test_build(self, name, use_sstate):
+    def do_test_build(self, name, use_sstate, use_faketime):
         capture_vars = ['DEPLOY_DIR_' + c.upper() for c in self.package_classes]

         tmpdir = os.path.join(self.topdir, name, 'tmp') @@ -256,6 +257,18 @@ class ReproducibleTests(OESelftestTestCase):
                 SSTATE_MIRRORS = ""
                 ''')

+        if use_faketime:  ##sangeeta
+            # This config fragment will enable to fake system time
+            # advance by 34308122 sec
+            bitbake("libfaketime")
+            find_binary = "find . -path '*/image/*/libfaketime.so.1"
+            full_path_to_binary = runCmd(find_binary)
+            binary_path = full_path_to_binary.split("./")
+            ld_preload_path = os.path.join(os.environ.get('BUILDDIR'), binary_path[1])
+            seconds_add_to_system_time = "+34308122"
+            cmd = 'LD_PRELOAD=%s FAKETIME=%s' %(ld_preload_path, seconds_add_to_system_time)
+            runCmd(cmd)
+
         self.logger.info("Building %s (sstate%s allowed)..." % (name, '' if use_sstate else ' NOT'))
         self.write_config(config)
         d = get_bb_vars(capture_vars)
@@ -282,9 +295,9 @@ class ReproducibleTests(OESelftestTestCase):
             os.chmod(save_dir, stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP | stat.S_IROTH | stat.S_IXOTH)
             self.logger.info('Non-reproducible packages will be copied to %s', save_dir)

-        vars_A = self.do_test_build('reproducibleA', self.build_from_sstate)
+        vars_A = self.do_test_build('reproducibleA',
+ self.build_from_sstate, self.use_faketime))

-        vars_B = self.do_test_build('reproducibleB', False)
+        vars_B = self.do_test_build('reproducibleB', False, True)

         # NOTE: The temp directories from the reproducible build are purposely
         # kept after the build so it can be diffed for debugging.
--
2.7.4





[PATCH] lib/oeqa/selftest/cases/reproducible.py : updated test to faketime in future when buiding the second test build.

Sangeeta Jain
 

This update will ensure that recipes are not including time stamps by creating an image with modified system

time. It uses libfaketime recipe to fake system time to advance by 34308122 seconds.

Signed-off-by: sangeeta jain <sangeeta.jain@intel.com>
---
meta/lib/oeqa/selftest/cases/reproducible.py | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py b/meta/lib/oeqa/selftest/cases/reproducible.py
index 8849c95..831a304 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -180,6 +180,7 @@ class ReproducibleTests(OESelftestTestCase):
# will test that and also make the test run faster. If your sstate is not
# reproducible, disable this in your derived test class
build_from_sstate = True
+ use_faketime = False

def setUpLocal(self):
super().setUpLocal()
@@ -227,7 +228,7 @@ class ReproducibleTests(OESelftestTestCase):
bb.utils.mkdirhier(os.path.dirname(dest))
shutil.copyfile(source, dest)

- def do_test_build(self, name, use_sstate):
+ def do_test_build(self, name, use_sstate, use_faketime):
capture_vars = ['DEPLOY_DIR_' + c.upper() for c in self.package_classes]

tmpdir = os.path.join(self.topdir, name, 'tmp') @@ -256,6 +257,18 @@ class ReproducibleTests(OESelftestTestCase):
SSTATE_MIRRORS = ""
''')

+ if use_faketime: ##sangeeta
+ # This config fragment will enable to fake system time
+ # advance by 34308122 sec
+ bitbake("libfaketime")
+ find_binary = "find . -path '*/image/*/libfaketime.so.1"
+ full_path_to_binary = runCmd(find_binary)
+ binary_path = full_path_to_binary.split("./")
+ ld_preload_path = os.path.join(os.environ.get('BUILDDIR'), binary_path[1])
+ seconds_add_to_system_time = "+34308122"
+ cmd = 'LD_PRELOAD=%s FAKETIME=%s' %(ld_preload_path, seconds_add_to_system_time)
+ runCmd(cmd)
+
self.logger.info("Building %s (sstate%s allowed)..." % (name, '' if use_sstate else ' NOT'))
self.write_config(config)
d = get_bb_vars(capture_vars)
@@ -282,9 +295,9 @@ class ReproducibleTests(OESelftestTestCase):
os.chmod(save_dir, stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP | stat.S_IROTH | stat.S_IXOTH)
self.logger.info('Non-reproducible packages will be copied to %s', save_dir)

- vars_A = self.do_test_build('reproducibleA', self.build_from_sstate)
+ vars_A = self.do_test_build('reproducibleA',
+ self.build_from_sstate, self.use_faketime))

- vars_B = self.do_test_build('reproducibleB', False)
+ vars_B = self.do_test_build('reproducibleB', False, True)

# NOTE: The temp directories from the reproducible build are purposely
# kept after the build so it can be diffed for debugging.
--
2.7.4


Package names in IMAGE_MANIFEST and PACKAGES

Mikko Murto
 

Hello,

I'm developing a meta layer to save details about an image created by Yocto to an SPDX document (https://github.com/doubleopen-project/meta-doubleopen).

I've encountered two issues regarding package names in IMAGE_MANIFEST and PACKAGES variables, https://github.com/doubleopen-project/meta-doubleopen/issues/2 and https://github.com/doubleopen-project/meta-doubleopen/issues/3.

The crux of the matter is that I need to find packages created by recipes and to link the packages listed in image's manifest files to these packages.

First, the PACKAGES variable of all recipes doesn't seem to include all packages created. For example util-linux's PACKAGES doesn't include util-linux-sulogin, but util-linux-sulogin may be included in an image's manifest and it has a directory in the packages-split directory of util-linux. What would be the correct way to get information about all packages?

Second, the package names in the image manifest may differ from those in the PACKAGES variable or in packages-split directory. As an example, a manifest file may include libkmod2, but recipe for kmod creates package named libkmod. How to make the link from libkmod2 to libkmod?

Best regards,

Mikko Murto
Associate

HH Partners, Attorneys-at-law Ltd
Eteläesplanadi 22 a, 00130 Helsinki, Finland
P.O. Box 232, 00101 Helsinki, Finland
Tel: +358 9 177 613, Fax: +358 9 653 873
mikko.murto@hhpartners.fi
www.hhpartners.fi

HH Partners shines in international rankings. See details at hhpartners.fi.

Privileged and confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for the delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, kindly notify us by reply e-mail and delete this message immediately. Thank you.


[meta-selinux][PATCH] openssh: don't overwrite sshd_config unconditionally

Purushottam choudhary
 

The current implementation was overwriting the sshd_config and sshd
assuming PAM is needed by default.

openssh should use the default sshd_config packaged with the component
if no distro specific needs are present and not overwrite the full
sshd_config file.

1. If PAM is enabled as a distro then enable the UsePAM option in sshd_config.
2. Moved the file sshd to pam directory so that when pam is enabled,
then replace the default from poky by installing the same.

Signed-off-by: Purushottam Choudhary <purushottam.choudhary@kpit.com>
---
recipes-connectivity/openssh/files/{ => pam}/sshd | 0
recipes-connectivity/openssh/files/sshd_config | 118 ----------------------
recipes-connectivity/openssh/openssh_%.bbappend | 14 +++
3 files changed, 14 insertions(+), 118 deletions(-)
rename recipes-connectivity/openssh/files/{ => pam}/sshd (100%)
delete mode 100644 recipes-connectivity/openssh/files/sshd_config

diff --git a/recipes-connectivity/openssh/files/sshd b/recipes-connectivity/openssh/files/pam/sshd
similarity index 100%
rename from recipes-connectivity/openssh/files/sshd
rename to recipes-connectivity/openssh/files/pam/sshd
diff --git a/recipes-connectivity/openssh/files/sshd_config b/recipes-connectivity/openssh/files/sshd_config
deleted file mode 100644
index 1c33ad0..0000000
--- a/recipes-connectivity/openssh/files/sshd_config
+++ /dev/null
@@ -1,118 +0,0 @@
-# $OpenBSD: sshd_config,v 1.102 2018/02/16 02:32:40 djm Exp $
-
-# This is the sshd server system-wide configuration file. See
-# sshd_config(5) for more information.
-
-# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
-
-# The strategy used for options in the default sshd_config shipped with
-# OpenSSH is to specify options with their default value where
-# possible, but leave them commented. Uncommented options override the
-# default value.
-
-#Port 22
-#AddressFamily any
-#ListenAddress 0.0.0.0
-#ListenAddress ::
-
-#HostKey /etc/ssh/ssh_host_rsa_key
-#HostKey /etc/ssh/ssh_host_ecdsa_key
-#HostKey /etc/ssh/ssh_host_ed25519_key
-
-# Ciphers and keying
-#RekeyLimit default none
-
-# Logging
-#SyslogFacility AUTH
-#LogLevel INFO
-
-# Authentication:
-
-#LoginGraceTime 2m
-#PermitRootLogin prohibit-password
-#StrictModes yes
-#MaxAuthTries 6
-#MaxSessions 10
-
-#PubkeyAuthentication yes
-
-# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
-# but this is overridden so installations will only check .ssh/authorized_keys
-#AuthorizedKeysFile .ssh/authorized_keys
-
-#AuthorizedPrincipalsFile none
-
-#AuthorizedKeysCommand none
-#AuthorizedKeysCommandUser nobody
-
-# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
-#HostbasedAuthentication no
-# Change to yes if you don't trust ~/.ssh/known_hosts for
-# HostbasedAuthentication
-#IgnoreUserKnownHosts no
-# Don't read the user's ~/.rhosts and ~/.shosts files
-#IgnoreRhosts yes
-
-# To disable tunneled clear text passwords, change to no here!
-#PasswordAuthentication yes
-#PermitEmptyPasswords no
-
-# Change to yes to enable challenge-response passwords (beware issues with
-# some PAM modules and threads)
-ChallengeResponseAuthentication no
-
-# Kerberos options
-#KerberosAuthentication no
-#KerberosOrLocalPasswd yes
-#KerberosTicketCleanup yes
-#KerberosGetAFSToken no
-
-# GSSAPI options
-#GSSAPIAuthentication no
-#GSSAPICleanupCredentials yes
-
-# Set this to 'yes' to enable PAM authentication, account processing,
-# and session processing. If this is enabled, PAM authentication will
-# be allowed through the ChallengeResponseAuthentication and
-# PasswordAuthentication. Depending on your PAM configuration,
-# PAM authentication via ChallengeResponseAuthentication may bypass
-# the setting of "PermitRootLogin without-password".
-# If you just want the PAM account and session checks to run without
-# PAM authentication, then enable this but set PasswordAuthentication
-# and ChallengeResponseAuthentication to 'no'.
-UsePAM yes
-
-#AllowAgentForwarding yes
-#AllowTcpForwarding yes
-#GatewayPorts no
-#X11Forwarding no
-#X11DisplayOffset 10
-#X11UseLocalhost yes
-#PermitTTY yes
-#PrintMotd yes
-#PrintLastLog yes
-#TCPKeepAlive yes
-#UseLogin no
-#PermitUserEnvironment no
-Compression no
-ClientAliveInterval 15
-ClientAliveCountMax 4
-#UseDNS no
-#PidFile /var/run/sshd.pid
-#MaxStartups 10:30:100
-#PermitTunnel no
-#ChrootDirectory none
-#VersionAddendum none
-
-# no default banner path
-#Banner none
-
-# override default of no subsystems
-Subsystem sftp /usr/libexec/sftp-server
-
-# Example of overriding settings on a per-user basis
-#Match User anoncvs
-# X11Forwarding no
-# AllowTcpForwarding no
-# PermitTTY no
-# ForceCommand cvs server
diff --git a/recipes-connectivity/openssh/openssh_%.bbappend b/recipes-connectivity/openssh/openssh_%.bbappend
index 7719d3b..b541c3e 100644
--- a/recipes-connectivity/openssh/openssh_%.bbappend
+++ b/recipes-connectivity/openssh/openssh_%.bbappend
@@ -1 +1,15 @@
require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', '${BPN}_selinux.inc', '', d)}
+
+# if pam feature is enabled in the distro then take sshd from the pam directory.
+FILESEXTRAPATHS_prepend := "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${THISDIR}/files/pam:', ' ', d)}"
+
+do_install_append(){
+
+ if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+ # Make sure UsePAM entry is in the sshd_config file.
+ # If entry not present then append it.
+ grep -q 'UsePAM' "${D}/etc/ssh/sshd_config" && \
+ sed -i 's/.*UsePAM.*/UsePAM yes/' "${D}/etc/ssh/sshd_config" || \
+ echo 'UsePAM yes' >> "${D}/etc/ssh/sshd_config"
+ fi
+}
--
2.7.4

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.


Re: [External] Re: [yocto] Yocto- Apache2 build guide

D, Sharmila <sharmila.d@...>
 

Hi MacLeod,

Thanks for your e-mail.
Yes, without apach2 I am able to build the core-image-minimal successfully. The issue is only when I add apache2 in IMAGE_INSTALL.
I am using TI processor SDK and I have setup the arago based yocto environment based on TI user guide.
version is THUD.
Do you need any further details about the setup?
Please provide me the steps to include apache2 package into my final image.

Looking forward to hearing from you at your earliest convenience.

With Best Regards,
Sharmila D

-----Original Message-----
From: Randy MacLeod <randy.macleod@windriver.com>
Sent: Thursday, February 25, 2021 12:08 AM
To: D, Sharmila <Sharmila.D@Honeywell.com>; yocto@lists.yoctoproject.org
Subject: [External] Re: [yocto] Yocto- Apache2 build guide

On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,

I am trying to enable httpd package into my yocto build, steps I
followed is as below

1. Added below layer in bblayer.conf file

sources/meta-openembedded/meta-webserver

2. Added below line in local.conf file

IMAGE_INSTALL_append = "apache2"

The yocto build using bitbake core-image-minimal gives below error

WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst
returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
['busybox'] have failed. If the intention is to defer them to first
boot, then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl
138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs
.2937
ERROR: Task
(/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-co
re/images/core-image-minimal.bb:do_rootfs)
failed with exit code '1'

Please provide the solution for the same
Hi Sharmila,

This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?

Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases

../Randy


With Best Regards,

Sharmila D





--
# Randy MacLeod
# Wind River Linux


Re: [opkg-devel] [opkg-utils PATCH] CONTRIBUTING: fix yocto ML link

Alex Stewart
 

Thanks for catching that and putting in a fix! ACK from me.

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


Re: [opkg-devel] [opkg-utils PATCH] opkg-build: make sure destination dir exists

Alex Stewart
 

Looks good to me. I'll pull tomorrow if there are no objections.

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


[meta-rockchip][PATCH] rock-pi-e: add

Trevor Woerner
 

Add support for Radxa's ROCK Pi E device
https://wiki.radxa.com/RockpiE

It's a great surprise to find upstream U-Boot and the Linux kernel already
provide support for this board! On the kernel side this support was
added in 5.11. However, that support is so new that even linux-yocto-dev
(which is based on 5.11) doesn't include the commits that add support
for this board yet. As a result I've added a custom Linux kernel recipe
(linux-stable-bleeding) which should, in time, become unnecessary.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/rock-pi-e.conf | 42 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 2 +-
recipes-bsp/u-boot/u-boot%.bbappend | 2 +
.../linux/linux-stable-bleeding_5.11.bb | 18 ++++++++
recipes-kernel/linux/linux-yocto-dev.bbappend | 2 +-
wic/rk3328-boot.wks | 23 ++++++++++
wic/rock-pi-e.wks | 4 ++
7 files changed, 91 insertions(+), 2 deletions(-)
create mode 100644 conf/machine/rock-pi-e.conf
create mode 100644 recipes-kernel/linux/linux-stable-bleeding_5.11.bb
create mode 100644 wic/rk3328-boot.wks
create mode 100644 wic/rock-pi-e.wks

diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
new file mode 100644
index 0000000..035a950
--- /dev/null
+++ b/conf/machine/rock-pi-e.conf
@@ -0,0 +1,42 @@
+#@TYPE: Machine
+#@NAME: ROCK Pi E rk3328
+#@DESCRIPTION: ROCK Pi E is a Rockchip RK3328-based SBC by Radxa. E is for Ethernets.
+#https://wiki.radxa.com/RockpiE
+
+MACHINEOVERRIDES =. "rock-pi-e:"
+SOC_FAMILY = "rk3328"
+DEFAULTTUNE = "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-stable-bleeding"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb"
+KBUILD_DEFCONFIG = "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
+UBOOT_SUFFIX = "itb"
+UBOOT_ENTRYPOINT = "0x06000000"
+PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
+SPL_BINARY = "idbloader.img"
+
+WKS_FILE = "rock-pi-e.wks"
+IMAGE_FSTYPES += "wic.xz wic.bmap"
+WKS_FILE_DEPENDS = " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= " \
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES = "1500000;ttyS2"
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 2374205..442dee8 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -3,4 +3,4 @@
DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"

COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
-
+COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 042507d..95c019d 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -9,6 +9,8 @@ ATF_DEPENDS ??= ""

EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
ATF_DEPENDS_rk3399 = " virtual/trusted-firmware-a:do_deploy"
+EXTRA_OEMAKE_append_rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
+ATF_DEPENDS_rk3328 = " virtual/trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

diff --git a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
new file mode 100644
index 0000000..dce537d
--- /dev/null
+++ b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
@@ -0,0 +1,18 @@
+# the rock-pi-e is very new
+# it's exciting that support has already been added upstream
+# but it's so new that even linux-yocto-dev doesn't have it yet
+#
+# in time we should see the need for this recipe going away
+
+inherit kernel
+require recipes-kernel/linux/linux-yocto.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
+
+SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git"
+SRCREV = "c03c21ba6f4e95e406a1a7b4c34ef334b977c194"
+LINUX_VERSION = "5.11"
+LINUX_VERSION_EXTENSION = ""
+PV = "${LINUX_VERSION}"
+
+COMPATIBLE_MACHINE = "(rock-pi-e)"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index 2f498d9..a85b85e 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1 +1 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288|rock-pi-e"
diff --git a/wic/rk3328-boot.wks b/wic/rk3328-boot.wks
new file mode 100644
index 0000000..194145b
--- /dev/null
+++ b/wic/rk3328-boot.wks
@@ -0,0 +1,23 @@
+# Copyright (C) 2021 Trevor Woerner
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 - (suggested)
+#
+
+part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --offset 4032 --fixed-size 64K --ondisk ${RK_BOOT_DEVICE}
+part reserved2 --offset 4096 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
+part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
+part atf --offset 12288 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
+part /boot --offset 16384 --size 114688K --active --ondisk ${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
diff --git a/wic/rock-pi-e.wks b/wic/rock-pi-e.wks
new file mode 100644
index 0000000..97f84d1
--- /dev/null
+++ b/wic/rock-pi-e.wks
@@ -0,0 +1,4 @@
+include rk3328-boot.wks
+part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,1500000n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
--
2.30.0.rc0


Re: [External] Re: [yocto] Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 10:37 p.m., D, Sharmila wrote:
Hi MacLeod,
Thanks for your e-mail.
Yes, without apach2 I am able to build the core-image-minimal successfully. The issue is only when I add apache2 in IMAGE_INSTALL.
I am using TI processor SDK and I have setup the arago based yocto environment based on TI user guide.
version is THUD.
Do you need any further details about the setup?
Please provide me the steps to include apache2 package into my final image.
Looking forward to hearing from you at your earliest convenience.
Hello Sharmila,

If you can reproduce the problem with only the oe-core/poly + meta-openembedded layers then perhaps someone on this list can help you.
Otherwise, you should contact the people who provided the
TI processor SDK.

By the way, Thud is EOL in the YP community:
https://wiki.yoctoproject.org/wiki/Releases
but commercial vendors do have longer support cycles
so hopefully TI can help you out.

../Randy
With Best Regards,
Sharmila D
-----Original Message-----
From: Randy MacLeod <randy.macleod@windriver.com>
Sent: Thursday, February 25, 2021 12:08 AM
To: D, Sharmila <Sharmila.D@Honeywell.com>; yocto@lists.yoctoproject.org
Subject: [External] Re: [yocto] Yocto- Apache2 build guide
On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,

I am trying to enable httpd package into my yocto build, steps I
followed is as below

1. Added below layer in bblayer.conf file

sources/meta-openembedded/meta-webserver

2. Added below line in local.conf file

IMAGE_INSTALL_append = "apache2"

The yocto build using bitbake core-image-minimal gives below error

WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst
returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
['busybox'] have failed. If the intention is to defer them to first
boot, then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl
138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs
.2937
ERROR: Task
(/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-co
re/images/core-image-minimal.bb:do_rootfs)
failed with exit code '1'

Please provide the solution for the same
Hi Sharmila,
This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?
Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases
../Randy


With Best Regards,

Sharmila D



--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Yocto Technical Team Minutes/Engineering Sync for Feb 23, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for Feb 23, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Scott Murray, Armin Kuster, Michael
Halstead, Steve Sakoman, Richard Purdie, Randy MacLeod, Saul Wold, Jon
Mason, Joshua Watt, Paul Barker, Tim Orling, Mark Morton, John Kaldas,
Alejandro H, Ross Burton

== notes ==
- 3.2.2 passed QA clean, awaiting final approval from TSC
- 3.1.6 built and in QA
- 1 week before -m3 should be built (feature freeze for 3.3)
- adding RPM to reproducibility, still needs some work
- recipe maintainers: please review the patches we’re carrying (push
upstream as many as possible)
- glibc 2.33 issue should be resolved with latest pseudo
- AUH patches are now merged or queued, few of the failures handled
- AB issue list is at record high (not good)

== general ==
RP: can’t get stable test results out of AB on master


RP: would be nice to get RPM reproducibility issues ironed out, but there are
some epoch issues to work through which messes up diffoscope
RP: was surprised to see how bad the interactive response is on the cmdline on
the builders. it seems like an I/O bottleneck
Randy: mostly I/O to SSDs?
RP: i believe so
RP: it was immediately after a build had been started. so it could be related
to downloads or sstate fetching. how much sstate did you expect that build
to be reusing?
SteveS: version bumps to conman, kernel… yea that could lead to a lot of
rebuilds
Michael: we’ve been optimizing for throughput for a while. on some other
build systems we leave some overhead available for cmdline interactivity.
should we start to do that with the YP AB?
RP: i think it would have to be backed off by a significant amount to get that
breathing space. so maybe yes, but we’d have to look at it to see what
to backoff and by how much. looking through the build i see that 77% was
pulled from sstate (therefore pulling data off the NAS, then extracting
it).
Randy: and that’s not coordinated at all, if there are 100 items, then 100
threads?
RP: but limited by BB_THREADS
JPEW: run by buildbot? maybe we could use cgroups?
RP: i don’t think it’s CPU bound, the CPU was 50% idle when the cmdline
was very slow
MichaelH: sometimes we see that when the system isn’t healthy, i wonder if
it’s isolated to specific machines?
RP: on the CentOS machine, a command took over 5 minutes to complete. then
tried debian, same thing. then logged into the fedora machine and was
able to do stuff. but it didn’t seem isolated to any machines, it
seemed localized in time (i.e. right after a build had been started),
then dropped off. so i feel that it might be related to the initial build
startup, probably related to sstate pulling/extraction
Randy: could also limit I/O using cgroups
RP: we do use IOnice for parts of the build (2.1 and 2.7)
Michael: translation: class 2 priority 1; class 2 priority 7
Alejandro: are these sharing any hardware
RP: they’re all connected to the NAS
Michael: and they’re 100% dedicated to this work
RP: i don’t think this is a network bottleneck, i think this is sstate extraction
JPEW: maybe a different compression algorithm? gzip is notoriously slow
RP: wouldn’t that make it worse?
JPEW: does each AB have their own mirror
RP: it’s all done over NFS
JPEW: network bandwidth should be lower than local unzipping/extraction bandwidth?
Alejandro: could we try different I/O scheduling?
RP: don’t know

RP: had a look at patches. 1,300 patches in oe-core, ~600 in pending the rest
are submitted or not appropriate. some of these are 10 years or older,
do we still need them? i sent 2 upstream and was told it wasn’t needed
anymore (problem fixed in other ways). there’s also one in valgrind that
looks similar (different fix upstream) and not needed.
Ross: if some people could try to do 1 a day that would be a huge help
RP: lots of patches related to reproducibility
JPEW: the big issue with perf is that it uses bison (which needs patches)

PaulB: read-only mode for PR server. i’ve been working on it, but it’s 1
big patch. there’s code to handle daemonizing and forking which in hash
server is using the python mutli-processing. we also want to use the
same RPC mechanisms that python is using. are those good lines along which
to break the patches down?
RP: that sounds perfect
PaulB: it was easier to bash on it all together, then go back and break it up
into digestible chunks
RP: it’s 10 year old code, so i’m not surprised
PaulB: i’ve broken out a part that uses JSON RPC, then use that for the
server
RP: sounds good to me
JPEW: me too
RP: scaling that code under python2 was a challenge. glad to see this moving
forward

RP: Randy posted rust patch set. felt it couldn’t be merged in this form
(too many patches)
Randy: do you want the history squashed?
RP: that was my feeling
Randy: i’ve been working on it bit by bit as stuff happens upstream which
leads to lots of little commits. but i can reorg by logical group and
squash the log
RP: yes. in one case there were lots of commits to the rust version, then in
the end you end up with 2
Randy: someone from MS worked on getting the sdk stuff working
RP: given that next Monday is the feature freeze, let’s get the patched out
sooner, and worry about the sdk later
Randy: ok. last remaining issue is the pre-fetcher but i don’t know much
about it. looked at PaulB’s patches
PaulB: there are 3 methods floating around, i’ve focused on one of them that
i like
1. doing the download ahead of time in do_fetch()
2. let rust-bin do the downloads itself in do_compile() which i don’t like
3. haven’t looked at the last one yet
PaulB: i like 1 because it asks rust to output a cargo which the fetcher can
then act on
Randy: doesn’t rely on crates?
PaulB: i think it relies on crates for things that it can’t resolve. however
Andreas’ approach relies on getting bitbake to understand cargo-toml
file, not sure if that’s a good approach
Randy: are there any lessons with Go that we can use?
Scott: Bruce would be a good one to talk to
PaulB: my understanding with Go is that the code tends to all be placed
together in the git repository, so the fetch side is a little simpler
Randy: so given the approach we’re using is there anything that needs to be
added
PaulB: it needs testing
Randy: i have a team working on testing the rust compiler itself. they can
successfully execute 2/3 of the tests now (of which 99.9% pass). i have
a reproducibility test for rust hello world, but it takes a long time to
run. any tests you’re thinking of?
PaulB: fetcher tests. if you have a “crate://” in a URL, just making sure
it gets translated correctly to make sure it doesn’t bitrot
Randy: is that an -m3 or -m4 activity
RP: if we’ll get it in -m4 for sure we can wait until then. in oe-core
we’d want some sort of hello world (make sure compiler works and we can
run the binaries)
Randy: we have that already
RP: both for cross-compiling and target. then reproducibility tests. i’m
happy to build them up, as long as there’s a roadmap. for -m3 i think we
should get the baseline rust set and the crate fetcher
PaulB: crate fetcher overrides the wget fetcher and makes sure everything gets
put in the right place. so it just needs a couple test cases; a map of
inputs to outputs. i’ll resubmit the patch and include a list of tests
that we need to add
RP: if someone could reply to Andreas and let him know what’s going on and
why we’re going in a slightly different direction than the work he’s
submitted
PaulB: the fundamental unit is the recipe. devtool is the place for some of
the functionality not bitbake
Randy: building rust hello world works for all glibc qemu targets but some
breakage with musl (risc-v and powerpc) i think Khem is working on the
risc-v one. will that hold things up?
RP: no
PaulB: i have some slightly larger rust packages (larger than hello world)
that i think will test things a little more thoroughly, e.g. ripgrep
Randy: we’re testing that one already. should we add it to oe-core?
RP: it would be good to have something in oe-core to do testing
Randy: i think hello world would be good enough for oe-core and leave larger
tests for other layers
PaulB: there are rust things in oe-core (librsvg, etc) so i think oe-core will
have good test things already in them without having to add recipes just
for testing’s sake
Randy: things also seem to work well on ARM builders
Ross: yes, things are on-target

TrevorW: started work on 2021 YP conference. conversation moved to
conferences@lists.yoctoproject.org if you want to follow along or help

RP: fetch, workdir, can’t clean up workdir, config changes but can’t
cleanup. maybe we should fetch to a special dir and then just symlink
PaulB: would it be recipe-specific
RP: yes, it would be under $WORKDIR
PaulB: would make the archiver easier
TimO: there are a number of Go modules that don’t cleanup properly so maybe
this would help
ScottM: there are lots recipes that do post-processing on files in $WORKDIR
before moving them to the artifacts directory, so there could be breakage
there
PaulB: can we do it first thing next release
RP: we’ll give it a try and see
TrevorW: i think a lot of BSP layers will be affected
RP: i think there’s a lot of chance a lot of things (not just BSPs) will be
affected
ScottM: there are some BSP things that will be affected, but in AGL we’re
doing a lot of $WORKDIR manipulations that aren’t necessarily BSP
related as well
(several): overall it sounds like a good idea and a good cleanup to try


Re: BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

Thanks, will try it out...

-----Original Message-----
From: Quentin Schulz <quentin.schulz@streamunlimited.com>
Sent: Thursday, February 25, 2021 8:42 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] BB_HASHBASE_WHITELIST

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in recipes/conf files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


Re: BB_HASHBASE_WHITELIST

Quentin Schulz
 

On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since
local.conf is parsed pretty early, += will override current values set
with ?= or ??=. It might also be overridden if = is used in recipes/conf
files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

 

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST “ ?

 

I tried to do : BB_HASHBASE_WHITELIST += “BB_TRACE” in my local.conf but it ended up replacing existing list with just “BB_TRACE”…

 

 

basewhitelist changed from '{'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'LICENSE_PATH', 'BB_WORKERCONTEXT', 'BB_HASHSERVE', 'BB_UNIHASH', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'SDKPKGSUFFIX', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'PRSERV_HOST', 'CCACHE_DIR', 'PRSERV_LOCKDOWN', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'PATH', 'SSTATE_DIR', 'PKGDATA_DIR'}' to '{'BB_TRACE'}'

changed items: {'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'BB_WORKERCONTEXT', 'LICENSE_PATH', 'BB_UNIHASH', 'BB_HASHSERVE', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'PATH', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'SSTATE_DIR', 'PRSERV_HOST', 'CCACHE_DIR', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'BB_TRACE', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'SDKPKGSUFFIX', 'PRSERV_LOCKDOWN', 'PKGDATA_DIR'}

 

Thanks,

Steve


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.6.rc1)

Sangeeta Jain
 

Hi all,

This is the full report for yocto-3.1.6.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

no new issue found

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Tuesday, 23 February, 2021 6:48 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.6.rc1)


A build flagged for QA (yocto-3.1.6.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.6.rc1


Build hash information:

bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd
meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63
poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org







Re: Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,
I am trying to enable httpd package into my yocto build, steps I followed is as below
1. Added below layer in bblayer.conf file
sources/meta-openembedded/meta-webserver
2. Added below line in local.conf file
IMAGE_INSTALL_append = "apache2"
The yocto build using bitbake core-image-minimal gives below error
WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.2937
ERROR: Task (/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'
Please provide the solution for the same
Hi Sharmila,

This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?

Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or
on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases

../Randy

With Best Regards,
Sharmila D

--
# Randy MacLeod
# Wind River Linux


Re: [meta-security] [PATCH V2 0/8] Some fixes for IMA/EVM

Armin Kuster
 

merged

On 2/20/21 4:18 AM, liu.ming50@gmail.com wrote:
From: Ming Liu <liu.ming50@gmail.com>

Changes in patch set V2:

1 Split patches as suggested by Dmitry Baryshkov.

Ming Liu (8):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
ima-evm-keys: add recipe
initramfs-framework-ima: RDEPENDS on ima-evm-keys
meta: refactor IMA/EVM sign rootfs
README.md: update according to the refactoring in
ima-evm-rootfs.bbclass
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb


Multi-planar API support in g_webcam

Sheraz Ali
 

Hi All,

I wanted to know whether g_webcam supports multi-planar API.

--
Thanks and Regards
Sheraz Ali Shah

1021 - 1040 of 53484