Date   

Build wayland/weston from source?

Haase, Juergen [ext]
 

Hi. I'm probably not exactly on topic in the yocto mailing list, but thought maybe someone can point me into the right direction.

What I want to do:
I've made a modification to weston and am planning to do some more, so I would like to integrate this modified version of wayland/weston into my Petalinux 2019.1 config (have to use that version).
At the moment my wayland branch is based on v9.0.0.

What I've tried so far (please do tell me if I'm doing something totally stupid):
Unfortunately I don't have very good understanding about petalinux/yocto, I tried to start with the following steps:

I began with trying to integrate the wayland recipes from openembedded:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/wayland

I copied this folder over into my petalinux recipes folder and ran

    $ petalinux-build -c wayland
    [INFO] building wayland
    [INFO] sourcing bitbake
    [INFO] generating user layers
    INFO: bitbake wayland
    Loading cache: 100% |############################################################| Time: 0:00:00
    Loaded 3826 entries from dependency cache.
    ERROR: ParseError at <my_petalinuxroot>/project-spec/meta-user/recipes-apps/wayland/weston_9.0.0.bb:22: Could not inherit file classes/features_check.bbclass
  
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.
    ERROR: Failed to build wayland

I searched through my Petalinux project and didn't find any other *.bbclass files, so I don't know where this could be put if I copied it over from openembedded.
So I grepped for this and found:

    $ rg features_check
    weston_9.0.0.bb
    22:inherit meson pkgconfig useradd features_check
 
    weston-init.bb
    65:inherit update-rc.d features_check systemd useradd

Since it wasn't obvious to me if the inclusion of this even does anything, I removed it and ran the build again:

    $ petalinux-build -c wayland
    [INFO] building wayland
    [INFO] sourcing bitbake
    [INFO] generating user layers
    INFO: bitbake wayland
    Loading cache: 100% |############################################################| Time: 0:00:00
    Loaded 3826 entries from dependency cache.
    Parsing recipes: 100% |##########################################################| Time: 0:00:02
    Parsing of 2799 .bb files complete (2791 cached, 8 parsed). 3836 targets, 162 skipped, 0 masked, 0 errors.
    NOTE: Resolving any missing task queue dependencies
    Initialising tasks: 100% |#######################################################| Time: 0:00:00
    Checking sstate mirror object availability: 100% |###############################| Time: 0:00:03
    Sstate summary: Wanted 62 Found 18 Missed 88 Current 320 (29% match, 88% complete)
    NOTE: Executing SetScene Tasks
    NOTE: Executing RunQueue Tasks
    ERROR: wayland-native-1.19.0-r0 do_configure: meson failed
    ERROR: wayland-native-1.19.0-r0 do_configure: Function failed: do_configure (log file is located at <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/temp/log.do_configure.8492)
    ERROR: Logfile of failure stored in: <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/temp/log.do_configure.8492
    Log data follows:
    | DEBUG: Executing shell function do_configure
    | NOTE: Executing meson -Ddocumentation=false -Dlibraries=false -Ddtd_validation=true...
    | The Meson build system
    | Version: 0.47.2
    | Source dir: <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/wayland-1.19.0
    | Build dir: <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/build
    | Build type: native build
    |
    | meson.build:1:0: ERROR:  Meson version is 0.47.2 but project requires >= 0.52.1.
    |
    | A full log can be found at <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/build/meson-logs/meson-log.txt
    | ERROR: meson failed
    | WARNING: <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/temp/run.do_configure.8492:1 exit 1 from 'exit 1'
    | ERROR: Function failed: do_configure (log file is located at <my_petalinuxroot>/build/tmp/work/x86_64-linux/wayland-native/1.19.0-r0/temp/log.do_configure.8492)
    ERROR: Task (virtual:native:<my_petalinuxroot>/project-spec/meta-user/recipes-apps/wayland/wayland_1.19.0.bb:do_configure) failed with exit code '1'
    NOTE: Tasks Summary: Attempted 1328 tasks of which 1314 didn't need to be rerun and 1 failed.
 
    Summary: 1 task failed:
      virtual:native:<my_petalinuxroot>/project-spec/meta-user/recipes-apps/wayland/wayland_1.19.0.bb:do_configure
    Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
    ERROR: Failed to build wayland

Ok, it seems I need a newer meson, so I copied this over too from openembedded and tried to build it:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/meson

    $ petalinux-build -c meson
    [INFO] building meson
    [INFO] sourcing bitbake
    [INFO] generating user layers
    INFO: bitbake meson
    Loading cache: 100% |############################################################| Time: 0:00:00
    Loaded 3835 entries from dependency cache.
    Parsing recipes: 100% |##########################################################| Time: 0:00:01
    Parsing of 2801 .bb files complete (2798 cached, 3 parsed). 3839 targets, 162 skipped, 0 masked, 0 errors.
    NOTE: Resolving any missing task queue dependencies
    ERROR: Nothing RPROVIDES 'python3-pkg-resources' (but <my_petalinuxroot>/project-spec/meta-user/recipes-apps/meson/meson_0.57.1.bb RDEPENDS on or otherwise requires it)
    NOTE: Runtime target 'python3-pkg-resources' is unbuildable, removing...
    Missing or unbuildable dependency chain was: ['python3-pkg-resources']
    ERROR: Required build target 'meson' has no buildable providers.
    Missing or unbuildable dependency chain was: ['meson', 'python3-pkg-resources']
 
    Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
    ERROR: Failed to build meson

And this is where I started to get stuck. Grepping the openembedded repo for 'python3-pkg-resources' didn't turn up anything. Googling it seeems to suggest it is part of python-setuptools.
So I tried to install python3-setuptools by copying it over again:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3-setuptools_54.1.1.bb

    $ petalinux-build -c python3-setuptools
    [INFO] building python3-setuptools
    [INFO] sourcing bitbake
    [INFO] generating user layers
    INFO: bitbake python3-setuptools
    Loading cache: 100% |############################################################| Time: 0:00:00
    Loaded 3838 entries from dependency cache.
    WARNING: <my_petalinuxroot>/project-spec/meta-user/recipes-apps/python3-setuptools/python3-setuptools_54.1.1.bb: Unable to get checksum for python3-setuptools-native SRC_URI entry 0001-conditionally-do-not-fetch-code-by-easy_install.patch: file could not be found
    Parsing recipes: 100% |##########################################################| Time: 0:00:01
    Parsing of 2802 .bb files complete (2800 cached, 2 parsed). 3842 targets, 162 skipped, 0 masked, 0 errors.
    NOTE: Resolving any missing task queue dependencies
    ERROR: Nothing RPROVIDES 'python3-pkg-resources-native' (but virtual:native:<my_petalinuxroot>/project-spec/meta-user/recipes-apps/python3-setuptools/python3-setuptools_54.1.1.bb RDEPENDS on or otherwise requires it)
    NOTE: Runtime target 'python3-pkg-resources-native' is unbuildable, removing...
    Missing or unbuildable dependency chain was: ['python3-pkg-resources-native']
    ERROR: Required build target 'python3-setuptools' has no buildable providers.
    Missing or unbuildable dependency chain was: ['python3-setuptools', 'python3-setuptools-native', 'python3-pkg-resources-native']
 
    Summary: There was 1 WARNING message shown.
    Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
    ERROR: Failed to build python3-setuptools

I couldn't find 'python3-setuptools-native' or 'python3-pkg-resources-native' in the openembedded repo, so here my journey is over for now.


Is this way I tried even the correct way to get wayland from source into my petalinux project? Or is there a better solution?

Any help would be really appreciated.

Rgeards,
Jürgen Haase


Yocto Project Status WW11`21

Stephen Jolley
 

Current Dev Position: YP 3.3 M4 (Feature Freeze)

Next Deadline: 5th April 2021 YP 3.3 M4 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3 M3 rc1 had an issue with the beaglebone reference platform. As such, we plan to build an rc2 when this has been fixed.
  • The release series name for core has been bumped to “hardknott” and the previous one, “gatesgarth” has now been removed. We do this so that layers being actively maintained can be clearly identified compared to those which are not. Layers will need to be updated to show compatibility with the 3.3 core.
  • We’ve taken a number of version upgrades and other changes as the benefits to taking them seem to outweigh the potential risk.
  • There is a pending change to remove ‘stale’ sstate task output before the main build starts in master-next. This has been testing for a while with no reports of issues and seems to perform well so will likely be included in M3 rc2.
  • “Pending” state patch review is still needed, we have some really old stale ones which really need decisions to be made about their future. It would help a lot if recipe maintainers could review recipe patchsets and upstream them or remove them if they are no longer relevant. 
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M3 will go back to QA for rc2 soon.
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.2.3 build date 2021/03/22
  • YP 3.2.3 release date 2021/04/02
  • YP 3.1.7 build date 2021/03/29
  • YP 3.1.7 release date 2021/04/09
  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.1.8 build date 2021/05/17
  • YP 3.1.8 release date 2021/05/28

 

Tracking Metrics:

 

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

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

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-rockchip][PATCH v3] NanoPi-M4: add machines

Trevor Woerner
 

Applied, thanks! :-)


Anecdotally, having the bmap file available has the following effect on
writing a core-image-base image to a µSD card:
without: 33s
with: 11s


[meta-rockchip] defconfig alternatives

Yann Dirson
 

Hi Trevor,

Le lun. 22 mars 2021 à 16:50, Trevor Woerner <twoerner@...> a écrit :
BTW, I'm also unclear on what to do next to better support those
boards: with the default
kernel config only a subset of the hardware is supported, and for
state-of-the-art hw
support we'll also need patches not yet in upstream kernel (from eg.
armbian and libreelec).

I feel it would be good to provide defconfig files for those machines,
but then there are
several options to handle that. Would a minimal hw-focused defconfig
suitable for
`KCONFIG_MODE = "--allnoconfig"` be a good option ?
I feel exactly the same way.

By default all arm64 kernels are configured with the one, in-kernel, generic
arm64 defconfig. That gives me a kernel that is over 11MB in size, and
includes all sorts of useless drivers.

I've been working off-and-on on a mechanism for meta-rockchip that would allow
users to decide between the default in-kernel arm64 defconfig (which would
be selected by doing nothing) or using a leaner defconfig that I have been
tweaking specifically for each board. Currently I only have a lean defconfig
for rock-pi-4b, but it was my hope to generate defconfigs for all supported
boards.

Ideally I had wanted to leverage the linux-yocto kmeta mechanism to generate
defconfigs dynamically based on the specific machine and specific user
preferences, but that didn't go as smoothly as I was hoping, then I got
distracted by other things.

I had created a spreadsheet with a comparison between the various boards that
would have been a basis for the individual kmeta pieces. Maybe I'll find some
more time to poke at it later this week. I could also push my WIP stuff to
somewhere if you'd like to take a look.

In any case, my point is, I'm very interested in something better than what
currently exists :-)
On my side I have a minimal defconfig for our own board, which is very similar
to the nanopi-m4, which could be used as a starting point for the latter.


One thing that I'd like to keep clear in meta-rockchip is to always allow the
user to choose between upstream and "extras". My feeling is: the simplest
build, if the user does nothing explicit, will always pull from pure upstream
with no out-of-tree patches or vendor pieces. But I'm not opposed to having
a mechanism whereby if the user does something explicit, they can choose to
use a vendor tree or make use of out-of-tree patches for various things.
One possibility would be using a KERNEL_CONFIG_VARIANT variable, whose
values would select consistent sets of KBUILD_DEFCONFIG + KCONFIG_MODE
+ SRC_URI_append. Standard variants could include "mainline" as the
default, and
maybe "customhw" which would bring just the hw features for the board
in allnoconfig
mode.

Or maybe we could try to fit such a selection mechanism in the PACKAGECONFIG
system, but I'm not sure it would really fit.



--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


[meta-rockchip][PATCH v3] NanoPi-M4: add machines

Yann Dirson
 

From: Yann Dirson <yann@...>

We have two board variants, respectively with 2GB and 4GB RAM.

Signed-off-by: Yann Dirson <yann@...>
---

Changes from v2:
- commit message rework
- add wic.bmap
Changes from v1:
- split in two distinct machines: nanopi-m4 and nanopi-m4-2gb

conf/machine/include/nanopi-m4.inc | 22 +++++++++++++++++++
conf/machine/nanopi-m4-2gb.conf | 8 +++++++
conf/machine/nanopi-m4.conf | 8 +++++++
recipes-kernel/linux/linux-yocto-dev.bbappend | 2 ++
.../linux/linux-yocto-rt_%.bbappend | 2 ++
.../linux/linux-yocto-tiny_%.bbappend | 2 ++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 ++
7 files changed, 46 insertions(+)
create mode 100644 conf/machine/include/nanopi-m4.inc
create mode 100644 conf/machine/nanopi-m4-2gb.conf
create mode 100644 conf/machine/nanopi-m4.conf

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
new file mode 100644
index 0000000..74cdae8
--- /dev/null
+++ b/conf/machine/include/nanopi-m4.inc
@@ -0,0 +1,22 @@
+# Copyright (C) 2021 Blade SAS
+# Common definitions for all NanoPi M4 RK3399 board variants
+
+require rk3399.inc
+
+KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
+
+RK_BOOT_DEVICE =3D "mmcblk1"
+WKS_FILE ?=3D "rock-pi-4.wks"
+IMAGE_FSTYPES +=3D "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
diff --git a/conf/machine/nanopi-m4-2gb.conf b/conf/machine/nanopi-m4-2gb=
.conf
new file mode 100644
index 0000000..9fd7279
--- /dev/null
+++ b/conf/machine/nanopi-m4-2gb.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 2GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE =3D "nanopi-m4-2gb-rk3399_defconfig"
diff --git a/conf/machine/nanopi-m4.conf b/conf/machine/nanopi-m4.conf
new file mode 100644
index 0000000..648fc75
--- /dev/null
+++ b/conf/machine/nanopi-m4.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 4GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE =3D "nanopi-m4-rk3399_defconfig"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kern=
el/linux/linux-yocto-dev.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-ker=
nel/linux/linux-yocto-rt_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-k=
ernel/linux/linux-yocto-tiny_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel=
/linux/linux-yocto_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
--=20
2.30.2


Re: package_rpm and file conflicts.

Quentin Schulz
 

Hi Randall,

On Mon, Mar 22, 2021 at 06:01:59PM -0700, Randall wrote:
HI,

Building up a customization layer over the top of poke to install 3rd party RPM files at build time. These packages contain some basic global configuration changes for the destination environment.

Unfortunately I am getting RPM file conflicts (EG: /etc/network/interfaces) when I go to build. How can force the package installation allowing for the conflicting file from the custom layer to over write the files in the base packages?
You cannot, you need to either not instal init-ifupdown and
busybox-udhdpc or modify them to not install this file in your image.

Cheers,
Quentin


[meta-rockchip][PATCH] README: update mailing list info

Trevor Woerner
 

The Yocto Project mailing lists migrated to a new system and email address a
while back. Update the README with the up-to-date information.

Signed-off-by: Trevor Woerner <twoerner@...>
---
README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index a751fce..7272c3f 100644
--- a/README
+++ b/README
@@ -31,7 +31,7 @@ Status of supported boards:
Maintenance:
-----------
Please send pull requests, patches, comments, or questions to the
- yocto mailing list (yocto@...) CCing the maintainer
+ yocto mailing list (yocto@...) CCing the maintainer

When sending patches, please make sure the email subject line includes
"[meta-rockchip][PATCH]" and follow the community's patch submission
@@ -42,7 +42,7 @@ Maintenance:
For example, to send your most recent commit (i.e. just one patch),
please use something like:
git format-patch -M --subject-prefix="meta-rockchip][PATCH" HEAD^
- git send-email --to yocto@... --cc twoerner@... <your patch file>
+ git send-email --to yocto@... --cc twoerner@... <your patch file>

Maintainer:
----------
--
2.30.0.rc0


Re: [meta-rockchip][PATCH v2] Add machine definitions for NanoPi-M4 boards, 2GB and 4GB variants

Trevor Woerner
 

On Tue 2021-03-23 @ 12:25:17 AM, Trevor Woerner wrote:
On Mon 2021-03-22 @ 04:07:20 PM, yann.dirson@... wrote:
+IMAGE_FSTYPES += "wic"
Please add "wic.bmap" to IMAGE_FSTYPES in addition to "wic". It makes creating
an µSD card so much faster.
Personally, specifying wic should add wic.bmap implicitly. I can't imagine why
anyone would want to generate a wic without the bmap to go with it. But my
use-case is probably narrow.


Re: [error-report-web] [PATCH] Post/parser: Use bleach to sanitse XSS input

Khem Raj
 

On 3/22/21 10:56 AM, Richard Purdie wrote:
Instead of searching for "<", use bleach to sanity input to avoid
any XSS issues.
I will be able to test it. once its installed

Signed-off-by: Richard Purdie <richard.purdie@...>
---
Post/parser.py | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/Post/parser.py b/Post/parser.py
index f411e02..536e872 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -9,6 +9,7 @@
# Licensed under the MIT license, see COPYING.MIT for details
import json, re
+import bleach
from Post.models import Build, BuildFailure, ErrorType
from django.conf import settings
from django.utils import timezone
@@ -19,21 +20,6 @@ class Parser:
def __init__(self, data):
self.data = data.decode('utf-8')
- # returns true if the values contain '<' char
- # Ignore the failures field (which is an array anyway)
- # Ignore any non-str fields too [YOCTO #14208]
- def contains_tags (self, data):
- for key,val in data.items():
- if key == 'failures':
- continue
-
- if not isinstance(val, str):
- continue
-
- if '<' in val:
- return True
- return False
-
def parse(self, request):
build_fails_logged = []
@@ -42,8 +28,14 @@ class Parser:
except:
return { 'error' : 'Invalid json' }
- if self.contains_tags(jsondata) == True:
- return { 'error' : 'Invalid characters in json' }
+ # Bleach data going directly into the database so that
+ # displaying in any of the graphing doesn't introduce XSS
+ for key,val in jsondata.items():
+ if key == 'failures':
+ continue
+ if not isinstance(val, str):
+ continue
+ jsondata[key] = bleach.clean(val)
b = Build.objects.create()
try:


Re: [meta-rockchip][PATCH v2] Add machine definitions for NanoPi-M4 boards, 2GB and 4GB variants

Trevor Woerner
 

Hi Yann,

Sorry to nitpick…

Could you please tighten up the commit message? For example, please set
the subject to something like: "NanoPi-M4: add" or perhaps "NanoPi-M4: add
machines" then in the body give the details of exactly which boards are being
added; rather than having a long subject line and nothing in the body.

Also, I'm going to need a "signed-off-by:" line in order to accept this patch.

On Mon 2021-03-22 @ 04:07:20 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

---

Changes from v1: split in two distinct machines: nanopi-m4 and nanopi-m4-2gb

conf/machine/include/nanopi-m4.inc | 22 +++++++++++++++++++
conf/machine/nanopi-m4-2gb.conf | 8 +++++++
conf/machine/nanopi-m4.conf | 8 +++++++
recipes-kernel/linux/linux-yocto-dev.bbappend | 2 ++
.../linux/linux-yocto-rt_%.bbappend | 2 ++
.../linux/linux-yocto-tiny_%.bbappend | 2 ++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 ++
7 files changed, 46 insertions(+)
create mode 100644 conf/machine/include/nanopi-m4.inc
create mode 100644 conf/machine/nanopi-m4-2gb.conf
create mode 100644 conf/machine/nanopi-m4.conf

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
new file mode 100644
index 0000000..f6d9c11
--- /dev/null
+++ b/conf/machine/include/nanopi-m4.inc
@@ -0,0 +1,22 @@
+# Copyright (C) 2021 Blade SAS
+# Common definitions for all NanoPi M4 RK3399 board variants
+
+require rk3399.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"
+
+RK_BOOT_DEVICE = "mmcblk1"
+WKS_FILE ?= "rock-pi-4.wks"
+IMAGE_FSTYPES += "wic"
Please add "wic.bmap" to IMAGE_FSTYPES in addition to "wic". It makes creating
an µSD card so much faster.

+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES = "1500000;ttyS2"
diff --git a/conf/machine/nanopi-m4-2gb.conf b/conf/machine/nanopi-m4-2gb.conf
new file mode 100644
index 0000000..9fd7279
--- /dev/null
+++ b/conf/machine/nanopi-m4-2gb.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 2GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE = "nanopi-m4-2gb-rk3399_defconfig"
diff --git a/conf/machine/nanopi-m4.conf b/conf/machine/nanopi-m4.conf
new file mode 100644
index 0000000..648fc75
--- /dev/null
+++ b/conf/machine/nanopi-m4.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 4GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE = "nanopi-m4-rk3399_defconfig"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board = "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board = "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board = "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board = "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
--
2.30.2


[ptest-runner][PATCH 4/4] utils.c: wait_child reimplement timeout using alarm

Anibal Limon
 

Since we are using threads to read from child, no complex logic is
needed for handle timeouts use alarm(2).

[YOCTO #14220]

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
utils.c | 60 ++++++++++++++++++++-------------------------------------
1 file changed, 21 insertions(+), 39 deletions(-)

diff --git a/utils.c b/utils.c
index 84cb570..1a3c90f 100644
--- a/utils.c
+++ b/utils.c
@@ -57,6 +57,9 @@
static struct {
int fds[2];
FILE *fps[2];
+
+ int timeouted;
+ pid_t pid;
} _child_reader;

static inline char *
@@ -335,45 +338,25 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
/* exit(1); not needed? */
}

-static inline int
-wait_child(pid_t pid, int timeout, int *timeouted)
+static void
+timeout_child_handler(int signo)
{
- struct timespec sentinel;
- clockid_t clock = CLOCK_MONOTONIC;
- int looping = 1;
+ _child_reader.timeouted = 1;
+ kill(-_child_reader.pid, SIGKILL);
+}

+static inline int
+wait_child(pid_t pid, int timeout)
+{
int status = -1;
- int waitflags;
-
- if (clock_gettime(clock, &sentinel) == -1) {
- clock = CLOCK_REALTIME;
- clock_gettime(clock, &sentinel);
- }
-
- *timeouted = 0;

- while (looping) {
- waitflags = WNOHANG;
+ _child_reader.timeouted = 0;
+ _child_reader.pid = pid;

- if (timeout >= 0) {
- struct timespec time;
-
- clock_gettime(clock, &time);
- if ((time.tv_sec - sentinel.tv_sec) > timeout) {
- *timeouted = 1;
- kill(-pid, SIGKILL);
- waitflags = 0;
- }
- }
-
- if (waitpid(pid, &status, waitflags) == pid)
- looping = 0;
-
- clock_gettime(clock, &sentinel);
-
- if (WIFEXITED(status))
- status = WEXITSTATUS(status);
- }
+ alarm(timeout);
+ waitpid(pid, &status, 0);
+ if (WIFEXITED(status))
+ status = WEXITSTATUS(status);

return status;
}
@@ -438,7 +421,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
pid_t child;
int pipefd_stdout[2];
int pipefd_stderr[2];
- int timeouted;
time_t sttime, entime;
time_t duration;
int slave;
@@ -477,6 +459,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
close(pipefd_stdout[1]);
break;
}
+ signal(SIGALRM, timeout_child_handler);

fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p)
@@ -527,8 +510,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "BEGIN: %s\n", ptest_dir);


- status = wait_child(child, opts.timeout, &timeouted);
-
+ status = wait_child(child, opts.timeout);

entime = time(NULL);
duration = entime - sttime;
@@ -538,11 +520,11 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
rc += 1;
}
fprintf(fp, "DURATION: %d\n", (int) duration);
- if (timeouted)
+ if (_child_reader.timeouted)
fprintf(fp, "TIMEOUT: %s\n", ptest_dir);

if (opts.xml_filename)
- xml_add_case(xh, status, ptest_dir, timeouted, (int) duration);
+ xml_add_case(xh, status, ptest_dir, _child_reader.timeouted, (int) duration);

fprintf(fp, "END: %s\n", ptest_dir);
fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, entime));
--
2.31.0


[ptest-runner][PATCH 3/4] utils.c: Use a thread to read from child

Anibal Limon
 

In order to handle large output add a thread for read from childs using
a pipe and remove non-blocking option.

Modify bash unittest to output large data and cover this scenario.

[YOCTO #14220]

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
Makefile | 2 +-
tests/data/bash/ptest/run-ptest | 4 +-
utils.c | 112 +++++++++++++++++++++-----------
3 files changed, 78 insertions(+), 40 deletions(-)

diff --git a/Makefile b/Makefile
index 3cca17b..1aa1830 100644
--- a/Makefile
+++ b/Makefile
@@ -31,7 +31,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)

$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -pthread -lutil -o $@

tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)

diff --git a/tests/data/bash/ptest/run-ptest b/tests/data/bash/ptest/run-ptest
index 09f997f..f36e077 100755
--- a/tests/data/bash/ptest/run-ptest
+++ b/tests/data/bash/ptest/run-ptest
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

echo "bash"
printf "Hello World!,stderr\n" >&2
@@ -7,3 +7,5 @@ printf "Hello World!,stderr2\n" >&2
echo "bash3"
echo "bash4"
printf "Hello World!,stderr3\n" >&2
+
+echo {1..1000000}\\n
diff --git a/utils.c b/utils.c
index d784736..84cb570 100644
--- a/utils.c
+++ b/utils.c
@@ -39,6 +39,7 @@
#include <string.h>
#include <time.h>
#include <unistd.h>
+#include <pthread.h>

#include <sys/ioctl.h>
#include <sys/resource.h>
@@ -53,6 +54,11 @@
#define WAIT_CHILD_POLL_TIMEOUT_MS 200
#define WAIT_CHILD_BUF_MAX_SIZE 1024

+static struct {
+ int fds[2];
+ FILE *fps[2];
+} _child_reader;
+
static inline char *
get_stime(char *stime, size_t size, time_t t)
{
@@ -269,6 +275,44 @@ close_fds(void)
}
}

+static void *
+read_child(void *arg)
+{
+ struct pollfd pfds[2];
+ int r;
+
+ pfds[0].fd = _child_reader.fds[0];
+ pfds[0].events = POLLIN;
+ pfds[1].fd = _child_reader.fds[1];
+ pfds[1].events = POLLIN;
+
+ do {
+ r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
+ if (r > 0) {
+ char buf[WAIT_CHILD_BUF_MAX_SIZE];
+ ssize_t n;
+
+ if (pfds[0].revents != 0) {
+ n = read(_child_reader.fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE);
+ if (n > 0)
+ fwrite(buf, (size_t)n, 1, _child_reader.fps[0]);
+ }
+
+ if (pfds[1].revents != 0) {
+ n = read(_child_reader.fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE);
+ if (n > 0)
+ fwrite(buf, (size_t)n, 1, _child_reader.fps[1]);
+ }
+
+ }
+
+ fflush(_child_reader.fps[0]);
+ fflush(_child_reader.fps[1]);
+ } while (1);
+
+ return NULL;
+}
+
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
@@ -292,22 +336,15 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
}

static inline int
-wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
+wait_child(pid_t pid, int timeout, int *timeouted)
{
- struct pollfd pfds[2];
struct timespec sentinel;
clockid_t clock = CLOCK_MONOTONIC;
int looping = 1;
- int r;

int status = -1;
int waitflags;

- pfds[0].fd = fds[0];
- pfds[0].events = POLLIN;
- pfds[1].fd = fds[1];
- pfds[1].events = POLLIN;
-
if (clock_gettime(clock, &sentinel) == -1) {
clock = CLOCK_REALTIME;
clock_gettime(clock, &sentinel);
@@ -332,32 +369,12 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
if (waitpid(pid, &status, waitflags) == pid)
looping = 0;

- r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
- if (r > 0) {
- char buf[WAIT_CHILD_BUF_MAX_SIZE];
- ssize_t n;
-
- if (pfds[0].revents != 0) {
- while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, (size_t)n, 1, fps[0]);
- }
-
- if (pfds[1].revents != 0) {
- while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
- fflush(fps[0]);
- fwrite(buf, (size_t)n, 1, fps[1]);
- fflush(fps[1]);
- }
- }
-
- clock_gettime(clock, &sentinel);
- }
+ clock_gettime(clock, &sentinel);

if (WIFEXITED(status))
status = WEXITSTATUS(status);
}

- fflush(fps[0]);
return status;
}

@@ -426,6 +443,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
time_t duration;
int slave;
int pgid = -1;
+ pthread_t tid;

if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -435,18 +453,32 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,

do
{
- if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
+ if ((rc = pipe(pipefd_stdout)) == -1)
break;

- if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
+ if ((rc = pipe(pipefd_stderr)) == -1) {
close(pipefd_stdout[0]);
close(pipefd_stdout[1]);
break;
}
- fprintf(fp, "START: %s\n", progname);
+
if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
}
+
+ _child_reader.fds[0] = pipefd_stdout[0];
+ _child_reader.fds[1] = pipefd_stderr[0];
+ _child_reader.fps[0] = fp;
+ _child_reader.fps[1] = fp_stderr;
+ rc = pthread_create(&tid, NULL, read_child, NULL);
+ if (rc != 0) {
+ fprintf(fp, "ERROR: Failed to create reader thread, %s\n", strerror(errno));
+ close(pipefd_stdout[0]);
+ close(pipefd_stdout[1]);
+ break;
+ }
+
+ fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p)
char *ptest_dir = strdup(p->run_ptest);
if (ptest_dir == NULL) {
@@ -485,8 +517,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,

} else {
int status;
- int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
- FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;

if (setpgid(child, pgid) == -1) {
fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
@@ -496,17 +526,20 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);

- status = wait_child(child, opts.timeout, fds, fps, &timeouted);
+
+ status = wait_child(child, opts.timeout, &timeouted);
+
+
entime = time(NULL);
duration = entime - sttime;

if (status) {
- fprintf(fps[0], "\nERROR: Exit status is %d\n", status);
+ fprintf(fp, "\nERROR: Exit status is %d\n", status);
rc += 1;
}
- fprintf(fps[0], "DURATION: %d\n", (int) duration);
+ fprintf(fp, "DURATION: %d\n", (int) duration);
if (timeouted)
- fprintf(fps[0], "TIMEOUT: %s\n", ptest_dir);
+ fprintf(fp, "TIMEOUT: %s\n", ptest_dir);

if (opts.xml_filename)
xml_add_case(xh, status, ptest_dir, timeouted, (int) duration);
@@ -517,6 +550,9 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
PTEST_LIST_ITERATE_END
fprintf(fp, "STOP: %s\n", progname);

+ pthread_cancel(tid);
+ pthread_join(tid, NULL);
+
close(pipefd_stdout[0]); close(pipefd_stdout[1]);
close(pipefd_stderr[0]); close(pipefd_stderr[1]);
} while (0);
--
2.31.0


[ptest-runner][PATCH 2/4] utils.c: Fix exit status of a child

Anibal Limon
 

Modify testcase to validate the actual exit status.

[YOCTO #14217]

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
tests/data/fail/ptest/run-ptest | 3 +++
tests/utils.c | 2 +-
utils.c | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
mode change 100644 => 100755 tests/data/fail/ptest/run-ptest

diff --git a/tests/data/fail/ptest/run-ptest b/tests/data/fail/ptest/run-ptest
old mode 100644
new mode 100755
index e69de29..f4e5d0b
--- a/tests/data/fail/ptest/run-ptest
+++ b/tests/data/fail/ptest/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exit 10
diff --git a/tests/utils.c b/tests/utils.c
index 132d98f..105e0c8 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -234,7 +234,7 @@ END_TEST
static void
search_for_fail(const int rp, FILE *fp_stdout)
{
- const char *fail_str = "ERROR: Exit status is";
+ const char *fail_str = "ERROR: Exit status is 10";
char line_buf[PRINT_PTEST_BUF_SIZE];
int found_fail = 0;
char *line = NULL;
diff --git a/utils.c b/utils.c
index 43ab03b..d784736 100644
--- a/utils.c
+++ b/utils.c
@@ -352,6 +352,9 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)

clock_gettime(clock, &sentinel);
}
+
+ if (WIFEXITED(status))
+ status = WEXITSTATUS(status);
}

fflush(fps[0]);
--
2.31.0


[ptest-runner][PATCH 1/4] utils.c: get_available_ptests allow to specify relative directories

Anibal Limon
 

Fixes,

$ ./ptest-runner -d ./tests/data bash

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
utils.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/utils.c b/utils.c
index a4e190e..43ab03b 100644
--- a/utils.c
+++ b/utils.c
@@ -34,6 +34,7 @@
#include <poll.h>
#include <pty.h>
#include <signal.h>
+#include <limits.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
@@ -85,6 +86,9 @@ get_available_ptests(const char *dir)
struct dirent **namelist;
int fail;
int saved_errno = -1; /* Initalize to invalid errno. */
+ char realdir[PATH_MAX];
+
+ realpath(dir, realdir);

do
{
@@ -93,7 +97,7 @@ get_available_ptests(const char *dir)
if (head == NULL)
break;

- if (stat(dir, &st_buf) == -1) {
+ if (stat(realdir, &st_buf) == -1) {
PTEST_LIST_FREE_CLEAN(head);
break;
}
@@ -104,7 +108,7 @@ get_available_ptests(const char *dir)
break;
}

- n = scandir(dir, &namelist, NULL, alphasort);
+ n = scandir(realdir, &namelist, NULL, alphasort);
if (n == -1) {
PTEST_LIST_FREE_CLEAN(head);
break;
@@ -130,7 +134,7 @@ get_available_ptests(const char *dir)
}

if (asprintf(&run_ptest, "%s/%s/ptest/run-ptest",
- dir, d_name) == -1) {
+ realdir, d_name) == -1) {
fail = 1;
saved_errno = errno;
free(d_name);
--
2.31.0


package_rpm and file conflicts.

Randall <randall.crook@...>
 

HI,

Building up a customization layer over the top of poke to install 3rd party RPM files at build time. These packages contain some basic global configuration changes for the destination environment. 

Unfortunately I am getting RPM file conflicts (EG: /etc/network/interfaces) when I go to build. How can force the package installation allowing for the conflicting file from the custom layer to over write the files in the base packages?

EG:

 file /etc/network/interfaces conflicts between attempted installs of router-1.0-r0.noarch and init-ifupdown-1.0-r7.qemuarm64
 file /etc/udhcpc.d/50default conflicts between attempted installs of router-1.0-r0.noarch and busybox-udhcpc-1.24.1-r0.aarch64


M+ & H bugs with Milestone Movements WW12

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW12 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11449

Allow overriding classes to override overridden classes

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

11746

oe-selftest: capture self.logger messages in XML output

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12937

Consistent naming scheme for deployed artifacts

randy.macleod@...

Martin.Jansa@...

3.3 M3

3.4 M1

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12986

Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13183

bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13278

If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13448

bitbake master appears to expand variables it should not need to

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13699

Prolonged recipe parsing times after removing tmp when the resident bitbake server is used

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13711

Parsing fails on externalsrc recipe containing both git and file in SRC_URI

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13742

HashEquiv server should have a read-only port or endpoint

randy.macleod@...

dl9pf@...

3.3 M3

3.4 M1

 

13823

fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13886

bitbake resident server does not honour --runonly or --runall options

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13975

cve-checker: save to alternate file format like JSON

randy.macleod@...

chee.yang.lee@...

3.3 M3

3.4 M1

 

13973

change siginfo data format to json for reproducibility? (siginfo files currently not reproducible)

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14021

Remove debug_domain logic

randy.macleod@...

JPEWhacker@...

3.4

3.4 M1

 

14088

Attempting to override RDEPENDS_${PN} from global config doesn't work

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14123

Intermittent FileNotFound error on autobuilder oe-selftest-debian

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14125

busybox wget ssl is exposed to MitM attack due to CVE-2018-1000500

randy.macleod@...

shachar@...

3.3 M3

3.3 M4

 

14156

gitsm: submodules are fetched as mirrored and not working as expected

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14227

Intermittent oe-selftest fails with bash 5.1 do_compile

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW12!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

4

richard.purdie@...

2

JPEWhacker@...

2

yifan.yu@...

1

dorindabassey@...

1

kergoth@...

1

steve@...

1

Grand Total

12

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 42 bug owners as of the end of WW12 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 28 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

ross@...

24

bluelightning@...

14

richard.purdie@...

9

mark.morton@...

7

JPEWhacker@...

7

akuster808@...

5

raj.khem@...

4

Qi.Chen@...

4

chee.yang.lee@...

4

trevor.gamblin@...

4

idadelm@...

3

timothy.t.orling@...

3

mostthingsweb@...

3

sakib.sajal@...

3

matthewzmd@...

2

ydirson@...

2

limon.anibal@...

2

bruce.ashfield@...

2

jeanmarie.lemetayer@...

2

stacygaikovaia@...

2

nicolas.dechesne@...

2

randy.macleod@...

2

jaewon@...

2

alejandro@...

2

yoctoproject@...

1

dorindabassey@...

1

mark.hatle@...

1

devendra.tewari@...

1

kergoth@...

1

twoerner@...

1

aehs29@...

1

anuj.mittal@...

1

jon.mason@...

1

pokylinux@...

1

mhalstead@...

1

mshah@...

1

mister_rs@...

1

hongxu.jia@...

1

john.kaldas.enpj@...

1

matt.ranostay@...

1

kexin.hao@...

1

open.source@...

1

Grand Total

132

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 366 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Joshua Watt
 

On 3/22/21 2:30 PM, Yann Dirson wrote:
Hi Joshua,

Le lun. 22 mars 2021 à 19:24, Joshua Watt <jpewhacker@...> a écrit :

On 3/22/21 9:59 AM, Yann Dirson wrote:

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@...> a écrit :

On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@... wrote:

This supports both the 2GB and 4GB versions of the board. This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/
Wait, it's only the dtb used by u-boot which is different in this
case, the kernel uses a single dtb for both variants.
Those probably get embedded inside the bootloader, in any case they
are not those embedded in the fitImage.

#include "rk3399-nanopi4-u-boot.dtsi"
-#include "rk3399-sdram-ddr3-1866.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"

I have no clue how easily the two boards could be told one from the
other (let alone if that can be done safely),
and I feel that would rather be uboot-side work, rather than something
to be solved on the yocto side.
Ah, I was referring to the DTB used by the Kernel (which u-boot can switch), not the DTB used by u-boot itself (which AFAIK is compiled into u-boot and cannot be changed).







4621 - 4640 of 57410